[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

EAP Working Group                                       Jose Puthenkulam
INTERNET-DRAFT                                              Victor Lortz
Category: Informational                                Intel Corporation
<draft-puthenkulam-eap-binding-00.txt>                    Ashwin Palekar
27 October 2002                                                Dan Simon
                                                           Bernard Aboba
                                                               Microsoft


              The Compound Authentication Binding Problem

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

This document describes man-in-the-middle attacks possible when compound
authentication methods are used without cryptographically binding the
methods together. Several protocols currently being proposed within the
IETF are vulnerable to these attacks, including IKE with XAUTH, PIC,
PANA over TLS, EAP TTLS, and PEAP. This document reviews potential
solutions to the problem, including solutions which can be implemented
as extensions to the EAP protocol.









Puthenkulam et al.            Informational                     [Page 1]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


Table of Contents

1.     Introduction ..........................................    3
   1.1       Specification of Requirements ...................    3
   1.2       Terminology .....................................    4
2.     Overview ..............................................    4
3.     Attack scenarios ......................................    7
4.     Potential solutions ...................................    8
   4.1       Solution requirements ...........................   10
   4.2       Solution mechanisms .............................   11
   4.3       Solution approaches .............................   13
   4.4       Solution scope ..................................   14
5.     Normative references ..................................   16
6.     Informative references ................................   17
ACKNOWLEDGMENTS ..............................................   19
AUTHORS' ADDRESSES ...........................................   19
Full Copyright Statement .....................................   20


































Puthenkulam et al.            Informational                     [Page 2]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


1.  Introduction

This document describes man-in-the-middle attacks against protocols
supporting compound authentication methods.  Compound authentication
methods can occur in sequence, or more commonly, when authentication
method(s) are encapsulated within a tunnel which is itself
authenticated.

The vulnerability arises when the peers are not required to demonstrate
that they have participated in all of the authentication methods
occurring within the exchange. Where an authentication method sequence
is used, it is possible for a man-in-the-middle to intercede between the
client and server, fooling the client into believing that a single
endpoint acted as the server throughout the exchange. Where one or more
authentication methods in the sequence is one-way or is vulnerable to
dictionary attack, this can result in disclosure of client credentials
to untrusted peers.

Where a one-way authenticated tunnel setup is used to derive
authentication and/or encryption keys, and subsequent authentication
methods are encapsulated inside the tunnel, it is possible to launch
another man-in-the-middle attack. By shuttling authentication packets
between the client and server, the man-in-the-middle can authenticate
itself to the server and obtain the authentication and/or encryption
keys needed for subsequent access to the server.  For this attack to be
successful, it is necessary for the tunneled authentication methods to
also be enabled for use outside the tunnel, and for the same credentials
to be used for authentication inside and outside the tunnel.

A number of protocols currently proposed within the IETF are vulnerable
to these attacks. Vulnerable protocols include, but are not limited to
[XAUTH], an IKE extension widely deployed with IPsec VPNs; [PIC], a
protocol for certificate enrollment, proposed for use with IPsec VPNs;
PANA over TLS [PANATLS], a protocol proposed for use within wireless
networks; EAP TTLS [EAPTTLS], an EAP method which tunnels other EAP
mechanisms within a TLS tunnel; and Protected EAP [PEAP], a protocol
similar to EAP TTLS.

Given the wide scope of this vulnerability, a solution is desirable, and
this document describes the benefits and limitations of potential
solution approaches.

1.1.  Specification of requirements

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be



Puthenkulam et al.            Informational                     [Page 3]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


interpreted as described in [RFC2119].

1.2.  Terminology

This document frequently uses the following terms:

Authenticator
          The end of the link requiring the authentication.

Peer      The other end of the point-to-point link (PPP), point-to-point
          LAN segment (IEEE 802.1x) or 802.11 wireless link, which being
          authenticated by the Authenticator. In IEEE 802.1X, this end
          is known as the Supplicant.

Authentication Server
          An Authentication Server is an entity that provides an
          Authentication Service to an Authenticator. This service
          verifies from the credentials provided by the Peer, the claim
          of identity made by the Peer.

Silently Discard
          This means the implementation discards the packet without
          further processing.  The implementation SHOULD provide the
          capability of logging the error, including the contents of the
          silently discarded packet, and SHOULD record the event in a
          statistics counter.

Sequenced Methods
          Authentication methods which are used in sequence one after an
          another where each completes and the other one starts. The
          authentication is complete after the final method in the
          sequence is completed.

Tunneled Methods
          The first method sets up a tunnel and subsequent method(s) run
          within the tunnel.

2.  Overview

The attacks described in this document can be mounted against a number
of protocols currently proposed for authenticated network access,
including [XAUTH],[PIC],[PANATLS], [EAPTTLS], and [PEAP]. The attacks
are enabled when compound authentication techniques are used, allowing
clients and servers to authenticate each other with a sequence of
methods, or one or more methods encapsulated within an authenticated
tunnel. The most common attacks occur when the tunnel is authenticated
only from the server to the client, so that the client does not prove
its identity to the server, and where authentication techniques are



Puthenkulam et al.            Informational                     [Page 4]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


permitted both inside and outside a tunnel.

In order to enable secure access using legacy authentiation methods,
protocols such as XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP first
create a security association, using well analyzed techniques such as
ISAKMP [RFC2408] and TLS [RFC2246]. They then tunnel authentication
methods within the security association. The intent is to utilize dual
authentication techniques so as to provide mutual authentication, as
well as to allow the derivation of keys used to provide subsequent per-
packet authentication and encryption.

However, because the initial authentication only authenticates the
server to the client, or provides only an indication of group membership
(where group pre-shared keys are used within IKE), and because the keys
derived within ISAKMP and TLS are not subsequently included within the
tunneled authentication computations, there is no demonstration that the
ISAKMP/TLS endpoints are the same as the tunneled authentication
endpoints. Where authentication techniques are enabled both inside and
outside the tunnel, such as when they are in use for multiple purposes
(e.g. dialup or web authentication) then an attacker can induce an
unsuspecting client to authenticate, then tunnel the authentication
within [XAUTH],[PIC],[PANATLS],[EAPTTLS] or [PEAP].

Thus it is the lack of client authentication within the initial security
association, along with a dependency of key derivation solely on the
initial one-way authentication, the deployment of untunneled
authentication methods, and the lack of "cryptographic binding" between
the security association and the tunneled authentication method, that
enables the vulnerability. Note that in addition to these
vulnerabilities, authentication tunneling also provides a number of
security benefits, including well understood key derivation, replay and
dictionary attack protection and privacy support. These benefits explain
why tunneling has been so frequently proposed for legacy authentication
methods with known security vulnerabilities.

For the purposes of the attack, it makes no difference whether the
authentication technique used inside the tunnel provides for mutual
authentication or not. As long as the tunneled authentication method
does not require that both sides demonstrate participation in the
previous "tunnel authentication" as well as subsequent authentications,
and as long as keys derived during the exchange are not dependent on
material from *all* of the authentications, the vulnerability exists.
The tunnel client, having not proved its identity, can act as a man-in-
the-middle, luring unsuspecting clients to authenticate to it using any
authentication method suitable for use inside the tunnel.

Despite the prevalence of man-in-the-middle vulnerabilities within IETF
protocol proposals, it should be noted that these attacks are not the



Puthenkulam et al.            Informational                     [Page 5]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


result of design flaws within IKE [RFC2409] or EAP [RFC2284].

IPsec VPN implementations which require strong mutual authentication
within the tunnel prior to permitting subsequent authentication are not
vulnerable to this attack.  For example, when L2TP over IPsec [RFC3193]
or IPsec tunnel mode [DHCPIPsec], are used with certificate
authentication or unique pre-shared keys, the attack is not possible. By
requiring strong mutual authentication via certificates or a unique pre-
shared key, the tunnel server obtains the ability to verify the identity
of the tunnel client, and vice versa. The tunnel server may then
subsequently apply access control in order to limit authentication
within the established tunnel.

However, where group pre-shared keys are used (as is common in IKE Main
Mode implementations that support clients with dynamically allocated IP
addresses), followed by one-way authentication mechanisms such as CHAP
[RFC1994], the vulnerability is exposed.  Since group pre-shared keys
only determine group membership but authenticate neither the client nor
the server, it is not possible for the server to enforce access controls
on members of the group individually. Since CHAP is a widely used
authentication method, an attacker can gain access to a client willing
to engage in CHAP authentication in a variety of ways.  This allows any
client with knowledge of the group pre-shared key to act as a man-in-
the-middle for another member of the group.

EAP, as defined in [RFC2284], enables a single authentication mechanism
to be negotiated and carried out, but does not describe sequences of
methods or tunnels. Most existing EAP implementations do not support
authentication sequences, and since EAP does not support a version
number, a server cannot easily determine whether an EAP client supports
sequences. For backward compatibility, it is therefore necessary for the
server to assume that authentication sequences are not supported by
default.

The concept of tunneling has been introduced by recent work-in-progress
such as [PIC], [PANATLS], [EAPTTLS], and [PEAP]. However, these
proposals have not yet been published as RFCs, and are not yet widely
deployed.

Note that man-in-the-middle vulnerabilities are not a necessary
consequence of "credential reuse". For example, they need not
necessarily occur where the same authentication credentials are used in
accessing the network via multiple media. For example, L2TP [RFC2661]
when used in "compulsory tunneling", assumes that the same credentials
are used for both PPP and VPN access, and permits a PPP dialin user to
access a VPN by tunneling PPP packets from the network access server
(NAS) to the VPN server.




Puthenkulam et al.            Informational                     [Page 6]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


Where L2TP over IPsec [RFC3193] is deployed using certificate
authentication or a unique pre-shared key, the L2TP Network Server (LNS
or VPN server) can choose to authorize an authenticated tunnel client to
act as an L2TP Access Concentrator (LAC), tunneling PPP dialin users to
the L2TP Network Server (LNS). Alternatively, it can disallow this,
permitting only a restricted set of users to authenticate within a
tunnel established with given machine credentials.

3.  Attack scenarios

This section describes a how man-in-the-middle vulnerabilities can be
exploited, as well as discussing the underlying causes of the attacks.
Given the man possible attack variations, we do not attempt to describe
every potential variant.

The major scenario for the attack is a one-way authenticated tunnel.  In
this scenario, the client and server first establish a tunnel, then
include within the tunnel an authentication method which derives keys
and provides strong mutual authentication.  The attacker first poses as
a valid client to the server and establishes a tunnel that is
authenticated only on the server end. Although the attacker that sets up
the tunnel has not been authenticated, it obtains the tunnel key derived
as part of the tunnel establishment. Since these keys protect a
conversation between an attacker and a server, the strength of the key
derivation is not relevant.

For the purposes of exploiting the vulnerability, it does not matter
whether the tunneling protocol is IKE [RFC2409] authenticated via a
group pre-shared key; PIC [PIC], which uses ISAKMP [RFC2408] with one-
way authentication; or TLS [RFC2246] with server-only authentication, as
used with [PANATLS], [EAPTTLS] or [PEAP]. The effect is the same - a
tunnel that does not provide unique mutual authentication of the tunnel
endpoints.

Once the attacker has established a tunnel to the server, it seeks to
induce clients to connect to it. This can be accomplished by having the
attacker masquerade as a legitimate 802.11 access point (AP) or Ethernet
switch implementing [IEEE8021X], a PPP Network Access Server (NAS), a
SIP server supporting CHAP, or a VPN server using a protocol such as
PPTP [RFC2637].  For the purposes of the attack, the important
characteristic is that the protocol used by the client enables an
authentication method which is also permitted within the tunneling
mechanism, without first requiring that the attacker authenticate
itself. For example, an attacker setting up a rogue L2TP over IPsec
[RFC3193] server would not be successful since clients would first
require mutual authentication within IKE prior to connecting to the
rogue server.




Puthenkulam et al.            Informational                     [Page 7]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


It is also necessary that the credentials used for the client protocol
and the tunneled authentication protocol are the same.  Without this, it
would not be possible for the authentication conversation between the
client and server to conclude successfully.

Figure 1 on the next page illustrates the attack, for the case where the
attacker acts as a rogue NAS or Access Point. In step 1, the attacker
creates a tunnel with the authentication server. This can occur directly
in [PIC] or [XAUTH] or through a NAS using EAP [RFC2284]. In step 2,
tunnel keys are derived, using server-only authentication using
protocols such as ISAKMP [RFC2408], IKE [RFC2409] or TLS [RFC2246].
Since the tunnel is between the attacker and the authentication server,
both the authentication server and attacker possess the keys.

In the third step, the client connects to the rogue NAS or AP, and the
attacker tunnels the authentication  method between the client and
authentication server. The method may or may not derive keys, but if it
does, then in the fourth step, the method keys are derived on the client
and the authentication server.  Since the attacker does not obtain the
method keys, it is not able to decrypt traffic sent between client and
authentication server. However, while the client may use the method
keys, the authentication server will typically use only tunnel keys,
which have been obtained by the attacker.

In the last step, this allows the attacker to obtain access to the
network, using the successfully tunneled authentication and the tunnel
keys.  The attacker does not have access to the client data, since it is
encrypted with the method keys, so that it will typically discard the
data sent by the client, who will eventually disconnect due to a lack of
response.  However, the attacker has accomplished its mission so that
continued interaction with the client is not necessary unless
reauthentication is required.

4.  Potential solutions

This section describes potential solutions to the man-in-the-middle
attacks described within this document. This includes a description of
solution requirements as well as identification of potential solution
approaches.












Puthenkulam et al.            Informational                     [Page 8]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


    Client            <-|Rogue NAS   |        NAS                  Auth Server
                        | Attacker   |->
       |                     |                 |                        |
       |                     |                 |                        |
       |                     |         Tunnel establishment w/          |
       |                     |         Server Authentication (1)        |
       |                     |<========================================>|
       |                     |                 |                        |
       |              (Non-Authenticated       |               (Authenticated
       |               end of tunnel)          |                end of tunnel)
       |                     |                 |                        |
       |              +--------------+         |               +--------------+
       |              | Tunnel       | (2)     |               | Tunnel       |
       |              | Keys Derived |         |               | Keys Derived |
       |              +--------------+         |               +--------------+
       |                     |                 |                        |
       |                     |..........................................|
       |                     |              Tunnel                      |
       |                     |..........................................|
       |                     |      (Encrypted using Tunnel keys)       |
       |                     |                 |                        |
       |                     |                 |                        |
       |                 Tunneled authentication method (3)             |
       |<==============================================================>|
       |                     |                 |                        |
       |                     |                 |                        |
  +--------------+           |                 |              +--------------+
  | Method       |           |                 |              | Method       |
  | Keys Derived | (4)       |                 |              | Keys Derived |
  | and used.    |           |                 |              | Not Used.    |
  +--------------+           |                 |              +--------------+
       |                     |                 |                        |
       |                     |                 |<===tunnel keys=========|
       |                     |                 |                        |
       |                     | Client's session|                        |
       |                     | stolen          |                        |
       |====================+|<===============>|                        |
       |            Data    ||                 |                        |
       |            dropped v|                 |                        |


Figure 1 - Man-in-the-middle attack on one-way authenticated tunnel









Puthenkulam et al.            Informational                     [Page 9]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


4.1.  Solution Requirements

The following are some of the criteria for a potential solution:

Backwards compatibility
               A solution MUST NOT require modification of existing
               authentication methods. Since tunneling is used in order
               to prolong the life of legacy authentication techniques,
               requiring replacement of existing methods across the
               board is likely to be unacceptable.

Simplicity     A solution SHOULD add minimal round trips to the
               authentication exchange and be modest in its
               computational complexity.

Protocol compatibility
               Given that tunneling techniques are used with well-
               established security protocols such as IKE [RFC2409],
               ISAKMP [RFC2408], TLS [RFC2246], and RADIUS [RFC2865], a
               solution MUST NOT require changes to these protocols.

Forward evolution
               The solution SHOULD be compatible with authentication
               methods supporting mutual authentication and key
               derivation. It is acceptable if the solution cannot
               provide security for tunneling of one-way authentication
               methods that do not derive keys, such as CHAP, EAP-MD5,
               OTP, or Generic Token Card.  As described earlier, these
               methods are vulnerable to connection hijacking attacks,
               and are therefore inherently insecure.

Architectural compatibility
               Solutions MUST NOT require fundamental architectural
               changes to established technologies such as network
               access authentication. Since these technologies are
               already widely deployed, such changes would be likely to
               be unacceptable.

Tunneling protocol independence
               While a solution MAY introduce changes to tunneling
               protocols such as [XAUTH],[PIC], [PANATLS], [EAPTTLS], or
               [PEAP], it is preferable that a single solution be
               applicable to all of these protocols. This is desirable
               both because such a solution will require the least
               effort deploy, as well as to enable the security
               community to focus on a single proposed solution so as to
               be able to determine that it is secure.




Puthenkulam et al.            Informational                    [Page 10]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


4.2.  Solution mechanisms

Several mechanisms are available to solving the problem:

[1]  Compound MACs. This solution uses Message Authentication Codes
     (MACs) computed using keying material from each of the
     authentication methods, by adding a final mutual authenticating
     round-trip. In order to make sure that both sides are aware of the
     outcome of the authentication, the compound MAC MUST include
     coverage of the authentication result (success/failure) sent by
     each side. This ensures that the server cannot be tricked into
     using the tunnel key in the attacker's posession in order to
     authenticate and encrypt data.

[2]  Compound keys. this solution combines keying material from all the
     methods in order to derive the keys used for encrypting and
     authenticating data.

Option 1 prevents a man-in-the-middle from gaining authenticated access,
and therefore prevents false authenticated states which could result in
a Denial of Service attack (possible in Option 2). This makes this
approach relatively straightforward to implement, although it does
require an additional round-trip. While it is believed that this
approach may be sufficient in some cases, further study is required in
order confirm this.

Option 2 does not require additional round trips, but it enables the
man-in-the-middle to authenticate, although not to obtain keys used for
subsequent authentication and encryption of data. This implies that the
client will only discover an attack when it discovers that it is unable
to decipher the incoming data stream. This enables a form of Denial of
Service attack. As a result, Option 2 is probably not sufficient by
itself.

In order to provide the highest level of assurance against man-in-the-
middle attacks it is recommended that a potential solution utilize both
options 1 and 2, so that a man-in-the-middle will not be able to
authenticate, spoof an authentication result or derive keys used to
authenticate and encrypt traffic between the legitimate client and
server.  When both solution options applied, potential man-in-the-middle
attacks are thwarted, as shown in Figure 2 on the next page.










Puthenkulam et al.            Informational                    [Page 11]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


    Client            <-|Rogue NAS   |        NAS                  Auth Server
                        | Attacker   |->
       |                     |                 |                        |
       |                     |                 |                        |
       |                     |         Tunnel establishment w/          |
       |                     |         Server Authentication (1)        |
       |                     |<========================================>|
       |                     |                 |                        |
       |              (Non-Authenticated       |               (Authenticated
       |               end of tunnel)          |                end of tunnel)
       |                     |                 |                        |
       |              +--------------+         |               +--------------+
       |              | Tunnel       | (2)     |               | Tunnel       |
       |              | Keys Derived |         |               | Keys Derived |
       |              +--------------+         |               +--------------+
       |                     |                 |                        |
       |                     |..........................................|
       |                     |              Tunnel                      |
       |                     |..........................................|
       |                     |      (Encrypted using Tunnel keys)       |
       |                     |                 |                        |
       |                     |                 |                        |
       |             Tunneled mutual authentication method (3)          |
       |                     | w/key derivation|                        |
       |<==============================================================>|
       |                     |                 |                        |
       |                     |                 |                        |
  +--------------+           |                 |              +--------------+
  | Compound     |           |                 |              | Compound     |
  | Keys Derived | (4)       |                 |              | Keys Derived |
  +--------------+           |                 |              +--------------+
       |                     |                 |                        |
       |                     | Compound MAC(5)/|                        |
       |                     | Success         |                        |
       |<===============================================================|
       |                     |                 |                        |
       |                     | Compound MAC(6)/|                        |
       |                     | Failure         |                        |
       |===============================================================>|
       |                     |                 |                        |
       |                     |                 |    Attack detected     |
       |                     |                 |     No keys sent       |
       |                     |                 |                        |
       |                     |                 |        Failure         |
       |                     |                 | <======================|
       |                     |                 |                        |

Figure 2 - Man-in-the-middle attack thwarted by compound MAC and keys



Puthenkulam et al.            Informational                    [Page 12]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


As before, the man-in-the-middle can establish a one-way authenticated
tunnel, obtain tunnel keys, lure an unsuspecting client to authenticate
with it, and encapsulate the authentication exchange within the tunnel.
However, after the authentication method is complete compound keys are
derived, requiring knowledge of both the tunnel keys and the keys
derived during each of the authentication methods. The compound keys are
then used in formulation of a compound MAC covering an acknowledged
result indication sent from server to client. Since the server is not
aware of the man-in-the-middle attack in progress, it indicates that
from its perspective the authentication has been successful.

However, since the client did not participate in establishment of the
tunnel, it does not possess the tunnel keys, and will not be able to
verify the compound MAC sent by the server. As a result, it will compute
its own compound key and compound MAC which will include a result
indicating authentication failure. On receiving the client's reply, the
server will be unable to verify the client's compound MAC, and the
authentication will fail. As a result, no compound keys are sent to the
NAS, and the attacker is neither authenticated nor gains access to the
network.

4.3.  Solution approaches

Options 1 or 2 can be implemented in different ways:

EAP       In this approach the exchange of a compound MAC is supported
          within EAP, by implementing the exchange as a new EAP method
          occuring after authentication is complete. In this approach,
          the tunneling key material is provided to the EAP layer in
          order to enable computation of a compound MAC and compound
          keys. Since existing EAP implementations already enable EAP
          methods to provide keying material to the EAP layer, such an
          interface typically already exists. Since this approach
          applies to any tunneling technique it is the most general
          approach.

Tunneling method
          In this approach, the tunneling method acquires keying
          material derived by the underlying authentication methods in
          order to enable computation of the compound MAC and compound
          keys.  Since existing tunneling techniques typically do not
          provide an interface for receiving keying material from
          authentication methods, this approach will typically require
          some re-architecture of existing implementations. It also has
          the disadvantage of requiring changes to each tunneling
          method, and as a result is not as general as an EAP-based
          solution. Given the prevalence of the attacks described within
          this document, it would represent a considerable burden on the



Puthenkulam et al.            Informational                    [Page 13]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


          security community to individually review changes to each
          tunneling approach. However, such an approach may be able to
          take advantage of properties of the underlying tunnel
          technology, such as the ability to have more than one packet
          in transit at a time.

EAP methods
          In this approach, keys derived from previous EAP methods are
          incorporated into the authentication calculations of
          subsequent methods. Since existing interfaces only support the
          export of keys by EAP methods, not importation, some
          rearchitecture is required in this approach. In addition, this
          approach requires modification of existing EAP methods, which
          will create deployment barriers.  However, this approach may
          be applied even to methods which support only one-way
          authentication and do not generate keys.

Based on the pros and cons of the above techniques, we recommend a
solution that applies to all EAP methods. Since EAP is supported within
[PIC], [PANATLS], [EAPTTLS] and [PEAP], though not within [XAUTH], this
approach covers most of the vulnerable protocols, though not all of
them. Assuming that changes to individual EAP methods are not permitted,
this approach is only applicable to tunneling of authentication methods
that support mutual authentication and derive keys. It is therefore not
applicable to CHAP, EAP-MD5, EAP-OTP, EAP-GTC or EAP-SECURID
authentication methods.

Without requiring changes to established methods, secure use of these
protocols within sequences or tunnels is not feasible. If an
authentication method does not generate keys, then keying material is
not available with which to compute a compound MAC or compound key. As a
result, the compound authentication sequence cannot be bound together,
enabling the man-in-the-middle vulnerability to remain.

4.4.  Solution scope

While options 1 and 2 address many of the attack scenarios, they do not
cope with all of them.  If every authentication method within a sequence
generates keys,  then a compound MAC can be used to verify that each
endpoint participated in each of the authentication methods within the
compound authentication. There are some exceptions:

[1]  Anonymous or one-way authentication methods. Some authentication
     methods use anonymous or one-way authentication. In this case, as
     long as a combination of authentication methods support mutual
     authentication, the combined keys could be used to verify both
     peers.




Puthenkulam et al.            Informational                    [Page 14]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


[2]  Methods that do not generate keys.  If one or more authentication
     method(s) that do not generate keys are allowed to run with and
     without tunneling, then a man-in-the-middle attack is enabled.

[3]  Lack of data integrity/encryption. Where per-packet authentication,
     integrity and encryption is not used, there is no binding between
     the results of the authentication and subsequent data traffic. This
     enables connection hijacking.

In order to verify that the peers acted as end-points in a compound
authentication, the peers can exchange compound MACs. However,
authentication schemes which do not derive keys cannot contribute to
calculation of a compound MAC or a compound key.  Such mechanisms
include popular one-way authentication mechanisms such as CHAP
[RFC1994], EAP-MD5 [RFC2284], One-Time-Password [RFC1938], Generic Token
Card [RFC2284], and [SECURID]. These mechanisms authenticate the client
to the server, but do not authenticate the server to the client. They
also do not derive keys which can be used in constructing a compound MAC
or providing authentication and/or encryption of a subsequent data
stream via a compound key.  As a result, without modifications these
methods cannot be bound to the underlying tunnel authentiation and also
do not provide a binding between the one-way authentication and
subsequent data authentication, thereby creating a connection hijacking
vulnerability.

In order to enable a solution for these methods, existing one-way
authentication methods may be modified so as to enable key derivation,
or to incorporate key material derived during the initial tunnel
authentication. However, since the motivation for continued use of
legacy technologies is to minimize the deployment of new technology,
such upgrades are typically impractical. In situations where deployment
of a modified legacy method would be feasible, it would also typically
be feasible to consider a wide range of alternatives, such as deployment
of a new method supporting mutual authentication and key derivation, or
deployment of alternative technologies such as certificates.

Given these constraints, it appears difficult for authentication
tunneling to provide a long-term solution to the security
vulnerabilities inherent in one-way authentication methods such as CHAP,
EAP-MD5, OTP, and Generic Token Card. Where protocols such as [PIC] are
used to transition from these technologies to certificate-based
authentication, it may be possible to restrict the transition to a short
time period, as well as to turn off use of the techniques outside of
[PIC].

These counter-measures may reduce the risk sufficiently to enable
certificate deployment to proceed. However, where [PIC] is used to
provide short- term certificates, and long-term use of password or



Puthenkulam et al.            Informational                    [Page 15]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


token-card based authentication technology is contemplated, improved
security will not be possible without a willingness to replace legacy
authentication methods with more secure technology.

If a transition to certificate-based authentication is not possible,
then at the least, one-way authentication technology can be replaced by
techniques supporting mutual authentication and key derivation. For
example, CHAP may be replaced by Kerberos [RFC1510] or MS-CHAP-V2
[RFC2759] and Generic Token Card may be replaced by token cards
supporting key derivation.

5.  Normative references

[RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
               RFC 1661, July 1994.

[RFC1938]      Haller, N. and C. Metz, "A One-Time Password System", RFC
               1938, May 1996.

[RFC1994]      Simpson, W., "PPP Challenge Handshake Authentication
               Protocol (CHAP)", RFC 1994, August 1996.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.]

[RFC2284]      Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
               Protocol (EAP)", RFC 2284, March 1998.

[RFC2865]      Rigney, C., Rubens, A., Simpson, W., Willens, S.,
               "Remote Authentication Dial In User Service (RADIUS)",
               RFC 2865, June 2000.

[RFC3193]      Patel, B., et al., "Securing L2TP Using IPsec", RFC 3193,
               November 2001.

[EAPTTLS]      Funk, P., Blake-Wilson, S., "EAP Tunneled TLS
               Authentication Protocol", Internet draft (work in
               progress), February 2002.

[DHCPIpsec]    Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel
               Mode", Internet draft (work in progress), draft-ietf-
               ipsec-dhcp-13.txt, June 2001.

[PEAP]         Andersson, H., et al., "Protected EAP Protocol (PEAP)",
               Internet draft (work in progress), draft-josefsson-
               pppext-eap-tls-eap-05.txt, September 2002.





Puthenkulam et al.            Informational                    [Page 16]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


[PIC]          Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE
               Credential Provisioning Protocol", Internet draft (work
               in progress), draft-ietf-ipsra-pic-06.txt, September
               2002.

[IPSRAREQ]     Kelly, S., Ramamoorthi, S., "Requirements for IPsec
               Remote Access Scenarios", Internet draft (work in
               progress), draft-ietf-ipsra- reqmts-05.txt, September
               2002.

[GETCERT]      Bellovin, S., and Moskowitz, B., "Client Certificate and
               Key Retrieval for IKE", Internet draft (work in
               progress), draft-bellovin-ipsra-getcert-00.txt, June
               2000.

[SECURID]      Josefsson, S., "The EAP SecurID(r) Mechanism", Internet
               draft (work in progress), draft-josefsson-eap-
               securid-01.txt, February 2002.

[PANATLS]      Ohba, Y., et al., "PANA over TLS", Internet draft (work
               in progress), draft-ohba-pana-potls-00.txt, September
               2002.

[XAUTH]        Pereira, R., Beaulieu, S., "Extended Authentication
               within ISAKMP/Oakley", Internet-draft (work in progress),
               draft-beaulieu-ike-xauth-02.txt, September, 2000.

[IEEE802]      IEEE Standards for Local and Metropolitan Area Networks:
               Overview and Architecture, ANSI/IEEE Std 802, 1990.

[IEEE8021X]    IEEE Standards for Local and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June 2001.

[IEEE80211]    Information technology - Telecommunications and
               information exchange between systems - Local and
               metropolitan area networks - Specific Requirements Part
               11:  Wireless LAN Medium Access Control (MAC) and
               Physical Layer (PHY) Specifications, IEEE Std.
               802.11-1997, 1997.

6.  Informative references

[RFC1510]      Kohl, J., Neuman, C., "The Kerberos Network
               Authentication Service (V5)", RFC 1510, September 1993.

[RFC2246]      Dierks, T. and  C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, November 1998.



Puthenkulam et al.            Informational                    [Page 17]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


[RFC2486]      Beadles, M., Aboba, B., "The Network Access Identifier",
               RFC 2486, January 1999.

[RFC2401]      Atkinson, R., Kent, S., "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

[RFC2402]      Kent,S., Atkinson, R., "IP Authentication Header", RFC
               2402, November 1998.

[RFC2406]      Kent,S., Atkinson, R., "IP Encapsulating Security Payload
               (ESP)", RFC 2406, November 1998.

[RFC2407]      Piper, D., "The Internet IP Security Domain of
               Interpretation of ISAKMP", RFC 2407, November 1998.

[RFC2408]      Maughhan, D., Schertler, M., Schneider, M., and Turner,
               J., "Internet Security Association and Key Management
               Protocol (ISAKMP)", RFC 2408, November 1998.

[RFC2409]      Harkins, D., Carrel, D., "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.

[RFC2412]      Orman, H., "The Oakley Key Determination Protocol", RFC
               2412, Nov. 1998.

[RFC2433]      Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC
               2433, October 1998.

[RFC2637]      Hamzeh, K., et al., "Point-to-Point Tunneling Protocol
               (PPTP)", RFC 2637, July 1999.

[RFC2661]      Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
               G., and Palter, B., "Layer Two Tunneling Protocol L2TP",
               RFC 2661, August 1999.

[RFC2716]      Aboba, B., Simon, D.,"PPP EAP TLS Authentication
               Protocol", RFC 2716, October 1999.

[RFC2759]      Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
               2759, January 2000.

[RFC2866]      Rigney, C., "RADIUS  Accounting", RFC 2866, June 2000.

[DECEPTION]    Slatalla, M., and  Quittner, J., "Masters of Deception."
               HarperCollins, New York, 1995.

[KRBATTACK]    Wu, T., "A Real-World Analysis of Kerberos Password
               Security", Stanford University Computer Science



Puthenkulam et al.            Informational                    [Page 18]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


               Department, http://theory.stanford.edu/~tjw/krbpass.html

[KRBLIM]       Bellovin, S.M., Merritt, M., "Limitations of the kerberos
               authentication system", Proceedings of the 1991 Winter
               USENIX Conference, pp. 253-267, 1991.

[KERB4WEAK]    Dole, B., Lodin, S., and Spafford, E., "Misplaced trust:
               Kerberos 4 session keys", Proceedings of the Internet
               Society Network and Distributed System Security
               Symposium, pp. 60-70, March 1997.

[PPTPv1]       Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point-
               to- Point Tunneling Protocol", Proceedings of the 5th ACM
               Conference on Communications and Computer Security, ACM
               Press, November 1998.

[IEEE8023]     ISO/IEC 8802-3 Information technology -
               Telecommunications and information exchange between
               systems - Local and metropolitan area networks - Common
               specifications - Part 3:  Carrier Sense Multiple Access
               with Collision Detection (CSMA/CD) Access Method and
               Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
               1996), 1996.

Acknowledgments

Thanks to Bernard Aboba for editorial assistance and discussions
relevant to this problem space.

Authors' Addresses

Jose Puthenkulam
Intel Corporation
2111 NE 25th Avenue, JF2-58
Hillsboro, OR 97124

EMail: jose.p.puthenkulam@intel.com
Phone: +1 503 264 6121
Fax:   +1 503 264 8154

Victor Lortz
Intel Corporation
2111 NE 25th Avenue, JF3-206
Hillsboro, OR 97124

EMail: viktor.lortz@intel.com
Phone: +1 503 264 3253
Fax:   +1 503 626 0396



Puthenkulam et al.            Informational                    [Page 19]


INTERNET-DRAFT          Compound Binding Problem         27 October 2002


Ashwin Palekar
Dan Simon
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: {ashwinp, dansimon, bernarda}@microsoft.com
Phone: +1 425 882 8080
Fax:   +1 425 936 7329

Full Copyright Statement

Copyright (C) The Internet Society (2002).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

EAP Issues

Open issues relating to EAP, including the issues described in this
document, are tracked on the following web site:

http://www.drizzle.com/~aboba/EAP/eapissues.html

Expiration Date

This memo is filed as <draft-puthenkulam-eap-binding-00.txt>,  and
expires April 24, 2003.






Puthenkulam et al.            Informational                    [Page 20]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/