Subject: [eap] Potential resolution of Issue 41: Expanded Nak

From: [email-masked] (Bernard Aboba)
Date: Sun, 9 Feb 2003 11:13:22 -0800 (PST)

At the risk of misunderstanding Paul's suggested fix once again, I would
like to submit the following potential resolution of Issue 41. This
involves replacing the current Section 5.3 with the following:

5.3.  Nak

5.3.1 Legacy Nak

Description

   The legacy Nak Type is valid only in Response messages. It is sent
   in reply to a Request where the desired authentication Type is
   unacceptable. Authentication Types are numbered 4 and above.
   The Response contains one or more authentication Types desired
   by the Peer. Type zero (0) is used to indicate that the sender
   has no viable alternatives.

   Since the legacy Nak Type is only valid in Responses and has very
   limited functionality, it MUST NOT be used as a general purpose error
   indication, such as for communication of error messages, or
   negotiation of parameters specific to a particular EAP method.

Code

   2 for Response.

Identifier

   The Identifier field is one octet and aids in matching Responses
   with Requests. The Identifier field of a legacy Nak Response
   MUST match the Identifier field of the Request packet that it
   is sent in response to.

Length

   >=6

Type

   3

Type-Data

   Where any peer receives a Request for an unacceptable Type in the
   range (1-253,255), or a peer lacking support for expanded Types
   receives a Request for Type 254, a legacy Nak Response MUST be sent. The
   Type-Data field of the legacy Nak Response MUST contain one or more
   octets indicating the desired authentication Type(s), one octet per
   Type, or the value zero (0) to indicate no proposed alternative. A
   peer supporting expanded Types that receives a Request for an
   unacceptable Type (1-253, 255) MAY include the value 254
   in the legacy Nak Response in order to indicate the desire for
   an expanded authentication Type. If the authenticator can accomodate
   this preference, it will respond with an expanded Type Request.

5.3.2 Expanded Nak

Description

   The expanded Nak Type is valid only in Response messages. It MUST
   be sent only in reply to a Request of Type 254 (expanded Type)
   where the authentication Type is unacceptable. The expanded Nak
   Type uses the expanded Type format itself, and the Response
   contains one or more authentication Types desired by the peer,
   all in expanded Type format. Type zero (0) is used to indicate
   that the sender has no viable alternatives.

   Since the expanded Nak Type is only valid in Responses and
   has very limited functionality, it MUST NOT be used as a
   general purpose error indication, such as for communication
   of error messages, or negotiation of parameters specific to
   a particular EAP method.

Code

   2 for Response.

Identifier

   The Identifier field is one octet and aids in matching Responses
   with Requests. The Identifier field of a expanded Nak Response
   MUST match the Identifier field of the Request packet that it
   is sent in response to.

Length

   >=40

Type

   254

Vendor-Id

     0 (IETF)

Vendor-Type

     3 (Nak)

Vendor-Data

   The expanded Nak Type is only sent when the Request contains an
   expanded Type (254) as defined in Section 5.7. The Vendor-Data
   field of the Nak Response MUST contain one or more authentication
   Types (4 or greater), all in expanded format, 8 octets per Type,
   or the value zero (0), also in expanded Type format, to indicate
   no proposed alternative. The desired authentication Types may
   include a mixture of Vendor-Specific and IETF Types. For example,
   an expanded Nak Response indicating a preference for OTP (Type 5),
   and an MIT (Vendor-Id=20) Vendor-Specific Type  of 6 would
   appear as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     2         |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=254    |                0 (IETF)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                3 (Nak)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=254    |                0 (IETF)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                5 (OTP)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=254    |                20 (MIT)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                6                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An expanded Nak Response indicating a no desired alternative
   would appear as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     2         |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=254    |                0 (IETF)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                3 (Nak)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=254    |                0 (IETF)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                0 (No alternative)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: [email-masked] (Paul Funk)
Date: Sun, 09 Feb 2003 19:26:14 -0500

Bernard,

Yes, this is exactly what I had in mind.

You use the term "expanded type" to refer to 254, but section 5.7
defines "vendor-specific type" to mean the same thing. I prefer
"expanded type" and would suggest updating 5.7 with that term.

Paul

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 9 Feb 2003 15:16:51 -0800 (PST)

Wow! I actually got it right this time :) I agree that section 5.7 should
be updated as you state.