4.  Handoff Vulnerabilities

   A handoff occurs when an EAP peer moves to a new authenticator.
   Several mechanisms have been proposed for reducing handoff latency
   within networks utilizing EAP.  These include:

   EAP pre-authentication
      In EAP pre-authentication, an EAP peer pre-establishes EAP keying
      material with an authenticator prior to arrival.  EAP
      pre-authentication only affects the timing of EAP authentication,
      but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
      exchanges;  Discovery (phase 0) and Secure Association Protocol
      (phase 2) exchanges occur as described in Section 1.3.  As a
      result, the primary benefit is to enable EAP authentication to be
      removed from the handoff critical path, thereby reducing latency.
      Use of EAP pre-authentication within IEEE 802.11 is described in
      [IEEE-802.11] and [8021XPreAuth].

   Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.  As a result, EAP
      (phase 1a) is not needed, but the Discovery (phase 0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication.  Proactive key distribution is described in
      [MishraPro], [IEEE-03-084], and [HANDOFF].

   Key caching
      Caching of EAP keying material enables an EAP peer to re-attach to
      an authenticator without requiring EAP (phase 1a) or AAA (phase
      1b) exchanges.  However, Discovery (phase 0) and Secure
      Association Protocol (phase 2) exchanges are still needed.  Use of
      key caching within IEEE 802.11 is described in [IEEE-802.11].

   Context transfer
      In context transfer schemes, keying material and authorizations
      are transferred between a previous authenticator and a new
      authenticator.  This can occur in response to a handoff request by
      the EAP peer, or in advance, as in proactive key distribution.  As
      a result, EAP (phase 1a) is eliminated, but not the Discovery
      (phase 0) or Secure Association Protocol exchanges (phase 2).  If
      a secure channel can be established between the new and previous
      authenticator without assistance from the backend authentication
      server, then the AAA exchange (phase 1b) can be eliminated;
      otherwise, it is still needed, although it can be shortened.
      Context transfer protocols are described in [IEEE-802.11F] (now
      deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
      "Fast Authentication Methods for Handovers between IEEE 802.11
      Wireless LANs" [Bargh] analyzes fast handoff techniques, including
      context transfer mechanisms.

   Token distribution
      In token distribution schemes, the EAP peer is provided with a
      credential, subsequently enabling it to authenticate with one or
      more additional authenticators.  During the subsequent
      authentications, EAP (phase 1a) is eliminated or shortened; the
      Discovery (phase 0) and Secure Association Protocol exchanges
      (phase 2) still occur, although the latter can be shortened.  If
      the token includes authorizations and can be validated by an
      authenticator without assistance from the backend authentication
      server, then the AAA exchange (phase 1b) can be eliminated;
      otherwise, it is still needed, although it can be shortened.
      Token-based schemes, initially proposed in early versions of IEEE
      802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and
      [SHORT-TERM].

   The sections that follow discuss the security vulnerabilities
   introduced by the above schemes.

4.1.  EAP Pre-Authentication

   EAP pre-authentication differs from a normal EAP conversation
   primarily with respect to the lower-layer encapsulation.  For
   example, in [IEEE-802.11], EAP pre-authentication frames utilize a
   distinct Ethertype, but otherwise conforms to the encapsulation
   described in [IEEE-802.1X].  As a result, an EAP pre-authentication
   conversation differs little from the model described in Section 1.3,
   other than the introduction of a delay between phase 1 and phase 2.

   EAP pre-authentication relies on lower-layer mechanisms for discovery
   of candidate authenticators.  Where discovery can provide information
   on candidate authenticators outside the immediate listening range,
   and the peer can determine whether it already possesses valid EAP
   keying material with candidate authenticators, the peer can avoid
   unnecessary EAP pre-authentications and can establish EAP keying
   material well in advance, regardless of the coverage overlap between
   authenticators.  However, if the peer can only discover candidate
   authenticators within listening range and cannot determine whether it
   can reuse existing EAP keying material, then it is possible that the
   peer will not be able to complete EAP pre-authentication prior to
   connectivity loss or that it can pre-authenticate multiple times with
   the same authenticator, increasing backend authentication server
   load.

   Since a peer can complete EAP pre-authentication with an
   authenticator without eventually attaching to it, it is possible that
   phase 2 will not occur.  In this case, an Accounting-Request
   signifying the start of service will not be sent, or will only be
   sent with a substantial delay after the completion of authentication.

   As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
   exchange resulting from EAP pre-authentication differs little from an
   ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
   For example, since in IEEE 802.11 [IEEE-802.11] an Association
   exchange does not occur prior to EAP pre-authentication, the SSID is
   not known by the authenticator at authentication time, so that an
   Access-Request cannot include the SSID within the Called-Station-Id
   attribute as described in [RFC3580] Section 3.20.

   Since only the absence of an SSID in the Called-Station-Id attribute
   distinguishes an EAP pre-authentication attempt, if the authenticator
   does not always include the SSID for a normal EAP authentication
   attempt, it is possible that the backend authentication server will
   not be able to determine whether a session constitutes an EAP
   pre-authentication attempt, potentially resulting in authorization or
   accounting problems.  Where the number of simultaneous sessions is
   limited, the backend authentication server can refuse to authorize a
   valid EAP pre-authentication attempt or can enable the peer to engage
   in more simultaneous sessions than they are authorized for.  Where
   EAP pre-authentication occurs with an authenticator which the peer
   never attaches to, it is possible that the backend accounting server
   will not be able to determine whether the absence of an
   Accounting-Request was due to packet loss or a session that never
   started.

   In order to enable pre-authentication requests to be handled more
   reliably, it is RECOMMENDED that AAA protocols explicitly identify
   EAP pre-authentication.  In order to suppress unnecessary EAP
   pre-authentication exchanges, it is RECOMMENDED that authenticators
   unambiguously identify themselves as described in Section 2.3.

4.2.  Proactive Key Distribution

   In proactive key distribution schemes, the backend authentication
   server transports keying material and authorizations to an
   authenticator in advance of the arrival of the peer.  The
   authenticators selected to receive the transported key material are
   selected based on past patterns of peer movement between
   authenticators known as the "neighbor graph".  In order to reduce
   handoff latency, proactive key distribution schemes typically only
   demonstrate proof of possession of transported keying material
   between the EAP peer and authenticator.  During a handoff, the
   backend authentication server is not provided with proof that the
   peer successfully authenticated to an authenticator; instead, the
   authenticator generates a stream of accounting messages without a
   corresponding set of authentication exchanges.  As described in
   [MishraPro], knowledge of the neighbor graph can be established via
   static configuration or analysis of authentication exchanges.  In

   order to prevent corruption of the neighbor graph, new neighbor graph
   entries can only be created as the result of a successful EAP
   exchange, and accounting packets with no corresponding authentication
   exchange need to be verified to correspond to neighbor graph entries
   (e.g., corresponding to handoffs between neighbors).

   In order to prevent compromise of one authenticator from resulting in
   compromise of other authenticators, cryptographic separation needs to
   be maintained between the keying material transported to each
   authenticator.  However, even where cryptographic separation is
   maintained, an attacker compromising an authenticator can still
   disrupt the operation of other authenticators.  As noted in [RFC3579]
   Section 4.3.7, in the absence of spoofing detection within the AAA
   infrastructure, it is possible for EAP authenticators to impersonate
   each other.  By forging NAS identification attributes within
   authentication messages, an attacker compromising one authenticator
   could corrupt the neighbor graph, tricking the backend authentication
   server into transporting keying material to arbitrary authenticators.
   While this would not enable recovery of EAP keying material without
   breaking fundamental cryptographic assumptions, it could enable
   subsequent fraudulent accounting messages, or allow an attacker to
   disrupt service by increasing load on the backend authentication
   server or thrashing the authenticator key cache.

   Since proactive key distribution requires the distribution of derived
   keying material to candidate authenticators, the effectiveness of
   this scheme depends on the ability of backend authentication server
   to anticipate the movement of the EAP peer.  Since proactive key
   distribution relies on backend authentication server knowledge of the
   neighbor graph, it is most applicable to intra-domain handoff
   scenarios.  However, in inter-domain handoff, where there can be many
   authenticators, peers can frequently connect to authenticators that
   have not been previously encountered, making it difficult for the
   backend authentication server to derive a complete neighbor graph.

   Since proactive key distribution schemes typically require
   introduction of server-initiated messages as described in [RFC5176]
   and [HANDOFF], security issues described in [RFC5176] Section 6 are
   applicable, including authorization (Section 6.1) and replay
   detection (Section 6.3) problems.

4.3.  AAA Bypass

   Fast handoff techniques that enable elimination of the AAA exchange
   (phase 1b) differ fundamentally from typical network access scenarios
   (dial-up, wired LAN, etc.) that include user authentication as well
   as authorization for the offered service.  Where the AAA exchange
   (phase 1b) is omitted, authorizations and keying material are not
   provided by the backend authentication server, and as a result, they
   need to be supplied by other means.  This section describes some of
   the implications.

4.3.1.  Key Transport

   Where transported keying material is not supplied by the backend
   authentication server, it needs to be provided by another party
   authorized to access that keying material.  As noted in Section 1.5,
   only the EAP peer, authenticator, and server are authorized to
   possess transported keying material.  Since EAP peers do not trust
   each other, if the backend authentication server does not supply
   transported keying material to a new authenticator, it can only be
   provided by a previous authenticator.

   As noted in Section 1.5, the goal of the EAP conversation is to
   derive session keys known only to the peer and the authenticator.  If
   keying material is replicated between a previous authenticator and a
   new authenticator, then the previous authenticator can possess
   session keys used between the peer and new authenticator.  Also, the
   new authenticator can possess session keys used between the peer and
   the previous authenticator.

   If a one-way function is used to derive the keying material to be
   transported to the new authenticator, then the new authenticator
   cannot possess previous session keys without breaking a fundamental
   cryptographic assumption.

4.3.2.  Authorization

   As a part of the authentication process, the backend authentication
   server determines the user's authorization profile and transmits the
   authorizations to the authenticator along with the transported keying
   material.  Typically, the profile is determined based on the user
   identity, but a certificate presented by the user can also provide
   authorization information.

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

   (a)  Is this a legitimate user of this network?

   (b)  Is the user allowed to access this network?

   (c)  Is the user permitted to access this network on this day and at
        this time?

   (d)  Is the user within the concurrent session limit?

   (e)  Are there any fraud, credit limit, or other concerns that could
        lead to access denial?

   (f)  If access is to be granted, what are the service parameters
        (mandatory tunneling, bandwidth, filters, and so on) to be
        provisioned for the user?

   While the authorization decision is, in principle, simple, the
   distributed decision making process can add complexity.  Where
   brokers or proxies are involved, all of the AAA entities in the chain
   from the authenticator to the home backend authentication server are
   involved in the decision.  For example, a broker can deny access even
   if the home backend authentication 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 concurrent session
   limits).  In addition to the Accept/Reject decisions made by AAA
   entities, service parameters or constraints can be communicated to
   the authenticator.

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

4.3.3.  Correctness

   When the AAA exchange (phase 1b) is bypassed, several challenges
   arise in ensuring correct authorization:

   Theft of service
      Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to
      extend their network access or gain access to services they are
      not entitled to.

   Consideration of network-wide state
      Handoff techniques SHOULD NOT render the backend authentication
      server incapable of keeping track of network-wide state.  For
      example, a backend authentication server can need to keep track of
      simultaneous user sessions.

   Elevation of privilege
      Backend authentication servers often perform conditional
      evaluation, in which the authorizations returned in an
      Access-Accept message are contingent on the authenticator or on
      dynamic state such as the time of day.  In this situation,
      bypassing the AAA exchange could enable unauthorized access unless
      the restrictions are explicitly encoded within the authorizations
      provided by the backend authentication server.

   A handoff mechanism that provides proper authorization is said to be
   "correct".  One condition for correctness is as follows:

      For a handoff to be "correct" it MUST establish on the new
      authenticator the same authorizations as would have been created
      had the new authenticator completed a AAA conversation with the
      backend authentication server.

   A properly designed handoff scheme will only succeed if it is
   "correct" in this way.  If a successful handoff would establish
   "incorrect" authorizations, it is preferable for it to fail.  Where
   the supported services differ between authenticators, a handoff that
   bypasses the backend authentication server is likely to fail.
   Section 1.1 of [RFC2865] states:

      A authenticator that does not implement a given service MUST NOT
      implement the RADIUS attributes for that service.  For example, a
      authenticator that is unable to offer ARAP service MUST NOT
      implement the RADIUS attributes for ARAP.  A authenticator MUST
      treat a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead.

   This behavior applies to attributes that are known, but not
   implemented.  For attributes that are unknown, Section 5 of [RFC2865]
   states:

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

   In order to perform a correct handoff, if a new authenticator is
   provided with RADIUS authorizations for a known but unavailable
   service, then it MUST process these authorizations the same way it
   would handle a RADIUS Access-Accept requesting an unavailable

   service;  this MUST cause the handoff to fail.  However, if a new
   authenticator is provided with authorizations including unknown
   attributes, then these attributes MAY be ignored.  The definition of
   a "known but unsupported service" MUST encompass requests for
   unavailable security services.  This includes vendor-specific
   attributes related to security, such as those described in [RFC2548].
   Although it can seem somewhat counter-intuitive, failure is indeed
   the "correct" result where a known but unsupported service is
   requested.

   Presumably, a correctly configured backend authentication server
   would not request that an authenticator provide a service that it
   does not implement.  This implies that if the new authenticator were
   to complete a AAA conversation, it would be likely to receive
   different service instructions.  Failure of the handoff is the
   desired result since it will cause the new authenticator to go back
   to the backend server in order to receive the appropriate service
   definition.

   Handoff mechanisms that bypass the backend authentication server are
   most likely to be successful when employed in a homogeneous
   deployment within a single administrative domain.  In a heterogeneous
   deployment, the backend authentication server can return different
   authorizations depending on the authenticator making the request in
   order to make sure that the requested service is consistent with the
   authenticator capabilities.  Where a backend authentication server
   would send different authorizations to the new authenticator than
   were sent to a previous authenticator, transferring authorizations
   between the previous authenticator and the new authenticator will
   result in incorrect authorization.

   Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
   support for dynamic VLANs is described in [RFC3580] and [RFC4675].
   If some authenticators support dynamic VLANs while others do not,
   then attributes present in the Access-Request (such as the
   NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier)
   could be examined by the backend authentication server to determine
   when VLAN attributes will be returned, and if so, which ones.
   However, if the backend authenticator is bypassed, then a handoff
   occurring between authenticators supporting different VLAN
   capabilities could result in a user obtaining access to an
   unauthorized VLAN (e.g., a user with access to a guest VLAN being
   given unrestricted access to the network).

   Similarly, it is preferable for a handoff between an authenticator
   providing confidentiality and another that does not to fail, since if
   the handoff were successful, the user would be moved from a secure to
   an insecure channel without permission from the backend
   authentication server.

5.  Security Considerations

   The EAP threat model is described in [RFC3748] Section 7.1.  The
   security properties of EAP methods (known as "security claims") are
   described in [RFC3748] Section 7.2.1.  EAP method requirements for
   applications such as Wireless LAN authentication are described in
   [RFC4017].  The RADIUS threat model is described in [RFC3579] Section
   4.1, and responses to these threats are described in [RFC3579],
   Sections 4.2 and 4.3.

   However, in addition to threats against EAP and AAA, there are other
   system level threats.  In developing the threat model, it is assumed
   that:

      All traffic is visible to the attacker.
      The attacker can alter, forge, or replay messages.
      The attacker can reroute messages to another principal.
      The attacker can be a principal or an outsider.
      The attacker can compromise any key that is sufficiently old.

   Threats arising from these assumptions include:

   (a)  An attacker can compromise or steal an EAP peer or
        authenticator, in an attempt to gain access to other EAP peers
        or authenticators or to obtain long-term secrets.

   (b)  An attacker can attempt a downgrade attack in order to exploit
        known weaknesses in an authentication method or cryptographic
        algorithm.

   (c)  An attacker can try to modify or spoof packets, including
        Discovery or Secure Association Protocol frames, EAP or AAA
        packets.

   (d)  An attacker can attempt to induce an EAP peer, authenticator, or
        server to disclose keying material to an unauthorized party, or
        utilize keying material outside the context that it was intended
        for.

   (e)  An attacker can alter, forge, or replay packets.

   (f)  An attacker can cause an EAP peer, authenticator, or server to
        reuse a stale key.  Use of stale keys can also occur
        unintentionally.  For example, a poorly implemented backend
        authentication server can provide stale keying material to an
        authenticator, or a poorly implemented authenticator can reuse
        nonces.

   (g)  An authenticated attacker can attempt to obtain elevated
        privilege in order to access information that it does not have
        rights to.

   (h)  An attacker can attempt a man-in-the-middle attack in order to
        gain access to the network.

   (i)  An attacker can compromise an EAP authenticator in an effort to
        commit fraud.  For example, a compromised authenticator can
        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 and EAP
        server.

   (j)  An attacker can launch a denial-of-service attack against the
        EAP peer, authenticator, or backend authentication server.

   In order to address these threats, [RFC4962] Section 3 describes
   required and recommended security properties.  The sections that
   follow analyze the compliance of EAP methods, AAA protocols, and
   Secure Association Protocols with those guidelines.

5.1.  Peer and Authenticator Compromise

   Requirement: In the event that an authenticator is compromised or
   stolen, an attacker can gain access to the network through that
   authenticator, or can obtain the credentials needed for the
   authenticator/AAA client to communicate with one or more backend
   authentication servers.  Similarly, if a peer is compromised or
   stolen, an attacker can obtain credentials needed to communicate with
   one or more authenticators.  A mandatory requirement from [RFC4962]
   Section 3:

      Prevent the Domino effect

      Compromise of a single peer MUST NOT compromise keying material
      held by any other peer within the system, including session keys
      and long-term keys.  Likewise, compromise of a single
      authenticator MUST NOT compromise keying material held by any
      other authenticator within the system.  In the context of a key

      hierarchy, this means that the compromise of one node in the key
      hierarchy must not disclose the information necessary to
      compromise other branches in the key hierarchy.  Obviously, the
      compromise of the root of the key hierarchy will compromise all of
      the keys; however, a compromise in one branch MUST NOT result in
      the compromise of other branches.  There are many implications of
      this requirement; however, two implications deserve highlighting.
      First, the scope of the keying material must be defined and
      understood by all parties that communicate with a party that holds
      that keying material.  Second, a party that holds keying material
      in a key hierarchy must not share that keying material with
      parties that are associated with other branches in the key
      hierarchy.

      Group keys are an obvious exception.  Since all members of the
      group have a copy of the same key, compromise of any one of the
      group members will result in the disclosure of the group key.

   Some of the implications of the requirement are as follows:

   Key Sharing
        In order to be able to determine whether keying material has
        been shared, it is necessary for the identity of the EAP
        authenticator (NAS-Identifier) to be defined and understood by
        all parties that communicate with it.  EAP lower-layer
        specifications such as [IEEE-802.11], [IEEE-802.16e],
        [IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve
        key sharing.

   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 the backend
        authentication server, or even to impersonate a backend
        authentication server to other AAA clients.

   Compromise of Long-Term Credentials
        An attacker obtaining keying material (such as TSKs, TEKs, or
        the MSK) MUST NOT be able to obtain long-term user credentials
        such as pre-shared keys, passwords, or private-keys without
        breaking a fundamental cryptographic assumption.  The mandatory
        requirements of [RFC4017] Section 2.2 include generation of EAP
        keying material, capability to generate EAP keying material with
        128 bits of effective strength, resistance to dictionary
        attacks, shared state equivalence, and protection against
        man-in-the-middle attacks.

5.2.  Cryptographic Negotiation

   Mandatory requirements from [RFC4962] Section 3:

      Cryptographic algorithm independent

      The AAA key management protocol MUST be cryptographic algorithm
      independent.  However, an EAP method MAY depend on a specific
      cryptographic algorithm.  The ability to negotiate the use of a
      particular cryptographic algorithm provides resilience against
      compromise of a particular cryptographic algorithm.  Algorithm
      independence is also REQUIRED with a Secure Association Protocol
      if one is defined.  This is usually accomplished by including an
      algorithm identifier and parameters in the protocol, and by
      specifying the algorithm requirements in the protocol
      specification.  While highly desirable, the ability to negotiate
      key derivation functions (KDFs) is not required.  For
      interoperability, at least one suite of mandatory-to-implement
      algorithms MUST be selected.  Note that without protection by
      IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does
      not meet this requirement, since the integrity protection
      algorithm cannot be negotiated.

      This requirement does not mean that a protocol must support both
      public-key and symmetric-key cryptographic algorithms.  It means
      that the protocol needs to be structured in such a way that
      multiple public-key algorithms can be used whenever a public-key
      algorithm is employed.  Likewise, it means that the protocol needs
      to be structured in such a way that multiple symmetric-key
      algorithms can be used whenever a symmetric-key algorithm is
      employed.

      Confirm ciphersuite selection

      The selection of the "best" ciphersuite SHOULD be securely
      confirmed.  The mechanism SHOULD detect attempted roll-back
      attacks.

   EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements
   and AAA protocols utilizing transmission-layer security are capable
   of addressing downgrade attacks.  [RFC3748] Section 7.2.1 describes
   the "protected ciphersuite negotiation" security claim that refers to
   the ability of an EAP method to negotiate the ciphersuite used to
   protect the EAP method conversation, as well as to integrity protect
   the ciphersuite negotiation.  [RFC4017] Section 2.2 requires EAP
   methods satisfying this security claim.  Since TLS v1.2 [RFC5246] and
   IKEv2 [RFC4306] support negotiation of Key Derivation Functions
   (KDFs), EAP methods based on TLS or IKEv2 will, if properly designed,

   inherit this capability.  However, negotiation of KDFs is not
   required by RFC 4962 [RFC4962], and EAP methods based on neither TLS
   nor IKEv2 typically do not support KDF negotiation.

   When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for
   transmission layer security, they can leverage the cryptographic
   algorithm negotiation support provided by IKEv2 [RFC4306] or TLS
   [RFC5246].  RADIUS [RFC3579] by itself does not support cryptographic
   algorithm negotiation and relies on MD5 for integrity protection,
   authentication, and confidentiality.  Given the known weaknesses in
   MD5 [MD5Collision], this is undesirable, and can be addressed via use
   of RADIUS over IPsec, as described in [RFC3579] Section 4.2.

   To ensure against downgrade attacks within lower-layer protocols,
   algorithm independence is REQUIRED with lower layers using EAP for
   key derivation.  For interoperability, at least one suite of
   mandatory-to-implement algorithms MUST be selected.  Lower-layer
   protocols supporting EAP for key derivation SHOULD also support
   secure ciphersuite negotiation as well as KDF negotiation.

   As described in [RFC1968], PPP ECP does not support secure
   ciphersuite negotiation.  While [IEEE-802.16e] and [IEEE-802.11]
   support ciphersuite negotiation for protection of data, they do not
   support negotiation of the cryptographic primitives used within the
   Secure Association Protocol, such as message integrity checks (MICs)
   and KDFs.

5.3.  Confidentiality and Authentication

   Mandatory requirements from [RFC4962] Section 3:

      Authenticate all parties

      Each party in the AAA key management protocol MUST be
      authenticated to the other parties with whom they communicate.
      Authentication mechanisms MUST maintain the confidentiality of any
      secret values used in the authentication process.  When a secure
      association protocol is used to establish session keys, the
      parties involved in the secure association protocol MUST identify
      themselves using identities that are meaningful in the lower-layer
      protocol environment that will employ the session keys.  In this
      situation, the authenticator and peer may be known by different
      identifiers in the AAA protocol environment and the lower-layer
      protocol environment, making authorization decisions difficult
      without a clear key scope.  If the lower-layer identifier of the

      peer will be used to make authorization decisions, then the pair
      of identifiers associated with the peer MUST be authorized by the
      authenticator and/or the AAA server.

      AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588],
      provide a mechanism for the identification of AAA clients; since
      the EAP authenticator and AAA client are always co-resident, this
      mechanism is applicable to the identification of EAP
      authenticators.

      When multiple base stations and a "controller" (such as a WLAN
      switch) comprise a single EAP authenticator, the "base station
      identity" is not relevant; the EAP method conversation takes place
      between the EAP peer and the EAP server.  Also, many base stations
      can share the same authenticator identity.  The authenticator
      identity is important in the AAA protocol exchange and the secure
      association protocol conversation.

      Authentication mechanisms MUST NOT employ plaintext passwords.
      Passwords may be used provided that they are not sent to another
      party without confidentiality protection.

      Keying material confidentiality and integrity

      While preserving algorithm independence, confidentiality and
      integrity of all keying material MUST be maintained.

   Conformance to these requirements is analyzed in the sections that
   follow.

5.3.1.  Spoofing

   Per-packet authentication and integrity protection provides
   protection against spoofing attacks.

   Diameter [RFC3588] provides support for per-packet authentication and
   integrity protection via use of IPsec or TLS.  RADIUS/EAP [RFC3579]
   provides for per-packet authentication and integrity protection via
   use of the Message-Authenticator Attribute.

   [RFC3748] Section 7.2.1 describes the "integrity protection" security
   claim and [RFC4017] Section 2.2 requires EAP methods supporting this
   claim.

   In order to prevent forgery of Secure Association Protocol frames,
   per-frame authentication and integrity protection is RECOMMENDED on
   all messages.  IKEv2 [RFC4306] supports per-frame integrity

   protection and authentication, as does the Secure Association
   Protocol defined in [IEEE-802.16e].  [IEEE-802.11] supports per-frame
   integrity protection and authentication on all messages within the
   4-way handshake except the first message.  An attack leveraging this
   omission is described in [Analysis].

5.3.2.  Impersonation

   Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are
   potentially vulnerable to a rogue authenticator impersonating another
   authenticator.  While both protocols support mutual authentication
   between the AAA client/authenticator and the backend authentication
   server, the security mechanisms vary.

   In RADIUS, the shared secret used for authentication is determined by
   the source address of the RADIUS packet.  However, when RADIUS
   Access-Requests are forwarded by a proxy, the NAS-IP-Address,
   NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS
   server will not correspond to the source address.  As noted in
   [RFC3579] Section 4.3.7, if the first-hop proxy does not check the
   NAS identification attributes against the source address in the
   Access-Request packet, it is possible for a rogue authenticator to
   forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or
   NAS-Identifier [RFC2865] attributes in order to impersonate another
   authenticator; attributes such as the Called-Station-Id [RFC2865] and
   Calling-Station-Id [RFC2865] can be forged as well.  Among other
   things, this can result in messages (and transported keying material)
   being sent to the wrong authenticator.

   While [RFC3588] requires use of the Route-Record AVP, this utilizes
   Fully Qualified Domain Names (FQDNs), so that impersonation detection
   requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly
   configured.  As a result, Diameter is as vulnerable to this attack as
   RADIUS, if not more so.  [RFC3579] Section 4.3.7 recommends
   mechanisms for impersonation detection; to prevent access to keying
   material by proxies without a "need to know", it is necessary to
   allow the backend authentication server to communicate with the
   authenticator directly, such as via the redirect functionality
   supported in [RFC3588].

5.3.3.  Channel Binding

   It is possible for a compromised or poorly implemented EAP
   authenticator to communicate incorrect information to the EAP peer
   and/or server.  This can enable an authenticator to impersonate
   another authenticator or communicate incorrect information via
   out-of-band mechanisms (such as via AAA or the lower layer).

   Where EAP is used in pass-through mode, the EAP peer does not verify
   the identity of the pass-through authenticator within the EAP
   conversation.  Within the Secure Association Protocol, the EAP peer
   and authenticator only demonstrate mutual possession of the
   transported keying material; they do not mutually authenticate.  This
   creates a potential security vulnerability, described in [RFC3748]
   Section 7.15.

   As described in [RFC3579] Section 4.3.7, it is possible for a
   first-hop AAA proxy to detect a AAA client attempting to impersonate
   another authenticator.  However, it is possible for a pass-through
   authenticator acting as a AAA client to provide correct information
   to the backend authentication server while communicating misleading
   information to the EAP peer via the lower layer.

   For example, a compromised authenticator can utilize another
   authenticator's Called-Station-Id or NAS-Identifier in communicating
   with the EAP peer via the lower layer.  Also, a pass-through
   authenticator acting as a AAA client can provide an incorrect peer
   Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication
   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 is possible to match the channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  Typically, the EAP
   method imports channel binding parameters from the lower layer on the
   peer, and transmits them securely to the EAP server, which exports
   them to the lower layer or AAA layer.  However, transport can occur
   from EAP server to peer, or can be bi-directional.  On the side of
   the exchange (peer or server) where channel binding is verified, the
   lower layer or AAA layer passes the result of the verification (TRUE
   or FALSE) up to the EAP method.  While the verification can be done
   either by the peer or the server, typically only the server has the
   knowledge to determine the correctness of the values, as opposed to
   merely verifying their equality.  For further discussion, see
   [EAP-SERVICE].

   It is also possible to perform channel binding without transporting
   data over EAP, as described in [EAP-CHANNEL].  In this approach the
   EAP method includes channel binding parameters in the calculation of
   exported EAP keying material, making it impossible for the peer and

   authenticator to complete the Secure Association Protocol if there is
   a mismatch in the channel binding parameters.  However, this approach
   can only be applied where methods generating EAP keying material are
   used along with lower layers that utilize EAP keying material.  For
   example, this mechanism would not enable verification of channel
   binding on wired IEEE 802 networks using [IEEE-802.1X].

5.3.4.  Mutual Authentication

   [RFC3748] Section 7.2.1 describes the "mutual authentication" and
   "dictionary attack resistance" claims, and [RFC4017] requires EAP
   methods satisfying these claims.  EAP methods complying with
   [RFC4017] therefore provide for mutual authentication between the EAP
   peer and server.

   [RFC3748] Section 7.2.1 also describes the "Cryptographic binding"
   security claim, and [RFC4017] Section 2.2 requires support for this
   claim.  As described in [EAP-BINDING], EAP method sequences and
   compound authentication mechanisms can be subject to
   man-in-the-middle attacks.  When such attacks are successfully
   carried out, the attacker acts as an intermediary between a victim
   and a legitimate authenticator.  This allows the attacker to
   authenticate successfully to the authenticator, as well as to obtain
   access to the network.

   In order to prevent these attacks, [EAP-BINDING] recommends
   derivation of a compound key by which the EAP peer and server can
   prove that they have participated in the entire EAP exchange.  Since
   the compound key MUST NOT be known to an attacker posing as an
   authenticator, and yet must be derived from EAP keying material, it
   MAY be desirable to derive the compound key from a portion of the
   EMSK.  Where this is done, in order to provide proper key hygiene, it
   is RECOMMENDED that the compound key used for man-in-the-middle
   protection be cryptographically separate from other keys derived from
   the EMSK.

   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 authenticator/AAA client and backend authentication server
   communicate directly and credible key wrap is used (see Section 3.8),
   this ensures that the AAA Key Transport (phase 1b) achieves its
   security objectives: mutually authenticating the AAA
   client/authenticator and backend authentication server and providing
   transported keying material to the EAP authenticator and to no other
   party.

   [RFC2607] Section 7 describes the security issues occurring when the
   authenticator/AAA client and backend authentication server do not
   communicate directly.  Where a AAA intermediary is present (such as a
   RADIUS proxy or a Diameter agent), and data object security is not
   used, transported keying material can be recovered by an attacker in
   control of the intermediary.  As discussed in Section 2.1, unless the
   TSKs are derived independently from EAP keying material (as in
   IKEv2), possession of transported keying material enables decryption
   of data traffic sent between the peer and the authenticator to whom
   the keying material was transported.  It also allows the AAA
   intermediary to impersonate the authenticator or the peer.  Since the
   peer does not authenticate to a AAA intermediary, it has no ability
   to determine whether it is authentic or authorized to obtain keying
   material.

   However, as long as transported keying material or keys derived from
   it are only utilized by a single authenticator, compromise of the
   transported keying material does not enable an attacker to
   impersonate the peer to another authenticator.  Vulnerability to
   compromise of a AAA intermediary can be mitigated by implementation
   of redirect functionality, as described in [RFC3588] and [RFC4072].

   The Secure Association Protocol does not provide for mutual
   authentication between the EAP peer and authenticator, only mutual
   proof of possession of transported keying material.  In order for the
   peer to verify the identity of the authenticator, mutual proof of
   possession needs to be combined with impersonation prevention and
   channel binding.  Impersonation prevention (described in Section
   5.3.2) enables the backend authentication server to determine that
   the transported keying material has been provided to the correct
   authenticator.  When utilized along with impersonation prevention,
   channel binding (described in Section 5.3.3) enables the EAP peer to
   verify that the EAP server has authorized the authenticator to
   possess the transported keying material.  Completion of the Secure
   Association Protocol exchange demonstrates that the EAP peer and the
   authenticator possess the transported keying material.

5.4.  Key Binding

   Mandatory requirement from [RFC4962] Section 3:

      Bind key to its context

      Keying material MUST be bound to the appropriate context.  The
      context includes the following:

      o  The manner in which the keying material is expected to be used.

      o  The other parties that are expected to have access to the
         keying material.

      o  The expected lifetime of the keying material.  Lifetime of a
         child key SHOULD NOT be greater than the lifetime of its parent
         in the key hierarchy.

      Any party with legitimate access to keying material can determine
      its context.  In addition, the protocol MUST ensure that all
      parties with legitimate access to keying material have the same
      context for the keying material.  This requires that the parties
      are properly identified and authenticated, so that all of the
      parties that have access to the keying material can be determined.

      The context will include the peer and NAS identities in more than
      one form.  One (or more) name form is needed to identify these
      parties in the authentication exchange and the AAA protocol.
      Another name form may be needed to identify these parties within
      the lower layer that will employ the session key.

   Within EAP, exported keying material (MSK, EMSK,IV) is bound to the
   Peer-Id(s) and Server-Id(s), which are exported along with the keying
   material.  However, not all EAP methods support authenticated server
   identities (see Appendix A).

   Within the AAA protocol, transported keying material is destined for
   the EAP authenticator identified by the NAS-Identifier Attribute
   within the request, and is for use by the EAP peer identified by the
   Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI)
   [RFC4372] attributes.  The maximum lifetime of the transported keying
   material can be provided, as discussed in Section 3.5.1.  Key usage
   restrictions can also be included as described in Section 3.2.  Key
   lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.