Subject: [eap] Re: Issue 54: Problem with NAK type

From: [email-masked] (Bernard Aboba)
Date: Thu, 2 Jan 2003 09:56:48 -0800 (PST)

Here is the text from RFC 2284 that might support the conclusion that the
NAK Type might contain no alternatives:

Section 2.2.1:

When sending a Nak in response to a
Request, the peer MAY indicate an alternative desired
authentication Type which it supports.

On the other hand, section 3.3 says:

This field MUST contain a single octet indicating the desired
authentication type.

John V. or Larry Blunk -- can you clarify the intent here?

------------------------------------------------------------
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.

---

From: [email-masked] (James Carlson)
Date: Thu, 2 Jan 2003 14:22:37 -0500

> authentication Type which it supports.

I ways assumed that meant "or might have non-working garbage such as
zero in this field," but you're right that it's lacking detail on what
was intended in the 'not' case.

> or that the authentication attempt should be restarted.

Actually, now that I've looked that over again, I'd like to amend it
further by removing the word "initial."  EAP as defined in RFC 2284
has no such concept as "method proposal."  There's no reason that I
can see to suppose that the first Request of a given Type is somehow
special, beyond what the method definition itself specifies.

More to the point: there's no apparent reason to prohibit an
implementation from getting half way through an authentication method
before saying "oops; I can't go on -- please use something else."

(I think the "method proposal" language is another example of the
implementation leaking into the protocol specification: the fact that
any vendor's implementation internally presumes that it will run one
method to completion and then signal another method to run has nothing
to do with the definition of EAP itself.  Especially because of fast
rechallenge support in some methods, I think this needs to be left to
the documentation of the individual methods.  That is, *if* the
authenticatee can presume anything at all from seeing a different Type
in a Request [i.e., "discard state here"], then that needs to be
documented.)

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 02 Jan 2003 17:48:56 -0500

It has been a long time and my recollection may be faulty - but I think the 
intent was to allow the NAK to have zero or one alternatives.  The wording 
is certainly up for grabs, and I think the proposed change would be good, 
and would make it clearer to implementers.

--On Thursday, January 02, 2003 9:56 AM -0800 Bernard Aboba 
<[email-masked]> wrote:

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap