draft-ietf-hokey-reauth-ps-01.txt   draft-ietf-hokey-reauth-ps-02.txt 
HOKEY Working Group T. Clancy, Editor HOKEY Working Group T. Clancy, Ed.
Internet-Draft LTS Internet-Draft LTS
Intended status: Informational January 24, 2007 Intended status: Informational July 24, 2007
Expires: July 28, 2007 Expires: January 25, 2008
Handover Key Management and Re-authentication Problem Statement Handover Key Management and Re-authentication Problem Statement
draft-ietf-hokey-reauth-ps-01 draft-ietf-hokey-reauth-ps-02
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 July 28, 2007. This Internet-Draft will expire on January 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (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 EAP keying framework is not designed to
support re-authentication and handovers. This often cause support re-authentication and handovers. This often cause
unacceptable latency in various mobile wireless environments. HOKEY unacceptable latency in various mobile wireless environments. HOKEY
plans to address these HOKEY plans to address these problems by plans to address these HOKEY plans to address these problems by
implementing a generic mechanism to reuse derived EAP keying material implementing a generic mechanism to reuse derived EAP keying material
for hand-off. for handover.
Table of Contents Table of Contents
1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9
7.2. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10
7.3. Inter-Technology Hand-Off . . . . . . . . . . . . . . . . 10 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Authors 1. Authors
The following authors contributed to the HOKEY problem statement The following authors contributed to the HOKEY problem statement
draft: draft:
o Julien Bournelle, France Telecom R&D, o Julien Bournelle, France Telecom R&D,
julien.bournelle@orange-ftgroup.com julien.bournelle@orange-ftgroup.com
o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com
o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es
o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com
o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com
o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com
o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com
2. Introduction 2. Introduction
The extensible authentication protocol (EAP), specified in RFC3748 The extensible authentication protocol (EAP), specified in [RFC3748]
[RFC3748] is a generic framework supporting multiple authentication is a generic framework supporting multiple authentication methods.
methods. The primary purpose of EAP is network access control. It The primary purpose of EAP is network access control. It also
also supports exporting session keys derived during the supports exporting session keys derived during the authentication.
authentication. The EAP keying hierarchy defines two keys that are The EAP keying hierarchy defines two keys that are derived at the top
derived at the top level, the master session key (MSK) and the level, the master session key (MSK) and the extended MSK (EMSK).
extended MSK (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 AAA protocol.
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 transports the MSK to the authenticator. The underlying L2 or L3
skipping to change at page 4, line 21 skipping to change at page 4, line 21
\-------------------------->| Authen- |<--------/ \-------------------------->| Authen- |<--------/
L2/L3 | ticator | AAA L2/L3 | ticator | AAA
+---------+ +---------+
Initial Authentication: Initial Authentication:
<----------------- EAP Authentication -------------> <----------------- EAP Authentication ------------->
<------ MSK Transport ------------- <------ MSK Transport -------------
<- TSK Generation -> <- TSK Generation ->
Re-Authentication / Hand-off: Re-Authentication / Handover:
<----------------- EAP Authentication -------------> <----------------- EAP Authentication ------------->
<- MSK Transport - <- MSK Transport -
<---------- TSK Generation ---------> <---------- TSK Generation --------->
Figure 1: Logical diagram of EAP authentication and key derivation Figure 1: Logical diagram of EAP authentication and key derivation
using passthrough authenticator using passthrough authenticator
Note that while the authenticator is one logical device, there can be Note that while the authenticator is one logical device, there can be
many physical devices involved. For example, in the CAPWAP model many physical devices involved. For example, in the CAPWAP model
skipping to change at page 5, line 6 skipping to change at page 5, line 6
will require the peer to run an EAP method irrespective of whether it will require the peer to run an EAP method irrespective of whether it
has been authenticated to the network recently and has unexpired has been authenticated to the network recently and has unexpired
keying material. A full EAP method execution involves several round keying material. A full EAP method execution involves several round
trips between the EAP peer and the server. 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 conform to the AAA keying requirements specified in [RFC4962].
[I-D.housley-aaa-key-mgmt].
This document provides a detailed description of EAP efficient re- This document provides a detailed description of EAP efficient re-
authentication protocol requirements. authentication protocol requirements.
3. Terminology 3. 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].
This document follows the terminology that has been defined in This document follows the terminology that has been defined in
RFC3748 [RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying]. [RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying].
4. Problem Statement 4. Problem Statement
When a peer needs to re-affirm access to an authenticator or moves When a peer needs to re-affirm access to an authenticator or moves
from one authenticator and reattaches to another authenticator, the from one authenticator and reattaches to another authenticator, the
current EAP keying model requires the peer to engage in a full EAP current EAP keying model requires the peer to engage in a full EAP
exchange with the authentication server in its home domain [RFC3748]. exchange with the authentication server in its home domain [RFC3748].
An EAP conversation with a full EAP method run takes several round An EAP conversation with a full EAP method run takes several round
trips and significant time to complete, causing delays in re- trips and significant time to complete, causing delays in re-
authentication and hand-off times. Some methods [RFC4187] specify authentication and handover times. Some methods [RFC4187] specify
the use of keys and state from the initial authentication to finish the use of keys and state from the initial authentication to finish
subsequent authentications in fewer round trips. However, even in subsequent authentications in fewer round trips. However, even in
those cases, several round trips to the EAP server are still those cases, several round trips to the EAP server are still
involved. Furthermore, many commonly-used EAP methods do not offer involved. Furthermore, many commonly-used EAP methods do not offer
such a fast re-authentication feature. In summary, it is undesirable such a fast re-authentication feature. In summary, it is undesirable
to have to run a full EAP method each time a peer associates with a to have to run a full EAP method each time a peer associates with a
new authenticator or needs to extend its current association with the new authenticator or needs to extend its current association with the
same authenticator. Furthermore, it is desirable to specify a same authenticator. Furthermore, it is desirable to specify a
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
skipping to change at page 6, line 23 skipping to change at page 6, line 22
5. Design Goals 5. 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
defined MUST be lower layer independent in order to provide the defined MUST be lower layer independent in order to provide the
capability over heterogeneous technologies. The defined protocols capability over heterogeneous technologies. The defined protocols
MAY require some additional support from the lower layers that use MAY require some additional support from the lower layers that use
it. Any keying hierarchy and protocol defined MUST accommodate it. Any keying hierarchy and protocol defined MUST accommodate
inter-technology heterogeneous handover. inter-technology heterogeneous handover.
EAP method independence: Changes to existing EAP methods MUST NOT be EAP method independence: Changes to existing EAP methods MUST NOT be
required as a result of the re-authentication protocol. There required as a result of the re-authentication protocol. There
MUST be no requirements imposed on future EAP methods. Note that MUST be no requirements imposed on future EAP methods. Note that
the only EAP methods for which independence is required are those the only EAP methods for which independence is required are those
that conform to the specifications of [I-D.ietf-eap-keying] and that conform to the specifications of [I-D.ietf-eap-keying] and
[RFC4017]. [RFC4017].
AAA protocol compatibility and keying: Any modifications to EAP and AAA protocol compatibility and keying: Any modifications to EAP and
EAP keying MUST be compatible with RADIUS and Diameter. EAP keying MUST be compatible with RADIUS and Diameter.
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 satisfy the AAA key management requirements specified in
[I-D.housley-aaa-key-mgmt]. [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 6. Security Goals
The section draws from the guidance provided in The section draws from the guidance provided in [RFC4962] to further
[I-D.housley-aaa-key-mgmt] to further define the security goals to be define the security goals to be achieved by a complete re-
achieved by a complete re-authentication keying solution. authentication keying solution.
6.1. Key Context and Domino Effect 6.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
skipping to change at page 7, line 41 skipping to change at page 7, line 46
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 6.2. Key Freshness
As [I-D.housley-aaa-key-mgmt] defines, a fresh key is one that is As [RFC4962] defines, a fresh key is one that is generated for the
generated for the intended use. This would mean the key hierarchy intended use. This would mean the key hierarchy MUST provide for
MUST provide for creation of multiple cryptographically separate creation of multiple cryptographically separate child keys from a
child keys from a root key at higher level. Furthermore, the keying root key at higher level. Furthermore, the keying solution needs to
solution needs to provide mechanisms for refreshing each of the keys provide mechanisms for refreshing each of the keys within the key
within the key hierarchy. hierarchy.
6.3. Authentication 6.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 6.4. Authorization
skipping to change at page 9, line 15 skipping to change at page 9, line 19
identities used for keying also needs to be explored. identities used for keying also needs to be explored.
7. Use Cases and Related Work 7. 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 7.1. IEEE 802.11r Applicability
One of the EAP lower layers, IEEE 802.11, is in the process of One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in
specifying a mechanism to avoid the problem of repeated full EAP the process of specifying a mechanism to avoid the problem of
exchanges in a limited setting, by introducing a two-level key repeated full EAP exchanges in a limited setting, by introducing a
hierarchy. The EAP authenticator is collocated with what is known as two-level key hierarchy. The EAP authenticator is collocated with
an R0 Key Holder (R0-KH), which receives the MSK from the EAP server. what is known as an R0 Key Holder (R0-KH), which receives the MSK
A pairwise master key (PMK-R0) is derived from the last 32 octets of from the EAP server. A pairwise master key (PMK-R0) is derived from
the MSK. Subsequently, the R0-KH derives an PMK-R1 to be handed out the last 32 octets of the MSK. Subsequently, the R0-KH derives an
to the attachment point of the peer. When the peer moves from one PMK-R1 to be handed out to the attachment point of the peer. When
R1-KH to another, a new PMK-R1 is generated by the R0-KH and handed the peer moves from one R1-KH to another, a new PMK-R1 is generated
out to the new R1-KH. The transport protocol used between the R0-KH by the R0-KH and handed out to the new R1-KH. The transport protocol
and the R1-KH is not specified. used between the R0-KH and the R1-KH is not specified.
In some cases, a mobile may seldom move beyond the domain of the In some cases, a mobile may seldom move beyond the domain of the
R0-KH and this model works well. A full EAP authentication will R0-KH and this model works well. A full EAP authentication will
generally be repeated when the PMK-R0 expires. However, in general generally be repeated when the PMK-R0 expires. However, in general
cases mobiles may roam beyond the domain of R0-KHs (or EAP cases mobiles may roam beyond the domain of R0-KHs (or EAP
authenticators), and the latency of full EAP authentication remains authenticators), and the latency of full EAP authentication remains
an issue. an issue.
Another consideration is that there needs to be a key transfer Another consideration is that there needs to be a key transfer
protocol between the R0-KH and the R1-KH; in other words, there is protocol between the R0-KH and the R1-KH; in other words, there is
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. CAPWAP Applicability 7.2. IEEE 802.21 Applicability
The IETF CAPWAP WG is developing a protocol between what is termed an The IEEE 802.21 working group [IEEE.802-21] is standardizing
Access Controller (AC) and Wireless Termination Points (WTP). The AC mechanisms for media-independent handover. More specifically, they
and WTP can be mapped to a WLAN switch and Access Point respectively. are looking at transitions from one link-layer protocol to another,
which is currently beyond the scope of the HOKEY charter.
The CAPWAP model supports both split and integrated MAC The techniques developed within HOKEY could be applicable to IEEE
architectures, with the authenticator always being implemented at the 802.21 if the necessary issues with handover between different lower
AC. layers can be resolved. In particular, pre-authentication may be
more appropriate than re-authentication.
7.3. CAPWAP Applicability
The IETF CAPWAP WG [RFC3990] is developing a protocol between what is
termed an Access Controller (AC) and Wireless Termination Points
(WTP). The AC and WTP can be mapped to a WLAN switch and Access
Point respectively. The CAPWAP model supports both split and
integrated MAC architectures, with the authenticator always being
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 hand-off problem from an EAP addresses an inter-authenticator handover problem from an EAP
perspective, which applies during hand-off between ACs. Inter- perspective, which applies during handover between ACs. Inter-
controller hand-offs 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.3. Inter-Technology Hand-Off 7.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 hand- forward. Given that, it should be feasible to support smoother
offs across technologies. That is one of the big advantages of using handover across technologies. That is one of the big advantages of
a common authentication protocol. Authentication procedures using a common authentication protocol. Authentication procedures
typically add substantial hand-off 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 hand-off. With a method independent EAP every horizontal or vertical handover. With a method independent EAP
efficient re-authentication, it is feasible to support faster hand- efficient re-authentication, it is feasible to support faster
offs even in the vertical hand-off 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 8. 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 [I-D.housley-aaa-key-mgmt] to which HOKEY must conform, inferred from [RFC4962] to which HOKEY must conform, including the
including the management of key context, scope, freshness, and management of key context, scope, freshness, and transport;
transport; resistance to attacks based on the domino effect; and resistance to attacks based on the domino effect; and authentication
authentication and authorization. See section Section 6 for further and authorization. See section Section 6 for further details.
details.
9. IANA Considerations 9. IANA Considerations
This document does not introduce any new IANA considerations. This document does not introduce any new IANA considerations.
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.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management,",
BCP 132, RFC 4962, July 2007.
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-17 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), January 2007. progress), February 2007.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-06 (work in
progress), November 2006.
10.2. Informative References 10.2. Informative References
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
Provisioning for Wireless Access Points (CAPWAP) Problem Provisioning for Wireless Access Points (CAPWAP) Problem
Statement", RFC 3990, February 2005. Statement", RFC 3990, February 2005.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[IEEE.802-11R-D7.0]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications - Amendment 2: Fast BSS
Transition", IEEE Standard 802.11r, June 2007.
[IEEE.802-21]
"Media Independent Handover Working Group", IEEE Working
Group 802.21.
Author's Address Author's Address
T. Charles Clancy, Editor T. Charles Clancy, Editor
DoD Laboratory for Telecommunications Sciences DoD Laboratory for Telecommunications Sciences
8080 Greenmead Drive 8080 Greenmead Drive
College Park, MD 20740 College Park, MD 20740
USA USA
Email: clancy@LTSnet.net Email: clancy@LTSnet.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 36 change blocks. 
82 lines changed or deleted 106 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/