Subject: [eap] Proposed Resolution to Issue 53: NAK of Identity messages

From: [email-masked] (Bernard Aboba)
Date: Fri, 3 Jan 2003 15:35:46 -0800 (PST)

RFC 2284 appears to support the notion that a NAK may not be sent in
Response to an Identity Request. However, this leaves open the question of
what an authenticator does if a NAK is sent anyway. While it can be argued
that Peer with an unknown identity can send a NULL Identity Response,
there are other cases where the Peer might want to terminate the
conversation. For example, if an 802.11 STA sends an Identity Request to
an AP (EAP is a Peer to Peer protocol so this is legal), the AP could
silently discard the packet, but this will just result in a
retransmission. So there is a need for a packet that a Peer can send that
says "I don't want to authenticate, please stop."

As a result, the proposed resolution is not to prohibit the sending of a
NAK, but to make clear that this is not the preferred way to say "I don't
have an Identity" -- sending a NULL Identity Response is preferred.
Rather, the implication is "I am requesting Identity Protection" (if one
or more alternate Types are provided) or "Please go away" (if no Types are
provided).

Proposed Text:

"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 SHOULD
send a NULL Identity Response. If the peer requires identity
protection (wants to negotiate a method that negotiates cryptographic
protection before providing its Identity), then it MAY send a
Nak, including one or more preferred Types. If the peer does not
wish to authentiate via EAP, then it MAY send a NAK with no alternative
authentication method."

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.
Response from Bernard Aboba:
"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.