Network Working Group                                        C. Holmberg                                          J. Lennox
Internet-Draft                                                  Ericsson
Updates:                                                     Vidyo
Obsoletes: 4572 (if approved)                           September 25, 2016                                C. Holmberg
Intended status: Standards Track                                Ericsson
Expires: March 29, May 7, 2017                                    November 3, 2016

          Connection-Oriented Media Transport over TLS in SDP Fingerprint Attribute Usage Clarifications
                  draft-ietf-mmusic-4572-update-07.txt
                    draft-ietf-mmusic-4572-update-08

Abstract

   This document updates RFC 4572 by clarifying specifies how to establish secure connection-oriented
   media transport sessions over the usage of multiple
   SDP 'fingerprint' attributes with Transport Layer Security (TLS)
   protocol using the Session Description Protocol (SDP).  It defines a single
   new SDP media description ("m=
   line").  The document protocol identifier, 'TCP/TLS'.  It also updates defines the preferred cipher suite with a
   stronger cipher suite. 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 29, May 7, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   3.  Update to RFC 4572  Overview  . . . . . . . . . . . . . . . . . . . . . . .   3 . . .   4
     3.1.  Update to the sixth paragraph of section 5  SDP Operational Modes . . . . . . . . .   3 . . . . . . . . .   4
     3.2.  New paragraphs to the end of section 5  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  The Need for Self-Signed Certificates . . . . . . . . . .   5
     3.4.  Example SDP Description for TLS Connection  . . . . . . .   6
   4.  Security Considerations  Protocol Identifiers  . . . . . . . . . . . . . . . . . . .   5 .   6
   5.  IANA Considerations  Fingerprint Attribute . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Multiple Fingerprints .   6 . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  Endpoint Identification . . . . . . . . . . . . . . . . . . .   9
     6.1.  Certificate Choice  . . .   6
   7.  Change Log . . . . . . . . . . . . . . . .   9
     6.2.  Certificate Presentation  . . . . . . . . .   6 . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Normative References  IANA Considerations . . . . . . . . . . . . . . . . . . . .   7
   Author's Address .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   RFC 4572 [RFC4572] specifies how to establish Transport Layer
   Security (TLS) connections using the Session Description Protocol . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The Session Description Protocol (SDP) [RFC4566].

   RFC 4572 defines the SDP 'fingerprint' attribute, which [14] provides a general-
   purpose format for describing multimedia sessions in announcements or
   invitations.  For many applications, it is used desirable to
   carry a secure hash value (fingerprint) associated with establish, as
   part of a
   certificate.  However, RFC 4572 is currently unclear on whether
   multiple 'fingerprint' attributes can be associated with multimedia session, a single SDP media description ("m= line") [RFC4566], and the associated
   semantics.  Multiple fingerprints are needed if an endpoints wants to
   provide fingerprints associated with multiple certificates.  For
   example, with RTP-based media, an endpoint might use different
   certificates for RTP and RTCP. stream that uses a connection-
   oriented transport.  RFC 4572 also 4145, Connection-Oriented Media Transport in
   the Session Description Protocol (SDP) [10], specifies a preferred cipher suite.  However, general
   mechanism for describing and establishing such connection-oriented
   streams; however, the
   currently preferred cipher suite only transport protocol it directly supports is considered outdated,
   TCP.  In many cases, session participants wish to provide
   confidentiality, data integrity, and authentication for their media
   sessions.  This document therefore extends the
   preference needs Connection-Oriented
   Media specification to be updated.

   RFC 4572 mandates that the hash function used allow session descriptions to calculate the
   fingerprint is describe media
   sessions that use the same hash function used Transport Layer Security (TLS) protocol [13].

   TLS protocol allows applications to calculate communicate over a channel t
   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
   certificate signature.  That requirement might prevent usage question of
   newer, stronger how to
   interpret and more collision-safe hash functions validate authentication certificates as an issue for
   calculating certificate fingerprints.  This change also requires
   the protocols that
   multiple 'fingerprint' attributes can 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 associated with
   unable to obtain authentication certificates signed by a single
   "m=" line, so that implementations are 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 provide fingerprints
   calculated using updated hash functions alongside those confirm that they are
   needed issuing the signed certificates to interoperate with existing implementations. 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 document updates RFC 4572 [RFC4572] by clarifying specification defines
   a mechanism that allows self-signed certificates can be used
   securely, provided that the usage integrity of
   multiple the SDP 'fingerprint' attributes. 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
   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.

   This document obsoletes [25] but remains backwards compatible with
   older implementations.  The changes from [25] are that it clarified
   that multiple 'fingerprint' attributes can be used to carry
   fingerprints, calculated using different hash functions, associated
   with a given certificate, and to carry fingerprints associated with
   multiple certificates.  The fingerprint matching procedure, when
   multiple fingerprints are provided, are also clarified.  The document
   also updates the preferred cipher suite with a stronger cipher suite,
   and removes the requirement to use the same hash function for
   calculating a certificate fingerprint and certificate signature.

   NOTE: Even though this document updates the procedures in RFC 4572,
   it does not make existing implementations non-compliant with RFC
   4572.  The updated procedures in

2.  Terminology

   In this document have been defined in
   order to be backward compatible with document, the procedures in RFC 4572.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Update to RFC 4572 2119 [5] and
   indicate requirement levels for compliant implementations.

3.  Overview

   This section updates section 5 of RFC 4572.

3.1.  Update to discusses the sixth paragraph of section 5
 OLD TEXT:

    A certificate fingerprint MUST be computed using the same one-way
    hash function as is used in the certificate's signature algorithm.
    (This ensures threat model that the security properties required for the
    certificate also apply motivates TLS transport
   for the fingerprint. connection-oriented media streams.  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, discusses in more
   detail the defined hash functions need for end systems to use self-signed certificates.

3.1.  SDP Operational Modes

   There are 'SHA-1' [11]
    [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11]
    , 'MD5' [12], two principal operational modes for multimedia sessions:
   advertised and 'MD2' [13], with 'SHA-1' preferred.  A new IANA
    registry of Hash Function Textual Names, specified offer-answer.  Advertised sessions are the simpler
   mode.  In this mode, a server publishes, in Section 8,
    allows for addition some manner, an SDP
   session description of future tokens, but they may only be added if
    they are included a multimedia session it is making available.
   The classic example of this mode of operation is the Session
   Announcement Protocol (SAP) [17], in RFCs that update or obsolete RFC 3279 [7].
    Self-signed certificates (for which legacy certificates SDP session descriptions
   are not periodically transmitted to 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 well-known multicast group.
   Traditionally, these descriptions involve multicast conferences, but
   unicast sessions are also MUST possible.  (Connection-oriented media,
   obviously, cannot use it multicast.)  Recipients of a session
   description connect to calculate certificate fingerprints.

 NEW TEXT:

    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-256' preferred. A new IANA registry of Hash
    Function Textual Names, specified addresses published in Section 8, allows for addition
    of future tokens, but they the session
   description.  These recipients may only be added if they are included
    in RFCs that update or obsolete RFC 3279 [7].

3.2.  New paragraphs not previously have been known to
   the end advertiser of section 5
NEW TEXT:

    Multiple the session description.

   Alternatively, SDP fingerprint attributes conferences can be associated with an m-
    line. operate in offer-answer mode [6].
   This can occur if multiple fingerprints have been calculated
    for mode allows two participants in a certificate using different hash functions. It can also
    occur if multimedia session to
   negotiate the multimedia session between them.  In this model, one or more fingerprints associated
   participant offers the other a description of the desired session
   from its perspective, and the other participant answers with multiple
    certificates have been calculated. the
   desired session from its own perspective.  In this mode, each of the
   participants in the session has knowledge of the other one.  This might be needed if multiple
    certificates will be is
   the mode of operation used by the Session Initiation Protocol (SIP)
   [19].

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 m- line
    (e.g. if separate certificates 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 [22] can be used to
   secure session descriptions.

3.3.  The Need for RTP and 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.

   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 [10], 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 [14] 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 [13] 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
   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 [10].  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 [2] 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 [15], 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 [11] in Figure 2.  This syntax extends the BNF
   syntax of SDP [14].

   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

   Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the
   defined hash functions are 'SHA-1' [1] [18], 'SHA-224' [1], 'SHA-256'
   [1], 'SHA-384'[1], 'SHA-512' [1], 'MD5' [4], and 'MD2' [3], with
   'SHA-256' 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].

   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.

5.1.  Multiple Fingerprints

   Multiple SDP fingerprint attributes can be associated with an m-
   line.  This can occur if multiple fingerprints have been calculated
   for a certificate using different hash functions.  It can also occur
   if one or more fingerprints associated with multiple certificates
   have been calculated.  This might be needed if multiple certificates
   will be used for media associated with an m- line (e.g. if separate
   certificates are used for RTP and RTCP), or where
    it where it is not known
   which certificate will be used when the fingerprints are exchanged.
   In such cases, one or more fingerprints MUST be calculated for each
   possible certificate.

   An endpoint MUST, as a minimum, calculate a fingerprint using both
   the 'SHA-256' hash function algorithm and the hash function used to
   generate the signature on the certificate for each possible
   certificate.  Including the hash from the signature algorithm ensures
   interoperability with strict implementations of RFC 4572 [25].
   Either of these fingerprints MAY be omitted if the endpoint includes
   a hash with a stronger hash algorithm that it knows that the peer
   supports, if it is known that the peer does not support the hash
   algorithm, or if local policy mandates use of stronger algorithms.

   If fingerprints associated with multiple certificates are calculated,
   the same set of hash functions MUST be used to calculate fingerprints
   for each certificate associated with the m- line.

   For each used certificate, an endpoint MUST be able to match at least
   one fingerprint, calculated using the hash function that the endpoint
   supports and considers most secure, with the used certificate.  If
   the checked fingerprint does not match the used certificate, the
   endpoint MUST NOT establish the TLS connection.  In addition, the
   endpoint MAY also check fingerprints calculated using other hash
   functions that it has received for a match.  For each hash function
   checked, one of the received fingerprints calculated using the hash
   function MUST match the used certificate.

   NOTE: The SDP fingerprint attribute does not contain a reference to a
   specific certificate.  Endpoints need to compare the fingerprint with
   a certificate hash in order to look for a match.

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 [16] or secured by S/MIME [22] 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 [19], 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 [19]) 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
   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 [6] 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 [10]) 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 [17]), 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 [14] 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
   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 known which certificate will 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 used notified when the
    fingerprints are exchanged. In such cases, one or more fingerprints
    MUST an unsecured certificate associated
   with a previously unknown end system is presented and SHOULD be calculated for each possible certificate. An endpoint
    MUST, as
   strongly warned if a minimum, calculate different unsecured certificate is presented by
   a fingerprint using both the 'SHA-256'
    hash function algorithm and the hash function used to generate party with which they have communicated in the
    signature on past.  In this way,
   even in the certificate absence of integrity protection for each possible certificate.
    Including the hash from SDP, the signature algorithm ensures
    interoperability with strict implementations security of RFC 4572.
    Either
   this document's mechanism is equivalent to that of these fingerprints MAY be omitted if the endpoint includes
    a hash with a stronger hash algorithm Secure Shell
   (ssh) protocol [23], which is vulnerable to man-in-the-middle attacks
   when two parties first communicate, but can detect ones that it knows occur
   subsequently.  (Note that a precise definition of the peer
    supports, if it is known that "other party"
   depends on the peer does not support application protocol carrying the hash
    algorithm, or if local policy mandates use of stronger algorithms.

    If fingerprints associated with multiple 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
   [19], SIP over TLS) are
    calculated, considered sufficiently secure to allow the same set of hash functions MUST
   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 to
    calculate fingerprints for each certificate associated with in deployed networks in
   the
    m- line.

    For each used certificate, an endpoint MUST be able short to match at
    least one fingerprint, calculated using the hash function 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 the
    endpoint supports are secured in only a hop-by-hop manner, and considers most secure, with the used
    certificate. If the checked fingerprint does definitions of
   media formats running over TCP/TLS MAY specify that only end-to-end
   integrity mechanisms be used.

   Depending on how SDP messages are transmitted, it is not match the used
    certificate, always
   possible to determine whether or not a subjectAltName presented in a
   remote certificate is expected for the endpoint MUST NOT establish remote party.  In particular,
   given call forwarding, third-party call control, or session
   descriptions generated by endpoints controlled by the TLS connection. Gateway Control
   Protocol [20], it is not always possible in SIP to determine what
   entity ought to have generated a remote SDP response.  In
    addition, 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 MAY also check fingerprints calculated using receives a certificate over SIP
   asserting an identity (including an iPAddress or dNSName identity)
   other hash functions that than the one to which it has 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 match. For each
    hash function checked, 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 of the received fingerprints calculated
    using the hash function MUST match specific to this
   specification; the used certificate.

    NOTE: The same consideration applies for S/MIME-signed SDP fingerprint attribute
   carried over SIP.)

   This document does not contain define any mechanism for securely transporting
   RTP and RTP Control Protocol (RTCP) packets over a reference connection-
   oriented channel.  There was no consensus in the working group as to
   whether it would be better to send Secure RTP packets [21] over a specific certificate. Endpoints need
   connection-oriented transport [24], or whether it would be better to compare
   send standard unsecured RTP packets over TLS using the fingerprint
    with a certificate hash mechanisms
   described in order this document.  The group consensus was to look 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 match.

4.  Security Considerations higher- or lower-level security
   protocol may be appropriate.

   This document improves security. security from the RFC 4572 [25].  It updates
   the preferred hash function cipher suite from SHA-1 to SHA-256.  By
   clarifying the usage and handling of multiple fingerprints, the
   document also enables hash agility, and incremental deployment of
   newer, and more secure, cipher suites.

5.

8.  IANA Considerations

   IANA is requested

   Note to add a reference IANA.  No IANA considerations are changed from RFC4572 [25]
   so the only actions required are to update the registreis to point at
   this specification.

   This document for the att-
   field (both 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) registration "fingerprint" media-level attribute:
   'fingerprint'.  Its format is defined in
   Session Section 5.  This attribute
   has been registered by IANA under "Session Description Protocol (SDP) Parameters registry.

6.  Acknowledgements

   Martin Thomson, Paul Kyzivat, Jonathan Lennox and Roman Shpount
   provided valuable comments
   Parameters" under "att-field (both session and input on this document.

7.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-ietf-mmusic-4572-update-05

   o  Change of document title.

   Changes from draft-ietf-mmusic-4572-update-05

   o  Added a requirement to generate a fingerprint media level)".

   The SDP specification [14] states that matches specifications defining new
   proto values, like the
      signature.

   o  Added text clarifying that updates do not make existing
      implementations non-compliant with RFC 4572.

   o  IANA Considerations text added.

   Changes from draft-ietf-mmusic-4572-update-04

   o  Removed prevously added requirement that endpoint 'TCP/TLS' proto value defined in this one,
   must calcuate at
      least one fingerprint using a hash function that was also used define the rules by which their media format (fmt) namespace is
   managed.  For the peer.

   Changes from draft-ietf-mmusic-4572-update-03

   o  Mandatory (except in specific situations) to provide a fingerprint
      calculated using SHA-256.

   o  When TCP/TLS protocol, new formats SHOULD have an endpoint receives fingerprints from its peer,
   associated MIME registration.  Use of an existing MIME subtype for
   the endpoint
      must (except in specific situations) calculate at least format is encouraged.  If no MIME subtype exists, it is
   RECOMMENDED that a suitable one
      fingerpint using be registered through the IETF
   process [12] by production of, or reference to, a hash function standards-track RFC
   that was also used by defines the peer.

   Changes from draft-ietf-mmusic-4572-update-02
   o  Editorial fixes based on comments from Martin Thomson.

   o  Non-used references removed.

   Changes from draft-ietf-mmusic-4572-update-01

   o  Changes based on comments from Martin Thomson.

   o  - Editorial fixes

   o  Changes in handling transport protocol for the format.

   This specification creates a new IANA registry named "Hash Function
   Textual Names".  It will not be part of multiple fingerprints.

   o  - Sender must send same set the SDP Parameters.

   The names of hash functions used for each offered
      certificate.

   o  - Receiver must check 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 it considers most secure
      for a match.  It may check other hash functions.

   Changes from draft-ietf-mmusic-4572-update-00 function textual name, the following
   information MUST be provided:

   o  Changes in handling  The textual name of multiple fingerprints. the hash function.

   o  - Number  The Object Identifier (OID) of fingerprints calculated for each certificate does not
      have to match.

   o  - Clarified that receiver shall check check fingerprints using the hash algorithms it considers safe. function as used in X.509
      certificates.

   o  - Additional text added  A reference to security considerations section.

   Changes from draft-holmberg-mmusic-4572-update-01

   o  Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted.

   o the standards-track RFC, updating or obsoleting RFC
      3279 [7], defining the use of the hash function in X.509
      certificates.

   Table 1 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 |
        +--------------------+------------------------+-----------+

             Table 1: IANA considerations section added.

8. Hash Function Textual Name Registry

9.  References

9.1.  Normative References

   [RFC2119]

   [1]        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>.

   [2]        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.

   [3]        Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
              DOI 10.17487/RFC1319, April 1992,
              <http://www.rfc-editor.org/info/rfc1319>.

   [4]        Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <http://www.rfc-editor.org/info/rfc1321>.

   [5]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4566]

   [6]        Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [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, DOI 10.17487/RFC3279, April
              2002, <http://www.rfc-editor.org/info/rfc3279>.

   [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,
              DOI 10.17487/RFC3280, April 2002,
              <http://www.rfc-editor.org/info/rfc3280>.

   [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,
              DOI 10.17487/RFC4055, June 2005,
              <http://www.rfc-editor.org/info/rfc4055>.

   [10]       Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              DOI 10.17487/RFC4145, September 2005,
              <http://www.rfc-editor.org/info/rfc4145>.

   [11]       Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234,
              October 2005, <http://www.rfc-editor.org/info/rfc4234>.

   [12]       Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
              December 2005, <http://www.rfc-editor.org/info/rfc4288>.

   [13]       Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346,
              DOI 10.17487/RFC4346, April 2006,
              <http://www.rfc-editor.org/info/rfc4346>.

   [14]       Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC4572]

9.2.  Informative References

   [15]       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, DOI 10.17487/RFC2617, June 1999,
              <http://www.rfc-editor.org/info/rfc2617>.

   [16]       Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [17]       Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
              October 2000, <http://www.rfc-editor.org/info/rfc2974>.

   [18]       Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
              <http://www.rfc-editor.org/info/rfc3174>.

   [19]       Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [20]       Groves, C., Ed., Pantaleo, M., Ed., Anderson, T., Ed., and
              T. Taylor, Ed., "Gateway Control Protocol Version 1",
              RFC 3525, DOI 10.17487/RFC3525, June 2003,
              <http://www.rfc-editor.org/info/rfc3525>.

   [21]       Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.

   [22]       Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, DOI 10.17487/RFC3851, July 2004,
              <http://www.rfc-editor.org/info/rfc3851>.

   [23]       Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <http://www.rfc-editor.org/info/rfc4251>.

   [24]       Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
              and RTP Control Protocol (RTCP) Packets over Connection-
              Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
              2006, <http://www.rfc-editor.org/info/rfc4571>.

   [25]       Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572,
              DOI 10.17487/RFC4572, July 2006,
              <http://www.rfc-editor.org/info/rfc4572>.

Author's Address

Appendix A.  Acknowledgments

   This version of the document included significant contributions by
   Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson.

Authors' Addresses

   Jonathan Lennox
   Vidyo

   Email: jonathan@vidyo.com

    Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com