Network Working Group G. Zorn, Ed.
Internet-Draft Network Zen
Intended status: Informational Q. Wu
Expires: July 16, 2012 T. Taylor
Huawei
Y. Nir
Check Point
K. Hoeper
Motorola
S. Decugis
INSIDE Secure
January 13, 2012
Handover Keying (HOKEY) Architecture Design
draft-ietf-hokey-arch-design-11
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 basic
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 defines 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/.
Zorn, et al. Expires July 16, 2012 [Page 1]
Internet-Draft HOKEY Architecture Design January 2012
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 16, 2012.
Copyright Notice
Copyright (c) 2012 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.
Zorn, et al. Expires July 16, 2012 [Page 2]
Internet-Draft HOKEY Architecture Design January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Reducing Signaling Overhead . . . . . . . . . . . . . . . 7
3.1.1. Minimized Communications with Home Servers . . . . . . 7
3.1.2. Minimized User Interaction for Authentication . . . . 7
3.2. Integrated Local Domain Name (LDN) Discovery . . . . . . . 7
3.3. Fault-tolerant re-authentication . . . . . . . . . . . . . 8
3.4. Improved Deployment Scalability . . . . . . . . . . . . . 8
4. Required Functionality . . . . . . . . . . . . . . . . . . . . 8
4.1. Authentication Subsystem Functional Overview . . . . . . . 8
4.2. Pre-Authentication Function (Direct or Indirect) . . . . . 9
4.3. EAP Re-authentication Function . . . . . . . . . . . . . . 9
4.4. EAP Authentication Function . . . . . . . . . . . . . . . 10
4.5. Authenticated Anticipatory Keying (AAK) Function . . . . . 10
4.6. Management of EAP-Based Handover Keys . . . . . . . . . . 10
5. Components of the HOKEY Architecture . . . . . . . . . . . . . 10
5.1. Functions of the Peer . . . . . . . . . . . . . . . . . . 11
5.2. Functions of the Serving Authenticator . . . . . . . . . . 12
5.3. Functions of the Candidate Authenticator . . . . . . . . . 13
5.4. Functions of the EAP Server . . . . . . . . . . . . . . . 13
5.5. Functions of the ER Server . . . . . . . . . . . . . . . . 14
6. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Simple Re-authentication . . . . . . . . . . . . . . . . . 15
6.2. Intra-domain Handover . . . . . . . . . . . . . . . . . . 15
6.3. Inter-domain handover . . . . . . . . . . . . . . . . . . 16
6.4. Inter-technology handover . . . . . . . . . . . . . . . . 16
7. AAA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Transport Aspect . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Zorn, et al. Expires July 16, 2012 [Page 3]
Internet-Draft HOKEY Architecture Design January 2012
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 in a variety of 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.
RFC 5169 [RFC5169] describes this problem more fully and establishes
design goals for solutions to reduce re-authentication delay for
transfers within a single administrative domain. It also suggests a
number of ways to achieve a solution:
o specification of a method-independent, efficient, re-
authentication protocol based upon EAP;
o reuse of keying material from the initial EAP 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.
RFC 5295 [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, while Wu, et al. [I-D.ietf-hokey-rfc5296bis]
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.
Zorn, et al. Expires July 16, 2012 [Page 4]
Internet-Draft HOKEY Architecture Design January 2012
Other work provides further pieces of the solution or insight into
the problem. For the purpose of this memo, RFC 5749 [RFC5749]
provides an abstract mechanism for distribution of keying material
from the EAP server to re-authentication servers. RFC 5836 [RFC5836]
contrasts the EAP re-authentication (ER) strategy provided by ERP
with an alternative strategy called "early authentication". RFC 5836
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. 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 (AAK). All three early authentication mechanisms provide
means to securely establish authenticated keying material on 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 between SAP and CAP, whereas the
discovery and selection of Candidate Access Points is outside the
scope of AAK. Furthermore, both direct and indirect pre-
authentication require a full EAP execution to occur before the
handover of the peer takes place, while AAK (like ERP
[I-D.ietf-hokey-rfc5296bis]) uses keys derived from the initial EAP
authentication.
Both EAP re-authentication and early authentication enable faster
inter-authenticator handovers. However, it is currently unclear how
the necessary handover infrastructure can be deployed and 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. 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
Zorn, et al. Expires July 16, 2012 [Page 5]
Internet-Draft HOKEY Architecture Design January 2012
reference to the documents summarized above where possible and
otherwise within this document itself. Finally, Section 7 provides
an analysis of how AAA protocols can be applied in the HOKEY
architecture.
2. Terminology
This document contains no normative language, hence [RFC2119]
language does not apply.
This document reuses terms defined in Section 2.2 of Ohba, et al.
[RFC5836] and Section 2 of Wu, et al. [I-D.ietf-hokey-rfc5296bis].
In addition, it defines the following:
DSrRK
Domain-Specific reauthentication Root Key.
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
Ohba, et al. [RFC5836].
ER Key Management
An instantiation of the mechanism described in Hoeper, et al.
[RFC5749] for creating and delivering root keys from an EAP server
to an ER server.
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 4 of Wu, et al. [I-D.ietf-hokey-rfc5296bis].
ER Server
A component of the HOKEY architecture that terminates the EAP re-
authentication exchange with the peer.
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, enabling fault-tolerant re-authentication and
improving deployment scalability. These goals supplement those
discussed in Section 4 of RFC 5169 [RFC5169]. Note that the
identification and selection of Candidate Access Points is not a goal
Zorn, et al. Expires July 16, 2012 [Page 6]
Internet-Draft HOKEY Architecture Design January 2012
of the architecture, since those operations are generally specific to
the lower layer in use.
3.1. Reducing Signaling Overhead
3.1.1. Minimized Communications with Home Servers
ERP [I-D.ietf-hokey-rfc5296bis] requires only one round trip;
however, this roundtrip may require communication 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 the home ER and home AAA servers may be distant
from the peer and the network to which it is attached. To lower
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.
3.1.2. Minimized User Interaction for Authentication
When the peer is initially attached to the network or moves between
heterogeneous networks, full EAP authentication between the peer and
EAP server occurs and user interaction may be needed, e.g., a dialog
to prompt the user for credentials. To reduce latency, user
interaction for authentication at each handover should be minimized.
Ideally, user involvement should take place only during initial
authentication and subsequent re-authentication should occur
transparently.
3.2. Integrated Local Domain Name (LDN) Discovery
ERP bootstrapping must occur before (implicit) or during (explicit) a
handover to transport the necessary keys to the local ER server
involved. Implicit bootstrapping is preferable because it does not
require communication with the home ER server during handover, but it
requires the peer to know the domain name of the ER server before the
subsequent local ERP exchange happens in order to derive the
necessary re-authentication keying material. ERP
[I-D.ietf-hokey-rfc5296bis] 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 may introduce extra
latency. To allow more efficient handovers, a HOKEY architecture
should support an efficient domain name discovery mechanism (for
example, see Zorn, Wu & Wang [RFC6440]) and allow its integration
with ERP implicit bootstrapping. Even in the case of explicit
Zorn, et al. Expires July 16, 2012 [Page 7]
Internet-Draft HOKEY Architecture Design January 2012
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.3. Fault-tolerant re-authentication
If all authentication services depend upon a remote server, a network
partition can result in the denial of service to valid users.
However, if for example an ER server exists in the local network,
previously authenticated users can re-authenticate even though a link
to the home or main authentication server doesn't exist.
3.4. Improved Deployment Scalability
To provide better deployment scalability, there should be no
requirement for the co-location of entities proving handover keying
services (e.g., ER servers) and AAA servers or proxies. Separation
of these entities may cause problems with routing, but allows greater
flexibility in deployment and implementation.
4. Required Functionality
4.1. Authentication Subsystem Functional Overview
The operation of the authentication subsystem provided by HOKEY 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;
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.
The major functions comprising the authentication subsystem and their
inter-dependencies are discussed in greater detail below.
Zorn, et al. Expires July 16, 2012 [Page 8]
Internet-Draft HOKEY Architecture Design January 2012
o When AAA is invoked to authorize network access, it uses one of
two services offered by the authentication subsystem: full EAP
authentication, or EAP re-authentication. Note that although AAA
may perform authentication directly in some cases, when EAP is
utilized AAA functions only as a transport for EAP messages and
the encryption keys (if any) resulting from successful EAP
authentication.
o Pre-authentication triggers AAA network access 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.
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. AAK uses an
extension to EAP re-authentication to communicate with ER/AAK
servers.
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 Ohba, et al. [RFC5836]. No document is yet
available to describe the implementation of pre-authentication in
terms of specific protocols; Pre-Authentication Support for PANA
[RFC5873] could be part of the solution.
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. RFC 5169 [RFC5169] provides
the design objectives for an implementation of this function. ERP
[I-D.ietf-hokey-rfc5296bis] describes a protocol to implement EAP re-
Zorn, et al. Expires July 16, 2012 [Page 9]
Internet-Draft HOKEY Architecture Design January 2012
authentication.
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. Aboba, et
al. [RFC3748] defines the associated protocol, while Ohba, et al.
[RFC5836] describe 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 Ohba, et al. [RFC5836], although PANA [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
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 one or more candidate access points. The operation
of the authenticated anticipatory keying function is described in
very general terms in Ohba, et al. [RFC5836]. A protocol
specification exists (see Cao, et al. [I-D.ietf-hokey-erp-aak]).
4.6. Management of EAP-Based Handover Keys
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 Salowey, et al.
[RFC5295], and AAA-based key distribution is specified in Hoeper,
Nakhjiri & Ohba [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
Zorn, et al. Expires July 16, 2012 [Page 10]
Internet-Draft HOKEY Architecture Design January 2012
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, and
o the ER/AAK server , [I-D.ietf-hokey-erp-aak] either in the home
domain or local to the authenticator.
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. Participates in ERP exchange |
| | with ER server. |
| - | - |
Zorn, et al. Expires July 16, 2012 [Page 11]
Internet-Draft HOKEY Architecture Design January 2012
| Authenticated | Determines that AAK is possible based on |
| anticipatory | discovery or serving authenticator |
| keying | prompting. Discovers candidate access |
| | points. Participates in ERP/AAK exchange, |
| | requesting distribution of 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.
+--------------------+----------------------------------------------+
| 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
Zorn, et al. Expires July 16, 2012 [Page 12]
Internet-Draft HOKEY Architecture Design January 2012
5.3. Functions of the Candidate Authenticator
The candidate authenticator participates in the functions described
in Section 4 as shown in Table 3.
+--------------------+----------------------------------------------+
| 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.
Zorn, et al. Expires July 16, 2012 [Page 13]
Internet-Draft HOKEY Architecture Design January 2012
+--------------------+----------------------------------------------+
| Function | EAP Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | Terminates EAP signaling between it and the |
| | peer via the candidate authenticator. |
| | Determines whether network access |
| | authentication succeeds or fails. Provides |
| | MSK to authenticator (via AAA). |
| - | - |
| Direct | As for EAP authentication. |
| pre-authentication | |
| - | - |
| Indirect | As for EAP authentication. |
| pre-authentication | |
| - | - |
| EAP | Provides rRK or DSrRK to the ER server (via |
| re-authentication | AAA). |
| - | - |
| 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.
Zorn, et al. Expires July 16, 2012 [Page 14]
Internet-Draft HOKEY Architecture Design January 2012
+--------------------+----------------------------------------------+
| Function | ER Server Role |
+--------------------+----------------------------------------------+
| EAP authentication | No role. |
| - | - |
| Direct | No role. |
| pre-authentication | |
| - | - |
| Indirect | No role. |
| pre-authentication | |
| - | - |
| EAP | Acquires rRK or DSrRK as applicable when |
| re-authentication | necessary. Terminates ERP signaling between |
| | it and the peer via the candidate |
| | authenticator. Determines whether network |
| | access authentication succeeds or fails. |
| | Provides MSK to authenticator. |
| - | - |
| Authenticated | And acquires rRK or DSrRK as applicable when |
| anticipatory | necessary. Derives pMSKs and passes them to |
| keying | the candidate access points. |
| - | - |
| ER key management | Receives and saves rRK or DSrRK as |
| | applicable. |
+--------------------+----------------------------------------------+
Table 5: Functions of the ER Server
6. Usage Scenarios
Depending upon whether it involves a change in a domain or access
technology, we have the following the usage scenarios.
6.1. Simple Re-authentication
The peer remains stationary and re-authenticates to the original
access point. Note that in this case, the SAP takes the role of the
CAP in the discussion above.
6.2. Intra-domain Handover
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.
Zorn, et al. Expires July 16, 2012 [Page 15]
Internet-Draft HOKEY Architecture Design January 2012
6.3. Inter-domain handover
The peer moves between two different domains. In this scenario, the
peer communicates with more than one ER server 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 to which the peer belongs.
6.4. Inter-technology handover
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 communicate with the
same local ER server to complete authentication and obtain keying
materials corresponding to the peer.
7. AAA Considerations
This section provides an analysis of how the AAA protocol can be
applied in the hokey architecture in accordance with the
Authentication Subsystem Functional Overview (see Section 4.1)
7.1. Authorization
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, it is unnecessary to couple
authorization with authentication at every handover, since
authorization is only needed when the peer is initially attached to
the network or moves between two different AAA domains. The EAP key
management document [RFC5247] 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
regards session management. In some circumstances 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 a new AAA user session, however the AAA server should not
view these handoffs as different sessions. Otherwise this may affect
Zorn, et al. Expires July 16, 2012 [Page 16]
Internet-Draft HOKEY Architecture Design January 2012
user experience and also cause accounting or logging issues. For
example, session ID creation, in most cases, is done by each
authenticator to which the peer attaches. In this sense, the new
authenticator acting as AAA client needs to create a new AAA user
session from scratch which forces its corresponding AAA Server to
terminate the existing user session with previous authenticator and
setup a new user session with the new authenticator. This may
complicate the set up and maintenance of the AAA user session.
7.2. Transport Aspect
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 Hoeper, Nakhjiri & Ohba [RFC5749] and
Bournelle, et al. [I-D.ietf-dime-erp]. AAA transport of EAP
messages is specified in [RFC4072]. Key transport also can be
performed through a AAA protocol. Zorn, Wu & Cakulev
[I-D.ietf-dime-local-keytran] specifies a set of Attribute-Value
Pairs (AVPs) providing native Diameter support of cryptographic key
delivery.
8. IANA Considerations
This document does not require any actions by IANA.
9. Security Considerations
This note does not introduce any new security vulnerabilities.
10. Acknowledgments
The authors would like to thank Mark Jones, Zhen Cao, Semyon
Mizikovsky, Stephen Farrell, Ondrej Sury, Richard Barnes, Jari Arkko
and Lionel Morand for their reviews and comments.
11. References
11.1. Normative References
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication
Zorn, et al. Expires July 16, 2012 [Page 17]
Internet-Draft HOKEY Architecture Design January 2012
Protocol (EAP) Early Authentication Problem Statement",
RFC 5836, April 2010.
[I-D.ietf-hokey-rfc5296bis]
Wu, W., Cao, Z., Zorn, G., Shi, Y., and B. He, "EAP
Extensions for EAP Re-authentication Protocol (ERP)",
draft-ietf-hokey-rfc5296bis-06 (work in progress),
November 2011.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of
EAP-Based Keys for Handover and Re-Authentication",
RFC 5749, March 2010.
[RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the
Protocol for Carrying Authentication for Network Access
(PANA)", RFC 5873, May 2010.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011.
[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)",
draft-ietf-hokey-erp-aak-06 (work in progress),
October 2011.
[I-D.ietf-dime-erp]
Bournelle, J., Morand, L., Decugis, S., Wu, W., and G.
Zorn, "Diameter support for EAP Re-authentication Protocol
(ERP)", draft-ietf-dime-erp-07 (work in progress),
September 2011.
Zorn, et al. Expires July 16, 2012 [Page 18]
Internet-Draft HOKEY Architecture Design January 2012
[I-D.ietf-dime-local-keytran]
Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-
Value Pairs for Cryptographic Key Transport",
draft-ietf-dime-local-keytran-14 (work in progress),
August 2011.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
Authors' Addresses
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-0404617
Email: glenzorn@gmail.com
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: bill.wu@huawei.com
Tom Taylor
Huawei Technologies Co., Ltd
Ottawa, Ontario
Canada
Email: tom111.taylor@bell.net
Zorn, et al. Expires July 16, 2012 [Page 19]
Internet-Draft HOKEY Architecture Design January 2012
Yoav Nir
Check Point
5 Hasolelim st.
Tel Aviv 67897
Israel
Email: ynir@checkpoint.com
Katrin Hoeper
Motorola, Inc.
1301 E. Algonquin Road
Schaumburg, IL 60196
USA
Email: khoeper@motorola.com
Sebastien Decugis
INSIDE Secure
41 Parc Club du Golf
Aix-en-Provence 13856
France
Phone: +33 (0)4 42 39 63 00
Email: sdecugis@freediameter.net
Zorn, et al. Expires July 16, 2012 [Page 20]
