Multiparty Multimedia Session                                  J. Lennox
Control                                                      Columbia U.

Expires: January 2, September 4, 2006

 Connection-Oriented Media Transport over the Transport Layer Security
        (TLS) Protocol in the Session Description Protocol (SDP)
                    draft-ietf-mmusic-comedia-tls-05
                    draft-ietf-mmusic-comedia-tls-06

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, September 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (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 which 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 revision of the document reflects comments made during IESG
   review.

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  . . . . . . . . . . . . . . . . . . .  8
     6.1.  Certificate Choice . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Certificate Presentation . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11 12
   Appendix A.   Changes From Earlier Versions  . . . . . . . . . . . 12 13
   Appendix A.1. Changes From Draft -04 -05 . . . . . . . . . . . . . . . 12 13
   Appendix A.2. Changes From Draft -03 -04 . . . . . . . . . . . . . . . 12 14
   Appendix A.3. Changes From Draft -02 -03 . . . . . . . . . . . . . . . 12 14
   Appendix A.4. Changes From Draft -01 -02 . . . . . . . . . . . . . . . 13 15
   Appendix A.5. Changes From Draft -01 . . . . . . . . . . . . . . . 15
   Appendix A.6. Changes From Draft -00 . . . . . . . . . . . . . . . 13 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 17 19

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 which uses a connection-
   oriented transport.  The document  RFC 4145, Connection-Oriented Media Transport in
   the Session Description Protocol (SDP) [2] [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
   which provides privacy 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 which 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 certificate 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 certificate 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 which 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 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
   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 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 which 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 describing 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].

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 certificate 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
   which 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 certificate certification authority.

   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 which 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 draft 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 by 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
   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 the connection-oriented media specification 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 which 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
   upper-case 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 lower-case 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].

   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 are 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.  Additional hash functions can be defined  A new IANA
   registry of Hash Function Textual Names, specified in Section 8,
   allows for addition of future tokens, but they may only by
   standards-track be added if
   they are included in RFCs which update or obsolete RFC 3279 [7].  Self-
   signed
   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.

6.  Endpoint Identification

6.1.  Certificate Choice

   An X.509 certificates certify identities.  The certificate binds an identity and a public key.  If SDP
   describing a TLS session is transmitted over a mechanism which
   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 which 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 needs to MUST certify an appropriate
   identity for the connection.  Identity matching is performed using  In these scenarios, the matching rules
   specified certificate
   presented by RFC 3280 [8].  If more than one an endpoint MUST certify either the SDP connection
   address, or the 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.

   The certificate presented by an endpoint MUST correspond to one creator of the following identities: 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 which exactly matches the IP in the
      connection-address in the session description's 'c' line.
   o  If
      Similarly, if the connection address for the media description is
      specified as a fully-qualified pfully-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  If  Alternately, if the SDP session description describing 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. subjectAltName corresponding to the
      identity of the endpoint which generated the SDP.  The details of
      what URIs are appropriate valid are dependent on the transmitting protocol.
      (For more details on this, the validity of URIs, see Section 7.)

   If the SDP session description describing the session was transmitted
   over an end-to-end secure protocol which uses X.509 certificates, and
   the certificates sent fulfill the requirements above (as they
   normally would be expected to), the endpoint MAY use the same
   certificate to certify

   Identity matching is performed using the media connection.  For example, an SDP
   description sent over HTTP/TLS [20] or secured matching rules specified by S/MIME [17] MAY use
   RFC 3280 [8].  If more than one identity of a given type is present
   in the same certificate to secure the media connection.  (Note, however,
   that (e.g., more than one dNSName name), a match in any
   one of the sips protocol [16] (SIP over TLS) provides only hop-by-hop
   security, so its TLS certificates do not satisfy this criterion.) set is considered acceptable.  To support the use of
   certificate caches, as described in Section 7, endpoints SHOULD
   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, or, if there is no fingerprint, the
   certificate identity is incorrect, the client endpoint MUST either
   notify the user, if possible, or terminate
   the media connection with a bad certificate 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, or, if there was
   no fingerprint, the certificate identity is incorrect, the server
   endpoint MUST either notify the user or terminate the media connection with a bad certificate 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 the Connection-Oriented Media
   specification RFC 4145 [2]) begin listening for an
   incoming connection as soon as it sends its offer.  However, because its peer's media connection
   may outrace its answer, it MUST
   NOT definitively accept assume the peer's
   certificate data transmitted over the TLS connection is valid
   until it has received and processed the 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]), the TLS server typically has there is no
   external knowledge of what the TLS client's identity ought secure channel
   available for clients to communicate certificate fingerprints to be.
   servers.  In this case, no servers MAY request client certificate need be presented, and no
   certificate validation can certificates,
   which SHOULD be performed, unless the server has
   knowledge of valid signed by a well-known certification authority, or
   MAY allow clients through some external means. 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 an 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
   endpoint must engage in the standard TLS negotiation procedure to
   ensure that the TLS stream cypher and MAC algorithm chosen meet the
   security needs of the higher-level application.  (For example, an
   offered stream cypher 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, MGCP,
   etc.).  It is the responsibility of the encapsulating protocol to
   ensure the integrity and confidentiality 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). IPsec).  This security
   service SHOULD provide strong message authentication and packet-payload encryption 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 which
   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 and unauthenticated 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 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 which
   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 syntactially 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 are to be used.

   Depending on how SDP messages are transmitted, it is not always
   possible to determine whether a uniformResourceIdentifier subjectAltName presented in a remote
   certificate is expected or not for the remote party.  In particular,
   given call forwarding, third-
   party 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 some cases this determination may need 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
   made legitimately signed by a human, as automated logic
   certification authority, but may still not be able to determine
   correctness.  (For example, "You placed this acceptable for a call
   to
   sip:alice@example.com, but the remote certificate presented belongs
   to sip:bob@example.com.  Continue?")  This sip:alice@example.com.  (This issue is not one specific to this
   specification; the same consideration applies for S/MIME-
   signed S/MIME-signed SDP
   carried over SIP.

   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. SIP.)

   This document does not define any mechanism for securely transporting
   RTP and 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 should be registered by IANA
   on 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
   should be registered by IANA under "Session Description Protocol
   (SDP) Parameters" under "att-field (both session and media level)".

   The SDP specification, RFC2327, specification [1] states that specifications defining new
   proto values, like the 'TCP/TLS' proto value defined in this one,
   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 which 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

Appendix A.  Changes From Earlier Versions

   Note to the RFC-Editor: please remove this section prior to
   publication as an RFC.

Appendix A.1.  Changes From Draft -05

   o  Specified that hop-by-hop integrity protection counts as valid
      integrity protection (though specific media formats can define
      otherwise if they choose.)
   o  Allowed SDP descriptions which are integrity-protected to
      advertise any subjectAltName in their certificates.
   o  Made session teardown a MUST following a bad certificate
      fingerprint -- user notification is no longer an option in this
      scenario.

   o  Established and populated a new IANA registry for Hash Function
      Textual Names.
   o  Allowed announcement-mode (SAP-like) uses of TLS to request client
      certificates, even though there is no way for clients to provide
      certificate fingerprints in this case.
   o  Confidentiality is not required for secure transmission of SDP
      descriptions, only integrity protection; removed this requirement.
   o  Established that user notification about bad certificate
      identities only applies to certificates not sent over a protected
      channel.
   o  Clarified the language on what identity must be asserted, for
      certificates which must include specific identities.
   o  Clarified the scenarios in which users must be consulted on
      whether certificates are acceptable.
   o  Clarified that TLS connections MUST NOT act upon data transmitted
      over a TLS connection before they have verified the fingerprint.
   o  Clarified that the use of the same hash function for fingerprints
      as for their corresponding certificates ensures that the
      certificates' security properties are preserved for their
      fingerprints.
   o  Standardized some terminology to properly reflect standard
      security usage.  Notably, "confidentiality" and "certification
      authority" replaced "privacy" and "certificate authority"
      respectively.
   o  Updated the references for Connection-Oriented Media in SDP (now
      RFC 4145 [2]), ABNF (now RFC 4234 [10]), Media Type Registration
      Procedures (now RFC 4288 [14]), and the SSH Protocol Architecture
      (now RFC 4251 [21]).

Appendix A.2.  Changes From Draft -04

   o  The section discussing the difficulty of knowing what URI
      identities are appropriate for SDP was expanded, adding a
      reference to the Gateway Control Protocol.
   o  An un-cited informative reference was removed.

Appendix A.2. A.3.  Changes From Draft -03

   o  The number of options in the protocol were significantly reduced:
      a number of SHOULD requirements were elevated to MUST.  Notably,
      the use of the 'fingerprint' attribute, strict certificate
      identity choices, and the use of the same digest algorithm for
      fingerprints as for certificates were all made mandatory.
   o  Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055
      [9] ('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added.
   o  Discussion was added about the difficulty of automatically
      determining the URI a remote endpoint's certificate should assert,
      especially in SIP in the presence of call forwarding or third-party third-
      party call control.
   o  The document was aligned with version -10 of
      draft-ietf-mmusic-comedia [2].  This consisted mostly of wording
      and formatting changes.

Appendix A.3. A.4.  Changes From Draft -02

   None, other than IPR boilerplate and reference updates.  Draft -03
   was a resubmission to refresh the draft's presence in the Internet-
   Drafts repository.

Appendix A.4. A.5.  Changes From Draft -01

   o  Made the use of SHA-1 fingerprints mandatory in self-signed
      certificates.
   o  Aligned with version -09 of draft-ietf-mmusic-comedia [2], also
      drawing some wording changes from that document.
   o  Forbid the use of wildcards for the dNS subjectAltName.
   o  Eliminated requirements on identities provided with self-signed
      certificates.
   o  Recommended the use of a certificate cache when SDP integrity
      protection cannot be assured.
   o  Explained that there is no currently supported mechanism for
      securely sending RTP over connection-oriented media.
   o  Described the procedure for establishing media formats for TCP/
      TLS.

Appendix A.5. A.6.  Changes From Draft -00

   o  Significantly expanded introduction and motivation sections.
   o  Significant clarifications to other sections.
   o  Aligned with version -07 of draft-ietf-mmusic-comedia [2].
      Protocol identifier changed from TLS to TCP/TLS at that document's
      recommendation.

9.  References

9.1.  Normative References

   [1]   Handley, M., "SDP: Session Description Protocol",
         draft-ietf-mmusic-sdp-new-25
         draft-ietf-mmusic-sdp-new-26 (work in progress), July 2005. January 2006.

   [2]   Yon, D., "Connection-Oriented D. and G. Camarillo, "TCP-Based Media Transport in the
         Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10
         (work in progress), November 2004. RFC 4145, September 2005.

   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [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., Ed. D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997. 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., Klensin, J., N. and J. Postel, "Multipurpose Internet
         Mail Extensions (MIME) Part Four: Klensin, "Media Type Specifications and
         Registration Procedures", BCP 13, RFC 2048, November 1996. 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., "S/MIME Version 3 Message Specification",
         RFC 2633, June 1999.

   [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, "SSH "The Secure Shell (SSH) Protocol
         Architecture",
         draft-ietf-secsh-architecture-22 (work in progress),
         March 2005. 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 RTP and RTCP Packets over Connection-
         Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06
         (work in progress), September 2005.

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

   Phone: +1 212 939 7018

   Email: lennox@cs.columbia.edu

Intellectual Property Statement

   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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2005). (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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.