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

Versions: 00 01 02 03 04

EAP Working Group                                       Jose Puthenkulam
INTERNET-DRAFT                                              Victor Lortz
Category: Informational                                Intel Corporation
<draft-puthenkulam-eap-binding-01.txt>                    Ashwin Palekar
28 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         28 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 ...................................    9
   4.1       Solution requirements ...........................    9
   4.2       Solution mechanisms .............................   10
   4.3       Solution approaches .............................   13
   4.4       Solution scope ..................................   14
5.     Normative references ..................................   15
6.     Informative references ................................   17
ACKNOWLEDGMENTS ..............................................   18
AUTHORS' ADDRESSES ...........................................   18
Full Copyright Statement .....................................   19


































Puthenkulam et al.            Informational                     [Page 2]


INTERNET-DRAFT          Compound Binding Problem         28 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 also possible to a
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 communication with 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         28 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 proposed IETF protocols, including [XAUTH],[PIC],[PANATLS],
[EAPTTLS], and [PEAP]. Each of these protocols support authentication
tunneling of legacy authentication methods such as CHAP [RFC1994], EAP-
MD5 [RFC2284], One-Time-Password (OTP) [RFC1993], Generic Token Card
(GTC) [RFC2284], and SecurID [SECURID] in order to provide a number of
benefits, including well understood key derivation, replay and
dictionary attack protection and privacy support.




Puthenkulam et al.            Informational                     [Page 4]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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, and where tunneled
authentication techniques are permitted both inside and outside a
tunnel.  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.  The
attacks are possible, even though the tunnels created within these
protocols utilize well analyzed protocols such as ISAKMP [RFC2408] and
TLS [RFC2246], because mutual authentication (supported within both
protocols) is not used.

Since 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 methods, 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].

For the purposes of the attack, it makes no difference whether the
authentication method used inside the tunnel supports mutual
authentication or not. The vulnerability exists as long as both sides
are not required to 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.

Thus it is the lack of client authentication within the initial security
association, combined with key derivation based on a one-way tunnel
authentication, and lack of "cryptographic binding" between the security
association and the tunneled authentication method that enables the
vulnerability. In addition, it is necessary for the same authentication
methods to be allowed inside and outside of tunnels.

Despite the prevalence of man-in-the-middle vulnerabilities within IETF
protocol proposals, it should be noted that these attacks are not the
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]



Puthenkulam et al.            Informational                     [Page 5]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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. 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 individual members of the group. Since CHAP is a widely used
authentication method, an attacker can easily gain access to a client
willing to engage in CHAP authentication.  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 EAP 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. PPP dialin users are then
permitted to access a VPN by tunneling PPP packets from the network
access server (NAS) to the VPN server.

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,



Puthenkulam et al.            Informational                     [Page 6]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


permitting only a restricted set of users to authenticate within a
tunnel established with given machine credentials.

3.  Attack scenarios

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

The major scenario for the attack is a one-way authenticated tunnel
encapsulating subsequent authentication methods.  In this scenario, the
client and server first establish a tunnel, then include within the
tunnel one or more authentication method(s).  The attacker first poses
as a valid client to the server and establishes a tunnel that is
authenticated only on the server end, obtaining tunnel keys.  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 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, it is necessary that
the client be induced to authenticate to the attacker using an
authentication mechanism permitted within the tunnel. It is also
necessary that the credentials within the client protocol and the
tunneled authentication protocol are the same, so that the
authentication mechanism remains valid when encapsulated within the
tunnel.

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 via protocols
such as ISAKMP [RFC2408], IKE [RFC2409] with group pre-shared keys or
TLS [RFC2246]. Since the tunnel is between the attacker and the server,
both the server and attacker possess the keys.



Puthenkulam et al.            Informational                     [Page 7]


INTERNET-DRAFT          Compound Binding Problem         28 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 a one-way authenticated tunnel









Puthenkulam et al.            Informational                     [Page 8]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


In the third step, the client connects to the rogue NAS or AP, and the
attacker tunnels the authentication  method between the client and
server. The tunneled authentication 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 server.  Since the attacker does not obtain the
method keys, it is not able to decrypt traffic sent between client and
server. However, while the client may use the method keys, the server
will typically use only tunnel keys, which have been obtained by the
attacker.

In the last step, the attacker obtains access to the server, using the
successfully tunneled authentication and the tunnel keys.  The attacker
does not have access to client data, since it is encrypted with the
method keys. As a result, it will typically discard the data sent by the
client, who will eventually disconnect due to a lack of response.  Since
the attacker has accomplished its mission, 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 prevously described. This includes a discussion of solution
requirements as well as identification of potential solution approaches.

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



Puthenkulam et al.            Informational                     [Page 9]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


               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, Generic Token Card, or SecurID.  As described
               earlier, these methods are already vulnerable to
               connection hijacking.

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 [PIC], [PANATLS], [EAPTTLS], or [PEAP],
               it is preferable that a single solution be applicable to
               all of these protocols. This is desirable since a single
               solution will be easiest deploy and also enables the
               security community to focus efforts on determining
               whether the proposal is secure.

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 within 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) to authenticate
     and encrypt data.

[2]  Compound keys. This solution combines keying material from all the
     methods in order to derive keys used for subsequent encryption and
     authentication of 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.



Puthenkulam et al.            Informational                    [Page 10]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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 and 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. This prevents a man-in-the-middle from being 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 are applied, potential man-in-the-
middle attacks are thwarted, as shown in Figure 2 on the next page.

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 the authentication
result, which is sent from server to client. Since the server is not
aware of the man-in-the-middle attack in progress, from its perspective
the authentication has been successful.

Since the client did not participate in establishment of the tunnel, it
does not possess the tunnel keys, and cannot verify the compound MAC
sent by the server. The client computes its own compound key and
compound MAC, covering an indicated authenticate failure. On receiving
the client's reply, the server is unable to verify the client's compound
MAC, and the authentication fails.  As a result, no compound keys are
sent to the NAS, and the attacker is neither authenticated nor gains
access to the server.
















Puthenkulam et al.            Informational                    [Page 11]


INTERNET-DRAFT          Compound Binding Problem         28 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 compound keys



Puthenkulam et al.            Informational                    [Page 12]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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.  Tunnel keys are
          provided by the tunneling protocol to the EAP layer in order
          to enable computation of the 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. This approach is general in that it
          ppplies to any tunneling technique.

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
          security community to review changes to each individual
          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 each approach, we recommend a solution
that applies to all EAP methods.






Puthenkulam et al.            Informational                    [Page 13]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


4.4.  Solution scope

Since EAP is supported within [PIC], [PANATLS], [EAPTTLS] and [PEAP],
though not within [XAUTH], implementation of options 1 and 2 within EAP
covers most of the vulnerable protocols. There are some exceptions,
however.

[1]  Methods that do not generate keys.  In order to verify that the
     peers acted as end-points in a compound authentication, the peers
     can exchange compound MACs and compute compound keys.  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 compound MACs and compound keys or providing
     keying material for authentication and/or encryption of a
     subsequent data stream.

     Without requiring changes to existing 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.  One workaround is to prohibit use of these methods outside
     a tunnel; there is some logic to this, since without support for
     key generation, use of these methods outside the tunnel is
     vulnerable to connection hijacking.

[2]  Ciphers without authentication support. Where per-packet
     authentication and integrity protection is not supported, there is
     no binding between the results of the authentication and subsequent
     data traffic. This enables connection hijacking.

In order to enable a solution for methods such as CHAP, EAP-MD5, OTP,
GTC or SECURID, they 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.




Puthenkulam et al.            Informational                    [Page 14]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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, GTC and SecurID. 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
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



Puthenkulam et al.            Informational                    [Page 15]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


               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.

[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



Puthenkulam et al.            Informational                    [Page 16]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


               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.

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



Puthenkulam et al.            Informational                    [Page 17]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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



Puthenkulam et al.            Informational                    [Page 18]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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

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







Puthenkulam et al.            Informational                    [Page 19]


INTERNET-DRAFT          Compound Binding Problem         28 October 2002


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-01.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/