[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4572

Multiparty Multimedia Session                                  J. Lennox
Control                                                      Columbia U.
Internet-Draft                                            April 26, 2004
Expires: October 25, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 October 25, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document describes how to express connection-oriented media
   transport over the Transport Layer Security (TLS) protocol using the
   Session Description Protocol.  It defines a new protocol identifier,
   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.






Lennox                  Expires October 25, 2004                [Page 1]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Identifiers . . . . . . . . . . . . . . . . . . . . .  4
   4.  Fingerprint Attribute  . . . . . . . . . . . . . . . . . . . .  4
   5.  Endpoint Identification  . . . . . . . . . . . . . . . . . . .  5
     5.1   Certificate Choice . . . . . . . . . . . . . . . . . . . .  5
     5.2   Certificate Presentation . . . . . . . . . . . . . . . . .  6
   6.  Example SDP description for TLS connection . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.1   Normative References . . . . . . . . . . . . . . . . . . . .  8
   9.2   Informative References . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 11


































Lennox                  Expires October 25, 2004                [Page 2]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


1.  Introduction

   The document Connection-Oriented Media Transport in SDP [1] describes
   how to express media transport over connection-oriented protocols
   using the Session Description Protocol [2].  SDP is a general-purpose
   format for describing multimedia sessions in announcements or
   invitations.  The Connection-Oriented Media document defines how SDP
   can be used for connection-oriented media, such as TCP, which must be
   explicitly connected before being used.  The connection-oriented
   media draft defines the connection setup procedure for such
   connections, and defines how SDP descriptions can advertise whether
   they wish to initiate and/or receive the media connections.

   In many cases, session participants wish to provide confidentiality,
   data integrity, and authentication for their media sessions.  For
   connection-oriented media, the Transport Layer Security (TLS)
   protocol [3] is an obvious and widely-implemented choice which can
   provide an encrypted data channel and authenticated client and server
   identities.  However, TLS cannot be used blindly; it is necessary to
   specify the appropriate certificates which each end party to a
   connection should present, so their counterparties can verify that
   they are indeed who they claim to be.

   Parties to a TLS session indicate their identities by presenting
   authentication certificates as part of the TLS handshake procedure.
   Authentication certificates are X.509 [4] certificates, as profiled
   by RFC 3279 [5] and RFC 3280 [6]. TLS leaves the issue of how to
   interpret these certificates as an issue for the protocols which run
   atop TLS.  Certificate interpretation is a critical issue, however;
   it does an endpoint no good to know only that its peer has a valid
   certificate, without also having some way of judging whether the
   identity that it certifies is indeed a correct one for its
   counterparty.

   Further complicating this issue, endpoints exchanging media will
   often be unable to afford to obtain certificates signed by a
   well-known root certificate authority.  Most certificate authorities
   charge for signed certificates, particularly host-based certificates;
   additionally, there is a substantial administrative overhead to
   obtaining signed certificates, as certificate authorities must be
   able to confirm that they are issuing the signed certificates to the
   correct party.

   This specification, therefore, defines how to signal TLS-based media
   sessions in SDP.  It describes what identities endpoints should
   present in certificates, and, assuming the integrity of SDP content
   is assured, allows the secure use of self-signed certificates.




Lennox                  Expires October 25, 2004                [Page 3]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


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 [7]
   and indicate requirement levels for compliant implementations.

3.  Protocol Identifiers

   The m= line in SDP is where an endpoint specifies the protocol used
   for the media in the session.  See the "Media Announcements" section
   of SDP [2] for a discussion on protocol identifiers.

   The protocol identifier "TLS" in a media description specifies that
   the media being described will use the Transport Layer Security
   protocol [3] with an implied transport protocol of TCP.   An m= line
   that specifies TLS MUST further qualify the protocol using a fmt
   identifier.

   As TLS sessions are connection-oriented, media sessions described in
   this manner are subject to the definitions given in the
   connection-oriented media specification [1].  This includes the
   "direction" and "reconnect" attributes, and also that specification's
   rules on session and connection lifetime.

4.  Fingerprint Attribute

   In order to associated media streams with connections, and to prevent
   unauthorized barge-in attacks on the media streams, endpoints can
   optionally 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 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
   openssl package's command-line tool 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 hexidecimal 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



Lennox                  Expires October 25, 2004                [Page 4]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


   from the syntax used to represent hash values in, e.g., HTTP digest
   authentication [13], which uses unseparated lower-case hexidecimal
   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 [8] in Figure 1.  This syntax extends the BNF syntax
   of SDP [2].

   attribute              =/ fingerprint-attribute

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

   hash-func              =  "sha-1" / "md5" / "md2" / token
                             ; New hash functions must be registered
                             ; with IANA.
                             ; TODO: figure out what IANA registry
                             ; this should reference.

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

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

  Figure 1: Abstract Backus-Naur Syntax for the Fingerprint Attribute

   A certificate fingerprint SHOULD be computed using the same hash
   function as is used by the certificate itself.  (This guarantees that
   the fingerprint will be usable by the other endpoint so long as the
   certificate itself is.) Following RFC 3279 [5], therefore, the
   defined hash functions are SHA-1 [9][14], MD5 [10], and MD2 [11],
   with SHA-1 preferred.

   (TODO: figure out what IANA or other registry lists hash functions.)

   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.  Endpoint Identification

5.1  Certificate Choice

   X.509 certificates certify identities.  The certificate provided for
   a TLS connection needs to certify an appropriate identity for the
   connection.  Identity matching is performed using the matching rules



Lennox                  Expires October 25, 2004                [Page 5]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


   specified by RFC 3280 [6].  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.

   If an endpoint does not provide a certificate fingerprint in its SDP,
   its certificate MUST correspond to one of the following identities,
   and MUST be signed by a well-known certificate authority.  If the
   endpoint does provide a certificiate fingerprint, the certificate
   SHOULD indicate one of these identities.  In all cases, the
   certificate MUST indicate some identity which has a meaningful
   relationship to the end point.

   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.
   o  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
      connection address.  Names may contain the wildcard character *
      which is considered to match any single domain name component or
      component fragment.  E.g., *.a.com matches foo.a.com but not
      bar.foo.a.com.  f*.com matches foo.com but not bar.com.
   o  Finally, if the SDP describing the connection was transmitted over
      a secure protocol which uses X.509 certificates to certify the
      endpoints of the connection, the endpoint MAY use the same
      certificate to certify the media connection.  (For example, an SDP
      description sent over HTTP/TLS [15] or secured by S/MIME [16] MAY
      use the same certificate to secure the media connection.  Note,
      however, that the sips: protocol (SIP over TLS) [17] provides only
      hop-by-hop security, so this certificate does not satisfy this
      criterion.  Such a certificate could satisify one of the previous
      two points, however.)

5.2  Certificate Presentation

   In all cases, an endpoint acting as the TLS server -- i.e., one
   taking the direction:passive role, in the terminology of
   connection-oriented media -- MUST present a certificate during TLS
   initiation, following the rules presented in Section 5.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 or terminate the connection with
   a bad certificate error.

   If the SDP offer/answer model [12] is being used, the client (the
   endpoint with the direction:active role) MUST also present a
   certificate following the rules of Section 5.1.  The server MUST



Lennox                  Expires October 25, 2004                [Page 6]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


   request a certificate, and if the client does not provide one, 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 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 direction:passive or
   direction:both role, it MUST (as specified in the connection-oriented
   media specification [1]) 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 SHOULD NOT definitively accept
   or rejecting the peer's certificate until it has received and
   processed the SDP answer.

   If offer/answer is not being used (e.g., if the SDP was sent over the
   Session Announcement Protocol [18]), the server typically has no
   external knowledge of what the client's identity ought to be.  In
   this case, no client certificate need be presented, and no
   certificate validation can be performed, unless the server has
   knowledge of valid clients through some external means.

6.  Example SDP description for TLS connection

   Figure 2 illustrates an SDP offer to signal the availability of a
   T.38 fax session over TLS.  (This example is the same as the one in
   [1], except for the transport parameter and the fingerprint
   attribute.)

   v=0
   o=me 2890844526 2890842807 IN IP4 10.1.1.2
   s=Call me using TCP
   t=3034423619 3042462419
   c=IN IP4 10.1.1.2
   m=image 54111 TLS t38
   a=direction:passive
   a=fingerprint:MD5 48:AA:D8:BA:36:7C:6D:70:7F:81:BB:BA:ED:6D:B8:C7

     Figure 2: Example SDP description offering a TLS media stream


7.  Security Considerations

   This entire document concerns itself with security.

   Like all SDP messages, SDP messages describing TLS streams are
   conveyed in an encapsulating application protocol (e.g., SIP, MGCP,



Lennox                  Expires October 25, 2004                [Page 7]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


   etc.). It is the responsibility of the encapsulating protocol to
   ensure the protection 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 and
   packet-payload encryption as well as effective replay protection.

   TLS is not always the most appropriate choice for secure
   connection-oriented media; in some cases, a higher-level security
   protocol may be appropriate.  For example, RTP and RTCP packets may
   be sent over a connection-oriented transport [19].  In this case, it
   is often more appropriate to use the Secure RTP protocol [20] with
   appropriate SDP descriptions [21].

8.  IANA Considerations

   This document registers the "TLS" protocol identifier and the
   "fingerprint" attribute for SDP, as specified by Appendix B of the
   SDP specification [2].

9.  References

9.1  Normative References

   [1]   Yon, D., "Connection-Oriented Media Transport in SDP",
         draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
         2003.

   [2]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

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

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

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

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



Lennox                  Expires October 25, 2004                [Page 8]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


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

   [8]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [9]   National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-1, April 1995, <http://
         www.itl.nist.gov/fipspubs/fip180-1.htm>.

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

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

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

9.2  Informative References

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

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

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

   [16]  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
         2633, June 1999.

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

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

   [19]  Lazzaro, J., "Framing RTP and RTCP Packets over
         Connection-Oriented Transport",
         draft-ietf-avt-rtp-framing-contrans-01 (work in progress),
         March 2004.

   [20]  Baugher, M., "The Secure Real-time Transport Protocol",
         draft-ietf-avt-srtp-09 (work in progress), July 2003.




Lennox                  Expires October 25, 2004                [Page 9]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


   [21]  Andreasen, F., Baugher, M. and D. Wing, "Session Description
         Protocol Security Descriptions for Media Streams",
         draft-ietf-mmusic-sdescriptions-03 (work in progress), February
         2004.

   [22]  Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
         Description Protocol", draft-ietf-mmusic-sdp-new-15 (work in
         progress), October 2003.


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






























Lennox                  Expires October 25, 2004               [Page 10]


Internet-Draft    Connection-Oriented Media over TLS in SDP   April 2004


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 IETF's procedures with respect to rights in IETF 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 (2004). 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.




Lennox                  Expires October 25, 2004               [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/