EAP Working Group                                               B.                                          Bernard Aboba
Internet-Draft                                                  D.
INTERNET-DRAFT                                                 Dan Simon
Expires: April 26, 2004
Category: Informational                                        Microsoft
<draft-ietf-eap-keying-02.txt>                                  J. Arkko
26 June 2004                                                    Ericsson
                                                               P. Eronen
                                                                   Nokia
                                                       H. Levkowetz, Ed.
                                                             ipUnplugged
                                                        October 27, 2003

                      EAP

   Extensible Authentication Protocol (EAP) Key Management Framework
                     <draft-ietf-eap-keying-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. RFC 2026.

   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.

   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". progress."

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

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

   This Internet-Draft will expire on April 26, 2004.
   http://www.ietf.org/shadow.html.

Copyright Notice

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

Abstract

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   enables extensible network access authentication.  This document
   provides a framework for EAP key management, including
   a statement of applicability and guidelines for the generation, transport and usage of EAP
   keying material.  Algorithms for key derivation or
   mechanisms for key transport are not specified in this document.
   Rather, this document provides a framework within which algorithms
   and transport mechanisms can be discussed and evaluated. material generated by EAP authentication algorithms, known as
   "methods".

Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . . . ..........................................    4
      1.1       Requirements Language  . . . . . . . . . . . . . . . . ...........................    4
      1.2       Terminology  . . . . . . . . . . . . . . . . . . . . . .....................................    4
      1.3   Conversation       Overview  . . . . . . . . . . . . . . . .  6
               1.3.1 Discovery Phase  . . . . . . . . . . . . . . . .  7
               1.3.2 Authentication Phase . . . . . . . . . . . . . .  8
               1.3.3 Secure Association Phase . . . . . . . . . . . .  9 ........................................    5
      1.4   Authorization issues . . . . . . . . . . . . . . . . .  9
               1.4.1 Correctness in fast handoff  . . . . . . . . . .       EAP Invariants ..................................   11
   2.     EAP Key Hierarchy  . . . . . . . . . . . . . . . . . . . . . .....................................   13
      2.1   EAP Invariants . . . . . . . . . . . . . . . . . . . . 14
               2.1.1 Media Independence . . . . . . . . . . . . . . . 14
               2.1.2 Method Independence  . . . . . . . . . . . . . . 14
               2.1.3 Ciphersuite Independence . . . . . . . . . . . . 14       Key Terminology .................................   13
      2.2       Key Hierarchy  . . . . . . . . . . . . . . . . . . . . ...................................   15
      2.3   Exchanges  . . . . . . . . . . . . . . . . . . . . . . 19       Key Lifetimes ...................................   17
      2.4       AAA-Key Scope ...................................   24
      2.5       Fast Handoff Support ............................   26
   3.     Security Associations  . . . . . . . . . . . . . . . . . . . 22 associations .................................   30
      3.1       EAP Method SA (peer - EAP server) . . . . . . . . . . . . . . 23 ...................................   31
      3.2   EAP method       EAP-Key SA (peer - EAP server)  . . . . . . . . . . 23
               3.2.1 Example: EAP-TLS . . . . . . . . . . . . . . . . 24
               3.2.2 Example: EAP-AKA . . . . . . . . . . . . . . . . 24 ......................................   33
      3.3   EAP-key SA . . . . . . . . . . . . . . . . . . . . . . 25
         3.4       AAA SA(s) (authenticator - backend auth. server) . . . 25
               3.4.1 Example: RADIUS  . . . . . . . . . . . . . . . . 25
               3.4.2 Example: Diameter with TLS . . . . . . . . . . . 25 .......................................   33
      3.4       Service SA(s) ...................................   34
      3.5   Unicast Secure Association SA  . . . . . . . . . . . . 26
         3.6   Multicast Secure Association       SA  . . . . . . . . . . . 27
         3.7   Key Naming . . . . . . . . . . . . . . . . . . . . . . 28 .......................................   37
   4.    Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 29     Security Considerations  ..............................   39
      4.1       Security Assumptions . . . . . . . . . . . . . . . . . 29 Terminology ............................   39
      4.2       Threat Model ....................................   39
      4.3       Security Analysis ...............................   41
      4.4       Man-in-the-middle Attacks .......................   45
      4.5       Denial of Service Attacks .......................   45
      4.6       Impersonation ...................................   46
      4.7       Channel Binding .................................   47
      4.8       Key Strength ....................................   48
      4.9       Key Wrap ........................................   48
   5.     Security Requirements  . . . . . . . . . . . . . . . . 32
               4.2.1 .................................   49
      5.1       EAP method requirements  . . . . . . . . . . . . 32
               4.2.2 Method Requirements .........................   49
      5.2       AAA Protocol Requirements  . . . . . . . . . . . 34
               4.2.3 .......................   52
      5.3       Secure Association Protocol Requirements . . . . 36
               4.2.4 ........   54
      5.4       Ciphersuite Requirements . . . . . . . . . . . . 37
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 38 ........................   55
   6.    Security     IANA Considerations  . . . . . . . . . . . . . . . . . . 38
         6.1   Key Strength . . . . . . . . . . . . . . . . . . . . . 38
         6.2   Key Wrap . . . . . . . . . . . . . . . . . . . . . . . 38
         6.3   Man-in-the-middle Attacks  . . . . . . . . . . . . . . 39
         6.4   Impersonation  . . . . . . . . . . . . . . . . . . . . 39
         6.5   Denial of Service Attacks  . . . . . . . . . . . . . . 40 ...................................   56
   7.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41     References ............................................   56
      7.1       Normative References . . . . . . . . . . . . . . . . . . . . 41 ............................   56
      7.2       Informative References . . . . . . . . . . . . . . . . . . . 41
         Authors' ..........................   57
   Acknowledgments ..............................................   60
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . 45
   A. ...........................................   61
   Appendix A - Ciphersuite Keying Requirements  . . . . . . . . . . . . . . 46
   B. .................   62
   Appendix B - Transient EAP Key (TEK) Hierarchy  . . . . . . . . . . . . . 47
   C.    MSK and EMSK ...............   63
   Appendix C - EAP Key Hierarchy . . . . . . . . . . . . . . . . . . . 48
   D. ...............................   64
   Appendix D - Transient Session Key (TSK) Derivation . . . . . . . . . . . 51
   E. ..........   66
   Appendix E - AAA-Key Derivation . . . . . . . . . . . . . . . . . . . . . 52
   F.    Open issues  . . . . . . . . . . . . . . . . . . . . . . . . 53 ..............................   67
   Intellectual Property and Statement ..............................   68
   Full Copyright Statements . . . . . . . 54 Statement .....................................   68

1.  Introduction

   The Extensible Authentication Protocol (EAP), defined in
   [I-D.ietf-eap-rfc2284bis], [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".  Since in EAP keying material is generated by EAP
   methods, transported by AAA protocols, transformed into session keys
   by secure association protocols Secure Association Protocols and used by lower layer ciphersuites,
   it is necessary to describe each of these elements and provide a
   system-level security analysis.

1.1

1.1.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   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

1.2.  Terminology

   This document frequently uses the following terms:

authenticator
     The end of the link initiating EAP authentication. Where no
      backend authentication server is present, the authenticator acts
      as the EAP server, terminating the EAP conversation with the peer.
      Where a backend authentication server is present, the
      authenticator may act as a pass-through for one or more
      authentication methods and for non-local users. This terminology  The term
     Authenticator is also used in [IEEE8021X], [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 methods for the authenticator.  This
     terminology is also used in [IEEE8021X].

   AAA-Token
      The package within which keying material [IEEE-802.1X].

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

EAP server and the authenticator.
     The attributes provide entity that terminates the
      authenticator EAP authentication method with usage context and key names suitable to bind
      the key to the appropriate context. The format and wrapping of the
      AAA-Token, which is intended to be accessible only to
     peer.  In the case where no backend authentication server and authenticator, is defined by used,
     the AAA
      protocol.  Examples include  RADIUS [RFC2548], and  Diameter
      [I-D.ietf-aaa-eap].

   Cryptographic binding
      The demonstration EAP server is part of the EAP peer to authenticator.  In the case where the
     authenticator operates in pass-through mode, the EAP server that a single
      entity has acted as the EAP peer for all methods executed within a
      sequence or tunnel.  Binding MAY also imply that the EAP server
      demonstrates to the peer that a single entity has acted as is
     located on the EAP
      server for all methods executed within a sequence or tunnel.  If
      executed correctly, binding serves to mitigate man-in-the-middle
      vulnerabilities.

   Cryptographic separation
      Two keys (x backend authentication server.

security association
     A set of policies and y) are "cryptographically separate" if an
      adversary that knows all messages exchanged key(s) used to protect information.  This
     information in the protocol cannot
      compute x from y or y from x without "breaking" some cryptographic
      assumption.  In particular, this definition allows that the
      adversary has the knowledge security association is stored by each party of all nonces sent in cleartext as
      well as all predictable counter values used in
     the protocol.
      Breaking a cryptographic assumption would typically require
      inverting a one-way function or predicting security association and must be consistent among the outcome parties.
     Elements of a security association include cryptographic pseudo-random number generator without knowledge of
      the secret state.  In keys,
     negotiated ciphersuites and other words, if the keys are
      cryptographically separate, there parameters, counters, sequence
     spaces, authorization attributes, etc.

1.3.  Overview

   EAP is no shortcut typically deployed in order to compute x from
      y or y from x.

   EAP server
      The entity which terminates EAP support extensible network
   access authentication with the in situations where a peer desires network
   access via one or more authenticators.  The situation is
      known as illustrated
   in Figure 1.

   Since both the EAP server.  Where pass-through is supported, peer and authenticator may have more than one physical
   or logical port, a given peer may simultaneously access the
      backend authentication server functions as the EAP server;  where
      authentication occurs locally, the EAP server is 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 peer may be stationary, in which case it may establish
   communications with one or more authenticators while remaining in one
   location.  Alternatively, the peer may be mobile, changing its point
   of attachment from one authenticator to another, or moving between
   points of attachment on a single authenticator.

   AAA-Key
      A key derived by

   Where authenticators are deployed standalone, the EAP conversation
   occurs between the peer and EAP server authenticator, and transported to the authenticator.  In 802.11 terminology, authenticator must
   locally implement an EAP method acceptable to the first 32 octets peer.

   However, one of the AAA-Key advantages of EAP is known as the Pairwise Master Key (PMK).

   Key strength
      If that it enables deployment
   of new authentication methods without requiring development of new
   code on the effective key strength is N bits, authenticator.  While the best currently known authenticator may implement
   some EAP methods locally and use those methods to recover authenticate local
   users, it may at the key (with non-negligible probability)
      require an effort comparable to 2^N operations of same time act as a typical block
      cipher.

   Mutual authentication
      This refers to an pass-through for other users
   and methods, forwarding EAP method in which, within an interlocked
      exchange, the authenticator authenticates the peer packets back and forth between the peer
      authenticates the authenticator.  Two one-way conversations,
      running in opposite directions do not provide mutual
   backend authentication as defined here.

   peer
      The end of the link that responds to server and the authenticator. In
      [IEEE8021X], this end is known as peer.

                            +-+-+-+-+
                            |       |
                            | EAP   |
                            | Peer  |
                            |       |
                            +-+-+-+-+
                              | | |  Peer Ports
                             /  |  \
                            /   |   \
 Phase 0: Discovery        /    |    \
 Phase 1: Authentication  /     |     \
 Phase 2: Secure         /      |      \
          Association   /       |       \
                       /        |        \
                      /         |         \
                   | | |      | | |      | | |  Authenticator Ports
                 +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                 |       |  |       |  |       |
                 | Auth. |  | Auth. |  | Auth. |
                 |       |  |       |  |       |
                 +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                      \         |         /
                       \        |        /
                        \       |       /
          EAP over AAA   \      |      /
            (optional)    \     |     /
                           \    |    /
                            \   |   /
                             \  |  /
                            +-+-+-+-+
                            |       |
                            | AAA   |
                            |Server |
                            |       |
                            +-+-+-+-+

Figure 1:  Relationship between peer, authenticator and backend server

   This is accomplished by encapsulating EAP packets within the Supplicant.

1.3 Conversation Overview
   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].

   Where EAP key derivation is supported, EAP authentication is the conversation between the
   peer and the authenticator typically a component of a takes place in three phase exchange: phases:

      Phase 0: Discovery phase (phase 0)
      Phase 1: Authentication
               1a: EAP authentication, key derivation and transport (phase 1) authentication
               1b: AAA-Key Transport (optional)
      Phase 2: Secure Association Establishment
               2a: Unicast and multicast secure association establishment (phase 2) Secure Association
               2b: Multicast Secure Association (optional)

   In the discovery phase (phase 0),  the EAP  peers locate each other authenticators and
   discover their capabilities.  This can include an EAP  For example, a peer
   locating may locate an
   authenticator suitable for providing access to a particular network, or it could involve an EAP a peer locating may
   locate an authenticator behind a bridge with which it desires to
   establish a secure
   association.  Typically the discovery Secure Association.

   The authentication phase takes place between the
   EAP peer and authenticator.

   Once (phase 1) may begin once the EAP peer and
   authenticator discover each other, other.  This phase always includes EAP
   authentication may begin (phase 1a).  Where the chosen EAP enables deployment of new
   authentication methods without requiring development of new code method supports key
   derivation, in phase 1a keying material is derived on both 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 peer
   and the peer.

   As described in Section 2, in addition to supporting authentication, EAP methods may also support derivation of server.  This keying material may be used for
   purposes multiple
   purposes, including protection of the EAP conversation and subsequent
   data exchanges.  EAP key derivation takes place between the EAP peer
   and EAP server, and methods supporting key derivation MUST also
   support mutual authentication.  Where an authenticator server

   An additional step (phase 1b) is
   present, it acts as the EAP server and transports derived 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 authenticator.

   A Secure Association exchange (phase 1b).

   EAP methods may mutually authenticate 2) then occurs between the peer
   and derive keys.  However a
   distinct secure association exchange is required authenticator in order to manage the creation and deletion of
   unicast (phase 2a) and multicast (phase 2b) security associations
   between the EAP peer and authenticator.

   The conversation phases and the relationship between the parties is illustrated
   below. shown
   in 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 1: 2: Conversation Overview

1.3.1

1.3.1.  Discovery Phase

   In the peer discovery exchange 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 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] includes 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.  In

   IEEE 802.11 [IEEE80211], the EAP peer (also known as [IEEE80211] also provides integrated discovery support
   utilizing Beacon and/or Probe Request/Response frames, allowing the Station
   peer (known as the station or STA) discovers to determine the authenticator (Access Point or AP) MAC address and determines
   its
   capabilities using Beacon or Probe Request/Response frames.
   Since device discovery is handled outside of EAP, there is no need to
   provide this functionality within EAP.

   Device discovery can occur manually one or automatically.  In EAP
   implementations running over PPP, the EAP peer might be configured
   with a phone book providing phone numbers of more authenticators and
   associated capabilities such (known as supported rates, authentication
   protocols Access Point or ciphersuites.

   Since device discovery can occur prior to authentication and key
   derivation, it may not be possible for the discovery phase to be
   protected using keying material derived during an authentication
   exchange.  As a result, device discovery protocols may be insecure,
   leaving them vulnerable to spoofing unless the discovered parameters
   can subsequently be securely verified.

1.3.2
   APs).

1.3.2.  Authentication Phase

   Once the EAP peer and authenticator discover each other, they exchange
   EAP packets.  Typically, the peer desires access to the network, and
   the authenticators are Network Access Servers (NASes)
   providing 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 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 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 an
   EAP 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
   Secure Association Protocol (phase 2).  As a result, EAP may be used
   for "pre-authentication" in situations where it is necessary to
   pre-establish pre-
   establish EAP security associations in order to decrease handoff or
   roaming latency.

1.3.3

1.3.3.  Secure Association Phase

   The secure association Secure Association phase (phase 2) always occurs after the
   completion of EAP authentication (phase 1a) and key transport (phase
   1b), and typically supports the following features:

[1] The secure negotiation of capabilities.  This includes usage
       modes, session parameters and ciphersuites, and required filters,
       including confirmation  Entity Naming.  A basic feature of a Secure Association Protocol is
     the capabilities discovered during
       phase 0.  By securely negotiating session parameters, naming of the secure
       association protocol protects against spoofing during parties engaged in the
       discovery phase and ensures that exchange.  As illustrated
     in Figure 1, it is possible for both the peer and authenticator are
       in agreement about how data is NAS to be secured.

   [2] Generation have more
     than one physical or virtual port.  For the purposes of fresh transient session keys.  This
     identification, it is typically
       accomplished via therefore not possible to identify either
     peers or NAS devices using port identifiers.  Proper identification
     of the parties is critical to the Secure Association phase, since
     without this the parties engaged in the exchange are not identified
     and the scope of nonces within the transient session keys (TSKs) generated during
     the exchange is undefined.

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

[3]  Generation of fresh transient session keys (TSKs).  The Secure
     Association Protocol typically guarantees the freshness of session
     keys by exchanging nonces between both parties and then mixing the
     nonces with the AAA-Key in order to generate fresh unicast (phase
     2a) and multicast (phase 2b) session keys.  By not using the AAA-Key AAA-
     Key directly to protect data, the secure association
       protocol Association Protocol
     protects against compromise of the AAA-Key, and by guaranteeing the
     freshness of transient session key, keys, assures that
       session keys they are not
     reused.

   [3]

[4]  Key activation and deletion.

   [4] In order for the peer and
     authenticator to communicate securely, it is necessary for both
     sides to derive the same session keys, and remain in sync with
     respect to key state going forward.  One of the functions of the
     Secure Association Protocol is to synchronize the activation 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.

[5]  Mutual proof of possession of the AAA-Key.  This demonstrates that
     both the EAP peer and authenticator have been authenticated and
     authorized by the AAA backend authentication server.  Since mutual
     proof of possession is not the same as mutual authentication, the EAP
     peer cannot verify authenticator assertions (including the
     authenticator identity) as a result of this exchange.

1.4 Authorization issues

   In

1.4.  EAP Invariants

   By utilizing 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 the offered
   service.

   As a part of the authentication process, the AAA network determines
   the user's authorization profile.  The user authorizations are
   transmitted by the AAA server to three phase exchange, the EAP authenticator (also key management framework
   guarantees that certain basic characteristics, known as the Network Access Server or NAS) included with the AAA-Token, which
   also contains the AAA-Key, in Phase 1b "EAP
   Invariants" hold true for all implementations of EAP.  These include:

      Media independence
      Method independence
      Ciphersuite independence

1.4.1.  Media Independence

   One of the goals of EAP conversation.
   Typically, the profile is determined based to allow EAP methods to function on any
   lower layer meeting the user identity, but
   a certificate presented by the user may also provide authorization
   information.

   The AAA server 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 responsible necessary for making a user authorization
   decision, answering EAP to
   avoid inclusion of media-specific elements.  For example, EAP methods
   cannot be assumed to have knowledge of the following questions:

   o  Is this lower layer over which
   they are transported, and cannot utilize identifiers associated with
   a legitimate user for this particular network?

   o  Is this user allowed usage environment (e.g. MAC addresses).

   The need for media independence has also motivated the type development of access he or she is requesting?

   o  Are there any specific parameters (mandatory tunneling, bandwidth,
      filters, and so on) that
   the access network should be aware of for
      this user?

   o  Is three phase exchange.  Since discovery is typically media-
   specific, this user within the subscription rules regarding time function is handled outside of day?

   o  Is this user EAP, rather than being
   incorporated within his limits for concurrent sessions?

   o  Are there any fraud, credit limit, it.  Similarly, the Secure Association Protocol
   often contains media dependencies such as negotiation of media-
   specific ciphersuites or other concerns that indicate session parameters, and as a result this
   functionality also cannot be incorporated within EAP.

   Note that access should media independence may be denied?

   While the authorization decision is in principle simple, the process
   is complicated by the distributed nature of AAA decision making.
   Where brokering entities retained within EAP methods that
   support channel binding or proxies are involved, all method-specific identification.  An EAP
   method need not be aware of the AAA
   devices content of an identifier in the chain from the NAS 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 home AAA server are involved in the decision.  For instance, a broker can disallow access even if
   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 and profiles as
   well as dynamic state (e.g. time form of day or limits on the number an opaque blob, and receive
   confirmation of
   concurrent sessions).  In addition to the Accept/Reject decision made
   by whether the AAA chain, parameters or constraints match, without requiring
   media-specific knowledge.

1.4.2.  Method Independence

   By enabling pass-through, authenticators can be communicated to support any method
   implemented on the NAS.

   The criteria for Accept/Reject decisions or peer and server, not just locally implemented
   methods.  This allows the reasons authenticator to avoid implementing code
   for choosing
   particular authorizations are typically each EAP method required by peers.  In fact, since a pass-through
   authenticator is not communicated required to the NAS,
   only the final result. implement any EAP methods at all, it
   cannot be assumed to support any EAP method-specific code.

   As a result, the NAS has no way to know what
   the decision was based on.  Was a set as noted in [RFC3748], authenticators must by default be
   capable of authorization parameters
   sent because this service is always provided to supporting any EAP method.  Since the user, or was Discovery and Secure
   Association exchanges are also method independent, an authenticator
   can carry out the
   decision based on three phase exchange without having an EAP method
   in common with the time/day peer.

   This is useful where there is no single EAP method that is both
   mandatory-to-implement and offers acceptable security for the capabilities of media
   in use.  For example, the requesting
   NAS device?

   Within EAP, "fast handoff" is defined [RFC3748] mandatory-to-implement EAP method
   (MD5-Challenge) does not provide dictionary attack resistance, mutual
   authentication or key derivation, and as a conversation result is not appropriate
   for use in which wireless LAN authentication [WLANREQ].  However, despite
   this it is possible for the
   EAP exchange (phase 1a) peer and associated AAA passthrough is bypassed,
   so as authenticator to reduce latency.  Depending interoperate as
   long as a suitable EAP method is supported on the fast handoff mechanism,
   AAA-Key transport (phase 1b) may also be bypassed in favor a context
   transfer (see [IEEE80211f] and [I-D.aboba-802-context]) or it EAP server.

1.4.3.  Ciphersuite Independence

   While EAP methods may be
   provided in a pre-emptive manner as negotiate the ciphersuite used in [IEEE-03-084] and
   [I-D.irtf-aaaarch-handoff].

   As we will discuss, protection of
   the introduction EAP conversation, the ciphersuite used for the protection of fast handoff creates a new
   class of security vulnerabilities as well as requirements for the
   secure handling of authorization context.

1.4.1 Correctness in fast handoff

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

   o  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 by
      changing negotiated within the point of attachment.

   o  Avoidance Secure Association Protocol, out-of-band of privilege elevation.  A fast handoff should
   EAP.

   The backend authentication server is not
      result in a user being granted access party to services which they are
      not entitled to.

   o  Consideration of dynamic state.  In situations in which dynamic
      state this negotiation
   nor is involved it an intermediary in the access decision (day/time, simultaneous
      session limit) it should be possible 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 data flow between the AAA server.

   o  Encoding of restrictions.  Since a NAS EAP peer and
   authenticator.  The backend authentication server may not be aware even have
   knowledge of the
      criteria considered ciphersuites implemented by a AAA server when allowing access, in order
      to ensure consistent authorization during a fast handoff it may be
      necessary to explicitly encode the restrictions within peer and
   authenticator, or be aware of the
      authorizations provided ciphersuite negotiated between
   them, and therefore does not implement ciphersuite-specific code.

   Since ciphersuite negotiation occurs in the AAA-Token.

   o  State validity.  The introduction of fast handoff should Secure Association
   protocol, not
      render in EAP, ciphersuite-specific key generation, if
   implemented within an EAP method, would potentially conflict with the authentication server incapable of keeping track of
      network-wide state.

   A fast handoff mechanism capable of addressing these concerns
   transient session key derivation occurring in the Secure Association
   protocol.  As a result, EAP methods generate keying material that is said
   ciphersuite-independent.  Additional advantages of ciphersuite-
   independence include:

Update requirements
     If EAP methods were to be "correct".  One condition specify how to derive transient session keys
     for correctness is as follows:

   For a fast handoff each ciphersuite, they would need to be "correct" it MUST establish on the new
   device the same context as would have been created had the new device
   completed updated each time a AAA conversation new
     ciphersuite is developed.  In addition, backend authentication
     servers might not be usable with all EAP-capable authenticators,
     since the backend authentication server.

   A properly designed fast handoff scheme will only succeed if it is
   "correct" in this way.  If a successful fast handoff server would establish
   "incorrect" state, it is preferable also need to be
     updated each time support for it a new ciphersuite is added to fail, in order the
     authenticator.

EAP method complexity
     Requiring each EAP method to avoid
   creation of incorrect context.

   Some AAA server include ciphersuite-specific code for
     transient session key derivation would increase method complexity
     and NAS configurations are incapable result in duplicated effort.

Knowledge of meeting this
   definition capabilities
     In practice, an EAP method may not have knowledge of "correctness".  For example, if the old
     ciphersuite that has been negotiated between the peer and new device
   differ in their capabilities, it may be difficult to meet
     authenticator, since this
   definition of correctness in a fast handoff mechanism that bypasses
   AAA.  AAA servers often perform conditional evaluation, in which the
   authorizations returned in an Access-Accept message are contingent on
   the NAS or on dynamic state such as negotiation typically occurs within the time of day or number of
   simultaneous sessions.
     Secure Association Protocol.

     For example, PPP ciphersuite negotiation occurs in a heterogeneous deployment, the AAA server might return different authorizations depending on Encryption
     Control Protocol (ECP) [RFC1968].  Since ECP negotiation occurs
     after authentication, unless an EAP method is utilized that
     supports ciphersuite negotiation, the
   NAS making peer, authenticator and
     backend authentication server may not be able to anticipate the request, in order
     negotiated ciphersuite and therefore this information cannot be
     provided to make sure that the requested
   service EAP method.  Since ciphersuite negotiation is consistent with
     assumed to occur out-of-band, there is no need for ciphersuite
     negotiation within EAP.

2.  EAP Key Hierarchy

2.1.  Key Terminology

   The EAP Key Hierarchy makes use of the NAS capabilities.

   If differences following types of keys:

Long Term Credential
     EAP methods frequently make use of long term secrets in order to
     enable authentication between the new peer and old device would result in server.  In the AAA
   server sending a different set case of messages to the new device than
   were sent to
     a method based on pre-shared key authentication, the old device, then if long term
     credential is the fast handoff mechanism
   bypasses AAA, then pre-shared key.  In the fast handoff cannot be carried out correctly.

   For example, if some NAS devices within case of a deployment support dynamic
   VLANs while others do not, then attributes present in the
   Access-Request (such as public-key
     based method, the NAS-IP-Address, NAS-Identifier,
   Vendor-Identifier, etc.) could be examined to determine when VLAN
   attributes will be returned, as described in [RFC3580].   VLAN
   support long term credential is defined in [IEEE8021Q].  If a fast handoff bypassing the
   AAA corresponding private
     key.

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

Extended Master Session Key (EMSK)
     Additional keying material derived between a NAS supporting dynamic VLANs the peer and
   another NAS which does not, then a guest user with access restricted
   to a guest VLAN could be given unrestricted access to server that
     is exported by the network.

   Similarly, EAP method.  The EMSK is at least 64 octets in a network where access
     length, and is restricted based on never shared with a third party.

AAA-Key
     A key derived by the day peer and time, SSID, Calling-Station-Id or other factors, unless EAP server, used by the
   restrictions are encoded within peer and
     authenticator in the authorizations, or derivation of Transient Session Keys (TSKs).
     Where a partial AAA
   conversation backend authentication server is included, then a fast handoff could result in the
   user bypassing present, the restrictions.

   In practice, these considerations limit AAA-Key is
     transported from the situations in which fast
   handoff mechanisms bypassing AAA can be expected backend authentication server to be successful.
   Where the deployed devices implement
     authenticator, wrapped within the same set of services, AAA-Token; it may
   be possible to do successful fast handoffs within such mechanisms. is therefore known
     by the peer, authenticator and backend authentication server.
     However, where despite the supported services differ between devices, name, the
   fast handoff may not succeed.  For example, [RFC2865], section 1.1
   states:

      "A NAS that does not implement AAA-Key is computed regardless of
     whether a given service MUST NOT implement backend authentication server is present.  AAA-Key
     derivation is discussed in Appendix E; in existing implementations
     the RADIUS attributes 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 that service.  For example, extended uses.  AMSK derivation
     is discussed in Appendix E.

AAA-Token
     Where a NAS that backend server is unable to offer ARAP service MUST NOT implement present, the RADIUS AAA-Key and one or more
     attributes for ARAP.  A NAS MUST treat is transported between the backend authentication server
     and the authenticator within a RADIUS access-accept
      authorizing an unavailable service package known as an access-reject instead."

   Note that this behavior the AAA-Token.  The
     format and wrapping of the AAA-Token, which is intended to be
     accessible only applies to attributes that are known,
   but not implemented.  For attributes that are unknown, section of 5
   of [RFC2865] states:

      "A RADIUS the backend authentication server MAY ignore Attributes with an unknown Type.  A
      RADIUS client MAY ignore Attributes with an unknown Type."

   In order to perform a correct fast handoff, if a new device and
     authenticator, is
   provided with defined by the AAA protocol.  Examples include
     RADIUS context [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 but unavailable service,
   then it MUST process this context the same way value in methods such as EAP-
     TLS [RFC2716], it would handle cannot be used by itself for computation of any
     quantity that needs to remain secret.  As a
   RADIUS Access-Accept requesting an unavailable service.  This MUST
   cause the fast handoff result, its use has
     been deprecated and EAP methods are not required to fail. generate it.
     However, if a new device is provided
   with RADIUS context that indicates an unknown attribute, then this
   attribute MAY be ignored.

   Although when it may seem somewhat counter-intuitive, failure is indeed
   the "correct" result where a known but unsupported service is
   requested. Presumably a correctly configured AAA server would not
   request that a device carry out a service that generated it does not implement.
   This implies that if MUST be unpredictable.

Pairwise Master Key (PMK)
     The AAA-Key is divided into two halves, the new device were "Peer to complete a AAA
   conversation that it would be likely Authenticator
     Encryption Key" (Enc-RECV-Key) and "Authenticator to receive different service
   instructions.  In such a case, failure Peer
     Encryption Key" (Enc-SEND-Key) (reception is defined from the point
     of view of the fast handoff is authenticator).  Within [IEEE80211i] Octets 0-31 of
     the
   desired result.  This will cause AAA-Key (Enc-RECV-Key) are known as the new device to go back to Pairwise Master Key
     (PMK).  In [IEEE80211i] the AAA
   server TKIP and AES CCMP ciphersuites derive
     their Transient Session Keys (TSKs) solely from the PMK, whereas
     the WEP ciphersuite as noted in order to receive [RFC3580], derives its TSKs from
     both halves of the appropriate service definition.

   In practice, this implies that fast handoff mechanisms AAA-Key.

Transient EAP Keys (TEKs)
     Session keys which bypass
   AAA are most likely to be successful within a homogeneous device
   deployment within a single administrative domain. For example, it
   would not be advisable used to carry out establish a fast handoff bypassing AAA protected channel
     between a NAS providing confidentiality the EAP peer and another NAS that does not
   support this service. server during the EAP authentication
     exchange. The correct result of such a fast handoff
   would be a failure, since if TEKs are appropriate for use with the handoff were blindly carried out,
   then ciphersuite
     negotiated between EAP peer and server for use in protecting the user would be moved from a secure
     EAP conversation.  Note that the ciphersuite used to an insecure set up the
     protected channel
   without permission from between the AAA server.  Thus EAP peer and server during EAP
     authentication is unrelated to the definition of a
   "known but unsupported service" MUST encompass requests for
   unavailable security services.  This includes vendor-specific
   attributes related ciphersuite used to security, such as those subsequently
     protect data sent between the EAP peer and authenticator. An
     example TEK key hierarchy is described in
   [RFC2548]."

2. Appendix C.

Transient Session Keys (TSKs)
     Session keys used to protect data which are appropriate for the
     ciphersuite negotiated between the EAP peer and authenticator.  The
     TSKs are derived from AAA-Key during the Secure Association
     Protocol.  In the case of [IEEE80211i] the Secure Association
     Protocol consists of the 4-way handshake and group key derivation.
     An example TSK derivation is provided in Appendix D.

2.2.  Key Hierarchy

2.1 EAP Invariants

   The EAP key management framework assumes that certain basic
   characteristics, known as Key Hierarchy, illustrated in Figure 3, has at the "EAP Invariants" hold true for all
   implementations of EAP.  These include:

      Media independence
      Method independence
      Ciphersuite independence

2.1.1 Media Independence

   As described in [I-D.ietf-eap-rfc2284bis], root the
   long term credential utilized by the selected EAP method.  If
   authentication can run
   over multiple lower layers, including PPP [RFC1661] and IEEE 802
   wired networks [IEEE8021X].  Use with IEEE 802.11 wireless LANs is
   also contemplated [IEEE80211i].  Since based on a pre-shared key, the parties store the
   EAP methods cannot be assumed method to have knowledge of be used and the lower layer over which they are transported, pre-shared key.  The EAP methods can function 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 any lower layer meeting proof of possession of the criteria
   outlined in [I-D.ietf-eap-rfc2284bis], Section 3.1.  As private key
   corresponding to the public key contained within a result, certificate, the
   parties store the EAP
   methods should not utilize identifiers associated with a particular
   usage environment (e.g. MAC addresses).

2.1.2 Method Independence

   Supporting pass-through of authentication method to be used and the backend
   authentication trust anchors used to
   validate the certificates.  The EAP server enables also stores the authenticator peer's
   identity and/or other information necessary to support any
   authentication method implemented 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 backend authentication
   server long term credential established between the peer and peer, not just
   the server, EAP derives four types of keys:

    [1] Keys calculated locally implemented methods.

   This implies that by the authenticator need not implement code for each EAP method required but not exported
        by authenticating peers. In fact, the
   authenticator is not required to implement any EAP methods at all,
   nor can it be assumed to implement code specific to any method, such as the TEKs.
    [2] Keys exported by the EAP method.

   This is useful where there is no single method: MSK, EMSK, IV
    [3] Keys calculated from exported quantities: AAA-Key, AMSKs.
    [4] Keys calculated by the Secure Association Protocol: TSKs.

   In order to protect the EAP method that is both
   mandatory-to-implement conversation, methods supporting key
   derivation typically negotiate a ciphersuite and offers acceptable security derive Transient EAP
   Keys (TEKs) for use with that ciphersuite.  The TEKs are stored
   locally by the media
   in use.  For example, the [I-D.ietf-eap-rfc2284bis]
   mandatory-to-implement EAP method (MD5-Challenge) does not provide
   dictionary attack resistance, mutual authentication or key
   derivation, and as a result is are not appropriate for use exported.

   As noted in wireless
   authentication.

2.1.3 Ciphersuite Independence

   While [RFC3748] Section 7.10, EAP methods may negotiate generating keys are
   required to calculate and export the ciphersuite used MSK and EMSK, which must be at
   least 64 octets in protection of
   the length.  EAP conversation, methods also may export the ciphersuite used for IV;
   however, the protection use of data the IV is negotiated within deprecated.

   On both the secure association protocol, out-of-band of
   EAP. The peer and EAP server, the exported MSK and EMSK are
   utilized in order to calculate the AAA-Key, as described in Appendix
   E.

   Where a backend authentication server is not a party to this
   negotiation nor is it an intermediary in present, the data flow between AAA-Key is
   transported from the
   EAP peer and authenticator.  The backend authentication server may
   not even have knowledge of to the ciphersuites implemented by
   authenticator within the AAA-Token, using the AAA protocol.

   Once EAP authentication completes and is successful, the peer and authenticator, or be aware of
   authenticator obtain the ciphersuite negotiated AAA-Key and the Secure Association Protocol
   is run between
   them, the peer and therefore does not implement ciphersuite-specific code.

   Since ciphersuite negotiation occurs authenticator in order to securely
   negotiate the secure association
   protocol, not in EAP, ciphersuite-specific key generation, if
   implemented within an EAP method, would potentially conflict with ciphersuite, derive fresh TSKs used to protect data,
   and provide mutual proof of possession of the
   transient session key derivation occurring in AAA-Key.

   When the secure association
   protocol.  As a result, EAP methods generate keying material that is
   ciphersuite-independent. Additional advantages authenticator acts as an endpoint of
   ciphersuite-independence include:

   Update requirements
      If the EAP methods were to specify how to derive transient session
      keys for each ciphersuite, they would need to be updated each time conversation
   rather than a new ciphersuite is developed.  In addition, backend
      authentication servers might not be usable with all EAP-capable
      authenticators, since pass-through, EAP methods are implemented on the backend authentication server would also
      need to be updated each time support for a new ciphersuite is
      added to
   authenticator as well as the peer.  If the authenticator. EAP method complexity
      Requiring each negotiated
   between the EAP method to include ciphersuite-specific code for
      transient session peer and authenticator supports mutual authentication
   and key derivation would increase derivation, the complexity of
      each EAP method Master Session Key (MSK) and would result in duplicated effort.

   Knowledge of capabilities
      In practice, an EAP method may not have knowledge of the
      ciphersuite that has been negotiated between Extended
   Master Session Key (EMSK) are derived on the EAP peer and
      authenticator.  In PPP, ciphersuite negotiation occurs in
   authenticator and exported by the
      Encryption Control Protocol (ECP) [RFC1968].  Since ECP
      negotiation occurs after authentication, unless an EAP method is
      utilized that supports ciphersuite negotiation, method.  In this case, the peer,
      authenticator MSK
   and backend authentication server may not be able EMSK are known only to
      anticipate the negotiated ciphersuite peer and therefore this
      information cannot be provided to authenticator and no other
   parties.  The TEKs and TSKs also reside solely on the EAP method.  Since
      ciphersuite negotiation peer and
   authenticator.  This is assumed illustrated in Figure 4.  As demonstrated in
   [I-D.ietf-roamops-cert], in this case it is still possible to occur out-of-band, there support
   roaming between providers, using certificate-based authentication.

   Where a backend authentication server is utilized, the situation is
      no need for ciphersuite negotiation within EAP.

2.2 Key Hierarchy

   The EAP keying hierarchy,
   illustrated in Figure 2, makes use of 5.   Here the
   following types of keys:

   EAP Master key (MK)
      A key derived authenticator acts as a pass-
   through between the EAP client peer and server during the EAP a backend authentication process, and that is kept local to server. In
   this model, the EAP method
      and not exported or made available authenticator delegates the access control decision
   to the backend authentication server, which acts as a third party.

   Master Session Key (MSK)
      Keying material (at least 64 octets) that is derived between
   Distribution Center (KDC).  In this case, the authenticator
   encapsulates EAP client packet with a AAA protocol such as RADIUS [RFC3579]
   or Diameter [I-D.ietf-aaa-eap], and server forwards packets to and exported by from the EAP method.

   AAA-Key
      Where a
   backend authentication server is present, acting as an EAP server,  keying material known which acts as the AAA-Key is transported from
      the authentication server to EAP server.  Since
   the authenticator wrapped within 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 EAP peer and authenticator
      in within the derivation of
   Secure Association Protocol to derive Transient Session Keys (TSKs)
   required for the
      ciphersuite negotiated between ciphersuite.  The TSKs are known only to
   the EAP peer and authenticator.

2.3.  Key Lifetimes

   As
      a result, the AAA-Key is typically known by all parties in noted earlier, the EAP
      exchange: the peer, authenticator and the authentication server
      (if present).  AAA-Key derivation is discussed in Appendix E.

   Extended Master Session Key (EMSK)
      Additional keying material (64 octets) derived between Management framework includes several
   types of keys, including:

    [1] Keys calculated locally by the EAP
      client and server that is method but not exported
        by the EAP method.  The EMSK is
      known only to method, such as the EAP peer and server and is not provided to a
      third party.

   Initialization Vector (IV)
      A quantity of at least 64 octets, suitable for use in an
      initialization vector field, that is derived between TEKs.
    [2] Keys exported by the EAP
      client and server.  Since the method: MSK, EMSK, IV is a known value
    [3] Keys calculated from exported quantities: AAA-Key, AMSKs.
    [4] Keys calculated by the Secure Association Protocol: TSKs.

   Key lifetime issues associated with each type of key are discussed in methods such
      as EAP-TLS [RFC2716], it
   the sections that follow.  Challenges include:

[a]  Security.  Where key lifetimes 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.

   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). IEEE 802.11i ciphersuites [IEEE80211i] derive
      their Transient Session Keys (TSKs) solely from the PMK, whereas
      the WEP ciphersuite, when used with [IEEE8021X], as noted in
      [RFC3580], derives its TSKs from both halves of the AAA-Key, the
      Enc-RECV-Key and the Enc-SEND-Key.

   Transient EAP Keys (TEKs)
      Session keys which are used assumed, it may be
     necessary 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 negotiate them.  While key lifetimes may be announced
     or negotiated between EAP peer and server for use in protecting the
      EAP conversation.  Note that the ciphersuite used to set up the clear, a 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 lifetime negotiation is described in
      Appendix C.
     RECOMMENDED.

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

                            Figure 2: 3: EAP Key Hierarchy
   Transient Session Keys
     +-+-+-+-+-+               +-+-+-+-+-+
     |         |               |         |
     |         |               |         |
     | 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 |
     | (TSKs)
      Session keys used to protect data which are appropriate for the
      ciphersuite negotiated between the  |               |  (TSKs) |
     |         |               |         |
     +-+-+-+-+-+               +-+-+-+-+-+
         ^                         ^
         |                         |
         | MSK, EMSK               | MSK, EMSK
         |                         |
         |                         |
     +-+-+-+-+-+               +-+-+-+-+-+
     |         |               |         |
     |  EAP peer and authenticator.
      The TSKs are derived from the keying material included in the
      AAA-Token via the secure association protocol. In the case of IEEE
      802.11, the role of the secure association protocol is handled by
      the 4-way handshake and group key derivation.  An example TSK
      derivation is provided in Appendix D.

2.3 Exchanges    |               |  EAP supports both a two party exchange    |
     |  Method |               |  Method |
     |         |               |         |
     | (TEKs)  |               | (TEKs)  |
     |         |               |         |
     +-+-+-+-+-+               +-+-+-+-+-+

     Figure 4:  Relationship between an EAP peer and an
   authenticator, as well as a three party exchange between an EAP peer,
   an authenticator and (acting
     as an EAP server.

   Figure 3 illustrates the two party exchange.  Here EAP server), where no backend authentication server is spoken
   between the
     present.

     +-+-+-+-+-+               +-+-+-+-+-+
     |         |               |         |
     |         |               |         |
     | Cipher- |               | Cipher- |
     | Suite   |               | Suite   |
     |         |               |         |
     +-+-+-+-+-+               +-+-+-+-+-+
         ^                         ^
         |                         |
         |                         |
         |                         |
         V                         V
     +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
     |         |===============|         |========|         |
     |         |EAP, TEK Deriv.|         |        |         |
     |         |<-------------------------------->| backend |
     |         |               |         |        |         |
     |         | Secure Assoc. |         | AAA-Key|         |
     | peer and authenticator, encapsulated within a lower layer
   protocol, such as PPP, defined in [RFC1661] or IEEE 802, defined in
   [IEEE802].

   Since the authenticator acts as an endpoint of the EAP conversation
   rather than a pass-through,    |<------------->|Authenti-|<-------|  auth   |
     |         |===============| cator   |========| server  |
     |         |  Link Layer   |         |  AAA   | (EAP    |
     |         | (PPP,IEEE 802)|         |Protocol| server) |
     |MSK,EMSK |               |         |        |         |
     | AAA-Key |               | AAA-Key |        |MSK,EMSK,|
     | (TSKs)  |               |  (TSKs) |        | AAA-Key |
     |         |               |         |        |         |
     +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
         ^                                            ^
         |                                            |
         | MSK, EMSK                                  | MSK, EMSK
         |                                            |
         |                                            |
     +-+-+-+-+-+                                  +-+-+-+-+-+
     |         |                                  |         |
     |  EAP methods are implemented on the
   authenticator as well as the peer.  If the    |                                  |  EAP method negotiated    |
     |  Method |                                  |  Method |
     |         |                                  |         |
     |  (TEKs) |                                  |  (TEKs) |
     |         |                                  |         |
     +-+-+-+-+-+                                  +-+-+-+-+-+

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

[b]  Resource reclaimation.  While 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.

   Where no backend authentication server lifetimes may be securely
     negotiated, it is present, the MSK and EMSK
   are known only to possible for the NAS or peer to reboot or reclaim
     resources, and authenticator and neither is
   transported therefore not be able to a third party. cache keys for their full
     lifetime.  As demonstrated in
   [I-D.ietf-roamops-cert], despite the absence of a backend
   authentication server, such exchanges can support roaming between
   providers; it result, lifetime negotiation does not guarantee
     that the key cache will remain sychronized.  It is even possible therefore
     RECOMMENDED for the lower layer to support fast handoff without
   re-authentication.  However, provide a mechanism for key
     state resynchronization.  Note that securing this is typically only possible where
   both the EAP peer and authenticator support certificate-based
   authentication, mechanism may be
     difficult since in this situation one or where more of the user base is sufficiently small that EAP
   authentication can occur locally.

   In order parties
     initially do not possess a key with which to protect the EAP conversation, the EAP method may
   negotiate a ciphersuite and derive
     resynchronization exchange.

2.3.1.  Local Key Lifetimes

   The Transient EAP Keys (TEKs) to
   provide are session keys for that ciphersuite in order used to protect some or all of the
   EAP exchange. conversation.  The TEKs are stored locally within internal to the EAP method and are
   not exported.

   Once EAP mutual authentication completes and is successful, the
   secure association protocol is run between the peer and
   authenticator.  This derives fresh transient session keys (TSKs),
   provides  They remain valid only for the secure negotiation duration of the ciphersuite used to
   protect data, EAP
   conversation, and supports mutual proof of possession of are lost once the EAP conversation completes.

   EAP methods may also implement a cache for other local keying
   material which may persist for multiple EAP conversations.  For
   example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive
   and cache the TLS Master Secret, typically for substantial time
   periods.  The lifetime of other local keying material calculated
   within the EAP method is defined by the method.

2.3.2.  Exported Key Lifetimes

   All EAP methods generating keys are required to generate the MSK and
   EMSK, and may optionally generate the IV.  However, although new
   exported keys are generated during reauthentication, the lifetime of
   exported keys is conceptually distinct from the reauthentication
   time, since while reauthentication causes new exported keys to be
   derived, exported keys may be cached on the AAA-Key.

     +-+-+-+-+-+               +-+-+-+-+-+
     |         |               |         |
     | Cipher- |               | Cipher- |
     | Suite   |               | Suite   |
     |         |               |         |
     +-+-+-+-+-+               +-+-+-+-+-+
         ^                         ^
         |                         |
         V                         V
     +-+-+-+-+-+               +-+-+-+-+-+
     |         |               |         |
     |         |===============|         |
     |         |EAP, TEK Deriv.|Authenti-|
     |         |<------------->| cator   |
     |         |               |         |
     |         | Secure Assoc. |         |
     | peer    |<------------->| (EAP    |
     |         |===============| server) |
     |         | Link layer    |         |
     |         | (PPP,IEEE802) |         |
     |         |               |         |
     |MSK,EMSK |               |MSK,EMSK |
     | (TSKs)  |               |  (TSKs) |
     |         |               |         |
     +-+-+-+-+-+               +-+-+-+-+-+
         ^                         ^
         |                         |
         | MSK, EMSK               | and server after a
   session completes and therefore their lifetime may be greater than
   the reauthentication time.

   Although exported keys are generated by the EAP method, most existing
   EAP methods do not negotiate the lifetime of the exported keys.  EAP,
   defined in [RFC3748], also does not support the negotiation of
   lifetimes for exported keying material such as the MSK, EMSK
         |                         |
     +-+-+-+-+-+               +-+-+-+-+-+
     |         |               |         |
     | and IV.

   Several mechanisms exist for managing the lifetime of exported EAP
   keys.  Exported EAP keys may be cached on the EAP server as well as
   on the peer.  On the EAP server, it is RECOMMENDED that the lifetime
   of exported keys be managed as a system parameter.  Where the EAP
   method does not support the negotiation of the exported key lifetime,
   and where a negotiation mechanism is not provided by the lower lower,
   it is RECOMMENDED that the peer assume a default value of the
   exported key lifetime.  A value of 8 hours is suggested.

   Managing the lifetime of exported keys using a AAA attribute is NOT
   RECOMMENDED.  This is problematic because although this would ensure
   transport of the exported key lifetime between the AAA server and the
   authenticator,  the goal is to synchronize the exported key lifetime
   between the peer and EAP server.  Providing the the exported key
   lifetime on an per-session basis to the authenticator results in
   requiring the authenticator to maintain EAP-Key SA state.  As a
   described in Section 3, EAP-Key SA state is typically only maintained
   on the peer and server, so that this represents a substantial
   additional burden.

2.3.3.  Calculated Key Lifetimes

   When keying material exported by EAP methods is replaced, new
   calculated keys are also put in place.  Similarly, when the keying
   material exported by EAP methods expires, so do the calculated keys.
   As a result, the lifetime of keys calculated from material exported
   by EAP methods can be no larger than the lifetime of the keying
   material they are calculated from.  Since the lifetime of calculated
   keys can be less than that of the exported keys they are derived
   from, calculated key lifetimes are conceptually distinct from
   exported key lifetimes and reauthentication times, and need to be
   managed as a separate parameter.

   Note that just as the reauthentication time and the exported key
   lifetime are conceptually distinct parameters, so too are calculated
   key lifetimes conceptually distinct from the reauthentication time.

   Today AAA protocols such as RADIUS [RFC2865] support the Session-
   Timeout attribute.  As described in [RFC3580], this may be used to
   determine the maximum session time prior to reauthentication.  Since
   reauthentication results in the derivation of new exported keys and
   the transport of a new AAA-Key, while a session is in progress the
   maximum session time prior to reauthentication places an upper bound
   on the AAA-Key lifetime.

   However, after the session has terminated, it is possible for the
   AAA-Key to be cached on the authenticator.  Therefore the AAA-Key
   lifetime may be larger than the reauthentication time.  As a result,
   the AAA-Key lifetime needs to be managed as a separate parameter.

   Since the lifetime of the AAA-Key within the authenticator key cache
   is in part determined by authenticator resources, the AAA-Key
   lifetime is typically managed as a system parameter on the
   authenticator.  Since the authenticator may have considerably fewer
   resources than either the EAP peer or server, it is possible that
   AAA-Key lifetime on the authenticator may be less than exported key
   lifetime maintained by the server, or that the authenticator may need
   to reclaim AAA-Key resources prior to expiration of the AAA-Key
   lifetime.

   As a result, the primary issue with managing the AAA-Key lifetime is
   the determination by the peer whether a particular AAA-Key exists
   within the key cache of a given authenticator.  Transmitting the AAA-
   Key lifetime from the AAA server to the authenticator is not helpful
   in solving this problem in several important scenarios.

   Where the AAA-key lifetime is negotiated between the authenticator
   and the peer within the Secure Association Protocol, this may be used
   by the peer to manage the lifetime of the AAA-Key once the Secure
   Association Protocol has completed.

   However, should a time gap may exist between the time of completion
   of the EAP method and the initiation of the Secure Association
   Protocol, the lifetime of the AAA-Key cannot be determined by the
   peer during this period.  As a result, unless the Secure Association
   Protocol always follos the completion of the EAP method exchange
   without a gap in time, it may not be possible for the peer and
   authenticator to negotiate session-specific value of the AAA-Key
   lifetime.  For example, where EAP pre-authentication is used,  the
   AAA-Key may be derived and remain resident on the peer and
   authenticator prior to initiation of the Secure Association Protocol.

   However, if the AAA-Key lifetime is managed as an authenticator
   system parameter, it may be possible for lower layer solutions to
   bridge the gap. For example, the lower layer may utilize Discovery
   mechanisms to ensure AAA-Key cache synchronization between the peer
   and authenticator.

   If 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.

2.3.4.  TSK Key Lifetimes

   Since the TSKs depend on the AAA-Key, replacement of the AAA-Key
   implies replacement of the TSKs.  However, replacement of the TSKs
   only implies replacement of the AAA-Key when the TSKs are taken from
   a portion of the AAA-Key.

   Therefore while the lifetime of the TSKs may be shorter than or equal
   to the AAA-Key lifetime, the TSK lifetime cannot exceed the AAA-Key
   lifetime.  Where a Secure Association Protocol exists, it is possible
   for TSKs to be refreshed prior to reauthentication, and so the TSK
   Key Lifetime may also be shorter than or equal to the
   reauthentication timeout.  It is therefore RECOMMENDED that the TSK
   Key lifetime be managed parameter distinct from the reauthentication
   timeout and the AAA-Key lifetime (except where the TSK is taken from
   the AAA-Key).

   Where TSKs are established as the result of a Secure Association
   Protocol exchange, it is RECOMMENDED that the Secure Association
   Protocol include secure negotiation of the TSK lifetime between the
   peer and authenticator.  Where the TSK is taken from the AAA-Key,
   there is no need to manage the TSK lifetime as a separate parameter,
   since the TSK lifetime and AAA-Key lifetime are identical.

   As described in Section 3, TSKs are part of Service SAs which reside
   on the peer and authenticator and as with the AAA-Key lifetime, the
   TSK lifetime is often determined by authenticator resources.  As a
   result, the AAA server has no insight into the TSK derivation
   process, and by the principle of ciphersuite independence, it is not
   appropriate for the AAA server to manage any aspect of the TSK
   derivation process, including the TSK lifetime.

2.4.  AAA-Key Scope

   As described in Appendix E, the AAA-Key is calculated from the EMSK
   and MSK by the EAP peer and server, and is used as the root of the
   ciphersuite-specific key hierarchy.  Where a backend authentication
   server is present, the AAA-Key is transported from the EAP server to
   the authenticator; where it is not present, the AAA-Key is calculated
   on the authenticator.

   The AAA-Key is restricted to use between the EAP peer that calculates
   it, and the authenticator that either calculates it (where no backend
   authenticator is present) or receives it from the server (where a
   backend authenticator server is present).  However, in practice
   difficulties arise in ensuring that the AAA-Key is used only within
   the defined scope.

   A wide variety of authenticator and peer designs need to be
   accomodated within the EAP key management framework.  An
   authenticator may contain multiple physical ports; a single physical
   authenticator may, for the purpose of peer discovery, advertise
   itself as multiple "virtual authenticators"; authenticators may be
   compromised of multiple CPUs; authenticators may utilize clustering
   in order to provide load balancing or failover.  Similarly, a peer
   may support multiple ports; may support multiple CPUs; or may support
   clustering.

   As illustrated in Figure 1, an EAP peer with multiple ports may be
   attached to one or more authenticators, each with multiple ports.
   Where an authenticator identifies itself to the peer only via use of
   a port identifer (such as a link layer address), it may not be
   obvious to the peer which authenticator ports are associated with
   which authenticators.

   Similarly, where an EAP peer identifies itself using a port
   identifier (such as a link layer address), it may not be obvious to
   the authenticator which peer ports are associated with which peers.
   In such situations, the peer and authenticator may not be able to
   determine the appropriate AAA-Key scope.

   Additional issues arise when a single physical authenticator
   advertises itself as multiple "virtual authenticators".  In such a
   situation, the EAP peer may act as though each "virtual
   authenticator" represented a distinct physical authenticator, thereby
   restricting the AAA-Key to use with the "virtual authenticator" that
   it interacts with.  However, depending on the architecture of the
   physical AP, it may or may not share AAA-Keys between "virtual
   authenticators".  Once again, the peer and authenticator may not be
   in agreement on the AAA-key scope.

   This lack of synchronization may create security vulnerabilities.
   For example, where the AAA-Key is shared between "virtual
   authenticators" an EAP peer could authenticate with the "Guest"
   "virtual authenticator" and derive a AAA-Key.  The peer could then
   use that AAA-Key within the Secure Association Protocol in order to
   connect to the "Corporate Intranet" "virtual authenticator" within
   the same physical authenticator.  If the "virtual authenticators"
   share a AAA-Key cache, then the attempt will be successful.

   Several measures are recommended to address these issues:

[a]  Authenticators are REQUIRED to cache associated authorizations
     along with the AAA-Key and apply authorizations consistently.  This
     ensures that an attacker cannot obtain elevated privileges even
     where the AAA-Key cache is shared between "virtual authenticators".

[b]  It is RECOMMENDED that Secure Association Protocols utilize peer
     and authenticator identities that are unambiguous and do not
     incorporate implicit assumptions about peer and authenticator
     architectures.

     For example, using port-specific MAC addresses as identifiers is a
     particularly poor choice, given that peers and authenticators may
     have multiple ports.

[c]  It is RECOMMENDED that physical authenticators maintain separate
     AAA-Key caches for each "virtual authenticator".

[d]  Where a "virtual authenticator" is implemented, the AAA client MAY
     also be virtualized.  Where a "virtual AAA client" is implemented,
     each "virtual authenticator" identifies itself distinctly to the
     AAA server.  Where the AAA client and server communicate directly,
     this enables the AAA server to authenticate each "virtual AAA
     client" distinctly.

[e]  The AAA server and authenticator MAY implement additional
     attributes in order to further restrict the AAA-Key scope.  When
     this is done, it is RECOMMENDED that the Secure Association
     Protocol be extended to enable the restrictions to be communicated
     between the authenticator and the peer.  For example, in 802.11,
     the AAA server may provide the authenticator with a list of
     authorized Called-Station-Ids and/or SSIDs for which the  AAA-Key
     is valid, restricting the use of the AAA-Key by the peer.
     Similarly, the authenticator may provide the peer with a list of
     Calling-Station-Ids for which the AAA-Key is valid.

2.5.  Fast Handoff Support

   Within EAP, "fast handoff" is defined as a conversation in which the
   EAP exchange (phase 1a) and associated AAA passthrough is bypassed,
   so as to reduce latency.  Depending on the fast handoff mechanism,
   AAA-Key transport (phase 1b) may also be bypassed or it may be
   provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-
   aaaarch-handoff].

   The introduction of fast handoff creates a new class of security
   vulnerabilities as well as requirements for the secure handling of
   authorization context.

2.5.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 the offered
   service.

   As a part of the authentication process, the AAA network determines
   the user's authorization profile.  The user authorizations are
   transmitted by the backend authentication server to the EAP
   authenticator (also known as the Network Access Server or
   authenticator) included with the AAA-Token, which also contains the
   AAA-Key, in Phase 1b of the EAP conversation.  Typically, the profile
   is determined based on the user identity, but a certificate presented
   by the user may also provide authorization information.

   The backend authentication server is responsible for making a user
   authorization decision, answering the following questions:

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

[b]  Is this user allowed the type of access he or she is requesting?

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

[d]  Is this user within the 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 authorization decision is in principle simple, the process
   is complicated by the distributed nature of AAA decision making.
   Where brokering entities or proxies are involved, all of the AAA
   devices in the chain from the authenticator to the home AAA server
   are involved in the decision.  For instance, a broker can disallow
   access even if 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 and profiles as
   well as dynamic state (e.g. time of day or limits on the number of
   concurrent sessions).  In addition to the Accept/Reject decision made
   by the AAA chain, parameters or constraints can be communicated to
   the authenticator.

   The criteria for Accept/Reject decisions or the reasons for choosing
   particular authorizations are typically not communicated to the
   authenticator, only the final result.  As a result, the authenticator
   has no way to know what the decision was based on.  Was a set of
   authorization parameters sent because this service is always provided
   to the user, or was the decision based on the time/day and the
   capabilities of the requesting authenticator device?

2.5.2.  Correctness in Fast Handoff

   Bypassing all or portions of the AAA conversation creates challenges
   in ensuring that authorization 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 by
     changing the point of attachment.

[b]  Avoidance of privilege elevation.  A fast handoff should not result
     in a user being granted access to services which they are not
     entitled to.

[c]  Consideration of dynamic state.  In situations in which dynamic
     state is involved in the access decision (day/time, simultaneous
     session limit) it should be possible 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 a authenticator may not be aware
     of the criteria considered by a backend authentication server when
     allowing access, in order to ensure consistent authorization during
     a fast handoff it may be necessary to explicitly encode the
     restrictions within the authorizations provided in the AAA-Token.

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

     A fast handoff mechanism capable of addressing these concerns is
     said to be "correct".  One condition for correctness is as follows:
     For a fast handoff to be "correct" it MUST establish on the new
     device the same context as would have been created had the new
     device completed a AAA conversation with the authentication server.

     A properly designed fast handoff scheme will only succeed if it is
     "correct" in this way.  If a successful fast handoff would
     establish "incorrect" state, it is preferable for it to fail, in
     order to avoid creation of incorrect context.

     Some backend authentication server and authenticator configurations
     are incapable of meeting this definition of "correctness".  For
     example, if 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 which the
     authorizations returned in an Access-Accept message are contingent
     on the authenticator or on dynamic state such as the time of day or
     number of simultaneous sessions.  For example, in a heterogeneous
     deployment, the backend authentication server might return
     different authorizations depending on the authenticator making the
     request, in order to make sure that the requested service is
     consistent with the authenticator capabilities.

     If differences between the new and old device would result in the
     backend authentication server sending a different set of messages
     to the new device than were sent to the old device, then if the
     fast handoff mechanism bypasses AAA, then the fast handoff cannot
     be carried out correctly.

     For example, if some authenticator devices within a deployment
     support dynamic VLANs while others do not, then attributes present
     in the Access-Request (such as the authenticator-IP-Address,
     authenticator-Identifier, Vendor-Identifier, etc.) could be
     examined 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 server were
     to occur between a authenticator supporting dynamic VLANs and
     another authenticator which does not, then a guest user with access
     restricted to a guest VLAN could be given unrestricted access to
     the network.

     Similarly, in a network where access is restricted based on the day
     and time, Service Set Identifier (SSID), Calling-Station-Id or
     other factors, unless the restrictions are encoded within the
     authorizations, or a partial AAA conversation is included, then a
     fast handoff could result in the user bypassing the restrictions.

     In practice, these considerations limit the situations in which
     fast handoff mechanisms bypassing AAA can be expected to be
     successful.  Where the deployed devices implement the same set of
     services, it may be possible to do successful fast handoffs within
     such mechanisms.  However, where the supported services differ
     between devices, the fast handoff may not succeed.  For example,
     [RFC2865], section 1.1 states:

        "A authenticator that does not implement a given service MUST
        NOT implement the RADIUS attributes for that service.  For
        example, a authenticator that is unable to offer ARAP service
        MUST NOT implement the 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 attributes that are known,
     but not implemented.  For attributes that are unknown, section of 5
     of [RFC2865] states:

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

     In order to perform a correct fast handoff, if a new device is
     provided with RADIUS context for a known but unavailable service,
     then it MUST process this context the same way it would handle a
     RADIUS Access-Accept requesting an unavailable service.  This MUST
     cause the fast handoff to fail.  However, if a new device is
     provided with RADIUS context that indicates an unknown attribute,
     then this attribute MAY be ignored.

     Although it may seem somewhat counter-intuitive, failure is indeed
     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 a service that it
     does not implement.  This implies that if the new device were to
     complete a AAA conversation that it would be likely to receive
     different service instructions.  In such a case, failure of the
     fast handoff is the desired result.  This will cause the new device
     to go back to the AAA server in order to receive the appropriate
     service definition.

     In practice, this implies that fast handoff mechanisms which bypass
     AAA are most likely to be successful within a homogeneous device
     deployment within a single administrative domain. 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 be a failure, since if the
     handoff were blindly carried out, then the user would be moved from
     a secure to an insecure channel without permission from the backend
     authentication server.  Thus the definition of a "known but
     unsupported service" MUST encompass requests for unavailable
     security services.  This includes vendor-specific attributes
     related to security, such as those described in [RFC2548].

3.  Security Associations

   During EAP authentication and subsequent exchanges, four types of
   security associations (SAs) are created:

[1]  EAP method SA.  This SA is between the peer and EAP server.  It
     stores state that can be used for "fast resume" or other
     functionality in some EAP methods.  Not all EAP methods create such
     an SA.

[2]  EAP-Key SA.  This is an SA between the peer and EAP    |               | server, which
     is used to store the keying material exported by the EAP    |
     |  Method |               |  Method |
     |         |               |         |
     |(MK,TEKs)|               |(MK,TEKs)|
     |         |               |         |
     +-+-+-+-+-+               +-+-+-+-+-+

  Figure 3: Relationship method.
     Current EAP server implementations do not retain this SA after the
     EAP conversation completes, but future implementations could 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.  They permit the parties to mutually
     authenticate each other and protect the communications between
     them.

[4]  Service SA(s). These SAs are between the peer and authenticator,
     and they are created as a result of phases 1-2 of the conversation
     (see Section 1.3).

3.1.  EAP Method SA (peer - EAP server)

   An EAP method may store some state on the peer and EAP server even
   after phase 1a has completed.

   Typically, this is used for "fast resume": the peer and EAP server
   can confirm that they are still talking to the same party, perhaps
   using fewer roundtrips or less computational power.  In this case,
   the EAP method SA is essentially a cache for performance
   optimization, and either party may remove the 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 original EAP method SA is lost),
   but may be stored for longer periods of time.

   The EAP method SA is not restricted to a particular service or
   authenticator (acting as and is most useful when the peer accesses many
   different authenticators.

   An EAP method is responsible for specifying how the parties select if
   an existing EAP server), where no method SA should be used, and if so, which one.
   Where multiple backend authentication server is present.

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

  Figure 4:  Pass-through relationship method
   SAs are not typically synchronized between them.

   EAP method implementations should consider the appropriate lifetime
   for the EAP method SA.  "Fast resume" assumes that the information
   required (primarily the keys in the EAP peer, authenticator
                   and backend method SA) hasn't been
   compromised.  In case the original authentication server.

   Where these conditions cannot be met, was carried out
   using, for instance, a backend authentication server
   is smart card, it may be easier to compromise the
   EAP method SA (stored on the PC, for instance), so typically required. In this exchange, as described in [RFC3579], the authenticator acts as EAP
   method SAs have a pass-through between limited lifetime.

   Contents:

      o  Implicitly, the EAP peer and a
   backend authentication server.  In method this model, the authenticator
   delegates the access control decision SA refers to
      o  One or more internal (non-exported) keys
      o  EAP method SA name
      o  SA lifetime

3.1.1.  Example: EAP-TLS

   In EAP-TLS [RFC2716], after the backend EAP authentication
   server, which acts as a Key Distribution Center (KDC), supplying
   keying material to both the EAP peer client (peer)
   and authenticator.

   Figure 4 illustrates server can store the case where following information:

      o  Implicitly, the authenticator acts as a
   pass-through. Here EAP is spoken between method this SA refers to (EAP-TLS)
      o  Session identifier (a value selected by the peer server)
      o  Certificate of the other party (server stores the clients's
         certificate and authenticator
   as before.  The authenticator then encapsulates EAP packets within a
   AAA protocol such vice versa)
      o  Ciphersuite and compression method
      o  TLS Master secret (known as RADIUS [RFC3579] the EAP-TLS Master Key or Diameter [I-D.ietf-aaa-eap],
   and forwards packets to and from MK)
      o  SA lifetime (ensuring that the backend authentication server,
   which acts as SA is not stored forever)
      o  If the EAP server. Since client has multiple different credentials (certificates
         and corresponding private keys), a pointer to those credentials

   When the authenticator acts as a
   pass-through, EAP methods (as well as server initiates EAP-TLS, the derived EAP Master Key, and
   TEKs) reside only client can look up the EAP-TLS
   SA based on the peer credentials it was going to use (certificate and backend authentication server.

   On completion
   private key), and the expected credentials (certificate or name) of a successful authentication, EAP methods on
   the EAP
   peer server.  If an EAP-TLS SA exists, and EAP it is not too old, the
   client informs the server export about the Master Session Key (MSK) and Extended
   Master Session Key (EMSK). existence of this SA by including
   its Session-Id in the TLS ClientHello message.  The backend authentication server then
   sends a message to looks
   up the authenticator indicating correct SA based on the Session-Id (or detects 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
   has been successful, providing the AAA-Key within a protected package
   known as the AAA-Token.  Along with the keying material,
   client and server can store the
   AAA-Token contains attributes naming following information:

      o  Implicitly, the enclosed keys and providing
   context.

   The MSK and EMSK are used EAP method this SA refers to derive the AAA-Key and (EAP-AKA)
      o  A re-authentication pseudonym
      o  The client's permanent identity (IMSI) (server)
      o  Replay protection counter
      o  Authentication key name which
   are enclosed within (K_aut)
      o  Encryption key (K_encr)
      o  Original Master Key (MK)
      o  SA lifetime (ensuring that the AAA-Token, transported to SA is not stored forever)

   When the  NAS by server initiates EAP-AKA, the AAA
   server, and used within client can look up the EAP-AKA
   SA based on the credentials it was going to use (permanent identity).
   If an EAP-AKA SA exists, and it is not too old, the secure association protocol for
   derivation of Transient Session Keys (TSKs) required for client informs
   the
   negotiated ciphersuite. The TSKs are known only to server about the peer and
   authenticator.

3. Security Associations

   EAP key management involves four types existence of security associations
   (SAs):

   [1] this SA by sending its re-
   authentication pseudonym as its identity in EAP SA. Identity Response
   message, instead of its permanent identity.  The server then looks up
   the correct SA based on this identity.

3.2.  EAP-key SA

   This is an SA between the peer and EAP server, which
       allows them is used to authenticate each other.

   [2] store
   the keying material exported by the EAP method SA.  This method.  Current EAP server
   implementations do not retain this SA is also between after the peer and EAP server.
       It stores state that can be used conversation
   completes, but future implementations could use this SA for "fast resume" or other
       functionality in pre-
   emptive key distribution.

   Contents:

      o  Name/identifier for this SA
      o  Identities of the parties
      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, they need to store some EAP methods.  Not all EAP methods create
       such an SA.

   [3] EAP-Key SA.  This is an information.

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

3.3.1.  Example: RADIUS

   In RADIUS, where shared secret authentication is used, the peer client and
   server store each other's IP address and the shared secret, which is
   used to calculate the Response Authenticator [RFC2865] and EAP server, which Message-
   Authenticator [RFC3579] values, and to encrypt some attributes (such
   as the AAA-Key [RFC2548]).

   Where IPsec is used to store the keying material exported by the EAP method.
       Current EAP server implementations do not retain this SA after
       the EAP conversation completes, but future implementations could
       use this SA protect RADIUS [RFC3579] and IKE is used for pre-emptive
   key distribution.

   [4] AAA SA(s).  These SAs are between management, the authenticator parties store information necessary to
   authenticate and authorize the
       backend authentication server.  They permit other party (e.g. certificates, trust
   anchors and names).  The IKE exchange results in IKE Phase 1 and
   Phase 2 SAs containing information used to protect the conversation
   (session keys, selected ciphersuite, etc.)

3.3.2.  Example: Diameter with TLS

   When using Diameter protected by TLS, the parties store information
   necessary to
       mutually authenticate each and authorize the other party (e.g.
   certificates, trust anchors and names).  The TLS handshake results in
   a short-term TLS SA that contains information used to protect the
   actual communications
       between them.

3.1 EAP SA (session keys, selected TLS ciphersuite, etc.).

3.4.  Service SA(s) (peer - EAP server)

   In order for authenticator)

   The service SA stores information about the peer and EAP service being provided.
   This includes:

      o  Service parameters (or at least those parameters
         that are still needed)
      o  On the authenticator, service authorization
         information received from the backend authentication
         server to authenticate each other, they
   need to store some (or necessary parts of it)
      o  On the peer, usually locally configured service
         authorization information.
      o  Transient Session Keys used to protect the communication
      o  The authentication AAA-Key, if it can be based on needed again (to refresh
         and/or resynchronize other keys or for another reason)
      o  AAA-Key lifetime

   The information in the service SA can be grouped into several
   different mechanisms, such as
   shared secrets or certificates.  If SAs. This would make sense if, for instance, the authentication service
   provided is based naturally divided into several different subconversations
   with different parameters.

   How exactly the relevant service SA is chosen at each point depends
   on a
   shared secret key, the parties store protocol; see below for examples.

3.4.1.  Example: 802.11i

   [IEEE802.11i] Section 8.4.1.1 defines the EAP method to be security associations used and
   the key.  The EAP server also stores
   within IEEE 802.11.  A summary follows; the peer's identity and/or other
   information necessary to decide whether access to some service standard should be granted.
   consulted for details.

   o Pairwise Master Key Security Association (PMKSA)

      The peer stores information necessary to choose which
   secret to use PMKSA is a bi-directional SA, used by both parties for which service.

3.2 EAP method SA (peer - EAP server)

   An EAP method may store some state sending
      and receiving.  It is created on the peer and when EAP server even
   after phase 1a has completed.

   Typically, this authentication
      completes successfully or a pre-shared key is used for "fast resume": configured.  The
      PMKSA is created on the peer and EAP server
   can confirm that they are still talking to authenticator when the same party, perhaps
   using fewer roundtrips PMK is received or less computational power.  In this case,
      created on the EAP method SA is essentially authenticator or a cache pre-shared key is configured.
      The PMKSA is used to create the PTKSA.  PMKSAs are cached for performance
   optimization, and either party may remove
      their lifetimes.  The PMKSA consists of the SA from its cache at
   any point.

   An EAP method may also keep state in order to support pseudonym-based
   identity protection. following elements:

      - PMKID (security association identifier)
      - Authenticator MAC address
      - PMK
      - Lifetime
      - Authenticated Key Management Protocol (AKMP)
      - Authorization parameters specified the AAA server or
        by local configuration.  This is typically a cache can include
        parameters such as well (the the peer's authorized SSID.
        On the peer, this information can be recreated if the original EAP method SA is lost),
   but may be stored for longer periods of time.

   The EAP method SA is not restricted 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 it when a particular service or
   authenticator and new four-way handshake is most useful when done
      - Reference to accounting context (the details of which depend
        on the peer accesses many
   different authenticators.

   An EAP method accounting protocol used, and various 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 is responsible for specifying how the parties select if
   an existing EAP method a bi-directional SA should created as the result of a
      successful four-way handshake.  There may only be used, one PTKSA
      between a pair of peer and if so, which one.
   Where multiple backend authentication servers are used, EAP method
   SAs authenticator MAC addresses.  PTKSAs
      are not typically synchronized between them.

   EAP method implementations should consider cached for the appropriate lifetime
   for of the EAP method SA.  "Fast resume" assumes that PMKSA.  Since the PTKSA is tied
      to the PMKSA, it only has the addititional information
   required (primarily from the keys in
      4-way handshake.  The PTKSA consists of the EAP method SA) hasn't been
   compromised.  In case following:

         - Key (PTK)
         - Selected ciphersuite
         - MAC addresses of the original authentication was carried out
   using, for instance, a smart card, it may be easier parties
         - Replay counters, and ciphersuite specific state
         - Reference to compromise the
   EAP method PMKSA: This is 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 GTKSA is a uni-directional SA (stored created based on the PC, for instance), so typically four-way
      handshake or the EAP
   method SAs have a limited lifetime.

   Contents:
   o  Implicitly, group key handshake.  A GTKSA consists of the EAP method this SA refers
      following:

         - Direction vector (whether the GTK is used for transmit or receive)
         - Group cipher suite selector
         - Key (GTK)
         - Authenticator MAC addres
         - Via reference to
   o  One PMKSA, or more internal (non-exported) keys copied here:
           o  EAP method SA name Authorization parameters
           o  SA lifetime

3.2.1 Reference to accounting context

3.4.2.  Example: EAP-TLS

   In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
   and server can store the following information:

   o  Implicitly, the EAP method IKEv2/IPsec

   Note that this SA refers example is intended to (EAP-TLS)
   o  Session identifier (a value selected by the server) be informative, and it does not
   necessarily include all information stored.

o  Certificate IKEv2 SA

   - Protocol version
   - Identitities of the other party (server stores 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 clients's
      certificate and vice versa)
   o  Ciphersuite and compression method
   o  TLS Master secret (known as authenticator, service authorization information
     received from the EAP-TLS Master Key or MK)
   o  SA lifetime (ensuring that backend authentication server.

When processing an incoming message, the correct SA is not stored forever) looked up based
on 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 is looked up based 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 how
   changing service elements is handled. Some approaches include:

Transparent sharing
     If the client has multiple different credentials (certificates and
      corresponding private keys), a pointer service parameters visible to those credentials

   When the server initiates EAP-TLS, other party (either peer
     or authenticator) do not change, the client service can look up be moved without
     requiring cooperation from the EAP-TLS
   SA based other party.

     Whether such a move should be supported or used depends on the credentials it was going to use (certificate and
   private key),
     implementation and the expected credentials (certificate or name) of
   the server.  If administrative considerations. For instance, an EAP-TLS SA exists, and it is not too old, the
   client informs the server about the existence
     administrator may decide to configure a group of this SA by including
   its Session-Id IKEv2/IPsec
     gateways in a cluster for high-availability purposes, if the TLS ClientHello message.
     implementation used supports this. The server then looks
   up peer does not necessarily
     have any way of knowing when the correct SA based on change occurs.

No sharing
     If the Session-Id (or detects that service parameters require changing, some changes may
     require terminating the old service, and starting a new
     conversation from phase 0. This approach is used by all services
     for at least some parameters, and it doesn't
   yet have one).

3.2.2 Example: EAP-AKA

   In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication require any protocol
     for transferring the
   client and server can store service SA between the following information:

   o  Implicitly, service elements.

     The service may support keeping the EAP method this SA refers old service element active
     while the new conversation takes phase, to (EAP-AKA)
   o  A re-authentication pseudonym
   o  The client's permanent identity (IMSI) (server)
   o  Replay protection counter
   o  Authentication key (K_aut)
   o  Encryption key (K_encr)
   o  Original Master Key (MK)
   o  SA lifetime (ensuring that decrease the SA is not stored forever)

   When time the server initiates EAP-AKA,
     service is not available.

Some sharing
     The service may allow changing some parameters by simply agreeing
     about the client can look up new values. This may involve a similar exchange as in
     phase 2, or perhaps a shorter conversation.

     This option usually requires some protocol for transferring the EAP-AKA
     service SA based on between the credentials it was going elements. An administrator may decide not to use (permanent identity).
   If an EAP-AKA SA exists,
     enable this feature at all, and it typically the sharing is restricted
     to some particular service elements (defined either by a service
     parameter, or simple administrative decision). If the old and new
     service element do not too old, support such "context transfer", this
     approach falls back to the client informs previous option (no transfer).

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

     Note that these considerations are not limited to service
     parameters related to the existence of this SA by sending its
   re-authentication pseudonym authenticator--they apply to peer's
     parameters as its identity in EAP Identity Response
   message, instead well.

3.5.  SA Naming

   In order to support the correct processing of its permanent identity.  The server then looks up phase 2 security
   associations, the Secure Association (phase 2) protocol supports the
   naming of phase 2 security associations and associated transient
   session keys, so that the correct SA based on this identity.

3.3 EAP-key SA

   This is an SA set of transient session keys can
   be identified for processing a given packet.  Explicit creation and
   deletion operations are also typically supported so that
   establishment and re-establishment of transient session keys can be
   synchronized between the parties.

   In order to securely bind the AAA SA (phase 1b) to its child phase 2
   security associations, the phase 2 Secure Association Protocol allows
   the EAP peer and EAP server, which is used authenticator to store
   the keying material exported by mutually prove possession of the EAP method.  Current EAP server
   implementations do not retain this SA after
   AAA-Key.  In order to avoid confusion in the case where an EAP conversation
   completes, but future implementations could use this SA peer
   has more than one AAA-Key (phase 1b) applicable to establishment of a
   phase 2 security association, it is necessary for
   pre-emptive the secure
   Association Protocol (phase 2) to support key distribution.

   Contents:
   o  Name/identifier for this SA
   o  Identities of selection, so that the
   appropriate phase 1b keying material can be utilized by both parties
   o  MSK and EMSK

3.4 AAA SA(s) (authenticator - backend auth. server)

   In order for
   in the authenticator and backend authentication server to
   authenticate each other, they need Secure Association Protocol exchange.

   For example, a peer might be pre-configured with policy indicating
   the ciphersuite to store some information.

   In case be used in communicating with a given
   authenticator.  Within PPP, 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.4.1 Example: RADIUS

   In RADIUS, where shared secret authentication ciphersuite is used, the client and
   server store each other's IP address and negotiated within the shared secret, which
   Encryption Control Protocol (ECP), after EAP authentication is
   used to calculate
   completed.  Within [IEEE80211i], the Response Authenticator [RFC2865] AP ciphersuites are advertised
   in the Beacon and
   Message-Authenticator [RFC3579] values, Probe Responses, and to encrypt some
   attributes (such as are securely verified during a
   4-way exchange after EAP authentication has completed.

   As part of the AAA-Key [RFC2548]).

   Where IPsec is used to protect RADIUS [RFC3579] and IKE Secure Association Protocol (phase 2), it is used for
   key management, the parties store information necessary
   to
   authenticate and authorize bind the other party (e.g. certificates, trust
   anchors and names).  The IKE exchange results in IKE Phase 1 and
   Phase 2 SAs containing information used Transient Session Keys (TSKs) to protect the conversation
   (session keys, selected ciphersuite, etc.)

3.4.2 Example: Diameter with TLS

   When using Diameter protected by TLS, keying material
   provided in the parties store information
   necessary to authenticate and authorize AAA-Token.  This ensures that the other party (e.g.
   certificates, trust anchors EAP peer and names).  The TLS handshake results in
   a short-term TLS SA that contains information used
   authenticator are both clear about what key to protect use to provide mutual
   proof of possession.

   Keys within the
   actual communications (session keys, selected TLS ciphersuite, etc.).

3.5 Unicast Secure Association EAP key hierarchy are named as follows:

EAP SA name
     The unicast secure EAP security association SA exists is negotiated between the EAP peer and
   authenticator.  It includes:

      the
     EAP server, and is uniquely named as follows <EAP peer port identifier (Calling-Station-Id)
      the NAS port identifier (Called-Station-Id)
      the unicast Transient Session Keys (TSKs) name, EAP
     server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
     Here the unicast secure association EAP peer nonce name and EAP server name are the unicast secure association authenticator nonce identifiers
     securely exchanged within the negotiated unicast capabilities EAP method.  Since multiple EAP SAs
     may exist between an EAP peer and unicast ciphersuite.

   During the phase 2a exchange, EAP server, the EAP peer nonce
     and authenticator
   demonstrate mutual possession EAP server nonce allow EAP SAs to be differentiated.  The
     inclusion of the AAA-Key derived and transported Method Type in phase 1; securely negotiate the session capabilities (including
   unicast ciphersuites), and derive fresh unicast transient session
   keys. EAP SA name ensures that each
     EAP method has a distinct EAP SA space.

AAA-Key Name
     The AAA-Key SA (phase 1b) is therefore used to create named by the
   unicast secure association concatenation of the EAP SA (phase 2a), name, "AAA-
     Key" and in the process authenticator name, since the
   phase 2a unicast secure association SA AAA-Key is bound to ports on the EAP
   peer and a
     particular authenticator.  However in  For the purpose of identification, the
     NAS-Identifier attribute is recommended.  In order for a phase 2a security
   association to be established, it is not necessary for ensure that
     all parties can agree on the phase 1a
   exchange NAS name this requires the NAS to be rerun each time.  This enables
     advertise its name (typically using a media-specific mechanism,
     such as the 802.11 Beacon/Probe Response)."

4.  Security considerations

4.1.  Security Terminology

Cryptographic binding
     The demonstration of the EAP exchange peer to be
   bypassed when fast handoff support is desired.

   Since both the EAP server that a single
     entity has acted as the EAP peer and authenticator nonces are used in for all methods executed within a
     tunnel method.  Binding MAY also imply that the creation of EAP server
     demonstrates to the unicast secure association SA, peer that a single entity has acted as the transient session EAP
     server for all methods executed within a tunnel method.  If
     executed correctly, binding serves to mitigate man-in-the-middle
     vulnerabilities.

Cryptographic separation
     Two keys (TSKs) (x and y) are guaranteed to be fresh, even "cryptographically separate" if an adversary
     that knows all messages exchanged in the AAA-Key is not.  As a result
   one protocol cannot compute x
     from y or more unicast secure association SAs (phase 2a) may be derived y from a single AAA-Key SA (phase 1b).  The phase 2a security
   associations may utilize x without "breaking" some cryptographic
     assumption.  In particular, this definition allows that the same security parameters (e.g. mode,
   ciphersuite, etc.) or they may utilize different parameters.

   A unicast secure association SA (phase 2a) may not persist longer
   than
     adversary has the maximum lifetime knowledge of its parent AAA-Key SA (if known).
   However, all nonces sent in cleartext as well
     as all predictable counter values used in the deletion of protocol.  Breaking a parent EAP
     cryptographic assumption would typically require inverting a one-
     way function or AAA-Key SA does not
   necessarily imply deletion of the corresponding unicast secure
   association SA.  Similarly, predicting the deletion outcome of a unicast secure
   association protocol SA does not imply the deletion cryptographic pseudo-
     random number generator without knowledge of the parent
   AAA-key SA or EAP SA.  Failure to mutually prove possession of secret state.  In
     other words, if the
   AAA-Key during keys are cryptographically separate, there is
     no shortcut to compute x from y or y from x, but the unicast secure association protocol exchange
   (phase 2a) need not be grounds for removal of a AAA-Key SA by both
   parties; rate-limiting unicast secure association exchanges should
   suffice work an
     adversary must do to prevent a brute force attack.

   An EAP peer may be able perform this computation is equivalent to negotiate multiple phase 2a SAs with a
   single EAP authenticator, or may be able
     performing exhaustive search for the secret state value.

Key strength
     If the effective key strength is N bits, the best currently known
     methods to maintain multiple phase
   2a SAs with multiple authenticators, based recover the key (with non-negligible probability)
     require on average an effort comparable to 2^(N-1) operations of a single
     typical block cipher.

Mutual authentication
     This refers to an EAP SA derived method in phase 1a. For example, during a re-key of which, within an interlocked
     exchange, the secure association
   protocol SA, it is possible for two phase 2a SAs to exist during authenticator authenticates the
   period between when peer and the new phase 2a SA parameters (such peer
     authenticates the authenticator.  Two independent one-way methods,
     running in opposite directions do not provide mutual authentication
     as defined here.

4.2.  Threat Model

   The EAP threat model is described in [RFC3748], Section 7.1.  In
   order to address these threats, EAP relies on the TSKs) security properties
   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 calculated described in [WLANREQ].

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

   Given the unicast secure association
   protocol, it should not be assumed that the installation of a new
   phase 2a SA necessarily implies deletion existing documentation of the old phase 2a SA.

   On some media (e.g. 802.11) a port on an EAP peer may only establish
   phase 2a and 2b SAs with a single port of AAA threat models and
   responses, there is no need to duplicate that 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 modify or spoof Secure Association Protocol
     packets.

[2]  An attacker compromising an authenticator within may provide incorrect
     information to the EAP peer and/or server via out-of-band
     mechanisms (such as via a
   given Local Area Network (LAN). AAA or lower layer protocol).  This implies that
     includes impersonating another authenticator, or providing
     inconsistent information to the successful
   negotiation of phase 2a and/or 2b SAs between an EAP peer port and a
   new authentiator port EAP server.

[3]  An attacker may attempt to perform downgrading attacks on the
     ciphersuite negotiation within a given LAN implies the deletion of
   existing phase 2a and 2b SAs with authenticators offering access Secure Association Protocol in
     order to ensure that Local Area Network (LAN).  However, since a given IEEE 802.11
   SSID weaker ciphersuite is used to protect data.

   Depending on the lower layer, these attacks may be comprised of multiple LANs, this does not imply an
   implicit binding of phase 2a and 2b SAs carried out
   without requiring physical proximity.

   In order to an SSID.

3.6 Multicast Secure Association SA

   The multicast secure association SA includes: address these threats, [Housley56] describes the multicast Transient Session Keys
   mandatory system security properties:

Algorithm independence
     Wherever cryptographic algorithms are chosen, the direction vector (for algorithms must
     be negotiable, in order to provide resilient against compromise of
     a uni-directional SA) particular algorithm.  Algorithm independence must be
     demonstrated within all aspects of the negotiated multicast capabilities system, including within
     EAP, AAA and multicast ciphersuite

   It is possible the Secure Association Protocol.  However, for more than
     interoperability, at least one multicast secure association SA to suite of algorithms MUST be derived from a single unicast secure association SA.   However, a
   multicast secure association SA is bound
     implemented.

Strong, fresh session keys
     Session keys must be demonstrated to a single EAP SA be strong and a
   single AAA-Key SA.

   During a re-key of the multicast secure association protocol SA, it
   is possible for two phase 2b SAs to exist during the period between
   when the new phase 2b SA parameters (such as fresh in all
     circumstances, while at the multicast TSKs) are
   calculated same time retaining algorithm
     independence.

Replay protection
     All protocol exchanges must be replay protected.  This includes
     exchanges within EAP, AAA, and when they are installed.  Except where explicitly
   specified by the semantics Secure Association Protocol.

Authentication
     All parties need to be authenticated.  The confidentiality of the multicast secure association
   protocol, it should not
     authenticator must be assumed that the installation of a new
   phase 2b SA necessarily implies deletion maintained.  No plaintext passwords are
     allowed.

Authorization
     EAP peer and authenticator authorization must be performed.

Session keys
     Confidentiality of the old phase 2b SA.

   A multicast secure association SA (phase 2b) may not persist longer
   than the maximum lifetime session keys must be maintained.

Ciphersuite negotiation
     The selection of its parent AAA-Key or unicast secure
   association SA. However, the deletion "best" ciphersuite must be securely confirmed.

Unique naming
     Session keys must be uniquely named.

Domino effect
     Compromise of a parent EAP, AAA-Key or
   unicast secure association SA does not necessarily imply deletion single authenticator cannot compromise any other
     part of the corresponding multicast secure association SA.  For example, a
   unicast secure association SA may system, including session keys and long-term secrets.

Key binding
     The key must be rekeyed without implying a rekey
   of the multicast secure association SA.

   Similarly, bound to the deletion of a multicast secure association protocol SA
   does not imply appropriate context.

4.3.  Security Analysis

   Figure 6 illustrates the deletion of relationship between the parent EAP, AAA-Key or unicast
   secure association SA.  Failure to mutually prove possession 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 are largely determined by
   the
   AAA-Key during the unicast secure association protocol exchange
   (phase 2a) need not be grounds for removal of chosen EAP method.  Method security claims are described in
   [RFC3748] Section 7.2.  These include the AAA-Key, unicast
   secure association  key strength, protected
   ciphersuite negotiation, mutual authentication, integrity protection,
   replay protection, confidentiality, key derivation, key strength,
   dictionary attack resistance, fast reconnect, cryptographic binding,
   session independence, fragmentation and multicast secure association SAs;
   rate-limiting unicast secure association exchanges should suffice to
   prevent channel binding claims.  At a brute force attack.

3.7 Key Naming

   In order
   minimum, methods claiming 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 the correct processing of phase 2 security
   associations, the secure association (phase 2) protocol supports EAP peer and the
   naming EAP Server.

   Ciphersuite independence is also required:

      Keying material exported by EAP methods MUST be independent of phase 2 security associations and associated transient
   session keys, so that the correct set
      ciphersuite negotiated to protect data.

   In terms of transient session keys can
   be identified for processing a given packet.  Explicit creation and
   deletion operations are also typically supported so that
   establishment key strength and re-establishment freshness, [RFC3748] Section 10 says:

      EAP methods SHOULD ensure the freshness of transient session keys can be
   synchronized between the parties. MSK and EMSK even
      in cases where one party may not have a high quality random number
      generator.... In order to securely bind preserve algorithm independence, EAP
      methods deriving keys SHOULD support (and document) the AAA SA (phase 1b) to its child phase 2
   security associations, protected
      negotiation of the phase 2 secure association protocol allows ciphersuite used to protect the EAP peer and authenticator to mutually prove possession of
      conversation between the
   AAA-Key. peer and server...  In order to avoid confusion in the case where an enable
      deployments requiring strong keys, EAP peer
   has more than one AAA-Key (phase 1b) applicable to establishment methods supporting key
      derivation SHOULD be capable of generating an MSK and EMSK, each
      with an effective key strength of at least 128 bits.

   The authenticator and backend authentication server communicate using
   a
   phase 2 security association, it is necessary for the secure
   association AAA protocol (phase 2) to support key selection, so that the
   appropriate phase 1b keying material can such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
   eap].  As noted in [RFC3588] Section 13, Diameter must be utilized protected
   by both parties
   in the secure association protocol exchange.

   For example, either IPsec ESP with non-null transform or TLS.  As a peer might result,
   Diameter requires per-packet integrity and confidentiality.  Replay
   protection must be pre-configured with policy indicating
   the ciphersuite to supported.  For RADIUS, [RFC3579] Section 4.2
   recommends that RADIUS be used in communicating protected by IPsec ESP with a given
   authenticator. Within PPP, the ciphersuite non-null
   transform, and where IPsec is negotiated within implemented replay protection must be
   supported.

   The peer and authenticator communicate using the
   Encryption Control Protocol (ECP), after EAP authentication is
   completed.  Within [IEEE80211i], Secure Association
   Protocol.

   As noted in the AP ciphersuites are advertised figure, each party in the Beacon and Probe Responses, and are securely verified during a
   4-way exchange after EAP authentication has completed.

   As part mutually
   authenticates with each of the secure association protocol (phase 2), it is necessary
   to bind the Transient Session Keys (TSKs) to the keying material
   provided other parties, and derives a unique
   key.  All parties in the AAA-Token.  This ensures that diagram have access to the AAA-Key.

   The EAP peer and
   authenticator backend authentication server mutually authenticate
   via the EAP method, and derive the TEKs and EMSK which are both clear about what key known only
   to use them. The TEKs are used to provide mutual
   proof protect some or all of possession.  Keys within the EAP key hierarchy are named as
   follows:

   EAP SA name
      The EAP security association is negotiated
   conversation between the EAP peer and authenticator, so as to guard
   against modification or insertion of EAP server, and packets by an attacker.  The
   degree of protection afforded by the TEKs is uniquely named as follows <EAP peer name, determined by the EAP server name,
   method; some methods may protect the entire EAP Method Type, packet, including the
   EAP peer nonce, header, while other methods may only protect the contents of the
   Type-Data field, defined in [RFC3748].

   Since EAP server
      nonce>.  Here is spoken only between the EAP peer name and EAP server, if a
   backend authentication server name are the
      identifiers securely exchanged within is present then the EAP method.  Since
      multiple EAP SAs may exist conversation
   does not provide mutual authentication between an EAP the peer and EAP server,
   authenticator, only between the EAP peer nonce and EAP server nonce allow EAP SAs to be
      differentiated.  The inclusion of (backend
   authentication server).  As a result, mutual authentication between
   the Method Type in peer and authenticator only occurs where a Secure Association
   protocol is used, such the EAP SA
      name ensures unicast and group key derivation handshake
   supported in [IEEE80211i].  This means that each EAP method has absent use of a distinct EAP SA space.

   MK Name
      The EAP Master Key, if supported by an secure
   Association Protocol, from the point of view of the peer, EAP method, mutual
   authentication only proves that the authenticator is named trusted by the
      concatenation
   backend authentication server; the identity of the EAP SA name and a method-specific session-id.

   AAA-Key Name
      The AAA-Key authenticator is named by the concatenation of
   not confirmed.

   Utilizing the EAP SA name,
      "AAA-Key" and AAA protocol, the authenticator name, since the and backend
   authentication server mutually authenticate and derive session keys
   known only to them, used to provide per-packet integrity and replay
   protection, authentication and confidentiality.  The AAA-Key is bound
      to a particular authenticator.  For the purpose of identification,
   distributed by the NAS-Identifier attribute is recommended.  In order backend authentication server to ensure
      that all parties can agree on the NAS name authenticator
   over this requires the NAS channel, bound to advertise attributes constraining its name (typically using a media-specific mechanism,
      such usage, as
   part of the 802.11 Beacon/Probe Response)."

4. Threat Model

4.1 Security Assumptions

   Figure 5 illustrates AAA-Token.  The binding of attributes to the relationship between AAA-Key
   within a protected package is important so the peer, authenticator
   receiving the AAA-Token can determine that it has not been
   compromised, and backend authentication server. As noted in that the figure, each party keying material has not been replayed, or
   mis-directed in some way.

   The security properties of the EAP exchange mutually authenticates with are dependent on each leg
   of the other
   parties, and derives a unique key.  All parties in the diagram have
   access to the AAA-Key.

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

               Figure 5: Three-party EAP key distribution

   The EAP peer and backend authentication server mutually authenticate
   via triangle: the selected EAP method, AAA protocol and derive the MK, TEKs Secure
   Association Protocol.

   Assuming that the AAA protocol provides protection against rogue
   authenticators forging their identity, then the AAA-Token can be
   assumed to be sent to the correct authenticator, and EMSK which are known
   only where it is
   wrapped appropriately, it can be assumed to them. The TEKs are used be immune to protect some or all of compromise
   by a snooping attacker.

   Where an untrusted AAA intermediary is present,  the EAP
   conversation between AAA-Token must
   not be provided to the peer and authenticator, intermediary so as to guard
   against modification or insertion of EAP packets by an attacker.  The
   degree avoid compromise of protection afforded by the TEKs is determined
   AAA-Token.  This can be avoided by the use of re-direct as defined in
   [RFC3588].

   When EAP
   method; some methods may protect is used for authentication on PPP or wired IEEE 802
   networks, it is typically assumed that the entire EAP packet, including link is physically secure,
   so that an attacker cannot gain access to the link, or insert a rogue
   device. EAP header, while other methods may only protect the contents of the
   Type-Data field, defined in [I-D.ietf-eap-rfc2284bis].

   Since EAP is spoken only between the [RFC3748] reflect this usage model.
   These include EAP peer MD5, as well as One-Time Password (OTP) and server, if a
   backend Generic
   Token Card.  These methods support one-way authentication server is present then the (from EAP conversation
   does
   peer to authenticator) but not provide mutual authentication between or key
   derivation.  As a result, these methods do not bind the peer initial
   authentication and
   authenticator, only between subsequent data traffic, even when the EAP peer the
   ciphersuite used to protect data supports per-packet authentication
   and integrity protection. As a result, EAP server (backend methods not supporting
   mutual authentication server). are vulnerable to session hijacking as well as
   attacks by rogue devices.

   On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
   become easy 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 between
   the peer and authenticator only occurs where a secure association
   protocol is used, key
   derivation, provided by methods such as EAP-TLS [RFC2716] are
   required [IEEE80211i], so as to address the unicast and group key derivation handshake
   supported in [IEEE80211i].  This means that absent use threat of a secure
   association protocol, from rogue devices,
   and provide keying material to bind the point of view of initial authentication to
   subsequent data traffic.

   If the peer, selected EAP method does not support mutual
   authentication only proves that authentication,
   then the authenticator is trusted peer will be vulnerable to attack by the rogue authenticators
   and backend authentication server; the identity of servers. If the authenticator is EAP method does not confirmed.

   Utilizing the AAA protocol, the authenticator derive
   keys, then TSKs will not be available for use with a negotiated
   ciphersuite, and backend there will be no binding between the initial EAP
   authentication server mutually authenticate and derive subsequent data traffic, leaving the session keys
   known only to them, used
   vulnerable to provide per-packet integrity and replay
   protection, authentication and confidentiality.  The MSK is
   distributed by hijack.

   If the backend authentication server to the does not protect against
   authenticator
   over this channel, bound to attributes constraining its usage, as
   part of masquerade, or provide the AAA-Token.  The proper binding of attributes the AAA-
   Key to the MSK session within a
   protected package is important so the authenticator receiving AAA-Token, then one or more AAA-Keys
   may be sent to an unauthorized party, and an attacker may be able to
   gain access to the network.  If the AAA-Token can determine that it has not been compromised, and is provided to an
   untrusted AAA intermediary, then that intermediary may be able to
   modify the keying material has not been replayed, AAA-Key, or mis-directed the attributes associated with it, as
   described in some
   way.

   The security properties of [RFC2607].

   If the EAP exchange are dependent on each leg Secure Association Protocol does not provide mutual proof of
   possession of the triangle: the selected EAP method, AAA protocol and the secure
   association protocol.

   Assuming that the AAA protocol provides protection against rogue
   authenticators forging their identity, AAA-Key material, then the AAA-Token can be
   assumed to be sent peer will not have
   assurance that it is connected to the correct authenticator, only
   that the authenticator and backend authentication server share a
   trust relationship (since AAA protocols support mutual
   authentication).  This distinction can become important when multiple
   authenticators receive AAA-Keys from the backend authentication
   server, such as where it fast handoff is
   wrapped appropriately, it can be assumed to supported.  If the TSK
   derivation does not provide for protected ciphersuite and
   capabilities negotiation, then downgrade attacks are possible.

4.4.  Man-in-the-middle Attacks

   As described in [I-D.puthenkulam-eap-binding], EAP method sequences
   and compound authentication mechanisms may be immune subject to compromise
   by a snooping attacker.

   Where man-in-the-
   middle attacks.  When such attacks are successfully carried out, the
   attacker acts as an untrusted AAA intermediary is present, between a victim and a legitimate
   authenticator.  This allows the AAA-Token must
   not be provided attacker to authenticate successfully
   to the intermediary so authenticator, as well as to avoid compromise 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
   AAA-Token.  This EAP peer and
   server can be avoided by use of re-direct as defined prove that they have participated in
   [RFC3588].

   When the entire EAP is used for authentication on PPP or wired IEEE 802
   networks, it is typically assumed that
   exchange.  Since the link is physically secure,
   so that compound key must not be known to an attacker cannot gain access to the link, or insert a rogue
   device. EAP methods defined in [I-D.ietf-eap-rfc2284bis] reflect this
   usage model.  These include EAP MD5, as well
   posing as One-Time Password
   (OTP) an authenticator, and Generic Token Card.  These methods support one-way
   authentication (from yet must be derived from quantities
   that are exported by EAP peer methods, it may be desirable to authenticator) but not mutual
   authentication or derive the
   compound key derivation.  As from a result, these methods do not
   bind the initial authentication and subsequent data traffic, even
   when portion of the EMSK.  In order to provide proper
   key hygiene, it is recommended that the ciphersuite compound key used for man-in-
   the-middle protection be cryptographically separate from other keys
   derived from the EMSK, such as fast handoff keys, discussed in
   Appendix E.

4.5.  Denial of Service Attacks

   The caching of security associations may result in vulnerability to protect data supports per-packet
   authentication
   denial of service attacks.  Since an EAP peer may derive multiple EAP
   SAs with a given EAP server, and integrity protection. As creation of a new EAP SA does not
   implicitly delete a result, previous EAP SA, EAP methods not
   supporting mutual authentication are that result in
   creation of persistent state may be vulnerable to session hijacking
   as well as denial of service
   attacks by a rogue devices.

   On wireless networks such as IEEE 802.11 [IEEE80211], these attacks
   become easy to mount, since any attacker within range can access the
   wireless medium, or act as an access point. EAP peer.

   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 and key
   derivation, provided by EAP methods such as EAP-TLS [RFC2716] are
   required [IEEE80211i], so as creating persistent state may wish to address limit
   the threat number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
   For example, an EAP server may choose to only retain a few EAP SAs
   for each peer.  This prevents a rogue devices,
   and provide keying material peer from denying access to bind the initial authentication
   other peers.

   Similarly, an authenticator may have multiple AAA-Key SAs
   corresponding to
   subsequent data traffic.

   If the selected a given EAP method does peer; to conserve resources an
   authenticator may choose to limit the number of cached AAA-Key (Phase
   1 b) SAs for each peer.

   Depending on the media, creation of a new unicast Secure Association
   SA may or may not support mutual authentication,
   then imply deletion of a previous unicast secure
   association SA.  Where there is no implied deletion, the peer will be
   authenticator may choose to limit Phase 2 (unicast and multicast)
   Secure Association SAs for each peer.

4.6.  Impersonation

   Both the RADIUS and Diameter protocols are potentially vulnerable to attack
   impersonation by a rogue authenticators
   and backend authenticator.

   While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
   support mutual authentication servers. If the EAP method does not derive
   keys, then TSKs will not be available for use with a negotiated
   ciphersuite, and there will be no binding between the initial EAP
   authentication and subsequent data traffic, leaving authenticator (known as the session
   vulnerable to hijack.

   If
   AAA client) and the backend authentication server does not protect against
   authenticator masquerade, or provide (known as the proper binding of AAA
   server), the
   AAA-Key security mechanisms vary according to the session within AAA protocol.

   In RADIUS, the AAA-Token, then shared secret used for authentication is determined by
   the source address of the RADIUS packet.  As noted in [RFC3579]
   Section 4.3.7, it is highly desirable that the source address be
   checked against one or more
   AAA-Keys may be sent NAS identification attributes so as to an unauthorized party,
   detect and prevent impersonation attacks.

   When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
   NAS-IPv6-Address attributes may not correspond to the source address.
   Since the NAS-Identifier attribute need not contain an attacker FQDN, it also
   may not correspond to the source address, even indirectly.  [RFC2865]
   Section 3 states:

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

   This implies that it is possible for a rogue authenticator to gain access 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 in messages (and
   MSKs) being sent to the network.  If the AAA-Token wrong authenticator. Since the rogue
   authenticator is provided to
   an untrusted AAA intermediary, then that intermediary may be able to
   modify authenticated by the AAA-Key, RADIUS proxy or server purely
   based on the source address, other mechanisms are required to detect
   the forgery.  In addition, it is possible for attributes associated with it, such as
   described the
   Called-Station-Id and Calling-Station-Id to be forged as well.

   As recommended in [RFC2607].

   If [RFC3579], this vulnerability can be mitigated by
   having RADIUS proxies check authenticator identification attributes
   against the secure association protocol does not provide mutual proof of
   possession source address.

   To allow verification of session parameters such as the AAA-Key material, then Called-
   Station- Id and Calling-Station-Id, these can be sent by the EAP peer will not have
   assurance that it is connected
   to the correct authenticator, only
   that server, protected by the authenticator and backend authentication TEKs. The RADIUS server share a
   trust relationship (since AAA protocols support mutual
   authentication).  This distinction can become important when multiple
   authenticators receive AAA-Keys from then
   check the backend authentication
   server, such as where fast handoff is supported. parameters sent by the EAP peer against those claimed by
   the authenticator.  If a discrepancy is found, an error can be
   logged.

   While [RFC3588] requires use of the TSK
   derivation does not provide for protected ciphersuite Route-Record AVP, this utilizes
   FQDNs, so that impersonation detection requires DNS A/AAAA and
   capabilities negotiation, then downgrade attacks are possible.

4.2 Security Requirements

   This section describes 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 security requirements for EAP methods, AAA
   protocols, secure association protocols and Ciphersuites.  These
   requirements MUST be met by specifications requesting publication backend
   authentication server to communicate with the authenticator directly,
   such as
   an RFC.  Based on these requirements, via the security properties of EAP
   exchanges are analyzed.

4.2.1 EAP method requirements redirect functionality supported in [RFC3588].

4.7.  Channel binding

   It is possible for the peer and a compromised or poorly implemented EAP server
   authenticator to mutually authenticate
   and derive keys.  In order communicate incorrect information to provide keying material for use in a
   subsequently negotiated ciphersuite, an the EAP method supporting key
   derivation MUST export a Master Session Key (MSK) of at least 64
   octets, and peer
   and/or server. This may enable an Extended Master Session Key (EMSK) of at least 64
   octets. authenticator to impersonate
   another authenticator or communicate incorrect information via out-
   of-band mechanisms (such as via a AAA or lower layer protocol).

   Where EAP Methods deriving keys MUST provide for mutual
   authentication between is used in pass-through mode, the EAP peer and typically does
   not verify the EAP Server.

   The MSK and EMSK MUST NOT be used directly to protect data; however,
   they are of sufficient size to enable derivation identity 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 pass-through authenticator, it only
   verifies that the AAA-Key.

   The AAA-Key pass-through authenticator is derived from the keying material exported trusted by the EAP
   method (MSK and EMSK).
   server. This derivation occurs on creates a potential security vulnerability, described in
   Section 7.15 of [RFC2284bis].

   Section 4.3.7 of [RFC3579] describes how an EAP 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 AAA server.  In
   many existing protocols that use EAP, the AAA-Key and MSK are
   equivalent, but more complicated mechanisms are protocol).  However, it is possible (see
   Appendix E
   for details).

   EAP methods SHOULD ensure a pass-through authenticator acting as a AAA client to provide
   correct information to the freshness of AAA server while communicating misleading
   information to the MSK and EMSK even in
   cases where one party may not have EAP peer via a high quality random number
   generator.  A RECOMMENDED method lower layer protocol.

   For example, it is possible for each party to provide a nonce
   of at least 128 bits, used compromised authenticator to
   utilize another authenticator's Called-Station-Id or NAS-Identifier
   in communicating with the derivation of the MSK and EMSK. EAP methods export the MSK and EMSK and not Transient Session Keys so peer via a lower layer protocol, or for
   a pass-through authenticator acting as a AAA client to allow EAP methods provide an
   incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
   server via the AAA protocol.

   As noted in Section 7.15 of [RFC3748] this vulnerability can be ciphersuite and media independent.
   Keying material exported
   addressed by EAP methods MUST be independent use 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 usable with
   any ciphersuite, EAP methods can used with support a wide range protected exchange of
   ciphersuites
   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 media.

   It NAS-IPv6-Address [RFC3162].

   Using such a protected exchange, it is RECOMMENDED that methods providing integrity protection of EAP
   packets include coverage of all possible to match the EAP header fields, including channel
   properties provided by the
   Code, Identifier, Length, Type and Type-Data fields. authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.

4.8.  Key Strength

   In order to preserve algorithm independence, guard against brute force attacks, EAP methods deriving
   keys SHOULD support (and document) the protected negotiation need to be capable of the
   ciphersuite used generating keys with an appropriate
   effective symmetric key strength.  In order to protect ensure that key
   generation is not the weakest link, it is necessary for EAP conversation between methods
   utilizing public key cryptography to choose a public key that has a
   cryptographic strength meeting the peer symmetric key strength
   requirement.

   As noted in Section 5 of [RFC3766], this results in the following
   required RSA or DH module and
   server.  This DSA subgroup size in bits, 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

4.9.  Key Wrap

   As described in [RFC3579], Section 4.3, known problems exist in the
   key wrap specified in [RFC2548].  Where the same RADIUS shared secret
   is distinct from used by a PAP authenticator and an EAP authenticator, there is a
   vulnerability to known plaintext attack.  Since RADIUS uses the ciphersuite negotiated between
   shared secret for multiple purposes, including per-packet
   authentication, attribute hiding, considerable information is exposed
   about the shared secret with each packet. This exposes the
   peer and authenticator, used shared
   secret to protect data.

   The strength of Transient Session Keys (TSKs) dictionary attacks.  MD5 is used both to protect data is
   ultimately dependent on compute the strength of keys generated by RADIUS
   Response Authenticator and the EAP
   method.  If an EAP method cannot produce keying material Message-Authenticator attribute, and
   some concerns exist relating to the security of
   sufficient strength, then this hash
   [MD5Attack].

   As discussed in [RFC3579], Section 4.3, 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 security vulnerabilities
   of generating an
   MSK RADIUS are extensive, and EMSK, each with an effective key strength therefore development of at least 128
   bits.

   Methods supporting an alternative
   key derivation MUST demonstrate cryptographic
   separation between the MSK and EMSK branches of wrap technique based on the 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
   hierarchy.  Without violating a fundamental cryptographic assumption
   attributes, to be protected by IPsec or TLS.

   Where an untrusted AAA intermediary is present (such as the non-invertibility of a one-way function) an attacker
   recovering the MSK RADIUS
   proxy or EMSK MUST NOT be able to recover the other
   quantity with a level of effort less than brute force.

   Non-overlapping substrings of the MSK MUST be cryptographically
   separate from each other.  That is, knowledge of one substring MUST
   NOT help in recovering some other substring without breaking some
   hard cryptographic assumption.  This Diameter agent), and data object security is required because some
   existing ciphersuites form TSKs by simply splitting not used, the
   AAA-Key to
   pieces of appropriate length.  Likewise, non-overlapping substrings may be recovered by an attacker in control of the EMSK MUST be cryptographically separate from each other, and
   from substrings untrusted
   intermediary.  Possession of the MSK.

   The EMSK MUST remain on AAA-Key enables decryption of data
   traffic sent between the EAP peer and EAP server a specific authenticator; however
   where it key separation is
   derived; it MUST NOT be transported to, or shared with, additional
   parties, or used to derive any other keys.

   Since EAP implemented, compromise of the AAA-Key does
   not provide for explicit key lifetime negotiation, EAP
   peers, authenticators and authentication servers MUST be prepared for
   situations in which one enable an attacker to impersonate the peer to another
   authenticator, since that requires possession of the parties discards key state MK or EMSK,
   which
   remains valid on another party.

   The development and validation are not transported by the AAA protocol.  This vulnerability
   may be mitigated by implementation of key derivation algorithms is
   difficult, and as a result EAP methods SHOULD reuse well established
   and analyzed mechanisms for key derivation (such redirect functionality, as those specified
   provided in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones.
   EAP methods SHOULD also utilize well established and analyzed
   mechanisms for MSK and EMSK derivation.

4.2.2 AAA Protocol [RFC3588].

5.  Security Requirements

   AAA protocols suitable for use in transporting EAP MUST provide

   This section summarizes the
   following facilities:

   Security services
      AAA protocols used for transport of security requirements that must be met by
   EAP keying material MUST
      implement and SHOULD use per-packet integrity and authentication,
      replay protection methods, AAA protocols,  Secure Association Protocols and confidentiality.
   Ciphersuites in order to address the security threats described in
   this document. These requirements are MUST be met by Diameter EAP [I-D.ietf-aaa-eap], as well specifications
   requesting publication as RADIUS over IPsec
      [RFC3579].

   Session Keys
      AAA protocols used for transport an RFC.  Each requirement provides a
   pointer to the sections of this document describing the threat that
   it mitigates.

5.1.  EAP keying material MUST
      implement Method Requirements

   It is possible for the peer and SHOULD use dynamic key management in order EAP server to mutually authenticate
   and derive
      fresh session keys, as keys.  In order to provide keying material for use in Diameter a
   subsequently negotiated ciphersuite, an EAP [I-D.ietf-aaa-eap] and
      RADIUS over IPsec [RFC3579], rather than using method supporting key
   derivation MUST export a static key, as
      originally defined in RADIUS [RFC2865].

   Mutual authentication
      AAA protocols used for transport Master Session Key (MSK) of at least 64
   octets, and an Extended Master Session Key (EMSK) of at least 64
   octets.  EAP keying material Methods deriving keys MUST provide for mutual
   authentication between the authenticator EAP peer and
      backend authentication server.  These requirements are met by
      Diameter the EAP [I-D.ietf-aaa-eap] as well as Server.

   The MSK and EMSK MUST NOT be used directly 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 derived from the keying material exported by RADIUS the EAP
      [RFC3579].

   Authorization
   method (MSK and EMSK).  This derivation occurs on the AAA server.  In
   many existing protocols used that use EAP, the AAA-Key and MSK are
   equivalent, but more complicated mechanisms are possible (see
   Appendix E for transport of details).

   EAP keying material methods SHOULD
      provide protection against rogue authenticators masquerading as
      other authenticators.  This can be accomplished, for example, by
      requiring that AAA agents check ensure the source address freshness of packets
      against the origin attributes (Origin-Host AVP MSK and EMSK even in Diameter,
      NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier
   cases where one party may not have a high quality random number
   generator.  A RECOMMENDED method is for each party to provide a nonce
   of at least 128 bits, used in RADIUS).  For
      details, see Section 4.3.7 the derivation of [RFC3579].

   Key transport
      Since the MSK and EMSK.

   EAP methods do not export the MSK and EMSK and not Transient Session Keys (TSKs) in
      order so
   as to maintain media and allow EAP methods to be ciphersuite independence, the AAA
      server and media independent.
   Keying material exported by EAP methods MUST NOT transport TSKs from be independent of the backend authentication
      server to authenticator.

   Key transport specification
      In order
   ciphersuite negotiated to enable backend authentication servers 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 provide the EAP method.  By providing keying material to the authenticator in a well defined format, AAA
      protocols suitable for use usable with
   any ciphersuite, EAP MUST define the format methods can used with a wide range of
   ciphersuites and
      wrapping media.

   It is RECOMMENDED that methods providing integrity protection of EAP
   packets include coverage of all the AAA-Token.

   EMSK transport
      Since EAP header fields, including the EMSK is a secret known only
   Code, Identifier, Length, Type and Type-Data fields.

   In order to preserve algorithm independence, EAP methods deriving
   keys SHOULD support (and document) the backend
      authentication server and peer, protected negotiation of the AAA-Token MUST NOT transport
   ciphersuite used to protect the EMSK from EAP conversation between the backend authentication server to peer and
   server.  This is distinct from the
      authenticator.

   AAA-Token protection
      To ensure against compromise, ciphersuite negotiated between the AAA-Token MUST be integrity
      protected, authenticated, replay protected
   peer and encrypted in
      transit, using well-established cryptographic algorithms. authenticator, used to protect data.

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

   Key naming
      In order (TSKs) used to ensure against confusion between protect data is
   ultimately dependent on the appropriate strength of keys generated by the EAP
   method.  If an EAP method cannot produce keying material to be used in a given secure association protocol
      exchange, of
   sufficient strength, then the AAA-Token SHOULD include explicit TSKs may be subject to brute force
   attack.  In order to enable deployments requiring strong keys, EAP
   methods supporting key names derivation SHOULD be capable of generating an
   MSK and
      context appropriate for informing the authenticator how EMSK, each with an effective key strength of at least 128
   bits.

   Methods supporting key derivation MUST demonstrate cryptographic
   separation between the keying
      material is to be used.

   Key Compromise
      Where untrusted intermediaries are present, MSK and EMSK branches of the AAA-Token SHOULD
      NOT be provided to EAP key
   hierarchy.  Without violating a fundamental cryptographic assumption
   (such as the intermediaries.  In Diameter, handling non-invertibility of
      keys by intermediaries can be avoided using Redirect functionality
      [RFC3588].

4.2.3 Secure Association Protocol Requirements

   The Secure Association Protocol supports a one-way function) an attacker
   recovering the following:

   Mutual proof MSK or EMSK MUST NOT be able to recover the other
   quantity with a level of possession
      The peer and authenticator effort less than brute force.

   Non-overlapping substrings of the MSK MUST be cryptographically
   separate from each demonstrate possession other.  That is, knowledge of the
      keying material transported between the AAA server and
      authenticator (AAA-Key).

   Key Naming
      The Secure Association Protocol one substring MUST explicitly name the keys used
   NOT help in recovering some other substring without breaking some
   hard cryptographic assumption.  This is required because some
   existing ciphersuites form TSKs by simply splitting the proof of possession exchange, so as AAA-Key to prevent confusion
      when more than one set
   pieces of appropriate length.  Likewise, non-overlapping substrings
   of keying material could potentially be
      used as the basis for the exchange.

   Creation EMSK MUST be cryptographically separate from each other, and Deletion
      In order to support the correct processing
   from substrings of phase 2 security
      associations, the secure association (phase 2) protocol MSK.

   The EMSK MUST
      support remain on the naming of phase 2 security associations EAP peer and associated
      transient session keys, so that the correct set of transient
      session keys can EAP server where it is
   derived; it MUST NOT be identified transported to, or shared with, additional
   parties, or used to derive any other keys.

   Since EAP does not provide for processing a given packet.  The
      phase 2 secure association protocol also MUST support transient
      session explicit key activation and SHOULD support deletion, so that
      establishment lifetime negotiation, EAP
   peers, authenticators and re-establishment of transient session keys can authentication servers MUST be synchronized between prepared for
   situations in which one of the parties.

   Integrity and Replay Protection parties discards key state which
   remains valid on another party.

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

   Direct operation
      Since the phase 2 secure association protocol key derivation algorithms is concerned with
      the establishment of security associations between the
   difficult, and as a result EAP peer methods SHOULD reuse well established
   and authenticator, including the analyzed mechanisms for key derivation of transient session
      keys, only (such as those parties have "a need specified
   in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones.
   EAP methods SHOULD also utilize well established and analyzed
   mechanisms for MSK and EMSK derivation.

5.1.1.  Requirements for EAP methods

   In order for an EAP method to know" meet the transient
      session keys. The secure association protocol MUST operate
      directly between guidelines for EMSK usage it
   must meet the peer and authenticator, and MUST NOT be
      passed-through following requirements:

      o It must specify how to derive the backend authentication server, or include
      additional parties.

   Derivation of transient session keys EMSK

      o The secure association protocol negotiation key material used for the EMSK MUST support
      derivation be
        computationally independent of unicast and multicast transient session keys
      suitable for use with the negotiated ciphersuite.

   TSK freshness MSK and TEKs.

      o The secure association (phase 2) protocol EMSK MUST support NOT be used for any other purpose than the key
        derivation of fresh unicast described in this document.

      o The EMSK MUST be secret and multicast transient session keys,
      even when the keying material provided by the AAA server is not
      fresh.  This is typically supported by including an exchange of
      nonces known to someone observing
        the authentication mechanism protocol exchange.

      o The EMSK MUST be maintained within the secure association protocol.

   Bi-directional operation
      While some ciphersuites only require a single set of transient
      session EAP server.
        Only keys (AMSKs) derived according to protect traffic in both directions, other
      ciphersuites require a this specification
        may be exported from the EAP server.

      o The EMSK MUST be unique set of transient session keys in for each direction. session.

      o The phase 2 secure association protocol EAP mechanism SHOULD provide for a way of naming the derivation EMSK.

   Implementations of unicast EAP frameworks on the EAP-Peer and multicast keys in each
      direction, so as not EAP-Server
   SHOULD provide an interface to require two separate phase 2 exchanges in obtain AMSKs.  The implementation MAY
   restrict which callers can obtain which keys.

5.1.2.  Requirements for EAP applications

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

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

      o The Secure Association Protocol MUST support secure capabilities
      negotiation. application MAY use the MSK transmitted to the NAS in any
        way it chooses. This includes security parameters such as is required for backward compatibility. New
        applications following this specification SHOULD NOT use the
      security association identifier (SAID) and ciphersuites. It also
      includes confirmation of
        MSK.  If more than one application uses the capabilities discovered during MSK, then the
      discovery phase (phase 0), so as
        cryptographic separation is not achieved. Implementations SHOULD
        prevent such combinations.

      o The application MUST NOT use the EMSK in any other way except to ensure that
        derive Application Master Session Keys (AMSK) using the key
        derivation specified in this document.  It MUST NOT
        use the EMSK directly for cryptographic protection of data.

      o Applications MUST define distinct key labels, application
        specific data, length of derived key material used in the announced
      capabilities have not been forged.

4.2.4 Ciphersuite key
        derivation described in section 2.4.3.

      o Applications MUST define how they use their AMSK to derive TSKs
        for their use.

5.2.  AAA Protocol Requirements

   Ciphersuites

   AAA protocols suitable for keying by use in transporting EAP methods MUST provide the
   following facilities:

   TSK derivation
      In order to allow a ciphersuite to be usable within the

Security services
     AAA protocols used for transport of EAP keying
      framework, a specification material MUST be provided describing how
      transient session keys suitable for
     implement and SHOULD use with the ciphersuite per-packet integrity and authentication,
     replay protection and confidentiality.  These requirements are
      derived from the AAA-Key. met
     by Diameter EAP method independence
      Algorithms [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
     [RFC3579].

Session Keys
     AAA protocols used for deriving transient transport of EAP keying material MUST
     implement and SHOULD use dynamic key management in order to derive
     fresh session keys from the AAA-Key keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
     RADIUS over IPsec [RFC3579], rather than using a static key, as
     originally defined in RADIUS [RFC2865].

Mutual authentication
     AAA protocols used for transport of EAP keying material MUST NOT depend on
     provide for mutual authentication between the authenticator and
     backend authentication server.  These requirements are met by
     Diameter EAP method.  However, algorithms [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].

Authorization
     AAA protocols used for
      deriving TEKs MAY transport of EAP keying material SHOULD
     provide protection against rogue authenticators masquerading as
     other authenticators.  This can be specific to accomplished, for example, by
     requiring that AAA agents check the source address of packets
     against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier in RADIUS).  For details,
     see Section 4.3.7 of [RFC3579].

Key transport
     Since EAP method.

   Cryptographic separation
      The TSKs derived from methods do not export Transient Session Keys (TSKs) in
     order to maintain media and ciphersuite independence, the AAA-Key MUST be cryptographically
      separate from each other.  Similarly, TEKs AAA
     server MUST be
      cryptographically separate from each other.  In addition, the NOT transport TSKs
      MUST be cryptographically separate from the TEKs.

5. IANA Considerations

   This specification does not create any new registries, or define any
   new EAP codes or types.

6. Security Considerations

6.1 backend authentication
     server to authenticator.

Key Strength transport specification
     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 enable backend authentication servers to ensure that key
   generation is not the weakest link, it is necessary for EAP methods
   utilizing public key cryptography provide keying
     material to choose a public key that has a
   cryptographic strength meeting the symmetric key strength
   requirement.

   As noted in Section 5 of [I-D.orman-public-key-lengths], this results
   in the following required RSA or DH module and DSA subgroup size authenticator in
   bits, 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

6.2 Key Wrap

   As described in [RFC3579], Section 4.3, known problems exist in the
   key wrap specified in [RFC2548].  Where well defined format, AAA
     protocols suitable for use with EAP MUST define the same RADIUS shared secret
   is used by a PAP authenticator format and an EAP authenticator, there is a
   vulnerability to known plaintext attack.
     wrapping of the AAA-Token.

EMSK transport
     Since RADIUS uses the
   shared secret for multiple purposes, including per-packet
   authentication, attribute hiding, considerable information EMSK is exposed
   about the shared secret with each packet. This exposes the shared a secret known only to dictionary attacks.  MD5 is used both to compute the RADIUS
   Response Authenticator backend authentication
     server and peer, the Message-Authenticator attribute, and
   some concerns exist relating AAA-Token MUST NOT transport the EMSK from the
     backend authentication server to the security of this hash
   [MD5Attack].  As discussed in [RFC3579], Section 4.2, these authenticator.

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

Session Keys
     The AAA-Token SHOULD be addressed by running protected with session keys as in Diameter
     [RFC3588] or RADIUS over IPsec.

   Where an untrusted AAA intermediary is present (such IPsec [RFC3579] rather than static keys,
     as a RADIUS
   proxy or a Diameter agent), and data object security is not used, in [RFC2548].

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

Key Compromise
     Where untrusted
   intermediary.  Possession of intermediaries are present, the AAA-Key enables decryption AAA-Token SHOULD
     NOT be provided to the intermediaries.  In Diameter, handling of data
   traffic sent between
     keys by intermediaries can be avoided using Redirect functionality
     [RFC3588].

5.3.  Secure Association Protocol Requirements

   The Secure Association Protocol supports the following:

Entity Naming
     The peer and authenticator SHOULD identify themselves in a specific authenticator; however
   where key separation manner
     that is implemented, compromise independent of the AAA-Key does
   not enable an attacker to impersonate the their attached ports.

Mutual proof of possession
     The peer to another
   authenticator, since that requires and authenticator MUST each demonstrate possession of the MK or EMSK,
   which are not
     keying material transported by between the AAA protocol.  This vulnerability
   may be mitigated by implementation of redirect functionality, as
   provided in[RFC3588].

6.3 Man-in-the-middle Attacks

   As described in [I-D.puthenkulam-eap-binding], EAP method sequences
   and compound backend 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
     server and a legitimate authenticator.  This allows authenticator (AAA-Key).

Key Naming
     The Secure Association Protocol MUST explicitly name the attacker to
   authenticate successfully to keys used
     in the authenticator, as well proof of possession exchange, so as to obtain
   access to prevent confusion
     when more than one set of keying material could potentially be used
     as the network. basis for the exchange.

Creation and Deletion
     In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
   recommends derivation support the correct processing of a compound key by which phase 2 security
     associations, the EAP peer Secure Association (phase 2) protocol MUST
     support the naming of phase 2 security associations and
   server can prove associated
     transient session keys, so that they have participated in the entire EAP
   exchange.  Since the compound key must not correct set of transient
     session keys can be known to an attacker
   posing as an authenticator, identified for processing a given packet.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation and yet must be derived from quantities SHOULD support deletion, so that are exported by EAP methods, it may
     establishment and re-establishment of transient session keys can be desirable to derive
     synchronized between the
   compound key from a portion parties.

Integrity and Replay Protection
     The Secure Association Protocol MUST support integrity and replay
     protection of all messages.

Direct operation
     Since the EMSK.  In order to provide proper
   key hygiene, it phase 2 Secure Association Protocol is recommended that the compound key used for
   man-in-the-middle protection be cryptographically separate from other
   keys derived from concerned with the EMSK, such as fast handoff keys, discussed in
   Appendix E.

6.4 Impersonation

   Both
     establishment of security associations between the RADIUS EAP peer and Diameter protocols are potentially vulnerable to
   impersonation by a rogue authenticator.

   When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
   NAS-IPv6-Address attributes may not correspond to the source address.
   Since
     authenticator, including the NAS-Identifier attribute derivation of transient session keys,
     only those parties have "a need not contain an FQDN, it also
   may not correspond to know" the source address, even indirectly.  [RFC2865]
   Section 3 states:

      A RADIUS server transient session
     keys. The Secure Association Protocol MUST use the source IP address of operate directly between
     the RADIUS
      UDP packet to decide which shared secret to use, so that
      RADIUS requests can peer and authenticator, and MUST NOT 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 in messages (and
   MSKs) being sent passed-through to the wrong authenticator. Since
     backend authentication server, or include additional parties.

Derivation of transient session keys
     The Secure Association Protocol negotiation MUST support derivation
     of unicast and multicast transient session keys suitable for use
     with the rogue
   authenticator is authenticated negotiated ciphersuite.

TSK freshness
     The Secure Association (phase 2) Protocol MUST support the
     derivation of fresh unicast and multicast transient session keys,
     even when the keying material provided by the RADIUS proxy or backend
     authentication server purely
   based on is not fresh.  This is typically supported by
     including an exchange of nonces within the source address, other mechanisms are required Secure Association
     Protocol.

Bi-directional operation
     While some ciphersuites only require a single set of transient
     session keys to detect
   the forgery.  In addition, it is possible protect traffic in both directions, other
     ciphersuites require a unique set of transient session keys in each
     direction. The phase 2 Secure Association Protocol SHOULD provide
     for attributes such as the
   Called-Station-Id derivation of unicast and Calling-Station-Id to be forged multicast keys in each direction,
     so as well.

   As recommended not to require two separate phase 2 exchanges in [RFC3579], this vulnerability can be mitigated by
   having RADIUS proxies check authenticator identification attributes
   against the source address.

   To allow verification of session 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
   Called-Station- Id
     security association identifier (SAID) and Calling-Station-Id, these can be sent by ciphersuites, as well as
     negotiation of the lifetime of the TSKs, AAA-Key and exported EAP peer to
     keys.  Secure capabilities negotiation also includes confirmation
     of the capabilities discovered during the server, protected by discovery phase (phase
     0), so as to ensure that the TEKs. announced capabilities have not been
     forged.

Key Scoping
     The RADIUS server can
   then check Secure Association Protocol MUST ensure the parameters sent by synchronization of
     key scope between the EAP peer against those claimed
   by the and authenticator.  If a discrepancy is found, an error can be
   logged.

   While [RFC3588] requires use  This includes
     negotiation of restrictions on key usage.

5.4.  Ciphersuite Requirements

   Ciphersuites suitable for keying by EAP methods MUST provide the Route-Record AVP, this utilizes
   FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
   RRs
   following facilities:

TSK derivation
     In order to be properly configured.  As allow 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 ciphersuite to allow be usable within the backend
   authentication server to communicate EAP keying
     framework, a specification MUST be provided describing how
     transient session keys suitable for use with the authenticator directly,
   such as via ciphersuite are
     derived from the redirect functionality supported in [RFC3588].

6.5 Denial of Service Attacks

   The caching of security associations may result in vulnerability to
   denial of service attacks.  Since an AAA-Key.

EAP peer may derive multiple method independence
     Algorithms for deriving transient session keys from the AAA-Key
     MUST NOT depend on the EAP
   SAs with a given method.  However, algorithms for
     deriving TEKs MAY be specific to the EAP server, and creation 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.

6.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of a new values related to EAP SA does not
   implicitly delete 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 previous EAP SA, EAP methods Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that result in
   creation of persistant state may any allocation will be vulnerable to denial of service
   attacks
   accompanied by a rogue EAP peer.

   As a result, EAP methods creating persistent state may wish published RFC.  But in order to limit allow for the number
   allocation of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
   For example, an EAP server may choose values prior to only retain a few EAP SAs the RFC being approved for each peer.  This prevents a rogue peer from denying access to
   other peers.

   Similarly, publication,
   the Designated Expert can approve allocations once it seems clear
   that an authenticator may have multiple AAA-Key SAs
   corresponding to RFC will be published.  The Designated expert will post a given EAP peer; to conserve resources an
   authenticator may choose
   request to limit the number of cached AAA-Key (Phase
   1 b) SAs for each peer.

   Depending on the media, creation of a new unicast secure association
   SA may or may not imply deletion of EAP WG mailing list (or a previous unicast secure
   association SA.  Where there is no implied deletion, successor designated by the
   authenticator may choose to limit Phase 2 (unicast and multicast)
   secure association SAs
   Area Director) for each peer.

7. Acknowledgements

   Thanks to Arun Ayyagari, Ashwin Palekar, comment and Tim Moore of Microsoft,
   Dorothy Stanley of Agere, Bob Moskowitz review, including an Internet-Draft.
   Before a period of TruSecure, 30 days has passed, the Designated Expert will
   either approve or deny the registration request and Russ
   Housley publish a notice
   of Vigil Security for useful feedback. 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.

7.  References

7.1.  Normative References

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

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

   [I-D.ietf-eap-rfc2284bis]

[RFC3748]
     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz,
     "Extensible Authentication Protocol (EAP)",
              draft-ietf-eap-rfc2284bis-06 (work in progress), September
              2003.

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

7.2.  Informative References

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

   [RFC1321]  Rivest, R.,

[RFC1661] Simpson, W., "The MD5 Message-Digest Algorithm", Point-to-Point Protocol (PPP)", STD 51, RFC 1321,
              April 1992.
          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.

   [RFC2855]  Fujisawa, K., "DHCP for IEEE 1394", RFC 2855, June 2000.

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

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L. and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 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.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

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

   [FIPS197]  National

[IEEE802] Institute of Standards Electrical and Technology, "Advanced
              Encryption Standard (AES)", FIPS PUB 197, November 2001.

   [FIPS.180-1.1995]
              National Institute of Electronics Engineers, "IEEE
          Standards for Local and Technology, "Secure
              Hash Standard", FIPS PUB 180-1, April 1995, <http://
              www.itl.nist.gov/fipspubs/fip180-1.htm>. 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-1997, 1997. 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-2001, June 2002. 802.1X-2004, September 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]

[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, "Draft
          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 Draft 802.11I/
              D6.1, August 2003. D8, February 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.

   [EAPAPI]   Microsoft Developer Network, "Windows 2000 EAP API",
              http://msdn.microsoft.com/library/default.asp?url=/
              library/en-us/eap/eapport_0fj9.asp, August 2000.

[I-D.ietf-roamops-cert]
          Aboba, B., "Certificate-Based Roaming",
              draft-ietf-roamops-cert-02 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-02 (work in progress), July 2003.

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

   [I-D.orman-public-key-lengths]
              Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric  Keys",
              draft-orman-public-key-lengths-05 June 2004.

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

[I-D.puthenkulam-eap-binding]
          Puthenkulam, J., "The Compound Authentication Binding
          Problem", draft-puthenkulam-eap-binding-03 draft-puthenkulam-eap-binding-04 (work in progress), July
          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-10 draft-
          arkko-pppext-eap-aka-11 (work in progress), June October 2003.

[IKEv2]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
          ietf-ipsec-ikev2-12 (work in progress), March 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.

Authors'

[WLANREQ] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements
          for Wireless LANs", draft-walker-ieee802-req-02.txt (work in
          progress), July 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, and Russ
   Housley of Vigil Security for useful feedback.

Author Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
   USA

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

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

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

   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

Appendix A. 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 [ECP]
   negotiation phase [RFC1968]." 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 a 128-bit
   authentication key (used in both directions); AES CCMP, which
   requires a single 128-bit key (used in both directions) in order to
   authenticate and encrypt data; and WRAP, which requires a single
   128-bit key (used in both directions).

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

Appendix B. 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.
   master_secret = TLS term for the MK.

          |                       |                           |
          |                       | pre_master_secret         |
    server|                       |                           | client
    Random|                       V                           | Random
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |     |                                     |       |
          |     |                                     |       |
          +---->|             master_secret           |<------+
          |     |               (MK)                  |       |
          |     |                                     |       |
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |                       |                           |
          |                       |                           |
          |                       |                           |
          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. MSK and EMSK C - EAP Key Hierarchy

   In EAP-TLS [RFC2716], the MSK is divided into two halves,
   corresponding to the "Peer to Authenticator Encryption Key"
   (Enc-RECV-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 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 MK via a
   one-way one-
   way function. This ensures that the MK 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 MK, if the MK is compromised then
   the MSK is also compromised.

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

   MSK           = TLS-PRF-64(MK, "client EAP encryption",
                      client.random || server.random)
   EMSK          = second 64 octets of:
                   TLS-PRF-128(MK, "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) =
   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 inclusive 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.
   MK            = TLS master_secret
   TLS-PRF-X     = TLS PRF function [RFC2246], 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 MK. Note that in [RFC2716],
   the MK is referred to as the "TLS Master Secret".

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

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

Appendix D. D - Transient Session Key (TSK) Derivation

   Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
   session key used to protect unicast traffic, is derived from the PMK
   (octets 0-31 of the MSK), known in [RFC2716] as the Peer to
   Authenticator Encryption Key.  In [IEEE80211i],  the PTK is derived
   from the PMK via 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, and WEP use X = 48.

   The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
   authenticity in the TSK derivation. It utilizes the first 128 bits
   (bits 0-127) of the PTK.  The EAPOL-Key Encryption Key (KEK) provides
   confidentiality in the TSK derivation.  It utilizes bits 128-255 of
   the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
   384-511 are used by Temporal Key 2.  Usage of TK1 and TK2 is
   ciphersuite specific. Details are available in [IEEE80211i].

Appendix E. E - AAA-Key Derivation

   Where a AAA-Key is generated as the result of a successful EAP
   authentication, the AAA-Key is set to MSK(0,63).

   As discussed in [I-D.irtf-aaaarch-handoff], [IEEE-02-758],
   [IEEE-03-084], and [8021XHandoff], keying material may be required
   for use in fast handoff between IEEE 802.11 authenticators. Where the backend
   authentication server provides keying material to multiple
   authenticators in order to fascilitate facilitate fast handoff, it is highly
   desirable for the keying material used on different authenticators to
   be cryptographically separate, so that if one authenticator is
   compromised, it does not lead to the compromise of other
   authenticators. Where keying material is provided by the backend
   authentication server, a key hierarchy derived from the EMSK, as
   suggested in [IEEE-03-155] can be
   used to provide cryptographically separate keying material for use in
   fast handoff:

   AAA-Key-A = MSK(0,63)
   AAA-Key-B = PRF(EMSK(0,63),AAA-Key-A,
                    B-Called-Station-Id,Calling-Station-Id) PRF(EMSK(0,63),"EAP AAA-Key derivation for
               multiple attachments", AAA-Key-A,B-Called-Station-Id,
               Calling-Station-Id,length)

   AAA-Key-E = PRF(EMSK(0,63),AAA-Key-A,
                    E-Called-Station-Id,Calling-Station-Id) PRF(EMSK(0,63),"EAP AAA-Key derivation for
               multiple attachments",AAA-Key-A,E-Called-Station-Id,
               Calling-Station-Id, length)

   Where:
   Calling-Station-Id  = STA MAC address
   B-Called-Station-Id = AP B MAC address
   E-Called-Station-Id = AP E MAC address
   length = length of derived key material

   Here AAA-Key-A is the AAA-Key derived during the initial EAP
   authentication between the peer and authenticator A. Based on this
   initial EAP authentication, the EMSK is also derived, which can be
   used to derive AAA-Keys for fast authentication between the EAP peer
   and authenticators B and E.  Since the EMSK is cryptographically
   separate from the MSK, each of these AAA-Keys is cryptographically
   separate from each other, and are guaranteed to be unique between the
   EAP peer (also known as the STA) and the authenticator (also known as
   the AP).

Appendix F. Open issues

   (This section should be removed by the RFC editor before publication)

   Open issues relating to this specification are tracked on the
   following web site:

   http://www.drizzle.com/~aboba/EAP/eapissues.html

   The current working documents for this draft are available at this
   web site:

   http://www.levkowetz.com/pub/ietf/drafts/eap/keying/

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

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or assignees.
   assigns.  This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgment

   Funding for PURPOSE."

Open Issues

   Open issues relating to this specification are tracked on the RFC Editor function
   following web site:

   http://www.drizzle.com/~aboba/EAP/eapissues.html

Expiration Date

   This memo is currently provided by the
   Internet Society. filed as <draft-ietf-eap-keying-02.txt>,  and  expires
   December 22, 2004.