One document matched: draft-ietf-mmusic-comedia-tls-04.txt
Differences from draft-ietf-mmusic-comedia-tls-03.txt
Multiparty Multimedia Session J. Lennox
Control Columbia U.
Internet-Draft July 6, 2005
Expires: January 7, 2006
Connection-Oriented Media Transport over the Transport Layer Security
(TLS) Protocol in the Session Description Protocol (SDP)
draft-ietf-mmusic-comedia-tls-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies how to establish secure connection-oriented
media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines a
new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax
and semantics for an SDP 'fingerprint' attribute that identifies the
certificate which will be presented for the TLS session. This
mechanism allows media transport over TLS connections to be
Lennox Expires January 7, 2006 [Page 1]
Internet-Draft Comedia over TLS in SDP July 2005
established securely, so long as the integrity of session
descriptions is assured.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 The Need For Self-Signed Certificates . . . . . . . . . . 5
3.4 Example SDP Description For TLS Connection . . . . . . . . 6
4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 6
5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 8
6.1 Certificate Choice . . . . . . . . . . . . . . . . . . . . 8
6.2 Certificate Presentation . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
A. Changes From Earlier Versions . . . . . . . . . . . . . . . . 12
A.1 Changes From Draft -03 . . . . . . . . . . . . . . . . . . 12
A.2 Changes From Draft -02 . . . . . . . . . . . . . . . . . . 12
A.3 Changes From Draft -01 . . . . . . . . . . . . . . . . . . 12
A.4 Changes From Draft -00 . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Normative References . . . . . . . . . . . . . . . . . . . 13
9.2 Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Lennox Expires January 7, 2006 [Page 2]
Internet-Draft Comedia over TLS in SDP July 2005
1. Introduction
The Session Description Protocol (SDP) [1] provides a general purpose
format for describing multimedia sessions in announcements or
invitations. For many applications, it is desirable to establish, as
part of a multimedia session, a media stream which uses a connection-
oriented transport. The document Connection-Oriented Media Transport
in the Session Description Protocol (SDP) [2] specifies a general
mechanism for describing and establishing such connection-oriented
streams; however, the only transport protocol it directly supports is
TCP. In many cases, session participants wish to provide
confidentiality, data integrity, and authentication for their media
sessions. This document therefore extends the Connection-Oriented
Media specification to allow session descriptions to describe media
sessions that use the Transport Layer Security (TLS) protocol [3].
The TLS protocol allows applications to communicate over a channel
which provides privacy and data integrity. The TLS specification,
however, does not specify how specific protocols establish and use
this secure channel; particularly, TLS leaves the question of how to
interpret and validate authentication certificates as an issue for
the protocols which run over TLS. This document specifies such usage
for the case of connection-oriented media transport.
Complicating this issue, endpoints exchanging media will often be
unable to obtain authentication certificates signed by a well-known
root certificate authority (CA). Most certificate authorities charge
for signed certificates, particularly host-based certificates;
additionally, there is a substantial administrative overhead to
obtaining signed certificates, as certificate authorities must be
able to confirm that they are issuing the signed certificates to the
correct party. Furthermore, in many cases endpoints' IP addresses
and host names are dynamic: they may be obtained from DHCP, for
example. It is impractical to obtain a CA-signed certificate valid
for the duration of a DHCP lease. For such hosts, self-signed
certificates are usually the only option. This specification defines
a mechanism which allows self-signed certificates can be used
securely, provided that the integrity of the SDP description is
assured. It provides for endpoints to include a secure hash of their
certificate, known as the "certificate fingerprint", within the
session description. Provided the fingerprint of the offered
certificate matches the one in the session description, end hosts can
trust even self-signed certificates.
The rest of this document is laid out as follows. An overview of the
problem and threat model is given in Section 3. Section 4 gives the
basic mechanism for establishing TLS-based connected-oriented media
in SDP. Section 5 describes the SDP fingerprint attribute, which,
Lennox Expires January 7, 2006 [Page 3]
Internet-Draft Comedia over TLS in SDP July 2005
assuming the integrity of SDP content is assured, allows the secure
use of self-signed certificates. Section 6 describes which X.509
certificates are presented, and how they are used in TLS. Section 7
discusses additional security considerations.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant implementations.
3. Overview
This section discusses the threat model which motivates TLS transport
for connection-oriented media streams. It also discusses in more
detail the need for end systems to use self-signed certificates.
3.1 SDP Operational Modes
There are two principal operational modes for multimedia sessions:
advertised and offer-answer. Advertised sessions are the simpler
mode. In this mode, a server publishes, in some manner, an SDP
session description describing a multimedia session it is making
available. The classic example of this mode of operation is the
Session Announcement Protocol (SAP) [15], in which SDP session
descriptions are periodically transmitted to a well-known multicast
group. Traditionally, these descriptions involve multicast
conferences, but unicast sessions are also possible. (Connection-
oriented media, obviously, cannot use multicast.) Recipients of a
session description connect to the addresses published in the session
description. These recipients may not previously have been known to
the advertiser of the session description.
Alternatively, SDP conferences can operate in offer-answer mode [5].
This mode allows two participants in a multimedia session to
negotiate the multimedia session between them. In this model, one
participant offers the other a description of the desired session
from its perspective, and the other participant answers with the
desired session from its own perspective. In this mode, each of the
participants in the session has knowledge of the other one. This is
the mode of operation used by the Session Initiation Protocol (SIP)
[16].
3.2 Threat Model
Participants in multimedia conferences often wish to guarantee
confidentiality, data integrity, and authentication for their media
Lennox Expires January 7, 2006 [Page 4]
Internet-Draft Comedia over TLS in SDP July 2005
sessions. This section describes various types of attackers and the
ways they attempt to violate these guarantees. It then describes how
the TLS protocol can be used to thwart the attackers.
The simplest type of attacker is one who listens passively to the
traffic associated with a multimedia session. This attacker might,
for example, be on the same local-area or wireless network as one of
the participants in a conference. This sort of attacker does not
threaten a connection's data integrity or authentication, and almost
any operational mode of TLS can provide media stream confidentiality.
More sophisticated is an attacker who can send his own data traffic
over the network, but who cannot modify or redirect valid traffic.
In SDP's 'advertised' operational mode, this can barely be considered
an attack; media sessions are expected to be initiated from anywhere
on the network. In SDP's offer-answer mode, however, this type of
attack is more serious. An attacker could initiate a connection to
one or both of the endpoints of a session, thus impersonating an
endpoint, or acting as a man in the middle to listen in on their
communications. To thwart these attacks, TLS uses endpoint
certificates. So long as the certificates' private keys have not
been compromised, the endpoints have an external trusted mechanism
(most commonly, a mutually-trusted certificate authority) to validate
certificates, and the endpoints know what certificate identity to
expect, endpoints can be certain that such an attack has not taken
place.
Finally, the most serious type of attacker is one who can modify or
redirect session descriptions: for example, a compromised or
malicious SIP proxy server. Neither TLS itself, nor any mechanisms
which use it, can protect an SDP session against such an attacker.
Instead, the SDP description itself must be secured through some
mechanism; SIP, for example, defines how S/MIME [17] can be used to
secure session descriptions.
3.3 The Need For Self-Signed Certificates
SDP session descriptions are created by any endpoint that needs to
participate in a multimedia session. In many cases, such as SIP
phones, such endpoints have dynamically-configured IP addresses and
host names, and must be deployed with nearly zero configuration. For
such an endpoint, it is for practical purposes impossible to obtain a
certificate signed by a well-known certificate 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,
Lennox Expires January 7, 2006 [Page 5]
Internet-Draft Comedia over TLS in SDP July 2005
it is possible to consider those SDP descriptions themselves as a
prior relationship: certificates can be securely described in the
session description itself. This is done by providing a secure hash
of a certificate, or "certificate fingerprint", as an SDP attribute;
this mechanism is described in Section 5.
3.4 Example SDP Description For TLS Connection
Figure 1 illustrates an SDP offer which signals the availability of a
T.38 fax session over TLS. For the purpose of brevity, the main
portion of the session description is omitted in the example, showing
only the 'm' line and its attributes. (This example is the same as
the first one in [2], except for the proto parameter and the
fingerprint attribute.) See the subsequent sections for explanations
of the example's TLS-specific attributes.
(Note: due to RFC formatting conventions, this draft splits SDP
across lines whose content would exceed 72 characters. A backslash
character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in
actual SDP content.)
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 1: Example SDP Description Offering a TLS Media Stream
4. Protocol Identifiers
The 'm' line in SDP specifies, among other items, the transport
protocol to be used for the media in the session. See the "Media
Descriptions" section of SDP [1] for a discussion on transport
protocol identifiers.
This specification defines a new protocol identifier, 'TCP/TLS',
which indicates that the media described will use the Transport Layer
Security protocol [3] over TCP. (Using TLS over other transport
protocols is not discussed by this document.) The 'TCP/TLS' protocol
identifier describes only the transport protocol, not the upper-layer
protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify
the protocol using a fmt identifier, to indicate the application
being run over TLS.
Lennox Expires January 7, 2006 [Page 6]
Internet-Draft Comedia over TLS in SDP July 2005
Media sessions described with this identifier follow the procedures
defined in the connection-oriented media specification [2]. They
also use the SDP attributes defined in that specification, 'setup'
and 'connection'.
5. Fingerprint Attribute
Parties to a TLS session indicate their identities by presenting
authentication certificates as part of the TLS handshake procedure.
Authentication certificates are X.509 [6] certificates, as profiled
by RFC 3279 [7], RFC 3280 [8] and RFC 4055 [9].
In order to associate media streams with connections, and to prevent
unauthorized barge-in attacks on the media streams, endpoints MUST
provide a certificate fingerprint. If the X.509 certificate
presented for the TLS connection matches the fingerprint presented in
the SDP, the endpoint can be confident that the author of the SDP is
indeed the initiator of the connection.
A certificate fingerprint is a secure one-way hash of the DER
(distinguished encoding rules) form of the certificate. (Certificate
fingerprints are widely supported by tools which manipulate X.509
certificates; for instance, the command "openssl x509 -fingerprint"
causes the command-line tool of the openssl package to print a
certificate fingerprint, and the certificate managers for Mozilla and
Internet Explorer display them when viewing the details of a
certificate.)
A fingerprint is represented in SDP as an attribute (an 'a' line).
It consists of the name of the hash function used, followed by the
hash value itself. The hash value is represented as a sequence of
upper-case hexadecimal bytes, separated by colons. The number of
bytes is defined by the hash function. (This is the syntax used by
openssl and by the browsers' certificate managers. It is different
from the syntax used to represent hash values in, e.g., HTTP digest
authentication [18], which uses unseparated lower-case hexadecimal
bytes. It was felt that consistency with other applications of
fingerprints was more important.)
The formal syntax of the fingerprint attribute is given in Augmented
Backus-Naur Form [10] in Figure 2. This syntax extends the BNF
syntax of SDP [1].
Lennox Expires January 7, 2006 [Page 7]
Internet-Draft Comedia over TLS in SDP July 2005
attribute =/ fingerprint-attribute
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" /
"md5" / "md2" / token
; Additional hash functions can only come
; from updates to RFC 3279
fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
A certificate fingerprint MUST be computed using the same one-way
hash function as is used in the certificate's signature algorithm.
(This guarantees that the fingerprint will be usable by the other
endpoint, so long as the certificate itself is.) Following RFC 3279
[7] as updated by RFC 4055 [9], therefore, the defined hash functions
are 'SHA-1' [11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384'
[11], 'SHA-512' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1'
preferred. Additional hash functions can be defined only by
standards-track RFCs which update or obsolete RFC 3279 [7]. Self-
signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA-
224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and
thus also MUST use it to calculate certificate fingerprints.
The fingerprint attribute may be either a session-level or a media-
level SDP attribute. If it is a session-level attribute, it applies
to all TLS sessions for which no media-level fingerprint attribute is
defined.
6. Endpoint Identification
6.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
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.
Lennox Expires January 7, 2006 [Page 8]
Internet-Draft Comedia over TLS in SDP July 2005
The certificate presented by an endpoint MUST correspond to one of
the following identities:
o If the connection address for the media description is specified
as an IP address, the endpoint MAY use a certificate with an
iPAddress subjectAltName which exactly matches the IP in the
connection-address in the session description's 'c' line.
o If 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 If the SDP session description describing the session was
transmitted over a protocol (such as SIP [16]) for which the
identities of session participants are defined by uniform resource
identifiers (URIs), the endpoint MAY use a certificate with a
uniformResourceIdentifier subjectAltName. The details of what
URIs are appropriate are dependent on the transmitting protocol.
(For more details on this, see Section 7.)
If the SDP session description describing the session was transmitted
over an end-to-end secure protocol which uses X.509 certificates, and
the certificates sent fulfill the requirements above (as they
normally would be expected to), the endpoint MAY use the same
certificate to certify the media connection. For example, an SDP
description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY use
the same certificate to secure the media connection. (Note, however,
that the sips protocol [16] (SIP over TLS) provides only hop-by-hop
security, so its TLS certificates do not satisfy this criterion.) To
support the use of certificate caches, as described in Section 7,
endpoints SHOULD consistently provide the same certificate for each
identity they support.
6.2 Certificate Presentation
In all cases, an endpoint acting as the TLS server, i.e., one taking
the 'setup:passive' role, in the terminology of connection-oriented
media, MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, or, if there is no fingerprint, the
certificate identity is incorrect, the client endpoint MUST either
notify the user, if possible, or terminate the media connection with
a bad certificate error.
If the SDP offer/answer model [5] is being used, the client (the
endpoint with the 'setup:active' role) MUST also present a
certificate following the rules of Section 6.1. The server MUST
request a certificate, and if the client does not provide one, if the
Lennox Expires January 7, 2006 [Page 9]
Internet-Draft Comedia over TLS in SDP July 2005
certificate does not match the provided fingerprint, or, if there was
no fingerprint, the certificate identity is incorrect, the server
endpoint MUST either notify the user or terminate the media
connection with a bad certificate error.
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in the Connection-Oriented Media
specification [2]) begin listening for an incoming connection as soon
as it sends its offer. However, because its peer's media connection
may outrace its answer, it MUST NOT definitively accept 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 [15]), the TLS server typically has no
external knowledge of what the TLS 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.
7. Security Considerations
This entire document concerns itself with security. The problem to
be solved is addressed in Section 1, and a high-level overview is
presented in Section 3. See the SDP specification [1] for security
considerations applicable to SDP in general.
Like all SDP messages, SDP messages describing TLS streams are
conveyed in an encapsulating application protocol (e.g., SIP, MGCP,
etc.). It is the responsibility of the encapsulating protocol to
ensure the integrity and confidentiality of the SDP security
descriptions. Therefore, the application protocol SHOULD either
invoke its own security mechanisms (e.g., secure multiparts) or
alternatively utilize a lower-layer security service (e.g., TLS or
IPSec). This security service SHOULD provide strong message
authentication and packet-payload encryption as well as effective
replay protection.
However, such integrity protection is not always possible. For these
cases, end systems SHOULD maintain a cache of certificates which
other parties have previously presented using this mechanism. If
possible, users SHOULD be notified when an unsecured certificate
associated with a previously unknown end system is presented, and
SHOULD be strongly warned if a different and unauthenticated
certificate is presented by a party with which they have communicated
in the past. In this way, even in the absence of integrity
protection for SDP, the security of this document's mechanism is
Lennox Expires January 7, 2006 [Page 10]
Internet-Draft Comedia over TLS in SDP July 2005
equivalent to that of the Secure Shell (ssh) protocol [21], which is
vulnerable to man-in-the-middle attacks when two parties first
communicate, but can detect ones that occur subsequently. (Note that
a precise definition of the "other party" depends on the application
protocol carrying the SDP message.)
Depending on how SDP messages are transmitted, it is not always
possible to determine whether a uniformResourceIdentifier
subjectAltName presented in a remote certificate is expected or not
for the remote party. In particular, given call forwarding and
third-party call control, it is not always possible in SIP to
determine what entity ought to have generated a remote SDP response.
In some cases this determination may need to be made by a human, as
automated logic may not be able to determine correctness. (For
example, "You placed this call to sip:alice@example.com, but the
remote certificate presented belongs to sip:bob@example.com.
Continue?") This issue is not one specific to this specification;
the same consideration applies for S/MIME-signed SDP carried over
SIP.
TLS is not always the most appropriate choice for secure connection-
oriented media; in some cases, a higher- or lower-level security
protocol may be appropriate.
This document does not define any mechanism for securely transporting
RTP and RTCP packets over a connection-oriented channel. There was
no consensus in the working group as to whether it would be better to
send Secure RTP packets [22] over a connection-oriented transport
[23], or whether it would be better to send standard unsecured RTP
packets over TLS using the mechanisms described in this document.
The group consensus was to wait until a use-case requiring secure
connection-oriented RTP was presented.
8. IANA Considerations
This document defines an SDP proto value: 'TCP/TLS'. Its format is
defined in Section 4. This proto value should be registered by IANA
on under "Session Description Protocol (SDP) Parameters" under
"proto".
This document defines an SDP session and media level attribute:
'fingerprint'. Its format is defined in Section 5. This attribute
should be registered by IANA under "Session Description Protocol
(SDP) Parameters" under "att-field (both session and media level)".
The SDP specification, RFC2327, states that specifications defining
new proto values, like the 'TCP/TLS' proto value defined in this one,
must define the rules by which their media format (fmt) namespace is
Lennox Expires January 7, 2006 [Page 11]
Internet-Draft Comedia over TLS in SDP July 2005
managed. For the TCP/TLS protocol, new formats SHOULD have an
associated MIME registration. Use of an existing MIME subtype for
the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one be registered through the IETF
process [14] by production of, or reference to, a standards-track RFC
that defines the transport protocol for the format.
Appendix A. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to
publication as an RFC.
Appendix A.1 Changes From Draft -03
The number of options in the protocol were significantly reduced: a
number of SHOULD requirements were elevated to MUST. Notably, the
use of the 'fingerprint' attribute, strict certificate identity
choices, and the use of the same digest algorithm for fingerprints as
for certificates were all made mandatory.
Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055 [9]
('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added.
Discussion was added about the difficulty of automatically
determining the URI a remote endpoint's certificate should assert,
especially in SIP in the presence of call forwarding or third-party
call control.
The document was aligned with version -10 of
draft-ietf-mmusic-comedia [2]. This consisted mostly of wording and
formatting changes.
Appendix A.2 Changes From Draft -02
None, other than IPR boilerplate and reference updates. Draft -03
was a resubmission to refresh the draft's presence in the Internet-
Drafts repository.
Appendix A.3 Changes From Draft -01
o Made the use of SHA-1 fingerprints mandatory in self-signed
certificates.
o Aligned with version -09 of draft-ietf-mmusic-comedia [2], also
drawing some wording changes from that document.
o Forbid the use of wildcards for the dNS subjectAltName.
o Eliminated requirements on identities provided with self-signed
certificates.
Lennox Expires January 7, 2006 [Page 12]
Internet-Draft Comedia over TLS in SDP July 2005
o Recommended the use of a certificate cache when SDP integrity
protection cannot be assured.
o Explained that there is no currently supported mechanism for
securely sending RTP over connection-oriented media.
o Described the procedure for establishing media formats for TCP/
TLS.
Appendix A.4 Changes From Draft -00
o Significantly expanded introduction and motivation sections.
o Significant clarifications to other sections.
o Aligned with version -07 of draft-ietf-mmusic-comedia [2].
Protocol identifier changed from TLS to TCP/TLS at that document's
recommendation.
9. References
9.1 Normative References
[1] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005.
[2] Yon, D., "Connection-Oriented Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10
(work in progress), November 2004.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] International Telecommunications Union, "Information technology
- Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks", ITU-T Recommendation X.509,
ISO Standard 9594-8, March 2000.
[7] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002.
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
Lennox Expires January 7, 2006 [Page 13]
Internet-Draft Comedia over TLS in SDP July 2005
[9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005.
[10] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[11] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/
publications/fips/fips180-2/fips180-2.pdf>.
[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992.
[14] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.
9.2 Informative References
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[17] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[21] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-22 (work in progress),
March 2005.
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Lennox Expires January 7, 2006 [Page 14]
Internet-Draft Comedia over TLS in SDP July 2005
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[23] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
Oriented Transport", draft-ietf-avt-rtp-framing-contrans-05
(work in progress), January 2005.
[24] Andreasen, F., "Session Description Protocol Security
Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-11 (work in progress),
June 2005.
Author's Address
Jonathan Lennox
Columbia University Department of Computer Science
450 Computer Science
1214 Amsterdam Ave., M.C. 0401
New York, NY 10027
US
Phone: +1 212 939 7018
Email: lennox@cs.columbia.edu
Lennox Expires January 7, 2006 [Page 15]
Internet-Draft Comedia over TLS in SDP July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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 January 7, 2006 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:42 |