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

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Wed, 29 Oct 2003 07:32:50 +0100

Hi Jari,

Thank you for your feedback and suggestions.

> > 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. 
> 
> 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."?

Yes, that was the intention. 
Your proposal sounds fine, thanks.

> 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.

OK. 

> > 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.
> 
> I think NOT RECOMMENDED may be a bit too strong. How about
> "may be inappropriate in some cases", or something shorter
> to that effect?

OK, as well.

> > 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).

I prefer a non-normative reference to Diameter EAP.
The text in the Diameter EAP is very valid for several Diameter applications, 
actually lot of that text should be in some general AAA document, where diameter 
applications could make reference, instead of a repeating same text.
But no problem to point the Diameter EAP.

Regards........Harri