Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
obsoletes
- rfc-4572 — Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
updated by
- rfc-8844 — Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)
Extracted elements (23)
Fingerprint bytes are encoded as uppercase hex separated by colons (openssl/browser style) rather than lowercase unseparated hex (HTTP digest style) because consistency with other certificate fingerprint applications was considered more important than consistency with HTTP digest authentication.
Multiple fingerprints per 'm' line are allowed to support hash agility and scenarios where multiple certificates may be used (e.g., separate certificates for RTP and RTCP) or where the specific certificate to be used is not known at fingerprint exchange time.
Self-signed certificates are permitted because many endpoints have dynamic IP addresses and cannot practically obtain CA-signed certificates. Security is maintained by including a secure hash (fingerprint) of the certificate in the SDP description, so that if SDP integrity is assured, even self-signed certificates can be trusted.
Including a fingerprint calculated using the same hash function as the certificate's signature algorithm ensures interoperability with strict RFC 4572 implementations. Either this or the SHA-256 fingerprint MAY be omitted if a stronger hash known to be supported by the peer is included.
This document obsoletes RFC 4572 but remains backwards compatible with older implementations. Key changes include clarified handling of multiple fingerprints, updated preferred hash from SHA-1 to SHA-256, and deprecation of MD2 and MD5.
An endpoint acting as the TLS server (setup:passive role) MUST present a certificate during TLS initiation. If the certificate does not match the original fingerprint, the client endpoint MUST terminate the media connection with a bad_certificate error.
An endpoint MUST, as a minimum, calculate a fingerprint using both the 'SHA-256' hash function algorithm and the hash function used to generate the signature on the certificate for each possible certificate.
An endpoint MUST select the set of fingerprints using its most preferred hash function (out of those offered by the peer) and verify that each certificate used matches one fingerprint out of that set. If a certificate does not match any such fingerprint, the endpoint MUST NOT establish the TLS connection.
An 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using an fmt identifier to indicate the application being run over TLS.
Endpoints MUST provide a certificate fingerprint to associate media streams with connections and prevent unauthorized barge-in attacks. If the X.509 certificate presented for the TLS connection matches the fingerprint in the SDP, the endpoint can be confident that the author of the SDP is the initiator of the connection.
If fingerprints associated with multiple certificates are calculated, the same set of hash functions MUST be used to calculate fingerprints for each certificate associated with the 'm' line.
If the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume data transmitted over TLS is valid until it has received a matching fingerprint in an SDP answer.
If the SDP is not integrity-protected, the certificate provided for a TLS connection MUST certify an appropriate identity: either the SDP connection address (IP or FQDN) or the identity of the creator of the SDP message. Wildcard patterns MUST NOT be used in certificate matching.
Implementations MUST NOT use MD2 and MD5 hash functions to calculate fingerprints or to verify received fingerprints calculated using them. SHA-256 is the preferred hash function.
When using the SDP offer/answer model, the client (setup:active role) MUST also present a certificate. The server MUST request a certificate; if the client does not provide one, or if it does not match a fingerprint, the server MUST terminate the connection with a bad_certificate error.
The 'TCP/TLS' SDP protocol identifier indicates that the media described will use TLS over TCP. An 'm' line specifying 'TCP/TLS' MUST further qualify the protocol using a fmt identifier to indicate the application being run over TLS.
IANA maintains the 'Hash Function Textual Names' registry for certificate fingerprint hash functions. New entries require a textual name, OID as used in X.509 certificates, and a reference to a Standards Track RFC that updates or obsoletes RFC 3279.
IANA registered the 'TCP/TLS' proto value under the 'proto' registry within the 'Session Description Protocol (SDP) Parameters' registry, and the 'fingerprint' attribute under the 'att-field (both session and media level)' registry.
Hop-by-hop integrity protection (e.g., SIPS, SIP over TLS) is considered sufficient to allow accepting any syntactically valid certificate identity, but this mode is vulnerable to attacks by compromised or malicious middleboxes such as SIP proxy servers.
The encapsulating application protocol (e.g., SIP) is responsible for ensuring the integrity of SDP security descriptions. It SHOULD either invoke its own security mechanisms or utilize a lower-layer security service providing strong message authentication and effective replay protection. Without SDP integrity, the mechanism is vulnerable to man-in-the-middle attacks on first contact (similar to SSH trust-on-first-use).
When a certificate received over SIP asserts an identity other than the one to which the call was placed or received, the endpoint SHOULD alert the user and ask for confirmation, regardless of whether the certificate is self-signed or CA-signed.
When SDP integrity cannot be assured, endpoints SHOULD maintain a cache of previously seen certificates and SHOULD warn users when a new or changed certificate is presented, providing SSH-like protection against subsequent man-in-the-middle attacks.
The fingerprint attribute is encoded as 'fingerprint:<hash-func> <fingerprint>' where the fingerprint is a sequence of uppercase hexadecimal bytes separated by colons. The hash-func field identifies the hash function (e.g., sha-256, sha-1) and the fingerprint field encodes the DER-form certificate hash.