Subject: [AAA-WG]: Diameter CCA Updated Security Considerations

From: <[email-masked]>
Date: Thu, 23 Oct 2003 16:08:20 +0300

Hi all,

We've updated the Diameter CCA Security Section. Comments welcome.

John

9. Security Consideration

The Diameter base protocol [DIAMBASE] assumes that each Diameter implementation uses underlying security, i.e. 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. Note also that this application includes a mechanism for application layer replay protection by the means of Session-ID from [DIAMBASE], and CC-Request-Number specified in this document. The Diameter credit control application is often used within one domain and there may be just single hop between the peers. In these environments the use of TLS or IPsec is sufficient. The details of TLS and IPsec related security considerations are discussed in the  [DIAMBASE].

Because this application handles monetary transactions (directly or indirectly) this kind of application increases the interest for various security attacks. Therefore extra attention should be paid to the authentication of the client and the server, as well as the possible proxy and relay agents. In addition to this, authorization of the client shall be emphasised, i.e. that the client is allowed to perform credit control for a certain user. 

Another kind threat is malicious modification, injection or deletion of AVPs or complete credit control messages. The credit control messages contain sensitive billing related information (such as subscription Id, granted units, used units, cost information) whose malicious modification can have economical consequences. Sometimes simply delaying the credit control messages can cause disturbances in the credit control client or server.

Even without any modification to the messages an adversary can invite a security threat by eavesdropping, because the transactions contain private information about the user. Also by monitoring the credit control messages one can collect information about credit control server's billing models and business relationships. 

When third party relays or proxy are involved, the hop-by-hop security does not necessarily provide sufficient protection for Diameter user session. Diameter messages, such as CCR and CCA, containing sensitive AVPs are NOT RECOMMENDED to be sent via untrusted Diameter proxy agents since there are no assurance that third party proxies will not modify the credit control commands or AVP values.  Section 9.1 describes a scenario how to make the situation a single hop if the security requirements demands that.

9.1 Direct connection with redirects

A Diameter Credit control agent cannot always know whether agents between it and the end user's Diameter credit control server are reliable. In this case the Diameter Credit control agent doesn't have a routing entry in its Diameter Routing Table for the realm of the Credit Control Server in the end user's home domain. The Diameter Credit control agent can have a default route configured to a local Redirect agent and it re-directs the CCR message to the redirect agent. The local Redirect agent then returns a redirect notification (Result-code 3006, DIAMETER_REDIRECT_INDICATION) to the Credit control agent, as well Diameter Credit control Server(s) information (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) how to the routing entry resulting from the Redirect-Host is to be used. The Diameter credit control agent then forwards the CCR message directly to one of the hosts identified by the CCA message from the redirect agent. If the value of the Redirect-Host-Usage AVP is unequal than zero all following messages are sent to the host specified in the Redirect-Host AVP until the time specified by the Redirect-Max-Cache-Time AVP is expired.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Oct 2003 15:45:44 +0200

> Because this application handles monetary transactions (directly or indirectly) this kind of application increases the interest for various security attacks. Therefore extra attention should be pai…

Hmm... what does "attention to authentication mean"? That you don't
forget to do it in TLS ;-) ? Perhaps you meant "... all parties communicating
with each other must be authenticated, including, for instance, TLS client-side
authentication."?

Regarding authorization, you might say that the specific means of authorization
are outside the scope of this specification but can be, for instance, manual
configuration.

> When third party relays or proxy are involved, the hop-by-hop security does not necessarily provide sufficient protection for Diameter user session. Diameter messages, such as CCR and CCA, containi…

I think NOT RECOMMENDED may be a bit too strong. How about
"may be inappropriate in some cases", or something shorter
to that effect?

> A Diameter Credit control agent cannot always know whether agents between it and the end user's Diameter credit control server are reliable. In this case the Diameter Credit control agent doesn't have a routing entry in its Diameter Routing Table for the realm of the Credit Control Server in the end user's home domain. The Diameter Credit control agent can have a default route configured to a local Redirect agent and it re-directs the CCR message to the redirect agent. The local Redirect agent then returns a redirect notification (Result-code 3006, DIAMETER_REDIRECT_INDICATION) to the Credit control agent, as well Diameter Credit control Server(s) information (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) how to the routing entry resulting from the Redirect-Host is to be used. The Diameter credit control agent then forwards the CCR message directly to one of the hosts identified by the CCA message from the redirect agent. If the value of the Redirect-Host-Usa
ge AVP is unequal than zero all following messages are sent to the host specified in the Redirect-Host AVP until the time specified by the Redirect-Max-Cache-Time AVP is expired.

Ok, but there are some authz issues even with redirects. Might make sense
to add a non-normative reference to Diameter EAP for a discussion of these,
or copy some text from there (though its in the process of being updated, you
could talk to Pasi about it).

--Jari