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/ |