Subject: [eap] Issue 40: Man-in-the-middle attacks on EAP method seque nces and tunnels

From: [email-masked] (Puthenkulam, Jose P)
Date: Tue, 22 Oct 2002 17:24:27 -0700

Its really good that we are trying to fix this problem in EAP if possible.
But don't we need to address the EAP key derivation framework first before
we
address this issue. The reason is that any key derivation framework we add
to EAP
will have to be designed with such a cryptographic binding capability
between
sequenced or tunnelled EAP methods.

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: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 7:09 PM
To: [email-masked]
Subject: [eap] Issue 40: Man-in-the-middle attacks on EAP method sequences
and tunnels

Issue 40: Man-in-the-middle attacks on EAP method sequences and tunnels
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 21, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: S
Section:  4.3

Rationale/Explanation of issue:
When EAP methods are used as part of a sequence or within a
tunnel, RFC 2284 does not provide a mechanism to cryptographically
bind subsequent authentication methods together.

The result of this is that neither side of the conversation
has any assurance that they are talking to the same endpoint
throughout the conversation, making EAP implementations
vulnerable to a man-in-the-middle attack. A number of existing EAP methods
are vulnerable to such an attack.

The problem occurs on the peer, where a rogue NAS could
fool a peer into authenticating to it, while acting as a
man-in-the-middle, and tunneling the peer's authentication
to another authenticator.

The vulnerability also exists on the server, where a proxy
can handle a portion of an authentication sequence while
routing other portions to other servers.

With EAP being increasingly adopted across multiple media,
including cellular, IEEE 802, and PPP, the need for such
a binding facility has become critical.

Binding requires both sides to demonstrate that they acted
as the endpoint for the sequence of authentication methods.
On the peer, this implies that the same entity acted as
the peer in each of the sequence of authentication mechanisms.
Similarly, on the authenticator, binding implies that the
same entity acted as the authenticator in each method within
the sequence.

There may be situations in which it may not be desirable for
binding to be required. For example, the server may not wish
to demonstrate binding, but may desire the client to do so.
Alternatively, the client may demand that the server demonstrate
binding. As a result, some flexibility is required within the
binding facility.

Note that there are a number of choices as to how binding
might be demonstrated:

a. Individual EAP methods may incorporate keys derived from
previous methods in order to demonstrate not only possession
of a shared secret, token or certificate, but possession of
previously derived key(s) as well. However, this approach
has the disadvantage of requiring that existing EAP methods
be modified to accomodate the binding facility. In many cases
this will not be possible since those methods are already
developed and deployed.

b. The binding facility can be provided within individual
EAP methods. This has the advantage of not requiring EAP
implementations to be upgraded, but has the disadvantage of
requiring the same facility to be developed multiple times.
This would result in overlapping effort as well as poor
interoperability among implementations.

c. The binding facility can be provided within EAP itself.
This has the advantage of enabling widespread interoperability
between implementations, and applicability to multiple EAP
methods. However, it has the disadvantage of being harder
to deploy.

Suggested changes

Add to section 7.2:
"[7] Protection against man-in-the-middle attacks. Where EAP is tunneled
within another protocol, or where a sequence of EAP method is used for
authentication, it is necessary for each endpoint to demonstrate that it
has participated in each method within the authentication sequence. If
this cannot be demonstrated then, the authentication
sequence or tunnel is vulnerable to a man-in-the-middle attack. "
Add a binding facility to EAP itself, possibly in concert with acknowleged
EAP Success/Failure.

Resolution: Discuss

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap