Subject: Re: [eap] Issue 392: Authorization Issues

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 05 Feb 2007 14:08:40 -0800

Thanks for catching this.

>Keying material MUST be bound to the appropriate context.
>
>MCV>>In general the binding of some strong requirement word like "MUST" to 
>a vague word >like "appropriate" is a red flag for me, as it allows for 
>attorney-like type of argument.. Perhaps this >is not an issue if the 
>"appropriate context" was clearly defined elsewhere (I did not see that).

I believe that the sentence above came out of an earlier version of 
"Guidelines for AAA Key Management", although it is not identified as such.  
On looking through the -06 version, the requirement has been expanded upon 
and clarified.

This brings up two questions.  The first is whether the requirements should 
be explicitly identified.  This came up in RFC 4017, and to delineate 
requirements that needed to be satisfied, the term "Requirement:" was put in 
front of them.   I believe this would be a good idea for this document as 
well.

The second issue is synchronization of requirements between the "Guidelines 
for AAA Key Management" document and this document.   To ensure this, I will 
need to go back over the requirements in Section 3 of the "Guidelines" 
document to make sure that all requirements are discussed in Section 5, and 
that the requirements text in both documents are aligned.   After I have 
done this, I'll post the revised text for Section 5.

>The Secure Association Protocol (phase 2) conversation may utilize
>different identifiers from the EAP conversation (phase 1a), so that
>binding between the EAP and Secure Association Protocol identities is
>REQUIRED.
>MCV>> "may utilize" --> MAY utlilize?? If so, then it's strange that a 
>REQUIREDis tied to a MAY.

This sentence also came out of the requirements in the "Guidelines" 
document; in looking through -06 it appears that this requirement has also 
had some text changes.
----------------------------

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Feb 2007 00:18:13 -0800

OK.  I've gone through the -06 "Guidelines" document and attempted to sync 
up the requirements with those in this document.  In some cases, the 
"Guidelines" requirements text has changed significantly from earlier drafts 
(e.g. the context binding text is much more explicit).

In doing the sync, I noticed that Section 5 did not include a section on Key 
Naming, so I added a small section on that.   Since the purpose of Section 5 
was to describe how the requirements are met, each second-level section now 
includes a Requirements statement, and all the requirements of the 
"Guidelines" document Section 3 are now included.

Find below an updated Section 5.  Hopefully this re-organization more 
clearly delineates the requirements and their relationship to the 
explanatory text.

------------------------------------------------------------------------------------------------------------------------------------
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 may 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 may 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 may attempt a downgrade attack in order to exploit
     known weaknesses in an authentication method or cryptographic
     algorithm.

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

(d)  An attacker may 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 may alter, forge or replay packets.

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

Aboba, et al.                Standards Track                   [Page 43]

INTERNET-DRAFT        EAP Key Management Framework       6 February 2007

     provide stale keying material to an authenticator, or a poorly
     implemented authenticator may reuse nonces.

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

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

(i)  An attacker may compromise an EAP authenticator in an effort to
     commit fraud.  For example, a compromised authenticator may provide
     incorrect information to the EAP peer and/or server via out-of-band
     mechanisms (such as via a AAA or lower layer protocol).  This
     includes impersonating another authenticator, or providing
     inconsistent information to the peer and EAP server.

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

   In order to address these threats, [I-D.housley-aaa-key-mgmt] Section
   3 provides a description of mandatory system security properties.
   These requirements are discussed in the sections that follow.

5.1.  Peer and Authenticator Compromise

   Requirement: In the event that an authenticator is compromised or
   stolen, an attacker may gain access to the network through that
   authenticator, or may obtain the credentials required for the
   authenticator/AAA client to communicate with one or more backend
   authentication servers.  Compromise of a single authenticator MUST
   NOT compromise keying material held by any other authenticator within
   the system, and SHOULD NOT allow the attacker to compromise the
   backend authentication server or obtain long-term user credentials.
   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.  In the context of a key hierarchy, 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 these
   requirements; 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.

   Some of the implications of the requirement are as follows:

No Key Sharing
     An EAP authenticator MUST NOT share any keying material with
     another EAP authenticator, since if one EAP authenticator were
     compromised, this would enable the compromise of keying material on
     another authenticator.  In order to be able to determine whether
     keying material has been shared, it is necessary for the identity
     of the EAP authenticator to be defined and understood by all
     parties that communicate with it.  Similarly, an EAP peer MUST NOT
     share any keying material with another EAP peer.

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

No Compromise of Long-Term Credentials
     An attacker obtaining TSKs, TEKs or EAP keying material such as 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.

5.2.  Cryptographic Negotiation

   Requirement: The ability to negotiate cryptographic algorithms
   resilience against compromise of a particular algorithm.  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.  The selection of the "best"
   cryptographic algorithm SHOULD be securely confirmed.  The mechanism
   SHOULD detect attempted roll back attacks.

   EAP methods satisfying [RFC4017] 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] requires EAP methods satisfying this security
   claim.  However, EAP methods may not enable the negotiation of all
   cryptographic algorithms, such as Key Distribution Functions (KDFs).

   Diameter [RFC3588] provides support for cryptographic algorithm
   negotiation via use of IPsec [RFC4301] or TLS [RFC4346].  RADIUS
   [RFC3579] does not support the negotiation of cryptographic
   algorithms, and relies on MD5 for integrity protection,
   authentication and confidentiality, despite known weaknesses in the
   algorithm [MD5Collision].  This issue can be addressed via use of
   RADIUS over IPsec, as described in [RFC3579] Section 4.2.  However,
   TLS and IKEv2 currently do not enable negotiation of the Key
   Distribution Function (KDF).

   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 algorithm MUST be selected.  Lower layer
   protocols supporting EAP for key derivation SHOULD also support
   secure ciphersuite negotiation.  As described in [RFC1968], PPP ECP
   does not provide support for secure ciphersuite negotiation.  While
   [IEEE-802.16e] and [IEEE-802.11i] support selection of ciphersuites
   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

   Requirement: Each party in the EAP, AAA and Secure Association
   Protocol conversations 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.
   While preserving algorithm independence, confidentiality and
   integrity of all keying material MUST be maintained.

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] requires use of 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 [IEEE-802.16e].
   [IEEE-802.11i] 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 the RADIUS [RFC2865] and Diameter [RFC3588] protocols 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.  As noted in [RFC3579]
   Section 4.3.7, it is highly desirable that the source address be
   checked against one or more Network Access Server (NAS) client
   identification attributes so as to detect and prevent impersonation
   attacks.

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

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

   This implies that it is possible for a rogue authenticator to forge
   NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
   a RADIUS Access-Request in order to impersonate another
   authenticator.  Among other things, this can result in messages (and
   transported keying material) being sent to the wrong authenticator.
   Since the rogue authenticator is authenticated by the RADIUS proxy or
   server purely based on the source address, other mechanisms are
   required to detect the forgery.  In addition, it is possible for
   attributes such as the Called-Station-Id and Calling-Station-Id to be
   forged as well.

   [RFC3579] Section 4.3.7 describes how an EAP pass-through
   authenticator acting as a AAA client can be detected if it attempts
   to impersonate another authenticator (such by sending incorrect

   Called-Station-Id [RFC2865], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA
   protocol).  This vulnerability can be mitigated by having RADIUS
   proxies check NAS identification attributes against the source
   address.

   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.  To address this vulnerability, 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 may 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 EAP keying material; they do not mutually authenticate.
   This creates a potential security vulnerability, described in
   [RFC3748] Section 7.15.

   As described in the previous section, it is possible for a AAA proxy
   to detect a AAA client attempting to impersonate another
   authenticator (such by sending incorrect Called-Station-Id [RFC2865],
   NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-
   IPv6-Address [RFC3162] attributes via the AAA protocol).  However, it
   is 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 may occur
   from EAP server to peer, or may 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 [I-
   D.arkko-eap-service-identity-auth].

   It is also possible to perform Channel Binding without transporting
   data over EAP.  For example, see [I-D.draft-ohba-eap-channel-
   binding].  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 EAP
   methods generating key material are used along with lower layers that
   utilize the 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] requires support for this claim.  As
   described in [I-D.puthenkulam-eap-binding], EAP method sequences and
   compound authentication mechanisms may be subject to man-in-the-
   middle attacks.  When such attacks are successfully carried out, the
   attacker acts as an intermediary between a victim and a legitimate
   authenticator.  This allows the attacker to authenticate successfully
   to the authenticator, as well as to obtain access to the network.

   In order to prevent these attacks, [I-D.puthenkulam-eap-binding]
   recommends derivation of a compound key by which the EAP peer and
   server can prove that they have participated in the entire EAP
   exchange.  Since the compound key must not be known to an attacker
   posing as an authenticator, and yet must be derived from quantities
   that are exported by EAP methods, it may be desirable to derive the
   compound key from a portion of the EMSK.  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 keywrap 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
   EAP 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 may 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 EAP 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 EAP 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 EAP 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 EAP keying material.  Completion of the
   Secure Association Protocol exchange demonstrates that the EAP peer
   and the authenticator possess the transported EAP keying material.

5.4.  Key Binding

   Requirement: Keying material MUST be bound to the appropriate
   context.  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 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 maximum lifetime of the keying material.  The maximum
      lifetime of a child key SHOULD NOT be greater than the maximum
      lifetime of its parent in the key hierarchy.

   Within EAP, keying material (MSK, EMSK) is bound to the Peer-Id and
   Server-Id 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, User-Name [RFC2865] or Chargeable User Identity (CUI)
   [RFC4372] attributes.  The maximum lifetime of the transported keying
   material may be provided, as discussed in Section 3.5.1.  Key usage
   restrictions may also be included as described in Section 3.2.  Key
   lifetime issues are discussed in Sections 3.3, 3.4 and 3.5.

5.5.  Authorization

   Requirement: Peer and authenticator authorization MUST be performed.
   These entities MUST demonstrate possession of the appropriate keying
   material, without disclosing it.  Authorization is REQUIRED whenever
   a peer associates with a new authenticator.  The authorization
   checking prevents an elevation of privilege attack, and it ensures
   that an unauthorized authenticator is detected.  Authorizations
   SHOULD be synchronized between the EAP peer, server, and
   authenticator.  Once all protocol exchanges are complete, all of
   these parties should hold a common view of the authorizations
   associated the other parties.  The Secure Association Protocol (phase
   2) conversation may utilize different identifiers from the EAP
   conversation (phase 1a), so that binding between the EAP and Secure
   Association Protocol identities is REQUIRED.

   As described in Section 2.2.1, consistent identification of the EAP
   authenticator enables the EAP peer to determine whether EAP keying
   material has been shared between EAP authenticators as well as to
   confirm with the backend authentication server that an EAP
   authenticator proving possession of EAP keying material during the
   Secure Association Protocol was authorized to obtain it.

   Within the AAA protocol, the authorization attributes are bound to
   the transported keying material.  While the AAA exchange provides the
   AAA client/authenticator with authorizations relating to the EAP
   peer, neither the EAP nor AAA exchanges provides authorizations to
   the EAP peer.  In order to ensure that all parties hold the same view
   of the authorizations it is RECOMMENDED that the Secure Association
   Protocol enable communication of authorizations between the EAP
   authenticator and peer.

   In lower layers where the authenticator consistently identifies
   itself to the peer and backend authentication server and the EAP peer
   completes the Secure Association Protocol exchange with the same
   authenticator through which it completed the EAP conversation,
   authorization of the authenticator is demonstrated to the peer by
   mutual authentication between the peer and authenticator as discussed
   in the previous section.  Identification issues are discussed in
   Section 2.2 and key scope issues are discussed in Section 3.2.

   Where the EAP peer utilizes different identifiers within the EAP
   method and Secure Association Protocol conversations, peer
   authorization may be difficult to demonstrate to the authenticator
   without additional restrictions.  This problem does not exist in
   IKEv2 where the Identity Payload is used for peer identification both
   within IKEv2 and EAP, and where the EAP conversation is
   cryptographically protected within IKEv2 packets, binding the EAP and

   Secure Association Protocol/IKEv2 exchanges.  However within
   [IEEE-802.11i] the EAP peer identity is not used within the 4-way
   handshake, so that it is necessary for the authenticator to require
   that the EAP peer utilize the same MAC address for EAP authentication
   as for the 4-way handshake.

5.6.  Replay Protection

   Requirement: Exchanges MUST be replay protected, including AAA, EAP
   and Secure Association Protocol exchanges.  Replay protection allows
   a protocol message recipient to discard any message that was recorded
   during a previous legitimate dialogue and presented as though it
   belonged to the current dialogue.

   [RFC3748] Section 7.2.1 describes the "replay protection" security
   claim and [RFC4017] requires use of EAP methods supporting this
   claim.

   Diameter [RFC3588] provides support for replay protection via use of
   IPsec or TLS.  RADIUS/EAP [RFC3579] protects against replay of keying
   material via the Request Authenticator.  However, some RADIUS packets
   are not replay protected.  In Accounting, Disconnect and CoA-Request
   packets the Request Authenticator contains a keyed MAC rather than a
   Nonce.  The Response Authenticator in Accounting, Disconnect and CoA
   Response packets also contains a keyed MAC whose calculation does not
   depend on a Nonce in either the Request or Response packets.
   Therefore unless an Event-Timestamp attribute is included or IPsec is
   used, the recipient may not be able to determine whether these
   packets have been replayed.

   In order to prevent replay of Secure Association Protocol frames,
   replay protection is REQUIRED on all messages.  [IEEE-802.11i]
   supports replay protection on all messages within the 4-way
   handshake; IKEv2 [RFC4306] also supports this.

5.7.  Key Freshness

   Requirement: While preserving algorithm independence, session keys
   MUST be strong and fresh.  A session key SHOULD be considered
   compromised if it remains in use beyond its authorized lifetime.
   Each session deserves an independent session key; disclosure of one
   session key MUST NOT aid the attacker in discovering any other
   session keys.  Fresh keys are required even when a long replay
   counter (that is, one that "will never wrap") is used to ensure that
   loss of state does not cause the same counter value to be used more
   than once with the same session key.  A fresh cryptographic key is
   one that is generated specifically for the intended use.  In this
   situation, a secure association protocol is used to establish session
   keys.  The AAA protocol and EAP method MUST ensure that the keying
   material supplied as an input to session key derivation is fresh, and
   the secure association protocol MUST generate a separate session key
   for each session, even if the keying material provided by EAP is
   cached.

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

EAP  EAP methods need to ensure the freshness and strength of EAP keying
     material provided as an input to session key derivation.  [RFC3748]
     Section 7.10 states that "EAP methods SHOULD ensure the freshness
     of the MSK and EMSK, even in cases where one party may not have a
     high quality random number generator.  A RECOMMENDED method is for
     each party to provide a nonce of at least 128 bits, used in the
     derivation of the MSK and EMSK."  The contribution of nonces
     enables the EAP peer and server to ensure that exported EAP keying
     material is fresh.

     [RFC3748] Section 7.2.1 describes the "key strength" and "session
     independence" security claims, and and [RFC4017] requires EAP
     methods supporting these claims as well as methods capable of
     providing equivalent key strength of 128 bits or greater.  See
     Section 3.7 for more information on key strength.

AAA  The AAA protocol needs to ensure that transported keying material
     is fresh and is not utilized outside its recommended lifetime.
     Replay protection is necessary for key freshness, but an attacker
     can deliver a stale (and therefore potentially compromised) key in
     a replay-protected message, so replay protection is not sufficient.
     As discussed in Section 3.5, the Session-Timeout attribute enables
     the backend authentication server to limit the exposure of
     transported EAP keying material.

     The EAP Session-Id, described in Section 1.4, enables the EAP peer,
     authenticator and server to distinguish EAP conversations.
     However, unless the authenticator keeps track of EAP Session-Ids,
     the authenticator cannot use the Session-Id to guarantee the
     freshness of EAP keying material.

Lower Layer
     The Secure Association Protocol, described in Section 3.1, MUST
     generate a fresh session key for each session, even if the keying
     material and parameters provided by EAP methods are cached, or
     either the peer or authenticator lack a high entropy random number
     generator. A RECOMMENDED method is for the peer and authenticator
     to each provide a nonce or counter used in session key derivation.
     If a nonce is used, it is RECOMMENDED that it be at least 128 bits.

     While [IEEE-802.11i] and IKEv2 [RFC4306] satisfy this requirement,
     [IEEE-802.16e] does not, since randomness is only contributed from
     the Base Station.

5.8.  Key Scope Limitation

   Requirement: Following the principle of least privilege, parties MUST
   NOT have access to keying material that is not needed to perform
   their role.  A party has access to a particular key if it has access
   to all of the secret information needed to derive it.  Any protocol
   that is used to establish session keys, MUST specify the scope for
   session keys, clearly identifying the parties to whom the session key
   is available.

   Transported EAP keying material is permitted to be accessed by the
   EAP peer, authenticator and server.  The EAP peer and server derive
   EAP keying material during the process of mutually authenticating
   each other using the selected EAP method.  During the Secure
   Association Protocol exchange, the EAP peer utilizes derived EAP
   keying material to demonstrate to the authenticator that it is the
   same party that authenticated to the EAP server and was authorized by
   it.  The EAP authenticator utilizes the transported EAP keying
   material to prove to the peer not only that the EAP conversation was
   transported through it (this could be demonstrated by a man-in-the-
   middle), but that it was uniquely authorized by the EAP server to
   provide the peer with access to the network.  Unique authorization
   can only be demonstrated if the EAP authenticator does not share the
   transported keying material with a party other than the EAP peer and
   server.

   TSKs are permitted to be accessed only by the EAP peer and
   authenticator (see Section 1.5); TSK derivation is discussed in
   Section 2.1.  Since demonstration of authorization within the Secure
   Association Protocol exchange depends on possession of transported
   EAP keying material, the backend authentication server can
   impersonate the authenticator and possibly to obtain the TSKs unless
   the backend server deletes the transported EAP keying material after
   sending it.

5.9.  Key Naming

   Requirement: A robust key naming scheme is REQUIRED, particularly
   where key caching is supported.  The key name provides a way to refer
   to a key in a protocol so that it is clear to all parties which key
   is being referenced.  Objects that cannot be named cannot be managed.
   All keys MUST be uniquely named, and the key name MUST NOT directly
   or indirectly disclose the keying material.  If the key name is not
   based on the keying material, then one can be sure that it cannot be
   used to assist in a search for the key value.

   EAP key names (defined in Section 1.4.1), along with the Peer-Id and
   Server-Id, uniquely identify EAP keying material, and do not directly
   or indirectly expose the keying material.

   Existing AAA server implementations do not distribute key names along
   with the transported EAP keying material, although Diameter EAP
   [RFC4072], provides the EAP-Key-Name AVP for this purpose.  Since the
   EAP-Key-Name AVP is defined within the RADIUS attribute space, it may
   be used either with RADIUS or Diameter.

   Since the authenticator is not provided with the name of the
   transported keying material by existing backend authentication server
   implementations, existing Secure Association Protocols do not utilize
   EAP key names.  For example, [IEEE-802.11i] supports PMK caching; to
   enable the peer and authenticator to determine the cached PMK to
   utilize within the 4-way handshake the PMK needs to be named.  For
   this purpose [IEEE-802.11i] utilizes a PMK naming scheme which is
   based on the key.  Since IKEv2 [RFC4306] does not cache transported
   EAP keying material, it does not need to refer to transported keying
   material.

5.10.  Denial of Service Attacks

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

   To address this vulnerability, EAP methods creating persistent state
   may wish to limit the persistent state created by an EAP peer.  For
   example, for each peer an EAP server may choose to limit persistent
   state to a few EAP conversations, distinguished by the EAP Session-
   Id.  This prevents a rogue peer from denying access to other peers.

   Similarly, to conserve resources an authenticator may choose to limit
   the persistent state corresponding to each peer.  This can be
   accomplished by limiting each peer to persistent state corresponding
   to a few EAP conversations, distinguished by the EAP Session-Id.

   Depending on the media, creation of new TSKs may or may not imply
   deletion of previously derived TSKs.  Where there is no implied
   deletion, the authenticator may choose to limit the number of TSKs
   and associated state that can be stored for each peer.