Abstract
As the Extensible Authentication Protocol (EAP) evolves, EAP peers
rely increasingly on information received from the EAP server. EAP
extensions such as channel binding or network posture information are
often carried in tunnel methods; peers are likely to rely on this
information. EAP has provided a facility that protects tunnel
methods against man-in-the-middle attacks. However, cryptographic
binding focuses on protecting the server rather than the peer. This
memo explores attacks possible when the peer is not protected from
man-in-the-middle attacks and recommends mutual cryptographic
binding, a new form of cryptographic binding that protects both peer
and server along with other mitigations.
1. Introduction
The Extensible Authentication Protocol [RFC3748] provides
authentication between a peer (a party accessing some service) and a
authentication server. Traditionally, peers have not relied
significantly on information received from EAP servers. However
facilities such as EAP Channel Binding [I-D.ietf-emu-chbind] provide
the peer with confirmation of information about the resource it is
accessing. Other facilities such as EAP Posture Transport
[I-D.ietf-nea-pt-eap] permit a peer and EAP server to discuss the
security properties of accessed networks. Both of these facilities
provide peers with information they need to rely on and provide
attackers who are able to impersonate an EAP server to a peer with
new opportunities for attack.
Instead of adding these new facilities to all EAP methods, work has
focused on adding support to tunnel methods
[I-D.ietf-emu-eaptunnel-req]. There are numerous tunnel methods
including [RFC4851], [RFC5281], and work on building a standards
track tunnel method [I-D.ietf-emu-eap-tunnel-method]. These tunnel
methods are extensible. By adding an extension to support a facility
such as channel binding to a tunnel method, it can be used with any
inner method carried in the tunnel.
Tunnel methods need to be careful about man-in-the-middle attacks.
Interested people could refer to section 3.2 and 4.6.3 in
[I-D.ietf-emu-eaptunnel-req] and [TUNNEL-MITM] for a detailed
description of these attacks. An example of the attack can happen
when a peer is willing to perform authentication inside and outside a
tunnel. In this case, an attacker can impersonate the EAP server and
offer the inner method to the peer. However, on the other side, the
attacker acts as a man-in-the-middle and opens a tunnel to the real
EAP server. Figure 1 illustrates this attack. At the end of the
attack, the EAP server believes it is talking to the peer. At the
inner method level, this is true. At the outer method level,
however, the server is talking to the attacker.
Hartman, et al. Expires July 9, 2013 [Page 3]
Internet-Draft Mutual Crypto Binding January 2013
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates connection to a Service | |
|-------------------------------------->| |
| | | |
| | Tunnel Establishment |
| |<-------------------------------->|
| | | |
| |..................................|
| | Tunnel |
| Non-Tunneled | | |
| method | Tunneled authentication method |
|<===================>|<================================>|
| | | |
| |..................................|
| | | |
| | Attacker |<--- MSK keys --|
| | Connected as | |
| | Peer | |
| |<--------------->| |
A classic tunnel attack where the attacker inserts an extra tunnel
between the attacker and EAP server.
Figure 1: Classic Tunnel Attack
There are several mitigation strategies for this classic attack.
First, security policies can be set up so that the same method is not
offered by a server both inside and outside a tunnel. A technical
solution is available if the inner method is sufficiently strong:
cryptographic binding is a security property of a tunnel method under
which the EAP server confirms that the inner and outer parties are
the same. One common way to do this is to ask the outer party (the
other end of the tunnel) to prove knowledge of the Master Session Key
(MSK) of the inner method. As defined in [RFC3748], cryptographic
binding is proposed to help each peer prove that the inner and outer
exchanges are with the same party. However, it is typically failed
in making this proof. Instead, it is typically limited to proving to
the server that the inner and outer peer are the same. In the
following sections, security risks caused by such limitation are
introduced.
read more..................http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-01