draft-ietf-mmusic-sdescriptions-08.txt   draft-ietf-mmusic-sdescriptions-09.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: June 2005 Cisco Systems EXPIRES: August 2005 Cisco Systems
December, 2004 February, 2005
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-08.txt> <draft-ietf-mmusic-sdescriptions-09.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.....................................................6 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......................................11 4.1.4 Modifying the Session.....................................10
4.2 Use Outside Offer/Answer........................................11 4.2 Use Outside Offer/Answer.......................................10
4.3 General Backwards Compatibility Considerations..................11 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions........................................11 5. SRTP Security Descriptions.......................................11
5.1 SRTP Key Parameter..............................................13 5.1 SRTP Key Parameter.............................................12
5.2 Crypto-suites...................................................15 5.2 Crypto-suites..................................................14
5.2.1 AES_CM_128_HMAC_SHA1_80....................................16 5.2.1 AES_CM_128_HMAC_SHA1_80...................................15
5.2.2 AES_CM_128_HMAC_SHA1_32....................................16 5.2.2 AES_CM_128_HMAC_SHA1_32...................................15
5.2.3 F8_128_HMAC_SHA1_80........................................17 5.2.3 F8_128_HMAC_SHA1_80.......................................16
5.2.4 Adding new Crypto-suite Definitions........................17 5.2.4 Adding new Crypto-suite Definitions.......................16
5.3 Session Parameters..............................................17 5.3 Session Parameters.............................................16
5.3.1 KDR=n......................................................17 5.3.1 KDR=n.....................................................16
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................18 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP....................16
5.3.3 UNAUTHENTICATED_SRTP.......................................18 5.3.3 UNAUTHENTICATED_SRTP......................................17
5.3.4 FEC_ORDER=order............................................18 5.3.4 FEC_ORDER=order...........................................17
5.3.5 FEC_KEY=key-params.........................................18 5.3.5 FEC_KEY=key-params........................................17
5.3.6 Window Size Hint (WSH).....................................19 5.3.6 Window Size Hint (WSH)....................................18
5.3.7 Defining New SRTP Session Parameters.......................19 5.3.7 Defining New SRTP Session Parameters......................18
5.4 SRTP Crypto Context Initialization..............................19 5.4 SRTP Crypto Context Initialization.............................18
5.4.1 Late Binding of one or more SSRCs to a crypto context......21 5.4.1 Late Binding of one or more SSRCs to a crypto context.....19
5.4.2 Sharing cryptographic contexts among Sessions or SSRCs.....22 5.4.2 Sharing cryptographic contexts among Sessions or SSRCs....20
5.5 Removal of Crypto Contexts......................................22 5.5 Removal of Crypto Contexts.....................................21
6. SRTP-Specific Use of the crypto Attribute.........................23 6. SRTP-Specific Use of the crypto Attribute........................21
6.1 Use with Offer/Answer...........................................23 6.1 Use with Offer/Answer..........................................21
6.1.1 Generating the Initial Offer - Unicast Streams.............23 6.1.1 Generating the Initial Offer - Unicast Streams............22
6.1.2 Generating the Initial Answer - Unicast Streams............23 6.1.2 Generating the Initial Answer - Unicast Streams...........22
6.1.3 Processing of the Initial Answer - Unicast Streams.........24 6.1.3 Processing of the Initial Answer - Unicast Streams........23
6.1.4 Modifying the Session......................................25 6.1.4 Modifying the Session.....................................23
6.1.5 Offer/Answer Example.......................................26 6.1.5 Offer/Answer Example......................................24
6.2 SRTP-Specific Use Outside Offer/Answer..........................27 6.2 SRTP-Specific Use Outside Offer/Answer.........................25
6.3 Support for SIP Forking.........................................27 6.3 Support for SIP Forking........................................26
6.4 SRTP-Specific Backwards Compatibility Considerations............28 6.4 SRTP-Specific Backwards Compatibility Considerations...........26
6.5 Operation with KEYMGT= and k= lines.............................28 6.5 Operation with KEYMGT= and k= lines............................27
7. Security Considerations..........................................27
7. Security Considerations...........................................28 7.1 Authentication of packets......................................27
7.1 Authentication of packets.......................................29 7.2 Keystream Reuse................................................28
7.2 Keystream Reuse.................................................29 7.3 Signaling Authentication and Signaling Encryption..............28
7.3 Signaling Authentication and Signaling Encryption...............30 8. Grammar..........................................................29
8. Grammar...........................................................31 8.1 Generic "Crypto" Attribute Grammar.............................29
8.1 Generic "Crypto" Attribute Grammar..............................31 8.2 SRTP "Crypto" Attribute Grammar................................29
8.2 SRTP "Crypto" Attribute Grammar.................................31 9. IANA Considerations..............................................30
9. IANA Considerations...............................................32 9.1 Registration of the "crypto" attribute.........................30
9.1 Registration of the "crypto" attribute..........................32 9.2 New IANA Registries and Registration Procedures................31
9.2 New IANA Registries and Registration Procedures.................32 9.2.1 Key Method Registry and Registration......................31
9.2.1 Key Method Registry and Registration.......................33 9.2.2 Media Stream Transport Registry and Registration..........31
9.2.2 Media Stream Transport Registry and Registration...........33 9.3 Initial Registrations..........................................32
9.3 Initial Registrations...........................................34 9.3.1 Key Method................................................32
9.3.1 Key Method.................................................34 9.3.2 SRTP Media Stream Transport...............................32
9.3.2 SRTP Media Stream Transport................................34 10. Acknowledgements................................................33
10. Acknowledgements.................................................35 11. Authors' Addresses..............................................33
11. Authors' Addresses...............................................35 12. Normative References............................................34
12. Normative References.............................................36 13. Informative References..........................................34
13. Informative References...........................................36 14. Full Copyright Statement........................................36
14. Full Copyright Statement.........................................38
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 14, line 34 skipping to change at page 14, line 4
convenient when the SRTP cryptographic key lifetime is the default convenient when the SRTP cryptographic key lifetime is the default
value. As a shortcut to avoid long decimal values, the syntax of the value. As a shortcut to avoid long decimal values, the syntax of the
lifetime allows using the literal "2^", which indicates "two to the lifetime allows using the literal "2^", which indicates "two to the
power of". The example above, shows a case where the lifetime is power of". The example above, shows a case where the lifetime is
specified as 2^20. The following example, which is for the specified as 2^20. The following example, which is for the
AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime
field, which means that SRTP's and SRTCP's default values will be field, which means that SRTP's and SRTCP's default values will be
used (see [srtp]): used (see [srtp]):
inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4
The example shows a 30-character key and concatenated salt that is The example shows a 30-character key and concatenated salt that is
base64 encoded: The 30-character key/salt concatenation is expanded base64 encoded: The 30-character key/salt concatenation is expanded
to 40 characters by the three-in-four encoding of base64. to 40 characters by the three-in-four encoding of base64.
The third field, which is also OPTIONAL, is the Master Key Identifier The third field, which is also OPTIONAL, is the Master Key Identifier
(MKI) and its byte length. (MKI) and its byte length.
"MKI" is the master key identifier associated with the SRTP master "MKI" is the master key identifier associated with the SRTP master
key. If the MKI is given, then the length of the MKI MUST also be key. The MKI is expressed as positive integer in big-endian order
given and separated from the MKI by a colon (":"). The MKI length is with unused, high-order bytes set to zero. If the MKI is given, then
the size of the MKI field in the SRTP packet, specified in bytes. If the length of the MKI MUST also be given and separated from the MKI
the MKI length is not given or its value exceeds 128 (bytes), then by a colon (":"). The MKI length is the size of the MKI field in the
the entire crypto attribute MUST be considered invalid. The SRTP packet, specified in bytes. If the MKI length is not given or
substring "1:4" in the first example assigns to the key a master key its value exceeds 128 (bytes), then the entire crypto attribute MUST
identifier of 1 that is 4 bytes long, and the second example assigns be considered invalid. The substring "1:4" in the first example
a 4-byte master key identifier of 1066 to the key. One or more assigns to the key a master key identifier of 1 that is 4 bytes long,
master keys with their associated MKI can be initially defined, and and the second example assigns a 4-byte master key identifier of 1066
then later updated, or deleted and new ones defined. to the key. One or more master keys with their associated MKI can be
initially defined, and then later updated, or deleted and new ones
defined.
SRTP offers a second feature for specifying the lifetime of a master SRTP offers a second feature for specifying the lifetime of a master
key in terms of two values, called "From" and "To," which are defined key in terms of two values, called "From" and "To," which are defined
on the SRTP sequence number space [srtp]. This SRTP Security on the SRTP sequence number space [srtp]. This SRTP Security
Descriptions specification, however, does not support the Descriptions specification, however, does not support the
<"From","To"> feature since the lifetime of an AES master key is 2^48 <"From","To"> feature since the lifetime of an AES master key is 2^48
SRTP packets, which means that there is no cryptographic reason to SRTP packets, which means that there is no cryptographic reason to
replace a master key for practical point-to-point applications. For replace a master key for practical point-to-point applications. For
this reason, there is no need to support two means for signaling key this reason, there is no need to support two means for signaling key
update. The MKI is chosen over <"From","To"> by this specification update. The MKI is chosen over <"From","To"> by this specification
 End of changes. 

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