draft-ietf-hokey-reauth-ps-05.txt | draft-ietf-hokey-reauth-ps-06.txt | |||
---|---|---|---|---|
HOKEY Working Group T. Clancy, Editor | HOKEY Working Group T. Clancy, Editor | |||
Internet-Draft LTS | Internet-Draft LTS | |||
Intended status: Informational November 2, 2007 | Intended status: Informational November 6, 2007 | |||
Expires: May 5, 2008 | Expires: May 9, 2008 | |||
Handover Key Management and Re-authentication Problem Statement | Handover Key Management and Re-authentication Problem Statement | |||
draft-ietf-hokey-reauth-ps-05 | draft-ietf-hokey-reauth-ps-06 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on May 5, 2008. | This Internet-Draft will expire on May 9, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
This document describes the Handover Keying (HOKEY) problem | This document describes the Handover Keying (HOKEY) problem | |||
statement. The current EAP keying framework is not designed to | statement. The current Extensible Authentication Protocol (EAP) | |||
support re-authentication and handovers. This often cause | keying framework is not designed to support re-authentication and | |||
unacceptable latency in various mobile wireless environments. HOKEY | handovers. This often causes unacceptable latency in various mobile | |||
plans to address these HOKEY plans to address these problems by | wireless environments. The HOKEY Working Group plans to address | |||
implementing a generic mechanism to reuse derived EAP keying material | these problems by designing a generic mechanism to reuse derived EAP | |||
for handover. | keying material for handover. | |||
Table of Contents | Table of Contents | |||
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 | |||
6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 | 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 | 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 | 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | |||
6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 | 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 | |||
6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 | 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | |||
7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 | 6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 | |||
7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 | 6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8 | |||
7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9 | 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 | |||
7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 | 6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 | |||
7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 12 | Intellectual Property and Copyright Statements . . . . . . . . . . 13 | |||
1. Contributors | ||||
The following authors contributed to the HOKEY problem statement | ||||
document: | ||||
o Julien Bournelle, France Telecom R&D, | ||||
julien.bournelle@orange-ftgroup.com | ||||
o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com | ||||
o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es | ||||
o Madjid Nakhjiri, Motorola, madjid.nakhjiri@motorola.com | ||||
o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com | ||||
o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com | ||||
o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com | ||||
2. 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 MSK (EMSK). | Extended Master Session Key (EMSK). | |||
In many common deployment scenario, an EAP peer and EAP server | In many common deployment scenario, an EAP peer and EAP server | |||
authenticate each other through a third party known as the pass- | authenticate each other through a third party known as the pass- | |||
through authenticator (hereafter referred to as simply | through authenticator (hereafter referred to as simply | |||
"authenticator"). The authenticator is responsible for translating | "authenticator"). The authenticator is responsible for translating | |||
EAP packets from the layer 2 (L2) or layer 3 (L3) network access | EAP packets from the layer 2 (L2) or layer 3 (L3) network access | |||
technology to the AAA protocol. | technology to the Authentication, Authorization, and Accounting (AAA) | |||
protocol. The authenticator does not directly participate in the EAP | ||||
exchange, and simply acts as a gateway during the EAP method | ||||
execution. | ||||
According to [RFC3748], after successful authentication, the server | According to [RFC3748], after successful authentication, the server | |||
transports the MSK to the authenticator. The underlying L2 or L3 | to transports the MSK to the authenticator. Note that this is | |||
protocol uses the MSK to derive additional keys, including the | performed using AAA protocols, not EAP itself. The underlying L2 or | |||
transient session keys (TSK) used per-packet access encryption and | L3 protocol uses the MSK to derive additional keys, including the | |||
enforcement. | transient session keys (TSKs) 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 unfortunately | The current models of EAP authentication and keying are unfortunately | |||
not efficient in case of mobile and wireless networks. When a peer | not efficient in cases where the peer is a mobile device. When a | |||
arrives at the new authenticator, or is expected to re-affirm its | peer arrives at the new authenticator, the security restraints will | |||
access through the current authenticator, the security restraints | require the peer to run an EAP method irrespective of whether it has | |||
will require the peer to run an EAP method irrespective of whether it | been authenticated to the network recently and has unexpired keying | |||
has been authenticated to the network recently and has unexpired | material. A full EAP method execution may involve several round | |||
keying material. A full EAP method execution may involves several | trips between the EAP peer and the server. | |||
round trips between the EAP peer and the server. | ||||
There have been attempts to solve the problem of efficient re- | There have been attempts to solve the problem of efficient re- | |||
authentication in various ways. However, those solutions are either | authentication in various ways. However, those solutions are either | |||
EAP-method specific, EAP lower-layer specific, or are otherwise | EAP-method specific, EAP lower-layer specific, or are otherwise | |||
limited in scope. Furthermore, these solutions do not deal with | limited in scope. Furthermore, these solutions do not deal with | |||
scenarios involving handovers to new authenticators, or do not | scenarios involving handovers to new authenticators, or do not | |||
conform to the AAA keying requirements specified in [RFC4962]. | conform to the AAA keying requirements specified in [RFC4962]. | |||
This document provides a detailed description of EAP efficient re- | This document provides a detailed description of efficient EAP-based | |||
authentication protocol requirements. | re-authentication protocol requirements. | |||
3. Terminology | 2. Terminology | |||
In this document, several words are used to signify the requirements | In this document, several words are used to signify the requirements | |||
of the specification. These words are often capitalized. The key | of the specification. These words are often capitalized. The key | |||
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | |||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document | |||
are to be interpreted as described in [RFC2119]. | are to be interpreted as described in [RFC2119]. | |||
With respect to EAP, this document follows the terminology that has | With respect to EAP, this document follows the terminology that has | |||
been defined in [RFC3748] and [I-D.ietf-eap-keying]. | been defined in [RFC3748] and [I-D.ietf-eap-keying]. | |||
4. Problem Statement | 3. Problem Statement | |||
Under the existing model, any re-authentication requires a full EAP | Under the existing model, any re-authentication requires a full EAP | |||
exchange with the EAP server in its home domain [RFC3748]. An EAP | exchange with the EAP server in its home domain [RFC3748]. An EAP | |||
conversation with a full EAP method run can take several round trips | conversation with a full EAP method run can take several round trips | |||
and significant time to complete, causing delays in re-authentication | and significant time to complete, causing delays in re-authentication | |||
and handover times. Some methods [RFC4187] specify the use of keys | and handover times. Some methods [RFC4187] specify the use of keys | |||
and state from the initial authentication to finish subsequent | and state from the initial authentication to finish subsequent | |||
authentications in fewer round trips. However, even in those cases, | authentications in fewer round trips. However, even in those cases, | |||
multiple round trips to the EAP server are still involved. | multiple round trips to the EAP server are still involved. | |||
Furthermore, many commonly-used EAP methods do not offer such a fast | Furthermore, many commonly-used EAP methods do not offer such a fast | |||
skipping to change at page 5, line 11 | skipping to change at page 4, line 45 | |||
method-independent, efficient, re-authentication protocol. Keying | method-independent, efficient, re-authentication protocol. Keying | |||
material from the full authentication can be used to enable efficient | material from the full authentication can be used to enable efficient | |||
re-authentication. | re-authentication. | |||
Significant network latency between the peer and EAP server is | Significant network latency between the peer and EAP server is | |||
another source of delay during re-authentication. It is desirable to | another source of delay during re-authentication. It is desirable to | |||
have a local server with low-latency connectivity to the peer that | have a local server with low-latency connectivity to the peer that | |||
can facilitate re-authentication. | can facilitate re-authentication. | |||
Lastly, a re-authentication protocol should also be capable of | Lastly, a re-authentication protocol should also be capable of | |||
supporting handover keying. Handover keying allows re-authentication | supporting handover keying. Handover keying allows an EAP server to | |||
keys to be passed to a different re-authentication domain (not | pass authentication information to a remote re-authentication server, | |||
necessarily a different AAA domain or administrative domain). | allowing a peer to re-authenticate to that re-authentication server | |||
Execution of the re-authentication protocol in that re-authentication | without having to communicate with its home re-authentication server. | |||
domain will then allow handover from one re-authentication domain to | ||||
another. | ||||
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. | |||
5. 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. | |||
EAP lower-layer independence: Any keying hierarchy and protocol | EAP lower-layer independence: Any keying hierarchy and protocol | |||
skipping to change at page 6, line 10 | skipping to change at page 5, line 45 | |||
Extensions to both RADIUS and Diameter to support these EAP | Extensions to both RADIUS and Diameter to support these EAP | |||
modifications are acceptable. The designs and protocols must | modifications are acceptable. The designs and protocols must | |||
satisfy the AAA key management requirements specified in RFC 4962 | satisfy the AAA key management requirements specified in RFC 4962 | |||
[RFC4962]. | [RFC4962]. | |||
Compatability: Compatibility and co-existence with compliant | Compatability: Compatibility and co-existence with compliant | |||
([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be | ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be | |||
provided. The keying hierarchy or protocol extensions MUST NOT | provided. The keying hierarchy or protocol extensions MUST NOT | |||
preclude the use of CAPWAP or IEEE 802.11r. | preclude the use of CAPWAP or IEEE 802.11r. | |||
6. Security Goals | 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. | |||
6.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 | |||
skipping to change at page 7, line 5 | skipping to change at page 6, line 38 | |||
Note that the compromise of higher-level keys has security | Note that the compromise of higher-level keys has security | |||
implications on lower levels. | implications on lower levels. | |||
Guidance on parameters required, caching, storage and deletion | Guidance on parameters required, caching, storage and deletion | |||
procedures to ensure adequate security and authorization provisioning | procedures to ensure adequate security and authorization provisioning | |||
for keying procedures MUST be defined in a solution document. | for keying procedures MUST be defined in a solution document. | |||
All the keying material MUST be uniquely named so that it can be | All the keying material MUST be uniquely named so that it can be | |||
managed effectively. | managed effectively. | |||
6.2. Key Freshness | 5.2. Key Freshness | |||
As [RFC4962] defines, a fresh key is one that is generated for the | As [RFC4962] defines, a fresh key is one that is generated for the | |||
intended use. This would mean the key hierarchy MUST provide for | intended use. This would mean the key hierarchy MUST provide for | |||
creation of multiple cryptographically separate child keys from a | creation of multiple cryptographically separate child keys from a | |||
root key at higher level. Furthermore, the keying solution needs to | root key at higher level. Furthermore, the keying solution needs to | |||
provide mechanisms for refreshing each of the keys within the key | provide mechanisms for refreshing each of the keys within the key | |||
hierarchy. | hierarchy. | |||
6.3. Authentication | 5.3. Authentication | |||
Each party in the handover keying architecture MUST be authenticated | Each party in the handover keying architecture MUST be authenticated | |||
to any other party with whom it communicates, and securely provide | to any other party with whom it communicates, and securely provide | |||
its identity to any other entity that may require the identity for | its identity to any other entity that may require the identity for | |||
defining the key scope. The identity provided MUST be meaningful | defining the key scope. The identity provided MUST be meaningful | |||
according to the protocol over which the two parties communicate. | according to the protocol over which the two parties communicate. | |||
6.4. Authorization | 5.4. Authorization | |||
The EAP Key management document [I-D.ietf-eap-keying] discusses | The EAP Key management document [I-D.ietf-eap-keying] discusses | |||
several vulnerabilities that are common to handover mechanisms. One | several vulnerabilities that are common to handover mechanisms. One | |||
important issue arises from the way the authorization decisions might | important issue arises from the way the authorization decisions might | |||
be handled at the AAA server during network access authentication. | be handled at the AAA server during network access authentication. | |||
For example, if AAA proxies are involved, they may also influence in | For example, if AAA proxies are involved, they may also influence in | |||
the authorization decision. Furthermore, the reasons for making a | the authorization decision. Furthermore, the reasons for making a | |||
particular authorization decision are not communicated to the | particular authorization decision are not communicated to the | |||
authenticator. In fact, the authenticator only knows the final | authenticator. In fact, the authenticator only knows the final | |||
authorization result. The proposed solution MUST make efforts to | authorization result. The proposed solution MUST make efforts to | |||
document and mitigate authorization attacks. | document and mitigate authorization attacks. | |||
6.5. Channel Binding | 5.5. Channel Binding | |||
Channel Binding procedures are needed to avoid a compromised | Channel Binding procedures are needed to avoid a compromised | |||
intermediate authenticator providing unverified and conflicting | intermediate authenticator providing unverified and conflicting | |||
service information to each of the peer and the EAP server. In the | service information to each of the peer and the EAP server. In the | |||
architecture introduced in this document, there are multiple | architecture introduced in this document, there are multiple | |||
intermediate entities between the peer and the back-end EAP server. | intermediate entities between the peer and the back-end EAP server. | |||
Various keys need to be established and scoped between these parties | Various keys need to be established and scoped between these parties | |||
and some of these keys may be parents to other keys. Hence the | and some of these keys may be parents to other keys. Hence the | |||
channel binding for this architecture will need to consider layering | channel binding for this architecture will need to consider layering | |||
intermediate entities at each level to make sure that an entity with | intermediate entities at each level to make sure that an entity with | |||
higher level of trust can examine the truthfulness of the claims made | higher level of trust can examine the truthfulness of the claims made | |||
by intermediate parties. | by intermediate parties. | |||
6.6. Transport Aspects | 5.6. Transport Aspects | |||
Depending on the physical architecture and the functionality of the | Depending on the physical architecture and the functionality of the | |||
elements involved, there may be a need for multiple protocols to | elements involved, there may be a need for multiple protocols to | |||
perform the key transport between entities involved in the handover | perform the key transport between entities involved in the handover | |||
keying architecture. Thus, a set of requirements for each of these | keying architecture. Thus, a set of requirements for each of these | |||
protocols, and the parameters they will carry, MUST be developed. | protocols, and the parameters they will carry, MUST be developed. | |||
Following the requirement specifications, recommendations will be | Following the requirement specifications, recommendations will be | |||
provided as to whether new protocols or extensions to existing | provided as to whether new protocols or extensions to existing | |||
protocols are needed. | protocols are needed. | |||
As mentioned, the use of existing AAA protocols for carrying EAP | As mentioned, the use of existing AAA protocols for carrying EAP | |||
messages and keying material between the AAA server and AAA clients | messages and keying material between the AAA server and AAA clients | |||
that have a role within the architecture considered for the keying | that have a role within the architecture considered for the keying | |||
problem will be carefully examined. Definition of specific | problem will be carefully examined. Definition of specific | |||
parameters, required for keying procedures and to be transferred over | parameters, required for keying procedures and to be transferred over | |||
any of the links in the architecture, are part of the scope. The | any of the links in the architecture, are part of the scope. The | |||
relation of the identities used by the transport protocol and the | relation of the identities used by the transport protocol and the | |||
identities used for keying also needs to be explored. | identities used for keying also needs to be explored. | |||
7. 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. | |||
7.1. IEEE 802.11r Applicability | 6.1. IEEE 802.11r Applicability | |||
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in | One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in | |||
the process of specifying a mechanism to avoid the problem of | the process of specifying a mechanism to avoid the problem of | |||
repeated full EAP exchanges in a limited setting, by introducing a | repeated full EAP exchanges in a limited setting, by introducing a | |||
two-level key hierarchy. The EAP authenticator is collocated with | two-level key hierarchy. The EAP authenticator is collocated with | |||
what is known as an R0 Key Holder (R0-KH), which receives the MSK | what is known as an R0 Key Holder (R0-KH), which receives the MSK | |||
from the EAP server. A pairwise master key (PMK-R0) is derived from | from the EAP server. A pairwise master key (PMK-R0) is derived from | |||
the last 32 octets of the MSK. Subsequently, the R0-KH derives an | the last 32 octets of the MSK. Subsequently, the R0-KH derives an | |||
PMK-R1 to be handed out to the attachment point of the peer. When | PMK-R1 to be handed out to the attachment point of the peer. When | |||
the peer moves from one R1-KH to another, a new PMK-R1 is generated | the peer moves from one R1-KH to another, a new PMK-R1 is generated | |||
skipping to change at page 9, line 12 | skipping to change at page 8, line 44 | |||
either a star configuration of security associations between the key | either a star configuration of security associations between the key | |||
holder and a centralized entity that serves as the R0-KH, or if the | holder and a centralized entity that serves as the R0-KH, or if the | |||
first authenticator is the default R0-KH, there will be a full-mesh | first authenticator is the default R0-KH, there will be a full-mesh | |||
of security associations between all authenticators. This is | of security associations between all authenticators. This is | |||
undesirable. | undesirable. | |||
The proposed work on EAP efficient re-authentication protocol aims at | The proposed work on EAP efficient re-authentication protocol aims at | |||
addressing re-authentication in a lower layer agnostic manner that | addressing re-authentication in a lower layer agnostic manner that | |||
also can fill some of the gaps in IEEE 802.11r. | also can fill some of the gaps in IEEE 802.11r. | |||
7.2. IEEE 802.21 Applicability | 6.2. IEEE 802.21 Applicability | |||
The IEEE 802.21 working group [IEEE.802-21] is standardizing | The IEEE 802.21 working group [IEEE.802-21] is standardizing | |||
mechanisms for media-independent handover. More specifically, they | mechanisms for media-independent handover. More specifically, they | |||
are looking at transitions from one link-layer protocol to another, | are looking at transitions from one link-layer protocol to another, | |||
which is currently beyond the scope of the HOKEY charter. | which is currently beyond the scope of the HOKEY charter. | |||
The techniques developed within HOKEY could be applicable to IEEE | The techniques developed within HOKEY could be applicable to IEEE | |||
802.21 if the necessary issues with handover between different lower | 802.21 if the necessary issues with handover between different lower | |||
layers can be resolved. In particular, pre-authentication may be | layers can be resolved. In particular, pre-authentication may be | |||
more appropriate than re-authentication. | more appropriate than re-authentication. | |||
7.3. CAPWAP Applicability | 6.3. CAPWAP Applicability | |||
The IETF CAPWAP WG [RFC3990] is developing a protocol between what is | The IETF CAPWAP WG [RFC3990] is developing a protocol between what is | |||
termed an Access Controller (AC) and Wireless Termination Points | termed an Access Controller (AC) and Wireless Termination Points | |||
(WTP). The AC and WTP can be mapped to a WLAN switch and Access | (WTP). The AC and WTP can be mapped to a WLAN switch and Access | |||
Point respectively. The CAPWAP model supports both split and | Point respectively. The CAPWAP model supports both split and | |||
integrated MAC architectures, with the authenticator always being | integrated MAC architectures, with the authenticator always being | |||
implemented at the AC. | implemented at the AC. | |||
The proposed work on EAP efficient re-authentication protocol | The proposed work on EAP efficient re-authentication protocol | |||
addresses an inter-authenticator handover problem from an EAP | addresses an inter-authenticator handover problem from an EAP | |||
perspective, which applies during handover between ACs. Inter- | perspective, which applies during handover between ACs. Inter- | |||
controller handover is a topic yet to be addressed in great detail | controller handover is a topic yet to be addressed in great detail | |||
and the re-authentication work can potentially address it in an | and the re-authentication work can potentially address it in an | |||
effective manner. | effective manner. | |||
7.4. Inter-Technology Handover | 6.4. Inter-Technology Handover | |||
EAP is used for access authentication by several technologies and is | EAP is used for access authentication by several technologies and is | |||
under consideration for use over several other technologies going | under consideration for use over several other technologies going | |||
forward. Given that, it should be feasible to support smoother | forward. Given that, it should be feasible to support smoother | |||
handover across technologies. That is one of the big advantages of | handover across technologies. That is one of the big advantages of | |||
using a common authentication protocol. Authentication procedures | using a common authentication protocol. Authentication procedures | |||
typically add substantial handover delays. | typically add substantial handover delays. | |||
An EAP peer that has multiple radio technologies (802.11 and GSM, for | An EAP peer that has multiple radio technologies (802.11 and GSM, for | |||
instance) must perform the full EAP exchange on each interface upon | instance) must perform the full EAP exchange on each interface upon | |||
every horizontal or vertical handover. With a method independent EAP | every horizontal or vertical handover. With a method independent EAP | |||
efficient re-authentication, it is feasible to support faster | efficient re-authentication, it is feasible to support faster | |||
handover even in the vertical handover cases, when the peer may be | handover even in the vertical handover cases, when the peer may be | |||
roaming from one technology to another. | roaming from one technology to another. | |||
8. 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 6 for further details. | and authorization. See section Section 5 for further details. | |||
9. 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 | ||||
This document represents the synthesis of two problem statement | ||||
documents. In this section, we acknowledge their contributions. | ||||
Authors of "AAA based Keying for Wireless Handovers: Problem | ||||
Statement" are: | ||||
Madjid Nakhjiri | ||||
Motorola Labs | ||||
Email: madjid.nakhjiri@motorola.com | ||||
Mohan Parthasarathy | ||||
Nokia | ||||
Email: mohan.parthasarathy@nokia.com | ||||
Julien Bournelle | ||||
France Telecom R&D | ||||
Email: julien.bournelle@orange-ftgroup.com | ||||
Hannes Tschofenig | ||||
Siemens | ||||
Email: Hannes.Tschofenig@siemens.com | ||||
Rafael Marin Lopez, Editor | ||||
Universidad de Murcia | ||||
Email: rafa@dif.um.es | ||||
Authors of "Problem Statement on EAP Efficient Re-authentication and | ||||
Key Management" are: | ||||
Vidya Narayanan | ||||
QUALCOMM, Inc. | ||||
Email: vidyan@qualcomm.com | ||||
Lakshminath Dondeti | ||||
QUALCOMM, Inc. | ||||
Email: ldondeti@qualcomm.com | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |||
Levkowetz, "Extensible Authentication Protocol (EAP)", | Levkowetz, "Extensible Authentication Protocol (EAP)", | |||
RFC 3748, June 2004. | RFC 3748, June 2004. | |||
End of changes. 32 change blocks. | ||||
88 lines changed or deleted | 114 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/ |