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

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Nov 2001 20:40:47 -0800 (PST)

On Thu, 8 Nov 2001, Glen Zorn wrote:

> First page headers
> Change "Updates: RFC 2284" to "Obsoletes: RFC 2284"
> 
> 
> 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.

My take on this is that PEAP is just another EAP method, so I'm not sure
what additional text would be required. 

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

Sounds reasonable. 

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

You are probably right. Apparently Hiperlan2 and Bluetooth are now looking
at EAP support...

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

Sounds reasonable. 

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

Ok with me. 

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

Good suggestion. 

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

I think it might because clients would typically  not expect it. 

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

Care to draft that text? (You should have known that was coming...)