< draft-ietf-mmusic-sdescriptions-11.txt   draft-ietf-mmusic-sdescriptions-12.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: March 2006 Cisco Systems
June, 2005 September, 2005
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-11.txt> <draft-ietf-mmusic-sdescriptions-12.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 ?
7.1.3 Processing of the Initial Answer - Unicast Streams.......23 7.1.3 Processing of the Initial Answer - Unicast Streams.......23
7.1.4 Modifying the Session....................................23 7.1.4 Modifying the Session....................................23
7.1.5 Offer/Answer Example.....................................24 7.1.5 Offer/Answer Example.....................................24
7.2 SRTP-Specific Use Outside Offer/Answer........................25 7.2 SRTP-Specific Use Outside Offer/Answer........................25
7.3 Support for SIP Forking.......................................26 7.3 Support for SIP Forking.......................................26
7.4 SRTP-Specific Backwards Compatibility Considerations..........26 7.4 SRTP-Specific Backwards Compatibility Considerations..........26
7.5 Operation with KEYMGT= and k= lines...........................27 7.5 Operation with KEYMGT= and k= lines...........................27
8 Security Considerations..........................................27 8 Security Considerations..........................................27
8.1 Authentication of packets.....................................28 8.1 Authentication of packets.....................................28
8.2 Keystream Reuse...............................................28 8.2 Keystream Reuse...............................................28
8.3 Signaling Authentication and Signaling Encryption.............28 8.3 Signaling Authentication and Signaling Encryption.............29
9 Grammar..........................................................29 9 Grammar..........................................................29
9.1 Generic "Crypto" Attribute Grammar............................29 9.1 Generic "Crypto" Attribute Grammar............................29
9.2 SRTP "Crypto" Attribute Grammar...............................30 9.2 SRTP "Crypto" Attribute Grammar...............................30
10 IANA Considerations.............................................31 10 IANA Considerations.............................................31
10.1 Registration of the "crypto" attribute......................31 10.1 Registration of the "crypto" attribute......................31
10.2 New IANA Registries and Registration Procedures.............31 10.2 New IANA Registries and Registration Procedures.............31
10.2.1 Key Method Registry and Registration.....................31 10.2.1 Key Method Registry and Registration.....................32
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..............................................34
13 Normative References............................................34 13 Normative References............................................34
14 Informative References..........................................34 14 Informative References..........................................35
15 Full Copyright Statement........................................36 15 Full Copyright Statement........................................36
1 Introduction 1 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
skipping to change at page 5, line 25 skipping to change at page 5, line 25
material. material.
In contrast, this specification carries the keying material within In contrast, this specification carries the keying material within
the SDP message, and it is intended for use when the keying material the SDP message, and it is intended for use when the keying material
is protected along with the signaling. Implementations MUST employ is protected along with the signaling. Implementations MUST employ
security mechanisms that provide confidentiality and integrity for security mechanisms that provide confidentiality and integrity for
the keying material. When this specification is used in the context the keying material. When this specification is used in the context
of SIP [RFC3261], the application SHOULD employ either the SIPS URI of SIP [RFC3261], the application SHOULD employ either the SIPS URI
or S/MIME to provide protection for the SDP message and the keying 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 material that it contains. The use of transport layer or IP layer
security is NOT RECOMMENDED since the protection of the SDP message security in lieu of the SIPS URI or S/MIME protection is NOT
and the keying material that it contains cannot be ensured through RECOMMENDED since the protection of the SDP message and the keying
all intermediate entities such as SIP proxies. 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):
skipping to change at page 27, line 36 skipping to change at page 27, line 36
descriptions, are conveyed in an encapsulating application protocol descriptions, are conveyed in an encapsulating application protocol
(e.g., SIP, MGCP, etc.). It is the responsibility of the (e.g., SIP, MGCP, etc.). It is the responsibility of the
encapsulating protocol to ensure the protection of the SDP security encapsulating protocol to ensure the protection of the SDP security
descriptions. Therefore, IT IS REQUIRED that the application invoke descriptions. Therefore, IT IS REQUIRED that the application invoke
its own security mechanisms (e.g., secure multiparts such as S/MIME its own security mechanisms (e.g., secure multiparts such as S/MIME
[smime]) or alternatively utilize a lower-layer security service [smime]) or alternatively utilize a lower-layer security service
(e.g., TLS, or IPsec). IT IS REQUIRED that this security service (e.g., TLS, or IPsec). IT IS REQUIRED that this security service
provide strong message authentication and packet-payload encryption provide strong message authentication and packet-payload encryption
as well as effective replay protection. as well as effective replay protection.
"Replay protection" is needed against an attacker that has enough
access to the communications channel to intercept messages and
deliver copies to the destination. A successful replay attack will
cause the recipient to perform duplicate processing on a message;
the attack is worse when the duped recipient sends a duplicate reply
to the initiator. Replay protections are not found in S/MIME or in
the other secure-multiparts standard, PGP/MIME. S/MIME and
PGP/MIME, therefore need to be augmented with some replay-protection
mechanism that is appropriate to the encapsulating application
protocol (e.g. SIP, MGCP, etc.). Three common ways to provide
replay protection are to place a sequence number in the message, use
a timestamp, or for the receiver to keep a hash of the message to
compare with incoming messages. There typically needs to be a
replay "window" and some policy for keeping state information from
previous messages in a "replay table" or list.
The discussion which follows uses "message authentication" and The discussion which follows uses "message authentication" and
"message confidentiality" in a consistent manner with SRTP "message confidentiality" in a consistent manner with SRTP
[RFC3711]. "Message confidentiality" means that only the holder of [RFC3711]. "Message confidentiality" means that only the holder of
the secret decryption key can access the plain-text content of the the secret decryption key can access the plain-text content of the
message. The decryption key is the same key as the encryption key message. The decryption key is the same key as the encryption key
using SRTP counter mode and f8 encryption transforms, which are using SRTP counter mode and f8 encryption transforms, which are
vulnerable to message tampering and need SRTP message authentication vulnerable to message tampering and need SRTP message authentication
to detect such tampering. "Message authentication" and "message to detect such tampering. "Message authentication" and "message
integrity validation" generally mean the same thing in IETF security integrity validation" generally mean the same thing in IETF security
standards: An SRTP message is authenticated following a successful standards: An SRTP message is authenticated following a successful
 End of changes. 8 change blocks. 
10 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/