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/ |