Subject: [AAA-WG]: Issue 388: Diameter Peer Discovery and Authorization

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Nov 2002 08:30:50 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: November 11, 2002
Reference:
Document: BASE-15
Comment type: T
Priority: S
Section: 5.2
Rationale/Explanation of issue:

While Diameter uses IPsec or TLS for transmission layer
security, the ability authenticate with IKE or TLS does
not imply authorization.

Therefore, with pre-shared key authentication in IKE it
is still typically necessary to manually configure the
IP address of the NAS or AAA server, along with the
corresponding pre-shared key. With certificate
authentication, the FQDN is typically manually
configued, along with the trusted root.

This means that Diameter Peer discovery, even if
secured, must be careful to make sure that the
discovered Diameter peers are actually authorized
for their roles. This is particularly important
when DNS is used for discovery, because the
use of DNSSEC does not imply authorization.
For example, a host could exist that had a TyLS
certificate (for web use), and secured DNS
RRs, but was *not* authorized to act as a Diameter
server.

Similarly, with SLPv2, security SHOULD be used,
both to validate the integrity of the advertisements
as well as to determine authorization to act as a
Diameter Peer.

Change:

"It is recommended that SLPv2 security
be deployed (this requires distributing keys to SLPv2 agents).
This is discussed further in Appendix A."

To:

"SLPv2 security SHOULD be used (requiring distribution of
keys to SLPv2 agents) in order to ensure that discovered
peers are authorized for their roles. SLPv2 is discussed
further in Appendix A."

Change:

"If the server is using a site certificate, the domain name in
the query and the domain name in the replacement field MUST
both be valid based on the site certificate handed out by the
server in the TLS exchange. Similarly, the domain name in the
SRV query and the domain name in the target in the SRV record
MUST both be valid based on the same site certificate.
Otherwise, an attacker could modify the DNS records to contain
replacement values in a different domain, and the client could
not validate that this was the desired behavior, or the result
of an attack."

To:

"If the server is using a site certificate, the domain name in
the query and the domain name in the replacement field MUST
both be valid based onthe the site certificate handed out by the
server in the TLS or IKE exchange. Similarly, the domain name in the
SRV query and the domain name in the target in the SRV record
MUST both be valid based on the same site certificate.
Otherwise, an attacker could modify the DNS records to contain
replacement values in a different domain, and the client could
not validate that this was the desired behavior, or the result
of an attack.

Also, the Diameter Peer MUST check to make sure that the discovered
peers are authorized to act in its role. Authentication via IKE
or TLS, or validation of DNS RRs via DNSSEC is not sufficient
to conclude this. For example, a web server may have obtained a
valid TLS certificate, and secured RRs may be included in the
DNS, but this does not imply that it is authorized to act as
a Diameter Server.

Authorization can be achieved for example, by configuration of a
Diameter Server CA. Alternatively this can be achieved by
definition of OIDs within TLS or IKE certificates so as to
signify Diameter Server authorization."