Subject: [eap] More details on issue 40

From: [email-masked] (Puthenkulam, Jose P)
Date: Wed, 30 Oct 2002 13:53:10 -0800

One additional point I would also add is that, in our analysis we did find
that if only Compound MACs
are used and instead of Compound keys, just the tunnel keys are used, the
solution is still relatively
strong. As possession of the all the method keys by the client are proven
just by the Compound MACs.

thanks,
jose

-----Original Message-----
From: Puthenkulam, Jose P 
Sent: Wednesday, October 30, 2002 1:20 PM
To: [email-masked]'; Bernard Aboba
Cc: Puthenkulam, Jose P; [email-masked]; [email-masked];
Yoshihiro Ohba
Subject: RE: [eap] More details on issue 40

In our draft we mention that there are two mechanisms which provide the
maximum protection

1.The additional exchange with Compound MACs and
2.Compound keys for ciphering the link.

As you point out, there is a possiblity for the Compound keys may be weaker
than the TLS keys
generated by the tunnel method. To address this the best way is to define a
strong compound
key derivation method which doesn't reduce the entropy of the Tunnel keys.
Our suggestion would
be to form a design team at the next IETF if there is wide support for this
proposal to
specify the MAC calculation and the Compound key derivation. 

Server and client policies are hard to administer consistently and leave the
problem to the
abilities of the Sys Admin. If the protocols and their implementations could
simplify administration
hazzles I would vouch for it :)

thanks,
jose

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2002 8:16 PM
To: Bernard Aboba
Cc: Puthenkulam, Jose P; [email-masked]; [email-masked];
Yoshihiro Ohba
Subject: RE: [eap] More details on issue 40

Bernard Aboba [mailto:[email-masked]]:

The cryptographic solutions to the problem that I have seen are deeply
flawed, in that they win the battle (the MitM is kept from highjacking the
session) but lose the war (the attacker still ends up with the (weak) user
credentials that the tunnel was supposed to protect).  In fact, I suspect
that combining the e.g. TLS and MS-CHAP v2 keys might weaken the protection
of the session.  IMHO, the only way to actually solve the problem is through
client & server policy.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernard Aboba
> Sent: Tuesday, October 29, 2002 6:26 PM
> To: Yoshihiro Ohba
> Cc: Puthenkulam, Jose P; [email-masked]'; [email-masked]
> Subject: Re: [eap] More details on issue 40
>
>
> > BTW, I would like to make sure that the problem is essentially due to
> > combining multiple authentication methods without cryptographically
> > co-relating them, not due to lack of mutual authentication in some of
> > the methods.
>
> We have set aside some time in the second session at IETF 55 to discuss
> the problem and potential solution approaches in more detail. If anyone
> would like to make a presentation on the subject, send mail to myself and
> Jari.
>
> The attack can still be perpetrated even if the methods that are tunneled
> support mutual authentication. This is because the ends that are
> authenticated are the client and server, but the man-in-the-middle still
> obtains the keys from the tunnel authentication which is only one-way. The
> man-in-the-middle cannot necessarily decrypt the traffic sent by the real
> client, but this is not necessary since the attacker is already
> authenticated to the network and in possession of the keys required to
> authentication and/or encrypt data traffic. Thus the client has served its
> purpose and the attacker can drop traffic arriving from it.
>
> Note that some of the proposed solutions (e.g. compound MAC and/or
> compound keys) require that the tunneled methods generate keys. Thus these
> solutions do not apply to methods such as EAP MD5, OTP or GTC.
> Since these methods are well
> established, it does not seem practical to modify them so as to
> incorporate previously derived keys either.
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>
>