Hi Stefan, Here are few comments:
"2.1. Communication of authorisation information: EAP-MSCHAPv2;" Do you think this (and similar, if any) example indicates that we shall extend EAP to also signal authorization results, or should this qualify as one EAP method going beyond the scope? I'm inclined to think latter. "2.4. EAP over IP: PANA" It'd be more accurate to call it EAP over UDP, or UDP-based EAP lower-layer. "The original EAP applicability statement states that EAP is applicable in cases where "IP layer connectivity may not be available". The wording in the applicability statement leaves open whether the transport of EAP over IP is in scope or not. " Complete statement from RFC 3748 reads like this: "EAP was designed for use in network access authentication, where IP layer connectivity may not be available." So, this provides historical background and an observation. It shouldn't be taken as "EAP can/shall/should not be carried above IP". Btw, you may also want to note IKEv2, which also carries EAP over UDP. "This limits the use of EAP to transport layers which are on top of IP, and provide their own ordering guarantees." Sure thing. But neither IKEv2 nor PANA are "EAP naked over IP". There is UDP, and a UDP-based header in between which ensures the EAP requirements are satisfied. "In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service. The peer does not need to differentiate between different access network services supported by the same EAP server. Same EAP server can be serving multiple different types of access technology for the same terminal (e.g., WiFi, WiMAX, 3G). So, the aforementioned assumption may not be true. "A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the service that newly accepts EAP auths may decrease the security of this service even for users who previously used non-EAP means of authentication to the service." Isn't this supposed to be handled by the crypto-secured AAA signaling between the NAS and the AAA proxy/server? AAA infra would not let anyone drop some arbitrary AAA node in and get it on the AAA path. " Pending issuance of a Channel Binding RFC, it is thus due to extend the EAP applicability statement to include non-network access contexts if - and only if - this context mandates channel bindings." I couldn't parse this well. To me, EAP applicability statement revision is needed for ABFAB work (even though the ordering of these developments taking place is not natural :-). And plus you are saying channel binding work is needed for ABFAB work too. " The use of EAP over IP is recommended if - and only if - it is transported over a transport layer on top of IP which provides ordering guarantees." I think this goes w/o saying. Whatever requirements exist for EAP lower-layer applies to any lower layer. Besides, like I don't think this is part of "extending" the applicability because it was already allowed. Nevertheless, an explicit recognition of that possibility can be useful too. Thanks. Alper > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Stefan Winter > Sent: Monday, June 06, 2011 12:03 PM > To: [email protected] > Subject: [abfab] Work Item: Update to the EAP Applicability Statement > > Hello, > > I foolishly volunteered to draft an update to the EAP applicability > statement. With the help of very knowledgable people, in particular Joe > Salowey and Sam Hartman, I made an initial attempt: > > http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 > > This obviously isn't perfect, and I would welcome comments of any sort > (including, but not limited to, offers for text and/or co-authorship :- > ) ). > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
