EAP Working Group                                          Bernard Aboba
INTERNET-DRAFT                                                 Dan Simon
Category: Informational Standards Track                                      Microsoft
<draft-ietf-eap-keying-04.txt>
<draft-ietf-eap-keying-05.txt>                                  J. Arkko
14 November 2004
18 February 2005                                                Ericsson
                                                               P. Eronen
                                                                   Nokia
                                                       H. Levkowetz, Ed.
                                                             ipUnplugged

   Extensible Authentication Protocol (EAP) Key Management Framework

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 May August 22, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).  All Rights Reserved.

Abstract

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   enables extensible network access authentication.  This document
   provides a framework for the generation, transport and usage of
   keying material generated by EAP authentication algorithms, known as
   "methods".  It also specifies the EAP key hierarchy.

Table of Contents

   1.     Introduction ..........................................    4
      1.1       Requirements Language ...........................    4
      1.2       Terminology .....................................    4
      1.3       Overview ........................................    5
      1.4       EAP Invariants ..................................   11
   2.     EAP     Key Hierarchy .....................................   13 Derivation ........................................   14
      2.1       Key Terminology .................................   13   14
      2.2       Key Hierarchy ...................................   15
      2.3       Key Lifetimes ...................................   17
      2.4       Key Names and Scopes ............................   24
      2.5       AAA-Key Derivation ..............................   27
      2.6   21
      2.4       AMSK Key Derivation .............................   28
      2.7   22
      2.5       Key Scope Issues ................................   29 Naming ......................................   23
   3.     Security associations .................................   30   26
      3.1       EAP Method SA ...................................   31   26
      3.2       EAP-Key SA ......................................   33   27
      3.3       AAA SA(s) .......................................   33   28
      3.4       Service SA(s) ...................................   34   28
   4.     Key Management ........................................   30
      4.1       Key Caching .....................................   31
      4.2       Parent-Child Relationships ......................   32
      4.3       Local Key Lifetimes .............................   32
      4.4       Exported and Calculated Key Lifetimes ...........   33
      4.5       Key Cache Synchronization .......................   34
      4.6       Key Scope .......................................   35
      4.7       Key Strength ....................................   36
      4.8       Key Wrap ........................................   37
   5.     Handoff Support .......................................   39
      4.1   38
      5.1       Authorization Issues ............................   39
      4.2 ...................................   38
      5.2       Correctness Issues ..............................   41
   5. .....................................   39
   6.     Security Considerations  ..............................   44
      5.1   42
      6.1       Security Terminology ............................   44
      5.2   42
      6.2       Threat Model ....................................   44
      5.3   42
      6.3       Security Analysis ...............................   45
      5.4   44
      6.4       Man-in-the-middle Attacks .......................   49
      5.5   48
      6.5       Denial of Service Attacks .......................   49
      5.6   48
      6.6       Impersonation ...................................   50
      5.7   49
      6.7       Channel Binding .................................   51
      5.8       Key Strength ....................................   52
      5.9       Key Wrap ........................................   53
   6.   50
   7.     Security Requirements .................................   53
      6.1   51
      7.1       EAP Method Requirements .........................   53
      6.2   51
      7.2       AAA Protocol Requirements .......................   56
      6.3   54
      7.3       Secure Association Protocol Requirements ........   58
      6.4   55
      7.4       Ciphersuite Requirements ........................   60
   7.   57
   8.     IANA Considerations ...................................   60
   8.   57
   9.     References ............................................   61
      8.1   58
      9.1       Normative References ............................   61
      8.2   58
      9.2       Informative References ..........................   61   59
   Acknowledgments ..............................................   65   62
   Author's Addresses ...........................................   65   63
   Appendix A - Ciphersuite Keying Requirements .................   67   64
   Appendix B - Example Transient EAP Key (TEK) Hierarchy .......   68   65
   Appendix C - EAP-TLS Key Hierarchy ...........................   69   66
   Appendix D - Example Transient Session Key (TSK) Derivation ..   71   68
   Appendix E - Key Names and Scope in Existing Methods .........   72   69
   Appendix F - Security Association Examples ...................   70
   Intellectual Property Statement ..............................   73
   Disclaimer of Validity .......................................   73   74
   Copyright Statement ..........................................   73   74

1.  Introduction

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   was designed to enable extensible authentication for network access
   in situations in which the IP protocol is not available.  Originally
   developed for use with PPP [RFC1661], it has subsequently also been
   applied to IEEE 802 wired networks [IEEE8021X].

   This document provides a framework for the generation, transport and
   usage of keying material generated by EAP authentication algorithms,
   known as "methods".  In EAP keying material is generated by EAP
   methods.  Part of this keying material may be used by EAP methods
   themselves and part of this material may be exported.  The exported
   keying material may be transported by AAA protocols or transformed by
   Secure Association Protocols into session keys which are used by
   lower layer ciphersuites.  This document describes each of these
   elements and provides a system-level security analysis.  It also
   specifies the EAP key hierarchy.

1.1.  Requirements Language

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

1.2.  Terminology

   This document frequently uses the following terms:

auth
enticator

authenticator
     The end of the link initiating EAP authentication.  The term
     Authenticator is used in [IEEE-802.1X], and authenticator has the
     same meaning in this document.

peer The end of the link that responds to the authenticator.  In
     [IEEE-802.1X], this end is known as the Supplicant.

Supplicant
     The end of the link that responds to the authenticator in
     [IEEE-802.1X].  In this document, this end of the link is called
     the peer.

backend authentication server
     A backend authentication server is an entity that provides an
     authentication service to an authenticator.  When used, this server
     typically executes EAP methods for the authenticator.  This
     terminology is also used in [IEEE-802.1X].

AAA  Authentication, Authorization and Accounting.  AAA protocols with
     EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-
     eap].  In this document, the terms "AAA server" and "backend
     authentication server" are used interchangeably.

EAP server
     The entity that terminates the EAP authentication method with the
     peer.  In the case where no backend authentication server is used,
     the EAP server is part of the authenticator.  In the case where the
     authenticator operates in pass-through mode, the EAP server is
     located on the backend authentication server.

security association
     A set of policies and cryptographic state used to protect
     information.  Elements of a security association may include
     cryptographic keys, negotiated ciphersuites and other parameters,
     counters, sequence spaces, authorization attributes, etc.

1.3.  Overview

   EAP is typically deployed in order to support extensible network
   access authentication in situations where a peer desires network
   access via one or more authenticators.  Since both the peer and
   authenticator may have more than one physical or logical port, a
   given peer may simultaneously access the network via multiple
   authenticators, or via multiple physical or logical ports on a given
   authenticator.  Similarly, an authenticator may offer network access
   to multiple peers, each via a separate physical or logical port.  The
   situation is illustrated in Figure 1.

   Where authenticators are deployed standalone, the EAP conversation
   occurs between the peer and authenticator, and the authenticator must
   locally implement an EAP method acceptable to the peer.  However, one
   of the advantages of EAP is that it enables deployment of new
   authentication methods without requiring development of new code on
   the authenticator.  While the authenticator may implement some EAP
   methods locally and use those methods to authenticate local users, it
   may at the same time act as a pass-through for other users and
   methods, forwarding EAP packets back and forth between the backend
   authentication server and the peer.

   This is accomplished by encapsulating EAP packets within the
   Authentication, Authorization and Accounting (AAA) protocol, spoken
   between the authenticator and backend authentication server.  AAA
   protocols supporting EAP include RADIUS [RFC3579] and Diameter [I-
   D.ietf-aaa-eap].

                            +-+-+-+-+
                            |       |
                            | EAP   |
                            | Peer  |
                            |       |
                            +-+-+-+-+
                              | | |  Peer Ports
                             /  |  \
                            /   |   \
                           /    |    \
                          /     |     \
                         /      |      \
                        /       |       \
                       /        |        \
                      /         |         \
                   | | |      | | |      | | |  Authenticator Ports
                 +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                 |       |  |       |  |       |
                 | Auth. |  | Auth. |  | Auth. |
                 |       |  |       |  |       |
                 +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                      \         |         /
                       \        |        /
                        \       |       /
          EAP over AAA   \      |      /
            (optional)    \     |     /
                           \    |    /
                            \   |   /
                             \  |  /
                            +-+-+-+-+
                            |       |
                            | AAA   |
                            |Server |
                            |       |
                            +-+-+-+-+

Figure 1:  Relationship between peer, authenticator and backend server

   Where EAP key derivation is supported, the conversation between the
   peer and the authenticator typically takes place in three phases:

      Phase 0: Discovery
      Phase 1: Authentication
               1a: EAP authentication
               1b: AAA-Key Transport (optional)
      Phase 2: Secure Association Establishment
               2a: Unicast Secure Association
               2b: Multicast Secure Association (optional)
   In the discovery phase (phase 0),  peers locate authenticators and
   discover their capabilities.  For example, a peer may locate an
   authenticator providing access to a particular network, or a peer may
   locate an authenticator behind a bridge with which it desires to
   establish a Secure Association.

   The authentication phase (phase 1) may begin once the peer and
   authenticator discover each other.  This phase always includes EAP
   authentication (phase 1a).  Where the chosen EAP method supports key
   derivation, in phase 1a keying material is derived on both the peer
   and the EAP server.  This keying material may be used for multiple
   purposes, including protection of the EAP conversation and subsequent
   data exchanges.

   An additional step (phase 1b) is required in deployments which
   include a backend authentication server, in order to transport keying
   material (known as the AAA-Key) from the backend authentication
   server to the authenticator.

   A Secure Association exchange (phase 2) then occurs between the peer
   and authenticator in order to manage the creation and deletion of
   unicast (phase 2a) and multicast (phase 2b) security associations
   between the peer and authenticator.

   EAP may be used in the following scenarios:

[a]  Stationary peer.  Where

   The conversation phases and relationship between the peer parties is stationary it will establish
     communications with one or more authenticators while remaining shown
   in
     one location.  In this scenario, EAP authentication typically
     represents only a small fraction of the total session time, so that
     it is acceptable for EAP authentication to occur each time the peer
     wishes to access the network.  In this scenario, the Secure
     Association Protocol (Phase 2) MAY be ommitted.

[b]  Mobile peer. Where the peer is mobile, it may move its point of
     attachment from one authenticator to another, or between points of
     attachment on a single authenticator.  In this scenario, it is
     often desirable to minimize the handoff latency, so that it is
     desirable to avoid EAP authentication each time the peer changes
     its point of attachment.  In this scenario, the Secure Association
     Protocol (Phase 2) is REQUIRED.

     The conversation phases and relationship between the parties is
     shown in Figure 2.

Abo Figure 2.

   EAP peer                   Authenticator               Auth. Server
   --------                   -------------               ------------
    |<----------------------------->|                               |
    |     Discovery (phase 0)       |                               |
    |<----------------------------->|<----------------------------->|
    |   EAP auth (phase 1a)         |  AAA pass-through (optional)  |
    |                               |                               |
    |                               |<----------------------------->|
    |                               |       AAA-Key transport       |
    |                               |      (optional; phase 1b)     |
    |<----------------------------->|                               |
    |  Unicast Secure association   |                               |
    |          (phase 2a)           |                               |
    |                               |                               |
    |<----------------------------->|                               |
    | Multicast Secure association  |                               |
    |     (optional; phase 2b)      |                               |
    |                               |                               |

                  Figure 2: Conversation Overview

1.3.1.  Discovery Phase

   In the discovery phase (phase 0), the EAP peer and authenticator
   locate each other and discover each other's capabilities. Discovery
   can occur manually or automatically, depending on the lower layer
   over which EAP runs.  Since authenticator discovery is handled
   outside of EAP, there is no need to provide this functionality within
   EAP.

   For example, where EAP runs over PPP, the EAP peer might be
   configured with a phone book providing phone numbers of
   authenticators and associated capabilities such as supported rates,
   authentication protocols or ciphersuites.

   In contrast, PPPoE [RFC2516] provides support for a Discovery Stage
   to allow a peer to identify the Ethernet MAC address of one or more
   authenticators and establish a PPPoE SESSION_ID.

   IEEE 802.11 [IEEE80211] also provides integrated discovery support
   utilizing Beacon and/or Probe Request/Response frames, allowing the
   peer (known as the station or STA) to determine the MAC address and
   capabilities of one or more authenticators (known as Access Point or
   APs).

1.3.2.  Authentication Phase

   Once the peer and authenticator discover each other, they exchange
   EAP packets.  Typically, the peer desires access to the network, and
   the authenticators provide that access.  In such a situation, access
   to the network can be provided by any authenticator attaching to the
   desired network, and the EAP peer is typically willing to send data
   traffic through any authenticator that can demonstrate that it is
   authorized to provide access to the desired network.

   An EAP authenticator may handle the authentication locally, or it may
   act as a pass-through to a backend authentication server.  In the
   latter case the EAP exchange occurs between the EAP peer and a
   backend authenticator server, with the authenticator forwarding EAP
   packets between the two. The entity which terminates EAP
   authentication with the peer is known as the EAP server.  Where pass-
   through is supported, the backend authentication server functions as
   the EAP server; where authentication occurs locally, the EAP server
   is the authenticator.  Where a backend authentication server is
   present, at the successful completion of an authentication exchange,
   the AAA-Key is transported to the authenticator (phase 1b).

   EAP may also be used when it is desired for two network devices (e.g.
   two switches or routers) to authenticate each other, or where two
   peers desire to authenticate each other and set up a secure
   association suitable for protecting data traffic.

   Some EAP methods exist which only support one-way authentication;
   however, EAP methods deriving keys are required to support mutual
   authentication.  In either case, it can be assumed that the parties
   do not utilize the link to exchange data traffic unless their
   authentication requirements have been met.  For example, a peer
   completing mutual authentication with an EAP server will not send
   data traffic over the link until the EAP server has authenticated
   successfully to the peer, and a Secure Association has been
   negotiated.

   Since EAP is a peer-to-peer protocol, an independent and simultaneous
   authentication may take place in the reverse direction.  Both peers
   may act as authenticators and authenticatees at the same time.

   Successful completion of EAP authentication and key derivation by a
   peer and EAP server does not necessarily imply that the peer is
   committed to joining the network associated with an EAP server.
   Rather, this commitment is implied by the creation of a security
   association between the EAP peer and authenticator, as part of the
   Secure Association Protocol (phase 2).  As a result, EAP may be used
   for "pre-authentication" in situations where it is necessary to pre-
   establish EAP security associations in order to decrease handoff or
   roaming latency.

1.3.3.  Secure Association Phase

   The Secure Association phase (phase 2), if it occurs, begins after
   the completion of EAP authentication (phase 1a) and key transport
   (phase 1b), 1b).  EAP may be used in the following scenarios:

[a]  Stationary peer.  Where the peer is stationary it will establish
     communications with one or more authenticators while remaining in
     one location.  In this scenario, EAP authentication typically
     represents only a small fraction of the total session time, so that
     it is acceptable for EAP authentication to occur each time the peer
     wishes to access the network.  In this scenario, the Secure
     Association Protocol phase may be omitted.

[b]  Mobile peer. Where the peer is mobile, it may move its point of
     attachment from one authenticator to another, or between points of
     attachment on a single authenticator.  In this scenario, it is
     often desirable to minimize the handoff latency, so that it is
     desirable to avoid EAP authentication each time the peer changes
     its point of attachment.  In this scenario, caching of the AAA-Key
     be supported on the EAP peer and authenticator.  In this, a Secure
     Assocation Protocol phase is required to allow EAP to be used
     securely.

     A Secure Association Protocol used with EAP typically supports the
     following features:

[1]  Generation of fresh transient session keys (TSKs).  Where AAA-Key
     caching is supported, the EAP peer may initiate a new session using
     a AAA-Key that was used in a previous session.  Were the TSKs to be
     derived from a portion of the AAA-Key,  this would result in reuse
     of the session keys which could expose the underlying ciphersuite
     to attack.

     As a result, where AAA-Key caching is supported, freshness of TSKs the Secure
     Association Protocol phase is REQUIRED, and MUST be provided by mechanisms outside provide for
     freshness of EAP. the TSKs.  This is typically handled within the Secure Association protocol via the exchange
     of nonces or counters, which are then mixed with the AAA-Key in
     order to generate  fresh unicast (phase 2a) and possibly multicast
     (phase 2b) session keys.  By not using the AAA-Key directly to
     protect data, the secure Secure Association Protocol protects against
     compromise of the AAA-Key.

[2]  Entity Naming.  A basic feature of a Secure Association Protocol is
     the explicit naming of the parties engaged in the exchange.
     Explicit identification of the parties is critical, since without
     this the parties engaged in the exchange are not identified and the
     scope of the transient session keys (TSKs) generated during the
     exchange is undefined.  As illustrated in Figure 1, both the peer
     and NAS may have more than one physical or virtual port, so that
     port identifiers are typically inappropriate as not recommended a naming mechanism.

[3]  Secure capabilities negotiation.  This provides for includes the secure
     negotiation of usage modes, session parameters (such as key
     lifetimes), ciphersuites, ciphersuites and required filters, including
     confirmation of the capabilities discovered during phase 0.  By
     securely negotiating session parameters,  It is
     RECOMMENDED that the secure Secure Association Protocol protects support secure
     capabilities negotiation, in order to protect against spoofing
     during the discovery phase phase, and
     ensures that to ensure agreement between the
     peer and authenticator are in agreement about how data is to be secured.

[4]  Key
activation and deletion. In order management. EAP as defined in [RFC3748] supports key
     derivation, but not key management.  While EAP methods may derive
     keying material, EAP does provide for the peer and
     authenticator to communicate securely, it is necessary for both
     sides to derive management of exported or
     derived keys.  For example, EAP does not support negotiation of the same session
     key lifetime of exported or derived keys, and remain nor does it support
     rekey.  Although EAP methods may support "fast reconnect" as
     defined in sync with
     respect [RFC3748] Section 7.2.1, rekey of exported keys cannot
     occur without reauthentication.  In order to provide method
     independence, key state going forward.  One of the functions management of exported or derived keys SHOULD NOT
     be provided within EAP methods.

     Since neither EAP nor EAP methods provide key management support,
     it is RECOMMENDED that key management facilities be provided within
     the Secure Association Protocol is to synchronize Protocol.  This includes key lifetime
     management (such as via explicit key lifetime negotiation, or
     seamless rekey), as well synchronization of the activation installation and
     deletion of keys so as to enable seamless rekey, or recovery from partial or complete
     loss of key state by the peer or authenticator.  Since key
     management requires a key naming scheme, Secure Association
     Protocols supporting key management support MUST also support key
     naming.

[5]  Mutual proof of possession of the AAA-Key.  This demonstrates  The Secure Association
     Protocol MUST demonstrate mutual proof of posession of the AAA-Key,
     in order to show that both the peer and authenticator have been
     authenticated and authorized by the backend authentication server.
     Since mutual proof of possession is not the same as mutual
     authentication, the peer cannot verify authenticator assertions
     (including the authenticator identity) as a result of this
     exchange.

1.4.  EAP Invariants

   Certain basic characteristics, known as the "EAP Invariants" hold
   true for EAP implementations on all media:

      Media independence
      Method independence
      Ciphersuite independence

1.4.1.  Media Independence

   One of the goals of EAP is to allow EAP methods to function on any
   lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
   For example, as described in [RFC3748], EAP authentication can be run
   over PPP [RFC1661],  IEEE 802 wired networks [IEEE8021X], and IEEE
   802.11 wireless LANs [IEEE80211i].

   In order to maintain media independence, it is necessary for EAP to
   avoid inclusion of media-specific elements.  For example, EAP methods
   cannot be assumed to have knowledge of the lower layer over which
   they are transported, and cannot utilize identifiers associated with
   a particular usage environment (e.g. MAC addresses).

   The need for media independence has also motivated the development of
   the three phase exchange.  Since discovery is typically media-
   specific, this function is handled outside of EAP, rather than being
   incorporated within it.  Similarly, the Secure Association Protocol
   often contains media dependencies such as negotiation of media-
   specific ciphersuites or session parameters, and as a result this
   functionality also cannot be incorporated within EAP.

   Note that media independence may be retained within EAP methods that
   support channel binding or method-specific identification.  An EAP
   method need not be aware of the content of an identifier in order to
   use it.  This enables an EAP method to use media-specific identifiers
   such as MAC addresses without compromising media independence.  To
   support channel binding, an EAP method can pass binding parameters to
   the AAA server in the form of an opaque blob, and receive
   confirmation of whether the parameters match, without requiring
   media-specific knowledge.

1.4.2.  Method Independence

   By enabling pass-through, authenticators can support any method
   implemented on the peer and server, not just locally implemented
   methods.  This allows the authenticator to avoid implementing code
   for each EAP method required by peers.  In fact, since a pass-through
   authenticator is not required to implement any EAP methods at all, it
   cannot be assumed to support any EAP method-specific code.

   As a result, as noted in [RFC3748], authenticators must by default be
   capable of supporting any EAP method.  Since the Discovery and Secure
   Association exchanges are also method independent, an authenticator
   can carry out the three phase exchange without having an EAP method
   in common with the peer.

   This is useful where there is no single EAP method that is both
   mandatory-to-implement and offers acceptable security for the media
   in use.  For example, the [RFC3748] mandatory-to-implement EAP method
   (MD5-Challenge) does not provide dictionary attack resistance, mutual
   authentication or key derivation, and as a result is not appropriate
   for use in wireless LAN authentication [WLANREQ].  However, despite
   this it is possible for the peer and authenticator to interoperate as
   long as a suitable EAP method is supported on the EAP server.

1.4.3.  Ciphersuite Independence

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator out-of-band of EAP.  Since
   ciphersuite negotiation is assumed to occur out-of-band, there is no
   need for ciphersuite negotiation within EAP.  Since ciphersuite
   negotiation occurs outside of EAP, EAP methods generate keying
   material that is ciphersuite-independent.

   For example, within PPP, the ciphersuite is negotiated within the
   Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
   authentication is completed.  Within [IEEE80211i], the AP
   ciphersuites are advertised in the Beacon and Probe Responses prior
   to EAP authentication, and are securely verified during a 4-way
   handshake exchange after EAP authentication has completed.

   Advantages of ciphersuite-independence include:

Reduced update requirements
     If EAP methods were to specify how to derive transient session keys
     for each ciphersuite, they would need to be updated each time a new
     ciphersuite is developed.  In addition, backend authentication
     servers might not be usable with all EAP-capable authenticators,
     since the backend authentication server would also need to be
     updated each time support for a new ciphersuite is added to the
     authenticator.

Reduced EAP method complexity
     Requiring each EAP method to include ciphersuite-specific code for
     transient session key derivation would increase method complexity
     and result in duplicated effort.

Simplified configuration
     The ciphersuite is negotiated between the peer and authenticator
     out-of-band of EAP.  The backend authentication server is neither a
     party to this negotiation, nor is it an intermediary in the data
     flow between the EAP peer and authenticator.  The backend
     authentication server may not have knowledge of the ciphersuites
     and negotiation policies implemented by the peer and authenticator,
     or be aware of the ciphersuite negotiated between them.  This
     simplifies the configuration of the backend authentication server.

     For example, since ECP negotiation occurs after authentication,
     when run over PPP, the EAP peer, authenticator and backend
     authentication server may not anticipate the negotiated ciphersuite
     and therefore this information cannot be provided to the EAP
     method.

2.  EAP  Key Hierarchy Derivation

2.1.  Key Terminology

   The EAP Key Hierarchy makes use of the following types of keys:

Long Term Credential
     EAP methods frequently make use of long term secrets in order to
     enable authentication between the peer and server.  In the case of
     a method based on pre-shared key authentication, the long term
     credential is the pre-shared key.  In the case of a public-key
     based method, the long term credential is the corresponding private
     key.

Master Session Key (MSK)
     Keying material that is derived between the EAP peer and server and
     exported by the EAP method.  The MSK is at least 64 octets in
     length.

INTERNET-DRAFT        EAP
Key Management Framework      14 November 2004

Extended Master Session Key (EMSK)
     Additional keying material derived between the peer and server that
     is exported by the EAP method.  The EMSK is at least 64 octets in
     length, and is never shared with a third party.

AAA-Key
     A key derived by the peer and EAP server, used by the peer and
     authenticator in the derivation of Transient Session Keys (TSKs).
     Where a backend authentication server is present, the AAA-Key is
     transported from the backend authentication server to the
     authenticator, wrapped within the AAA-Token; it is therefore known
     by the peer, authenticator and backend authentication server.
     Despite the name, the AAA-Key is computed regardless of whether a
     backend authentication server is present.  AAA-Key derivation is
     discussed in Section 2.5; 2.3; in existing implementations the MSK is
     used as the AAA-Key.

Application-specific Master Session Keys (AMSKs)
     Keys derived from the EMSK which are cryptographically separate
     from each other and may be subsequently used in the derivation of
     Transient Session Keys (TSKs) for extended uses.  AMSK derivation
     is discussed in Section 2.6. 2.4.

AAA-Token
     Where a backend server is present, the AAA-Key and one or more
     attributes is transported between the backend authentication server
     and the authenticator within a package known as the AAA-Token.  The
     format and wrapping of the AAA-Token, which is intended to be
     accessible only to the backend authentication server and
     authenticator, is defined by the AAA protocol.  Examples include
     RADIUS [RFC2548] and Diameter [I-D.ietf-aaa-eap].

Initialization Vector (IV)
     A quantity of at least 64 octets, suitable for use in an
     initialization vector field, that is derived between the peer and
     EAP server.  Since the IV is a known value in methods such as EAP-
     TLS [RFC2716], it cannot be used by itself for computation of any
     quantity that needs to remain secret.  As a result, its use has
     been deprecated and EAP methods are not required to generate it.
     However, when it is generated it MUST be unpredictable.

Pairwise Master Key (PMK)
     The AAA-Key is divided into two halves, the "Peer to Authenticator
     Encryption Key" (Enc-RECV-Key) and "Authenticator to Peer
     Encryption Key" (Enc-SEND-Key) (reception is defined from the point
     of view of the authenticator).  Within [IEEE80211i] Octets 0-31 of
     the AAA-Key (Enc-RECV-Key) are known as the Pairwise Master Key
     (PMK).  In [IEEE80211i] the TKIP and AES CCMP ciphersuites derive
     their Transient Session Keys (TSKs) solely from the PMK, whereas
     the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
     both halves of the AAA-Key.

Transient EAP Keys (TEKs)
     Session keys which are used to establish a protected channel
     between the EAP peer and server during the EAP authentication
     exchange. The TEKs are appropriate for use with the ciphersuite
     negotiated between EAP peer and server for use in protecting the
     EAP conversation.  Note that the ciphersuite used to set up the
     protected channel between the EAP peer and server during EAP
     authentication is unrelated to the ciphersuite used to subsequently
     protect data sent between the EAP peer and authenticator. An
     example TEK key hierarchy is described in Appendix C.

Transient Session Keys (TSKs)
     Session keys used to protect data exchanged between the peer and
     the authenticator after the EAP authentication has successfully
     completed.  TSKs are appropriate for the lower layer ciphersuite
     negotiated between the EAP peer and authenticator.  Examples of TSK
     derivation are provided in Appendix D.

2.2.  Key Hierarchy

   The EAP Key Hierarchy, illustrated in Figure 3, has at the root the
   long term credential utilized by the selected EAP method.  If
   authentication is based on a pre-shared key, the parties store the
   EAP method to be used and the pre-shared key.  The EAP server also
   stores the peer's identity and/or other information necessary to
   decide whether access to some service should be granted.  The peer
   stores information necessary to choose which secret to use for which
   service.

   If authentication is based on proof of possession of the private key
   corresponding to the public key contained within a certificate, the
   parties store the EAP method to be used and the trust anchors used to
   validate the certificates.  The EAP server also stores the peer's
   identity and/or other information necessary to decide whether access
   to some service should be granted.  The peer stores information
   necessary to choose which certificate to use for which service.

   Based on the long term credential established between the peer and
   the server, EAP derives two types of keys:

    [1] Keys calculated locally by the EAP method but not exported
        by the EAP method, such as the TEKs.
    [2] Keys exported by the EAP method: MSK, EMSK, IV

   From the keys exported by the EAP method, two other types of keys may
   be derived:

    [3] Keys calculated from exported quantities: AAA-Key, AMSKs.
    [4] Keys calculated by the Secure Association Protocol from the
        AAA-Key or AMSKs: TSKs.

   In order to protect the EAP conversation, methods supporting key
   derivation typically negotiate a ciphersuite and derive Transient EAP
   Keys (TEKs) for use with that ciphersuite.  The TEKs are stored
   locally by the EAP method and are not exported.

   As noted in [RFC3748] Section 7.10, EAP methods generating keys are
   required to calculate and export the MSK and EMSK, which must be at
   least 64 octets in length.  EAP methods also may export the IV;
   however, the use of the IV is deprecated.  On both the peer and EAP
   server, the exported MSK and keys derived from the AMSK are utilized
   in order to calculate the AAA-Key, as described in Section 2.5. 2.3.

   Where a backend authentication server is present, the AAA-Key is
   transported from the backend authentication server to the
   authenticator within the AAA-Token, using the AAA protocol.

   Once EAP authentication completes and is successful, the peer and
   authenticator obtain the AAA-Key and the Secure Association Protocol
   is run between the peer and authenticator in order to securely
   negotiate the ciphersuite, derive fresh TSKs used to protect data,
   and provide mutual proof of possession of the AAA-Key.

   When the authenticator acts as an endpoint of the EAP conversation
   rather than a pass-through, EAP methods are implemented on the
   authenticator as well as the peer.  If the EAP method negotiated
   between the EAP peer and authenticator supports mutual authentication
   and key derivation, the EAP Master Session Key (MSK) and Extended
   Master Session Key (EMSK) are derived on the EAP peer and
   authenticator and exported by the EAP method.  In this case, the MSK
   and EMSK are known only to the peer and authenticator and no other
   parties.  The TEKs and TSKs also reside solely on the peer and
   authenticator.  This is illustrated in Figure 4.  As demonstrated in
   [I-D.ietf-roamops-cert], in this case it is still possible to support
   roaming between providers, using certificate-based authentication.

   Where a backend authentication server is utilized, the situation is
   illustrated in Figure 5.   Here the authenticator acts as a pass-
   through between the EAP peer and a backend authentication server. In
   this model, the authenticator delegates the access control decision
   to the backend authentication server, which acts as a Key
   Distribution Center (KDC).  In this case, the authenticator
   encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
   or Diameter [I-D.ietf-aaa-eap], and forwards packets to and from the
   backend authentication server, which acts as the EAP server.  Since
   the authenticator acts as a pass-through, EAP methods reside only on
   the peer and EAP server As a result, the TEKs, MSK and EMSK are
   derived on the peer and EAP server.

   On completion of EAP authentication, EAP methods on the peer and EAP
   server export the Master Session Key (MSK) and Extended Master
   Session Key (EMSK).  The peer and EAP server then calculate the AAA-
   Key from the MSK and EMSK, and the backend authentication server
   sends an Access-Accept to the authenticator, providing the AAA-Key
   within a protected package known as the AAA-Token.

   The AAA-Key is then used by the peer and authenticator within the
   Secure Association Protocol to derive Transient Session Keys (TSKs)
   required for the negotiated ciphersuite.  The TSKs are known only to
   the peer and authenticator.

2.3.  Key Lifetimes

   Key lifetime issues are discussed in the sections that follow.
   Issues include:

[a]  Key lifetime negotiation.  Where key lifetimes cannot be assumed,
     it may be necessary to negotiate them.  Where negotiation is
     supported, it is RECOMMENDED that the negotiation be secured.  Note
     that key lifetime negotiation may not always be required.  A
     difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
     were negotiated. In IKEv2, each end of the SA is responsible for
     enforcing its own lifetime policy on the SA and rekeying the SA
     when necessary.

[b]  Key resynchronization.  It is possible for the peer or
     authenticator to reboot or reclaim resources, clearing portions or
     all of the key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the key cache will remain synchronized, and the peer
     may not be able to determine before attempting to use it whether a
     particular key exists within the authenticator cache.  It is
     therefore RECOMMENDED for the lower layer to provide a mechanism
     for key state resynchronization.  Since in this situation one or
     more of the parties initially do not possess a key with which to
     protect the resynchronization exchange, securing this mechanism may
     be difficult.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP Method                               |            |
|                                                         |            |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+   |            |
| |                                 |   |             |   |            |
| |       EAP Method Key            |<->| Long-Term   |   |            |
| |         Derivation              |   | Credential  |   |            |
| |                                 |   |             |   |            |
| |                                 |   +-+-+-+-+-+-+-+   |  Local to  |
| |                                 |                     |       EAP  |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |     Method |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   V             |               |                       |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
| |  TEK      | | MSK       | |EMSK       | |IV         | |            |
| |Derivation | |Derivation | |Derivation | |Derivation | |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|                 |               |                 |     |            |
|                 |               |                 |     |            V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
                  |               |                 |                  ^
                  |               |                 |                  |
                  | MSK (64B)     | EMSK (64B)      | IV (64B)         |
                  |               |                 |          Exported|
                  |               |                 |              by  |
                  V               V                 V              EAP |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+  Method|
          |          AAA  Key Derivation,     | | Known       |        |
          |          Naming & Binding         | |(Not Secret) |        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+        V
                  |                                                 ---+
                  | AAA-Key/                               Transported |
                  | Name                                        by AAA |
                  |                                           Protocol |
                  V                                                    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
   |                           |                                       ^
   |     TSK  Derivation       |                           Lower layer |
   |     [AAA-Key Cache]       |                              Specific |
   |                           |                                       V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

                          Figure 3: EAP Key Hierarchy
   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |               |         |
   | Cipher- |               | Cipher- |
   | Suite   |               | Suite   |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       |                         |
       |                         |
       V                         V
   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |===============|         |
   |         |EAP, TEK Deriv.|Authenti-|
   |         |<------------->| cator   |
   |         |               |         |
   |         | Secure Assoc. |         |
   | peer    |<------------->| (EAP    |
   |         |===============| server) |
   |         | Link layer    |         |
   |         | (PPP,IEEE802) |         |
   |         |               |         |
   |MSK,EMSK |               |MSK,EMSK |
   | AAA-Key/|               | AAA-Key/|
   | Name    |               | Name    |
   | (TSKs)  |               | (TSKs)  |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       | MSK, EMSK               | MSK, EMSK
       |                         |
       |                         |
   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |  EAP    |               |  EAP    |
   |  Method |               |  Method |
   |         |               |         |
   | (TEKs)  |               | (TEKs)  |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+

   Figure 4:  Relationship between EAP peer and authenticator (acting as
   an EAP server), where no backend authentication server is present.

   +-+-+-+-+-+               +-+-+-+-+-+
   |         |               |         |
   |         |               |         |
   | Cipher- |               | Cipher- |
   | Suite   |               | Suite   |
   |         |               |         |
   +-+-+-+-+-+               +-+-+-+-+-+
       ^                         ^
       |                         |
       |                         |
       |                         |
       V                         V
   +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
   |         |===============|         |========|         |
   |         |EAP, TEK Deriv.|         |        |         |
   |         |<-------------------------------->| backend |
   |         |               |         |AAA-Key/|         |
   |         | Secure Assoc. |         | Name   |         |
   | peer    |<------------->|Authenti-|<-------|  auth   |
   |         |===============| cator   |========| server  |
   |         |  Link Layer   |         |  AAA   | (EAP    |
   |         | (PPP,IEEE 802)|         |Protocol| server) |
   |MSK,EMSK |               |         |        |         |
   | AAA-Key/|               | AAA-Key/|        |MSK,EMSK,|
   | Name    |               |  Name   |        | AAA-Key/|
   | (TSKs)  |               |  (TSKs) |        | Name    |
   +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
       ^                                            ^
       |                                            |
       | MSK, EMSK                                  | MSK, EMSK
       |                                            |
       |                                            |
   +-+-+-+-+-+                                  +-+-+-+-+-+
   |         |                                  |         |
   |  EAP    |                                  |  EAP    |
   |  Method |                                  |  Method |
   |         |                                  |         |
   |  (TEKs) |                                  |  (TEKs) |
   |         |                                  |         |
   +-+-+-+-+-+                                  +-+-+-+-+-+

   Figure 5: Pass-through relationship between EAP peer, authenticator
   and backend authentication server.

2.3.1.  Parent-child relationships

   When keying material exported by EAP methods expires,  all keying
   material derived from the exported keying material, (including the
   AAA-Key, AMSKs and TSKs) also expires.

   Similarly, when an EAP reauthentication takes place, new keying
   material

2.3.  AAA-Key Derivation

   Where a AAA-Key is derived and exported by generated as the EAP method, which eventually
   results in replacement result of calculated keys, including the AAA-Key,
   AMSKs, and TSKs.

   As a result, successful EAP
   authentication with the lifetime of keys calculated from authenticator A, the exported keying
   material can be no longer than AAA-Key is based on the lifetime of the exported
   MSK:  AAA-Key = MSK(0,63).

   As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
   [IEEE-03-084], and [8021XHandoff], keying material itself.  However, the lifetime of calculated keys can may be
   less than that of required
   for use in fast handoff between authenticators.  Where the exported keys.  For example, TSK rekey may
   occur prior backend
   authentication server provides keying material to EAP reauthentication.

   Note that deletion of additional
   authenticators in order to facilitate fast handoff, it is highly
   desirable for the AAA-Key keying material used on different authenticators B,
   C to be cryptographically separate, so that if one authenticator is
   compromised, it does not necessarily imply deletion
   of lead to the corresponding TSKs.  Replacement or deletion of TSKs only
   implies replacement compromise of other
   authenticators.  Where keying material is provided by the AAA-Key when the TSKs are taken from backend
   authentication server, a
   portion of the AAA-Key.

   Failure to mutually prove possession of the AAA-Key during the Secure
   Association Protocol exchange need not be grounds for deletion of key hierarchy derived from the
   AAA-Key by both parties; rate-limiting Secure Association Protocol
   exchanges could AMSK can be
   used to prevent a brute force attack.

2.3.2.  Local Key Lifetimes

   The Transient EAP Keys (TEKs) are session keys used to protect the
   EAP conversation.  The TEKs are internal to the EAP method and are
   not exported.  TEKs are typically created during an EAP conversation,
   used until the end provide cryptographically separate keying material for use in
   fast handoff.  Instead of the conversation and then discarded.  However,
   methods may rekey TEKs during a conversation.

   When using TEKs within the EMSK directly an EAP conversation or across conversations,
   it application
   specific key (AMSK) is necessary to ensure that replay protection and derived as described in Section 2.4:

      AAA-Key = MSK(0,63)

      AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
                  length)

      AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments", AAA-Key, B-Called-Station-Id,
                  Calling-Station-Id,length)

      AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments",AAA-Key, C-Called-Station-Id,
                  Calling-Station-Id, length)

      Where:
      Calling-Station-Id  = STA MAC address
      B-Called-Station-Id = AP B MAC address
      C-Called-Station-Id = AP C MAC address
      prf = HMAC-SHA1
      KDF = defined in Section 2.4
      length = length of derived key separation
   requirements are fulfilled.  For instance, if a replay counter material

   Here AAA-Key is
   used, TEK rekey MUST occur prior to wrapping of derived during the counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK rekeying or caching. This prevents TEK compromise from
   leading directly to compromise of initial EAP authentication between
   the TSKs peer and vice versa.

   EAP methods may cache local keying material which may persist for
   multiple authenticator A. Based on this initial EAP conversations when fast reconnect
   authentication, an AMSK is also derived, which can be used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) to derive and cache the TLS Master Secret, typically
   AAA-Keys for substantial
   time periods.  The lifetime of other local keying material calculated
   within fast authentication between the EAP method peer and
   authenticators B and C.  Since the AMSK is defined by cryptographically separate
   from the method.  Note that in
   general, when using fast reconnect, there MSK, each of these AAA-Keys is no guarantee cryptographically separate
   from each other, and are guaranteed to that be unique between the
   original long-term credentials are still in EAP peer
   (also known as the possession of the
   peer.  For instance, a card hold holding the private key for EAP-TLS
   may have been removed. EAP servers should verify that STA) and the long-term
   credentials are still valid, such authenticator (also known as by checking that certificate
   used in the original authentication has not yet expired.

2.3.3.  Exported and Calculated AP).

2.4.  AMSK Key Lifetimes

   All Derivation

   The EAP methods generating keys are required to generate AMSK key derivation function (KDF) derives an AMSK from the MSK and
   EMSK,
   Extended Master Session Key (EMSK), an application key label,
   optional application data, and may optionally generate the IV.  Existing EAP methods do
   not negotiate the lifetime of the exported keys.  EAP, defined in
   [RFC3748], also does not support the negotiation of lifetimes output length.

   AMSK = KDF(EMSK, key label, optional application data, length)

   The key labels are printable ASCII strings unique for
   exported keying material such as the MSK, EMSK and IV.

   Several mechanisms exist each
   application (see Section 8 for managing IANA Considerations).

   Additional ciphering keys (TSKs) can be derived from the AMSK using
   an application specific key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and
     Diameter [DiamEAP] support derivation mechanism.  In many cases,
   this AMSK->TSK derivation can simply split the Session-Timeout attribute. AMSK to pieces of
   correct length.  In particular, it is not necessary to use a
   cryptographic one-way function.  The
     Session-Timeout value represents the maximum lifetime length of the
     exported keys, and all keys calculated from it, in all
     circumstances.  The AAA server AMSK MUST expire be
   specified by the exported keys, and
     all keys calculated application.

   The AMSK key derivation function is taken from them, prior to the future time indicated
     by Session-Timeout.  On the authenticator,  where EAP is used for
     authentication, the Session-Timeout value represents the maximum
     session time prior to re-authentication, PRF+ key expansion
   PRF from [IKEv2].  This KDF takes 4 parameters as described in [RFC3580].
     Where EAP input: secret,
   label, application data, and output length.  It is used only defined for pre-authentication, the session may not start
     until some future time, or may never occur.  Nevertheless, the
     Session-Timeout value represents the time after which the AAA-Key,
     and all keys calculated from it, will have expired on the
     authenticator.  If the session subsequently starts, re-
     authentication will be initiated once the Session-Time has expired.
     If the session never started, or started and ended, the AAA-Key and
     all keys calculated from
   255 iterations so it will be expired by
 the authenticator
     prior may produce up to the future time indicated by Session-Timeout.

     Since the TSK lifetime is often determined by authenticator
     resources, the AAA server has no insight into the TSK derivation
     process, and by the principle 5100 bytes of ciphersuite independence, it is
     not appropriate for key material.

   For the AAA server to manage any aspect purposes of this specification the TSK
     derivation process, including secret is taken as the TSK lifetime.

[b]  Lower layer mechanisms.  While AAA attributes can communicate
   EMSK, the
     maximum exported key lifetime, this only serves to synchronize label is the key lifetime between label described above concatenated with a
   NUL byte, the backend authentication server application data is also described above and the
     authenticator.  Lower layer mechanisms can then output
   length is two bytes.  Application data MAY be used to enable
     the lifetime of exported and calculated keys to be negotiated
     between the peer and authenticator.

     Where TSKs are established as the result of a Secure Association
     Protocol exchange, it an empty string.  The
   KDF is RECOMMENDED that the Secure Association
     Protocol include secure negotiation based on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we
   have:

      KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...

      where:
      T1 = prf (K, S | 0x01)
      T2 = prf (K, T1 | S | 0x02)
      T3 = prf (K, T2 | S | 0x03)
      T4 = prf (K, T3 | S | 0x04)

      prf = HMAC-SHA1
      K = EMSK
      L = key label
      D = application data
      O = OutputLength (2 bytes)
      S = L | " " | D | O

   The prf+ construction was chosen because of the TSK lifetime between the
     peer its simplicity and authenticator.  Where
   efficiency over other PRFs such as those used in [TLS].  The
   motivation for the TSK design of this PRF is taken from described in [SIGMA].

   The NUL byte after the AAA-Key,
     there key label is no need used to manage the TSK lifetime as avoid collisions if one
   key label is a separate
     parameter, since the TSK lifetime prefix of another label (e.g. "foobar" and AAA-Key lifetime are
     identical.

[c]  System defaults.
   "foobarExtendedV2"). This is considered a simpler solution than
   requiring a key label assignment policy that prevents prefixes from
   occurring.

   Where another prf needs to be negotiated, this can be handled within
   the EAP method does not support the
     negotiation of method.

2.5.  Key Naming

   Each key created within the exported EAP key lifetime, and management framework has a negotiation
     mechanism is not provided name
   (the identifier by which the lower lower, there may key can be no way
     for the peer identified), as well as a
   scope (the parties to learn knowledge of whom the exported key liftime.  In
     this case it is RECOMMENDED that the peer assume a default value of available).  This section
   describes how keys are named, and the exported scope within which that name
   applies.

Session-Id

   EAP methods supporting key lifetime; 8 hours is suggested.  Similarly, the
     lifetime of calculated keys can also be managed as naming MUST specify a system
     parameter on the authenticator.

2.3.4.  Key cache synchronization

   Issues arise when attempting to synchronize temporally unique
   method identifier known as the key cache on EAP Method-Id, which is typically
   constructed from nonces or counters used within the exchange.  Since
   multiple EAP sessions may exist between an EAP peer and authenticator.  Lifetime negotiation alone cannot guarantee key
   cache synchronization.

   One problem is that EAP server,
   the AAA protocol cannot guarantee synchronization Method-Id allows MSKs to be differentiated.

   The concatenation of key lifetimes between the peer EAP Type (expressed in ASCII text), ":" and authenticator.  Where
   the
   Secure Association Protocol Method-Id (also expressed in ASCII text) is not run immediately after known as the EAP
   authentication,
   Session-Id.  The inclusion of the exported and calculated key lifetimes will not be
   known by Type in the peer during EAP Session-Id ensures
   that each EAP method has a distinct name space.

   The EAP Session-Id uniquely identifies the hiatus.  Where EAP pre-authentication
   occurs, this can leave session to the EAP
   peer uncertain whether a subsequent
   attempt to use and server terminating the exported keys will prove successful.

   However, even where the Secure Association Protocol is run
   immediately after EAP, it is still possible for the authenticator to
   reclaim resources if the created key state is not immediately
   utilized.

   The lower layer may utilize Discovery mechanisms to assist in this.
   For example, the authenticator manages the AAA-Key cache by deleting
   the oldest AAA-Key first (LIFO), the relative creation time of the
   last AAA-Key to be deleted could be advertised with the Discovery
   phase, enabling the peer to determine whether a given AAA-Key had
   been expired from the authenticator key cache prematurely.

2.4.  Key Names and Scopes

   Each key created within the EAP key management framework has a name
   (the identifier by which the key can be identified), as well as a
   scope (the parties to whom the key is available).  This section
   describes how keys are named, and the scope within which that name
   applies.

Session-Id

   EAP methods supporting key naming MUST specify a temporally unique
   method identifier known as the EAP Method-Id, which is typically
   constructed from nonces or counters used within the exchange.  Since
   multiple EAP sessions may exist between an EAP peer and EAP server,
   the Method-Id allows MSKs to be differentiated.

   The combination of the EAP Type and the Method-Id is known as the EAP
   Session-Id.  The inclusion of the Type in the EAP Session-Id ensures
   that each EAP method has a distinct name space.

   The EAP Session-Id uniquely identifies the EAP session to the EAP
   peer and server terminating the EAP conversation. EAP conversation.  However, suitable
   EAP peer and server names may not always be available.  As described
   in [RFC3748] Section 7.3, the identity provided in the EAP-
   Response/Identity, may be different from the identity authenticated
   by the EAP method, and as a result the EAP-Response/Identity is
   unsuitable for determination of the peer identity.  As a result, the
   Session-Id scope is defined by the EAP peer name (if securely
   exchanged within the method) concatenated with the EAP server name
   (also only if securely exchanged).  Where a peer or server name is
   missing the null string is used.  Since an EAP session is not bound
   to a particular authentication or specific ports on the peer and
   authenticator, the authenticator port or identity are not included in
   the Session-Id scope.

   The EAP Session-Id is exported by the EAP method along with the
   Session-Id scope, if available, and is used to construct names for
   other EAP keys.  Note that the EAP Session-Id and scope are only
   known by the EAP method.  As a result, the format of the EAP Session-
   Id and the definition of the Session-Id scope needs to be specified
   within the method.  Appendix E defines the EAP Session-Id and scope
   provided by existing methods.

MSK Name

   This key is created between the EAP peer and EAP server, and can be
   referred to using the string "MSK" and "MSK:", concatenated with the EAP
   Session-Id.  As with the EAP Session-Id, the MSK scope is defined by
   the EAP peer name (if securely exchanged within the method) and the
   EAP server name (also only if securely exchanged).  Where a peer or
   server name is missing the null string is used.

EMSK Name

   The EMSK can be referred to using the string "EMSK" and "EMSK:", concatenated
   with the EAP Session-Id.

   As with the EAP Session-Id, the EMSK scope is defined by the EAP peer
   name (if securely exchanged within the method) and the EAP server
   name (also only if securely exchanged).  Where a peer or server name
   is missing the null string is used.

AMSK Name

   AMSKs, if any, can be referred to using the string "AMSK", "AMSK:", the key
   label, ":", application data (see Section 2.6) 2.4), ":", and the EAP
   Session-Id.

   As with the EAP Session-Id, the AMSK scope is defined by the EAP peer
   name (if securely exchanged within the method) method), ":" and the EAP
   server name (also only if securely exchanged).  Where a peer or
   server name is missing the null string is used.

AAA-Key Name

   The AAA-Key is derived from either the MSK or AMSK and so can be
   referred to using the MSK or AMSK names.

   The AAA-Key scope is provided by the concatenation of the EAP peer
   name (if securely provided to the authenticator), and the
   authenticator name (if securely provided to the peer).

   For the purpose of identifying the authenticator to the peer, the
   value of the NAS-Identifier attribute is recommended.  The
   authenticator may include the NAS-Identifier attribute to the AAA
   server in an Access-Request, and the authenticator may provide the
   NAS-Identifier (unsecured) to the EAP peer in the EAP-
   Request/Identity or via a lower layer mechanism (such as the 802.11
   Beacon/Probe Response).  Where the NAS-Identifier is provided by the
   authenticator to the peer a secure mechanism is RECOMMENDED.

   For the purpose of identifying the peer to the authenticator, the EAP
   peer identifier provided within the EAP method is recommended.  It
   cannot be assumed that the authenticator is aware of the EAP peer
   name used within the method.  Therefore alternatives mechanisms need
   to be used to provide the EAP peer name to the authenticator.  For
   example, the AAA server may include the EAP peer name in the User-
   Name attribute of the Access-Accept or the peer may provide the
   authenticator with its name via a lower layer mechanism.

   Absent an explicit binding step within the Secure Association
   Protocol, the AAA-Key is not bound to a specific peer or
   authenticator port.  As a result, the peer or authenticator port over
   which the EAP conversation takes place is not included in the AAA-Key
   scope.

PMK Name

   This document does not specify a naming scheme for the PMK.  The PMK
   is only identified by the AAA-Key from which it is derived.
   Similarly, the PMK scope is the same as the AAA-Key scope.

   Note: IEEE 802.11i names the PMKID for the purposes of being able to
   refer to it in the Secure Association protocol; this naming is based
   on a hash of the PMK itself as well as some other parameters (see
   Section 8.5.1.2 [IEEE80211i]).

TEKs

   The TEKs may or may not be named. Their naming is specified in the
   EAP method.  Since the TEKs are only known by the EAP peer and
   server, the TEK scope is the same as the Session-Id scope.

TSKs

   The TSKs are typically named. Their naming is specified in the Secure
   Association (phase 2) protocol, so that the correct set of transient
   session keys can be identified for processing a given packet.  The
   scope of the TSKs is negotiated within the Secure Association
   Protocol.

   TSK creation and deletion operations are typically supported so that
   establishment and re-establishment of TSKs can be synchronized
   between the parties.

   In order to avoid confusion in the case where an EAP peer has more
   than one AAA-Key (phase 1b) applicable to establishment of a phase 2
   security association, the secure Association protocol needs to
   utilize the AAA-Key name so that the appropriate phase 1b keying
   material can be identified for use in the Secure Association Protocol
   exchange.

2.5.  AAA-Key Derivation

   Where a AAA-Key is generated as the result of a successful

3.  Security Associations

   During EAP authentication with the authenticator A, the AAA-Key and subsequent exchanges, four types of
   security associations (SAs) are created:

[1]  EAP method SA.  This SA is based on between the
   MSK:  AAA-Key = MSK(0,63).

   As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
   [IEEE-03-084], peer and [8021XHandoff], keying material may EAP server.  It
     stores state that can be required used for use "fast reconnect" or other
     functionality in fast handoff some EAP methods.  Not all EAP methods create such
     an SA.

[2]  EAP-Key SA.  This is an SA between authenticators. Where the backend
   authentication server provides keying material to additional
   authenticators in order to facilitate fast handoff, it peer and EAP server, which
     is highly
   desirable for the keying material used on different authenticators B,
   C to be cryptographically separate, so that if one authenticator is
   compromised, it does not lead to store the compromise of other
   authenticators.  Where keying material is provided exported by the EAP method.
     Current EAP server implementations do not retain this SA after the
     EAP conversation completes, but proposals such as [IEEE-03-084] and
     [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre-
     emptive key distribution.

[3]  AAA SA(s).  These SAs are between the authenticator and the backend
     authentication server, a key hierarchy derived from server.  They permit the AMSK can be
   used parties to provide cryptographically separate keying material for use in
   fast handoff.  Instead of using mutually
     authenticate each other and protect the EMSK directly an application
   specific key (AMSK) is derived communications between
     them.

[4]  Service SA(s). These SAs are between the peer and authenticator,
     and they are created as described in Section 2.6:

      AAA-Key = MSK(0,63)

      AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
                  length)

      AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments", AAA-Key, B-Called-Station-Id,
                  Calling-Station-Id,length)

      AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments",AAA-Key, C-Called-Station-Id,
                  Calling-Station-Id, length)

      Where:
      Calling-Station-Id  = STA MAC address
      B-Called-Station-Id = AP B MAC address
      C-Called-Station-Id = AP C MAC address
      prf = HMAC-SHA1
      KDF = defined in Section 2.6
      length = length a result of phases 1-2 of derived key material

   Here AAA-Key is derived during the initial conversation
     (see Section 1.3).

   Examples of security associations are provided in Appendix F.

3.1.  EAP authentication between Method SA (peer - EAP server)

   An EAP method may store some state on the peer and authenticator A. Based on this initial EAP
   authentication, an AMSK server even
   after phase 1a has completed.

   Typically, this is also derived, which can be used to derive
   AAA-Keys for fast authentication between "fast reconnect": the EAP peer and
   authenticators B and C.  Since the AMSK is cryptographically separate
   from the MSK, each of these AAA-Keys is cryptographically separate
   from each other, and EAP server
   can confirm that they are guaranteed still talking to be unique between the EAP peer
   (also known as same party, perhaps
   using fewer round-trips or less computational power. In this case,
   the STA) EAP method SA is essentially a cache for performance
   optimization, and either party may remove the authenticator (also known SA from its cache at
   any point.

   An EAP method may also keep state in order to support pseudonym-based
   identity protection. This is typically a cache as well (the
   information can be recreated if the AP).

2.6.  AMSK Key Derivation

   The original EAP AMSK key derivation function (KDF) derives an AMSK from the
   Extended Master Session Key (EMSK), an application key label,
   optional application data, and output length.

   AMSK = KDF(EMSK, key label, optional application data, length)

   The key labels are printable ASCII strings unique for each
   application (see Section 7 for IANA Considerations).

   Additional ciphering keys (TSKs) can method SA is lost),
   but may be derived from the AMSK using
   an application specific key derivation mechanism.  In many cases,
   this AMSK->TSK derivation can simply split the AMSK to pieces stored for longer periods of
   correct length.  In particular, it time.

   The EAP method SA is not necessary restricted to use a
   cryptographic one-way function.  The length of the AMSK MUST be
   specified by the application.

   The AMSK key derivation function particular service or
   authenticator and is taken from most useful when the PRF+ key expansion
   PRF from [IKEv2].  This KDF takes 4 parameters as input: secret,
   label, application data, and output length.  It peer accesses many
   different authenticators.  An EAP method is only defined responsible for
   255 iterations so it may produce up to 5100 bytes of key material.

   For
   specifying how the purposes of this specification parties select if an existing EAP method SA should
   be used, and if so, which one.  Where multiple backend authentication
   servers are used, EAP method SAs are not typically synchronized
   between them.

   EAP method implementations should consider the secret is taken as appropriate lifetime
   for the
   EMSK, EAP method SA. "Fast reconnect" assumes that the label is information
   required (primarily the key label described above concatenated with a
   NUL byte, keys in the application data is also described above and EAP method SA) hasn't been
   compromised. In case the output
   length is two bytes.  Application data MAY original authentication was carried out
   using, for instance, a smart card, it may be an empty string.  The
   KDF is based easier to compromise the
   EAP method SA (stored on HMAC-SHA1 [RFC2104] [SHA1]. For this specification we
   have:

      KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...

      where:
      T1 = prf (K, S | 0x01)
      T2 = prf (K, T1 | S | 0x02)
      T3 = prf (K, T2 | S | 0x03)
      T4 = prf (K, T3 | S | 0x04)

      prf = HMAC-SHA1
      K = EMSK
      L = key label
      D = application data
      O = OutputLength (2 bytes)
      S = L | " " | D | O

   The prf+ construction was chosen because of its simplicity and
   efficiency over other PRFs such as those used in [TLS].  The
   motivation the PC, for instance), so typically the design of this PRF is described in [SIGMA].

   The NUL byte after EAP
   method SAs have a limited lifetime.

   Contents:

      o  Implicitly, the key label is used EAP method this SA refers to avoid collisions if one
   key label
      o  Internal (non-exported) cryptographic state
      o  EAP method SA name
      o  SA lifetime

3.2.  EAP-Key SA

   This is a prefix of another label (e.g. "foobar" an SA between the peer and
   "foobarExtendedV2"). This EAP server, which is considered a simpler solution than
   requiring a key label assignment policy that prevents prefixes from
   occurring.

   Where another prf needs used to be negotiated, this can be handled within store
   the keying material exported by the EAP method.

2.7.  Key Scope Issues

   As described in Section 2.5, the AAA-Key is calculated from the EMSK
   and MSK by  Current EAP server
   implementations do not retain this SA after the EAP peer conversation
   completes, but future implementations could use this SA for pre-
   emptive key distribution.

   Contents:

      o  MSK and server, EMSK names
      o  MSK and is used as the root of the
   ciphersuite-specific key hierarchy.  Where a EMSK
      o  SA lifetime

3.3.  AAA SA(s) (authenticator - backend authentication
   server is present, the AAA-Key is transported from server)

   In order for the EAP authenticator and backend authentication server to
   authenticate each other, they need to store some information.

   In case the authenticator; where it is authenticator and backend authentication server are
   colocated, and they communicate using local procedure calls or shared
   memory, this SA need not present, necessarily contain any information.

3.4.  Service SA(s) (peer - authenticator)

   The service SAs store information about the AAA-Key service being provided.
   These include the Root service SA and derived unicast and multicast
   service SAs.

   The Root service SA is calculated
   on established as the authenticator.

   Regardless result of how many sessions are initiated using it, the AAA-Key
   scope is between the completion of
   EAP peer that calculates it, authentication (phase 1a) and the
   authenticator
that either calculates it (where no backend
   authenticator is present) AAA-Key derivation or receives it transport
   (phase 1b).  It includes:

      o  Service parameters (or at least those parameters
         that are still needed)
      o  On the authenticator, service authorization
         information received from the server (where a backend authenticator authentication
         server is present).

   It should (or necessary parts of it)
      o  On the peer, usually locally configured service
         authorization information.
      o  The AAA-Key, if it can be understood that an authenticator or peer:

   [a] may contain multiple physical ports;
   [b] may advertise itself as multiple "virtual" authenticators needed again (to refresh
         and/or resynchronize other keys or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or failover.

   As illustrated in Figure 1, an EAP peer with multiple ports may be
   attached to one or more authenticators, each with multiple ports.
   Where another reason)
      o  AAA-Key lifetime

   Unicast and (optionally) multicast service SAs are derived from the peer
   Root service SA, via the Secure Association Protocol.  In order for
   unicast and authenticator identify themselves using a port
   identifier such as a link layer address, multicast service SAs and associated TSKs to be
   established, it may is not be obvious necessary for EAP authentication (phase 1a) to
   be rerun each time.  Instead, the
   peer which authenticator ports are associated with which
   authenticators.  Similarly, it may not Secure Association Protocol can be obvious
   used to mutually prove possession of the
   authenticator which peer ports are AAA-Key and create
   associated with which peers.  As a
   result, the peer unicast (phase 2a) and authenticator may not multicast (phase 2b) service SAs
   and TSKs, enabling the EAP exchange to be able bypassed.  Unicast and
   multicast service SAs include:

      o Service parameters negotiated by the Secure Association Protocol.
      o Endpoint identifiers.
      o Transient Session Keys used to determine protect the
   scope communication.
      o Transient Session Key lifetime.

   One function of the AAA-Key.

   When a single physical authenticator advertises itself as multiple
   "virtual authenticators", the EAP peer and authenticator also may not
   be able Secure Association Protocol is to agree on bind the scope of the AAA-Key, creating a security
   vulnerability.
   unicast and multicast service SAs and TSKs to endpoint identifiers.
   For example, within [IEEE802.11i], the peer may assume that 4-way handshake binds the "virtual
   authenticators" TSKs
   to the MAC addresses of the endpoints; in [IKEv2], the TSKs are distinct and do not share a key cache, whereas,
   depending on bound
   to the architecture IP addresses of the physical AP, endpoints and the negotiated SPI.

   It is possible for more than one unicast or multicast service SA to
   be derived from a shared key cache single Root service SA.  However, a unicast or
   multicast service SA is always descended from only one Root service
   SA.  Unicast or multicast service SAs descended from the same Root
   service SA may utilize the same security parameters (e.g. mode,
   ciphersuite, etc.) or they may utilize different parameters.

   An EAP peer may be able to negotiate multiple service SAs with a
   given authenticator, or may be able to maintain one or more service
   SAs with multiple authenticators, depending on the properties of the
   media.

   Except where explicitly specified by the Secure Association Protocol,
   it should not be implemented.

   Where assumed that the AAA-Key installation of new service SAs
   implies deletion of old service SAs.  It is shared possible for multicast
   Root service SAs to between "virtual authenticators" an
   attacker acting as a peer could authenticate with the "Guest"
   "virtual authenticator" same EAP peer and derive authenticator;
   during a AAA-Key.  If the virtual
   authenticators share re-key of a key cache, then the peer can utilize the AAA-
   Key derived unicast or multicast service SA it is possible
   for the "Guest" network to obtain access two service SAs to exist during the
   "Corporate Intranet" virtual authenticator.

   Several measures period between when the new
   service SA and corresponding TSKs are recommended to address these issues:

[a]  Authenticators calculated and when they are REQUIRED to cache associated authorizations
     along with
   installed.

   Similarly, deletion or creation of a unicast or multicast service SA
   does not necessarily imply deletion or creation of related unicast or
   multicast service SAs, unless specified by the AAA-Key Secure Association
   protocol.  For example, a unicast service SA may be rekeyed without
   implying a rekey of the multicast service SA.

   The deletion of the Root service SA does not necessarily imply the
   deletion of the derived unicast and apply authorizations consistently.  This
     ensures that an attacker cannot obtain elevated privileges even
     where multicast service SAs and
   associated TSKs.  Failure to mutually prove possession of the AAA-Key cache is shared between "virtual authenticators".

[b]  It is RECOMMENDED that physical authenticators maintain separate
     AAA-Key caches
   during the Secure Association Protocol exchange need not be grounds
   for each "virtual authenticator".

[c]  It is RECOMMENDED that each "virtual authenticator" identify itself
     distinctly to deletion of the AAA server, such as AAA-Key by utilizing a distinct NAS-
     identifier attribute.  This enables both parties; the AAA server to utilize a
     separate credential action to authenticate each "virtual authenticator".

[d]  It be taken
   is RECOMMENDED that defined by the Secure Association Protocols identify peers
     and authenticators unambiguously, without incorporating implicit
     assumptions about peer and authenticator architectures.  Using
     port-specific MAC addresses as identifiers is NOT RECOMMENDED where
     peers and authenticators Protocol.

3.4.1.  Sharing service SAs

   A single service may support be provided by multiple ports.

[e]  The AAA server and authenticator MAY implement additional
     attributes in order to further restrict the AAA-Key scope.  For
     example, in 802.11, the AAA server may provide the authenticator
     with a list of authorized Called logical or Calling-Station-Ids and/or
     SSIDs for which the  AAA-Key physical
   service elements.  Each service is valid.

[f]  Where the AAA server provides attributes restricting the key scope,
     it responsible for specifying how
   changing service elements is RECOMMENDED that restrictions be securely communicated by handled. Some approaches include:

Transparent sharing
     If the
     authenticator service parameters visible to the peer.  This is typically accomplished using other party (either peer
     or authenticator) do not change, the Secure Association Protocol,  but also service can be accomplished via moved without
     requiring cooperation from the EAP method other party.

     Whether such a move should be supported or the lower layer.

3.  Security Associations

   During EAP authentication used depends on
     implementation and subsequent exchanges, four types administrative considerations. For instance, an
     administrator may decide to configure a group of
   security associations (SAs) are created:

[1]  EAP method SA.  This SA is between IKEv2/IPsec
     gateways in a cluster for high-availability purposes, if the
     implementation used supports this. The peer does not necessarily
     have any way of knowing when the change occurs.

No sharing
     If the service parameters require changing, some changes may
     require terminating the old service, and EAP server.  It
     stores state that can be starting a new
     conversation from phase 0. This approach is used by all services
     for "fast reconnect" or other
     functionality in at least some EAP methods.  Not all EAP methods create such
     an SA.

[2]  EAP-Key SA.  This is an parameters, and it doesn't require any protocol
     for transferring the service SA between the peer and EAP server, which
     is used service elements.

     The service may support keeping the old service element active
     while the new conversation takes phase, to store decrease the keying material exported by time the EAP method.
     Current EAP server implementations do
     service is not retain this SA after available.

Some sharing
     The service may allow changing some parameters by simply agreeing
     about the
     EAP conversation completes, but proposals such new values. This may involve a similar exchange as [IEEE-03-084] and
     [I-D.irtf-aaaarch-handoff] use this SA in
     phase 2, or perhaps a shorter conversation.

     This option usually requires some protocol for purposes such as pre-
     emptive key distribution.

[3]  AAA SA(s).  These SAs are between the authenticator and transferring the backend
     authentication server.  They permit
     service SA between the parties elements. An administrator may decide not to mutually
     authenticate each other
     enable this feature at all, and protect typically the communications between
     them.

[4]  Service SA(s). These SAs are between sharing is restricted
     to some particular service elements (defined either by a service
     parameter, or simple administrative decision). If the peer and authenticator, old and they are created as a result of phases 1-2 of new
     service element do not support such "context transfer", this
     approach falls back to the conversation previous option (no transfer).

     Services supporting this feature should also consider what changes
     require new authorization from the backend authentication server
     (see Section 1.3).

3.1.  EAP Method SA (peer - EAP server)

   An EAP method may store some state on 4.2).

     Note that these considerations are not limited to service
     parameters related to the authenticator--they apply to peer and
     parameters as well.

4.  Key Management

   The EAP server even
   after phase 1a has completed.

   Typically, this is used for "fast reconnect": the peer peer, authenticator and EAP backend server
   can confirm that they are still talking to the same party, perhaps
   using fewer round-trips or less computational power. In may support key
   caching.  Since EAP supports key derivation, but not key management,
   this case, functionality needs to be provided by the Secure Association
   Protocol.  Key management support includes:

[a]  Key lifetime determination.  EAP method SA is essentially does not support negotiation of
     key lifetimes, nor does it support rekey without reauthentication.

     As a cache result, the Secure Association Protocol is responsible for performance
   optimization,
     rekey and either party may remove determination of the SA from its cache at
   any point.

   An EAP method may also keep state in order to support pseudonym-based
   identity protection. This key lifetime.  Where key caching is typically a cache as well (the
   information can be recreated if the original EAP method SA
     supported, secure negotiation of key lifetimes is lost), RECOMMENDED.
     Lower layers that support rekey, but not key caching may be stored for longer periods of time.

   The EAP method SA is not restricted to a particular service or
   authenticator
     require key lifetime negotiation.  To take an example from IKE, the
     difference between IKEv1 and IKEv2 is most useful when that in IKEv1 SA lifetimes
     were negotiated. In IKEv2, each end of the peer accesses many
   different authenticators.  An EAP method SA is responsible for
   specifying how
     enforcing its own lifetime policy on the parties select if an existing EAP method SA should
   be used, and if so, which one.  Where multiple backend authentication
   servers are used, EAP method SAs are not typically synchronized
   between them.

   EAP method implementations should consider rekeying the appropriate lifetime SA
     when necessary.

[b]  Key resynchronization.  It is possible for the EAP method SA. "Fast reconnect" assumes peer or
     authenticator to reboot or reclaim resources, clearing portions or
     all of the key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the information
   required (primarily key cache will remain synchronized, and the keys in peer
     may not be able to determine before attempting to use a AAA-Key
     whether it exists within the EAP method SA) hasn't been
   compromised. In case authenticator cache.  It is therefore
     RECOMMENDED for the original authentication was carried out
   using, Secure Association Protocol to provide a
     mechanism for instance, key state resynchronization.  Since in this situation
     one or more of the parties initially do not possess a smart card, key with
     which to protect the resynchronization exchange, securing this
     mechanism may be difficult.

[c]  Key selection.  Where key caching is supported, it may be easier to compromise the
   EAP method SA (stored on the PC, possible
     for instance), so typically the EAP
   method SAs have peer and authenticator to share more than one key of a limited lifetime.

   Contents:

      o  Implicitly,
     given type.  As a result, the EAP method this SA refers Secure Association Protocol needs to
      o  Internal (non-exported) cryptographic state
      o
     support key selection, using the EAP method SA name
      o  SA lifetime

3.1.1.  Example: EAP-TLS

   In EAP-TLS [RFC2716], after Key Naming scheme described in
     this document.

[d]  Key scope determination.  Since the Discovery phase is handled out-
     of-band, EAP authentication does not provide a mechanism by which the client (peer)
   and server peer can store
     determine the following information:

      o  Implicitly, authenticator identity.  As a result, where the EAP method this SA refers to (EAP-TLS)
      o  Session identifier (a value selected by the server)
      o  Certificate of the other party (server stores the client's
         certificate and vice versa)
      o  Ciphersuite
     authenticator has multiple ports and compression method
      o  TLS Master secret (known as the EAP-TLS Master Key)
      o  SA lifetime (ensuring that the SA AAA-Key caching is supported,
     the EAP peer may not stored forever)
      o  If be able to determine the client scope of validity of
     a AAA-Key.  Similarly, where the EAP peer has multiple different credentials (certificates
         and corresponding private keys), ports, the
     authenticator may not be able to determine whether a pointer peer has
     authorization to those credentials

   When use a particular AAA-Key.  To allow key scope
     determination, the server initiates EAP-TLS, lower layer SHOULD provide a mechanism by which
     the client peer can look up determine the EAP-TLS
   SA based on scope of the credentials it was going to use (certificate and
   private key), AAA-Key cache on each
     authenticator, and by which the expected credentials (certificate or name) authenticator can determine the
     scope of the server. If an EAP-TLS SA exists, AAA-Key cache on a peer.

4.1.  Key Caching

   Key caching may be supported on the EAP peer, authenticator and it is not too old,
   backend server.  Where explicitly supported by the
   client informs lower layer, the server about
   EAP peer and authenticator MAY cache the existence AAA-Key and/or TSKs.  The
   structure of this SA the key cache on the peer and authenticator is defined
   by including
   its Session-Id in the TLS ClientHello message. The server then looks
   up lower layer.  Unless specified by the correct SA based on lower layer, the Session-Id (or detects EAP
   peer, authenticator and server MUST assume that it doesn't
   yet have one).

3.1.2.  Example: EAP-AKA

   In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication peers and
   authenticators do not cache the
   client AAA-Key or TSKs.

   The EAP peer and server can store the following information:

      o  Implicitly, MAY cache keys exported by the EAP method this SA refers as
   well as keys derived from them, subject to (EAP-AKA)
      o  A re-authentication pseudonym
      o  The client's permanent identity (IMSI)
      o  Replay protection counter
      o  Authentication key (K_aut)
      o  Encryption key (K_encr)
      o  Original Master Key (MK)
      o  SA lifetime (ensuring that the SA is not stored forever)

   When following
   restrictions:

[1]  In order to avoid key reuse, on the EAP server, transported keys
     are deleted once they are sent.  An EAP server initiates EAP-AKA, the client can look up MUST NOT retain keys
     that it has previously sent to the EAP-AKA
   SA authenticator.  For example, an
     EAP server that has transported a AAA-Key based on the credentials it was going to use (permanent identity).
   If an EAP-AKA SA exists, MSK MUST
     delete both the AAA-Key and it is not too old, the client informs MSK, and no keys may be derived
     from either the server about AAA-Key or the existence of this SA MSK from that point forward by sending its re-
   authentication pseudonym the
     server.

[2]  Keys which are not transported, such as its identity in EAP Identity Response
   message, instead of its permanent identity. The server then looks up the correct SA based EMSK, MAY be cached on this identity.

3.2.  EAP-Key SA

   This is an SA between
     the peer and EAP server, which is used to store server.  While AMSKs calculated from the keying material exported by EMSK MUST be
     deleted from the EAP method.  Current EAP server
   implementations do not retain this SA after the EAP conversation
   completes, but future implementations could use this SA for pre-
   emptive key distribution.

   Contents:

      o  MSK and EMSK names
      o  MSK and EMSK
      o  SA lifetime

3.3.  AAA SA(s) (authenticator - backend authentication server)

   In order for the authenticator and backend authentication server to
   authenticate each other, once they need to store some information.

   In case the authenticator and backend authentication server are
   colocated, and they communicate using local procedure calls or shared
   memory, this SA need not necessarily contain any information.

3.3.1.  Example: RADIUS

   In RADIUS, where shared secret authentication is used, transported, the client and
   server store each other's IP address and parent
     EMSK may remain in the shared secret, which is
   used to calculate EAP server cache.

4.2.  Parent-Child Relationships

   When keying material exported by EAP methods expires,  all keying
   material derived from the Response Authenticator [RFC2865] and Message-
   Authenticator [RFC3579] values, and to encrypt some attributes (such
   as exported keying material expires, including
   the AAA-Key, see [RFC3580] Section 3.16).

   Where IPsec is used to protect RADIUS [RFC3579] AMSKs and IKE TSKs.

   When an EAP reauthentication takes place, new keying material is used for
   key management, the parties store information necessary to
   authenticate
   derived and authorize exported by the other party (e.g. certificates, trust
   anchors and names). The IKE exchange EAP method, which eventually results in IKE Phase 1 and Phase
   2 SAs containing information used to protect the conversation
   (session
   replacement of calculated keys, selected ciphersuite, etc.)

3.3.2.  Example: Diameter with TLS

   When using Diameter protected by TLS, including the parties store information
   necessary to authenticate AAA-Key, AMSKs, and authorize the other party (e.g.
   certificates, trust anchors and names). The TLS handshake results in
   TSKs.

   As a short-term TLS SA that contains information used to protect the
   actual communications (session keys, selected TLS ciphersuite, etc.).

3.4.  Service SA(s) (peer - authenticator)

   The service SAs store information about the service being provided.
   These include the Root service SA and derived unicast and multicast
   service SAs.

   The Root service SA is established as the result of result,  while the completion lifetime of
   EAP authentication (phase 1a) and AAA-Key derivation calculated keys can be less than
   or transport
   (phase 1b).  It includes:

      o  Service parameters (or at least those parameters equal that are still needed)
      o  On the authenticator, service authorization
         information received from the backend authentication
         server (or necessary parts of it)
      o  On the peer, usually locally configured service
         authorization information.
      o  The AAA-Key, if it can be needed again (to refresh
         and/or resynchronize other exported keys or for another reason)
      o  AAA-Key lifetime

   Unicast and (optionally) multicast service SAs they are derived from from, it cannot
   be greater.  For example, TSK rekey may occur prior to EAP
   reauthentication.

   Failure to mutually prove possession of the
   Root service SA, via AAA-Key during the Secure
   Association Protocol.  In order for
   unicast and multicast service SAs and associated TSKs to be
   established, it is Protocol exchange need not necessary for EAP authentication (phase 1a) to be rerun each time.  Instead, grounds for deletion of the
   AAA-Key by both parties; rate-limiting Secure Association Protocol can
   exchanges could be used to mutually prove possession of the AAA-Key and create
   associated unicast (phase 2a) and multicast (phase 2b) service SAs
   and TSKs, enabling prevent a brute force attack.

4.3.  Local Key Lifetimes

   The Transient EAP Keys (TEKs) are session keys used to protect the
   EAP exchange conversation.  The TEKs are internal to be bypassed.  Unicast and
   multicast service SAs include:

      o Service parameters negotiated by the Secure Association Protocol.
      o Endpoint identifiers.
      o Transient Session Keys EAP method and are
   not exported.  TEKs are typically created during an EAP conversation,
   used to protect until the communication.

      o Transient Session Key lifetime.

   One function end of the Secure Association Protocol conversation and then discarded.  However,
   methods may rekey TEKs during a conversation.

   When using TEKs within an EAP conversation or across conversations,
   it is necessary to bind the the
   unicast and multicast service SAs ensure that replay protection and TSKs to endpoint identifiers. key separation
   requirements are fulfilled.  For example, within [IEEE802.11i], the 4-way handshake binds instance, if a replay counter is
   used, TEK rekey MUST occur prior to wrapping of the counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK rekeying or caching. This prevents TEK compromise from
   leading directly to the MAC addresses compromise of the endpoints; in [IKEv2], the TSKs are bound
   to and vice versa.

   EAP methods may cache local keying material which may persist for
   multiple EAP conversations when fast reconnect is used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
   derive and cache the IP addresses TLS Master Secret, typically for substantial
   time periods.  The lifetime of other local keying material calculated
   within the endpoints and EAP method is defined by the negotiated SPI.

   It method.  Note that in
   general, when using fast reconnect, there is possible for more than one unicast or multicast service SA no guarantee to
   be derived from a single Root service SA.  However, that the
   original long-term credentials are still in the possession of the
   peer.  For instance, a unicast or
   multicast service SA is always descended from only one Root service
   SA.  Unicast or multicast service SAs descended from card hold holding the same Root
   service SA private key for EAP-TLS
   may utilize have been removed. EAP servers SHOULD also verify that the same security parameters (e.g. mode,
   ciphersuite, etc.) or they may utilize different parameters.

   An long-
   term credentials are still valid, such as by checking that
   certificate used in the original authentication has not yet expired.

4.4.  Exported and Calculated Key Lifetimes

   All EAP peer may be able to negotiate multiple service SAs with a
   given authenticator, or may be able methods generating keys are required to maintain one or more service
   SAs with multiple authenticators, depending on the properties of generate the
   media.

   Except where explicitly specified by MSK and
   EMSK, and may optionally generate the Secure Association Protocol,
   it should IV.  However, EAP, defined in
   [RFC3748], does not be assumed that support the installation of new service SAs
   implies deletion negotiation of old service SAs.  It is possible lifetimes for multicast
   Root service SAs to between exported
   keying material such as the same EAP peer MSK, EMSK and authenticator;
   during a re-key of a unicast or multicast service SA it is possible
   for two service SAs to IV.

   Several mechanisms exist during for managing key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and
     Diameter [DiamEAP] support the period between when Session-Timeout attribute.  The
     Session-Timeout value represents the new
   service SA and corresponding TSKs are maximum lifetime of the
     exported keys, and all keys calculated from it.  If the AAA server
     caches exported keys, then it MUST expire the exported keys and when they are
   installed.

   Similarly, deletion or creation of a unicast or multicast service SA
   does not necessarily imply deletion or creation of related unicast or
   multicast service SAs, unless specified all
     keys calculated from them, no later than the future time indicated
     by Session-Timeout.

     On the Secure Association
   protocol.  For example, a unicast service SA may be rekeyed without
   implying a rekey of authenticator,  where EAP is used for authentication, the multicast service SA.

   The deletion of
     Session-Timeout value represents the Root service SA does maximum session time prior to
     re-authentication, as described in [RFC3580].  Where EAP is used
     for pre-authentication, the session may not necessarily imply start until some future
     time, or may never occur.  Nevertheless, the
   deletion of Session-Timeout value
     represents the derived unicast and multicast service SAs time after which the AAA-Key, and
   associated TSKs.  Failure to mutually prove possession of all keys
     calculated from it, will have expired on the AAA-Key
   during authenticator.  If the Secure Association Protocol exchange need not
     session subsequently starts, re-authentication will be grounds
   for deletion of initiated
     once the Session-Time has expired.  If the session never started,
     or started and ended, the AAA-Key and all keys calculated from it
     will be expired by both parties; the action authenticator prior to be taken the future time
     indicated by Session-Timeout.

     Since the TSK lifetime is defined often determined by authenticator
     resources, the Secure Association Protocol.

3.4.1.  Example: 802.11i

   [IEEE802.11i] Section 8.4.1.1 defines AAA server has no insight into the security associations used
   within IEEE 802.11.  A summary follows; TSK derivation
     process, and by the standard should be
   consulted for details.

   o Pairwise Master Key Security Association (PMKSA)

      The PMKSA principle of ciphersuite independence, it is a bi-directional SA, used
by both parties
     not appropriate for sending the AAA server to manage any aspect of the TSK
     derivation process, including the TSK lifetime.

[b]  Lower layer mechanisms.  While AAA attributes can communicate the
     maximum exported key lifetime, this only serves to synchronize the
     key lifetime between the backend authentication server and receiving.  The PMKSA is the Root Service SA.  It is created
      on
     authenticator.  Lower layer mechanisms can then be used to enable
     the lifetime of exported and calculated keys to be negotiated
     between the peer when EAP authentication completes successfully or and authenticator.

     Where TSKs are established as the result of a
      pre-shared key is configured.  The PMKSA Secure Association
     Protocol exchange, it is created on RECOMMENDED that the
      authenticator when Secure Association
     Protocol include support for TSK resynchronization. Where the PMK TSK
     is received or created on taken from the
      authenticator or a pre-shared key is configured.  The PMKSA AAA-Key, there is
      used no need to create manage the PTKSA.  PMKSAs TSK
     lifetime as a separate parameter, since the TSK lifetime and AAA-
     Key lifetime are cached for their lifetimes.
      The PMKSA consists identical.

[c]  System defaults.  Where the EAP method does not support the
     negotiation of the following elements:

      - PMKID (security association identifier)
      - Authenticator MAC address
      - PMK
      - Lifetime
      - Authenticated Key Management Protocol (AKMP)
      - Authorization parameters specified exported key lifetime, and a key lifetime
     negotiation mechanism is not provided by the AAA server or
        by local configuration.  This can include
        parameters such as lower lower, there may
     be no way for the peer's authorized SSID.
        On peer to learn the peer, exported key liftime.  In this information can be locally
        configured.
      - Key replay counters (for EAPOL-Key messages)
      - Reference to PTKSA (if any), needed to:
          o delete it (e.g. AAA server-initiated disconnect)
          o replace
     case it when a new four-way handshake is done
      - Reference to accounting context, RECOMMENDED that the details peer assume a default value of which depend
        on the accounting protocol used, the implementation
        and administrative details. In RADIUS, this could include
        (e.g. packet and octet counters, and Acct-Multi-Session-Id).

   o Pairwise Transient Key Security Association (PTKSA)

      The PTKSA
     exported key lifetime; 8 hours is a bi-directional SA created as suggested.  Similarly, the result
     lifetime of a
      successful four-way handshake.  The PTKSA is a unicast service SA.
      There may only calculated keys can also be one PTKSA between managed as a pair of system
     parameter on the authenticator.

4.5.  Key cache synchronization

   Issues arise when attempting to synchronize the key cache on the peer
   and
      authenticator MAC addresses.  PTKSAs are cached for authenticator.  Lifetime negotiation alone cannot guarantee key
   cache synchronization.

   One problem is that the lifetime AAA protocol cannot guarantee synchronization
   of key lifetimes between the PMKSA.  Since peer and authenticator.  Where the PTKSA
   Secure Association Protocol is tied to not run immediately after EAP
   authentication, the PMKSA, it only has exported and calculated key lifetimes will not be
   known by the additional information from peer during the 4-way handshake.  The PTKSA
      consists of hiatus.  Where EAP pre-authentication
   occurs, this can leave the following:

         - Key (PTK)
         - Selected ciphersuite
         - MAC addresses of the parties
         - Replay counters, and ciphersuite specific state
         - Reference to PMKSA: This is needed when:
            o A new four-way handshake is needed (lifetime, TKIP
              countermeasures), and we need to know which PMKSA peer uncertain whether a subsequent
   attempt to use
   o Group Transient Key Security the exported keys will prove successful.

   However, even where the Secure Association (GTKSA)

      The GTKSA Protocol is a uni-directional SA created based on run
   immediately after EAP, it is still possible for the four-way
      handshake or authenticator to
   reclaim resources if the group created key handshake. The GTKSA state is a multicast
      service SA.  A GTKSA consists of not immediately
   utilized.

   The lower layer may utilize Discovery mechanisms to assist in this.
   For example, the following:

         - Direction vector (whether authenticator manages the GTK is used for transmit or receive)
         - Group cipher suite selector
         - Key (GTK)
         - Authenticator MAC address
         - Via reference AAA-Key cache by deleting
   the oldest AAA-Key first (LIFO), the relative creation time of the
   last AAA-Key to PMKSA, or copied here:
           o Authorization parameters
           o Reference be deleted could be advertised with the Discovery
   phase, enabling the peer to accounting context

3.4.2.  Example: IKEv2/IPsec

   Note that this example determine whether a given AAA-Key had
   been expired from the authenticator key cache prematurely.

4.6.  Key Scope Issues

   As described in Section 2.3, the AAA-Key is intended to be informative, calculated from the EMSK
   and it does not
   necessarily include all information stored.

o IKEv2 SA

   - Protocol version
   - Identities MSK by the EAP peer and server, and is used as the root of the parties
   - IKEv2 SPIs
   - Selected ciphersuite
   - Replay protection counters (Message ID)
   - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
   - Key for deriving keys for IPsec SAs (SK_d)
   - Lifetime information
   - On
   ciphersuite-specific key hierarchy.  Where a backend authentication
   server is present, the authenticator, service authorization information
     received AAA-Key is transported from the backend authentication server.

When processing an incoming message, EAP server to
   the correct SA authenticator; where it is looked up based
on not present, the SPIs.

o IPsec SAs/SPD

   - Traffic selectors
   - Replay protection counters
   - Selected ciphersuite
   - IPsec SPI
   - Keys
   - Lifetime information
   - Protocol mode (tunnel or transport)

   The correct SA AAA-Key is looked up based calculated
   on SPI (for inbound packets), or
   SPD traffic selectors (for outbound traffic).  A separate IPsec SA
   exists for each direction.

3.4.3.  Sharing service SAs

   A single service may be provided by multiple logical or physical
   service elements.  Each service is responsible for specifying the authenticator.

   Regardless of how
   changing service elements is handled. Some approaches include:

Transparent sharing
     If many sessions are initiated using it, the service parameters visible to AAA-Key
   scope is between the other party (either EAP peer
     or authenticator) do not change, that calculates it, and the service can be moved without
     requiring cooperation
   authenticator that either calculates it (where no backend
   authenticator is present) or receives it from the other party.

     Whether such server (where a move
   backend authenticator server is present).

   It should be supported or used depends on
     implementation and administrative considerations. For instance, understood that an
     administrator authenticator or peer:

   [a] may decide to configure a group of IKEv2/IPsec
     gateways in a cluster for high-availability purposes, if the
     implementation used supports this. The contain multiple physical ports;
   [b] may advertise itself as multiple "virtual" authenticators
       or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or failover.

   As illustrated in Figure 1, an EAP peer does not necessarily
     have any way of knowing when the change occurs.

No sharing
     If the service parameters require changing, some changes with multiple ports may
     require terminating be
   attached to one or more authenticators, each with multiple ports.
   Where the old service, peer and starting authenticator identify themselves using a new
     conversation from phase 0. This approach is used by all services
     for at least some parameters, and port
   identifier such as a link layer address, it doesn't require any protocol
     for transferring the service SA between the service elements.

     The service may support keeping the old service element active
     while not be obvious to the new conversation takes phase,
   peer which authenticator ports are associated with which
   authenticators.  Similarly, it may not be obvious to decrease the time
   authenticator which peer ports are associated with which peers.  As a
   result, the
     service is not available.

Some sharing
     The service peer and authenticator may allow changing some parameters by simply agreeing
     about not be able to determine the new values. This may involve
   scope of the AAA-Key.

   When a similar exchange single physical authenticator advertises itself as in
     phase 2, or perhaps a shorter conversation.

     This option usually requires some protocol for transferring the
     service SA between multiple
   "virtual authenticators", the elements. An administrator EAP peer and authenticator also may decide not
   be able to
     enable this feature at all, and typically agree on the sharing is restricted
     to some particular service elements (defined either by scope of the AAA-Key, creating a service
     parameter, or simple administrative decision). If security
   vulnerability.  For example, the old peer may assume that the "virtual
   authenticators" are distinct and new
     service element do not support such "context transfer", this
     approach falls back to the previous option (no transfer).

     Services supporting this feature should also consider what changes
     require new authorization from share a key cache, whereas,
   depending on the backend authentication server
     (see Section 4.2).

     Note that these considerations are not limited to service
     parameters related to architecture of the authenticator--they apply to peer's
     parameters as well.

4.  Handoff Support

   With EAP, physical AP, a number of mechanisms shared key cache
   may or may not be utilized in order to reduce implemented.

   Where the latency of handoff between authenticators.  One such mechanism is
   EAP pre-authentication, in which EAP is utilized to pre-establish a AAA-Key on an authenticator prior to arrival of the peer.

   "Fast Handoff" is defined shared between "virtual authenticators" an
   attacker acting as a conversation in which EAP exchange
   (phase 1a) peer could authenticate with the "Guest"
   "virtual authenticator" and associated AAA pass-through is bypassed, so as to
   reduce latency.  Unlike EAP pre-authentication, "Fast  Handoff"
   mechanisms do not result in additional AAA server load.  Fast handoff
   mechanisms include:

[a]  Pre-emptive handoff.  In this technique, derive a AAA-Key.  If the AAA server pre-
     establishes virtual
   authenticators share a key state on cache, then the authenticator prior peer can utilize the AAA-
   Key derived for the "Guest" network to obtain access to arrival of the
     peer, without completion of EAP authentication.  As described in
     [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
     includes conventional AAA-Key transport, but without an EAP
     authentication.

[b]  Context transfer.  In this technique, the old authenticator
     transfers the session text
   "Corporate Intranet" virtual authenticator.

   Several measures are recommended to address these issues:

[a]  Authenticators are REQUIRED to cache associated authorizations
     along with the new authenticator, either prior
     to, or after the arrival of the peer.  As a result, AAA-Key
     transport (phase 1b) is bypassed.

   Regardless of how and apply authorizations consistently.  This
     ensures that an attacker cannot obtain elevated privileges even
     where the AAA-Key cache is provisioned on a given
   authenticator, AAA-Key caching may be utilized in order to enable a
   peer to quickly re-esta
blish a session with an authenticator.

   Where key caching shared between "virtual authenticators".

[b]  It is supported, once the RECOMMENDED that physical authenticators maintain separate
     AAA-Key caches for each "virtual authenticator".

[c]  It is derived and/or
   transported RECOMMENDED that each "virtual authenticator" identify itself
     distinctly to the authenticator, it may remain cached on the peer
   and authenticator, even after a subsequent session terminates.  To
   initiate AAA server, such as by utilizing a subsequent session with the same authenticator, distinct NAS-
     identifier attribute.  This enables the peer
   may AAA server to utilize the a
     separate credential to authenticate each "virtual authenticator".

[d]  It is RECOMMENDED that Secure Association Protocol to confirm mutual
   possession of the AAA-Key by the Protocols identify peers
     and authenticators unambiguously, without incorporating implicit
     assumptions about peer and authenticator, thereby re-
   activating authenticator architectures.  Using
     port-specific MAC addresses as identifiers is NOT RECOMMENDED where
     peers and authenticators may support multiple ports.

[e]  The AAA server and authenticator MAY implement additional
     attributes in order to further restrict the AAA-Key for use in a subsequent session.

   The introduction of handoff support introduces new security
   vulnerabilities as well as requirements for the secure handling of
   authorization context.  These issues are discussed scope.  For
     example, in 802.11, the sections
   that follow.

4.1.  Authorization Issues

   In a typical network access scenario (dial-in, wireless LAN, etc.)
   access control mechanisms are typically applied. These mechanisms
   include user authentication as well as authorization for AAA server may provide the offered
   service.

   As authenticator
     with a part list of authorized Called or Calling-Station-Ids and/or
     SSIDs for which the authentication process,  AAA-Key is valid.

[f]  Where the AAA network determines server provides attributes restricting the user's authorization profile.  The user authorizations are
   transmitted key scope,
     it is RECOMMENDED that restrictions be securely communicated by the backend authentication server to the EAP
     authenticator (also known as to the Network Access Server or
   authenticator) included with peer.  This is typically accomplished using
     the AAA-Token, which Secure Association Protocol,  but also contains the
   AAA-Key, in Phase 1b of can be accomplished via
     the EAP conversation.  Typically, method or the profile lower layer.

4.7.  Key Strength

   In order to guard against brute force attacks, EAP methods deriving
   keys need to be capable of generating keys with an appropriate
   effective symmetric key strength.  In order to ensure that key
   generation is determined based on the user identity, but a certificate presented
   by not the user may also provide authorization information.

   The backend authentication server weakest link, it is responsible for making RECOMMENDED that EAP
   methods utilizing public key cryptography choose a user
   authorization decision, answering the following questions:

[a]  Is this public key that
   has a legitimate user for this particular network?

[b]  Is this user allowed cryptographic strength meeting the type of access he symmetric key strength
   requirement.

   As noted in [RFC3766] Section 5, this results in the following
   required RSA or she is requesting?

[c]  Are there any specific parameters (mandatory tunneling, bandwidth,
     filters, DH module and so on) that the access network should be aware of DSA subgroup size in bits, for
     this user?

[d]  Is this user within the subscription rules regarding time a given
   level of day?

[e]  Is this user within his limits for concurrent sessions?

[f]  Are there any fraud, credit limit, attack resistance in bits:

        Attack Resistance     RSA or other concerns that indicate
     that access should be denied?

   While DH Modulus     DSA subgroup
           (bits)              size (bits)          size (bits)
        -----------------     -----------------     ------------
        70                          947                 128
        80                         1228                 145
        90                         1553                 153
        100                        1926                 184
        150                        4575                 279
        200                        8719                 373
        250                       14596                 475

4.8.  Key Wrap

   As described in [RFC3579] Section 4.3, known problems exist in the authorization decision is
   key wrap specified in principle simple, [RFC2548].  Where the process same RADIUS shared secret
   is complicated used by a PAP authenticator and an EAP authenticator, there is a
   vulnerability to known plaintext attack.  Since RADIUS uses the distributed nature of AAA decision making.
   Where brokering entities or proxies are involved, all of the AAA
   devices in
   shared secret for multiple purposes, including per-packet
   authentication, attribute hiding, considerable information is exposed
   about the chain from shared secret with each packet. This exposes the authenticator shared
   secret to dictionary attacks.  MD5 is used both to compute the home AAA server
   are involved in RADIUS
   Response Authenticator and the decision.  For instance, a broker can disallow
   access even if Message-Authenticator attribute, and
   some concerns exist relating to the home AAA server would allow it, or a proxy can add
   authorizations (e.g., bandwidth limits).

   Decisions can be based on static policy definitions security of this hash
   [MD5Attack].

   As discussed in [RFC3579] Section 4.3, the security vulnerabilities
   of RADIUS are extensive, and profiles as
   well as dynamic state (e.g. time therefore development of day or limits an alternative
   key wrap technique based on the number of
   concurrent sessions).  In addition RADIUS shared secret would not
   substantially improve security.  As a result, [RFC3759] Section 4.2
   recommends running RADIUS over IPsec.  The same approach is taken in
   Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
   attributes, to the Accept/Reject decision made be protected by the AAA chain, parameters IPsec or constraints can be communicated to
   the authenticator.

   The criteria for Accept/Reject decisions TLS.

   Where an untrusted AAA intermediary is present (such as a RADIUS
   proxy or the reasons for choosing
   particular authorizations are typically a Diameter agent), and data object security is not communicated to the
   authenticator, only used, the final result.  As a result,
   AAA-Key may be recovered by an attacker in control of the authenticator
   has no way to know what untrusted
   intermediary.  Possession of the decision was based on.  Was a set AAA-Key enables decryption of
   authorization parameters data
   traffic sent because this service is always provided
   to the user, or was the decision based on between the time/day peer and a specific authenticator; however
   where key separation is implemented, compromise of the
   capabilities AAA-Key does
   not enable an attacker to impersonate the peer to another
   authenticator, since that requires possession of the requesting authenticator device?

4.2.  Correctness Issues

   Bypassing all or portions of the AAA conversation creates challenges
   in ensuring that authorization EMSK, which is properly handled. These include:

[a]  Consistent application of session time limits.  A fast handoff
     should
   not automatically increase the available session time,
     allowing a user to endlessly extend their network access transported by
     changing the point of attachment.

[b]  Avoidance AAA protocol.  This vulnerability may be
   mitigated by implementation of privilege elevation.  A fast handoff should not result redirect functionality, as provided in
   [RFC3588].

5.  Handoff Support

   With EAP, a user being granted access number of mechanisms may be utilized in order to services which they are not
     entitled to.

[c]  Consideration reduce
   the latency of dynamic state.  In situations handoff between authenticators.  One such mechanism is
   EAP pre-authentication, in which dynamic
     state EAP is involved in the access decision (day/time, simultaneous
     session limit) it should be possible utilized to take this state into
     account either before or after access is granted. Note that
     consideration of network-wide state such as simultaneous session
     limits can typically only be taken into account by the backend
     authentication server.

[d]  Encoding of restrictions.  Since pre-establish a
   AAA-Key on an authenticator may not be aware prior to arrival of the criteria considered by peer.

   "Fast Handoff" is defined as a backend authentication server when
     allowing access, conversation in order which the EAP exchange
   (phase 1a) and associated AAA pass-through is bypassed, so as to ensure consistent authorization during
     a fast
   reduce latency.  Fast handoff it may be necessary to explicitly encode mechanisms include:

[a]  Pre-emptive handoff.  In this technique, the
     restrictions within AAA server pre-
     establishes key state on the authorizations provided in the AAA-Token.

[e]  State validity.  The introduction authenticator prior to arrival of fast handoff should not render the authentication server incapable of keeping track of network-
     wide state.

   A fast handoff mechanism capable
     peer, without completion of addressing these concerns is said
   to be "correct".  One condition for correctness is as follows: For a
   fast handoff EAP authentication.  As described in
     [IEEE-03-084] and [I.D.irtf-aaaarch-handoff], this technique
     includes conventional AAA-Key transport, but without an EAP
     authentication.

[b]  Context transfer.  In this technique, the old authenticator
     transfers the session text to be "correct" it MUST establish on the new device authenticator, either prior
     to, or after the
   same context as would have been created had arrival of the peer.  As a result, AAA-Key
     transport (phase 1b) is bypassed.

[c]  Key Request.  In this technique, the peer requests that the new device completed
     authenticator retrieve a AAA conversation with named key from the authentication server.

   A properly designed fast handoff scheme will only succeed if it is
   "correct" EAP server for
     potential use in this way.  If a successful fast handoff would establish
   "incorrect" state, it forthcoming session.  In this technique, EAP
     authentication (phase 1a) is preferable bypassed, but AAA-Key transport (phase
     1b) is not.

5.1.  Authorization

   In a typical network access scenario (dial-in, wireless LAN, etc.)
   access control mechanisms are typically applied. These mechanisms
   include user authentication as well as authorization for it to fail, in order to avoid
   creation the offered
   service.

   As a part of incorrect context.

   Some the authentication process, the AAA network determines
   the user's authorization profile.  The user authorizations are
   transmitted by the backend authentication server and to the EAP
   authenticator configurations
   are incapable of meeting this definition of "correctness".  For
   example, if (also known as the old and new device differ in their capabilities, it
   may be difficult to meet this definition of correctness in a fast
   handoff mechanism that bypasses AAA.  Backend authentication servers
   often perform conditional evaluation, in Network Access Server or
   authenticator) included with the AAA-Token, which also contains the authorizations
   returned
   AAA-Key, in an Access-Accept message are contingent on Phase 1b of the
   authenticator or EAP conversation.  Typically, the profile
   is determined based on dynamic state such as the time of day or number
   of simultaneous sessions.  For example, in user identity, but a heterogeneous
   deployment, certificate presented
   by the user may also provide authorization information.

   The backend authentication server might return different
   authorizations depending on the authenticator is responsible for making a user
   authorization decision, answering the request, in
   order to make sure that following questions:

[a]  Is this a legitimate user for this particular network?

[b]  Is this user allowed the requested service type of access he or she is consistent with the
   authenticator capabilities.

   If differences between the new requesting?

[c]  Are there any specific parameters (mandatory tunneling, bandwidth,
     filters, and old device would result in so on) that the
   backend authentication server sending a different set access network should be aware of messages to for
     this user?

[d]  Is this user within the new device than were sent to subscription rules regarding time of day?

[e]  Is this user within his limits for concurrent sessions?

[f]  Are there any fraud, credit limit, or other concerns that indicate
     that access should be denied?

   While the old device, then if authorization decision is in principle simple, the fast
   handoff mechanism bypasses AAA, then process
   is complicated by the fast handoff cannot be
   carried out correctly.

   For example, if some authenticator distributed nature of AAA decision making.
   Where brokering entities or proxies are involved, all of the AAA
   devices within a deployment
   support dynamic VLANs while others do not, then attributes present in the Access-Request (such as chain from the authenticator-IP-Address,
   authenticator-Identifier, Vendor-Identifier, etc.) could be examined authenticator to determine when VLAN attributes will be returned, as described in
   [RFC3580].   VLAN support is defined in [IEEE8021Q].  If a fast
   handoff bypassing the backend authentication home AAA server were to occur
   between a authenticator supporting dynamic VLANs and another
   authenticator which does not, then a guest user with access
   restricted to
   are involved in the decision.  For instance, a guest VLAN could be given unrestricted broker can disallow
   access to even if the
   network.

   Similarly, in home AAA server would allow it, or a network where access is restricted proxy can add
   authorizations (e.g., bandwidth limits).

   Decisions can be based on the day static policy definitions and time, Service Set Identifier (SSID), Calling-Sta
tion-Id or other
   factors, unless the restrictions are encoded within the
   authorizations, profiles as
   well as dynamic state (e.g. time of day or a partial AAA conversation is included, then a
   fast handoff could result in the user bypassing limits on the restrictions. number of
   concurrent sessions).  In practice, these considerations limit addition to the Accept/Reject decision made
   by the situations in which fast
   handoff mechanisms bypassing AAA chain, parameters or constraints can be expected communicated to be successful.
   Where
   the deployed devices implement authenticator.

   The criteria for Accept/Reject decisions or the same set of services, it may
   be possible reasons for choosing
   particular authorizations are typically not communicated to do successful fast handoffs within such mechanisms.
   However, where the supported services differ between devices,
   authenticator, only the final result.  As a result, the
   fast handoff may not succeed.  For example, [RFC2865] section 1.1
   states:

      "A authenticator that does not implement
   has no way to know what the decision was based on.  Was a given set of
   authorization parameters sent because this service MUST NOT
      implement is always provided
   to the RADIUS attributes for that service.  For example, a user, or was the decision based on the time/day and the
   capabilities of the requesting authenticator device?

5.2.  Correctness

   Bypassing all or portions of the AAA conversation creates challenges
   in ensuring that authorization is unable properly handled. These include:

[a]  Consistent application of session time limits.  A fast handoff
     should not automatically increase the available session time,
     allowing a user to offer ARAP service MUST NOT
      implement endlessly extend their network access by
     changing the RADIUS attributes for ARAP. point of attachment.

[b]  Avoidance of privilege elevation.  A authenticator MUST
      treat fast handoff should not result
     in a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead."

   Note that this behavior only applies user being granted access to attributes that services which they are known,
   but not implemented.  For attributes that are unknown, [RFC2865]
   Section 5 states:

      "A RADIUS server MAY ignore Attributes with an unknown Type.  A
      RADIUS client MAY ignore Attributes with an unknown Type."
     entitled to.

[c]  Consideration of dynamic state.  In order to perform a correct fast handoff, if a new device situations in which dynamic
     state is
   provided with RADIUS context for a known but unavailable service,
   then it MUST process this context involved in the same way access decision (day/time, simultaneous
     session limit) it would handle a
   RADIUS Access-Accept requesting an unavailable service.  This MUST
   cause the fast handoff should be possible to fail.  However, if a new device take this state into
     account either before or after access is provided
   with RADIUS context granted. Note that indicates an unknown attribute, then this
   attribute MAY
     consideration of network-wide state such as simultaneous session
     limits can typically only be ignored.

   Although it may seem somewhat counter-intuitive, failure is indeed taken into account by the "correct" result where a known but unsupported service is
   requested. Presumably a correctly configured backend
     authentication
   server would not request that a device carry out server.

[d]  Encoding of restrictions.  Since a service that it
   does authenticator may not implement.  This implies that if be aware
     of the new device were criteria considered by a backend authentication server when
     allowing access, in order to
   complete ensure consistent authorization during
     a AAA conversation that fast handoff it would may be likely necessary to receive
   different service instructions.  In such a case, failure of explicitly encode the fast
   handoff is
     restrictions within the desired result.  This will cause authorizations provided in the new device to go
   back to AAA-Token.

[e]  State validity.  The introduction of fast handoff should not render
     the AAA authentication server in order to receive the appropriate service
   definition.

   In practice, this implies that incapable of keeping track of network-
     wide state.

   A fast handoff mechanisms which bypass
   AAA are most likely mechanism capable of addressing these concerns is said
   to be successful within a homogeneous device
   deployment within a single administrative domain. "correct".  One condition for correctness is as follows: For example, it
   would not be advisable to carry out a fast handoff bypassing AAA
   between a authenticator providing confidentiality and another
   authenticator that does not support this service.  The correct result
   of such a
   fast handoff would to be a failure, since if "correct" it MUST establish on the handoff were
   blindly carried out, then new device the user
   same context as would be moved from have been created had the new device completed
   a secure to an
   insecure channel without permission from AAA conversation with the backend authentication server.  Thus the definition of

   A properly designed fast handoff scheme will only succeed if it is
   "correct" in this way.  If a "known but unsupported service"
   MUST encompass requests successful fast handoff would establish
   "incorrect" state, it is preferable for unavailable security services.  This
   includes vendor-specific attributes related it to security, such as
   those described in [RFC2548].

5.  Security Considerations

5.1.  Security Terminology

   "Cryptographic binding", "Cryptographic separation", "Key strength"
   and "Mutual authentication" are defined fail, in [RFC3748] order to avoid
   creation of incorrect context.

   Some backend authentication server and authenticator configurations
   are used
   with incapable of meeting this definition of "correctness".  For
   example, if the same meaning here.

5.2.  Threat Model

   The EAP threat model is described old and new device differ in [RFC3748] Section 7.1.  In order their capabilities, it
   may be difficult to address these threats, EAP relies on the security properties meet this definition of
   EAP methods (known as "security claims", described in [RFC3784]
   Section 7.2.1).  EAP method requirements for application such as
   Wireless LAN authentication are described correctness in [WLANREQ].

   The RADIUS threat model is described in [RFC3579] Section 4.1, and
   responses to these threats are described in [RFC3579] Sections 4.2
   and 4.3.  Among other things, [RFC3579] Section 4.2 recommends the
   use of IPsec ESP with non-null transform to provide per-packet
   authentication and confidentiality, integrity and replay protection
   for RADIUS/EAP.

   Given the existing documentation of EAP and AAA threat models and
   responses, there is no need to duplicate a fast
   handoff mechanism that material here.
   However, there are many other system-level threats no covered bypasses AAA.  Backend authentication servers
   often perform conditional evaluation, in
   these document which have not been described or analyzed elsewhere.
   These include:

[1]  An attacker may try to modify or spoof Secure Association Protocol
     packets.

[2]  An attacker compromising the authorizations
   returned in an authenticator may provide incorrect
     information to Access-Accept message are contingent on the EAP peer and/or server via out-of-band
     mechanisms (such as via a AAA
   authenticator or lower layer protocol).  This
     includes impersonating another authenticator, on dynamic state such as the time of day or providing
     inconsistent information to number
   of simultaneous sessions.  For example, in a heterogeneous
   deployment, the peer and EAP server.

[3]  An attacker may attempt to perform downgrading attacks backend authentication server might return different
   authorizations depending on the
     ciphersuite negotiation within authenticator making the Secure Association Protocol request, in
   order to ensure make sure that a weaker ciphersuite the requested service is used to protect data.

   Depending on consistent with the lower layer, these attacks may be carried out
   without requiring physical proximity.

   In order to address these threats, [Housley56] describes
   authenticator capabilities.

   If differences between the
   mandatory system security properties:

Algorithm independence
     Wherever cryptographic algorithms are chosen, the algorithms must
     be negotiable, new and old device would result in order to provide resilient against compromise of the
   backend authentication server sending a particular algorithm.  Algorithm independence must be
     demonstrated within all aspects different set of messages to
   the system, including within
     EAP, AAA and the Secure Association Protocol.  However, for
     interoperability, at least one suite of algorithms MUST be
     implemented.

Strong, fresh session keys
     Session keys must be demonstrated new device than were sent to be strong and fresh in all
     circumstances, while at the same time retaining algorithm
     independence.

Replay protection
     All protocol exchanges must old device, then if the fast
   handoff mechanism bypasses AAA, then the fast handoff cannot be replay protected.  This includes
     exchanges
   carried out correctly.

   For example, if some authenticator devices within EAP, AAA, and a deployment
   support dynamic VLANs while others do not, then attributes present in
   the Secure Association Protocol.

Authentication
     All parties need Access-Request (such as the authenticator-IP-Address,
   authenticator-Identifier, Vendor-Identifier, etc.) could be examined
   to determine when VLAN attributes will be authenticated.  The confidentiality of returned, as described in
   [RFC3580].   VLAN support is defined in [IEEE8021Q].  If a fast
   handoff bypassing the backend authentication server were to occur
   between a authenticator must be maintained.  No plaintext passwords are
     allowed.

Authorization
     EAP peer supporting dynamic VLANs and another
   authenticator authorization must be performed.

Session keys
     Confidentiality of session keys must which does not, then a guest user with access
   restricted to a guest VLAN could be maintained.

Ciphersuite negotiation
     The selection of given unrestricted access to the "best" ciphersuite must be securely confirmed.

Unique naming
     Session keys must be uniquely named.

Domino effect
     Compromise of
   network.

   Similarly, in a single authenticator cannot compromise any other
     part of network where access is restricted based on the system, including session keys day
   and long-term secrets.

Key binding
     The key must be bound to the appropriate context.

5.3.  Security Analysis

   Figure 6 illustrates the relationship between time, Service Set Identifier (SSID), Calling-Station-Id or other
   factors, unless the peer, authenticator
   and backend authentication server.

                               EAP peer
                                 /\
                                /  \
            Protocol: EAP      /    \    Protocol: Secure Association
            Auth: Mutual      /      \   Auth: Mutual
            Unique keys:     /        \  Unique keys: TSKs
            TEKs,EMSK       /          \
                           /
           \
              EAP server  +--------------+ Authenticator
                            Protocol: AAA
                            Auth: Mutual
                            Unique key: AAA session key

    Figure 6: Relationship between peer, authenticator and auth. server

   The peer and EAP server communicate using EAP [RFC3748].  The
   security properties of this communication restrictions are largely determined by encoded within the chosen EAP method.  Method security claims are described
   authorizations, or a partial AAA conversation is included, then a
   fast handoff could result in
   [RFC3748] Section 7.2.  These include the  key strength, protected
   ciphersuite negotiation, mutual authentication, integrity protection,
   replay protection, confidentiality, key derivation, key strength,
   dictionary attack resistance, user bypassing the restrictions.

   In practice, these considerations limit the situations in which fast reconnect, cryptographic binding,
   session independence, fragmentation and channel binding claims.  At a
   minimum, methods claiming
   handoff mechanisms bypassing AAA can be expected to support key derivation must also support
   mutual authentication.  As noted in [RFC3748] Section 7.10:

      EAP Methods deriving keys MUST provide for mutual authentication
      between be successful.
   Where the EAP peer and deployed devices implement the EAP Server.

   Ciphersuite independence is also required:

      Keying material exported by EAP methods MUST be independent same set of the
      ciphersuite negotiated services, it may
   be possible to protect data.

   In terms of key strength and freshness, [RFC3748] Section 10 says:

      EAP methods SHOULD ensure do successful fast handoffs within such mechanisms.
   However, where the freshness of supported services differ between devices, the MSK and EMSK even
      in cases where one party
   fast handoff may not have succeed.  For example, [RFC2865] section 1.1
   states:

      "A authenticator that does not implement a high quality random number
      generator.... In order to preserve algorithm independence, EAP
      methods deriving keys SHOULD support (and document) the protected
      negotiation of given service MUST NOT
      implement the ciphersuite used RADIUS attributes for that service.  For example, a
      authenticator that is unable to protect the EAP
      conversation between offer ARAP service MUST NOT
      implement the peer and server...  In order RADIUS attributes for ARAP.  A authenticator MUST
      treat a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead."

   Note that this behavior only applies to enable
      deployments requiring strong keys, EAP methods supporting key
      derivation SHOULD be capable of generating attributes that are known,
   but not implemented.  For attributes that are unknown, [RFC2865]
   Section 5 states:

      "A RADIUS server MAY ignore Attributes with an MSK and EMSK, each unknown Type.  A
      RADIUS client MAY ignore Attributes with an effective key strength of at least 128 bits.

   The authenticator and backend authentication server communicate using unknown Type."

   In order to perform a AAA protocol such as correct fast handoff, if a new device is
   provided with RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
   eap].  As noted in [RFC3588] Section 13, Diameter must be protected
   by either IPsec ESP with non-null transform or TLS.  As context for a known but unavailable service,
   then it MUST process this context the same way it would handle a result,
   Diameter requires per-packet integrity and confidentiality.  Replay
   protection must be supported.  For RADIUS, [RFC3579] Section 4.2
   recommends that
   RADIUS be protected by IPsec ESP with Access-Accept requesting an unavailable service.  This MUST
   cause the fast handoff to fail.  However, if a non-null
   transform, and where IPsec new device is implemented replay protection must be
   supported.

   The peer and authenticator communicate using the Secure Association
   Protocol.

   As noted in the figure, each party in the exchange mutually
   authenticates provided
   with each of RADIUS context that indicates an unknown attribute, then this
   attribute MAY be ignored.

   Although it may seem somewhat counter-intuitive, failure is indeed
   the other parties, and derives "correct" result where a unique
   key.  All parties in the diagram have access to the AAA-Key.

   The EAP peer and known but unsupported service is
   requested. Presumably a correctly configured backend authentication
   server mutually authenticate
   via the EAP method, and derive would not request that a device carry out a service that it
   does not implement.  This implies that if the TEKs and EMSK which are known only new device were to them. The TEKs are used
   complete a AAA conversation that it would be likely to protect some or all receive
   different service instructions.  In such a case, failure of the EAP
   conversation between fast
   handoff is the peer and authenticator, so as to guard
   against modification or insertion of EAP packets by an attacker.  The
   degree of protection afforded by the TEKs is determined by the EAP
   method; some methods may protect the entire EAP packet, including the
   EAP header, while other methods may only protect desired result.  This will cause the contents of new device to go
   back to the
   Type-Data field, defined AAA server in [RFC3748].

   Since EAP is spoken only between order to receive the EAP peer and server, if appropriate service
   definition.

   In practice, this implies that fast handoff mechanisms which bypass
   AAA are most likely to be successful within a
   backend authentication server is present then the EAP conversation
   does homogeneous device
   deployment within a single administrative domain. For example, it
   would not provide mutual authentication between the peer and
   authenticator, only between the EAP peer and EAP server (backend
   authentication server).  As be advisable to carry out a result, mutual authentication fast handoff bypassing AAA
   between
   the peer and authenticator only occurs where a Secure Association
   protocol is used, such the unicast authenticator providing confidentiality and group key derivation handshake
   supported in [IEEE80211i].  This means another
   authenticator that absent use does not support this service.  The correct result
   of such a secure
   Association Protocol, from the point of view of fast handoff would be a failure, since if the peer, EAP mutual
   authentication only proves that handoff were
   blindly carried out, then the authenticator is trusted by user would be moved from a secure to an
   insecure channel without permission from the backend authentication server;
   server.  Thus the identity definition of the authenticator is
   not confirmed.

   Utilizing the AAA protocol, the authenticator and backend
   authentication server mutually authenticate and derive session keys
   known only to them, used a "known but unsupported service"
   MUST encompass requests for unavailable security services.  This
   includes vendor-specific attributes related to provide per-packet integrity security, such as
   those described in [RFC2548].

6.  Security Considerations

6.1.  Security Terminology

   "Cryptographic binding", "Cryptographic separation", "Key strength"
   and replay
   protection, authentication "Mutual authentication" are defined in [RFC3748] and confidentiality. are used
   with the same meaning here.

6.2.  Threat Model

   The AAA-Key EAP threat model is
   distributed by the backend authentication server described in [RFC3748] Section 7.1.  In order
   to address these threats, EAP relies on the authenticator
   over this channel, bound to attributes constraining its usage, as
   part security properties of the AAA-Token.
   EAP methods (known as "security claims", described in [RFC3784]
   Section 7.2.1).  EAP method requirements for application such as
   Wireless LAN authentication are described in [WLANREQ].

   The binding of attributes to the AAA-Key
   within a protected package RADIUS threat model is important so the authenticator
   receiving the AAA-Token can determine that it has not been
   compromised, described in [RFC3579] Section 4.1, and that the keying material has not been replayed, or
   mis-directed
   responses to these threats are described in some way.

   The security properties of [RFC3579] Sections 4.2
   and 4.3.  Among other things, [RFC3579] Section 4.2 recommends the EAP exchange are dependent on each leg
   use of IPsec ESP with non-null transform to provide per-packet
   authentication and confidentiality, integrity and replay protection
   for RADIUS/EAP.

   Given the triangle: the selected existing documentation of EAP method, and AAA protocol threat models and the Secure
   Association Protocol.

   Assuming
   responses, there is no need to duplicate that the AAA protocol provides protection against rogue
   authenticators forging their identity, then the AAA-Token can be
   assumed material here.
   However, there are many other system-level threats no covered in
   these document which have not been described or analyzed elsewhere.
   These include:

[1]  An attacker may try to be sent modify or spoof Secure Association Protocol
     packets.

[2]  An attacker compromising an authenticator may provide incorrect
     information to the correct EAP peer and/or server via out-of-band
     mechanisms (such as via a AAA or lower layer protocol).  This
     includes impersonating another authenticator, or providing
     inconsistent information to the peer and where it is
   wrapped appropriately, it can be assumed EAP server.

[3]  An attacker may attempt to be immune perform downgrading attacks on the
     ciphersuite negotiation within the Secure Association Protocol in
     order to compromise
   by ensure that a snooping attacker.

   Where an untrusted AAA intermediary weaker ciphersuite is present, used to protect data.

   Depending on the AAA-Token must
   not lower layer, these attacks may be provided carried out
   without requiring physical proximity.

   In order to address these threats, [Housley56] describes the intermediary so as
   mandatory system security properties:

Algorithm independence
     Wherever cryptographic algorithms are chosen, the algorithms must
     be negotiable, in order to avoid provide resilient against compromise of the
   AAA-Token.  This can
     a particular algorithm.  Algorithm independence must be avoided by use
     demonstrated within all aspects of re-direct as defined in
   [RFC3588].

   When EAP is used for authentication on PPP or wired IEEE 802
   networks, it is typically assumed that the link is physically secure,
   so that an attacker cannot gain access to system, including within
     EAP, AAA and the link, or insert a rogue
   device. EAP methods defined in [RFC3748] reflect this usage model.
   These include EAP MD5, as well as One-Time Password (OTP) and Generic
   Token Card.  These methods support one-way authentication (from EAP
   peer to authenticator) but not mutual authentication or key
   derivation.  As a result, these methods do not bind the initial
   authentication and subsequent data traffic, even when the the
   ciphersuite used to protect data supports per-packet authentication
   and integrity protection. As a result, EAP methods not supporting
   mutual authentication are vulnerable to Secure Association Protocol.  However, for
     interoperability, at least one suite of algorithms MUST be
     implemented.

Strong, fresh session hijacking as well as
   attacks by rogue devices.

   On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
   become easy keys
     Session keys must be demonstrated to mount, since any attacker within range can access the
   wireless medium, or act as an access point.  As a result, new
   ciphersuites have been proposed for use with wireless LANs
   [IEEE80211i] which provide per-packet authentication, integrity and
   replay protection.  In addition, mutual authentication be strong and key
   derivation, provided by methods such as EAP-TLS [RFC2716] are
   required [IEEE80211i], so as to address fresh in all
     circumstances, while at the threat of rogue devices, same time retaining algorithm
     independence.

Replay protection
     All protocol exchanges must be replay protected.  This includes
     exchanges within EAP, AAA, and provide keying material to bind the initial authentication Secure Association Protocol.

Authentication
     All parties need to
   subsequent data traffic.

   If be authenticated.  The confidentiality of the selected
     authenticator must be maintained.  No plaintext passwords are
     allowed.

Authorization
     EAP method does not support mutual authentication,
   then the peer will and authenticator authorization must be vulnerable to attack by rogue authenticators
   and backend authentication servers. If performed.

Session keys
     Confidentiality of session keys must be maintained.

Ciphersuite negotiation
     The selection of the EAP method does not derive
   keys, then TSKs will not "best" ciphersuite must be available for use with a negotiated
   ciphersuite, and there will securely confirmed.

Unique naming
     Session keys must be no binding between the initial EAP
   authentication and subsequent data traffic, leaving the session
   vulnerable to hijac
k.

   If the backend authentication server does not protect against uniquely named.

Domino effect
     Compromise of a single authenticator masquerade, or provide the proper binding cannot compromise any other
     part of the AAA-
   Key to the system, including session within the AAA-Token, then one or more AAA-Keys
   may be sent to an unauthorized party, keys and an attacker may be able to
   gain access to the network.  If the AAA-Token is provided to an
   untrusted AAA intermediary, then that intermediary may long-term secrets.

Key binding
     The key must be able bound to
   modify the AAA-Key, or the attributes associated with it, as
   described in [RFC2607].

   If the Secure Association Protocol does not provide mutual proof of
   possession of the AAA-Key material, then the peer will not have
   assurance that it is connected to appropriate context.

6.3.  Security Analysis

   Figure 6 illustrates the correct authenticator, only
   that relationship between the peer, authenticator
   and backend authentication server.

                               EAP peer
                                 /\
                                /  \
            Protocol: EAP      /    \    Protocol: Secure Association
            Auth: Mutual      /      \   Auth: Mutual
            Unique keys:     /        \  Unique keys: TSKs
            TEKs,EMSK       /          \
                           /            \
              EAP server share a
   trust relationship (since  +--------------+ Authenticator
                            Protocol: AAA protocols support mutual
   authentication).  This distinction can become important when multiple
   authenticators receive AAA-Keys from
                            Auth: Mutual
                            Unique key: AAA session key

    Figure 6: Relationship between peer, authenticator and auth. server
   The peer and EAP server communicate using EAP [RFC3748].  The
   security properties of this communication are largely determined by
   the backend authentication
   server, such as where fast handoff is supported.  If chosen EAP method.  Method security claims are described in
   [RFC3748] Section 7.2.  These include the TSK
   derivation does not provide for  key strength, protected
   ciphersuite and
   capabilities negotiation, then downgrade attacks are possible.

5.4.  Man-in-the-middle Attacks mutual authentication, integrity protection,
   replay protection, confidentiality, key derivation, key strength,
   dictionary attack resistance, fast reconnect, cryptographic binding,
   session independence, fragmentation and channel binding claims.  At a
   minimum, methods claiming to support key derivation must also support
   mutual authentication.  As described noted in [I-D.puthenkulam-eap-binding], [RFC3748] Section 7.10:

      EAP method sequences
   and compound Methods deriving keys MUST provide for mutual authentication mechanisms may be subject to man-in-the-
   middle attacks.  When such attacks are successfully carried out, the
   attacker acts as an intermediary
      between a victim and a legitimate
   authenticator.  This allows the attacker to authenticate successfully
   to the authenticator, as well as to obtain access to the network.

   In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
   recommends derivation of a compound key by which the EAP peer and
   server can prove that they have participated in the entire EAP
   exchange.  Since the compound key must not be known to an attacker
   posing as an authenticator, and yet must be derived from quantities
   that are Server.

   Ciphersuite independence is also required:

      Keying material exported by EAP methods, it may methods MUST be desirable to derive independent of the
   compound key from a portion
      ciphersuite negotiated to protect data.

   In terms of key strength and freshness, [RFC3748] Section 10 says:

      EAP methods SHOULD ensure the freshness of the EMSK. MSK and EMSK even
      in cases where one party may not have a high quality random number
      generator.... In order to provide proper
   key hygiene, it is recommended that the compound key used for man-in-
   the-middle protection be cryptographically separate from other preserve algorithm independence, EAP
      methods deriving keys
   derived from SHOULD support (and document) the EMSK, such as fast handoff keys, discussed in
   Section 2.5.

5.5.  Denial of Service Attacks

   The caching protected
      negotiation of security associations may result in vulnerability the ciphersuite used to
   denial of service attacks.  Since an protect the EAP
      conversation between the peer may derive multiple EAP
   SAs with a given and server...  In order to enable
      deployments requiring strong keys, EAP server, methods supporting key
      derivation SHOULD be capable of generating an MSK and creation EMSK, each
      with an effective key strength of at least 128 bits.

   The authenticator and backend authentication server communicate using
   a new EAP SA does not
   implicitly delete a previous EAP SA, EAP methods that result AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
   eap].  As noted in
   creation of persistent state may [RFC3588] Section 13, Diameter must be vulnerable to denial of service
   attacks protected
   by a rogue EAP peer. either IPsec ESP with non-null transform or TLS.  As a result, EAP methods creating persistent state may wish to limit
   the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
   Diameter requires per-packet integrity and confidentiality.  Replay
   protection must be supported.  For example, an EAP server may choose to only retain a few EAP SAs
   for each peer.  This prevents RADIUS, [RFC3579] Section 4.2
   recommends that RADIUS be protected by IPsec ESP with a rogue non-null
   transform, and where IPsec is implemented replay protection must be
   supported.

   The peer from denying access to
   other peers.

   Similarly, an authenticator may have multiple AAA-Key SAs
   corresponding to a given EAP peer; to conserve resources an and authenticator may choose to limit the number of cached AAA-Key (Phase
   1 b) SAs for each peer.

   Depending on communicate using the media, creation of a new unicast Secure Association
   SA may or may not imply deletion of a previous unicast secure
   association SA.  Where there is no implied deletion,
   Protocol.

   As noted in the
   authenticator may choose to limit Phase 2 (unicast and multicast)
   Secure Association SAs for figure, each peer.

5.6.  Impersonation

   Both party in the RADIUS exchange mutually
   authenticates with each of the other parties, and Diameter protocols are potentially vulnerable to
   impersonation by derives a rogue authenticator.

   While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
   support mutual authentication between unique
   key.  All parties in the authenticator (known as diagram have access to the
   AAA client) AAA-Key.

   The EAP peer and the backend authentication server (known as mutually authenticate
   via the AAA
   server), EAP method, and derive the security mechanisms vary according TEKs and EMSK which are known only
   to the AAA protocol.

   In RADIUS, the shared secret them. The TEKs are used for authentication is determined by
   the source address to protect some or all of the RADIUS packet.  As noted in [RFC3579]
   Section 4.3.7, it is highly desirable that EAP
   conversation between the source address be
   checked against one or more NAS identification attributes peer and authenticator, so as to
   detect and prevent impersonation attacks.

   When RADIUS requests are forwarded guard
   against modification or insertion of EAP packets by an attacker.  The
   degree of protection afforded by a proxy, the NAS-IP-Address or
   NAS-IPv6-Address attributes TEKs is determined by the EAP
   method; some methods may not correspond to protect the source address.
   Since entire EAP packet, including the NAS-Identifier attribute need not contain an FQDN, it also
   EAP header, while other methods may not correspond to the source address, even indirectly.  [RFC2865]
   Section 3 states:

         A RADIUS server MUST use only protect the source IP address contents of the RADIUS
         UDP packet to decide which shared secret to use, so that
         RADIUS requests can be proxied.

   This implies that it is possible for a rogue authenticator to forge
   NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
   a RADIUS Access-Request in order to impersonate another
   authenticator.  Among other things, this can result
   Type-Data field, defined in messages (and
   MSKs) being sent to the wrong authenticator. [RFC3748].

   Since the rogue
   authenticator EAP is authenticated by spoken only between the RADIUS proxy or EAP peer and server, if a
   backend authentication server purely
   based on is present then the source address, other mechanisms are required to detect EAP conversation
   does not provide mutual authentication between the forgery.  In addition, it peer and
   authenticator, only between the EAP peer and EAP server (backend
   authentication server).  As a result, mutual authentication between
   the peer and authenticator only occurs where a Secure Association
   protocol is possible for attributes used, such as the
   Called-Station-Id unicast and Calling-Station-Id to be forged as well.

   As recommended group key derivation handshake
   supported in [RFC3579], this vulnerability can be mitigated by
   having RADIUS proxies check authenticator identification attributes
   against the source address.

   To allow verification [IEEE80211i].  This means that absent use of session parameters such as a secure
   Association Protocol, from the Called-
   Station- Id and Calling-Station-Id, these can be sent by point of view of the peer, EAP peer
   to mutual
   authentication only proves that the server, protected authenticator is trusted by the TEKs. The RADIUS server can then
   check the parameters sent by
   backend authentication server; the EAP peer against those claimed by identity of the authenticator.  If a discrepancy authenticator is found, an error can be
   logged.

   While [RFC3588] requires use of
   not confirmed.

   Utilizing the Route-Record AVP, this utilizes
   FQDNs, so that impersonation detection requires DNS A/AAAA AAA protocol, the authenticator and PTR
   RRs backend
   authentication server mutually authenticate and derive session keys
   known only to be properly configured.  As a result, it appears that Diameter
   is as vulnerable them, used to this attack as RADIUS, if not more so. To address
   this vulnerability, it provide per-packet integrity and replay
   protection, authentication and confidentiality.  The AAA-Key is necessary to allow
   distributed by the backend authentication server to communicate with the authenticator directly,
   such
   over this channel, bound to attributes constraining its usage, as via
   part of the redirect functionality supported in [RFC3588].

5.7.  Channel AAA-Token.  The binding

   It is possible for a compromised or poorly implemented EAP
   authenticator to communicate incorrect information of attributes to the EAP peer
   and/or server. This may enable an authenticator to impersonate
   another AAA-Key
   within a protected package is important so the authenticator or communicate incorrect information via out-
   of-band mechanisms (such as via AAA or the lower layer protocol).

   Where EAP is used in pass-through mode,
   receiving the EAP peer typically does AAA-Token can determine that it has not verify been
   compromised, and that the identity keying material has not been replayed, or
   mis-directed in some way.

   The security properties of the pass-through authenticator, it only
   verifies that EAP exchange are dependent on each leg
   of the pass-through authenticator is trusted by triangle: the selected EAP
   server. This creates a potential security vulnerability, described in
   [RFC3748] Section 7.15.

   [RFC3579] Section 4.3.7 describes how an EAP pass-through
   authenticator acting as a method, AAA client protocol and the Secure
   Association Protocol.

   Assuming that the AAA protocol provides protection against rogue
   authenticators forging their identity, then the AAA-Token can be detected if it attempts
   assumed to be sent to impersonate another authenticator (such by sending incorrect NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
   [RFC3162] attributes via the AAA protocol).  However, correct authenticator, and where it is possible
   for a pass-through authenticator acting as
   wrapped appropriately, it can be assumed to be immune to compromise
   by a snooping attacker.

   Where an untrusted AAA client to provide

INTERNET-DRAFT        EAP Key Management Framework
 14 November 2004

   correct information intermediary is present,  the AAA-Token must
   not be provided to the AAA server while communicating misleading
   information intermediary so as to avoid compromise of the
   AAA-Token.  This can be avoided by use of re-direct as defined in
   [RFC3588].

   When EAP peer via a lower layer protocol.

   For example, it is possible used for a compromised authenticator to
   utilize another authenticator's Called-Station-Id authentication on PPP or NAS-Identifier
   in communicating with wired IEEE 802
   networks, it is typically assumed that the EAP peer via a lower layer protocol, or for
   a pass-through authenticator acting as a AAA client to provide link is physically secure,
   so that an
   incorrect peer Calling-Station-Id [RFC2865][RFC3580] attacker cannot gain access to the AAA
   server via the AAA protocol.

   As noted link, or insert a rogue
   device. EAP methods defined in [RFC3748] Section 7.15, reflect this vulnerability can be
   addressed by use of usage model.
   These include EAP MD5, as well as One-Time Password (OTP) and Generic
   Token Card.  These methods that support a protected exchange of
   channel properties such as endpoint identifiers, including (but one-way authentication (from EAP
   peer to authenticator) but not
   limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
   [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865], and NAS-IPv6-Address [RFC3162].

   Using such mutual authentication or key
   derivation.  As a protected exchange, it is possible to match result, these methods do not bind the channel
   properties provided by initial
   authentication and subsequent data traffic, even when the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  For example, see
   [ServiceIdent].

5.8.  Key Strength

   In order
   ciphersuite used to guard against brute force attacks, protect data supports per-packet authentication
   and integrity protection. As a result, EAP methods deriving
   keys need not supporting
   mutual authentication are vulnerable to be capable of generating keys with an appropriate
   effective symmetric key strength.  In order session hijacking as well as
   attacks by rogue devices.

   On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
   become easy to ensure that key
   generation is not mount, since any attacker within range can access the weakest link, it is necessary for EAP methods
   utilizing public key cryptography to choose
   wireless medium, or act as an access point.  As a public key that has a
   cryptographic strength meeting the symmetric key strength
   requirement.

   As noted in [RFC3766] Section 5, this results in the following
   required RSA or DH module and DSA subgroup size in bits, result, new
   ciphersuites have been proposed for a given
   level of attack resistance in bits:

        Attack Resistance     RSA or DH Modulus     DSA subgroup
           (bits)              size (bits)          size (bits)
        -----------------     -----------------     ------------
        70                          947                 128
        80                         1228                 145
        90                         1553                 153
        100                        1926                 184
        150                        4575                 279
        200                        8719                 373
        250                       14596                 475

5.9.  Key Wrap

   As described in [RFC3579] Section 4.3, known problems exist in the use with wireless LANs
   [IEEE80211i] which provide per-packet authentication, integrity and
   replay protection.  In addition, mutual authentication and key wrap specified in [RFC2548].  Where the same RADIUS shared secret
   is used
   derivation, provided by a PAP authenticator methods such as EAP-TLS [RFC2716] are
   required [IEEE80211i], so as to address the threat of rogue devices,
   and an EAP authenticator, there is a
   vulnerability provide keying material to known plaintext attack.  Since RADIUS uses bind the
   shared secret for multiple purposes, including per-packet
   authentication, attribute hiding, considerable information is exposed
   about initial authentication to
   subsequent data traffic.

   If the shared secret with each packet. This exposes selected EAP method does not support mutual authentication,
   then the shared
   secret to dictionary attacks.  MD5 is used both peer will be vulnerable to compute the RADIUS
   Response Authenticator attack by rogue authenticators
   and backend authentication servers. If the Message-Authenticator attribute, EAP method does not derive
   keys, then TSKs will not be available for use with a negotiated
   ciphersuite, and
   some concerns exist relating to the security of this hash
   [MD5Attack].

   As discussed in [RFC3579] Section 4.3, there will be no binding between the security vulnerabilities
   of RADIUS are extensive, initial EAP
   authentication and therefore development subsequent data traffic, leaving the session
   vulnerable to hijack.

   If the backend authentication server does not protect against
   authenticator masquerade, or provide the proper binding of the AAA-
   Key to the session within the AAA-Token, then one or more AAA-Keys
   may be sent to an alternative
   key wrap technique based on unauthorized party, and an attacker may be able to
   gain access to the RADIUS shared secret would not
   substantially improve security.  As a result, [RFC3759] Section 4.2
   recommends running RADIUS over IPsec.  The same approach network.  If the AAA-Token is taken in
   Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
   attributes, provided to be protected by IPsec or TLS.

   Where an
   untrusted AAA intermediary, then that intermediary is present (such as a RADIUS
   proxy or a Diameter agent), and data object security is not used, the
   AAA-Key may be recovered by an attacker able to
   modify the AAA-Key, or the attributes associated with it, as
   described in control of [RFC2607].

   If the untrusted
   intermediary.  Possession Secure Association Protocol does not provide mutual proof of
   possession of the AAA-Key enables decryption of data
   traffic sent between material, then the peer and a specific authenticator; however
   where key separation is implemented, compromise of the AAA-Key does will not enable an attacker have
   assurance that it is connected to impersonate the peer to another correct authenticator, since only
   that requires possession of the EMSK, which is
   not transported by the authenticator and backend authentication server share a
   trust relationship (since AAA protocol. protocols support mutual
   authentication).  This vulnerability may be
   mitigated by implementation of redirect functionality, distinction can become important when multiple
   authenticators receive AAA-Keys from the backend authentication
   server, such as provided in
   [RFC3588].

6.  Security Requirements

   This section summarizes where fast handoff is supported.  If the security requirements that must be met by
   EAP methods, AAA protocols,  Secure Association Protocols TSK
   derivation does not provide for protected ciphersuite and
   Ciphersuites in order to address the security threats
   capabilities negotiation, then downgrade attacks are possible.

6.4.  Man-in-the-middle Attacks

   As described in
   this document. These requirements MUST [I-D.puthenkulam-eap-binding], EAP method sequences
   and compound authentication mechanisms may be met by specifications
   requesting publication subject to man-in-the-
   middle attacks.  When such attacks are successfully carried out, the
   attacker acts as an RFC.  Each requirement provides intermediary between a
   pointer to the sections of this document describing the threat that
   it mitigates.

6.1.  EAP Method Requirements

   It is possible for the peer victim and EAP server a legitimate
   authenticator.  This allows the attacker to mutually authenticate
   and derive keys. successfully
   to the authenticator, as well as to obtain access to the network.

   In order to provide keying material for use in a
   subsequently negotiated ciphersuite, an EAP method supporting key prevent these attacks, [I-D.puthenkulam-eap-binding]
   recommends derivation MUST export a Master Session Key (MSK) of at least 64
   octets, and an Extended Master Session Key (EMSK) of at least 64
   octets.  EAP Methods deriving keys MUST provide for mutual
   authentication between a compound key by which the EAP peer and
   server can prove that they have participated in the entire EAP Server.

   The MSK and EMSK MUST NOT
   exchange.  Since the compound key must not be used directly known to protect data; however,
   they are of sufficient size to enable derivation of a AAA-Key
   subsequently used to derive Transient Session Keys (TSKs) for use
   with the selected ciphersuite.  Each ciphersuite is responsible for
   specifying how to derive the TSKs from the AAA-Key.

   The AAA-Key is an attacker
   posing as an authenticator, and yet must be derived from the keying material quantities
   that are exported by the EAP
   method (MSK and EMSK).  This derivation occurs on methods, it may be desirable to derive the AAA server.
   compound key from a portion of the EMSK.  In
   many existing protocols order to provide proper
   key hygiene, it is recommended that use EAP, the AAA-Key and MSK are
   equivalent, but more complicated mechanisms are possible (see Section
   2.5 compound key used for details).

   EAP methods SHOULD ensure the freshness of man-in-
   the-middle protection be cryptographically separate from other keys
   derived from the MSK and EMSK even EMSK, such as fast handoff keys, discussed in
   cases where one party may not have a high quality random number
   generator.  A RECOMMENDED method is for each party to provide a nonce
   Section 2.3.

6.5.  Denial of at least 128 bits, used Service Attacks

   The caching of security associations may result in the derivation vulnerability to
   denial of the MSK and EMSK. service attacks.  Since an EAP methods export the MSK and EMSK peer may derive multiple EAP
   SAs with a given EAP server, and creation of a new EAP SA does not Transient Session Keys so
   as to allow
   implicitly delete a previous EAP methods to be ciphersuite and media independent.
   Keying material exported by SA, EAP methods MUST be independent that result in
   creation of the
   ciphersuite negotiated to protect data.

   Depending on the lower layer, EAP methods may run before or after
   ciphersuite negotiation, so that the selected ciphersuite persistent state may not be
   known vulnerable to the EAP method.  By providing keying material usable with
   any ciphersuite, denial of service
   attacks by a rogue EAP methods can used with peer.

   As a wide range of
   ciphersuites and media.

   It is RECOMMENDED that methods providing integrity protection of result, EAP
   packets include coverage of all methods creating persistent state may wish to limit
   the number of cached EAP header fields, including the
   Code, Identifier, Length, Type and Type-Data fields.

   In order SAs (Phase 1a) corresponding to preserve algorithm independence, an EAP methods deriving
   keys SHOULD support (and document) the protected negotiation of the
   ciphersuite used peer.
   For example, an EAP server may choose to protect the only retain a few EAP conversation between the peer and
   server. SAs
   for each peer.  This is distinct from the ciphersuite negotiated between the prevents a rogue peer and authenticator, used from denying access to protect data.

   The strength of Transient Session Keys (TSKs) used
   other peers.

   Similarly, an authenticator may have multiple AAA-Key SAs
   corresponding to protect data is
   ultimately dependent on the strength of keys generated by the a given EAP
   method.  If peer; to conserve resources an EAP method cannot produce keying material of
   sufficient strength, then the TSKs
   authenticator may be subject to brute force
   attack.
 In order choose to enable deployments requiring strong keys, EAP
   methods supporting key derivation SHOULD be capable limit the number of generating an
   MSK and EMSK, cached AAA-Key (Phase
   1 b) SAs for each with an effective key strength peer.

   Depending on the media, creation of at least 128
   bits.

   Methods supporting key derivation MUST demonstrate cryptographic
   separation between a new unicast Secure Association
   SA may or may not imply deletion of a previous unicast secure
   association SA.  Where there is no implied deletion, the MSK
   authenticator may choose to limit Phase 2 (unicast and EMSK branches of multicast)
   Secure Association SAs for each peer.

6.6.  Impersonation

   Both the EAP key
   hierarchy.  Without violating RADIUS and Diameter protocols are potentially vulnerable to
   impersonation by a fundamental cryptographic assumption
   (such rogue authenticator.

   While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
   support mutual authentication between the authenticator (known as the non-invertibility of a one-way function) an attacker
   recovering
   AAA client) and the MSK or EMSK MUST NOT be able backend authentication server (known as the AAA
   server), the security mechanisms vary according to recover the other
   quantity with a level of effort less than brute force.

   Non-overlapping substrings of AAA protocol.

   In RADIUS, the MSK MUST be cryptographically
   separate from each other.  That is, knowledge of one substring MUST
   NOT help in recovering some other non-overlapping substring without
   breaking some hard cryptographic assumption.  This shared secret used for authentication is required
   because some existing ciphersuites form TSKs determined by simply splitting the
   AAA-Key to pieces of appropriate length.  Likewise, non-overlapping
   substrings of
   the EMSK MUST be cryptographically separate from each
   other, and from substrings source address of the MSK.

   The EMSK MUST remain on the EAP peer and EAP server where RADIUS packet.  As noted in [RFC3579]
   Section 4.3.7, it is
   derived; it MUST NOT highly desirable that the source address be transported to, or shared with, additional
   parties, or used for purposes other than AMSK derivation (see Section
   2.6).

   Since EAP does not provide for explicit key lifetime negotiation, EAP
   peers, authenticators and authentication servers MUST be prepared for
   situations in which
   checked against one of the parties discards key state which
   remains valid on another party.

   The development and validation of key derivation algorithms is
   difficult, and or more NAS identification attributes so as a result EAP methods SHOULD reuse well established
   and analyzed mechanisms for MSK to
   detect and EMSK key derivation (such as
   those specified in IKE [RFC2409] prevent impersonation attacks.

   When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or TLS [RFC2246]), rather than
   inventing new ones.

6.1.1.  Requirements for EAP methods

   In order for an EAP method
   NAS-IPv6-Address attributes may not correspond to meet the guidelines for EMSK usage it
   must meet source address.
   Since the following requirements:

      o It MUST specify how NAS-Identifier attribute need not contain an FQDN, it also
   may not correspond to derive the EMSK

      o The key material used for the EMSK source address, even indirectly.  [RFC2865]
   Section 3 states:

         A RADIUS server MUST be
        computationally independent use the source IP address of the MSK and TEKs.

      o The EMSK MUST NOT RADIUS
         UDP packet to decide which shared secret to use, so that
         RADIUS requests can be used proxied.

   This implies that it is possible for any other purpose than the key
        derivation described a rogue authenticator to forge
   NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
   a RADIUS Access-Request in this document.

      o The EMSK MUST be secret and not known order to impersonate another
   authenticator.  Among other things, this can result in messages (and
   MSKs) being sent to someone observing
        the authentication mechanism protocol exchange.

      o The EMSK MUST NOT be exported from the EAP server.
        Only keys (AMSKs) derived according wrong authenticator. Since the rogue
   authenticator is authenticated by the RADIUS proxy or server purely
   based on the source address, other mechanisms are required to this specification
        may be exported from detect
   the EAP server.

      o The EMSK MUST be unique for each session.

      o The EAP mechanism SHOULD a unique identifier suitable forgery.  In addition, it is possible for naming attributes such as the EMSK.

   Implementations
   Called-Station-Id and Calling-Station-Id to be forged as well.

   As recommended in [RFC3579], this vulnerability can be mitigated by
   having RADIUS proxies check authenticator identification attributes
   against the source address.

   To allow verification of EAP frameworks on session parameters such as the EAP-Peer Called-
   Station- Id and EAP-Server
   SHOULD provide an interface to obtain AMSKs.  The implementation MAY
   restrict which callers Calling-Station-Id, these can obtain which keys.

6.1.2.  Requirements for be sent by the EAP applications

   In order for an application peer
   to meet the guidelines for EMSK usage it
   must meet server, protected by the following requirements:

      o New applications following this specification SHOULD NOT use TEKs. The RADIUS server can then
   check the
        MSK.  If more than one application uses parameters sent by the MSK, then EAP peer against those claimed by
   the
        cryptographic separation authenticator.  If a discrepancy is not achieved.  Implementations SHOULD
        prevent such combinations.

      o A peer MUST NOT found, an error can be
   logged.

   While [RFC3588] requires use of the EMSK in any other way except to
        derive Application Master Session Keys (AMSKs) using Route-Record AVP, this utilizes
   FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
   RRs to be properly configured.  As a result, it appears that Diameter
   is as vulnerable to this attack as RADIUS, if not more so. To address
   this vulnerability, it is necessary to allow the
        key derivation specified backend
   authentication server to communicate with the authenticator directly,
   such as via the redirect functionality supported in Section 2.6. [RFC3588].

6.7.  Channel binding

   It MUST NOT
        use the EMSK directly is possible for cryptographic protection of data,
        and SHOULD provide only a compromised or poorly implemented EAP
   authenticator to communicate incorrect information to the AMSKs EAP peer
   and/or server. This may enable an authenticator to applications.

      o Applications MUST define distinct key labels, application
        specific data, and impersonate
   another authenticator or communicate incorrect information via out-
   of-band mechanisms (such as via AAA or the length of derived key material lower layer protocol).

   Where EAP is used in pass-through mode, the key
        derivation EAP peer typically does
   not verify the identity of the pass-through authenticator, it only
   verifies that the pass-through authenticator is trusted by the EAP
   server. This creates a potential security vulnerability, described in
   [RFC3748] Section 2.6.

      o Applications MUST define 7.15.

   [RFC3579] Section 4.3.7 describes how they use their AMSK to derive TSKs
        for their use.

6.2.  AAA Protocol Requirements

   AAA protocols suitable for use in transporting an EAP MUST provide pass-through
   authenticator acting as a AAA client can be detected if it attempts
   to impersonate another authenticator (such by sending incorrect NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
   [RFC3162] attributes via the
   following facilities:

Security services AAA protocols used protocol).  However, it is possible
   for transport of EAP keying material MUST
     implement and SHOULD use per-packet integrity and authentication,
     replay protection and confidentiality.  These requirements are met
     by Diameter EAP [I-D.ietf-aaa-eap], as well a pass-through authenticator acting as RADIUS over IPsec
     [RFC3579].

Session Keys a AAA protocols used for transport of EAP keying material MUST
     implement and SHOULD use dynamic key management in order client to derive
     fresh session keys, as in Diameter provide
   correct information to the AAA server while communicating misleading
   information to the EAP [I-D.ietf-aaa-eap] and
     RADIUS over IPsec [RFC3579], rather than using peer via a static key, as
     originally defined in RADIUS [RFC2865].

Mutual authentication
     AAA protocols used lower layer protocol.

   For example, it is possible for transport of a compromised authenticator to
   utilize another authenticator's Called-Station-Id or NAS-Identifier
   in communicating with the EAP keying material MUST
     provide peer via a lower layer protocol, or for mutual authentication between the
   a pass-through authenticator and
     backend authentication server.  These requirements are met by
     Diameter EAP [I-D.ietf-aaa-eap] as well acting as by RADIUS EAP [RFC3579].

Authorization a AAA protocols used for transport of EAP keying material SHOULD client to provide protection against rogue authenticators masquerading as
     other authenticators.  This can be accomplished, for example, by
     requiring that AAA agents check an
   incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the source address of packets
     against AAA
   server via the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier AAA protocol.

   As noted in RADIUS).  For details,
     see [RFC3579] [RFC3748] Section 4.3.7.

Key transport
     Since 7.15, this vulnerability can be
   addressed by use of EAP methods do not export Transient Session Keys (TSKs) that support a protected exchange of
   channel properties such as endpoint identifiers, including (but not
   limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
   [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865], and NAS-IPv6-Address [RFC3162].

   Using such a protected exchange, it is possible to match the channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  For example, see
   [ServiceIdent].

7.  Security Requirements

   This section summarizes the security requirements that must be met by
   EAP methods, AAA protocols,  Secure Association Protocols and
   Ciphersuites in order to maintain media and ciphersuite independence, address the AAA
     server security threats described in
   this document. These requirements MUST NOT transport TSKs from be met by specifications
   requesting publication as an RFC.  Each requirement provides a
   pointer to the backend authentication sections of this document describing the threat that
   it mitigates.

7.1.  EAP Method Requirements

   It is possible for the peer and EAP server to authenticator.

Key transport specification mutually authenticate
   and derive keys.  In order to enable backend authentication servers to provide keying material to the authenticator in a well defined format, AAA
     protocols suitable for use with in a
   subsequently negotiated ciphersuite, an EAP method supporting key
   derivation MUST define the format export a Master Session Key (MSK) of at least 64
   octets, and
     wrapping an Extended Master Session Key (EMSK) of the AAA-Token.

EMSK transport
     Since the EMSK is a secret known only to the backend at least 64
   octets.  EAP Methods deriving keys MUST provide for mutual
   authentication
     server between the EAP peer and peer, the AAA-Token EAP Server.

   The MSK and EMSK MUST NOT transport the EMSK from the
     backend authentication server be used directly to the authenticator.

AAA-Token protection
     To ensure against compromise, the AAA-Token MUST be integrity
     protected, authenticated, replay protected and encrypted in
     transit, using well-established cryptographic algorithms. protect data; however,
   they are of sufficient size to enable derivation of a AAA-Key
   subsequently used to derive Transient Session Keys
     The AAA-Token SHOULD be protected (TSKs) for use
   with session keys as in Diameter
     [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
     as in [RFC2548].

Key naming
     In order the selected ciphersuite.  Each ciphersuite is responsible for
   specifying how to ensure against confusion between derive the TSKs from the AAA-Key.

   The AAA-Key is derived from the appropriate keying material to be used in a given Secure Association Protocol
     exchange, exported by the AAA-Token SHOULD include explicit key names EAP
   method (MSK and
     context appropriate for informing EMSK).  This derivation occurs on the authenticator how AAA server.  In
   many existing protocols that use EAP, the keying
     material is to be used.

Key Compromise
     Where untrusted intermediaries AAA-Key and MSK are present, the AAA-Token
   equivalent, but more complicated mechanisms are possible (see Section
   2.3 for details).

   EAP methods SHOULD
     NOT be provided to ensure the intermediaries.  In Diameter, handling freshness of
     keys by intermediaries can be avoided using Redirect functionality
     [RFC3588].

6.3.  Secure Association Protocol Requirements

   The Secure Association Protocol supports the following:

Entity Naming
     The peer MSK and authenticator SHOULD identify themselves EMSK even in
   cases where one party may not have a manner
     that high quality random number
   generator.  A RECOMMENDED method is independent of their attached ports.

Mutual proof of possession
     The peer and authenticator MUST for each demo
nstrate possession party to provide a nonce
   of at least 128 bits, used in the
     keying material transported between the backend authentication
     server and authenticator (AAA-Key).

Key Naming
     The Secure Association Protocol MUST explicitly name derivation of the keys used
     in MSK and EMSK.

   EAP methods export the proof of possession exchange, MSK and EMSK and not Transient Session Keys so
   as to prevent confusion
     when more than one set allow EAP methods to be ciphersuite and media independent.
   Keying material exported by EAP methods MUST be independent of the
   ciphersuite negotiated to protect data.

   Depending on the lower layer, EAP methods may run before or after
   ciphersuite negotiation, so that the selected ciphersuite may not be
   known to the EAP method.  By providing keying material could potentially be usable with
   any ciphersuite, EAP methods can used
     as with a wide range of
   ciphersuites and media.

   It is RECOMMENDED that methods providing integrity protection of EAP
   packets include coverage of all the basis for EAP header fields, including the exchange.

Creation
   Code, Identifier, Length, Type and Deletion Type-Data fields.

   In order to preserve algorithm independence, EAP methods deriving
   keys SHOULD support (and document) the correct processing protected negotiation of phase 2 security
     associations, the Secure Association (phase 2) protocol MUST
     support
   ciphersuite used to protect the naming of phase 2 security associations and associated
     transient session keys, so that EAP conversation between the correct set of transient
     session keys can be identified for processing a given packet.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation and SHOULD support deletion, so that
     establishment peer and re-establishment of transient session keys can be
     synchronized
   server.  This is distinct from the ciphersuite negotiated between the parties.

Integrity
   peer and Replay Protection authenticator, used to protect data.

   The Secure Association Protocol MUST support integrity and replay
     protection strength of all messages.

Direct operation
     Since the phase 2 Secure Association Protocol Transient Session Keys (TSKs) used to protect data is concerned with
   ultimately dependent on the
     establishment strength of security associations between keys generated by the EAP peer and
     authenticator, including
   method.  If an EAP method cannot produce keying material of
   sufficient strength, then the TSKs may be subject to brute force
   attack.  In order to enable deployments requiring strong keys, EAP
   methods supporting key derivation SHOULD be capable of transient session keys,
     only those parties have "a need to know" the transient session
     keys. The Secure Association Protocol generating an
   MSK and EMSK, each with an effective key strength of at least 128
   bits.

   Methods supporting key derivation MUST operate directly demonstrate cryptographic
   separation between the peer and authenticator, MSK and EMSK branches of the EAP key
   hierarchy.  Without violating a fundamental cryptographic assumption
   (such as the non-invertibility of a one-way function) an attacker
   recovering the MSK or EMSK MUST NOT be passed-through able to recover the
     backend authentication server, or include additional parties.

Derivation other
   quantity with a level of transient session keys
     The Secure Association Protocol negotiation MUST support derivation effort less than brute force.

   Non-overlapping substrings of unicast and multicast transient session keys suitable for use
     with the negotiated ciphersuite.

TSK freshness
     The Secure Association (phase 2) Protocol MSK MUST support be cryptographically
   separate from each other.  That is, knowledge of one substring MUST
   NOT help in recovering some other non-overlapping substring without
   breaking some hard cryptographic assumption.  This is required
   because some existing ciphersuites form TSKs by simply splitting the
     derivation
   AAA-Key to pieces of fresh unicast appropriate length.  Likewise, non-overlapping
   substrings of the EMSK MUST be cryptographically separate from each
   other, and multicast transient session keys,
     even when from substrings of the keying material provided by MSK.

   The EMSK MUST remain on the backend
     authentication EAP peer and EAP server where it is
   derived; it MUST NOT be transported to, or shared with, additional
   parties, or used for purposes other than AMSK derivation (see Section
   2.4).

   Since EAP does not fresh.  This is typically supported by
     including an exchange provide for explicit key lifetime negotiation, EAP
   peers, authenticators and authentication servers MUST be prepared for
   situations in which one of nonces within the Secure Association
     Protocol.

Bi-directional operation
     While some ciphersuites only require a single set parties discards key state which
   remains valid on another party.

   The development and validation of transient
     session keys to protect traffic in both directions, other
     ciphersuites require key derivation algorithms is
   difficult, and as a unique set of transient session keys in each
     direction. The phase 2 Secure Association Protocol result EAP methods SHOULD provide reuse well established
   and analyzed mechanisms for the derivation of unicast MSK and multicast keys in each direction,
     so EMSK key derivation (such as not to require two separate phase 2 exchanges
   those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
   inventing new ones.

7.1.1.  Requirements for EAP methods

   In order for an EAP method to
     create a bi-directional phase 2 security association.

Secure capabilities negotiation
     The Secure Association Protocol meet the guidelines for EMSK usage it
   must meet the following requirements:

      o It MUST support secure capabilities
     negotiation.  This includes security parameters such as specify how to derive the
     security association identifier (SAID) and ciphersuites, as well as
     negotiation of EMSK

      o The key material used for the lifetime EMSK MUST be
        computationally independent of the TSKs, AAA-Key MSK and exported EAP
     keys.  Secure capabilities negotiation also includes confirmation
     of the capabilities discovered during the discovery phase (phase
     0), so as to ensure that the announced capabilities have not been
     forged.

Key Scoping TEKs.

      o The Secure Association Protocol EMSK MUST ensure NOT be used for any other purpose than the synchronization of key scope between the peer
        derivation described in this document.

      o The EMSK MUST be secret and authenticator.  This includes
     negotiation of restrictions on key usage.

6.4.  Ciphersuite Requirements

   Ciphersuites suitable for keying by EAP methods not known to someone observing
        the authentication mechanism protocol exchange.

      o The EMSK MUST provide NOT be exported from the
   following facilities:

TSK derivation
     In order to allow a ciphersuite EAP server.
        Only keys (AMSKs) derived according to this specification
        may be usable within exported from the EAP keying
     framework, a specification server.

      o The EMSK MUST be provided describing how
     transient session keys suitable unique for use with the ciphersuite are
     derived from the AAA-Key. each session.

      o The EAP method independence
     Algorithms mechanism SHOULD a unique identifier suitable for deriving transient session keys from naming the AAA-Key
     MUST NOT depend EMSK.

   Implementations of EAP frameworks on the EAP-Peer and EAP-Server
   SHOULD provide an interface to obtain AMSKs.  The implementation MAY
   restrict which callers can obtain which keys.

7.1.2.  Requirements for EAP method.  However, algorithms applications

   In order for
     deriving TEKs MAY be specific an application to meet the EAP method.

Cryptographic separation
     The TSKs derived from guidelines for EMSK usage it
   must meet the AAA-Key MUST be cryptographically
     separate from each other.  Similarly, TEKs MUST be
     cryptographically separate from each other.  In addition, following requirements:

      o New applications following this specification SHOULD NOT use the TSKs
        MSK.  If more than one application uses the MSK, then the
        cryptographic separation is not achieved.  Implementations SHOULD
        prevent such combinations.

      o A peer MUST be cryptographically separate from NOT use the TEKs.

7.  IANA Considerations

   This section provides guidance EMSK in any other way except to
        derive Application Master Session Keys (AMSKs) using the Internet Assigned Numbers
   Authority (IANA) regarding registration
        key derivation specified in Section 2.4.  It MUST NOT
        use the EMSK directly for cryptographic protection of values related data,
        and SHOULD provide only the AMSKs to EAP applications.

      o Applications MUST define distinct key
   management, in accordance with BCP 26, [RFC2434].

   The following terms are used here with labels, application
        specific data, and the meanings defined in BCP
   26: "name space", "assigned value", "registration".

   The following policies are length of derived key material used here with the meanings defined in BCP
   26: "Private Use", "First Come First Served", "Expert Review",
   "Specification Required", "IETF Consensus", "Standards Action".

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that any allocation will be
   accompanied by a published RFC.  But key
        derivation described in order Section 2.4.

      o Applications MUST define how they use their AMSK to allow derive TSKs
        for the
   allocation of values prior to the RFC being approved their use.

7.2.  AAA Protocol Requirements

   AAA protocols suitable for publication,
   the Designated Expert can approve allocations once it seems clear
   that an RFC will be published.  The Designated expert will post a
   request to the use in transporting EAP WG mailing list (or a successor designated by MUST provide the
   Area Director)
   following facilities:

Security services
     AAA protocols used for comment transport of EAP keying material MUST
     implement and review, including an Internet-Draft.
   Before a period SHOULD use per-packet integrity and authentication,
     replay protection and confidentiality.  These requirements are met
     by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
     [RFC3579].

Session Keys
     AAA protocols used for transport of 30 days has passed, the Designated Expert will
   either approve or deny the registration request EAP keying material MUST
     implement and publish SHOULD use dynamic key management in order to derive
     fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
     RADIUS over IPsec [RFC3579], rather than using a notice static key, as
     originally defined in RADIUS [RFC2865].

Mutual authentication
     AAA protocols used for transport of EAP keying material MUST
     provide for mutual authentication between the decision to the authenticator and
     backend authentication server.  These requirements are met by
     Diameter EAP WG mailing list or its successor, [I-D.ietf-aaa-eap] as well as informing IANA.  A denial notice must be justified by an
   explanation and, in the cases where it is possible, concrete
   suggestions on how the request can be modified so RADIUS EAP [RFC3579].

Authorization
     AAA protocols used for transport of EAP keying material SHOULD
     provide protection against rogue authenticators masquerading as to become
   acceptable.
     other authenticators.  This document introduces a new name space can be accomplished, for "key labels".  Key
   labels are ASCII strings and are assigned via IETF Consensus.  It is
   expected example, by
     requiring that key label specifications will include AAA agents check the following
   information:

        o A description source address of packets
     against the application
        o The key label origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier in RADIUS).  For details,
     see [RFC3579] Section 4.3.7.

Key transport
     Since EAP methods do not export Transient Session Keys (TSKs) in
     order to be used
        o How maintain media and ciphersuite independence, the AAA
     server MUST NOT transport TSKs will be derived from the AMSK backend authentication
     server to authenticator.

Key transport specification
     In order to enable backend authentication servers to provide keying
     material to the authenticator in a well defined format, AAA
     protocols suitable for use with EAP MUST define the format and how they will be used
        o If application specific data is used, what it
     wrapping of the AAA-Token.

EMSK transport
     Since the EMSK is a secret known only to the backend authentication
     server and how it is
           maintained
        o Where peer, the AMSKs AAA-Token MUST NOT transport the EMSK from the
     backend authentication server to the authenticator.

AAA-Token protection
     To ensure against compromise, the AAA-Token MUST be integrity
     protected, authenticated, replay protected and encrypted in
     transit, using well-established cryptographic algorithms.

Session Keys
     The AAA-Token SHOULD be protected with session keys as in Diameter
     [RFC3588] or TSKs will RADIUS over IPsec [RFC3579] rather than static keys,
     as in [RFC2548].

Key naming
     In order to ensure against confusion between the appropriate keying
     material to be used in a given Secure Association Protocol
     exchange, the AAA-Token SHOULD include explicit key names and
     context appropriate for informing the authenticator how they the keying
     material is to be used.

Key Compromise
     Where untrusted intermediaries are
          communicated if necessary.

8.  References

8.1.  Normative References

[RFC2119]
     Bradner, S., "Key words for use in RFCs present, the AAA-Token SHOULD
     NOT be provided to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[RFC2434]
     Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

8.2.  Informative References

[RFC0793]
     Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
     September 1981.

[RFC1661] Simpson, W., "The Point-to-Point the intermediaries.  In Diameter, handling of
     keys by intermediaries can be avoided using Redirect functionality
     [RFC3588].

7.3.  Secure Association Protocol (PPP)", STD 51, RFC
          1661, July 1994.

[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Requirements

   The Secure Association Protocol
          (ECP)", RFC 1968, June 1996.

[RFC2104] Krawczyk, H., Bellare,
 M. and R. Canetti, "HMAC: Keyed-Hashing
          for Message Authentication", RFC 2104, February 1997.

[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. supports the following:

Entity Naming
     The peer and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
          January 1999.

[RFC2401] Kent, S. authenticator SHOULD identify themselves in a manner
     that is independent of their attached ports.

Mutual proof of possession
     The peer and R. Atkinson, "Security Architecture for authenticator MUST each demonstrate possession of the
          Internet Protocol", RFC 2401, November 1998.

[RFC2409] Harkins, D.
     keying material transported between the backend authentication
     server and D. Carrel, "The Internet authenticator (AAA-Key).

Key Exchange (IKE)",
          RFC 2409, November 1998.

[RFC2419] Sklower, K. Naming
     The Secure Association Protocol MUST explicitly name the keys used
     in the proof of possession exchange, so as to prevent confusion
     when more than one set of keying material could potentially be used
     as the basis for the exchange.

Creation and G. Meyer, "The PPP DES Encryption Protocol,
          Version Deletion
     In order to support the correct processing of phase 2 (DESE-bis)", RFC 2419, September 1998.

[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
          RFC 2420, September 1998.

[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. security
     associations, the Secure Association (phase 2) protocol MUST
     support the naming of phase 2 security associations and
          R. Wheeler, "A Method associated
     transient session keys, so that the correct set of transient
     session keys can be identified for Transmitting PPP Over Ethernet
          (PPPoE)", RFC 2516, February 1999.

[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
          2548, March 1999.

[RFC2607] Aboba, B. processing a given packet.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation and J. Vollbrecht, "Proxy Chaining SHOULD support deletion, so that
     establishment and Policy
          Implementation in Roaming", RFC 2607, June 1999.

[RFC2716] Aboba, B. re-establishment of transient session keys can be
     synchronized between the parties.

Integrity and D. Simon, "PPP Replay Protection
     The Secure Association Protocol MUST support integrity and replay
     protection of all messages.

Direct operation
     Since the phase 2 Secure Association Protocol is concerned with the
     establishment of security associations between the EAP TLS Authentication Protocol",
          RFC 2716, October 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A. peer and W. Simpson, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
          (MPPE) Protocol", RFC 3078, March 2001.

[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
          Encryption (MPPE)", RFC 3079, March 2001.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
          In User Service) Support For Extensible Authentication
          Protocol (EAP)", RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
          "IEEE 802.1X Remote Authentication Dial In User Service
          (RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
          Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
          Keys Used For Exchanging Symmetric  Keys", RFC 3766, April
          2004.

[FIPSDES] National Institute
     authenticator, including the derivation of Standards transient session keys,
     only those parties have "a need to know" the transient session
     keys. The Secure Association Protocol MUST operate directly between
     the peer and Technology, "Data
          Encryption Standard", FIPS PUB 46, January 1977.

[DESMODES]
          National Institute of Standards authenticator, and Technology, "DES Modes MUST NOT be passed-through to the
     backend authentication server, or include additional parties.

Derivation of
          Operation", FIPS PUB 81, December 1980, <http://
          www.itl.nist.gov/fipspubs/fip81.htm>.

[IEEE802] Institute transient session keys
     The Secure Association Protocol negotiation MUST support derivation
     of Electrical unicast and Electronics Engineers, "IEEE
          Standards multicast transient session keys suitable for Local and Metropolitan Area Networks: Overview use
     with the negotiated ciphersuite.

TSK freshness
     The Secure Association (phase 2) Protocol MUST support the
     derivation of fresh unicast and Architecture", ANSI/IEEE Standard 802, 1990.

[IEEE80211]
          Institute of Electrical and Electronics Engineers,
          "Information technology - Telecommunications and information multicast transient session keys,
     even when the keying material provided by the backend
     authentication server is not fresh.  This is typically supported by
     including an exchange between systems - Local and metropolitan area
          networks - Specific Requirements Part 11:  Wireless LAN Medium
          Access Control (MAC) and Physical Layer (PHY) Specifications",
          IEEE IEEE Standard 802.11-1999, 1999.

[IEEE8021X]
          Institute of Electrical and Electronics Engineers, "Local and
          Metropolitan Area Networks: Port-Based Network Access
          Control", IEEE Standard 802.1X-2004, September 2004.

[IEEE8021Q]
          Institute nonces within the Secure Association
     Protocol.

Bi-directional operation
     While some ciphersuites only require a single set of Electrical and Electronics Engineers, "IEEE
          Standards for Local and Metropolitan Area Networks: Draft
          Standard for Virtual Bridged Local Area Networks", IEEE
          Standard 802.1Q/D8, January 1998.

[IEEE80211F]
          Institute transient
     session keys to protect traffic in both directions, other
     ciphersuites require a unique set of Electrical and Electronics Engineers,
          "Recommended Practice for Multi-Vendor Access Point
          Interoperability via an Inter-Access Point transient session keys in each
     direction. The phase 2 Secure Association Protocol Across
          Distribution Systems Supporting IEEE 802.11 Operation", IEEE
          802.11F, July 2003.

[IEEE80211i]
          Institute SHOULD provide
     for the derivation of Electrical unicast and Electronics Engineers, "Draft
          Supplement multicast keys in each direction,
     so as not to STANDARD FOR Telecommunications require two separate phase 2 exchanges in order to
     create a bi-directional phase 2 security association.

Secure capabilities negotiation
     The Secure Association Protocol MUST support secure capabilities
     negotiation.  This includes security parameters such as the
     security association identifier (SAID) and Information
          Exchange between Systems - LAN/MAN Specific Requirements -
          Part 11: Wireless Medium Access Control (MAC) and physical
          layer (PHY) specifications: Specification for Enhanced
          Security", IEEE Draft 802.11I/ D8, February 2004.

[IEEE-02-758]
          Mishra, A., Shin, M., Arbaugh, W., Lee, I. ciphersuites, as well as
     negotiation of the lifetime of the TSKs, AAA-Key and K. Jang,
          "Proactive Caching Strategies for IAPP Latency Improvement exported EAP
     keys.  Secure capabilities negotiation also includes confirmation
     of the capabilities discovered during 802.11 Handoff", IEEE 802.11 Working Group,
          IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.

[IEEE-03-084]
          Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
          "Proactive Key Distribution the discovery phase (phase
     0), so as to support fast and secure
          roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
          http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip,
          January 2003.

[IEEE-03-155]
          Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
          IEEE-03-155r0-I,  http://www.ieee802.org/11/
          Documents/DocumentHolder/3-155.zip, March 2003.

[I-D.ietf-roamops-cert]
          Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
          cert-02 (work in progress), April 1999.

[I-D.ietf-aaa-eap]
          Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
          Authentication ensure that the announced capabilities have not been
     forged.

Key Scoping
     The Secure Association Protocol (EAP) Application", draft-ietf-aaa-
          eap-08 (work in progress), June 2004.

[I-D.irtf-aaaarch-handoff]
          Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
          draft-irtf-aaaarch-handoff-04 (work in progress), October
          2003.

[I-D.puthenkulam-eap-binding]
          Puthenkulam, J., "The Compound Authentication Binding
          Problem", draft-puthenkulam-eap-binding-04 (work in progress),
          October 2003.

[I-D.aboba-802-context]
          Aboba, B. MUST ensure the synchronization of
     key scope between the peer and T. Moore, "A Model authenticator.  This includes
     negotiation of restrictions on key usage.

7.4.  Ciphersuite Requirements

   Ciphersuites suitable for Context Transfer in IEEE
          802", draft-aboba-802-context-03 (work in progress), October
          2003.

[I-D.arkko-pppext-eap-aka]
          Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
          arkko-pppext-eap-aka-11 (work in progress), October 2003.

[IKEv2]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
          ietf-ipsec-ikev2-14 (work in progress), June 2004.

[8021XHandoff]
          Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in keying by EAP methods MUST provide the
   following facilities:

TSK derivation
     In order to allow a
          Public Wireless LAN Based on IEEE 802.1X Model", School of
          Computer Science and Engineering, Seoul National University,
          Seoul, Korea, 2002.

[MD5Attack]
          Dobbertin, H., "The Status of MD5 After ciphersuite to be usable within the EAP keying
     framework, a Recent Attack",
          CryptoBytes, Vol.2 No.2, 1996.

[WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements specification MUST be provided describing how
     transient session keys suitable for Wireless LANs", draft-walker-ieee802-req-02.txt (work in
          progress), July 2004.

[Housley56]
          Housley, R., "Key Management in AAA", Presentation use with the ciphersuite are
     derived from the AAA-Key.

EAP method independence
     Algorithms for deriving transient session keys from the AAA-Key
     MUST NOT depend on the EAP method.  However, algorithms for
     deriving TEKs MAY be specific to the AAA
          WG at IETF 56,
          http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
          March 2003.

Acknowledgments

   Thanks EAP method.

Cryptographic separation
     The TSKs derived from the AAA-Key MUST be cryptographically
     separate from each other.  Similarly, TEKs MUST be
     cryptographically separate from each other.  In addition, the TSKs
     MUST be cryptographically separate from the TEKs.

8.  IANA Considerations

   This section provides guidance to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
   Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, and Russ
   Housley the Internet Assigned Numbers
   Authority (IANA) regarding registration of Vigil Security for useful feedback.

Author Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98
052

   EMail: bernarda@microsoft.com
   Phone: +1 values related to EAP key
   management, in accordance with BCP 26, [RFC2434].

   The following terms are used here with the meanings defined in BCP
   26: "name space", "assigned value", "registration".

   The following policies are used here with the meanings defined in BCP
   26: "Private Use", "First Come First Served", "Expert Review",
   "Specification Required", "IETF Consensus", "Standards Action".

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that any allocation will be
   accompanied by a published RFC.  But in order to allow for the
   allocation of values prior to the RFC being approved for publication,
   the Designated Expert can approve allocations once it seems clear
   that an RFC will be published.  The Designated expert will post a
   request to the EAP WG mailing list (or a successor designated by the
   Area Director) for comment and review, including an Internet-Draft.
   Before a period of 30 days has passed, the Designated Expert will
   either approve or deny the registration request and publish a notice
   of the decision to the EAP WG mailing list or its successor, as well
   as informing IANA.  A denial notice must be justified by an
   explanation and, in the cases where it is possible, concrete
   suggestions on how the request can be modified so as to become
   acceptable.

   This document introduces a new name space for "key labels".  Key
   labels are ASCII strings and are assigned via IETF Consensus.  It is
   expected that key label specifications will include the following
   information:

        o A description of the application
        o The key label to be used
        o How TSKs will be derived from the AMSK and how they will be used
        o If application specific data is used, what it is and how it is
           maintained
        o Where the AMSKs or TSKs will be used and how they are
          communicated if necessary.

9.  References

9.1.  Normative References

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

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998.

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

9.2.  Informative References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
          September 1981.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
          1661, July 1994.

[RFC1968] Meyer, G. and K. Fox, "The PPP Encryption Control Protocol
          (ECP)", RFC 1968, June 1996.

[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
          for Message Authentication", RFC 2104, February 1997.

[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
          and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
          January 1999.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
          Internet Protocol", RFC 2401, November 1998.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
          RFC 2409, November 1998.

[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
          Version 2 (DESE-bis)", RFC 2419, September 1998.

[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
          RFC 2420, September 1998.

[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.  and
          R. Wheeler, "A Method for Transmitting PPP Over Ethernet
          (PPPoE)", RFC 2516, February 1999.

[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
          2548, March 1999.

[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
          Implementation in Roaming", RFC 2607, June 1999.

[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
          RFC 2716, October 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
          (MPPE) Protocol", RFC 3078, March 2001.

[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
          Encryption (MPPE)", RFC 3079, March 2001.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
          In User Service) Support For Extensible Authentication
          Protocol (EAP)", RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
          "IEEE 802.1X Remote Authentication Dial In User Service
          (RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
          Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
          Keys Used For Exchanging Symmetric  Keys", RFC 3766, April
          2004.

[FIPSDES] National Institute of Standards and Technology, "Data
          Encryption Standard", FIPS PUB 46, January 1977.

[DESMODES]
          National Institute of Standards and Technology, "DES Modes of
          Operation", FIPS PUB 81, December 1980, <http://
          www.itl.nist.gov/fipspubs/fip81.htm>.

[IEEE802] Institute of Electrical and Electronics Engineers, "IEEE
          Standards for Local and Metropolitan Area Networks: Overview
          and Architecture", ANSI/IEEE Standard 802, 1990.

[IEEE80211]
          Institute of Electrical and Electronics Engineers,
          "Information technology - Telecommunications and information
          exchange between systems - Local and metropolitan area
          networks - Specific Requirements Part 11:  Wireless LAN Medium
          Access Control (MAC) and Physical Layer (PHY) Specifications",
          IEEE IEEE Standard 802.11-2003, 2003.

[IEEE8021X]
          Institute of Electrical and Electronics Engineers, "Local and
          Metropolitan Area Networks: Port-Based Network Access
          Control", IEEE Standard 802.1X-2004, December 2004.

[IEEE8021Q]
          Institute of Electrical and Electronics Engineers, "IEEE
          Standards for Local and Metropolitan Area Networks: Draft
          Standard for Virtual Bridged Local Area Networks", IEEE
          Standard 802.1Q/D8, January 1998.

[IEEE80211F]
          Institute of Electrical and Electronics Engineers,
          "Recommended Practice for Multi-Vendor Access Point
          Interoperability via an Inter-Access Point Protocol Across
          Distribution Systems Supporting IEEE 802.11 Operation", IEEE
          802.11F, July 2003.

[IEEE80211i]
          Institute of Electrical and Electronics Engineers, "Supplement
          to STANDARD FOR Telecommunications and Information Exchange
          between Systems - LAN/MAN Specific Requirements - Part 11:
          Wireless Medium Access Control (MAC) and physical layer (PHY)
          specifications: Specification for Enhanced Security", IEEE
          802.11i, December 2004.

[IEEE-02-758]
          Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
          "Proactive Caching Strategies for IAPP Latency Improvement
          during 802.11 Handoff", IEEE 802.11 Working Group,
          IEEE-02-758r1-F Draft 802.11I/D5.0, November 2002.

[IEEE-03-084]
          Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang,
          "Proactive Key Distribution to support fast and secure
          roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I,
          http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip,
          January 2003.

[IEEE-03-155]
          Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working Group,
          IEEE-03-155r0-I,  http://www.ieee802.org/11/
          Documents/DocumentHolder/3-155.zip, March 2003.

[I-D.ietf-roamops-cert]
          Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
          cert-02 (work in progress), April 1999.

[I-D.ietf-aaa-eap]
          Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
          Authentication Protocol (EAP) Application", draft-ietf-aaa-
          eap-10 (work in progress), November 2004.

[I-D.irtf-aaaarch-handoff]
          Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
          draft-irtf-aaaarch-handoff-04 (work in progress), October
          2003.

[I-D.puthenkulam-eap-binding]
          Puthenkulam, J., "The Compound Authentication Binding
          Problem", draft-puthenkulam-eap-binding-04 (work in progress),
          October 2003.

[I-D.aboba-802-context]
          Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE
          802", draft-aboba-802-context-03 (work in progress), October
          2003.

[I-D.arkko-pppext-eap-aka]
          Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-
          arkko-pppext-eap-aka-15.txt (work in progress), December 2004.

[IKEv2]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
          ietf-ipsec-ikev2-17 (work in progress), September 2004.

[8021XHandoff]
          Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a
          Public Wireless LAN Based on IEEE 802.1X Model", School of
          Computer Science and Engineering, Seoul National University,
          Seoul, Korea, 2002.

[MD5Attack]
          Dobbertin, H., "The Status of MD5 After a Recent Attack",
          CryptoBytes, Vol.2 No.2, 1996.

[WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
          for Wireless LANs", draft-walker-ieee802-req-04.txt (work in
          progress), August 2004.

[Housley56]
          Housley, R., "Key Management in AAA", Presentation to the AAA
          WG at IETF 56,
          http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
          March 2003.

Acknowledgments

   Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft,
   Dorothy Stanley of Agere, Bob Moskowitz of TruSecure, Jesse Walker of
   Intel, Joe Salowey of Cisco and Russ Housley of Vigil Security for
   useful feedback.

Author Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: bernarda@microsoft.com
   Phone: +1 425 706 6605
   Fax:   +1 425 936 7329

   Dan Simon
   Microsoft Research
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: dansimon@microsoft.com
   Phone: +1 425 706 6711
   Fax:   +1 425 936 7329

   Jari Arkko
   Ericsson
   Jorvas 02420
   Finland

   Phone:
   EMail: jari.arkko@ericsson.com

   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

   EMail: pasi.eronen@nokia.com

   Henrik Levkowetz (editor)
   ipUnplugged AB
   Arenavagen 27
   Stockholm  S-121 28
   SWEDEN

   Phone: +46 708 32 16 08
   EMail: henrik@levkowetz.com 16 08
   EMail: henrik@levkowetz.com

Appendix A - Ciphersuite Keying Requirements

   To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
   EAP.  This Appendix describes the keying requirements of common PPP
   and 802.11 ciphersuites.

   PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
   [RFC3078].  The DES algorithm is described in [FIPSDES], and DES
   modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in
   [RFC2420]) are described in [DESMODES].  For PPP DESEbis, a single
   56-bit encryption key is required, used in both directions. For PPP
   3DES, a 168-bit encryption key is needed, used in both directions. As
   described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV,
   which is different in each direction, is "deduced from an explicit
   64-bit nonce, which is exchanged in the clear during the [ECP]
   negotiation phase."  There is therefore no need for the IV to be
   provided by EAP.

   For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in
   each direction, as described in [RFC3078]. No initialization vector
   is required.

   While these PPP ciphersuites provide encryption, they do not provide
   per-packet authentication or integrity protection, so an
   authentication key is not required in either direction.

   Within [IEEE80211], Transient Session Keys (TSKs) are required both
   for unicast traffic as well as for multicast traffic, and therefore
   separate key hierarchies are required for unicast keys and multicast
   keys. IEEE 802.11 ciphersuites include WEP-40, described in
   [IEEE80211], which requires a 40-bit encryption key, the same in
   either direction; and WEP-128, which requires a 104-bit encryption
   key, the same in either direction.  These ciphersuites also do not
   support per-packet authentication and integrity protection.  In
   addition to these unicast keys, authentication and encryption keys
   are required to wrap the multicast encryption key.

   Recently, new ciphersuites have been proposed for use with IEEE
   802.11 that provide per-packet authentication and integrity
   protection as well as encryption [IEEE80211i].  These include TKIP,
   which requires a single 128-bit encryption key and two 64-bit
   authentication keys (one for each direction); and AES CCMP, which
   requires a single 128-bit key (used in both directions) in order to
   authenticate and encrypt data.

   As with WEP, authentication and encryption keys are also required to
   wrap the multicast encryption (and possibly, authentication) keys.

Appendix B - Transient EAP Key (TEK) Hierarchy

   Figure B-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
   which is based on the TLS key hierarchy described in [RFC2246].  The
   TLS-negotiated ciphersuite is used to set up a protected channel for
   use in protecting the EAP conversation,  keyed by the derived TEKs.
   The TEK derivation proceeds as follows:

   master_secret = TLS-PRF-48(pre_master_secret, "master secret",
                   client.random || server.random)
   TEK           = TLS-PRF-X(master_secret, "key expansion",
                   server.random || client.random)
   Where:
   TLS-PRF-X =     TLS pseudo-random function defined in [RFC2246],
                   computed to X octets.

          |                       |                           |
          |                       | pre_master_secret         |
    server|                       |                           | client
    Random|                       V                           | Random
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |     |                                     |       |
          |     |                                     |       |
          +---->|             master_secret           |<------+
          |     |               (TMS)                 |       |
          |     |                                     |       |
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |                       |                           |
          |                       |                           |
          |                       |                           |
          V                       V                           V
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                                                               |
    |                         Key Block                             |
    |                          (TEKs)                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           |           |           |           |           |
      | client    | server    | client    | server    | client    | server
      | MAC       | MAC       | write     | write     | IV        | IV
      |           |           |           |           |           |
      V           V           V           V           V           V

   Figure B-1 - TLS [RFC2246] Key Hierarchy

Appendix C - EAP-TLS Key Hierarchy

   In EAP-TLS [RFC2716], the MSK is divided into two halves,
   corresponding to the "Peer to Authenticator Encryption Key" (Enc-
   RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
   Peer Encryption Key" (Enc-SEND-Key, 32 octets).  In [RFC2548], the
   Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
   attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
   Key attribute.

   The EMSK is also divided into two halves, corresponding to the "Peer
   to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
   "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
   octets).  The IV is a 64 octet quantity that is a known value; octets
   0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
   Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.

   In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
   secret via a one-way function. This ensures that the TLS master
   secret cannot be derived from the MSK, EMSK or IV unless the one-way
   function (TLS PRF) is broken.  Since the MSK is derived from the the
   TLS master secret, if the TLS master secret is compromised then the
   MSK is also compromised.

   As described in [RFC2716], the formula for the derivation of the MSK,
   EMSK and IV is as follows:

   MSK           = TLS-PRF-64(TMS, "client EAP encryption",
                      client.random || server.random)
   EMSK          = second 64 octets of:
                   TLS-PRF-128(TMS, "client EAP encryption",
                      client.random || server.random)
   IV            = TLS-PRF-64("", "client EAP encryption",
                      client.random || server.random)

   AAA-Key(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
                   (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
                   PMK.
   AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
                   (MS-MPPE-Send-Key in [RFC2548])
   EMSK(0,31)    = Peer to Authenticator Authentication Key (Auth-RECV-Key)
   EMSK(32,63)   = Authenticator to Peer Authentication Key (Auth-Send-Key)
   IV(0,31)      = Peer to Authenticator Initialization Vector (RECV-IV)
   IV(32,63)     = Authenticator to Peer Initialization vector (SEND-IV)

   Where:

   AAA-Key(W,Z)  = Octets W through Z includes of the AAA-Key.
   IV(W,Z)       = Octets W through Z inclusive of the IV.
   MSK(W,Z)      = Octets W through Z inclusive of the MSK.
   EMSK(W,Z)     = Octets W through Z inclusive of the EMSK.
   TMS           = TLS master_secret
   TLS-PRF-X     = TLS PRF function defined in [RFC2246] computed to X octets
   client.random = Nonce generated by the TLS client.
   server.random = Nonce generated by the TLS server.

   Figure C-1 describes the process by which the MSK,EMSK,IV and
   ultimately the TSKs, are derived from the TLS Master Secret.

                                                                       ---+
                                 |                                        ^
                                 | TLS Master Secret (TMS)                |
                                 |                                        |
                                 V                                        |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
               |                                     |            EAP     |
               |       Master Session Key (MSK)      |           Method   |
               |              Derivation             |                    |
               |                                     |                    V
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             EAP ---+
                 |               |                 |               API    ^
                 | MSK           | EMSK            | IV                   |
                 |               |                 |                      |
                 V               V                 V                      v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+
   |                                                             |        |
   |                                                             |        |
   |             backend authentication server                   |        |
   |                                                             |        |
   |                                                             |        V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+
     |                 |                                                  ^
     | AAA-Key(0,31)   | AAA-Key(32,63)                                       |
     | (PMK)           |                                     Transported  |
     |                 |                                        via AAA   |
     |                 |                                                  |
     V                 V                                                  V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+
   |                                                               |      ^
   |                Ciphersuite-Specific Transient Session         | Auth.|
   |                       Key Derivation                          |      |
   |                                                               |      V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+

   Figure C-1 - EAP TLS [RFC2716] Key hierarchy

Appendix A D - Ciphersuite Keying Requirements

   To date, PPP and Example Transient Session Key (TSK) Derivation

   Within IEEE 802.11 ciphersuites are suitable for keying by
   EAP.  This Appendix describes RSN, the keying requirements of common PPP
   and 802.11 ciphersuites.

   PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
   [RFC3078].  The DES algorithm is described in [FIPSDES], and DES
   modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in
   [RFC2420]) are described in [DESMODES].  For PPP DESEbis, a single
   56-bit encryption key is required, used in both directions. For PPP
   3DES, Pairwise Transient Key (PTK), a 168-bit encryption transient
   session key is needed, used in both directions. As
   described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV,
   which is different in each direction, to protect unicast traffic, is "deduced derived from an explicit
   64-bit nonce, which is exchanged in the clear during the [ECP]
   negotiation phase."  There is therefore no need for PMK
   (octets 0-31 of the IV to be
   provided by EAP.

   For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required MSK), known in
   each direction, [RFC2716] as described in [RFC3078]. No initialization vector
   is required.

   While these PPP ciphersuites provide encryption, they do not provide
   per-packet authentication or integrity protection, so an
   authentication key the Peer to
   Authenticator Encryption Key.  In [IEEE80211i],  the PTK is not required in either direction.

   Within [IEEE80211], Transient Session Keys (TSKs) are required both
   for unicast traffic as well as for multicast traffic, and therefore
   separate derived
   from the PMK via the following formula:

   PTK = EAPOL-PRF-X(PMK, "Pairwise key hierarchies are required for unicast keys expansion", Min(AA,SA) ||
         Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

   Where:

   PMK             = AAA-Key(0,31)
   SA              = Station MAC address (Calling-Station-Id)
   AA              = Access Point MAC address (Called-Station-Id)
   ANonce          = Access Point Nonce
   SNonce          = Station Nonce
   EAPOL-PRF-X     = Pseudo-Random Function based on HMAC-SHA1, generating
                     a PTK of size X octets.

   TKIP uses X = 64, while CCMP, WRAP, and multicast
   keys. IEEE 802.11 ciphersuites include WEP-40, described WEP use X = 48.

   The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
   authenticity in
   [IEEE80211], which requires a 40-bit encryption key, the same in
   either direction; and WEP-128, which requires a 104-bit encryption
   key, TSK derivation. It utilizes the same first 128 bits
   (bits 0-127) of the PTK.  The EAPOL-Key Encryption Key (KEK) provides
   confidentiality in either direction.  These ciphersuites also do not
   support per-packet authentication and integrity protection.  In
   addition to these unicast keys, authentication the TSK derivation.  It utilizes bits 128-255 of
   the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and encryption keys Bits
   384-511 are required to wrap the multicast encryption key.

   Recently, new ciphersuites have been proposed for use with IEEE
   802.11 that provide per-packet authentication used by Temporal Key 2.  Usage of TK1 and integrity
   protection as well as encryption TK2 is
   ciphersuite specific. Details are available in [IEEE80211i].  These include TKIP,
   which requires a single 128-bit encryption key and two 64-bit
   authentication keys (one for each direction);

Appendix E - Key Names and AES CCMP, which
   requires a single 128-bit Scope in Existing Methods

   This appendix specifies the key (used names and scope in both directions) methods that have
   been published prior to the publication of this RFC.  What is needed
   in order addition to
   authenticate the rules in Section 2.4 is the definition of what EAP
   peer and encrypt data.

   As with WEP, authentication server names are used, what Method-Id is used, and encryption keys how these
   are also required to
   wrap encoded.

EAP-TLS

   The EAP-TLS Method-Id is provided by the concatenation of the peer
   and server nonces.

   Where certificates are used, the Session-Id scope is determined via
   the multicast encryption (and possibly, authentication) keys.

Appendix B - Transient EAP Key (TEK) Hierarchy

   Figure B-1 illustrates peer and server names, deduced from the TEK altSubjectName in the
   peer and server certificates.

   Issue: What happens if a pre-shaked key hierarchy for EAP-TLS [RFC2716],
   which ciphersuite is based on negotiated?
   How are the TLS key hierarchy described EAP peer and server names determined?

EAP-AKA

   The EAP-AKA Method-Id is the contents of the RAND field from the
   AT_RAND attribute, followed by the contents of the AUTN field in [RFC2246]. the
   AT_AUTN attribute.

   The
   TLS-negotiated ciphersuite EAP peer name is the contents of the Identity field from the
   AT_IDENTITY attribute, using only the Actual Identity Length octets
   from the beginning, however.  Note that the contents are used to set up as they
   are transmitted, regardless of whether the transmitted identity was a protected channel for
   use
   permanent, pseudonym, or fast reauthentication identity.  The EAP
   server name is an empty string.

EAP-SIM

   The Method-Id is the contents of the RAND field from the AT_RAND
   attribute, followed by the contents of the NONCE_MT field in protecting the
   AT_NONCE_MT attribute.

   The EAP conversation,  keyed by peer name is the derived TEKs.
   The TEK derivation proceeds contents of the Identity field from the
   AT_IDENTITY attribute, using only the Actual Identity Length octets
   from the beginning, however.  Note that the contents are used as follows:

   master_secret = TLS-PRF-48(pre_master_secret, "master secret",
                   client.random || server.random)
   TEK           = TLS-PRF-X(master_secret, "key expansion",
                   server.random || client.random)
   Where:
   TLS-PRF-X =     TLS pseudo-random function defined in [RFC2246],
                   computed to X octets.

          |                       |                           |
          |                       | pre_master_secret         |
    server|                       |                           | client
    Random|                       V                           | Random
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |     |                                     |       |
          |     |                                     |       |
          +---->|             master_secret           |<------+
          |     |               (TMS)                 |       |
          |     |                                     |       |
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |                       |                           |
          |                       |                           |
          |                       |                           |
          V                       V                           V
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                                                               |
    |                         Key Block                             |
    |                          (TEKs)                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           |           |           |           |           |
      | client    | server    | client    | server    | client    | they
   are transmitted, regardless of whether the transmitted identity was a
   permanent, pseudonym, or fast reauthentication identity.  The EAP
   server
      | MAC       | MAC       | write     | write     | IV        | IV
      |           |           |           |           |           |
      V           V           V           V           V           V

   Figure B-1 - TLS [RFC2246] Key Hierarchy name is an empty string.

Appendix C F - Security Association Examples

EAP Method SA Example: EAP-TLS Key Hierarchy

   In EAP-TLS [RFC2716], after the MSK is divided into two halves,
   corresponding to the "Peer to Authenticator Encryption Key" (Enc-
   RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
   Peer Encryption Key" (Enc-SEND-Key, 32 octets).  In [RFC2548], the
   Enc-RECV-Key (the PMK) is transported in EAP authentication the MS-MPPE-Recv-Key
   attribute, client (peer)
   and server can store the Enc-SEND-Key is transported in following information:

      o  Implicitly, the MS-MPPE-Send-
   Key attribute.

   The EMSK is also divided into two halves, corresponding EAP method this SA refers to (EAP-TLS)
      o  Session identifier (a value selected by the "Peer
   to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) server)
      o  Certificate of the other party (server stores the client's
         certificate and
   "Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
   octets).  The IV is a 64 octet quantity vice versa)
      o  Ciphersuite and compression method
      o  TLS Master secret (known as the EAP-TLS Master Key)
      o  SA lifetime (ensuring that the SA is a known value; octets
   0-31 are known as not stored forever)
      o  If the "Peer to Authenticator IV" or RECV-IV, client has multiple different credentials (certificates
         and
   Octets 32-63 are known as the "Authenticator corresponding private keys), a pointer to Peer IV", or SEND-IV.

   In those credentials

   When the server initiates EAP-TLS, the MSK, EMSK and IV are derived from client can look up the TLS master
   secret via a one-way function. This ensures that EAP-TLS
   SA based on the TLS master
   secret cannot be derived from credentials it was going to use (certificate and
   private key), and the MSK, EMSK expected credentials (certificate or IV unless the one-way
   function (TLS PRF) is broken.  Since name) of
   the MSK server. If an EAP-TLS SA exists, and it is derived from the not too old, the
   TLS master secret, if
   client informs the TLS master secret is compromised then server about the
   MSK is also compromised.

   As described existence of this SA by including
   its Session-Id in [RFC2716], the formula for TLS ClientHello message. The server then looks
   up the derivation of correct SA based on the MSK,
   EMSK and IV is as follows:

   MSK           = TLS-PRF-64(TMS, "client Session-Id (or detects that it doesn't
   yet have one).

EAP encryption",
                      client.random || server.random)
   EMSK          = second 64 octets of:

             TLS-PRF-128(TMS, "client Method SA Example: EAP-AKA

   In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP encryption",
                      client.random || server.random)
   IV            = TLS-PRF-64("", "client authentication the
   client and server can store the following information:

      o  Implicitly, the EAP encryption",
                      client.random || server.random)

   AAA-Key(0,31) = Peer method this SA refers to Authenticator (EAP-AKA)
      o  A re-authentication pseudonym
      o  The client's permanent identity (IMSI)
      o  Replay protection counter
      o  Authentication key (K_aut)
      o  Encryption key (K_encr)
      o  Original Master Key (Enc-RECV-Key)
                   (MS-MPPE-Recv-Key in [RFC2548]).  Also known as (MK)
      o  SA lifetime (ensuring that the
                   PMK.
   AAA-Key(32,63)= Authenticator to Peer Encryption Key (Enc-SEND-Key)
                   (MS-MPPE-Send-Key in [RFC2548])
   EMSK(0,31)    = Peer to Authenticator Authentication Key (Auth-RECV-Key)
   EMSK(32,63)   = Authenticator to Peer Authentication Key (Auth-Send-Key)
   IV(0,31)      = Peer to Authenticator Initialization Vector (RECV-IV)
   IV(32,63)     = Authenticator to Peer Initialization vector (SEND-IV)

   Where:

   AAA-Key(W,Z)  = Octets W through Z includes of SA is not stored forever)

   When the AAA-Key.
   IV(W,Z)       = Octets W through Z inclusive of server initiates EAP-AKA, the IV.
   MSK(W,Z)      = Octets W through Z inclusive of client can look up the MSK.
   EMSK(W,Z)     = Octets W through Z inclusive of EAP-AKA
   SA based on the EMSK.
   TMS           = TLS master_secret
   TLS-PRF-X     = TLS PRF function defined in [RFC2246] computed credentials it was going to X octets
   client.random = Nonce generated by use (permanent identity).
   If an EAP-AKA SA exists, and it is not too old, the TLS client.
   server.random = Nonce generated by client informs
   the TLS server.

   Figure C-1 describes server about the process existence of this SA by which sending its re-
   authentication pseudonym as its identity in EAP Identity Response
   message, instead of its permanent identity. The server then looks up
   the MSK,EMSK,IV correct SA based on this identity.

AAA SA Example: RADIUS

   In RADIUS, where shared secret authentication is used, the client and
   server store each other's IP address and
   ultimately the TSKs, are derived from shared secret, which is
   used to calculate the TLS Master Secret.

                                                                       ---+
                                 |                                        ^
                                 | TLS Master Secret (TMS)                |
                                 |                                        |
                                 V                                        |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    |
               |                                     |            EAP     |
               |       Master Session Key (MSK)      |           Method   |
               |              Derivation             |                    |
               |                                     |                    V
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             EAP ---+
                 |               |                 |               API    ^
                 | MSK           | EMSK            | IV                   |
                 |               |                 |                      |
                 V               V                 V                      v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+
   |                                                             |        |
   |                                                             |        |
   |             backend authentication server                   |        |
   |                                                             |        |
   |                                                             |        V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     ---+
     |                 |                                                  ^
     | AAA-Key(0,31)   | AAA-Key(32,63)                                       |
     | (PMK)           |                                     Transported  |
     |                 |                                        via AAA   |
     |                 |                                                  |
     V                 V                                                  V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+
   |                                                               |      ^
   |                Ciphersuite-Specific Transient Session         | Auth.|
   |                       Key Derivation                          |      |
   |                                                               |      V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---+

   Figure C-1 - EAP TLS [RFC2716] Key hierarchy

Appendix D - Example Transient Session Key (TSK) Derivation

   Within IEEE 802.11 RSN, Response Authenticator [RFC2865] and Message-
   Authenticator [RFC3579] values, and to encrypt some attributes (such
   as the Pairwise Transient Key (PTK), a transient
   session key AAA-Key, see [RFC3580] Section 3.16).

   Where IPsec is used to protect unicast traffic, RADIUS [RFC3579] and IKE is derived from used for
   key management, the PMK
   (octets 0-31 of parties store information necessary to
   authenticate and authorize the MSK), known other party (e.g. certificates, trust
   anchors and names). The IKE exchange results in [RFC2716] as the Peer IKE Phase 1 and Phase
   2 SAs containing information used to
   Authenticator Encryption Key.  In [IEEE80211i], protect the PTK is derived
   from conversation
   (session keys, selected ciphersuite, etc.)

AAA SA Example: Diameter with TLS

   When using Diameter protected by TLS, the PMK via parties store information
   necessary to authenticate and authorize the following formula:

   PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
         Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))

   Where:

   PMK             = AAA-Key(0,31)
   SA              = Station MAC address (Calling-Station-Id)
   AA              = Access Point MAC address (Called-Station-Id)
   ANonce          = Access Point Nonce
   SNonce          = Station Nonce
   EAPOL-PRF-X     = Pseudo-Random Function based on HMAC-SHA1, generating
                     a PTK of size X octets.

   TKIP uses X = 64, while CCMP, WRAP, other party (e.g.
   certificates, trust anchors and WEP use X = 48. names). The EAPOL-Key Confirmation TLS handshake results in
   a short-term TLS SA that contains information used to protect the
   actual communications (session keys, selected TLS ciphersuite, etc.).

Service SA Example: 802.11i

   [IEEE802.11i] Section 8.4.1.1 defines the security associations used
   within IEEE 802.11.  A summary follows; the standard should be
   consulted for details.

   o Pairwise Master Key (KCK) Security Association (PMKSA)

      The PMKSA is a bi-directional SA, used to provide data origin
   authenticity in by both parties for sending
      and receiving.  The PMKSA is the TSK derivation. Root Service SA.  It utilizes the first 128 bits
   (bits 0-127) of is created
      on the PTK. peer when EAP authentication completes successfully or a
      pre-shared key is configured.  The EAPOL-Key Encryption Key (KEK) provides
   confidentiality in PMKSA is created on the TSK derivation.  It utilizes bits 128-255 of
      authenticator when the PTK. Bits 256-383 of PMK is received or created on the PTK are
      authenticator or a pre-shared key is configured.  The PMKSA is
      used by Temporal Key 1, and Bits
   384-511 to create the PTKSA.  PMKSAs are used by Temporal Key 2.  Usage cached for their lifetimes.
      The PMKSA consists of TK1 and TK2 is
   ciphersuite specific. Details are available in [IEEE80211i].

Appendix E the following elements:

      - PMKID (security association identifier)
      - Authenticator MAC address
      - PMK
      - Lifetime
      - Authenticated Key Names and Scope in Existing Methods Management Protocol (AKMP)
      - Authorization parameters specified by the AAA server or
        by local configuration.  This appendix specifies can include
        parameters such as the key names and scope in methods that have
   been published prior to peer's authorized SSID.

        On the publication of peer, this RFC.  What is needed
   in addition information can be locally
        configured.
      - Key replay counters (for EAPOL-Key messages)
      - Reference to the rules in Section 2.4 is the definition of what EAP
   peer and server names are used, what Method-Id is used, and how these
   are encoded.

EAP-TLS

   The EAP-TLS Method-Id PTKSA (if any), needed to:
          o delete it (e.g. AAA server-initiated disconnect)
          o replace it when a new four-way handshake is provided by done
      - Reference to accounting context, the concatenation details of which depend
        on the peer
   and server nonces.

   Where certificates are accounting protocol used, the Session-Id scope is determined via
   the EAP peer implementation
        and server names, deduced from the altSubjectName in the
   peer administrative details. In RADIUS, this could include
        (e.g. packet and server certificates.

   Issue: What happens if a pre-shaked key ciphersuite is negotiated?
   How are the EAP peer octet counters, and server names determined?

EAP-AKA Acct-Multi-Session-Id).

   o Pairwise Transient Key Security Association (PTKSA)

      The EAP-AKA Method-Id PTKSA is a bi-directional SA created as the contents of the RAND field from the
   AT_RAND attribute, followed by the contents result of the AUTN field in the
   AT_AUTN attribute. a
      successful four-way handshake.  The EAP peer name PTKSA is a unicast service SA.
      There may only be one PTKSA between a pair of peer and
      authenticator MAC addresses.  PTKSAs are cached for the contents lifetime
      of the Identity field from PMKSA.  Since the
   AT_IDENTITY attribute, using PTKSA is tied to the PMKSA, it only has
      the Actual Identity Length octets additional information from the beginning, however.  Note that 4-way handshake.  The PTKSA
      consists of the contents are used as they
   are transmitted, regardless following:

         - Key (PTK)
         - Selected ciphersuite
         - MAC addresses of whether the transmitted identity was a
   permanent, pseudonym, or fast reauthentication identity.  The EAP
   server name parties
         - Replay counters, and ciphersuite specific state
         - Reference to PMKSA: This is an empty string.

EAP-SIM needed when:
            o A new four-way handshake is needed (lifetime, TKIP
              countermeasures), and we need to know which PMKSA to use

   o Group Transient Key Security Association (GTKSA)

      The Method-Id GTKSA is a uni-directional SA created based on the contents of the RAND field from the AT_RAND
   attribute, followed by four-way
      handshake or the contents group key handshake. The GTKSA is a multicast
      service SA.  A GTKSA consists of the NONCE_MT field in following:

         - Direction vector (whether the
   AT_NONCE_MT attribute.

   The EAP peer name GTK is the contents used for transmit or receive)
         - Group cipher suite selector
         - Key (GTK)
         - Authenticator MAC address
         - Via reference to PMKSA, or copied here:
           o Authorization parameters
           o Reference to accounting context

   Service SA Example: IKEv2/IPsec

      Note that this example is intended to be informative, and it does
      not necessarily include all information stored.

   o IKEv2 SA

      - Protocol version
      - Identities of the Identity field from the
   AT_IDENTITY attribute, using only parties
      - IKEv2 SPIs
      - Selected ciphersuite
      - Replay protection counters (Message ID)
      - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
      - Key for deriving keys for IPsec SAs (SK_d)
      - Lifetime information
      - On the Actual Identity Length octets authenticator, service authorization information
        received from the beginning, however.  Note that backend authentication server.

   When processing an incoming message, the contents are used as they
   are transmitted, regardless of whether correct SA is looked up
   based on the transmitted identity was a
   permanent, pseudonym, SPIs.

   o IPsec SAs/SPD

      - Traffic selectors
      - Replay protection counters
      - Selected ciphersuite
      - IPsec SPI
      - Keys
      - Lifetime information
      - Protocol mode (tunnel or fast reauthentication identity. transport)

      The EAP
   server name correct SA is an empty string.

INTERNET-DRAFT        EAP Key Manageme
nt Framework      14 November 2004 looked up based on SPI (for inbound packets), or
      SPD traffic selectors (for outbound traffic).  A separate IPsec SA
      exists for each direction.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

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 (2004). (2005).  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.

Open Issues

   Open issues relating to this specification are tracked on the
   following web site:

   http://www.drizzle.com/~aboba/EAP/eapissues.html