draft-ietf-hokey-reauth-ps-03.txt   draft-ietf-hokey-reauth-ps-04.txt 
HOKEY Working Group T. Clancy, Ed. HOKEY Working Group T. Clancy, Editor
Internet-Draft LTS Internet-Draft LTS
Intended status: Informational September 10, 2007 Intended status: Informational September 28, 2007
Expires: March 13, 2008 Expires: March 31, 2008
Handover Key Management and Re-authentication Problem Statement Handover Key Management and Re-authentication Problem Statement
draft-ietf-hokey-reauth-ps-03 draft-ietf-hokey-reauth-ps-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2008. This Internet-Draft will expire on March 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the Handover Keying (HOKEY) problem This document describes the Handover Keying (HOKEY) problem
statement. The current EAP keying framework is not designed to statement. The current EAP keying framework is not designed to
support re-authentication and handovers. This often cause support re-authentication and handovers. This often cause
unacceptable latency in various mobile wireless environments. HOKEY unacceptable latency in various mobile wireless environments. HOKEY
plans to address these HOKEY plans to address these problems by plans to address these HOKEY plans to address these problems by
implementing a generic mechanism to reuse derived EAP keying material implementing a generic mechanism to reuse derived EAP keying material
for handover. for handover.
Table of Contents Table of Contents
1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6
6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7
6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8
7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8
7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9
7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9
7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Authors 1. Contributors
The following authors contributed to the HOKEY problem statement The following authors contributed to the HOKEY problem statement
draft: document:
o Julien Bournelle, France Telecom R&D, o Julien Bournelle, France Telecom R&D,
julien.bournelle@orange-ftgroup.com julien.bournelle@orange-ftgroup.com
o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com
o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es
o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com o Madjid Nakhjiri, Motorola, madjid.nakhjiri@motorola.com
o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com
o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com
o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com
2. Introduction 2. Introduction
The extensible authentication protocol (EAP), specified in [RFC3748] The Extensible Authentication Protocol (EAP), specified in RFC 3748
is a generic framework supporting multiple authentication methods. [RFC3748] is a generic framework supporting multiple authentication
The primary purpose of EAP is network access control. It also methods. The primary purpose of EAP is network access control. It
supports exporting session keys derived during the authentication. also supports exporting session keys derived during the
The EAP keying hierarchy defines two keys that are derived at the top authentication. The EAP keying hierarchy defines two keys that are
level, the master session key (MSK) and the extended MSK (EMSK). derived at the top level, the master session key (MSK) and the
extended MSK (EMSK).
In many common deployment scenario, an EAP peer and EAP server In many common deployment scenario, an EAP peer and EAP server
authenticate each other through a third party known as the pass- authenticate each other through a third party known as the pass-
through authenticator (hereafter referred to as simply through authenticator (hereafter referred to as simply
"authenticator"). The authenticator is responsible for translating "authenticator"). The authenticator is responsible for translating
EAP packets from the layer 2 (L2) or layer 3 (L3) network access EAP packets from the layer 2 (L2) or layer 3 (L3) network access
technology to the AAA protocol. technology to the AAA protocol.
According to [RFC3748], after successful authentication, the server According to [RFC3748], after successful authentication, the server
transports the MSK to the authenticator. The underlying L2 or L3 transports the MSK to the authenticator. The underlying L2 or L3
protocol uses the MSK to derive additional keys, including the protocol uses the MSK to derive additional keys, including the
transient session keys (TSK) used per-packet access encryption and transient session keys (TSK) used per-packet access encryption and
enforcement. Figure Figure 1 depicts this process. enforcement.
+--------+ +---------+ +--------+
| EAP |<----->| Authen- |<------------------->| EAP |
| Client | L2/L3 | ticator | AAA | Server |
+--------+ +---------+ +--------+
^ ^
| +---------+ |
\-------------------------->| Authen- |<--------/
L2/L3 | ticator | AAA
+---------+
Initial Authentication:
<----------------- EAP Authentication ------------->
<------ MSK Transport -------------
<- TSK Generation ->
Re-Authentication / Handover:
<----------------- EAP Authentication ------------->
<- MSK Transport -
<---------- TSK Generation --------->
Figure 1: Logical diagram of EAP authentication and key derivation
using passthrough authenticator
Note that while the authenticator is one logical device, there can be Note that while the authenticator is one logical device, there can be
many physical devices involved. For example, in the CAPWAP model multiple physical devices involved. For example, the CAPWAP model
[RFC3990] WTPs communicate using L2 protocols with the EAP client and [RFC3990] splits authenticators into two logical devices: Wireless
ACs communicate using AAA to the EAP server, while using CAPWAP Termination Points (WTPs) and Access Controllers (ACs). Depending on
protocols to communicate with each other. Depending on the the configuration, authenticator features can be split in a variety
configuration, authenticator features can be split in a variety of of ways between physical devices, however from the EAP perspective
ways between physical devices, however from the EAP perspective there there is only one logical authenticator.
is only one logical authenticator.
The current models of EAP authentication and keying are unfortunately The current models of EAP authentication and keying are unfortunately
not efficient in case of mobile and wireless networks. When a peer not efficient in case of mobile and wireless networks. When a peer
arrives at the new authenticator, or is expected to re-affirm its arrives at the new authenticator, or is expected to re-affirm its
access through the current authenticator, the security restraints access through the current authenticator, the security restraints
will require the peer to run an EAP method irrespective of whether it will require the peer to run an EAP method irrespective of whether it
has been authenticated to the network recently and has unexpired has been authenticated to the network recently and has unexpired
keying material. A full EAP method execution involves several round keying material. A full EAP method execution may involves several
trips between the EAP peer and the server. round trips between the EAP peer and the server.
There have been attempts to solve the problem of efficient re- There have been attempts to solve the problem of efficient re-
authentication in various ways. However, those solutions are either authentication in various ways. However, those solutions are either
EAP-method specific, EAP lower-layer specific, or are otherwise EAP-method specific, EAP lower-layer specific, or are otherwise
limited in scope. Furthermore, these solutions do not deal with limited in scope. Furthermore, these solutions do not deal with
scenarios involving handovers to new authenticators, or do not scenarios involving handovers to new authenticators, or do not
conform to the AAA keying requirements specified in [RFC4962]. conform to the AAA keying requirements specified in [RFC4962].
This document provides a detailed description of EAP efficient re- This document provides a detailed description of EAP efficient re-
authentication protocol requirements. authentication protocol requirements.
3. Terminology 3. Terminology
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
This document follows the terminology that has been defined in With respect to EAP, this document follows the terminology that has
[RFC3748]. been defined in [RFC3748] and [I-D.ietf-eap-keying].
4. Problem Statement 4. Problem Statement
When a peer needs to re-affirm access to an authenticator or moves When a peer needs to re-affirm access to an authenticator or moves
from one authenticator and reattaches to another authenticator, the from one authenticator to another, the current model requires the
current EAP keying model requires the peer to engage in a full EAP peer to engage in a full EAP exchange with the EAP server in its home
exchange with the authentication server in its home domain [RFC3748]. domain [RFC3748].
An EAP conversation with a full EAP method run takes several round An EAP conversation with a full EAP method run can take several round
trips and significant time to complete, causing delays in re- trips and significant time to complete, causing delays in re-
authentication and handover times. Some methods [RFC4187] specify authentication and handover times. Some methods [RFC4187] specify
the use of keys and state from the initial authentication to finish the use of keys and state from the initial authentication to finish
subsequent authentications in fewer round trips. However, even in subsequent authentications in fewer round trips. However, even in
those cases, several round trips to the EAP server are still those cases, multiple round trips to the EAP server are still
involved. Furthermore, many commonly-used EAP methods do not offer involved. Furthermore, many commonly-used EAP methods do not offer
such a fast re-authentication feature. In summary, it is undesirable such a fast re-authentication feature. In summary, it is undesirable
to have to run a full EAP method each time a peer associates with a to have to run a full EAP method each time a peer authenticates to a
new authenticator or needs to extend its current association with the new authenticator or needs to extend its current authentication with
same authenticator. Furthermore, it is desirable to specify a the same authenticator. Furthermore, it is desirable to specify a
method-independent, efficient, re-authentication protocol. Keying method-independent, efficient, re-authentication protocol. Keying
material from the full authentication can be used to enable efficient material from the full authentication can be used to enable efficient
re-authentication. re-authentication.
Another problem with respect to authentication is when the EAP server Significant network latency between the peer and EAP server is
is several hops away from the peer, causing too much delay in another source of delay during re-authentication. It is desirable to
executing the re-authentication. It is desirable to allow a locally have a local server with low-latency connectivity to the peer that
reachable server with EAP efficient re-authentication capability with can facilitate re-authentication.
which the peer can execute such re-authentication without having to
involve the original EAP server all the time. An EAP re-
authentication solution defined MUST NOT prevent its extension to a
fast re-authentication protocol that operates between EAP servers,
and the defined keying hierarchy MUST be designed such that this
could be supported.
Lastly, a re-authentication protocol should also be capable of Lastly, a re-authentication protocol should also be capable of
supporting handover keying. Handover keying allows re-authentication supporting handover keying. Handover keying allows re-authentication
keys to be passed to a different domain. Execution of the re- keys to be passed to a different domain. Execution of the re-
authentication protocol in that domain will then allow handover from authentication protocol in that domain will then allow handover from
one domain to another. one domain to another.
These problems are the primary issue to be resolved. In solving These problems are the primary issues to be resolved. In solving
them, there are a number of constraints to conform to and those them, there are a number of constraints to conform to and those
result in some additional work to be done in the area of EAP keying. result in some additional work to be done in the area of EAP keying.
5. Design Goals 5. Design Goals
The following are the goals and constraints in designing the EAP re- The following are the goals and constraints in designing the EAP re-
authentication and key management protocol: authentication and key management protocol:
Lower latency operation: The protocol MUST be responsive to handover Lower latency operation: The protocol MUST be responsive to handover
and re-authentication latency performance objectives within a and re-authentication latency performance objectives within a
skipping to change at page 6, line 47 skipping to change at page 6, line 9
required as a result of the re-authentication protocol. There required as a result of the re-authentication protocol. There
MUST be no requirements imposed on future EAP methods. Note that MUST be no requirements imposed on future EAP methods. Note that
the only EAP methods for which independence is required are those the only EAP methods for which independence is required are those
that conform to the specifications of [I-D.ietf-eap-keying] and that conform to the specifications of [I-D.ietf-eap-keying] and
[RFC4017]. [RFC4017].
AAA protocol compatibility and keying: Any modifications to EAP and AAA protocol compatibility and keying: Any modifications to EAP and
EAP keying MUST be compatible with RADIUS and Diameter. EAP keying MUST be compatible with RADIUS and Diameter.
Extensions to both RADIUS and Diameter to support these EAP Extensions to both RADIUS and Diameter to support these EAP
modifications are acceptable. The designs and protocols must modifications are acceptable. The designs and protocols must
satisfy the AAA key management requirements specified in satisfy the AAA key management requirements specified in RFC 4962
[RFC4962]. [RFC4962].
Compatability: Compatibility and co-existence with compliant Compatability: Compatibility and co-existence with compliant
([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
provided. The keying hierarchy or protocol extensions MUST NOT provided. The keying hierarchy or protocol extensions MUST NOT
preclude the use of CAPWAP or IEEE 802.11r. preclude the use of CAPWAP or IEEE 802.11r.
6. Security Goals 6. Security Goals
The section draws from the guidance provided in [RFC4962] to further The section draws from the guidance provided in [RFC4962] to further
skipping to change at page 11, line 28 skipping to change at page 10, line 32
and authorization. See section Section 6 for further details. and authorization. See section Section 6 for further details.
9. IANA Considerations 9. IANA Considerations
This document does not introduce any new IANA considerations. This document does not introduce any new IANA considerations.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
10.2. Informative References 10.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
Provisioning for Wireless Access Points (CAPWAP) Problem Provisioning for Wireless Access Points (CAPWAP) Problem
Statement", RFC 3990, February 2005. Statement", RFC 3990, February 2005.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[IEEE.802-11R-D7.0] [IEEE.802-11R-D7.0]
"Information technology - Telecommunications and "Information technology - Telecommunications and
 End of changes. 25 change blocks. 
97 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/