Subject: [eap] Resolution: Rewrite of Security Considerations Section

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 24 Oct 2005 00:07:38 -0700

Here is the proposed rewrite of the Security Considerations Section,  
addressing Issues 279, 294 and 302.

-------------------------------------------------------------------------------------------
5.  Security Considerations

   In order to analyze whether the EAP conversation achieves it security
   goals, it is first necessary to state those goals as well as the
   underlying security assumptions.

   The overall goal of the EAP conversation is to derive fresh session
   keys between the EAP peer and authenticator that are known only to
   those parties, and for both the EAP peer and authenticator to
   demonstrate that they are authorized to perform their roles either by
   each other or by a trusted third party (the AAA server).

   The principals of the authentication phase are the EAP peer and
   server.  Completion of an EAP method exchange supporting key
   derivation results in the derivation of EAP keying material (MSK,
   EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
   and server (identified by the Server-ID).  Both the EAP peer and EAP
   server know the exported keying material to be fresh.

   The principals of the AAA Key transport exchange are the EAP
   authenticator and the EAP server.  Completion of the AAA exchange
   results in the transport of EAP keying material from the EAP server
   (identified by the Server-ID) to the EAP authenticator (identified by
   the NAS-Identifier) without disclosure to any other party.  Both the
   EAP server and EAP authenticator know this keying material to be
   fresh.

   The principals of the Secure Association Protocol are the EAP peer
   (identified by the Peer-ID) and authenticator (identified by the NAS-
   Identifier).  Completion of the Secure Association Protocol results
   in the derivation of TSKs known only to the EAP peer and
   authenticator.  Both the EAP peer and authenticator know the TSKs to
   be fresh.

5.1.  Terminology

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

5.2.  Threat Model

   The EAP threat model is described in [RFC3748] Section 7.1.  The
   security properties of EAP methods (known as "security claims",
   described in [RFC3784] Section 7.2.1), address these threats.  EAP
   method requirements for 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 worth discussing.  These include:

[1]  An attacker may compromise or steal an EAP authenticator, in an
     attempt to gain access to other EAP authenticators or obtain long-
     term secrets.

[2]  An attacker may compromise an EAP authenticator in an effort to
     commit fraud.  For example, a 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.

[3]  An attacker may try to modify or spoof packets, including Discovery
     or Secure Association Protocol frames, EAP or AAA packets.

[4]  An attacker may attempt a downgrade attack in order to exploit
     known weaknesses in an authentication method or cryptographic
     transform.

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

[6]  An attacker may replay packets.

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

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

[8]  An authenticated attacker may attempt to obtain elevated privilege
     in order to access information that it does not have rights to.

   In order to address these threats, [Housley] provides a description
   of mandatory system security properties.  Issues relating system
   security requirements are discussed in the sections that follow.

5.3.  Authenticator Compromise

   In the event that an authenticator is compromised or stolen, an
   attacker may gain access to the network via that authenticator, or
   may obtain the credentials required for that authenticator/AAA client
   to communicate with one or more AAA servers.  However, this should
   not allow the attacker to compromise other authenticators or the AAA
   server, or obtain long-term user credentials.

   The implications of this requirement are many, but some of the more
   important are as follows:

No Key Sharing
     An EAP authenticator MUST NOT share any keying material with
     another EAP authenticator, since if 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.

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

No Compromise of Long-Term Credentials
     An attacker obtaining TSKs, TEKs or EAP 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.4.  Spoofing

   The use of 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.  [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 ommission is described
   in [Analysis].

5.5.  Downgrade Attacks

   The ability to negotiate the use of a particular cryptographic
   algorithm provides resilience against compromise of a particular
   cryptographic algorithm.  This is usually accomplished by including
   an algorithm identifier in the protocol, and by specifying the
   algorithm requirements in the protocol specification.  In order to
   prevent downgrade attacks, secure confirmation of the "best"
   ciphersuite is required.

   [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
   conversation, as well as to integrity protect the negotiation.
   [RFC4017] requires EAP methods satisfying this security claim.

   Diameter [RFC3588] provides support for cryptographic algorithm
   negotiation via use of IPsec or TLS.  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 [MD5Attack].  This issue
   can be addressed via use of RADIUS over IPsec, as described in
   [RFC3579] Section 4.2.

   As a result, EAP methods and AAA protocols are capable of addressing
   downgrade attacks.  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.
   However, [IEEE-802.11i] does support secure ciphersuite negotiation.

5.6.  Unauthorized Disclosure

   While preserving algorithm independence, confidentiality of all
   keying material MUST be maintained.  To prevent unauthorized disclose
   of keys, each party in the EAP conversation MUST be authenticated to
   the other parties with whom it communicates.  Keying material MUST be
   bound to the appropriate context.

   [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.  Binding of EAP keying material (MSK, EMSK) to the
   appropriate context is provided by the Peer-ID and Server-ID which
   are exported along with the keying material.

   Diameter [RFC3588] provides for per-packet authentication and
   integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
   provides for per-packet authentication and integrity protection.
   Where the NAS/authenticator and AAA server communicate directly and
   credible keywrap is used (see Section 3.7), this ensures that the AAA
   Key Transport phase achieves its security objectives: mutually
   authenticating the AAA client/authenticator and AAA server and
   providing EAP keying material to the EAP authenticator and to no
   other party.

   As noted in Section 3.1, the Secure Association Protocol does not by
   itself provide for mutual authentication between the EAP peer and
   authenticator, even if mutual possession of EAP keying material is
   proven.  However, where the NAS/authenticator and AAA server
   communicate directly, the AAA server can verify the correspondence
   between NAS identification attributes, the source address of packets
   sent by the NAS, and the AAA credentials.  As long as the NAS has not
   shared its AAA credentials with another NAS, this allows the AAA
   server to authenticate the NAS.  Using Channel Bindings, the EAP peer
   can then determine whether the NAS/authenticator has provided the
   same identifying information to the EAP peer and AAA server.

   Peer and authenticator authorization MUST be performed.
   Authorization is REQUIRED whenever a peer associates with a new
   authenticator.  Authorization checking prevents an elevation of
   privilege attack, and ensures that an unauthorized authenticator is
   detected.  Authorizations SHOULD be synchronized between the EAP
   peer, server, authenticator.  Once the EAP conversation exchanges are
   complete, all of these parties should hold the same view of the
   authorizations associated the other parties.  If peer authorization
   is restricted, then the peer SHOULD be made aware of the restriction.

   The AAA exchange provides the EAP authenticator with authorizations
   relating to the EAP peer.  However, 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 order to enable key binding and authorization of all parties, it
   is RECOMMENDED that the parties use a set of identities that are
   consistent between the conversation phases.  RADIUS [RFC2865] and
   Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
   identify itself by including one or more identification attributes
   within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
   IPv6-Address).

   Since the AAA server provides EAP keying material for use by the EAP
   authenticator as identified by these attributes, where an EAP
   authenticator may have multiple ports, it is RECOMMENDED for the EAP
   authenticator to identify itself using NAS identification attributes
   during the Secure Association Protocol exchange with the EAP peer.
   This enables the EAP peer to determine whether EAP keying material
   has been shared between EAP authenticators as well as to confirm with
   the AAA server that an EAP authenticator proving possession of EAP
   keying material during the Secure Association Protocol was authorized
   to obtain it.  Typically, the NAS-Identifier attribute is most
   convenient for this purpose, since a NAS/authenticator may have
   multiple IP addresses.

   Similarly, the AAA server authorizes the EAP authenticator to provide
   access to the EAP peer identified by the Peer-ID, securely verified
   during the EAP authentication exchange.  In order to determine
   whether EAP keying material has been shared between EAP peers, where
   the EAP peer has multiple ports it is RECOMMENDED for the EAP peer to
   identify itself using the Peer-ID during the Secure Association
   Protocol exchange with the EAP authenticator.

5.7.  Replay Protection

   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.

5.8.  Key Freshness

   A session key should be considered compromised if it remains in use
   too long.  As noted in [Housley], session keys MUST be strong and
   fresh, while preserving algorithm independence.  A fresh
   cryptographic key is one that is generated specifically for the
   intended use.  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.

   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 use of
     EAP methods supporting these claims as well as being capable of
     providing an equivalent key strength of 128 bits or greater.

AAA  The AAA protocol needs to ensure that transported keying material
     is fresh and is not utilized outside its recommended lifetime.
     Replay protection is necessary for key freshness, but an attacker
     can deliver a stale (and therefore potentially compromised) key in
     a replay-protected message, so replay protection is not sufficient.

     The EAP Session-ID, derived from the EAP Type and Method-ID (based
     on the nonces contributed by the peer and server) 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.

     As described in [RFC3580] Section 3.17, When sent in an Access-
     Accept along with a Termination-Action value of RADIUS-Request, the
     Session-Timeout attribute specifies the maximum number of seconds
     of service provided prior to re-authentication.  [IEEE-802.11i]
     also utilizes the Session-Timeout attribute to limit the maximum
     time that EAP keying material may be cache.  Therefore the use of
     the Session-Timeout attribute enables the AAA server to limit the
     exposure of EAP keying material.

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

5.9.  Elevation of Privilege

   Parties MUST NOT have access to keying material that is not needed to
   perform their own role.  A party has access to a particular key if it
   has access to all of the secret information needed to derive it.  If
   a post-EAP handshake is used to establish session keys, the post-EAP
   handshake MUST specify the scope for session keys.

   Transported EAP keying material is permitted to be accessed by the
   EAP peer, authenticator and server.  The EAP peer and server derive
   the transported keying material during the process of mutually
   authenticating each other using the selected EAP method.  During the
   Secure Association Protocol, the EAP peer utilizes the transported
   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.  Since the TSKs can be determined from the transported
   EAP keying material and the cleartext of the Secure Association
   Protocol exchange, the AAA server will have access to the TSKs unless
   it deletes the transported EAP keying material after sending it.

5.10.  Man-in-the-middle Attacks

   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.

5.11.  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 sttate corresponding
   to a few EAP converations, 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.

5.12.  Impersonation

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

   While AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
   support mutual authentication between the authenticator (known as the
   AAA client) and the backend authentication server (known as the AAA
   server), the security mechanisms vary according to the AAA protocol.

   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 NAS identification attributes so as to
   detect and prevent impersonation attacks.

   When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
   NAS-IPv6-Address attributes may not correspond to the source address.
   Since the NAS-Identifier attribute need not contain an 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
   transorted 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.

   As recommended in [RFC3579] Section 4.3.7, 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
   FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
   RRs to be properly configured.  As a result, it appears that Diameter
   is as vulnerable to this attack as RADIUS, if not more so.  To
   address this vulnerability, it is necessary to allow the backend
   authentication server to communicate with the authenticator directly,
   such as via the redirect functionality supported in [RFC3588].

5.13.  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 Secure
   Association Protocol, the EAP peer and authenticator only demonstrate
   mutual possession of the transported EAP keying material.  This
   creates a potential security vulnerability, described in [RFC3748]
   Section 7.15.

   [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).  However, it is possible for a pass-through authenticator
   acting as a AAA client to provide correct information to the AAA
   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, or for a pass-through
   authenticator acting as a AAA client to provide an incorrect peer
   Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA
   protocol.

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

   Using such a protected exchange, it is possible to match the channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  For example, see [I-
   D.arkko-eap-service-identity-auth].

   It is also possible to achieve Channel Bindings without transporting
   data over EAP.  For example, see [draft-ohba-eap-aaakey-binding].  In
   this approach the authenticator informs the backend server about the
   Channel Binding parameters using AAA, and the backend server
   calculates transported keying material based on this parameter set,
   making it impossible for the peer and authenticator to complete the
   Secure Association Protocol if there was a mismatch in the
   parameters.

   The main difference between these approaches is that Channel Binding
   support within an EAP method may require upgrading or changing the
   EAP method, impacting both the peer and the server.   Where Channel
   Bindings are implemented in AAA,  the peer, authenticator and the
   backend server need to be upgraded, but the EAP method need not be
   modified.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Oct 2005 10:44:29 +0300

>     An EAP authenticator MUST NOT share any keying material with

Can we make this more specific? "... any keying material derived by EAP 
... "?

>     impersonate a AAA server to other AAA clients.

Maybe add "Proper management practises helps in achieving this."

>     fundamental cryptographic assumption.

Add:
    Proper design of key
    derivation mechansms in methods achieves this.

>     a replay-protected message, so replay protection is not sufficient.

Right.

>     freshness of EAP keying material.

I need to think about this some more. This worries me a bit.

>   backend server need to be upgraded, but the EAP method need not be

--Jari