> >> > "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. > > Alper> Here your I-D is sliding into talking about "EAP lower-layer > Alper> requirements" which is a different thing than "EAP > Alper> applicability statement". > > I believe that requirements of the domain of applicability--in this > case > lower layer requirements--are in scope for this draft. > My current position is that I support this discussion.
I find this very confusing. As you might know, RFC 3748 already has a dedicated section "3.1 Lower Layer Requirements". Are you intending to add to that, or modify that too in this "applicability statement" I-D? > >> 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. > > Alper> B is a NAS. It's not allowed to source AAA messages for > Alper> non-NAS related procedures (e.g., IMAP). Wouldn't this > simply > Alper> solution handle the issue? > > B is malicious. It doesn't care what you think it is allowed to do. > Something in the system needs to prevent B from acting improperly. > The logical place to enfore that is at the EAP server. > To do that, the EAP server needs to know what the user thought they > were > trying to do--it needs channel binding. C knows B is a "NAS", not an "IMAP server". Therefore C would not let an IMAP session be AAAed on the B. Equivalent of that is what is relied upon in order to prevent a WiFi NAS to pretend like a WiMAX NAS. I'm not saying channel binding is unnecessary. I'm saying the scenario you are providing does not require channel binding. > > Alper> I'm afraid this is mixing up requirements and applicability > Alper> discussions. Probably any transport protocol (including > Alper> pigeons) is fine as an EAP lower-layer as long as it > Alper> satisfies the EAP lower-layer requirements. But carrying > Alper> anything or doing anything with EAP is not fine, and that's > Alper> where the applicability statement comes into the picture. > > > > > Alper> On a more radical note, why EAP has applicability statement, > Alper> but no(?) other IETF protocol has one? What happens if we > get > Alper> rid of the applicability statement completely? > > Alper> Cheers, > > I would be strongly against removing the applicability statement > entirely. One of the main reasons for this is exactly because we have > found requirements such as channel binding that we need to place on > other uses of EAP. My concern with the applicability statement is that, it can be misused unless it is perfectly defined, which is not possible by definition. This is very tricky. Do we have good experience and examples with defining applicability statements in IETF? (The ones that I have seen so far have been bad experiences :-) Btw, can't we say the same thing for any authentication method/mechanism/protocol (not just EAP)? If I'm getting authenticated/authorized for Service X using method Y, there needs to be some way of ensuring that the other end-point of authentication also thinks I'm up for Service X. Does TLS, HTTP-digest, IKE, etc. all take care of that? I think not. So, we should think if they also need channel-binding, or if they have some substitute solutions. Any thoughts on that? Alper Alper _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
