Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5247

Extensible Authentication Protocol (EAP) Key Management Framework

Pages: 79
Proposed Standard
Errata
Updates:  3748
Updated by:  8940
Part 3 of 4 – Pages 41 to 60
First   Prev   Next

Top   ToC   RFC5247 - Page 41   prevText

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].
Top   ToC   RFC5247 - Page 42
   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.
Top   ToC   RFC5247 - Page 43
   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.
Top   ToC   RFC5247 - Page 44
   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
Top   ToC   RFC5247 - Page 45
   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.
Top   ToC   RFC5247 - Page 46

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:
Top   ToC   RFC5247 - Page 47
   (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.
Top   ToC   RFC5247 - Page 48
   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
Top   ToC   RFC5247 - Page 49
   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).
Top   ToC   RFC5247 - Page 50
   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.
Top   ToC   RFC5247 - Page 51
   (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
Top   ToC   RFC5247 - Page 52
      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.
Top   ToC   RFC5247 - Page 53

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,
Top   ToC   RFC5247 - Page 54
   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
Top   ToC   RFC5247 - Page 55
      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
Top   ToC   RFC5247 - Page 56
   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).
Top   ToC   RFC5247 - Page 57
   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
Top   ToC   RFC5247 - Page 58
   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.
Top   ToC   RFC5247 - Page 59
   [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.
Top   ToC   RFC5247 - Page 60
      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.



(page 60 continued on part 4)

Next Section