Subject: [AAA-WG]: Issue 401: No security considerations section

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Feb 2003 06:02:06 -0800 (PST)

Issue 401: No Security Considerations Section
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 02-19-2003
Reference:
Document: EAP-00
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
The draft currently has no security considerations section.
Find enclosed a contribution filling this need:

4. Security Considerations

4.1. Security requirements

Diameter/EAP is used in order to provide authentication and authorization
for network access. As a result, both the Diameter and EAP portions of the
conversation are open to attack. Examples include:

[1] An adversary may attempt to acquire confidential data and
identities by snooping Diameter/EAP packets.

[2] An adversary may attempt to modify packets containing Diameter
messages.

[3] An adversary may attempt to inject packets into a Diameter
conversation.

[4] An adversary may attempt to replay a Diameter exchange.

[5] An adversary may attempt to disrupt the EAP negotiation,
in order to weaken the authentication, or gain access to user
passwords.

[6] An authenticated NAS may attempt to forge attributes,
including NAS-IP-Address, NAS-Identifier, Called-Station-Id,
or Calling-Station-Id.

[7] A rogue (unauthenticated) NAS may attempt to impersonate a
legitimate NAS.

[8] An attacker may attempt to act as a man-in-the-middle.

To address these threats, it is necessary to support confidentiality,
data origin authentication, integrity, and replay protection on a per-
packet basis. Bi-directional authentication between the Diameter client
and server also needs to be provided. There is no requirement that the
identities of Diameter clients and servers be kept confidential (e.g.,
from a passive eavesdropper). Diameter Base protocol [BASE] provides
support for both IPsec and TLS transmission layer security, addressing
threats 1-4. The other security issues are discussed below.

4.2. Security issues

This section provides more detail on the vulnerabilities identified in
above, and how they may be mitigated. Vulnerabilities include:

Privacy issues
Connection hijacking
Replay attacks
Negotiation attacks
Impersonation
Man in the middle attacks
Multiple databases

4.3.1. Privacy issues

Since Diameter messages may contain the User-Name attribute as well as
NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
Diameter traffic may be able to determine the geographic location of users
in real time. In wireless networks, it is often assumed that Diameter
traffic is physically secure, since it typically travels over the wired
network and that this limits the release of location information.

However, it is possible for an authenticated attacker to spoof ARP
packets from another Access Point so as to cause diversion of Diameter
traffic onto the wireless network. In this way an attacker may obtain
Diameter packets from which it can glean location information. To address
this
vulnerability, IPsec or TLS can be used to provide per-packet
authentication,
integrity protection, confidentiality and replay protection
of Diameter messages, as specified in [BASE].

4.3.2. Connection hijacking

An attacker may attempt to inject packets into the conversation between
the NAS and the Diameter server, or between the Diameter server and the
security server.

To address this
vulnerability, IPsec or TLS can be used to provide per-packet
authentication,
integrity protection, confidentiality and replay protection
of Diameter messages, as specified in [BASE].

4.3.3. Replay attacks

The Diameter protocol relies upon IPsec or TLS transmission layer
security to prevent replay. However, where untrusted proxies are
present, this is not sufficient to prevent replay of CMS-protected
objects. These objects, when included in Diameter EAP messages,
MUST contain sufficient liveness to address replay attacks.

<More detail here>

4.3.4. Negotiation attacks

In a negotiation attack, a rogue NAS, tunnel server, Diameter agent or
Diameter server causes the authenticating peer to choose a less secure
authentication method so as to make it easier to obtain the user's
password. For example, a session that would normally be authenticated
with EAP would instead authenticated via CHAP or PAP; alternatively, a
connection that would normally be authenticated via one EAP type occurs
via a less secure EAP type, such as MD5-Challenge. The threat posed by
rogue devices, once thought to be remote, has gained currency given
compromises of telephone company switching systems, such as those
described in [Masters].

Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved by protecting the Diameter
exchange using IPsec or TLS as described in [BASE]. Alternatively,
the vulnerability can be mitigated via implementation
of per-connection policy on the part of the authenticating peer, and
per-user policy on the part of the Diameter server. For the
authenticating peer, authentication policy should be set on a per-
connection basis. Per-connection policy allows an authenticating peer to
negotiate a strong EAP method when connecting to one service, while
negotiating a weaker EAP method for another service.

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. Should the NAS not
be able to negotiate EAP, or should the EAP-Request sent by the NAS be
of a different EAP type than what is expected, the authenticating peer
MUST disconnect. An authenticating peer expecting EAP to be negotiated
for a session MUST NOT negotiate a weaker method, such as CHAP or PAP.
In wireless networks, the service advertisement itself may be spoof-
able, so that an attacker could fool the peer into negotiating an
authentication method suitable for a less secure network.

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 an
EAP-capable client to support more than one authentication type, which
could weaken security.

If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
Password attributes to the Diameter server in an Access-Request packet.
If the user is not required to use EAP, then the Diameter server will
respond with an Access-Accept or Access-Reject packet as appropriate.
However, if CHAP has been negotiated but EAP is required, the Diameter
server MUST respond with an Access-Reject, rather than an Access-
Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST
refuse to renegotiate authentication, even if the renegotiation is from
CHAP to EAP.

If EAP is negotiated but is not supported by the Diameter agent or server,
then the server or agent MUST respond with an Access-Reject. In these
cases, a PPP NAS MUST send an LCP-Terminate and disconnect the user.
This is the correct behavior since the authenticating peer is expecting
EAP to be negotiated, and that expectation cannot be fulfilled. An EAP-
capable authenticating peer MUST refuse to renegotiate the
authentication protocol if EAP had initially been negotiated. Note that
problems with a non-EAP capable Diameter proxy could prove difficult to
diagnose, since a user connecting from one location (with an EAP-capable
proxy) might be able to successfully authenticate via EAP, while the
same user connecting at another location (and encountering an EAP-
incapable proxy) might be consistently disconnected.

4.3.5. Impersonation

When Diameter requests are forwarded by an agent, 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.

This implies that it is possible for a rogue NAS to forge NAS-IP-
Address, NAS-IPv6-Address or NAS-Identifier AVPs in order to
impersonate another NAS. This could result in Diameter messages,
including Grouped Key AVPs, being sent to the wrong NAS. ALthough the
rogue
NAS is authenticated by the Diameter agent or server within TLS or
IKE, this authentication information may not be accessible to the Diameter
agent or server, making it unable 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.

To address these vulnerabilities it is necessary for the Grouped Key AVP
to contain enough information to "bind" the key to the NAS and client
with which it is to be used. For example, AVPs identifying the NAS
(Origin-Host, NAS-IPV6-Address, NAS-IP-Address, NAS-Port, etc.) can
be included as well as attributes identifying the client
(Calling-Station-Id,
Framed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id, Session-Id,
etc.).

Diameter servers SHOULD check whether NAS-Identifier, Origin-Host,
NAS-IP-Address or NAS-IPv6-Address AVPs match an entry in the
Route-Record AVP. If the NAS-Identifier AVP is present,
such a check may not be possible since the NAS-Identifier
may not correspond to an FQDN. Similarly, where a PTR RR does not
exist corresponding to the NAS-IP-Address or NAS-IPv6-Address,
determination
of the FQDN may not be possible. Also, where a NAT
exists between the Diameter client and server, checking the NAS-IP-Address
or NAS-IPv6-Address attributes may not be feasible.

To allow verification of session parameters such as the Called-Station-
Id and Calling-Station-Id, they can be sent by the EAP peer to the EAP
server, and covered by an EAP method-specific message integrity check.
The Diameter server can then check the parameters sent by the EAP client
against those claimed by the NAS. If a discrepancy is found, an error
can be logged.

4.3.6. Man in the middle attacks

As a result, attackers gaining control
of a Diameter agent will be able to modify EAP packets in transit. This is
the case even where IPsec or TLS is used to protect Diameter messages, as
described in [BASE].

To protect against this vulnerability, object security mechanisms SHOULD
be used wherever untrusted Diamter agents are present. These include
Diameter CMS [CMS], a work in progress.

4.3.7. Multiple databases

In many cases a security server will be deployed along with a Diameter
server in order to provide EAP services. Unless the security server also
functions as a Diameter server, two separate user databases will exist,
each containing information about the security requirements for the
user. This represents a weakness, since security may be compromised by a
successful attack on either of the servers, or their databases. With
multiple user databases, adding a new user may require multiple
operations, increasing the chances for error. The problems are further
magnified in the case where user information is also being kept in an
LDAP server. In this case, three stores of user information may exist.

In order to address these threats, consolidation of databases is
recommended. This can be achieved by having both the Diameter server and
security server store information in the same database; by having the
security server provide a full Diameter implementation; or by
consolidating both the security server and the Diameter server onto the
same machine.