From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4572.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc4572.txt (limited to 'doc/rfc/rfc4572.txt') diff --git a/doc/rfc/rfc4572.txt b/doc/rfc/rfc4572.txt new file mode 100644 index 0000000..1d4048c --- /dev/null +++ b/doc/rfc/rfc4572.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group J. Lennox +Request for Comments: 4572 Columbia U. +Updates: 4145 July 2006 +Category: Standards Track + + + Connection-Oriented Media Transport over the Transport Layer Security + (TLS) Protocol in the Session Description Protocol (SDP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to 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 + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies how to establish secure connection-oriented + media transport sessions over the Transport Layer Security (TLS) + protocol using the Session Description Protocol (SDP). It defines a + new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax + and semantics for an SDP 'fingerprint' attribute that identifies the + certificate that will be presented for the TLS session. This + mechanism allows media transport over TLS connections to be + established securely, so long as the integrity of session + descriptions is assured. + + This document extends and updates RFC 4145. + + + + + + + + + + + + + + + + + +Lennox Standards Track [Page 1] + +RFC 4572 Comedia over TLS in SDP July 2006 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox Standards Track [Page 2] + +RFC 4572 Comedia over TLS in SDP July 2006 + + +1. Introduction + + The Session Description Protocol (SDP) [1] provides a general-purpose + format for describing multimedia sessions in announcements or + invitations. For many applications, it is desirable to establish, as + part of a multimedia session, a media stream that uses a connection- + oriented transport. RFC 4145, Connection-Oriented Media Transport in + the Session Description Protocol (SDP) [2], specifies a general + mechanism for describing and establishing such connection-oriented + streams; however, the only transport protocol it directly supports is + TCP. In many cases, session participants wish to provide + confidentiality, data integrity, and authentication for their media + sessions. This document therefore extends the Connection-Oriented + Media specification to allow session descriptions to describe media + sessions that use the Transport Layer Security (TLS) protocol [3]. + + The TLS protocol allows applications to communicate over a channel + that provides confidentiality and data integrity. The TLS + specification, however, does not specify how specific protocols + establish and use this secure channel; particularly, TLS leaves the + question of how to interpret and validate authentication certificates + as an issue for the protocols that run over TLS. This document + specifies such usage for the case of connection-oriented media + transport. + + Complicating this issue, endpoints exchanging media will often be + unable to obtain authentication certificates signed by a well-known + root certification authority (CA). Most certificate authorities + charge for signed certificates, particularly host-based certificates; + additionally, there is a substantial administrative overhead to + obtaining signed certificates, as certification authorities must be + able to confirm that they are issuing the signed certificates to the + correct party. Furthermore, in many cases endpoints' IP addresses + and host names are dynamic: they may be obtained from DHCP, for + example. It is impractical to obtain a CA-signed certificate valid + for the duration of a DHCP lease. For such hosts, self-signed + certificates are usually the only option. This specification defines + a mechanism that allows self-signed certificates can be used + securely, provided that the integrity of the SDP description is + assured. It provides for endpoints to include a secure hash of their + certificate, known as the "certificate fingerprint", within the + session description. Provided that 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 document is laid out as follows. An overview of the + problem and threat model is given in Section 3. Section 4 gives the + basic mechanism for establishing TLS-based connected-oriented media + + + +Lennox Standards Track [Page 3] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + in SDP. Section 5 describes the SDP fingerprint attribute, which, + assuming that 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 are used in TLS. + Section 7 discusses additional security considerations. + +2. Terminology + + In this document, 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. + +3. Overview + + This section discusses the threat model that motivates TLS transport + for connection-oriented media streams. It also discusses in more + detail the need for end systems to use self-signed certificates. + +3.1. SDP Operational Modes + + There are two principal operational modes for multimedia sessions: + advertised and offer-answer. Advertised sessions are the simpler + mode. In this mode, a server publishes, in some manner, an SDP + session description of a multimedia session it is making available. + The classic example of this mode of operation is the Session + Announcement Protocol (SAP) [15], in which SDP session descriptions + are periodically transmitted to a well-known multicast group. + Traditionally, these descriptions involve multicast conferences, but + unicast sessions are also possible. (Connection-oriented media, + obviously, cannot use multicast.) Recipients of a session + description connect to the addresses published in the session + description. These recipients may not previously have been known to + the advertiser of the session description. + + Alternatively, SDP conferences can operate in offer-answer mode [5]. + This mode allows two participants in a multimedia session to + negotiate the multimedia session between them. In this model, one + participant offers the other a description of the desired session + from its perspective, and the other participant answers with the + desired session from its own perspective. In this mode, each of the + participants in the session has knowledge of the other one. This is + the mode of operation used by the Session Initiation Protocol (SIP) + [16]. + + + + + + + +Lennox Standards Track [Page 4] + +RFC 4572 Comedia over TLS in SDP July 2006 + + +3.2. Threat Model + + Participants in multimedia conferences often wish to guarantee + confidentiality, data integrity, and authentication for their media + sessions. This section describes various types of attackers and the + ways they attempt to violate these guarantees. It then describes how + the TLS protocol can be used to thwart the attackers. + + The simplest type of attacker is one who listens passively to the + traffic associated with a multimedia session. This attacker might, + for example, be on the same local-area or wireless network as one of + the participants in a conference. This sort of attacker does not + threaten a connection's data integrity or authentication, and almost + any operational mode of TLS can provide media stream confidentiality. + + More sophisticated is an attacker who can send his own data traffic + over the network, but who cannot modify or redirect valid traffic. + In SDP's 'advertised' operational mode, this can barely be considered + an attack; media sessions are expected to be initiated from anywhere + on the network. In SDP's offer-answer mode, however, this type of + attack is more serious. An attacker could initiate a connection to + one or both of the endpoints of a session, thus impersonating an + endpoint, or acting as a man in the middle to listen in on their + communications. To thwart these attacks, TLS uses endpoint + certificates. So long as the certificates' private keys have not + 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, endpoints can be certain that such an attack has + not taken place. + + Finally, the most serious type of attacker is one who can modify or + redirect session descriptions: for example, a compromised or + malicious SIP proxy server. Neither TLS itself nor any mechanisms + that use it can protect an SDP session against such an attacker. + Instead, the SDP description itself must be secured through some + 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 + participate in a multimedia session. In many cases, such as SIP + phones, such endpoints have dynamically-configured IP addresses and + host names and must be deployed with nearly zero configuration. For + such an endpoint, it is for practical purposes impossible to obtain a + certificate signed by a well-known certification authority. + + + + +Lennox Standards Track [Page 5] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + If two endpoints have no prior relationship, self-signed certificates + cannot generally be trusted, as there is no guarantee that an + attacker is not launching a man-in-the-middle attack. Fortunately, + however, if the integrity of SDP session descriptions can be assured, + it is possible to consider those SDP descriptions themselves as a + prior relationship: 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 + + Figure 1 illustrates an SDP offer that signals the availability of a + T.38 fax session over TLS. For the purpose of brevity, the main + portion of the session description is omitted in the example, showing + only the 'm' line and its attributes. (This example is the same as + the first one in RFC 4145 [2], except for the proto parameter and the + fingerprint attribute.) See the subsequent sections for explanations + of the example's TLS-specific attributes. + + (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 + + The 'm' line in SDP specifies, among other items, the transport + protocol to be used for the media in the session. See the "Media + Descriptions" section of SDP [1] for a discussion on transport + protocol identifiers. + + This specification defines a new protocol identifier, 'TCP/TLS', + which indicates that the media described will use the Transport Layer + Security protocol [3] over TCP. (Using TLS over other transport + protocols is not discussed in this document.) The 'TCP/TLS' protocol + identifier describes only the transport protocol, not the upper-layer + protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify + + + +Lennox Standards Track [Page 6] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + the protocol using a fmt identifier to indicate the application being + run over TLS. + + Media sessions described with this identifier follow the procedures + defined in RFC 4145 [2]. They also use the SDP attributes defined in + that specification, 'setup' and 'connection'. + +5. Fingerprint Attribute + + Parties to a TLS session indicate their identities by presenting + authentication certificates as part of the TLS handshake procedure. + Authentication certificates are X.509 [6] certificates, as profiled + by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9]. + + In order to associate media streams with connections and to prevent + unauthorized barge-in attacks on the media streams, endpoints MUST + provide a certificate fingerprint. If the X.509 certificate + presented for the TLS connection matches the fingerprint presented in + the SDP, the endpoint can be confident that the author of the SDP is + indeed the initiator of the connection. + + A certificate fingerprint is a secure one-way hash of the DER + (distinguished encoding rules) form of the certificate. (Certificate + fingerprints are widely supported by tools that manipulate X.509 + certificates; for instance, the command "openssl x509 -fingerprint" + causes the command-line tool of the openssl package to print a + certificate fingerprint, and the certificate managers for Mozilla and + Internet Explorer display them when viewing the details of a + certificate.) + + A fingerprint is represented in SDP as an attribute (an 'a' line). + It consists of the name of the hash function used, followed by the + hash value itself. The hash value is represented as a sequence of + uppercase hexadecimal bytes, separated by colons. The number of + bytes is defined by the hash function. (This is the syntax used by + openssl and by the browsers' certificate managers. It is different + from the syntax used to represent hash values in, e.g., HTTP digest + authentication [18], which uses unseparated lowercase hexadecimal + bytes. It was felt that consistency with other applications of + fingerprints was more important.) + + The formal syntax of the fingerprint attribute is given in Augmented + Backus-Naur Form [10] in Figure 2. This syntax extends the BNF + syntax of SDP [1]. + + + + + + + +Lennox Standards Track [Page 7] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + 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 + + 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 for the fingerprint. It also guarantees that + the fingerprint will be usable by the other endpoint, so long as the + certificate itself is.) Following RFC 3279 [7] as updated by RFC + 4055 [9], therefore, 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. A new IANA + registry of Hash Function Textual Names, specified in Section 8, + allows for addition of future tokens, but they may only be added if + they are included in RFCs that update or obsolete RFC 3279 [7]. + Self-signed certificates (for which legacy certificates are not 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, + and thus also MUST use it to calculate certificate fingerprints. + + The fingerprint attribute may be either a session-level or a media- + level SDP attribute. If it is a session-level attribute, it applies + to all TLS sessions for which no media-level fingerprint attribute is + defined. + + + + + + + + + + + + +Lennox Standards Track [Page 8] + +RFC 4572 Comedia over TLS in SDP July 2006 + + +6. Endpoint Identification + +6.1. Certificate Choice + + An X.509 certificate binds an identity and a public key. If SDP + describing a TLS session is transmitted 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 securing the media connection. + + Security protocols that provide only hop-by-hop integrity protection + (e.g., the sips protocol [16], SIP over TLS) are considered + sufficiently secure to allow the mode in which any valid identity is + accepted. However, see Section 7 for a discussion of some security + implications of this fact. + + In situations where the SDP is not integrity-protected, however, 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: + + o 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.) + + o 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 are dependent on the transmitting protocol. + (For more details on the validity of URIs, see Section 7.) + + Identity matching is performed using the matching rules specified by + RFC 3280 [8]. If more than one identity of a given type is present + in the certificate (e.g., more than one dNSName name), a match in any + one of the set is considered acceptable. To support the use of + certificate caches, as described in Section 7, endpoints SHOULD + + + +Lennox Standards Track [Page 9] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + consistently provide the same certificate for each identity they + support. + +6.2. Certificate Presentation + + In all cases, an endpoint acting as the TLS server (i.e., one taking + the 'setup:passive' role, in the terminology of connection-oriented + media) MUST present a certificate during TLS initiation, following + the rules presented in Section 6.1. If the certificate does not + 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, and if the client does not provide one, or if + the certificate does not match the provided fingerprint, the server + endpoint MUST terminate the media connection with a bad_certificate + error. + + Note that when the offer/answer model is being used, it is possible + for a media connection to outrace the answer back to the offerer. + Thus, if the offerer has 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 that the data transmitted over the TLS connection is valid + until it has received a matching fingerprint in an SDP answer. If + the fingerprint, once it arrives, does not match the client's + certificate, the server endpoint MUST terminate the media connection + with a bad_certificate error, as stated in the previous paragraph. + + If offer/answer is not being used (e.g., if the SDP was sent over the + Session Announcement Protocol [15]), there is no secure channel + available for clients to communicate 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. + +7. Security Considerations + + This entire document concerns itself with security. The problem to + be solved is addressed in Section 1, and a high-level overview is + presented in Section 3. See the SDP specification [1] for security + considerations applicable to SDP in general. + + Offering a TCP/TLS connection in SDP (or agreeing to one in SDP + offer/answer mode) does not create an obligation for an endpoint to + accept any TLS connection with the given fingerprint. Instead, the + + + +Lennox Standards Track [Page 10] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + endpoint must engage in the standard TLS negotiation procedure to + ensure that the TLS stream cipher and MAC algorithm chosen meet the + security needs of the higher-level application. (For example, an + offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected + in almost every application scenario.) + + Like all SDP messages, SDP messages describing TLS streams are + conveyed in an encapsulating application protocol (e.g., SIP, Media + Gateway Control Protocol (MGCP), etc.). It is the responsibility of + the encapsulating protocol to ensure the integrity of the SDP + security descriptions. Therefore, the application protocol SHOULD + either invoke its own security mechanisms (e.g., secure multiparts) + or, alternatively, utilize a lower-layer security service (e.g., TLS + or IPsec). This security service SHOULD provide strong message + authentication as well as effective replay protection. + + However, such integrity protection is not always possible. For these + cases, end systems SHOULD maintain a cache of certificates that other + parties have previously presented using this mechanism. If possible, + users SHOULD be notified when an unsecured certificate associated + with a previously unknown end system is presented and SHOULD be + strongly warned if a different unsecured certificate is presented by + a party with which they have communicated in the past. In this way, + even in the absence of integrity protection for SDP, the security of + this document's mechanism is equivalent to that of the Secure Shell + (ssh) protocol [21], which is vulnerable to man-in-the-middle attacks + when two parties first communicate, but can detect ones that occur + subsequently. (Note that a precise definition of the "other party" + depends on the application protocol carrying the SDP message.) Users + SHOULD NOT, however, in any circumstances be notified about + certificates described in SDP descriptions sent over an integrity- + protected channel. + + To aid interoperability and deployment, security protocols that + provide only hop-by-hop integrity protection (e.g., the sips protocol + [16], SIP over TLS) are considered sufficiently secure to allow the + mode in which any syntactically valid identity is accepted in a + certificate. This decision was made because sips is currently the + integrity mechanism most likely to be used in deployed networks in + the short to medium term. However, in this mode, SDP integrity is + vulnerable to attacks by compromised or malicious middleboxes, e.g., + SIP proxy servers. End systems MAY warn users about SDP sessions + that are secured in only a hop-by-hop manner, and definitions of + media formats running over TCP/TLS MAY specify that only end-to-end + integrity mechanisms be used. + + + + + + +Lennox Standards Track [Page 11] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + Depending on how SDP messages are transmitted, it is not always + possible to determine whether or not a subjectAltName presented in a + remote certificate is expected for the remote party. In particular, + given call forwarding, third-party call control, or session + descriptions generated by endpoints controlled by the Gateway Control + Protocol [22], it is not always possible in SIP to determine what + entity ought to have generated a remote SDP response. In general, + when not using authenticity and integrity protection of SDP + descriptions, a certificate transmitted over SIP SHOULD assert the + endpoint's SIP Address of Record as a uniformResourceIndicator + subjectAltName. When an endpoint receives a certificate over SIP + asserting an identity (including an iPAddress or dNSName identity) + other than the one to which it placed or received the call, it SHOULD + alert the user and ask for confirmation. This applies whether + certificates are self-signed, or signed by certification authorities; + a certificate for sip:bob@example.com may be legitimately signed by a + certification authority, but may still not be acceptable for a call + to sip:alice@example.com. (This issue is not one specific to this + specification; the same consideration applies for 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 consensus in the working + group as to whether it would be better to send Secure RTP packets + [23] over a connection-oriented transport [24], or whether it would + be better to send standard unsecured RTP packets over TLS using the + mechanisms described in this document. The group consensus was to + wait until a use-case requiring secure connection-oriented RTP was + presented. + + TLS is not always the most appropriate choice for secure connection- + oriented media; in some cases, a higher- or lower-level security + protocol may be appropriate. + +8. IANA Considerations + + This document defines an SDP proto value: 'TCP/TLS'. Its format is + defined in Section 4. This proto value has been registered by IANA + under "Session Description Protocol (SDP) Parameters" under "proto". + + This document defines an SDP session and media-level attribute: + 'fingerprint'. Its format is defined in Section 5. This attribute + has been registered by IANA under "Session Description Protocol (SDP) + Parameters" under "att-field (both session and media level)". + + The SDP specification [1] states that specifications defining new + proto values, like the 'TCP/TLS' proto value defined in this one, + + + +Lennox Standards Track [Page 12] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + must define the rules by which their media format (fmt) namespace is + managed. For the TCP/TLS protocol, new formats SHOULD have an + associated MIME registration. Use of 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 production of, or reference to, a standards-track RFC + that defines the transport protocol for the format. + + This specification creates a new IANA registry named "Hash Function + Textual Names". It will not be part of the SDP Parameters. + + The names of hash functions used for certificate fingerprints are + registered by the IANA. 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: + + o The textual name of the hash function. + + o The Object Identifier (OID) of the hash function as used in X.509 + certificates. + + o 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 + + + + + + + + + + + +Lennox Standards Track [Page 13] + +RFC 4572 Comedia over TLS in SDP July 2006 + + +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, . + + [12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + + + +Lennox Standards Track [Page 14] + +RFC 4572 Comedia over TLS in SDP July 2006 + + + [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. + + + + + + + + + + +Lennox Standards Track [Page 15] + +RFC 4572 Comedia over TLS in SDP 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lennox Standards Track [Page 16] + +RFC 4572 Comedia over TLS in SDP July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Lennox Standards Track [Page 17] + -- cgit v1.2.3