Subject: [AAA-WG]: Issue: Updated security considerations for Diameter EAP

From: <[email-masked]>
Date: Wed, 22 Oct 2003 17:09:34 +0300

Updated security considerations for Diameter EAP
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: October 22, 2003
Reference: 
Document: EAP-02
Comment type: T/E
Priority: 1
Section: 8
Rationale/Explanation of issue:

The current security considerations section has a lot of text that
doesn't really belong there (e.g. about certificates and
authorization), and some text unnecessarily duplicating issues that
are already well presented in 2284bis and the new EAP key management
framework document.

Suggested change: Replace section 8 with the following text.

8. Security Considerations

8.1 Overview

   Diameter peer-to-peer connections can be protected with IPsec or TLS.
   These mechanisms are believed to provide sufficient protection under
   the normal Internet threat model--that is, assuming the authorized
   nodes engaging in the protocol have not been compromised, but the
   attacker has complete control over the communication channels between
   them.  This includes eavesdropping, message modification, insertion,
   man-in-the-middle and replay attacks.  The details and related
   security considerations are discussed in [BASE].

   In addition to authentication provided by IPsec or TLS, authorization
   is also required.  Authorization here means the act of determining if
   a Diameter message received from an authenticated Diameter peer
   should be accepted (and not authorization of users requesting network
   access from a NAS).  In other words, when a Diameter server receives
   a Diameter-EAP-Request, it has to decide if the client is authorized
   to act as a NAS for the specific user, service type, and so on.
   Correspondingly, when a NAS contacts a server to send a
   Diameter-EAP-Request, it has to determine whether the server is
   authorized to act as home server for the realm in question.

   Authorization can involve local Access Control Lists (ACLs),
   information contained in certificates, or some other means.  See
   [BASE] for more discussion and related security considerations.

   The hop-by-hop security mechanisms (IPsec and TLS) combined with
   proper authorization provide good protection against "outside"
   attackers (denial-of-service is, of course, possible).  The remaining
   part of this section deals with attacks by nodes that have been
   properly authorized (to function as a NAS, Diameter agent, or
   Diameter server) but abuse their authorization or have been
   compromised.  In general, it is not possible to completely protect
   against attacks by compromised nodes, but this section offers some
   advice that can be used to limit the extent of the damage.

   Attacks involving eavesdropping or modification of EAP messages are
   beyond the scope of these document. See [RFC2284bis] for discussion
   of these security considerations (including method negotation,
   dictionary attacks, and privacy issues). While these attacks can be
   carried out by an attacker between the client and the NAS,
   compromised NASes and Diameter agents are naturally also in a good
   position to modify and eavesdrop the EAP messages.

   Similarly, attacks involving whatever link layer protocol is used
   between the client and the NAS, such as PPP or IEEE 802.11, are
   beyond the scope of this document.

8.2 AVP editing

   Diameter agents can modify, insert, and delete AVPs. Diameter agents
   are usually meant to modify AVPs, and the protocol in general cannot
   distinguish well-intentioned and malicious modifications (see
   [RFC2607] for more discussion). Similarly, a compromised NAS or
   server can naturally include different set of AVPs than expected.

   The question is thus "what can an attacker who compromises an
   authorized NAS, agent, or server do using Diameter EAP messages?"
   Some of the consequences are rather obvious--for instance, a Diameter
   agent can give access to unauthorized users by changing the
   Result-Code to DIAMETER_SUCCESS. Other consequences are less obvious,
   and are discussed below (authentication method negotiation attacks
   are discussed in the next section).

   By including suitable AVPs in an AA-Answer/Diameter-EAP-Answer
   messages an attacker (depending on implementation and configuration
   details) may be able to:

   o  Give unauthorized users access, or deny access to authorized users
      (Result-Code).

   o  Give attacker a login session to a host otherwise protected by
      firewalls, or redirect an authorized user's login session to a
      host controlled by the attacker (Login-Host).

   o  Route an authorized user's traffic through a host controlled by
      the attacker (various tunneling AVPs).

   o  Redirect an authorized user's DNS requests to a malicious DNS
      server (various vendor-specific AVPs).

   o  Modify routing tables at the NAS and thus redirect packets
      destined for someone else (Framed-Route, Framed-Routing).

   o  Remove packet filters and other restrictions for user (Filter,
      Callback, various vendor-specific AVPs).

   o  Cause the NAS to call some number, possibly expensive toll number
      controlled by the attacker (callback AVPs)

   o  Execute Command Line Interface (CLI) commands on the NAS (various
      vendor-specific attributes).

   By modifying an AA-Request/Diameter-EAP-Request, an attacker may be
   able to:

   o  Change NAS-Identifier/NAS-Port/Origin-Host (or something) so that
      a valid user appears to be accessing the network from a different
      NAS than in reality.

   o  Modify Calling-Station-ID (either to hide the true value, gain
      access, or frame someone else).

   o  Modify password change messages (some vendor-specific attributes)

   o  Modify usage information in accounting messages.

   o  Modify contents of Class/State AVPs?

   Some of these attacks can be prevented if the NAS or server can be
   configured not to accept some particular AVPs, or accepting them only
   from some nodes.

8.3 Negotiation attacks

   This section deals with attacks where the NAS, any Diameter agents,
   or Diameter server attempts to cause the authenticating user to
   choose some authentication method other than EAP, such as PAP or CHAP
   (negotiation attacks within EAP are discussed in [RFC2284bis],
   Section 7.8).

   The vulnerability can be mitigated via implementation of
   per-connection policy on the part of the authenticating peer, and
   per-peer policy on the part of the Diameter server.  For the
   authenticating peer, authentication policy should be set on a
   per-connection basis.

   With per-connection policy, an authenticating peer will only attempt
   to negotiate EAP for a session in which EAP support is expected.  As
   a result, there is a presumption that an authenticating peer
   selecting EAP requires that level of security. If it cannot be
   provided, it is likely that there is some kind of misconfiguration,
   or even that the authenticating peer is contacting the wrong server.
   In this case, the authenticating peer simply disconnects.

   Similarly, with a per-user policy, the home server will not accept
   authentication methods other than EAP for users for which EAP support
   is expected.

   For a NAS, it may not be possible to determine whether a peer is
   required to authenticate with EAP until the peer's identity is known.
   For example, for shared-uses NASes it is possible for one reseller to
   implement EAP while another does not.  Alternatively, some peer might
   be authenticated locally by the NAS while other peers are
   authenticated via Diameter.  In such cases, if any peers of the NAS
   MUST do EAP, then the NAS MUST attempt to negotiate EAP for every
   session.  This avoids forcing a peer to support more than one
   authentication type, which could weaken security.

8.4 Session key distribution

   Since there are currently no end-to-end (NAS-to-home server) security
   mechanisms specified for Diameter, any agents that process
   Diameter-EAP-Answer messages can see the contents of the
   EAP-Session-Key AVP.  For this reason, this specification strongly
   recommends avoiding Diameter agents when they cannot be trusted to
   keep the keys secret.

   In environments where agents are present, several factors should be
   considered when deciding whether the agents that are authorized (and
   considered "trustworthy enough") to grant access to users and specify
   various authorization and tunneling AVPs are also "trustworthy
   enough" to handle the session keys.  These factors include (but are
   not limited to) the type of access provided (e.g., public Internet or
   corporate internet), security level of the agents, and the
   possibilities for attacking user's traffic after it has been
   decrypted by the NAS.

   Note that the keys communicated in Diameter messages are usually
   short-term session keys (or short-term master keys that are used to
   derive session keys).  To actually cause any damage, those session
   keys must end with some malicious party; that party must be able to
   eavesdrop, modify, or insert traffic between the user and the NAS
   during the lifetime of those keys (e.g., in 802.11i the attacker must
   also eavesdrop the "four-way handshake"); and that eavesdropping or
   modification must cause some damage.

8.5 Privacy issues

   Diameter messages can contain AVPs that can be used to identify the
   user (e.g., User-Name) and approximate location of the user (e.g.
   Origin-Host for WLAN access points, Calling-Station-Id for fixed
   phone lines).  Thus, any Diameter nodes that process the messages may
   be able to determine the geographic location of users.

   Note that in many cases, the user identity is also sent in clear
   inside EAP-Payload AVPs, and it may be possible to eavesdrop this
   between the user and the NAS.

   This can mitigated somewhat by using EAP methods that provide
   identity protection (see [RFC2284bis], Section 7.3), and using
   Session-Id or pseudonyms for accounting.

8.6 Note about EAP and impersonation

   If the EAP method used does not provide mutual authentication,
   obviously anyone can impersonate as the network to the user.  Even
   when EAP mutual authentication is used, it occurs between the user
   and the Diameter home server. See  for an extensive discussion about
   the details and their implications.

   However, one issue is worth pointing out here. As described in
   [EAPKey], the current EAP architecture does not allow the home server
   to restrict what service parameters or identities (such as SSID or
   BSSID in 802.11 wireless LANs) are advertised by the NAS to the
   client. That is, a compromised NAS can change its BSSID or SSID, thus
   appearing to offer a different service than intended.  Even if these
   parameters are included in Diameter-EAP-Request messages, the NAS can
   tell different values to the client.

   Thus, the possession of the session keys by the NAS proves that the
   user is talking to *some* authorized NAS, but a compromised NAS can
   lie about its exact identity. See [EAPKey] for discussion how
   individual EAP methods can provide authentication of NAS service
   parameters and identities.

   Note that the usefulness of such authentication may be rather limited
   in many environments. For instance, in wireless LANs the user does
   not usually securely know the identity (such as BSSID) of the "right"
   access point--it's simply picked from a beacon message that has the
   correct SSID and good signal strength (something that's easy to
   spoof). Thus, simply authenticating the identity may not allow the
   user to distinguish the "right" access point from all other ones.

Best regards,
Pasi