draft-ietf-hokey-reauth-ps-00.txt   draft-ietf-hokey-reauth-ps-01.txt 
HOKEY Working Group T. Clancy, Editor HOKEY Working Group T. Clancy, Editor
Internet-Draft LTS Internet-Draft LTS
Intended status: Informational January 16, 2007 Intended status: Informational January 24, 2007
Expires: July 20, 2007 Expires: July 28, 2007
Handover Key Management and Re-authentication Problem Statement Handover Key Management and Re-authentication Problem Statement
draft-ietf-hokey-reauth-ps-00 draft-ietf-hokey-reauth-ps-01
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 20, 2007. This Internet-Draft will expire on July 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The Internet Society (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 hand-off.
Table of Contents Table of Contents
1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 7
6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 8 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. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9
7.3. Inter-Technology Hand-Off . . . . . . . . . . . . . . . . 10 7.3. Inter-Technology Hand-Off . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
skipping to change at page 4, line 5 skipping to change at page 4, line 5
"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
protocol uses the MSK to derive additional keys, including the protocol uses the MSK to derive additional keys, including the
transient session keys (TSK) used per-packet access encryption and transient session keys (TSK) used per-packet access encryption and
enforcement. Figure Figure 1 depicts this process. enforcement. Figure Figure 1 depicts this process.
+--------+ +---------------+ +----------+ +--------+ +---------+ +--------+
| EAP |<----->| Passthrough |<--->| EAP | | EAP |<----->| Authen- |<------------------->| EAP |
| Client | L2/L3 | Authenticator | AAA | Server | | Client | L2/L3 | ticator | AAA | Server |
+--------+ +---------------+ +----------+ +--------+ +---------+ +--------+
^ ^
| +---------+ |
\-------------------------->| Authen- |<--------/
L2/L3 | ticator | AAA
+---------+
<------------- EAP Authentication ----------> Initial Authentication:
<---- MSK Transport ---- <----------------- EAP Authentication ------------->
<------ MSK Transport -------------
<- TSK Generation ->
<-- TSK Generation --> Re-Authentication / Hand-off:
<----------------- EAP Authentication ------------->
<- MSK Transport -
<---------- 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
[RFC3990] WTPs communicate using L2 protocols with the EAP client and [RFC3990] WTPs communicate using L2 protocols with the EAP client and
ACs communicate using AAA to the EAP server, while using CAPWAP ACs communicate using AAA to the EAP server, while using CAPWAP
protocols to communicate with each other. Depending on the protocols to communicate with each other. Depending on the
configuration, authenticator features can be split in a variety of configuration, authenticator features can be split in a variety of
skipping to change at page 6, line 32 skipping to change at page 6, line 41
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]. [I-D.housley-aaa-key-mgmt].
Compatability: Compatibility and especially co-existence with Compatability: Compatibility and co-existence with compliant
current EAP implementations and deployment SHOULD be provided. ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be
Compatibility with other fast transition mechanisms SHOULD also 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
[I-D.housley-aaa-key-mgmt] to further define the security goals to be [I-D.housley-aaa-key-mgmt] to further define the security goals to be
achieved by a complete re-authentication keying solution. achieved by a complete re-authentication keying solution.
6.1. Key Context and Domino Effect 6.1. Key Context and Domino Effect
skipping to change at page 7, line 35 skipping to change at page 7, line 45
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 [I-D.housley-aaa-key-mgmt] defines, a fresh key is one that is
generated for the intended use. This would mean the key hierarchy generated for the intended use. This would mean the key hierarchy
MUST provide for creation of multiple cryptographically separate MUST provide for creation of multiple cryptographically separate
child keys from a root key at higher level. Furthermore, the keying child keys from a root key at higher level. Furthermore, the keying
solution needs to provide mechanisms for authorized refreshing each solution needs to provide mechanisms for refreshing each of the keys
of the keys within the key hierarchy. within the key 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 7 skipping to change at page 9, line 15
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, provides a mechanism to One of the EAP lower layers, IEEE 802.11, is in the process of
avoid the problem of repeated full EAP exchanges in a limited specifying a mechanism to avoid the problem of repeated full EAP
setting, by introducing a two-level key hierarchy. The EAP exchanges in a limited setting, by introducing a two-level key
authenticator is collocated with what is known as an R0 Key Holder hierarchy. The EAP authenticator is collocated with what is known as
(R0-KH), which receives the MSK from the EAP server. A pairwise an R0 Key Holder (R0-KH), which receives the MSK from the EAP server.
master key (PMK-R0) is derived from the last 32 octets of the MSK. A pairwise master key (PMK-R0) is derived from the last 32 octets of
Subsequently, the R0-KH derives an PMK-R1 to be handed out to the the MSK. Subsequently, the R0-KH derives an PMK-R1 to be handed out
attachment point of the peer. When the peer moves from one R1-KH to to the attachment point of the peer. When the peer moves from one
another, a new PMK-R1 is generated by the R0-KH and handed out to the R1-KH to another, a new PMK-R1 is generated by the R0-KH and handed
new R1-KH. The transport protocol used between the R0-KH and the out to the new R1-KH. The transport protocol used between the R0-KH
R1-KH is not specified at the moment. 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.
Furthermore, in the 802.11r architecture, the R0-KH may actually be
located close to the edge, thereby creating a vulnerability: If the
R0-KH is compromised, all PMK-R1s derived from the corresponding PMK-
R0s will also be compromised.
The proposed work on EAP efficient re-authentication protocol aims at The proposed work on EAP efficient re-authentication protocol aims at
addressing the problem in a lower layer agnostic manner that also can addressing re-authentication in a lower layer agnostic manner that
operate without some of the restrictions or shortcomings of 802.11r also can fill some of the gaps in IEEE 802.11r.
mentioned above.
7.2. CAPWAP Applicability 7.2. CAPWAP Applicability
The IETF CAPWAP WG is developing a protocol between what is termed an The IETF CAPWAP WG is developing a protocol between what is termed an
Access Controller (AC) and Wireless Termination Points (WTP). The AC Access Controller (AC) and Wireless Termination Points (WTP). The AC
and WTP can be mapped to a WLAN switch and Access Point respectively. and WTP can be mapped to a WLAN switch and Access Point respectively.
The CAPWAP model supports both split and integrated MAC The CAPWAP model supports both split and integrated MAC
architectures, with the authenticator always being implemented at the architectures, with the authenticator always being implemented at the
AC. 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 hand-off problem from an EAP
perspective, which applies during hand-off between ACs. Inter- perspective, which applies during hand-off between ACs. Inter-
controller hand-offs is a topic yet to be addressed in great detail controller hand-offs 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.
skipping to change at page 11, line 20 skipping to change at page 11, line 20
[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.
[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-16 (work in Management Framework", draft-ietf-eap-keying-17 (work in
progress), January 2007. progress), January 2007.
[I-D.housley-aaa-key-mgmt] [I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-06 (work in Management", draft-housley-aaa-key-mgmt-06 (work in
progress), November 2006. 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
 End of changes. 18 change blocks. 
40 lines changed or deleted 45 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/