draft-ietf-hokey-reauth-ps-07.txt   draft-ietf-hokey-reauth-ps-08.txt 
HOKEY Working Group T. Clancy HOKEY Working Group T. Clancy
Internet-Draft LTS Internet-Draft LTS
Intended status: Informational M. Nakhjiri Intended status: Informational M. Nakhjiri
Expires: May 13, 2008 Motorola Expires: August 13, 2008 Motorola
V. Narayanan V. Narayanan
L. Dondeti L. Dondeti
Qualcomm Qualcomm
November 10, 2007 February 10, 2008
Handover Key Management and Re-authentication Problem Statement Handover Key Management and Re-authentication Problem Statement
draft-ietf-hokey-reauth-ps-07 draft-ietf-hokey-reauth-ps-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2008. This Internet-Draft will expire on August 13, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes the Handover Keying (HOKEY) problem This document describes the Handover Keying (HOKEY) re-authentication
statement. The current Extensible Authentication Protocol (EAP) problem statement. The current Extensible Authentication Protocol
keying framework is not designed to support re-authentication and (EAP) keying framework is not designed to support re-authentication
handovers. This often causes unacceptable latency in various mobile and handovers without re-executing an EAP method. This often causes
wireless environments. The HOKEY Working Group plans to address unacceptable latency in various mobile wireless environments. This
these problems by designing a generic mechanism to reuse derived EAP document details the problem and defines design goals for a generic
keying material for handover. mechanism to reuse derived EAP keying material for handover.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8
6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 8
6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), specified in RFC 3748 The Extensible Authentication Protocol (EAP), specified in RFC 3748
[RFC3748] is a generic framework supporting multiple authentication [RFC3748] is a generic framework supporting multiple authentication
methods. The primary purpose of EAP is network access control. It methods. The primary purpose of EAP is network access control. It
also supports exporting session keys derived during the also supports exporting session keys derived during the
authentication. The EAP keying hierarchy defines two keys that are authentication. The EAP keying hierarchy defines two keys that are
derived at the top level, the Master Session Key (MSK) and the derived at the top level, the Master Session Key (MSK) and the
Extended Master Session Key (EMSK). Extended Master Session Key (EMSK).
In many common deployment scenario, an EAP peer and EAP server In many common deployment 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 encapsulating
EAP packets from the layer 2 (L2) or layer 3 (L3) network access EAP packets from a network access technology lower layer within the
technology to the Authentication, Authorization, and Accounting (AAA) Authentication, Authorization, and Accounting (AAA) protocol. The
protocol. The authenticator does not directly participate in the EAP authenticator does not directly participate in the EAP exchange, and
exchange, and simply acts as a gateway during the EAP method simply acts as a gateway during the EAP method execution.
execution.
According to [RFC3748], after successful authentication, the server After successful authentication, the EAP server transports the MSK to
to transports the MSK to the authenticator. Note that this is the authenticator. Note that this is performed using AAA protocols,
performed using AAA protocols, not EAP itself. The underlying L2 or not EAP itself. The underlying L2 or L3 protocol uses the MSK to
L3 protocol uses the MSK to derive additional keys, including the derive additional keys, including the transient session keys (TSKs)
transient session keys (TSKs) used for per-packet encryption and used for per-packet encryption and authentication.
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 frequently
not efficient in cases where the peer is a mobile device. When a not efficient in cases where the peer is a mobile device
peer arrives at the new authenticator, the security restraints will [MSA03][KP01]. In existing implementations, when a peer arrives at
require the peer to run an EAP method irrespective of whether it has the new authenticator, it runs an EAP method irrespective of whether
been authenticated to the network recently and has unexpired keying it 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 involves an EAP-
trips between the EAP peer and the server. Response/Identity message from the peer to server, followed by one or
more round trips between the EAP server and peer to perform the
authentication, followed by the EAP-Success or EAP-Failure message
from the EAP server to peer. At a minimum, the peer has 2 round
trips with the EAP 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 or EAP lower-layer specific. Furthermore, these
limited in scope. Furthermore, these solutions do not deal with solutions do not deal with scenarios involving handovers to new
scenarios involving handovers to new authenticators, or do not authenticators, or do not conform to the AAA keying requirements
conform to the AAA keying requirements specified in [RFC4962]. specified in [RFC4962].
This document provides a detailed description of efficient EAP-based This document provides a detailed description of efficient EAP-based
re-authentication protocol requirements. re-authentication protocol design goals. The scope of this protocol
is specifically re-authentication and handover between authenticators
within a single administrative domain. Inter-technology handover and
inter-administrative-domain handover are outside the scope of this
protocol.
2. Terminology 2. Terminology
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119], with the
qualification that unless otherwise stated they apply to the design
of the re-authentication protocol, not its implementation or
application.
With respect to EAP, this document follows the terminology that has With respect to EAP, this document follows the terminology that has
been defined in [RFC3748] and [I-D.ietf-eap-keying]. been defined in [RFC3748] and [I-D.ietf-eap-keying].
3. Problem Statement 3. Problem Statement
Under the existing model, any re-authentication requires a full EAP Under the existing model, any re-authentication requires a full EAP
exchange with the EAP server in its home domain [RFC3748]. An EAP exchange with the EAP server to which the peer initially
conversation with a full EAP method run can take several round trips authenticated [RFC3748]. This introduces handover latency from both
and significant time to complete, causing delays in re-authentication network transit time and processing delay. In service provider
and handover times. Some methods [RFC4187] specify the use of keys networks, the home EAP server for a peer could be on the other side
and state from the initial authentication to finish subsequent of the world, and typical intercontinental latencies across the
authentications in fewer round trips. However, even in those cases, Internet are 100 to 300 milliseconds per round trip [LGS07].
multiple round trips to the EAP server are still involved. Processing delays average a couple of milliseconds for symmetric-key
Furthermore, many commonly-used EAP methods do not offer such a fast operations and hundreds of milliseconds for public-key operations.
re-authentication feature. In summary, it is undesirable to have to
run a full EAP method each time a peer authenticates to a new
authenticator or needs to extend its current authentication with the
same authenticator. Furthermore, it is desirable to specify a
method-independent, efficient, re-authentication protocol. Keying
material from the full authentication can be used to enable efficient
re-authentication.
Significant network latency between the peer and EAP server is An EAP conversation with a full EAP method run can take two or more
another source of delay during re-authentication. It is desirable to round trips and to complete, causing delays in re-authentication and
have a local server with low-latency connectivity to the peer that handover times. Some methods specify the use of keys and state from
can facilitate re-authentication. the initial authentication to finish subsequent authentications in
fewer round trips and without using public-key operations (detailed
Section 6.1). However, even in those cases, multiple round trips to
the EAP server are required, resulting in unacceptable handover
times.
Lastly, a re-authentication protocol should also be capable of In summary, it is undesirable to run an EAP Identity and complete EAP
supporting handover keying. Handover keying allows an EAP server to method exchange each time a peer authenticates to a new authenticator
pass authentication information to a remote re-authentication server, or needs to extend its current authentication with the same
allowing a peer to re-authenticate to that re-authentication server authenticator. Furthermore, it is desirable to specify a method-
without having to communicate with its home re-authentication server. independent, efficient, re-authentication protocol. Keying material
from the initial authentication can be used to enable efficient re-
authentication. It is also desirable to have a local server with
low-latency connectivity to the peer that can facilitate re-
authentication. Lastly, a re-authentication protocol should also be
capable of supporting scenarios where an EAP server passes
authentication information to a remote re-authentication server,
allowing a peer to re-authenticate locally without having to
communicate with its home re-authentication server.
These problems are the primary issues to be resolved. In solving These problems are the primary issues to be resolved. In solving
them, there are a number of constraints to conform to and those them, there are a number of constraints to conform to and those
result in some additional work to be done in the area of EAP keying. result in some additional work to be done in the area of EAP keying.
4. Design Goals 4. Design Goals
The following are the goals and constraints in designing the EAP re- The following are the goals and constraints in designing the EAP re-
authentication and key management protocol: authentication and key management protocol:
Lower latency operation: The protocol MUST be responsive to handover Lower latency operation: The protocol MUST be responsive to handover
and re-authentication latency performance objectives within a and re-authentication latency performance objectives within a
mobile access network. A solution that reduces latency as mobile access network. A solution that reduces latency as
compared to a full EAP authentication will be most favorable. compared to a full EAP authentication will be most favorable,
since in networks that rely on reactive re-authentication this
will directly impact handover times.
EAP lower-layer independence: Any keying hierarchy and protocol EAP lower-layer independence: Any keying hierarchy and protocol
defined MUST be lower layer independent in order to provide the defined MUST be lower layer independent in order to provide
capability over heterogeneous technologies. The defined protocols capabilities over heterogeneous technologies. The defined
MAY require some additional support from the lower layers that use protocols MAY require some additional support from the lower
it. Any keying hierarchy and protocol defined MUST accommodate layers that use it, but should not require any particular lower
inter-technology heterogeneous handover. layer.
EAP method independence: Changes to existing EAP methods MUST NOT be EAP method independence: Changes to existing EAP methods MUST NOT be
required as a result of the re-authentication protocol. There required as a result of the re-authentication protocol. There
MUST be no requirements imposed on future EAP methods. Note that MUST be no requirements imposed on future EAP methods, provided
the only EAP methods for which independence is required are those they satisfy [I-D.ietf-eap-keying] and [RFC4017]. Note that the
that conform to the specifications of [I-D.ietf-eap-keying] and only EAP methods for which independence is required are those that
[RFC4017]. currently conform to the specifications of [I-D.ietf-eap-keying]
and [RFC4017]. In particular, methods that do not generate the
keys required by [I-D.ietf-eap-keying] need not be supported by
the re-authentication protocol.
AAA protocol compatibility and keying: Any modifications to EAP and AAA protocol compatibility and keying: Any modifications to EAP and
EAP keying MUST be compatible with RADIUS and Diameter. EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design]
Extensions to both RADIUS and Diameter to support these EAP and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both
modifications are acceptable. The designs and protocols must RADIUS and Diameter to support these EAP modifications are
acceptable. The designs and protocols must be configurable to
satisfy the AAA key management requirements specified in RFC 4962 satisfy the AAA key management requirements specified in RFC 4962
[RFC4962]. [RFC4962].
Compatability: Compatibility and co-existence with compliant Compatibility: Compatibility and co-existence with compliant
([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
provided. The keying hierarchy or protocol extensions MUST NOT provided. Specifically, the protocol should be designed such that
preclude the use of CAPWAP or IEEE 802.11r. fall back to EAP authentication occurs if not all devices in the
network support fast re-authentication.
Cryptographic Agility: Any re-authentication protocol MUST support
cryptographic algorithm agility, to avoid hard-coded primitives
whose security may eventually prove to be compromised. The
protocol MAY support cryptographic algorithm negotiation, provided
it does not adversely affect overall performance (i.e. by
requiring additional round trips).
5. Security Goals 5. Security Goals
The section draws from the guidance provided in [RFC4962] to further The section draws from the guidance provided in [RFC4962] to further
define the security goals to be achieved by a complete re- define the security goals to be achieved by a complete re-
authentication keying solution. authentication keying solution.
5.1. Key Context and Domino Effect 5.1. Key Context and Domino Effect
Any key MUST have a well-defined scope and MUST be used in a specific Any key must have a well-defined scope and must be used in a specific
context and for the intended use. This specifically means the context and for the intended use. This specifically means the
lifetime and scope of each key MUST be defined clearly so that all lifetime and scope of each key must be defined clearly so that all
entities that are authorized to have access to the key have the same entities that are authorized to have access to the key have the same
context during the validity period. In a hierarchical key structure, context during the validity period. In a hierarchical key structure,
the lifetime of lower level keys MUST NOT exceed the lifetime of the lifetime of lower level keys must not exceed the lifetime of
higher level keys. This requirement MAY imply that the context and higher level keys. This requirement may imply that the context and
the scope parameters have to be exchanged. Furthermore, the the scope parameters have to be exchanged. Furthermore, the
semantics of these parameters MUST be defined to provide proper semantics of these parameters must be defined to provide proper
channel binding specifications. The definition of exact parameter channel binding specifications. The definition of exact parameter
syntax definition is part of the design of the transport protocol syntax definition is part of the design of the transport protocol
used for the parameter exchange and that may be outside scope of this used for the parameter exchange and that may be outside scope of this
protocol. protocol.
If a key hierarchy is deployed, compromising lower level keys MUST If a key hierarchy is deployed, compromising lower level keys must
NOT result in a compromise of higher level keys which they were used not result in a compromise of higher level keys which were used to
to derive the lower level keys. The compromise of keys at each level derive the lower level keys. The compromise of keys at each level
MUST NOT result in compromise of other keys at the same level. The must not result in compromise of other keys at the same level. The
same principle applies to entities that hold and manage a particular same principle applies to entities that hold and manage a particular
key defined in the key hierarchy. Compromising keys on one key defined in the key hierarchy. Compromising keys on one
authenticator MUST NOT reveal the keys of another authenticator. authenticator must not reveal the keys of another authenticator.
Note that the compromise of higher-level keys has security Note that the compromise of higher-level keys has security
implications on lower levels. implications on lower levels.
Guidance on parameters required, caching, storage and deletion Guidance on parameters required, caching, storage and deletion
procedures to ensure adequate security and authorization provisioning procedures to ensure adequate security and authorization provisioning
for keying procedures MUST be defined in a solution document. for keying procedures must be defined in a solution document.
All the keying material MUST be uniquely named so that it can be All the keying material must be uniquely named so that it can be
managed effectively. managed effectively.
5.2. Key Freshness 5.2. Key Freshness
As [RFC4962] defines, a fresh key is one that is generated for the As [RFC4962] defines, a fresh key is one that is generated for the
intended use. This would mean the key hierarchy MUST provide for intended use. This would mean the key hierarchy must provide for
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.
5.3. Authentication 5.3. Authentication
Each party in the handover keying architecture MUST be authenticated Each handover keying participant must be authenticated to any other
to any other party with whom it communicates, and securely provide party with whom it communicates to the extent it is necessary to
its identity to any other entity that may require the identity for ensure proper key scoping, and securely provide its identity to any
defining the key scope. The identity provided MUST be meaningful other entity that may require the identity for defining the key
according to the protocol over which the two parties communicate. scope.
5.4. Authorization 5.4. Authorization
The EAP Key management document [I-D.ietf-eap-keying] discusses The EAP Key management document [I-D.ietf-eap-keying] discusses
several vulnerabilities that are common to handover mechanisms. One several vulnerabilities that are common to handover mechanisms. One
important issue arises from the way the authorization decisions might important issue arises from the way the authorization decisions might
be handled at the AAA server during network access authentication. be handled at the AAA server during network access authentication.
For example, if AAA proxies are involved, they may also influence in For example, if AAA proxies are involved, they may influence
the authorization decision. Furthermore, the reasons for making a authorization decisions. 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.
5.5. Channel Binding 5.5. Channel Binding
Channel Binding procedures are needed to avoid a compromised Channel Binding procedures are needed to avoid a compromised
intermediate authenticator providing unverified and conflicting intermediate authenticator providing unverified and conflicting
service information to each of the peer and the EAP server. In the service information to each of the peer and the EAP server. To
architecture introduced in this document, there are multiple support fast re-authentication, there will be intermediate entities
intermediate entities between the peer and the back-end EAP server. between the peer and the back-end EAP server. Various keys need to
Various keys need to be established and scoped between these parties be established and scoped between these parties and some of these
and some of these keys may be parents to other keys. Hence the keys may be parents to other keys. Hence the channel binding for
channel binding for this architecture will need to consider layering this architecture will need to consider layering intermediate
intermediate entities at each level to make sure that an entity with entities at each level to make sure that an entity with higher level
higher level of trust can examine the truthfulness of the claims made of trust can examine the truthfulness of the claims made by
by intermediate parties. intermediate parties.
5.6. Transport Aspects 5.6. Transport Aspects
Depending on the physical architecture and the functionality of the Depending on the physical architecture and the functionality of the
elements involved, there may be a need for multiple protocols to elements involved, there may be a need for multiple protocols to
perform the key transport between entities involved in the handover perform the key transport between entities involved in the handover
keying architecture. Thus, a set of requirements for each of these keying architecture. Thus, a set of requirements for each of these
protocols, and the parameters they will carry, MUST be developed. protocols, and the parameters they will carry, must be developed.
Following the requirement specifications, recommendations will be
provided as to whether new protocols or extensions to existing
protocols are needed.
As mentioned, the use of existing AAA protocols for carrying EAP The use of existing AAA protocols for carrying EAP messages and
messages and keying material between the AAA server and AAA clients keying material between the AAA server and AAA clients that have a
that have a role within the architecture considered for the keying role within the architecture considered for the keying problem will
problem will be carefully examined. Definition of specific be carefully examined. Definition of specific parameters, required
parameters, required for keying procedures and to be transferred over for keying procedures and to be transferred over any of the links in
any of the links in the architecture, are part of the scope. The the architecture, are part of the scope. The relation of the
relation of the identities used by the transport protocol and the identities used by the transport protocol and the identities used for
identities used for keying also needs to be explored. keying also needs to be explored.
6. Use Cases and Related Work 6. Use Cases and Related Work
In order to further clarify the items listed in scope of the proposed In order to further clarify the items listed in scope of the proposed
work, this section provides some background on related work and the work, this section provides some background on related work and the
use cases envisioned for the proposed work. use cases envisioned for the proposed work.
6.1. IEEE 802.11r Applicability 6.1. Method-Specific EAP Re-authentication
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], is in A number of EAP methods support fast re-authentication. In this
section we examine their properties in further detail.
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast re-
authentication, bootstrapped by the keys generated during an initial
full authentication. In response to the typical EAP-Request/
Identity, the peer sends a specially formatted identity indicating a
desire to perform a fast re-authentication. A single round-trip
occurs to verify knowledge of the existing keys and provide fresh
nonces for generating new keys. This is followed by an EAP success.
In the end, it requires a single local round trip between the peer
and authenticator, followed by another round trip between the peer
and EAP server. AKA is based on symmetric-key cryptography, so
processing latency is minimal.
EAP-TTLS [I-D.funk-eap-ttls-v0] and PEAP
[I-D.josefsson-pppext-eap-tls-eap] support using TLS session
resumption for fast re-authentication. During the TLS handshake, the
client includes the message ID of the previous session he wishes to
resume, and the server can echo that ID back if it agrees to resume
the session. EAP-FAST [RFC4851] also supports TLS session
resumption, but additionally allows stateless session resumption as
defined in [RFC4507]. Overall, for all three protocols there are
still two round trips between the peer and EAP server, in addition to
the local round trip for the Identity request and response.
To improve performance, fast re-authentication needs to reduce the
number of overall round trips. Optimal performance could result from
eliminating the EAP-Request/Identity and EAP-Response/Identity
messages observed in typical EAP method execution, and allowing a
single round trip between the peer and a local re-authentication
server.
6.2. IEEE 802.11r Applicability
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in
the process of specifying a mechanism to avoid the problem of the process of specifying a 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
by the R0-KH and handed out to the new R1-KH. The transport protocol by the R0-KH and handed out to the new R1-KH. The transport protocol
used between the R0-KH and the R1-KH is not specified. used between the R0-KH and the R1-KH is not specified.
skipping to change at page 8, line 44 skipping to change at page 10, line 7
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.
6.2. IEEE 802.21 Applicability
The IEEE 802.21 working group [IEEE.802-21] is standardizing
mechanisms for media-independent handover. More specifically, they
are looking at transitions from one link-layer protocol to another,
which is currently beyond the scope of the HOKEY charter.
The techniques developed within HOKEY could be applicable to IEEE
802.21 if the necessary issues with handover between different lower
layers can be resolved. In particular, pre-authentication may be
more appropriate than re-authentication.
6.3. CAPWAP Applicability 6.3. CAPWAP Applicability
The IETF CAPWAP Working Group [RFC3990] is developing a protocol The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] allows
between what is termed an Access Controller (AC) and Wireless the functionality of an IEEE 802.11 access point to be split into two
Termination Points (WTP). The AC and WTP can be mapped to a WLAN physical devices in enterprise deployments. Wireless Termination
switch and Access Point respectively. The CAPWAP model supports both Points (WTPs) implement the physical and low-level MAC layers, while
split and integrated MAC architectures, with the authenticator always a centralized Access Controller (AC) provides higher-level management
being implemented at the AC. and protocol execution. Client authentication is handled by the AC,
which acts as the AAA authenticator.
The proposed work on EAP efficient re-authentication protocol
addresses an inter-authenticator handover problem from an EAP
perspective, which applies during handover between ACs. Inter-
controller handover is a topic yet to be addressed in great detail
and the re-authentication work can potentially address it in an
effective manner.
6.4. Inter-Technology Handover
EAP is used for access authentication by several technologies and is One of the many features provided by CAPWAP is the ability to roam
under consideration for use over several other technologies going between WTPs without executing an EAP authentication. To accomplish
forward. Given that, it should be feasible to support smoother this, the AC caches the MSK from an initial EAP authentication, and
handover across technologies. That is one of the big advantages of uses it to execute a separate four-way handshake with the station as
using a common authentication protocol. Authentication procedures it moves between WTPs. The keys resulting from the four-way
typically add substantial handover delays. handshake are then distributed to the WTP to which the station is
associated. CAPWAP is transparent to the station.
An EAP peer that has multiple radio technologies (802.11 and GSM, for CAPWAP currently has no means to support roaming between ACs in an
instance) must perform the full EAP exchange on each interface upon enterprise network. The proposed work on EAP efficient re-
every horizontal or vertical handover. With a method independent EAP authentication addresses an inter-authenticator handover problem from
efficient re-authentication, it is feasible to support faster an EAP perspective, which applies during handover between ACs.
handover even in the vertical handover cases, when the peer may be Inter-AC handover is a topic yet to be addressed in great detail and
roaming from one technology to another. the re-authentication work can potentially address it in an effective
manner.
7. Security Considerations 7. Security Considerations
This document details the HOKEY problem statement. Since HOKEY is an This document details the HOKEY problem statement. Since HOKEY is an
authentication protocol, there are a myriad of security-related authentication protocol, there 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;
skipping to change at page 10, line 31 skipping to change at page 11, line 27
Email: julien.bournelle@orange-ftgroup.com Email: julien.bournelle@orange-ftgroup.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Rafael Marin Lopez Rafael Marin Lopez
Universidad de Murcia Universidad de Murcia
Email: rafa@dif.um.es Email: rafa@dif.um.es
10. References 10. Acknowledgements
10.1. Normative References The authors would like to thank the participants of the HOKEY working
group for their review and comments, including Glen Zorn, Dan
Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to
thank those that provided last call reviews, including Bernard Aboba,
Alan DeKok, and Hannes Tschofenig.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
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, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
10.2. Informative References 11.2. Informative References
[I-D.funk-eap-ttls-v0]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol Version 0 (EAP-TTLSv0)",
draft-funk-eap-ttls-v0-02 (work in progress),
November 2007.
[I-D.ietf-capwap-protocol-specification]
Calhoun, P., "CAPWAP Protocol Specification",
draft-ietf-capwap-protocol-specification-08 (work in
progress), November 2007.
[I-D.ietf-dime-app-design-guide]
Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G.,
and J. Loughney, "Diameter Applications Design
Guidelines", draft-ietf-dime-app-design-guide-06 (work in
progress), January 2008.
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-21 (work in progress), October 2007. draft-ietf-eap-keying-22 (work in progress),
November 2007.
[I-D.ietf-radext-design]
Weber, G. and A. DeKok, "RADIUS Design Guidelines",
draft-ietf-radext-design-02 (work in progress),
December 2007.
[I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
"Protected EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
October 2004.
[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.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile
Communications (GSM) Subscriber Identity Modules (EAP-
SIM)", RFC 4186, January 2006.
[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] [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007.
[IEEE.802-11R-D9.0]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications - Amendment 2: Fast BSS Layer (PHY) specifications - Amendment 2: Fast BSS
Transition", IEEE Standard 802.11r, June 2007. Transition", IEEE Standard 802.11r, January 2008.
[IEEE.802-21] [KP01] Koodli, R. and C. Perkins, "Fast Handover and Context
"Media Independent Handover Working Group", IEEE Working Relocation in Mobile Networks", ACM SIGCOMM Computer and
Group 802.21. Communications Review, October 2001.
[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network
Coordinates in the Wild", USENIX Symposium on Networked
System Design and Implementation, April 2007.
[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical
Analysis of the IEEE 802.11 MAC-Layer Handoff Process",
ACM SIGCOMM Computer and Communications Review,
April 2003.
Authors' Addresses Authors' Addresses
T. Charles Clancy, Editor T. Charles Clancy, Editor
Laboratory for Telecommunications Sciences Laboratory for Telecommunications Sciences
US Department of Defense US Department of Defense
College Park, MD College Park, MD
USA USA
Email: clancy@LTSnet.net Email: clancy@LTSnet.net
skipping to change at page 13, line 7 skipping to change at page 15, line 7
Lakshminath Dondeti Lakshminath Dondeti
Qualcomm, Inc. Qualcomm, Inc.
San Diego, CA San Diego, CA
USA USA
Email: ldondeti@qualcomm.com Email: ldondeti@qualcomm.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 56 change blocks. 
185 lines changed or deleted 286 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/