EAP Working Group                                          Bernard Aboba
INTERNET-DRAFT                                                 Dan Simon
Category: Standards Track                                      Microsoft
<draft-ietf-eap-keying-07.txt>
<draft-ietf-eap-keying-08.txt>                                  J. Arkko
17 July
23 October 2005                                                 Ericsson
                                                               P. Eronen
                                                                   Nokia
                                                       H. Levkowetz, Ed.
                                                             ipUnplugged

   Extensible Authentication Protocol (EAP) Key Management Framework

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on January April 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society 2005.

Abstract

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

Table of Contents

   1.     Introduction ..........................................    4    3
      1.1       Requirements Language ...........................    4    3
      1.2       Terminology .....................................    4    3
      1.3       Overview ........................................    7    5
      1.4       EAP Invariants ..................................   14    9
   2.     Lower Layer Operation .................................   16   13
      2.1       Discovery Phase .................................   18       Overview ........................................   13
      2.2       Authentication Phase ............................   18       Layering ........................................   14
      2.3       Secure Association Phase ........................   19       Caching .........................................   17
      2.4       Lower Layer       Key Hierarchy .......................   21
      2.5       AAA-Key Derivation and Naming ...................   24
   3.     Security associations .................................   26
      3.1       EAP Method SA ...................................   26
      3.2       EAP-Key SA ......................................   27
      3.3       AAA SA(s) Scope .......................................   27
      3.4       Service SA(s) ...................................   27
   4.   18
   3.     Key Management ........................................   30
      4.1       Key Caching .....................................   31
      4.2   21
      3.1       Secure Association Protocol .....................   22
      3.2       Parent-Child Relationships ......................   32
      4.3   24
      3.3       Local Key Lifetimes .............................   32
      4.4   25
      3.4       Exported and Calculated Key Lifetimes ...........   33
      4.5   25
      3.5       Key Cache Synchronization .......................   34
      4.6       Key Scope .......................................   35
      4.7   27
      3.6       Key Strength ....................................   36
      4.8   27
      3.7       Key Wrap ........................................   37
   5.   28
   4.     Handoff Vulnerabilities ...............................   38
      5.1   29
      4.1       Authorization ...................................   38
      5.2   29
      4.2       Correctness .....................................   39
   6.   30
   5.     Security Considerations  ..............................   42
      6.1   33
      5.1       Security Terminology ............................   42
      6.2   34
      5.2       Threat Model ....................................   42
      6.3       Security Analysis   34
      5.3       Authenticator Compromise ........................   35
      5.4       Spoofing ........................................   36
      5.5       Downgrade Attacks ...............................   44
      6.4       Man-in-the-middle   36
      5.6       Unauthorized Disclosure .........................   37
      5.7       Replay Protection ...............................   38
      5.8       Key Freshness ...................................   39
      5.9       Elevation of Privilege ..........................   40
     5.10       Man-in-the-Middle Attacks .......................   47
      6.5   41
     5.11       Denial of Service Attacks .......................   48
      6.6   41
     5.12       Impersonation ...................................   48
      6.7   42
     5.13       Channel Binding .................................   50
   7.     Security Requirements .................................   50
      7.1       EAP Method Requirements .........................   51
      7.2       AAA Protocol Requirements .......................   53
      7.3       Secure Association Protocol Requirements ........   55
      7.4       Ciphersuite Requirements ........................   56
   8.   43
   6.     IANA Considerations ...................................   57
   9.   44
   7.     References ............................................   57
      9.1   44
      7.1       Normative References ............................   57
      9.2   44
      7.2       Informative References ..........................   57   45
   Acknowledgments ..............................................   61   49
   Author's Addresses ...........................................   61   49
   Appendix A - Ciphersuite Keying Requirements .................   63
   Appendix B - Example Transient EAP Key (TEK) Hierarchy .......   64
   Appendix C - EAP-TLS Key Hierarchy ...........................   65
   Appendix D - Example Transient Session Key (TSK) Derivation ..   67   51
   Appendix E B - Exported Parameters in Existing Methods .........   68
   Appendix F - Security Association Examples ...................   70   53
   Intellectual Property Statement ..............................   73   54
   Disclaimer of Validity .......................................   74   55
   Copyright Statement ..........................................   74   55

1.  Introduction

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

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

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].

1.2.  Terminology

   This document frequently uses the following terms:

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

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

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

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

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

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

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

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

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

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

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

Pairwise Master Key (PMK)
     The AAA-Key MSK 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 [IEEE-802.11i] Octets 0-31
     of the AAA-Key MSK (Enc-RECV-Key) are known as the Pairwise Master Key
     (PMK).  In [IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
     their Transient Session Keys (TSKs) solely from the PMK, whereas
     the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
     both halves of the AAA-Key. MSK.

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

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

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

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

1.3.  Overview

   EAP, defined in [RFC3748] [RFC3748], is a two-party protocol spoken between the
   EAP peer and server.  Within EAP, keying material is generated by EAP
   methods.  Part of this keying material may be used by EAP methods
   themselves and part of this material may be exported.  In addition to
   export of keying material, EAP methods may also export associated
   parameters, and may import and export Channel Bindings from the lower
   layer.

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

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

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

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

   As noted in [RFC3748] Section 7.10, EAP methods generating keys are
   required to calculate and export the MSK and EMSK, which must be at
   least 64 octets in length.  EAP methods also may export the IV;
   however, the use of the IV is deprecated.

   EAP methods also MAY export method-specific peer and server
   identifiers (peer-ID and server-ID), a method-specific EAP
   conversation identifier known as the Method-ID, and the lifetime of
   the exported keys, known the Key-Lifetime.   EAP methods MAY also
   support the import and export of Channel Bindings.  New EAP method
   specifications MUST define the Peer-ID, Server-ID and Method-ID. The
   combination of the Peer-ID and Server-ID uniquely specifies the
   endpoints of the EAP method exchange.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^
|                EAP Method                               |            |
|                                                         |            |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+   |            |
| |                                 |   |             |   |            |
| |       EAP Method Key            |<->| Long-Term   |   |            |
| |         Derivation              |   | Credential  |   |            |
| |                                 |   |             |   |            |
| |                                 |   +-+-+-+-+-+-+-+   |  Local to  |
| |                                 |                     |       EAP  |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |     Method |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |             |               |                       |            |
|   |           +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|   |           | TEK       | |MSK, EMSK  | |IV         | |            |
|   |           |Derivation | |Derivation | |Derivation | |            |
|   |           +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ |            |
|   |                             |                 |     |            |
|   |                 ^           |                 |     |            V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+         ---+
    |                 |           |                 |                  ^
    | Peer-ID,        |           |                 |          Exported|
    | Server-ID,      | Channel   | MSK (64+B)      | IV (64B)    by   |
    | Method-ID,      | Bindings  | EMSK (64+B)     |             EAP  |
    | Key-Lifetime    | & Result  |                 |           Method |
    V                 V           V                 V                  V

     Figure 1:  EAP Method Parameter Import/Export

   EAP methods also MAY export method-specific peer and server
   identifiers (peer-ID and server-ID), a method-specific EAP
   conversation identifier known as the Method-ID, and the lifetime of
   the exported keys, known the Key-Lifetime.   EAP methods MAY also
   support the import and export of Channel Bindings.  New EAP method
   specifications MUST define the Peer-ID, Server-ID and Method-ID. The
   combination of the Peer-ID and Server-ID uniquely specifies the
   endpoints of the EAP method exchange.

Peer-ID

   As described in [RFC3748] Section 7.3, the identity provided in the
   EAP-Response/Identity, may be different from the peer identity
   authenticated by the EAP method.  Where the EAP method authenticates
   the peer identity, that identity is exported by the method as the
   Peer-ID.  A suitable EAP peer name may not always be available.
   Where an EAP method does not define a method-specific peer identity,
   the Peer-ID is the null string.   The Peer-ID for existing EAP
   methods is defined in Appendix E. B.

Server-ID

   Where the EAP method authenticates the server identity, that identity
   is exported by the method as the Server-ID.  A suitable EAP server
   name may not always be available.  Where an EAP method does not
   define a method-specific peer identity, the Server-ID is the null
   string.  The Server-ID for existing EAP methods is defined in
   Appendix E. B.

Method-ID

   EAP method specifications deriving keys MUST specify a temporally
   unique method identifier known as the Method-ID.  The EAP Method-
      ID Method-ID
   uniquely identifies an EAP session of a given Type between an EAP
   peer and server.  The Method-ID is typically constructed from nonces
   or counters used within the EAP method exchange.  The Method-ID for
   existing EAP methods is defined in Appendix E. B.

Session-ID

   The Session-ID uniquely identifies an EAP session between an EAP peer
   (as identified by the Peer-ID) and server (as identified by the
   Server-ID).  The EAP Session-ID consists of the concatenation of the
   Expanded EAP Type Code (including the Type, Vendor-ID and Vendor-Type
   fields defined in [RFC3748] Section 5.7) and the Method-ID.  The
   inclusion of the Expanded Type Code in the EAP Session-Id ensures
   that each EAP method has a distinct Session-ID space.  Since an EAP
   session is not bound to a particular authenticator or specific ports
   on the peer and authenticator, the authenticator port or identity are
   not included in the Session-Id.

Key-Lifetime

   While EAP itself does not support key lifetime negotiation, it is
   possible to specify methods that do.  However, systems that rely on
   such negotiation for exported keys would only function with these
   methods. As a result, it is NOT RECOMMENDED to use this approach as
   the sole way to determine key lifetimes.

Channel Bindings

   Channel Bindings include lower layer parameters that are verified for
   consistency between the EAP peer and server.  In order to avoid
   introducing media dependencies, EAP methods that transport Channel
   Binding data MUST treat
      Channel Bindings this data as opaque octets.  Typically the
   EAP method imports Channel Bindings from the lower layer on the peer,
   and transmits them securely to the EAP server, which exports them to
   the lower layer.  However, transport may occur from EAP server to
   peer, or may be bi-directional.  On the side of the exchange (peer or
   server) where Channel Bindings are verified, the lower layer passes
   the result of the verification (TRUE or FALSE) up to the EAP method.

1.3.1.  Layering

   As illustrated in Figure 2,  keying material and parameters exported
   by EAP methods are passed down to  Key Naming

   Each key created within the EAP peer or authenticator
   layers, which passes them key management framework has a name
   (a unique identifier), as well as a scope (the parties to whom the EAP layer.  Keying material and
   related
   key is available).  The scope of exported parameters (including Channel Bindings) MUST NOT be cached is defined by
   the EAP peer or authenticator layers, or name (if securely exchanged within the method) and the
   EAP layer.

   Based on server name (also only if securely exchanged).  Where a peer or
   server name is missing the Method-ID null string is used.

MSK, EMSK and IV Names
     These parameters are exported by the EAP method, the peer and EAP layer
   forms server, and
     can be referred to using the EAP Session-ID by concatenating and a binary or textual
     indication of the EAP Expanded Type with parameter being referred to.

PMK Name
     This document does not specify a naming scheme for the Method-ID.  Together with PMK.  The
     PMK is only identified by the MSK, EMSK, IV, Peer-ID, Server-ID,
   and Key-Lifetime, key from which it is derived.

     Note: IEEE 802.11i names the EAP layer passes PMKID for the Session-ID down purposes of being able
     to refer to it in the
   lower layer.

   The Method-ID Secure Association protocol; this naming is exported by EAP methods rather than
     based on a hash of the Session-ID
   so PMK itself as to prevent EAP methods from writing into each other's Session-
   ID space.  Lower layers MAY cache keying material and related
   parameters, including Channel Bindings.  Lower Layer behavior well as some other parameters
     (see Section 8.5.1.2 [IEEE-802.11i]).

TEK Name
     The TEKs may or may not be named.  Their naming is
   discussed in more detail specified in Section 2.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                             |
   |                                             |
   |          EAP method                         |
   |                                             |
   | MSK, EMSK, IV,             Channel          |
   | Peer-ID, Server-ID,        Bindings         |
   | Method-ID,                                  |
   | Key-Lifetime                                |
   |                                             |
   |       V                       ^         ^   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP  ! Peer or Authenticator !         !   |
   |       ! layer                 !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP  ! layer                 !         !   |
   |       !                       !         !   |
   |       ! Session-ID =          !         !   |
   |       ! Expanded-Type ||      !         !   |
   |       ! Method-ID             !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   | Lower ! layer                 !         !   |
   |       !                       !         !   |
   |       V                       V         ^   |
   | MSK, EMSK, IV,             Channel   Result |
   | Peer-ID, Server-ID,        Bindings         |
   | Session-ID,                                 |
   | Key-Lifetime                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2:  Flow of EAP parameters

1.3.2.  Key Naming

   Each key created within the
     EAP key management framework has a name
   (the identifier by which method.

TSK Name
     The TSKs are typically named.  Their naming is specified in the key
     lower layer so that the correct set of transient session keys can
     be identified), as well as identified for processing a
   scope (the parties to whom the key is available).  The scope of
   exported parameters is defined by the given packet.

1.4.  EAP peer name (if securely
   exchanged within the method) and the Invariants

   Certain basic characteristics, known as "EAP Invariants", hold true
   for EAP server name (also only if
   securely exchanged).  Where a peer or server name is missing the null
   string is used.

MSK Name
     This key is created between the EAP peer and EAP server, and can be
     referred to using the string "MSK:", concatenated with the EAP
     Session-ID.

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

IV Name
     Use of the IV is deprecated.  However, if necessary the IV can be
     referred to using the string "IV:" concatenated with the EAP
     Session-ID.

PMK Name
     This document does not specify a naming scheme for the PMK.  The
     PMK is only identified by the key from which it is derived.

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

TEK Name
     The TEKs may or may not be named.  Their naming is specified in the
     EAP method.

1.3.3.  EAP and AAA all media:

      Mode independence
      Media independence
      Method independence
      Ciphersuite independence

1.4.1.  Mode Independence

   EAP is typically deployed in order to support extensible network
   access authentication in situations where a peer desires network
   access via one or more authenticators.  Since both the peer and
   authenticator may have more than one physical or logical port, a
   given peer may simultaneously access the network via multiple
   authenticators, or via multiple physical or logical ports on a given
   authenticator.  Similarly, an authenticator may offer network access
   to multiple peers, each via a separate physical or logical port.  The
   situation is illustrated in Figure 3.  Where authenticators are
   deployed standalone, the EAP conversation occurs between the peer and
   authenticator, and the authenticator must locally implement an EAP
   method acceptable to the peer.  However, one of the advantages of EAP
   is that it enables deployment of new authentication methods without
   requiring development of new code on the authenticator.

   While the authenticator may implement some EAP methods locally and
   use those methods to authenticate local users, it may at the same
   time act as a pass-through for other users and methods, forwarding
   EAP packets back and forth between the backend authentication server
   and the peer.  This is accomplished by encapsulating EAP packets
   within the Authentication, Authorization and Accounting (AAA)
   protocol, spoken between the authenticator and backend authentication
   server.  AAA protocols supporting EAP include RADIUS [RFC3579] and
   Diameter [I-
   D.ietf-aaa-eap].

                            +-+-+-+-+
                            |       |
                            | [RFC4072].

   It is a fundamental property of EAP   |
                            | Peer  |
                            |       |
                            +-+-+-+-+
                              | | |  Peer Ports
                             /  |  \
                            /   |   \
                           /    |    \
                          /     |     \
                         /      |      \
                        /       |       \
                       /        |        \
                      /         |         \
                   | | |      | | |      | | |  Authenticator Ports
                 +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                 |       |  |       |  |       |
                 | Auth. |  | Auth. |  | Auth. |
                 |       |  |       |  |       |
                 +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                      \         |         /
                       \        |        /
                        \       |       /
          EAP over AAA   \      |      /
            (optional)    \     |     /
                           \    |    /
                            \   |   /
                             \  |  /
                            +-+-+-+-+
                            |       |
                            | AAA   |
                            |Server |
                            |       |
                            +-+-+-+-+

Figure 3:  Relationship between peer, authenticator and backend server

1.4.  EAP Invariants

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

      Mode independence
      Media independence
      Method independence
      Ciphersuite independence

1.4.1.  Mode Independence

   EAP as defined in [RFC3748] is a two party protocol spoken between
   the EAP peer and server.  A fundamental property of EAP is that at the EAP method layer, the
   conversation between the EAP peer and server is unaffected by whether
   the EAP authenticator is operating in "pass-through" mode.  EAP
   methods operate identically in all aspects, including key derivation
   and parameter import/export, regardless of whether the authenticator
   is operating as a pass-through or not.

   The successful completion of an EAP method that supports key
   derivation results in the export of keying material on the EAP peer
   and server.  Even though the EAP peer or server may import Channel-
   Bindings that may include the identity of the EAP authenticator,
   this information is treated as opaque octets.  As a result, within
   EAP the only relevant identities are the Peer-ID and Server-ID.
   Channel Bindings are only interpreted by the lower layer.

   Within EAP, the primary function of the AAA protocol is to maintain
   the principle of Mode Independence, so that as far as the EAP peer is
   concerned, its conversation with the EAP authenticator, and all
   consequences of that conversation, are identical, regardless of the
   authenticator mode of operation.

1.4.2.  Media Independence

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

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

   Note that media independence may be retained within EAP methods that
   support Channel-Bindings or method-specific identification.  An EAP
   method need not be aware of the content of an identifier in order to
   use it.  This enables an EAP method to use media-specific identifiers
   such as MAC addresses without compromising media independence.
   Channel-Bindings are treated as opaque octets by EAP methods, so that
   handling them does not require media-specific knowledge.

1.4.3.  Method Independence

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

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

1.4.4.  Ciphersuite Independence

   Ciphersuite Independence is a consequence of the principles of Mode
   Independence and Media Independence.

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator within the lower layer, outside of
   EAP.

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

   Since the ciphersuites used to protect data depend on the lower
   layer, requiring EAP methods have knowledge of lower layer
   ciphersuites would compromise the principle of Media Indepence. Independence.
   Since ciphersuite negotiation occurs in the lower layer, there is no
   need for ciphersuite negotiation within EAP, and EAP methods generate
   keying material that is ciphersuite-independent.

   For example, within PPP,

   Algorithms for deriving TSKs MUST NOT depend on the EAP method,
   although algorithms for TEK derivation MAY be specific to the EAP
   method.

   In order to allow a ciphersuite is negotiated to be usable within the
   Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
   authentication is completed.  Within [IEEE-802.11i], keying
   framework, a specification MUST be provided describing how TSKs
   suitable for use with the AP
   ciphersuites ciphersuite are advertised in the Beacon and Probe Responses prior
   to derived from exported EAP authentication, and are securely verified during a 4-way
   handshake exchange.
   keying parameters.

   Advantages of ciphersuite-independence include:

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

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

Simplified configuration
     The ciphersuite is negotiated between the peer and authenticator
     outside of EAP.  Where the authenticator operates in "pass-through"
     mode, the EAP server is not a party to this negotiation, nor is it
     involved in the data flow between the EAP peer and authenticator.
     As a result, the EAP server may not have knowledge of the
     ciphersuites and negotiation policies implemented by the peer and
     authenticator, or be aware of the ciphersuite negotiated between
     them.  For example, since ECP negotiation occurs after
     authentication, when run over PPP, the EAP peer and server may not
     anticipate the negotiated ciphersuite and therefore this
     information cannot be provided to the EAP method.

2.  Lower Layer Operation

2.1.  Overview

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

      Phase 0: Discovery
      Phase 1: Authentication
               1a: EAP authentication
               1b: AAA-Key AAA Key Transport (optional)
      Phase 2: Secure Association Establishment
               2a: Unicast Secure Association
               2b: Multicast Secure Association (optional)

   Of these phases, Phase 0, 1b and Phase 2 are handled by a lower
   layer.  In the discovery phase (phase 0),  peers locate
   authenticators and discover their capabilities.  For example, a  A peer may locate an
   authenticator providing access to a particular network, or a peer may
   locate an authenticator behind a bridge with which it desires to
   establish a Secure Association.  Discovery can occur manually or
   automatically, depending on the lower layer over which EAP runs.

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

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

   A
   In order to obey the principle of Mode Independence, where a backend
   server is present AAA Key transport needs to provide the exported EAP
   keying material and/or derived keys required for derivation of the
   TSKs.  Since existing TSK derivation techniques depend solely on the
   MSK, in existing AAA implementations, this is the only keying
   material replicated in the AAA key transport phase 1b.

   Successful completion of EAP authentication and key derivation by a
   peer and EAP server does not necessarily imply that the peer is
   committed to joining the network associated with an EAP server.
   Rather, this commitment is implied by the creation of a security
   association between the EAP peer and authenticator, as part of the
   Secure Association Protocol (phase 2).

   The Secure Association exchange (phase 2) then occurs between the peer and
   authenticator in order to manage the creation and deletion of unicast
   (phase 2a) and multicast (phase 2b) security associations between the
   peer and authenticator.  The conversation phases and relationship between the parties is
   shown in Figure 4. 2.

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

                  Figure 4: 2: Conversation Overview

2.1.  Discovery Phase

2.2.  Layering

   In the discovery phase (phase 0), the completion of EAP authentication, EAP methods on the peer and authenticator
   locate each other and discover each other's capabilities. Discovery
   can occur manually or automatically, depending on EAP
   server export the lower layer
   over which Master Session Key (MSK), Extended Master Session
   Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
   ID and Key-Lifetime.  As illustrated in Figure 3, EAP runs.  Since authenticator discovery is handled
   outside of EAP, there is no need methods export
   keying material and parameters to provide this functionality within
   EAP.

   For example, where EAP runs over PPP, the EAP peer might be
   configured with a phone book providing phone numbers of
   authenticators and associated capabilities such as supported rates,
   authentication protocols or ciphersuites.  In contrast, PPPoE
   [RFC2516] provides support for a Discovery Stage to allow a authenticator
   layers.

   The EAP peer to
   identify the Ethernet MAC address of one or more authenticators and
   establish a PPPoE SESSION_ID.

   IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
   utilizing Beacon and/or Probe Request/Response frames, allowing authenticator layers MUST NOT modify or cache keying
   material or parameters (including Channel Bindings) passing in either
   direction between the
   peer (known as EAP method layer and the station EAP layer.  The EAP
   layer also MUST NOT cache keying material or STA) parameters (including
   Channel Bindings) passed to determine it by the MAC address and
   capabilities of one or more authenticators (known as Access Point EAP peer/authenticator layer or
   APs).

2.2.  Authentication Phase

   Once
   the peer and authenticator discover each other, they exchange lower layer.

   Based on the Method-ID exported by the EAP packets.  Typically, method, the peer desires access to EAP layer
   forms the network, EAP Session-ID by concatenating the EAP Expanded Type with
   the Method-ID.  Together with the MSK, IV (deprecated), Peer-ID,
   Server-ID, and Key-Lifetime, the authenticators provide that access.  In such a situation, access EAP layer passes the Session-ID down
   to the network can lower layer.

   The EMSK MUST NOT be provided by any authenticator attaching to the
   desired network, and the EAP peer lower layer, nor is typically willing to send data
   traffic through any authenticator that can demonstrate that it is
   authorized permitted
   to provide access pass any quantity to the desired network.

   An EAP authenticator may handle lower layer from which the authentication locally, or it may
   act EMSK could be
   computed without breaking some cryptographic assumption, such as
   inverting a pass-through to a backend authentication server.  In the
   latter case the EAP exchange occurs between the EAP peer one-way function.  As noted in [RFC3748] Section 7.10:

      The EMSK is reserved for future use and a
   backend authenticator server, with the authenticator forwarding EAP
   packets between MUST remain on the two. The entity which terminates EAP
   authentication with the
      peer is known as the and EAP server.  Where pass-
   through is supported, the backend authentication server functions as
   the EAP server; where authentication occurs locally, the EAP server
   is the authenticator.  Where a backend authentication server is
   present, at the successful completion of an authentication exchange,
   the AAA-Key is transported to the authenticator (phase 1b).

   EAP may also be used when it is desired for two network devices (e.g.
   two switches derived; it MUST NOT be
      transported to, or routers) to authenticate each other, shared with, additional parties, or where two
   peers desire used to authenticate each
      derive any other and set up keys.  (This restriction will be relaxed in a secure
   association suitable for protecting data traffic.

   Some
      future document that specifies how the EMSK can be used.)

   The Method-ID is exported by EAP methods exist which only support one-way authentication;
   however, rather than the Session-ID
   so as to prevent EAP methods deriving keys are required to support mutual
   authentication. from writing into each other's Session-
   ID space.

   In either case, it can be assumed that the parties
   do not utilize the link order 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 preserve the security of keys derived within EAP server has authenticated
   successfully to the peer, and a Secure Association has been
   negotiated.

   Since methods,
   lower layers other than AAA MUST NOT export keys passed down by EAP is
   methods.  This implies that EAP keying material or parameters passed
   down to a peer-to-peer protocol, an independent and simultaneous
   authentication may take place in lower layer are for the reverse direction.  Both peers
   may act as authenticators exclusive use of that lower layer
   and authenticatees at the same time.

   Successful completion MUST NOT be used within another lower layer.  This prevents
   compromise of one lower layer from compromising other applications
   using EAP authentication keying parameters.

   EAP keying material and key derivation by parameters provided to a
   peer and lower layer other
   than AAA MUST NOT be transported to another entity.  For example, EAP server does not necessarily imply that
   keying material and parameters passed down to the EAP peer is
   committed lower
   layer MUST NOT leave the peer;  EAP keying material and parameters
   passed down or transported to joining the network associated with an EAP server.
   Rather, this commitment is implied by authenticator lower layer MUST
   NOT leave the creation of a security
   association between authenticator.

   The exception to the "no sharing" rule is the AAA layer.  On EAP peer
   server, keying material requested by and authenticator, as part of passed down to the
   Secure Association Protocol (phase 2).  As a result, EAP AAA layer
   may be used
   for "pre-authentication" in situations where it is necessary to pre-
   establish EAP security associations in order replicated to decrease handoff or
   roaming latency.

2.3.  Secure Association Phase

   The Secure Association phase (phase 2), if it occurs, begins after the completion of EAP authentication (phase 1a) and key transport
   (phase 1b).  A Secure Association Protocol used with EAP typically
   supports AAA layer on the following features:

[1]  Generation of fresh transient session keys (TSKs).  Where AAA-Key
     caching is supported, authenticator.   On the EAP peer
   authenticator, the AAA layer may initiate a new session using
     a AAA-Key that was used in a previous session.  Were provide the TSKs replicated keying
   material to be
     derived from a portion of the AAA-Key,  this would result in reuse
     of the session keys lower layer over which could expose the underlying ciphersuite EAP authentication
   conversation took place.  This enables "mode independence" to attack. be
   maintained.

   As illustrated in Figure 4, a result, where AAA-Key caching is supported, the Secure
     Association Protocol phase is REQUIRED, AAA client receiving transported EAP
   keying material and MUST provide for
     freshness of the TSKs.  This is typically handled via parameters passes them to the exchange
     of nonces or counters, EAP authenticator
   and EAP layers, which are then mixed with the AAA-Key in
     order provide them to generate  fresh unicast (phase 2a) and possibly multicast
     (phase 2b) session keys.  By not using the AAA-Key directly to
     protect data, authenticator lower
   layer using the Secure Association Protocol protects against
     compromise of same mechanisms that would be used if the AAA-Key.

[2]  Entity Naming.  A basic feature of EAP peer
   and authenticator were conducting a Secure Association Protocol is
     the explicit naming of the parties engaged stand-alone conversation.  The
   resulting key state in the exchange.
     Explicit identification of the parties lower layer is critical, since without
     this the parties engaged in indistinguishable between
   the exchange are not identified standalone and pass-through cases, as required by the
     scope principle
   of the transient session keys (TSKs) generated during the
     exchange is undefined.  As illustrated in Figure 3, both the peer
     and NAS may have more than one physical or virtual port, so that
     port identifiers are NOT RECOMMENDED as a naming mechanism.

[3]  Secure capabilities negotiation.  This includes the secure
     negotiation of usage modes, session parameters (such as key
     lifetimes), ciphersuites and required filters, including
     confirmation of the capabilities discovered during phase 0.  It is
     RECOMMENDED that the Secure Association Protocol support secure
     capabilities negotiation, in mode independence.  In order to protect against spoofing
     during prevent the discovery phase, compromise of
   transported EAP keying material and to ensure agreement between parameters, the
     peer AAA client and
   EAP authenticator about how data is to MUST be secured.

[4]  Key management. EAP as defined in [RFC3748] supports key
     derivation, but not key management.  While EAP methods may derive
     keying material, co-resident.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                             |
   |                                             |
   |          EAP does provide for the management of exported or
     derived keys.  For example, method                         |
   |                                             |
   | MSK, EMSK, IV,             Channel          |
   | Peer-ID, Server-ID,        Bindings         |
   | Method-ID,                                  |
   | Key-Lifetime                                |
   |                                             |
   |       V                       ^         ^   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP does not support negotiation of the
     key lifetime of exported  ! Peer or derived keys, nor does it support
     rekey.  Although Authenticator !         !   |
   |       ! layer                 !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   |  EAP methods may support "fast reconnect" as
     defined in [RFC3748] Section 7.2.1, rekey of exported keys cannot
     occur without reauthentication.  In order to provide method
     independence, key management of exported or derived keys SHOULD NOT
     be provided within  ! layer                 !         !   |
   |       !                       !         !   |
   |       ! Session-ID =          !         !   |
   |       ! Expanded-Type ||      !         !   |
   |       ! Method-ID             !         !   |
   |       !                       !         !   |
   +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
   |       !                       !         !   |
   | Lower ! layer                 !         !   |
   |       !                       !         !   |
   |       V                       V         ^   |
   | MSK, IV, Peer-ID,          Channel   Result |
   | Server-ID,                 Bindings         |
   | Session-ID,                                 |
   | Key-Lifetime                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 3:  Flow of EAP methods.

     Since neither parameters
        Peer         Pass-through Authenticator   Authentication
                                                      Server

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   |           |                                   |           |
   |EAP method |                                   |EAP method |
   |     V     |                                   |     V     |
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |     !     |   |EAP  |  EAP nor  |             |   |     !     |
   |     !     |   |Peer |  Auth.| EAP methods provide Auth.   |   |     !     |
   |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
   |     !     |   |     | !     |     !       |   |     !     |
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   |     !     |   |       !     |     !       |   |     !     |
   |EAP  !layer|   |   EAP !layer| EAP !layer  |   |EAP  !layer|
   |     !     |   |       !     |     !       |   |     !     |
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   |     V     |   |       V     |     !       |   |     !     |
   |Lower layer|   |  Lower layer| AAA ! /IP   |   | AAA ! /IP |
   |           |   |             |     !       |   |     !     |
   +-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
                                       !                 !
                                       !                 !
                                       +---------<-------+

       Figure 4:  Flow of EAP Keying Material and Parameters

2.3.  Caching

   Where explicitly supported by the lower layer, lower layers MAY cache
   the exported EAP keying material and parameters and/or TSKs.  The
   structure of this key management support,
     it cache is RECOMMENDED that key management facilities be provided within defined by the Secure Association Protocol.  This includes key lifetime
     management (such as via explicit key lifetime negotiation, or
     seamless rekey), as well synchronization of the installation and
     deletion of keys so lower layer.  So as to
   enable recovery from partial or complete
     loss of key state by the peer or authenticator.  Since key
     management requires a key naming scheme, Secure Association
     Protocols supporting key management support  interoperability, new lower layer specifications MUST also support
   describe EAP key
     naming.

[5]  Mutual proof of possession of the AAA-Key.  The Secure Association
     Protocol MUST demonstrate mutual proof of posession of caching behavior.  Unless explicitly specified by
   the AAA-Key,
     in order to show that both  lower layer, the peer EAP peer, server and authenticator have been
     authenticated MUST assume
   that peers and authorized by the backend authentication server.
     Since mutual proof authenticators do not cache exported EAP keying
   parameters or TSKs.

   The caching behavior of possession existing EAP lower layers is not the same as mutual
     authentication, the peer cannot verify authenticator assertions
     (including the authenticator identity) as a result follows:

PPP  PPP, defined in [RFC1661] does not support caching of this
     exchange.

2.4.  Lower Layer Key Hierarchy

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

    [3] Keys calculated from exported quantities: AAA-Key.
    [4] Keys calculated by the Secure Association Protocol keying
     material or parameters.  Since PPP ciphersuites derive their TSKs
     directly from the
        AAA-Key: TSKs.

   In order MSK as described in [RFC2716], were PPP to protect
     support caching, this could result in stale TSKs.  Therefore once
     the PPP session is terminated, it is assumed that EAP conversation, methods supporting key
   derivation typically negotiate a ciphersuite keying
     material and derive Transient EAP
   Keys (TEKs) for use with that ciphersuite.  The TEKs parameters are stored
   locally by the discarded.

IKEv2
     IKEv2, defined in [IKEv2] only uses EAP method keying material for
     authentication purposes and are not exported. key derivation.  As noted in [RFC3748] Section 7.10, EAP methods generating keys are
   required to calculate and export the MSK and EMSK, which must be at
   least 64 octets in length. a result, IKEv2
     does not cache EAP methods also may export keying material or parameters, nor does it
     utilize the IV;
   however, Key-Lifetime to determine the use lifetime of the IV IPsec SAs.
     As  result, once IKEv2 authentication completes it is deprecated.  On both the peer and assumed that
     EAP
   server, keying material and parameters are discarded.

IEEE 802.11i
     IEEE 802.11i enables caching of the exported MSK is utilized in order to calculate MSK, but not the AAA-
   Key.  Where a backend authentication server is present, EMSK, IV,
     Peer-ID, Server-ID, Session-ID, or Key-Lifetime.  More details are
     about the AAA-Key
   is transported from structure of the backend cache are available in [IEEE-802.11i].

IEEE 802.1X-2004
     IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
     caching of EAP keying material or parameters.  Therefore once EAP
     authentication server to the
   authenticator within the AAA-Token, using the completes, it is assumed that EAP keying material
     and parameters are discarded.

AAA protocol.

   Once  Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
     EAP authentication completes [RFC4207] do not support caching of EAP keying material or
     parameters.  In existing AAA server implementations, exported EAP
     keying material (MSK, EMSK and is successful, the peer IV) as well as parameters and
   authenticator obtain the AAA-Key
     derived keys are not cached and MUST be presumed lost after the Secure Association Protocol
   is run between the peer and authenticator in AAA
     exchange completes.

     In order to securely
   negotiate avoid key reuse, the ciphersuite, derive fresh TSKs used AAA layer MUST delete transported
     keys once they are sent.  The AAA layer MUST NOT retain keys that
     it has previously sent to protect data,
   and provide mutual proof of possession of the AAA-Key.

   When the authenticator acts as an endpoint of the EAP conversation
   rather than authenticator.  For example, a pass-through, EAP methods are implemented on the
   authenticator as well as the peer.  If the EAP method negotiated
   between the EAP peer and authenticator supports mutual authentication
   and key derivation, AAA
     layer that has transported the EAP Master Session Key (MSK) MSK MUST delete it, and Extended
   Master Session Key (EMSK) are keys MUST
     NOT be derived on from the MSK from that point forward.

2.4.  Key Scope

   It should be understood that an EAP peer and authenticator and exported by the EAP method.  In or peer:

   [a] may contain one or more physical or logical ports;
   [b] may advertise itself as one or more "virtual"
       authenticators or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or failover.

   The issues that arise from this case, the MSK
   and EMSK are known only to discussed below.

2.4.1.  Multiple Ports

   Both the EAP peer and authenticator and no other
   parties.  The TEKs and TSKs also reside solely on the may have more than one physical
   or logical port.  A peer and may simultaneously access the network via
   multiple authenticators, or via multiple physical or logical ports on
   a given authenticator.  This  Similarly, an authenticator may offer network
   access to multiple peers, each via a separate physical or logical
   port.  The situation is illustrated in Figure 6.  As demonstrated in
   [I-D.ietf-roamops-cert], in this case it is still possible to support
   roaming between providers, using certificate-based authentication.

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

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

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+
|                                                         |            ^ 5.

                               +-+-+-+-+
                               | EAP Method                               |  Local to  |   |
                               |       EAP Peer  |
                               +-+-+-+-+
                                 | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |  Peer Ports
                                /  |  \
                               /   |  TEK   \
                              /    |    \
                             /     | MSK     \
                            /      | |EMSK      \
                           /       | |IV       \
                          /        |        \
                         /         |         \
                      | | |Derivation | |Derivation      | |Derivation | |Derivation | |            |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |      | | |  Authenticator Ports
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                    |       |            V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         ---+  |       |  |                  ^       | MSK (64B)
                    | EMSK (64B) Auth. | IV (64B) Exported|  | Auth. |  |              by Auth. |
                    |       |  |              EAP       |  |               V                 V                  v       |                                                 ---+
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                         \         | AAA-Key                                Transported         /
                          \        |        /
                           \       |                                             by       /
             EAP over AAA   \      |      /
               (optional)    \     |                                           Protocol |
                  V                                                    V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+
   |                           |                                       ^
   |     TSK  Derivation       |                           Lower layer |
   |     [AAA-Key Cache]       |                              Specific |
   |                           |                                       V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                    ---+

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

   Figure 6: 5:  Relationship between EAP peer, authenticator and server

   Absent explicit specification within the lower layer, EAP keying
   material and parameters are not bound to a specific peer or
   authenticator port.  Where the peer and authenticator (acting identify
   themselves within the lower layer using a port identifier such as
   an EAP server), where no backend authentication server is present.

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

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

2.5.  AAA-Key Derivation and Naming

   In existing usage, where a AAA-Key is generated as the result of
   link layer address, this creates a
   successful EAP authentication with the authenticator, the AAA-Key is
   based on the MSK:  AAA-Key = MSK(0,63).

   In existing usage, the AAA-Key is always derived from the MSK so can problem, because it may not be referred
   obvious to using the MSK name.

   The AAA-Key scope is provided by the concatenation of the EAP peer
   name (if securely provided which authenticator ports are associated with
   which authenticators.  Similarly, it may not be obvious to the authenticator), and
   authenticator which peer ports are associated with which peers.  As a
   result, the peer and authenticator name (if securely provided may not be able to determine the peer).

   For the purpose
   scope of identifying the authenticator to EAP keying material.  This is particularly problematic
   for lower layers where key caching is supported.

   For example, where the peer, EAP peer cannot identify the
   value EAP
   authenticator, it will be unable to determine whether EAP keying
   material has been shared outside of the NAS-Identifier attribute its authorized scope, and
   therefore needs to be considered compromised.  There is recommended.  The
   authenticator may include also a
   practical problem because the NAS-Identifier attribute EAP peer will be unable to utilize the AAA
   server
   EAP authenticator key cache in an Access-Request, efficient way.

   The solution to this problem is for lower layers to identify EAP
   peers and authenticators unambiguously, without incorporating
   implicit assumptions about peer and the authenticator architectures.  Use
   of port identifiers is NOT RECOMMENDED where peers and authenticators
   may support multiple ports.

   AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
   a mechanism for the
   NAS-Identifier to identification of AAA clients; since the EAP peer.  Mechanisms for
   authenticator and AAA client are always co-resident, this include use of mechanism
   can be applied to the EAP-Request/Identity (unsecured) identification of EAP authenticators.

   RADIUS requires that an Access-Request packet contain one or a lower layer mechanism (such
   as more of
   the 802.11 Beacon/Probe Response).  Where NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes.
   Since a NAS may have more than one IP address associated with it, the
   NAS-Identifier attribute is
   provided by RECOMMENDED for the authenticator to unambiguous
   identification of the peer a secure mechanism is
   RECOMMENDED.

   For EAP authenticator.

   From the purpose point of view of identifying the peer AAA server, EAP keying material and
   parameters are transported to the authenticator, NAS identified by the EAP
   peer identifier provided within NAS-
   Identifier attribute.  Since the NAS/ EAP method is recommended.  It
   cannot be assumed that the authenticator is aware of MUST NOT
   share EAP keying material or parameters with another party, if the
   EAP peer
   name used within or AAA server detects use of EAP keying material and
   parameters outside the method.  Therefore alternatives mechanisms need
   to scope defined by the NAS-Identifier, the
   keying material MUST be used considered compromised.

   In order to provide further limit the key scope the following measures are
   suggested:

[a]  The lower layer MAY specify additional restrictions on key usage,
     such as limiting the use of EAP keying material and parameters on
     the EAP peer name to the authenticator.  For
   example, port over which on the EAP conversation was
     conducted.

[b]  The AAA server may include the EAP peer name and client/authenticator MAY implement additional
     attributes in order to further restrict the User-
   Name attribute scope of EAP keying
     material.  For example, in 802.11, the Access-Accept or the peer AAA server may provide the
     authenticator with its name via a lower layer mechanism.

   Absent an explicit binding step within the Secure Association
   Protocol, the AAA-Key is not bound to a specific peer or
   authenticator port.  As a result, the peer list of authorized Called or authenticator port over Calling-Station-
     Ids and/or SSIDs for which the EAP conversation takes place keying material is not included in valid.

[c]  Where the AAA-Key
   scope.

2.5.1.  TSKs

   The TSKs are typically named. Their naming is specified in AAA server provides attributes restricting the Secure
   Association (phase 2) protocol, so key scope,
     it is RECOMMENDED that restrictions be securely communicated by the correct set of transient
   session keys
     authenticator to the peer.  This can be identified for processing a given packet.  The
   scope of the TSKs is negotiated within accomplished using the
     Secure Association
   Protocol.

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

   In order to avoid confusion in accomplished via the case where an
     EAP peer has more
   than one AAA-Key (phase 1b) applicable to establishment of method or the lower layer.

2.4.2.  Virtual Authenticators

   When a phase 2
   security association, single physical authenticator advertises itself as multiple
   "virtual authenticators", the secure Association protocol needs EAP peer and authenticator also may not
   be able to
   utilize the AAA-Key name so that agree on the appropriate phase 1b keying
   material can be identified for use in scope of the Secure Association Protocol
   exchange.

3.  Security Associations

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

[1]  EAP method SA.  This SA is between vulnerability.  For example, the peer and EAP server.  It
     stores state may assume that can be used for "fast reconnect" the
   "virtual authenticators" are distinct and do not share a key cache,
   whereas, depending on the architecture of the physical authenticator,
   a shared key cache may or other
     functionality in some EAP methods.  Not all may not be implemented.

   Where EAP methods create such
     an SA.

[2]  EAP-Key SA.  This keying material is an SA shared between the "virtual authenticators"
   an attacker acting as a peer could authenticate with the "Guest"
   "virtual authenticator" and derive EAP server, which
     is used to store the keying material exported by the EAP method.
     Current EAP server implementations do not retain this SA after material.  If the
     EAP conversation completes.

[3]  AAA SA(s).  These SAs are between
   virtual authenticators share a key cache, then the authenticator and peer can utilize
   the backend
     authentication server.  They permit EAP keying material derived for the parties "Guest" network to obtain
   access 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 "Corporate Intranet" virtual authenticator.

   Several measures are created as a result of phases 1-2 of the conversation
     (see Section 2).

   Examples of security associations recommended to address these issues:

[d]  Authenticators are provided in Appendix F.

3.1.  EAP Method SA (peer - EAP server)

   An REQUIRED to cache associated authorizations
     along with EAP method may store some state on the peer keying material and EAP server parameters and to apply
     authorizations consistently.  This ensures that an attacker cannot
     obtain elevated privileges even
   after phase 1a has completed.

   Typically, this where the key cache is used shared
     between "virtual authenticators".

[e]  It is RECOMMENDED that physical authenticators maintain separate
     key caches for "fast reconnect": the peer and EAP server
   can confirm each "virtual authenticator".

[f]  It is RECOMMENDED that they are still talking each "virtual authenticator" identify itself
     distinctly to the same party, perhaps
   using fewer round-trips or less computational power. In this case,
   the EAP method SA is essentially AAA server, such as by utilizing a cache for performance
   optimization, and either party may remove distinct NAS-
     Identifier attribute.  This enables the SA from its cache at
   any point.

   An EAP method may also keep state in order AAA server to support pseudonym-based
   identity protection. This is typically utilize a cache as well (the
   information can be recreated if the original
     separate credential to authenticate each "virtual authenticator".

3.  Key Management

   EAP method SA is lost), as defined in [RFC3748] supports key derivation, but not key
   management.  While EAP methods may be stored for longer periods of time.

   The derive keying material, EAP method SA is does
   not restricted to a particular service or
   authenticator and is most useful when the peer accesses many
   different authenticators.  An EAP method is responsible provide for
   specifying how the parties select if an existing management of exported or derived keys.  For
   example, EAP method SA should
   be used, and if so, which one.  Where multiple backend authentication
   servers are used, EAP method SAs are does not typically synchronized
   between them.

   EAP method implementations should consider support negotiation of the appropriate key lifetime
   for the of
   exported or derived keys, nor does it support re-key.  Although EAP method SA. "Fast
   methods may support "fast reconnect" assumes as defined in [RFC3748] Section
   7.2.1, re-key of exported keys cannot occur without re-
   authentication.  In order to provide method independence, key
   management of exported or derived keys SHOULD NOT be provided within
   EAP methods.

3.1.  Secure Association Protocol

   Since neither EAP nor EAP methods provide key management support, it
   is RECOMMENDED that key management facilities be provided within the information
   required (primarily
   Secure Association Protocol.  This includes:

[a]  Entity Naming.  A basic feature of a Secure Association Protocol is
     the keys explicit naming of the parties engaged in the EAP method SA) hasn't been
   compromised. In case exchange.
     Without explicit identification, the original authentication was carried out
   using, for instance, a smart card, it may be easier to compromise parties engaged in the
   EAP method SA (stored on
     exchange are not identified and the PC, for instance), so typically scope of the EAP
   method SAs have a limited lifetime.

   Contents:

      o  Implicitly, keying
     parameters negotiated during the EAP method this SA refers to
      o  Internal (non-exported) cryptographic state
      o  EAP method SA name
      o  SA lifetime

3.2.  EAP-Key SA

   This exchange is an SA between undefined.  As
     shown in Figure 5, both the peer and EAP server, which authenticator may have more
     than one physical or virtual port, and as a result SHOULD identify
     themselves in a manner that is used to store
   the independent of their attached ports.

[b]  Mutual proof of possession of EAP keying material exported by material.  During the
     Secure Association Protocol the EAP method.  Current EAP server
   implementations do not retain this SA after the EAP conversation
   completes.  As a result, all keys exported by the EAP method
   (including the MSK, EMSK and IV) on the AAA server are discarded peer and
   are not cached.  Calculated keys (such as authenticator MUST
     demonstrate possession of the AAA-Key) are also
   discarded and not cached.

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

   In order for keying material transported between
     the authenticator and backend authentication server and authenticator (e.g. MSK), in
     order to
   authenticate each other, they need to store some information.

   In case demonstrate that the authenticator peer and backend authentication server are
   colocated, authenticator have been and they communicate using local procedure calls or shared
   memory, this SA need
     authorized.  Since mutual proof of possession is not necessarily contain any information.

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

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

   The Root service SA is established same as
     mutual authentication, the result of peer cannot verify authenticator
     assertions (including the completion authenticator identity) as a result of
   EAP authentication (phase 1a) and AAA-Key derivation or transport
   (phase 1b).  It includes:

      o  Service parameters (or at least those parameters
         that are still needed)
      o  On the authenticator, service authorization
         information received from
     this exchange.

[c]  Secure capabilities negotiation.  In order to protect against
     spoofing during the backend authentication
         server (or necessary parts discovery phase, ensure selection of it)
      o  On the peer, usually locally configured service
         authorization information.
      o  The AAA-Key, if it can be needed again (to refresh
         and/or resynchronize other keys or for another reason)
      o  AAA-Key lifetime

   Unicast "best"
     ciphersuite, and (optionally) multicast service SAs are derived from the
   Root service SA, via protect against forging of negotiated security
     parameters, the Secure Association Protocol.  In order for
   unicast and multicast service SAs and associated TSKs to be
   established, it is not necessary for EAP authentication (phase 1a) to
   be rerun each time.  Instead, Protocol MUST support secure
     capabilities negotiation.  This includes the secure negotiation of
     usage modes, session parameters (such as security association
     identifiers (SAIDs) and key lifetimes), ciphersuites and required
     filters, including confirmation of security-relevant capabilities
     discovered during phase 0.  As part of secure capabilities
     negotiation, the Secure Association Protocol can be
   used to mutually prove possession of the AAA-Key and create
   associated unicast (phase 2a) MUST support integrity
     and multicast (phase 2b) service SAs replay protection of all messages.

[d]  Key naming and TSKs, enabling selection.  Where key caching is supported, it may
     be possible for the EAP exchange to be bypassed.  Unicast peer and
   multicast service SAs include:

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

   One function share more than
     one key of a given type.  As a result, the Secure Association
     Protocol is to bind MUST explicitly name the keys used in the
   unicast and multicast service SAs and TSKs proof of
     possession exchange, so as to endpoint identifiers.
   For example, within [IEEE802.11i], the 4-way handshake binds prevent confusion when more than one
     set of keying material could potentially be used as the TSKs
   to basis for
     the MAC addresses exchange.  Use of the endpoints; key naming mechanism described in [IKEv2], the TSKs are bound this
     document is RECOMMENDED.

     In order to support the IP addresses correct processing of phase 2 security
     associations, the endpoints Secure Association (phase 2) protocol MUST
     support the naming of phase 2 security associations and associated
     transient session keys, so that the negotiated SPI.

   It is possible correct set of transient
     session keys can be identified for more than one unicast or multicast service SA to
   be derived from a single Root service SA.  However, processing a unicast or
   multicast service SA is always descended from only one Root service
   SA.  Unicast or multicast service SAs descended from given packet.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation and SHOULD support deletion, so that
     establishment and re-establishment of transient session keys can be
     synchronized between the same Root
   service SA may utilize parties.

[e]  Generation of fresh transient session keys (TSKs).  Where the lower
     layer supports caching of exported EAP keying material, the same security parameters (e.g. mode,
   ciphersuite, etc.) or they may utilize different parameters.

   An EAP
     peer lower layer may be able to negotiate multiple service SAs with initiate a
   given authenticator, or may be able new session using keying material
     that was derived in a previous session.  Were the TSKs to maintain one or more service
   SAs with multiple authenticators, depending on be
     derived from a portion of the properties exported EAP keying material, this
     would result in reuse of the
   media.

   Except session keys which could expose the
     underlying ciphersuite to attack.

     In lower layers where explicitly specified by caching of EAP keying material is supported,
     the Secure Association Protocol,
   it should not be assumed that the installation of new service SAs
   implies deletion of old service SAs.  It Protocol phase is possible for multicast
   Root service SAs to between the same EAP peer REQUIRED, and authenticator;
   during a re-key MUST support
     the derivation of a fresh unicast or and multicast service SA it is possible
   for two service SAs to exist during the period between TSKs, even when the new
   service SA and corresponding TSKs are calculated and when they are
   installed.

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

   The deletion of the Root service SA does backend authentication server is
     not necessarily imply fresh.  This is typically supported via the
   deletion exchange of nonces
     or counters, which are then mixed with the derived exported keying material
     in order to generate  fresh unicast (phase 2a) and possibly
     multicast service SAs and
   associated TSKs.  Failure (phase 2b) session keys.  By not using EAP keying
     material directly to mutually prove possession of the AAA-Key
   during protect data, the Secure Association Protocol exchange need
     protects it against compromise.

[f]  Key lifetime management.  This includes explicit key lifetime
     negotiation or seamless re-key.  EAP does not be grounds
   for deletion support negotiation
     of the AAA-Key by both parties; the action to be taken
   is defined by key lifetimes, nor does it support re-key without re-
     authentication.   As a result, the Secure Association Protocol.

3.4.1.  Sharing service SAs

   A single service Protocol may be provided by multiple logical or physical
   service elements.  Each service
     handle re-key and determination of the key lifetime.  Where key
     caching is responsible for specifying how
   changing service elements supported, secure negotiation of key lifetimes is handled. Some approaches include:

Transparent sharing
     If the service parameters visible to the other party (either peer
     or authenticator) do
     RECOMMENDED.  Lower layers that support re-key, but not change, the service can be moved without
     requiring cooperation key
     caching, may not require key lifetime negotiation.  To take an
     example from IKE, the other party.

     Whether such a move should be supported or used depends on
     implementation difference between IKEv1 and administrative considerations. For instance, an
     administrator may decide to configure a group of IKEv2/IPsec
     gateways IKEv2 is that in a cluster for high-availability purposes, if the
     implementation used supports this. The peer does not necessarily
     have any way
     IKEv1 SA lifetimes were negotiated. In IKEv2, each end of knowing when the change occurs.

No sharing
     If the service parameters require changing, some changes may
     require terminating the old service, and starting a new
     conversation from phase 0. This approach SA is used by all services
     for at least some parameters, and it doesn't require any protocol
     responsible for transferring enforcing its own lifetime policy on the service SA between the service elements.

     The service may support keeping the old service element active
     while the new conversation takes phase, to decrease the time and re-
     keying the
     service SA when necessary.

[g]  Key resynchronization.  It is not available.

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

     This option usually requires some protocol for transferring
     authenticator to reboot or reclaim resources, clearing portions or
     all of the
     service SA between key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the elements. An administrator key cache will remain synchronized, and the peer
     may decide not be able to
     enable this feature at all, and typically determine before attempting to use a key whether
     it exists within the sharing authenticator cache.  It is restricted therefore
     RECOMMENDED for the Secure Association Protocol to some particular service elements (defined either by provide a service
     parameter,
     mechanism for key state resynchronization.  Since in this situation
     one or simple administrative decision). If more of the old and new
     service element parties initially do not support such "context transfer", this
     approach falls back possess a key with
     which to protect the previous option (no transfer).

     Services supporting resynchronization exchange, securing this feature should also consider what changes
     require new authorization from
     mechanism may be difficult.

[h]  Key scope synchronization.  Since the backend authentication server
     (see Section 5.2).

     Note that these considerations are Discovery phase is handled
     out-of-band, EAP does not limited to service
     parameters related to provide a mechanism by which the authenticator--they apply to peer
     parameters as well.

4.  Key Management

   EAP supports key derivation, but not key management. can
     determine the authenticator identity.  As a result,
   key management functionality needs to be provided by where the Secure
   Association Protocol.  This includes:

[a]  Generation of fresh transient session keys (TSKs).  Where AAA-Key
     authenticator has multiple ports and key caching is supported, the
     EAP peer may initiate a new session using
     a AAA-Key that was used in a previous session.  Were the TSKs to not be
     derived from a portion of able to determine the AAA-Key,  this would result in reuse scope of validity of the session keys which could expose
     exported EAP keying material.  Similarly, where the underlying ciphersuite EAP peer has
     multiple ports, the authenticator may not be able to attack.  As determine
     whether a result, where AAA-Key caching is supported, peer has authorization to use a particular key.  To allow
     key scope determination, the Secure Association Protocol phase is REQUIRED, and MUST SHOULD
     provide for
     freshness of a mechanism by which the TSKs.

[b]  Key lifetime determination.  EAP does not support negotiation peer can determine the scope of
     key lifetimes, nor does it support rekey without reauthentication.
     As a result,
     the Secure Association Protocol may handle rekey key cache on each authenticator, and
     determination by which the authenticator
     can determine the scope of the key lifetime.  Where key caching is supported,
     secure cache on a peer.  This includes
     negotiation of restrictions on key lifetimes usage.

[i]  Direct operation.  Since the phase 2 Secure Association Protocol is RECOMMENDED.  Lower layers
     that support rekey, but not key caching, may not require key
     lifetime negotiation.  To take an example from IKE,
     concerned with the difference
     between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were
     negotiated. In IKEv2, each end establishment of security associations between
     the SA is responsible for
     enforcing its own lifetime policy on the SA EAP peer and rekeying the SA
     when necessary.

[c]  Key resynchronization.  It is possible for authenticator, including the peer or
     authenticator to reboot or reclaim resources, clearing portions or
     all derivation of
     transient session keys, only those parties have "a need to know"
     the key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the key cache will remain synchronized, and transient session keys. The Secure Association Protocol MUST
     operate directly between the peer
     may not and authenticator, and MUST NOT
     be able passed-through to determine before attempting the backend authentication server, or include
     additional parties.

[j]  Bi-directional operation While some ciphersuites only require a
     single set of transient session keys to use protect traffic in both
     directions, other ciphersuites require a AAA-Key
     whether it exists within the authenticator cache.  It is therefore
     RECOMMENDED for the unique set of transient
     session keys in each direction. The phase 2 Secure Association
     Protocol to SHOULD provide a
     mechanism for key state resynchronization.  Since in this situation
     one or more of the parties initially do derivation of unicast and multicast
     keys in each direction, so as not possess a key with
     which to protect the resynchronization exchange, securing this
     mechanism may be difficult.

[d]  Key selection.  Where key caching is supported, it may be possible
     for the EAP peer and authenticator require two separate phase 2
     exchanges in order to share more than one key of a
     given type.  As create a result, bi-directional phase 2 security
     association.

3.2.  Parent-Child Relationships

   When keying material exported by EAP methods expires,  all keying
   material derived from the Secure Association Protocol needs to
     support key selection, using exported keying material expires, including
   the TSKs.

   When an EAP Key Naming scheme described in
     this document.

[e]  Key scope determination.  Since the Discovery phase re-authentication takes place, new keying material is handled out-
     of-band, EAP does not provide a mechanism
   derived and exported by which the peer can
     determine EAP method, which eventually results in
   replacement of calculated keys, including the authenticator identity. TSKs.

   As a result, where the
     authenticator has multiple ports and AAA-Key caching is supported,
     the EAP peer may not be able to determine  while the scope lifetime of validity calculated keys can be less than
   or equal that of
     a AAA-Key.  Similarly, where the exported keys they are derived from, it cannot
   be greater.  For example, TSK re-key may occur prior to EAP peer has multiple ports, re-
   authentication.

   Failure to mutually prove possession of keying material during the
     authenticator may
   Secure Association Protocol exchange need not be able grounds for deletion
   of the keying material by both parties; rate-limiting Secure
   Association Protocol exchanges could be used to determine whether prevent a peer has
     authorization brute force
   attack.

3.3.  Local Key Lifetimes

   The Transient EAP Keys (TEKs) are session keys used to use a particular AAA-Key.  To allow key scope
     determination, the lower layer SHOULD provide a mechanism by which
     the peer can determine protect the scope of
   EAP conversation.  The TEKs are internal to the AAA-Key cache on each
     authenticator, EAP method and by which the authenticator can determine are
   not exported.  TEKs are typically created during an EAP conversation,
   used until the
     scope end of the AAA-Key cache on a peer.

4.1.  Key Caching

   In existing implementations, key caching conversation and then discarded.  However,
   methods may be supported on the re-key TEKs during a conversation.

   When using TEKs within an EAP
   peer conversation or across conversations,
   it is necessary to ensure that replay protection and authenticator but not on the backend server.  Where
   explicitly supported by key separation
   requirements are fulfilled.  For instance, if a replay counter is
   used, TEK re-key MUST occur prior to wrapping of the lower layer, counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK re-keying or caching. This prevents TEK compromise from
   leading directly to compromise of the TSKs and vice versa.

   EAP peer methods may cache local keying material which may persist for
   multiple EAP conversations when fast reconnect is used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
   derive and
   authenticator MAY cache the AAA-Key and/or TSKs. TLS Master Secret, typically for substantial
   time periods.  The structure lifetime of other local keying material calculated
   within the key cache on the peer and authenticator EAP method is defined by the lower
   layer.  Unless specified by method.  Note that in
   general, when using fast reconnect, there is no guarantee to that the lower layer,
   original long-term credentials are still in the possession of the
   peer.  For instance, a card hold holding the private key for EAP-TLS
   may have been removed. EAP peer and
   authenticator MUST assume servers SHOULD also verify that peers and authenticators do not cache the AAA-Key or TSKs.

   In existing AAA server implementations, all keys exported long-
   term credentials are still valid, such as by EAP
   methods (including checking that
   certificate used in the MSK, EMSK and IV) and calculated keys (e.g.
   AAA-Key) are original authentication has not cached yet expired.

3.4.  Exported and are lost after EAP authentication
   completes:

[1]  In order to avoid key reuse, on the Calculated Key Lifetimes

   All EAP server, transported methods generating keys are deleted once they are sent.  An EAP server MUST NOT retain keys
     that it has previously sent required to the authenticator.  For example, an
     EAP server that has transported a AAA-Key based on generate the MSK MUST
     delete the MSK, and no keys
   EMSK, and may be derived from the MSK from that
     point forward by optionally generate the server.

[2]  Keys which are IV.  However, EAP, defined in
   [RFC3748], does not transported, such as the EMSK, are also deleted
     by existing implementations.

4.2.  Parent-Child Relationships

   When keying material exported by EAP methods expires,  all keying
   material derived from support the negotiation of lifetimes for exported
   keying material expires, including such as the AAA-Key MSK, EMSK and TSKs.

   When an EAP reauthentication takes place, new keying material is
   derived IV.

   Several mechanisms exist for managing key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and exported by the EAP method, which eventually results in
   replacement of calculated keys, including
     Diameter [RFC4072] support the AAA-Key and TSKs.

   As a result,  while Session-Timeout attribute.  The
     Session-Timeout value represents the maximum lifetime of the
     exported keys, and all keys calculated from it, on the
     authenticator.  Since existing AAA servers do not cache keys can be less than
     exported by EAP methods, or equal that keys calculated from exported keys, the
     value of the exported keys they are derived from, it cannot
   be greater.  For example, TSK rekey may occur prior to EAP
   reauthentication.

   Failure to mutually prove possession of Session-Timeout attribute has no bearing on the AAA-Key during key
     lifetime within the Secure
   Association Protocol exchange need not be grounds for deletion of AAA server.

     On the
   AAA-Key by both parties; rate-limiting Secure Association Protocol
   exchanges could be used to prevent a brute force attack.

4.3.  Local Key Lifetimes

   The Transient authenticator,  where EAP Keys (TEKs) are session keys is used to protect for authentication, the
   EAP conversation.  The TEKs are internal to
     Session-Timeout value represents the maximum session time prior to
     re-authentication, as described in [RFC3580].  Where EAP method and are
   not exported.  TEKs are typically created during an EAP conversation, is used
     for pre-authentication, the session may not start until some future
     time, or may never occur.  Nevertheless, the end of Session-Timeout value
     represents the conversation and then discarded.  However,
   methods may rekey TEKs during a conversation.

   When using TEKs within an time after which transported EAP conversation keying material,
     and all keys calculated from it, will have expired on the
     authenticator.  If the session subsequently starts, re-
     authentication will be initiated once the Session-Time has expired.
     If the session never started, or across conversations,
   it is necessary to ensure that replay protection started and key separation
   requirements are fulfilled.  For instance, if a replay counter is
   used, TEK rekey MUST occur ended, by default keys
     transported by AAA and all keys calculated from them will be
     expired by the authenticator prior to wrapping of the counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK rekeying or caching. This prevents TEK compromise from
   leading directly to compromise of future time indicated by
     Session-Timeout.

     Since the TSKs and vice versa.

   EAP methods may cache local keying material which may persist for
   multiple EAP conversations when fast reconnect TSK lifetime is used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
   derive and cache often determined by authenticator
     resources, the TLS Master Secret, typically for substantial
   time periods.  The lifetime of other local keying material calculated
   within AAA server has no insight into the EAP method is defined TSK derivation
     process, and by the method.  Note that in
   general, when using fast reconnect, there principle of ciphersuite independence, it is no guarantee
     not appropriate for the AAA server to that manage any aspect of the
   original long-term credentials are still in TSK
     derivation process, including the possession of TSK lifetime.

[b]  Lower layer mechanisms.  While AAA attributes can communicate the
   peer.  For instance, a card hold holding
     maximum exported key lifetime, this only serves to synchronize the private
     key for EAP-TLS
   may have been removed. EAP servers SHOULD also verify that lifetime between the long-
   term credentials are still valid, backend authentication server and the
     authenticator.  Lower layer mechanisms such as by checking that
   certificate the Secure
     Association Protocol can then be used in to enable the original authentication has not yet expired.

4.4.  Exported lifetime of
     exported and Calculated Key Lifetimes

   All EAP methods generating calculated keys are required to generate be negotiated between the MSK and
   EMSK, peer and may optionally generate the IV.  However, EAP, defined in
   [RFC3748], does not support the negotiation of lifetimes for exported
   keying material such
     authenticator.

     Where TSKs are established as the MSK, EMSK and IV.

   Several mechanisms exist for managing key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and
     Diameter [I-D.ietf-aaa-eap] result of a Secure Association
     Protocol exchange, it is RECOMMENDED that the Secure Association
     Protocol include support for TSK resynchronization. Where the Session-Timeout attribute.
     The Session-Timeout value represents TSK
     is taken from the maximum MSK, there is no need to manage the TSK lifetime of
     as a separate parameter, since the
     exported keys, TSK lifetime and all keys calculated from it, on MSK lifetime
     are identical.

[c]  System defaults.  Where the
     authenticator.  Since existing AAA servers do not cache keys
     exported by EAP methods, or keys calculated from exported keys, method does not support the
     value
     negotiation of the Session-Timeout attribute has no bearing on the exported key lifetime, and a key lifetime within the AAA server.

     On the authenticator,  where EAP
     negotiation mechanism is used for authentication, not provided by the
     Session-Timeout value represents lower lower, there may
     be no way for the maximum session time prior peer to
     re-authentication, as described in [RFC3580].  Where EAP is used
     for pre-authentication, learn the session may not start until some future
     time, or may never occur.  Nevertheless, exported key lifetime.  In this
     case it is RECOMMENDED that the Session-Timeout peer assume a default value
     represents of the time after which
     exported key lifetime; 8 hours is recommended.  Similarly, the AAA-Key, and all keys
     lifetime of calculated from it, will have expired keys can also be managed as a system
     parameter on the authenticator.  If the
     session subsequently starts, re-authentication will

[d]  Method specific negotiation within EAP. While EAP itself does not
     support lifetime negotiation, it would be initiated
     once the Session-Time has expired.  If the session never started,
     or started and ended, the AAA-Key and all possible to specify
     methods that do.  However, systems that rely on such negotiation
     for exported keys calculated from would only function with these methods. As a
     result, it
     will be expired by the authenticator prior is NOT RECOMMENDED to use this approach as the future time
     indicated by Session-Timeout.

     Since the TSK lifetime is often determined by authenticator
     resources, sole way
     to determine key lifetimes.

3.5.  Key cache synchronization

   Issues arise when attempting to synchronize the AAA server has no insight into key cache on the TSK derivation
     process, peer
   and by the principle of ciphersuite independence, it authenticator.  Lifetime negotiation alone cannot guarantee key
   cache synchronization.

   One problem is
     not appropriate for that the AAA server to manage any aspect protocol cannot guarantee synchronization
   of the TSK
     derivation process, including the TSK lifetime.

[b]  Lower layer mechanisms.  While AAA attributes can communicate the
     maximum exported key lifetime, this only serves to synchronize the key lifetime lifetimes between the backend authentication server peer and the authenticator.  Lower layer mechanisms such as  Where the
   Secure Association Protocol can then be used to enable is not run immediately after EAP
   authentication, the lifetime of exported and calculated keys to key lifetimes will not be negotiated between
   known by the peer and
     authenticator. during the hiatus.  Where TSKs are established as EAP pre-authentication
   occurs, this can leave the result of peer uncertain whether a subsequent
   attempt to use the exported keys will prove successful.

   However, even where the Secure Association Protocol exchange, is run
   immediately after EAP, it is RECOMMENDED that the Secure Association
     Protocol include support still possible for TSK resynchronization. Where the TSK
     is taken from the AAA-Key, there is no need authenticator to manage the TSK
     lifetime as a separate parameter, since the TSK lifetime and AAA-
     Key lifetime are identical.

[c]  System defaults.  Where the EAP method does not support the
     negotiation of
   reclaim resources if the exported key lifetime, and a created key lifetime
     negotiation mechanism state is not provided by the immediately
   utilized.

   The lower lower, there layer may
     be no way for the peer utilize Discovery mechanisms to learn assist in this.
   For example, the exported key lifetime.  In this
     case it is RECOMMENDED that authenticator manages the peer assume a default value of key cache by deleting the
     exported
   oldest key lifetime; 8 hours is recommended.  Similarly, first (LIFO), the
     lifetime relative creation time of calculated keys can also be managed as a system
     parameter on the authenticator.

[d]  Method specific negotiation within EAP. While EAP itself does not
     support lifetime negotiation, it would be possible last key
   to specify
     methods that do.  However, systems that rely on such negotiation
     for exported keys would only function be deleted could be advertised with these methods. As a
     result, it is NOT RECOMMENDED to use this approach as the sole way Discovery phase, enabling
   the peer to determine whether a given key lifetimes.

4.5.  Key cache synchronization

   Issues arise when attempting to synchronize had been expired from the
   authenticator key cache on the peer
   and authenticator.  Lifetime negotiation alone cannot guarantee prematurely.

3.6.  Key Strength

   In order to guard against brute force attacks, EAP methods deriving
   keys need to be capable of generating keys with an appropriate
   effective symmetric key
   cache synchronization.

   One problem is strength.  In order to ensure that the AAA protocol cannot guarantee synchronization
   of key lifetimes between
   generation is not the peer and authenticator.  Where the
   Secure Association Protocol weakest link, it is not run immediately after RECOMMENDED that EAP
   authentication, the exported and calculated
   methods utilizing public key lifetimes will not be
   known by the peer during the hiatus.  Where EAP pre-authentication
   occurs, this can leave the peer uncertain whether cryptography choose a subsequent
   attempt to use the exported keys will prove successful.

   However, even where the Secure Association Protocol is run
   immediately after EAP, it is still possible for the authenticator to
   reclaim resources if public key that
   has a cryptographic strength meeting the created symmetric key state is not immediately
   utilized.

   The lower layer may utilize Discovery mechanisms to assist strength
   requirement.

   As noted in [RFC3766] Section 5, this results in this.
   For example, the authenticator manages the AAA-Key cache by deleting
   the oldest AAA-Key first (LIFO), the relative creation time of the
   last AAA-Key to be deleted could be advertised with the Discovery
   phase, enabling the peer to determine whether following
   required RSA or DH module and DSA subgroup size in bits, for a given AAA-Key had
   been expired from the authenticator key cache prematurely.

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

3.7.  Key Scope Wrap

   As described in [RFC3579] Section 2.5, 4.3, known problems exist in existing applications the AAA-Key is
   derived from the MSK by
   key wrap specified in [RFC2548].  Where the EAP peer and server, and same RADIUS shared secret
   is used as the
   root of the ciphersuite-specific key hierarchy.  Where by a backend
   authentication server PAP authenticator and an EAP authenticator, there is present, a
   vulnerability to known plaintext attack.  Since RADIUS uses the AAA-Key
   shared secret for multiple purposes, including per-packet
   authentication, attribute hiding, considerable information is transported from exposed
   about the
   EAP server to shared secret with each packet. This exposes the authenticator; where it shared
   secret to dictionary attacks.  MD5 is not present, used both to compute the AAA-Key
   is calculated on RADIUS
   Response Authenticator and the authenticator.

   Regardless of how many sessions are initiated using it, Message-Authenticator attribute, and
   some concerns exist relating to the AAA-Key
   scope is between security of this hash
   [MD5Attack].

   As discussed in [RFC3579] Section 4.3, the EAP peer that calculates it, security vulnerabilities
   of RADIUS are extensive, and therefore development of an alternative
   key wrap technique based on the
   authenticator that either calculates it (where no backend
   authenticator is present) or receives it from the server (where RADIUS shared secret would not
   substantially improve security.  As a
   backend authenticator server result, [RFC3759] Section 4.2
   recommends running RADIUS over IPsec.  The same approach is present).

   It should be understood that an authenticator or peer:

   [a] may contain multiple physical ports;
   [b] may advertise itself as multiple "virtual" authenticators
       or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or failover.

   As illustrated taken in Figure 1, an
   Diameter EAP peer with multiple ports may be
   attached [RFC4072], which defines cleartext key attributes, to one be
   protected by IPsec or more authenticators, each with multiple ports. TLS.

   Where the peer and authenticator identify themselves using a port
   identifier such an untrusted AAA intermediary is present (such as a link layer address, it may RADIUS
   proxy or a Diameter agent), and data object security is not used,
   transported keying material  may be obvious to recovered by an attacker in
   control of the untrusted intermediary.  Possession of transported
   keying material enables decryption of data traffic sent between the
   peer which authenticator ports are associated with which
   authenticators.  Similarly, and a specific authenticator.  However, as long as EAP keying
   material or keys derived from it may is only utilized by a single
   authenticator, compromise of the transported keying material does not be obvious
   enable an attacker to the
   authenticator which peer ports are associated with which peers.  As a
   result, impersonate the peer to another authenticator.

   Vulnerability to an untrusted AAA intermediary can be mitigated by
   implementation of redirect functionality, as described in [RFC3588]
   and authenticator may not [RFC4072].

4.  Handoff Vulnerabilities

   With EAP, a number of mechanisms are be able utilized in order to determine reduce
   the
   scope latency of the AAA-Key.

   When a single physical handoff between authenticators.  One such mechanism is
   EAP pre-authentication, in which EAP is utilized to pre-establish EAP
   keying material on an authenticator advertises itself as multiple
   "virtual authenticators", prior to arrival of the peer.
   Another such mechanism is key caching, in which an EAP peer and can re-
   attach to an authenticator also may not
   be able without having to agree on the scope of the AAA-Key, creating a re-authenticate using
   EAP.  Yet another mechanism is context transfer, such as is defined
   in [IEEE-802.11F] and [CTP].  These mechanisms introduce new security
   vulnerability.  For example,
   vulnerabilities, as discussed in the peer may assume sections that the "virtual
   authenticators" are distinct and do not share follow.

4.1.  Authorization

   In a key cache, whereas,
   depending on the architecture of the physical AP, a shared key cache
   may or may not be implemented.

   Where the AAA-Key is shared between "virtual authenticators" an
   attacker acting typical network access scenario (dial-in, wireless LAN, etc.)
   access control mechanisms are typically applied. These mechanisms
   include user authentication as a peer could authenticate with the "Guest"
   "virtual authenticator" and derive a AAA-Key.  If well as authorization for the virtual
   authenticators share offered
   service.

   As a key cache, then the peer can utilize part of the AAA-
   Key derived for authentication process, the "Guest" AAA network to obtain access to determines
   the
   "Corporate Intranet" virtual authenticator.

   Several measures are recommended to address these issues:

[a]  Authenticators user's authorization profile.  The user authorizations are REQUIRED
   transmitted by the backend authentication server to cache associated authorizations
     along the EAP
   authenticator (also known as the Network Access Server or
   authenticator) included with the AAA-Key and apply authorizations consistently.  This
     ensures that an attacker cannot obtain elevated privileges even
     where AAA-Token, which also contains the AAA-Key cache is shared between "virtual authenticators".

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

[c]  It
   transported EAP keying material, in Phase 1b of the EAP conversation.
   Typically, the profile is RECOMMENDED that each "virtual authenticator" identify itself
     distinctly to determined based on the AAA server, such as by utilizing user identity, but
   a distinct NAS-
     identifier attribute.  This enables certificate presented by the AAA user may also provide authorization
   information.

   The backend authentication server to utilize a
     separate credential to authenticate each "virtual authenticator".

[d]  It is RECOMMENDED that Secure Association Protocols identify peers
     and authenticators unambiguously, without incorporating implicit
     assumptions about peer and authenticator architectures.  Using
     port-specific MAC addresses as identifiers 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 NOT RECOMMENDED where
     peers and authenticators may support multiple ports.

[e]  The AAA server requesting?

[c]  Are there any specific parameters (mandatory tunneling, bandwidth,
     filters, and authenticator MAY implement additional
     attributes in order to further restrict the AAA-Key scope.  For
     example, in 802.11, so on) that the AAA server may provide access network should be aware of for
     this user?

[d]  Is this user within the authenticator
     with a list subscription rules regarding time of authorized Called or Calling-Station-Ids and/or
     SSIDs day?

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

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

   While the  AAA-Key authorization decision is valid.

[f] 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 server provides attributes restricting
   devices in the key scope,
     it is RECOMMENDED that restrictions be securely communicated by chain from the authenticator to the peer.  This can be accomplished using home AAA server
   are involved in the
     Secure Association Protocol,  but also decision.  For instance, a broker can be accomplished via disallow
   access even if the
     EAP method home AAA server would allow it, or the lower layer.

4.7.  Key Strength

   In order to guard against brute force attacks, EAP methods deriving
   keys need to be capable of generating keys with an appropriate
   effective symmetric key strength. 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 order addition to ensure that key
   generation is 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 weakest link, it is RECOMMENDED that EAP
   methods utilizing public key cryptography choose
   authenticator, only the final result.  As a public key that result, the authenticator
   has a cryptographic strength meeting no way to know what the symmetric key strength
   requirement.

   As noted in [RFC3766] Section 5, decision was based on.  Was a set of
   authorization parameters sent because this results in service is always provided
   to the following
   required RSA user, or DH module was the decision based on the time/day and DSA subgroup size in bits, for a given
   level the
   capabilities 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.8.  Key Wrap

   As described in [RFC3579] Section 4.3, known problems exist in the requesting authenticator device?

4.2.  Correctness

   When the AAA exchange is bypassed via use of techniques such as key wrap specified
   caching, this creates challenges in [RFC2548].  Where the same RADIUS shared secret ensuring that authorization is used by
   properly handled. These include:

[a]  Consistent application of session time limits.  Bypassing AAA
     should not automatically increase the available session time,
     allowing a PAP authenticator and an EAP authenticator, there is user to endlessly extend their network access by
     changing the point of attachment.

[b]  Avoidance of privilege elevation.   Bypassing AAA should not result
     in a
   vulnerability user being granted access to known plaintext attack.  Since RADIUS uses services which they are not
     entitled to.

[c]  Consideration of dynamic state.  In situations in which dynamic
     state is involved in the
   shared secret for multiple purposes, including per-packet
   authentication, attribute hiding, considerable information access decision (day/time, simultaneous
     session limit) it should be possible to take this state into
     account either before or after access is exposed
   about granted. Note that
     consideration of network-wide state such as simultaneous session
     limits can typically only be taken into account by the shared secret with each packet. This exposes backend
     authentication server.

[d]  Encoding of restrictions.  Since a authenticator may not be aware
     of the shared
   secret criteria considered by a backend authentication server when
     allowing access, in order to dictionary attacks.  MD5 is used both ensure consistent authorization during
     a fast handoff it may be necessary to compute explicitly encode the RADIUS
   Response Authenticator and
     restrictions within the Message-Authenticator attribute, and
   some concerns exist relating to authorizations provided in the security AAA-Token.

[e]  State validity.  The introduction of this hash
   [MD5Attack].

   As discussed in [RFC3579] Section 4.3, fast handoff should not render
     the security vulnerabilities authentication server incapable of RADIUS are extensive, and therefore development keeping track of an alternative
   key 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 network-
     wide state.

   A handoff mechanism capable of addressing these concerns is taken in
   Diameter EAP [I-D.ietf-aaa-eap], which defines cleartext key
   attributes, said to
   be protected by IPsec or TLS.

   Where an untrusted AAA intermediary "correct".  One condition for correctness is present (such as follows: For a RADIUS
   proxy or a Diameter agent), and data object security is not used, the
   AAA-Key may
   handoff to be recovered by an attacker in control of the untrusted
   intermediary.  Possession of "correct" it MUST establish on the AAA-Key enables decryption of data
   traffic sent between new device the peer and a specific authenticator.  However,
   as long same
   context as would have been created had the new device completed a AAA-Key or keys derived from AAA
   conversation with the authentication server.

   A properly designed handoff scheme will only succeed if it is only utilized by
   "correct" in this way.  If a
   single authenticator, compromise of the AAA-Key does not enable an
   attacker to impersonate the peer successful handoff would establish
   "incorrect" state, it is preferable for it to another authenticator.
   Vulnerability fail, in order to an untrusted AAA intermediary can be mitigated by
   implementation avoid
   creation of redirect functionality, as described in [RFC3588] incorrect context.

   Some backend authentication server and [I-D.ietf-aaa-eap].

5.  Handoff Vulnerabilities

   With EAP, a number of mechanisms authenticator configurations
   are be utilized incapable of meeting this definition of "correctness".  For
   example, if the old and new device differ in order their capabilities, it
   may be difficult to reduce
   the latency meet this definition of correctness in a handoff between authenticators.  One such
   mechanism is
   EAP pre-authentication, that bypasses AAA.  Backend authentication servers often
   perform conditional evaluation, in which EAP is utilized to pre-establish a
   AAA-Key on an authenticator prior to arrival of the peer.  Another
   such mechanism is AAA-Key caching, authorizations returned
   in which an EAP peer can re-attach
   to an Access-Accept message are contingent on the authenticator without having to re-authenticate using EAP.  Yet
   another mechanism is context transfer, or on
   dynamic state such as is defined in
   [IEEE-802.11F] and [CTP].  These mechanisms introduce new security
   vulnerabilities, as discussed in the sections that follow.

5.1.  Authorization

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

   As a part time of the authentication process, the AAA network determines
   the user's authorization profile.  The user authorizations are
   transmitted by day or number of simultaneous
   sessions.  For example, in a heterogeneous deployment, the backend
   authentication server to might return different authorizations depending
   on the EAP authenticator (also known as the Network Access Server or
   authenticator) included with the AAA-Token, which also contains making the
   AAA-Key, request, in Phase 1b of the EAP conversation.  Typically, order to make sure that
   the profile requested service is determined based on consistent with the user identity, but a certificate presented
   by authenticator
   capabilities.

   If differences between the new and old device would result in 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 sending a legitimate user for this particular network?

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

[c]  Are there any specific parameters (mandatory tunneling, bandwidth,
     filters, and so on) that messages to
   the access network should new device than were sent to the old device, then if the handoff
   mechanism bypasses AAA, then the handoff cannot be aware of for
     this user?

[d]  Is this user carried out
   correctly.

   For example, if some authenticator devices within a deployment
   support dynamic VLANs while others do not, then attributes present in
   the subscription rules regarding time of day?

[e]  Is this 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 [IEEE-802.1Q].  If a 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 within his limits for concurrent sessions?

[f]  Are there any fraud, credit limit, or other concerns that indicate
     that with access should restricted to a guest
   VLAN could be denied?

   While given unrestricted access to the authorization decision is network.

   Similarly, in principle simple, the process a network where access is complicated by restricted based on the distributed nature of AAA decision making.
   Where brokering entities day
   and time, Service Set Identifier (SSID), Calling-Station-Id or proxies other
   factors, unless the restrictions are involved, all of encoded within the
   authorizations, or a partial AAA
   devices conversation is included, then a
   handoff could result in the chain from user bypassing the authenticator to restrictions.

   In practice, these considerations limit the home AAA server
   are involved situations in the decision.  For instance, a broker can disallow
   access even if the home which fast
   handoff mechanisms bypassing 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 expected to be successful.
   Where the Accept/Reject decision made
   by deployed devices implement the AAA chain, parameters or constraints can same set of services, it may
   be communicated possible to do successful handoffs within such mechanisms.
   However, where the authenticator.

   The criteria for Accept/Reject decisions or supported services differ between devices, the reasons for choosing
   particular authorizations are typically
   handoff may not communicated to the
   authenticator, only the final result.  As a result, the succeed.  For example, [RFC2865] section 1.1 states:

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

5.2.  Correctness

   When the AAA exchange is bypassed via use of techniques such MUST
      treat a RADIUS access-accept authorizing an unavailable service as AAA-
   Key caching,
      an access-reject instead."

   Note that this creates challenges in ensuring behavior only applies to attributes that authorization
   is properly handled. These include:

[a]  Consistent application of session time limits.  Bypassing AAA
     should are known,
   but 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.   Bypassing AAA should not result
     in a user being granted access to services which they implemented.  For attributes that are not
     entitled to.

[c]  Consideration of dynamic state. unknown, [RFC2865]
   Section 5 states:

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

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

[d]  Encoding of restrictions.  Since a authenticator ignored.

   Although it may not be aware
     of seem somewhat counter-intuitive, failure is indeed
   the criteria considered by "correct" result where a known but unsupported service is
   requested. Presumably a correctly configured backend authentication
   server when
     allowing access, in order would not request that a device carry out a service that it
   does not implement.  This implies that if the new device were to ensure consistent authorization during
   complete a fast handoff AAA conversation that it may would be necessary likely to explicitly encode the
     restrictions within the authorizations provided in the AAA-Token.

[e]  State validity.  The introduction receive
   different service instructions.  In such a case, failure of fast handoff should not render the authentication server incapable of keeping track of network-
     wide state.

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

   A properly designed handoff scheme will only succeed if it is
   "correct" AAA server in order to receive the appropriate service
   definition.

   In practice, this way.  If a successful implies that handoff would establish
   "incorrect" state, it is preferable for it mechanisms which bypass AAA
   are most likely to fail, in order be successful within a homogeneous device
   deployment within a single administrative domain. For example, it
   would not be advisable to avoid
   creation of incorrect context.

   Some backend authentication server carry out a fast handoff bypassing AAA
   between a authenticator providing confidentiality and another
   authenticator configurations
   are incapable of meeting that does not support this definition service.  The correct result
   of "correctness".  For
   example, such a handoff would be a failure, since if the old and new device differ in their capabilities, it
   may handoff were
   blindly carried out, then the user would be difficult moved from a secure to meet this an
   insecure channel without permission from the backend authentication
   server.  Thus the definition of correctness in a handoff
   mechanism that bypasses AAA.  Backend authentication servers often
   perform conditional evaluation, in which the authorizations returned "known but unsupported service"
   MUST encompass requests for unavailable security services.  This
   includes vendor-specific attributes related to security, such as
   those described in an Access-Accept message are contingent on [RFC2548].

5.  Security Considerations

   In order to analyze whether the authenticator or on
   dynamic EAP conversation achieves it security
   goals, it is first necessary to state such those goals as well as the time of day or number
   underlying security assumptions.

   The overall goal of simultaneous
   sessions.  For example, in a heterogeneous deployment, the backend
   authentication server might return different authorizations depending
   on EAP conversation is to derive fresh session
   keys between the EAP peer and authenticator making that are known only to
   those parties, and for both the request, in order EAP peer and authenticator to make sure
   demonstrate that they are authorized to perform their roles either by
   each other or by a trusted third party (the AAA server).

   The principals of the requested service is consistent with the authenticator
   capabilities.

   If differences between authentication phase are the new EAP peer and old device would result
   server.  Completion of an EAP method exchange supporting key
   derivation results in the
   backend authentication server sending a different set derivation of messages EAP keying material (MSK,
   EMSK, TEKs) known only to the new device than were sent to EAP peer (identified by the old device, then if Peer-ID)
   and server (identified by the handoff
   mechanism bypasses AAA, then Server-ID).  Both the handoff cannot EAP peer and EAP
   server know the exported keying material to be carried out
   correctly.

   For example, if some authenticator devices within a deployment
   support dynamic VLANs while others do not, then attributes present in fresh.

   The principals of the Access-Request (such as AAA Key transport exchange are 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 EAP
   authenticator and the EAP server.  Completion of the AAA exchange
   results in [IEEE-802.1Q].  If a handoff
   bypassing the backend authentication transport of EAP keying material from the EAP server were
   (identified by the Server-ID) to occur between a the EAP authenticator supporting dynamic VLANs (identified by
   the NAS-Identifier) without disclosure to any other party.  Both the
   EAP server and another EAP authenticator
   which does not, then a guest user with access restricted know this keying material 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
   fresh.

   The principals of the restrictions Secure Association Protocol are encoded within the
   authorizations, or a partial AAA conversation is included, then a
   handoff could result in EAP peer
   (identified by the user bypassing Peer-ID) and authenticator (identified by the restrictions.

   In practice, these considerations limit NAS-
   Identifier).  Completion of the situations Secure Association Protocol results
   in which fast
   handoff mechanisms bypassing AAA can be expected to be successful.
   Where the deployed devices implement the same set derivation of services, it may
   be possible TSKs known only to do successful handoffs within such mechanisms.
   However, where the supported services differ between devices, EAP peer and
   authenticator.  Both the
   handoff may not succeed.  For example, [RFC2865] section 1.1 states:

      "A EAP peer and authenticator that does not implement a given service MUST NOT
      implement know the RADIUS attributes for that service.  For example, a
      authenticator that is unable TSKs to offer ARAP service MUST NOT
      implement
   be fresh.

5.1.  Terminology

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

5.2.  Threat Model

   The EAP threat model is described in [RFC3748] Section 7.1.  The
   security properties of EAP methods (known as "security claims",
   described in [RFC3784] Section 7.2.1), address these threats.  EAP
   method requirements for ARAP.  A authenticator MUST
      treat a RADIUS access-accept authorizing an unavailable service applications such as
      an access-reject instead."

   Note that this behavior only applies Wireless LAN
   authentication are described in [RFC4017].  The RADIUS threat model
   is described in [RFC3579] Section 4.1, and responses to attributes that these threats
   are known,
   but not implemented.  For attributes that described in [RFC3579] Sections 4.2 and 4.3.

   However, in addition to threats against EAP and AAA, there are unknown, [RFC2865]
   Section 5 states:

      "A RADIUS server MAY ignore Attributes with other
   system-level threats worth discussing.  These include:

[1]  An attacker may compromise or steal an unknown Type.  A
      RADIUS client MAY ignore Attributes with EAP authenticator, in an unknown Type."

   In order
     attempt to perform a correct handoff, if a new device is provided
   with RADIUS context for gain access to other EAP authenticators or obtain long-
     term secrets.

[2]  An attacker may compromise an EAP authenticator in an effort to
     commit fraud.  For example, a known but unavailable service, then it MUST
   process this context compromised authenticator may provide
     incorrect information to the same way it would handle EAP peer and/or server via out-of-band
     mechanisms (such as via a RADIUS Access-
   Accept requesting an unavailable service. AAA or lower layer protocol).  This MUST cause
     includes impersonating another authenticator, or providing
     inconsistent information to the
   handoff peer and EAP server.

[3]  An attacker may try 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 modify or spoof packets, including Discovery
     or Secure Association Protocol frames, EAP or AAA packets.

[4]  An attacker may seem somewhat counter-intuitive, failure is indeed
   the "correct" result where attempt a downgrade attack in order to exploit
     known but unsupported service is
   requested. Presumably a correctly configured backend weaknesses in an authentication method or cryptographic
     transform.

[5]  An attacker may attempt to induce an EAP peer, authenticator or
     server would not request to disclose keying material to an unauthorized party, or
     utilize keying material outside the context that it was intended
     for.

[6]  An attacker may replay packets.

[7]  An attacker may cause an EAP peer, authenticator or server to reuse
     an stale key.  Use of stale keys may also occur unintentionally.

     For example, a device carry out poorly implemented AAA server may provide stale
     keying material to an authenticator, or a service poorly implemented
     authenticator may reuse nonces.

[8]  An authenticated attacker may attempt to obtain elevated privilege
     in order to access information that it does not implement.  This implies that if the new device were have rights to.

   In order to
   complete address these threats, [Housley] provides a AAA conversation description
   of mandatory system security properties.  Issues relating system
   security requirements are discussed in the sections that it would be likely to receive
   different service instructions. follow.

5.3.  Authenticator Compromise

   In such a case, failure of the
   handoff event that an authenticator is compromised or stolen, an
   attacker may gain access to the desired result.  This will cause network via that authenticator, or
   may obtain the new device to go
   back credentials required for that authenticator/AAA client
   to the communicate with one or more AAA server in order to receive the appropriate service
   definition.

   In practice, servers.  However, this implies that 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 should
   not be advisable allow the attacker to carry out a fast handoff bypassing compromise other authenticators or the AAA
   between a authenticator providing confidentiality and another
   authenticator that does not support this service.
   server, or obtain long-term user credentials.

   The correct result implications of such a handoff would be a failure, this requirement are many, but some of the more
   important are as follows:

No Key Sharing
     An EAP authenticator MUST NOT share any keying material with
     another EAP authenticator, since if the handoff one EAP authenticator were
   blindly carried out, then the user
     compromised, this would enable the compromise of keying material on
     another authenticator.  In order to be moved from a secure able to an
   insecure channel without permission from the backend authentication
   server.  Thus determine whether
     keying material has been shared, it is necessary for the definition identity
     of a "known but unsupported service"
   MUST encompass requests for unavailable security services.  This
   includes vendor-specific attributes related the EAP authenticator to security, such as
   those described in [RFC2548].

6.  Security Considerations

6.1.  Security Terminology

   "Cryptographic binding", "Cryptographic separation", "Key strength"
   and "Mutual authentication" are be defined in [RFC3748] and are used understood by all
     parties that communicate with the same meaning here.

6.2.  Threat Model

   The EAP threat model is described in [RFC3748] Section 7.1.  In order it.

No AAA Credential Sharing
     AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
     keys or certificates) MUST NOT be shared between AAA clients, since
     if one AAA client were compromised, this would enable an attacker
     to impersonate other AAA clients to address these threats, EAP relies on the security properties AAA server, or even to
     impersonate a AAA server to other AAA clients.

No Compromise of Long-Term Credentials
     An attacker obtaining TSKs, TEKs or EAP methods (known keying material such as "security claims", described in [RFC3784]
   Section 7.2.1).  EAP method requirements for application the
     MSK MUST NOT be able to obtain long-term user credentials such as
   Wireless LAN authentication are described in [RFC4017].
     pre-shared keys, passwords or private-keys without breaking a
     fundamental cryptographic assumption.

5.4.  Spoofing

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

   Given via use of the existing documentation
   Message-Authenticator attribute.

   [RFC3748] Section 7.2.1 describes the "integrity protection" security
   claim and [RFC4017] requires use of EAP and 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 methods supporting this
   claim.

   In order to modify or spoof prevent forgery of Secure Association Protocol
     packets.

[2]  An attacker compromising an authenticator may provide incorrect
     information to the EAP peer and/or server via out-of-band
     mechanisms (such as via a AAA or lower layer protocol).  This
     includes impersonating another authenticator, or providing
     inconsistent information to the peer frames,
   per-frame authentication and EAP server.

[3]  An attacker may attempt to perform downgrading attacks integrity protection is RECOMMENDED on the
     ciphersuite negotiation
   all messages.  [IEEE-802.11i] supports per-frame integrity protection
   and authentication on all messages within the Secure Association Protocol in
     order to ensure that a weaker ciphersuite is used to protect data.

   Depending on 4-way handshake except
   the lower layer, these attacks may be carried out
   without requiring physical proximity.

   In order first message.  An attack leveraging this ommission is described
   in [Analysis].

5.5.  Downgrade Attacks

   The ability to address these threats, [Housley] describes negotiate the mandatory
   system security properties:

Algorithm independence
     Wherever use of a particular cryptographic algorithms are chosen, the algorithms must
     be negotiable, in order to provide resilient
   algorithm provides resilience against compromise of a particular
   cryptographic algorithm.  Algorithm independence must be
     demonstrated within all aspects of the system,  This is usually accomplished by including within
     EAP, AAA and
   an algorithm identifier in the Secure Association Protocol.  However, for
     interoperability, at least one suite of algorithms MUST be
     implemented.

Strong, fresh session keys
     Session keys must be demonstrated to be strong protocol, and fresh in all
     circumstances, while at by specifying the same time retaining
   algorithm
     independence.

Replay protection
     All protocol exchanges must be replay protected.  This includes
     exchanges within EAP, AAA, and requirements in the Secure Association Protocol.

Authentication
     All parties need protocol specification.  In order to be authenticated.  The confidentiality of the
     authenticator must be maintained.  No plaintext passwords are
     allowed.

Authorization
     EAP peer and authenticator authorization must be performed.

Session keys
     Confidentiality of session keys must be maintained.

Ciphersuite negotiation
     The selection
   prevent downgrade attacks, secure confirmation of the "best"
   ciphersuite must be securely confirmed.

Unique naming
     Session keys must be uniquely named.

Domino effect
     Compromise of a single authenticator cannot compromise any other
     part of is required.

   [RFC3748] Section 7.2.1 describes the system, including session keys and long-term secrets.

Key binding
     The key must be bound "protected ciphersuite
   negotiation" security claim that refers to the appropriate context.

6.3.  Security Analysis

   Figure 8 illustrates the relationship between the peer, authenticator
   and backend authentication server.

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

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

   The peer and EAP server communicate using EAP [RFC3748].  The
   security properties ability of this communication are largely determined by
   the chosen an EAP method.  Method security claims are described in
   [RFC3748] Section 7.2.  These include
   method to negotiate the  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 channel binding claims.  At a
   minimum, methods claiming used 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 protect the EAP peer and
   conversation, as well as to integrity protect the EAP Server.

   Ciphersuite independence is also required:

      Keying material exported by negotiation.
   [RFC4017] requires EAP methods MUST be independent satisfying this security claim.

   Diameter [RFC3588] provides support for cryptographic algorithm
   negotiation via use of IPsec or TLS.  RADIUS [RFC3579] does not
   support the
      ciphersuite negotiated to protect data.

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

      EAP methods SHOULD ensure the freshness of the MSK relies on
   MD5 for integrity protection, authentication and EMSK even confidentiality,
   despite known weaknesses in cases where one party may not have a high quality random number
      generator.... In order to preserve algorithm independence, EAP
      methods deriving keys SHOULD support (and document) the protected
      negotiation of the ciphersuite used to protect the EAP
      conversation between the peer and server...  In order to enable
      deployments requiring strong keys, EAP methods supporting key
      derivation SHOULD algorithm [MD5Attack].  This issue
   can be capable of generating an MSK and EMSK, each
      with an effective key strength addressed via use of at least 128 bits.

   The authenticator and backend authentication server communicate using
   a AAA protocol such as RADIUS [RFC3579] or Diameter [I-D.ietf-aaa-
   eap].  As noted over IPsec, as described in [RFC3588]
   [RFC3579] Section 13, Diameter must be protected
   by either IPsec ESP with non-null transform or TLS. 4.2.

   As a result,
   Diameter requires per-packet integrity and confidentiality.  Replay
   protection must be supported.  For RADIUS, [RFC3579] Section 4.2
   recommends that RADIUS be protected by IPsec ESP with a non-null
   transform, EAP methods and where IPsec AAA protocols are capable of addressing
   downgrade attacks.  To ensure against downgrade attacks within lower
   layer protocols, algorithm independence is implemented replay protection must be
   supported.

   The peer and authenticator communicate REQUIRED with lower layers
   using the Secure Association
   Protocol. EAP for key derivation.  For interoperability, at least one
   suite of mandatory-to-implement algorithm MUST be selected.   Lower
   layer protocols supporting EAP for key derivation SHOULD also support
   secure ciphersuite negotiation.  As noted described in the figure, [RFC1968], PPP ECP
   does not provide support for secure ciphersuite negotiation.
   However, [IEEE-802.11i] does support secure ciphersuite negotiation.

5.6.  Unauthorized Disclosure

   While preserving algorithm independence, confidentiality of all
   keying material MUST be maintained.  To prevent unauthorized disclose
   of keys, each party in the exchange mutually
   authenticates with each of EAP conversation MUST be authenticated to
   the other parties, and derives a unique
   key.  All parties in the diagram have access with whom it communicates.  Keying material MUST be
   bound to the AAA-Key.

   The EAP peer and backend authentication server mutually authenticate
   via appropriate context.

   [RFC3748] Section 7.2.1 describes the EAP method, "mutual authentication" and derive the TEKs
   "dictionary attack resistance" claims, and EMSK which are known only
   to them. The TEKs are used to protect some or all of the [RFC4017] requires EAP
   conversation
   methods satisfying these claims.  EAP methods complying with
   [RFC4017] therefore provide for mutual authentication between the EAP
   peer and authenticator, so as to guard
   against modification or insertion server.  Binding of EAP packets by an attacker.  The
   degree of protection afforded by keying material (MSK, EMSK) to the TEKs
   appropriate context is determined provided by the EAP
   method; some methods may protect Peer-ID and Server-ID which
   are exported along with the entire EAP packet, including keying material.

   Diameter [RFC3588] provides for per-packet authentication and
   integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
   provides for per-packet authentication and integrity protection.
   Where the
   EAP header, while other methods may only protect NAS/authenticator and AAA server communicate directly and
   credible keywrap is used (see Section 3.7), this ensures that the contents of AAA
   Key Transport phase achieves its security objectives: mutually
   authenticating the
   Type-Data field, defined in [RFC3748].

   Since AAA client/authenticator and AAA server and
   providing EAP is spoken only between keying material to the EAP peer authenticator and server, if a
   backend authentication server is present then to no
   other party.

   As noted in Section 3.1, the EAP conversation Secure Association Protocol does not by
   itself provide for mutual authentication between the EAP peer and
   authenticator, only between the even if mutual possession of EAP peer keying material is
   proven.  However, where the NAS/authenticator and EAP AAA server (backend
   authentication server).  As a result, mutual authentication
   communicate directly, the AAA server can verify the correspondence
   between NAS identification attributes, the peer source address of packets
   sent by the NAS, and authenticator only occurs where a Secure Association
   protocol is used, such the unicast and group key derivation handshake
   supported in [IEEE-802.11i].  This means that absent use of a secure
   Association Protocol, from the point of view of AAA credentials.  As long as the peer, EAP mutual
   authentication only proves that NAS has not
   shared its AAA credentials with another NAS, this allows the authenticator is trusted by AAA
   server to authenticate the
   backend authentication server; NAS.  Using Channel Bindings, the identity of EAP peer
   can then determine whether the authenticator is
   not confirmed.

   Utilizing NAS/authenticator has provided the AAA protocol,
   same identifying information to the authenticator and backend
   authentication server mutually authenticate EAP peer and derive session keys
   known only to them, used to provide per-packet integrity AAA server.

   Peer and replay
   protection, authentication authenticator authorization MUST be performed.
   Authorization is REQUIRED whenever a peer associates with a new
   authenticator.  Authorization checking prevents an elevation of
   privilege attack, and confidentiality.  The AAA-Key ensures that an unauthorized authenticator is
   distributed by
   detected.  Authorizations SHOULD be synchronized between the backend authentication server to EAP
   peer, server, authenticator.  Once the authenticator
   over this channel, bound to attributes constraining its usage, as
   part EAP conversation exchanges are
   complete, all of these parties should hold the AAA-Token.  The binding same view of attributes to the AAA-Key
   within a protected package is important so the authenticator
   receiving
   authorizations associated the AAA-Token can determine that it has not been
   compromised, and that other parties.  If peer authorization
   is restricted, then the keying material has not been replayed, or
   mis-directed in some way.

   The security properties peer SHOULD be made aware of the EAP restriction.

   The AAA exchange are dependent on each leg
   of the triangle: provides the selected EAP method, AAA protocol and authenticator with authorizations
   relating to the Secure
   Association Protocol.

   Assuming that EAP peer.  However, neither the EAP nor AAA protocol exchanges
   provides protection against rogue
   authenticators forging their identity, then the AAA-Token can be
   assumed authorizations to be sent the EAP peer.  In order to ensure that all
   parties hold the correct authenticator, and where it is
   wrapped appropriately, same view of the authorizations it can be assumed to be immune to compromise
   by a snooping attacker.

   Where an untrusted AAA intermediary is present, RECOMMENDED
   that the AAA-Token must
   not be provided to Secure Association Protocol enable communication of
   authorizations between the intermediary so as EAP authenticator and peer.

   In order to avoid compromise enable key binding and authorization of all parties, it
   is RECOMMENDED that the
   AAA-Token.  This can be avoided by parties use a set of re-direct as defined in
   [RFC3588].

   When EAP is used for authentication on PPP or wired IEEE 802
   networks, it is typically assumed identities that are
   consistent between the link is physically secure,
   so conversation phases.  RADIUS [RFC2865] and
   Diameter NASREQ [RFC4005] require that an attacker cannot gain access to the link, NAS/EAP authenticator
   identify itself by including one or insert a rogue
   device. more identification attributes
   within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
   IPv6-Address).

   Since the AAA server provides EAP methods defined in [RFC3748] reflect this usage model.
   These include keying material for use by the EAP MD5, as well
   authenticator as One-Time Password (OTP) and Generic
   Token Card.  These methods support one-way authentication (from identified by these attributes, where an EAP
   peer
   authenticator may have multiple ports, it is RECOMMENDED for the EAP
   authenticator to authenticator) but not mutual authentication or key
   derivation.  As a result, these methods do not bind identify itself using NAS identification attributes
   during the initial
   authentication and subsequent data traffic, even when Secure Association Protocol exchange with the EAP peer.
   This enables the
   ciphersuite used to protect data supports per-packet authentication
   and integrity protection. As a result, EAP methods not supporting
   mutual authentication are vulnerable peer to session hijacking determine whether EAP keying material
   has been shared between EAP authenticators as well as
   attacks by rogue devices.

   On wireless networks such as IEEE 802.11 [IEEE-802.11], 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 confirm with wireless LANs
   [IEEE-802.11i] which provide per-packet authentication, integrity and
   replay protection.  In addition, mutual authentication and key
   derivation, provided by methods such as EAP-TLS [RFC2716] are
   required [IEEE-802.11i], so as to address
   the threat AAA server that an EAP authenticator proving possession of rogue
   devices, and provide EAP
   keying material to bind during the initial
   authentication Secure Association Protocol was authorized
   to subsequent data traffic.

   If obtain it.  Typically, the NAS-Identifier attribute is most
   convenient for this purpose, since a NAS/authenticator may have
   multiple IP addresses.

   Similarly, the AAA server authorizes the selected EAP method does not support mutual authentication,
   then authenticator to provide
   access to the EAP peer will be vulnerable to attack identified by rogue authenticators
   and backend authentication servers. If the Peer-ID, securely verified
   during 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 authentication exchange.  In order to determine
   whether EAP keying material has been shared between EAP peers, where
   the initial EAP
   authentication and subsequent data traffic, leaving peer has multiple ports it is RECOMMENDED for the session
   vulnerable EAP peer to hijack.

   If
   identify itself using the backend authentication server does not protect against
   authenticator masquerade, or provide Peer-ID during the proper binding of Secure Association
   Protocol exchange with the AAA-
   Key EAP authenticator.

5.7.  Replay Protection

   Replay protection allows a protocol message recipient to the session within the 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 is provided to an
   untrusted AAA intermediary, then discard any
   message that intermediary may be able was recorded during a previous legitimate dialogue and
   presented as though it belonged to
   modify the AAA-Key, or the attributes associated with it, as
   described in [RFC2607].

   If current dialogue.

   [RFC3748] Section 7.2.1 describes the Secure Association Protocol does not provide mutual proof "replay protection" security
   claim and [RFC4017] requires use of
   possession EAP methods supporting this
   claim.

   Diameter [RFC3588] provides support for replay protection via use of
   IPsec or TLS.  RADIUS/EAP [RFC3579] protects against replay of keying
   material via the AAA-Key material, then the peer will Request Authenticator.  However, some RADIUS packets
   are not have
   assurance that it is connected to the correct authenticator, only
   that replay protected.  In Accounting, Disconnect and CoA-Request
   packets the authenticator Request Authenticator contains a keyed MAC rather than a
   Nonce.  The Response Authenticator in Accounting, Disconnect and backend authentication server share CoA
   Response packets also contains 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 fast handoff is supported.  If the TSK
   derivation keyed MAC whose calculation does not provide for protected ciphersuite and
   capabilities negotiation, then downgrade attacks are possible.

6.4.  Man-in-the-middle Attacks

   As described
   depend on a Nonce in [I-D.puthenkulam-eap-binding], EAP method sequences
   and compound authentication mechanisms may be subject to man-in-the-
   middle attacks.  When such attacks are successfully carried out, either the
   attacker acts as Request or Response packets.
   Therefore unless an intermediary between a victim and a legitimate
   authenticator.  This allows Event-Timestamp attribute is included or IPsec is
   used, the attacker recipient may not be able to authenticate successfully
   to the authenticator, as well as to obtain access to the network.

   In order determine whether these
   packets have been replayed.

   In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
   recommends derivation replay of a compound key by which Secure Association Protocol frames,
   replay protection is REQUIRED on all messages.  [IEEE-802.11i]
   supports replay protection on all messages within the EAP peer 4-way
   handshake.

5.8.  Key Freshness

   A session key should be considered compromised if it remains in use
   too long.  As noted in [Housley], session keys MUST be strong and
   server can prove
   fresh, while preserving algorithm independence.  A fresh
   cryptographic key is one that they have participated in the entire EAP
   exchange.  Since is generated specifically for the compound
   intended use.  Each session deserves an independent session key;
   disclosure of one session key must MUST NOT aid the attacker in
   discovering any other session keys.

   Fresh keys are required even when a long replay counter (that is, one
   that "will never wrap") is used to ensure that loss of state does not be known
   cause the same counter value to an attacker
   posing as an authenticator, and yet must be derived from quantities
   that are exported by used more than once with the same
   session key.

   EAP, AAA and the lower layer each bear responsibility for ensuring
   the use of fresh, strong session keys:

EAP methods, it may be desirable  EAP methods need to derive ensure the
   compound key from a portion freshness and strength of the EMSK.  In order EAP keying
     material provided as an input to provide proper session key hygiene, it is recommended derivation.  [RFC3748]
     Section 7.10 states that "EAP methods SHOULD ensure the compound key used for man-in-
   the-middle protection be cryptographically separate from other keys
   derived from freshness
     of the MSK and EMSK, such as fast handoff keys, discussed even in
   Section 2.3.

6.5.  Denial of Service Attacks

   The caching of security associations cases where one party may result in vulnerability not have a
     high quality random number generator.  A RECOMMENDED method is for
     each party to
   denial provide a nonce of service attacks.  Since an at least 128 bits, used in the
     derivation of the MSK and EMSK."  The contribution of nonces
     enables the EAP peer may derive multiple EAP
   SAs with a given and server to ensure that exported EAP server, keying
     material is fresh.

     [RFC3748] Section 7.2.1 describes the "key strength" and creation "session
     independence" security claims, and and [RFC4017] requires use of a new EAP SA does not
   implicitly delete a previous EAP SA,
     EAP methods that result in
   creation supporting these claims as well as being capable of persistent state may be vulnerable to denial
     providing an equivalent key strength of service
   attacks by 128 bits or greater.

AAA  The AAA protocol needs to ensure that transported keying material
     is fresh and is not utilized outside its recommended lifetime.
     Replay protection is necessary for key freshness, but an attacker
     can deliver a rogue EAP peer.

   As stale (and therefore potentially compromised) key in
     a result, replay-protected message, so replay protection is not sufficient.

     The EAP methods creating persistent state may wish to limit Session-ID, derived from the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer.
   For example, an Type and Method-ID (based
     on the nonces contributed by the peer and server) enables the EAP
     peer, authenticator and server may choose to only retain a few distinguish EAP SAs
   for each peer.  This prevents a rogue peer from denying access to
   other peers.

   Similarly, an conversations.
     However, unless the authenticator may have multiple AAA-Key SAs
   corresponding to a given keeps track of EAP peer; to conserve resources an Session-IDs,
     the authenticator may choose to limit cannot use the number of cached AAA-Key (Phase
   1 b) SAs for each peer.

   Depending on Session-ID to guarantee the media, creation
     freshness of EAP keying material.

     As described in [RFC3580] Section 3.17, When sent in an Access-
     Accept along with a new unicast Secure Association
   SA may or may not imply deletion Termination-Action value of a previous unicast secure
   association SA.  Where there is no implied deletion, RADIUS-Request, the
   authenticator
     Session-Timeout attribute specifies the maximum number of seconds
     of service provided prior to re-authentication.  [IEEE-802.11i]
     also utilizes the Session-Timeout attribute to limit the maximum
     time that EAP keying material may choose be cache.  Therefore the use of
     the Session-Timeout attribute enables the AAA server to limit Phase 2 (unicast and multicast) the
     exposure of EAP keying material.

Lower Layer
     The lower layer Secure Association SAs Protocol MUST generate a fresh
     session key for each peer.

6.6.  Impersonation

   Both session, even if the RADIUS keying material and Diameter protocols are potentially vulnerable to
   impersonation
     parameters provided by a rogue authenticator.

   While AAA protocols such as RADIUS [RFC2865] EAP methods are cached, or Diameter [RFC3588]
   support mutual authentication between the peer or
     authenticator (known as lacks a high entropy random number generator.  A
     RECOMMENDED method is for the
   AAA client) peer and the backend authentication server (known as the AAA
   server), the security mechanisms vary according authenticator to the AAA protocol.

   In RADIUS, the shared secret used for authentication is determined by
   the source address each
     provide a nonce or counter of the RADIUS packet.  As noted at least 128 bits, used in [RFC3579]
   Section 4.3.7, it is highly desirable session
     key derivation.

5.9.  Elevation of Privilege

   Parties MUST NOT have access to keying material that the source address be
   checked against one or more NAS identification attributes so as is not needed to
   perform their own role.  A party has access to
   detect and prevent impersonation attacks.

   When RADIUS requests are forwarded by a proxy, particular key if it
   has access to all of the NAS-IP-Address or
   NAS-IPv6-Address attributes may not correspond secret information needed to derive it.  If
   a post-EAP handshake is used to establish session keys, the source address.
   Since post-EAP
   handshake MUST specify the NAS-Identifier attribute need not contain an FQDN, it also
   may not correspond scope for session keys.

   Transported EAP keying material is permitted to be accessed by the source address, even indirectly.  [RFC2865]
   Section 3 states:

         A RADIUS
   EAP peer, authenticator and server.  The EAP peer and server MUST use derive
   the source IP address transported keying material during the process of mutually
   authenticating each other using the RADIUS
         UDP packet selected EAP method.  During the
   Secure Association Protocol, the EAP peer utilizes the transported
   EAP keying material to decide which shared secret demonstrate to use, so that
         RADIUS requests can be proxied.

   This implies the authenticator that it is possible for a rogue authenticator
   the same party that authenticated to forge
   NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
   a RADIUS Access-Request in order the EAP server and was
   authorized by it.  The EAP authenticator utilizes the transported EAP
   keying material to impersonate another
   authenticator.  Among other things, this can result in messages (and
   MSKs) being sent prove to the wrong authenticator. Since peer not only that the rogue
   authenticator is authenticated EAP
   conversation was transported through it (this could be demonstrated
   by a man-in-the-middle), but that it was uniquely authorized by the RADIUS proxy or
   EAP server purely
   based on to provide the source address, other mechanisms are required peer with access to detect the forgery.  In addition, it is possible for attributes such as the
   Called-Station-Id and Calling-Station-Id to be forged as well.

   As recommended in [RFC3579], this vulnerability network.  Unique
   authorization can only be mitigated by
   having RADIUS proxies check demonstrated if the EAP authenticator identification attributes
   against does
   not share the source address.

   To allow verification of session parameters such as transported keying material with a party other than the Called-
   Station- Id
   EAP peer and Calling-Station-Id, these can server.

   TSKs are permitted to be sent accessed only by the EAP peer
   to the server, protected by and
   authenticator.  Since the TEKs. The RADIUS server TSKs can then
   check the parameters sent by be determined from the transported
   EAP peer against those claimed by keying material and the authenticator.  If a discrepancy is found, an error can be
   logged.

   While [RFC3588] requires use cleartext of the Route-Record AVP, this utilizes
   FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
   RRs to be properly configured.  As a result, it appears that Diameter
   is as vulnerable to this attack as RADIUS, if not more so. To address
   this vulnerability, it is necessary to allow Secure Association
   Protocol exchange, the backend
   authentication AAA server will have access to communicate with the authenticator directly,
   such as via TSKs unless
   it deletes the redirect functionality supported transported EAP keying material after sending it.

5.10.  Man-in-the-middle Attacks

   As described in [RFC3588].

6.7.  Channel binding

   It is possible for a compromised or poorly implemented [I-D.puthenkulam-eap-binding], EAP
   authenticator to communicate incorrect information method sequences
   and compound authentication mechanisms may be subject to man-in-the-
   middle attacks.  When such attacks are successfully carried out, the EAP peer
   and/or server. This may enable
   attacker acts as an authenticator intermediary between a victim and a legitimate
   authenticator.  This allows the attacker to impersonate
   another authenticator or communicate incorrect information via out-
   of-band mechanisms (such authenticate successfully
   to the authenticator, as via AAA or well as to obtain access to the lower layer protocol).

   Where EAP is used in pass-through mode, network.

   In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
   recommends derivation of a compound key by which the EAP peer typically does
   not verify the identity of the pass-through authenticator, it only
   verifies and
   server can prove that they have participated in the pass-through authenticator is trusted by the entire EAP
   server. This creates a potential security vulnerability, described in
   [RFC3748] Section 7.15.

   [RFC3579] Section 4.3.7 describes how
   exchange.  Since the compound key must not be known to an EAP pass-through
   authenticator acting attacker
   posing as a AAA client can an authenticator, and yet must be detected if derived from quantities
   that are exported by EAP methods, it attempts may be desirable to impersonate another authenticator (such by sending incorrect NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
   [RFC3162] attributes via derive the AAA protocol).  However,
   compound key from a portion of the EMSK.  In order to provide proper
   key hygiene, it is possible recommended that the compound key used for a pass-through authenticator acting as a AAA client man-in-
   the-middle protection be cryptographically separate from other keys
   derived from the EMSK.

5.11.  Denial of Service Attacks

   Key caching may result in vulnerability to provide
   correct information denial of service attacks.
   For example, EAP methods that create persistent state may be
   vulnerable to denial of service attacks on the AAA EAP server while communicating misleading
   information by a rogue
   EAP peer.

   To address this vulnerability, EAP methods creating persistent state
   may wish to limit the persistent state created by an EAP peer via a lower layer protocol. peer.  For
   example, it is possible for a compromised authenticator each peer an EAP server may choose to
   utilize another authenticator's Called-Station-Id or NAS-Identifier
   in communicating with limit persistent
   state to a few EAP conversations, distinguished by the EAP peer via a lower layer protocol, or for
   a pass-through authenticator acting as Session-
   ID.  This prevents a AAA client rogue peer from denying access to provide other peers.

   Similarly, to conserve resources an
   incorrect peer Calling-Station-Id [RFC2865][RFC3580] authenticator may choose to limit
   the AAA
   server via the AAA protocol.

   As noted in [RFC3748] Section 7.15, this vulnerability persistent state corresponding to each peer.  This can be
   addressed
   accomplished by use of EAP methods that support limiting each peer to persistent sttate corresponding
   to a protected exchange few EAP converations, distinguished by the EAP Session-ID.

   Depending on the media, creation of
   channel properties such as endpoint identifiers, including (but new TSKs may or may not
   limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
   [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865], and NAS-IPv6-Address [RFC3162].

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

7.  Security Requirements

   This section summarizes may choose to limit the security requirements number of TSKs
   and associated state that must can be met by
   EAP methods, AAA protocols,  Secure Association Protocols stored for each peer.

5.12.  Impersonation

   Both the RADIUS and
   Ciphersuites in order Diameter protocols are potentially vulnerable to address the security threats described in
   this document. These requirements MUST be met
   impersonation by specifications
   requesting publication as an RFC.  Each requirement provides a
   pointer to the sections of this document describing the threat that
   it mitigates.

7.1.  EAP Method Requirements

   It is possible for the peer and EAP server to mutually authenticate
   and derive keys.  In order to provide keying material for use in a
   subsequently negotiated ciphersuite, an EAP method supporting key
   derivation MUST export a Master Session Key (MSK) of at least 64
   octets, and an Extended Master Session Key (EMSK) of at least 64
   octets.  EAP Methods deriving keys MUST provide for rogue authenticator.

   While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
   support mutual authentication between the EAP peer and authenticator (known as the EAP Server.

   The MSK
   AAA client) 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 backend authentication server (known as the AAA
   server), the security mechanisms vary according to derive the TSKs from AAA protocol.

   In RADIUS, the AAA-Key.

   The AAA-Key shared secret used for authentication is derived from the keying material exported determined by
   the EAP
   method (MSK and EMSK).  This derivation occurs on source address of the AAA server.  In
   many existing protocols RADIUS packet.  As noted in [RFC3579]
   Section 4.3.7, it is highly desirable that use EAP, the AAA-Key and MSK are
   equivalent, but source address be
   checked against one or more complicated mechanisms NAS identification attributes so as to
   detect and prevent impersonation attacks.

   When RADIUS requests are possible.

   EAP methods SHOULD ensure the freshness of forwarded by a proxy, the MSK and EMSK even in
   cases where one party NAS-IP-Address or
   NAS-IPv6-Address attributes may not have a high quality random number
   generator.  A RECOMMENDED method is for each party correspond to provide a nonce
   of at least 128 bits, used in the derivation of the MSK and EMSK.

   EAP methods export source address.
   Since the MSK and EMSK and NAS-Identifier attribute need not Transient Session Keys so
   as to allow EAP methods contain an FQDN, it also
   may not correspond to be ciphersuite and media independent.
   Keying material exported by EAP methods the source address, even indirectly.  [RFC2865]
   Section 3 states:

         A RADIUS server MUST be independent use the source IP address of the
   ciphersuite negotiated RADIUS
         UDP packet to protect data.

   Depending on the lower layer, EAP methods may run before or after
   ciphersuite negotiation, decide which shared secret to use, so that the selected ciphersuite may not
         RADIUS requests can be
   known proxied.

   This implies that it is possible for a rogue authenticator to the EAP method.  By providing keying material usable with
   any ciphersuite, EAP methods can used with forge
   NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
   a wide range of
   ciphersuites and media.

   It is RECOMMENDED that methods providing integrity protection of EAP
   packets include coverage of all the EAP header fields, including the
   Code, Identifier, Length, Type and Type-Data fields.

   In RADIUS Access-Request in order to preserve algorithm independence, EAP methods deriving
   keys SHOULD support impersonate another
   authenticator.  Among other things, this can result in messages (and document) the protected negotiation of the
   ciphersuite used
   transorted keying material) being sent to protect the EAP conversation between wrong authenticator.
   Since the peer and
   server.  This rogue authenticator is distinct from authenticated by the ciphersuite negotiated between RADIUS proxy or
   server purely based on the
   peer and authenticator, used source address, other mechanisms are
   required to protect data.

   The strength of Transient Session Keys (TSKs) used to protect data detect the forgery.  In addition, it is
   ultimately dependent on possible for
   attributes such as the strength of keys generated Called-Station-Id and Calling-Station-Id to be
   forged as well.

   As recommended in [RFC3579] Section 4.3.7, this vulnerability can be
   mitigated by having RADIUS proxies check NAS identification
   attributes against the EAP
   method.  If an EAP method cannot produce keying material source address.

   While [RFC3588] requires use of
   sufficient strength, then the TSKs may Route-Record AVP, this utilizes
   FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
   RRs to be subject properly configured.  As a result, it appears that Diameter
   is as vulnerable to brute force
   attack.  In order this attack as RADIUS, if not more so.  To
   address this vulnerability, it is necessary to enable deployments requiring strong keys, EAP
   methods supporting key derivation SHOULD be capable of generating an
   MSK and EMSK, each allow the backend
   authentication server to communicate with an effective key strength of at least 128
   bits.

   Methods supporting key derivation MUST demonstrate cryptographic
   separation between the MSK and EMSK branches of authenticator directly,
   such as via the EAP key
   hierarchy.  Without violating redirect functionality supported in [RFC3588].

5.13.  Channel Binding

   It is possible for a fundamental cryptographic assumption compromised or poorly implemented EAP
   authenticator to communicate incorrect information to the EAP peer
   and/or server.  This may enable an authenticator to impersonate
   another authenticator or communicate incorrect information via out-
   of-band mechanisms (such as via AAA or the non-invertibility of a one-way function) an attacker
   recovering lower layer).

   Where EAP is used in pass-through mode, the MSK or EMSK MUST NOT be able to recover EAP peer does not verify
   the other
   quantity with a level of effort less than brute force.

   Non-overlapping substrings identity of the MSK MUST be cryptographically
   separate from each other.  That is, knowledge of one substring MUST
   NOT help in recovering some other non-overlapping substring without
   breaking some hard cryptographic assumption.  This is required
   because some existing ciphersuites form TSKs by simply splitting pass-through authenticator.  Within the
   AAA-Key to pieces of appropriate length.  Likewise, non-overlapping
   substrings of Secure
   Association Protocol, the EMSK MUST be cryptographically separate from each
   other, EAP peer and from substrings authenticator only demonstrate
   mutual possession of the MSK.  The EMSK MUST NOT be transported to, or shared with, additional parties.

   Since EAP does not provide for explicit key lifetime negotiation, keying material.  This
   creates a potential security vulnerability, described in [RFC3748]
   Section 7.15.

   [RFC3579] Section 4.3.7 describes how an EAP
   peers, authenticators and authentication servers MUST pass-through
   authenticator acting as a AAA client can be prepared for
   situations in which one of the parties discards key state which
   remains valid on detected if it attempts
   to impersonate another party.

   The development and validation of key derivation algorithms authenticator (such by sending incorrect
   Called-Station-ID [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
   protocol).  However, it is
   difficult, and possible for a pass-through authenticator
   acting as a result AAA client to provide correct information to the AAA
   server while communicating misleading information to the EAP methods SHOULD reuse well established
   and analyzed mechanisms for MSK and EMSK key derivation (such as
   those specified in IKE [RFC2409] peer via
   the lower layer.

   For example, a compromised authenticator can utilize another
   authenticator's Called-Station-Id or TLS [RFC2246]), rather than
   inventing new ones.

7.1.1.  Requirements for NAS-Identifier in communicating
   with the EAP methods

   In order peer via the lower layer, or for a pass-through
   authenticator acting as a AAA client to provide an EAP method incorrect peer
   Calling-Station-Id [RFC2865][RFC3580] to meet the guidelines for EMSK usage AAA server via the AAA
   protocol.

   As noted in [RFC3748] Section 7.15, this vulnerability can be
   addressed by EAP methods that support a protected exchange of channel
   properties such as endpoint identifiers, including (but not limited
   to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
   [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865], and NAS-IPv6-Address [RFC3162].

   Using such a protected exchange, it
   must meet is possible to match the following requirements:

      o channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  For example, see [I-
   D.arkko-eap-service-identity-auth].

   It MUST specify how is also possible to derive achieve Channel Bindings without transporting
   data over EAP.  For example, see [draft-ohba-eap-aaakey-binding].  In
   this approach the EMSK

      o The key material used for authenticator informs the EMSK MUST be
        computationally independent of backend server about the MSK
   Channel Binding parameters using AAA, and TEKs.

      o The EMSK MUST NOT be used for any other purpose than the key
        derivation described in backend server
   calculates transported keying material based on this document.

      o The EMSK MUST be secret parameter set,
   making it impossible for the peer and not known authenticator to someone observing complete the authentication mechanism protocol exchange.

      o The EMSK MUST NOT be exported from
   Secure Association Protocol if there was a mismatch in the EAP server.

      o The EMSK MUST be unique for each session.

      o
   parameters.

   The main difference between these approaches is that Channel Binding
   support within an EAP mechanism SHOULD a unique identifier suitable for naming method may require upgrading or changing the EMSK.

7.1.2.  Requirements for
   EAP applications

   In order for an application to meet method, impacting both the guidelines for EMSK usage it
   must meet peer and the following requirements:

      o New applications following this specification SHOULD NOT use server.   Where Channel
   Bindings are implemented in AAA,  the
        MSK.  If more than one application uses peer, authenticator and the MSK, then
   backend server need to be upgraded, but the
        cryptographic separation is EAP method need not achieved.  Implementations SHOULD
        prevent such combinations.

      o A peer MUST NOT use the EMSK directly for cryptographic
        protection of data.

7.2.  AAA Protocol Requirements

   AAA protocols suitable be
   modified.

6.  IANA Considerations

   This document does not create any new name spaces nor does it
   allocate any protocol parameters.

7.  References

7.1.  Normative References

[RFC2119] Bradner, S., "Key words for use in transporting EAP MUST provide the
   following facilities:

Security services
     AAA protocols used for transport of EAP keying material MUST
     implement RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

7.2.  Informative References

[Analysis]
          He, C. and confidentiality.  These requirements are met
     by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
     [RFC3579].

Session Keys
     AAA protocols used for transport J. Mitchell, "Analysis of EAP keying material MUST
     implement the 802.11i 4-Way
          Handshake", Proceedings of the 2004 ACM Workshop on Wireless
          Security, pp. 43-50, ISBN: 1-58113-925-X.

[CTP]     Loughney, J., Nakhjiri, M., Perkins, C. and SHOULD use dynamic key management in order to derive
     fresh session keys, as R. Koodli,
          "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
          Internet draft (work in Diameter EAP [I-D.ietf-aaa-eap] progress), August 2004.

[DESMODES]
          National Institute of Standards and
     RADIUS over IPsec [RFC3579], rather than using a static key, as
     originally defined in RADIUS [RFC2865].

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

Authorization
     AAA protocols used for transport of EAP keying material SHOULD
     provide protection against rogue authenticators masquerading as
     other authenticators.  This can be accomplished, for example, by
     requiring that AAA agents check the source address
          Operation", FIPS PUB 81, December 1980, <http://
          www.itl.nist.gov/fipspubs/fip81.htm>.

[FIPSDES] National Institute of packets
     against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier in RADIUS).  For details,
     see [RFC3579] Section 4.3.7.

Key transport
     Since EAP methods do not export Transient Session Keys (TSKs) in
     order to maintain media Standards and ciphersuite independence, the AAA
     server MUST NOT transport TSKs from the backend authentication
     server to authenticator. Technology, "Data
          Encryption Standard", FIPS PUB 46, January 1977.

[Housley] Housley, R. and B. Aboba, "AAA Key transport specification
     In order to enable backend authentication servers to provide keying
     material to the authenticator Management", draft-housley-
          aaa-key-mgmt-00.txt, Internet draft (work in a well defined format, AAA
     protocols suitable progress), June
          2005.

[IEEE-802]
          Institute of Electrical and Electronics Engineers, "IEEE
          Standards for use with EAP MUST define the format Local and
     wrapping Metropolitan Area Networks: Overview
          and Architecture", ANSI/IEEE Standard 802, 1990.

[IEEE-802.11]
          Institute of the AAA-Token.

EMSK transport
     Since the EMSK is a secret known only to the backend authentication
     server Electrical and peer, the AAA-Token MUST NOT transport the EMSK from the
     backend authentication server to the authenticator.

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

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

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

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

7.3.  Secure Association Protocol metropolitan area
          networks - Specific Requirements

   The Secure Association Protocol supports the following:

Entity Naming
     The peer and authenticator SHOULD identify themselves in a manner
     that is independent of their attached ports.

Mutual proof of possession
     The peer and authenticator MUST each demonstrate possession of the
     keying material transported between the backend authentication
     server and authenticator (AAA-Key).

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

Creation Part 11:  Wireless LAN Medium
          Access Control (MAC) and Deletion
     In order to support the correct processing of phase 2 security
     associations, the Secure Association (phase 2) protocol MUST
     support the naming Physical Layer (PHY) Specifications",
          IEEE IEEE Standard 802.11-2003, 2003.

[IEEE-802.1X]
          Institute of phase 2 security associations Electrical and associated
     transient session keys, so that the correct set of transient
     session keys can be identified for processing a given packet.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation Electronics Engineers, "Local and SHOULD support deletion, so that
     establishment and re-establishment of transient session keys can be
     synchronized between the parties.

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

Direct operation
     Since the phase 2 Secure Association Protocol is concerned with the
     establishment of security associations between the EAP peer and
     authenticator, including the derivation of transient session keys,
     only those parties have "a need to know" the transient session
     keys. The Secure Association Protocol MUST operate directly between
     the peer and authenticator, and MUST NOT be passed-through to the
     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 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 backend
     authentication server is not fresh.  This is typically supported by
     including an exchange of nonces within the Secure Association
     Protocol.

Bi-directional operation
     While some ciphersuites only require a single set of transient
     session keys to 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 the derivation of unicast and multicast keys in each direction,
     so as not to require two separate phase 2 exchanges in order to
     create a bi-directional phase 2 security association.

Secure capabilities negotiation
     The Secure Association Protocol MUST support secure capabilities
     negotiation.  This includes security parameters such as the
     security association identifier (SAID) and ciphersuites, as well as
     negotiation of the lifetime of the TSKs, AAA-Key and exported EAP
     keys.  Secure capabilities negotiation also includes confirmation
     of the capabilities discovered during the discovery phase (phase
     0), so as to ensure that the announced capabilities have not been
     forged.

Key Scoping
     The Secure Association Protocol MUST ensure the synchronization of
     key scope between the peer and authenticator.  This includes
     negotiation of restrictions on key usage.

7.4.  Ciphersuite Requirements

   Ciphersuites suitable for keying by EAP methods MUST provide the
   following facilities:

TSK derivation
     In order to allow a ciphersuite to be usable within the EAP keying
     framework, a specification MUST be provided describing how
     transient session keys suitable for use with the ciphersuite are
     derived from the AAA-Key.

EAP method independence
     Algorithms for deriving transient session keys from the AAA-Key
     MUST NOT depend on the EAP method.  However, algorithms for
     deriving TEKs MAY be specific to the EAP method.

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

8.  IANA Considerations

   This document does not create any new name spaces nor does it
   allocate any protocol parameters.

9.  References

9.1.  Normative References

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

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

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

9.2.  Informative References

[CTP]     Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli,
          "Context Transfer Protocol", draft-ietf-seamoby-ctp-11.txt,
          Internet draft (work in progress), August 2004.

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

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

[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-
          aaa-key-mgmt-00.txt, Internet draft (work in progress), June
          2005..IP  [IEEE-802] Institute of Electrical and Electronics
          Engineers, "IEEE Standards for Local and Metropolitan Area
          Networks: Overview and Architecture", ANSI/IEEE Standard 802,
          1990.

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

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

[IEEE-802.1Q]
          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.

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

[IEEE-802.11F]
          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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acknowledgments

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

Author Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

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

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

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

   Jari Arkko
   Ericsson
   Jorvas 02420
   Finland

   Phone:
   EMail: jari.arkko@ericsson.com

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

   EMail: pasi.eronen@nokia.com

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

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

Appendix A - Ciphersuite Keying Requirements

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

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

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

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

   Within [IEEE-802.11], 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
   [IEEE-802.11], 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 [IEEE-802.11i].  These include TKIP,
   which requires a single 128-bit encryption key and two 64-bit
   authentication keys (one for each direction); and AES CCMP, which
   requires a single 128-bit key (used in both directions) in order to
   authenticate and encrypt data.

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

Appendix B - Transient EAP Key (TEK) Hierarchy

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

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

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

   Figure B-1 - TLS [RFC2246] Key Hierarchy

Appendix C - EAP-TLS Key Hierarchy

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

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

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

   The key derivation scheme specified in RFC 2716 that was specified
   prior to the introduction of the terminology MSK and EMSK MUST be
   interpreted as follows:

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

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

   Where:

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

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

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

   Figure C-1
          Metropolitan Area Networks: Port-Based Network Access
          Control", IEEE Standard 802.1X-2004, December 2004.

[IEEE-802.1Q]
          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.

[IEEE-802.11i]
          Institute of Electrical and Electronics Engineers, "Supplement
          to STANDARD FOR Telecommunications and Information Exchange
          between Systems - EAP TLS [RFC2716] Key hierarchy

Appendix D LAN/MAN Specific Requirements - Example Transient Session Key (TSK) Derivation

   Within Part 11:
          Wireless Medium Access Control (MAC) and physical layer (PHY)
          specifications: Specification for Enhanced Security", 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
          802.11i, December 2004.

[IEEE-802.11F]
          Institute of the MSK), known in [RFC2716] as the Peer to
   Authenticator Encryption Key.  In [IEEE-802.11i],  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              = Electrical and Electronics Engineers,
          "Recommended Practice for Multi-Vendor Access Point MAC address (Called-Station-Id)
   ANonce          = Access
          Interoperability via an Inter-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, Protocol Across
          Distribution Systems Supporting IEEE 802.11 Operation", IEEE
          802.11F, July 2003.

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

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

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

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

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

[I-D.arkko-pppext-eap-aka]
          Arkko, J. and WEP use X = 48.

   The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
   authenticity H. Haverinen, "EAP AKA Authentication", draft-
          arkko-pppext-eap-aka-15.txt (work in progress), December 2004.

[I-D.arkko-eap-service-identity-auth]
          Arkko, J. and P. Eronen, "Authenticated Service Information
          for the TSK derivation. It utilizes the first 128 bits
   (bits 0-127) of the PTK.  The EAPOL-Key Encryption Key (KEK) provides
   confidentiality Extensible Authentication Protocol (EAP)", draft-
          arkko-eap-service-identity-auth-02.txt (work 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 progress), May
          2005.

[I-D.ohba-eap-aaakey-binding]
          Ohba, Y., "AAA-Key Derivation with Channel Binding", draft-
          ohba-eap-aaakey-binding-00.txt (work in progress), May 2005.

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

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

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

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

[RFC1968] Meyer, G. and TK2 is
   ciphersuite specific. Details are available in [IEEE-802.11i].

Appendix E - Exported Parameters in Existing Methods

   This Appendix specifies Method-ID, Peer-ID, Server-ID K. Fox, "The PPP Encryption Control Protocol
          (ECP)", RFC 1968, June 1996.

[RFC2104] Krawczyk, H., Bellare, M. and Key-
   Lifetime R. Canetti, "HMAC: Keyed-Hashing
          for EAP methods that have been published prior to this
   specification.  Future EAP method specifications MUST include a
   definition of the Method-ID,  Peer-ID, 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 Server-ID (could be R. Atkinson, "Security Architecture for the
   empty string)
          Internet Protocol", RFC 2401, November 1998.

[RFC2409] Harkins, D. and MAY also define the Key-Lifetime (assumed to be
   indeterminate if not described).

   EAP-Identity

      The EAP-Identity method does not derive keys, D. Carrel, "The Internet Key Exchange (IKE)",
          RFC 2409, November 1998.

[RFC2419] Sklower, K. and therefore does
      not define the Key-Lifetime or Method-ID. The Peer-ID exported by
      the Identity method is determined by the octets included within
      the EAP- Response/Identity.  The Server-ID is the empty string
      (zero length).

   EAP-Notification

      The EAP-Notification method does not derive keys 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 therefore
      does not define the Key-Lifetime
          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 Method-ID.  The Peer-ID J. Vollbrecht, "Proxy Chaining and
      Server-ID are the empty string (zero length).

   EAP-GTC

      The EAP-GTC method does not derive keys Policy
          Implementation in Roaming", RFC 2607, June 1999.

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

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

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

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

[RFC3579] Aboba, B. and therefore does not
      define the Key-Lifetime 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 Method-ID.  The Peer-ID 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 Server-ID
      are the empty string.

   EAP-OTP

      The EAP-OTP method does not derive keys J.
          Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3766] Orman, H. and therefore does not
      define the Key-Lifetime P. Hoffman, "Determining Strengths For Public
          Keys Used For Exchanging Symmetric  Keys", RFC 3766, April
          2004.

[RFC4005] Calhoun, P., Zorn, G., Spence, D. and Method-ID.  The Peer-ID D. Mitton, "Diameter
          Network Access Server Application", RFC 4005, August 2005.

[RFC4017] Stanley, D., Walker, J. and Server-ID
      are the empty string.

   EAP-TLS

      The EAP-TLS Method-Id is the concatenation of the peer B. Aboba, "EAP Method Requirements
          for Wireless LANs", RFC 4017, March 2005.

[RFC4072] Eronen, P., Hiller, T. and server
      nonces.

      The Peer-ID G. Zorn, "Diameter Extensible
          Authentication Protocol (EAP) Application", RFC 4072, August
          2005.

[8021XHandoff]
          Pack, S. and Server-ID are the contents of the altSubjectName Y. Choi, "Pre-Authenticated Fast Handoff in the peer and server certificates.

      EAP-TLS does not negotiate a Key-Lifetime.

   EAP-AKA

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

      The Peer-ID is the contents
          Public Wireless LAN Based on IEEE 802.1X Model", School of the Identity field from the
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless
          Computer Science and Engineering, Seoul National University,
          Seoul, Korea, 2002.

Acknowledgments

   Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of whether the
      transmitted identity was a permanent, pseudonym, or fast
      reauthentication identity.  The Server- ID is an empty string.
      EAP-AKA does not negotiate a key lifetime.

   EAP-SIM

      The Method-Id is the contents Microsoft,
   Dorothy Stanley of the RAND field from the AT_RAND
      attribute, followed by the contents Agere, Bob Moskowitz of the NONCE_MT field in the
      AT_NONCE_MT attribute.

      The Peer-ID is the contents TruSecure, Jesse Walker of the Identity field from the
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless
   Intel, Joe Salowey of whether the
      transmitted identity was a permanent, pseudonym, or fast
      reauthentication identity.  The Server- ID is an empty string.
      EAP-SIM does not negotiate a key lifetime. Cisco and Russ Housley of Vigil Security for
   useful feedback.

Author Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

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

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

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

   Jari Arkko
   Ericsson
   Jorvas 02420
   Finland

   Phone:
   EMail: jari.arkko@ericsson.com

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

   EMail: pasi.eronen@nokia.com

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

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

Appendix F A - Security Association Examples

EAP Method SA Example: EAP-TLS

   In Key Hierarchy

   EAP-TLS [RFC2716], after [RFC 2716] was documented prior to the development of EAP authentication key
   management terminology [RFC3748], and therefore does not explicitly
   define the client (peer) MSK and server can store EMSK.

   In EAP-TLS, the following information:

      o  Implicitly, MSK, EMSK and IV are derived from the EAP method this SA refers to (EAP-TLS)
      o  Session identifier (a value selected by TLS master
   secret via a one-way function. This ensures that the server)
      o  Certificate of TLS master
   secret cannot be derived from the MSK, EMSK or IV unless the one-way
   function (TLS PRF) is broken.  Since the MSK is derived from the other party (server stores the client's
         certificate and vice versa)
      o  Ciphersuite and compression method
      o
   TLS Master master secret, if the TLS master secret (known as is compromised then the EAP-TLS Master Key)
      o  SA lifetime (ensuring
   MSK is also compromised.

   [RFC2716] specifies that the SA MSK is not stored forever)
      o  If divided into two halves,
   corresponding to the client has multiple different credentials (certificates "Peer to Authenticator Encryption Key" (Enc-
   RECV-Key, 32 octets, also known as the PMK) and corresponding private keys), a pointer "Authenticator to those credentials

   When
   Peer Encryption Key" (Enc-SEND-Key, 32 octets).  In [RFC2548], the server initiates EAP-TLS,
   Enc-RECV-Key (the PMK) is transported in the client can look up MS-MPPE-Recv-Key
   attribute, and the EAP-TLS
   SA based on Enc-SEND-Key is transported in the credentials it was going MS-MPPE-Send-
   Key attribute.

   The EMSK is also divided into two halves, corresponding to use (certificate and
   private key), 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 expected credentials (certificate "Peer to Authenticator IV" or name) of
   the server. If an EAP-TLS SA exists, RECV-IV, and it is not too old, the
   client informs the server about the existence of this SA by including
   its Session-Id in
   Octets 32-63 are known as the TLS ClientHello message. "Authenticator to Peer IV", or SEND-IV.

   The server then looks
   up the correct SA based on the Session-Id (or detects that it doesn't
   yet have one). key derivation scheme  MUST be interpreted as follows:

   MSK           = TLS-PRF-64(TMS, "client EAP Method SA Example: EAP-AKA

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

      o  Implicitly, the encryption",
                      client.random || server.random)
   IV            = TLS-PRF-64("", "client EAP method this SA refers encryption",
                      client.random || server.random)

   MSK(0,31)     = Peer to (EAP-AKA)
      o  A re-authentication pseudonym
      o  The client's permanent identity (IMSI)
      o  Replay protection counter
      o  Authentication key (K_aut)
      o Authenticator Encryption key (K_encr)
      o  Original Master Key (MK)
      o  SA lifetime (ensuring that (Enc-RECV-Key)
                   (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the SA is not stored forever)

   When
                   PMK.
   MSK(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:

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

   Figure A-1 illustrates the EAP-AKA
   SA TEK key hierarchy for EAP-TLS [RFC2716],
   which is based on the credentials it was going TLS key hierarchy described in [RFC2246].  The
   TLS-negotiated ciphersuite is used to set up a protected channel for
   use (permanent identity).
   If an EAP-AKA SA exists, and it is not too old, the client informs
   the server about in protecting the existence of this SA EAP conversation,  keyed by sending its re-
   authentication pseudonym the derived TEKs.
   The TEK derivation proceeds as its identity 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 EAP Identity Response
   message, instead of its permanent identity. The [RFC2246],
                   computed to X octets.

          |                       | pre_master_secret         |
    server|                       |                           | client
    Random|                       V                           | Random
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |     |                                     |       |
          +---->|             master_secret           |<------+
          |     |               (TMS)                 |       |
          |     |                                     |       |
          |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |
          |                       |                           |
          V                       V                           V
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                    Key Block  (TEKs)                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           |           |           |           |           |
      | client    | server then looks up
   the correct SA based on    | client    | server    | client    | server
      | MAC       | MAC       | write     | write     | IV        | IV
      |           |           |           |           |           |
      V           V           V           V           V           V

   Figure A-1 - TLS [RFC2246] Key Hierarchy

Appendix B - Exported Parameters in Existing Methods

   This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
   Lifetime for EAP methods that have been published prior to this identity.

AAA SA Example: RADIUS

   In RADIUS, where shared secret authentication is used,
   specification.  Future EAP method specifications MUST include a
   definition of the client Method-ID,  Peer-ID, and
   server store each other's IP address Server-ID (could be the
   empty string) and MAY also define the shared secret, which is
   used Key-Lifetime (assumed to calculate the Response Authenticator [RFC2865] and Message-
   Authenticator [RFC3579] values, be
   indeterminate if not described).

   EAP-Identity

      The EAP-Identity method does not derive keys, and to encrypt some attributes (such
   as therefore does
      not define the AAA-Key, see [RFC3580] Section 3.16).

   Where IPsec Key-Lifetime or Method-ID. The Peer-ID exported by
      the Identity method is used to protect RADIUS [RFC3579] and IKE determined by the octets included within
      the EAP- Response/Identity.  The Server-ID is used for
   key management, the parties store information necessary to
   authenticate empty string
      (zero length).

   EAP-Notification

      The EAP-Notification method does not derive keys and authorize therefore
      does not define the other party (e.g. certificates, trust
   anchors Key-Lifetime and names). Method-ID.  The IKE exchange results in IKE Phase 1 Peer-ID and Phase
   2 SAs containing information used to protect the conversation
   (session keys, selected ciphersuite, etc.)

AAA SA Example: Diameter with TLS

   When using Diameter protected by TLS,
      Server-ID are the parties store information
   necessary to authenticate empty string (zero length).

   EAP-GTC

      The EAP-GTC method does not derive keys and authorize therefore does not
      define the other party (e.g.
   certificates, trust anchors Key-Lifetime and names). Method-ID.  The TLS handshake results in
   a short-term TLS SA that contains information used to protect the
   actual communications (session keys, selected TLS ciphersuite, etc.).

Service SA Example: 802.11i

   [IEEE802.11i] Section 8.4.1.1 defines Peer-ID and Server-ID
      are the security associations used
   within IEEE 802.11.  A summary follows; empty string.

   EAP-OTP

      The EAP-OTP method does not derive keys and therefore does not
      define the standard should be
   consulted for details.

   o Pairwise Master Key Security Association (PMKSA) Key-Lifetime and Method-ID.  The PMKSA is a bi-directional SA, used by both parties for sending Peer-ID and receiving. Server-ID
      are the empty string.

   EAP-TLS

      The PMKSA EAP-TLS Method-Id is the Root Service SA.  It is created
      on concatenation of the peer when EAP authentication completes successfully or a
      pre-shared key is configured. and server
      nonces.

      The PMKSA is created on Peer-ID and Server-ID are the
      authenticator when contents of the PMK is received or created on altSubjectName
      in the
      authenticator or peer and server certificates.

      EAP-TLS does not negotiate a pre-shared key is configured. Key-Lifetime.

   EAP-AKA

      The PMKSA EAP-AKA Method-Id is
      used to create the PTKSA.  PMKSAs are cached for their lifetimes.
      The PMKSA consists contents of the following elements:

      - PMKID (security association identifier)
      - Authenticator MAC address
      - PMK
      - Lifetime
      - Authenticated Key Management Protocol (AKMP)
      - Authorization parameters specified by RAND field from the AAA server or
      AT_RAND attribute, followed by local configuration.  This can include
        parameters such as the peer's authorized SSID.

        On contents of the peer, this information can be locally
        configured.
      - Key replay counters (for EAPOL-Key messages)
      - Reference to PTKSA (if any), needed to:
          o delete it (e.g. AAA server-initiated disconnect)
          o replace it when a new four-way handshake AUTN field in
      the AT_AUTN attribute.

      The Peer-ID is done
      - Reference to accounting context, the details contents of which depend
        on the accounting protocol used, Identity field from the implementation
        and administrative details. In RADIUS, this could include
        (e.g. packet and octet counters, and Acct-Multi-Session-Id).

   o Pairwise Transient Key Security Association (PTKSA)

      The PTKSA is a bi-directional SA created as
      AT_IDENTITY attribute, using only the result Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless of whether the
      transmitted identity was a
      successful four-way handshake. permanent, pseudonym, or fast re-
      authentication identity.  The PTKSA Server-ID is an empty string.  EAP-
      AKA does not negotiate a unicast service SA.
      There may only be one PTKSA between a pair of peer and
      authenticator MAC addresses.  PTKSAs are cached for the lifetime
      of the PMKSA.  Since the PTKSA key lifetime.

   EAP-SIM

      The Method-Id is tied to the PMKSA, it only has contents of the additional information RAND field from the 4-way handshake.  The PTKSA
      consists of AT_RAND
      attribute, followed by the following:

         - Key (PTK)
         - Selected ciphersuite
         - MAC addresses contents of the parties
         - Replay counters, and ciphersuite specific state
         - Reference to PMKSA: This is needed when:
            o A new four-way handshake is needed (lifetime, TKIP
              countermeasures), and we need to know which PMKSA to use

   o Group Transient Key Security Association (GTKSA)

      The GTKSA is a uni-directional SA created based on the four-way
      handshake or NONCE_MT field in the group key handshake.
      AT_NONCE_MT attribute.

      The GTKSA Peer-ID is a multicast
      service SA.  A GTKSA consists of the following:

         - Direction vector (whether the GTK is used for transmit or receive)
         - Group cipher suite selector
         - Key (GTK)
         - Authenticator MAC address
         - Via reference to PMKSA, or copied here:
           o Authorization parameters
           o Reference to accounting context

   Service SA Example: IKEv2/IPsec

      Note that this example is intended to be informative, and it does
      not necessarily include all information stored.

   o IKEv2 SA

      - Protocol version
      - Identities contents of the parties
      - IKEv2 SPIs
      - Selected ciphersuite
      - Replay protection counters (Message ID)
      - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
      - Key for deriving keys for IPsec SAs (SK_d)
      - Lifetime information
      - On Identity field from the authenticator, service authorization information
        received
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the backend authentication server.

   When processing an incoming message, beginning, however.  Note that the correct SA is looked up
   based on contents are
      used as they are transmitted, regardless of whether the SPIs.

   o IPsec SAs/SPD

      - Traffic selectors
      - Replay protection counters
      - Selected ciphersuite
      - IPsec SPI
      - Keys
      - Lifetime information
      - Protocol mode (tunnel
      transmitted identity was a permanent, pseudonym, or transport) fast re-
      authentication identity.  The correct SA Server-ID is looked up based on SPI (for inbound packets), or
      SPD traffic selectors (for outbound traffic).  A separate IPsec SA
      exists for each direction. an empty string.  EAP-
      SIM does not negotiate a key lifetime.

Intellectual Property Statement

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

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

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

Disclaimer of Validity

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

Copyright Statement

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

Acknowledgment

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

Open Issues

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

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