One document matched: draft-ietf-hokey-preauth-ps-06.txt
Differences from draft-ietf-hokey-preauth-ps-05.txt
Network Working Group Q. Wu (Editor)
Internet-Draft Huawei
Intended status: Informational Y. Ohba (Editor)
Expires: September 9, 2009 Toshiba
March 8, 2009
EAP Pre-authentication Problem Statement
draft-ietf-hokey-preauth-ps-06
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 9, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
EAP (Extensible Authentication Protocol) pre-authentication is
defined as the use of EAP to pre-establish EAP keying material on a
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 1]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
target authenticator prior to arrival of the peer at the access
network managed by that authenticator. This draft discusses EAP pre-
authentication problems in detail.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Usage Models . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. The pre-authentication model(Peer-CA-AAA) . . . . . . . . 9
4.2. The Pre-authentication model(Peer-SA-CA-AAA) . . . . . . . 10
4.3. The Pre-authentication model(Peer-SA-AAA-CA) . . . . . . . 12
5. Architectural Considerations . . . . . . . . . . . . . . . . . 13
5.1. Authenticator Discovery . . . . . . . . . . . . . . . . . 13
5.2. Context Binding . . . . . . . . . . . . . . . . . . . . . 13
6. AAA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 2]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
1. Introduction
When a mobile device during an active communication session moves
from one access network to another access network and changes its
point of attachment, it is subjected to disruption in the continuity
of service because of the associated handover operation. The
performance requirement of a real-time application will vary based on
the type of application and its characteristics such as delay
tolerance and loss tolerance limit. ITU-T G.114 [ITU] recommends 150
ms as the upper limit for VoIP applications and 400 ms as generally
unacceptable delay. Similarly, a streaming application has a
tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and
the transfer delay of less than 300 ms. Thus, any optimized handoff
mechanism will need to take these factors into consideration in order
to be able to support a heterogeneous handover that is agnostic to
link-layer technologies.
As a mobile device goes through a handover process, it is subjected
to delay because of the rebinding of its association at or across
several layers of the protocol stack and higer number of round trips
for EAP exchange. Delays incurred within each of these layers affect
the ongoing multimedia application and data traffic within the client
[WCM].
During the handover process, it often requires authentication and
authorization for acquisition or modification of resources assigned
to a mobile device and the authentication and authorization needs
interaction with a central authority in a domain in most cases. In
some cases the central authority may be placed far away from the
mobile device. The delay introduced due to such an authentication
and authorization procedure adds to the handover latency and
consequently affects ongoing application sessions [MQ7]. As
regarding this kind of delay, we focus our discussion highlighting
the factors that affect the performance due to network access
authentication and authorization where EAP [RFC3748] is used for
network access authentication.
This draft discusses EAP pre-authentication problems in detail where
EAP pre-authentication is defined as the utilization of EAP to pre-
establish EAP keying material on an EAP authenticator prior to
arrival of the mobile device that acts as an EAP peer, at the access
network served by that authenticator.
2. Terminology
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 3]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Peer
See [RFC3748].
Authenticator
See [RFC3748].
EAP Server
See [RFC3748].
Serving Authenticator (SA)
An authenticator that is currently serving the peer.
Target Authenticator (TA)
An authenticator that has been chosen to be the new serving
authenticator for a peer.
Candidate Authenticator (CA)
An authenticator that can potentially become the target
authenticator for a peer. There can be multiple candidate
authenticators for the peer.
Serving Access Network
An access network that is currently serving the peer.
Candidate Access Network
An access network that can potentially become the target access
network for a peer. There can be multiple candidate access
network for the peer.
Target Access Network
An access network that has been chosen to be the new serving
access network for a peer.
Master Session Key (MSK)
See [RFC3748].
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 4]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Access Point (AP)
A network point of attachment in IEEE 802.11 wireless LAN
[802.11].
Basic Service Set (BSS)
The basic building block of an IEEE 802.11 wireless LAN [802.11].
The BSS consists of a group of any number of 802.11 stations.
Extended Service Set (ESS)
A set of infrastructure BSSs in IEEE 802.11 wireless LAN [802.11],
where the access points communicate amongst themselves to forward
traffic from one BSS to another to facilitate movement of stations
between BSSs.
Inter-ESS Handover
An 802.11 handover across multiple ESSs.
Intra-AAA-Domain Handover (Intra-Domain Handover)
A handover within the same AAA domain. Intra-AAA-domain Handover
include a handover across different authenticators within the same
AAA domain.
Inter-AAA-Domain Handover (Inter-Domain Handover)
A handover across multiple AAA domains.
Intra-Technology Handover
A handover within the same link layer technology.
Inter-Technology Handover
A handover across different link layer technologies.
Inter-Authenticator Handover
A handover across multiple authenticators. An inter-access-domain
handover, an inter-ESS handover, an inter-AAA-domain handover, an
inter-technology handover can be view as examples of An inter-
authenticator handover.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 5]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
ERP (EAP Extensions for EAP Re-authentication Protocol)
Extensions to EAP and EAP keying hierarchy to support an EAP
method-independent protocol for efficient re-authentication
between the peer and an EAP re-authentication server defined in
[RFC5296].
3. Problem Statement
The basic mechanism of handover is a three-step procedure involving
i) discovery of candidate network points of attachment and their
authenticators, ii) network selection procedure to determine the
appropriate candidate network point of attachment and iii) handover
or setting up L2 and L3 connectivity to the target network point of
attachment. Currently, as part of the third step, network access
authentication and authorization are performed directly with the
target network. For example, in IEEE 802.11 wireless LANs [802.11],
the network access authentication and authorization involves
performing a new IEEE 802.1X message exchange with the authenticator
in the target AP to initiate an EAP exchange to the authentication
server [WPA]. Following a successful EAP authentication, a secure
association procedure is performed between the peer and the target
authenticator to derive a new set of link-layer ciphering keys from
EAP keying material such as the MSK. The third step may require full
EAP authentication in the absence of any particular optimization for
handover key management. The handover latency introduced by full EAP
authentication has proven to be larger than that is acceptable for
real-time applications scenarios as described in [MQ7]. Hence,
improvement in the handover latency performance due to EAP is a
necessary objective for such scenarios.
There is relevant work undertaken by various standards organizations,
but these efforts are scoped to a specific link layer technology.
IEEE 802.11F [802.11f], a trial use document has defined context
transfer and caching mechanism to transfer some IEEE 802.11 keying
material between the neighboring APs. However, it has been
administratively withdrawn since 2006. IEEE 802.11 [802.11] defines
a pre-authentication mechanism for use in 802.11 wireless networks.
This mechanism allows peers to pre-authenticate to one or more
candidate authenticators over the wired medium, by way of the serving
authenticator. IEEE 802.11r [802.11r] defines Fast BSS transition
mechanisms involving a definition of a key management hierarchy and
setup of session keys before the re-association to the target AP in
the same 802.11r mobility domain. These mechanisms, as indicated
before, are defined for IEEE 802.11 technologies and are only
applicable for intra-technology handover within the 802.11 mobility
domain with the limited coverage and fall short when it comes to
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 6]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
inter-technology handovers (e.g., movement between WLAN and 3G cell
network) or inter-ESS handover. They also require L2 (e.g.,
Ethernet) connectivity for transfer of key management signaling to
the target AP. A solution is needed to enable EAP pre-authentication
for inter-AAA-domain or inter-ESS handovers in IEEE 802.11.
As various flavors of wireless technologies are increasingly
available, there is a growing demand for seamless inter-technology
mobility. This is particularly beneficial in the presence of high
bandwidth, low cost, wireless technologies (e.g., IEEE 802.11) with
only limited coverage, e.g., hotspot coverage while the overlay
licensed wireless/cellular coverage is expensive and relatively low
bandwidth. Hence, the security optimization mechanisms for better
handover performance must be looked at from the IP level so as to
make it a common method over different access technologies.
Optimized solutions for secure inter-authenticator handovers can be
largely seen as security context transfer: ERP [RFC5296] or EAP pre-
authentication. Security context transfer involves transfer of
reusable key context to the new point of attachment. However, the
recent AAA key management requirements [RFC4962] do not recommend
horizontal context transfer of reusable key context because of the
domino effect in which the compromise of an authenticator will lead
to the compromise of another authenticator. So ERP uses existing EAP
keying material obtained from AAA server for deriving a re-
authentication key to be distributed to an ERP server in a visited
domain in order to reduce the handover delay, which eliminates the
need for running full EAP authentication with the EAP server in the
home domain for intra-domain handovers. On the other hand, there are
certain cases where ERP is not applicable or an additional
optimization mechanism is needed to establish a key for the candidate
authenticator:
o One case is an inter-domain handover with the trust relationship
between the home and visited AAA domains. If there is a trust
relationship between the two AAA domains and the visited AAA
domain supports ERP, full EAP authentication with the EAP server
in the home AAA domain is still needed to distribute the existing
keying materials to the ERP server when entering the visited AAA
domain.
o Second case is an inter-technology handover where the target
authenticator or AAA domain do not support ERP.
o Another case is an intra-domain, inter-authenticator handover
where the target authenticator or AAA domain do not support ERP,
or ERP needs to be performed proactively before the peer arrives
at the target authenticator.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 7]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
EAP pre-authentication discussed in this document is mainly to deal
with these cases while a general solution for the EAP pre-
authentication problem can be used for other handover cases.
EAP pre-authentication has general applicability to various
deployment scenarios in which proactive signaling can take effect.
In other words, applicability of EAP pre-authentication is limited to
the scenarios where candidate authenticators can be discovered and an
accurate prediction of movement can be easily made. Also the
effectiveness of EAP pre-authentication may be less significant for
particular inter-technology handover scenarios where simultaneous use
of multiple technologies is not a major concern.
In EAP pre-authentication, AAA-based authentication and authorization
for a candidate authenticator is performed while ongoing data
communication is in progress via the serving network. The goal of
EAP pre-authentication is to avoid AAA signaling for EAP when or soon
after the peer moves. There are several AAA issues related to EAP
pre-authentication. The pre-authentication AAA issues are described
in Section 6.
Figure 1 shows the functional elements that are related to EAP pre-
authentication. These functional elements include a peer, a serving
authenticator, a candidate authenticator and an AAA/EAP server or
AAA/EAP servers. The AAA servers can be divided into the AAA server
in the home domain and the AAA proxy/server in the visited AAA
domain. When the serving and candidate authenticators belong to
different AAA domains, the candidate authenticator may use a
different AAA server and user credentials than those were used by the
serving authenticator to authenticate the peer.
+------+ +-------------+ +------+
| Peer |------| Serving | / \
| | |Authenticator|---/ \
+------+ +-------------+ / \
. / \ +-----------------+
. Move + IP Network +---|AAA/EAP Server(s)|
. \ / +-----------------+
v +-------------+ \ /
| Candidate |---\ /
|Authenticator| \ /
+-------------+ +------+
Figure 1: EAP Pre-authentication Functional Elements
A peer is attached to the serving access network. Before the peer
performs handover from the serving access network to a candidate
access network, it performs EAP pre-authentication with a candidate
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 8]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
authenticator via the serving access network. The peer may perform
EAP pre-authentication with one or more candidate authenticators. It
is assumed that each authenticator has an IP address. It is assumed
that there is at least one candidate authenticator in each candidate
access network while the serving access network may or may not have a
serving authenticator. The serving and candidate access networks may
use different link layer technologies.
Each authenticator is either a standalone authenticator or pass-
through authenticator [RFC3748]. When an authenticator acts as a
standalone authenticator, it also has the functionality of an EAP
server. When an authenticator acts as a pass-through authenticator,
it communicates with the EAP server typically implemented on a AAA
server using a AAA transport protocol such as RADIUS [RFC2865] and
Diameter [RFC3588].
If the candidate authenticator uses an MSK [RFC5247] for generating
lower-layer ciphering keys, EAP pre-authentication is used for
proactively generating an MSK for the candidate authenticator.
4. Usage Models
As specified in the section 3, there are certain cases where Pre-
authentication is applicable while ERP does not work. This section
concentrates on providing some usage models based on the certain
cases mentioned above. It is assumed that in these models there is
no direct L2 connectivity between a peer and a candidate
authenticator. No security association between the serving
authenticator and the candidate authenticator is required for either
pre-authentication scenario (see Section 7 Section 7 for more
detailed discussion). Depending on how the serving authenticator is
involved in the EAP pre-authentication signaling, these scenarios can
be categorized into the following three usage models.
4.1. The pre-authentication model(Peer-CA-AAA)
In this type of pre-authentication model shown in Figure 2,
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 9]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Peer Candidate AAA Server
Authenticator
(CA)
+---------+ +---------------------+ +---------+
| | | EAP Auth- | | EAP |
|EAP Peer | | enticator | | Server |
| | | | | |
+---------+ +---------------------+ +---------+
|Peer-SA | |Peer-CA | |CA-AAA | |CA-AAA |
|Signaling<-->|Signaling| |Signaling|<--->Signaling|
|Layer | |Layer | |Layer | |Layer |
+---------+ +---------+ +---------+ +---------+
Figure 2: Pre-authentication Model(Peer-CA-AAA)
the serving authenticator does not involve in EAP exchange and only
forwards the EAP pre-authentication traffic as it would any other
data traffic or there may be no serving authenticator at all in the
serving access network. The candidate authenticator and the serving
authenticator may belong to the different AAA domain. An
intermediary AAA node such as a AAA proxy may also involve in the AAA
signaling between the candidate Authenticator and AAA/EAP server.
The pre-authentication signaling for the model (Peer-CA-AAA) is shown
in Figure 3.
Peer Serving Candidate AAA/EAP
Authenticator Authenticator Server
(SA) (CA)
| | | |
| | | |
| Peer-CA Signaling (L3) | AAA |
|<------------------+------------------->|<----------------->|
| | | |
| | | |
Figure 3: Pre-authentication for the model(Peer,CA,AAA)
[I-D.ietf-pana-preauth] is identified as a protocol to realize direct
pre-authentication.
4.2. The Pre-authentication model(Peer-SA-CA-AAA)
The Pre-authentication model(Peer-SA-CA-AAA) is illustrated in
Figure 4.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 10]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Peer Serving Candidate AAA Server
Authenticator Authenticator
(SA) (CA)
+----------+ +--------------------+ +------+
| <- - - - - - - - - - - - - ->| <->| |
| EAP Peer | +--------------------| | EAP Auth- | |EAP |
| | |Pre-authentication | | enticator | |Server|
| | |Forwarding | | | | |
+----------+ +---------++---------| +--------------------+ +------+
| Peer-SA | |Peer-SA ||SA-CA | |SA-CA ||CA-AAA | |CA-AAA|
| Signaling<-->|Signaling||Signaling<-->|Signaling||Signaling<-->Signa-|
| Layer | |Layer ||Layer | |Layer ||Layer | |ling |
+----------+ +---------++---------+ +---------++---------+ |Layer |
+------+
Figure 4: Pre-authentication Model (Peer-SA-CA-AAA)
In this pre-authentication model(Peer-SA-CA-AAA), it is assumed that
a trust relationship exists between the serving network (or serving
AAA domain) and candidate network (or candidate AAA domain). The
candidate authenticator and the serving authenticator may belong to
the different AAA domain. An intermediary AAA node such as a AAA
proxy may also involve in the AAA signaling between the candidate
Authenticator and AAA/EAP server. The serving authenticator is
involved in EAP pre-authentication signaling. This pre-
authentication model is needed if the peer cannot discover the
candidate authenticator's IP address or if IP communication is not
available due to security or network topology reasons.
The role of the serving authenticator in this pre-authentication
model is to forward EAP pre-authentication signaling between the peer
and the candidate authenticator and not to act as an authenticator,
while it acts as an authenticator for normal authentication
signaling.
The pre-authentication signaling for this model is shown in Figure 5
.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 11]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Peer Serving Candidate AAA/EAP
Authenticator Authenticator Server
(SA) (CA)
| | | |
| | | |
| Peer-SA Signaling | SA-CA Signaling | AAA |
| (L2 or L3) | (L3) | |
|<----------------->|<------------------>|<----------------->|
| | | |
| | | |
Figure 5: Pre-authentication for the model(Peer-SA-CA-AAA)
In this model, the pre-authentication signaling between a peer and a
candidate authenticator consists of peer to serving authenticator
signaling (Peer-SA signaling) and serving authenticator to candidate
authenticator signaling (SA-CA signaling).
SA-CA signaling is performed over L3.
Peer-SA signaling is performed over L2 or L3.
4.3. The Pre-authentication model(Peer-SA-AAA-CA)
The Pre-authentication model(Peer-SA-AAA-CA) is illustrated in
Figure 6.
Peer Serving AAA Server Candidate
Authenticator Authenticator
(SA) (CA)
+---------+ +--------------------+ +--------------------+ + ---------+
| | | | | | | |
|EAP Peer | | EAP Auth- | | EAP | | EAP Auth-|
| | | enticator | | Server | | enticator|
+---------+ +--------------------+ +--------------------+ + ---------+
|Peer-SA | |Peer-SA ||SA-AAA | |SA-AAA ||CA-AAA | | CA-AAA |
|Signaling<->|Signaling||Signaling<->|Signaling||Signaling<-> Signaling|
|Layer | |Layer ||Layer | |Layer ||Layer | | Layer |
+---------+ +---------++---------+ +---------++---------+ + ---------+
Figure 6: Pre-authentication Model(Peer-SA-AAA-CA)
In this pre-authentication model(Peer-SA-AAA-CA), it is assumed that
there is no trust relationship between the serving authenticator (or
serving AAA domain) and the candidate authenticator (or candidate AAA
domain). The serving authenticator is involved in EAP pre-
authentication signaling. The candidate authenticator and the
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 12]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
serving authenticator may belong to the different AAA domain. An
intermediary AAA node such as a AAA proxy may also involve in the AAA
signaling between the candidate Authenticator and AAA/EAP server.
The role of the serving authenticator in this pre-authentication
model is to perform the pre-authentication signaling between the peer
and EAP server on behalf of the candidate authenticator and act as an
authenticator. The pre-authentication signaling is different from
the normal authentication signaling associated with the serving
authenticator. The Peer-SA signaling is performed over L2 or L3.
5. Architectural Considerations
There are two architectural issues relating to pre-authentication:
authenticator discovery and context binding.
5.1. Authenticator Discovery
In general, pre-authentication requires an address of a candidate
authenticator to be discovered either by a peer or by a serving
authenticator or some other entity prior to handover. An
authenticator discovery protocol is typically defined as a separate
protocol from a pre-authentication protocol. For both intra-domain
and inter-domain handover, the IP address of a candidate
authenticator must be reachable by the peer or the serving
authenticator that is performing the pre-authentication. For
example, IEEE 802.21 Information Service (IS) [802.21] provides a
link layer independent mechanism for obtaining neighboring network
information by defining a set of Information Elements (IEs), where
one of the IEs is defined to contain an IP address of a point of
attachment. IEEE 802.21 IS queries for such an IE may be used as a
method for authenticator discovery.
If IEEE 802.21 IS or a similar mechanism is used, an authenticator
discovery requires a database on the neighboring network information.
Provisioning of a server with such a database is another issue.
5.2. Context Binding
When a candidate authenticator uses different EAP transport protocols
for normal authentication and pre-authentication, a mechanism is
needed to bind link layer independent context carried over pre-
authentication signaling to the link layer specific context of the
link to be established between the peer and the candidate
authenticator. The link layer independent context includes the
identities of the peer and authenticator as well as the MSK. The
link layer specific context includes link layer addresses of the peer
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 13]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
and the candidate authenticator. Such context binding can happen
before or after the peer changes its point of attachment.
There are at least two possible approaches to address the context
binding issue. The first approach is based on communicating the link
layer context as opaque data via pre-authentication signaling. The
second approach is based on running EAP over the link layer of the
candidate authenticator after the peer arrives at the authenticator
using short-term credentials generated via pre-authentication. In
this case, the short-term credentials are shared between the peer and
the candidate authenticator, where the candidate authenticator is
also the EAP server for the EAP method execution performed after the
peer arrives at the target authenticator resides in the
authenticator. In both approaches, context binding needs to be
securely made between the peer and the candidate authenticator.
Also, the peer is not fully authorized by the candidate authenticator
until the peer completes the link layer specific secure association
procedure with the authenticator using the link layer signaling.
6. AAA Issues
Most of the AAA documents today do not distinguish between a normal
authentication and a pre-authentication and this creates a set of
open issues:
Pre-authentication authorization: Many users may not be allowed to
have more than one logon session at the time. This means that
when such users actively engage in an active session (as a result
of a previously valid authentication), they will not be able to
perform pre-authentication. The AAA server currently has no way
of distinguishing between a normal authentication request and a
pre-authentication request.
Pre-authentication lifetime: Currently AAA protocols define
attributes carrying lifetime information for a normal
authentication session. Even when a user profile and the AAA
server supports pre-authentication, the lifetime for a pre-
authentication session is typically valid only for a short amount
of time because the peer has not completed its authentication at
the target link layer. It is currently not possible for a AAA
server to indicate to the AAA client or a peer the lifetime of the
pre-authenticated session unless AAA protocols are extended to
carry pre-authentication session lifetime information. In other
words, it is not clear to the peer or the authenticator when the
pre-authentication session will expire.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 14]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Pre-authentication retries: It is typically expected that shortly
following the pre-authentication process, the peer moves to the
new point of attachment and converts the pre-authentication state
to a normal authentication state (the procedure for which is not
the topic of this particular subsection). However, if the peer
has not yet moved to the new location and realizes that the pre-
authentication is expiring, it may perform another pre-
authentication. Some limiting mechanism is needed to avoid
unlimited number of pre-authentication tries.
Completion of network attachment: Once the peer has successfully
attached to the new point of attachment, it needs to convert its
authentication state from pre-authenticated to fully attached and
authorized. There may need to be a mechanism within the AAA
protocol to provide this indication to the AAA server if the AAA
server needs to differentiate between pre-authentication and
normal authentication. This is important from billing perspective
where the billing policy does not charge for a pre-authenticated
peer until the peer is fully attached to the target authenticator.
Session Resumption: In case the peer cycles between a network N1
with which it has a normal authentication state to another network
N2 and then back to N1, it should be possible to simply convert
the full authentication state to a pre-authenticated state. The
problems around handling session lifetime and keying material
caching need to be dealt with.
Multiple candidate authenticators: There may be situations where
the peer may need to make a selection between a number of
candidate authenticators. In such cases, it is desirable for the
peer to perform pre-authentication with multiple candidate
authenticators. In such cases the AAA server may need to be aware
of the situation.
Inter-AAA-domain handover support: There may be situations where the
peer moves across different visited AAA domains, in such cases,
the EAP Pre-authentication with the EAP server in the home AAA
domain should be performed through the visited AAA domains. It
requires the identity information of visited AAA domain and the
home AAA domain to be discovered by the peer or the candidate
authenticator for routing the EAP pre-authentication traffic. The
keying materials may be generated based on the identity
information of visited AAA domain for securing the EAP exchange
between the peer and the visited AAA domain.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 15]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Inter-technology support: Current specifications on pre-
authentication mostly deal with homogeneous 802.11 networks. The
AAA attributes such as Calling-Station-ID [I-D.aboba-radext-wlan]
may need to be expanded to cover other access technologies.
Furthermore, inter-technology handovers may require a change of
the peer identifier as part of the handover. Investigation on the
best type of identifiers for peers that support multiple access
technologies is required.
7. Security Considerations
This section specifically covers threats introduced to the EAP model
by pre-authentication. Security issues on general EAP and handover
are described in other documents such as [RFC3748], [RFC4962],
[RFC5169] and [RFC5247].
Since pre-authentication described in this document needs to work
across multiple authenticators, any solution needs to consider the
following security threats.
First, a resource consumption denial of service attack is possible,
where an attacker that is not on the same IP link as the legitimate
peer or the candidate authenticator may send unprotected pre-
authentication messages to the legitimate peer or the candidate
authenticator. As a result, they may spend their computational and
bandwidth resources on processing pre-authentication messages sent by
the attacker. This attack is possible for both direct and indirect
pre-authentication scenarios. To mitigate this attack, the candidate
network or authenticator may apply non-cryptographic packet filtering
so that pre-authentication messages received from only a specific set
of serving networks or authenticators are processed. In addition, a
simple solution for the peer side would be to let the peer always
initiate EAP pre-authentication and not allow EAP pre-authentication
initiation from an authenticator.
Second, consideration for the Channel Binding problem described in
[RFC5247] is needed as lack of Channel Binding may enable an
authenticator to impersonate another authenticator or communicate
incorrect information via out-of-band mechanisms (such as via a AAA
or lower layer protocol) [RFC3748]. It should be noted that it is
relatively easier to launch such an impersonation attack for pre-
authentication than normal authentication because an attacker does
not need to be physically on the same link as the legitimate peer to
send a pre-authentication trigger to the peer.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 16]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
8. IANA Considerations
This document has no actions for IANA.
9. Acknowledgments
The authors would like to thank Bernard Aboba, Jari Arkko, Ajay
Rajkumar, Maryna Komarova, Charles Clancy, Glen Zorn, Subir Das,
Shubhranshu Singh, Preetida Vinayakray and Rafa Marin Lopez for their
valuable input.
10. Contributors
The following people contributed to this document.
Yoshihiro Ohba (yohba@tari.toshiba.com)
Ashutosh Dutta (adutta@research.telcordia.com)
Srinivas Sreemanthula (srinivas.sreemanthula@nokia.com)
Alper E. Yegin (alper.yegin@yegin.org)
Madjid Nakhjiri (madjid.nakhjiri@motorola.com)
Mahalingam Mani (mmani@avaya.com)
11. References
11.1. Normative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 17]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
11.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
authentication Protocol (ERP)", RFC 5296, August 2008.
[I-D.aboba-radext-wlan]
Aboba, B., Malinen, J., Congdon, P., and J. Salowey,
"RADIUS Attributes for IEEE 802 Networks",
draft-aboba-radext-wlan-09 (work in progress),
October 2008.
[I-D.ietf-pana-preauth]
Ohba, Y., "Pre-authentication Support for PANA",
draft-ietf-pana-preauth-04 (work in progress),
December 2008.
[802.21] IEEE, "Draft Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services", LAN MAN
Standards Committee of the IEEE Computer Society
802.21 D11 2008.
[802.11] IEEE, "IEEE Standard for 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
Computer Society 2007.
[802.11r] IEEE, "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 - Amendment 2: Fast BSS
Transition", LAN MAN Standards Committee of the IEEE
Computer Society 802.11r D9.0 2008.
[802.11f] IEEE, "IEEE Trial-Use Recommended Practice for Multi-
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 18]
Internet-Draft EAP Pre-authentication Problem Statement March 2009
Vendor Access Point Interoperability via an Inter-Access
Point Protocol Across Distribution Systems Supporting IEEE
802.11 Operation", IEEE Computer Society 2003.
[ITU] ITU-T, "General Characteristics of International Telephone
Connections and International Telephone Circuits: One-Way
Transmission Time", ITU-T Recommendation G.114 1998.
[WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-
Fi WPA v3.1, 2004.
[MQ7] Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A.
Skarmeta, "Network-layer Assisted Mechanism to Optimize
Authentication Delay During Handoff in 802.11 Networks",
ACM Mobiquitous 2007.
[WCM] Dutta, A., Famorali, D., Das, S., Ohba, Y., and R. Lopez,
"Media-Independent Pre-Authentication Supporting Secure
Interdomain Handover Optimization Network-layer Assisted
Mechanism to Optimize", IEEE Wireless Communications April
2008.
Authors' Addresses
Qin Wu
Huawei Technologies Co.,Ltd
SiteB, Floor 12F,Huihong Mansion, No.91.,Baixia Rd.
Nanjing, JiangSu 210001
P.R C
Phone: +86 2584565892
Email: sunseawq@huawei.com
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Wu (Editor) & Ohba (Editor) Expires September 9, 2009 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 09:36:56 |