One document matched: draft-ietf-hokey-preauth-ps-12.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.aboba-radext-wlan PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.aboba-radext-wlan.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2828 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2828.xml">
<!ENTITY rfc2865 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY rfc3588 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY rfc3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc4306 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY rfc4962 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml">
<!ENTITY rfc5169 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5169.xml">
<!ENTITY rfc5247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc2989 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2989.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-hokey-preauth-ps-12" ipr="pre5378Trust200902">
<front>
<title abbrev="Early Authentication PS">Extensible Authentication Protocol
(EAP) Early Authentication Problem Statement</title>
<author fullname="Yoshihiro Ohba" initials="Y." role="editor"
surname="Ohba">
<organization abbrev="Toshiba">Toshiba America Research,
Inc.</organization>
<address>
<postal>
<street>1 Telcordia Drive</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08854</code>
<country>USA</country>
</postal>
<phone>+1 732 699-5365</phone>
<email>yohba@tari.toshiba.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." role="editor" surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co.,Ltd</organization>
<address>
<postal>
<street>SiteB, Floor 12F,Huihong Mansion, No.91.,Baixia Rd.</street>
<city>Nanjing</city>
<region>JiangSu</region>
<code>210001</code>
<country>China</country>
</postal>
<phone>+86 25 84565892</phone>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G." role="editor" surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>1463 East Republican Street,</street>
<city>Seattle</city>
<region>Washington</region>
<code>98112</code>
<country>USA</country>
</postal>
<email>gwz@net-zen.net</email>
</address>
</author>
<date year="2010" />
<abstract>
<t>Extensible Authentication Protocol (EAP)
early authentication may be defined as the use of EAP by a mobile
device to establish authenticated keying material on a target attachment
point prior to its arrival. This draft discusses the EAP early
authentication problem in detail.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When a mobile device, during an active communication session, moves
from one access network to another and changes its attachment point, the
session may be subjected to disruption of service due to the delay
associated with the handover operation. The performance requirements of
a real-time application will vary based on the type of application and
its characteristics such as delay and packet loss tolerance. For Voice over IP
applications, ITU-T G.114 <xref target="ITU"></xref> recommends a
steady-state end-to-end delay of 150 ms as the upper limit and rates 400
ms as generally unacceptable delay. Similarly, a streaming application
has tolerable packet error rates ranging from 0.1 to 0.00001 with a
transfer delay of less than 300 ms. Any help that an optimized handoff
mechanism can provide toward meeting these objectives is useful. The
ultimate objective is to achieve seamless handover with low latency,
even when handover is between different link technologies or between
different AAA realms. <vspace blankLines="1" /> 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 because of the additional round trips needed for a new EAP
exchange. Delays incurred within each protocol layer affect the ongoing
multimedia application and data traffic within the client <xref
target="WCM"></xref>. <vspace blankLines="1" /> The handover process
often requires authentication and authorization for acquisition or
modification of resources assigned to the mobile device. In most cases,
these authentication and authorization require interaction with a
central authority in a realm. In some cases the central authority may be
distant 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 <xref
target="MQ7"></xref> The discussion in this document is focused on
mitigating delay due to EAP authentication.</t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="AAA"><vspace blankLines="1"/>
Authentication, Authorization, and Accounting (see
below). RADIUS <xref target="RFC2865"></xref> and Diameter <xref
target="RFC3588"></xref> are examples of AAA protocols defined in the
IETF.</t>
<t hangText="AAA realm"><vspace blankLines="0" /> The set of access
networks within the scope of a specific AAA server. Thus, if a
mobile device moves from one attachment point to another within the
same AAA realm, it continues to be served by the same AAA server</t>
<t hangText="Accounting"><vspace blankLines="0" />The act of
collecting information on resource usage for the purpose of trend
analysis, auditing, billing, or cost allocation <xref
target="RFC2989"></xref>.</t>
<t hangText="Attachment Point"><vspace blankLines="0" /> A device,
such as a wireless access point, that serves as a gateway between
access clients and a network. In the context of this document, an
attachment point must also support EAP authenticator functionality
and may act as a AAA client. </t>
<t hangText="Authentication"><vspace blankLines="0" /> The act of
verifying a claimed identity, in the form of a pre- existing label
from a mutually known name space, as the originator of a message
(message authentication) or as the end-point of a channel (entity
authentication) <xref target="RFC2989"></xref>.</t>
<t hangText="Authenticator"><vspace blankLines="0" />The end of the
link initiating EAP authentication <xref
target="RFC3748"></xref>.</t>
<t hangText="Authorization"><vspace blankLines="0" /> The act of
determining if a particular right, such as access to some resource,
can be granted to the presenter of a particular credential <xref
target="RFC2989"></xref>.</t>
<t hangText="Candidate Access Network"><vspace blankLines="0" /> An
access network that can potentially become the target access network
for a mobile device. Multiple access networks may be candidates
simultaneously.</t>
<t hangText="Candidate Attachment Point "><vspace blankLines="0" />
An attachment point that can potentially become the target
attachment point for a mobile device. Multiple attachment points may
be candidates simultaneously.</t>
<t hangText="Candidate Authenticator "><vspace blankLines="0" />The
EAP authenticator on the CAP.</t>
<t hangText="EAP Server"><vspace blankLines="0" /> The entity that
terminates the EAP authentication method with the peer <xref
target="RFC3748"></xref>. EAP servers are often, but not
necessarily, co- located with AAA servers, using a AAA protocol to
communicate with remote pass-through authenticators.</t>
<t
hangText="Inter-AAA-realm Handover (Inter-realm Handover)"><vspace
blankLines="0" />A handover across multiple AAA realms.</t>
<t hangText="Inter-Technology Handover"><vspace blankLines="0" /> A
handover across different link layer technologies.</t>
<t
hangText="Intra-AAA-realm Handover (Intra-realm Handover)"><vspace
blankLines="0" /> A handover within the same AAA realm.
Intra-AAA-realm handover includes a handover across different
authenticators within the same AAA realm.</t>
<t hangText="Intra-Technology Handover"><vspace blankLines="0" /> A
handover within the same link layer technology.</t>
<t hangText="Master Session Key (MSK)"><vspace blankLines="0" />
Keying material that is derived between the EAP peer and server and
exported by the EAP method <xref target="RFC3748"></xref>.</t>
<t hangText="Peer"><vspace blankLines="0" />The entity that responds
to the authenticator and requires authentication<xref
target="RFC3748"></xref>.</t>
<t hangText="Serving Access Network"><vspace blankLines="0" />An
access network that is currently serving the mobile device.</t>
<t hangText="Serving Attachment Point (SAP)"><vspace
blankLines="0" />An attachment point that is currently serving the
mobile device.</t>
<t hangText="Target Access Network"><vspace blankLines="0" />An
access network that has been selected to be the new serving access
network for a mobile device.</t>
<t hangText="Target Attachment Point (TAP) "><vspace
blankLines="0" /> An attachment point that has been selected to be
the new SAP for a mobile device.</t>
</list></t>
</section>
<section anchor="PS" title="Problem Statement">
<t>The basic mechanism of handover is a two-step procedure involving</t>
<t><list hangIndent="" style="symbols">
<t>handover preparation and</t>
<t>handover execution</t>
</list></t>
<section title="Handover Preparation">
<t>Handover preparation includes the discovery of candidate attachment
points and selection of an appropriate target attachment point from
the candidate set. Handover preparation is outside the scope of this
document.</t>
</section>
<section title="Handover Execution">
<t>Handover execution consists of setting up Layer 2 (L2) and Layer 3
(L3) connectivity with the TAP. Currently, handover execution includes
network access authentication and authorization performed directly
with the target network; this may include full EAP authentication in
the absence of any particular optimization for handover key
management. Following a successful EAP authentication, a secure
association procedure is typically performed between the mobile device
and the TAP to derive a new set of link-layer encryption keys from EAP
keying material such as the MSK. The handover latency introduced by
full EAP authentication has proven to be higher than that which is
acceptable for real-time application scenarios <xref
target="MQ7"></xref>; hence, reduction in handover latency due to EAP
is a necessary objective for such scenarios.</t>
<section title="Examples">
<section title="IEEE 802.11">
<t>In IEEE 802.11 WLANs <xref target="IEEE.802-11.2007"></xref>
network access authentication and authorization involves
performing a new IEEE 802.1X <xref
target="IEEE.802-1X.2004"></xref> message exchange with the
authenticator in the TAP to execute an EAP exchange with the
authentication server <xref target="WPA"></xref>.There has been
some optimization work undertaken by the IEEE, but these efforts
have been scoped to IEEE link layer technologies; for example, the
work done in the IEEE 802.11f <xref
target="IEEE.802-11F.2003"></xref> and 802.11r <xref
target="IEEE.802-11R.2008"></xref> Task Groups applies only to
intra- technology handovers.</t>
</section>
<section title="3GPP TS33.402">
<t>3GPP Technical Specification 33.402 <xref
target="TS33.402"></xref>, defines the authentication and key
management procedures performed during interworking between
non-3GPP access networks and the Evolved Packet System (EPS).
Network access authentication and authorization happens after the
L2 connection is established between the mobile device and a
non-3GPP target access network, and involves an EAP exchange
between the mobile device and the 3GPP AAA server via the non-3GPP
target access network. These procedures are not really independent
of link technology, since they assume either that the
authenticator lies in the EPS network or that separate
authentications are performed in the access network and then in
the EPS network.</t>
</section>
</section>
</section>
<section title="Solution Space">
<t>As the examples in the preceding sections illustrate, a solution is
needed to enable EAP early authentication for inter-AAA-realm
handovers and inter-technology handovers. A search for solutions at
the IP level may offer the necessary technology independence.</t>
<t>Optimized solutions for secure inter-authenticator handovers can be
seen either as security context transfer (e.g., using the EAP
Extensions for EAP Re-authentication Protocol (ERP)) <xref
target="RFC5296"></xref>, or as EAP early authentication.</t>
<section title="Context Transfer">
<t>Security context transfer involves transfer of reusable key
context to the TAP and can take two forms: horizontal and vertical.</t>
<t>Horizontal security context transfer (e.g., from SAP to TAP) is
not recommended because of the possibility that the compromise of
one attachment point might lead to the compromise of another (the
so- called Domino effect, <xref target="RFC4962"></xref>). Vertical
context transfer is similar to the initial establishment of keying
material on an attachment point in that the keys are sent from a
trusted server to the TAP as a direct result of a successful
authentication. ERP specifies vertical context transfer using
existing EAP keying material obtained from the home AAA server
during the initial authentication. A cryptographically independent
re-authentication key is derived and transmitted to the TAP as a
result of successful ERP authentication. This reduces handover delay
for intra-realm handovers by eliminating the need to run full EAP
authentication with the home EAP server.</t>
<t>However, in the case of inter-realm handover, ERP is either not
applicable or an additional optimization mechanism is needed to
establish a key on the TAP.</t>
</section>
<section title="Early Authentication">
<t>In EAP early authentication, AAA-based authentication and
authorization for a CAP is performed while ongoing data
communication is in progress via the serving access network, the
goal being to complete AAA signaling for EAP before the mobile
device moves. The applicability of EAP early authentication is
limited to the scenarios where candidate authenticators can be
discovered and an accurate prediction of movement can be easily
made. In addition, the effectiveness of EAP early authentication may
be less significant for particular inter-technology handover
scenarios where simultaneous use of multiple technologies is not a
major concern.</t>
<t>There are also several AAA issues related to EAP early
authentication, discussed in <xref
target="section-aaa-issues"></xref>.</t>
</section>
</section>
</section>
<section title="System Overview">
<t><xref target="figure-earlyauth"></xref> shows the functional elements
that are related to EAP early authentication. These functional elements
include a mobile device, a SAP, a CAP and one or more AAA and EAP
servers; for the sake of convenience, the AAA and EAP servers are
represented as being co- located. When the SAP and CAP belong to
different AAA realms, the CAP may require a different set of user
credentials than those used by the peer when authenticating to the SAP.
Alternatively, the CAP and the SAP may rely on the same AAA server,
located in the home realm of the mobile device (MD).</t>
<figure align="center" anchor="figure-earlyauth"
title="EAP Early Authentication Functional Elements">
<artwork>
+------+ +-------+ +---------+ +---------+
| MD |------| SAP |------| | | |
+------+ +-------+ | IP | | EAP/AAA
. | |------| |
. Move | Network | | Server |
v +-------+ | | | |
| CAP |------| | | |
+-------+ +---------+ +---------+
</artwork>
</figure>
<t>A mobile device is attached to the serving access network. Before the
MD performs handover from the serving access network to a candidate
access network, it performs EAP early authentication with a candidate
authenticator via the serving access network. The peer may perform EAP
early authentication with one or more candidate authenticators. It is
assumed that each attachment point has an IP address. It is assumed that
there is at least one CAP in each candidate access network. The serving
and candidate access networks may use different link layer
technologies.</t>
<t>Each authenticator is either a standalone authenticator or pass-
through authenticator <xref target="RFC3748"></xref>. 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 using a AAA transport protocol such as RADIUS <xref
target="RFC2865"></xref> or Diameter <xref target="RFC3588"></xref>.</t>
<t>If the CAP uses an MSK <xref target="RFC5247"></xref> for generating
lower-layer ciphering keys, EAP early authentication is used to
proactively generate an MSK for the CAP.</t>
</section>
<section anchor="TopClass"
title="Topological Classification of Handover Scenarios">
<t>The complexity of the authentication and authorization part of
handover depends on whether it involves a change in EAP Server. Consider
first the case where the authenticators operate in pass- through mode,
so that the EAP Server is co-located with a AAA server. Then there is a
strict hierarchy of complexity, as follows:<list style="numbers">
<t>inter-attachment-point handover with common AAA server: the CAP
and SAP are different entities, but the AAA server is the same.
There are two sub-cases here:<list style="format (%c)">
<t>the AAA server is common because both attachment points lie
within the same network, or</t>
<t>the AAA server is common because AAA entities in the serving
and candidate networks proxy to a AAA server in the home
realm.</t>
</list></t>
<t>inter-AAA-realm handover: the CAP and SAP are different entities,
and the respective AAA servers also differ. As a result,
authentication in the candidate network requires a second set of
user credentials.</t>
</list></t>
<t>A third case is where one or both authenticators are co-located with
an EAP server. This has some of the characteristics of an inter-AAA-
realm handover, but offers less flexibility for resolution of the early
authentication problem.</t>
<t>Orthogonally to this classification, one can distinguish intra-
technology handover from inter-technology handover, thinking of the link
technologies involved. In the inter-technology case, it is highly
probable that the authenticators will differ. The most likely cases are
1(b) or 2 in the above list.</t>
</section>
<section title="Models of Early Authentication">
<t>As noted in <xref target="PS"></xref>, there are cases where early
authentication is applicable while ERP does not work. This section
concentrates on providing some models around which we can build our
analysis of the EAP early authentication problem. Different usage models
can be defined depending on whether<list style="symbols">
<t>the SAP is not involved in early authentication (direct pre-
authentication usage model),</t>
<t>the SAP interacts only with the CAP (indirect pre-authentication
usage model), or</t>
<t>the SAP interacts with the AAA server (the authenticated
anticipatory keying usage model).</t>
</list>It is assumed that the CAP and SAP are different entities. It
is further assumed in describing these models that there is no direct L2
connectivity between the peer and the candidate attachment point.</t>
<section title="EAP Pre-authentication Usage Models">
<t>In the EAP pre-authentication model, the SAP does not interact with
the AAA server directly. Depending on how the SAP is involved in the
pre-authentication signaling, the EAP pre-authentication usage model
can be further categorized into the following two sub-models, direct
and indirect.</t>
<section title="The Direct Pre-authentication Model">
<t>In this model, the SAP is not involved in the EAP exchange and
only forwards the EAP pre-authentication traffic as it would any
other data traffic. The direct pre-authentication model is based on
the assumption that the MD can discover candidate authenticators and
establish direct IP communication with them. It is applicable to any
of the cases described in <xref target="TopClass"></xref>.
<vspace blankLines="1" />
<figure align="center"
anchor="figure-model-Peer-CA-AAA"
title="Direct Pre-authentication Usage Model">
<artwork> <![CDATA[
Mobile Candidate Attachment AAA Server
Device Point(CAP)
+-----------+ +-------------------------+ +------------+
| | | Candidate | | |
| Peer | | Authenticator | | EAP Server |
| | | | | |
+-----------+ +-------------------------+ +------------+
| MD-CAP |<-->| MD-CAP | | CAP-AAA |<-->| CAP-AAA |
| Signaling | | Signaling | | Signaling | | Signaling |
+-----------+ +-----------+ +-----------+ +------------+
]]></artwork>
</figure>
The direct pre-authentication signaling for the usage
model is shown in <xref
target="figure-signaling-Peer-CA-AAA"></xref>.</t>
<figure align="center" anchor="figure-signaling-Peer-CA-AAA"
title="Direct Pre-authentication Signaling for the Usage Model">
<artwork><![CDATA[
Mobile Serving Candidate AAA/EAP
Device Attachment Point Authenticator Server
(SAP)
| | | |
| | | |
| EAP over MD-CAP Signaling (L3) | EAP over AAA |
|<------------------+------------------->|<----------------->|
| | | |
| | | |
]]></artwork>
</figure>
</section>
<section title="The Indirect Pre-authentication Usage Model">
<t>The indirect pre-authentication usage model is illustrated in
<xref target="figure-model-Peer-SA-CA-AAA"></xref>.</t>
<figure align="center" anchor="figure-model-Peer-SA-CA-AAA"
title="Indirect Pre-authentication Usage Model">
<artwork><![CDATA[
Mobile Serving Candidate AAA
Device Attachment Point Attachment Point Server
(SAP) (CAP)
+----------+ +----------------+ +--------+
| | | | | |
| EAP Peer | | Candidate | | EAP |
| | | Authenticator | | Server |
| | | | | |
+----------+ +---------+------+ +-------+--------+ +--------+
| Peer-SA |<->| Peer-SA |SA-CA |<->| SA-CA | CA-AAA |<->| CA-AAA |
+----------+ +---------+------+ +-------+--------+ +--------+
{-----------------------------Signaling---------------------------}
]]></artwork>
</figure>
<t>In the indirect pre-authentication model, it is assumed that a
trust relationship exists between the serving network (or serving
AAA realm) and candidate network (or candidate AAA realm). The SAP
is involved in EAP pre-authentication signaling. This pre-
authentication model is needed if the peer cannot discover the
candidate authenticators identity or if direct IP communication
between the MD and CAP is not possible due to security or network
topology issues.<vspace blankLines="1" />The role of the SAP in this
pre-authentication model is to forward EAP pre-authentication
signaling between the mobile device and CAP; the role of the CAP is
to forward EAP pre-authentication signaling between the peer (via
the SAP) and EAP server and receive the transported keying
material.<vspace blankLines="1" /> The pre-authentication signaling
for this model is shown in <xref
target="figure-signaling-Peer-SA-CA-AAA"></xref>.</t>
<figure align="center" anchor="figure-signaling-Peer-SA-CA-AAA"
title="Indirect Pre-authentication Signaling for the Usage Model">
<artwork><![CDATA[
Mobile Serving Candidate AAA/EAP
Device Attachment Point Attachment Point Server
(SAP) (CAP)
| | | |
| EAP over | EAP over | EAP over AAA |
| MD-SAP Signaling | SAP-CAP Signaling | |
| (L2 or L3) | (L3) | |
|<----------------->|<------------------<|<----------------->|
| | | |
| | | |
]]></artwork>
</figure>
<t>In this model, the pre-authentication signaling path between a
peer and a candidate authenticator consists of two segments: peer to
SAP signaling (over L2 or L3) and SAP to CAP signaling over L3.</t>
</section>
</section>
<section title="The Authenticated Anticipatory Keying Usage Model">
<t>In this model, it is assumed that there is no trust relationship
between the SAP and the CAP and the SAP is required to interact with
the AAA server directly. The authenticated anticipatory keying usage
model is illustrated in <xref
target="figure-model-Peer-SA-AAA-CA"></xref>.</t>
<figure align="center" anchor="figure-model-Peer-SA-AAA-CA"
title="Authenticated Anticipatory Keying Usage Model">
<artwork><![CDATA[
Mobile Serving AAA Server Candidate
Device Attachment Point Attachment
(SAP) Point (CAP)
+---------+ +------------------+ +-----------------+ +--------+
| | | | | | | |
| Peer | | Authenticator | | EAP Server | | AAA |
| | | | | | | Client |
+---------+ +------------------+ +-----------------+ +--------+
| Peer-SA |<->| Peer-SA | SA-AAA |<->| SA-AAA | CA-AAA |<>| CA-AAA |
+---------+ +------------------+ +--------+--------+ +--------+
{------------------------------Signaling---------------------------}
]]></artwork>
</figure>
<t>The SAP is involved in EAP authenticated anticipatory keying
signaling.<vspace blankLines="1" /> The role of the serving attachment
point in this usage model is to communicate with the peer on one side
and exchange authenticated anticipatory keying signaling with the EAP
server on the other side. The role of the candidate authenticator is
to receive the transported keying materials from the EAP server and to
act as the serving attachment point after handover occurs. The Peer-SA
signaling is performed over L2 or L3; the SA-AAA and AAA-CA segments
operate over L3.</t>
</section>
</section>
<section title="Architectural Considerations">
<t>There are two architectural issues relating to early authentication:
authenticator discovery and context binding.</t>
<section title="Authenticator Discovery">
<t>In general, early authentication requires the identity of a
candidate attachment point to be discovered by a peer, by a serving
attachment point, or by some other entity prior to handover. An
attachment point discovery protocol is typically defined as a separate
protocol from an early authentication protocol. For example, the IEEE
802.21 Information Service (IS) <xref target="IEEE.802-21"></xref>
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
attachment point. IEEE 802.21 IS queries for such an IE may be used as
a method for authenticator discovery. <vspace blankLines="1" /> If
IEEE 802.21 IS or a similar mechanism is used, authenticator discovery
requires a database of information regarding the target network; the
provisioning of a server with such a database is another issue.</t>
</section>
<section title="Context Binding">
<t>When a candidate authenticator uses different EAP transport
protocols for normal authentication and early authentication, a
mechanism is needed to bind link-layer-independent context carried
over early 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
and the candidate authenticator. Such context binding can happen
before or after the peer changes its point of attachment.<vspace
blankLines="1" /> 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 early
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 early authentication. In this case, the short-term credentials are
shared between the peer and the candidate 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 link layer signaling.</t>
</section>
</section>
<section anchor="section-aaa-issues" title="AAA Issues">
<t>Most of the AAA documents today do not distinguish between a normal
authentication and an early authentication and this creates a set of
open issues:<list style="hanging">
<t hangText="Early authentication authorization"><vspace
blankLines="0" /> Users may not be allowed to have more than one
logon session at the time. This means that while such users actively
engage in a session (as a result of a previously valid
authentication), they will not be able to perform early
authentication. The AAA server currently has no way of
distinguishing between a normal authentication request and an early
authentication request.</t>
<t hangText="Early authentication lifetime"><vspace
blankLines="0" /> Currently, AAA protocols define attributes
carrying lifetime information for a normal authentication session.
Even when a user profile and the AAA server support early
authentication, the lifetime for an early 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 early authenticated session
unless AAA protocols are extended to carry early authentication
session lifetime information. In other words, it is not clear to the
peer or the authenticator when the early authentication session will
expire.</t>
<t hangText="Early authentication retries"><vspace blankLines="0" />
It is typically expected that shortly following the early
authentication process, the peer moves to the new point of
attachment and converts the early 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 early authentication
session is expiring, it may perform another early authentication.
Some limiting mechanism is needed to avoid an unlimited number of
early-authentication attempts.</t>
<t hangText="Completion of network attachment"><vspace
blankLines="0" /> Once the peer has successfully attached to the new
point of attachment, it needs to convert its authentication state
from early authenticated to fully attached and authorized. If the
AAA server needs to differentiate between early authentication and
normal authentication, there may need to be a mechanism within the
AAA protocol to provide this indication to the AAA server. This may
be important from a billing perspective if the billing policy does
not charge for an early authenticated peer until the peer is fully
attached to the target authenticator.</t>
<t hangText="Session resumption"><vspace blankLines="0" /> In the
case where the peer cycles between a network N1 with which it has
fully authenticated to another network N2 and then back to N1, it
should be possible to simply convert the fully authenticated state
on N1 to an early authenticated state. The problems around handling
session lifetime and keying material caching need to be dealt
with.</t>
<t hangText="Multiple candidate attachment points"><vspace
blankLines="0" /> There may be situations where the peer needs to
choose from among a number of CAPs. In such cases, it is desirable
for the peer to perform early authentication with multiple candidate
authenticators. This amplifies the difficulties noted under the
point "Early authentication authorization".</t>
<t hangText="Inter-AAA-realm handover support"><vspace
blankLines="0" /> There may be situations where the peer moves out
of the home AAA realm or across different visited AAA realms. In
such cases, the early authentication should be performed through the
visited AAA realm with the AAA server in the home AAA realm. It also
requires AAA in the visited realm to acquire the identity
information of the home AAA realms for routing the EAP early
authentication traffic. Knowledge of realm identities is required by
both the peer and AAA to generate the early authentication key for
mutual authentication between the peer and the visited AAA
server.</t>
<t hangText="Inter-technology support"><vspace blankLines="0" />
Current specifications on early authentication mostly deal with
homogeneous 802.11 networks. AAA attributes such as Calling-
Station-ID <xref target="I-D.aboba-radext-wlan"></xref> 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.</t>
</list></t>
</section>
<section anchor="sec-security-cons" title="Security Considerations">
<t>This section specifically covers threats introduced to the EAP model
by early authentication. Security issues on general EAP and handover are
described in other documents such as RFC 3748 <xref
target="RFC3748"></xref>, RFC 4962 <xref target="RFC4962"></xref>,
RFC5169 <xref target="RFC5169"></xref> and RFC5247 <xref
target="RFC5247"></xref>. <vspace blankLines="1" /> Since early
authentication as described in this document needs to work across
multiple attachment points, any solution needs to consider the following
security threats.<vspace blankLines="1" /> 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 early authentication messages to the legitimate
peer or the candidate authenticator. As a result, the latter may spend
computational and bandwidth resources on processing early authentication
messages sent by the attacker. This attack is possible in both the
direct and indirect pre-authentication scenarios. To mitigate this
attack, the candidate network or authenticator may apply
non-cryptographic packet filtering so that only early authentication
messages received from 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 early
authentication and not allow EAP early authentication initiation from an
authenticator. <vspace blankLines="1" />Second, consideration for the
channel binding problem described in <xref target="RFC5247"></xref> 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)
<xref target="RFC3748"></xref>. It should be noted that it is relatively
easier to launch such an impersonation attack for early authentication
than normal authentication because an attacker does not need to be
physically on the same link as the legitimate peer to send an early
authentication trigger to the peer.</t>
</section>
<section title="IANA Considerations">
<t>This document makes no requests for IANA action.</t>
</section>
<section title="Acknowledgments">
<t>The editors would like to thank Preetida Vinayakray, Shubhranshu
Singh, Ajay Rajkumar, Rafa Marin Lopez, Jong-Hyouk Lee, Maryna Komarova,
Katrin Hoeper, Subir Das, Charles Clancy, Jari Arkko, and Bernard Aboba
for their valuable input.</t>
</section>
<section title="Contributors">
<t>The following people all contributed to this document: Alper E.
Yegin, Tom Taylor, Srinivas Sreemanthula, Madjid Nakhjiri, Mahalingam
Mani and Ashutosh Dutta.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3748;
&rfc4962;
&rfc5247;
</references>
<references title="Informative References">
&rfc2865;
&rfc3588;
&rfc5169;
&rfc5296;
&I-D.aboba-radext-wlan;
&rfc2989;
<reference anchor="IEEE.802-1X.2004" target="">
<front>
<title>Port-Based Network Access Control</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date year="2004" />
</front>
<seriesInfo name="IEEE" value="Standard 802.1X" />
</reference>
<reference anchor="IEEE.802-21" target="">
<front>
<title>Draft Standard for Local and Metropolitan Area Networks:Media
Independent Handover Services</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="IEEE" value="Draft Standard 802.21" />
</reference>
<reference anchor="IEEE.802-11.2007">
<front>
<title>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</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2007" />
</front>
<seriesInfo name="IEEE" value="Standard 802.11" />
<format type="PDF" target="http://standards.ieee.org/getieee802/download/802.11-2007.pdf"/>
</reference>
<reference anchor="IEEE.802-11R.2008">
<front>
<title>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</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="IEEE" value="Standard 802.11R" />
<format type="PDF" target="http://standards.ieee.org/getieee802/download/802.11r-2008.pdf"/>
</reference>
<reference anchor="IEEE.802-11F.2003">
<front>
<title>IEEE Trial-Use Recommended Practice for Multi-Vendor Access
Point Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date year="2003" />
</front>
<seriesInfo name="IEEE" value="Recommendation 802.11F" />
<format type="PDF" target="http://standards.ieee.org/getieee802/download/802.11F-2003.pdf"/>
</reference>
<reference anchor="TS33.402">
<front>
<title>System Architecture Evolution (SAE):Security aspects of
non-3GPP accesses (Release 8)</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2009" />
</front>
<seriesInfo name="3GPP TS33.402" value="V8.3.1" />
</reference>
<reference anchor="ITU">
<front>
<title>General Characteristics of International Telephone
Connections and International Telephone Circuits: One-Way
Transmission Time</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="1998" />
</front>
<seriesInfo name="ITU-T Recommendation" value="G.114" />
</reference>
<!--
<reference anchor='ETSI'>
<front>
<title>
Telecommunications and Internet Protocol Harmonization
Over Networks (TIPHON) Release 3: End-to-end Quality of
Service in TIPHON systems; Part 1: General aspects of
Quality of Service.
</title>
<author>
<organization>
ETSI
</organization>
</author>
</front>
<seriesInfo name="ETSI TR 101 329-6" value="V2.1.1" />
</reference>
-->
<reference anchor="WPA">
<front>
<title>WPA (Wi-Fi Protected Access)</title>
<author>
<organization>The Wi-Fi Alliance</organization>
</author>
<date year="2004" />
</front>
<seriesInfo name="Wi-Fi" value="WPA v3.1" />
</reference>
<reference anchor="MQ7">
<front>
<title>Network-layer Assisted Mechanism to Optimize Authentication
Delay During Handoff in 802.11 Networks</title>
<author initials="R." surname="Lopez">
<organization></organization>
</author>
<author initials="A." surname="Dutta">
<organization></organization>
</author>
<author initials="Y." surname="Ohba">
<organization></organization>
</author>
<author initials="H." surname="Schulzrinne">
<organization></organization>
</author>
<author initials="A." surname="Skarmeta">
<organization></organization>
</author>
<date year="2007" />
</front>
<seriesInfo name="The 4th Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services"
value="(MOBIQUITOUS 2007)" />
</reference>
<reference anchor="WCM">
<front>
<title>Media-independent pre-authentication supporting secure
interdomain handover optimization</title>
<author initials="A." surname="Dutta">
<organization></organization>
</author>
<author initials="D." surname="Famorali">
<organization></organization>
</author>
<author initials="S." surname="Das">
<organization></organization>
</author>
<author initials="Y." surname="Ohba">
<organization></organization>
</author>
<author initials="R." surname="Lopez">
<organization></organization>
</author>
<date month="April" year="2008" />
</front>
<seriesInfo name="IEEE Wireless Communications"
value="Volume 15, Issue 2" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:45:46 |