Subject: [eap] Proposed resolution to Issue 54: Accept

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 18:52:32 -0800 (PST)

Issue 54, listed below, proposes to clarify the specification so as to
make clear that a NAK with no Type is unacceptable. My proposal is that
this change is accepted.

=================================
Issue 54: Problem with NAK type
Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: 1
Section: 5.3
Rationale/Explanation of issue:

This also breaks RFC 2284 compatibility. In the original RFC, the
type field was *required*. Systems implemented to RFC 2284 will
*discard* bogus Nak messages that don't have a suggested type field.
Instead, if "Nak with no alternative" is required (I don't think it
is), then I suggest either a reserved value (e.g., 0) or (better yet)
using the value 1 (Identity) to tell the peer to start over.

Requested change:

from:

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.

to:
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 a single octet
authentication Type desired by the Peer. This value may be 1
(Identity) to indicate that the sender has no viable alternatives,
or that the authentication attempt should be restarted.