Subject: [eap] Issue 36: When may a NAK be sent?

From: [email-masked] (Bernard Aboba)
Date: Sat, 5 Oct 2002 19:28:27 -0700 (PDT)

Issue 36: When may a NAK be sent?
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: 1
Section: 5.3

Rationale/Explanation of issue:

RFC 2284bis doesn't state when a NAK can be sent, and when not. For
example:

a. Whether a NAK may only be sent in response to a method proposal or
b. Whether NAK can be sent at any time (e.g. in the middle of a method
exchange)

Change:

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

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 1 and 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.
For example, a NAK MUST NOT be sent in the middle of an EAP
method conversation."

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 08 Oct 2002 12:49:42 -0400

I am not sure about this.  I wonder what a peer method does if it gets
req in the middle of a method that doesn't seem right.  Does it quietly
discard?  I should think it might want a way to positively indicate that
it was not happy.  

John

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

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Oct 2002 22:00:46 -0700 (PDT)

> discard?  I should think it might want a way to positively indicate that

I think that this requires a method-specific error message, no? The
problem with allowing a NAK in the middle of the method is that the NAK is
unprotected, and has very limited semantics, so that it can't serve as a
general purpose error message, and can be easily spoofed. Plus, like
Notification, you can't assume that the Nak is delivered to the method.

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 09 Oct 2002 07:25:07 -0400

> Notification, you can't assume that the Nak is delivered to the method.

I agree that the NAK doesn't get sent directly to the method.  But if
there were an API, I would think it would indicate to the method that it
was no longer the method of choice so it could clean up.

So -- thinking of the possibility of peer and authenticator methods that
may have a bug - what does a peer do when it gets arequest for a method
that it thinks is done?