Subject: [AAA-WG]: Issue 399: NASREQ Security Issues

From: Bernard Aboba <[email-masked]>
Date: Sun, 2 Feb 2003 07:58:14 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: February 2, 2003
Document: NASREQ-10
Comment type: T
Priority: S
Section: 6.2

In Diameter NASREQ as well as in RADIUS, it is possible for a
rogue NAS to send forged AVPs. For example, NAS A could
send an Origin-Host, NAS-Identifier or NAS-IP-Address AVP with information
corresponding to NAS B, and could even forge AVPs relating
to the client such as the Called-Station-Id or Calling-Station-Id.

In RADIUS shared secret checks are done based on the
Source Address, not the NAS-Identifier/NAS-IP-Address,
since the message could have been forwarded by a proxy.
This means that the RADIUS server may not have the means
to verify that the NAS-Identifier or NAS-IP-Address is correct.

We can and should do better in Diameter. In particular, we
have the Route-Record AVP, in which a Diameter agent will
store information about the previous hop before forwarding
the packet to the Diameter server.

This means that a forgery of NAS-Identifier/NAS-IP-Address
AVPs can be detected by a Diameter agent before it even gets
to the Diameter server, by checking for a match between the
Route-Record AVP and the NAS-Identifier/NAS-IP-Address AVPs.

In Diameter Base 6.1.8 it is stated:

"A relay or proxy agent MUST append a Route-Record AVP to all requests
forwarded. The AVP contains the identity of the peer the request was
received from." In Figure 7, a sample Route-Record AVP is included,
with FQDNs as entries.

In Section 6.7.1 it is stated:

"The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one received in
the Origin-Host of the Capabilities Exchange message."

I interpret this to mean that the Origin-Host AVP must contain the
FQDN of the NAS, and that there must be a A & PTR RRs in the DNS
corresponding to this, so that the Diameter agent can take the
source IP address, do a PTR RR query, insert the result in the
Route-Record AVP, and check it against the Origin-Host AVP.

In order to be able to verify the contents of the NAS-Identifier
or NAS-IP-Address AVPs, we need for the Diameter Agent to check
whether the contents of those AVPs corresponds to any existing
entry in the Route-Record AVP. This means doing a PTR RR query
on the NAS-IP-Address and checking for a match within the
Record-Route AVP. For NAS-Identifier AVP, a check may not be
possible unless this AVP contains an FQDN, in which case an
entry in the Route-Record AVP can also be searched for.

If there is no match, then the Diameter Client must be a
first hop, in which case, the NAS-IP-Address AVP should
match the Source Address of the packet, and a PTR RR on
this address should correspond to the Origin-Host AVP
and can be entered in the Route-Record AVP. With
NAS-Identifier, it is not clear how a check can be done
unless this is assumed to contain an FQDN. In that
case, the NAS-Identifier AVP can be checked against the
Origin-Host AVP and an A RR query can be made on the FQDN and the
resulting IP address can be compared against the
Source Address.

Since the Diameter agent cannot independently verify the
Called-Station-Id or Calling-Station-Id, there are no
checks that can be done to prevent forgery of those AVPs;
however, it is conceivable that an EAP method could include
those values in a MIC so as to allow the Diameter Server
to verify them.

Please insert the following text in Section 6.2.1 (NAS-IP-Address AVP):

"In RADIUS it is possible for a rogue NAS to forge the
NAS-IP-Address attribute. Diameter/RADIUS translation agents
MUST check a received NAS-IP-Address attribute against the source address
of the RADIUS packet. If they do not match, and the Diameter/RADIUS
translation agent does not know whether the packet was sent by
a RADIUS proxy or NAS (e.g. no Proxy-State attribute) then
by default it is assumed that the source address corresponds
to a RADIUS proxy, and that the NAS-IP-Address is behind that
proxy, potentially with some additional RADIUS proxies in between.
The Diameter/RADIUS translation agent MUST insert entries
in the Route-Record AVP corresponding to the apparent route.
This implies doing a reverse lookup on the source address and
NAS-IP-Address attributes in order to determine the corresponding
FQDNs.

If the source address and the NAS-IP-Address do not match,
and the Diameter/RADIUS translation agent knows that it is
talking directly to the NAS (e.g. no RADIUS proxies between
it and the NAS), then the error should be logged, and the
packet MUST be discarded.

Diameter agents and servers MUST check whether the
NAS-IP-Address AVP corresponds to an entry in the Record-Route AVP.
This is done by doing a reverse lookup (PTR RR) for the NAS-IP-Address
to retrieve the corresponding FQDN, and checking for a match
with the Record-Route AVP. If no match is found, then an error
is logged, but no other action is taken."

Please insert the following text in Section 6.2.2 (NAS-IPv6-Address AVP):

"In RADIUS it is possible for a rogue NAS to forge the
NAS-IPv6-Address attribute. Diameter/RADIUS translation agents
MUST check a received NAS-IPv6-Address attribute against the source
address of the RADIUS packet. If they do not match, and the
Diameter/RADIUS translation agent does not know whether the packet was
sent by a RADIUS proxy or NAS (e.g. no Proxy-State attribute) then
by default it is assumed that the source address corresponds
to a RADIUS proxy, and that the NAS-IP-Address is behind that
proxy, potentially with some additional RADIUS proxies in between.
The Diameter/RADIUS translation agent MUST insert entries
in the Route-Record AVP corresponding to the apparent route.
This implies doing a reverse lookup on the source address and
NAS-IP-Address attributes in order to determine the corresponding
FQDNs.

If the source address and the NAS-IP-Address do not match,
and the Diameter/RADIUS translation agent knows that it is
talking directly to the NAS (e.g. no RADIUS proxies between
it and the NAS), then the error should be logged, and the
packet MUST be discarded.

Diameter agents and servers MUST check whether the
NAS-IPv6-Address AVP corresponds to an entry in the Record-Route AVP.
This is done by doing a reverse lookup (PTR RR) for the NAS-IPv6-Address
to retrieve the corresponding FQDN, and checking for a match
with the Record-Route AVP. If no match is found, then an error
is logged, but no other action is taken."

Please insert the following text in Section 6.2.3 (NAS-Identifier AVP):

"In RADIUS it is possible for a rogue NAS to forge the
NAS-Identifier attribute. Diameter/RADIUS translation agents
SHOULD attempt to check a received NAS-Identifier attribute
against the source address of the RADIUS packet, by doing an
A/AAAA RR query. If the NAS-Identifier attribute contains an
FQDN, then such a query would resolve to an IP address matching
the source address. However, the NAS-Identifier attribute
is not required to contain an FQDN, so such a query could
fail. In this case, an error should be logged, but no other
action taken, other than doing a reverse lookup on the
source address and inserting the resulting FQDN into the
Route-Record AVP.

Diameter agents and servers SHOULD check whether a
NAS-Identifier AVP corresponds to an entry in the Record-Route AVP.
If no match is found, then an error is logged, but no other
action is taken."

---

From: Jari Arkko <[email-masked]>
Date: Sun, 02 Feb 2003 23:02:12 +0200

> NAS-IP-Address attributes in order to determine the corresponding

I'm OK with this otherwise, but are you adding exactly two
entries, one for the proxy and one for the NAS? I don't see
what else you would be doing, but the language above isn't
exact on this.

> packet MUST be discarded.

Ok.

> is logged, but no other action is taken."

Hmm... care to explain why we couldn't drop the message?

Also, what happens if there was a NAT or private DNS at
some point in the path?

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 2 Feb 2003 12:57:11 -0800 (PST)

> what else you would be doing, but the language above isn't

Yes, that's the intent.

> Hmm... care to explain why we couldn't drop the message?

We could do that.

> Also, what happens if there was a NAT or private DNS at

Then the proposed text won't work. Care to suggest an alternative?

---

From: David Mitton <[email-masked]>
Date: Mon, 03 Feb 2003 11:16:02 -0500

>to the client such as the Called-Station-Id or Calling-Station-Id.
<..snip...>

I have added the suggested text to Diameter NAS draft 11.
If there are any desired changes to the suggested text, let me know.

Dave.