Subject: [eap] Proposed Resolution to Issue 40: Accept

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 11:53:04 -0800 (PST)

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:
http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt
Document: RFC2284bis-07
Comment type: T
Priority: S
Section:  7.4

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.

Suggested changes

Add Section 7.4:

7.4 Man-in-the-middle attacks

Where a sequence of methods is utilized for authentication or is tunneled
within another protocol that omits peer authentication, there exists a
potential vulnerability to man-in-the-middle attack.

Where a sequence of EAP methods is utilized for authentication, the peer
might not have proof that a single entity has acted as the authenticator
for all EAP methods within the sequence. For example, an authenticator
might terminate one EAP method, then forward the next method in the sequence
to another party without the peer's knowlege or consent. Similarly, the
authenticator might not have proof that a single
entity has acted as the peer for all EAP methods within the sequence.

This enables an attack by a rogue EAP authenticator tunneling EAP to a
legitimate server. Where the tunneling protocol is used for key
establishment but does not require peer authentication, an attacker
convincing a legitimate peer to connect to it will be able to tunnel EAP
packets to a legitimate server, successfully authenticating and obtaining
the key. This allows the attacker to successfully establish itself as a
man-in-the-middle, gaining access to the network, as well as the ability
to decrypt data traffic between the legitimate peer and server.

This attack may be mitigated by the following measures:
[a] Requiring mutual authentication within EAP tunneling mechanisms.
[b] Requiring cryptographic binding between EAP methods executed within a
sequence or between the EAP tunneling protocol and the tunneled EAP
methods.
[c] Limiting the EAP methods authorized for use without protection based
on peer and authenticator policy. "

---

From: [email-masked] (Jari Arkko)
Date: Wed, 27 Nov 2002 21:06:40 +0200

> on peer and authenticator policy. "

[d] Avoiding the use of sequences or tunnels when a single, strong
method is available?