Subject: [eap] Issue 41: NAK of Extended Types

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 11:34:52 -0800 (PST)

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?

Here is the example Extended Type payload:

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=255 |                    Vendor-Id                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Vendor-Type                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposed solution:
Change:

"Description

The Nak Type is valid only in Response messages. It is sent in reply
to a method proposal (the initial EAP Request for a given Type) where
the desired authentication Type is unacceptable. Authentication
Types are numbered 4 and above. The Response contains zero or more
authentication Types desired by the peer. A Nak with no
authentication Type(s) indicates that the Peer does not wish to
authenticate using the proposed method but is not proposing an
alternative.

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. As a
result, a NAK is only sent in response to a method proposal and MUST
NOT be sent in the middle of an EAP method conversation.
Type-Data

This field MUST contain zero or more octets indicating the desired
authentication Types, in order of preference, with the most preferred
method first. In order to avoid an interminable negotiation, the Peer
MUST only include Types that it is willing to accept."

To:

"Description

The Nak Type is valid only in Response messages. It is sent in reply
to a method proposal (the initial EAP Request for a given Type) where
the desired authentication Type is unacceptable. Authentication
Types are numbered 4 and above. The Response contains zero or one
authentication Type desired by the peer. A Nak with no
authentication Type indicates that the Peer does not wish to
authenticate using the proposed method but is not proposing an
alternative.

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. As a
result, a NAK is only sent in response to a method proposal and MUST
NOT be sent in the middle of an EAP method conversation.

Type-Data

Where the desired authentication Type is within the
original EAP Type space (1-254), the Type-Data field, when present, MUST
contain a single octet indicating the desired authentication
Type.

Where the desired authentication Type is a method
within the extended EAP Type space (Type=255), the Type-Data
field is formatted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        255    |               Vendor-Id                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Type...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+