[secdir] Secdir review of draft-ietf-dime-diameter-qos-11.txt

[Brian Weis <[e-mail]>]

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG. These comments were written primarily for the benefit of the  
security area directors. Document editors and WG chairs should treat  
these comments just like any other last call comments.

This document describes a Diameter Quality of Service (QoS)  
application, which allows network elements to interact with Diameter  
servers when allocating QoS resources in the network. It re-uses the  
Diameter Base Protocol (RFC 3588) packet formats for this new  
application. New message flows between Network Elements (acting as  
Diameter Clients) and Authorizing Entities (acting as Diameter  
Servers) are defined. Examples are given as to how the new flows fit  
into various QoS methods.

This document seems to be mature. I have some detailed comments/ 
questions, but they are primarily suggesting additional topics for the  
Security Considerations section and a suggestion to better clarify how  
"identities" are used.

The Security Considerations section of this document describes various  
threats to Diameter messaging, which are accurate, but more precisely  
apply to the Base Protocol rather than the use case presented in this  
I-D. That is, the need for authentication, authorization, integrity  
and confidentiality is no different for this I-D than for RFC 3588. I  
see no problem with the existing text, but a statement that the  
Security Considerations in RFC 3588 also apply would also be  
appropriate (especially as that document discusses mitigations to the  
threats described here).

I don't believe there is a sufficient discussion in the Security  
Considerations regarding the threats to the QoS application itself.  
Let me try to explain. If I'm not mistaken, the traditional Diameter  
Base Protocol use case consists of a login service on an access port  
and a Diameter Client that provide no access to the user until the  
Diameter Server returns positive results. As such, mitigating threats  
to the messages (using some form of transport security) is the primary  
consideration to the Base Protocol -- it is understood that the actual  
device trying to access the network is being denied access by the  
login service until the Diameter exchange finishes. However, the QoS  
application brings two new dynamic actors into the solution: the  
Resource Requesting Entity (RRE) (using unspecified and possibly  
unsecured QoS request protocols), and a potential man-in-the-middle  
actor between the RRE and the Network Element. I understand that how  
those messages are protected between an RRE and a Network Element is  
outside the scope of this document, but because the Network Element/ 
Diameter Client acts on those messages there are additional threats to  
the QoS application that should be described. Here are some threats  
that occur to me:

1. In some (if not all) cases, the the Diameter Client translates  
information provided by the RRE (as shown in Figure 3), and includes  
it in a QoS-Request (described in Section 5.1) sent to the Diameter  
Server. In particular, the the QoS-Request may include a number of  
identification fields that, if blindly accepted from an RRE QoS  
Request message, could be cause the Diameter QoS service to allow  
authorizations that it should not (or conversely, deny authorizations  
unnecessarily). Of course, the same is true for the QoS parameters. I  
would expect the security consideration section to discuss the risks  
of the Network Element acting on these fields. For example,  
recommending that adequate transport security be used between the RRE  
and the Network Element to mitigate the man-in-the-middle threat.

2. A Token-based Three Party Scheme (Figure 4) may mitigate the threat  
of an RRE lying about its own identity. However, I see no means  
described by which the Diameter Client can have assurance that the RRE  
presenting the token was actually the RRE given that particular  
token.  Perhaps there is an assumption that the Network Client will  
have previously authenticated the RRE and can verify the Username in a  
token to a Username associated with an access port. A discussion of  
how the Network Element maps the token to an identity would be useful.

Here are a few comments on the rest of the document:

3. Figures 3, 4, and 5 show a "financial settlement" line between an  
an "Entity authorizing resource request" and a Network Element. It is  
odd to think of a Network Element (e.g., router) participating in a  
financial transaction. Wouldn't it be more likely that the "Entity  
authorizing resource request" would be a proxy device in the home  
network that speaks back-end protocols for both authorization and  
financial settlement to a visited network device?

4. Section 3.4 includes requirements titled "Identity-based Routing"  
and "Associating QoS Reservations and Application State", which  
essential require that the Diameter Server must be given identities  
that it trusts. Comments 1 and 2 above really are questioning how this  
requirement is actually met. Since this is a critical point, it would  
be worth adding some discussion in the text regarding how accurate   
identities can be obtained by the Diameter Client. By the way, what  
identity types does the Diameter QoS application expect to use?  
Username, IP address, and/or Hostname? Is mapping an IP address to a  
Username important? This might be valuable discussion to add.

5. Section 4.2.3. The term "Diameter QoS application node" is used  
exclusively in this section. Does it refer to a Diameter QoS client,  
server, or both? Clarifying this would be good.

Thanks,
Brian

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]