One document matched: draft-ietf-hokey-reauth-ps-07.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY I-D.ietf-eap-keying PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-eap-keying.xml'>
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3748 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY RFC3990 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3990.xml'>
<!ENTITY RFC4017 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml'>
<!ENTITY RFC4187 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml'>
<!ENTITY RFC4962 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<rfc ipr="full3978" category="info" >
<front>
<title abbrev="HOKEY Reath PS">Handover Key Management and Re-authentication Problem Statement</title>
<author initials="T" surname="Clancy" fullname="T. Charles Clancy, Editor">
<organization abbrev="LTS">Laboratory for Telecommunications Sciences</organization>
<address>
<postal>
<street>US Department of Defense</street>
<city>College Park</city>
<region>MD</region>
<country>USA</country>
</postal>
<email>clancy@LTSnet.net</email>
</address>
</author>
<author initials="M" surname="Nakhjiri" fullname="Madjid Nakhjiri">
<organization abbrev="Motorola">Motorola</organization>
<address>
<email>madjid.nakhjiri@motorola.com</email>
</address>
</author>
<author initials="V" surname="Narayanan" fullname="Vidya Narayanan">
<organization abbrev="Qualcomm">Qualcomm, Inc.</organization>
<address>
<postal>
<street></street>
<city>San Diego</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>vidyan@qualcomm.com</email>
</address>
</author>
<author initials="L" surname="Dondeti" fullname="Lakshminath Dondeti">
<organization abbrev="Qualcomm">Qualcomm, Inc.</organization>
<address>
<postal>
<street></street>
<city>San Diego</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>ldondeti@qualcomm.com</email>
</address>
</author>
<date month="November" year="2007"/>
<workgroup>HOKEY Working Group</workgroup>
<keyword>HOKEY</keyword>
<keyword>Handover Key Management</keyword>
<keyword>Fast Re-authentication</keyword>
<keyword>Mobility</keyword>
<abstract>
<t>This document describes the Handover Keying (HOKEY) problem
statement. The current Extensible Authentication Protocol
(EAP) keying framework is not designed to support
re-authentication and handovers. This often causes
unacceptable latency in various mobile wireless environments.
The HOKEY Working Group plans to address these problems by
designing a generic mechanism to reuse derived EAP keying
material for handover.</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************** -->
<section title="Introduction">
<t>The Extensible Authentication Protocol (EAP), specified
in RFC 3748 <xref target="RFC3748" /> is a generic framework
supporting multiple authentication methods. The primary
purpose of EAP is network access control. It also supports
exporting session keys derived during the authentication.
The EAP keying hierarchy defines two keys that are derived
at the top level, the Master Session Key (MSK) and the
Extended Master Session Key (EMSK).</t>
<t>In many common deployment scenario, an EAP peer and EAP
server authenticate each other through a third party known
as the pass-through authenticator (hereafter referred to as
simply "authenticator"). The authenticator is responsible
for translating EAP packets from the layer 2 (L2) or layer 3
(L3) network access 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.</t>
<t>According to <xref target="RFC3748" />, after successful
authentication, the server to transports the MSK to the
authenticator. Note that this is performed using AAA
protocols, not EAP itself. The underlying L2 or L3 protocol
uses the MSK to derive additional keys, including the
transient session keys (TSKs) used for per-packet encryption
and authentication.</t>
<t>Note that while the authenticator is one logical device,
there can be multiple physical devices involved. For
example, the CAPWAP model <xref target="RFC3990" /> splits
authenticators into two logical devices: Wireless
Termination Points (WTPs) and Access Controllers (ACs).
Depending on the configuration, authenticator features can
be split in a variety of ways between physical devices,
however from the EAP perspective there is only one logical
authenticator.</t>
<t>The current models of EAP authentication and keying are
unfortunately not efficient in cases where the peer is a
mobile device. When a peer arrives at the new
authenticator, the security restraints will require the peer
to run an EAP method irrespective of whether it has been
authenticated to the network recently and has unexpired
keying material. A full EAP method execution may involve
several round trips between the EAP peer and the server.</t>
<t>There have been attempts to solve the problem of
efficient re-authentication in various ways. However, those
solutions are either EAP-method specific, EAP lower-layer
specific, or are otherwise limited in scope. Furthermore,
these solutions do not deal with scenarios involving
handovers to new authenticators, or do not conform to the
AAA keying requirements specified in <xref target="RFC4962"
/>.</t>
<t>This document provides a detailed description of
efficient EAP-based re-authentication protocol
requirements.</t>
</section>
<!-- ******************************************************************** -->
<section title="Terminology">
<t>In this document, several words are used to signify the
requirements of the specification. These words are often
capitalized. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted
as described in <xref target="RFC2119"/>.</t>
<t>With respect to EAP, this document follows the
terminology that has been defined in <xref target="RFC3748"
/> and <xref target="I-D.ietf-eap-keying" />.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="psa" title="Problem Statement">
<t>Under the existing model, any re-authentication requires
a full EAP exchange with the EAP server in its home domain
<xref target="RFC3748" />. An EAP conversation with a full
EAP method run can take several round trips and significant
time to complete, causing delays in re-authentication and
handover times. Some methods <xref target="RFC4187" />
specify the use of keys and state from the initial
authentication to finish subsequent authentications in fewer
round trips. However, even in those cases, multiple round
trips to the EAP server are still involved. Furthermore,
many commonly-used EAP methods do not offer such a fast
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.</t>
<t>Significant network latency between the peer and EAP
server is another source of delay during re-authentication.
It is desirable to have a local server with low-latency
connectivity to the peer that can facilitate
re-authentication.</t>
<t>Lastly, a re-authentication protocol should also be
capable of supporting handover keying. Handover keying
allows an EAP server to pass authentication information to a
remote re-authentication server, allowing a peer to
re-authenticate to that re-authentication server without
having to communicate with its home re-authentication
server.</t>
<t>These problems are the primary issues to be resolved. In
solving 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.</t>
</section>
<section title="Design Goals">
<t>The following are the goals and constraints in designing
the EAP re-authentication and key management protocol:</t>
<t>
<list style="hanging">
<t hangText="Lower latency operation:"> The protocol MUST
be responsive to handover and re-authentication latency
performance objectives within a mobile access network. A
solution that reduces latency as compared to a full EAP
authentication will be most favorable.
<vspace blankLines="1" /></t>
<t hangText="EAP lower-layer independence:"> Any keying
hierarchy and protocol defined MUST be lower layer
independent in order to provide the capability over
heterogeneous technologies. The defined protocols MAY
require some additional support from the lower layers that
use it. Any keying hierarchy and protocol defined MUST
accommodate inter-technology heterogeneous handover.
<vspace blankLines="1" /></t>
<t hangText="EAP method independence:"> Changes to
existing EAP methods MUST NOT be required as a result of
the re-authentication protocol. There MUST be no
requirements imposed on future EAP methods. Note that the
only EAP methods for which independence is required are
those that conform to the specifications of
<xref target="I-D.ietf-eap-keying" /> and
<xref target="RFC4017" />. <vspace blankLines="1" /></t>
<t hangText="AAA protocol compatibility and keying:"> Any
modifications to EAP and EAP keying MUST be compatible
with RADIUS and Diameter. Extensions to both RADIUS and
Diameter to support these EAP modifications are
acceptable. The designs and protocols must satisfy the
AAA key management requirements specified in RFC 4962
<xref target="RFC4962" />. <vspace blankLines="1" /></t>
<t hangText="Compatability:"> Compatibility and
co-existence with compliant (<xref target="RFC3748" />
<xref target="I-D.ietf-eap-keying" />) EAP deployments
SHOULD be provided. The keying hierarchy or protocol
extensions MUST NOT preclude the use of CAPWAP or IEEE
802.11r.</t>
</list>
</t>
</section>
<!-- ******************************************************************** -->
<section title="Security Goals" anchor="sec">
<t>The section draws from the guidance provided in
<xref target="RFC4962" /> to further define the security
goals to be achieved by a complete re-authentication keying
solution.</t>
<section title="Key Context and Domino Effect">
<t>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 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 context
during the validity period. In a hierarchical key
structure, the lifetime of lower level keys MUST NOT
exceed the lifetime of higher level keys. This
requirement MAY imply that the context and the scope
parameters have to be exchanged. Furthermore, the
semantics of these parameters MUST be defined to provide
proper channel binding specifications. The definition of
exact parameter syntax definition is part of the design of
the transport protocol used for the parameter exchange and
that may be outside scope of this protocol.</t>
<t>If a key hierarchy is deployed, compromising lower
level keys MUST NOT result in a compromise of higher level
keys which they were used to 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 same
principle applies to entities that hold and manage a
particular key defined in the key hierarchy. Compromising
keys on one authenticator MUST NOT reveal the keys of
another authenticator. Note that the compromise of
higher-level keys has security implications on lower
levels.</t>
<t>Guidance on parameters required, caching, storage and
deletion procedures to ensure adequate security and
authorization provisioning for keying procedures MUST be
defined in a solution document.</t>
<t>All the keying material MUST be uniquely named so that
it can be managed effectively.</t>
</section>
<section title="Key Freshness">
<t>As <xref target="RFC4962" /> defines,
a fresh key is one that is generated for the intended use.
This would mean the key hierarchy MUST provide for
creation of multiple cryptographically separate child keys
from a root key at higher level. Furthermore, the keying
solution needs to provide mechanisms for
refreshing each of the keys within the key hierarchy.</t>
</section>
<section title="Authentication">
<t>Each party in the handover keying architecture MUST be
authenticated to any other party with whom it
communicates, and securely provide its identity to any
other entity that may require the identity for defining
the key scope. The identity provided MUST be meaningful
according to the protocol over which the two parties
communicate.</t>
</section>
<section title="Authorization">
<t>The EAP Key management document
<xref target="I-D.ietf-eap-keying" /> discusses several
vulnerabilities that are common to handover mechanisms.
One important issue arises from the way the authorization
decisions might be handled at the AAA server during
network access authentication. For example, if AAA
proxies are involved, they may also influence in the
authorization decision. Furthermore, the reasons for
making a particular authorization decision are not
communicated to the authenticator. In fact, the
authenticator only knows the final authorization result.
The proposed solution MUST make efforts to document and
mitigate authorization attacks.</t>
</section>
<section title="Channel Binding">
<t>Channel Binding procedures are needed to avoid a
compromised intermediate authenticator providing
unverified and conflicting service information to each of
the peer and the EAP server. In the architecture
introduced in this document, there are multiple
intermediate entities between the peer and the back-end
EAP server. Various keys need to be established and
scoped between these parties and some of these keys may be
parents to other keys. Hence the channel binding for this
architecture will need to consider layering intermediate
entities at each level to make sure that an entity with
higher level of trust can examine the truthfulness of the
claims made by intermediate parties.</t>
</section>
<section title="Transport Aspects">
<t>Depending on the physical architecture and the
functionality of the elements involved, there may be a
need for multiple protocols to perform the key transport
between entities involved in the handover keying
architecture. Thus, a set of requirements for each of
these 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.</t>
<t>As mentioned, the use of existing AAA protocols for
carrying EAP messages and keying material between the AAA
server and AAA clients that have a role within the
architecture considered for the keying problem will be
carefully examined. Definition of specific parameters,
required for keying procedures and to be transferred over
any of the links in the architecture, are part of the
scope. The relation of the identities used by the
transport protocol and the identities used for keying also
needs to be explored.</t>
</section>
</section>
<!-- ******************************************************************** -->
<section title="Use Cases and Related Work">
<t>In order to further clarify the items listed in scope of
the proposed work, this section provides some background on
related work and the use cases envisioned for the proposed
work.</t>
<section title="IEEE 802.11r Applicability">
<t>One of the EAP lower layers, IEEE 802.11 <xref
target="IEEE.802-11R-D7.0" />, is in the process of
specifying a mechanism to avoid the problem of repeated
full EAP exchanges in a limited setting, by introducing a
two-level key hierarchy. The EAP authenticator is
collocated with 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 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 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 used between the R0-KH and the
R1-KH is not specified.</t>
<t>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 generally be repeated when the PMK-R0
expires. However, in general cases mobiles may roam
beyond the domain of R0-KHs (or EAP authenticators), and
the latency of full EAP authentication remains an
issue.</t>
<t>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 either a star configuration of
security associations between the key 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 of security associations between all
authenticators. This is undesirable.</t>
<t>The proposed work on EAP efficient re-authentication
protocol aims at addressing re-authentication in a lower
layer agnostic manner that also can fill some of the gaps
in IEEE 802.11r.</t>
</section>
<section title="IEEE 802.21 Applicability">
<t>The IEEE 802.21 working group <xref
target="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.</t>
<t>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.</t>
</section>
<section title="CAPWAP Applicability">
<t>The IETF CAPWAP Working Group <xref target="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.</t>
<t>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.</t>
</section>
<section title="Inter-Technology Handover">
<t>EAP is used for access authentication by several
technologies and is under consideration for use over several
other technologies going forward. Given that, it should
be feasible to support smoother handover across
technologies. That is one of the big advantages of using
a common authentication protocol. Authentication
procedures typically add substantial handover delays.</t>
<t>An EAP peer that has multiple radio technologies
(802.11 and GSM, for instance) must perform the full EAP
exchange on each interface upon every horizontal or
vertical handover. With a method independent EAP efficient
re-authentication, it is feasible to support faster
handover even in the vertical handover cases, when the peer
may be roaming from one technology to another.</t>
</section>
</section>
<!-- ******************************************************************** -->
<section title="Security Considerations">
<t>This document details the HOKEY problem statement. Since HOKEY is
an authentication protocol, there are a myriad of security-related
issues surrounding its development and deployment.</t>
<t>In this document, we have detailed a variety of security
properties inferred from <xref
target="RFC4962" /> to which HOKEY must
conform, including the management of key context, scope,
freshness, and transport; resistance to attacks based on the
domino effect; and authentication and authorization. See
section <xref target="sec" /> for further details.</t>
</section>
<!-- ******************************************************************** -->
<section title="IANA Considerations">
<t>This document does not introduce any new IANA considerations.</t>
</section>
<!-- ******************************************************************** -->
<section title="Contributors">
<t>This document represents the synthesis of two problem statement
documents. In this section, we acknowledge their contributions,
and involvement in the early documents.</t>
<t><list style="hanging" hangIndent="2">
<t>Mohan Parthasarathy</t>
<t>Nokia</t>
<t>Email: mohan.parthasarathy@nokia.com
<vspace blankLines="1"/></t>
<t>Julien Bournelle</t>
<t>France Telecom R&D</t>
<t>Email: julien.bournelle@orange-ftgroup.com
<vspace blankLines="1"/></t>
<t>Hannes Tschofenig</t>
<t>Siemens</t>
<t>Email: Hannes.Tschofenig@siemens.com
<vspace blankLines="1"/></t>
<t>Rafael Marin Lopez</t>
<t>Universidad de Murcia</t>
<t>Email: rafa@dif.um.es</t>
</list></t>
</section>
<!-- ******************************************************************** -->
</middle>
<!-- ******************************************************************** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC3748;
&RFC4017;
&RFC4962;
</references>
<references title="Informative References">
&I-D.ietf-eap-keying;
&RFC3990;
&RFC4187;
<reference anchor="IEEE.802-11R-D7.0">
<front>
<title>
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
</title>
<author>
<organization/>
</author>
<date month="June" year="2007"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.11r"/>
</reference>
<reference anchor="IEEE.802-21">
<front>
<title>
Media Independent Handover Working Group
</title>
<author>
<organization/>
</author>
</front>
<seriesInfo name="IEEE" value="Working Group 802.21"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:18 |