Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
obsoleted by
- rfc-8122 — Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
updates
- rfc-4145 — TCP-Based Media Transport in the Session Description Protocol (SDP)
Extracted elements (27)
Self-signed certificates are necessary because many endpoints (e.g., SIP phones) have dynamically configured IP addresses and near-zero-configuration deployment requirements, making CA-signed certificates impractical. The fingerprint mechanism allows self-signed certificates to be used securely provided the SDP description's integrity is assured.
The fingerprint attribute may appear at session level or media level. A session-level fingerprint applies to all TLS sessions for which no media-level fingerprint is defined, allowing a single fingerprint to cover multiple media streams without repetition.
The fingerprint hex encoding uses uppercase bytes separated by colons (the OpenSSL and browser certificate manager convention) rather than unseparated lowercase hex (as used in HTTP Digest authentication). Consistency with existing certificate fingerprint display tools was considered more important than consistency with HTTP Digest.
Authentication certificates used in TLS sessions are X.509 certificates as profiled by RFC 3279, RFC 3280, and RFC 4055. Certificate identity matching follows the matching rules of RFC 3280; if multiple identities of a given type exist in the certificate, a match in any one is acceptable.
Media sessions using the TCP/TLS protocol identifier follow all procedures defined in RFC 4145, including the 'setup' and 'connection' SDP attributes. RFC 4572 extends RFC 4145 by adding TLS-specific requirements on top of the base connection-oriented media transport framework.
When offer/answer is not used (e.g., sessions announced via SAP), there is no secure channel for clients to communicate certificate fingerprints to servers. In this case, servers MAY request client certificates (which SHOULD be CA-signed) or MAY allow clients to connect without a certificate.
A certificate fingerprint MUST be computed using the same one-way hash function as is used in the certificate's signature algorithm. This ensures that the security properties required for the certificate also apply to the fingerprint.
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 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using a fmt identifier to indicate the application being run over TLS.
Endpoints MUST provide a certificate fingerprint to associate media streams with connections and to 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.
Hash functions used in the Hash Function Textual Names registry MUST be defined by standards-track RFCs that update or obsolete RFC 3279. When registering a new hash function, the textual name, OID as used in X.509 certificates, and a reference to the RFC must be provided.
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 that data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer.
Self-signed certificates MUST use one of the FIPS 180 algorithms (SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and thus also MUST use one of these to calculate certificate fingerprints.
To support the use of certificate caches, endpoints SHOULD consistently provide the same certificate for each identity they support.
When 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 via subjectAltName) or the identity URI of the SDP creator. Wildcard patterns MUST NOT be used in certificate identity matching.
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 the fingerprint, the server MUST terminate the media connection with a bad_certificate error.
RFC 4572 defines a new SDP protocol identifier 'TCP/TLS' indicating that the described media will use TLS over TCP. The 'TCP/TLS' identifier describes only the transport, not the upper-layer protocol; an 'm' line using it must further qualify the protocol with a fmt identifier for the application running over TLS.
The 'fingerprint' SDP attribute identifies the X.509 certificate that will be presented for the TLS session. It consists of a hash function name followed by the hash value as uppercase hexadecimal bytes separated by colons, and may be a session-level or media-level attribute.
RFC 4572 creates the IANA 'Hash Function Textual Names' registry with initial entries for md2, md5, sha-1, sha-224, sha-256, sha-384, and sha-512, each mapped to their X.509 OID and defining RFC. New entries require a standards-track RFC updating or obsoleting RFC 3279.
RFC 4572 registers the SDP proto value 'TCP/TLS' under 'Session Description Protocol (SDP) Parameters' / 'proto', and registers the SDP attribute 'fingerprint' under 'att-field (both session and media level)'.
Hop-by-hop integrity mechanisms like sips (SIP over TLS) are considered sufficient to allow acceptance of any syntactically valid certificate identity, but this leaves SDP integrity vulnerable to compromised middleboxes such as SIP proxy servers. End systems MAY warn users about sessions secured only hop-by-hop.
Offering a TCP/TLS connection in SDP does not obligate an endpoint to accept any TLS connection with that fingerprint; standard TLS cipher negotiation must proceed. An offered TLS_NULL_WITH_NULL_NULL stream cipher SHOULD be rejected in almost every application scenario.
RFC 4572 explicitly does not define a mechanism for securely transporting RTP/RTCP over a connection-oriented channel. The working group deferred the question of whether to use SRTP over connection-oriented transport or standard RTP over TLS until a concrete use case was presented.
SDP messages describing TLS streams must have their integrity assured by the encapsulating application protocol (e.g., SIP, MGCP). The encapsulating protocol SHOULD invoke its own security mechanisms or use a lower-layer security service providing strong message authentication and effective replay protection.
When not using end-to-end authenticity protection over SIP, a certificate SHOULD assert the endpoint's SIP Address of Record as a uniformResourceIndicator subjectAltName. If a received certificate asserts an identity other than the called/calling party, the endpoint SHOULD alert the user and ask for confirmation.
When SDP integrity protection is not possible, end systems SHOULD maintain a cache of certificates previously presented. Users SHOULD be warned when an unsecured certificate from a previously unknown endpoint is presented, and STRONGLY warned when a different certificate appears from a known party — providing SSH-like trust-on-first-use semantics.
The fingerprint attribute is encoded as: 'fingerprint' ':' hash-func SP fingerprint, where hash-func is one of sha-1, sha-224, sha-256, sha-384, sha-512, md5, md2, or a registered token, and fingerprint is 2 or more uppercase hex bytes separated by colons (e.g., 'SHA-1 4A:AD:B9:...').