One document matched: draft-ietf-hokey-rfc5296bis-04.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 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 rfc5295 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc5749 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5749.xml">
<!ENTITY rfc5836 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5836.xml">
<!ENTITY rfc5873 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5873.xml">
<!ENTITY I-D.ietf-hokey-erp-aak PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-erp-aak.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-hokey-arch-design-04"
ipr="trust200902">
<front>
<title abbrev="HOKEY Architecture Design">Handover Keying (HOKEY)
Architecture Design</title>
<author fullname="Glen Zorn" initials="G." role="editor" surname="Zorn">
<organization abbrev="Network Zen">Network Zen</organization>
<address>
<postal>
<street>227/358 Thanon Sanphawut</street>
<city>Bang Na</city>
<region>Bangkok</region>
<code>10260</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87-040617</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co.,Ltd</organization>
<address>
<postal>
<street>Site B, 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="Tom Taylor" initials="T." surname="Taylor">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<country>Canada</country>
</postal>
<email>tom111.taylor@bell.net</email>
</address>
</author>
<author fullname="Katrin Hoeper" initials="K." surname="Hoeper">
<organization abbrev="Motorola">Motorola, Inc.</organization>
<address>
<postal>
<street>1301 E. Algonquin Road</street>
<city>Schaumburg</city>
<region>IL</region>
<code>60196</code>
<country>USA</country>
</postal>
<email>khoeper@motorola.com</email>
</address>
</author>
<author fullname="Sebastien Decugis" initials="S." surname="Decugis">
<organization>Free Diameter</organization>
<address>
<postal>
<street>4-2-1 Nukui-Kitamachi</street>
<city>Tokyo</city>
<region>Koganei</region>
<code>184-8795</code>
<country>Japan</country>
</postal>
<email>sdecugis@freediameter.net</email>
</address>
</author>
<author fullname="Yoav Nir" initials="Y." surname="Nir">
<organization>Check Point</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<region>Tel Aviv</region>
<code>67897</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<date year="2011" />
<workgroup>Network Working Group</workgroup>
<abstract>
<t>The Handover Keying (HOKEY) Working Group seeks to minimize handover
delay due to authentication when a peer moves from one point of
attachment to another. Work has progressed on two different approaches
to reduce handover delay: early authentication (so that authentication
does not need to be performed during handover), and reuse of
cryptographic material generated during an initial authentication to
save time during re-authentication. A starting assumption is that the
mobile host or "peer" is initially authenticated using the Extensible
Authentication Protocol (EAP), executed between the peer and an EAP
server as defined in RFC 3748.</t>
<t>This document documents the HOKEY architecture. Specifically, it
describes design objectives, the functional environment within which
handover keying operates, the functions to be performed by the HOKEY
architecture itself, and the assignment of those functions to
architectural components. It goes on to illustrate the operation of the
architecture within various deployment scenarios that are described more
fully in other documents produced by the HOKEY Working Group.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Extensible Authentication Protocol (EAP) <xref
target="RFC3748"></xref> is an authentication framework that supports
different types of authentication methods. Originally designed for
dial-up connections, EAP is now commonly used for authentication in
wireless access networks.</t>
<t>When a host (or "peer", the term used from this point onward) changes
its point of attachment to the network, it must be re-authenticated. If
a full EAP authentication must be repeated, several message round-trips
between the peer and the home EAP server may be involved. The resulting
delay will result in degradation or in the worst case loss of any
service session in progress if communication is suspended while
re-authentication is carried out. The delay is worse if the new point of
attachment is in a visited network rather than the peer's home network,
because of the extra procedural steps involved as well as because of the
probable increase in round-trip time.</t>
<t><xref target="RFC5169"></xref> describes this problem more fully and
establishes design goals for solutions to reduce re-authentication delay
for transfers within a single administrative domain. <xref
target="RFC5169"></xref> also suggests a number of ways to achieve a
solution: <list style="symbols">
<t>specification of a method-independent, efficient,
re-authentication protocol;</t>
<t>reuse of keying material from the initial authentication;</t>
<t>deployment of re-authentication servers local to the peer to
reduce round-trip delay; and</t>
<t>specification of the additional protocol needed to allow the EAP
server to pass authentication information to the local
re-authentication servers.</t>
</list></t>
<t><xref target="RFC5295"></xref> tackles the problem of reuse of keying
material by specifying how to derive a hierarchy of cryptographically
independent purpose-specific keys from the results of the original EAP
authentication. <xref target="RFC5296"></xref> specifies a
method-independent re-authentication protocol (ERP) applicable to two
specific deployment scenarios: <list style="symbols">
<t>where the peer's home EAP server also performs re-authentication;
and</t>
<t>where a local re-authentication server exists but is collocated
with a AAA proxy within the domain.</t>
</list></t>
<t>Other work provides further pieces of the solution or insight into
the problem. For the purpose of this draft, <xref
target="RFC5749"></xref> provides an abstract mechanism for distribution
of keying material from the EAP server to re-authentication servers.
<xref target="RFC5836"></xref> contrasts the EAP re-authentication (ER)
strategy provided by <xref target="RFC5296"></xref> with an alternative
strategy called "early authentication". <xref target="RFC5836"></xref>
defines EAP early authentication as the use of EAP by a mobile peer to
establish authenticated keying material on a target attachment point
prior to its arrival. Here, a full EAP execution occurs before the
handover of the peer takes place. Hence, the goal of EAP early
authentication is to complete all EAP-related communications, including
AAA signaling, in preparation for the handover, before the mobile device
actually moves. Early authentication includes direct and indirect
pre-authentication as well as Authenticated Anticipatory Keying (AKK).
All three mechanims provide means to execute a full EAP authentication
with a Candidate Access Point (CAP) while still being connected to the
Serving Access Point (SAP) but vary in their respective system
assumptions and communication paths. In particular, direct
pre-authentication assumes that clients are capable of discovering
candidate access points and all communications are routed through the
serving access point. On the other hand, indirect pre-authentication
assumes an existing relationship betweem SAP and CAP, whereas in AAK the
client interacts with the AAA to discover and connect to CAPs.</t>
<t>Both EAP re-authentication and early authentication enable faster
inter-authenticator handovers. However, it is currently unclear how the
necessary handover infrastructure is deployed and can be integrated into
existing EAP infrastructures. In particular, previous work has not
described how ER servers that act as endpoints in the re-authentication
process should be integrated into local and home domain networks.
Furthermore, it is currently unspecified how EAP infrastructure can
support the timely triggering of early authentications and aid with the
selection of candidate access points.</t>
<t>This document proposes a general HOKEY architecture and demonstrates
how it can be adapted to different deployment scenarios. To begin with,
<xref target="goals"></xref> recalls the design objectives for the HOKEY
architecture. <xref target="fncns"></xref> reviews the functions that
must be supported within the architecture. <xref target="compon"></xref>
describes the components of the HOKEY architecture. Finally, <xref
target="scen"></xref> describes the different deployment scenarios that
the HOKEY Working Group has addressed and the information flows that
must occur within those scenarios, by reference to the documents
summarized above where possible and otherwise within this document
itself.</t>
</section>
<!-- Introduction -->
<section anchor="terms" title="Terminology">
<t>This document contains no normative language, hence <xref
target="RFC2119"></xref> language does not apply.</t>
<t>This document reuses most of the terms defined in Section 2.2 of
<xref target="RFC5836"></xref>. In addition, it defines the following:
<list style="hanging">
<t hangText="EAP Early Authentication"><vspace blankLines="0" /> The
use of EAP by a mobile peer to establish authenticated keying
material on a target attachment point prior to its arrival, see
<xref target="RFC5836"></xref>.</t>
<t hangText="EAP Re-authentication (ER)"><vspace blankLines="0" />
The use of keying material derived from an initial EAP
authentication to enable single-roundtrip re-authentication of a
mobile peer. For a detailed description of the keying material see
Section 3 of <xref target="RFC5296"></xref>.</t>
<t hangText="ER Server"><vspace blankLines="0" /> A component of the
HOKEY architecture that terminates the EAP re-authentication
exchange with the peer.</t>
<t hangText="ER Key Management"><vspace blankLines="0" /> An
instantiation of the mechanism provided by <xref
target="RFC5749"></xref> for creating and delivering root keys from
an EAP server to an ER server.</t>
</list></t>
</section>
<section anchor="goals" title="Design Goals">
<t>This section investigates the design goals for the HOKEY
architecture. These include reducing the signaling overhead for re-
authentication and early authentication, integrating local domain name
discovery, and improving deployment scalability. These goals supplement
the discussion in <xref target="RFC5169"></xref>.</t>
<section anchor="sigOvhd" title="Reducing Signalling Overhead">
<section title="Minimized Communications with Home Servers">
<t>ERP requires only one round trip, however, this roundtrip may
require communications between a peer and its home ER and/or home
AAA server in explicit bootstrapping and communication between local
servers and home server in Implicit bootstrapping even if the peer
is currently attached to a visited (local) network. As a result,
even this one round trip may introduce long delays because home ER
and home AAA servers may be distant from the peer and the local
server to which the peer is attached. To lower the signaling
overhead, communication with the home ER server and home AAA server
should be minimized. Ideally, a peer should only need to communicate
with local servers and other local entities. </t>
</section>
<section title="Minimized User Interaction for authorization">
<t> When the peer is firstly attached to the network or moves
between heterogeneous networks, normally EAP full authentication
between the peer and EAP server occurs and User Interaction for
authorization may be needed, e.g., a dialog is prompted to the user
for a personal identifier. To lower the signaling overhead, user
interaction for authorization at each time of handover should be
minimized. Ideally, user interaction once for authorization and then
transparently authenticating in other places during handover is a
desirable solution which also can be used to improve user
experience. </t>
</section>
<section title="Integrated Local Domain Name (LDN) Discovery">
<t> ERP bootstrapping must occur before (implicit) or during
(explicit) a handover to transport the necessary re-authentication
root keys to the local ER server involved. Implicit bootstrapping is
preferable because it does not require communication with the home
ER server during handover (see section 3.1.1), but it requires the
peer to know the domain name of the ER server before subsequent
local ERP exchange happens in order to derive the necessary
re-authentication keying material. <xref target="RFC5296"></xref>
does not specify such a domain name discovery mechanism and suggests
that the peer may learn the domain name through the EAP- Initiate/
Re-auth-Start message or via lower layer announcements. However
domain name discovery happens after the implicit bootstrapping
completes, which potentially may introduce extra latency. To allow
more efficient handovers, a HOKEY architecture should support an
efficient domain name discovery mechanism and allow its integration
with ERP implicit bootstrapping. Even in the case of explicit
bootstrapping, local domain name discovery should be optimized such
that it does not require contacting the home AAA server, as is
currently the case. </t>
</section>
</section>
<!-- sigOvhd -->
<section title="Better Deployment Scalability">
<t>To provide better deployment scalability, it should not be required
that the HOKEY server and AAA servers or proxies are collocated.
Separation of these entities may cause problems with routing, but
allows flexibility in deployment and implementation.</t>
</section>
</section>
<section anchor="fncns" title="Functions That Must Be Supported">
<section title="System Overview">
<t>This section views the HOKEY architecture as the implementation of
a subsystem providing authentication services to AAA. Not only does
AAA depend on the authentication subsystem, but the latter also
depends on AAA as a means for the routing and secure transport of
messages internal to the operation of network access
authentication.</t>
<t>The operation of the authentication subsystem also depends on the
availability of a number of discovery functions: <list style="symbols">
<t>discovery of candidate access points, by the peer, by the
serving attachment point, or by some other entity;</t>
<t>discovery of the authentication services supported at a given
candidate access point;</t>
<t>discovery of the required server in the home domain when a
candidate access point is not in the same domain as the serving
attachment point, or no local server is available;</t>
<t>peer discovery of the local domain name (LDN) when EAP
re-authentication is used with a local server.</t>
</list> It is assumed that these functions are provided by the
environment within which the authentication subsystem operates, and
are outside the scope of the authentication subsystem itself. Local
domain name discovery is a possible exception.</t>
<t><xref target="fig_fctlOver"></xref> shows the major functions
comprising the authentication subsystem and their interdependencies.
These functions are described below. [EDITOR'S NOTE: These probably
need refinement. The relationship of pre-authentication to EAP
authentication, for instance, is currently not totally correct, when
one takes account of the roles described in <xref
target="compon"></xref>. AAK also needs an extension of ER key
management.]</t>
<figure anchor="fig_fctlOver"
title="Authentication Subsystem Functional Overview">
<artwork>
+------------------------------------------------------------+
| AAA Network Access Authentication and Authorization |
+---+-------------.----------------------------+-------------+
| /|\ |
| | Authentication subsystem |
+===|=============|============================|=============+
| | +---------+----------+ +-------------V---------+ |
| | | Direct and | | EAP Re-authentication | |
| | | Indirect | +--+------+-------^-----+ |
| | | Pre-Authentication | / / | |
| | +--------------------+ / / | |
| | / / +--------|------+ |
| | / | | Authenticated | |
| | / | | Anticipatory | |
| | / | | Keying (AAK) | |
| | / | +-------+-------+ |
| | / | | |
| +-V------------------+ / +---------V----------V--------+ |
| | EAP Authentication | | | ER Key Management | |
| +---------+----------+ | |+------------+ +------------+| |
| | | ||Handover Key| |Handover Key|| |
| | | || Derivation | |Distribution|| |
| | | |+------------+ +------+-----+| |
| | | +----------------------|------+ |
+===========|=============|=========================|========+
| | |
+-----------V-------------V-------------------------V--------+
| AAA routing and secure transport |
+------------------------------------------------------------+
</artwork>
<postamble>Arrows show the direction of functional
dependency.</postamble>
</figure>
<t><xref target="fig_fctlOver"></xref> shows the following
dependencies: <list style="symbols">
<t>When AAA is invoked to authenticate and authorize network
access, it uses one of two services offered by the authentication
subsystem: full EAP authentication, or EAP re-authentication.</t>
<t>Pre-authentication triggers AAA network access authentication
and authorization at each candidate access point, which in turn
causes full EAP authentication to be invoked.</t>
<t>EAP re-authentication invokes ER key management at the time of
authentication to create and distribute keying material to ER
servers.</t>
<t>Authenticated anticipatory keying (AAK) relies on ER key
management to establish keying material on ER/AAK servers, but
uses an extension to ER key management to derive and establish
keying material on candidate authenticators. Also AAK uses an
extension to EAP re-authentication to communicate with ER/AAK
servers.</t>
</list></t>
<t>EAP authentication, EAP re-authentication, and handover key
distribution depend on the routing and secure transport service
provided by AAA. Discovery functions and the function of
authentication and authorization of network entities (access points,
ER servers) are not shown. As stated above, these are external to the
authentication subsystem.</t>
</section>
<!-- System Overview -->
<section anchor="preauth"
title="Pre-Authentication Function (Direct or Indirect)">
<t>The pre-authentication function is responsible for discovery of
candidate access points and completion of network access
authentication and authorization at each candidate access point in
advance of handover. The operation of this function is described in
general terms in <xref target="RFC5836"></xref>. No document is yet
available to describe the implementation of pre-authentication in
terms of specific protocols. <xref target="RFC5873"></xref> could be
part of the solution, but is Experimental rather than Standards
Track.</t>
</section>
<!-- preauth -->
<section anchor="reauth" title="EAP Re-authentication Function">
<t>The EAP re-authentication function is responsible for
authenticating the peer at a specific access point using keying
material derived from a prior full EAP authentication. <xref
target="RFC5169"></xref> provides the design objectives for an
implementation of this function. <xref target="RFC5296"></xref>
describes a protocol to implement EAP re-authentication subject to the
architectural restrictions noted above. Work is in progress to relax
those restrictions.</t>
</section>
<!-- reauth -->
<section anchor="EAPauthen" title="EAP Authentication Function">
<t>The EAP authentication function is responsible for authenticating
the peer at a specific access point using a full EAP exchange. <xref
target="RFC3748"></xref> defines the associated protocol. <xref
target="RFC5836"></xref> shows the use of EAP as part of
pre-authentication. Note that the HOKEY Working Group has not
specified the non-AAA protocol required to transport EAP frames over
IP that is shown in Figures 3 and 5 of <xref target="RFC5836"></xref>,
although <xref target="RFC5873"></xref> is a candidate.</t>
</section>
<!-- EAPauthen -->
<section anchor="AAKfcn"
title="Authenticated Anticipatory Keying (AAK) Function">
<t>The authenticated anticipatory keying function is responsible for
pre-placing keying material derived from an initial full EAP
authentication on candidate access points. The operation is carried
out in two steps: ER key management (with trigger not currently
specified) places root keys derived from initial EAP authentication
onto an ER/AAK server associated with the peer. When requested by the
peer, the ER/AAK server derives and pushes predefined master session
keys to a list of candidate access points. The operation of the
authenticated anticipatory keying function is described in very
general terms in <xref target="RFC5836"></xref>. A protocol
implementation is being specified in <xref
target="I-D.ietf-hokey-erp-aak"></xref>.</t>
</section>
<!-- AAKfcn -->
<section anchor="keyMgmt" title="EAP-Based Handover Key Management">
<t>EAP-based handover key management consists of EAP method
independent key derivation and distribution and comprises the
following specific functions: <list style="symbols">
<t>handover key derivation; and</t>
<t>handover key distribution.</t>
</list> The derivation of handover keys is specified in <xref
target="RFC5295"></xref>, and key distribution is specified in <xref
target="RFC5749"></xref>.</t>
</section>
<!-- keyMgmt -->
</section>
<!-- fncns -->
<section anchor="compon" title="Components of the HOKEY Architecture">
<t>This section describes the components of the HOKEY architecture, in
terms of the functions they perform. The components cooperate as
described in this section to carry out the functions described in the
previous section. <xref target="scen"></xref> describes the different
deployment scenarios that are possible using these functions.</t>
<t>The components of the HOKEY architecture are as follows: <list
style="symbols">
<t>the peer;</t>
<t>the authenticator, which is a part of the serving access point
and candidate access points;</t>
<t>the EAP server; and</t>
<t>the ER server, and</t>
<t>the ER/AAK server , <xref
target="I-D.ietf-hokey-erp-aak"></xref>either in the home domain or
local to the authenticator.</t>
</list></t>
<section anchor="peerFnc" title="Functions of the Peer">
<t>The peer participates in the functions described in <xref
target="fncns"></xref> as shown in <xref
target="tab_peerFnc"></xref>.</t>
<texttable anchor="tab_peerFnc" title="Functions of the Peer">
<ttcol>Function</ttcol>
<ttcol>Peer Role</ttcol>
<c>EAP authentication</c>
<c>Determines that full EAP authentication is needed based on
context (e.g., initial authentication), prompting from the
authenticator, or discovery that only EAP authentication is
supported. Participates in the EAP exchange with the EAP server.</c>
<c>-</c>
<c>-</c>
<c>Direct pre-authentication</c>
<c>Discovers candidate access points. Initiates pre-authentication
with each, followed by EAP authentication as above, but using IP
rather than L2 transport for the EAP frames.</c>
<c>-</c>
<c>-</c>
<c>Indirect pre-authentication</c>
<c>Enters into a full EAP exchange when triggered, using either L2
or L3 transport for the frames.</c>
<c>-</c>
<c>-</c>
<c>EAP re-authentication</c>
<c>Determines that EAP re-authentication is possible based on
discovery or authenticator prompting. Discovers ER server.
Participates in ERP exchange with ER server.</c>
<c>-</c>
<c>-</c>
<c>Authenticated anticipatory keying</c>
<c>Determines that AAK is possible based on discovery or serving
authenticator prompting. Discovers candidate access points. Sends
request to serving authenticator to distribute keying material to
the candidate access points.</c>
<c>-</c>
<c>-</c>
<c>ER key management</c>
<c>No role.</c>
</texttable>
</section>
<!-- peerFnc -->
<section anchor="saFnc" title="Functions of the Serving Authenticator">
<t>The serving authenticator participates in the functions described
in <xref target="fncns"></xref> as shown in <xref
target="tab_saFnc"></xref>.</t>
<texttable anchor="tab_saFnc"
title="Functions of the Serving Authenticator">
<ttcol>Function</ttcol>
<ttcol>Serving Authenticator Role</ttcol>
<c>EAP authentication</c>
<c>No role.</c>
<c>-</c>
<c>-</c>
<c>Direct pre-authentication</c>
<c>No role.</c>
<c>-</c>
<c>-</c>
<c>Indirect pre-authentication</c>
<c>Discovers candidate access points. Initiates an EAP exchange
between the peer and the EAP server through each candidate
authenticator. Mediates between L2 transport of EAP frames on the
peer side and a non-AAA protocol over IP toward the candidate access
point.</c>
<c>-</c>
<c>-</c>
<c>EAP re-authentication</c>
<c>No role.</c>
<c>-</c>
<c>-</c>
<c>Authenticated anticipatory keying</c>
<c>Mediates between L2 transport of AAK frames on the peer side and
AAA transport toward the ER/AAK server.</c>
<c>-</c>
<c>-</c>
<c>ER key management</c>
<c>No role.</c>
</texttable>
</section>
<!-- saFnc -->
<section anchor="caFnc" title="Functions of the Candidate Authenticator">
<t>The candidate authenticator participates in the functions described
in <xref target="fncns"></xref> as shown in <xref
target="tab_caFnc"></xref>.</t>
<texttable anchor="tab_caFnc"
title="Functions of the Candidate Authenticator">
<ttcol>Function</ttcol>
<ttcol>Candidate Authenticator Role</ttcol>
<c>EAP authentication</c>
<c>Invokes AAA network access authentication and authorization upon
handover/initial attachment. Mediates between L2 transport of EAP
frames on the peer link and AAA transport toward the EAP server.</c>
<c>-</c>
<c>-</c>
<c>Direct pre-authentication</c>
<c>Invokes AAA network access authentication and authorization when
the peer initiates authentication. Mediates between non-AAA L3
transport of EAP frames on the peer side and AAA transport toward
the EAP server.</c>
<c>-</c>
<c>-</c>
<c>Indirect pre-authentication</c>
<c>Same as direct pre-authentication, except that it communicates
with the serving authenticator rather than the peer.</c>
<c>-</c>
<c>-</c>
<c>EAP re-authentication</c>
<c>Invokes AAA network access authentication and authorization upon
handover. Discovers or is configured with the address of the ER
server. Mediates between L2 transport of a ERP frames on the peer
side and AAA transport toward the ER server.</c>
<c>-</c>
<c>-</c>
<c>Authenticated anticipatory keying</c>
<c>Receives and saves pMSK.</c>
<c>-</c>
<c>-</c>
<c>ER key management</c>
<c>No role.</c>
</texttable>
</section>
<!-- caFnc -->
<section anchor="EAPsrvFnc" title="Functions of the EAP Server">
<t>The EAP server participates in the functions described in <xref
target="fncns"></xref> as shown in <xref
target="tab_EAPsrvFnc"></xref>.</t>
<texttable anchor="tab_EAPsrvFnc" title="Functions of the EAP Server">
<ttcol>Function</ttcol>
<ttcol>EAP Server Role</ttcol>
<c>EAP authentication</c>
<c>Authenticates and authorizes the candidate access point to act as
authenticator. Terminates EAP signalling between it and the peer via
the candidate authenticator. Determines whether network access
authentication succeeds or fails. Provides MSK to authenticator.</c>
<c>-</c>
<c>-</c>
<c>Direct pre-authentication</c>
<c>As for EAP authentication.</c>
<c>-</c>
<c>-</c>
<c>Indirect pre-authentication</c>
<c>As for EAP authentication.</c>
<c>-</c>
<c>-</c>
<c>EAP re-authentication</c>
<c>Mutually authenticates with the ER server and authorizes it for
receiving keying amterial. Provides rRK or DSrRK to the ER
server.</c>
<c>-</c>
<c>-</c>
<c>Authenticated anticipatory keying</c>
<c>As for EAP re-authentication.</c>
<c>-</c>
<c>-</c>
<c>ER key management</c>
<c>Creates rRK or DSrRK and distributes it to ER server requesting
the information.</c>
</texttable>
</section>
<!-- EAPsrvFnc -->
<section anchor="ERsrvFnc" title="Functions of the ER Server">
<t>The ER server participates in the functions described in <xref
target="fncns"></xref> as shown in <xref
target="tab_ERsrvFnc"></xref>. [EDITOR'S NOTE: Need discussion of
respective roles of local and home ER server, or whether there should
even be such a distinction.]</t>
<texttable anchor="tab_ERsrvFnc" title="Functions of the ER Server">
<ttcol>Function</ttcol>
<ttcol>ER Server Role</ttcol>
<c>EAP authentication</c>
<c>No role.</c>
<c>-</c>
<c>-</c>
<c>Direct pre-authentication</c>
<c>No role.</c>
<c>-</c>
<c>-</c>
<c>Indirect pre-authentication</c>
<c>No role.</c>
<c>-</c>
<c>-</c>
<c>EAP re-authentication</c>
<c>Authenticates and authorizes the candidate access point to act as
authenticator. Authenticates itself to the EAP server and acquires
rRK or DSrRK as applicable when necessary. Terminates ERP signalling
between it and the peer via the candidate authenticator. Determines
whether network access authentication succeeds or fails. Provides
MSK to authenticator.</c>
<c>-</c>
<c>-</c>
<c>Authenticated anticipatory keying</c>
<c>Authenticates itself to the EAP server and acquires rRK or DSrRK
as applicable when necessary. Authenticates and authorizes the
candidate access points to act as authenticator. Derives pMSKs and
passes them to the candidate access points.</c>
<c>-</c>
<c>-</c>
<c>ER key management</c>
<c>Receives and saves rRK or DSrRK as applicable.</c>
</texttable>
</section>
<!-- ERsrvFnc -->
</section>
<!-- compon -->
<section anchor="scen" title="Usage Scenarios">
<t>Depends on whether it involves a change in a domain or access
technology, we have the following the usage scenarios.</t>
<section title="Intra-domain handover">
<t>The peer moves between two authenticators in the same domain. In
this scenario, the peer communicates with the ER server via the ER
authenticator within the same network.</t>
</section>
<section title="Inter-domain handover">
<t>The peer moves between two different domains. In this scenario, the
peer communicates with more than one ER servers via one or two
different ER authenticators. One ER server is located in the current
network as the peer, one is located in the previous network from which
the peer moves. Another ER server is located in the home network which
the peer belong to.</t>
</section>
<section title="Inter-technology handover">
<t>The peer moves between two heterogeneous networks. In this
scenario, The peer needs to support at least two access technologies.
The coverage of two access technologies usually is overlapped during
handover. In this case, only authentication corresponding to
intra-domain handover is required, i.e., the peer can communicates
with the same local ER server to complete authentication and obtain
keying materials corresponding to the peer.</t>
</section>
</section>
<!-- scen -->
<section title="AAA Consideration">
<t>This section provides an analysis of how the AAA protocol can be
applied for hokey architecture in accordance with Authentication
Subsystem Functional Overview in figure 1.</t>
<section title="Authorization">
<t> Authorization is a major issue in deployments. Wherever the peer
moves around, the home AAA server provides authorization for the peer
during its handover. However authorization is not necessary to couple
with authentication at each time of handover, since authorization is
only needed when the peer is firstly attached to the network or moves
between two different AAA domains. The EAP Key management document
<xref target="RFC5247"></xref> discusses several vulnerabilities that
are common to handover mechanisms. One important issue arises from the
way the authorization decisions which might be handled at the AAA
server during network access authentication. For example, if AAA
proxies are involved, they may also influence in the authorization
decision. Furthermore, the reasons for choosing a particular decision
are not communicated to the AAA clients. In fact, the AAA client only
knows the final authorization result. Another issue is about session
management. In some circumstance when the peer moves from one
authenticator to another, the peer may be authenticated by the
different authenticator during a period of time and the authenticator
to which the peer is currently attached needs to create new AAA user
session, however the AAA Server should not view these handoffs as
different sessions. Otherwise this may affect user experience and also
accounting or logging issues. For example, the session-Id creation, in
most case, is done by each authenticator to which the peer attaches.
In this sense, the new authenticator acting as AAA Client needs to
create new AAA user session from scratch which forces its
corresponding AAA Server to terminate the existing user session with
previous authenticator and setup the new user session with the new
authenticator. This may complicate the set up and maintenance of the
AAA User session. </t>
</section>
<section title="Transport aspect">
<t>The existing AAA protocols can be used to carry EAP messages and
ERP messages between the AAA server and AAA clients AAA Transport of
ERP messages is specified in <xref target="RFC5749"></xref> and <xref
target="I-D.ietf-dime-erp"></xref>. AAA transport of EAP message is
specified in <xref target="RFC4072"></xref>.The key transport also can
be performed through a AAA protocol. <xref
target="I-D.ietf-dime-local-keytran"></xref> specifies a set of
Attribute-Value Pairs (AVPs) providing native Diameter support of
cryptographic key delivery.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document does not require any actions by IANA.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Mark Jones, Zhen Cao,Lionel Morand
for their reviews of previous versions of this draft.</t>
</section>
</middle>
<back>
<references title="Informative References">
&rfc2119;
&rfc3748;
&rfc5169;
&rfc5295;
&rfc5296;
&rfc5749;
&rfc5836;
&rfc5873;
&I-D.ietf-hokey-erp-aak;
<reference anchor="RFC5247">
<front>
<title>Extensible Authentication Protocol (EAP) Key Management
Framework</title>
<author fullname="B. Aboba" initials="B." surname="Aboba">
<organization>Microsoft</organization>
</author>
<author fullname="D. Simon" initials="D." surname="Simon">
<organization>Microsoft</organization>
</author>
<author fullname="P. Eronen" initials="P." surname="Eronen">
<organization>Nokia</organization>
</author>
<date month="August" year="2008" />
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC
3748, enables extensible network access authentication. This
document specifies the EAP key hierarchy and provides a framework
for the transport and usage of keying material and parameters
generated by EAP authentication algorithms, known as "methods". It
also provides a detailed system-level security analysis,
describing the conditions under which the key management
guidelines described in RFC 4962 can be satisfied.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5247" />
<format target="http://www.rfc-editor.org/rfc/rfc5247.txt" type="TXT" />
</reference>
<reference anchor="I-D.ietf-dime-erp">
<front>
<title>Diameter support for EAP Re-authentication Protocol
(ERP)</title>
<author fullname="Julien Bournelle" initials="J" surname="Bournelle">
<organization></organization>
</author>
<author fullname="Lionel Morand" initials="L" surname="Morand">
<organization></organization>
</author>
<author fullname="Sebastien Decugis" initials="S" surname="Decugis">
<organization></organization>
</author>
<author fullname="Wenson Wu" initials="W" surname="Wu">
<organization></organization>
</author>
<author fullname="Glen Zorn" initials="G" surname="Zorn">
<organization></organization>
</author>
<date day="4" month="May" year="2011" />
<abstract>
<t>The EAP Re-authentication Protocol (ERP) defines extensions to
the Extensible Authentication Protocol (EAP) to support efficient
re- authentication between the peer and an EAP Re-authentication
(ER) server through a compatible authenticator. This document
specifies Diameter support for ERP. It defines a new Diameter ERP
application to transport ERP messages between an ER authenticator
and the ER server, and a set of new AVPs that can be used to
transport the cryptographic material needed by the
re-authentication server.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-dime-local-keytran">
<front>
<title>Diameter Attribute-Value Pairs for Cryptographic Key
Transport</title>
<author fullname="Qin Wu" initials="Q.">
<organization>Huawei</organization>
</author>
<author fullname="Glen Zorn" initials="G.">
<organization>Network Zen</organization>
</author>
<date month="July" year="2010" />
<abstract>
<t>Some Authentication, Authorization, and Accounting (AAA)
applications require the transport of cryptographic keying
material; this document specifies a set of Attribute-Value Pairs
(AVPs) providing native Diameter support of cryptographic key
delivery.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4072">
<front>
<title>Diameter Extensible Authentication Protocol (EAP)
Application</title>
<author fullname="P. Eronen" initials="P." role="editor"
surname="Eronen">
<organization>Nokia</organization>
</author>
<author fullname="T. Hiller" initials="T." surname="Hiller">
<organization>Lucent Technologies</organization>
</author>
<author fullname="G.Zorn" initials="G." surname="Zorn">
<organization>Cisco</organization>
</author>
<date month="August" year="2005" />
</front>
<seriesInfo name="RFC" value="4072" />
<format target="http://www.rfc-editor.org/rfc/rfc4072.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 18:31:43 |