One document matched: draft-ietf-mmusic-comedia-tls-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 17:19:40 |