> > "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.
Here your I-D is sliding into talking about "EAP lower-layer requirements" which is a different thing than "EAP applicability statement". > 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. I don't think there is anything to prevent an ICMP-based EAP lower-layer being designed. > > > "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. B is a NAS. It's not allowed to source AAA messages for non-NAS related procedures (e.g., IMAP). Wouldn't this simply solution handle the issue? > > > " 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. I'm afraid this is mixing up requirements and applicability discussions. Probably any transport protocol (including pigeons) is fine as an EAP lower-layer as long as it satisfies the EAP lower-layer requirements. But carrying anything or doing anything with EAP is not fine, and that's where the applicability statement comes into the picture. On a more radical note, why EAP has applicability statement, but no(?) other IETF protocol has one? What happens if we get rid of the applicability statement completely? Cheers, Alper > > 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 > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
