summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4572.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4572.txt')
-rw-r--r--doc/rfc/rfc4572.txt955
1 files changed, 955 insertions, 0 deletions
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, <http://csrc.nist.gov/
+ publications/fips/fips180-2/fips180-2.pdf>.
+
+ [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]
+