draft-ietf-hokey-reauth-ps-04.txt   draft-ietf-hokey-reauth-ps-05.txt 
HOKEY Working Group T. Clancy, Editor HOKEY Working Group T. Clancy, Editor
Internet-Draft LTS Internet-Draft LTS
Intended status: Informational September 28, 2007 Intended status: Informational November 2, 2007
Expires: March 31, 2008 Expires: May 5, 2008
Handover Key Management and Re-authentication Problem Statement Handover Key Management and Re-authentication Problem Statement
draft-ietf-hokey-reauth-ps-04 draft-ietf-hokey-reauth-ps-05
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 31, 2008. This Internet-Draft will expire on May 5, 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 18 skipping to change at page 2, line 18
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6
6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7
6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7
7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8
7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8
7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9
7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9
7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Contributors 1. Contributors
The following authors contributed to the HOKEY problem statement The following authors contributed to the HOKEY problem statement
document: 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
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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].
With respect to EAP, this document follows the terminology that has With respect to EAP, this document follows the terminology that has
been defined in [RFC3748] and [I-D.ietf-eap-keying]. 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 Under the existing model, any re-authentication requires a full EAP
from one authenticator to another, the current model requires the exchange with the EAP server in its home domain [RFC3748]. An EAP
peer to engage in a full EAP exchange with the EAP server in its home conversation with a full EAP method run can take several round trips
domain [RFC3748]. and significant time to complete, causing delays in re-authentication
and handover times. Some methods [RFC4187] specify the use of keys
An EAP conversation with a full EAP method run can take several round and state from the initial authentication to finish subsequent
trips and significant time to complete, causing delays in re- authentications in fewer round trips. However, even in those cases,
authentication and handover times. Some methods [RFC4187] specify multiple round trips to the EAP server are still involved.
the use of keys and state from the initial authentication to finish Furthermore, many commonly-used EAP methods do not offer such a fast
subsequent authentications in fewer round trips. However, even in re-authentication feature. In summary, it is undesirable to have to
those cases, multiple round trips to the EAP server are still run a full EAP method each time a peer authenticates to a new
involved. Furthermore, many commonly-used EAP methods do not offer authenticator or needs to extend its current authentication with the
such a fast re-authentication feature. In summary, it is undesirable same authenticator. Furthermore, it is desirable to specify a
to have to run a full EAP method each time a peer authenticates to a
new authenticator or needs to extend its current authentication with
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.
Significant network latency between the peer and EAP server is Significant network latency between the peer and EAP server is
another source of delay during re-authentication. It is desirable to another source of delay during re-authentication. It is desirable to
have a local server with low-latency connectivity to the peer that have a local server with low-latency connectivity to the peer that
can facilitate re-authentication. can facilitate re-authentication.
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 re-authentication domain (not
authentication protocol in that domain will then allow handover from necessarily a different AAA domain or administrative domain).
one domain to another. Execution of the re-authentication protocol in that re-authentication
domain will then allow handover from one re-authentication domain to
another.
These problems are the primary issues 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:
skipping to change at page 10, line 32 skipping to change at page 10, line 28
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., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-21 (work in progress), October 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. 9 change blocks. 
30 lines changed or deleted 29 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/