Hi, thanks for these quick comments! Much appreciated!
> 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. I try not to judge this. The point I'm trying to make is: it has been done, and it seems to work well. Whether or not it is something that should be expressly endorsed or better not - that is something that should be discussed. Same goes for the "change password" stuff in EAP-MSCHAPv2. There, I'm even less sure that it is something that should be endorsed. But it exists, and works - for some at least. I think it would be good to have more examples of both aspects: authorisation information and account management. After a few off-line discussions, it seems that transport of authorisation information is something that happens on a broader scale than just EAP-MSCHAPv2; I've heard that at least 3GPP does the same thing with something called AT_TRUST_IND within EAP-AKA. But, knowing nothing about 3GPP, I didn't dare use this as an example. The "change password" things though - I don't have any other example for that on the top of my head right now. If this feature is a singleton in EAP-MSCHAPv2, maybe it's not a good indicator of what should be done within EAP. > "2.4. EAP over IP: PANA" > > It'd be more accurate to call it EAP over UDP, or UDP-based EAP lower-layer. I was trying *not* to mention UDP specifically. SCTP might make a just-as-good lower-layer for EAP, and runs on IP. PANA should only serve as an example for the section "EAP over IP"; I guess that wasn't very clear. > "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. Point taken, I'll enlarge the quote and add IKEv2. > "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. Well, the applicability statement should also provide limits on what NOT to do. So, it's good that PANA and IKEv2 use UDP. But some ill-advised person might envisage "EAP over ICMP", which is on top of IP, but does not provide ordering guarantees. I think it would be good to tell such a person that they should... do something else. > "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. That's a good point; it depends largely on how one defines "very similar". I was just about to write back "but these are all just IP network access technologies" - but they aren't. IIRC, EAP-AKA in the 3GPP world isn't only used for IP network data access, it's also for good old voice telephony (is that right? I think I mentioned before that the 3GPP world is a mystery to me ... ). Still, even with data being "different" - it is still a network. Circuit-switched as opposed to packet-switched alright, but for some, it might still qualify as being "very similar". IOW, the text still has a bit of leeway for interpretation here. I'm happy to get text suggestions. > "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. That's not where I understood the impersonation threat to come from. Isn't it more like: Consider user A who uses a NAS B to get network access, where B authenticates the user credentials to EAP server C. A also reads his email via IMAP, but the IMAP server will do plain old PAP, against server C (not speaking EAP though). B can't read the user's email because it doesn't know A's credentials at C; it's just a pass-through. Now, the IMAP administrative personnel enables IMAP server access with abfab technology, i.e. GSSAPI and EAP, authenticating against the same server C (now speaking EAP). B's operator would now love to read the user's email, and waits for the user to login via B (network access!) next time. He then triggers a GSSAPI-based EAP authentication at the IMAP server, and relays the EAP conversation from A to the IMAP server, which uses it to authenticate "A" at C. B (or, the sinister administrator of B) now has access to A's mails without actually being A - a successful impersonation. B will never learn the actual credential of A; that is hopefully cryptographically secured inside the EAP mechanism, but it may get access to another service in the name of the user. So, while B and IMAP are both part of the same AAA infrastructure, they only have a per-service trust towards the EAP server; the AAA infrastructure doesn't preclude the two from cheating over each other. > " 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. This is not necessarily about ABFAB in a narrow sense. It's more like: "using EAP for access to multiple services requires channel bindings". Since one usage of EAP is for the service "network access" ever since, adding any other second use triggers the need to add channel bindings. But yes, ABFAB is such a "second use". > " 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. Well, yes, it doesn't hurt to be explicit. Greetings, Stefan Winter > > 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 >> > -- 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
