Network Working Group Q. Wu
Internet-Draft Huawei
Intended status: Standards Track K. Hoeper
Expires: April 22, 2010 Motorola
S. Decugis
NICT
G. Zorn
Network Zen
October 19, 2009
HOKEY Architecture Design
draft-hoeper-hokey-arch-design-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Wu, et al. Expires April 22, 2010 [Page 1]
Internet-Draft HOKEY Architecture Design October 2009
Abstract
This document describes deployment scenarios of HOKEY architectures
in the wireless environment. The design objectives and main
components of HOKEY architecture are identified, and examples of how
the EAP Re-authentication Protocol (ERP) can be integrated into a
HOKEY architecture are discussed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Enhance deployment scalability . . . . . . . . . . . . . . 4
3.2. Lower communication overhead . . . . . . . . . . . . . . . 5
4. HOKEY Architecture Design . . . . . . . . . . . . . . . . . . 5
4.1. System Overview . . . . . . . . . . . . . . . . . . . . . 6
4.2. EAP based handover Key Management . . . . . . . . . . . . 7
4.2.1. Handover Key Derivation . . . . . . . . . . . . . . . 7
4.2.2. Handover Key Distribution . . . . . . . . . . . . . . 7
4.3. EAP Authentication . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Full ERP authentication . . . . . . . . . . . . . . . 7
4.3.2. Local ERP authentication . . . . . . . . . . . . . . . 7
4.3.3. Early EAP authentication . . . . . . . . . . . . . . . 7
4.4. Local Domain Name Discovery . . . . . . . . . . . . . . . 7
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8
5.1. Scenario 1: Home Network HOKEY Service . . . . . . . . . . 8
5.2. Scenario 2: Visited network HOKEY Service . . . . . . . . 8
5.3. Scenario 3: Roaming Case . . . . . . . . . . . . . . . . . 9
6. ERP Integration with HOKEY Architecture . . . . . . . . . . . 9
6.1. Combine Full EAP Auth with Local ERP Auth . . . . . . . . 10
6.2. Combine Full ERP Auth with Local ERP Auth . . . . . . . . 11
6.3. Combine Local domain name discovery with Local ERP Auth . 12
7. HOKEY Authorization . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Wu, et al. Expires April 22, 2010 [Page 2]
Internet-Draft HOKEY Architecture Design October 2009
1. Introduction
The Extensible Authentication Protocol (EAP) defined in [RFC3748] is
an authentication framework that supports different types of
authentication methods which are defined in EAP methods. Originally
designed for dial up connections, EAP is now commonly used for
authentications in wireless access networks. To allow faster re-
authentications of previously authenticated peers, the EAP Re-
authentication Protocol (ERP) was defined in [RFC5296]. ERP supports
two forms of bootstrapping, i.e., "implicit bootstrapping" and
"explicit bootstrapping". Both forms of bootstrapping are used to
derive EAP-based root keys for re-authentication and transport them
to the local server that requested a root key for protecting re-
authentication services to a peer. Thus, ERP can be directly
performed between a peer and the local server this peer is attached
to without the need to communicate with the peer's home server in the
home domain.
[I-D.ietf-hokey-preauth-ps] 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
complete all EAP related communication in prepartion for the Handover
including AAA signaling before the mobile device moves.
Both of these method-independent optimized authentication protocols
enable fast inter-authenticator handovers. However, currently it is
unclear how the necessary handover infrastructure is deployed and can
be integrated into existing EAP infrastructures. In particular, it
still needs to be defined where EAP re-authentication (ER) servers
are placed in the network and how they can be integrated with the
local as well as the home domain network to allow optmized
communication overhead during handovers and better scalability. This
document focuses on providing deployment scenarios of HOKEY
architecture and HOKEY architecture design in the wireless
environment. The design objectives for HOKEY architecture and main
components of HOKEY architecture will be discussed, and examples of
how ERP and early authentication can be integrated into HOKEY
architecture will be taken into account.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Wu, et al. Expires April 22, 2010 [Page 3]
Internet-Draft HOKEY Architecture Design October 2009
In addition, the following terms are defined:
Early Authentication Service
Use of EAP by a mobile peer to establish authenticated keying
material on a target attachment point prior to its arrival.
Re-authentication Service
Use of ERP by a mobile peer to make already existing keying
material available to the target attachment point and use it for
re-authentication during the handover.
ER Server
A logical entity that performs the server portion of ERP and may
be co-located with an EAP or AAA server, see [RFC5296].
HOKEY Service
Re-authentication service provided by the ER server to the peer or
early authentication service provided by the EAP server to the
peer.
HkSh Home HOKEY Service
Re-authentication service provided by the home server with ERP
support in the home domain to the peer.
Hksv Visited HOKEY Service
Re-authentication service provided by the local server with ERP
support in the visited domain of the peer.
3. Design Goals
This section investigates the fundamental design goals for HOKEY
architectures. The general goals for HOKEY architecture design are
to enhance the deployment scalability and lower the complexity of
signaling overhead.
3.1. Enhance deployment scalability
Ideally, whenever a peer performs a handover, ERP can be executed
between the peer and a local ER server, thus, reducing handover
latency by avoiding a full EAP authentication with the peer's home
EAP server. In order for this to work, ERP bootstrapping must occur
Wu, et al. Expires April 22, 2010 [Page 4]
Internet-Draft HOKEY Architecture Design October 2009
before (implicit) or during (explicit) a handover. Implicit
bootstrapping requires the discovery of potential targets including,
in case of inter-domain handovers, other local domain names.
Explicit bootstrapping, on the other hand, requires the local ER
server to contact the peer's home ER server. Note that these
discovery capabilities cannot be provided by EAP and typically depend
on lower layer announcements. Due to bootstrapping issues in inter-
domain handovers, early authentication can be better suited for such
handovers. In order to enhance deployment scalability and
flexibility, upon entering a new domain, early authentication or re-
authentication via ERP should be coupled with implicit ERP
bootstrapping to enable seamless transition from inter-domain
handovers to intra-domain handovers.
3.2. Lower communication overhead
Full EAP exchanges or method specific re-authentication schemes (such
as EAP-AKA's fast authentication) take at least two message round
trips between a peer and its home EAP server. In order to achieve
low latency handovers, there is a need for a method-independent re-
authentication protocol that completes in less than two round trips,
e.g., ERP takes only one round trip to complete. Ideally, no
communication with the home EAP and ER servers should be necessary
and instead a peer only communicates with a local servers. The
authentication and authorization needs interaction with a central
authority (such as an AAA server) in a domain in most cases. However
the central authority may be placed far away from the mobile peer.
In order to lower signaling exchange complexity, the communications
with the central authority should be minimized as well.
4. HOKEY Architecture Design
Wu, et al. Expires April 22, 2010 [Page 5]
Internet-Draft HOKEY Architecture Design October 2009
4.1. System Overview
+---------------------------------------------------------+
|HOKEY Architecture |
| +-----------------------------+ |
| |HOKEY Key Management | |
|+-------------+ |+------------+ +------------+| |
||LDN Discovery|--->Handover Key| |Handover Key|| |
|+-------------+ || Derivation | |Distribution|| |
| |+------------+ +------------+| |
| +-----/\------------------/\--+ |
| || || |
| || || |
|+----------------------\/------+ || |
|| HOKEY Authen | || |
|| +--------------------------+ | +------\/-----------+|
|| |Full ERP Authentication | | |HOKEY Authorization||
|| +--------------------------+ | | +---------------+ ||
|| +------------------------+ | | |Local ER Server| ||
|| |Local ERP Authentication| | | |authorization | ||
|| +------------------------+ | | +---------------+ ||
|| +-------------------------+ | +-------------------+|
|| |Early EAP Authentication | | |
|| +-------------------------+ | |
++------------------------------+-------------------------+
Figure 1 System Overview
The HOKEY architecture is structured as three main EAP-based
components, i.e., EAP based handover key management, HOKEY
authentication using handover key and HOKEY authorization.
The EAP based handover key management is focused on EAP method
independent key derivation and distribution and comprises the
following functional elements:
o Handover key derivation
o Handover key distribution
The HOKEY authentication is focused on the inter-authenticator
handover or inter-technology handover and comprises the following
functional elements:
o Full ERP authentication
Wu, et al. Expires April 22, 2010 [Page 6]
Internet-Draft HOKEY Architecture Design October 2009
o Local ERP authentication
o Early EAP Authentication
4.2. EAP based handover Key Management
4.2.1. Handover Key Derivation
Keying material is derived from the EMSK for inter-authenticator
handover usage.
4.2.2. Handover Key Distribution
The delivery of the EMSK child keys from the server holding the EMSK
or a root key to another network server that requests a root key for
providing protected services (such as re-authentication and other
usage and domain-specific services) to EAP peers. Handover key
distributions support two forms of bootstrapping, implicit ERP
bootstrapping and explicit ERP bootstrapping. In both bootstrapping,
the root key will be distributed from the home server to the local
server.
4.3. EAP Authentication
4.3.1. Full ERP authentication
It is full ERP exchange with the home ER server specified in the
section 5.1 of [RFC5296]. The Local ER server should be present on
the path of full ERP authentication and request DSRK from the home ER
server.
4.3.2. Local ERP authentication
Local ERP authentication is specified in section 3.2. It is ERP
exchange with the local server without EAP method exchange.
4.3.3. Early EAP authentication
EAP Early authentication defined in the [I-D.ietf-hokey-preauth-ps].
4.4. Local Domain Name Discovery
Learn local domain name via the lower layer (e.g., L2 or L3
announcement) or from the EAP-Initiate/ Re-auth-Start message.
Wu, et al. Expires April 22, 2010 [Page 7]
Internet-Draft HOKEY Architecture Design October 2009
5. Deployment Scenarios
5.1. Scenario 1: Home Network HOKEY Service
In this scenario, the HOKEY peer and HOKEY Service are located in the
home network. We refer to this set of services provided by the HOKEY
server as HkSh. As shown in the figure 1, the HOKEY service can be
located in the access network the HOKEY peer uses to connect to the
home network, or it can be located elsewhere.
+------------+ +======+
|Home Network| | HkSh |
+------------+ +======+
/ \
| |
| |
| |
\ /
+----------+
|HOKEY Peer|
+----------+
Figure 1 Home Network HOKEY Service
5.2. Scenario 2: Visited network HOKEY Service
In this scenario, the HOKEY peer is in the visited network and HOKEY
services are provided by the visited network. We refer to this as
HkSv as shown in Figure 2.
+------------+
|Home Network|
+------------+
/ \
| |
| |
\ /
+======+ +---------------+
| HkSv | |Visited Network|
+======+ +---------------+
/ \
| |
| |
| |
\ /
+----------+
|HOKEY Peer|
+----------+
Figure 2 Visited network HOKEY Service
Wu, et al. Expires April 22, 2010 [Page 8]
Internet-Draft HOKEY Architecture Design October 2009
5.3. Scenario 3: Roaming Case
In this scenario, the HOKEY Peer is located in the visited network
and all HOKEY services are provided by both the home network and the
visited network, as shown in Figure 4.
+======+ +------------+
| HkSh | |Home Network|
+======+ +------------+
/ \
| |
| |
\ /
+======+ +---------------+
| HkSv | |Visited Network|
+======+ +---------------+
/ \
| |
| |
| |
\ /
+----------+
|HOKEY Peer|
+----------+
Figure 4 Roaming Case
6. ERP Integration with HOKEY Architecture
Wu, et al. Expires April 22, 2010 [Page 9]
Internet-Draft HOKEY Architecture Design October 2009
6.1. Combine Full EAP Auth with Local ERP Auth
+----+ +----+ +----------------+ +----------+
+----+ |Prev| | New| | AAA Agent | |Home AAA |
|Peer| |NAS | | NAS| |/Local ER Server| |Server/ |
+-+--+ +-+--+ +-+--+ +-------+--------+ |EAP Server|
| | | | +----+-----+
| | | | Transport DSRK |
| | | | rMSK1 to Local |
| Initial Full EAP|authentication | ER Server |
|<------->|<-------+-------------->|<-------------->|
| | Push rMSK1 | |
| | to Prev NAS | |
| | | | |
| Local ERP authentication | |
| /Discovery Local Domain Name | |
|<------->| | | |
| | | | |
| Local|ERP authentication | |
|<--------+------->|<------------->| |
| | | Push rMSK2 | |
| | | to New NAS | |
| | | | |
Figure 5
1. Implicit bootstrapping occurs in the initial full EAP execution
when a peer first attaches to one domain or enters into a new
domain. The bootstrapping is used to transport local root keys
(e.g., DSRK) to the local ER server.
2. Suppose the serving NAS is aware of the local domain name of the
target NAS, then local ERP can be used between the peer and the
serving NAS to request this local domain name for the peer. In
this case, it is out of the scope of this document how the
serving NAS knows the local domain names.
3. When the peer moves to the target NAS, the peer uses the local
domain name received from the serving NAS to perform ERP with the
local ER server without involvement of the home EAP server.
Wu, et al. Expires April 22, 2010 [Page 10]
Internet-Draft HOKEY Architecture Design October 2009
6.2. Combine Full ERP Auth with Local ERP Auth
+----+ +----+ +----------------+ +----------+
+----+ |Prev| | New| | AAA Agent | |Home AAA |
|Peer| |NAS | | NAS| |/Local ER Server| |Server/ |
+-+--+ +-+--+ +-+--+ +-------+--------+ |ER Server |
| | | | +----+-----+
| | | | Transport DSRK |
| Full ERP Auth with Home ER Server| rMSK1 to Local |
| /Local Domain name Discovery | ER Server |
|<------->|<---------------------->|<-------------->|
| | Push rMSK1 | |
| | to Prev NAS | |
| Local ERP Authentication | |
|<---------------->|<------------->| |
| | | Push rMSK2 | |
| | | to New NAS | |
| | | | |
Figure 6
1. Explicit ERP bootstrapping occurs in the initial full
authentication with the home ER server when the peer firstly
attaches to one domain or enters into a new domain. It is used
to re-authenticate the peer in the home domain and transports the
local root key to the local ER server. Also it is used to
request the local domain name for the peer.
2. When the peer associates with the target authenticator, ERP in
the local domain is used to re-authenticate the peer in the local
domain.
Wu, et al. Expires April 22, 2010 [Page 11]
Internet-Draft HOKEY Architecture Design October 2009
6.3. Combine Local domain name discovery with Local ERP Auth
+--------+ +----+ +------+ +---------+ +----------+
+----+ |Prev NAS| | New| |DHCP | |AAA Agent| |Home AAA |
|Peer| |/DHCP | | NAS| |Server| |/Local | |Server/ |
+-+--+ |Client | +-+--+ +--+---+ |ER Server| |ER Server |
| +---+----+ | | +----+----+ +----+-----+
| | | | |Transport DSRK
| | | | |rMSK1 to Local
| Initial Full EAP|authentication |ER Server
|<------->|<------------------------->|<----------->|
| | Push rMSK1 | |
| | to Prev NAS | |
|DCHP Procedure | | |
|/Local Domain Name Discovery | |
|<------->|<-------------->| | |
| | | | | |
| Local ERP Authentication | |
|<---------------->|<---------------->| |
| | | Push rMSK2 | |
| | | to New NAS | |
| | | | | |
Figure 7
1. Implicit bootstrapping occurs in the initial full EAP execution
when the peer first attaches to one domain or enters into a new
domain and is used to transport local root key to the local ER
server.
2. DHCP procedure is used to request local domain name for the peer
and compute re-authentication root keys.
3. When the peer moves to the target NAS and knows the local domain
name, the peer uses this information to perform ERP with the
local ER server without involvement of the home EAP server.
7. HOKEY Authorization
TBD
8. Security Considerations
TBD
Wu, et al. Expires April 22, 2010 [Page 12]
Internet-Draft HOKEY Architecture Design October 2009
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgments
The authors would like to thank all colleagues for their review and
comments of this draft.
11. References
11.1. Normative 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.
[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.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
11.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[I-D.ietf-hokey-preauth-ps]
Wu, et al. Expires April 22, 2010 [Page 13]
Internet-Draft HOKEY Architecture Design October 2009
Wu, Q., Ohba, Y., and G. Zorn, "EAP Early authentication
problem statement", draft-ietf-hokey-preauth-ps-09 (work
in progress), May 2009.
[I-D.ietf-hokey-key-mgm]
Hoeper, K. and Y. Ohba, "Distribution of EAP based keys
for handover and re-authentication",
draft-ietf-hokey-key-mgm-09 (work in progress),
April 2009.
Authors' Addresses
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
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
Wu, et al. Expires April 22, 2010 [Page 14]
Internet-Draft HOKEY Architecture Design October 2009
Glen Zorn
Network Zen
1310 East Thomas Street
Seattle, Washington 98102
+1 (206) 377-9035
Email: gwz@net-zen.net
Wu, et al. Expires April 22, 2010 [Page 15]