EAP Working Group Jose Puthenkulam
INTERNET-DRAFT Victor Lortz
Intel Corporation
Category: Informational Ashwin Palekar
Dan Simon
<draft-puthenkulam-eap-binding-02.txt> Microsoft
3 March 2003
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 (2003). All Rights Reserved.
Abstract
There are several motivations for using compound authentication methods
using tunnels, but man-in-the-middle attacks are possible in certain
circumstances when they 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 studies the problems
and suggests potential solutions to mitigate them.
Puthenkulam et al. Informational [Page 1]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
Table of Contents
1. Introduction .......................................... 3
1.1 Scope ........................................... 3
1.2 Motivations for Compound Methods ................ 4
1.3 Problem Statement ............................... 5
1.4 Requirements Language ........................... 5
1.5 Terminology ..................................... 5
2. Problem Description.................................... 7
2.1 Overview ........................................ 7
2.2 Attack Scenarios ................................ 9
2.2 Conditions for the attack........................ 11
3. Potential Solutions ................................... 12
3.1 Solution criteria ............................... 13
3.2 Solution concepts ............................... 14
3.3 Solution mechanisms ............................. 15
3.4 Thwarting the attack............................. 19
3.5 Solution approaches ............................. 21
3.6 Solution scope .................................. 22
4. Reference Solution in Tunneling Protocol............... 23
4.1 Binding Phase Exchange........................... 23
4.2 Compound MAC and Session Key derivation.......... 25
4.3 Binding Message Formats ......................... 27
4.4 IANA Considerations.............................. 33
5. Normative references .................................. 33
6. Informative references ................................ 35
ACKNOWLEDGMENTS .............................................. 36
AUTHORS' ADDRESSES ........................................... 37
Full Copyright Statement ..................................... 39
Puthenkulam et al. Informational [Page 2]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
1. Introduction
As authentication protocols evolved over time, weaker ones have
either been replaced or modified to meet the increasing security needs
in new environments. The development of secure tunneling techniques like
[TLS] and [IPSEC] have generated a lot of interest in securing legacy or
weaker authentication protocols using tunnels. We call such compositions
of multiple authentication protocols that are used in concert to
accomplish a single purpose, Compound Authentication Methods. They may
be used for several purposes, including user authentication for granting
network access or establishing a security association for
confidentiality and integrity protection of data traffic.
We highlight certain ôman-in-the-middleö vulnerabilities associated with
the composition of compound authentication methods that are being
proposed or already in use today. These include authentication methods
that are commonly encapsulated within an independently authenticated
tunnel that provides additional protective properties. Some examples of
compound authentication methods using tunnels include EAPMD5 using
[EAPTTLS], [EAPMSCHAPV2] using [PEAP], PANA over TLS [PANATLS], and
[XAUTH] with ISAKMP as part of IKE. These may also include multiple
authentication methods used in sequence when multiple credentials are
used in different stages of authentication.
1.1. Scope
This document identifies the man-in-the-middle attacks that are possible
when one-way authenticated tunnels are used to protect communications of
one or a sequence of authentication methods; and characterizes the
solution(s) that address the attack. The context studied is the use of
compound authentication for getting access from an authentication
server.
Intuitively, certain attacks may also be possible with sequences of
authentication methods even if they are not used within one-way
authenticated tunnels, but we donÆt address those scenarios here.
We study the root causes of the attack and develop solutions using a mix
of policy based and cryptographic means. We also describe a reference
solution as a logical extension to an EAP based tunneling protocol.
However the same principles could be used in other classes of
authentication protocols as well.
Puthenkulam et al. Informational [Page 3]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
1.2. Motivations for Compound Methods using tunnels
They are the following:
[1] Support for legacy authentication methods in new environments:
These new environments have brought new requirements including identity
privacy, mutual authentication, authentication data confidentiality,
integrity protection, replay and dictionary attack protection and strong
cipher keys for the authenticated link, especially in the context of
wireless networks. Secure tunneling techniques like TLS and ISAKMP with
strong security properties provide a way to accomplish this in an
extensible manner, providing longer life for easy to use legacy methods.
ex: Using legacy PAP that has no key derivation in 802.11 WLANs, by
running it inside an EAP-TTLS tunnel that provides the additional
protection needed.
[2] Consistent security properties for authentication methods:
Any time a new credential type is introduced, it becomes necessary to
construct a complete cryptographic protocol with all the necessary
security properties, which is not an easy task to accomplish. The
availability of well-reviewed tunneling protocols like TLS and ISAKMP
provide the opportunity to construct simpler methods for new credentials
that can use the protection of the tunnel to do authentication securely.
On a wireless network supporting multiple authentication methods, this
enables consistent security for all credential types.
ex: EAP-SIM running inside a PEAP tunnel that uses a TLS tunnel for
protection.
[3] Support for Multiple credentials
New system capabilities in certain cases require authentication of more
than one credential between two peers. This sometimes requires
authentication methods with different security properties to be
sequenced. By running the sequence inside a tunnel, it enables providing
a protection layer for all the methods.
Puthenkulam et al. Informational [Page 4]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
[4] Deployment aspects for securing legacy methods:
The ease of deployment of secure tunneling techniques using server
authentication alone as in TLS and also IPSec (though they allow
mutual authentication), making them even more popular candidates for
securing the use of legacy authentication methods.
ex: The TLS tunnel in PEAP can be established with server authentication
using a server certificate. No client certificates that are unique per
user are required.
1.3. Problem Statement
This document suggests that compound methods have evolved from need,
but their composition today as it is practiced, has some
man-in-the-middle vulnerabilities in certain circumstances. These
were not known at the time these compositions were suggested but have
been found recently [MITM]. As compound methods have widespread
application, this document studies the problem, its circumstances and
and suggests solutions for mitigating them using a mix of protocol
extensions and policy based techniques.
1.4. Requirements language
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
interpreted as described in [RFC2119].
1.5. Terminology
This document frequently uses the following terms:
Authenticator
The end of the link requiring the authentication.
Puthenkulam et al. Informational [Page 5]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
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 is
being authenticated by the Authenticator. In IEEE 802.1X, this
end is known as the Supplicant. We also sometimes refer to the
Peer as a Client of the Authentication Server also.
Authentication Server
It 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.
Binding Phase
The protocol stage where validation of the peers
participating in the compound authentication method is carried
out after all the individual methods have completed.
Compound MAC
A Message Authentication Code (MAC) computed using keying
material from multiple methods used in a compound
authentication method. This is computed during the binding
phase.
Compound Keys
Session keys computed using keying material from multiple
methods used in a compound authentication method. This is
computed during the binding phase and can be used for
ciphering at the lower layers or as application specific keys.
Puthenkulam et al. Informational [Page 6]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
2. Problem Description
2.1. Overview
The attack described in this document can be mounted against a number
of proposed IETF protocols, including IKE with [XAUTH],[PIC],[PANATLS],
[EAPTTLS], and [PEAP]. Each of these protocols supports 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, fast reconnect, mutual
authentication, replay and dictionary attack protection and privacy
support.
The attack is enabled when compound authentication techniques are
used, allowing clients and servers to authenticate each other with one
or more methods encapsulated within an independently authenticated
tunnel. The simplest 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 using the
same credential. 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
Puthenkulam et al. Informational [Page 7]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
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
credentials to be used 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], TLS[RFC2246], 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], is 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.
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.
Puthenkulam et al. Informational [Page 8]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
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. This is mainly because, on
physically secure networks, unlike wireless networks, its harder to
become a man-in-the-middle.
2.2. Attack scenario
This section describes how man-in-the-middle vulnerabilities can be
exploited, as well as discussing the underlying causes of the attacks.
We use a single example to highlight the problem. But the weakness of
the composition of tunnel-based compound authentication methods should
become apparent even in a broader context using this example.
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
Puthenkulam et al. Informational [Page 9]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
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
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
Puthenkulam et al. Informational [Page 10]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
necessary that the credentials within the client protocol and the
tunneled authentication protocol be the same, so that the
authentication mechanism remains valid when encapsulated within the
tunnel.
Figure 1 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.
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.
The attack described is also possible, if the tunnel server is not the
final authentication server. Now in that case the vulnerability is even
more serious because the inner method could be running to an untrusted
network, and it assumes, that the tunnel server and the final
authentication server have a trust relationship which it cannot validate.
EAPTTLS typically suggests this model and care must be taken while
deploying this intermediate tunnel termination model to prevent such
man-in-the-middle attacks.
2.3. Conditions for the Attack
The following are some causal conditions that are necessary for this
attack to be possible. We label these conditions using a prefix CC
and refer to them during the solution description.
Puthenkulam et al. Informational [Page 11]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
[CC-A] Client and Authentication server policy allowing client
credentials to be used both within one-way server-authenticated tunnels
and outside them.
ex: An authentication server supports EAP-MD5 using EAP-TTLS and also
supports the same method when used without EAP-TTLS. This can occur
when clients are being upgraded at different times or when upgrades are
not universal. If the identities used were different in each case, then
the server would be able to detect fraudulent use and prevent the
attack.
[CC-B] The ability for a man-in-the-middle to pose as a legitimate
client to the authentication server as well as a legitimate
authenticator to the client and perform both functions simultaneously.
ex: A 802.11 WLAN client that also has the capabilities to function as
an AP and functions as one entity with malicious intent. This is
relatively easy to accomplish given the low cost of equipment and tools.
This may be relatively more difficult to accomplish on dial-up RAS servers.
[CC-C] The inability of the authentication server to validate that the
client authentication occurring inside a tunnel originated at the
same endpoint as the tunnel itself.
ex: When an EAP method runs inside of EAP-TTLS or PEAP, the tunnel
endpoint that is not authenticated really doesnÆt prove that it
originated the inner EAP conversation as link is protected only by the
tunnel keys.
[CC-D] The data link being authenticated is always confidentiality-
and/or integrity-protected using tunnel keys instead of the keys
derived from the client method running inside the tunnel.
ex: The keys from any EAP method running inside of EAP-TTLS or PEAP are
not used today.
3. Potential Solutions
This section describes potential solutions to the man-in-the-middle
attacks prevously described. This includes a discussion of solution
criteria, concepts, mechanisms, approaches and their scope. Some of the
limitations of these solutions are also captured.
Puthenkulam et al. Informational [Page 12]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
3.1. Solution Criteria
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 cost.
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
be uniformly applied for providing 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.
3.2. Solution Concepts
There are several concepts at our disposal for mitigating this attack.
As the root problem was missing proof that both peers actually performed
all the individual methods in the compound authentication, one solution
is to provide just that. The other solutions include restrictions on the
implementation of the compound authentication methods so as to avoid
the causal conditions described in section 2.3 (CC-A...CC-D).
Puthenkulam et al. Informational [Page 13]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
So here we list all the concepts and some of the limitations of each.
[S1] Provide proof that the unauthenticated tunnel endpoint is a real
peer and not the man-in-the-middle attacker using cryptographic
binding. This prevents condition CC-C.
This solution works for all key-deriving methods used inside a
tunnel. And this is the primary solution described
in this document. This will not work for non-key-deriving methods
without breaking at least one of our solution criteria. So we
only consider this solution for key-deriving methods.
[S2] Guarantee that the same peer credential is never usable inside and
outside a tunnel using server and client policy. This prevents
condition CC-A.
This solution actually works for all methods, but is sometimes hard
to deploy, due to legacy deployments, and since clients and servers
need to be synchronized for proper policy enforcement. An
additional problem with this solution is the manageability issues
due to the multiple credentials that have to be managed by the same
client and server.
[S3] Prevent an Access Point (or Base station)/Client to be ever
manipulated to perform both functions and become an attacker.
This prevents condition CC-B.
This solution is possible to accomplish in a very limited context,
like under the watchful eyes of law enforcement. But due to the
wide availability of hacking tools, it is extremely expensive to
implement in the real world.
[S4] Provide a mechanism for all method secrets in a compound
authentication to be used for deriving link layer cipher keys. This
prevents condition CC-D.
This solution also, just like [S1], will only work for only key-
deriving methods. For non-key-deriving methods, this won't work
as the only choice is to use tunnel keys to meet the
solution criteria.
For realizing concepts S1 and S4 we use cryptographic means. S2 is
realizable just using policy techniques on the client and server ends.
Thus we have solutions that can prevent all the causal conditions
except CC-B as solution S3 is not viable.
Puthenkulam et al. Informational [Page 14]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
3.3. Solution Mechanisms
The solution mechanisms include a mix of policy based techniques and
using cryptographic means. Assuming that compound methods are of
interest, the policy based techniques have significant relevance for
non-key deriving (possibly legacy) authentication methods where
cryptographic binding is not necessarily practical. These involve
the following mechanisms:
[1] Providing separate credentials for a user identity supported inside
and outside tunnels.
This enables the server to know when a credential that is not
intended for use inside a tunnel is being used. This maybe done
by an attacker and appropriate action can be taken. Though this is
restrictive and worsens usability, it maybe easy to deploy.
[2] Enforce client and server policy to always use authentication
methods inside tunnels.
This could have more significant deployment issues, but is a better
option if possible, as it enables the benefits of compound methods
to be realized more effectively.
For non-key deriving methods, if they are modifiable, then using a
signal to indicate when they are running inside a tunnel would also
prevent the attack. This works because the server is able to
distinguish between an attacker diverting a method into a tunnel versus
a client method intentionally initiated inside a tunnel. However such
signals need protection from spoofing.
The mechanisms to provide cryptographic proof involve combining some
knowledge unknown to the attacker derived from each authentication
method involved in a compound authentication to prove that both parties
are the real peers. This knowledge may be in the form of keying material
available to both parties. This information can be used as part of a
two-stage solution.
[Stage 1] Binding Phase Exchange with Compound Keyed MACs
Here we execute an additional 2-way handshake to the tunneling protocol
or base protocol, we call it the ôBinding Phase Exchangeö. This phase is
entered only if the server knows that all the individual
authentication methods inside the tunnel have completed. (There maybe
some situations where binding maybe carried out after each inner method
completes. However that is beyond our scope at the moment.)
Puthenkulam et al. Informational [Page 15]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
In case of the tunnel server endpoint not being the final
authentication server, it has possession of the inner method keys if
they are available. The keys from all the inner methods and the tunnel
keys are used to compute keyed compound MACs as described in section 4.2.
The validation of the compound MACs protects against the
man-in-the-middle attack, as the attacker is unable to get any of the
inner method keys. Here the server sends a Binding request B1 with
a B1_MAC and the client validates it. If the message is valid the client
responds with the B2 message that also has a B2_MAC associated with it.
If the server successfully validate the B2_MAC, then it can be certain
that there was not man-in-the-middle.
| Binding Request(B1)[S_NONCE...S_MAC] |
|<===============================================================|
| |
| |
| Binding Response(B2)[C_NONCE....C_MAC] |
|===============================================================>|
| |
Figure 2: Binding Phase Message Flows
For clarity, we name all the keys and nonce values used in the two
stages. The input keys for the binding phase are TSK and the several
ISKs, one from each inner method. These keys should be available before
the binding phase exchange can be carried out. The details of the
derivation of these keys are in section 4.2
TSK Tunnel Session Key. This is part of the base keying material
available from the tunneling protocol. It should be at least
256 bits and derived ensuring key separation for binding,
non-binding, transmit and receive encryption and integrity
purposes.
ISK Inner Session Key for the inner authentication method running
inside the tunnel. Each inner method that derives keys will
have an non-zero ISK. It could be of variable length depending
on the particular method. But should be at least 64 bits. The
key derivation process in section 4.2 is capable of handling
variable length ISKs as they are input as strings to the PRFs.
S_NONCE 256 bit random number used for computing the Compound keyed
MAC values for the B1 message (B1_MAC) and the B2 message
(B2_MAC).
Puthenkulam et al. Informational [Page 16]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
C_NONCE 256 bit random number used for computing the Compound keyed
MAC value for the B2 message (B2_MAC).
The output keys generated as part of the cryptographic binding process
are the MAC keys CMK_B1 and CMK_B2 and the CSK. CMK_B1 and CMK_B2 are
needed for computing the B1_MAC and B2_MAC repectively in stage 1. The
CSk is needed for stage 2.
CMK_B1 Compound MAC key derived for the B1 message MAC (B1_MAC)
computation. It is 128 bits in length. It is derived using
two nonces the S_NONCE and the C_NONCE both of which are
256 bit random numbers and also additional parameters that
representative of all the inner methods.
CMK_B2 Compound MAC key derived for the B2 message MAC (B2_MAC)
computation. It is 128 bits in length. This is derived
with the S_NONCE which is a 256 bit random number.
CSK Compound Session Key, which is the bound key generated for
use as the base keying material for the link layer. It is
192 bytes in length. The different portions of the CSK
are partitioned into 32 byte chunks and specified for
different uses.
Here we descibe the stage 1 message exchange related aspects.
B1. Binding Request
This message is a request sent from the tunnel server to the
tunnel client to perform binding. Among other parameters it
includes a 256 bit random number, ie. the S_NONCE and a compound
keyed MAC, B1_MAC computed by the server over the entire
B1 message. There is a compound MAC server key CMK_B1, derived
for computing the B1_MAC on the server and another equivalent one
derived on the client for validating it after receiving the
message. The S_NONCE is used in the derivation of this CMK_B1 in
addition to the bound keying material (ISK1...ISKn) from all the
inner methods inside the tunnel and the tunnel keys (TSK). So if
the client and server have all the keying material from all the
methods, the B1_MAC validation on the client should succeed and
the response message B2 will be sent.
In the case of invalid B1_MAC, the client need not send a response
and can disconnect as a potential man-in-the-middle could be
Puthenkulam et al. Informational [Page 17]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
present and be modifying packets. Also this message as it will be
enacapsulated in the underlying protocol, the retry policies on
the server can be specified as part of that protocol which
initiates binding.
B2. Binding Response
This is only sent as a response to B1 and includes a B2_MAC and
also additional parameters including a 256 bit random number
called the C_NONCE. The B2_MAC is a compound keyed MAC calculated
over the entire B2 message. The derivation of B2_MAC is explained
in section 4.2. A client MAC key is derived for computing this
B2_MAC. To prevent against replay attacks, the CMK_B2 is derived
using the S_NONCE and the C_NONCE and can only be derived after
the B1 message is received.
If the B1 message has an invalid B1_MAC, this CMK_B2 MAC key
derivation is not possible and the B2 message cannot be safely
constructed. So no response is sent. The server that does not
receive a B2 response can timeout and disconnect or perform a
retry. It is expected to use a new S_NONCE for every retry.
If the Binding Phase successfully completes with the server validating
the B2 message, then the compound authentication is complete. More
details this binding phase exchange is described in section 4.1.
The CMKs should provide enough strength for the MACs so that it cannot
be broken in the time taken to authenticate. ie. seconds. Its important
to remember that the binding phase exchange when performed as the
final step to to complete authentication should include the protected
success/failure indication using the Result TLV. This is described in
section 4.1. Also other meta information about the methods exchanged
can be used for policy validation or fraud detection purposes. However
the protection from the attack is mainly from the MACs and not from
the other parameters.
[Stage 2] Compound Session Keys Generation
In stage 2 we generate combined keys that are session keys for
link layer confidentiality and integrity protection needs.These are
computed using from all the inner method keys if they are available
and the tunnel keys. The resultant keys called Compound Session Keys
(CSKs) are provided to the link layer for ciphering and integrity
protection. These keys provide the assurance that all packets
are being exchanged between the real peers and no man-in-the-middle is
actually decrypting the conversation. The Compound Session Key
derivation is specified in section 4.2.
Puthenkulam et al. Informational [Page 18]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
Though from our analysis, compound MACs used in the Stage 1 Binding
Phase Exchange provide the necessary protection, we argue that for
additional protection one could also use Stage 2.
Performing Stage 1 prevents a man-in-the-middle from gaining
authenticated access. It also prevents false authenticated states
which could result in a Denial-of-Service attack that could result
if only Stage 2 is done.
Only implementing Stage 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 link-level authentication and encryption
of the data. This implies that the client will only discover an attack
when it discovers that it is unable to decipher the incoming data
stream. As a result, Stage 2 is probably not sufficient by itself.
3.4. Thwarting the attack
Figure 3 shows how by adding the Binding Phase Protocol Exchange
the attack is prevented as the man-in-the-middle attacker cannot provide
the correct B1_MAC that the client will validate against in the B1
message in step (5). Also the B2 message cannot be successfully sent
by the attacker and the server will fail a false B2 message, that does
not possess a valid B2_MAC. Hence the compound session keys (if stage 2
is used) or tunnel keys are not sent to the Authenticator by the server.
Thus the man-in-the-middle attack is prevented.
Puthenkulam et al. Informational [Page 19]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
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 |
+--------------+ | | +--------------+
| | | |
| | Binding Request | |
| | (5) (B1_MAC) | |
|<===============================================================|
| | | |
| | Binding Response| |
| | (6) (B2_MAC) | |
|===============================================================>|
| | | |
| | | Attack detected |
| | | No keys(CSK/TSK)sent |
| | | |
| | | Failure |
| | | <======================|
Figure 3 - Man-in-the-middle attack thwarted by compound MAC and
compound session keys
Puthenkulam et al. Informational [Page 20]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
3.5. Solution approaches
Stages 1 or 2 can be implemented in different ways:
EAP In this approach, the binding phase exchange of a compound
keyed MACs 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 keyed MACs and compound session 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 applies 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 keyed MACs and
compound session 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. As mentioned
Puthenkulam et al. Informational [Page 21]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
earlier the use of signals to indicate the explicit intention
to run inside a tunnel can be another approach to mitigating
the problem. However the signals have to be protected from
spoofing and that is not easy without some keying material
being available.
Based on the pros and cons of each approach, we recommend a solution
that applies to all EAP methods either in the Tunneling method or
in the EAP base protocol.
3.6. Solution scope
The policy based mechanisms we described in the previous section will
work for any tunneling protocol, but it can be a bit restrictive.
The cryptographic mechanisms work for all key deriving methods and
can be implemented in the EAP base protocol or the tunneling protocol
as extensions.
When a mix of key deriving and non-key deriving methods are used inside
the tunnel the nature of protection largely relies on the key deriving
methods. If the non-key deriving methods are not properly managed
through policy mechanisms as described earlier and if they play a
significant role in the compound authentication success/failure
condition then the vulnerability still exists. But the attacker may not
be able to take control of the network access session.
However it important to note that, downgrade attacks are possible
with modified EAP or tunneling protocols as attackers can always try
to get the server to connect to a client tunnel that does not support
cryptographic binding or the policy mechanisms. So appropriate server
policies are needed to either not support older versions of the
protocols that do not have the enhancements or have counter measures
in place to deal with potential fraud.
Puthenkulam et al. Informational [Page 22]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
4. Reference Solution in Tunneling Protocol
Here we describe a reference solution using cryptographic binding
that can be implemented in a tunneled EAP-based authentication protocol
like PEAP to thwart man-in-the-middle attacks. This involves
incorporating a binding phase handshake after all the inner EAP methods
complete to provide cryptographic proof that the peers indeed took part
in all the authentication methods. We use compound keyed MACs for these
messages using keys derived from the individual methods combined with
the tunnel keys. We also derive cryptographically bound session keys
that can be used for ciphering at the link layer. Though we limit our
discussion to PEAP, the principles used here can be applied to other
compound authentication protocols as well. Here for simplicity we
assume the tunnel server endpoint is the final authentication server.
Its also very important to note that the tunnel protocol needs to do
proper version negotiation upfront to prevent downgrade attacks. In the
case where the tunnel server is not the final authentication server,
this binding phase is started only after the tunnel server gets the
inner method keys from the final authentication server. This also
assumes that the tunnel server and authentication server have a security
association that enables them to share these keys and the tunnel server
is capable of holding the authentication state till the binding phase
is complete.
4.1 Binding Phase Handshake
This 2-way handshake for cryptographic binding can be added as a tunnel
protocol extension. This handshake is started when the server makes
a determination that the last inner authentication methods have
completed. The following meta information is used in both the Binding
Request (B1) and Binding Response (B2) messages.
- Highest version number supported by the tunnel client and tunnel
server
- Information of each inner authentication method. Method type, version,
size of keys used for CMK computation and identity used to
authenticate both client and server.
- Type of media being used for the authentication. ex: RADIUS
NAS-Port-Type.
Puthenkulam et al. Informational [Page 23]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
The version number will prevent roll back attacks between tunnel
protocol versions that support cryptographic binding, but not for other
implementations that do not support it.
The server having possession of all the inner method keys and also
the tunnel keys, and including a 256 bit server Nonce (S_NONCE),
computes a compound MAC server key (CMK_B1). This and other
cryptographic derivations are described in the next section. Then the
server sends a Binding Request Message (B1) that has a server-computed
compound keyed MAC (B1_MAC) associated with it. This message body
includes the version number of the protocol extension,
a 256 bit S_NONCE, a RESULT_TLV that provides protected success/failure
indication, one METHOD_IDENTITY_TLV each for all the methods that were
exchanged inside the tunnel and the METHOD_IDENTITY_TLV for the tunnel
server. The B1_MAC is computed over this entire message body by setting
the MAC field bits to zero.
| Binding Request(B1) |
|<===============================================================|
| [VERSION,S_NONCE,RESULT_TLV, METHOD_IDENTITY_TLV.....,B1_MAC] |
| |
| |
| Binding Response(B2) |
|===============================================================>|
| [VERSION,C_NONCE,RESULT_TLV, METHOD_IDENTITY_TLV.....,B2_MAC] |
| |
Figure 4: Binding Phase Message Flows (Success Case)
The client on receiving the B1 message will first compute its own CMK_B1
using the S_NONCE and its own knowledge of all the inner method keys and
the tunnel keys. Then it validates the B1_MAC sent from the server by
recomputing it over the B1 message body with MAC bits set to zero. If
the B1 message is valid, it responds with a Binding Response (B2)
message that includes a compound keyed MAC (B2_MAC). Before it responds,
it first computes a MAC key (CMK_B2), for computing the B2_MAC,
using the tunnel keys, all the inner method keys, the S_NONCE received
from the server and a locally derived 256 bit client Nonce (C_NONCE).
The B2 message body is similar to the B1 message, and includes a version
number of the protocol extension, a 256 bit C_NONCE, a RESULT TLV that
provides acknowledgment for the protected success/failure indication,
one METHOD_IDENTITY_TLV each for all the methods that were exchanged
inside the tunnel and the METHOD_IDENTITY_TLV for the tunnel server
that was known to the client (it could include the FQDN or the server
name in the PEAP server certificate). A client side MAC (B2_MAC) is
Puthenkulam et al. Informational [Page 24]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
computed for this message body using the CMK_B2, with the MAC bits set
to zero, and is included in the B2 message. figure 4 shows both the
messages in the success case.
There are several conditions that can cause invalid B1 or B2 messages,
they include the following:
ò Invalid B1_MAC or B2_MAC
ò Incompatible protocol version
ò Invalid RESULT_TLV
ò Invalid METHOD_IDENTITY_TLV
A man-in-the-middle attack can cause these conditions to occur. More
details on detecting these conditions are described as part of the
message formats in section 4.3. Here we describe how they are handled
as the failure authentication cases.
[1] Client receiving an invalid B1 message
If the client finds the Binding Request (B1) message to be invalid, it
doesnÆt send any response. It can make a decision to drop the connection
at this time, as it is not certain, that its talking to the right server.
Any other Binding Requests (B1) messages if they arrive subsequently,
and if they are valid, are responded to using proper Binding Response
(B2) messages. This is to allow for packet loss during the server retry
time period. The retry of packets is handled by the EAP layer; and is
transparent to the EAP methods. The packets should not be different
because the media is unreliable.
[2] Client never receiving a B1 message
In this case, client having waited for sufficient time (retry time
period) will time out and can drop the connection.
[3] Server receiving an invalid B2 message
If the server receives an invalid Binding Response (B2) message, it can
decide to drop the connection, as its not certain that it is talking to
the right client. Any further Binding Responses are ignored, even if the
server had sent out more than one B1 messages.
[4] Server never receiving a B2 message
In this case, the server will time out and can do a retry, up to 3 times
with new B1 messages. It must use a new S_NONCE every time it sends a
new message.
4.2 Compound MAC and Session Key derivation
Puthenkulam et al. Informational [Page 25]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
The input for the cryptographic binding we use includes the Tunnel
Session Keys (TSK), and the inner method provided session keys, ISK1,
ISK2,àISKN, that belong to the N authentication methods used inside the
tunnel. These keys may all be of varying sizes. The sizes used for this
computation need to be input to the METHOD_IDENTITY_TLV as described in
section 4.3.
The Compound MAC for the client (the B2_MAC) and the server (the B2_MAC)
are derived from two different MAC keys called CMK_B2 and CMK_B1
respectively. A compound session key (CSK) is also derived on both the
client and server for cryptographic purposes. If the binding phase is
implemented, that alone prevents the man-in-the-middle attacks, so the
CSKs are really not needed and the tunnel session keys can still be used
for ciphering purposes.
The CMK_B1, CMK_B2 and CSK are derived as follows for the PEAP protocol.
PEAP tunnel session key (TSK); TSK is calculated using the EAP-TLS
algorithm (RFC2716 section 3.5). and is 192 octets.
ISK1ààISKn are the EAP inner session keys obtained from methods 1 to n.
In some cases, ISKi, for some i, may be the null string ("").
We use the P_SHA-1 PRF specified in the TLS specification [RFC2246].
Compound MAC Key derivation algorithm:
Take the second 256 bits of TSK (192-octet TLS/SChannel output)
IPMK0 = TSK
for j = 1 to n do
IPMKj = PRF(IPMK(j-1),"Intermediate PEAP MAC key", ISKj);
CMK_B1 = PRF(IPMKn,"PEAP Server B1 MAC key",S_NONCE)
CMK_B2 = PRF(IPMKn,"PEAP Client B2 MAC key",C_NONCE|S_NONCE)
("|" denotes concatenation)
The pseudorandom function PRF(k,label,string) is computed as
P-SHA1(k,label|string) (or substitute, if necessary, any other PRF that
produces output of sufficient length). Here the outputs are taken to
as many bits as are necessary (typically 256 bits for a key).
Puthenkulam et al. Informational [Page 26]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
Compound Session Key Generation (PEAP encryption key):
The following function provides the necessary keying material.
CSK = PRF(IPMKn, "PEAP compound session key", C_NONCE|S_NONCE,
OutputLength)
where
PRF(Key, Label, String, OutputLength)
Output ::= NULL
for i = 0 to (OutputLength/20 - 1) do
Output ::= Output | P-SHA1(Key, Label | String | i | OutputLength)
return 1st OutputLength octets of Output
("|" denotes concatenation)
Here the outputs are taken to as many bits as are necessary.
(typically 256 bits for a key).
4.3 Binding Message Formats
There seems to be a assumption below that binding packets are only
transferred in the final ACK packet inside PEAP. The Binding messages
can be transferred in the final protected ACK or in other EAP-TLV
packets inside PEAP. It can be transferred after each EAP method if
so desired. Only the final ACKed packet can contain the Result TLV.
All other packets do not contain a Result TLV.
The Binding Phase uses messages for Binding Request (B1) and Binding
Response (B2) are defined using TLVs. They contain the TLV_RESULT
that provides success/failure indications, TLV_METHOD_IDENTITY that
provides meta information about an EAP method and is specifically
designed for use in binding. For non-key generating inner EAP-methods
in a tunnel, the TLV_METHOD_IDENTITY is used for achieving binding.
We first describe the TLVs used and then define the B1 and B2 message
formats. The generic TLV format is defined in [TLV] in section 3.1
and duplicated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
1 - Mandatory TLV
Puthenkulam et al. Informational [Page 27]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
R
Reserved, set to zero (0)
Type
A 14-bit field, denoting the attribute type. Allocated AVP Types
include:
0 - Reserved
1 - Reserved
2 - Reserved
3 - Result TLV (Acknowledged Result)
Length
The length of the Value field in octets.
Value
The value of the object.
Result TLV:
This is defined in draft-hiller-eap-tlv-00.txt [ref] in section 3.2
and duplicated below.
The Result TLV provides support for acknowledged Success and Failure
messages within EAP. It is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
Puthenkulam et al. Informational [Page 28]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
R
Reserved, set to zero (0)
TLV Type
3 - Success/Failure
Length
2
Status
The status field is two octets. Values include:
1 - Success
2 - Failure
Method Identity TLV:
This TLV is used to indicate meta information about each method that
participated in the compound authentication. It includes the method
type (EAP,IPSec etc), the length of the key used for compound key
derivation, the Client and Server identities used and their lengths.
The Media type for the compound authentication is also included.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Method Type | Version | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Identity Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Client Identity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identity Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Server Identity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Puthenkulam et al. Informational [Page 29]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
METHOD_IDENTITY_TLV. See IANA considerations section
Method Type
One octet. This indicates what EAP method type was used.
Version
One octet. This indicates the version of the EAP method used.
Key Length
Length of the method keys in bits, used to for compound key
derivation. It is the length of the ISK or TSK used to for
compound MAC and session key derivations. They are the same
size for both.
Client Identity Length
2 octets. The number of octets used for the Client Identity field
Client Identity
As many octets as indicated in the Client Identity Length. For EAP methods,
this would be the identity exchanged in the identity request packet. If no
Identity request was used, then this would be set to 0. This field can be
omitted if the Client Identity Length is set to 0.
Server Identity Length
2 octets. The number of octets used for the Server Identity field
Puthenkulam et al. Informational [Page 30]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
Server Identity
As many octets as the value of Server Identity Length. This is to
indicate the identity of the server, the client is talking to for
a particular method.
Media Type
The media used for the compound authentication. eg. RADIUS NAS
Port Type values.
Implementation Note:
Due to the identities not being consistent across methods, its
possible that the client and server identities used in these TLVs for
the Binding Request (B1) and Binding Response (B2) messages donÆt
necessarily match. The exact specification of these fields needs
further study.
Binding TLV:
This message format is used for the Binding Request (B1) and also the
Binding Response. This uses TLV type CRYPTO_BINDING_TLV. The format is
as given below.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ NONCE +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of inner methods(n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESULT_TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| METHOD_IDENTITY_TLV (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| METHOD_IDENTITY_TLV (n-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| METHOD_IDENTITY_TLV (tunnel method) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Compound MAC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Puthenkulam et al. Informational [Page 31]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
CRYPTO_BINDING_TLV. See IANA Considerations.
Version
Version of tunnel protocol extension for binding. Initially set to
0.
Length
2 octets
Nonce
32 octets. 256 bit Random number that is never repeated and is
used for compound MAC key derivation at each end. It is a S_NONCE
for the B1 message and a C_NONCE for the B2 message.
RESULT_TLV
This is defined earlier. It either indicates a success/failure.
METHOD IDENTITY TLV (0àn-1)
This is defined earlier. One TLV indicating the meta information
for each authentication method is included.
METHOD IDENTITY TLV (tunnel)
This is indicating the tunnel method meta information.
MAC
16 octets. This can be the Server MAC (B1_MAC) or the Client MAC
(B2_MAC). It is computed over the entire Binding TLV packet using
the HMAC-SHA1-128 using the CMK_B1 or CMK_B2. It is truncated to
128 bits.
Puthenkulam et al. Informational [Page 32]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
4.4 IANA Considerations
IANA has assigned the EAP type number 33 for TLVs.
This protocol extension defines a new TLV types for cryptographic
binding that are defined below.
CRYPTO_BINDING_TLV 5
METHOD_IDENTITY_TLV 6
It also uses the Result TLV (RESULT_TLV) defined in the draft[TLV, PEAP]
5. Normative references
[TLS] [RFC2246]
[EAP-MD5] [RFC2284]
[ISAKMP] [RFC2408]
[IKE] [RFC2409]
[PEAPV0] Kamath, V., Palekar, A., Wodrich,M., "Microsoft's PEAP
version 0 (Implementation in Windows XP SP1)", October
2002 (work in progress)
[TLV] Hiller, T., Palekar, A., Zorn, Glen, "A Container Type
for the Extensible Authentication Protocol (EAP)",
October 2002 (work in progress)
[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.
Puthenkulam et al. Informational [Page 33]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
[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.
[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.
Puthenkulam et al. Informational [Page 34]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
[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.
[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.
Puthenkulam et al. Informational [Page 35]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
[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
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.
Puthenkulam et al. Informational [Page 36]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
[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.
[MITM] Nokia Research Center, Man-in-the-middle attacks in
tunneled authentication protocols,
http://www.saunalahti.fi/~asokan/research/mitm.html,
October 2002
[MITM1] Asokan, N., Niemi, V., Nyberg, K., "Man-in-the-middle
in tunneled authentication", November 2002
Acknowledgments
We wish to thank N. Asokan, Valterri Niemi, Kaisa Nyberg and Henry
Haverinen of Nokia for initially making us aware of the problem [MITM].
Special thanks to Bernard Aboba, N.Asokan, Jesse Walker, Farid Adrangi,
Nancy Cam-Winget and Joe Salowey for their valuable comments and
suggestions.
Also thanks to Bernard Aboba for his expert advice and editorial
assistance.
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
Puthenkulam et al. Informational [Page 37]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
Victor Lortz
Intel Corporation
2111 NE 25th Avenue, JF3-206
Hillsboro, OR 97124
EMail: victor.lortz@intel.com
Phone: +1 503 264 3253
Fax: +1 503 264 4230
Ashwin Palekar
Dan Simon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: {ashwinp, dansimon}@microsoft.com
Phone: +1 425 882 8080
Fax: +1 425 936 7329
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 38]
INTERNET-DRAFT Compound Binding Problem 3 March 2003
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-02.txt>, and
expires on September 3, 2003.
Puthenkulam et al. Informational [Page 39]