draft-ietf-hokey-reauth-ps-09.txt | rfc5169.txt | |||
---|---|---|---|---|
HOKEY Working Group T. Clancy | Network Working Group T. Clancy | |||
Internet-Draft LTS | Request for Comments: 5169 LTS | |||
Intended status: Informational M. Nakhjiri | Category: Informational M. Nakhjiri | |||
Expires: August 26, 2008 Motorola | Motorola | |||
V. Narayanan | V. Narayanan | |||
L. Dondeti | L. Dondeti | |||
Qualcomm | Qualcomm | |||
February 23, 2008 | Handover Key Management and Re-Authentication Problem Statement | |||
Handover Key Management and Re-authentication Problem Statement | ||||
draft-ietf-hokey-reauth-ps-09 | ||||
Status of this Memo | ||||
By submitting this Internet-Draft, each author represents that any | ||||
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 | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on August 26, 2008. | ||||
Copyright Notice | Status of This Memo | |||
Copyright (C) The IETF Trust (2008). | This memo provides information for the Internet community. It does | |||
not specify an Internet standard of any kind. Distribution of this | ||||
memo is unlimited. | ||||
Abstract | Abstract | |||
This document describes the Handover Keying (HOKEY) re-authentication | This document describes the Handover Keying (HOKEY) re-authentication | |||
problem statement. The current Extensible Authentication Protocol | problem statement. The current Extensible Authentication Protocol | |||
(EAP) keying framework is not designed to support re-authentication | (EAP) keying framework is not designed to support re-authentication | |||
and handovers without re-executing an EAP method. This often causes | and handovers without re-executing an EAP method. This often causes | |||
unacceptable latency in various mobile wireless environments. This | unacceptable latency in various mobile wireless environments. This | |||
document details the problem and defines design goals for a generic | document details the problem and defines design goals for a generic | |||
mechanism to reuse derived EAP 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 | 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 | 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 | |||
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 | 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 | 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 | 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 | 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 | 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 | |||
6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 9 | 6.1. Method-Specific EAP Re-Authentication . . . . . . . . . . 9 | |||
6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 | 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10 | |||
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 | 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
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 scenarios, an EAP peer and EAP server | In many common deployment scenarios, 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 encapsulating | "authenticator"). The authenticator is responsible for encapsulating | |||
EAP packets from a network access technology lower layer within the | EAP packets from a network-access technology lower layer within the | |||
Authentication, Authorization, and Accounting (AAA) protocol. The | Authentication, Authorization, and Accounting (AAA) protocol. The | |||
authenticator does not directly participate in the EAP exchange, and | authenticator does not directly participate in the EAP exchange, and | |||
simply acts as a gateway during the EAP method execution. | simply acts as a gateway during the EAP method execution. | |||
After successful authentication, the EAP server transports the MSK to | After successful authentication, the EAP server transports the MSK to | |||
the authenticator. Note that this is performed using AAA protocols, | the authenticator. Note that this is performed using AAA protocols, | |||
not EAP itself. The underlying L2 or L3 protocol uses the MSK to | not EAP itself. The underlying L2 or L3 protocol uses the MSK to | |||
derive additional keys, including the transient session keys (TSKs) | derive additional keys, including the transient session keys (TSKs) | |||
used for per-packet encryption and authentication. | used for per-packet encryption and 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. | |||
Wireless handover between access points or base stations is typically | Wireless handover between access points or base stations is typically | |||
a complex process that involves several layers of protocol execution. | a complex process that involves several layers of protocol execution. | |||
Often times executing these protocols results in unacceptable delays | Often times executing these protocols results in unacceptable delays | |||
for many real-time applications such as voice [MSA03]. One part of | for many real-time applications such as voice [MSA03]. One part of | |||
the handover process is EAP re-authentication, which can contribute | the handover process is EAP re-authentication, which can contribute | |||
significantly to the overall handover time [MSPCA04]. Thus in many | significantly to the overall handover time [MSPCA04]. Thus, in many | |||
environments we can lower overall handover time by lowering EAP re- | environments we can lower overall handover time by lowering EAP re- | |||
authentication time. | authentication time. | |||
In EAP existing implementations, when a peer arrives at the new | In EAP existing implementations, when a peer arrives at the new | |||
authenticator, it runs an EAP method irrespective of whether it has | authenticator, it runs an EAP method irrespective of whether it has | |||
been authenticated to the network recently and has unexpired keying | been authenticated to the network recently and has unexpired keying | |||
material. This typically involves an EAP-Response/Identity message | material. This typically involves an EAP-Response/Identity message | |||
from the peer to server, followed by one or more round trips between | from the peer to the server, followed by one or more round trips | |||
the EAP server and peer to perform the authentication, followed by | between the EAP server and peer to perform the authentication, | |||
the EAP-Success or EAP-Failure message from the EAP server to the | followed by the EAP-Success or EAP-Failure message from the EAP | |||
peer. At a minimum, the EAP exchange consists of 1.5 round trips. | server to the peer. At a minimum, the EAP exchange consists of 1.5 | |||
However, given the way EAP interacts with AAA, and given that an EAP | round trips. However, given the way EAP interacts with AAA, and | |||
identity exchange is typically employed, at least 2 round trips are | given that an EAP identity exchange is typically employed, at least 2 | |||
required to the EAP server. An even higher number of round trips is | round trips are required to the EAP server. An even higher number of | |||
required by the most commonly used EAP methods. For instance, EAP- | round trips is required by the most commonly used EAP methods. For | |||
TLS requires at least 3 but typically 4 or more round trips. | instance, EAP-TLS (Extensible Authentication Protocol - Transport | |||
Layer Security) requires at least 3, but typically 4 or more, round | ||||
trips. | ||||
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 or EAP lower-layer specific. Furthermore, these | EAP-method specific or EAP lower-layer specific. Furthermore, these | |||
solutions do not deal with scenarios involving handovers to new | solutions do not deal with scenarios involving handovers to new | |||
authenticators, or do not conform to the AAA keying requirements | authenticators, or they do not 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 design goals. The scope of this protocol | re-authentication protocol design goals. The scope of this protocol | |||
is specifically re-authentication and handover between authenticators | is specifically re-authentication and handover between authenticators | |||
within a single administrative domain. While the design goals | within a single administrative domain. While the design goals | |||
presented in this document may facilitate inter-technology handover | presented in this document may facilitate inter-technology handover | |||
and inter-administrative-domain handover, they are outside the scope | and inter-administrative-domain handover, they are outside the scope | |||
of this protocol. | 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], with the | are to be interpreted as described in [RFC2119], with the | |||
qualification that unless otherwise stated they apply to the design | qualification that, unless otherwise stated, they apply to the design | |||
of the re-authentication protocol, not its implementation or | of the re-authentication protocol, not its implementation or | |||
application. | 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 [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 to which the peer initially | exchange with the EAP server to which the peer initially | |||
authenticated [RFC3748]. This introduces handover latency from both | authenticated [RFC3748]. This introduces handover latency from both | |||
network transit time and processing delay. In service provider | network transit time and processing delay. In service provider | |||
networks, the home EAP server for a peer could be on the other side | networks, the home EAP server for a peer could be on the other side | |||
of the world, and typical intercontinental latencies across the | of the world, and typical intercontinental latencies across the | |||
Internet are 100 to 300 milliseconds per round trip [LGS07]. | Internet are 100 to 300 milliseconds per round trip [LGS07]. | |||
Processing delays average a couple of milliseconds for symmetric-key | Processing delays average a couple of milliseconds for symmetric-key | |||
operations and hundreds of milliseconds for public-key operations. | operations and hundreds of milliseconds for public-key operations. | |||
An EAP conversation with a full EAP method run can take two or more | An EAP conversation with a full EAP method run can take two or more | |||
round trips to complete, causing delays in re-authentication and | round trips to complete, causing delays in re-authentication and | |||
handover times. Some methods specify the use of keys and state from | handover times. Some methods specify the use of keys and state from | |||
the initial authentication to finish subsequent authentications in | the initial authentication to finish subsequent authentications in | |||
fewer round trips and without using public-key operations (detailed | fewer round trips and without using public-key operations (detailed | |||
Section 6.1). However, even in those cases, multiple round trips to | in Section 6.1). However, even in those cases, multiple round trips | |||
the EAP server are required, resulting in unacceptable handover | to the EAP server are required, resulting in unacceptable handover | |||
times. | times. | |||
In summary, it is undesirable to run an EAP Identity and complete EAP | In summary, it is undesirable to run an EAP Identity and complete EAP | |||
method exchange each time a peer authenticates to a new authenticator | method exchange each time a peer authenticates to a new authenticator | |||
or needs to extend its current authentication with the same | or needs to extend its current authentication with the same | |||
authenticator. Furthermore, it is desirable to specify a method- | authenticator. Furthermore, it is desirable to specify a method- | |||
independent, efficient, re-authentication protocol. Keying material | independent, efficient, re-authentication protocol. Keying material | |||
from the initial authentication can be used to enable efficient re- | from the initial authentication can be used to enable efficient re- | |||
authentication. It is also desirable to have a local server with | authentication. It is also desirable to have a local server with | |||
low-latency connectivity to the peer that can facilitate re- | low-latency connectivity to the peer that can facilitate re- | |||
authentication. Lastly, a re-authentication protocol should also be | authentication. Lastly, a re-authentication protocol should also be | |||
capable of supporting scenarios where an EAP server passes | capable of supporting scenarios where an EAP server passes | |||
authentication information to a remote re-authentication server, | authentication information to a remote re-authentication server, | |||
allowing a peer to re-authenticate locally without having to | allowing a peer to re-authenticate locally, without having to | |||
communicate with its home re-authentication server. | 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 | since in networks that rely on reactive re-authentication this | |||
will directly impact handover times. | 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 | defined MUST be lower-layer independent in order to provide | |||
capabilities over heterogeneous technologies. The defined | capabilities over heterogeneous technologies. The defined | |||
protocols MAY require some additional support from the lower | protocols MAY require some additional support from the lower | |||
layers that use it, but should not require any particular lower | layers that use it, but should not require any particular lower | |||
layer. | 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, provided | MUST be no requirements imposed on future EAP methods, provided | |||
they satisfy [I-D.ietf-eap-keying] and [RFC4017]. Note that the | they satisfy [EAP-KEYING] and [RFC4017]. Note that the only EAP | |||
only EAP methods for which independence is required are those that | methods for which independence is required are those that | |||
currently conform to the specifications of [I-D.ietf-eap-keying] | currently conform to the specifications of [EAP-KEYING] and | |||
and [RFC4017]. In particular, methods that do not generate the | [RFC4017]. In particular, methods that do not generate the keys | |||
keys required by [I-D.ietf-eap-keying] need not be supported by | required by [EAP-KEYING] need not be supported by the re- | |||
the re-authentication protocol. | 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 [I-D.ietf-radext-design] | EAP keying MUST be compatible with RADIUS [RADEXT-DESIGN] and | |||
and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both | Diameter [DIME-APP-DESIGN]. Extensions to both RADIUS and | |||
RADIUS and Diameter to support these EAP modifications are | Diameter to support these EAP modifications are acceptable. The | |||
acceptable. The designs and protocols must be configurable to | designs and protocols must be configurable to satisfy the AAA key | |||
satisfy the AAA key management requirements specified in RFC 4962 | management requirements specified in RFC 4962 [RFC4962]. | |||
[RFC4962]. | ||||
Compatibility: Compatibility and co-existence with compliant | Compatibility: Compatibility and coexistence with compliant | |||
([RFC3748] [I-D.ietf-eap-keying]) EAP deployments MUST be | ([RFC3748] [EAP-KEYING]) EAP deployments MUST be provided. | |||
provided. Specifically, the protocol should be designed such that | Specifically, the protocol should be designed such that a peer not | |||
a peer not supporting fast re-reauthentication should still | supporting fast re-reauthentication should still function in a | |||
function in a network supporting fast re-authentication, and also | network supporting fast re-authentication, and also a peer | |||
a peer supporting fast re-authentication should still function in | supporting fast re-authentication should still function in a | |||
a network not supporting fast re-authentication. | network not supporting fast re-authentication. | |||
Cryptographic Agility: Any re-authentication protocol MUST support | Cryptographic Agility: Any re-authentication protocol MUST support | |||
cryptographic algorithm agility, to avoid hard-coded primitives | cryptographic algorithm agility, to avoid hard-coded primitives | |||
whose security may eventually prove to be compromised. The | whose security may eventually prove to be compromised. The | |||
protocol MAY support cryptographic algorithm negotiation, provided | protocol MAY support cryptographic algorithm negotiation, provided | |||
it does not adversely affect overall performance (i.e. by | it does not adversely affect overall performance (i.e., by | |||
requiring additional round trips). | requiring additional round trips). | |||
Impact to Existing Deployments: Any re-authentication protocol MAY | Impact to Existing Deployments: Any re-authentication protocol MAY | |||
make changes to the peer, authenticator, and EAP server, as | make changes to the peer, authenticator, and EAP server, as | |||
necessary to meet the aforementioned design goals. In order to | necessary to meet the aforementioned design goals. In order to | |||
facilitate protocol deployment, protocols should seek to minimize | facilitate protocol deployment, protocols should seek to minimize | |||
the necessary changes, without sacrificing performance. | the necessary changes, without sacrificing performance. | |||
5. Security Goals | 5. Security Goals | |||
The section draws from the guidance provided in [RFC4962] to further | This 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 | |||
protocol. | this 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 were used to | not result in a compromise of higher-level keys that were used 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, and 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 | |||
skipping to change at page 8, line 8 | skipping to change at page 8, line 15 | |||
5.3. Authentication | 5.3. Authentication | |||
Each handover keying participant must be authenticated to any other | Each handover keying participant must be authenticated to any other | |||
party with whom it communicates to the extent it is necessary to | party with whom it communicates to the extent it is necessary to | |||
ensure proper key scoping, and securely provide its identity to any | ensure proper key scoping, and securely provide its identity to any | |||
other entity that may require the identity for defining the key | other entity that may require the identity for defining the key | |||
scope. | scope. | |||
5.4. Authorization | 5.4. Authorization | |||
The EAP Key management document [I-D.ietf-eap-keying] discusses | The EAP Key management document [EAP-KEYING] discusses several | |||
several vulnerabilities that are common to handover mechanisms. One | 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. | |||
Furthermore, the reasons for making a particular authorization | Furthermore, the reasons for making a particular authorization | |||
decision are not communicated to the authenticator. In fact, the | decision are not communicated to the authenticator. In fact, the | |||
authenticator only knows the final authorization result. The | authenticator only knows the final authorization result. The | |||
proposed solution must make efforts to document and mitigate | proposed solution must make efforts to document and mitigate | |||
authorization attacks. | 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. To | service information to each of the peer and the EAP server. To | |||
support fast re-authentication, there will be intermediate entities | support fast re-authentication, there will be intermediate entities | |||
between the peer and the back-end EAP server. Various keys need to | between the peer and the back-end EAP server. Various keys need to | |||
be established and scoped between these parties and some of these | be established and scoped between these parties and some of these | |||
keys may be parents to other keys. Hence the channel binding for | keys may be parents to other keys. Hence, the channel binding for | |||
this architecture will need to consider layering intermediate | this architecture will need to consider layering intermediate | |||
entities at each level to make sure that an entity with higher level | entities at each level to make sure that an entity with a higher | |||
of trust can examine the truthfulness of the claims made by | level of trust can examine the truthfulness of the claims made 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. | |||
The use of existing AAA protocols for carrying EAP messages and | The use of existing AAA protocols for carrying EAP messages and | |||
keying material between the AAA server and AAA clients that have a | keying material between the AAA server and AAA clients that have a | |||
role within the architecture considered for the keying problem will | role within the architecture considered for the keying problem will | |||
be carefully examined. Definition of specific parameters, required | be carefully examined. Definition of specific parameters, required | |||
for keying procedures and to be transferred over any of the links in | for keying procedures and for being transferred over any of the links | |||
the architecture, are part of the scope. The relation between the | in the architecture, are part of the scope. The relation between the | |||
identities used by the transport protocol and the identities used for | identities used by the transport protocol and the 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. Method-Specific EAP Re-authentication | 6.1. Method-Specific EAP Re-Authentication | |||
A number of EAP methods support fast re-authentication. In this | A number of EAP methods support fast re-authentication. In this | |||
section we examine their properties in further detail. | section, we examine their properties in further detail. | |||
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re- | EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re- | |||
authentication, bootstrapped by the keys generated during an initial | authentication, bootstrapped by the keys generated during an initial | |||
full authentication. In response to the typical EAP-Request/ | full authentication. In response to the typical EAP-Request/ | |||
Identity, the peer sends a specially formatted identity indicating a | Identity, the peer sends a specially formatted identity indicating a | |||
desire to perform a fast re-authentication. A single round-trip | desire to perform a fast re-authentication. A single round-trip | |||
occurs to verify knowledge of the existing keys and provide fresh | occurs to verify knowledge of the existing keys and provide fresh | |||
nonces for generating new keys. This is followed by an EAP success. | 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 | In the end, it requires a single local round trip between the peer | |||
and authenticator, followed by another 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 | and EAP server. AKA is based on symmetric-key cryptography, so | |||
processing latency is minimal. | processing latency is minimal. | |||
EAP-TTLS [I-D.funk-eap-ttls-v0] and PEAP | EAP-TTLS [EAP-TTLS] and PEAP (Protected EAP Protocol) | |||
[I-D.josefsson-pppext-eap-tls-eap] support using TLS session | [JOSEFSSON-PPPEXT] support using TLS session resumption for fast re- | |||
resumption for fast re-authentication. During the TLS handshake, the | authentication. During the TLS handshake, the client includes the | |||
client includes the message ID of the previous session he wishes to | message ID of the previous session he wishes to resume, and the | |||
resume, and the server can echo that ID back if it agrees to resume | server can echo that ID back if it agrees to resume the session. | |||
the session. EAP-FAST [RFC4851] also supports TLS session | EAP-FAST [RFC4851] also supports TLS session resumption, but | |||
resumption, but additionally allows stateless session resumption as | additionally allows stateless session resumption as defined in | |||
defined in [RFC4507]. Overall, for all three protocols there are | [RFC5077]. Overall, for all three protocols, there are still two | |||
still two round trips between the peer and EAP server, in addition to | round trips between the peer and EAP server, in addition to the local | |||
the local round trip for the Identity request and response. | round trip for the Identity request and response. | |||
To improve performance, fast re-authentication needs to reduce the | To improve performance, fast re-authentication needs to reduce the | |||
number of overall round trips. Optimal performance could result from | number of overall round trips. Optimal performance could result from | |||
eliminating the EAP-Request/Identity and EAP-Response/Identity | eliminating the EAP-Request/Identity and EAP-Response/Identity | |||
messages observed in typical EAP method execution, and allowing a | messages observed in typical EAP method execution, and allowing a | |||
single round trip between the peer and a local re-authentication | single round trip between the peer and a local re-authentication | |||
server. | server. | |||
6.2. IEEE 802.11r Applicability | 6.2. IEEE 802.11r Applicability | |||
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in | 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 fast handover mechanism. Access Points | |||
repeated full EAP exchanges in a limited setting, by introducing a | (APs) are grouped into mobility domains. Initial authentication to | |||
two-level key hierarchy. The EAP authenticator is collocated with | any AP in a mobility domain requires execution of EAP, but handover | |||
what is known as an R0 Key Holder (R0-KH), which receives the MSK | between APs within the mobility domain does not require the use of | |||
from the EAP server. A pairwise master key (PMK-R0) is derived from | EAP. | |||
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 | ||||
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 | ||||
used between the R0-KH and the R1-KH is not specified. | ||||
In some cases, a mobile may seldom move beyond the domain of the | ||||
R0-KH and this model works well. A full EAP authentication will | ||||
generally be repeated when the PMK-R0 expires. However, in general | ||||
cases mobiles may roam beyond the domain of R0-KHs (or EAP | ||||
authenticators), and the latency of full EAP authentication remains | ||||
an issue. | ||||
Another consideration is that there needs to be a key transfer | Internal to the mobility domain are sets of security associations to | |||
protocol between the R0-KH and the R1-KH; in other words, there is | support key transfers between APs. In one model, relatively few | |||
either a star configuration of security associations between the key | devices, called R0-KHs, act as authenticators. All EAP traffic | |||
holder and a centralized entity that serves as the R0-KH, or if the | traverses an R0-KH, and it derives the initial IEEE 802.11 keys. It | |||
first authenticator is the default R0-KH, there will be a full-mesh | then distributes cryptographically separate keys to APs in the | |||
of security associations between all authenticators. This is | mobility domain, as necessary, to support the client mobility. For a | |||
undesirable. | deployment with M designated R0-KHs and N APs, this requires M*N | |||
security associations. For small M, this approach scales reasonably. | ||||
Another approach allows any AP to act as an R0-KH, necessitating a | ||||
full mesh of N2 security associations, which scales poorly. | ||||
The proposed work on EAP efficient re-authentication protocol aims at | The model that utilizes designated R0-KHs is architecturally similar | |||
addressing re-authentication in a lower layer agnostic manner that | to the fast re-authentication model proposed by HOKEY. HOKEY, | |||
also can fill some of the gaps in IEEE 802.11r. | however, allows for handover between authenticators. This would | |||
allow an IEEE 802.11r-enabled peer to handover from one mobility | ||||
domain to another without performing an EAP authentication. | ||||
6.3. CAPWAP Applicability | 6.3. CAPWAP Applicability | |||
The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] allows | The CAPWAP (Control and Provisioning of Wireless Access Points) | |||
the functionality of an IEEE 802.11 access point to be split into two | protocol [CAPWAP-PROTOCOL-SPEC] allows the functionality of an IEEE | |||
physical devices in enterprise deployments. Wireless Termination | 802.11 access point to be split into two physical devices in | |||
Points (WTPs) implement the physical and low-level MAC layers, while | enterprise deployments. Wireless Termination Points (WTPs) implement | |||
a centralized Access Controller (AC) provides higher-level management | the physical and low-level Media Access Control (MAC) layers, while a | |||
centralized Access Controller (AC) provides higher-level management | ||||
and protocol execution. Client authentication is handled by the AC, | and protocol execution. Client authentication is handled by the AC, | |||
which acts as the AAA authenticator. | which acts as the AAA authenticator. | |||
One of the many features provided by CAPWAP is the ability to roam | One of the many features provided by CAPWAP is the ability to roam | |||
between WTPs without executing an EAP authentication. To accomplish | between WTPs without executing an EAP authentication. To accomplish | |||
this, the AC caches the MSK from an initial EAP authentication, and | this, the AC caches the MSK from an initial EAP authentication, and | |||
uses it to execute a separate four-way handshake with the station as | uses it to execute a separate four-way handshake with the station as | |||
it moves between WTPs. The keys resulting from the four-way | it moves between WTPs. The keys resulting from the four-way | |||
handshake are then distributed to the WTP to which the station is | handshake are then distributed to the WTP to which the station is | |||
associated. CAPWAP is transparent to the station. | associated. CAPWAP is transparent to the station. | |||
CAPWAP currently has no means to support roaming between ACs in an | CAPWAP currently has no means to support roaming between ACs in an | |||
enterprise network. The proposed work on EAP efficient re- | enterprise network. The proposed work on EAP efficient re- | |||
authentication addresses an inter-authenticator handover problem from | authentication addresses is an inter-authenticator handover problem | |||
an EAP perspective, which applies during handover between ACs. | from an EAP perspective, which applies during handover between ACs. | |||
Inter-AC handover is a topic yet to be addressed in great detail and | Inter-AC handover is a topic yet to be addressed in great detail and | |||
the re-authentication work can potentially address it in an effective | the re-authentication work can potentially address it in an effective | |||
manner. | 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 is a myriad of security-related issues | |||
issues surrounding its development and deployment. | 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; | |||
resistance to attacks based on the domino effect; and authentication | resistance to attacks based on the domino effect; and authentication | |||
and authorization. See Section 5 for further details. | and authorization. See Section 5 for further details. | |||
8. IANA Considerations | 8. Contributors | |||
This document does not introduce any new IANA considerations. | ||||
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, and | documents. In this section, we acknowledge their contributions, and | |||
involvement in the early documents. | involvement in the early documents. | |||
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 | Rafael Marin Lopez | |||
Universidad de Murcia | Universidad de Murcia | |||
Email: rafa@dif.um.es | EMail: rafa@dif.um.es | |||
10. Acknowledgements | 9. Acknowledgements | |||
The authors would like to thank the participants of the HOKEY working | The authors would like to thank the participants of the HOKEY working | |||
group for their review and comments, including Glen Zorn, Dan | group for their review and comments including: Glen Zorn, Dan | |||
Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to | Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to | |||
thank those that provided last call reviews, including Bernard Aboba, | thank those that provided last-call reviews including: Bernard Aboba, | |||
Alan DeKok, Jari Arkko, and Hannes Tschofenig. | Alan DeKok, Jari Arkko, and Hannes Tschofenig. | |||
11. References | 10. References | |||
11.1. Normative References | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | 10.1. Normative References | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | [RFC2119] Bradner, S., "Key words for use in RFCs to | |||
Levkowetz, "Extensible Authentication Protocol (EAP)", | Indicate Requirement Levels", BCP 14, | |||
RFC 3748, June 2004. | RFC 2119, March 1997. | |||
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., | |||
Authentication Protocol (EAP) Method Requirements for | Carlson, J., and H. Levkowetz, "Extensible | |||
Wireless LANs", RFC 4017, March 2005. | Authentication Protocol (EAP)", RFC 3748, | |||
June 2004. | ||||
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, | [RFC4017] Stanley, D., Walker, J., and B. Aboba, | |||
Authorization, and Accounting (AAA) Key Management", | "Extensible Authentication Protocol (EAP) | |||
BCP 132, RFC 4962, July 2007. | Method Requirements for Wireless LANs", | |||
RFC 4017, March 2005. | ||||
11.2. Informative References | [RFC4962] Housley, R. and B. Aboba, "Guidance for | |||
Authentication, Authorization, and Accounting | ||||
(AAA) Key Management", BCP 132, RFC 4962, | ||||
July 2007. | ||||
[I-D.funk-eap-ttls-v0] | 10.2. Informative References | |||
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] | [CAPWAP-PROTOCOL-SPEC] Calhoun, P., Montemurro, M., and D. Stanely, | |||
Calhoun, P., "CAPWAP Protocol Specification", | "CAPWAP Protocol Specification", Work | |||
draft-ietf-capwap-protocol-specification-09 (work in | in Progress, March 2008. | |||
progress), February 2008. | ||||
[I-D.ietf-dime-app-design-guide] | [DIME-APP-DESIGN] Fajardo, V., Asveren, T., Tschofenig, H., | |||
Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., | McGregor, G., and J. Loughney, "Diameter | |||
and J. Loughney, "Diameter Applications Design | Applications Design Guidelines", Work | |||
Guidelines", draft-ietf-dime-app-design-guide-06 (work in | in Progress, January 2008. | |||
progress), January 2008. | ||||
[I-D.ietf-eap-keying] | [EAP-KEYING] Aboba, B., Simon, D., and P. Eronen, | |||
Aboba, B., Simon, D., and P. Eronen, "Extensible | "Extensible Authentication Protocol (EAP) Key | |||
Authentication Protocol (EAP) Key Management Framework", | Management Framework", Work in Progress, | |||
draft-ietf-eap-keying-22 (work in progress), | ||||
November 2007. | November 2007. | |||
[I-D.ietf-radext-design] | [EAP-TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled | |||
Weber, G. and A. DeKok, "RADIUS Design Guidelines", | TLS Authentication Protocol Version 0 (EAP- | |||
draft-ietf-radext-design-02 (work in progress), | TTLSv0)", Work in Progress, March 2008. | |||
December 2007. | ||||
[I-D.josefsson-pppext-eap-tls-eap] | [IEEE.802-11R-D9.0] "Information technology - Telecommunications | |||
Josefsson, S., Palekar, A., Simon, D., and G. Zorn, | and information exchange between systems - | |||
"Protected EAP Protocol (PEAP) Version 2", | Local and metropolitan area networks - | |||
draft-josefsson-pppext-eap-tls-eap-10 (work in progress), | Specific requirements - Part 11: Wireless LAN | |||
October 2004. | Medium Access Control (MAC) and Physical | |||
Layer (PHY) specifications - Amendment 2: | ||||
Fast BSS Transition", IEEE Standard 802.11r, | ||||
January 2008. | ||||
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and | [JOSEFSSON-PPPEXT] Josefsson, S., Palekar, A., Simon, D., and G. | |||
Provisioning for Wireless Access Points (CAPWAP) Problem | Zorn, "Protected EAP Protocol (PEAP) Version | |||
Statement", RFC 3990, February 2005. | 2", Work in Progress, October 2004. | |||
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication | [LGS07] Ledlie, J., Gardner, P., and M. Selter, | |||
Protocol Method for Global System for Mobile | "Network Coordinates in the Wild", | |||
Communications (GSM) Subscriber Identity Modules (EAP- | USENIX Symposium on Networked System Design | |||
SIM)", RFC 4186, January 2006. | and Implementation, April 2007. | |||
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication | [MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An | |||
Protocol Method for 3rd Generation Authentication and Key | Empirical Analysis of the IEEE 802.11 MAC- | |||
Agreement (EAP-AKA)", RFC 4187, January 2006. | Layer Handoff Process", ACM SIGCOMM Computer | |||
and Communications Review, April 2003. | ||||
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, | [MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, | |||
"Transport Layer Security (TLS) Session Resumption without | T., and W. Arbaugh, "Proactive Key | |||
Server-Side State", RFC 4507, May 2006. | Distribution using Neighbor Graphs", | |||
IEEE Wireless Communications, February 2004. | ||||
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The | [RADEXT-DESIGN] Weber, G. and A. DeKok, "RADIUS Design | |||
Flexible Authentication via Secure Tunneling Extensible | Guidelines", Work in Progress, December 2007. | |||
Authentication Protocol Method (EAP-FAST)", RFC 4851, | ||||
May 2007. | ||||
[IEEE.802-11R-D9.0] | [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, | |||
"Information technology - Telecommunications and | "Configuration and Provisioning for Wireless | |||
information exchange between systems - Local and | Access Points (CAPWAP) Problem Statement", | |||
metropolitan area networks - Specific requirements - Part | RFC 3990, February 2005. | |||
11: Wireless LAN Medium Access Control (MAC) and Physical | ||||
Layer (PHY) specifications - Amendment 2: Fast BSS | ||||
Transition", IEEE Standard 802.11r, January 2008. | ||||
[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network | [RFC4186] Haverinen, H. and J. Salowey, "Extensible | |||
Coordinates in the Wild", USENIX Symposium on Networked | Authentication Protocol Method for Global | |||
System Design and Implementation, April 2007. | System for Mobile Communications (GSM) | |||
Subscriber Identity Modules (EAP-SIM)", | ||||
RFC 4186, January 2006. | ||||
[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical | [RFC4187] Arkko, J. and H. Haverinen, "Extensible | |||
Analysis of the IEEE 802.11 MAC-Layer Handoff Process", | Authentication Protocol Method for 3rd | |||
ACM SIGCOMM Computer and Communications Review, | Generation Authentication and Key Agreement | |||
April 2003. | (EAP-AKA)", RFC 4187, January 2006. | |||
[MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W. | [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and | |||
Arbaugh, "Proactive Key Distribution using Neighbor | H. Zhou, "The Flexible Authentication via | |||
Graphs", IEEE Wireless Communications, February 2004. | Secure Tunneling Extensible Authentication | |||
Protocol Method (EAP-FAST)", RFC 4851, | ||||
May 2007. | ||||
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. | ||||
Tschofenig, "Transport Layer Security (TLS) | ||||
Session Resumption without Server-Side | ||||
State", RFC 5077, January 2008. | ||||
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 | |||
Madjid Nakhjiri | Madjid Nakhjiri | |||
Motorola | Motorola | |||
Email: madjid.nakhjiri@motorola.com | EMail: madjid.nakhjiri@motorola.com | |||
Vidya Narayanan | Vidya Narayanan | |||
Qualcomm, Inc. | Qualcomm, Inc. | |||
San Diego, CA | San Diego, CA | |||
USA | USA | |||
Email: vidyan@qualcomm.com | EMail: vidyan@qualcomm.com | |||
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 (2008). | 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 | |||
skipping to change at page 15, line 44 | skipping to change at line 639 | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 75 change blocks. | ||||
244 lines changed or deleted | 208 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/ |