none
PEAP/NAP flow with non NAP capable client RRS feed

Answers

  • Hello Maya,

     

    As specified in [MS-PEAP] Section 3.2.5.4.5 Received SoH Request TLV, the NAK is defined in [RFC3748] Section 5.3.

    The blog describes a scenario where the client is not NAP capable. This means the PEAP peer does not support the SoH EAP Extensions Method, so the PEAP peer does not support the SoH transmission for Network Access Protection (NAP) protocol.

    As a result, the PEAP peer MUST send a NAK to the PEAP server, as specified in 3.2.5.4.5 Received SoH Request TLV. Then PEAP MUST proceed Phase 2 of PEAP, as specified in 3.3.5.4.5 Received EAP NAK.

    In the blog example, the EAP Result packet describes a peer that is sending a legacy NAK (type = 03, see RFC3748 Section 5.3). The Type-Data = 1a indicates the desired authentication type is MS-CHAPv2. The logic for a client to propose alternative desired authentication types is described in RFC3748 Section 5.3.1.

    On another note, PEAP status and error handling are defined in common details 3.1.5.1 Status and Error Handling.

     

    Best regards,

    Edgar

    Friday, May 7, 2010 7:24 PM
    Moderator

All replies

  • Hello Maya,

       Thank you for your question regarding one of the Microsoft Open Specifications Support Team regarding PEAP. A member of  the Microsoft Open Specifications Support team will be in contact with you soon to help you with these questions.

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM

    Tuesday, May 4, 2010 2:36 PM
  • Hi Maya,

    I have taken ownership of your question and will be be providing the answer once I complete my research.

    Regards,

    Edgar

    Tuesday, May 4, 2010 3:28 PM
    Moderator
  • Hello Maya,

     

    As specified in [MS-PEAP] Section 3.2.5.4.5 Received SoH Request TLV, the NAK is defined in [RFC3748] Section 5.3.

    The blog describes a scenario where the client is not NAP capable. This means the PEAP peer does not support the SoH EAP Extensions Method, so the PEAP peer does not support the SoH transmission for Network Access Protection (NAP) protocol.

    As a result, the PEAP peer MUST send a NAK to the PEAP server, as specified in 3.2.5.4.5 Received SoH Request TLV. Then PEAP MUST proceed Phase 2 of PEAP, as specified in 3.3.5.4.5 Received EAP NAK.

    In the blog example, the EAP Result packet describes a peer that is sending a legacy NAK (type = 03, see RFC3748 Section 5.3). The Type-Data = 1a indicates the desired authentication type is MS-CHAPv2. The logic for a client to propose alternative desired authentication types is described in RFC3748 Section 5.3.1.

    On another note, PEAP status and error handling are defined in common details 3.1.5.1 Status and Error Handling.

     

    Best regards,

    Edgar

    Friday, May 7, 2010 7:24 PM
    Moderator