5
Diameter Security

5.1 Introduction

In the design of Internet protocols, security is approached in a structured way by analyzing threats, which requires a high‐level understanding of the protocol's communication architecture 1 and has been described in earlier chapters, and then deriving security requirements. These security requirements can then be addressed by various security services, such as data integrity and confidentiality protection, authentication, authorization, etc. The IETF has developed building blocks offering such security services and offers guidance to specification authors on how to engineer security into protocols with RFC 3552 2. Guidance for considering privacy in protocol design is captured in RFC 6973 3.

We approach a description of Diameter security in this book similarly to RFC 3552, in addition we provide background information about information security in Section 5.2. We discuss threats in Section 5.3, followed by a description of security services applied to the Diameter protocol in Section 5.4, and conclude with an example in Section 5.5.

Recall that historically a user would connect to a network by contacting a Network Access Server (NAS) over a land line via a modem, then had to authenticate, probably using a login and password, before being granted access to the Internet or a company network. The NAS then communicated with a back‐end server and the AAA process took place. Since phone lines were not shared, the security of the network access was mainly provided by the AAA protocol, and in particular by the authentication interaction.

While dialup modems have disappeared, the basic principle of authenticating users before they are granted access to a network is still in widespread use. Mobile phones, for example, perform authentication via the subscriber identity module (SIM) and the authentication server checks whether the user is authorized before granting the user access to the mobile operator network. Another example is a remote access server (RAS) that enables company employees to access company internal resources from remote locations by establishing a virtual private network (VPN) connection, after the employee is successfully authenticated and authorized. In many deployments today, users access the network via wireless or cellular radio technology, and everyone within the transmission range can eavesdrop on the communication. Hence, there is not only the need to authenticate and authorize the access to the network, which is mainly of interest to the network operator, but also to secure the wireless link between the device and the NAS, such that unencrypted communication content is not available to an eavesdropper.1

The AAA architecture has therefore been designed to offer authentication and authorization of the device and user requesting access to the network and also to facilitate the distribution of keying material to enable integrity and confidentiality protection of data transmitted over the wireless link.

The authorization policies stored at AAA servers typically support a range of deployment scenarios. For example, in an enterprise WLAN environment, only employees may be entitled to access to the network, while at an Internet cafe access to the network and to the Internet may only be granted to paying customers.

The incentives for hackers to circumvent access control systems are obvious – in parallel, the techniques to protect the access control systems evolve rapidly to match the attacks as soon as new threats are identified. For example, the trend today in enterprise networks is not only to control access of remote connections in the RAS, but also to control all connections to the internal network, with the assumption that the protection granted by the enterprise premise's physical isolation is insufficient to protect against unauthorized access. For this purpose, architectures such as IEEE 802.1X 4 enforce authentication of devices connecting to wireless or wired 5 networks, similar to the remote access scenario. Here again, the AAA protocol is one component of the complete solution that secures the access to the network.

Besides network access control, Diameter is used nowadays in a variety of deployments where the nature of Diameter's signaling behavior is convenient for other applications and services as well. It is therefore important to understand the security properties Diameter offers when making a design decision to reuse Diameter for a specific service.

5.2 Background

For a better understanding of Diameter security concepts we will review a few basics. We do not aim, however, to provide a detailed treatment of cryptography, which is the study of mathematical techniques related to information security. There are many good books about cryptography and Internet security. For a good introduction to cryptography we recommend Handbook of Applied Cryptography by Alfred Menezes, Paul van Oorschot, and Scott Vanstone, which is available as a free download at http://cacr.uwaterloo.ca/hac/. For a better understanding of TLS we recommend SSL and TLS: Designing and Building Secure Systems by Eric Rescorla 6. Eric Rescorla is co‐author of the TLS and DTLS specifications and has co‐chaired the IETF TLS working group for several years. For IPsec and IKEv2 we recommend the reader consults the original IETF specifications, namely 7 for IPsec ESP and 8 for IKEv2.

Many Internet communication protocols assume a very simple adversary model, which is shown in Figure 5.1. Two entities, a client and a server, interact with each other by exchanging messages over an unsecured communication channel. This communication channel is exposed to an adversary, which may eavesdrop, replay, reorder, delete, and inject messages.

Diagram depicting Adversary model with Unsecured communication between client and server intercepted by an adversary.

Figure 5.1 Adversary model.

Both the sender and the receiver want confidentiality of data communication so that an adversary cannot spy on the exchange and retrieve plaintext data. A receiver also wants authenticity of the exchanged data so that he has a guarantee that the data was sent by a certain sender and not injected or modified by an adversary. The obvious solution to this problem is to use a dedicated communication channel between the sender and the receiver that is physically isolated from any adversary. Needless to say, this is expensive and impractical for most purposes. Since it is more cost‐effective to share communication channels, cryptography techniques are used to protect the data in transit over non‐secure channels, such as Internet communications.

Well‐established cryptographic algorithms, which are used to build cryptographic protocols, are known as cryptographic primitives. These cryptographic primitives can be split into three families of techniques with different properties, as described in the subsequent sub‐sections.

5.2.1 Unkeyed Primitives

Unkeyed primitives, particularly hash functions, are used as one‐way functions that map a large, variable‐sized input message into a small fingerprint. A common size of such a fingerprint is 128 or 256 bits. Unkeyed primitives are typically used in combination with other techniques, such as digital signatures, to sign only a small message instead of an entire document. For hash functions the goal is to prevent an attacker from easily generating two messages that lead to the same fingerprint. Unkeyed primitives, as the name indicates, do not utilize any key as input.

An example of an unkeyed primitive is SHA‐256 9.

5.2.2 Symmetric Key Primitives

Symmetric key primitives are cryptographic functions that assume two parties2 are in possession of a shared secret key, i.e., a bit string of variable length. To be useful this symmetric key has to be applied to a cryptographic function, such as a keyed message digest (also called message authentication code) or an encryption algorithm.

An example of a keyed message digest offering integrity services is HMAC‐SHA256 9.

When a keyed message digest is computed over a message M, often written as HMAC‐SHA256(M, K), whereby K denotes the symmetric key, then it provides integrity protection and data origin authentication. Integrity protection ensures that the message receiver can verify whether message M has been modified in transit. When the key K is known only to the sender and the receiver, then the receiver can be sure that only a particular sender computed the message digest. An example of an encryption algorithm is the Advanced Encryption Standard (AES) 10. Encryption algorithms, like AES, provide confidentiality services to ensure that messages transmitted by the sender can only be successfully decrypted by the intended recipient, who also knows the symmetric key. Since many encryption algorithms operate on blocks with a fixed length, the individual blocks need to be chained together so that their order cannot be rearranged. The mechanism of chaining the blocks together is also known as the mode of operation. An example of such a mode of operation is the Galois Counter Mode (GCM) 11.

5.2.3 Asymmetric Key Primitives

Unlike symmetric keys where the sender and the receiver share the same key, an asymmetric key primitive, also known as public key cryptography, requires that each party has two components: a public key and a private key. The private key is, as the name indicates, not shared with anyone whereas the public key is made available to everyone in an authentic fashion.

There are two main operations in public key cryptography: encryption and digital signature.

For the encryption operation, the sender uses the public key of the receiver to encrypt a message M. The encrypted message is then conveyed from the sender to the receiver, and only the corresponding private key, held by the receiver, can be used to obtain the original message M.

For the digital signature operation, the sender applies its own private key to the message M to create a digital signature of the message. The receiver verifies the integrity of the message M by using the sender's public key. If the verification is successful then the receiver can be certain that the message has been signed by the sender and that it has not been modified in transit.

An example of a popular public‐key cryptosystem is RSA, named after the inventors Rivest, Shamir, and Adleman 12. Since public key cryptography is computationally much more expensive than symmetric key cryptographic operations, many security protocols combine symmetric and asymmetric key primitives in a performance‐efficient way. For example, public‐key cryptography is used to authenticate the endpoints and to establish a fresh and unique session key. The established session key is then used with a symmetric key algorithm to secure the communication channel. Furthermore, in practical systems the above‐described digital signature algorithm is typically combined with a hash function so that the digital signature is computed over the fingerprint instead of the original message. Likewise public key encryption is used in combination with a symmetric key cryptosystem so that the public key encryption is only applied to a randomly generated symmetric key and this symmetric key is used to encrypt the content instead.

While public key cryptography seems to offer huge benefits over its symmetric counterparts, it is worth pointing out that distributing public keys in an authentic manner among all communication parties can be challenging, particularly when the number of parties increases. For this purpose the public key infrastructure (PKI) has been developed, as described in more detail below.

Once an asymmetric algorithm has been used to distribute keying material for the protection of application data, it becomes difficult for an adversary to modify or inject data. One popular attack vector is therefore the generation or distribution of the keys: if the attacker can trick a communication partner into using its own public key, a technique called man‐in‐the‐middle, then it can intercept the communication.

Hence, a logical follow‐up question is how to ensure that a public key belongs to the intended party? This question relates to the concept of trust, which is an important topic in Diameter deployments as it reflects business relationships protected by business contracts (at least in most cases). We will provide a high‐level overview in this chapter and a more detailed treatment in Section 5.5 .

As described earlier, public‐key cryptography enables the generation of digital signatures that can be generated only by the party in possession of the private key, and can be verified by anyone knowing the public key. As a result, if you have a public key that you know belongs to a legitimate party, any data you receive with a digital signature can be verified using that public key.

To bind an identifier and other attributes to the public key, the concept of a digital certificate was introduced. Table 5.1 lists several essential attributes contained inside a certificate.

Table 5.1 Essential attributes in a certificate.

AttributeDescription
SubjectIdentifier for the entity for which the certificate was created. The issuer has verified the identifier of the subject.
IssuerThe certificate creator's identifier.
Validity periodLength of time the certificate is valid.
Issuer signature algorithmAlgorithm used by the issuer to compute a digital signature over the certificate.
Issuer's signatureDigital signature computed over the certificate.
Subject Public Key InformationField containing the actual public key. The structure depends on the public key crypto‐system used.

The issuer of a certificate creates a digital signature to protect the content of that certificate. This signature creates the binding between the public key and the remaining attributes (and the identifier of the subject in particular3 ). Without such a digital signature, everyone could modify the content of the certificate and would therefore be able to modify the association between the subject and the public key.

However, this digital signature created by the issuer leads to another problem: the digital signature created by the issuer needs to be verified again. Hence, the certificate of the issuer needs to be known as well. The issuer certificate may well be digitally signed by another issuer. To terminate the process, it is important to provision TLS and IKEv2 clients and servers with a trust anchor store, which contains the certificates of issuers (so‐called root certificates or trust anchors). These trust anchors are typically self‐signed certificates of certification authorities (CAs) but may well be certificates for any other party (in case of certificate pinning). It is therefore important for a software implementation to configure the trust anchor store with those certificates that are relevant for the given task.

To provide interoperability, the certificate format and other support protocols (e.g., those used for certificate revocation) require standardization, which has taken place in the ITU‐T and the IETF. For example, the X.509 format 13 for encoding certificates has been used in TLS, the Internet Key Exchange protocol, and many other protocols. A more detailed description of certificates and the PKI can be found in Planning for PKI by Russ Housley and Tim Polk 14.

5.2.4 Key Length Recommendations

An important factor for determining the strength of symmetric and asymmetric cryptographic algorithms is the key size. The recommended length is based on several factors, including the best known attack against the algorithm family. For this reason, the recommended key length differs among the different algorithm families. Due to the increasing speed of computers and advances in cryptanalysis, key length recommendations (as well as the algorithms themselves) are adjusted from time to time.

Table 5.2 shows comparable key sizes for symmetric key algorithms and two categories of asymmetric algorithms. The values are taken from RFC 4492 15. The two categories of asymmetric algorithms are elliptic curve cryptography (ECC),4 and the RSA and Diffie–Hellman algorithms. For example, the second row in the table reads as follows: a 112‐bit symmetric key provides equivalent security to a 233‐bit ECC key and a 2048‐bit RSA key.

Table 5.2 Comparable key sizes (in bits).

Symmetric keyECCRSA/DH
80163 1024
112233 2048
128283 3072
192409 7680
25657115360

RFC 4492 provides a good illustration of what key sizes to expect when using different algorithms. Various publications, as summarized at http://www.keylength.com, offer key length recommendations. For example, key size recommendations for use with TLS‐based ciphers can be found in 16 and the authors recommend Diffie–Hellman‐based key lengths of at least 2048 bit, which corresponds to a 112‐bit symmetric key and a 233‐bit ECC key (according to the entries in Table 5.2). These recommendations are in line with those from other organizations, such as the National Institute of Standards and Technology (NIST) or the European Network and Information Security Agency (ENISA) 17. The authors of 18 note that a symmetric 80‐bit security level is sufficient for legacy applications for the coming years, but a symmetric 128‐bit security level is the minimum requirement for new systems.

5.3 Security Threats

Information conveyed in Diameter is sensitive. It consists of personal data, such as geographic location (defined in RFC 5580 19), user identifiers (such as the Network Access Identifier (NAI) 20), and account balance (specified in RFC 4006 21). It also includes security relevant information, such as keying material (e.g., RFC 7155 22, RFC 4072 23, RFC 6738 24), as well as authorization and service usage information (e.g., via accounting information). An adversary able to retrieve this data or inject new data will be able to gain information about end users (e.g., for surveillance purposes), interfere with services, reject access to services (as a denial‐of‐service attack), or commit fraud.

Since Diameter is versatile and usable in a variety of situations and applications with different security requirements, there are some intrinsic constants that help explain the security model of Diameter, starting with the actors involved in any Diameter deployment.

  • End User:

    The end user of the service does not use the Diameter protocol directly, but utilizes a service provider. The authentication interactions may be transparent for the user, for example when it is performed by hardware security modules without the user's interaction, like a mobile phone's subscriber identity module, or they may require user involvement (e.g., by having the user enter a PIN or password). For our discussion, unless specified otherwise, we will not distinguish between the human end user and his or her device, such as a mobile phone or tablet.

  • Service Provider:

    The service provider offers a specific service for users, such as Internet access, voice over IP (VoIP) services, or IPTV, and incurs costs in terms of bandwidth, service operation, hardware, etc. The service provider operates the client‐side of the AAA protocol as part of the service. Note that the service provider may offer network access as a service (which is the case of the classical use of network access authentication utilized by an Internet Service Provider (ISP)), or the service provider may offer application layer services, such as a VoIP service. It is also possible for an ISP to offer application layer services.

  • Identity Provider:

    The identity provider operates the server side of the AAA protocol and of the Diameter application. The identity provider is responsible for providing the user with credentials, processing requests forwarded from the service provider, authenticating end users, making access control decisions and forwarding authorization information to the service provider, collecting accounting records, etc. For commercial services, the accounting records are used to determine the actual service usage and consequently the service charge.

  • AAA Broker:

    The AAA broker is an intermediary that connects service providers and identity providers in larger eco‐systems. Not all deployments involve AAA brokers, but many large‐scale deployments utilize these intermediaries in order to scale their business relationships, i.e., to lower the number of contracts needed between identity providers and service providers. The functions of an AAA broker are to establish and maintain relationships between different parties (technically as well as business‐wise), to route Diameter messages, to offer security protection and privacy, to deal with fraud, to ensure that resource usage is correctly metered, and to perform financial settlement. While many AAA brokers do not publish a description of their architecture and processes, educational federations have been more transparent. An example of such an educational federation (using RADIUS) is Eduroam and a description of their infrastructure can be found in 25.

Each of these actors has different views on what is considered valuable data and how it should be protected. End users value the protection of their identity and privacy, and want to be charged correctly for their service usage. The service provider needs to keep accurate records of the service usage for billing and planning purposes. Keeping data about the service usage may also be a legal obligation for providing the service. The identity provider needs to protect the subscriber database against unauthorized access and data loss. AAA brokers are interested in ensuring the correct flow of accounting data to prevent fraud. It is worth noting that for a single end user service, several Diameter servers may be involved, with different Diameter applications, as is the case in an Long‐Term Evolution (LTE) network.

There are different adversaries to the Diameter infrastructure that need to be considered. An adversary aims to gain unauthorized access to data or attempts to inject or forge data within the AAA system. We have to assume that the entities bound by contract for the delivery of the service are trusted to fulfill their functions, meaning they will not purposely exploit the data collected for purposes other than AAA functions. In the security context, the term “trust” often has a negative connotation since trusting parties requires more entities to behave appropriately, which typically increases the attack surface. Of course, not all data in Diameter is required to be known by every entity since some Diameter payloads have only end‐to‐end significance and do not need to be processed by routing agents. However, certain Diameter payloads must be visible to all Diameter entities along the path, as explained in earlier chapters.

  • From the point of view of the end user, an adversary can:
    • Passively observe and collect data at any point along the entire communication chain (from the device to the network operator, during the service initialization and usage), in order to extract useful information such as identifiers, credentials, meta‐data about the user's communication partners, communication and mobility patterns, etc. or to replay this exchange to gain access to the service at a later time. In the context of government surveillance activities this is indeed a real threat.
    • Impersonate the service provider in order to trick the end user into sending any information that can be reused by this adversary, or at least allow this adversary to gain access to the service. This might lead to higher resource consumption, which may increase the service charge.
    • Impersonate end users to prevent them from accessing the service, or to cause the early termination of the service. This may, for example, allow the adversary to get faster Internet access or more bandwidth in a resource‐shared environment.
    • Impersonate end users in order to get access to the service, possibly after the legitimate user has ended using the service.
  • From the point of view of a service provider, an adversary can:
    • Impersonate an end user or otherwise try to gain access to the service, for example by exploiting flaws in the access control system.
    • Eavesdrop on AAA message exchanges for surveillance purposes.
    • Inject itself as a Diameter node in order to gain access to Diameter messages. This gives an adversary full control over the Diameter protocol, including access to the Diameter message content, the ability to modify messages, to inject new messages, and to control Diameter clients.
    • Disrupt the normal operation of the service (e.g., via a denial‐of‐service attack) in order to blackmail a service provider or to damage their reputation.
    • Replay previous authentication exchanges with a backend server in order to re‐authenticate a device without involving the end user.
    • Compromise the equipment of the network operator in order to get remote access to this device and to change the behaviour of the software running on this equipment.
  • From the point of view of an identity provider, an adversary can:
    • Disrupt the flow of the accounting records in order to use the service without being charged.
    • Compromise the AAA server to gain access to the subscriber data and other sensitive data stored in databases or in memory.
    • Mount a denial‐of‐service attack to make the server inaccessible.
  • From the point of view of a AAA broker, an adversary can:
    • Disrupt the routing of Diameter messages and thereby impact the service of the broker.
    • Gain unauthorized access to data stored by the AAA broker, such as accounting records.
    • Compromise the security of the AAA broker to launch an attack against service and identity providers.
    • Inject Diameter messages to cause fraudulent transactions.

All the above‐described threats can be categorized into three categories:

  1. (1) passive attacks, where an adversary simply collects and analyzes information without interfering;
  2. (2) active attacks on a communication channel, where an attacker may change the content of the packets exchanged between two parties involved in the system; and
  3. (3) active attacks on Diameter nodes participating in the system.

A short note about the threat of traffic analysis, which is a technique where an adversary is able to learn useful information of even encrypted communication interactions, for example by observing patterns in the exchange, the frequency of exchanges, unencrypted header information, or even the lack of communication. Diameter is less vulnerable to traffic analysis since Diameter links are typically encrypted and busy with messages pertaining to a large number of users and possibly many Diameter applications. Individual sessions belonging to a single user are therefore well hidden among the other Diameter messages when Diameter links are properly protected with channel security.

5.4 Security Services

In this section, we first present the security measures built into the Diameter protocol and how they address some of the threats described in the previous section. Subsequently, we discuss possible ways to mitigate generic security threats that are also applicable to Diameter deployments.

5.4.1 Diameter Security Model

As described in Chapter 2, the base Diameter specification reuses existing security protocols and exchanged data is cryptographically protected at two levels:

  1. 1. On a Diameter hop‐by‐hop basis, Diameter messages are carried between peers over network protocols that provide security features, such as mutual authentication of the peers, data confidentiality and integrity, and replay protection.
  2. 2. On an end‐to‐end basis, a Diameter AVP may contain cryptographically protected data. Such end‐to‐end protection is, however, not commonly used by Diameter applications. It is worth noting that the first version of Diameter, specified in RFC 3588 26, provided a dedicated flag in the AVP header, the “P” flag, to indicate when the AVP needed to be encrypted for end‐to‐end security. This flag was deprecated in the revision of the standard, since the initial attempt to standardize Diameter end‐to‐end security was never completed. Only recently has a new attempt to standardize an end‐to‐end security solution for Diameter been restarted, see 27.

While the Diameter specification mandates that hop‐by‐hop security is provided by a lower layer protocol, it offers the option to use either IPsec, combined with IKE or IKEv2 for key management, or preferably TLS or DTLS. We will discuss these alternatives below. Note that it is important to compare the identities exchanged by these security protocols with the DiameterIdentity – the same way a web browser compares the URL entered by a user with the identity received in the certificate sent by the server during the TLS exchange. A browser issues a security alert in case of mismatch – and to make sure that the remote peer, even when presenting valid credentials, is authorized to join your Diameter network. RFC 6125 28 goes into great detail on how to verify and represent application service identities within the Internet PKI using X.509 (PKIX) certificates in the context of TLS.

5.4.1.1 Secure Transports

Modern communication security protocols operate in two phases: a computationally expensive handshake phase followed by a phase that makes use of symmetric key cryptography to efficiently protect application data. The latter phase consists of the data exchanged by the endpoints of the protocol – the payload from the point of view of the protocol – where the security properties, such as confidentiality or authenticity, are cryptographically enforced. The handshake phase is dedicated to the setup and management of the cryptographic keying material and parameters for the bulk data protection, such as mutual authentication of the endpoints, key derivation, negotiation and establishment of the security parameters, rekeying, etc. At the transport layer the Transport Layer Security (TLS) protocol is widely used nowadays to protect HTTP exchanges on the web, commonly referred to as HTTPS – technically, HTTP over TLS. TLS is a layered protocol that consists of several sub‐protocols, including a handshake protocol and a record layer protocol. TLS can only be used over a transport protocol that provides reliable and ordered delivery of the data, such as TCP. To also offer communication security services for unreliable transport protocols like UDP, the Datagram Transport Layer Security (DTLS) protocol was designed, which is strongly inspired by TLS. SCTP is another transport protocol, younger than TCP and UDP. SCTP is a reliable protocol – all data sent on one side will be delivered on the other side, or an error reported – that provides to applications fine control over the ordering of the data delivered: data chunks can be sent unordered, as in UDP, or ordered within streams that are independent, as if parallel TCP connections were established, but with less overhead. In addition, SCTP supports multiple IP addresses for each endpoint, which makes it more resistant to network failures. The initial version of Diameter in RFC 3588 26 mandated TLS to be used to protect SCTP links. In that case a separate TLS context must be established for each SCTP stream, which is highly resource consuming. RFC 6733 29 resolved this issue by promoting DTLS over SCTP instead of TLS. For the use of TCP, the choice of TLS remained unchanged. SCTP is the transport protocol of choice for Diameter as its ordering granularity and resilience to network failures are interesting properties for AAA traffic. However, it is also a complex and relatively new protocol (at least compared to TCP), and the configuration of firewalls may be more complex. The combination of TLS over TCP is more commonly deployed than DTLS over SCTP in the industry today. From this point on, we will use the term (D)TLS when referring to either TLS over TCP or DTLS over SCTP, for the sake of simplicity.

RFC 3588 stated that, if a Diameter connection was not protected by IPsec, then the CER/CEA exchange needs to include an Inband‐Security‐Id AVP with a value of TLS. The TLS handshake would begin after completion of the CER/CEA exchange. This behavior has been deprecated by RFC 6733. However, TLS may still be negotiated via this Inband‐Security‐Id AVP to support older Diameter implementations. RFC 6733 introduced another important change with the allocation of a dedicated port for (D)TLS‐protected connections. In RFC 3588, a single port was used for all connections, and the TLS protection was started only after the capability exchange step, through negotiation. This method opened the door to downgrading attacks, where an attacker would be able to trick the Diameter peers to not use TLS. As a result, the revised method uses a dedicated port where (D)TLS handshake takes place immediately after connection establishment and before the Diameter capability exchange. The Diameter capability exchange is therefore protected as well. With this design the Diameter identity of the remote peer may not be known at the time of the (D)TLS handshake. Therefore, a Diameter implementation needs to store the authenticated identity and to compare this value with the identity presented during capability exchange. A connection needs to be terminated in case of mismatch. Failure to enforce this binding would enable a Diameter peer to impersonate another peer, possibly from another domain. Diameter can be used over a non‐secure transport protocol, TCP or SCTP, if the security is implemented at the IP layer, using IPsec ESP 7. IPsec ESP offers bulk data encryption and a separate handshake protocol, namely Internet Key Exchange version 2 (IKEv2). From the point of view of communication security, IPsec+IKEv2 and (D)TLS offer the same security services but the design details of the two protocols vary considerably. It is, however, worth noting that (D)TLS security is implemented in applications in modern systems, while IPsec comes as a system service, for example for management of system‐wide VPN connections. Therefore, choosing IPsec in a Diameter deployment might, from a software design point of view, create additional challenges for enforcing the binding between the authenticated identity in the IKEv2 exchange and the Diameter Identity presented by a peer. Furthermore, when using SCTP with its multi‐homing support, the configuration of IPsec may become challenging.

5.4.1.2 Authorization

It is not sufficient to ensure that a remote peer presents a valid credential, and an explicit authorization check must be performed on all Diameter peers to make sure that each peer, with credential matching its Diameter identity, is allowed to join the Diameter network.

For a single administrative domain this authorization check can be implemented, for example, by whitelisting peers in configuration files. It becomes a maintenance burden when such whitelists have to be extended to connections that span separately administered domains. Using a dedicated public key infrastructure for the Diameter network is more efficient: a specific certification authority (CA) issues certificates to be used only by Diameter peers in the domain, independent of certificates used by other services. This works reliably when all Diameter peers are configured to accept certificates signed only by this dedicated CA, the trust anchor for the Diameter domain, and accept no other CA certificates – most operating systems are configured with a long list of trust anchors that need to be ignored by a Diameter stack.

As with any PKI‐based model, it is important for an implementation to ensure that

  • Path validation for certificates in IKEv2 or (D)TLS stacks is performed,
  • The validity for all certificates in the chain between the CA certificate and the certificate presented by the remote party is checked,
  • X.509v3 extensions are verified, in particular that all intermediate CA certificates are authorized to issue certificates,
  • The revocation status of all certificates in the chain, using a certificate revocation list (CRL) or an Online Certificate Status Protocol (OCSP) responder 30, is verified.

Fortunately, these security checks are usually performed by the security protocol stack, and a Diameter implementation generally needs only to enforce the binding between the identity used for authentication and the Diameter Identity.

5.4.2 Relation to Threats

The security model of Diameter described previously aims to provide the following assurances:

  • The communication between two Diameter peers is cryptographically protected. This protection includes authentication, confidentiality, replay, and integrity protection.
  • All peers joining the Diameter network are legitimate entities involved in the business relationship covering the provision of a service. This insurance is provided partly by the mutual authentication at the cryptography level, and partly by the explicit authorization step.

The threats identified in Section 5.3 related to end users are not addressed by these security services. This is somewhat expected since the end user (or the device of the end user) is not directly involved in the Diameter exchange. The threats related to passive attackers are properly addressed, provided that cryptography is configured with appropriate algorithms and key lengths. The threats related to active attacks against the communication channel are addressed as well, provided that the mutual authentication and authorization of the Diameter peers is performed.

5.4.3 Mitigating Other Threats

By following the security recommendations from this chapter, the possible attacks to Diameter links, passive or active, are mitigated. Remaining from our initial threat description are the attacks on the Diameter endpoints themselves and on the end user of the service.

Attacks on Diameter endpoints encompass both remote and physical attacks on the equipment where the Diameter stack is running. The target can be the Diameter stack itself, the operating system where this stack is running, or any other entry point on this system. The mitigation of such a threat is not specific to Diameter. The following rules help to limit the risks:

  1. 1. Reduce the attack surface by limiting the number of services running on the entities that run Diameter.
  2. 2. Install security patches and install OS and Diameter stack security updates from reliable sources.
  3. 3. Limit the access from the outside world using a firewall; only Diameter ports should be open.
  4. 4. For Diameter stack developers, follow practices of secure software development. This includes penetration testing, peer review of source code, and static code analysis.
  5. 5. For nodes that store user‐specific data ensure protection against unauthorized access.
  6. 6. Limit the physical access to the equipment as much as possible.
  7. 7. Protect the private key corresponding to the certificate used for mutual authentication. Make sure the key is generated in a secure way – if an attacker can predict the key, cryptography is useless 31.
  8. 8. Rotate the key periodically and follow the latest recommendations in terms of key lengths and algorithms.

The mitigation of the threats to the end user is dependent on the service and the network access technology. In the case of IEEE 802.11i 32, for example, EAP is used during the authentication step, allowing mutual authentication between the end user device and the service provider. At the end of a successful authentication, a key is generated and transported from the service provider to the network operator equipment over AAA protocol. This key is used to bootstrap the security of the channel between the end user's device and the network equipment, effectively binding this security to the authentication and preventing all the threats that we described on a shared access medium such as WiFi.

In addition to these considerations, there are more intrinsic methods that help prevent information leakage, mostly of interest for Diameter application developers. For example, RFC 4962 33 describes how key material must be handled in an AAA protocol to limit the security risks, and RFC 6973 3 gives good recommendations for preserving the privacy in Internet protocols.

5.5 PKI Example Configuration in freeDiameter

In this section we explain how to secure freeDiameter using the guidance provided in this chapter. The freeDiameter implementation, similar to many commercial products, supports TLS protection of Diameter communication by using GnuTLS, an open source TLS implementation. Many TLS stacks are designed with the use of securing Web traffic in mind and hence they typically offer a wide range of features.5

The ability to protect SCTP using TLS, as specified in RFC 3588, is offered by freeDiameter. However, this approach requires a lot of resources when a large number of streams are used. The alternative, namely to protect SCTP with DTLS, is work in progress in freeDiameter and not available at the time of writing.

5.5.1 The Configuration File

The good news is that configuring TLS in freeDiameter is easy since there is only a handful of configuration parameters. For extra customization we describe the freeDiameter configuration file in detail in Section B.7.

  • Certificate and Private Key:

    Each Diameter peer needs to possess a certificate along with the private key since we use asymmetric cryptography in our example. The most important configuration parameter is therefore the path to this X.509 certificate and to the corresponding private key. This key pair will be used to authenticate the Diameter peer. The path is specified with the TLS_Cred parameter. It is important to note that the CN (Common Name) field of the certificate must match the DiameterIdentity of the peer. Both files should be PEM‐encoded. Protecting the private key with a password is currently not supported in freeDiameter.

  • Trust Anchors:

    The path to one or more trust anchor(s) is configured using the TLS_CA parameter. The trust anchor should be PEM‐encoded and by default the trust anchor store is empty. Only incoming TLS connections authenticated with a certificate anchored in one of the specified trust anchors will be accepted. Of course, other security checks may lead to a certificate verification failure, for example if the DiameterIdentity of a peer does not match the common name in the certificate, or if the certificate has expired.

  • Certificate Revocation Lists:

    freeDiameter has support for certificate revocation lists (CRLs) that help protect the network when a certificate is revoked, for example when the private key is compromised. The TLS_CRL parameter specifies the path to the CRL.6 This configuration can be omitted if the CRL feature is not used.

  • Ciphersuites:

    The TLS_Prio parameter enables fine control over the TLS ciphersuite selection. The TLS ciphersuites concept defines a combination of cryptographic algorithms, key sizes, and key exchange methods.

To display the configuration file, type the following command on server.example.net:

image

The configuration file has the following content:7

In this configuration we are not using the CRL feature. The ConnectPeer parameter serves three purposes:

image
  • authorizes a peer with identity client.example.net to join the Diameter network,
  • establishes a connection to this peer periodically, and
  • uses TCP for connection attempts.

5.5.2 The Certificate

The certificate shown below can be found in the test directory on server.example.net (look for cert.pem), and is an example of what is described in Table 5.1 of Section 5.2 . Here we show an X.509v3 certificate with the serial number 3 that was issued by the certification authority with the name freediameter.example.net based on information found in the Common Name (CN) of the Issuer attribute. Unless specified explicitly, the DiameterIdentity is automatically configured by freeDiameter from the FQDN. This certificate is valid from 3 February 2014 at 14:56:49 GMT to 1 February 2024 at 14:56:49 GMT. The Subject contains the identity of this server (server.example.net) in the CN attribute. The Subject Public Key Info field specifies the RSA parameters. Various X.509v3 extensions are followed by the digital signature computed by the issuer. The Basic Constraints field indicates that this is not a CA certificate, i.e., it cannot be used by server.example.net to issue further certificates. The Key Usage field indicates permissions, namely the use of the key for digital signatures, key encipherment, and non‐repudiation. Code signing, for example, is not allowed with this certificate.

r01g001

 Certificate:  Data:    Version: 3 (0x2)    Serial Number: 3 (0x3)  Signature Algorithm: sha1WithRSAEncryption    Issuer: CN=freediameter.example.net    Validity      Not Before: Feb 3 14:56:49 2014 GMT      Not After : Feb 1 14:56:49 2024 GMT    Subject: CN=server.example.net    Subject Public Key Info:      Public Key Algorithm: rsaEncryption        Public-Key: (1024 bit)        Modulus:          00:ac:48:db:a6:a7:2d:4f:86:fd:db:58:22:0d:b6:          33:d5:e6:80:f5:1f:c8:75:a6:98:c5:34:08:02:f1:          c9:23:d6:27:e5:f6:cf:87:7d:3c:b9:4a:cf:6f:88:          f1:2c:ed:bb:05:db:d9:ef:f9:e9:4f:41:5d:0e:4c:          97:14:93:e4:15:4e:95:1c:69:50:00:7d:21:70:dd:          ca:4a:6e:aa:a4:98:77:eb:0f:db:c8:aa:9c:92:50:          e3:c7:a1:fe:2c:3a:c7:f3:45:62:30:6b:47:25:e3:          6d:38:9b:87:7d:f8:e6:f5:ef:08:8c:fc:ee:46:19:          87:e6:58:42:d9:dd:8d:13:09        Exponent: 65537 (0x10001)    X509v3 extensions:      X509v3 Basic Constraints:        CA:FALSE      X509v3 Key Usage:        Digital Signature, Non Repudiation,        Key Encipherment      X509v3 Subject Key Identifier:        C7:AE:A0:EF:04:72:4A:8E:EB:47:A3:7A:9C:0E:51:        D3:2D:67:DF:BB      X509v3 Authority Key Identifier:        keyid:5F:86:3C:1D:7E:EC:13:9F:B1:E3:B8:B6:50:        6D:FB:47:EE:A3:9E:F5  Signature Algorithm: sha1WithRSAEncryption     aa:c6:0a:e9:81:52:1e:e4:5b:99:2b:ee:ac:2c:fc:d3:e8:0a:     f1:9f:6c:10:36:19:f0:d2:e3:bc:45:f5:82:93:18:f8:da:1a:     2c:71:1c:33:42:98:40:4a:cc:49:b2:df:36:e3:49:e0:cb:88:     f7:6d:d5:89:3f:5d:97:14:4b:6d:a1:fe:cf:9e:fc:4a:20:b8:     e6:a8:1a:27:55:a0:b3:00:26:0f:53:76:6c:3f:f6:82:e9:f5:     4a:1b:23:69:d8:f8:a5:86:f6:69:8e:42:e6:7b:92:57:85:dc:     d0:2f:7d:34:5d:f4:96:7e:4b:35:d6:3e:64:f3:d4:0e:aa:a1:     f8:d3 [ Another 128 bytes skipped ]

5.5.3 Protecting Exchanges via TLS

This section offers hands‐on experiments to show TLS with different configuration settings.

To run these tests you have to set up the virtual environment, as described in Section A.6, and client.example.net and server.example.net must be ready to use. The instructions in Section A.6 prepare the appropriate environment.

  1. 1. Prepare the network configuration profile for the server.example.net VM:
    image
  2. 2. Configure freeDiameter for the TLS experiment:
    image
  3. 3. Display the FQDN of server.example.net:
    image
  4. 4. Display the certificate subject name to ensure it matches the FQDN:
    image
  5. 5. Run freeDiameter:
    image
  6. 6. Configure and start the client with the following commands on client.example.net:
    image

    When we start the daemon on the client machine, a connection is successfully established and the two peers start exchanging periodic messages:

    image

    From the debugging output in the log file it is difficult to determine whether the connection is actually TLS protected. An easy way to check is to run Wireshark, a network protocol analyzer that captures protocol traffic from a network interface.

  7. 7. Open another terminal window on the server.example.net VM.
  8. 8. In the terminal window, type the following command to verify whether the connection is encrypted:
    image

    You may see an error mentioning the programming language Lua, and a warning about running Wireshark as the root user. Since we are not using any Lua scripting with Wireshark, we can ignore the warning. When a DWR/DWA exchange occurs, you will see the following on the screen:

    image

    Wireshark is only able to show the unencrypted parts of the TLS 1.2 handshake.

  9. 9. To stop the exercise, type Ctrl‐C in the terminal windows running freeDiameter and Wireshark.

5.5.3.1 Common Name and Hostname Mismatch

If the content of the Subject: CN attribute given in the certificate does not match the hostname used in freeDiameter, then the certificate will be rejected by freeDiameter. To verify this failure scenario, enter the following commands on the server.example.net machine, which will change the CN to client.example.net:

  1. 1. Reconfigure server.example.net for this experiment:
    image
  2. 2. Verify that the FQDN of server.example.net is indeed server.example.net:
    image
  3. 3. Note that its CN in the certificate is client.example.net:
    image
  4. 4. Start freeDiameter:
    image

    The following information will be displayed:

    image

5.5.3.2 Unprotected Exchanges

While it is strongly advised to use TLS protection for operating a Diameter network, it is sometimes convenient to disable the use of TLS during the software development to see protocol exchanges over the wire. This may simplify debugging in certain situations.

freeDiameter was designed to encourage users to configure TLS; as a result it is slightly more difficult to disable TLS than to enable it. The TLS configuration has to be performed globally, as we have seen above. It can be disabled for each connection individually by editing the configuration file.

It is not necessary to hand‐edit the configuration file for this exercise. We have created a configuration for you that can be applied to the VMs.

  1. 1. Apply the configuration settings to the server machine:
    image
  2. 2. Apply the configuration settings to the client machine:
    image
  3. 3. To see that TLS has been disabled, view the configuration file on the client machine:
    image
  4. 4. Run freeDiameter on both the server and client machines:
    image

    The log now contains a message highlighting that TLS is not used with that peer.

  5. 5. Open another terminal window on the server machine and run Wireshark again:
    image

    We can now see the Diameter messages clearly:

    image

    If you do not see these messages and Wireshark instead prints only TCP requests and responses then Wireshark needs to be told to interpret these messages as Diameter payloads. Please consult the Wireshark manual for the “decode as” functionality.

  6. 6. To stop the exercise, type Ctrl‐C in the terminal windows running freeDiameter and Wireshark.

5.5.3.3 Certificate Revocation

The next example shows how the CRL list specified in the configuration file can be used to communicate certificates that have been revoked.

  1. 1. Configure the client.example.net machine as follows:
    image
  2. 2. Verify that the CRL is configured:
    image

    Let us assume that the private key stored on server.example.net has been compromised. Consequently, the CA has to revoke the corresponding certificate. Subsequently, a new certificate would be created and the revoked certificate is added to the CRL list.

  3. 3. Configure the server.example.net machine to use a certificate that has been revoked. An attacker gaining access to the compromised private key would in effect present himself with a similar setup to join the Diameter network:
    image
  4. 4. Check the certificate being used:
    image
  5. 5. Run freeDiameter on both the client and server machines.
    image

    We can confirm that the connection is rejected on the client.example.net machine:

    image
  6. 6. To stop the exercise, type Ctrl‐C in the terminal windows running freeDiameter and Wireshark.

As an exercise, you can confirm that removing the TLS_CRL parameter from the client configuration file and then restarting the test will allow the two peers to successfully establish a connection.

For a real‐world deployment it is important to think about how the case of compromised keys would be handled, including how impacted customers and users would be notified. CRLs and OCSP are two standardized mechanisms offering a method of certificate revocation. They are, however, not a solution for modifying the trust anchor store. Modifying the trust anchor store can be accomplished using software updates, network management protocols, or even using the Trust Anchor Management Protocol (TAMP) 34. In any case, a product has to provide an answer for revoking certificates and for modifying the trust anchor store.

5.6 Security Evolution

Internet security is constantly evolving: new security threats arise, security solutions change, and cryptanalysis advances. The recommendations we give in this book are based on the state of the art in 2018, therefore the reader is strongly encouraged to consult the IETF DIME working group pages 35 for the latest specifications, information on our website at https://diameter‐book.info for updates, and new releases of the freeDiameter implementation.

For recommendations on the use of new ciphersuites in TLS consult the IETF working group. In addition, the Internet Engineering Research Task Force (IRTF) Crypto Forum Research Group (CFRG) at https://irtf.org/cfrg is a valuable resource for guidance on algorithms.

References

  1. 1 E. Rescorla and IAB. Writing Protocol Models. RFC 4101, Internet Engineering Task Force, June 2005.
  2. 2 E. Rescorla and B. Korver. Guidelines for Writing RFC Text on Security Considerations. RFC 3552, Internet Engineering Task Force, July 2003.
  3. 3 A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, and R. Smith. Privacy Considerations for Internet Protocols. RFC 6973, Internet Engineering Task Force, July 2013.
  4. 4 802.1X‐2010 – IEEE Standard for Local and Metropolitan Area Networks: Port‐Based Network Access Control, May 2010.
  5. 5 802.1AE‐2006 – IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Security, June 2006.
  6. 6 E. Rescorla. SSL and TLS: Designing and Building Secure Systems. Addison Wesley, 2001.
  7. 7 S. Frankel and S. Krishnan. IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. RFC 6071, Internet Engineering Task Force, Feb. 2011.
  8. 8 C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen. Internet Key Exchange Protocol Version 2 (IKEv2). RFC 7296, Internet Engineering Task Force, Oct. 2014.
  9. 9 D. Eastlake 3rd and T. Hansen. US Secure Hash Algorithms (SHA and SHA‐based HMAC and HKDF). RFC 6234, Internet Engineering Task Force, May 2011.
  10. 10 National Institute of Standards and Technology. FIPS 197, Advanced Encryption Standard (AES), pages 1–51, Nov. 2001.
  11. 11 M. Dworkin. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, National Institute of Standards and Technology SP 800‐ 38D, Nov. 2007.
  12. 12 R. Rivest, A. Shamir, and L. Adleman. A Method for Obtaining Digital Signatures and Public‐Key Cryptosystems. Communications of the ACM, 21:120–126, 1978.
  13. 13 D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280, Internet Engineering Task Force, May 2008.
  14. 14 R. Housley and T. Polk. Planning for PKI: Best Practices for Deploying Public Key Infrastructure. Wiley, 2001.
  15. 15 S. Blake‐Wilson, N. Bolyard, V. Gupta, C. Hawk, and B. Moeller. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). RFC 4492, Internet Engineering Task Force, May 2006.
  16. 16 D. Handerson, A. J. Menezes, and S. Vanstone. Guide to Elliptic Curve Cryptography. Springer, 2004.
  17. 17 ENISA. Algorithms, Key Sizes and Parameters Report – 2013, Oct. 2013. http://www.enisa.europa.eu/activities/identity‐and‐trust/library/deliverables/algorithms‐key‐sizes‐and‐parameters‐report.
  18. 18 Y. Sheffer, R. Holz, and P. Saint‐Andre. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). RFC 7525, Internet Engineering Task Force, May 2015.
  19. 19 H. Tschofenig, F. Adrangi, M. Jones, A. Lior, and B. Aboba. Carrying Location Objects in RADIUS and Diameter. RFC 5580, Internet Engineering Task Force, Aug. 2009.
  20. 20 B. Aboba, M. Beadles, J. Arkko, and P. Eronen. The Network Access Identifier. RFC 4282, Internet Engineering Task Force, Dec. 2005.
  21. 21 H. Hakala, L. Mattila, J.‐P. Koskinen, M. Stura, and J. Loughney. Diameter Credit‐Control Application. RFC 4006, Internet Engineering Task Force, Aug. 2005.
  22. 22 G. Zorn. Diameter Network Access Server Application. RFC 7155, Internet Engineering Task Force, Apr. 2014.
  23. 23 P. Eronen, T. Hiller, and G. Zorn. Diameter Extensible Authentication Protocol (EAP) Application. RFC 4072, Internet Engineering Task Force, Aug. 2005.
  24. 24 V. Cakulev, A. Lior, and S. Mizikovsky. Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers. RFC 6738, Internet Engineering Task Force, Oct. 2012.
  25. 25 K. Wierenga, S. Winter, and T. Wolniewicz. The eduroam Architecture for Network Roaming. RFC 7593, Internet Engineering Task Force, Sept. 2015.
  26. 26 P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. Diameter Base Protocol. RFC 3588, Internet Engineering Task Force, Sept. 2003.
  27. 27 H. Tschofenig, J. Korhonen, G. Zorn, and K. Pillay. Security at the Attribute‐Value Pair (AVP) Level for Non‐neighboring Diameter Nodes: Scenarios and Requirements. RFC 7966, Internet Engineering Task Force, Sept. 2016.
  28. 28 P. Saint‐Andre and J. Hodges. Representation and Verification of Domain‐Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). RFC 6125, Internet Engineering Task Force, Mar. 2011.
  29. 29 V. Fajardo, J. Arkko, J. Loughney, and G. Zorn. Diameter Base Protocol. RFC 6733, Internet Engineering Task Force, Oct. 2012.
  30. 30 S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP. RFC 6960, Internet Engineering Task Force, June 2013.
  31. 31 D. Eastlake 3rd, J. Schiller, and S. Crocker. Randomness Requirements for Security. RFC 4086, Internet Engineering Task Force, June 2005.
  32. 32 IEEE. 802.11i‐2004 – IEEE Standard for Information Technology – Telecommunications and Information Exchange Between Systems – Local and Metropolitan Area Networks – Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Medium Access Control (MAC) Security Enhancements, July 2004.
  33. 33 R. Housley and B. Aboba. Guidance for Authentication, Authorization, and Accounting (AAA) Key Management. RFC 4962, Internet Engineering Task Force, July 2007.
  34. 34 R. Housley, S. Ashmore, and C. Wallace. Trust Anchor Management Protocol (TAMP). RFC 5934, Internet Engineering Task Force, Aug. 2010.
  35. 35 IETF. Diameter Maintenance and Extensions (DIME), Mar. 2014. http://datatracker.ietf.org/wg/dime/charter/.

Notes

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset