draft-ietf-mmusic-sdescriptions-07.txt   draft-ietf-mmusic-sdescriptions-08.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: June 2005 Cisco Systems
July, 2004 December, 2004
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-07.txt> <draft-ietf-mmusic-sdescriptions-08.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.....................................................6
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......................................11
4.2 Use Outside Offer/Answer.......................................10 4.2 Use Outside Offer/Answer........................................11
4.3 General Backwards Compatibility Considerations.................10 4.3 General Backwards Compatibility Considerations..................11
5. SRTP Security Descriptions.......................................11 5. SRTP Security Descriptions........................................11
5.1 SRTP Key Parameter.............................................12 5.1 SRTP Key Parameter..............................................13
5.2 Crypto-suites..................................................14 5.2 Crypto-suites...................................................15
5.2.1 AES_CM_128_HMAC_SHA1_80...................................15 5.2.1 AES_CM_128_HMAC_SHA1_80....................................16
5.2.2 AES_CM_128_HMAC_SHA1_32...................................15 5.2.2 AES_CM_128_HMAC_SHA1_32....................................16
5.2.3 F8_128_HMAC_SHA1_80.......................................16 5.2.3 F8_128_HMAC_SHA1_80........................................17
5.2.4 Adding new Crypto-suite Definitions.......................16 5.2.4 Adding new Crypto-suite Definitions........................17
5.3 Session Parameters.............................................16 5.3 Session Parameters..............................................17
5.3.1 KDR=n.....................................................16 5.3.1 KDR=n......................................................17
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP....................16 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................18
5.3.3 UNAUTHENTICATED_SRTP......................................17 5.3.3 UNAUTHENTICATED_SRTP.......................................18
5.3.4 FEC_ORDER=order...........................................17 5.3.4 FEC_ORDER=order............................................18
5.3.5 FEC_KEY=key-params........................................17 5.3.5 FEC_KEY=key-params.........................................18
5.3.6 Window Size Hint (WSH)....................................18 5.3.6 Window Size Hint (WSH).....................................19
5.3.7 Defining New SRTP Session Parameters......................18 5.3.7 Defining New SRTP Session Parameters.......................19
5.4 SRTP Crypto Context Initialization.............................18 5.4 SRTP Crypto Context Initialization..............................19
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......21
5.4.2 Sharing cryptographic contexts among Sessions or SSRCs....20 5.4.2 Sharing cryptographic contexts among Sessions or SSRCs.....22
5.5 Removal of Crypto Contexts.....................................21 5.5 Removal of Crypto Contexts......................................22
6. SRTP-Specific Use of the crypto Attribute........................21 6. SRTP-Specific Use of the crypto Attribute.........................23
6.1 Use with Offer/Answer..........................................21 6.1 Use with Offer/Answer...........................................23
6.1.1 Generating the Initial Offer - Unicast Streams............22 6.1.1 Generating the Initial Offer - Unicast Streams.............23
6.1.2 Generating the Initial Answer - Unicast Streams...........22 6.1.2 Generating the Initial Answer - Unicast Streams............23
6.1.3 Processing of the Initial Answer - Unicast Streams........23 6.1.3 Processing of the Initial Answer - Unicast Streams.........24
6.1.4 Modifying the Session.....................................23 6.1.4 Modifying the Session......................................25
6.1.5 Offer/Answer Example......................................24 6.1.5 Offer/Answer Example.......................................26
6.2 SRTP-Specific Use Outside Offer/Answer.........................25 6.2 SRTP-Specific Use Outside Offer/Answer..........................27
6.3 Support for SIP Forking........................................26 6.3 Support for SIP Forking.........................................27
6.4 SRTP-Specific Backwards Compatibility Considerations...........26 6.4 SRTP-Specific Backwards Compatibility Considerations............28
6.5 Operation with KEYMGT= and k= lines............................27 6.5 Operation with KEYMGT= and k= lines.............................28
7. Security Considerations..........................................27
7.1 Authentication of packets......................................27 7. Security Considerations...........................................28
7.2 Keystream Reuse................................................27 7.1 Authentication of packets.......................................29
7.3 Signaling Authentication and Signaling Encryption..............28 7.2 Keystream Reuse.................................................29
8. Grammar..........................................................29 7.3 Signaling Authentication and Signaling Encryption...............30
8.1 Generic "Crypto" Attribute Grammar.............................29 8. Grammar...........................................................31
8.2 SRTP "Crypto" Attribute Grammar................................29 8.1 Generic "Crypto" Attribute Grammar..............................31
9. IANA Considerations..............................................30 8.2 SRTP "Crypto" Attribute Grammar.................................31
9.1 Registration of the "crypto" attribute.........................30 9. IANA Considerations...............................................32
9.2 New IANA Registries and Registration Procedures................30 9.1 Registration of the "crypto" attribute..........................32
9.2.1 Key Method Registry and Registration......................31 9.2 New IANA Registries and Registration Procedures.................32
9.2.2 Media Stream Transport Registry and Registration..........31 9.2.1 Key Method Registry and Registration.......................33
9.3 Initial Registrations..........................................31 9.2.2 Media Stream Transport Registry and Registration...........33
9.3.1 Key Method................................................31 9.3 Initial Registrations...........................................34
9.3.2 SRTP Media Stream Transport...............................32 9.3.1 Key Method.................................................34
10. Acknowledgements................................................33 9.3.2 SRTP Media Stream Transport................................34
11. Authors' Addresses..............................................33 10. Acknowledgements.................................................35
12. Normative References............................................34 11. Authors' Addresses...............................................35
13. Informative References..........................................34 12. Normative References.............................................36
14. Full Copyright Statement........................................36 13. Informative References...........................................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 4, line 42 skipping to change at page 4, line 48
definition of the key to render it useless, or change the parameters definition of the key to render it useless, or change the parameters
of the security session to gain unauthorized access to session- of the security session to gain unauthorized access to session-
related information. related information.
SDP, however, was not designed to provide AKE services, and the media SDP, however, was not designed to provide AKE services, and the media
security descriptions defined in this document do not add AKE security descriptions defined in this document do not add AKE
services to SDP. This specification is no replacement for a key services to SDP. This specification is no replacement for a key
management protocol or for the conveyance of key management messages management protocol or for the conveyance of key management messages
in SDP [keymgt]. The SDP security descriptions defined here are in SDP [keymgt]. The SDP security descriptions defined here are
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 secure multiparts) encapsulating data-security protocol (e.g., SIP S/MIME) protects the
protects the SDP message. This document adds security descriptions SDP message. This document adds security descriptions to those
to those encrypted and/or authenticated SDP messages through the new encrypted and/or authenticated SDP messages through the new SDP
SDP "crypto" attribute, which provides the cryptographic parameters "crypto" attribute, which provides the cryptographic parameters of a
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.
In Section 3, we introduce the general SDP crypto attribute, and in In Section 3, we introduce the general SDP crypto attribute, and in
Section 4 we define how it is used with and without the offer/answer Section 4 we define how it is used with and without the offer/answer
model. In Section 5, we define the crypto attribute details needed model. In Section 5, we define the crypto attribute details needed
for SRTP, and in Section 6 we define SRTP-specific use of the for SRTP, and in Section 6 we define SRTP-specific use of the
attribute with and without the offer/answer model. Section 7 recites attribute with and without the offer/answer model. Section 7 recites
security considerations, and Section 8 gives an Augmented-BNF grammar security considerations, and Section 8 gives an Augmented-BNF grammar
skipping to change at page 12, line 22 skipping to change at page 12, line 48
- UNENCRYPTED_SRTCP: SRTCP messages are not encrypted - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted
- UNAUTHENTICATED_SRTP: SRTP messages are not authenticated - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated
- FEC_ORDER: Order of forward error correction (FEC) - FEC_ORDER: Order of forward error correction (FEC)
relative to SRTP services relative to SRTP services
- FEC_KEY: Master Key for FEC when the FEC stream is sent - FEC_KEY: Master Key for FEC when the FEC stream is sent
to a separate address and/or port. to a separate address and/or port.
- WSH: Window Size Hint - WSH: Window Size Hint
- Extensions: Extension parameters can be defined - Extensions: Extension parameters can be defined
Please refer to the SRTP specification for a complete list of Please refer to the SRTP specification for a complete list of
parameters and their descriptions [Section 8.2, srtp]. The key parameters and their descriptions [Section 8.2, srtp]. Regarding the
parameter, the crypto-suite, and the session parameters shown above UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security
are described in detail in the following subsections. descriptions MUST NOT use the SRTCP E-bit to override
UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP
messages (see 5.3.2). The key parameter, the crypto-suite, and the
session parameters shown above are described in detail in the
following subsections.
5.1 SRTP Key Parameter 5.1 SRTP Key Parameter
SRTP security descriptions define use of the "inline" key method as SRTP security descriptions define use of the "inline" key method as
described in the following. Use of any other keying method, e.g., described in the following. Use of any other keying method, e.g.,
URL, for SRTP security descriptions is for further study. URL, for SRTP security descriptions is for further study.
The "inline" type of key contains the keying material (master key The "inline" type of key contains the keying material (master key
and salt) and all policy related to that master key, including how and salt) and all policy related to that master key, including how
long it can be used (lifetime) and whether or not it uses a master long it can be used (lifetime) and whether or not it uses a master
skipping to change at page 12, line 47 skipping to change at page 13, line 29
associated with a master key, and MUST NOT accept incoming packets associated with a master key, and MUST NOT accept incoming packets
that violate the policy (e.g., after the master key lifetime has that violate the policy (e.g., after the master key lifetime has
expired). expired).
The key parameter contains one or more cryptographic master keys, The key parameter contains one or more cryptographic master keys,
each of which MUST be a unique cryptographically random [RFC1750] each of which MUST be a unique cryptographically random [RFC1750]
value with respect to other master keys in the entire SDP message value with respect to other master keys in the entire SDP message
(i.e., including master keys for other streams). Each key follows (i.e., including master keys for other streams). Each key follows
the format (the formal definition is provided in Section 8.2): the format (the formal definition is provided in Section 8.2):
"inline:" <key||salt> "|" [lifetime] "|" [MKI ":" length] "inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
key||salt concatenated master key and salt, base64 encoded key||salt concatenated master key and salt, base64 encoded
(see [RFC3548], Section 3) (see [RFC3548], Section 3)
lifetime master key lifetime (max number of SRTP or SRTCP lifetime master key lifetime (max number of SRTP or SRTCP
packets using this master key) packets using this master key)
MKI:length MKI and length of the MKI field in SRTP packets MKI:length MKI and length of the MKI field in SRTP packets
The following definition provides an example for The following definition provides an example for
AES_CM_128_HMAC_SHA1_80: AES_CM_128_HMAC_SHA1_80:
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the
parameter is the cryptographic master key appended with the master parameter is the cryptographic master key appended with the master
salt; the two are first concatenated and then base64 encoded. The salt; the two are first concatenated and then base64 encoded. The
length of the concatenated key and salt is determined by the crypto- length of the concatenated key and salt is determined by the crypto-
suite for which the key applies. If the length (after being decoded suite for which the key applies. If the length (after being decoded
skipping to change at page 13, line 48 skipping to change at page 14, line 33
signaled by omitting the lifetime value (i.e., "||"). This is signaled by omitting the lifetime value (i.e., "||"). This is
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. If the MKI is given, then the length of the MKI MUST also be
skipping to change at page 17, line 11 skipping to change at page 18, line 17
SRTP and SRTCP packet payloads are encrypted by default. The SRTP and SRTCP packet payloads are encrypted by default. The
UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the
default behavior of the crypto-suites with which they are used: default behavior of the crypto-suites with which they are used:
* UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not
encrypted. encrypted.
* UNENCRYPTED_SRTP signals that the SRTP packet payloads are not * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not
encrypted. encrypted.
In the offer/answer model, these parameters are negotiated. In the offer/answer model, these parameters are negotiated. If
UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit
MUST be clear (0) in all SRTCP messages. If the default is used,
all SRTCP messages are encrypted and the E bit MUST be set (1) on
all SRTCP messages.
5.3.3 UNAUTHENTICATED_SRTP 5.3.3 UNAUTHENTICATED_SRTP
SRTP and SRTCP packet payloads are authenticated by default. The SRTP and SRTCP packet payloads are authenticated by default. The
UNAUTHENTICATED_SRTP session parameter signals that SRTP messages UNAUTHENTICATED_SRTP session parameter signals that SRTP messages
are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT
RECOMMENDED (see Security Considerations). RECOMMENDED (see Security Considerations).
The SRTP specification requires use of message authentication for The SRTP specification requires use of message authentication for
SRTCP, but not for SRTP [srtp]. SRTCP, but not for SRTP [srtp].
skipping to change at page 24, line 45 skipping to change at page 26, line 23
if the relay changes the media endpoint on one side transparently to if the relay changes the media endpoint on one side transparently to
the other side, the relay cannot operate as a simple packet the other side, the relay cannot operate as a simple packet
reflector but will have to actively engage in SRTP packet processing reflector but will have to actively engage in SRTP packet processing
and transformation (i.e., decryption and re-encryption, etc.). and transformation (i.e., decryption and re-encryption, etc.).
Finally note, that if the new offer is rejected, the old crypto Finally note, that if the new offer is rejected, the old crypto
parameters remain in place. parameters remain in place.
6.1.5 Offer/Answer Example 6.1.5 Offer/Answer Example
In this example, the offerer supports two crypto suites (F8 and AES). In this example, the offerer supports two crypto suites (f8 and AES).
The a=crypto line is actually one long line, although it is shown as The a=crypto line is actually one long line, although it is shown as
two lines in this document due to page formatting. two lines in this document due to page formatting. The f8 example
shows two inline parameters; as explained in Section 5.1, there may
be one or more key (i.e. inline) parameters in a crypto attribute.
In this way, multiple keys are offered to support key rotation using
a master key index (MKI).
Offerer sends: Offerer sends:
v=0 v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5 o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson) e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12 c=IN IP4 168.2.17.12
t=2873397496 2873404696 t=2873397496 2873404696
skipping to change at page 25, line 37 skipping to change at page 27, line 15
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson) e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11 c=IN IP4 168.2.17.11
t=2873397526 2873405696 t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0 m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
In this case, the session would use the AES_CM_128_HMAC_SHA1_80 In this case, the session would use the AES_CM_128_HMAC_SHA1_80
crypto suite for the RTP and RTCP traffic. crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80
were selected by the answerer, there would be two inline keys
associated with the SRTP cryptographic context. One key has an MKI
value of 1 and the second has an MKI of 2.
6.2 SRTP-Specific Use Outside Offer/Answer 6.2 SRTP-Specific Use Outside Offer/Answer
Use of SRTP security descriptions outside the offer/answer model is Use of SRTP security descriptions outside the offer/answer model is
not defined. not defined.
Use of SRTP security descriptions outside offer/answer could have Use of SRTP security descriptions outside offer/answer could have
been defined for sendonly media streams, however, there would not been defined for sendonly media streams, however, there would not
be a way to indicate the key to use for SRTCP by the receiver of be a way to indicate the key to use for SRTCP by the receiver of
said media stream. said media stream.
skipping to change at page 27, line 25 skipping to change at page 28, line 51
understand. If the answerer supports both "a=crypto" and "k=", the understand. If the answerer supports both "a=crypto" and "k=", the
answer MUST include either "a=crypto" or "k=" but not both, as answer MUST include either "a=crypto" or "k=" but not both, as
including both is undefined. including both is undefined.
7. Security Considerations 7. Security Considerations
Like all SDP messages, SDP messages containing security Like all SDP messages, SDP messages containing security
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, the application protocol SHOULD either descriptions. Therefore, IT IS REQUIRED that the application invoke
invoke its own security mechanisms (e.g., secure multiparts) or its own security mechanisms (e.g., secure multiparts such as S/MIME
alternatively utilize a lower-layer security service (e.g., TLS, or [smime]) or alternatively utilize a lower-layer security service
IPSec). This security service SHOULD provide strong message (e.g., TLS, or IPSec). IT IS REQUIRED that this security service
authentication and packet-payload encryption as well as effective provide strong message authentication and packet-payload encryption
replay protection. as well as effective replay protection.
The discussion which follows uses "message authentication" and
"message confidentiality" in a consistent manner with SRTP
[RFC3711]. "Message confidentiality" means that only the holder of
the secret decryption key can access the plain-text content of the
message. The decryption key is the same key as the encryption key
using SRTP counter mode and f8 encryption transforms, which are
vulnerable to message tampering and need SRTP message authentication
to detect such tampering. "Message authentication" and "message
integrity validation" generally mean the same thing in IETF security
standards: An SRTP message is authenticated following a successful
HMAC integrity check [RFC3711], which proves that the message
originated from the holder of an SRTP master key and was not altered
en route. Such an "authentic" message, however, can be captured by
an attacker and "replayed" when the attacker re-inserts the packet
into the channel. A replayed packet can have a variety of bad
effects on the session, and SRTP uses the extended sequence number
to detect replayed SRTP packets [RFC3711].
The SRTP specification identifies which services and features are
default values that are normative-to-implement (such as
AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32).
7.1 Authentication of packets 7.1 Authentication of packets
Security descriptions as defined herein signal security services for Security descriptions as defined herein signal security services for
RTP packets. RTP messages are vulnerable to a variety of attacks RTP packets. RTP messages are vulnerable to a variety of attacks
such as replay and forging. To limit these attacks, SRTP message such as replay and forging. To limit these attacks, SRTP message
integrity mechanisms SHOULD be used (SRTP replay protection is integrity mechanisms SHOULD be used (SRTP replay protection is
always enabled). always enabled).
7.2 Keystream Reuse 7.2 Keystream Reuse
skipping to change at page 28, line 23 skipping to change at page 30, line 26
of SRTP, however, when its key establishment is exposed to of SRTP, however, when its key establishment is exposed to
unauthorized parties. In most cases, the SRTP crypto attribute and unauthorized parties. In most cases, the SRTP crypto attribute and
its parameters are vulnerable to denial of service attacks when they its parameters are vulnerable to denial of service attacks when they
are carried in an unauthenticated SDP message. In some cases, the are carried in an unauthenticated SDP message. In some cases, the
integrity or confidentiality of the RTP stream can be compromised. integrity or confidentiality of the RTP stream can be compromised.
For example, if an attacker sets UNENCRYPTED for the SRTP stream in For example, if an attacker sets UNENCRYPTED for the SRTP stream in
an offer, this could result in the answerer not decrypting the an offer, this could result in the answerer not decrypting the
encrypted SRTP messages. In the worst case, the answerer might encrypted SRTP messages. In the worst case, the answerer might
itself send unencrypted SRTP and leave its data exposed to snooping. itself send unencrypted SRTP and leave its data exposed to snooping.
Thus, MIME secure multiparts, IPsec, TLS, or some other data Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or
security service SHOULD be used to provide message authentication some other data security service be used to provide message
for the encapsulating protocol that carries the SDP messages having authentication for the encapsulating protocol that carries the SDP
a crypto attribute (a=crypto). Furthermore, encryption of the messages having a crypto attribute (a=crypto). Furthermore, IT IS
encapsulating payload SHOULD be used because a master key parameter REQUIRED that encryption of the encapsulating payload be used
(inline) appears in the message. Failure to encrypt the SDP message whenever a master key parameter (inline) appears in the message.
containing an inline SRTP master key renders the SRTP authentication Failure to encrypt the SDP message containing an inline SRTP master
or encryption service useless in practically all circumstances. key renders the SRTP authentication or encryption service useless in
Failure to authenticate an SDP message that carries SRTP parameters practically all circumstances. Failure to authenticate an SDP
renders the SRTP authentication or encryption service useless in message that carries SRTP parameters renders the SRTP authentication
most practical applications. or encryption service useless in most practical applications.
When the communication path of the SDP message is routed through When the communication path of the SDP message is routed through
intermediate systems that inspect parts of the SDP message, security intermediate systems that inspect parts of the SDP message, security
protocols such as IPsec or TLS SHOULD NOT be used for encrypting protocols such as IPsec or TLS SHOULD NOT be used for encrypting
and/or authenticating the security description. In the case of and/or authenticating the security description. In the case of
intermediate-system processing of a message containing SDP security intermediate-system processing of a message containing SDP security
descriptions, the "a=crypto" attributes SHOULD be protected end-to- descriptions, the "a=crypto" attributes SHOULD be protected end-to-
end so that the intermediate system can neither modify the security end so that the intermediate system can neither modify the security
description nor access the keying material. Network or transport description nor access the keying material. Network or transport
security protocols that terminate at each intermediate system, security protocols that terminate at each intermediate system,
therefore, SHOULD NOT be used for protecting SDP security therefore, SHOULD NOT be used for protecting SDP security
descriptions. A security protocol SHOULD allow the security descriptions. A security protocol SHOULD allow the security
descriptions to be encrypted and authenticated end-to-end descriptions to be encrypted and authenticated end-to-end
independently of the portions of the SDP message that any independently of the portions of the SDP message that any
intermediate system modifies or inspects: MIME secure multiparts intermediate system modifies or inspects: MIME secure multiparts
are RECOMMENDED for the protection of SDP messages that are are RECOMMENDED for the protection of SDP messages that are
processed by intermediate systems. processed by intermediate systems.
When the SDP parameters cannot be carried in an encrypted and
authenticated SDP message, it is RECOMMENDED that a key management
protocol be used instead of the security descriptions defined here
(a=crypto). The proposed SDP key-mgmt extension [keymgt] allows
authentication and encryption of the key management protocol data
independently of the SDP message that carries it. The security of
the SDP SRTP attribute, however, is as good as the data security
protocol that protects the SDP message. For example, if an IPSec
security association exists between the SDP source and destination
endpoints, then this solution is more secure than use of the key-
mgmt statement in an unauthenticated SDP message, which is
vulnerable to tampering.
8. Grammar 8. Grammar
In this section we first provide the ABNF grammar for the generic In this section we first provide the ABNF grammar for the generic
crypto attribute, and then we provide the ABNF grammar for the SRTP crypto attribute, and then we provide the ABNF grammar for the SRTP
specific use of the crypto attribute. specific use of the crypto attribute.
8.1 Generic "Crypto" Attribute Grammar 8.1 Generic "Crypto" Attribute Grammar
The ABNF grammar for the crypto attribute is defined below: The ABNF grammar for the crypto attribute is defined below:
skipping to change at page 30, line 4 skipping to change at page 31, line 47
crypto-suite = srtp-crypto-suite crypto-suite = srtp-crypto-suite
key-method = srtp-key-method key-method = srtp-key-method
key-info = srtp-key-info key-info = srtp-key-info
session-param = srtp-session-param session-param = srtp-session-param
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" / "AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext srtp-crypto-suite-ext
srtp-key-method = "inline"
srtp-key-info = key-salt "|" [lifetime] "|" [mki]
srtp-key-method= "inline"
srtp-key-info = key-salt ["|" lifetime] ["|" mki]
key-salt = 1*(base64) ; binary key and salt values key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then ; concatenated together, and then
; base64 encoded [section 6.8 of ; base64 encoded [section 6.8 of
; RFC2046] ; RFC2046]
lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^" lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^"
mki = mki-value ":" mki-length mki = mki-value ":" mki-length
mki-value = 1*DIGIT mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128. mki-length = 1*3DIGIT ; range 1..128.
skipping to change at page 33, line 22 skipping to change at page 35, line 29
The reference for these parameters is this document. The reference for these parameters is this document.
10. Acknowledgements 10. Acknowledgements
This document is a product of the IETF MMUSIC working group and has This document is a product of the IETF MMUSIC working group and has
benefited from comments from its participants. This document also benefited from comments from its participants. This document also
benefited from discussions with Elisabetta Cararra, Earl Carter, benefited from discussions with Elisabetta Cararra, Earl Carter,
Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David
McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer,
Mike Thomas, Brian Weis, and Magnus Westerlund. These people shared Mike Thomas, Brian Weis, and Magnus Westerlund.
observations, identified errors and made suggestions for improving
the specification. Magnus provided many useful comments and Mats
made several valuable suggestions on parameters and syntax that are
in the current draft. Dave Oran and Mike Thomas encouraged us to
bring this work to the IETF for standardization. David McGrew
suggested the conservative approach of requiring unique master keys
for each unicast SDP media stream as followed in this document.
Paul Kyzivat suggested how to handle SIP forking. Jonathan
Rosenberg suggested reducing the complexity by specifying only one
security parameter for each media stream.
11. Authors' Addresses 11. Authors' Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
499 Thornall Street, 8th Floor 499 Thornall Street, 8th Floor
Edison, New Jersey 08837 USA Edison, New Jersey 08837 USA
fandreas@cisco.com fandreas@cisco.com
Mark Baugher Mark Baugher
skipping to change at page 34, line 38 skipping to change at page 36, line 38
[RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994, Recommendations for Security", RFC 1750, December 1994,
http://www.ietf.org/rfc/rfc1750.txt. http://www.ietf.org/rfc/rfc1750.txt.
[RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 3548, July 2003.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security
Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004.
13. Informative References 13. Informative References
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002, Capability Declaration", RFC 3407, October 2002,
http://www.ietf.org/rfc/rfc3407.txt. http://www.ietf.org/rfc/rfc3407.txt.
[Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols," in Proceedings of the Sixth Usenix Unix Security Protocols," in Proceedings of the Sixth Usenix Unix Security
Symposium, pp. 1-16, San Jose, CA, July 1996. Symposium, pp. 1-16, San Jose, CA, July 1996.
skipping to change at page 36, line 11 skipping to change at page 38, line 23
[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000, Protocol", RFC 2974, October 2000,
http://www.ietf.org/rfc/rfc2974.txt. http://www.ietf.org/rfc/rfc2974.txt.
[srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security
Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004.
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 End of changes. 

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