RFC 4572

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)

📅 published July 2006, from ietf

RFC 4572: Part 1 of 4 🎀

okay bestie, so this is RFC 4572, and the title is Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) 🦋 It's by J. Lennox from Columbia U., it's dated July 2006, and it's a Standards Track doc. It also updates RFC 4145 (it doesn't obsolete anything, fyi) 💅

Status of This Memo 📜

this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. distribution of this memo is unlimited ✨

Copyright Notice ⚖️

Abstract 🌸

this document is all about how to set up secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol, using the Session Description Protocol (SDP) 🔐 it defines a brand new SDP protocol identifier, 'TCP/TLS' 💖 it also defines the syntax and semantics for an SDP 'fingerprint' attribute, which identifies the certificate that will be presented for the TLS session 👑

the big idea is that media transport over TLS connections can be established securely, so long as the integrity of session descriptions is assured 😭 that "so long as" is doing a LOT of work here, iykyk 💀

this document extends and updates RFC 4145 🦋

Table of Contents 🗂️

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
   3.1. SDP Operational Modes ......................................4
   3.2. Threat Model ...............................................5
   3.3. The Need for Self-Signed Certificates ......................5
   3.4. Example SDP Description for TLS Connection .................6
4. Protocol Identifiers ............................................6
5. Fingerprint Attribute ...........................................7
6. Endpoint Identification .........................................9
   6.1. Certificate Choice .........................................9
   6.2. Certificate Presentation ..................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................12
9. References .....................................................14
   9.1. Normative References ......................................14
   9.2. Informative References ....................................15

1. Introduction ✨

okay so the Session Description Protocol (SDP) [1] is a general-purpose format for describing multimedia sessions in announcements or invitations 🎀 for lots of apps, you want to set up a media stream as part of a multimedia session that uses a connection-oriented transport 🧚

RFC 4145, Connection-Oriented Media Transport in the Session Description Protocol (SDP) [2], gives a general mechanism for describing and setting up those connection-oriented streams. BUT the only transport protocol it directly supports is TCP 😬 and honestly, in lots of cases, session participants want confidentiality, data integrity, and authentication for their media sessions 🔒 so this doc extends the Connection-Oriented Media spec so session descriptions can describe media sessions that use the Transport Layer Security (TLS) protocol [3] 💜

the TLS protocol lets apps talk over a channel that provides confidentiality and data integrity 🌸 BUT the TLS spec doesn't say how specific protocols set up and use that secure channel 🙈 especially, TLS leaves the question of how to interpret and validate authentication certificates up to the protocols that run over TLS. this document specifies that usage for the case of connection-oriented media transport 💅

now here's the tea 🍵 endpoints exchanging media often can't get authentication certificates signed by a well-known root certification authority (CA) 😩 most CAs charge for signed certificates, especially host-based ones 💸 and there's a big admin overhead too, since certification authorities have to confirm they're issuing the signed certificates to the correct party. ALSO, a lot of the time, endpoints' IP addresses and host names are dynamic. they might come from DHCP, for example 🌐 it's totally impractical to get a CA-signed certificate that's valid for the whole duration of a DHCP lease 💀 so for hosts like that, self-signed certificates are usually the only option 🫠

this spec defines a mechanism that lets self-signed certificates be used securely, provided that the integrity of the SDP description is assured ✨ endpoints include a secure hash of their certificate, known as the "certificate fingerprint", within the session description 🔐 as long as the fingerprint of the offered certificate matches the one in the session description, end hosts can trust even self-signed certificates 🥹👑

the rest of this doc is laid out like this 🗺️ an overview of the problem and threat model is in Section 3. Section 4 gives the basic mechanism for setting up TLS-based connection-oriented media in SDP. Section 5 describes the SDP fingerprint attribute, which (assuming the integrity of SDP content is assured) allows the secure use of self-signed certificates. Section 6 describes which X.509 certificates are presented, and how they're used in TLS. Section 7 discusses additional security considerations 🦋

2. Terminology 📖

in this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations 📏 these words are serious so don't mess with them 😤

3. Overview 🔍

this section talks about the threat model that motivates TLS transport for connection-oriented media streams 🕵️‍♀️ it also goes into more detail about why end systems need to use self-signed certificates 🎀

3.1. SDP Operational Modes 📞

there are two main operational modes for multimedia sessions: advertised and offer-answer 🧁 advertised sessions are the simpler one. in this mode, a server publishes, in some way, an SDP session description of a multimedia session it's making available 📣 the classic example is the Session Announcement Protocol (SAP) [15], where SDP session descriptions get sent out periodically to a well-known multicast group 📡 traditionally these are multicast conferences, but unicast sessions are possible too 💫 (connection-oriented media, obviously, cannot use multicast 🙃) recipients of a session description connect to the addresses published in it, and those recipients may not have been known to the advertiser beforehand 🫶

alternatively, SDP conferences can work in offer-answer mode [5] 🤝 this mode lets two participants negotiate the multimedia session between them. one participant offers the other a description of the session from its own perspective, and the other one answers with the session from its perspective 💅 in this mode, each participant knows about the other one. this is the mode the Session Initiation Protocol (SIP) [16] uses 📞✨

3.2. Threat Model 😈

participants in multimedia conferences often want to guarantee confidentiality, data integrity, and authentication for their media sessions 🔐 this section describes the different types of attackers and the ways they try to break those guarantees 🥷 then it explains how TLS can be used to stop them 🛡️

the simplest attacker just listens passively to the traffic of a multimedia session 👀 they might be, for example, on the same local-area or wireless network as one of the participants in a conference 📶 this kind of attacker doesn't threaten a connection's data integrity or authentication, and almost any operational mode of TLS can provide media stream confidentiality 💖

a more sophisticated attacker can send their own data traffic over the network, but can't modify or redirect valid traffic 🧐 in SDP's 'advertised' operational mode, this can barely count as an attack, since media sessions are expected to be started from anywhere on the network 🤷‍♀️ in SDP's offer-answer mode, though, this type of attack is way more serious 😱 an attacker could start a connection to one or both endpoints of a session, which means impersonating an endpoint, or acting as a man in the middle to listen in on their communications 👻 to stop these attacks, TLS uses endpoint certificates 🎀 as long as the certificates' private keys haven't been compromised, the endpoints have an external trusted mechanism (most commonly, a mutually-trusted certification authority) to validate certificates, and the endpoints know what certificate identity to expect, then they can be certain that no such attack has happened 💜

finally, the most serious attacker is one who can modify or redirect session descriptions 💀 for example, a compromised or malicious SIP proxy server 🚨 neither TLS itself nor any mechanism that uses it can protect an SDP session against an attacker like that 😭 instead, the SDP description itself must be secured through some other mechanism. SIP, for example, defines how S/MIME [17] can be used to secure session descriptions 🔐

3.3. The Need for Self-Signed Certificates 🔐

SDP session descriptions are created by any endpoint that needs to take part in a multimedia session 🧚‍♀️ in lots of cases, like SIP phones, these endpoints have dynamically-configured IP addresses and host names, and they have to be deployed with nearly zero configuration ⚙️ for an endpoint like that, it's basically impossible to get a certificate signed by a well-known certification authority, for practical purposes 🫠

if two endpoints have no prior relationship, self-signed certificates generally can't be trusted, because there's no guarantee that an attacker isn't launching a man-in-the-middle attack 👀 BUT, if the integrity of SDP session descriptions can be assured, those SDP descriptions can be treated as a prior relationship themselves: certificates can be securely described in the session description itself ✨🥹 this is done by providing a secure hash of a certificate, or "certificate fingerprint", as an SDP attribute 🎀 this mechanism is described in Section 5 🦋

3.4. Example SDP Description for TLS Connection ✨

Okay, so Figure 1 shows an SDP offer that says "hey, I've got a T.38 fax session over TLS!" 📠🔐 To keep things short, I only show the m line and its attributes. The main part of the session description is left out. This example matches the first one in RFC 4145 [2], except it swaps in the TLS proto parameter and adds the fingerprint attribute. Later sections explain those TLS-specific attributes, so stick around 💅

(Note: due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.)

m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 \
          4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

Figure 1: Example SDP Description Offering a TLS Media Stream

4. Protocol Identifiers 🦋

Okay, the m line in SDP is where you specify a bunch of stuff, including the transport protocol the media will use in the session. If you want the full tea on transport protocol identifiers, check the "Media Descriptions" section of SDP [1] 🫶

So this spec introduces a brand new protocol identifier, 'TCP/TLS', which says the media will use the Transport Layer Security protocol [3] over TCP. ✨ (Using TLS over other transport protocols isn't covered here, so don't go looking for it in this doc 🙈) The 'TCP/TLS' identifier only describes the transport, not the upper-layer protocol. An m line that specifies 'TCP/TLS' MUST further qualify the protocol using a fmt identifier to indicate the application being run over TLS. That part is non-negotiable, bestie 👑

Media sessions described with this identifier follow the procedures defined in RFC 4145 [2]. They also use the SDP attributes from that spec, 'setup' and 'connection'. Iconic reuse, honestly 💜

5. Fingerprint Attribute 🔐

Okay so when parties in a TLS session want to prove who they are, they show their authentication certificates during the TLS handshake. These certificates are X.509 [6] certificates, profiled by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9] 📜

Here's the big deal: to link media streams to their connections and stop unauthorized barge-in attacks on those streams, endpoints MUST provide a certificate fingerprint. 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 indeed the initiator of the connection. No imposters allowed 🙅‍♀️💖

A certificate fingerprint is a secure one-way hash of the DER (distinguished encoding rules) form of the certificate. Fingerprints are super widely supported, too! For example, the command openssl x509 -fingerprint makes the openssl command-line tool print one, and the certificate managers for Mozilla and Internet Explorer show them when you look at a certificate's details 🍓

A fingerprint shows up in SDP as an attribute (an a line). It has the name of the hash function first, then the hash value. The hash value is a sequence of uppercase hexadecimal bytes separated by colons, and the number of bytes depends on the hash function. This is the same syntax openssl and the browser certificate managers use. It's different from how HTTP digest authentication [18] writes hash values (unseparated lowercase hex). The team decided that matching the other fingerprint tools mattered more ✨

The formal syntax of the fingerprint attribute is in Augmented Backus-Naur Form [10], shown in Figure 2. It extends the BNF syntax of SDP [1]. 🧚

attribute              =/ fingerprint-attribute

fingerprint-attribute  =  "fingerprint" ":" hash-func SP fingerprint

hash-func              =  "sha-1" / "sha-224" / "sha-256" /
                          "sha-384" / "sha-512" /
                          "md5" / "md2" / token
                          ; Additional hash functions can only come
                          ; from updates to RFC 3279

fingerprint            =  2UHEX *(":" 2UHEX)
                          ; Each byte in upper-case hex, separated
                          ; by colons.

UHEX                   =  DIGIT / %x41-46 ; A-F uppercase

Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute

Now the rule that matters most: a certificate fingerprint MUST be computed using the same one-way hash function that the certificate's signature algorithm uses. This keeps the security properties of the certificate applying to the fingerprint too, and it means the other endpoint can use the fingerprint as long as the certificate itself is usable 🦋

So following RFC 3279 [7] as updated by RFC 4055 [9], the defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. There's a new IANA registry of Hash Function Textual Names, described in Section 8, that lets future tokens be added. But they can only be added if they show up in RFCs that update or obsolete RFC 3279 [7] 📋 Self-signed certificates (where legacy certificates aren't a consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, so they MUST also use it to calculate their certificate fingerprints. Strict, but iconic 💅

The fingerprint attribute can be either session-level or media-level. If it's session-level, it applies to every TLS session that doesn't have its own media-level fingerprint attribute 🌈

6. Endpoint Identification 🎀

6.1. Certificate Choice

Okay so an X.509 certificate binds an identity to a public key. If the SDP describing a TLS session gets sent over a mechanism that provides integrity protection, a certificate asserting any syntactically valid identity MAY be used. For example, an SDP description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY assert any identity in the certificate that secures the media connection 🔥

Security protocols that only give hop-by-hop integrity protection (for example, the sips protocol [16], SIP over TLS) are considered secure enough to allow the mode where any valid identity is accepted. However, see Section 7 for a discussion of some security implications of this 👀

Heads up, bestie: when the SDP is NOT integrity-protected, things get way stricter, so read on.

In situations where the SDP is not integrity-protected, the certificate provided for a TLS connection MUST certify an appropriate identity for the connection. In these scenarios, the certificate presented by an endpoint MUST certify either the SDP connection address, or the identity of the creator of the SDP message, as follows:

If the connection address for the media description is specified as an IP address, the endpoint MAY use a certificate with an iPAddress subjectAltName that exactly matches the IP in the connection-address in the session description's c line. Similarly, if the connection address for the media description is specified as a fully-qualified domain name, the endpoint MAY use a certificate with a dNSName subjectAltName matching the specified c line connection-address exactly. (Wildcard patterns MUST NOT be used.) 🙅‍♀️
Alternately, if the SDP session description of the session was transmitted over a protocol (such as SIP [16]) for which the identities of session participants are defined by uniform resource identifiers (URIs), the endpoint MAY use a certificate with a uniformResourceIdentifier subjectAltName corresponding to the identity of the endpoint that generated the SDP. The details of what URIs are valid depend on the transmitting protocol. (For more details on the validity of URIs, see Section 7.) 🧚

Identity matching uses the matching rules from RFC 3280 [8]. If there's more than one identity of a given type in the certificate (for example, more than one dNSName), a match in any one of them is acceptable. To support certificate caches, as described in Section 7, endpoints SHOULD consistently provide the same certificate for each identity they support. Consistency is the vibe 🫶

6.2. Certificate Presentation

Here's the rule for everybody: an endpoint acting as the TLS server (the one taking the 'setup:passive' role, in the terminology of connection-oriented media) MUST present a certificate during TLS initiation, following the rules in Section 6.1. If the certificate doesn't match the original fingerprint, the client endpoint MUST terminate the media connection with a bad_certificate error 💔

If the SDP offer/answer model [5] is being used, the client (the endpoint with the 'setup:active' role) MUST also present a certificate following the rules of Section 6.1. The server MUST request a certificate. If the client doesn't provide one, or if the certificate doesn't match the provided fingerprint, the server endpoint MUST terminate the media connection with a bad_certificate error 🌸

Now, here's a plot twist. When the offer/answer model is used, a media connection can outrace the answer back to the offerer. So if the offerer offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in RFC 4145 [2]) begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume the data sent over the TLS connection is valid until it has received a matching fingerprint in an SDP answer. If the fingerprint, once it arrives, doesn't match the client's certificate, the server endpoint MUST terminate the media connection with a bad_certificate error, as the previous paragraph said 😭

If offer/answer isn't being used (for example, if the SDP was sent over the Session Announcement Protocol [15]), there's no secure channel for clients to send certificate fingerprints to servers. In this case, servers MAY request client certificates, which SHOULD be signed by a well-known certification authority, or MAY allow clients to connect without a certificate. Not perfect, but that's the situation we've got, so we work with it 🍓

7. Security Considerations 🔒✨

okay bestie, this entire doc is about security 😭🔒 The problem it's solving is in Section 1, and the high-level overview is in Section 3. For the general SDP security stuff, go check the SDP spec [1] 💅

Offering a TCP/TLS connection in SDP (or agreeing to one in SDP offer/answer mode) does not mean you're on the hook to accept any TLS connection with the given fingerprint 🙅‍♀️ Instead, the endpoint must go through the standard TLS negotiation so the stream cipher and MAC algorithm that get picked actually meet the security needs of the higher-level app. (For example, an offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected in almost every app scenario 💀)

Like every SDP message, SDP messages describing TLS streams ride inside an encapsulating application protocol (like SIP, Media Gateway Control Protocol (MGCP), etc.) 🎀 It's the encapsulating protocol's job to keep the SDP security descriptions intact. So the application protocol SHOULD either use its own security stuff (like secure multiparts) or lean on a lower-layer security service (like TLS or IPsec). That security service SHOULD also give strong message authentication AND effective replay protection 🛡️

BUT, real talk, integrity protection isn't always possible 😩 For those cases, end systems SHOULD keep a cache of the certificates other parties have already shown them using this mechanism 🗂️ If it's possible, users SHOULD get notified when an unsecured certificate from a previously unknown end system shows up, and they SHOULD be strongly warned if a different unsecured certificate comes from a party they've talked to before 🚨 That way, even without integrity protection for SDP, this doc's mechanism is basically giving the same vibes as the Secure Shell (ssh) protocol [21]. ssh is vulnerable to man-in-the-middle attacks when two parties first talk, but it can catch them later on 👀 (Heads up: what counts as the "other party" depends on the app protocol carrying the SDP message.) Users SHOULD NOT, however, ever get notified about certificates described in SDP descriptions sent over an integrity-protected channel. No notifications there, periodt 🙅‍♀️

To keep interop and deployment smooth, security protocols that only give hop-by-hop integrity protection (like the sips protocol [16], aka SIP over TLS) are considered secure enough to allow the mode where any syntactically valid identity is accepted in a certificate 🌸 The reason is that sips is currently the integrity mechanism most likely to be used in deployed networks in the short to medium term. Still, in this mode, SDP integrity is vulnerable to attacks from compromised or malicious middleboxes, like SIP proxy servers 😬 End systems MAY warn users about SDP sessions that are only secured hop-by-hop, and definitions of media formats running over TCP/TLS MAY specify that only end-to-end integrity mechanisms be used. Options, options 💅

Heads up: depending on how SDP messages get transmitted, it's not always possible to tell whether a subjectAltName in a remote certificate is the one you expect for the remote party. Call forwarding, third-party call control, or session descriptions generated by endpoints controlled by the Gateway Control Protocol [22] can all make it unclear which entity should have generated a remote SDP response 🫠

So, when you're not using authenticity and integrity protection for SDP descriptions, a certificate sent over SIP SHOULD assert the endpoint's SIP Address of Record as a uniformResourceIndicator subjectAltName 📇 If an endpoint gets a certificate over SIP asserting an identity (including an iPAddress or dNSName identity) that is not the one it placed or received the call with, it SHOULD alert the user and ask for confirmation ⚠️ This applies whether the certificates are self-signed or signed by certification authorities. A certificate for sip:bob@example.com might be legitimately signed by a certification authority, and still not be acceptable for a call to sip:alice@example.com 🙃 (This issue isn't specific to this spec, by the way. The same consideration applies to S/MIME-signed SDP carried over SIP.)

This document does NOT define any mechanism for securely transporting RTP and RTP Control Protocol (RTCP) packets over a connection-oriented channel 🙅‍♀️ There was no working group consensus on whether it'd be better to send Secure RTP packets [23] over a connection-oriented transport [24], or to send standard unsecured RTP packets over TLS using the mechanisms in this document. The group decided to wait until a use case that needs secure connection-oriented RTP shows up 🕰️

Also, TLS isn't always the most appropriate choice for secure connection-oriented media 🫶 In some cases, a higher- or lower-level security protocol may be the better fit.

8. IANA Considerations 📋💖

This document defines an SDP proto value: 'TCP/TLS'. Its format is defined in Section 4. IANA has registered this proto value under "Session Description Protocol (SDP) Parameters" under "proto" 🎀

This document also defines an SDP session and media-level attribute: 'fingerprint'. Its format is defined in Section 5. IANA has registered this attribute under "Session Description Protocol (SDP) Parameters" under "att-field (both session and media level)" ✨

The SDP spec [1] says that specs defining new proto values, like the 'TCP/TLS' one in this doc, must define the rules for how their media format (fmt) namespace gets managed 📚 For the TCP/TLS protocol, new formats SHOULD have an associated MIME registration. Using an existing MIME subtype for the format is encouraged. If no MIME subtype exists, it is RECOMMENDED that a suitable one be registered through the IETF process [14], by producing or referencing a standards-track RFC that defines the transport protocol for the format 🌈

This specification creates a brand new IANA registry called "Hash Function Textual Names". It will NOT be part of the SDP Parameters 🦋

IANA registers the names of the hash functions used for certificate fingerprints. Hash functions MUST be defined by standards-track RFCs that update or obsolete RFC 3279 [7] 🔐

When registering a new hash function textual name, the following information MUST be provided:

The textual name of the hash function.
The Object Identifier (OID) of the hash function as used in X.509 certificates.
A reference to the standards-track RFC, updating or obsoleting RFC 3279 [7], defining the use of the hash function in X.509 certificates.

Figure 3 contains the initial values of this registry 🍓

Hash Function Name     OID                         Reference
------------------     ---                         ---------
"md2"                  1.2.840.113549.2.2          RFC 3279
"md5"                  1.2.840.113549.2.5          RFC 3279
"sha-1"                1.3.14.3.2.26               RFC 3279
"sha-224"              2.16.840.1.101.3.4.2.4      RFC 4055
"sha-256"              2.16.840.1.101.3.4.2.1      RFC 4055
"sha-384"              2.16.840.1.101.3.4.2.2      RFC 4055
"sha-512"              2.16.840.1.101.3.4.2.3      RFC 4055

         Figure 3: IANA Hash Function Textual Name Registry

9. References 📚🧚

9.1. Normative References

[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.

[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[6] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.

[7] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.

[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.

[9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.

[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[11] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.

[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.

[14] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

9.2. Informative References

[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.

[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.

[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.

[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[21] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.

[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[24] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.

Author's Address 🎀

Jonathan Lennox
Columbia University Department of Computer Science
450 Computer Science
1214 Amsterdam Ave., M.C. 0401
New York, NY  10027
US

EMail: lennox@cs.columbia.edu

Full Copyright Statement ✨

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🌸

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🦋

The IETF is not picking a side on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether any license for those rights is available, and it hasn't gone looking for any of them either. 🫶 If you want the rules on rights for RFC documents, check BCP 78 and BCP 79. 📚

Copies of IPR disclosures sent to the IETF Secretariat, any promises of licenses, and the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights can all be found through the IETF's online IPR repository at http://www.ietf.org/ipr. 💜

The IETF invites anyone interested to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. 🔥 Send that info to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement 🧚

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 🌈 Thank you IASA, you're the real MVP 👑✨

📦 where this page comes from

ietf: rfc4572 2006-07
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms