Diameter Security Requirements

RADIUS’s traditional reliance on hop-by-hop security based on shared secrets has created many problems for more modern applications of AAA protocols. RADIUS does not provide integrity protection in a symmetric manner (different mechanisms for access requests and responses are suggested as we saw in Chapter 6). This issue with RADIUS security procedures is especially severe when attribute hiding is important or the network needs to deal with mobile clients that have non-static IP addresses. Some specifications have tried to provide guidance on the use of IPsec for RADIUS. Still, the details on the use of IPsec for providing security services for specific RADIUS applications are not clear.

Once again, Diameter steps up and tries to accommodate for the shortcomings presented by RADIUS.

● Diameter starts by mandating support for IPsec for both Diameter clients (NAS) and servers. Diameter further mandates support of TLS by Diameter servers, while leaving the support of TLS for clients such as NAS and Mobility agents, such as FA, optional.

● One reason for easing the requirement on TLS support for NAS and edge devices is to relax the need for PKI certificate support by these devices, so IPsec can primarily be used for edge traffic or intra-domain traffic. On the other hand, it is recommended that inter- domain traffic is protected by TLS.

● Even though IPsec or TLS can provide security protection over a connection (see above), end-to-end security protection of Diameter messages may be required. One example is when the confidentiality of an attribute needs to be protected from these intermediaries. As opposed to RADIUS support for hop-by-hop security, Diameter base specification also encourages the use of specific CMS extensions [DICMSDR] for this purpose.

7.2.4.1 Use of IPsec or TLS for Diameter

Diameter requires transmission level security (through IPsec or TLS) over each connec- tion. Note that a connection may only extend between two Diameter intermediaries (e.g. a client to a relay, an agent to another agent, and so on). Diameter base specification assumes that Diameter messages are secured by using either IPsec or TLS. When IPsec is not used, only the capability exchanges between two Diameter nodes can be done without TLS support (more details on this in the next subsection). The two peers indicate the support for TLS to each other through the use of Inband-Security-ID AVP (with a value of TLS). The peers need to start the TLS handshake following the capability exchange (CER/CEA) messaging. If the TLS handshake fails at this point, the connection between the two peers must be closed.

All Diameter implementations must support the IPSec transport mode with encryption and authentication algorithms to provide per-packet authentication and confidentiality. They must also support IPSec anti-replay mechanisms. Furthermore, Diameter mandates the use of Internet Key Exchange (IKE) for peer authentication, key management and negotiation of IPsec security associations in all Diameter implementations. However, Diameter relaxes the requirements on support of all IKE authentications (see Chapter 4) and only requires the use of pre-shared secrets for IKE authentication, while leaving the support of certificate-based authentication as a choice for implementers. One issue that arises with use of certificates with IPsec and IKE is that, since the use of port identifiers is prohibited in IKE Phase 1, it is not possible to uniquely configure root certificate authorities (CAs) for each application individually. This implies a flaw in the use of certificates for IPsec-based security provisioning of Diameter messaging: the same policy must be used for all applications. The reason is that, since the authentication occurs only within Phase 1 of IKE between the client and the server and it is usually not possible to define separate trust or authorization schemes for each application during IPSec SA establishment, which happens later during phase 2.

When using TLS, the Diameter node that initiates the connection acts as the TLS client, while the diameter node (other peer) that accepts the connection acts as the TLS server. Diameter peers, implementing TLS to secure their connections, need to mutually authenticate each other as part of TLS session establishment. To support the TLS mutual authentication, the peer acting as the TLS server must be able to request a certificate from the peer acting as the TLS client and the TLS client must be able supply the certificate. Again, the issue that arises with use of certificates is that both peers need to trust the root CA that has issued these certificates. Even though TLS is much more flexible than IPsec with configuring the root CAs, it may still be possible that different CAs are used to generate certificates for different Diameter usages.

Finally, the specifications recommend that a Diameter peer implements the same security mechanism (IPsec or TLS) across all its peer-to-peer connections to avoid inconsistency, redundancy or even inadequacy in security provisioning.

7.2.4.2 Path Authorization: Impact of Security on Authorization and Accounting

As part of the transmission level security at each connection, not only are the two Diameter peers on each side of the connection (“AAA hop”) required to authenticate each other, but also they need to authorize both the connection and the session. For instance, the mere

fact that a peer has been successfully authenticated does not mean that it is authorized to act as a Diameter server supporting the applications it is advertising. Therefore the following is also required:

● Authorization of functionality: Before initiating a connection, a Diameter peer must check that its peers are authorized to act in their roles. Before bringing up the connection, author- ization checks are performed at each connection along the path. This includes Diameter capability negotiations (CER/CEA) to determine what applications are supported by each server. This is to make sure that Diameter messages relating to a session are routed along a path that only includes authorized nodes that have advertised support for the Diameter application required by that session.

● The home server, prior to authorizing a session, must check to make sure that the route traversed by the request is accepted, i.e. the request has not gone through untrusted realms. This is accomplished by checking the physical route by examining Route-Record AVPs. A DIAMETER_AUTHORIZATION_REJECTED error message is issued if the traversed route is not acceptable.

● Accounting messaging may also be tied to the aforementioned authorization. A home server may want to create a policy to accept only accounting requests for sessions for which specific authorization responses have been issued by the server.

● Local Diameter agents, proxying for Diameter messaging, also need to check the routing records included in the authorization responses coming from a home server. This is to make sure that the route taken by the message is an acceptable one. By forwarding the authorization response further down the path, a local agent is accepting the financial risk involved in authorizing the session. The same responsibility is involved in creating an accounting request corresponding to an authorization response.