draft-ietf-mmusic-sdescriptions-10.txt   draft-ietf-mmusic-sdescriptions-11.txt 
Internet Engineering Task Force Flemming Andreasen Internet Engineering Task Force Flemming Andreasen
MMUSIC Working Group Mark Baugher MMUSIC Working Group Mark Baugher
INTERNET-DRAFT Dan Wing INTERNET-DRAFT Dan Wing
EXPIRES: December 2005 Cisco Systems EXPIRES: December 2005 Cisco Systems
June, 2005 June, 2005
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-10.txt> <draft-ietf-mmusic-sdescriptions-11.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line ? skipping to change at page 2, line ?
describes a cryptographic key and other parameters, which serve to describes a cryptographic key and other parameters, which serve to
configure security for a unicast media stream in either a single configure security for a unicast media stream in either a single
message or a roundtrip exchange. The attribute can be used with a message or a roundtrip exchange. The attribute can be used with a
variety of SDP media transports and this document defines how to use variety of SDP media transports and this document defines how to use
it for the Secure Real-time Transport Protocol (SRTP) unicast media it for the Secure Real-time Transport Protocol (SRTP) unicast media
streams. The SDP crypto attribute requires the services of a data streams. The SDP crypto attribute requires the services of a data
security protocol to secure the SDP message. security protocol to secure the SDP message.
Table of Contents Table of Contents
1 Applicability.....................................................3 1 Introduction......................................................3
2 Notational Conventions............................................3 2 Notational Conventions............................................4
3 Introduction......................................................4 3 Applicability.....................................................5
4 SDP "Crypto" Attribute and Parameters.............................5 4 SDP "Crypto" Attribute and Parameters.............................5
4.1 Tag............................................................5 4.1 Tag............................................................6
4.2 Crypto-suite...................................................6 4.2 Crypto-suite...................................................6
4.3 Key Parameters.................................................6 4.3 Key Parameters.................................................6
4.4 Session Parameters.............................................7 4.4 Session Parameters.............................................7
4.5 Example........................................................7 4.5 Example........................................................7
5 General Use of the crypto Attribute...............................8 5 General Use of the crypto Attribute...............................8
5.1 Use With Offer/Answer..........................................8 5.1 Use With Offer/Answer..........................................8
5.1.1 Generating the Initial Offer - Unicast Streams............8 5.1.1 Generating the Initial Offer - Unicast Streams............8
5.1.2 Generating the Initial Answer - Unicast Streams...........9 5.1.2 Generating the Initial Answer - Unicast Streams...........9
5.1.3 Processing of the Initial Answer - Unicast Streams.......10 5.1.3 Processing of the Initial Answer - Unicast Streams.......10
5.1.4 Modifying the Session....................................10 5.1.4 Modifying the Session....................................10
skipping to change at page 3, line 19 skipping to change at page 3, line 19
10.2.2 Media Stream Transport Registry and Registration.........32 10.2.2 Media Stream Transport Registry and Registration.........32
10.3 Initial Registrations.......................................32 10.3 Initial Registrations.......................................32
10.3.1 Key Method...............................................32 10.3.1 Key Method...............................................32
10.3.2 SRTP Media Stream Transport..............................32 10.3.2 SRTP Media Stream Transport..............................32
11 Acknowledgements................................................33 11 Acknowledgements................................................33
12 Authors' Addresses..............................................33 12 Authors' Addresses..............................................33
13 Normative References............................................34 13 Normative References............................................34
14 Informative References..........................................34 14 Informative References..........................................34
15 Full Copyright Statement........................................36 15 Full Copyright Statement........................................36
1 Applicability 1 Introduction
RFC YYYY {Note to RFC Editor: replace "YYYY" with RFC number for
[keymgt]} provides similar cryptographic key distribution
capabilities, and is intended for use when the signaling is to be
confidential and/or integrity-protected separately from the keying
material.
In contrast, this specification carries the keying material within
the SDP message, and it is intended for use when the keying material
is protected along with the signaling. Implementations MUST employ
security mechanisms that provide confidentiality and integrity for
the keying material. When this specification is used in the context
of SIP [RFC3261], the application SHOULD employ either the SIPS URI
or S/MIME to provide protection for the SDP message and the keying
material that it contains. The use of transport layer or IP layer
security is NOT RECOMMENDED since the protection of the SDP message
and the keying material that it contains cannot be ensured through
all intermediate entities such as SIP proxies.
2 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary".
n^r is exponentiation where n is multiplied by itself r times; n and
r are integers. 0..k is an integer range of all integers from 0
through k inclusive.
The terms 'transport' and 'media transport' are used to mean
'transport protocol' as defined in RFC2327, page 20.
Explanatory notes are provided in several places throughout the
document; these notes are indented two spaces from the surrounding
text.
3 Introduction
The Session Description Protocol (SDP) [SDP] describes multimedia The Session Description Protocol (SDP) [SDP] describes multimedia
sessions, which can be audio, video, whiteboard, fax, modem, and sessions, which can be audio, video, whiteboard, fax, modem, and
other media streams. Security services such as data origin other media streams. Security services such as data origin
authentication, integrity and confidentiality are often needed for authentication, integrity and confidentiality are often needed for
those streams. The Secure Real-time Transport Protocol (SRTP) [srtp] those streams. The Secure Real-time Transport Protocol (SRTP) [srtp]
provides security services for RTP media and is signaled by use of provides security services for RTP media and is signaled by use of
secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP
media (m=) line. However, there are no means within SDP itself to media (m=) line. However, there are no means within SDP itself to
configure SRTP beyond using default values. This document specifies configure SRTP beyond using default values. This document specifies
skipping to change at page 5, line 20 skipping to change at page 4, line 30
suitable for restricted cases only where IPsec, TLS, or some other suitable for restricted cases only where IPsec, TLS, or some other
encapsulating data-security protocol (e.g., SIP S/MIME) protects the encapsulating data-security protocol (e.g., SIP S/MIME) protects the
SDP message. This document adds security descriptions to those SDP message. This document adds security descriptions to those
encrypted and/or authenticated SDP messages through the new SDP encrypted and/or authenticated SDP messages through the new SDP
"crypto" attribute, which provides the cryptographic parameters of a "crypto" attribute, which provides the cryptographic parameters of a
media stream. media stream.
The "crypto" attribute can be adapted to any media transport, but its The "crypto" attribute can be adapted to any media transport, but its
precise definition is unique to a particular transport. precise definition is unique to a particular transport.
Below, we first provide notational conventions in Section 2 followed
by an applicability statement for the crypto attribute in Section 3.
In Section 4, we introduce the general SDP crypto attribute, and in In Section 4, we introduce the general SDP crypto attribute, and in
Section 5 we define how it is used with and without the offer/answer Section 5 we define how it is used with and without the offer/answer
model. In Section 6, we define the crypto attribute details needed model. In Section 6, we define the crypto attribute details needed
for SRTP, and in Section 7 we define SRTP-specific use of the for SRTP, and in Section 7 we define SRTP-specific use of the
attribute with and without the offer/answer model. Section 8 recites attribute with and without the offer/answer model. Section 8 recites
security considerations, and Section 9 gives an Augmented-BNF grammar security considerations, and Section 9 gives an Augmented-BNF grammar
for the general crypto attribute as well as the SRTP-specific use of for the general crypto attribute as well as the SRTP-specific use of
the crypto attribute. IANA considerations are provided in Section the crypto attribute. IANA considerations are provided in Section
10. 10.
2 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary".
n^r is exponentiation where n is multiplied by itself r times; n and
r are integers. 0..k is an integer range of all integers from 0
through k inclusive.
The terms 'transport' and 'media transport' are used to mean
'transport protocol' as defined in RFC2327, page 20.
Explanatory notes are provided in several places throughout the
document; these notes are indented two spaces from the surrounding
text.
3 Applicability
RFC YYYY {Note to RFC Editor: replace "YYYY" with RFC number for
[keymgt]} provides similar cryptographic key distribution
capabilities, and is intended for use when the signaling is to be
confidential and/or integrity-protected separately from the keying
material.
In contrast, this specification carries the keying material within
the SDP message, and it is intended for use when the keying material
is protected along with the signaling. Implementations MUST employ
security mechanisms that provide confidentiality and integrity for
the keying material. When this specification is used in the context
of SIP [RFC3261], the application SHOULD employ either the SIPS URI
or S/MIME to provide protection for the SDP message and the keying
material that it contains. The use of transport layer or IP layer
security is NOT RECOMMENDED since the protection of the SDP message
and the keying material that it contains cannot be ensured through
all intermediate entities such as SIP proxies.
4 SDP "Crypto" Attribute and Parameters 4 SDP "Crypto" Attribute and Parameters
A new media-level SDP attribute called "crypto" describes the A new media-level SDP attribute called "crypto" describes the
cryptographic suite, key parameters, and session parameters for the cryptographic suite, key parameters, and session parameters for the
preceding unicast media line. The "crypto" attribute MUST only preceding unicast media line. The "crypto" attribute MUST only
appear at the SDP media level (not at the session level). The appear at the SDP media level (not at the session level). The
"crypto" attribute follows the format (see Section 9.1 for the formal "crypto" attribute follows the format (see Section 9.1 for the formal
ABNF grammar): ABNF grammar):
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>] a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/