RTP: Audio and Video for the Internet

There are two types of authentication: proof that the packets have not been tampered with, known as integrity protection , and proof that the packets came from the correct source, known as source origin authentication .

Integrity protection is achieved through the use of message authentication codes. These codes take a packet to be protected, and a key known only to the sender and receivers, and use these to generate a unique signature. Provided that the key is not known to an attacker, it is impossible to change the contents of the packet without causing a mismatch between the packet contents and the message authentication code. The use of a symmetric shared secret limits the capability to authenticate the source in a multiparty group : All members of the group are able to generate authenticated packets.

Source origin authentication is a much harder problem for RTP applications. It might first be thought equivalent to the problem of generating message authentication codes, but it is more difficult because a shared secret between sender and receiver is not sufficient. Rather, it is necessary to identify the sender in the signature, meaning that the signature is larger and more expensive to compute (in much the way public key cryptography is more expensive than symmetric cryptography). This requirement often makes it infeasible to authenticate the source of each packet in an RTP stream.

Like confidentiality, authentication can be applied at either the application level or the IP level, with much the same set of advantages and disadvantages. Both alternatives have been developed for use with RTP.

Authentication Using Standard RTP

Standard RTP provides no support for integrity protection or source origin authentication. Implementations that require authentication should either implement secure RTP or use a lower-layer authentication service such as that provided by the IP security extensions.

Authentication Using the Secure RTP Profile

SRTP supports both message integrity protection and source origin authentication. For integrity protection, a message authentication tag is appended to the end of the packet, as was shown in Figure 13.4. The message authentication tag is calculated over the entire RTP packet and is computed after the packet has been encrypted. At the time of this writing, the HMAC-SHA-1 integrity protection algorithm is specified for use with SRTP. Other integrity protection algorithms may be defined in the future, and negotiated for use with SRTP.

Source origin authentication using the TESLA (Timed Efficient Stream Loss-tolerant Authentication) authentication algorithm has been considered for use with SRTP, but TESLA is not fully defined at the time of this writing. You are advised to consult the SRTP specification, when it is completed, for details.

The authentication mechanisms of SRTP are not mandatory, but I strongly recommend that all implementations use them. In particular, you should be aware that it is trivially possible for an attacker to forge data encrypted using AES in counter mode unless authentication is used. The secure RTP profile specification describes this issue in detail.

Authentication Using IP Security

The IP security extensions can provide integrity protection and authentication for all packets sent from a host. There are two ways this can be done: as part of the encapsulating security payload, or as an authentication header.

The Encapsulating Security Payload was described earlier, in the section titled Confidentiality Using IP Security. As shown in Figure 13.9, ESP includes an optional authentication data section as part of the trailer. If present, the authentication provides a check on the entire encapsulated payload, plus the ESP header and trailer. The outer IP header is not protected.

An alternative to ESP is the Authentication Header (AH) defined in RFC 2402 ¹⁸ and shown in Figure 13.11. The fields in this header are much like their counterparts in ESP, and the AH can be used in both tunnel mode and transport mode. The key difference is that the entire packet is authenticated, including the outer IP header.

If the requirement is to provide confidentiality as well as authentication, then ESP is appropriate (using ESP to encrypt and AH to authenticate would lead to excessive bandwidth overheads). If the only requirement is authentication ”not confidentiality ”then the choice between ESP and AH depends on whether it is considered necessary to authenticate the outer IP header. Authentication of the outer header provides some additional security, by ensuring that the source IP address is not spoofed. It also has the side effect of rendering Network Address Translation impossible.

A range of authentication algorithms may be used with IP security. If authentication is used, the mandatory algorithms for both ESP and AH are HMAC-MD5-96 and HMAC-SHA-96, ^{19 , 20} which provide integrity protection only. Algorithms for source origin authentication may be defined in the future.

The earlier section titled Confidentiality Using IP Security noted potential interactions between IP security and header compression, firewalls, and NAT boxes. These issues also apply when IP security is used to provide authentication.

The IP security protocol suite includes an extensive signaling protocol, the Internet Key Exchange (IKE), which is used to set up the necessary parameters and authentication keys. The details of IKE are beyond the scope of this book.