Handover Key Management and Re-Authentication Problem Statement
RFC 5169
Network Working Group T. Clancy
Request for Comments: 5169 LTS
Category: Informational M. Nakhjiri
Motorola
V. Narayanan
L. Dondeti
Qualcomm
March 2008
Handover Key Management and Re-Authentication Problem Statement
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document describes the Handover Keying (HOKEY) re-authentication
problem statement. The current Extensible Authentication Protocol
(EAP) keying framework is not designed to support re-authentication
and handovers without re-executing an EAP method. This often causes
unacceptable latency in various mobile wireless environments. This
document details the problem and defines design goals for a generic
mechanism to reuse derived EAP keying material for handover.
Clancy, et al. Informational [Page 1]
RFC 5169 HOKEY Re-Auth PS March 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
6.1. Method-Specific EAP Re-Authentication . . . . . . . . . . 9
6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Clancy, et al. Informational [Page 2]
RFC 5169 HOKEY Re-Auth PS March 2008
1. Introduction
The Extensible Authentication Protocol (EAP), specified in RFC 3748
[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).
In many common deployment scenarios, 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 encapsulating
EAP packets from a network-access technology lower layer within 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.
After successful authentication, the EAP server 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.
Note that while the authenticator is one logical device, there can be
multiple physical devices involved. For example, the CAPWAP model
[RFC3990] splits authenticators into two logical devices: Wireless
Termination Points (WTPs) and Access Controllers (ACs). Depending on
Show full document text