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