Internet DRAFT - draft-nakhjiri-aaa-hokey-ps

draft-nakhjiri-aaa-hokey-ps






Network Working Group                                        M. Nakhjiri
Internet-Draft                                             Motorola Labs
Expires: December 25, 2006                              M. Parthasarathy
                                                                   Nokia
                                                            J. Bournelle
                                                                 GET/INT
                                                           H. Tschofenig
                                                                 Siemens
                                                     R. Marin Lopez(Ed.)
                                                                    TARI
                                                           June 23, 2006


       AAA based Keying for Wireless Handovers: Problem Statement
                     draft-nakhjiri-aaa-hokey-ps-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 25, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Extensible Authentication Protocol (EAP) provides a framework for



Nakhjiri, et al.        Expires December 25, 2006               [Page 1]

Internet-Draft          EAP Keying Handovers: PS               June 2006


   performing authentication and key management using the AAA
   infrastructure.  The framework deals with a model which includes a
   peer, a pass-through authenticator and a backend authentication
   server.

   Some of the emerging mobile networks use EAP in handover scenarios in
   ways that go beyond currently defined EAP keying framework.  This
   document provides a problem statement for the usage of EAP in these
   emerging mobile networks.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Assumptions  . . . . . . . . . . . . . . . . .  4
   3.  Problem Description  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Key Context and scope, prevention of domino effect . . . . 11
     4.2.  Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Key Freshness  . . . . . . . . . . . . . . . . . . . . . . 12
     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 13
     4.5.  Authentication of all the parties  . . . . . . . . . . . . 13
     4.6.  Channel Binding  . . . . . . . . . . . . . . . . . . . . . 13
     4.7.  EAP method independence  . . . . . . . . . . . . . . . . . 14
     4.8.  Transport aspects  . . . . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA consideration . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Intra-ADC handover example  . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

















Nakhjiri, et al.        Expires December 25, 2006               [Page 2]

Internet-Draft          EAP Keying Handovers: PS               June 2006


1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748] and the keying
   framework [I-D.ietf-eap-keying] documents define an authentication
   and key management framework.  These specifications define how an EAP
   method can be executed between a peer and an EAP server (typically
   located at the Home AAA server) through a pass-through authenticator
   and explain the key management.  EAP Keying framework provide
   guidelines for generation of the keying material (MSK in EAP
   documents), at the EAP peer and the EAP/AAA servers.  It also
   discusses transfer of this keying material to a pass-through
   authenticator for the purpose of further securing access links (i.e.
   deriving transient session keys (TSKs) through the Secure Association
   protocol (SAP) as described in [I-D.ietf-eap-keying]) to secure the
   link between the peer and the authenticator.

   Given that the TSK MAY be bound to particular access link, handover
   between different access links would require generation of new TSKs.
   Wireless networks deploy specific Access Nodes (ANs) providing link
   layer service to the peers, where the ANs are typically defined as
   separate elements from the element that controls them.  On the other
   hand, mapping between those functional elements and the functional
   elements defined in EAP keying framework such as authenticator and
   authenticator ports has not been clear.  This makes the applicability
   of EAP keying framework to each wireless technology difficult.  As a
   result, existing wireless technologies had to create their own
   mappings as follows:

   o  802.11r [802.11r] has introduced the concept of the key holders
      and two levels of key hierarchy between the MSK sent from the AAA
      server and the TSKs (called Pairwise Transient Key, PTK in
      802.11r) to avoid the need for generation of new MSKs in
      conjunction with each AN-handover.  The two levels are PMK-R0 and
      PMK-R1 (PMK stands for Pairwise Master Key).  The PMK-R0 is
      created based on MSK and is held at a so-called PMK-R0 key holder,
      while the PMK-R1 created from PMK-R0 and is kept at a PMK-R1
      holder.  This way the PMK-R0 key holder can create master keys
      (PMK-R1) for all the access points (AP) it is serving.

   o  WiMAX (supporting organization for 802.16e) has introduced a two-
      part authenticator function, in which one part acts as a key
      holder, receiving the MSK from AAA server and calculating keys
      specific to ANs, while the other part residing at the AN acts as
      an authenticator relay and key receiver that receives the master
      keys for link security (authorization key, AK).

   In either case, it seems that these SDOs have recognized that the EAP
   keying model where the EAP server simply sends the MSK to the pass-



Nakhjiri, et al.        Expires December 25, 2006               [Page 3]

Internet-Draft          EAP Keying Handovers: PS               June 2006


   through authenticator to which the EAP peer is directly connected to
   is not sufficient to succinctly design a keying solution for a mobile
   wireless environment even in cases where the peer hands over between
   access nodes that are all served by the same authenticator.  What is
   even more important to note is that neither of these SDOs have
   provided a method for inter-authenticator handovers.

   Given that various standard bodies are extending EAP keying framework
   in different ways to solve the wireless mobility keying for intra-
   authenticator handovers and given that most of these standards do not
   deal with inter-authenticator handovers, it seems appropriate to
   develop a comprehensive handover keying solutions that deals with
   various types of handovers within IETF.  This document intends to
   provide a problem statement for handover keying.  It also describing
   the security goals that the specification needs to meet.


2.  Terminology and Assumptions

   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 [RFC2119].

   Most of the terminology found in this document uses the EAP keying
   document [I-D.ietf-eap-keying].  However, this document defines new
   terms in place of several terms defined in EAP keying framework in
   order to clearly describe the handover keying problem.  Since
   wireless technologies that support handover have the architecture of
   physically or logically separating network attachment points from the
   controller of the network attachment points, it is more reasonable,
   than re-using the existing terms, to define the network attachment
   points as separate elements from the authenticator and other new
   terms that are closely related to this separation of authenticator
   and authenticator ports defined in [I-D.ietf-eap-keying].

   Access Node (AN): The access node is the entity (layer 2 or layer 3)
      residing at the edge of network and is responsible for providing
      access link to the peer.

   EAP server: The EAP server in handover keying has the same
      functionality of a backend EAP server in [RFC3748] and [I-D.ietf-
      eap-keying], i.e, the EAP server terminates the EAP authentication
      method with peer through a pass-through authenticator and can
      perform keying functions.







Nakhjiri, et al.        Expires December 25, 2006               [Page 4]

Internet-Draft          EAP Keying Handovers: PS               June 2006



   EAP pass-through authenticator: The pass-through authenticator is the
      entity between a peer and a backend EAP server that is passing
      through EAP Request and Response messages ([RFC3748]) without
      understanding their data content.  It can understand EAP success
      and failure messages.  The role of pass-through authenticator
      during EAP authentication is defined in [RFC3748].

   Access Domain Controller: Entity responsible for keying needs within
      an Access Domain.  ADC holds a per-ADC specific ADMSK for the
      authentication domain and uses this ADMSK to derive new LSAP-MK
      for different ANs under its control.

   Access Domain (AD): A domain whose authentication (with the backend
      EAP/AAA server) and key management goes through the same ADC.

   Mobile Node (MN) (peer): The entity that receives network access
      through an Access Node--> and acts as an EAP peer functionality as
      described by [RFC3748] and EAP keying framework [I-D.ietf-eap-
      keying], with the exception that mobile node may not have a direct
      link to the EAP pass-through authenticator.  In this document we
      use the terms MN and EAP peer interchangeably.

   SA: Security Association.

   Handover Root Key (HRK): A key that will be used as the root key to
      solve the handover keying problem.  We assume that the HRK is
      generated as a result of a successful EAP authentication and
      keying process and will be available at both the peer and the Home
      AAA server.  Whether the EAP generated MSK or an AMSK (generated
      from EMSK) is used as HRK as the root key is to be determined
      later on.  In the rest of this document, we will only refer to
      HRK.

   Access Domain Master Session Key (ADMSK): A key that is sent to each
      Access Domain Controller (or the key holder function within the
      ADC) that is unique for that ADC and can be used for a root key
      for generation further lower level keys within the domain served
      by the ADC.

   Link Secure Association Protocol (LSAP): In a general case, the
      authenticator function is not located at the AN.  The term Link
      Secure Association Protocol refers to the process used between the
      peer and the AN to generate and manage the security associations
      used to protect the peer-AN link (layer 2 or layer 3).  We
      introduce this term to avoid confusion with term Secure
      Association Protocol (SAP) defined in [I-D.ietf-eap-keying] that
      runs between the peer and the authenticator.  The LSAP protocol



Nakhjiri, et al.        Expires December 25, 2006               [Page 5]

Internet-Draft          EAP Keying Handovers: PS               June 2006


      uses LSAP-MK (below) as a root key and arrives at LSKs.

   LSAP Master key (LSAP-MK): The master key used by the peer and the AN
      during LSAP run to arrive at LSKs between the peer and the AN.
      LSAP-MK is derived from ADMSK through one or more steps in ways to
      be explored.

   Link Session Keys (LSK): The keys derived upon completion of LSAP and
      used to secure the access link between the peer and the AN.  In a
      special case, where the AN and the authenticator are co-located
      and use the same identifiers, the LSKs in this document and the
      transient session keys (TSK) in [I-D.ietf-eap-keying] may become
      the same.

   Key Holder: The functional entity that holds a root key/s and can
      perform further key derivation using that root key.  There may be
      multiple Key Holders in the network (e.g. at the AAA server or
      ADC).



3.  Problem Description

   As mentioned earlier, in wireless access networks, where the peer
   hands off between various ANs, using the keying model described in
   EAP authentication and key management framework causes some
   difficulties in achieving optimized handovers.

   As shown in Figure 1, it is more appropriate to consider a functional
   model, where a functional entity (we have used the term
   Authentication Domain Controller) other than the AN holds the master
   key sent from the AAA server and generates per AN master keys for
   each AN.


   +-+-+-+-+-+     +-+-+-+   +-+-+-+-+-+-+-+    +-+-+-+-+-+-+-+-+
   | MN/     |-----| AN  |---|     ADC     |----|EAP/AAA server |
   |EAP Peer |     +-+-+-+   |             |    +-+-+-+-+-+-+-+-+
   +-+-+-+-+-+               +-+-+-+-+-+-+-+


   Figure 1: Wireless access network with separate AN and Access Domain
   Controller(ADC)

   Important note: EAP pass-through authenticator plays an important
   role in execution of EAP authentications in a deployments employing
   central EAP and AAA servers.  EAP keying also provides specifications
   and requirements for a pass-through authenticator.  As the handover



Nakhjiri, et al.        Expires December 25, 2006               [Page 6]

Internet-Draft          EAP Keying Handovers: PS               June 2006


   keying only uses the results of a previously performed EAP
   authentication, the significance and function of pass-through
   authenticator in the handover keying process (reception and/or
   caching of keys, further derivation, and distribution) may be of less
   importance.  The expected behavior of a pass-through authenticator as
   well as its placement with respect to access domain controller needs
   to be investigated, but it is expected that handover keying channel
   binding solutions may be different than that required for EAP keying.
   For this reason, we will refer to inter-access domain and intra-
   access domain handovers instead of inter-authenticator and intra-
   authenticators respectively.

   Using EAP keying framework on this new architecture model poses some
   design issues in two main cases analyzed following:

   o  Inter-Access Domain Controller handovers: Most of the modern EAP
      methods create both an Master Session Key (MSK) and an Extended
      Master Session Key (EMSK) upon a success authentication.  Most of
      existing access technologies that use EAP keying transport MSK to
      the authenticator (as suggested by the current EAP keying
      framework).  This means they cannot support inter-authenticator
      handover without depending on either an authenticator-anchoring or
      a key context transfer from one authenticator to the next.  The
      anchoring would cause practical limitations in high speed mobility
      environments, while the context transfer will potentially suffer
      from the domino effect (see [I-D.housley-aaa-key-mgmt]), where the
      compromise of a single authenticator may lead to the compromise of
      series.  Writing off those two options, handing over to another
      authenticator would require generation of another MSK for the new
      authenticator (and thus a new EAP authentication).  A new key
      hierarchy should be developed in a way that handover to a new
      authenticator does not require a new full EAP authentication.
      This for instance could be achieved by generating lower level keys
      (called ADMSK) for each access domain from the HRK.  The AAA
      server will then transport the ADMSKs to the entity responsible
      for keying within the access domain.  Since this functionality is
      different from the behavior described for the "pass-through
      authenticator" within EAP document, we have called this entity the
      Access Domain Controller (ADC), even though an ADC will with high
      likelihood include pass-through authenticator functionality that
      assists the peer with its EAP authentications.

   o  Intra-Access Domain Controller handovers: The current EAP keying
      framework does not specify keying details for topologies where
      multiple ANs are grouped under one pass-through authenticator.
      The need for separation of master keys at the pass-through
      authenticator/ADC (ADMSK delivered from AAA server) and master
      keys used for LSAP exchange (called LSAP_MK in this draft) has



Nakhjiri, et al.        Expires December 25, 2006               [Page 7]

Internet-Draft          EAP Keying Handovers: PS               June 2006


      been recognized in several SDOs, such as IEEE 802.11r, 802.16e and
      WiMAX.  The notion of authenticator ports are now being discussed
      to deal with this issue.  Each AN can correspond to an
      authenticator port that may or may not physically be separated
      from the authenticator function.  However, introducing the notion
      of authenticator-port alone does not deal with issues related to
      derivation of AN-specific master keys (LSAP_MK) from ADMSK,
      including key scoping and channel binding issues.  Furthermore, it
      does not solve the delicate problem of the delivery of LSAP_MK
      from pass-through authenticator/ADC to the AN.

   Given both types of handover, some additional issues needs to be
   considered:

   o  Choice of HRK: As mentioned, the inter-authenticator handover
      scenario would require that per-authenticator (per-ADC) keys
      (ADMSK) would be different from the top level key (HRK) generated
      as part of/or as a result of an EAP authentication MSK.  Since EAP
      methods only generate an MSK and an EMSK, and EMSK is not
      transportable and possibly not exportable from the EAP server,
      either a MSK or an AMSK generated from the EMSK (as described in
      [I-D.salowey-eap-emsk-deriv]) are two choices for HRK.  It should
      also be noted that at EAP keying framework has required the
      transported keys to be deleted after transport.  Choosing MSK as
      the root for handover keying key hierarchy (HRK) would mean the
      MSK can no longer be sent to any authenticator and this would mean
      MSK usage would be different in EAP and handover keying solutions.
      Choosing AMSK would not cause any backward compatibility (by
      redefining previous usage of MSK) but would require generation of
      a specification on how AMSK needs to be generated from EMSK.

   o  Fast Re-authentication: The EAP keying framework does not provide
      guidance on fast re-authentication process based on generated keys
      as a consequence of a previous EAP authentication without running
      a new EAP authentication that would help to improve handover
      process.

   This would lead us to the following minimum architecture to realize
   the handover keying solution (note that, in the Figure 2 we name the
   authenticator as Authentication Domain Controller or ADC):











Nakhjiri, et al.        Expires December 25, 2006               [Page 8]

Internet-Draft          EAP Keying Handovers: PS               June 2006


                                  SA1
         <----------------------------------------------------->
                                  SA12
         <----------------------------------------------------->
              SA4             SA3                 SA2
         <----------> <---------------> <---------------------->
                      SA5
         <---------------------------->


                  (LSAP-MK)
   +-+-+-+-+-+     +-+-+-+
   | MN/     |-----| AN1 |---+          (ADMSK1)
   |EAP Peer |     +-+-+-+   |     +--------------+
   +-+-+-+-+-+       ^       +-----|ADC1(AUTH_KH) |---+
                     | SA6   |     +--------------+   |
                     |       |                        |        (HRK)
                     V       |                        |     +-+-+-+-+-+
                   +-+-+-+   |                        |     |AAA/EAP  |
                   | AN2 |---+                        +-+---| Server  |
                   +-+-+-+                              |   +---------+
                                        (ADMSK2)        |
                   +-+-+-+         +--------------+     |
                   | AN 3|---------|ADC2(AUTH_KH) |-----+
                   +-+-+-+         +--------------+

   Figure 2: A wireless handover keying architecture deploying EAP

   As it can be seen in the Figure 2, the EAP pass-through authenticator
   is not specified in any particular place.  Placing the pass-through
   authenticator in the AN is acceptable, as long as the AN is able to
   encapsulate the EAP signaling into AAA signaling and the ADC is able
   to act as a AAA proxy for AAA signaling.  Placing the EAP pass-
   through authenticator in the ADC will possibly require specific
   considerations in the transfer of EAP signaling from the peer over
   the AN and the ADC to the EAP server.  In any case, and as it has
   been mentioned previously, this will need further study.

   Note that, it is assumed that the Home AAA server (AAAH) and the EAP
   server are co-located within the same physical device and possibly
   interact through internal mechanism, and therefore can be considered
   as one trusted party.

   As it can also be noted, this document introduces certain Key Holder
   (AUTH_KH) and key distribution functionality into the Authentication
   Domain Controller (ADC).  As mentioned earlier, EAP keying
   specification has required of a AAA entity (either a AAA server or a
   AAA client) to delete a key (such as ADMSK) after transport.  To



Nakhjiri, et al.        Expires December 25, 2006               [Page 9]

Internet-Draft          EAP Keying Handovers: PS               June 2006


   accommodate such requirements a few things are required:

   1.  A per-ADC ADMSK must be generated from HRK and transported to the
       ADC instead of the HRK (to comply with the delete after transport
       requirement).

   2.  A stateless AAA server (such as RADIUS server) may also have a
       Key Holder (AAA_KH) function that caches the HRK.

   Finally and for completion, various security associations (SA)
   between the architecture entities shown in Figure 2 are described
   below:

   1.  SA1 is a long term credential established between the MN and the
       Home AAA server and used for EAP authentication.  Provisioning of
       SA1 is outside scope.
   2.  SA12 is generated as a result of the EAP authentication between
       EAP peer and EAP server.  For the purpose of handover keying,
       SA12 consists of HRK and other information resulting from EAP
       authentication, such as authentication lifetime, HRK lifetime and
       so on.
   3.  SA2 pre-exists between the ADC and the EAP/AAA server based on
       the AAA infrastructure before the EAP authentication starts.  In
       roaming environments (multiple administrative domains) this SA
       may have to be established through a chain of trust.
   4.  SA3 is between the Access Node and the ADC to protect signalling
       and key transfers.  Provisioning of SA3 is important for
       distribution of LSAP_MKs from authenticator to the AN.  SA3 may
       pre-exist or may be created as part of initial keying.  The
       requirements for SA3 and its creations are to be developed later
       on.
   5.  SA4 is between the peer (MN) and the Access Node and is
       established through LSAP exchange.  SA4 information includes
       LSKs.  Providing key derivation guidelines for SA4 is part of the
       problem being considered.
   6.  SA5 is between the MN and the ADC derived from the EAP
       authentication and key framework procedures.  Providing key
       derivation guidelines and specifications for SA5 is part of the
       problem being considered.
   7.  SA6 represents a possible trust relationship between the ANs.
       The need for this trust for keying solution is to be
       investigated.

   Note that as part of establishing new security associations in
   conjunction with a handover, network access policies may require re-
   authentications to the ADC or the AAA server depending on the type of
   handover.  A handover keying solution can provide additional keys
   (derived from the handover root key) that allow for fast re-



Nakhjiri, et al.        Expires December 25, 2006              [Page 10]

Internet-Draft          EAP Keying Handovers: PS               June 2006


   authentication without requiring support of fast re-authentication
   from the EAP methods.

   As mentioned earlier, the potential physical separation (or
   separation of identifiers) of the ADC and AN will present challenges
   such as the need for an additional key transport protocol between the
   ADC and the AN, channel binding at multiple levels and carrying EAP
   signalling between the peer and the ADC through the AN.

   The most important goal for this effort is to provide a handover
   keying solution that best fit the architecture shown in Figure 2,
   whilst meeting the initially defined security goals.


4.  Security Goals

   The baseline assumption in this document (see Section 3) is to use
   AAA based key management possibly using a key hierarchy stemming from
   an HRK which is generated through the EAP authentication and keying
   process.  However, as we described, there are a number of
   alternatives for deployment of EAP framework to a wireless mobile
   network providing handover keying solutions.

   The definition of key material and associated parameters to derive
   the keys and security associations from an initial EAP authentication
   to support an optimized wireless network handover is the goal of this
   work.  An important goal is to assess what keys and security
   associations (e.g.  SA4 and/or SA5 in Figure 2) are to be re-used or
   re-generated as part of handover or a re-authentication process.  The
   assessment is done considering the handover performance as well as
   the security goals defined in this document.  Definition of
   relationship between the key material, such as definition of the
   hierarchy and child-parent/sister relationship before and after
   handover is part of scope.  Although the exact definition of the
   actual cryptographic functions (Pseudo Random Functions) may not be
   part of the scope, definition of the inputs into the PRFs, e.g. root
   keys and associated parameters (e.g.  ADC's IDs and nonces) are part
   of solution scope.

   The section will draw from the guidance provided in [I-D.housley-aaa-
   key-mgmt] to further define the security goals to be achieved by a
   complete handover keying solution.

4.1.  Key Context and scope, prevention of domino effect

   Any key, including HRK and the keys derived for the lower levels of
   key hierarchy (e.g., ADMSK, LSKs) MUST have a well-defined scope and
   MUST be used in a specific context and for the intended use.  This



Nakhjiri, et al.        Expires December 25, 2006              [Page 11]

Internet-Draft          EAP Keying Handovers: PS               June 2006


   specifically means the lifetime and scope of each key MUST be defined
   clearly so that all the 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 (e.g., lifetime, ADC's ID,
   authorization information) have to be exchanged.  Furthermore, the
   semantics (not syntax) of these parameters MUST be defined to provide
   proper channel binding specifications.  The definition of exact
   parameter syntax definition is however part of the design of the
   transport protocol used for the parameter exchange and that may be
   outside scope of this document.

   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.  For example, an AN cannot have
   access to keying material for another AN.  That is, compromising keys
   on one AN MUST NOT reveal the keys of another AN.  Note that, the
   compromise of higher level keys has security implications on lower
   levels.

   Guidance on parameters required, caching, storage and deletion
   procedures to ensure adequate security and authorization provisioning
   for keying procedures will be defined in a solution document.

4.2.  Key Naming

   All the keying material starting from HRK and the derivatives MUST be
   uniquely named so that it can be managed effectively.  For example,
   when the peer is engaging in the LSAP, it should be able to identify
   the name of the key that is being used.

4.3.  Key Freshness

   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
   must provide for creation of multiple cryptographically separate
   child keys from a root key at higher level.  For instance, the
   LSAP-MK for the LSAP between the MN and two different ANs must be
   generated freshly and independently, even when both ANs are under the
   same ADC.  Furthermore, the keying solution needs to provide
   mechanisms for authorized refreshing each of the keys within the key
   hierarchy.





Nakhjiri, et al.        Expires December 25, 2006              [Page 12]

Internet-Draft          EAP Keying Handovers: PS               June 2006


4.4.  Authorization

   The EAP Key management document [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 choosing a
   particular decision are not communicated to the AAA clients.  In
   fact, the AAA client only knows the final authorization result.

   If AAA exchange is bypassed, this creates additional challenges to
   ensure that authorization is properly handled.  Possibly differing
   capabilities of the ANs before and after handovers could result in
   correctness issues with these authorization as the AN or AAA client
   may lack information of proper granularity to make access or
   authorization decisions after a handover.  The logical descriptions
   of each of the parties in the architecture in this document assumes
   that all the parties with the same role (ANs, ADCs, etc) have the
   same capabilities when dealing with the AAA and keying matters.

4.5.  Authentication of all the parties

   Each party in the handover keying architecture MUST be authenticated
   to any other party with whom it communicates and provides 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.

4.6.  Channel Binding

   Channel Binding procedures are needed to avoid a compromised
   intermediate authenticator/ADC providing unverified and conflicting
   service information to each of the peer and the EAP server.  However,
   typically only a 3-party model has been considered (see [I-D.arkko-
   eap-service-identity-auth]).  In the architecture introduced in this
   document, there are multiple intermediate entities between the peer
   and the backend EAP/AAA 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 lying intermediate entities at
   each level and make sure that an entity with higher level of trust
   can examine the truthfulness of the claims made by intermediate
   parties (a discussion about hierarchical channel binding can be found
   in [I-D.ohba-eap-channel-binding])






Nakhjiri, et al.        Expires December 25, 2006              [Page 13]

Internet-Draft          EAP Keying Handovers: PS               June 2006


4.7.  EAP method independence

   The handover keying framework needs to be independent of the chosen
   EAP method, as long as the method supports the needs of [RFC4017] and
   [I-D.ietf-eap-keying].

4.8.  Transport aspects

   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.  For instance when keys are transported between
   AAA server and AAA client, the key transport may be performed through
   a AAA protocol.  On the other hand, when the ANs and ADCs are
   physically disparate, and the ADCs perform key management functions
   for the ANs, there will be a need for a key transport protocol
   between the AN and the ADCs.  Thus, a set of requirements for each of
   these protocols (and the parameters they will carry) will be
   developed.  Following the requirement specifications, recommendations
   will be provided as to whether new protocols or extensions to
   existing protocols are needed.

   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.


5.  Security Considerations

   This document discusses an enhancement of EAP key management for in
   the emerging mobile networks.  Security aspects of this enhancement
   are discussed throughout the document.  When the solution for the
   problem statement presented in this document is being specified, the
   solution will be checked against the security goals presented
   previously.


6.  IANA consideration

   This document does not require any actions by IANA.






Nakhjiri, et al.        Expires December 25, 2006              [Page 14]

Internet-Draft          EAP Keying Handovers: PS               June 2006


7.  Acknowledgements

   The authors would like to thank Joe Salowey, Yoshihiro Ohba and
   Kuntal Chowdhury for their useful suggestions on forming this problem
   statement.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-13 (work in
              progress), May 2006.

8.2.  Informative references

   [802.11r]  Institute of Electrical and Electronics Engineer, "Draft
              Amendment to STANDARD FOR Information Technology -
              Telecommunications and Information Exchange Between
              Systems - LAN/MAN Specific Requirements. Part 11:Wireless
              LAN Medium Access Control   (MAC) and Physical Layer (PHY)
              Specifications: Amendment 8: Fast BSS Transition", IEEE
              std. 802.11r/D2.0.

   [I-D.housley-aaa-key-mgmt]
              Housley, R. and B. Aboba, "Guidance for AAA Key
              Management", draft-housley-aaa-key-mgmt-02 (work in
              progress), March 2006.

   [I-D.arkko-eap-service-identity-auth]
              Arkko, J. and P. Eronen, "Authenticated Service
              Information for the Extensible Authentication Protocol
              (EAP)", draft-arkko-eap-service-identity-auth-04 (work in
              progress), October 2005.

   [I-D.ohba-eap-channel-binding]
              Ohba, Y., "Channel Binding Mechanism based on Parameter
              Binding in Key Derivation",
              draft-ohba-eap-channel-binding-01 (work in progress),



Nakhjiri, et al.        Expires December 25, 2006              [Page 15]

Internet-Draft          EAP Keying Handovers: PS               June 2006


              June 2006.

   [I-D.salowey-eap-emsk-deriv]
              Salowey, J., "Specification for the Derivation of Usage
              Specific Root Keys (USRK) from an  Extended Master Session
              Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in
              progress), June 2006.

   [RFC4017]  Stanley, D., Walker, J., and B. Aboba, "Extensible
              Authentication Protocol (EAP) Method Requirements for
              Wireless LANs", RFC 4017, March 2005.








































Nakhjiri, et al.        Expires December 25, 2006              [Page 16]

Internet-Draft          EAP Keying Handovers: PS               June 2006


Appendix A.  Intra-ADC handover example

   Following and for the sake of clarity, we explain an intra-ADC
   handover example. (the example is based on the Figure 2 explained in
   Section 3)

   Initially, the MN (EAP peer) is connected to AN1 which in turn is
   connected to the ADC1.  When MN connects to the access network for
   the first time (through AN1), it can use EAP [RFC3748] to
   authenticate to the access network (AAA server).  This EAP
   authentication generates cryptographic material needed to generate
   the HRK.

   The AAA server can upon generating the HRK and then ADMSK1 forwards
   the ADMSK1 to ADC1, which in turn creates the LSAP master key
   (LSAP-MK) for the LSAP process between AN1 and the peer.  The LSAP
   exchange leads to creation of a set of link security keys (LSKs)
   between the peer and AN1.

   When the peer (MN) needs to handoff to another AN (AN2 in Figure 2),
   the MN needs to the SA4 and potentially SA5 (e.g.  AN2 to AN3
   handover) needs to be updated.  Thus, a new LSAP-MK is needed to
   perform a LSAP with new AN (i.e.  AN2) and arrive with new LSKs with
   it.  Not only the MN needs to know the mechanisms to arrive at a new
   LSAP-MK (LSAP-MK2) from the HRK (or its derivatives), but also there
   must be an infrastructure to deliver the LSAP-MK2 to AN2 in a secure
   and timely manner.  An optimal handover keying solution will achieve
   both of the above should happen without a new EAP authentication and
   possibly without contacting the Home AAA server.






















Nakhjiri, et al.        Expires December 25, 2006              [Page 17]

Internet-Draft          EAP Keying Handovers: PS               June 2006


Authors' Addresses

   Madjid Nakhjiri
   Motorola Labs


   Email: Madjid.nakhjiri@motorola.com


   Mohan Parthasarathy
   Nokia
   313 Fairchild Drive
   Mountain View  CA-94043
   US

   Email: mohan.parthasarathy@nokia.com


   Julien Bournelle
   GET/INT
   9 rue Charles Fourier
   Evry  91011
   France

   Email: julien.bournelle@int-evry.fr


   Hannes Tschofenig
   Siemens Corporate Technology
   Otto-Hahn-Ring 6
   81739 Munich
   Germany

   Email: Hannes.Tschofenig@siemens.com


   Rafael Marin Lopez
   Toshiba America Research,Inc
   1 Telcordia Dr.
   Piscataway, NJ  08854
   USA

   Email: rmlopez@tari.toshiba.com








Nakhjiri, et al.        Expires December 25, 2006              [Page 18]

Internet-Draft          EAP Keying Handovers: PS               June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Nakhjiri, et al.        Expires December 25, 2006              [Page 19]