Subject: Re: comments on draft-ietf-pppext-rfc2284bis-01.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Nov 2001 18:19:50 -0800 (PST)

Glen Zorn spake thusly:

First page headers
Change "Updates: RFC 2284" to "Obsoletes: RFC 2284"

>>Proposed Resolution: Accept

Section 1
I would really like to see the inclusion of some text allowing the
encapsulation of EAP packets within EAP packets (a la PEAP), maybe after
the paragraphs on sequential authentication.

>>Since PEAP is just another EAP method, it would seem that no explicit
language is required in the draft to enable its use. 

Section 2
Paragraph 5
Suggest changing "However, an initial Identity Request is not required,
and MAY be bypassed in cases where the identity is presumed (leased lines,
dedicated switch or dial-up ports, authentication via calling station
identity or MAC address, etc.)." to "However, an initial Identity Request
is not required, and MAY be bypassed in cases where the identity is
presumed (leased lines, dedicated switch or dial-up ports, etc.) or
obtained in
another fashion (via calling station identity or MAC address, in the Name
field of the MD5-Challenge Response, etc.)."

>>Proposed solution: Accept

Sections 2.1 & 2.2
I think that it would be a good idea to follow the l2tpext WG's lead and
separate the PPP and 802.1 applications of EAP from the base protocol.
Although the use of EAP with PPP is pretty well understood, 802.1X is
still
evolving.  Furthermore, I think it likely that EAP will be used in other
L2
contexts and I would like to avoid rewriting the EAP RFC again.

>>It is indeed likely that EAP will be used in other L2 contexts (I am
told Hiperlan2 will use EAP, and this has also been discussed in
Bluetooth SIG). There are also L3 applications for EAP, such as PIC
and BURP. So it seems reasonable to enable other documents to 
specify L2 or even may be L3 mappings for EAP. However, I don't know
that this necessarily requires that this document remove the existing
L2 mappings. 

>>Proposed resolution: discuss

Section 3.1
In the paragraph on "Type", I find the sentence "Only one Type MUST be
specified per EAP Request or Response." a little ambivalent.  If only one
Type MUST be specified, does that mean that more than one Type MAY be
specified?  I don't think so ;-).  Suggest replacing with "A single Type
MUST be specified for each EAP Request or Response."

>>Proposed resolution: Accept

Section 4.
Paragraph 1
Since the term "authentication Type code" has not been defined above,
suggest changing "The Nak Type MUST only be sent in response to a Request
which uses an authentication Type code." to "The Nak Type MUST only be
sent
in response to a Request which uses an authentication Type code (i.e.,
Type
> 3)."

>>Proposed resolution: Accept

Paragraph 2
Why bother w/forward references to another I-D?  Suggest changing "All EAP
implementations MUST support Types 1-4, which are defined in this
document.
Types 5 and 6 are defined in [4]. Follow-on RFCs will define additional
EAP
Types." to "All EAP implementations MUST support Types 1-4, which are
defined in this document.  Follow-on RFCs MAY define additional EAP
Types."
and deleting types 5 and 6 from the following list.

>>Proposed resolution: Accept

Section 4.3
Would it break backward compatability too badly to allow a list of single
octet authentication types in a Nak?

>>Proposed resolution: Discuss

Section 4.4
This section points to RFC 1994 for details on how to do MD5-Challenge
authentication.  However, the specification of the use of the Identifier
field in RFC 1994 is differentthat that described in this draft.  For
example, EAP allows for retransmission of MD5-Challenge Request packets
while RFC 1994 states that both the Identifier and Challenge fields MUST
change each time a Challenge (the CHAP equivalent of the MD5-Challenge
Request packet) is sent.  I think that a little clarifying text might be
in
order here.

>>How about this?

"The MD5-Challenge Type is analogous to the PPP CHAP protocol [3]
(with MD5 as the specified algorithm).          
The Request contains a
"challenge" message to the peer.  A Response MUST be sent in reply
to the Request.  The Response MAY be either of Type 4 (MD5-
Challenge) or Type 3 (Nak).   The Nak reply indicates the peer's
desired authentication mechanism Type.  All EAP implementations
MUST support the MD5-Challenge mechanism.

Note that the use of the Identifier field in the MD5-Challenge Type is
different from that described in RFC 1994 [3].
EAP allows for retransmission of MD5-Challenge Request packets
while RFC 1994 states that both the Identifier and Challenge fields MUST
change each time a Challenge (the CHAP equivalent of the MD5-Challenge
Request packet) is sent."