draft-ietf-hokey-reauth-ps-02.txt   draft-ietf-hokey-reauth-ps-03.txt 
HOKEY Working Group T. Clancy, Ed. HOKEY Working Group T. Clancy, Ed.
Internet-Draft LTS Internet-Draft LTS
Intended status: Informational July 24, 2007 Intended status: Informational September 10, 2007
Expires: January 25, 2008 Expires: March 13, 2008
Handover Key Management and Re-authentication Problem Statement Handover Key Management and Re-authentication Problem Statement
draft-ietf-hokey-reauth-ps-02 draft-ietf-hokey-reauth-ps-03
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 January 25, 2008. This Internet-Draft will expire on March 13, 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9
7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10
7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Authors 1. Authors
The following authors contributed to the HOKEY problem statement The following authors contributed to the HOKEY problem statement
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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 This document follows the terminology that has been defined in
[RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying]. [RFC3748].
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 and reattaches to another authenticator, the
current EAP keying model requires the peer to engage in a full EAP current EAP keying model requires the peer to engage in a full EAP
exchange with the authentication server in its home domain [RFC3748]. exchange with the authentication server in its home domain [RFC3748].
An EAP conversation with a full EAP method run takes several round An EAP conversation with a full EAP method run takes several round
trips and significant time to complete, causing delays in re- trips and significant time to complete, causing delays in re-
skipping to change at page 6, line 9 skipping to change at page 6, line 9
is several hops away from the peer, causing too much delay in is several hops away from the peer, causing too much delay in
executing the re-authentication. It is desirable to allow a locally executing the re-authentication. It is desirable to allow a locally
reachable server with EAP efficient re-authentication capability with reachable server with EAP efficient re-authentication capability with
which the peer can execute such re-authentication without having to which the peer can execute such re-authentication without having to
involve the original EAP server all the time. An EAP re- involve the original EAP server all the time. An EAP re-
authentication solution defined MUST NOT prevent its extension to a authentication solution defined MUST NOT prevent its extension to a
fast re-authentication protocol that operates between EAP servers, fast re-authentication protocol that operates between EAP servers,
and the defined keying hierarchy MUST be designed such that this and the defined keying hierarchy MUST be designed such that this
could be supported. could be supported.
Lastly, a re-authentication protocol should also be capable of
supporting handover keying. Handover keying allows re-authentication
keys to be passed to a different domain. Execution of the re-
authentication protocol in that domain will then allow handover from
one domain to another.
These problems are the primary issue to be resolved. In solving These problems are the primary issue 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
skipping to change at page 11, line 33 skipping to change at page 11, line 40
[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
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007. progress), February 2007.
10.2. Informative References
[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. 10 change blocks. 
10 lines changed or deleted 16 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/