On Thu, Jun 9, 2011 at 4:25 AM, Stefan Winter <[email protected]> wrote:
> 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...
Right, this is just a sort of MITM cut-n-paste attack. It's made
feasible only by the addition of a new context from which
authentication messages may be taken and played elsewhere. Another
factor that makes this feasible is that in the original context
there's either no additional confirmation of context establishment
than that provided by the authentication message exchange, OR failure
of that is often silently ignored.
This is an example of a good reason for an applicability statement.
Simply adding more contexts in which a technology might be used can
render insecure. This is also a good reason to not design mechanisms
with this sort of weakness built-in...
We've faced similar problems in the GSS and Kerberos worlds before.
The best example is SSHv2, where we used the same service name
('host') as in other kerberized and GSSified protocols (rsh, telnet,
FTP), where some of those other protocols had options to not perform
any confidentiality nor integrity protection after authentication.
This EAP issue is the same sort of problem that we faced when adding
GSS support to SSHv2.
Nico
--
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
