>>>>> "Alper" == Alper Yegin <[email protected]> writes:
>> > "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.
>> 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.
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.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
