Hi, (only replying to the impersonation part)
>> >> 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. C knows that B is a NAS. C knows that IMAP is a NAS. What C doesn't know is that B initiated a TCP connection on the IMAP4 port, started an IMAP conversation, and, when asked to authenticate via GSSAPI/EAP uses a carbon copy of the EAP authentication currently going on with A for network access. I hope that makes the attack scenario clearer... Stefan >> 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 > > > > > -- 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
