draft-ietf-hokey-reauth-ps-06.txt | draft-ietf-hokey-reauth-ps-07.txt | |||
---|---|---|---|---|
HOKEY Working Group T. Clancy, Editor | HOKEY Working Group T. Clancy | |||
Internet-Draft LTS | Internet-Draft LTS | |||
Intended status: Informational November 6, 2007 | Intended status: Informational M. Nakhjiri | |||
Expires: May 9, 2008 | Expires: May 13, 2008 Motorola | |||
V. Narayanan | ||||
L. Dondeti | ||||
Qualcomm | ||||
November 10, 2007 | ||||
Handover Key Management and Re-authentication Problem Statement | Handover Key Management and Re-authentication Problem Statement | |||
draft-ietf-hokey-reauth-ps-06 | draft-ietf-hokey-reauth-ps-07 | |||
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 38 | |||
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 May 9, 2008. | This Internet-Draft will expire on May 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 Extensible Authentication Protocol (EAP) | statement. The current Extensible Authentication Protocol (EAP) | |||
keying framework is not designed to support re-authentication and | keying framework is not designed to support re-authentication and | |||
skipping to change at page 2, line 26 | skipping to change at page 2, line 29 | |||
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 | 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 | |||
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | |||
6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 | 6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 | |||
6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8 | 6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8 | |||
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 | 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 | |||
6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 | 6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 13 | Intellectual Property and Copyright Statements . . . . . . . . . . 13 | |||
1. Introduction | 1. Introduction | |||
The Extensible Authentication Protocol (EAP), specified in RFC 3748 | The Extensible Authentication Protocol (EAP), specified in RFC 3748 | |||
[RFC3748] is a generic framework supporting multiple authentication | [RFC3748] is a generic framework supporting multiple authentication | |||
methods. The primary purpose of EAP is network access control. It | methods. The primary purpose of EAP is network access control. It | |||
also supports exporting session keys derived during the | also supports exporting session keys derived during the | |||
authentication. The EAP keying hierarchy defines two keys that are | authentication. The EAP keying hierarchy defines two keys that are | |||
derived at the top level, the Master Session Key (MSK) and the | derived at the top level, the Master Session Key (MSK) and the | |||
skipping to change at page 9, line 9 | skipping to change at page 9, line 9 | |||
are looking at transitions from one link-layer protocol to another, | are looking at transitions from one link-layer protocol to another, | |||
which is currently beyond the scope of the HOKEY charter. | which is currently beyond the scope of the HOKEY charter. | |||
The techniques developed within HOKEY could be applicable to IEEE | The techniques developed within HOKEY could be applicable to IEEE | |||
802.21 if the necessary issues with handover between different lower | 802.21 if the necessary issues with handover between different lower | |||
layers can be resolved. In particular, pre-authentication may be | layers can be resolved. In particular, pre-authentication may be | |||
more appropriate than re-authentication. | more appropriate than re-authentication. | |||
6.3. CAPWAP Applicability | 6.3. CAPWAP Applicability | |||
The IETF CAPWAP WG [RFC3990] is developing a protocol between what is | The IETF CAPWAP Working Group [RFC3990] is developing a protocol | |||
termed an Access Controller (AC) and Wireless Termination Points | between what is termed an Access Controller (AC) and Wireless | |||
(WTP). The AC and WTP can be mapped to a WLAN switch and Access | Termination Points (WTP). The AC and WTP can be mapped to a WLAN | |||
Point respectively. The CAPWAP model supports both split and | switch and Access Point respectively. The CAPWAP model supports both | |||
integrated MAC architectures, with the authenticator always being | split and integrated MAC architectures, with the authenticator always | |||
implemented at the AC. | being implemented at the AC. | |||
The proposed work on EAP efficient re-authentication protocol | The proposed work on EAP efficient re-authentication protocol | |||
addresses an inter-authenticator handover problem from an EAP | addresses an inter-authenticator handover problem from an EAP | |||
perspective, which applies during handover between ACs. Inter- | perspective, which applies during handover between ACs. Inter- | |||
controller handover is a topic yet to be addressed in great detail | controller handover is a topic yet to be addressed in great detail | |||
and the re-authentication work can potentially address it in an | and the re-authentication work can potentially address it in an | |||
effective manner. | effective manner. | |||
6.4. Inter-Technology Handover | 6.4. Inter-Technology Handover | |||
skipping to change at page 10, line 12 | skipping to change at page 10, line 12 | |||
resistance to attacks based on the domino effect; and authentication | resistance to attacks based on the domino effect; and authentication | |||
and authorization. See section Section 5 for further details. | and authorization. See section Section 5 for further details. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This document does not introduce any new IANA considerations. | This document does not introduce any new IANA considerations. | |||
9. Contributors | 9. Contributors | |||
This document represents the synthesis of two problem statement | This document represents the synthesis of two problem statement | |||
documents. In this section, we acknowledge their contributions. | documents. In this section, we acknowledge their contributions, and | |||
involvement in the early documents. | ||||
Authors of "AAA based Keying for Wireless Handovers: Problem | ||||
Statement" are: | ||||
Madjid Nakhjiri | ||||
Motorola Labs | ||||
Email: madjid.nakhjiri@motorola.com | ||||
Mohan Parthasarathy | Mohan Parthasarathy | |||
Nokia | Nokia | |||
Email: mohan.parthasarathy@nokia.com | Email: mohan.parthasarathy@nokia.com | |||
Julien Bournelle | Julien Bournelle | |||
France Telecom R&D | France Telecom R&D | |||
Email: julien.bournelle@orange-ftgroup.com | Email: julien.bournelle@orange-ftgroup.com | |||
Hannes Tschofenig | Hannes Tschofenig | |||
Siemens | Siemens | |||
Email: Hannes.Tschofenig@siemens.com | Email: Hannes.Tschofenig@siemens.com | |||
Rafael Marin Lopez, Editor | Rafael Marin Lopez | |||
Universidad de Murcia | Universidad de Murcia | |||
Email: rafa@dif.um.es | Email: rafa@dif.um.es | |||
Authors of "Problem Statement on EAP Efficient Re-authentication and | ||||
Key Management" are: | ||||
Vidya Narayanan | ||||
QUALCOMM, Inc. | ||||
Email: vidyan@qualcomm.com | ||||
Lakshminath Dondeti | ||||
QUALCOMM, Inc. | ||||
Email: ldondeti@qualcomm.com | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[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. | |||
skipping to change at page 12, line 5 | skipping to change at page 11, line 32 | |||
information exchange between systems - Local and | information exchange between systems - Local and | |||
metropolitan area networks - Specific requirements - Part | metropolitan area networks - Specific requirements - Part | |||
11: Wireless LAN Medium Access Control (MAC) and Physical | 11: Wireless LAN Medium Access Control (MAC) and Physical | |||
Layer (PHY) specifications - Amendment 2: Fast BSS | Layer (PHY) specifications - Amendment 2: Fast BSS | |||
Transition", IEEE Standard 802.11r, June 2007. | Transition", IEEE Standard 802.11r, June 2007. | |||
[IEEE.802-21] | [IEEE.802-21] | |||
"Media Independent Handover Working Group", IEEE Working | "Media Independent Handover Working Group", IEEE Working | |||
Group 802.21. | Group 802.21. | |||
Author's Address | Authors' Addresses | |||
T. Charles Clancy, Editor | T. Charles Clancy, Editor | |||
DoD Laboratory for Telecommunications Sciences | Laboratory for Telecommunications Sciences | |||
8080 Greenmead Drive | US Department of Defense | |||
College Park, MD 20740 | College Park, MD | |||
USA | USA | |||
Email: clancy@LTSnet.net | Email: clancy@LTSnet.net | |||
Madjid Nakhjiri | ||||
Motorola | ||||
Email: madjid.nakhjiri@motorola.com | ||||
Vidya Narayanan | ||||
Qualcomm, Inc. | ||||
San Diego, CA | ||||
USA | ||||
Email: vidyan@qualcomm.com | ||||
Lakshminath Dondeti | ||||
Qualcomm, Inc. | ||||
San Diego, CA | ||||
USA | ||||
Email: ldondeti@qualcomm.com | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
End of changes. 13 change blocks. | ||||
38 lines changed or deleted | 43 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/ |