Subject: [eap] Proposed Resolution to Issue 41: Nak of Extended Types

From: [email-masked] (Bernard Aboba)
Date: Sat, 18 Jan 2003 22:56:48 -0800 (PST)

I would like to propose that we modify the text of Section 5.3 (Nak) as
follows to take into account the changes proposed by Paul Funk and James Carlson.

5.3.  Nak

Description

   The 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 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 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 the Request contains a Type within the original EAP Type space
   (1-253, 255), or the Request contains an expanded Type as defined in
   Section 5.7, but the peer does not support the expanded Type space,
   then the Type-Data field MUST contain one or more octets indicating
   the desired authentication Type(s) within the original EAP Type space
   (one octet per type), or the value zero (0) to indicate no proposed
   alternative.

   If the Request contains an expanded Type as defined in Section 5.7,
   and the peer supports the expanded Type space, and desires to offer
   at least one alternative method within that expanded space, then the
   Type-Data field MUST contain one or more expanded format entries, all
   of which MUST be in the following format (see Section 5.7 for details
   on the Vendor-Id and Vendor-Type fields):

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=254    |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor-Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--------------------------------------------------------------
Issue 41: NAK of Extended Types
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 23, 2002
Reference:
Document: RFC2284bis-07
Comment type: T
Priority: S
Section:  5.3
Rationale/Explanation of issue:

Currently it is not possible to effectively NAK within the Extended EAP
type space.

For example, what happens when the authenticator proposes an Extended or
Vendor-Specific EAP Type, and the client supports the Extended type (255),
but not the vendorID or Extended Type that is being proposed?

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 21 Jan 2003 11:30:22 -0800 (PST)

Based on the recent conversation with Paul, I'd like to modify this
proposed resolution to the below section. Hopefully this is closer to the
right answer.

5.3.  Nak

Description

Code

   2 for Response.

Identifier

Length

Type

   3

Type-Data

   Where the Request contains a Type within the original EAP Type space
   (1-253, 255), or the Request contains an expanded Type as defined in
   Section 5.7, but the peer does not support expanded Types, then the
   Type-Data field of the 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.  When the Nak
   Response includes as one of the Type(s) the value 254, this indicates
   an expanded Type of preference indicated by the relative order.  If
   the authenticator can accomodate this preference, it will respond
   with a an expanded Type Request.

   If a peer supporting expanded Types receives an expanded Type
   Request, then the Type-Data field of the Nak Response, if sent, MUST
   contain one or more authentication Types, all of which MUST be in the
   format below (8 octets per Type). This includes the encoding of zero
   (0), to indicate no proposed alternative. See Section 5.7 for details
   on the Vendor-Id and Vendor-Type fields.  If the peer does not
   support expanded Types, then the Type-Data field of the Nak Response
   MUST contain one or more authentication Type(s), one octet per Type,
   or the value zero (0) to indicate no proposed alternative.  However,
   the value 254 MUST NOT be included as one of the preferred
   authentication Types.

    0                   1                   2                   3