draft-ietf-mmusic-sdescriptions-06.txt   draft-ietf-mmusic-sdescriptions-07.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: January 2005 Cisco Systems EXPIRES: January 2005 Cisco Systems
July, 2004 July, 2004
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-06.txt> <draft-ietf-mmusic-sdescriptions-07.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, the authors certify that any By submitting this Internet-Draft, the authors certify that any
applicable patent or other IPR claims of which we are aware have been applicable patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, the authors accept the provisions By submitting this Internet-Draft, the authors accept the provisions
of Section 3 of RFC 3667 (BCP 78). of Section 3 of RFC 3667 (BCP 78).
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. Notational Conventions...........................................3 1. Notational Conventions............................................3
2. Introduction.....................................................3 2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters............................5 3. SDP "Crypto" Attribute and Parameters.............................5
3.1 Tag............................................................5 3.1 Tag.............................................................5
3.2 Crypto-suite...................................................5 3.2 Crypto-suite....................................................5
3.3 Key Parameters.................................................6 3.3 Key Parameters..................................................6
3.4 Session Parameters.............................................7 3.4 Session Parameters..............................................7
3.5 Example........................................................7 3.5 Example.........................................................7
4. General Use of the crypto Attribute..............................8 4. General Use of the crypto Attribute...............................8
4.1 Use With Offer/Answer..........................................8 4.1 Use With Offer/Answer...........................................8
4.1.1 Generating the Initial Offer - Unicast Streams............8 4.1.1 Generating the Initial Offer - Unicast Streams.............8
4.1.2 Generating the Initial Answer - Unicast Streams...........9 4.1.2 Generating the Initial Answer - Unicast Streams............9
4.1.3 Processing of the Initial Answer - Unicast Streams.......10 4.1.3 Processing of the Initial Answer - Unicast Streams........10
4.1.4 Modifying the Session....................................10 4.1.4 Modifying the Session.....................................10
4.2 Use Outside Offer/Answer......................................10 4.2 Use Outside Offer/Answer.......................................10
4.3 General Backwards Compatibility Considerations................10 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions......................................11 5. SRTP Security Descriptions.......................................11
5.1 SRTP Key Parameter............................................12 5.1 SRTP Key Parameter.............................................12
5.2 Crypto-suites.................................................14 5.2 Crypto-suites..................................................14
5.2.1 AES_CM_128_HMAC_SHA1_80..................................15 5.2.1 AES_CM_128_HMAC_SHA1_80...................................15
5.2.2 AES_CM_128_HMAC_SHA1_32..................................15 5.2.2 AES_CM_128_HMAC_SHA1_32...................................15
5.2.3 F8_128_HMAC_SHA1_80......................................16 5.2.3 F8_128_HMAC_SHA1_80.......................................16
5.2.4 Adding new Crypto-suite Definitions......................16 5.2.4 Adding new Crypto-suite Definitions.......................16
5.3 Session Parameters............................................16 5.3 Session Parameters.............................................16
5.3.1 KDR=n....................................................16 5.3.1 KDR=n.....................................................16
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................16 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP....................16
5.3.3 UNAUTHENTICATED_SRTP.....................................17 5.3.3 UNAUTHENTICATED_SRTP......................................17
5.3.4 FEC_ORDER=order..........................................17 5.3.4 FEC_ORDER=order...........................................17
5.3.5 FEC_KEY=key-params.......................................17 5.3.5 FEC_KEY=key-params........................................17
5.3.6 Window Size Hint (WSH)...................................18 5.3.6 Window Size Hint (WSH)....................................18
5.3.7 Defining New SRTP Session Parameters.....................18 5.3.7 Defining New SRTP Session Parameters......................18
5.4 SRTP Crypto Context Initialization............................18 5.4 SRTP Crypto Context Initialization.............................18
5.4.1 Late Binding of one or more SSRCs to a crypto context....19 5.4.1 Late Binding of one or more SSRCs to a crypto context.....19
5.4.2 Sharing cryptographic contexts among SSRCs...............20 5.4.2 Sharing cryptographic contexts among Sessions or SSRCs....20
5.5 Removal of Crypto Contexts....................................21 5.5 Removal of Crypto Contexts.....................................21
6. SRTP-Specific Use of the crypto Attribute.......................21 6. SRTP-Specific Use of the crypto Attribute........................21
6.1 Use with Offer/Answer.........................................21 6.1 Use with Offer/Answer..........................................21
6.1.1 Generating the Initial Offer - Unicast Streams...........21 6.1.1 Generating the Initial Offer - Unicast Streams............22
6.1.2 Generating the Initial Answer - Unicast Streams..........22 6.1.2 Generating the Initial Answer - Unicast Streams...........22
6.1.3 Processing of the Initial Answer - Unicast Streams.......23 6.1.3 Processing of the Initial Answer - Unicast Streams........23
6.1.4 Modifying the Session....................................23 6.1.4 Modifying the Session.....................................23
6.1.5 Offer/Answer Example.....................................24 6.1.5 Offer/Answer Example......................................24
6.2 SRTP-Specific Use Outside Offer/Answer........................25 6.2 SRTP-Specific Use Outside Offer/Answer.........................25
6.3 Support for SIP Forking.......................................26 6.3 Support for SIP Forking........................................26
6.4 SRTP-Specific Backwards Compatibility Considerations..........26 6.4 SRTP-Specific Backwards Compatibility Considerations...........26
6.5 Operation with KEYMGT= and k= lines...........................27 6.5 Operation with KEYMGT= and k= lines............................27
7. Security Considerations.........................................27 7. Security Considerations..........................................27
7.1 Authentication of packets.....................................27 7.1 Authentication of packets......................................27
7.2 Keystream Reuse...............................................27 7.2 Keystream Reuse................................................27
7.3 Signaling Authentication and Signaling Encryption.............28 7.3 Signaling Authentication and Signaling Encryption..............28
8. Grammar.........................................................29 8. Grammar..........................................................29
8.1 Generic "Crypto" Attribute Grammar............................29 8.1 Generic "Crypto" Attribute Grammar.............................29
8.2 SRTP "Crypto" Attribute Grammar...............................29 8.2 SRTP "Crypto" Attribute Grammar................................29
9. IANA Considerations.............................................30 9. IANA Considerations..............................................30
9.1 Registration of the "crypto" attribute........................30 9.1 Registration of the "crypto" attribute.........................30
9.2 New IANA Registries and Registration Procedures...............30 9.2 New IANA Registries and Registration Procedures................30
9.2.1 Key Method Registry and Registration.....................31 9.2.1 Key Method Registry and Registration......................31
9.2.2 Media Stream Transport Registry and Registration.........31 9.2.2 Media Stream Transport Registry and Registration..........31
9.3 Initial Registrations.........................................31 9.3 Initial Registrations..........................................31
9.3.1 Key Method...............................................31 9.3.1 Key Method................................................31
9.3.2 SRTP Media Stream Transport..............................32 9.3.2 SRTP Media Stream Transport...............................32
10. Acknowledgements...............................................33 10. Acknowledgements................................................33
11. Authors' Addresses.............................................33 11. Authors' Addresses..............................................33
12. Normative References...........................................34 12. Normative References............................................34
13. Informative References.........................................34 13. Informative References..........................................34
14. Full Copyright Statement.......................................36 14. Full Copyright Statement........................................36
1. Notational Conventions 1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [RFC2119]. The terminology in this be interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary". document conforms to [RFC2828], "Internet Security Glossary".
n^r is exponentiation where n is multiplied by itself r times; n and 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 r are integers. 0..k is an integer range of all integers from 0
skipping to change at page 20, line 48 skipping to change at page 20, line 48
security attacks and consequently it is NOT RECOMMENDED (of course, security attacks and consequently it is NOT RECOMMENDED (of course,
this can be said for unauthenticated SRTP in general). this can be said for unauthenticated SRTP in general).
Note that use of late binding without authentication will result in Note that use of late binding without authentication will result in
local state being created as a result of receiving a packet from local state being created as a result of receiving a packet from
any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT
RECOMMENDED because it invites easy denial-of-service attack. In RECOMMENDED because it invites easy denial-of-service attack. In
contrast, late binding with authentication does not suffer from contrast, late binding with authentication does not suffer from
this weakness. this weakness.
5.4.2 Sharing cryptographic contexts among SSRCs 5.4.2 Sharing cryptographic contexts among Sessions or SSRCs
With the constraints and procedures described above, it is not With the constraints and procedures described above, it is not
necessary to explicitly signal the SSRC, ROC and SEQ for a unicast necessary to explicitly signal the SSRC, ROC and SEQ for a unicast
SRTP session. So there are no a=crypto parameters for signaling SSRC, RTP session. So there are no a=crypto parameters for signaling SSRC,
ROC or SEQ. Thus, multiple SSRCs will share a=crypto parameters when ROC or SEQ. Thus, multiple SSRCs from the same entity will share
late binding is used and when an SDP media line references a payload a=crypto parameters when late binding is used. Multiple SSRCs from
type that generates multiple SSRCs. An application that uses the same entity arises due to either multiple sources (microphones,
a=crypto in this way serially shares a master key among sessions and cameras, etc.), or RTP payloads requiring SSRC multiplexing within
MUST replace the master key when the aggregate number of packets that same session. SDP also allows multiple RTP sessions to be
among all sessions approaches 2^31 packets. SSRCs that share a defined in the same media description ("m="), these RTP sessions will
also share the a=crypto parameters. An application that uses
a=crypto in this way serially shares a master key among RTP sessions
or SSRCs and MUST replace the master key when the aggregate number of
packets among all SSRCs approaches 2^31 packets. SSRCs that share a
master key MUST be unique from one another. master key MUST be unique from one another.
5.5 Removal of Crypto Contexts 5.5 Removal of Crypto Contexts
The mechanism defined above addresses the issue of creating crypto The mechanism defined above addresses the issue of creating crypto
contexts, however in practice, session participants may want to contexts, however in practice, session participants may want to
remove crypto contexts prior to session termination. Since a crypto remove crypto contexts prior to session termination. Since a crypto
context contains information that can not automatically be recovered context contains information that can not automatically be recovered
(e.g., ROC), it is important that the sender and receiver agree on (e.g., ROC), it is important that the sender and receiver agree on
when a crypto context can be removed, and perhaps more importantly when a crypto context can be removed, and perhaps more importantly
 End of changes. 

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