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

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Nov 2003 17:40:54 +0200

Hi Pasi,

Sorry for responding to this so late, but was behind in e-mail...
I like your new text. I do have a few nits below, and two
technical suggestions:

> 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.

Here I would still add/keep a bit of discussion about the impacts of redirect
to authorization, since I don't see that being discussed in the keying
draft. Here's a suggestion:

      Authorization issues are particularly relevant when Diameter
      redirects are used. While redirection reduces the number of
      nodes which have access to the cleartext Diameter messages,
      a compromised Diameter agent may not supply the right
      home server's address. If the Diameter client is unable to
      tell whether this particular server is authorized to
      act as the home server for this particular user, the
      security of the communications rests on the agent, even if
      redirects are used.

>    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.

Hmm... I agree with the above. But I wonder if we should also talk
about the explicit authorization AVPs for users vs. current implicit
"its ok if I don't complain" approach in RADIUS/Diameter. I thought
the plan was to add some new authz AVPs in this draft, and we should say
something about their security here.

> 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

s/per-peer/per-user/? the latter term appears to be used below.

>    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.

Reference missing.

>    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.

--Jari