Subject: [eap] Issue 117: Miscellaneous Technical NITs

From: [email-masked] (Bernard Aboba)
Date: Sat, 26 Apr 2003 18:16:23 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 25th, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 4.1, 5, 5.2, 5.3.1, Appendix B
Rationale/Explanation of issue:

Section 4.1, third paragraph, add to the end:

"An EAP server receiving a Response not meeting this requirement MUST
silently discard it."

Section 5, second paragraph. Change:

" The remaining Types define authentication exchanges. The Nak Type is
valid only for Response packets, it MUST NOT be sent in a Request.
The Nak Type MUST only be sent in response to a Request which uses an
authentication Type code (i.e., Type of 4 or greater)."

To:

" The remaining Types define authentication exchanges. The Nak Type
(3) or Expanded Nak (254) is valid only for Response packets, it
MUST NOT be sent in a Request. The Nak Type MUST only be sent in
response to a Request which uses an authentication Type code
(i.e., Type of 4 or greater). An EAP server receiving a Nak Request
MUST silently discard it."

Section 5.2, first paragraph.

Change:

"An authenticator MAY send a Notification Request to the peer at any time
when there is no outstanding Request."

To:

"An authenticator MAY send a Notification Request to the peer at any time
when there is no outstanding Request, prior to completion of an EAP
authentication method."

Section 5.3.1

Change:

"
Where any peer receives a Request for an unacceptable Type in the
range (1-253,255), or a peer lacking support for Expanded Types
receives a Request for Type 254, a legacy Nak Response MUST be
sent. The Type-Data field of the legacy Nak Response MUST contain
one or more octets indicating the desired authentication Type(s),
one octet per Type, or the value zero (0) to indicate no proposed
alternative. A peer supporting Expanded Types that receives a
Request for an unacceptable Type (1-253, 255) MAY include the
value 254 in the legacy Nak Response in order to indicate the
desire for an Expanded authentication Type. If the authenticator
can accomodate this preference, it will respond with an Expanded
Type Request."

To:

"
Where a peer receives a Request for an unacceptable authentication
Type (4-253,255), or a peer lacking support for Expanded Types
receives a Request for Type 254, a legacy Nak Response MUST be
sent. The Type-Data field of the legacy Nak Response MUST contain
one or more octets indicating the desired authentication Type(s),
one octet per Type, or the value zero (0) to indicate no proposed
alternative. A peer supporting Expanded Types that receives a
Request for an unacceptable authentication Type (4-253, 255)
MAY include the value 254 in the legacy Nak Response in order to
indicate the desire for an Expanded authentication Type. If
the authenticator can accomodate this preference, it will respond
with an Expanded Type Request."

Appendix B

Add the following sentence to the next to last paragraph:

"Where possible it is desirable for a method-specific MIC to be computed
over the entire EAP packet, including the EAP layer (Code, Identifier,
Length) and EAP method layer headers (Type, Type-Data)."

---

From: [email-masked] (Jari Arkko)
Date: Mon, 28 Apr 2003 10:31:27 +0300

> MUST silently discard it."

This seems a bit odd. First of all, Expanded Nak (254) does not
really exist, all we have is "Expanded Types (254)" which is used
both for the methods as well as the Nak. Secondly, the third
and fourth sentences are about Nak while the rest of the paragraph
applies both to Nak and Extended Nak. Finally, it seems odd that
we have to list these things in the beginning of section 5, but
not at the subsections devoted to Nak/Extended Nak.

Suggested fix: Just keep the first two sentences of the original
second paragraph. Formulate Nak and Extended Nak specific texts
to sections 5.3.1 and 5.3.2.

> when there is no outstanding Request, prior to completion of an EAP

Hmm... why? So Notification can't appear between a completed method and
success, for instance?

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 28 Apr 2003 06:21:54 -0700 (PDT)

> to sections 5.3.1 and 5.3.2.

Will do. I think that the last sentence is redundant anyway, given the
existing text, so we can just drop it.

> Hmm... why? So Notification can't appear between a completed method and

Right. Or between a completed method and failure. That way after the
method is complete the next packet (Success/Failure) is pre-determined.

---

From: [email-masked] (Jari Arkko)
Date: Mon, 28 Apr 2003 17:06:50 +0300

> existing text, so we can just drop it.

Ok.

> method is complete the next packet (Success/Failure) is pre-determined.

Ok. The stricter this is, the better...

--Jari

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 29 Apr 2003 23:08:26 -0700

> method is complete the next packet (Success/Failure) is pre-determined.

What about a case where multiple authentication methods are running in
a tunneling authentication method?  (Prohibition of sequence of
methods does not apply to methods inside a tunneling method.)  In this
case a completion of an authentication method is not always followed
by by Success/Failure, but should we prohibit Notification at any
method boundaries?

Yoshihiro Ohba

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