Internet DRAFT - draft-barany-eap-gee
draft-barany-eap-gee
Network P. Barany
Internet-Draft R. Rezaiifar
Intended status: Informational L. Dondeti
Expires: August 5, 2007 V. Narayanan
QUALCOMM, Inc.
J. Salowey
P. Yegani
Cisco Systems
February 2007
3GPP2 Generic EAP Encapsulation (GEE) Protocol
draft-barany-eap-gee-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Extensible Authentication Protocol (EAP) is a general
authentication protocol that supports multiple authentication methods
and typically runs directly over data link layers without requiring
Barany, et al. Expires August 5, 2007 [Page 1]
Internet-Draft GEE February 2007
IP. EAP can be used for different types of authentication, where
multiple providers provide different services. However, EAP itself
does not have the ability to differentiate between multiple EAP
conversations between a peer and an authenticator. This document
specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for
differentiating between multiple EAP conversations between a peer and
an authenticator.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture and Overview . . . . . . . . . . . . . . . . . . 5
3.1. Multiple Authenticator Model . . . . . . . . . . . . . . . 6
4. Expected Lower Layer Behavior for GEE . . . . . . . . . . . . 7
5. GEE Message Format . . . . . . . . . . . . . . . . . . . . . . 7
5.1. GEE Header Format . . . . . . . . . . . . . . . . . . . . 8
6. Packet Processing Details . . . . . . . . . . . . . . . . . . 9
6.1. Packet Handling at the Peer . . . . . . . . . . . . . . . 9
6.2. Packet Handling at the Authenticator . . . . . . . . . . . 9
6.3. Multiple authentications and access control enforcement . 10
7. GEE Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Recap of use cases and interactions between network
entities . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Threats and mitigation strategies . . . . . . . . . . . . 12
8.2.1. Threats that might cause denial of service . . . . . . 13
8.2.2. Threats that might cause theft of service . . . . . . 13
8.3. Implications of multiple EAP authentications . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Barany, et al. Expires August 5, 2007 [Page 2]
Internet-Draft GEE February 2007
1. Introduction
The Extensible Authentication Protocol (EAP) [1] is a widely deployed
general authentication protocol that supports multiple authentication
methods and typically runs directly over data link layers such as the
Point-to-Point Protocol (PPP) [4] or other link layer protocols,
without requiring IP.
EAP was originally developed as a general authentication protocol for
use with the PPP protocol [5]. It is now also used by IEEE 802 wired
media as described in [6] and IEEE wireless LANs as described in [7].
As CDMA2000 third generation cellular networks evolve [8], [9], EAP
will also be used as a general authentication protocol that runs
directly over the data link layer [10].
EAP can be used for different types of authentication, where multiple
providers provide different services. However, EAP itself does not
have the ability to differentiate between multiple EAP conversations
between a peer and an authenticator. Typically, the lower layer is
responsible for differentiating multiple EAP conversations and thid
document provides one such mechanism.
This document specifies the 3GPP2 Generic EAP Encapsulation (GEE)
protocol for differentiating between multiple EAP conversations
between a peer and an authenticator. Note that this protocol is
"generic" within the specific context of 3gpp2. In other words, this
mechanism may be used by multiple lower layers within 3gpp2. In the
rest of this document, we refer to this protocol as GEE, Version 0 or
GEEv0.
1.1. Motivation
+--------------+ +--------------+
| ANP | | SNP |
| | | |
+----+ +-----+ | | |
| MN |--- | NAS | | | +-------+ |
+----+ +-----+ |===| |AAA-SNP| |
| \ | | +-------+ |
| \ +-------+ | | |
| -|AAA-ANP| | | |
| +-------+ | | |
+--------------+ +--------------+
Barany, et al. Expires August 5, 2007 [Page 3]
Internet-Draft GEE February 2007
Figure 1: Model with separate ANP and SNP
The network provider model has evolved to a point where it is not
uncommon to have multiple network providers that offer various
services. For instance, the access network provider (ANP) is often
different from a service network provider (SNP) as noted above. It
is possible that a peer needs to perform authentication separately
with the two network providers. Regardless of whether the access and
service network providers are the same or not, separate
authentications may be required. Also, for EAP-based authentication,
the two EAP methods may or may not be the same. Figure 1 shows an
example of the case where the access network provider is different
from the service network provider. The ANP hosts the Authenticator
(NAS or Network Access Server in the figure) and an Authentication
Server (AAA-ANP in the figure). The SNP may have its own
Authentication Server (AAA-SNP in the figure). Note that the
Authenticator for the SNP may be the same as that in the ANP. In
lower layers that support simultaneous attachment to multiple access
points, the Authenticator for each network may be different.
A good example where separate authentications are needed is the case
of Mobile Virtual Network Operators (MVNO). In this case, the
network provider providing Layer1 and Layer2 access is typically
different from that providing Layer 3 service (i.e., IP level
service). Hence, separate authentications are usually required.
In cases where multiple authentications are performed, it may be
desirable to do them in parallel, to avoid added latency resulting
from a sequential execution of the two authentications. When a peer
is performing multiple EAP authentications, it is not always possible
to clearly differentiate between the two types of authentications
using available means. Also, the authenticator will need to
distinguish the multiple EAP exchanges in order to route the packets
to the correct EAP server. Typically, the Identifier value in an EAP
Response packet will be the same as that in the matching Request -
however, the authenticator, while operating in pass-through mode,
does not keep track of the value of the Identifier field. Even if
the authenticator could match up the values of the Identifier field,
the two EAP servers performing the authentications may generate the
same Identifier (since the Identifier is a randomly chosen 8-bit
field in the EAP Request/Response packets to unambiguously match up
requests with responses). Hence, there is no available means that
can be used by any lower layer to allow multiple EAP authentications
for a given peer to occur in parallel.
While some EAP methods are TLV-based and can easily be extended to
carry additional information between the peer and the server, EAP
itself does not provide a means to carry any additional information
Barany, et al. Expires August 5, 2007 [Page 4]
Internet-Draft GEE February 2007
between the peer and the authenticator. Hence, the primary
motivation for this document is to provide, in the context of 3gpp2,
the functionality for EAP peers and authenticators to differentiate
between multiple EAP exchanges that a peer may be executing in
parallel.
2. Terminology
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 RFC 2119 [2].
This document uses terminology defined in [1]. In addition, this
document uses the following terms:
Access Network Provider (ANP)
A service provider that provides physical and link-layer
connectivity (i.e., Layer1 and Layer2 connectivity) to an access
network that it manages.
Service Network Provider (SNP)
A service provider that provides Layer3 connectivity to a network
it manages.
Type 1 Authentication
This refers to one authentication that is performed by the peer.
Type 2 Authentication
This refers to another authentication that is performed by the
peer, that is different from Type 1 authentication.
3. Architecture and Overview
GEE does not define any new architectural elements other than those
already defined by EAP. The protocol functionality described in this
document applies to the EAP peer and authenticator only. The
protocol has no impact and does not depend on the EAP method used by
the peer and the server.
In accordance with the EAP specification [1], an EAP authenticator
may either terminate the EAP session or may act in pass-through mode,
where the EAP session is terminated by a backend authentication
Barany, et al. Expires August 5, 2007 [Page 5]
Internet-Draft GEE February 2007
server, also known as an EAP server. This protocol applies to both
modes of operation, unless specifically pointed out.
The proposed protocol operation remains mostly the same in the EAP
multiplexing model as well as the EAP pass-through model. At a high
level, this protocol allows the peer and authenticator to perform
multiple EAP authentications independently and potentially with
different authentication servers in different provider networks. The
multiple EAP conversations may happen sequentially or in parallel.
However, in accordance with RFC 3748, an EAP peer and authenticator
MUST utilize only one authentication method within an EAP
conversation, unless the providers are the same and the peer is using
the same credentials and EAP method for both types of authentication.
When the authenticator operates in pass-through mode, the GEE-enabled
lower layer terminates at the authenticator and the EAP packet is
sent over a backend AAA layer (e.g., RADIUS [11]). In this case, the
authenticator must handle the GEE fields in exactly the same manner
as in the multiplexing model. The fields in the GEE header may be
used by the authenticator to identify the correct EAP exchange to
properly route the EAP packet. A Transaction ID (TID) field defined
in the protocol allows the EAP exchanges to be distinguished. The
TID field is used to look up the appropriate domain to which a
particular EAP message must be routed.
3.1. Multiple Authenticator Model
+--------------+ +--------------+
| ANP | | SNP |
| | | |
+----+ +-----+ | +-----+ |
| MN |--- |NAS 1| |===|NAS 2| |
+----+ +-----+ | +-----+ |
| \ | | \ |
| \ +-------+ | | \ +-------+ |
| -|AAA-ANP| | | -|AAA-SNP| |
| +-------+ | | +-------+ |
+--------------+ +--------------+
Figure 2: Multiple Authenticator Model
Depending on the architecture, the authenticator that is responsible
for each authentication may be different. This could be true
irrespective of whether the EAP server is the same or different for
each authentication. However, in most practical cases, the need for
multiple authentications arises only when the EAP servers performing
Barany, et al. Expires August 5, 2007 [Page 6]
Internet-Draft GEE February 2007
the different types of authentications are different. Figure 2 shows
the architecture with each provider having a different authenticator
that is engaged in different EAP exchanges that the peer performs.
In 3GPP2 networks, single authenticator and multiple authenticator
architectures are both possible.
When the multiple EAP authentications are over the same link, the EAP
exchange between the peer and one of the authenticators may have to
pass through another authenticator or enforcement point. Hence, the
lower layers at each hop must be able to indicate the presence of the
GEE header.
4. Expected Lower Layer Behavior for GEE
The peer and the authenticator must have a mechanism to agree on the
use of GEE as an encapsulation for EAP. Such a mechanism may be
achieved via lower layer negotiation. Alternately, the peer may be
pre-configured to know which networks require the use of GEE.
Further, there is no requirements placed on the EAP layer due to GEE.
The lower layer is fully expected to hide the presence of GEE from
the EAP layer. GEE is not a lower layer for EAP. Hence, this
implies that the processing of GEE happens fully within the lower
layer and the interface between the lower layer and EAP is unimpacted
by the presence of GEE.
When the authenticator sends an EAP packet to the peer, the lower
layer of the authenticator appends a GEE header to the EAP packet
created by the EAP layer before sending it to the peer. Upon
reception of the packet, the lower layer of the peer needs to process
the GEE header to determine which credentials to use in the EAP
response. Note that this does not assume any GEE-related interface
between the EAP and lower layers. It only implies that there must be
a mechanism of providing the right identity or credential to the EAP
layer based on the type of authentication requested by GEE.
5. GEE Message Format
A GEE encapsulated packet has the following format.
Barany, et al. Expires August 5, 2007 [Page 7]
Internet-Draft GEE February 2007
---------------------------------
| |
| EAP packet |
| |
---------------------------------
| |
| GEE header |
| |
---------------------------------
| |
| Data link layer header |
| |
---------------------------------
Figure 3: GEE Encapsulated Packet
5.1. GEE Header Format
The GEE Header has the following format.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version|TID|RFL|
+-+-+-+-+-+-+-+-+
Figure 4: GEE Header
Version
The first 4 bits in the GEE header represent the protocol version
number. This field MUST be set to 0 for GEEv0.
Transaction ID (TID)
A 2-bit TID flag is used to distinguish between multiple EAP
conversations. In Version 0 of GEE (GEEv0), the TID field MUST be
either 00 or 01. When TID = 01, the encapsulated EAP packet is
for Type 1 authentication. When TID = 00, the encapsulated EAP
packet is for Type 2 authentication. In GEEv0, TID values other
than 00 and 01 are reserved and MUST NOT be used.
Barany, et al. Expires August 5, 2007 [Page 8]
Internet-Draft GEE February 2007
Result flags/code (RFL)
The last 2 bits in the GEE header are used to indicate the result
of the EAP authentication in progress. The leftmost bit in this
field is the 'K' bit and indicates whether the Master Session Key
(MSK) resulting from the EAP conversation being encapsulated by
the particular GEE session must be bound with an MSK resulting
from the second EAP conversation carried in a second GEE session.
If set, this implies that the lower layer of the peer MUST bind
the MSKs to derive TSKs. The process of MSK binding is described
in Section 6.3. In GEEv0, the last bit is the R bit and is
reserved and MUST be set to zero at the sender and MUST be ignored
by the receiver.
6. Packet Processing Details
6.1. Packet Handling at the Peer
When the peer receives a GEEv0 packet, the TID field in the GEEv0
header MUST be used to determine if the encapsulated EAP packet is
for Type 1 or Type 2 authentication. If TID value is 01 in the
packet received from the authenticator, the peer must perform the
necessary Type 1 authentication. For instance, this may mean that
the peer provides the appropriate identity and use the appropriate
EAP method in the EAP session. When the TID is set to 00 in the
packet received from the authenticator, the peer must perform the
necessary Type 2 authentication.
While Type 1 and Type 2 authentications are not explicitly defined in
this document, these must be defined at the peer and authenticator
for a given usage of this protocol.
When the peer sends a GEEv0 packet in response to a GEEv0 packet
received from the authenticator, the TID value MUST be copied from
the corresponding packet received from the authenticator. As with
the packet from the authenticator, a value of 01 indicates that the
EAP packet is for Type 1 authentication and a value of 00 indicates
that the encapsulated EAP packet is for Type 2 authentication. The
RFL value MUST be set to 00.
6.2. Packet Handling at the Authenticator
When the authenticator receives a GEEv0 packet, the TID value in the
header MUST be used to determine if the encapsulated EAP packet is
for Type 1 or Type 2 authentication.
When the authenticator sends a GEEv0 packet, the TID value in the
Barany, et al. Expires August 5, 2007 [Page 9]
Internet-Draft GEE February 2007
header MUST be set to 01 if the encapsulated EAP packet is for Type 1
authentication. The TID value MUST be set to 00 by the authenticator
if the encapsulated EAP packet is for Type 2 authentication. The K
bit in the RFL field MUST be set if the peer is expected to bind the
MSKs prior to using it for generating other keys. The last bit in
the RFL field MUST always be set to 0. In order to set the K bit
appropriately, it is expected that the authenticator knows about
another EAP exchange that the peer may be doing and if the keys must
be bound or not.
6.3. Multiple authentications and access control enforcement
When both Type 1 and Type 2 authentications are carried out, access
control MUST conform to the following cases.
Type1 Type2 Combined result
Case 1 Success Success Success
Case 2 Success Failure Type1 related access only
Cases 3&4 Failure S/F Failure
Access Control Matrix
In GEEv0, at least one of the authentications MUST be key generating
and both authentications MUST be mutually authenticating. If one of
the authentications is not key generating, then there MUST be a way
for the authenticator to identify the two authentication
conversations (Type 1 and Type 2) corresponding to a peer.
Specifically, there MUST be a mechanism for the authenticator to
correlate the Type 1 and Type 2 credentials; typically this is
facilitated by backend network protocol support. An example of such
backend support is to be able to send an identifier that is unique to
the peer across the authentications in an authenticated manner. If
there is a mismatch, or the node has not received such an identity
from both transactions, the peer MUST be disconnected.
It must be noted that such non-cryptographic bindings cannot
translate to absolute access control based on both authentications,
unlike the case of key binding described below. These may be used in
the presence of non-key generating methods under tightly controlled
administrative environments.
If both Type 1 and Type 2 authentications are key generating and
occur in parallel, the keys must be bound as specified below.
Barany, et al. Expires August 5, 2007 [Page 10]
Internet-Draft GEE February 2007
MSK Binding
In this case,even when there are multiple authenticators, we
assume that there is only one access control enforcement point.
Here, the combined MSK MUST be used to derive session keys
(Transient session keys, TSKs). Both authenticators deliver the
MSK to the enforcement point and it computes a combined key as
follows: Intermediate-MSK = f(MSK-Type 1, "GEE Combined Key" ||
MSK-Type 2), where f represents prf+ as defined in [3]. The
length of the Combined-MSK MUST be at least 512 bits. With GEEv0,
the PRF is HMAC-SHA-256.
When two EAP authentications are performed, it is always feasible to
use keys from a first exchange to protect a subsequent exchange.
Note that the two authentications in this case will occur
sequentially and the first method must be key generating. The use of
GEE does not preclude such an operation, even though the main
motivation for GEE is to allow parallel execution of the EAP
exchanges.
7. GEE Extensibility
GEE could be extended to support dynamic TID assignment, where an
authenticator may pick an unused TID value. The peer could
participate in as many as 4 EAP conversations in parallel.
In order for the peer to be able to understand the meaning of each
TID, a new mechanism would be needed to send information about
authentication type and other policy hints. Such a mechanism could
either operate on the layer that carries GEE, or in an extended
version of GEE itself. Note that RFC 4284 defines a mechanism for
the authenticator to advertise a set of roaming realms. With this
information alone, the peer needs to readily understand the nature of
authentication based on the realm information. However, in some
cases, a peer may have multiple credentials (e.g., for device and
user authentication) for a give realm and for that or other reasons,
providing a list of realms alone may not be sufficient. In those
cases, the realm information itself is insufficient. Also, due to
EAP MTU and other considerations, RFC 4284 can carry only a very
limited amount of information, and it is not intended for carrying
other policy information. Due to such limitations with existing
mechanisms, other mechanisms are likely to be needed to support the
required functionality for dynamic TID assignment. This document
does not propose any such mechanisms at this time.
Specifically, if there is a need for additional capability to use the
identity hints and indicate the type of authentication via extensible
Barany, et al. Expires August 5, 2007 [Page 11]
Internet-Draft GEE February 2007
options (TLVs), the restriction imposed in GEEv0 on the semantics of
the TID field can be removed for future versions of the protocol that
may be developed. Further, future versions of GEE may use the last
bit in the result flags/code (RFL) field to indicate the presence of
TLVs in the GEE header.
8. Security Considerations
In this section, we recap the use cases of GEE and possible
interactions between various network entities using GEE, discuss
potential vulnerabilities that an adversary might exploit and finally
describe mechanisms and best practices on how to mitigate the
threats.
We note that the vulnerabilities discussed here in are in addition to
those considered in EAP [1].
8.1. Recap of use cases and interactions between network entities
GEE encapsulates EAP so an authenticator can signal to the peer about
the type of authentication the EAP request is meant for. GEE also
facilitates parallel execution of such authentications. For
instance, Type 1 and Type 2 authentication may take place
sequentially (in any order) or in parallel.
A further consideration is whether the same network provider is
providing Type 1 and Type 2 services (different credentials and same
AAA server), or different network providers, i.e., different AAA
servers are involved.
The lower layer needs to negotiate the use of GEE. Lower layer
implementations MAY choose to confirm the negotiation in the secure
association protocol exchange performed after EAP. However,
negotiation of GEE is an operational thing and no security properties
are lost if such a confirmation is not done.
8.2. Threats and mitigation strategies
The GEE header is not cryptographically protected. Thus it is
plausible for an eavesdropper to use Layer 2, GEE and EAP headers and
collate information on how certain devices are authenticating
themselves to their network providers: the order and combination of
the different types of authentication are easily available in those
headers.
Note that if Type 1 authentication occurs first and subsequent
authentication processes take place via a Layer 2 encrypted channel,
Barany, et al. Expires August 5, 2007 [Page 12]
Internet-Draft GEE February 2007
information about the rest of the authentications will not be
available to passive observers on the path from the peer to the
authenticator. However, this obviously suffers from the shortcoming
that the multiple authentications cannot be executed in parallel if
this is required. Further, this is no different than an eavesdropper
obtaining information from the EAP headers on the wire when GEE is
not used. Hence, such passive attacks are not considered to be of
any additional significance in GEEv0. If future versions of GEE
allow any sensitive data to be carried in GEE, passive attack
considerations must be revisited.
In addition to the passive attacks, an adversary may launch mainly
two types of active attacks on GEE: in the first, the adversary may
attempt to disrupt or deny service for other entities whereas in the
second, the adversary may attempt to gain network access or IP
services impersonating other entities.
8.2.1. Threats that might cause denial of service
An adversary may change any of the contents of the GEE payload, the
version field and/or the TID field, to cause either the peer or the
authenticator to drop GEE encapsulated EAP packets. Suppose an
attacker consistently changes the value of the TID field, the AAA
server may conclude that the peer's credentials may have been
compromised and may revoke access so as to trigger an offline process
for updating that peer's credentials. As a result the peer may lose
connectivity temporarily. Note however that EAP conversations
without GEE encapsulation are vulnerable to denial-of-service
attacks, and GEEv0 does not change this vulnerability.
8.2.2. Threats that might cause theft of service
If the EAP method used for one authentication is known to be weaker
than the EAP method used for another authentication, whereas the
authenticator may intend to enforce one authentication before the
other, an attacker may modify the GEE flags to cause the peer to
start the weaker authentication without the protection of stronger
authentication. The adversary may then be able to break the weaker
authentication method. Even if the authenticator requires, say, both
Type 1 and Type 2 authentications from all peers, it is plausible for
a rogue peer with available credentials for Type 1 authentication to
pass off the successful Type 2 authentication of another peer as its
own.
To mitigate this threat, i.e., when the EAP method used for one
authentication (e.g., Type 2) is more vulnerable to attacks than the
EAP method used for another authentication (e.g., Type 1), the
authenticator needs to strictly enforce a policy of Type 1
Barany, et al. Expires August 5, 2007 [Page 13]
Internet-Draft GEE February 2007
authentication first, and require that the Type 2 authentication
occur within the secure channel established as a result of Type 1
authentication.
8.2.2.1. Possible subversion of authentication policy
Suppose a peer has credentials for Type 1 authentication in a visited
network and credentials for both Type 1 and Type 2 authentication in
the home network. It is plausible that the peer may supply its home
network credentials for Type 1 as well as Type 2 authentication and
thereby avoid any payments to the visited ANP. To avoid this
possibility, the AAA-ANP may send to the authenticators its Type 1
authentication policy by sending a list of realms for which Type 1
authentication request is allowed to be forwarded to home network.
The authenticator may share that information with the peer in the EAP
identity request following the semantics in RFC 4284 [12] (and
applicable security considerations) or other similar procedures.
8.3. Implications of multiple EAP authentications
GEE is designed to facilitate the use of multiple parallel EAP
authentications and that implies certain requirements on the EAP
methods used. First, it is clear that at least one of the methods
must be key generating and all the methods must be mutually
authenticating. The key generation requirement is to authenticate
the data packets as coming from the peer that participated in the
authentication whereas the mutual authentication requirement is self-
explanatory.
There is however still the possibility of a man-in-the-middle (MiTM)
attack between EAP authentications. Briefly, since the authenticator
does not have enough information to associate NAIs corresponding to
multiple authentications, it is plausible for an adversary to skip
one or more of the EAP authentications and instead claim the
authentication exchange of a legitimate peer as its own. The
authenticator would have no way of verifying the claim.
There are several possible mitigation strategies including the use of
identifier binding between authentications, or in case of sequential
authentications, the use of key material from the first
authentication to encrypt future authentications. Other solutions
require all authentications to be key generating and binding all the
keys to generate the master key used to bootstrap the traffic key
generation process or using multiple encapsulations with the
generated keys.
When the multiple authentications are key generating and occur in
parallel, GEEv0 requires that all of the MSKs resulting from each
Barany, et al. Expires August 5, 2007 [Page 14]
Internet-Draft GEE February 2007
authentication be used for access control in order to successfully
prevent any MiTM attacks. When only one of the authentications is
key generating or when the authentications occur sequentially, other
administrative policies must be used to ensure that the threat is
mitigated.
When multiple authentications occur, packet modification attacks may
cause the wrong type of access to be granted to the peer as a result
of a particular authentication. To prevent this, specific
authorization information must be sent from the backend AAA server to
the authenticator specifying the type of access granted after a
particular authentication.
9. IANA Considerations
We request IANA to maintain a GEE registry. The registry will be
version dependent and will contain the following items for GEEv0:
The 4-bit Version field (Version 0 is to be registered for this
RFC). Additional values can be allocated via IETF Review [13].
The 2-bit TID field (values 00 and 01 are to be registered for
this RFC). Additional values can be allocated via IETF Review,
but only in conjunction of defining a new version number.
The 2-bit RFL field (the first bit, K, is to be registered for
this RFC). Additional values can be allocated via IETF Review.
10. Acknowledgments
We thank Parag Agashe, Paul Bender, Raymond Hsu, AC Mahendran, and
Jun Wang for their review of earlier versions of this draft and/or
for their contributions to the many discussions on this topic.
11. References
11.1. Normative References
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Barany, et al. Expires August 5, 2007 [Page 15]
Internet-Draft GEE February 2007
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
11.2. Informative References
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[6] Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Port based
Network Access Control, IEEE Std 802.1X-2004", Dec 2004.
[7] Institute of Electrical and Electronics Engineers, "Supplement
to Standard for Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications: Specification for Enhanced Security, IEEE
802.11i", July 2004.
[8] 3GPP2, "3GPP2 X.S0011-002-D v1.0, "cdma2000 Wireless IP Network
Standard: Simple IP and Mobile IP Access Services", (to be
published).".
[9] 3GPP2, "3GPP2 A.S0008-B v1.0, "Interoperability Specification
(IOS) for High Rate Packet Data (HRPD) Access Network
Interfaces", (to be published).".
[10] 3GPP2, "3GPP2 C.S0063-0 v2.0, "cdma2000 High Rate Packet Data
Supplemental Services", (to be published).".
[11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003.
[12] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
Selection Hints for the Extensible Authentication Protocol
(EAP)", RFC 4284, January 2006.
[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-05 (work in
progress), September 2006.
[14] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006.
Barany, et al. Expires August 5, 2007 [Page 16]
Internet-Draft GEE February 2007
Authors' Addresses
Peter Barany
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-658-2341
Email: pbarany@qualcomm.com
Ramin Rezaiifar
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-651-2067
Email: rrezaiifar@qualcomm.com
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Barany, et al. Expires August 5, 2007 [Page 17]
Internet-Draft GEE February 2007
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA
USA
Phone: +1 206-256-3380
Email: jsalowey@cisco.com
Parviz Yegani
Cisco Systems
3625 Cisco Way
San Jose, CA
USA
Phone: +1 408-832-5729
Email: pyegani@cisco.com
Barany, et al. Expires August 5, 2007 [Page 18]
Internet-Draft GEE February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barany, et al. Expires August 5, 2007 [Page 19]
