draft-ietf-hokey-reauth-ps-07.txt | draft-ietf-hokey-reauth-ps-08.txt | |||
---|---|---|---|---|
HOKEY Working Group T. Clancy | HOKEY Working Group T. Clancy | |||
Internet-Draft LTS | Internet-Draft LTS | |||
Intended status: Informational M. Nakhjiri | Intended status: Informational M. Nakhjiri | |||
Expires: May 13, 2008 Motorola | Expires: August 13, 2008 Motorola | |||
V. Narayanan | V. Narayanan | |||
L. Dondeti | L. Dondeti | |||
Qualcomm | Qualcomm | |||
November 10, 2007 | February 10, 2008 | |||
Handover Key Management and Re-authentication Problem Statement | Handover Key Management and Re-authentication Problem Statement | |||
draft-ietf-hokey-reauth-ps-07 | draft-ietf-hokey-reauth-ps-08 | |||
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 38 | 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 13, 2008. | This Internet-Draft will expire on August 13, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
Abstract | Abstract | |||
This document describes the Handover Keying (HOKEY) problem | This document describes the Handover Keying (HOKEY) re-authentication | |||
statement. The current Extensible Authentication Protocol (EAP) | problem statement. The current Extensible Authentication Protocol | |||
keying framework is not designed to support re-authentication and | (EAP) keying framework is not designed to support re-authentication | |||
handovers. This often causes unacceptable latency in various mobile | and handovers without re-executing an EAP method. This often causes | |||
wireless environments. The HOKEY Working Group plans to address | unacceptable latency in various mobile wireless environments. This | |||
these problems by designing a generic mechanism to reuse derived EAP | document details the problem and defines design goals for a generic | |||
keying material for handover. | mechanism to reuse derived EAP keying material for handover. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 | 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 | |||
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 6 | 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 6 | 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 | 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 | 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | |||
6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 | 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 8 | |||
6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8 | 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 | |||
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 | 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 | |||
6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | ||||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 15 | ||||
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 | |||
Extended Master Session Key (EMSK). | Extended Master Session Key (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 encapsulating | |||
EAP packets from the layer 2 (L2) or layer 3 (L3) network access | EAP packets from a network access technology lower layer within the | |||
technology to the Authentication, Authorization, and Accounting (AAA) | Authentication, Authorization, and Accounting (AAA) protocol. The | |||
protocol. The authenticator does not directly participate in the EAP | authenticator does not directly participate in the EAP exchange, and | |||
exchange, and simply acts as a gateway during the EAP method | simply acts as a gateway during the EAP method execution. | |||
execution. | ||||
According to [RFC3748], after successful authentication, the server | After successful authentication, the EAP server transports the MSK to | |||
to transports the MSK to the authenticator. Note that this is | the authenticator. Note that this is performed using AAA protocols, | |||
performed using AAA protocols, not EAP itself. The underlying L2 or | not EAP itself. The underlying L2 or L3 protocol uses the MSK to | |||
L3 protocol uses the MSK to derive additional keys, including the | derive additional keys, including the transient session keys (TSKs) | |||
transient session keys (TSKs) used for per-packet encryption and | used for per-packet encryption and authentication. | |||
authentication. | ||||
Note that while the authenticator is one logical device, there can be | Note that while the authenticator is one logical device, there can be | |||
multiple physical devices involved. For example, the CAPWAP model | multiple physical devices involved. For example, the CAPWAP model | |||
[RFC3990] splits authenticators into two logical devices: Wireless | [RFC3990] splits authenticators into two logical devices: Wireless | |||
Termination Points (WTPs) and Access Controllers (ACs). Depending on | Termination Points (WTPs) and Access Controllers (ACs). Depending on | |||
the configuration, authenticator features can be split in a variety | the configuration, authenticator features can be split in a variety | |||
of ways between physical devices, however from the EAP perspective | of ways between physical devices, however from the EAP perspective | |||
there is only one logical authenticator. | there is only one logical authenticator. | |||
The current models of EAP authentication and keying are unfortunately | The current models of EAP authentication and keying are frequently | |||
not efficient in cases where the peer is a mobile device. When a | not efficient in cases where the peer is a mobile device | |||
peer arrives at the new authenticator, the security restraints will | [MSA03][KP01]. In existing implementations, when a peer arrives at | |||
require the peer to run an EAP method irrespective of whether it has | the new authenticator, it runs an EAP method irrespective of whether | |||
been authenticated to the network recently and has unexpired keying | it has been authenticated to the network recently and has unexpired | |||
material. A full EAP method execution may involve several round | keying material. A full EAP method execution involves an EAP- | |||
trips between the EAP peer and the server. | Response/Identity message from the peer to server, followed by one or | |||
more round trips between the EAP server and peer to perform the | ||||
authentication, followed by the EAP-Success or EAP-Failure message | ||||
from the EAP server to peer. At a minimum, the peer has 2 round | ||||
trips with the EAP 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 or EAP lower-layer specific. Furthermore, these | |||
limited in scope. Furthermore, these solutions do not deal with | solutions do not deal with scenarios involving handovers to new | |||
scenarios involving handovers to new authenticators, or do not | authenticators, or do not conform to the AAA keying requirements | |||
conform to the AAA keying requirements specified in [RFC4962]. | specified in [RFC4962]. | |||
This document provides a detailed description of efficient EAP-based | This document provides a detailed description of efficient EAP-based | |||
re-authentication protocol requirements. | re-authentication protocol design goals. The scope of this protocol | |||
is specifically re-authentication and handover between authenticators | ||||
within a single administrative domain. Inter-technology handover and | ||||
inter-administrative-domain handover are outside the scope of this | ||||
protocol. | ||||
2. Terminology | 2. 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], with the | |||
qualification that unless otherwise stated they apply to the design | ||||
of the re-authentication protocol, not its implementation or | ||||
application. | ||||
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]. | |||
3. Problem Statement | 3. Problem Statement | |||
Under the existing model, any re-authentication requires a full EAP | Under the existing model, any re-authentication requires a full EAP | |||
exchange with the EAP server in its home domain [RFC3748]. An EAP | exchange with the EAP server to which the peer initially | |||
conversation with a full EAP method run can take several round trips | authenticated [RFC3748]. This introduces handover latency from both | |||
and significant time to complete, causing delays in re-authentication | network transit time and processing delay. In service provider | |||
and handover times. Some methods [RFC4187] specify the use of keys | networks, the home EAP server for a peer could be on the other side | |||
and state from the initial authentication to finish subsequent | of the world, and typical intercontinental latencies across the | |||
authentications in fewer round trips. However, even in those cases, | Internet are 100 to 300 milliseconds per round trip [LGS07]. | |||
multiple round trips to the EAP server are still involved. | Processing delays average a couple of milliseconds for symmetric-key | |||
Furthermore, many commonly-used EAP methods do not offer such a fast | operations and hundreds of milliseconds for public-key operations. | |||
re-authentication feature. In summary, it is undesirable 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 | ||||
material from the full authentication can be used to enable efficient | ||||
re-authentication. | ||||
Significant network latency between the peer and EAP server is | An EAP conversation with a full EAP method run can take two or more | |||
another source of delay during re-authentication. It is desirable to | round trips and to complete, causing delays in re-authentication and | |||
have a local server with low-latency connectivity to the peer that | handover times. Some methods specify the use of keys and state from | |||
can facilitate re-authentication. | the initial authentication to finish subsequent authentications in | |||
fewer round trips and without using public-key operations (detailed | ||||
Section 6.1). However, even in those cases, multiple round trips to | ||||
the EAP server are required, resulting in unacceptable handover | ||||
times. | ||||
Lastly, a re-authentication protocol should also be capable of | In summary, it is undesirable to run an EAP Identity and complete EAP | |||
supporting handover keying. Handover keying allows an EAP server to | method exchange each time a peer authenticates to a new authenticator | |||
pass authentication information to a remote re-authentication server, | or needs to extend its current authentication with the same | |||
allowing a peer to re-authenticate to that re-authentication server | authenticator. Furthermore, it is desirable to specify a method- | |||
without having to communicate with its home re-authentication server. | independent, efficient, re-authentication protocol. Keying material | |||
from the initial authentication can be used to enable efficient re- | ||||
authentication. It is also desirable to have a local server with | ||||
low-latency connectivity to the peer that can facilitate re- | ||||
authentication. Lastly, a re-authentication protocol should also be | ||||
capable of supporting scenarios where an EAP server passes | ||||
authentication information to a remote re-authentication server, | ||||
allowing a peer to re-authenticate locally without having to | ||||
communicate with its home re-authentication server. | ||||
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. | |||
4. Design Goals | 4. 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 | |||
mobile access network. A solution that reduces latency as | mobile access network. A solution that reduces latency as | |||
compared to a full EAP authentication will be most favorable. | compared to a full EAP authentication will be most favorable, | |||
since in networks that rely on reactive re-authentication this | ||||
will directly impact handover times. | ||||
EAP lower-layer independence: Any keying hierarchy and protocol | EAP lower-layer independence: Any keying hierarchy and protocol | |||
defined MUST be lower layer independent in order to provide the | defined MUST be lower layer independent in order to provide | |||
capability over heterogeneous technologies. The defined protocols | capabilities over heterogeneous technologies. The defined | |||
MAY require some additional support from the lower layers that use | protocols MAY require some additional support from the lower | |||
it. Any keying hierarchy and protocol defined MUST accommodate | layers that use it, but should not require any particular lower | |||
inter-technology heterogeneous handover. | layer. | |||
EAP method independence: Changes to existing EAP methods MUST NOT be | EAP method independence: Changes to existing EAP methods MUST NOT be | |||
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, provided | |||
the only EAP methods for which independence is required are those | they satisfy [I-D.ietf-eap-keying] and [RFC4017]. Note that the | |||
that conform to the specifications of [I-D.ietf-eap-keying] and | only EAP methods for which independence is required are those that | |||
[RFC4017]. | currently conform to the specifications of [I-D.ietf-eap-keying] | |||
and [RFC4017]. In particular, methods that do not generate the | ||||
keys required by [I-D.ietf-eap-keying] need not be supported by | ||||
the re-authentication protocol. | ||||
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 [I-D.ietf-radext-design] | |||
Extensions to both RADIUS and Diameter to support these EAP | and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both | |||
modifications are acceptable. The designs and protocols must | RADIUS and Diameter to support these EAP modifications are | |||
acceptable. The designs and protocols must be configurable to | ||||
satisfy the AAA key management requirements specified in RFC 4962 | satisfy the AAA key management requirements specified in RFC 4962 | |||
[RFC4962]. | [RFC4962]. | |||
Compatability: Compatibility and co-existence with compliant | Compatibility: 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. Specifically, the protocol should be designed such that | |||
preclude the use of CAPWAP or IEEE 802.11r. | fall back to EAP authentication occurs if not all devices in the | |||
network support fast re-authentication. | ||||
Cryptographic Agility: Any re-authentication protocol MUST support | ||||
cryptographic algorithm agility, to avoid hard-coded primitives | ||||
whose security may eventually prove to be compromised. The | ||||
protocol MAY support cryptographic algorithm negotiation, provided | ||||
it does not adversely affect overall performance (i.e. by | ||||
requiring additional round trips). | ||||
5. Security Goals | 5. Security Goals | |||
The section draws from the guidance provided in [RFC4962] to further | The section draws from the guidance provided in [RFC4962] to further | |||
define the security goals to be achieved by a complete re- | define the security goals to be achieved by a complete re- | |||
authentication keying solution. | authentication keying solution. | |||
5.1. Key Context and Domino Effect | 5.1. Key Context and Domino Effect | |||
Any key MUST have a well-defined scope and MUST be used in a specific | Any key must have a well-defined scope and must be used in a specific | |||
context and for the intended use. This specifically means the | context and for the intended use. This specifically means the | |||
lifetime and scope of each key MUST be defined clearly so that all | lifetime and scope of each key must be defined clearly so that all | |||
entities that are authorized to have access to the key have the same | entities that are authorized to have access to the key have the same | |||
context during the validity period. In a hierarchical key structure, | context during the validity period. In a hierarchical key structure, | |||
the lifetime of lower level keys MUST NOT exceed the lifetime of | the lifetime of lower level keys must not exceed the lifetime of | |||
higher level keys. This requirement MAY imply that the context and | higher level keys. This requirement may imply that the context and | |||
the scope parameters have to be exchanged. Furthermore, the | the scope parameters have to be exchanged. Furthermore, the | |||
semantics of these parameters MUST be defined to provide proper | semantics of these parameters must be defined to provide proper | |||
channel binding specifications. The definition of exact parameter | channel binding specifications. The definition of exact parameter | |||
syntax definition is part of the design of the transport protocol | syntax definition is part of the design of the transport protocol | |||
used for the parameter exchange and that may be outside scope of this | used for the parameter exchange and that may be outside scope of this | |||
protocol. | protocol. | |||
If a key hierarchy is deployed, compromising lower level keys MUST | If a key hierarchy is deployed, compromising lower level keys must | |||
NOT result in a compromise of higher level keys which they were used | not result in a compromise of higher level keys which were used to | |||
to derive the lower level keys. The compromise of keys at each level | derive the lower level keys. The compromise of keys at each level | |||
MUST NOT result in compromise of other keys at the same level. The | must not result in compromise of other keys at the same level. The | |||
same principle applies to entities that hold and manage a particular | same principle applies to entities that hold and manage a particular | |||
key defined in the key hierarchy. Compromising keys on one | key defined in the key hierarchy. Compromising keys on one | |||
authenticator MUST NOT reveal the keys of another authenticator. | authenticator must not reveal the keys of another authenticator. | |||
Note that the compromise of higher-level keys has security | Note that the compromise of higher-level keys has security | |||
implications on lower levels. | implications on lower levels. | |||
Guidance on parameters required, caching, storage and deletion | Guidance on parameters required, caching, storage and deletion | |||
procedures to ensure adequate security and authorization provisioning | procedures to ensure adequate security and authorization provisioning | |||
for keying procedures MUST be defined in a solution document. | for keying procedures must be defined in a solution document. | |||
All the keying material MUST be uniquely named so that it can be | All the keying material must be uniquely named so that it can be | |||
managed effectively. | managed effectively. | |||
5.2. Key Freshness | 5.2. Key Freshness | |||
As [RFC4962] defines, a fresh key is one that is generated for the | As [RFC4962] defines, a fresh key is one that is generated for the | |||
intended use. This would mean the key hierarchy MUST provide for | intended use. This would mean the key hierarchy must provide for | |||
creation of multiple cryptographically separate child keys from a | creation of multiple cryptographically separate child keys from a | |||
root key at higher level. Furthermore, the keying solution needs to | root key at higher level. Furthermore, the keying solution needs to | |||
provide mechanisms for refreshing each of the keys within the key | provide mechanisms for refreshing each of the keys within the key | |||
hierarchy. | hierarchy. | |||
5.3. Authentication | 5.3. Authentication | |||
Each party in the handover keying architecture MUST be authenticated | Each handover keying participant must be authenticated to any other | |||
to any other party with whom it communicates, and securely provide | party with whom it communicates to the extent it is necessary to | |||
its identity to any other entity that may require the identity for | ensure proper key scoping, and securely provide its identity to any | |||
defining the key scope. The identity provided MUST be meaningful | other entity that may require the identity for defining the key | |||
according to the protocol over which the two parties communicate. | scope. | |||
5.4. Authorization | 5.4. Authorization | |||
The EAP Key management document [I-D.ietf-eap-keying] discusses | The EAP Key management document [I-D.ietf-eap-keying] discusses | |||
several vulnerabilities that are common to handover mechanisms. One | several vulnerabilities that are common to handover mechanisms. One | |||
important issue arises from the way the authorization decisions might | important issue arises from the way the authorization decisions might | |||
be handled at the AAA server during network access authentication. | be handled at the AAA server during network access authentication. | |||
For example, if AAA proxies are involved, they may also influence in | For example, if AAA proxies are involved, they may influence | |||
the authorization decision. Furthermore, the reasons for making a | authorization decisions. Furthermore, the reasons for making a | |||
particular authorization decision are not communicated to the | particular authorization decision are not communicated to the | |||
authenticator. In fact, the authenticator only knows the final | authenticator. In fact, the authenticator only knows the final | |||
authorization result. The proposed solution MUST make efforts to | authorization result. The proposed solution must make efforts to | |||
document and mitigate authorization attacks. | document and mitigate authorization attacks. | |||
5.5. Channel Binding | 5.5. Channel Binding | |||
Channel Binding procedures are needed to avoid a compromised | Channel Binding procedures are needed to avoid a compromised | |||
intermediate authenticator providing unverified and conflicting | intermediate authenticator providing unverified and conflicting | |||
service information to each of the peer and the EAP server. In the | service information to each of the peer and the EAP server. To | |||
architecture introduced in this document, there are multiple | support fast re-authentication, there will be intermediate entities | |||
intermediate entities between the peer and the back-end EAP server. | between the peer and the back-end EAP server. Various keys need to | |||
Various keys need to be established and scoped between these parties | be established and scoped between these parties and some of these | |||
and some of these keys may be parents to other keys. Hence the | keys may be parents to other keys. Hence the channel binding for | |||
channel binding for this architecture will need to consider layering | this architecture will need to consider layering intermediate | |||
intermediate entities at each level to make sure that an entity with | entities at each level to make sure that an entity with higher level | |||
higher level of trust can examine the truthfulness of the claims made | of trust can examine the truthfulness of the claims made by | |||
by intermediate parties. | intermediate parties. | |||
5.6. Transport Aspects | 5.6. Transport Aspects | |||
Depending on the physical architecture and the functionality of the | Depending on the physical architecture and the functionality of the | |||
elements involved, there may be a need for multiple protocols to | elements involved, there may be a need for multiple protocols to | |||
perform the key transport between entities involved in the handover | perform the key transport between entities involved in the handover | |||
keying architecture. Thus, a set of requirements for each of these | keying architecture. Thus, a set of requirements for each of these | |||
protocols, and the parameters they will carry, MUST be developed. | protocols, and the parameters they will carry, must be developed. | |||
Following the requirement specifications, recommendations will be | ||||
provided as to whether new protocols or extensions to existing | ||||
protocols are needed. | ||||
As mentioned, the use of existing AAA protocols for carrying EAP | The use of existing AAA protocols for carrying EAP messages and | |||
messages and keying material between the AAA server and AAA clients | keying material between the AAA server and AAA clients that have a | |||
that have a role within the architecture considered for the keying | role within the architecture considered for the keying problem will | |||
problem will be carefully examined. Definition of specific | be carefully examined. Definition of specific parameters, required | |||
parameters, required for keying procedures and to be transferred over | for keying procedures and to be transferred over any of the links in | |||
any of the links in the architecture, are part of the scope. The | the architecture, are part of the scope. The relation of the | |||
relation of the identities used by the transport protocol and the | identities used by the transport protocol and the identities used for | |||
identities used for keying also needs to be explored. | keying also needs to be explored. | |||
6. Use Cases and Related Work | 6. Use Cases and Related Work | |||
In order to further clarify the items listed in scope of the proposed | In order to further clarify the items listed in scope of the proposed | |||
work, this section provides some background on related work and the | work, this section provides some background on related work and the | |||
use cases envisioned for the proposed work. | use cases envisioned for the proposed work. | |||
6.1. IEEE 802.11r Applicability | 6.1. Method-Specific EAP Re-authentication | |||
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in | A number of EAP methods support fast re-authentication. In this | |||
section we examine their properties in further detail. | ||||
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast re- | ||||
authentication, bootstrapped by the keys generated during an initial | ||||
full authentication. In response to the typical EAP-Request/ | ||||
Identity, the peer sends a specially formatted identity indicating a | ||||
desire to perform a fast re-authentication. A single round-trip | ||||
occurs to verify knowledge of the existing keys and provide fresh | ||||
nonces for generating new keys. This is followed by an EAP success. | ||||
In the end, it requires a single local round trip between the peer | ||||
and authenticator, followed by another round trip between the peer | ||||
and EAP server. AKA is based on symmetric-key cryptography, so | ||||
processing latency is minimal. | ||||
EAP-TTLS [I-D.funk-eap-ttls-v0] and PEAP | ||||
[I-D.josefsson-pppext-eap-tls-eap] support using TLS session | ||||
resumption for fast re-authentication. During the TLS handshake, the | ||||
client includes the message ID of the previous session he wishes to | ||||
resume, and the server can echo that ID back if it agrees to resume | ||||
the session. EAP-FAST [RFC4851] also supports TLS session | ||||
resumption, but additionally allows stateless session resumption as | ||||
defined in [RFC4507]. Overall, for all three protocols there are | ||||
still two round trips between the peer and EAP server, in addition to | ||||
the local round trip for the Identity request and response. | ||||
To improve performance, fast re-authentication needs to reduce the | ||||
number of overall round trips. Optimal performance could result from | ||||
eliminating the EAP-Request/Identity and EAP-Response/Identity | ||||
messages observed in typical EAP method execution, and allowing a | ||||
single round trip between the peer and a local re-authentication | ||||
server. | ||||
6.2. IEEE 802.11r Applicability | ||||
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in | ||||
the process of specifying a mechanism to avoid the problem of | the process of specifying a mechanism to avoid the problem of | |||
repeated full EAP exchanges in a limited setting, by introducing a | repeated full EAP exchanges in a limited setting, by introducing a | |||
two-level key hierarchy. The EAP authenticator is collocated with | two-level key hierarchy. The EAP authenticator is collocated with | |||
what is known as an R0 Key Holder (R0-KH), which receives the MSK | what is known as an R0 Key Holder (R0-KH), which receives the MSK | |||
from the EAP server. A pairwise master key (PMK-R0) is derived from | from the EAP server. A pairwise master key (PMK-R0) is derived from | |||
the last 32 octets of the MSK. Subsequently, the R0-KH derives an | the last 32 octets of the MSK. Subsequently, the R0-KH derives an | |||
PMK-R1 to be handed out to the attachment point of the peer. When | PMK-R1 to be handed out to the attachment point of the peer. When | |||
the peer moves from one R1-KH to another, a new PMK-R1 is generated | the peer moves from one R1-KH to another, a new PMK-R1 is generated | |||
by the R0-KH and handed out to the new R1-KH. The transport protocol | by the R0-KH and handed out to the new R1-KH. The transport protocol | |||
used between the R0-KH and the R1-KH is not specified. | used between the R0-KH and the R1-KH is not specified. | |||
skipping to change at page 8, line 44 | skipping to change at page 10, line 7 | |||
either a star configuration of security associations between the key | either a star configuration of security associations between the key | |||
holder and a centralized entity that serves as the R0-KH, or if the | holder and a centralized entity that serves as the R0-KH, or if the | |||
first authenticator is the default R0-KH, there will be a full-mesh | first authenticator is the default R0-KH, there will be a full-mesh | |||
of security associations between all authenticators. This is | of security associations between all authenticators. This is | |||
undesirable. | undesirable. | |||
The proposed work on EAP efficient re-authentication protocol aims at | The proposed work on EAP efficient re-authentication protocol aims at | |||
addressing re-authentication in a lower layer agnostic manner that | addressing re-authentication in a lower layer agnostic manner that | |||
also can fill some of the gaps in IEEE 802.11r. | also can fill some of the gaps in IEEE 802.11r. | |||
6.2. IEEE 802.21 Applicability | ||||
The IEEE 802.21 working group [IEEE.802-21] is standardizing | ||||
mechanisms for media-independent handover. More specifically, they | ||||
are looking at transitions from one link-layer protocol to another, | ||||
which is currently beyond the scope of the HOKEY charter. | ||||
The techniques developed within HOKEY could be applicable to IEEE | ||||
802.21 if the necessary issues with handover between different lower | ||||
layers can be resolved. In particular, pre-authentication may be | ||||
more appropriate than re-authentication. | ||||
6.3. CAPWAP Applicability | 6.3. CAPWAP Applicability | |||
The IETF CAPWAP Working Group [RFC3990] is developing a protocol | The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] allows | |||
between what is termed an Access Controller (AC) and Wireless | the functionality of an IEEE 802.11 access point to be split into two | |||
Termination Points (WTP). The AC and WTP can be mapped to a WLAN | physical devices in enterprise deployments. Wireless Termination | |||
switch and Access Point respectively. The CAPWAP model supports both | Points (WTPs) implement the physical and low-level MAC layers, while | |||
split and integrated MAC architectures, with the authenticator always | a centralized Access Controller (AC) provides higher-level management | |||
being implemented at the AC. | and protocol execution. Client authentication is handled by the AC, | |||
which acts as the AAA authenticator. | ||||
The proposed work on EAP efficient re-authentication protocol | ||||
addresses an inter-authenticator handover problem from an EAP | ||||
perspective, which applies during handover between ACs. Inter- | ||||
controller handover is a topic yet to be addressed in great detail | ||||
and the re-authentication work can potentially address it in an | ||||
effective manner. | ||||
6.4. Inter-Technology Handover | ||||
EAP is used for access authentication by several technologies and is | One of the many features provided by CAPWAP is the ability to roam | |||
under consideration for use over several other technologies going | between WTPs without executing an EAP authentication. To accomplish | |||
forward. Given that, it should be feasible to support smoother | this, the AC caches the MSK from an initial EAP authentication, and | |||
handover across technologies. That is one of the big advantages of | uses it to execute a separate four-way handshake with the station as | |||
using a common authentication protocol. Authentication procedures | it moves between WTPs. The keys resulting from the four-way | |||
typically add substantial handover delays. | handshake are then distributed to the WTP to which the station is | |||
associated. CAPWAP is transparent to the station. | ||||
An EAP peer that has multiple radio technologies (802.11 and GSM, for | CAPWAP currently has no means to support roaming between ACs in an | |||
instance) must perform the full EAP exchange on each interface upon | enterprise network. The proposed work on EAP efficient re- | |||
every horizontal or vertical handover. With a method independent EAP | authentication addresses an inter-authenticator handover problem from | |||
efficient re-authentication, it is feasible to support faster | an EAP perspective, which applies during handover between ACs. | |||
handover even in the vertical handover cases, when the peer may be | Inter-AC handover is a topic yet to be addressed in great detail and | |||
roaming from one technology to another. | the re-authentication work can potentially address it in an effective | |||
manner. | ||||
7. Security Considerations | 7. Security Considerations | |||
This document details the HOKEY problem statement. Since HOKEY is an | This document details the HOKEY problem statement. Since HOKEY is an | |||
authentication protocol, there are a myriad of security-related | authentication protocol, there are a myriad of security-related | |||
issues surrounding its development and deployment. | issues surrounding its development and deployment. | |||
In this document, we have detailed a variety of security properties | In this document, we have detailed a variety of security properties | |||
inferred from [RFC4962] to which HOKEY must conform, including the | inferred from [RFC4962] to which HOKEY must conform, including the | |||
management of key context, scope, freshness, and transport; | management of key context, scope, freshness, and transport; | |||
skipping to change at page 10, line 31 | skipping to change at page 11, line 27 | |||
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 | Rafael Marin Lopez | |||
Universidad de Murcia | Universidad de Murcia | |||
Email: rafa@dif.um.es | Email: rafa@dif.um.es | |||
10. References | 10. Acknowledgements | |||
10.1. Normative References | The authors would like to thank the participants of the HOKEY working | |||
group for their review and comments, including Glen Zorn, Dan | ||||
Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to | ||||
thank those that provided last call reviews, including Bernard Aboba, | ||||
Alan DeKok, and Hannes Tschofenig. | ||||
11. References | ||||
11.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. | |||
[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 | 11.2. Informative References | |||
[I-D.funk-eap-ttls-v0] | ||||
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS | ||||
Authentication Protocol Version 0 (EAP-TTLSv0)", | ||||
draft-funk-eap-ttls-v0-02 (work in progress), | ||||
November 2007. | ||||
[I-D.ietf-capwap-protocol-specification] | ||||
Calhoun, P., "CAPWAP Protocol Specification", | ||||
draft-ietf-capwap-protocol-specification-08 (work in | ||||
progress), November 2007. | ||||
[I-D.ietf-dime-app-design-guide] | ||||
Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., | ||||
and J. Loughney, "Diameter Applications Design | ||||
Guidelines", draft-ietf-dime-app-design-guide-06 (work in | ||||
progress), January 2008. | ||||
[I-D.ietf-eap-keying] | [I-D.ietf-eap-keying] | |||
Aboba, B., Simon, D., and P. Eronen, "Extensible | Aboba, B., Simon, D., and P. Eronen, "Extensible | |||
Authentication Protocol (EAP) Key Management Framework", | Authentication Protocol (EAP) Key Management Framework", | |||
draft-ietf-eap-keying-21 (work in progress), October 2007. | draft-ietf-eap-keying-22 (work in progress), | |||
November 2007. | ||||
[I-D.ietf-radext-design] | ||||
Weber, G. and A. DeKok, "RADIUS Design Guidelines", | ||||
draft-ietf-radext-design-02 (work in progress), | ||||
December 2007. | ||||
[I-D.josefsson-pppext-eap-tls-eap] | ||||
Josefsson, S., Palekar, A., Simon, D., and G. Zorn, | ||||
"Protected EAP Protocol (PEAP) Version 2", | ||||
draft-josefsson-pppext-eap-tls-eap-10 (work in progress), | ||||
October 2004. | ||||
[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. | |||
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication | ||||
Protocol Method for Global System for Mobile | ||||
Communications (GSM) Subscriber Identity Modules (EAP- | ||||
SIM)", RFC 4186, January 2006. | ||||
[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] | [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, | |||
"Transport Layer Security (TLS) Session Resumption without | ||||
Server-Side State", RFC 4507, May 2006. | ||||
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The | ||||
Flexible Authentication via Secure Tunneling Extensible | ||||
Authentication Protocol Method (EAP-FAST)", RFC 4851, | ||||
May 2007. | ||||
[IEEE.802-11R-D9.0] | ||||
"Information technology - Telecommunications and | "Information technology - Telecommunications and | |||
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, January 2008. | |||
[IEEE.802-21] | [KP01] Koodli, R. and C. Perkins, "Fast Handover and Context | |||
"Media Independent Handover Working Group", IEEE Working | Relocation in Mobile Networks", ACM SIGCOMM Computer and | |||
Group 802.21. | Communications Review, October 2001. | |||
[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network | ||||
Coordinates in the Wild", USENIX Symposium on Networked | ||||
System Design and Implementation, April 2007. | ||||
[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical | ||||
Analysis of the IEEE 802.11 MAC-Layer Handoff Process", | ||||
ACM SIGCOMM Computer and Communications Review, | ||||
April 2003. | ||||
Authors' Addresses | Authors' Addresses | |||
T. Charles Clancy, Editor | T. Charles Clancy, Editor | |||
Laboratory for Telecommunications Sciences | Laboratory for Telecommunications Sciences | |||
US Department of Defense | US Department of Defense | |||
College Park, MD | College Park, MD | |||
USA | USA | |||
Email: clancy@LTSnet.net | Email: clancy@LTSnet.net | |||
skipping to change at page 13, line 7 | skipping to change at page 15, line 7 | |||
Lakshminath Dondeti | Lakshminath Dondeti | |||
Qualcomm, Inc. | Qualcomm, Inc. | |||
San Diego, CA | San Diego, CA | |||
USA | USA | |||
Email: ldondeti@qualcomm.com | Email: ldondeti@qualcomm.com | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
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 | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
End of changes. 56 change blocks. | ||||
185 lines changed or deleted | 286 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/ |