Subject: [eap] More details on issue 40

From: [email-masked] (Puthenkulam, Jose P)
Date: Tue, 29 Oct 2002 13:16:04 -0800

Hi Henry,

We are willing to acknowledge the Nokia work which showed the Mitm attack
with EAP/AKA using tunnelled methods with a false UMTS tower posing as the
attacker. We extended on that work for WLAN and also proposed the solution
using the stage 3 mutual auth with bound keys. Our first intent was to cite
your work as a reference, but as there was no public material available so
we couldn't do it easily. But we could have put it in the acknowledgements.
As our draft was submitted over the weekend in a hurry to meet the IETF
deadline, apologies for the omission. We will include appropriate
attribution in our next draft revision. 

We were aware of this even before you pointed it out, but only after we
submitted it :) and cannot change it till
after the IETF meeting.

thanks,
jose

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Jose Puthenkulam
   Senior Software Engineer
   Emerging Platforms Lab
   Intel R & D
   Intel Corporation
   2111 NE 25th Avenue, JF2-58
   Hillsboro, OR 97124
   Tel: (503) 264 6121
   Fax: (503) 264 8154
   Email: [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2002 1:25 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [eap] More details on issue 40

Jose,

A slideset about the the man-in-the-middle issue (issue #40) and an
accompanying paper are in
http://www.saunalahti.fi/~asokan/research/mitm.html

We sent this slideset to several people including you at the beginning
of this month. Issue #40 and your draft on the topic appeared three
weeks later.  Please acknowledge this work in your draft.

Best regards,
Henry

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 28 October, 2002 17:43
> To: [email-masked]
> Subject: [eap] More details on issue 40
> 
> 
> A draft is now available providing more details on Issue 40:
> 
> http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt
> 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 29 Oct 2002 19:55:10 -0500

I also very much appreciate the work related to issue 40, which is
also important for PANA over TLS, as pointed out in the documents
cited in this thread.  The new version of PANA over TLS draft has some
improvement on this issue.  I'll add the citations for the documents
in the refererence section of the draft in the next version.

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.

Regards,
Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 29 Oct 2002 18:25:31 -0800 (PST)

> co-relating them, not due to lack of mutual authentication in some of

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.

---

From: [email-masked] (Glen Zorn)
Date: Tue, 29 Oct 2002 20:16:27 -0800

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.

> 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
>
>