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/