Subject: [eap] Re: Issue 53: NAK of Identity message

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

Here is the text in RFC 2284 that lead to the conclusion that Identity
Requests (and Notification Requests) can't be NAK'd:

Section 3.3

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

Since Identity is Type 1, and Notification is Type 2, the conclusion was
drawn that NAKs cannot be sent in response to these requests.

Section 3.1 states:

"A Response MUST be sent to this Request with a Type of 1 (Identity)."

This could be interpretted as saying that the Response MUST be of Type 1,
or that a Response MUST be sent when the Request is of Type 1.

Issue 53: NAK of Identity message
Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:

The change made in this draft breaks compatibility with the prior RFC,
and doesn't appear to add any benefit. Worse, it means that there's
now a completely undefined corner in the protocol: what do you do if
the peer sends Nak for Identity anyway? Do you terminate? Try again?
This was once well-defined (process as you would for any Nak), and is
now undefined.

Requested change:

from:

An optional displayable message MAY be included within an Identity
Request, to prompt the Peer in the case where there is an expectation
of interaction with a user. An Identity Response MUST be sent to an
Identity Request. A Peer MUST NOT respond to an Identity Request with
a NAK.

to:

An optional displayable message MAY be included within an Identity
Request, to prompt the Peer in the case where there is an expectation
of interaction with a user. An Identity Response MUST be sent to an
Identity Request. A peer with no known identity to offer MAY send
Nak instead.

---

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

> unacceptable.   Authentication Types are numbered 4 and above."

That part seems like a mostly reasonable interpretation, though I'm
less convinced that equating "identity is the null string" and
"facility to identify peer is unavailable" together is a good thing.

In that case, I think the text should indicate what an implementation
should (or may) do if it sees Types 0 to 3 in a Nak.

> or that a Response MUST be sent when the Request is of Type 1.

I've always read that as the former -- if any Response is generated,
it must have Type set to 1.  I read it that way because of the nearly
identical text in section 3.6:

      The Type-Data field in the Request contains a displayable message
      greater than zero octets in length.  The length of the message is
      determined by Length field of the Request packet.  The message
      MUST not be null terminated.  A Response MUST be sent in reply to
      the Request with a Type field of 6 (Generic Token Card).  The
      Response contains data from the Token Card required for
      authentication.  The length is of the data is determined by the
      Length field of the Response packet.

Surely, that can't possibly mean that nobody is allowed to send Nak
for Generic Token Card.

-- 
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] (Bernard Aboba)
Date: Thu, 2 Jan 2003 10:01:35 -0800 (PST)

> should (or may) do if it sees Types 0 to 3 in a Nak.

Any suggestions?

> it must have Type set to 1.

That's how I read it as well.