draft-ietf-mmusic-sdescriptions-09.txt   draft-ietf-mmusic-sdescriptions-10.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: August 2005 Cisco Systems EXPIRES: December 2005 Cisco Systems
February, 2005 June, 2005
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-09.txt> <draft-ietf-mmusic-sdescriptions-10.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, the authors certify that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which we are aware have been applicable patent or other IPR claims of which he or she is aware
disclosed, and any of which we become aware will be disclosed, in have been or will be disclosed, and any of which he or she becomes
accordance with RFC 3668 (BCP 79). aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, the authors accept the provisions
of Section 3 of RFC 3667 (BCP 78).
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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt. http://www.ietf.org/ietf/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document defines a Session Description Protocol (SDP) This document defines a Session Description Protocol (SDP)
cryptographic attribute for unicast media streams. The attribute cryptographic attribute for unicast media streams. The attribute
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 Applicability.....................................................3
2. Introduction......................................................3 2 Notational Conventions............................................3
3. SDP "Crypto" Attribute and Parameters.............................5 3 Introduction......................................................4
3.1 Tag.............................................................5
3.2 Crypto-suite....................................................5
3.3 Key Parameters..................................................6
3.4 Session Parameters..............................................7
3.5 Example.........................................................7
4. General Use of the crypto Attribute...............................8
4.1 Use With Offer/Answer...........................................8
4.1.1 Generating the Initial Offer - Unicast Streams.............8
4.1.2 Generating the Initial Answer - Unicast Streams............9
4.1.3 Processing of the Initial Answer - Unicast Streams........10
4.1.4 Modifying the Session.....................................10
4.2 Use Outside Offer/Answer.......................................10
4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions.......................................11
5.1 SRTP Key Parameter.............................................12
5.2 Crypto-suites..................................................14
5.2.1 AES_CM_128_HMAC_SHA1_80...................................15
5.2.2 AES_CM_128_HMAC_SHA1_32...................................15
5.2.3 F8_128_HMAC_SHA1_80.......................................16
5.2.4 Adding new Crypto-suite Definitions.......................16
5.3 Session Parameters.............................................16
5.3.1 KDR=n.....................................................16
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP....................16
5.3.3 UNAUTHENTICATED_SRTP......................................17
5.3.4 FEC_ORDER=order...........................................17
5.3.5 FEC_KEY=key-params........................................17
5.3.6 Window Size Hint (WSH)....................................18
5.3.7 Defining New SRTP Session Parameters......................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.2 Sharing cryptographic contexts among Sessions or SSRCs....20
5.5 Removal of Crypto Contexts.....................................21
6. SRTP-Specific Use of the crypto Attribute........................21
6.1 Use with Offer/Answer..........................................21
6.1.1 Generating the Initial Offer - 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.4 Modifying the Session.....................................23
6.1.5 Offer/Answer Example......................................24
6.2 SRTP-Specific Use Outside Offer/Answer.........................25
6.3 Support for SIP Forking........................................26
6.4 SRTP-Specific Backwards Compatibility Considerations...........26
6.5 Operation with KEYMGT= and k= lines............................27
7. Security Considerations..........................................27
7.1 Authentication of packets......................................27
7.2 Keystream Reuse................................................28
7.3 Signaling Authentication and Signaling Encryption..............28
8. Grammar..........................................................29
8.1 Generic "Crypto" Attribute Grammar.............................29
8.2 SRTP "Crypto" Attribute Grammar................................29
9. IANA Considerations..............................................30
9.1 Registration of the "crypto" attribute.........................30
9.2 New IANA Registries and Registration Procedures................31
9.2.1 Key Method Registry and Registration......................31
9.2.2 Media Stream Transport Registry and Registration..........31
9.3 Initial Registrations..........................................32
9.3.1 Key Method................................................32
9.3.2 SRTP Media Stream Transport...............................32
10. Acknowledgements................................................33
11. Authors' Addresses..............................................33
12. Normative References............................................34
13. Informative References..........................................34
14. Full Copyright Statement........................................36
1. Notational Conventions 4 SDP "Crypto" Attribute and Parameters.............................5
4.1 Tag............................................................5
4.2 Crypto-suite...................................................6
4.3 Key Parameters.................................................6
4.4 Session Parameters.............................................7
4.5 Example........................................................7
5 General Use of the crypto Attribute...............................8
5.1 Use With Offer/Answer..........................................8
5.1.1 Generating the Initial Offer - Unicast Streams............8
5.1.2 Generating the Initial Answer - Unicast Streams...........9
5.1.3 Processing of the Initial Answer - Unicast Streams.......10
5.1.4 Modifying the Session....................................10
5.2 Use Outside Offer/Answer......................................11
5.3 General Backwards Compatibility Considerations................11
6 SRTP Security Descriptions.......................................11
6.1 SRTP Key Parameter............................................12
6.2 Crypto-suites.................................................15
6.2.1 AES_CM_128_HMAC_SHA1_80..................................15
6.2.2 AES_CM_128_HMAC_SHA1_32..................................16
6.2.3 F8_128_HMAC_SHA1_80......................................16
6.2.4 Adding new Crypto-suite Definitions......................16
6.3 Session Parameters............................................16
6.3.1 KDR=n....................................................16
6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................17
6.3.3 UNAUTHENTICATED_SRTP.....................................17
6.3.4 FEC_ORDER=order..........................................17
6.3.5 FEC_KEY=key-params.......................................17
6.3.6 Window Size Hint (WSH)...................................18
6.3.7 Defining New SRTP Session Parameters.....................18
6.4 SRTP Crypto Context Initialization............................18
6.4.1 Late Binding of one or more SSRCs to a crypto context....20
6.4.2 Sharing cryptographic contexts among Sessions or SSRCs...21
6.5 Removal of Crypto Contexts....................................21
7 SRTP-Specific Use of the crypto Attribute........................21
7.1 Use with Offer/Answer.........................................21
7.1.1 Generating the Initial Offer - Unicast Streams...........22
7.1.2 Generating the Initial Answer - Unicast Streams..........22
7.1.3 Processing of the Initial Answer - Unicast Streams.......23
7.1.4 Modifying the Session....................................23
7.1.5 Offer/Answer Example.....................................24
7.2 SRTP-Specific Use Outside Offer/Answer........................25
7.3 Support for SIP Forking.......................................26
7.4 SRTP-Specific Backwards Compatibility Considerations..........26
7.5 Operation with KEYMGT= and k= lines...........................27
8 Security Considerations..........................................27
8.1 Authentication of packets.....................................28
8.2 Keystream Reuse...............................................28
8.3 Signaling Authentication and Signaling Encryption.............28
9 Grammar..........................................................29
9.1 Generic "Crypto" Attribute Grammar............................29
9.2 SRTP "Crypto" Attribute Grammar...............................30
10 IANA Considerations.............................................31
10.1 Registration of the "crypto" attribute......................31
10.2 New IANA Registries and Registration Procedures.............31
10.2.1 Key Method Registry and Registration.....................31
10.2.2 Media Stream Transport Registry and Registration.........32
10.3 Initial Registrations.......................................32
10.3.1 Key Method...............................................32
10.3.2 SRTP Media Stream Transport..............................32
11 Acknowledgements................................................33
12 Authors' Addresses..............................................33
13 Normative References............................................34
14 Informative References..........................................34
15 Full Copyright Statement........................................36
1 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.
2 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
through k inclusive. through k inclusive.
The terms 'transport' and 'media transport' are used to mean The terms 'transport' and 'media transport' are used to mean
'transport protocol' as defined in RFC2327, page 20. 'transport protocol' as defined in RFC2327, page 20.
Explanatory notes are provided in several places throughout the Explanatory notes are provided in several places throughout the
document; these notes are indented two spaces from the surrounding document; these notes are indented two spaces from the surrounding
text. text.
2. Introduction 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 4, line 16 skipping to change at page 4, line 36
The crypto attribute is defined in a generic way to enable its use The crypto attribute is defined in a generic way to enable its use
with SRTP and any other secure transports that can establish with SRTP and any other secure transports that can establish
cryptographic parameters with only a single message or in a single cryptographic parameters with only a single message or in a single
round-trip exchange using the offer/answer model [RFC3264]. round-trip exchange using the offer/answer model [RFC3264].
Extension to transports other than SRTP, however, is beyond the scope Extension to transports other than SRTP, however, is beyond the scope
of this document. Each type of secure media transport needs its own of this document. Each type of secure media transport needs its own
specification for the crypto-attribute parameter. These definitions specification for the crypto-attribute parameter. These definitions
are frequently unique to the particular type of transport and must be are frequently unique to the particular type of transport and must be
specified in a Standards Track RFC and registered with IANA according specified in a Standards Track RFC and registered with IANA according
to the procedures defined in Section 9. This document defines the to the procedures defined in Section 10. This document defines the
security parameters and keying material for SRTP only. security parameters and keying material for SRTP only.
It would be self-defeating not to secure cryptographic keys and other It would be self-defeating not to secure cryptographic keys and other
parameters at least as well as the data is secured. Data security parameters at least as well as the data is secured. Data security
protocols such as SRTP rely upon a separate key management system to protocols such as SRTP rely upon a separate key management system to
securely establish encryption and/or authentication keys. Key securely establish encryption and/or authentication keys. Key
management protocols provide authenticated key establishment (AKE) management protocols provide authenticated key establishment (AKE)
procedures to authenticate the identity of each endpoint and protect procedures to authenticate the identity of each endpoint and protect
against man-in-the-middle, reflection/replay, connection hijacking against man-in-the-middle, reflection/replay, connection hijacking
and some denial of service attacks [skeme]. Along with the key, an and some denial of service attacks [skeme]. Along with the key, an
skipping to change at page 4, line 51 skipping to change at page 5, line 20
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.
In Section 3, we introduce the general SDP crypto attribute, and in In Section 4, we introduce the general SDP crypto attribute, and in
Section 4 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 5, we define the crypto attribute details needed model. In Section 6, 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 7 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 8 recites
security considerations, and Section 8 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 9. the crypto attribute. IANA considerations are provided in Section
10.
3. 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 8.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>]
The fields tag, crypto-suite, key-params, and session-params are The fields tag, crypto-suite, key-params, and session-params are
described in the following sub-sections. Below we show an example of described in the following sub-sections. Below we show an example of
the crypto attribute for the "RTP/SAVP" transport, i.e., the secure the crypto attribute for the "RTP/SAVP" transport, i.e., the secure
RTP extension to the Audio/Video Profile [srtp]. In the following, RTP extension to the Audio/Video Profile [srtp]. In the following,
newlines are included for formatting reasons only: newlines are included for formatting reasons only:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined
by the text starting with "inline:", and session-params is omitted. by the text starting with "inline:", and session-params is omitted.
3.1 Tag 4.1 Tag
The tag is a decimal number used as an identifier for a particular The tag is a decimal number used as an identifier for a particular
crypto attribute (see Section 8.1 for details). The tag MUST be crypto attribute (see Section 9.1 for details). The tag MUST be
unique among all crypto attributes for a given media line. It is unique among all crypto attributes for a given media line. It is
used with the offer/answer model to determine which of several used with the offer/answer model to determine which of several
offered crypto attributes were chosen by the answerer (see Section offered crypto attributes were chosen by the answerer (see Section
4.1). 5.1).
In the offer/answer model, the tag is a negotiated parameter. In the offer/answer model, the tag is a negotiated parameter.
3.2 Crypto-suite 4.2 Crypto-suite
The crypto-suite field is an identifier that describes the encryption The crypto-suite field is an identifier that describes the encryption
and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for
the transport in question (see Section 8.1 for details). The the transport in question (see Section 9.1 for details). The
possible values for the crypto-suite parameter are defined within the possible values for the crypto-suite parameter are defined within the
context of the transport, i.e., each transport defines a separate context of the transport, i.e., each transport defines a separate
namespace for the set of crypto-suites. For example, the crypto- namespace for the set of crypto-suites. For example, the crypto-
suite "AES_CM_128_HMAC_SHA1_80" defined within the context suite "AES_CM_128_HMAC_SHA1_80" defined within the context
"RTP/SAVP" transport applies to Secure RTP only; the string may be "RTP/SAVP" transport applies to Secure RTP only; the string may be
reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a
separate definition would be needed. separate definition would be needed.
In the offer/answer model, the crypto-suite is a negotiated In the offer/answer model, the crypto-suite is a negotiated
parameter. parameter.
3.3 Key Parameters 4.3 Key Parameters
The key-params field provides one or more sets of keying material for The key-params field provides one or more sets of keying material for
the crypto-suite in question. The field consists of a method the crypto-suite in question. The field consists of a method
indicator followed by a colon, and the actual keying information as indicator followed by a colon, and the actual keying information as
shown below (the formal grammar is provided in Section 8.1): shown below (the formal grammar is provided in Section 9.1):
key-params = <key-method> ":" <key-info> key-params = <key-method> ":" <key-info>
Keying material might be provided by different means than key-params, Keying material might be provided by different means than key-params,
however this is out of scope. Only one method is defined in this however this is out of scope. Only one method is defined in this
document, namely "inline", which indicates that the actual keying document, namely "inline", which indicates that the actual keying
material is provided in the key-info field itself. There is a single material is provided in the key-info field itself. There is a single
name space for the key-method, i.e., the key-method is transport name space for the key-method, i.e., the key-method is transport
independent. New key-methods (e.g., use of a URL) may be defined in independent. New key-methods (e.g., use of a URL) may be defined in
a Standards Track RFC in the future. Although the key-method itself a Standards Track RFC in the future. Although the key-method itself
may be generic, the accompanying key-info definition is specific not may be generic, the accompanying key-info definition is specific not
only to the key-method, but also to the transport in question. Key- only to the key-method, but also to the transport in question. Key-
info encodes keying material for a crypto suite, which defines that info encodes keying material for a crypto suite, which defines that
keying material. New key methods MUST be registered with the IANA keying material. New key methods MUST be registered with the IANA
according to the procedures defined in Section 9.2.1. according to the procedures defined in Section 10.2.1.
Key-info is defined as a general character string (see Section 8.1 Key-info is defined as a general character string (see Section 9.1
for details); further transport and key-method specific syntax and for details); further transport and key-method specific syntax and
semantics MUST be provided in a Standards Track RFC for each semantics MUST be provided in a Standards Track RFC for each
combination of transport and key-method that use it; definitions for combination of transport and key-method that use it; definitions for
SRTP are provided in Section 5. Note that such definitions are SRTP are provided in Section 6. Note that such definitions are
provided within the context of both a particular transport (e.g., provided within the context of both a particular transport (e.g.,
"RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will
register the list of supported key methods for each transport. register the list of supported key methods for each transport.
When multiple keys are included in the key parameters, it MUST be When multiple keys are included in the key parameters, it MUST be
possible to determine which of the keys is being used in a given possible to determine which of the keys is being used in a given
media packet by a simple inspection of the media packet received; a media packet by a simple inspection of the media packet received; a
trial-and-error approach between the possible keys MUST NOT be trial-and-error approach between the possible keys MUST NOT be
performed. performed.
For SRTP, this could be achieved by use of Master Key Identifiers For SRTP, this could be achieved by use of Master Key Identifiers
(MKI) [srtp]. Use of <"From, "To"> values are not supported in (MKI) [srtp]. Use of <"From, "To"> values are not supported in
SRTP security descriptions for reasons explained in Section 5.1, SRTP security descriptions for reasons explained in Section 6.1,
below. below.
In the offer/answer model, the key parameter is a declarative In the offer/answer model, the key parameter is a declarative
parameter. parameter.
3.4 Session Parameters 4.4 Session Parameters
Session parameters are specific to a given transport and use of them Session parameters are specific to a given transport and use of them
is OPTIONAL in the security descriptions framework, where they are is OPTIONAL in the security descriptions framework, where they are
just defined as general character strings. If session parameters are just defined as general character strings. If session parameters are
to be used for a given transport, then transport-specific syntax and to be used for a given transport, then transport-specific syntax and
semantics MUST be provided in a Standards Track RFC; definitions for semantics MUST be provided in a Standards Track RFC; definitions for
SRTP are provided in Section 5. SRTP are provided in Section 6.
In the offer/answer model, session parameters may be either In the offer/answer model, session parameters may be either
negotiated or declarative; the definition of specific session negotiated or declarative; the definition of specific session
parameters MUST indicate whether they are negotiated or declarative. parameters MUST indicate whether they are negotiated or declarative.
Negotiated parameters apply to data sent in both directions, whereas Negotiated parameters apply to data sent in both directions, whereas
declarative parameters apply only to media sent by the entity that declarative parameters apply only to media sent by the entity that
generated the SDP. Thus, a declarative parameter in an offer applies generated the SDP. Thus, a declarative parameter in an offer applies
to media sent by the offerer, whereas a declarative parameter in an to media sent by the offerer, whereas a declarative parameter in an
answer applies to media sent by the answerer. answer applies to media sent by the answerer.
3.5 Example 4.5 Example
This example shows use of the crypto attribute for the "RTP/SAVP" This example shows use of the crypto attribute for the "RTP/SAVP"
media transport type (as defined in Section 4). The "a=crypto" line media transport type (as defined in Section 5). The "a=crypto" line
is actually one long line; it is shown as two lines due to page is actually one long line; it is shown as two lines due to page
formatting: formatting:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127 c=IN IP4 161.44.17.12/127
skipping to change at page 7, line 50 skipping to change at page 8, line 25
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0 m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb m=application 32416 udp wb
a=orient:portrait a=orient:portrait
This SDP message describes three media streams, two of which use the This SDP message describes three media streams, two of which use the
"RTP/SAVP" transport. Each has a crypto attribute for the "RTP/SAVP" transport. Each has a crypto attribute for the
"RTP/SAVP" transport. These secure-RTP specific descriptions are "RTP/SAVP" transport. These secure-RTP specific descriptions are
defined in Section 5. defined in Section 6.
4. General Use of the crypto Attribute 5 General Use of the crypto Attribute
In this section, we describe the general use of the crypto attribute In this section, we describe the general use of the crypto attribute
outside of any transport or key-method specific rules. outside of any transport or key-method specific rules.
4.1 Use With Offer/Answer 5.1 Use With Offer/Answer
The general offer/answer rules for the crypto attribute are in The general offer/answer rules for the crypto attribute are in
addition to the rules specified in RFC 3264, which MUST be followed, addition to the rules specified in RFC 3264, which MUST be followed,
unless otherwise noted. RFC 3264 defines operation for both unicast unless otherwise noted. RFC 3264 defines operation for both unicast
and multicast streams; the sections below describe operation for two- and multicast streams; the sections below describe operation for two-
party unicast streams only, since support for multicast streams (and party unicast streams only, since support for multicast streams (and
multipoint unicast streams) is for further study. multipoint unicast streams) is for further study.
4.1.1 Generating the Initial Offer - Unicast Streams 5.1.1 Generating the Initial Offer - Unicast Streams
When generating an initial offer for a unicast stream, there MUST be When generating an initial offer for a unicast stream, there MUST be
one or more crypto attributes present for each media stream for which one or more crypto attributes present for each media stream for which
security is desired. Each crypto attribute for a given media stream security is desired. Each crypto attribute for a given media stream
MUST contain a unique tag. MUST contain a unique tag.
The ordering of multiple "a=crypto" lines is significant: The most The ordering of multiple "a=crypto" lines is significant: The most
preferred crypto line is listed first. Each crypto attribute preferred crypto line is listed first. Each crypto attribute
describes the crypto-suite, key(s) and possibly session parameters describes the crypto-suite, key(s) and possibly session parameters
offered for the media stream. In general, a "more preferred" crypto- offered for the media stream. In general, a "more preferred" crypto-
skipping to change at page 9, line 10 skipping to change at page 9, line 34
be using for media sent to the offerer. Second, the offerer may not be using for media sent to the offerer. Second, the offerer may not
be able to deduce which of the offered crypto attributes were be able to deduce which of the offered crypto attributes were
accepted. Since media may arrive prior to the answer, delay or accepted. Since media may arrive prior to the answer, delay or
clipping can occur. If this is unacceptable to the offerer, the clipping can occur. If this is unacceptable to the offerer, the
offerer SHOULD use a mechanism outside the scope of this document to offerer SHOULD use a mechanism outside the scope of this document to
prevent the above problem. prevent the above problem.
For example, in SIP [RFC3261], a "security" precondition as defined For example, in SIP [RFC3261], a "security" precondition as defined
in [sprecon] could solve the above problem. in [sprecon] could solve the above problem.
4.1.2 Generating the Initial Answer - Unicast Streams 5.1.2 Generating the Initial Answer - Unicast Streams
When the answerer receives the initial offer with one or more crypto When the answerer receives the initial offer with one or more crypto
attributes for a given unicast media stream, the answerer MUST either attributes for a given unicast media stream, the answerer MUST either
accept exactly one of the offered crypto attributes, or the offered accept exactly one of the offered crypto attributes, or the offered
stream MUST be rejected. stream MUST be rejected.
If the answerer wishes to indicate support for other crypto If the answerer wishes to indicate support for other crypto
attributes, those can be listed by use of the SDP Simple Capability attributes, those can be listed by use of the SDP Simple Capability
Declaration [RFC3407] extensions. Declaration [RFC3407] extensions.
skipping to change at page 10, line 5 skipping to change at page 10, line 30
included in the answer. Declarative session parameters provided by included in the answer. Declarative session parameters provided by
the offerer are not included in the answer, however the answerer may the offerer are not included in the answer, however the answerer may
provide its own set of declarative session parameters. provide its own set of declarative session parameters.
Once the answerer has accepted one of the offered crypto attributes, Once the answerer has accepted one of the offered crypto attributes,
the answerer MAY begin sending media to the offerer in accordance the answerer MAY begin sending media to the offerer in accordance
with the selected crypto attribute. Note however, that the offerer with the selected crypto attribute. Note however, that the offerer
may not be able to process such media packets correctly until the may not be able to process such media packets correctly until the
answer has been received. answer has been received.
4.1.3 Processing of the Initial Answer - Unicast Streams 5.1.3 Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, the offerer MUST verify, that When the offerer receives the answer, the offerer MUST verify, that
one of the initially offered crypto suites and its accompanying tag one of the initially offered crypto suites and its accompanying tag
was accepted and echoed in the answer. Also, the answer MUST include was accepted and echoed in the answer. Also, the answer MUST include
one or more keys, which will be used for media sent from the answerer one or more keys, which will be used for media sent from the answerer
to the offerer. to the offerer.
If the offer contained any mandatory negotiated session parameters If the offer contained any mandatory negotiated session parameters
(see section 5.3.7), the offerer MUST verify that said parameters are (see section 6.3.7), the offerer MUST verify that said parameters are
included in the answer and support them. If the answer contains any included in the answer and support them. If the answer contains any
mandatory declarative session parameters, the offerer MUST be able to mandatory declarative session parameters, the offerer MUST be able to
support those. support those.
If any of the above fails, the negotiation MUST fail. If any of the above fails, the negotiation MUST fail.
4.1.4 Modifying the Session 5.1.4 Modifying the Session
Once a media stream has been established, it MAY be modified at any Once a media stream has been established, it MAY be modified at any
time, as described in RFC 3264, Section 8. Such a modification MAY time, as described in RFC 3264, Section 8. Such a modification MAY
be triggered by the security service, e.g., in order to perform a re- be triggered by the security service, e.g., in order to perform a re-
keying or change the crypto-suite. If media stream security using keying or change the crypto-suite. If media stream security using
the general security descriptions defined here is still desired, the the general security descriptions defined here is still desired, the
crypto attribute MUST be included in these new offer/answer crypto attribute MUST be included in these new offer/answer
exchanges. The procedures are similar to those defined in Section exchanges. The procedures are similar to those defined in Section
4.1.1, 4.1.2, 4.1.3 of this document, subject to the considerations 5.1.1, 5.1.2, 5.1.3 of this document, subject to the considerations
provided in RFC 3264 Section 8. provided in RFC 3264 Section 8.
4.2 Use Outside Offer/Answer 5.2 Use Outside Offer/Answer
The crypto attribute can also be used outside the context of The crypto attribute can also be used outside the context of
offer/answer where there is no negotiation of the crypto suite, offer/answer where there is no negotiation of the crypto suite,
cryptographic key or session parameters. In this case, the sender cryptographic key or session parameters. In this case, the sender
determines security parameters for the stream. Since there is no determines security parameters for the stream. Since there is no
negotiation mechanisms, the sender MUST include exactly one crypto negotiation mechanisms, the sender MUST include exactly one crypto
attribute and the receiver MUST either accept it or else SHOULD NOT attribute and the receiver MUST either accept it or else SHOULD NOT
receive the associated stream. The sender SHOULD select the security receive the associated stream. The sender SHOULD select the security
description that it deems most secure for its purposes. description that it deems most secure for its purposes.
4.3 General Backwards Compatibility Considerations 5.3 General Backwards Compatibility Considerations
In the offer/answer model, it is possible that the answerer supports In the offer/answer model, it is possible that the answerer supports
a given secure transport (e.g., "RTP/SAVP") and accepts the offered a given secure transport (e.g., "RTP/SAVP") and accepts the offered
media stream, yet the answerer does not support the crypto attribute media stream, yet the answerer does not support the crypto attribute
defined in this document and hence ignores it. The offerer can defined in this document and hence ignores it. The offerer can
recognize this situation by seeing an accepted media stream in the recognize this situation by seeing an accepted media stream in the
answer that does not include a crypto line. In that case, the answer that does not include a crypto line. In that case, the
security negotiation defined here MUST fail. security negotiation defined here MUST fail.
Similar issues exist when security descriptions are used outside of Similar issues exist when security descriptions are used outside of
the offer/answer model. But the source of a non-negotiated security the offer/answer model. But the source of a non-negotiated security
description has no indication that the receiver has ignored the description has no indication that the receiver has ignored the
crypto attribute. crypto attribute.
5. SRTP Security Descriptions 6 SRTP Security Descriptions
In this section, we provide definitions for security descriptions for In this section, we provide definitions for security descriptions for
SRTP media streams. In the next section, we define how to use SRTP SRTP media streams. In the next section, we define how to use SRTP
security descriptions with and without the offer/answer model. security descriptions with and without the offer/answer model.
SRTP security descriptions MUST only be used with the SRTP transport SRTP security descriptions MUST only be used with the SRTP transport
(e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security
descriptions for the "RTP/SAVP" profile defined in [srtp], however it descriptions for the "RTP/SAVP" profile defined in [srtp], however it
is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can
use the same descriptions, which are in accordance with the SRTP use the same descriptions, which are in accordance with the SRTP
skipping to change at page 11, line 34 skipping to change at page 12, line 6
SRTP service with a particular crypto attribute parameter, but SRTP SRTP service with a particular crypto attribute parameter, but SRTP
guarantees minimal interoperability among SRTP endpoints through the guarantees minimal interoperability among SRTP endpoints through the
default SRTP parameters [srtp]. More capable SRTP endpoints support default SRTP parameters [srtp]. More capable SRTP endpoints support
a variety of parameter values beyond the SRTP defaults and these a variety of parameter values beyond the SRTP defaults and these
values can be configured by the SRTP security descriptions defined values can be configured by the SRTP security descriptions defined
here. An endpoint that does not support the crypto attribute will here. An endpoint that does not support the crypto attribute will
ignore it according to the SDP. Such an endpoint will not correctly ignore it according to the SDP. Such an endpoint will not correctly
process the particular media stream. By using the Offer/Answer process the particular media stream. By using the Offer/Answer
model, the offerer and answerer can negotiate the crypto parameters model, the offerer and answerer can negotiate the crypto parameters
to be used before commencement of the multimedia session (see Section to be used before commencement of the multimedia session (see Section
6.1). 7.1).
There are over twenty cryptographic parameters listed in the SRTP There are over twenty cryptographic parameters listed in the SRTP
specification. Many of these parameters have fixed values for specification. Many of these parameters have fixed values for
particular cryptographic transforms. At the time of session particular cryptographic transforms. At the time of session
establishment, however, there is usually no need to provide unique establishment, however, there is usually no need to provide unique
settings for many of the SRTP parameters, such as salt length and settings for many of the SRTP parameters, such as salt length and
pseudo-random function (PRF). Thus, it is possible to simplify the pseudo-random function (PRF). Thus, it is possible to simplify the
list of parameters by defining "cryptographic suites" that fix a set list of parameters by defining "cryptographic suites" that fix a set
of SRTP parameter values for the security session. This approach is of SRTP parameter values for the security session. This approach is
followed by the SRTP security descriptions, which uses the general followed by the SRTP security descriptions, which uses the general
skipping to change at page 12, line 26 skipping to change at page 12, line 40
- 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]. Regarding the parameters and their descriptions [Section 8.2, srtp]. Regarding the
UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security
descriptions MUST NOT use the SRTCP E-bit to override descriptions MUST NOT use the SRTCP E-bit to override
UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP
messages (see 5.3.2). The key parameter, the crypto-suite, and the messages (see Section 6.3.2). The key parameter, the crypto-suite,
session parameters shown above are described in detail in the and the session parameters shown above are described in detail in the
following subsections. following subsections.
5.1 SRTP Key Parameter 6.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
key identifier (MKI) to associate an incoming SRTP packet with a key identifier (MKI) to associate an incoming SRTP packet with a
particular master key. Compliant implementations obey the policies particular master key. Compliant implementations obey the policies
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 9.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
skipping to change at page 13, line 38 skipping to change at page 13, line 52
results in the base64 input being an integral number of octets. For results in the base64 input being an integral number of octets. For
example, if the length defined was 250 bits, then 6 padding bits example, if the length defined was 250 bits, then 6 padding bits
would be needed, which could be defined to be the last 6 bits in a would be needed, which could be defined to be the last 6 bits in a
256 bit input. 256 bit input.
The second field, is the OPTIONAL lifetime of the master key as The second field, is the OPTIONAL lifetime of the master key as
measured in maximum number of SRTP or SRTCP packets using that master measured in maximum number of SRTP or SRTCP packets using that master
key (i.e., the number of SRTP packets and the number of SRTCP packets key (i.e., the number of SRTP packets and the number of SRTCP packets
each have to be less than the lifetime). The lifetime value MAY be each have to be less than the lifetime). The lifetime value MAY be
written as a non-zero, positive integer or as a power of 2 (see the written as a non-zero, positive integer or as a power of 2 (see the
grammar in Section 8.2 for details). The "lifetime" value MUST NOT grammar in Section 9.2 for details). The "lifetime" value MUST NOT
exceed the maximum packet lifetime for the crypto-suite. If the exceed the maximum packet lifetime for the crypto-suite. If the
lifetime is too large or otherwise invalid then the entire crypto lifetime is too large or otherwise invalid then the entire crypto
attribute MUST be considered invalid. The default MAY be implicitly attribute MUST be considered invalid. The default MAY be implicitly
signaled by omitting the lifetime value (i.e., "||"). This is signaled by omitting the lifetime (note that the lifetime field never
includes a colon, whereas the third field always does). 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
skipping to change at page 14, line 4 skipping to change at page 14, line 17
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. The MKI is expressed as positive integer in big-endian order key. The MKI is here defined as a positive integer which is encoded
with unused, high-order bytes set to zero. If the MKI is given, then as a big-endian integer in the actual SRTP packets. If the MKI is
the length of the MKI MUST also be given and separated from the MKI given, then the length of the MKI MUST also be given and separated
by a colon (":"). The MKI length is the size of the MKI field in the from the MKI by a colon (":"). The MKI length is the size of the MKI
SRTP packet, specified in bytes. If the MKI length is not given or field in the SRTP packet, specified in bytes. If the MKI length is
its value exceeds 128 (bytes), then the entire crypto attribute MUST not given or its value exceeds 128 (bytes), then the entire crypto
be considered invalid. The substring "1:4" in the first example attribute MUST be considered invalid. The substring "1:4" in the
assigns to the key a master key identifier of 1 that is 4 bytes long, first example assigns to the key a master key identifier of 1 that is
and the second example assigns a 4-byte master key identifier of 1066 4 bytes long, and the second example assigns a 4-byte master key
to the key. One or more master keys with their associated MKI can be identifier of 1066 to the key. One or more master keys with their
initially defined, and then later updated, or deleted and new ones associated MKI can be initially defined, and then later updated, or
defined. 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
skipping to change at page 14, line 41 skipping to change at page 15, line 4
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
for the very few applications that need it since the MKI feature is for the very few applications that need it since the MKI feature is
simpler (though the MKI adds additional bytes to each packet whereas simpler (though the MKI adds additional bytes to each packet whereas
<"From", "To"> does not). <"From", "To"> does not).
As mentioned above, the key parameter can contain one or more master As mentioned above, the key parameter can contain one or more master
keys. When the key parameter contains more than one master key, all keys. When the key parameter contains more than one master key, all
of the master keys in that key parameter MUST include an MKI value. of the master keys in that key parameter MUST include an MKI value.
When using the MKI, the MKI length MUST be the same for all keys in a When using the MKI, the MKI length MUST be the same for all keys in a
given crypto attribute. given crypto attribute.
5.2 Crypto-suites 6.2 Crypto-suites
The SRTP crypto-suites define the encryption and authentication The SRTP crypto-suites define the encryption and authentication
transforms to be used for the SRTP media stream. The SRTP transforms to be used for the SRTP media stream. The SRTP
specification has defined three crypto-suites, which are described specification has defined three crypto-suites, which are described
further in the following subsections in the context of the SRTP further in the following subsections in the context of the SRTP
security descriptions. The table below provides an overview of the security descriptions. The table below provides an overview of the
crypto-suites and their parameters: crypto-suites and their parameters:
+---------------------+-------------+--------------+---------------+ +---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ | | |AES_CM_128_ | AES_CM_128_ | F8_128_ |
skipping to change at page 15, line 21 skipping to change at page 15, line 33
| Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets | | Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | F8 | | Cipher | AES Counter | AES Counter | F8 |
| | Mode | Mode | | | | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits | | Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| Authentication tag | 80 bits | 32 bits | 80 bits | | Authentication tag | 80 bits | 32 bits | 80 bits |
| SRTP auth. key | 160 bits | 160 bits | 160 bits | | SRTP auth. key | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key | 160 bits | 160 bits | 160 bits | | SRTCP auth. key | 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+ +---------------------+-------------+--------------+---------------+
5.2.1 AES_CM_128_HMAC_SHA1_80 6.2.1 AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher
and HMAC-SHA1 message authentication having an 80-bit authentication and HMAC-SHA1 message authentication having an 80-bit authentication
tag. The master-key length is 128 bits and has a default lifetime tag. The master-key length is 128 bits and has a default lifetime
of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes
first [Page 39, srtp]. first [Page 39, srtp].
Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets,
whichever comes first. SRTP security descriptions, however, whichever comes first. SRTP security descriptions, however,
simplify the parameters to share a single upper bound of 2^31 simplify the parameters to share a single upper bound of 2^31
packets. It is RECOMMENDED that automated key management allow packets. It is RECOMMENDED that automated key management allow
easy and efficient rekeying at intervals far smaller than 2^31 easy and efficient rekeying at intervals far smaller than 2^31
packets given today's media rates or even HDTV media rates. packets given today's media rates or even HDTV media rates.
The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP
and SRTCP authentication key lengths are 160 bits (see Security and SRTCP authentication key lengths are 160 bits (see Security
Considerations in Section 7). The master salt value is 112 bits in Considerations in Section 8). The master salt value is 112 bits in
length and the session salt value is 112 bits in length. The length and the session salt value is 112 bits in length. The
pseudo-random function (PRF) is the default SRTP pseudo-random pseudo-random function (PRF) is the default SRTP pseudo-random
function that uses AES Counter Mode with a 128-bit key length. function that uses AES Counter Mode with a 128-bit key length.
The length of the base64 decoded key and salt value for this crypto- The length of the base64 decoded key and salt value for this crypto-
suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto
attribute is considered invalid. attribute is considered invalid.
5.2.2 AES_CM_128_HMAC_SHA1_32 6.2.2 AES_CM_128_HMAC_SHA1_32
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except
that the authentication tag is 32 bits. that the authentication tag is 32 bits.
The length of the base64-decoded key and salt value for this crypto- The length of the base64-decoded key and salt value for this crypto-
suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto
attribute is considered invalid. attribute is considered invalid.
5.2.3 F8_128_HMAC_SHA1_80 6.2.3 F8_128_HMAC_SHA1_80
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the
cipher is F8 [srtp]. cipher is F8 [srtp].
The length of the base64 decoded key and salt value for this crypto- The length of the base64 decoded key and salt value for this crypto-
suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto
attribute is considered invalid. attribute is considered invalid.
5.2.4 Adding new Crypto-suite Definitions 6.2.4 Adding new Crypto-suite Definitions
If new transforms are added to SRTP, new definitions for those If new transforms are added to SRTP, new definitions for those
transforms SHOULD be given for the SRTP security descriptions and transforms SHOULD be given for the SRTP security descriptions and
published in a Standards Track RFC. Sections 5.2.1 through 5.2.3 published in a Standards Track RFC. Sections 6.2.1 through 6.2.3
illustrate how to define crypto-suite values for particular illustrate how to define crypto-suite values for particular
cryptographic transforms. Any new crypto-suites MUST be registered cryptographic transforms. Any new crypto-suites MUST be registered
with IANA following the procedures in section 9. with IANA following the procedures in section 10.
5.3 Session Parameters 6.3 Session Parameters
SRTP security descriptions define a set of "session" parameters, SRTP security descriptions define a set of "session" parameters,
which OPTIONALLY may be used to override SRTP session defaults for which OPTIONALLY may be used to override SRTP session defaults for
the SRTP and SRTCP streams. These parameters configure an RTP the SRTP and SRTCP streams. These parameters configure an RTP
session for SRTP services. The session parameters provide session- session for SRTP services. The session parameters provide session-
specific information to establish the SRTP cryptographic context. specific information to establish the SRTP cryptographic context.
5.3.1 KDR=n 6.3.1 KDR=n
KDR specifies the Key Derivation Rate, as described in section 4.3.1 KDR specifies the Key Derivation Rate, as described in section 4.3.1
of [srtp]. of [srtp].
The value n MUST be an integer in the set {1,2,...,24}, which The value n MUST be an integer in the set {1,2,...,24}, which
denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key
derivation rate controls how frequently a new session key is derived derivation rate controls how frequently a new session key is derived
from an SRTP master key(s) [srtp] given in the declaration. When from an SRTP master key(s) [srtp] given in the declaration. When
the key derivation rate is not specified (i.e., the KDR parameter is the key derivation rate is not specified (i.e., the KDR parameter is
omitted), a single initial key derivation is performed [srtp]. omitted), a single initial key derivation is performed [srtp].
In the offer/answer model, KDR is a declarative parameter. In the offer/answer model, KDR is a declarative parameter.
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP
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. If In the offer/answer model, these parameters are negotiated. If
UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit 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, 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 are encrypted and the E bit MUST be set (1) on
all SRTCP messages. all SRTCP messages.
5.3.3 UNAUTHENTICATED_SRTP 6.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].
In the offer/answer model, this parameter is negotiated. In the offer/answer model, this parameter is negotiated.
5.3.4 FEC_ORDER=order 6.3.4 FEC_ORDER=order
FEC_ORDER signals the use of forward error correction for the RTP FEC_ORDER signals the use of forward error correction for the RTP
packets [rfc2733]. The forward error correction values for "order" packets [rfc2733]. The forward error correction values for "order"
are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied
before SRTP processing by the sender of the SRTP media and after SRTP before SRTP processing by the sender of the SRTP media and after SRTP
processing by the receiver of the SRTP media; FEC_SRTP is the processing by the receiver of the SRTP media; FEC_SRTP is the
default. SRTP_FEC is the reverse processing. default. SRTP_FEC is the reverse processing.
In the offer/answer model, FEC_ORDER is a declarative parameter. In the offer/answer model, FEC_ORDER is a declarative parameter.
5.3.5 FEC_KEY=key-params 6.3.5 FEC_KEY=key-params
FEC_KEY signals the use of separate master key(s) for a Forward FEC_KEY signals the use of separate master key(s) for a Forward
Error Correction (FEC) stream. The master key(s) are specified with Error Correction (FEC) stream. The master key(s) are specified with
the exact same format as the SRTP Key Parameter defined in Section the exact same format as the SRTP Key Parameter defined in Section
5.1, and the semantic rules are the same - in particular, the master 6.1, and the semantic rules are the same - in particular, the master
key(s) MUST be different from all other master key(s) in the SDP. A key(s) MUST be different from all other master key(s) in the SDP. A
FEC_KEY MUST be specified when the FEC stream is sent to a different FEC_KEY MUST be specified when the FEC stream is sent to a different
IP-address and/or port than the media stream to which it applies IP-address and/or port than the media stream to which it applies
(i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1. (i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1.
When a FEC stream is sent to the same IP-address and port as the When a FEC stream is sent to the same IP-address and port as the
media stream to which it applies, a FEC_KEY MUST NOT be specified. media stream to which it applies, a FEC_KEY MUST NOT be specified.
If a FEC_KEY is specified in this latter case, the crypto attribute If a FEC_KEY is specified in this latter case, the crypto attribute
in question MUST be considered invalid. in question MUST be considered invalid.
In the offer/answer model, FEC_KEY is a declarative parameter. In the offer/answer model, FEC_KEY is a declarative parameter.
5.3.6 Window Size Hint (WSH) 6.3.6 Window Size Hint (WSH)
SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to
protect against replay attacks. The minimum value is 64 [srtp], protect against replay attacks. The minimum value is 64 [srtp],
however this value may be considered too low for some applications however this value may be considered too low for some applications
(e.g., video). (e.g., video).
The Window Size Hint (WSH) session parameter provides a hint for how The Window Size Hint (WSH) session parameter provides a hint for how
big this window should be to work satisfactorily (e.g., based on big this window should be to work satisfactorily (e.g., based on
sender knowledge of number of packets per second). However, there sender knowledge of number of packets per second). However, there
might be enough information given in SDP attributes like might be enough information given in SDP attributes like
"a=maxprate" [maxprate] and the bandwidth modifiers to allow a "a=maxprate" [maxprate] and the bandwidth modifiers to allow a
receiver to derive the parameter satisfactorily. Consequently, this receiver to derive the parameter satisfactorily. Consequently, this
value is only considered a hint to the receiver of the SDP which MAY value is only considered a hint to the receiver of the SDP which MAY
choose to ignore the value provided. choose to ignore the value provided.
In the offer/answer model, WSH is a declarative parameter. In the offer/answer model, WSH is a declarative parameter.
5.3.7 Defining New SRTP Session Parameters 6.3.7 Defining New SRTP Session Parameters
New SRTP session parameters for the SRTP security descriptions can New SRTP session parameters for the SRTP security descriptions can
be defined in a Standards Track RFC and registered with IANA be defined in a Standards Track RFC and registered with IANA
according to the registration procedures defined in Section 9. according to the registration procedures defined in Section 10.
New SRTP session parameters are by default mandatory. A newly- New SRTP session parameters are by default mandatory. A newly-
defined SRTP session parameter that is prefixed with the dash defined SRTP session parameter that is prefixed with the dash
character ("-") however is considered optional and MAY be ignored. character ("-") however is considered optional and MAY be ignored.
If an SDP crypto attribute is received with an unknown session If an SDP crypto attribute is received with an unknown session
parameter that is not prefixed with a "-" character, that crypto parameter that is not prefixed with a "-" character, that crypto
attribute MUST be considered invalid. attribute MUST be considered invalid.
5.4 SRTP Crypto Context Initialization 6.4 SRTP Crypto Context Initialization
In addition to the various SRTP parameters defined above, there are In addition to the various SRTP parameters defined above, there are
three pieces of information that are critical to the operation of the three pieces of information that are critical to the operation of the
default SRTP ciphers: default SRTP ciphers:
* SSRC: Synchronization source * SSRC: Synchronization source
* ROC: Roll-over counter for a given SSRC * ROC: Roll-over counter for a given SSRC
* SEQ: Sequence number for a given SSRC * SEQ: Sequence number for a given SSRC
In a unicast session, as defined here, there are three constraints on In a unicast session, as defined here, there are three constraints on
these values. these values.
The first constraint is on the SSRC, which makes an SRTP keystream be The first constraint is on the SSRC, which makes an SRTP keystream be
unique from other participants. As explained in SRTP, the keystream unique from other participants. As explained in SRTP, the keystream
MUST NOT be reused on two or more different pieces of plaintext. MUST NOT be reused on two or more different pieces of plaintext.
Keystream reuse makes the ciphertext vulnerable to cryptanalysis. Keystream reuse makes the ciphertext vulnerable to cryptanalysis.
One vulnerability is that known-plaintext fields in one stream can One vulnerability is that known-plaintext fields in one stream can
expose portions of the reused keystream and this could further expose expose portions of the reused keystream and this could further expose
more plaintext in other streams. Since all current SRTP encryption more plaintext in other streams. Since all current SRTP encryption
transforms use keystreams, key sharing is a general problem [srtp]. transforms use keystreams, key sharing is a general problem [srtp].
SRTP mitigates this problem by including the SSRC of the sender in SRTP mitigates this problem by including the SSRC of the sender in
the keystream. But SRTP does not solve this problem in its entirety the keystream. But SRTP does not solve this problem in its entirety
because Real-time Transport Protocol has SSRC collisions, which are because Real-time Transport Protocol has SSRC collisions, which are
very rare [rtp] but quite possible. During a collision, two or more very rare [rtp] but quite possible. During a collision, two or more
SSRCs that share a master key will have identical keystreams for SSRCs that share a master key will have identical keystreams for
overlapping portions of the RTP sequence-number space. SRTP Security overlapping portions of the RTP sequence-number space. SRTP Security
skipping to change at page 19, line 52 skipping to change at page 20, line 7
number value and put the receiver in an ambiguous situation: If number value and put the receiver in an ambiguous situation: If
initial packets are lost in transit up to the point that the sequence initial packets are lost in transit up to the point that the sequence
number wraps (i.e., exceeds 2^16-1), then the receiver might not number wraps (i.e., exceeds 2^16-1), then the receiver might not
recognize that its ROC needs to be incremented. By restricting the recognize that its ROC needs to be incremented. By restricting the
initial SEQ to the range of 0..2^15-1, SRTP packet-index initial SEQ to the range of 0..2^15-1, SRTP packet-index
determination will find the correct ROC value, unless all of the determination will find the correct ROC value, unless all of the
first 2^15 packets are lost (which seems, if not impossible, then first 2^15 packets are lost (which seems, if not impossible, then
rather unlikely). See Section 3.3.1 of the SRTP specification rather unlikely). See Section 3.3.1 of the SRTP specification
regarding packet-index determination [srtp]. regarding packet-index determination [srtp].
5.4.1 Late Binding of one or more SSRCs to a crypto context 6.4.1 Late Binding of one or more SSRCs to a crypto context
The packet index, therefore, depends on the SSRC, the SEQ of an The packet index, therefore, depends on the SSRC, the SEQ of an
incoming packet and the ROC, which is an SRTP crypto context incoming packet and the ROC, which is an SRTP crypto context
variable. Thus, SRTP has a big security dependency on SSRC variable. Thus, SRTP has a big security dependency on SSRC
uniqueness. uniqueness.
Given the above constraints, unicast SRTP crypto contexts can be Given the above constraints, unicast SRTP crypto contexts can be
established without the need to negotiate SSRC values in the SRTP established without the need to negotiate SSRC values in the SRTP
security descriptions. Instead, an approach called "late binding" is security descriptions. Instead, an approach called "late binding" is
RECOMMENDED by this specification. When a packet arrives, the SSRC RECOMMENDED by this specification. When a packet arrives, the SSRC
skipping to change at page 20, line 50 skipping to change at page 21, line 7
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 Sessions or SSRCs 6.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
RTP 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 from the same entity will share ROC or SEQ. Thus, multiple SSRCs from the same entity will share
a=crypto parameters when late binding is used. Multiple SSRCs from a=crypto parameters when late binding is used. Multiple SSRCs from
the same entity arises due to either multiple sources (microphones, the same entity arises due to either multiple sources (microphones,
cameras, etc.), or RTP payloads requiring SSRC multiplexing within cameras, etc.), or RTP payloads requiring SSRC multiplexing within
that same session. SDP also allows multiple RTP sessions to be that same session. SDP also allows multiple RTP sessions to be
defined in the same media description ("m="), these RTP sessions will defined in the same media description ("m="), these RTP sessions will
also share the a=crypto parameters. An application that uses also share the a=crypto parameters. An application that uses
a=crypto in this way serially shares a master key among RTP sessions 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 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 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 6.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
when it cannot. when it cannot.
Even when late binding is used for a unicast stream, the ROC is Even when late binding is used for a unicast stream, the ROC is
skipping to change at page 21, line 38 skipping to change at page 21, line 46
the crypto context is removed. the crypto context is removed.
We resolve this problem as follows. When SRTP security descriptions We resolve this problem as follows. When SRTP security descriptions
are being used, crypto-context removal MUST follow the same rules as are being used, crypto-context removal MUST follow the same rules as
SSRC removal from the member table [RFC 3550]; note that this can SSRC removal from the member table [RFC 3550]; note that this can
happen as the result of an SRTCP BYE packet or a simple time-out due happen as the result of an SRTCP BYE packet or a simple time-out due
to inactivity. Inactive session participants that wish to ensure to inactivity. Inactive session participants that wish to ensure
their crypto contexts are not timed out MUST thus send SRTCP packets their crypto contexts are not timed out MUST thus send SRTCP packets
at regular intervals. at regular intervals.
6. SRTP-Specific Use of the crypto Attribute 7 SRTP-Specific Use of the crypto Attribute
Section 4 describes general use of the crypto attribute, and this Section 5 describes general use of the crypto attribute, and this
section completes it by describing SRTP-specific use. section completes it by describing SRTP-specific use.
6.1 Use with Offer/Answer 7.1 Use with Offer/Answer
In this section, we describe how the SRTP security descriptions are In this section, we describe how the SRTP security descriptions are
used with the offer/answer model to negotiate cryptographic used with the offer/answer model to negotiate cryptographic
capabilities and communicate SRTP master keys. The rules defined capabilities and communicate SRTP master keys. The rules defined
below complement the general offer/answer rules defined in Section below complement the general offer/answer rules defined in Section
4.1, which MUST be followed, unless otherwise specified. Note that 5.1, which MUST be followed, unless otherwise specified. Note that
the rules below define unicast operation only; support for multicast the rules below define unicast operation only; support for multicast
and multipoint unicast streams is for further study. and multipoint unicast streams is for further study.
6.1.1 Generating the Initial Offer - Unicast Streams 7.1.1 Generating the Initial Offer - Unicast Streams
When the initial offer is generated, the offerer MUST follow the When the initial offer is generated, the offerer MUST follow the
steps in Section 4.1.1 as well as the following steps. steps in Section 5.1.1 as well as the following steps.
For each unicast media line (m=) using the secure RTP transport For each unicast media line (m=) using the secure RTP transport
where the offerer wants to specify cryptographic parameters, the where the offerer wants to specify cryptographic parameters, the
offerer MUST provide at least one valid SRTP security description offerer MUST provide at least one valid SRTP security description
("a=crypto" line), as defined in Section 5. If the media stream ("a=crypto" line), as defined in Section 6. If the media stream
includes Forward Error Correction with a different IP-address and/or includes Forward Error Correction with a different IP-address and/or
port than the media stream itself, a FEC_KEY parameter MUST be port than the media stream itself, a FEC_KEY parameter MUST be
included, as described in Section 5.3.5. included, as described in Section 6.3.5.
The offerer MAY include one or more other SRTP session parameters as The offerer MAY include one or more other SRTP session parameters as
defined in Section 5.3. Note however, that if any SRTP session defined in Section 6.3. Note however, that if any SRTP session
parameters are included that are not known to the answerer, but are parameters are included that are not known to the answerer, but are
nonetheless mandatory (see Section 5.3.6), the negotiation will fail nonetheless mandatory (see Section 6.3.6), the negotiation will fail
if the answerer does not support them. if the answerer does not support them.
6.1.2 Generating the Initial Answer - Unicast Streams 7.1.2 Generating the Initial Answer - Unicast Streams
When the initial answer is generated, the answerer MUST follow the When the initial answer is generated, the answerer MUST follow the
steps in Section 4.1.2 as well as the following steps. steps in Section 5.1.2 as well as the following steps.
For each unicast media line which uses the secure RTP transport and For each unicast media line which uses the secure RTP transport and
contains one or more "a=crypto" lines in the offer, the answerer contains one or more "a=crypto" lines in the offer, the answerer
MUST either accept one (and only one) of the crypto lines for that MUST either accept one (and only one) of the crypto lines for that
media stream, or it MUST reject the media stream. Only "a=crypto" media stream, or it MUST reject the media stream. Only "a=crypto"
lines that are considered valid SRTP security descriptions as lines that are considered valid SRTP security descriptions as
defined in Section 5 can be accepted. Furthermore, all parameters defined in Section 6 can be accepted. Furthermore, all parameters
(crypto-suite, key parameter, and mandatory session parameters) MUST (crypto-suite, key parameter, and mandatory session parameters) MUST
be acceptable to the answerer in order for the offered media stream be acceptable to the answerer in order for the offered media stream
to be accepted. Note that if the media stream includes Forward to be accepted. Note that if the media stream includes Forward
Error Correction with a different IP-address and/or port than the Error Correction with a different IP-address and/or port than the
media stream itself, a FEC_KEY parameter MUST be included, as media stream itself, a FEC_KEY parameter MUST be included, as
described in Section 5.3.5. described in Section 6.3.5.
When the answerer accepts an SRTP unicast media stream with a crypto When the answerer accepts an SRTP unicast media stream with a crypto
line, the answerer MUST include one or more master keys appropriate line, the answerer MUST include one or more master keys appropriate
for the selected crypto algorithm; the master key(s) included in the for the selected crypto algorithm; the master key(s) included in the
answer MUST be different from those in the offer. answer MUST be different from those in the offer.
When the master key(s) are not shared between the offerer and When the master key(s) are not shared between the offerer and
answerer, SSRC collisions between the offerer and answerer will not answerer, SSRC collisions between the offerer and answerer will not
lead to keystream reuse, and hence SSRC collisions do not lead to keystream reuse, and hence SSRC collisions do not
necessarily have to be prevented. necessarily have to be prevented.
If Forward Error Correction to a separate IP-address and/or port is If Forward Error Correction to a separate IP-address and/or port is
included, the answer MUST include a FEC_KEY parameter, as described included, the answer MUST include a FEC_KEY parameter, as described
in Section 5.3.5. in Section 6.3.5.
Declarative session parameters may be added to the answer as usual, Declarative session parameters may be added to the answer as usual,
however the answerer SHOULD NOT add any mandatory session parameter however the answerer SHOULD NOT add any mandatory session parameter
(see Section 5.3.6) that might be unknown to the offerer. (see Section 6.3.6) that might be unknown to the offerer.
If the answerer cannot find any valid crypto line that it supports, If the answerer cannot find any valid crypto line that it supports,
or if its configured policy prohibits any cryptographic key or if its configured policy prohibits any cryptographic key
parameter (e.g., key length) or cryptographic session parameter parameter (e.g., key length) or cryptographic session parameter
(e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it
is able to successfully negotiate use of SRTP by other means outside is able to successfully negotiate use of SRTP by other means outside
the scope of this document (e.g., by use of MIKEY [mikey]). the scope of this document (e.g., by use of MIKEY [mikey]).
6.1.3 Processing of the Initial Answer - Unicast Streams 7.1.3 Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, it MUST perform the steps in When the offerer receives the answer, it MUST perform the steps in
Section 4.1.3 as well as the following steps for each SRTP media Section 5.1.3 as well as the following steps for each SRTP media
stream it offered with one or more crypto lines in it. stream it offered with one or more crypto lines in it.
If the media stream was accepted and it contains a crypto line, it If the media stream was accepted and it contains a crypto line, it
MUST be checked that the crypto line is valid according to the MUST be checked that the crypto line is valid according to the
constraints specified in Section 5 (including any FEC constraints). constraints specified in Section 6 (including any FEC constraints).
If the offerer either does not support or is not willing to honor If the offerer either does not support or is not willing to honor
one or more of the SRTP parameters in the answer, the offerer MUST one or more of the SRTP parameters in the answer, the offerer MUST
consider the crypto line invalid. consider the crypto line invalid.
If the crypto line is not valid, or the offerer's configured policy If the crypto line is not valid, or the offerer's configured policy
prohibits any cryptographic key parameter (e.g. key length) or prohibits any cryptographic key parameter (e.g. key length) or
cryptographic session parameter, the SRTP security negotiation MUST cryptographic session parameter, the SRTP security negotiation MUST
be deemed to have failed. be deemed to have failed.
6.1.4 Modifying the Session 7.1.4 Modifying the Session
When a media stream using the SRTP security descriptions has been When a media stream using the SRTP security descriptions has been
established, and a new offer/answer exchange is performed, the established, and a new offer/answer exchange is performed, the
offerer and answerer MUST follow the steps in Section 4.1.4 as well offerer and answerer MUST follow the steps in Section 5.1.4 as well
as the following steps. as the following steps.
When modifying the session, all negotiated aspects of the SRTP media When modifying the session, all negotiated aspects of the SRTP media
stream can be modified. For example, a new crypto suite can be used stream can be modified. For example, a new crypto suite can be used
or a new master key can be established. As described in RFC 3264, or a new master key can be established. As described in RFC 3264,
when doing a new offer/answer exchange there will be a window of when doing a new offer/answer exchange there will be a window of
time, where the offerer and the answerer must be prepared to receive time, where the offerer and the answerer must be prepared to receive
media according to both the old and the new offer/answer exchange. media according to both the old and the new offer/answer exchange.
This requirement applies here as well, however the following should This requirement applies here as well, however the following should
be noted: be noted:
* When authentication is not being used, it may not be possible for * When authentication is not being used, it may not be possible for
either the offerer or the answerer to determine if a given packet either the offerer or the answerer to determine if a given packet
is encrypted according to the old or new offer/answer exchange. is encrypted according to the old or new offer/answer exchange.
RFC 3264 defines a couple of techniques to address this problem, RFC 3264 defines a couple of techniques to address this problem,
e.g., changing the payload types used and/or the transport e.g., changing the payload types used and/or the transport
addresses. Note however that a change in transport addresses may addresses. Note however that a change in transport addresses may
have an impact on Quality of Service as well as firewall and NAT have an impact on Quality of Service as well as firewall and NAT
skipping to change at page 24, line 8 skipping to change at page 24, line 17
* When authentication is not being used, it may not be possible for * When authentication is not being used, it may not be possible for
either the offerer or the answerer to determine if a given packet either the offerer or the answerer to determine if a given packet
is encrypted according to the old or new offer/answer exchange. is encrypted according to the old or new offer/answer exchange.
RFC 3264 defines a couple of techniques to address this problem, RFC 3264 defines a couple of techniques to address this problem,
e.g., changing the payload types used and/or the transport e.g., changing the payload types used and/or the transport
addresses. Note however that a change in transport addresses may addresses. Note however that a change in transport addresses may
have an impact on Quality of Service as well as firewall and NAT have an impact on Quality of Service as well as firewall and NAT
traversal. The SRTP security descriptions use the MKI to deal with traversal. The SRTP security descriptions use the MKI to deal with
this (which adds a few bytes to each SRTP packet) as described in this (which adds a few bytes to each SRTP packet) as described in
Section 5.1. For further details on the MKI, please refer to Section 6.1. For further details on the MKI, please refer to
[srtp]. [srtp].
* If the answerer changes its master key, the offerer will not * If the answerer changes its master key, the offerer will not
be able to process packets secured via this master key until the be able to process packets secured via this master key until the
answer is received. This could be addressed by using a security answer is received. This could be addressed by using a security
"precondition" [sprecon]. "precondition" [sprecon].
If the offerer includes an IP address and/or port that differs from If the offerer includes an IP address and/or port that differs from
that used previously for a media stream (or FEC stream), the offerer that used previously for a media stream (or FEC stream), the offerer
MUST include a new master key with the offer (and in so doing, it MUST include a new master key with the offer (and in so doing, it
skipping to change at page 24, line 43 skipping to change at page 24, line 52
offer/answer, and any key lifetime constraints will trivially be offer/answer, and any key lifetime constraints will trivially be
satisfied too. Another consideration here applies to media relays; satisfied too. Another consideration here applies to media relays;
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 7.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. The f8 example two lines in this document due to page formatting. The f8 example
shows two inline parameters; as explained in Section 5.1, there may shows two inline parameters; as explained in Section 6.1, there may
be one or more key (i.e. inline) parameters in a crypto attribute. 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 In this way, multiple keys are offered to support key rotation using
a master key index (MKI). 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
skipping to change at page 25, line 42 skipping to change at page 25, line 47
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. If F8_128_HMAC_SHA1_80 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 were selected by the answerer, there would be two inline keys
associated with the SRTP cryptographic context. One key has an MKI associated with the SRTP cryptographic context. One key has an MKI
value of 1 and the second has an MKI of 2. value of 1 and the second has an MKI of 2.
6.2 SRTP-Specific Use Outside Offer/Answer 7.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.
6.3 Support for SIP Forking 7.3 Support for SIP Forking
As mentioned earlier, the security descriptions defined here do not As mentioned earlier, the security descriptions defined here do not
support multicast media streams or multipoint unicast streams. support multicast media streams or multipoint unicast streams.
However, in the SIP protocol, it is possible to receive several However, in the SIP protocol, it is possible to receive several
answers to a single offer due to the use of forking (see [SIP]). answers to a single offer due to the use of forking (see [SIP]).
Receiving multiple answers leads to a couple of problems for the Receiving multiple answers leads to a couple of problems for the
SRTP security descriptions: SRTP security descriptions:
* Different answerers may choose different ciphers, keys, etc., * Different answerers may choose different ciphers, keys, etc.,
however there is no way for the offerer to associate a particular however there is no way for the offerer to associate a particular
skipping to change at page 26, line 34 skipping to change at page 26, line 36
from SIP forking into multiple two-party unicast cases. This is from SIP forking into multiple two-party unicast cases. This is
done as follows: done as follows:
For each answer received beyond the initial answer, issue a new For each answer received beyond the initial answer, issue a new
offer to that particular answerer using a new receive transport offer to that particular answerer using a new receive transport
address (IP address and port); note that this requires support for address (IP address and port); note that this requires support for
the SIP UPDATE method [RFC 3313]. Also, to ensure that two media the SIP UPDATE method [RFC 3313]. Also, to ensure that two media
sessions are not inadvertently established prior to the UPDATE being sessions are not inadvertently established prior to the UPDATE being
processed by one of them, use security preconditions [sprecon]. processed by one of them, use security preconditions [sprecon].
Finally, note that all the answerers will know the key(s) being Finally, note that all SIP User Agents that received the offer will
proposed by the initial offer. If the offerer wants to ensure know the key(s) being proposed by the initial offer. If the offerer
security with respect to other answerers, a new offer/answer wants to ensure security with respect to all other User Agents that
exchange with a new key needs to be performed with the first may have received the offer, a new offer/answer exchange with a new
answerer as well. key needs to be performed with the answerer as well. It should be
noted, that the offerer cannot determine whether a single or
multiple SIP User Agents received the offer, since intermediate
forking proxies may only forward a single answer to the offerer.
6.4 SRTP-Specific Backwards Compatibility Considerations 7.4 SRTP-Specific Backwards Compatibility Considerations
It is possible that the answerer supports the SRTP transport and It is possible that the answerer supports the SRTP transport and
accepts the offered media stream, yet it does not support the crypto accepts the offered media stream, yet it does not support the crypto
attribute defined here. The offerer can recognize this situation by attribute defined here. The offerer can recognize this situation by
seeing an accepted SRTP media stream in the answer that does not seeing an accepted SRTP media stream in the answer that does not
include a crypto line. In that case, the security negotiation include a crypto line. In that case, the security negotiation
defined here MUST be deemed to have failed. defined here MUST be deemed to have failed.
Also, if a media stream with a given SRTP transport (e.g., Also, if a media stream with a given SRTP transport (e.g.,
"RTP/SAVP") is sent to a device that does not support SRTP, that "RTP/SAVP") is sent to a device that does not support SRTP, that
media stream will be rejected. media stream will be rejected.
6.5 Operation with KEYMGT= and k= lines 7.5 Operation with KEYMGT= and k= lines
An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt].
Per SDP rules, the answerer will ignore attribute lines that it does Per SDP rules, the answerer will ignore attribute lines that it does
not understand. If the answerer supports both "a=crypto" and not understand. If the answerer supports both "a=crypto" and
"a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt" "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt"
but not both, as including both is undefined. but not both, as including both is undefined.
An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP
rules, the answerer will ignore attribute lines it does not rules, the answerer will ignore attribute lines it does not
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 8 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, 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.
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
skipping to change at page 27, line 54 skipping to change at page 28, line 9
en route. Such an "authentic" message, however, can be captured by en route. Such an "authentic" message, however, can be captured by
an attacker and "replayed" when the attacker re-inserts the packet an attacker and "replayed" when the attacker re-inserts the packet
into the channel. A replayed packet can have a variety of bad into the channel. A replayed packet can have a variety of bad
effects on the session, and SRTP uses the extended sequence number effects on the session, and SRTP uses the extended sequence number
to detect replayed SRTP packets [RFC3711]. to detect replayed SRTP packets [RFC3711].
The SRTP specification identifies which services and features are The SRTP specification identifies which services and features are
default values that are normative-to-implement (such as default values that are normative-to-implement (such as
AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32). AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32).
7.1 Authentication of packets 8.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 8.2 Keystream Reuse
SRTP security descriptions signal configuration parameters for SRTP SRTP security descriptions signal configuration parameters for SRTP
sessions. Misconfigured SRTP sessions are vulnerable to attacks on sessions. Misconfigured SRTP sessions are vulnerable to attacks on
their encryption services when running the crypto suites defined in their encryption services when running the crypto suites defined in
Sections 5.2.1, 5.2.2, and 5.2.3. An SRTP encryption service is Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is
"misconfigured" when two or more media streams are encrypted using "misconfigured" when two or more media streams are encrypted using
the same AES keystream. When senders and receivers share derived the same keystream of AES blocks. When senders and receivers share
session keys, SRTP requires that the SSRCs of session participants derived session keys, SRTP requires that the SSRCs of session
serve to make their corresponding keystreams unique, which is participants serve to make their corresponding keystreams unique,
violated in the case of SSRC collision: SRTP SSRC collision which is violated in the case of SSRC collision: SRTP SSRC collision
drastically weakens SRTP or SRTCP payload encryption during the time drastically weakens SRTP or SRTCP payload encryption during the time
that identical keystreams were used [srtp]. An attacker, for that identical keystreams were used [srtp]. An attacker, for
example, might collect SRTP and SRTCP messages and await a example, might collect SRTP and SRTCP messages and await a
collision. This attack on the AES-CM and AES-f8 encryption is collision. This attack on the AES-CM and AES-f8 encryption is
avoided entirely when each media stream has its own unique master avoided entirely when each media stream has its own unique master
key in both the send and receive direction. This specification key in both the send and receive direction. This specification
restricts use of SDP security description to unicast point-to-point restricts use of SDP security description to unicast point-to-point
streams so that keys are not shared between SRTP hosts, and the streams so that keys are not shared between SRTP hosts, and the
master keys used in the send and receive direction for a given media master keys used in the send and receive direction for a given media
stream are unique. stream are unique.
7.3 Signaling Authentication and Signaling Encryption 8.3 Signaling Authentication and Signaling Encryption
There is no reason to incur the complexity and computational expense There is no reason to incur the complexity and computational expense
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
skipping to change at page 29, line 24 skipping to change at page 29, line 29
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.
8. Grammar 9 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 9.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:
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param) *(1*WSP session-param)
tag = 1*9DIGIT tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_") crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param) key-params = key-param *(";" key-param)
key-param = key-method ":" key-info key-param = key-method ":" key-info
key-method = "inline" / key-method-ext key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_") key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = %x21-3A / %x3C-7E ; visible (printing) characters key-info = %x21-3A / %x3C-7E ; visible (printing) characters
; except semi-colon ; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters session-param = 1*(VCHAR) ; visible (printing) characters
where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234]. where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234].
8.2 SRTP "Crypto" Attribute Grammar 9.2 SRTP "Crypto" Attribute Grammar
This section provides an Augmented BNF [RFC2234] grammar for the This section provides an Augmented BNF [RFC2234] grammar for the
SRTP-specific use of the SDP crypto attribute: SRTP-specific use of the SDP crypto attribute:
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" /
skipping to change at page 30, line 23 skipping to change at page 30, line 28
srtp-crypto-suite-ext srtp-crypto-suite-ext
srtp-key-method= "inline" srtp-key-method= "inline"
srtp-key-info = key-salt ["|" lifetime] ["|" mki] 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 6.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.
srtp-session-param = kdr / srtp-session-param = kdr /
"UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" / "UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" / "UNAUTHENTICATED_SRTP" /
fec-order / fec-order /
fec-key / fec-key /
wsh / wsh /
srtp-session-extension srtp-session-extension
kdr = "KDR=" 1*2(DIGIT) ; range 0..24, power of two kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
fec-order = "FEC_ORDER=" fec-type fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC" fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params fec-key = "FEC_KEY=" key-params
wsh = "WSH=" 2*DIGIT ; minimum value is 64 wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "=" base64 = ALPHA / DIGIT / "+" / "/" / "="
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234]
; first character must not be dash ("-") ; first character must not be dash ("-")
9. IANA Considerations 10 IANA Considerations
10.1 Registration of the "crypto" attribute
9.1 Registration of the "crypto" attribute
The IANA is hereby requested to register a new SDP attribute as The IANA is hereby requested to register a new SDP attribute as
follows: follows:
Attribute name: crypto Attribute name: crypto
Long form name: Security description cryptographic attribute Long form name: Security description cryptographic attribute
for media streams for media streams
Type of attribute: Media-level Type of attribute: Media-level
Subject to charset: No Subject to charset: No
Purpose: Security descriptions Purpose: Security descriptions
Appropriate values: See Section 3 Appropriate values: See Section 4
9.2 New IANA Registries and Registration Procedures 10.2 New IANA Registries and Registration Procedures
The following sub-sections define a new IANA registry with associated The following sub-sections define a new IANA registry with associated
sub-registries to be used for the SDP security descriptions. The sub-registries to be used for the SDP security descriptions. The
IANA is hereby requested to create an SDP Security Description IANA is hereby requested to create an SDP Security Description
registry as shown below and further described in the following registry as shown below and further described in the following
sections: sections:
SDP Security Descriptions SDP Security Descriptions
| |
+- Key Methods (described in 9.2.1) +- Key Methods (described in 10.2.1)
| |
+- Media Stream Transports (described in 9.2.2) +- Media Stream Transports (described in 10.2.2)
| |
+- Transport1 (e.g. SRTP) +- Transport1 (e.g. SRTP)
| | | |
| +- Supported Key Methods (e.g. inline) | +- Supported Key Methods (e.g. inline)
| | | |
| +- crypto suites | +- crypto suites
| | | |
| +- session parameters | +- session parameters
| |
+- Transport2 +- Transport2
: : : :
9.2.1 Key Method Registry and Registration 10.2.1 Key Method Registry and Registration
The IANA is hereby requested to create a new subregistry for SDP The IANA is hereby requested to create a new subregistry for SDP
security description key methods. An IANA key method registration security description key methods. An IANA key method registration
MUST be documented in an RFC in accordance with the RFC 2434 MUST be documented in an RFC in accordance with the RFC 2434
Standards Action and it MUST provide the name of the key method in Standards Action and it MUST provide the name of the key method in
accordance with the grammar for key-method-ext defined in Section accordance with the grammar for key-method-ext defined in Section
8.1. 9.1.
9.2.2 Media Stream Transport Registry and Registration 10.2.2 Media Stream Transport Registry and Registration
The IANA is hereby requested to create a new subregistry for SDP The IANA is hereby requested to create a new subregistry for SDP
security description Media Stream Transports. An IANA media stream security description Media Stream Transports. An IANA media stream
transport registration MUST be documented in an RFC in accordance transport registration MUST be documented in an RFC in accordance
with the RFC 2434 Standards Action and the procedures defined in with the RFC 2434 Standards Action and the procedures defined in
Section 3 and 4 of this document. The registration MUST provide the Section 4 and 5 of this document. The registration MUST provide the
name of the transport and a list of supported key methods. name of the transport and a list of supported key methods.
In addition, each new media stream transport registry must contain a In addition, each new media stream transport registry must contain a
crypto-suite registry and a session parameter registry as well as crypto-suite registry and a session parameter registry as well as
IANA instructions for how to populate these registries. IANA instructions for how to populate these registries.
9.3 Initial Registrations 10.3 Initial Registrations
9.3.1 Key Method 10.3.1 Key Method
The following security descriptions key methods are hereby The following security descriptions key methods are hereby
registered: registered:
inline inline
9.3.2 SRTP Media Stream Transport 10.3.2 SRTP Media Stream Transport
The IANA is hereby requested to create an SDP Security Description The IANA is hereby requested to create an SDP Security Description
Media Stream Transport subregistry for "SRTP". The key methods Media Stream Transport subregistry for "SRTP". The key methods
supported is "inline". The reference for the SDP security supported is "inline". The reference for the SDP security
description for SRTP is this document. description for SRTP is this document.
9.3.2.1 SRTP Crypto Suite Registry and Registration 10.3.2.1 SRTP Crypto Suite Registry and Registration
The IANA is hereby requested to create a new subregistry for SRTP The IANA is hereby requested to create a new subregistry for SRTP
crypto suites under the SRTP transport of the SDP Security crypto suites under the SRTP transport of the SDP Security
Descriptions. An IANA SRTP crypto suite registration MUST indicate Descriptions. An IANA SRTP crypto suite registration MUST indicate
the crypto suite name in accordance with the grammar for srtp- the crypto suite name in accordance with the grammar for srtp-
crypto-suite-ext defined in Section 8.2. crypto-suite-ext defined in Section 9.2.
The semantics of the SRTP crypto suite MUST be described in an RFC The semantics of the SRTP crypto suite MUST be described in an RFC
in accordance with the RFC 2434 Standards Action, including the in accordance with the RFC 2434 Standards Action, including the
semantics of the "inline" key-method and any special semantics of semantics of the "inline" key-method and any special semantics of
parameters. parameters.
The following SRTP crypto suites are hereby registered: The following SRTP crypto suites are hereby registered:
AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32 AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80 F8_128_HMAC_SHA1_80
The reference for these crypto-suites is provided in this document. The reference for these crypto-suites is provided in this document.
9.3.2.2 SRTP Session Parameter Registration 10.3.2.2 SRTP Session Parameter Registration
The IANA is hereby requested to create a new subregistry for SRTP The IANA is hereby requested to create a new subregistry for SRTP
session parameters under the SRTP transport of the SDP Security session parameters under the SRTP transport of the SDP Security
Descriptions. An IANA SRTP session parameter registration MUST Descriptions. An IANA SRTP session parameter registration MUST
indicate the session parameter name (srtp-session-extension as indicate the session parameter name (srtp-session-extension as
defined in Section 8.2); the name MUST NOT begin with the dash defined in Section 9.2); the name MUST NOT begin with the dash
character ("-"). character ("-").
The semantics of the parameter MUST be described in an RFC in The semantics of the parameter MUST be described in an RFC in
accordance with the RFC 2434 Standards Action. If values can be accordance with the RFC 2434 Standards Action. If values can be
assigned to the parameter, then the format and possible values that assigned to the parameter, then the format and possible values that
can be assigned MUST be described in the RFC in accordance with the can be assigned MUST be described in the RFC in accordance with the
RFC 2434 Standards Action as well. Also, it MUST be specified RFC 2434 Standards Action as well. Also, it MUST be specified
whether the parameter is declarative or negotiated in the whether the parameter is declarative or negotiated in the
offer/answer model. offer/answer model.
skipping to change at page 33, line 27 skipping to change at page 33, line 34
KDR KDR
UNENCRYPTED_SRTP UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP UNENCRYPTED_SRTCP
UNAUTHENTICATED_SRTP UNAUTHENTICATED_SRTP
FEC_ORDER FEC_ORDER
FEC_KEY FEC_KEY
WSH WSH
The reference for these parameters is this document. The reference for these parameters is this document.
10. Acknowledgements 11 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. Mike Thomas, Brian Weis, and Magnus Westerlund.
11. Authors' Addresses 12 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
5510 SW Orchid Street 5510 SW Orchid Street
Portland, Oregon 97219 USA Portland, Oregon 97219 USA
mbaugher@cisco.com mbaugher@cisco.com
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
dwing@cisco.com dwing@cisco.com
12. Normative References 13 Normative References
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550,
STD 64, July 2003, http://www.ietf.org/rfc/rfc3550.txt. STD 64, July 2003, http://www.ietf.org/rfc/rfc3550.txt.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF," RFC 2234, November 1997, Specifications: ABNF," RFC 2234, November 1997,
http://www.ietf.org/rfc/rfc2234.txt. http://www.ietf.org/rfc/rfc2234.txt.
[SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
skipping to change at page 34, line 47 skipping to change at page 34, line 47
[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 [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security
Preconditions for Session Description Protocol Media Streams", work Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004. in progress, February 2004.
13. Informative References 14 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.
[GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group
skipping to change at page 36, line 24 skipping to change at page 36, line 24
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.
14. Full Copyright Statement 15 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). 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
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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