draft-ietf-hokey-reauth-ps-08.txt | draft-ietf-hokey-reauth-ps-09.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: August 13, 2008 Motorola | Expires: August 26, 2008 Motorola | |||
V. Narayanan | V. Narayanan | |||
L. Dondeti | L. Dondeti | |||
Qualcomm | Qualcomm | |||
February 10, 2008 | February 23, 2008 | |||
Handover Key Management and Re-authentication Problem Statement | Handover Key Management and Re-authentication Problem Statement | |||
draft-ietf-hokey-reauth-ps-08 | draft-ietf-hokey-reauth-ps-09 | |||
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 August 13, 2008. | This Internet-Draft will expire on August 26, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
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 | |||
skipping to change at page 2, line 15 | skipping to change at page 2, line 15 | |||
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 . . . . . . . . . . . . . . 6 | 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 . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 | 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 | 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 | |||
6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 8 | 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 9 | |||
6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 | 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 | |||
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 | 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 15 | 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 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, | |||
skipping to change at page 3, line 38 | skipping to change at page 3, line 38 | |||
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. | |||
The current models of EAP authentication and keying are frequently | Wireless handover between access points or base stations is typically | |||
not efficient in cases where the peer is a mobile device | a complex process that involves several layers of protocol execution. | |||
[MSA03][KP01]. In existing implementations, when a peer arrives at | Often times executing these protocols results in unacceptable delays | |||
the new authenticator, it runs an EAP method irrespective of whether | for many real-time applications such as voice [MSA03]. One part of | |||
it has been authenticated to the network recently and has unexpired | the handover process is EAP re-authentication, which can contribute | |||
keying material. A full EAP method execution involves an EAP- | significantly to the overall handover time [MSPCA04]. Thus in many | |||
Response/Identity message from the peer to server, followed by one or | environments we can lower overall handover time by lowering EAP re- | |||
more round trips between the EAP server and peer to perform the | authentication time. | |||
authentication, followed by the EAP-Success or EAP-Failure message | ||||
from the EAP server to peer. At a minimum, the peer has 2 round | In EAP existing implementations, when a peer arrives at the new | |||
trips with the EAP server. | authenticator, it runs an EAP method irrespective of whether it has | |||
been authenticated to the network recently and has unexpired keying | ||||
material. This typically involves an EAP-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 the | ||||
peer. At a minimum, the EAP exchange consists of 1.5 round trips. | ||||
However, given the way EAP interacts with AAA, and given that an EAP | ||||
identity exchange is typically employed, at least 2 round trips are | ||||
required to the EAP server. An even higher number of round trips is | ||||
required by the most commonly used EAP methods. For instance, EAP- | ||||
TLS 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 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. Inter-technology handover and | within a single administrative domain. While the design goals | |||
inter-administrative-domain handover are outside the scope of this | presented in this document may facilitate inter-technology handover | |||
protocol. | and inter-administrative-domain handover, they 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], 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 | |||
skipping to change at page 4, line 38 | skipping to change at page 5, line 4 | |||
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 and 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 | Section 6.1). However, even in those cases, multiple round trips to | |||
the EAP server are required, resulting in unacceptable handover | 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 | |||
skipping to change at page 6, line 14 | skipping to change at page 6, line 25 | |||
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 [I-D.ietf-radext-design] | |||
and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both | and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both | |||
RADIUS and Diameter to support these EAP modifications are | RADIUS and Diameter to support these EAP modifications are | |||
acceptable. The designs and protocols must be configurable to | 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]. | |||
Compatibility: 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 MUST be | |||
provided. Specifically, the protocol should be designed such that | provided. Specifically, the protocol should be designed such that | |||
fall back to EAP authentication occurs if not all devices in the | a peer not supporting fast re-reauthentication should still | |||
network support fast re-authentication. | function in a network supporting fast re-authentication, and also | |||
a peer supporting fast re-authentication should still function in | ||||
a 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 | ||||
make changes to the peer, authenticator, and EAP server, as | ||||
necessary to meet the aforementioned design goals. In order to | ||||
facilitate protocol deployment, protocols should seek to minimize | ||||
the necessary changes, without sacrificing performance. | ||||
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 | |||
skipping to change at page 7, line 39 | skipping to change at page 8, line 12 | |||
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 [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 influence | Furthermore, the reasons for making a particular authorization | |||
authorization decisions. Furthermore, the reasons for making a | decision are not communicated to the authenticator. In fact, the | |||
particular authorization decision are not communicated to the | authenticator only knows the final authorization result. The | |||
authenticator. In fact, the authenticator only knows the final | proposed solution must make efforts to document and mitigate | |||
authorization result. The proposed solution must make efforts to | 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. 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 | |||
skipping to change at page 8, line 25 | skipping to change at page 8, line 45 | |||
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 to be transferred over any of the links in | |||
the architecture, are part of the scope. The relation of the | 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] supports 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. | |||
skipping to change at page 10, line 43 | skipping to change at page 11, line 19 | |||
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; | |||
resistance to attacks based on the domino effect; and authentication | resistance to attacks based on the domino effect; and authentication | |||
and authorization. See section Section 5 for further details. | and authorization. See Section 5 for further details. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This document does not introduce any new IANA considerations. | This document does not introduce any new IANA considerations. | |||
9. Contributors | 9. Contributors | |||
This document represents the synthesis of two problem statement | This document represents the synthesis of two problem statement | |||
documents. In this section, we acknowledge their contributions, and | documents. In this section, we acknowledge their contributions, and | |||
involvement in the early documents. | involvement in the early documents. | |||
skipping to change at page 11, line 33 | skipping to change at page 12, line 11 | |||
Rafael Marin Lopez | Rafael Marin Lopez | |||
Universidad de Murcia | Universidad de Murcia | |||
Email: rafa@dif.um.es | Email: rafa@dif.um.es | |||
10. Acknowledgements | 10. 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, and Hannes Tschofenig. | Alan DeKok, Jari Arkko, and Hannes Tschofenig. | |||
11. References | 11. References | |||
11.1. Normative 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)", | |||
skipping to change at page 12, line 17 | skipping to change at page 12, line 42 | |||
11.2. Informative References | 11.2. Informative References | |||
[I-D.funk-eap-ttls-v0] | [I-D.funk-eap-ttls-v0] | |||
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS | Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS | |||
Authentication Protocol Version 0 (EAP-TTLSv0)", | Authentication Protocol Version 0 (EAP-TTLSv0)", | |||
draft-funk-eap-ttls-v0-02 (work in progress), | draft-funk-eap-ttls-v0-02 (work in progress), | |||
November 2007. | November 2007. | |||
[I-D.ietf-capwap-protocol-specification] | [I-D.ietf-capwap-protocol-specification] | |||
Calhoun, P., "CAPWAP Protocol Specification", | Calhoun, P., "CAPWAP Protocol Specification", | |||
draft-ietf-capwap-protocol-specification-08 (work in | draft-ietf-capwap-protocol-specification-09 (work in | |||
progress), November 2007. | progress), February 2008. | |||
[I-D.ietf-dime-app-design-guide] | [I-D.ietf-dime-app-design-guide] | |||
Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., | Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., | |||
and J. Loughney, "Diameter Applications Design | and J. Loughney, "Diameter Applications Design | |||
Guidelines", draft-ietf-dime-app-design-guide-06 (work in | Guidelines", draft-ietf-dime-app-design-guide-06 (work in | |||
progress), January 2008. | 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", | |||
skipping to change at page 13, line 26 | skipping to change at page 13, line 50 | |||
May 2007. | May 2007. | |||
[IEEE.802-11R-D9.0] | [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, January 2008. | Transition", IEEE Standard 802.11r, January 2008. | |||
[KP01] Koodli, R. and C. Perkins, "Fast Handover and Context | ||||
Relocation in Mobile Networks", ACM SIGCOMM Computer and | ||||
Communications Review, October 2001. | ||||
[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network | [LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network | |||
Coordinates in the Wild", USENIX Symposium on Networked | Coordinates in the Wild", USENIX Symposium on Networked | |||
System Design and Implementation, April 2007. | System Design and Implementation, April 2007. | |||
[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical | [MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical | |||
Analysis of the IEEE 802.11 MAC-Layer Handoff Process", | Analysis of the IEEE 802.11 MAC-Layer Handoff Process", | |||
ACM SIGCOMM Computer and Communications Review, | ACM SIGCOMM Computer and Communications Review, | |||
April 2003. | April 2003. | |||
[MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W. | ||||
Arbaugh, "Proactive Key Distribution using Neighbor | ||||
Graphs", IEEE Wireless Communications, February 2004. | ||||
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 | |||
End of changes. 27 change blocks. | ||||
50 lines changed or deleted | 72 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/ |