Network Working Group K. Hoeper
Internet-Draft Motorola
Intended status: Informational S. Decugis
Expires: April 28, 2011 NICT
G. Zorn
Network Zen
Q. Wu
T. Taylor
Huawei
October 25, 2010
Handover Keying (HOKEY) Architecture Design
draft-ietf-hokey-arch-design-01
Abstract
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.
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
Hoeper, et al. Expires April 28, 2011 [Page 1]
Internet-Draft Architecture Design October 2010
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."
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hoeper, et al. Expires April 28, 2011 [Page 2]
Internet-Draft Architecture Design October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Reducing Signalling Overhead . . . . . . . . . . . . . . . 6
3.1.1. Minimized Communications with Home Servers . . . . . . 6
3.1.2. Integrated Local Domain Name (LDN) Discovery . . . . . 7
3.2. Better Deployment Scalability . . . . . . . . . . . . . . 7
4. Functions That Must Be Supported . . . . . . . . . . . . . . . 7
4.1. System Overview . . . . . . . . . . . . . . . . . . . . . 7
4.2. Pre-Authentication Function (Direct or Indirect) . . . . . 10
4.3. EAP Re-authentication Function . . . . . . . . . . . . . . 10
4.4. EAP Authentication Function . . . . . . . . . . . . . . . 10
4.5. Authenticated Anticipatory Keying (AAK) Function . . . . . 10
4.6. EAP-Based Handover Key Management . . . . . . . . . . . . 11
5. Components of the HOKEY Architecture . . . . . . . . . . . . . 11
5.1. Functions of the Peer . . . . . . . . . . . . . . . . . . 12
5.2. Functions of the Serving Authenticator . . . . . . . . . . 12
5.3. Functions of the Candidate Authenticator . . . . . . . . . 13
5.4. Functions of the EAP Server . . . . . . . . . . . . . . . 14
5.5. Functions of the ER Server . . . . . . . . . . . . . . . . 15
6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
7. AAA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Standalone HOKEY server . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Hoeper, et al. Expires April 28, 2011 [Page 3]
Internet-Draft Architecture Design October 2010
1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] 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.
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.
[RFC5169] describes this problem more fully and establishes design
goals for solutions to reduce re-authentication delay for transfers
within a single administrative domain. [RFC5169] also suggests a
number of ways to achieve a solution:
o specification of a method-independent, efficient, re-
authentication protocol;
o reuse of keying material from the initial authentication;
o deployment of re-authentication servers local to the peer to
reduce round-trip delay; and
o specification of the additional protocol needed to allow the EAP
server to pass authentication information to the local re-
authentication servers.
[RFC5295] 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. [RFC5296] specifies a method-independent re-
authentication protocol (ERP) applicable to two specific deployment
scenarios:
o where the peer's home EAP server also performs re-authentication;
and
o where a local re-authentication server exists but is collocated
with a AAA proxy within the domain.
Hoeper, et al. Expires April 28, 2011 [Page 4]
Internet-Draft Architecture Design October 2010
Other work provides further pieces of the solution or insight into
the problem. For the purpose of this draft, [RFC5749] provides an
abstract mechanism for distribution of keying material from the EAP
server to re-authentication servers. [RFC5836] contrasts the EAP re-
authentication (ER) strategy provided by [RFC5296] with an
alternative strategy called "early authentication". [RFC5836]
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.
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.
This document proposes a general HOKEY architecture and demonstrates
how it can be adapted to different deployment scenarios. To begin
with, Section 3 recalls the design objectives for the HOKEY
architecture. Section 4 reviews the functions that must be supported
within the architecture. Section 5 describes the components of the
HOKEY architecture. Finally, Section 6 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.
Hoeper, et al. Expires April 28, 2011 [Page 5]
Internet-Draft Architecture Design October 2010
2. Terminology
This document contains no normative language, hence [RFC2119]
language does not apply.
This document reuses most of the terms defined in Section 2.2 of
[RFC5836]. In addition, it defines the following:
EAP Early Authentication
The use of EAP by a mobile peer to establish authenticated keying
material on a target attachment point prior to its arrival, see
[RFC5836].
EAP Re-authentication (ER)
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 [RFC5296].
ER Server
A component of the HOKEY architecture that terminates the EAP re-
authentication exchange with the peer.
ER Key Management
An instantiation of the mechanism provided by [RFC5749] for
creating and delivering root keys from an EAP server to an ER
server.
3. Design Goals
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 [RFC5169].
3.1. Reducing Signalling Overhead
3.1.1. Minimized Communications with Home Servers
ERP requires only one round trip, however, this roundtrip may require
communications between a peer and its home ER and/or home AAA server
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.
To lower the signaling overhead, communication with the home ER
server and home AAA server should be minimized. Ideally, a peer
Hoeper, et al. Expires April 28, 2011 [Page 6]
Internet-Draft Architecture Design October 2010
should only need to communicate with local servers and other local
entities.
3.1.2. Integrated Local Domain Name (LDN) Discovery
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 previous section), but it requires the peer to
know the domain name of the ER server in order to derive the
necessary re-authentication keying material. [RFC5296] 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. 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.
3.2. Better Deployment Scalability
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.
4. Functions That Must Be Supported
4.1. System Overview
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.
The operation of the authentication subsystem also depends on the
availability of a number of discovery functions:
o discovery of candidate access points, by the peer, by the serving
attachment point, or by some other entity;
o discovery of the authentication services supported at a given
candidate access point;
Hoeper, et al. Expires April 28, 2011 [Page 7]
Internet-Draft Architecture Design October 2010
o 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;
o peer discovery of the local domain name (LDN) when EAP re-
authentication is used with a local server.
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.
Figure 1 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 Section 5. AAK also needs an extension of ER
key management.]
Hoeper, et al. Expires April 28, 2011 [Page 8]
Internet-Draft Architecture Design October 2010
+------------------------------------------------------------+
| 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 |
+------------------------------------------------------------+
Arrows show the direction of functional dependency.
Figure 1: Authentication Subsystem Functional Overview
Figure 1 shows the following dependencies:
o 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.
o Pre-authentication triggers AAA network access authentication and
authorization at each candidate access point, which in turn causes
full EAP authentication to be invoked.
o EAP re-authentication invokes ER key management at the time of
authentication to create and distribute keying material to ER
servers.
Hoeper, et al. Expires April 28, 2011 [Page 9]
Internet-Draft Architecture Design October 2010
o 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.
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.
4.2. Pre-Authentication Function (Direct or Indirect)
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 [RFC5836]. No document is yet available to describe
the implementation of pre-authentication in terms of specific
protocols. [RFC5873] could be part of the solution, but is
Experimental rather than Standards Track.
4.3. EAP Re-authentication Function
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. [RFC5169] provides the design
objectives for an implementation of this function. [RFC5296]
describes a protocol to implement EAP re-authentication subject to
the architectural restrictions noted above. Work is in progress to
relax those restrictions.
4.4. EAP Authentication Function
The EAP authentication function is responsible for authenticating the
peer at a specific access point using a full EAP exchange. [RFC3748]
defines the associated protocol. [RFC5836] 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 [RFC5836], although
[RFC5873] is a candidate.
4.5. Authenticated Anticipatory Keying (AAK) Function
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
Hoeper, et al. Expires April 28, 2011 [Page 10]
Internet-Draft Architecture Design October 2010
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 [RFC5836]. A protocol implementation is being
specified in [I-D.ietf-hokey-erp-aak].
4.6. EAP-Based Handover Key Management
EAP-based handover key management consists of EAP method independent
key derivation and distribution and comprises the following specific
functions:
o handover key derivation; and
o handover key distribution.
The derivation of handover keys is specified in [RFC5295], and key
distribution is specified in [RFC5749].
5. Components of the HOKEY Architecture
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. Section 6 describes the different deployment
scenarios that are possible using these functions.
The components of the HOKEY architecture are as follows:
o the peer;
o the authenticator, which is a part of the serving access point and
candidate access points;
o the EAP server; and
o the ER server, either in the home domain or local to the
authenticator.
[EDITOR'S NOTE: probably have to add the ER/AAK server named in
[I-D.ietf-hokey-erp-aak] to this list.]
Hoeper, et al. Expires April 28, 2011 [Page 11]
Internet-Draft Architecture Design October 2010
5.1. Functions of the Peer
The peer participates in the functions described in Section 4 as
shown in Table 1.
+--------------------+----------------------------------------------+
| Function | Peer Role |
+--------------------+----------------------------------------------+
| EAP authentication | 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. |
| - | - |
| Direct | Discovers candidate access points. |
| pre-authentication | Initiates pre-authentication with each, |
| | followed by EAP authentication as above, but |
| | using IP rather than L2 transport for the |
| | EAP frames. |
| - | - |
| Indirect | Enters into a full EAP exchange when |
| pre-authentication | triggered, using either L2 or L3 transport |
| | for the frames. |
| - | - |
| EAP | Determines that EAP re-authentication is |
| re-authentication | possible based on discovery or authenticator |
| | prompting. Discovers ER server. |
| | Participates in ERP exchange with ER server. |
| - | - |
| Authenticated | Determines that AAK is possible based on |
| anticipatory | discovery or serving authenticator |
| keying | prompting. Discovers candidate access |
| | points. Sends request to serving |
| | authenticator to distribute keying material |
| | to the candidate access points. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 1: Functions of the Peer
5.2. Functions of the Serving Authenticator
The serving authenticator participates in the functions described in
Section 4 as shown in Table 2.
Hoeper, et al. Expires April 28, 2011 [Page 12]
Internet-Draft Architecture Design October 2010
+--------------------+----------------------------------------------+
| Function | Serving Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | Discovers candidate access points. |
| pre-authentication | 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. |
| - | - |
| EAP | No role. |
| re-authentication | |
| - | - |
| Authenticated | Mediates between L2 transport of AAK frames |
| anticipatory | on the peer side and AAA transport toward |
| keying | the ER/AAK server. |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 2: Functions of the Serving Authenticator
5.3. Functions of the Candidate Authenticator
The candidate authenticator participates in the functions described
in Section 4 as shown in Table 3.
Hoeper, et al. Expires April 28, 2011 [Page 13]
Internet-Draft Architecture Design October 2010
+--------------------+----------------------------------------------+
| Function | Candidate Authenticator Role |
+--------------------+----------------------------------------------+
| EAP authentication | 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. |
| - | - |
| Direct | Invokes AAA network access authentication |
| pre-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. |
| - | - |
| Indirect | Same as direct pre-authentication, except |
| pre-authentication | that it communicates with the serving |
| | authenticator rather than the peer. |
| - | - |
| EAP | Invokes AAA network access authentication |
| re-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. |
| - | - |
| Authenticated | Receives and saves pMSK. |
| anticipatory | |
| keying | |
| - | - |
| ER key management | No role. |
+--------------------+----------------------------------------------+
Table 3: Functions of the Candidate Authenticator
5.4. Functions of the EAP Server
The EAP server participates in the functions described in Section 4
as shown in Table 4.
Hoeper, et al. Expires April 28, 2011 [Page 14]
Internet-Draft Architecture Design October 2010
+--------------------+----------------------------------------------+
| Function | EAP Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | 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. |
| - | - |
| Direct | As for EAP authentication. |
| pre-authentication | |
| - | - |
| Indirect | As for EAP authentication. |
| pre-authentication | |
| - | - |
| EAP | Mutually authenticates with the ER server |
| re-authentication | and authorizes it for receiving keying |
| | amterial. Provides rRK or DSrRK to the ER |
| | server. |
| - | - |
| Authenticated | As for EAP re-authentication. |
| anticipatory | |
| keying | |
| - | - |
| ER key management | Creates rRK or DSrRK and distributes it to |
| | ER server requesting the information. |
+--------------------+----------------------------------------------+
Table 4: Functions of the EAP Server
5.5. Functions of the ER Server
The ER server participates in the functions described in Section 4 as
shown in Table 5. [EDITOR'S NOTE: Need discussion of respective
roles of local and home ER server, or whether there should even be
such a distinction.]
Hoeper, et al. Expires April 28, 2011 [Page 15]
Internet-Draft Architecture Design October 2010
+--------------------+----------------------------------------------+
| Function | ER Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | No role. |
| pre-authentication | |
| - | - |
| EAP | Authenticates and authorizes the candidate |
| re-authentication | 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. |
| - | - |
| Authenticated | Authenticates itself to the EAP server and |
| anticipatory | acquires rRK or DSrRK as applicable when |
| keying | necessary. Authenticates and authorizes the |
| | candidate access points to act as |
| | authenticator. Derives pMSKs and passes |
| | them to the candidate access points. |
| - | - |
| ER key management | Receives and saves rRK or DSrRK as |
| | applicable. |
+--------------------+----------------------------------------------+
Table 5: Functions of the ER Server
6. Deployment Scenarios
The necessity for this section and its contents are TBD.
7. AAA Consideration
7.1. Standalone HOKEY server
TBD.
Hoeper, et al. Expires April 28, 2011 [Page 16]
Internet-Draft Architecture Design October 2010
8. Security Considerations
TBD
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgments
The authors would like to thank Mark Jones and Zhen Cao for their
reviews of previous versions of this draft.
11. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
August 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of
EAP-Based Keys for Handover and Re-Authentication",
RFC 5749, March 2010.
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication
Protocol (EAP) Early Authentication Problem Statement",
RFC 5836, April 2010.
[RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the
Protocol for Carrying Authentication for Network Access
(PANA)", RFC 5873, May 2010.
Hoeper, et al. Expires April 28, 2011 [Page 17]
Internet-Draft Architecture Design October 2010
[I-D.ietf-hokey-erp-aak]
Cao, Z., Deng, H., Wang, Y., Wu, Q., and G. Zorn, "EAP Re-
authentication Protocol Extensions for Authenticated
Anticipatory Keying (ERP/AAK)", Internet
Draft draft-ietf-hokey-erp-aak-02, May 2010.
Authors' Addresses
Katrin Hoeper
Motorola, Inc.
1301 E. Algonquin Road
Schaumburg, IL 60196
USA
Email: khoeper@motorola.com
Sebastien Decugis
NICT
4-2-1 Nukui-Kitamachi
Tokyo, Koganei 184-8795
Japan
Email: sdecugis@nict.go.jp
Glen Zorn
Network Zen
1310 East Thomas Street
Seattle, Washington 98102
USA
Email: gwz@net-zen.net
Qin Wu
Huawei Technologies Co.,Ltd
Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
Nanjing, JiangSu 210001
China
Phone: +86-25-84565892
Email: sunseawq@huawei.com
Hoeper, et al. Expires April 28, 2011 [Page 18]
Internet-Draft Architecture Design October 2010
Tom Taylor
Huawei Technologies Co., Ltd
Ottawa
Canada
Email: tom111.taylor@bell.net
Hoeper, et al. Expires April 28, 2011 [Page 19]