draft-ietf-mmusic-sdescriptions-02.txt   draft-ietf-mmusic-sdescriptions-03.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: April 2004 Cisco Systems EXPIRES: August 2004 Cisco Systems
October 24, 2003 February, 2004
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-02.txt> <draft-ietf-mmusic-sdescriptions-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines a Session Description Protocol (SDP) This document defines a Session Description Protocol (SDP)
cryptographic attribute for media streams. The attribute describes cryptographic attribute for unicast media streams. The attribute
a cryptographic key and other parameters, which serve to configure describes a cryptographic key and other parameters, which serve to
security for a media stream in either a single message or a configure security for a unicast media stream in either a single
roundtrip. The attribute can be used with a variety of SDP media message or a roundtrip exchange. The attribute can be used with a
transports and this document defines how to use it for the Secure variety of SDP media transports and this document defines how to use
Real-time Transport Protocol (SRTP) media streams. The SDP crypto it for the Secure Real-time Transport Protocol (SRTP) unicast media
attribute requires the services of a data security protocol to streams. The SDP crypto attribute requires the services of a data
secure the SDP message. security protocol to secure the SDP message.
Table of Contents Table of Contents
1. Notational Conventions............................................3 1. Notational Conventions............................................3
2. Introduction......................................................3 2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters.............................4 3. SDP "Crypto" Attribute and Parameters.............................5
3.1 Crypto-suite....................................................5 3.1 Tag.............................................................5
3.2 Key Parameters..................................................5 3.2 Crypto-suite....................................................5
3.3 Session Parameters..............................................6 3.3 Key Parameters..................................................6
3.4 Example.........................................................6 3.4 Session Parameters..............................................6
4. General Use of the crypto Attribute...............................6 3.5 Example.........................................................7
4.1 Use With Offer/Answer...........................................7 4. General Use of the crypto Attribute...............................7
4.1.1 Generating the Initial Offer..............................7 4.1 Use With Offer/Answer...........................................8
4.1.2 Generating the Initial Answer.............................8 4.1.1 Generating the Initial Offer - Unicast Streams............8
4.1.3 Offerer Processing of the Initial Answer..................9 4.1.2 Generating the Initial Answer - Unicast Streams...........9
4.1.3 Offerer Processing of the Initial Answer - Unicast Streams10
4.1.4 Modifying the Session....................................10 4.1.4 Modifying the Session....................................10
4.2 Use Outside Offer/Answer: Advertising..........................10 4.2 Use Outside Offer/Answer.......................................10
4.3 General Backwards Compatibility Considerations.................10 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions.......................................11 5. SRTP Security Descriptions.......................................11
5.1 SRTP Key Parameter.............................................12
5.2 Crypto-suites..................................................14 5.2 Crypto-suites..................................................14
5.2.1 AES_CM_128_HMAC_SHA1_80..................................14 5.2.1 AES_CM_128_HMAC_SHA1_80..................................15
5.2.2 AES_CM_128_HMAC_SHA1_32..................................14 5.2.2 AES_CM_128_HMAC_SHA1_32..................................15
5.2.3 F8_128_HMAC_SHA1_80......................................15 5.2.3 F8_128_HMAC_SHA1_80......................................16
5.2.4 Adding new Crypto-suite Definitions......................15 5.2.4 Adding new Crypto-suite Definitions......................16
5.3 Session Parameters.............................................15 5.3 Session Parameters.............................................16
5.3.1 SRC=SSRC/ROC/SEQ.........................................15 5.3.1 KDR=n....................................................16
5.3.2 KDR=n....................................................18 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................16
5.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................18 5.3.3 UNAUTHENTICATED_SRTP.....................................17
5.3.4 UNAUTHENTICATED_SRTP.....................................19 5.3.4 FEC_ORDER=order..........................................17
5.3.5 FEC_ORDER=order..........................................19 5.3.5 Window Size Hint (WSH)...................................17
5.3.6 Window Size Hint (WSH)...................................19 5.3.6 Defining New SRTP Session Parameters.....................18
5.3.7 SRTP Extension Session Parameters........................19 5.4 SRTP Crypto Context Initialization.............................18
6. SRTP-Specific Use of the crypto Attribute........................20 5.5 Removal of Crypto Contexts.....................................20
6.1 Use with Offer/Answer..........................................20 6. SRTP-Specific Use of the crypto Attribute........................21
6.1.1 Generating the Initial Offer.............................20 6.1 Use with Offer/Answer..........................................21
6.1.2 Generating the Initial Answer............................21 6.1.1 Generating the Initial Offer - Unicast Streams...........21
6.1.3 Offerer Processing of the Initial Answer.................22 6.1.2 Generating the Initial Answer - Unicast Streams..........21
6.1.4 Modifying the Session....................................23 6.1.3 Offerer Processing of the Initial Answer - Unicast Streams22
6.1.5 Offer/Answer Example.....................................24 6.1.4 Modifying the Session....................................22
6.2 SRTP-Specific Use Outside Offer/Answer: Advertising............25 6.1.5 Offer/Answer Example.....................................23
6.3 SRTP-Specific Backwards Compatibility Considerations...........25 6.2 SRTP-Specific Use Outside Offer/Answer.........................24
6.4 Operation with KEYMGT= and k= lines............................26 6.3 Support for SIP Forking........................................24
6.5 Removal of Crypto Contexts.....................................26 6.4 SRTP-Specific Backwards Compatibility Considerations...........25
6.5 Operation with KEYMGT= and k= lines............................25
7. Security Considerations..........................................26 7. Security Considerations..........................................26
7.1 Authentication of packets......................................27 7.1 Authentication of packets......................................26
7.2 Keystream Reuse................................................27 7.2 Keystream Reuse................................................26
7.3 Signaling Authentication and Signaling Encryption..............27 7.3 Signaling Authentication and Signaling Encryption..............26
8. Grammar..........................................................29 8. Grammar..........................................................28
8.1 Generic "Crypto" Attribute Grammar.............................29 8.1 Generic "Crypto" Attribute Grammar.............................28
8.2 SRTP "Crypto" Attribute Grammar................................29 8.2 SRTP "Crypto" Attribute Grammar................................28
9. Open Issues......................................................30 9. IANA Considerations..............................................29
10. IANA Considerations.............................................31 9.1 Registration of the "crypto" attribute.........................29
10.1 Registration of the "crypto" attribute........................31 9.2 New IANA Registries and Registration Procedures................29
10.2 New IANA Registries and Registration Procedures...............31 9.2.1 Security Descriptions Key Method Registry and Registration30
10.2.1 Security Descriptions Key Method Registry and Registration31 9.2.2 Security Description Media Stream Transport Registry and
10.2.2 SRTP Crypto Suite Registry and Registration..............31 Registration.....................................................30
10.2.3 SRTP Session Parameter Registration......................32 9.3 Initial Registrations..........................................30
10.3 Initial Registrations.........................................32 9.3.1 Key Method...............................................30
9.3.2 SRTP Media Stream Transport..............................31
11. Acknowledgements................................................32 10. Acknowledgements................................................32
12. Authors' Addresses..............................................33 11. Authors' Addresses..............................................32
13. Normative References............................................33 12. Normative References............................................32
14. Informative References..........................................34 13. Informative References..........................................33
Intellectual Property Statement.....................................35 Intellectual Property Statement.....................................35
Acknowledgement.....................................................36 Acknowledgement.....................................................36
1. Notational Conventions 1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [RFC2119]. The terminology in this be interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary". document conforms to [RFC2828], "Internet Security Glossary".
n^r is exponentiation where n is multiplied by itself r times; n and n^r is exponentiation where n is multiplied by itself r times; n and
r are integers. 0..k is an integer range of all integers from 0 r are integers. 0..k is an integer range of all integers from 0
through k inclusive. The abbreviation "iff" means "if and only if." through k inclusive.
Explanatory notes are provided in several places throughout the
document; these notes are indented two spaces from the surrounding
text.
2. Introduction 2. Introduction
The Session Description Protocol (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 sessions. 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
media streams. The Secure Real-time Transport Protocol (SRTP) those streams. The Secure Real-time Transport Protocol (SRTP)
[srtp] provides such security services and is signaled by use of the [srtp] provides security services for RTP media and is signaled by
"RTP/SAVP" transport in an SDP media (m=) line. However, there are use of secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an
no means within SDP itself to configure SRTP beyond using default SDP media (m=) line. However, there are no means within SDP itself
values. This document specifies a new SDP attribute called to configure SRTP beyond using default values. This document
"crypto", which is used to signal and negotiate cryptographic specifies a new SDP attribute called "crypto", which is used to
parameters for media streams in general, and SRTP in particular. signal and negotiate cryptographic parameters for media streams in
general, and SRTP in particular. The definition of the crypto
attribute in this document is limited to two-party unicast media
streams where each source has a unique cryptographic key; support
for multicast media streams or multipoint unicast streams is for
further study.
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 secure transports besides SRTP that need to signal and with secure transports besides SRTP that can establish cryptographic
negotiate cryptographic parameters, e.g. IPsec [ipsec], S/MIME parameters with only a single message or in a single round-trip
[s/mime], or TLS [tls], if and only if such parameters can either be exchange using the offer/answer model [RFC3264]. Extension to other
advertised in a single message, or negotiated in a single round-trip transports, however, is beyond the scope of this document. Each
by use of the offer/answer model [RFC3264]. Such extensions, type of secure SDP media transport needs its own specification for
however, are beyond the scope of this document. Each type of secure the crypto-attribute parameter. These definitions are frequently
SDP media transport needs its own specification for the crypto- unique to the particular type of transport and must be specified in
attribute parameter. These definitions are frequently unique to the an Internet RFC and registered with IANA according to the procedures
particular type of transport and MUST be specified in an Internet defined in Section 9. This document defines the security parameters
RFC and registered with IANA according to the procedures defined in and keying material for SRTP only.
Section 10. This document defines the security parameters and
keying material for SRTP only.
It would be self-defeating not to secure cryptographic keys and It would be self-defeating not to secure cryptographic keys and
other parameters at least as well as SRTP secures RTP packets or other parameters at least as well as the data is secured. Data
IPsec secures IP packets. Data security protocols such as SRTP rely security protocols such as SRTP rely upon a separate key management
upon a separate key management system to securely establish system to securely establish encryption and/or authentication keys.
encryption and/or authentication keys. Key management protocols Key management protocols provide authenticated key establishment
provide authenticated key establishment (AKE) procedures to (AKE) procedures to authenticate the identity of each endpoint and
authenticate the identity of each endpoint and protect against man- protect against man-in-the-middle, reflection/replay, connection
in-the-middle, reflection/replay, connection hijacking and some hijacking and some denial of service attacks [skeme]. Along with
denial of service attacks [skeme]. Along with the key, an AKE the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK
protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE [ike] [kink], IKE [ike] or TLS securely disseminates information
or TLS [tls] securely disseminates information describing both the describing both the key and the data-security session (for example,
key and the data-security session (for example, whether SRTCP whether SRTCP payloads are encrypted or unencrypted in an SRTP
payloads are encrypted or unencrypted in an SRTP session). AKE is session). AKE is needed because it is pointless to provide a key
needed because it is pointless to provide a key over a medium where over a medium where an attacker can snoop the key, alter the
an attacker can snoop the key, alter the definition of the key to definition of the key to render it useless, or change the parameters
render it useless, or change the parameters of the security session of the security session to gain unauthorized access to session-
to gain unauthorized access to session-related information. related information.
SDP, however, was not designed to provide AKE services, and the SDP, however, was not designed to provide AKE services, and the
media security descriptions that follow do not add AKE services to media security descriptions defined in this document do not add AKE
SDP. This specification is no replacement for a key management services to SDP. This specification is no replacement for a key
protocol or for the conveyance of key management messages in SDP management protocol or for the conveyance of key management messages
[keymgt]. The SDP security descriptions defined here are suitable in SDP [keymgt]. The SDP security descriptions defined here are
for restricted cases only where IPsec, TLS, or some other suitable for restricted cases only where IPsec, TLS, or some other
encapsulating data-security protocol (e.g. SIP secure multiparts) encapsulating data-security protocol (e.g., SIP secure multiparts)
protects the SDP message. This document adds security descriptions protects the SDP message. This document adds security descriptions
to those encrypted and/or authenticated SDP messages through the to those encrypted and/or authenticated SDP messages through the new
"crypto" attribute, which provides the cryptographic parameters of a SDP "crypto" attribute, which provides the cryptographic parameters
media stream. The "crypto" attribute can be adapted to any media of a media stream.
transport, but its precise definition is frequently unique to a
particular transport. In Section 3, we introduce the general SDP The "crypto" attribute can be adapted to any media transport, but
crypto attribute, and in Section 4 we define how it is used with and its precise definition is frequently unique to a particular
without the offer/answer model. In Section 5, we define the crypto transport.
attribute details needed for SRTP, and in Section 6 we define SRTP-
specific use of the attribute with and without the offer/answer In Section 3, we introduce the general SDP crypto attribute, and in
model. Section 7 recites security considerations, and Section 8 Section 4 we define how it is used with and without the offer/answer
gives an Augmented-BNF grammar for the general crypto attribute as model. In Section 5, we define the crypto attribute details needed
well as the SRTP-specific use of the crypto attribute. A list of for SRTP, and in Section 6 we define SRTP-specific use of the
open issues is provided in Section 9 and IANA considerations are attribute with and without the offer/answer model. Section 7
provided in Section 10. recites security considerations, and Section 8 gives an Augmented-
BNF grammar for the general crypto attribute as well as the SRTP-
specific use of the crypto attribute. IANA considerations are
provided in Section 9.
3. SDP "Crypto" Attribute and Parameters 3. 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 media line. The "crypto" attribute MUST only appear at preceding unicast media line. The "crypto" attribute MUST only
the SDP media level (not the session level). The "crypto" attribute appear at the SDP media level (not the session level). The "crypto"
follows the format (see Section 8.1 for a formal ABNF grammar): attribute follows the format (see Section 8.1 for the formal ABNF
grammar):
a=crypto:<crypto-suite> <key-params> *<session-params> a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
The fields crypto-suite, key-params, and session-param are described The fields tag, crypto-suite, key-params, and session-params are
in the following sub-sections. Below we show an example of the described in the following sub-sections. Below we show an example
crypto attribute for the "RTP/SAVP" transport, i.e. SRTP (newlines of the crypto attribute for the "RTP/SAVP" transport, i.e., the
secure RTP extension to the Audio/Video Profile [srtp] (newlines
included for formatting reasons only): included for formatting reasons only):
a=crypto: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
SRC=/721/13
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 line starting with "inline:", and there is a single session- by the text starting with "inline:", and session-params is omitted.
param named "SRC".
3.1 Crypto-suite 3.1 Tag
The tag is a decimal number (see Section 8.1 for details) used as an
identifier for a particular crypto attribute. The tag MUST be
unique among all crypto attributes for a given media stream. It is
used with the offer/answer model (see Section 4.1) to determine
which of several offered crypto attributes were chosen by the
answerer.
In the offer/answer model, the tag is a negotiated parameter.
3.2 Crypto-suite
The crypto-suite field is an identifier (see Section 8.1 for The crypto-suite field is an identifier (see Section 8.1 for
details) that describes the encryption and authentication algorithms details) that describes the encryption and authentication algorithms
(e.g. AES_CM_128_HMAC_SHA1_80) for the transport in question. The (e.g., AES_CM_128_HMAC_SHA1_80) for the transport in question. The
possible values for the crypto-suite parameter are defined within possible values for the crypto-suite parameter are defined within
the context of the transport, i.e. each transport defines a separate the context of the transport, i.e., each transport defines a
namespace for the set of crypto-suites. For example, the crypto- separate namespace for the set of crypto-suites. For example, the
suite "AES_CM_128_HMAC_SHA1_80" defined within the context of the crypto-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, however a separate definition would be reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a
needed. separate definition would be needed.
3.2 Key Parameters In the offer/answer model, the crypto-suite is a negotiated
parameter.
3.3 Key Parameters
The key-params field provides one or more sets of keying material The key-params field provides one or more sets of keying material
for the crypto-suite in question. The field consists of a method for 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 (a formal grammar is provided in Section 8.1): shown below (the formal grammar is provided in Section 8.1):
key-params = <key-method> ":" <key-info> key-params = <key-method> ":" <key-info>
Keying material may be provided by different means. One method is Keying material might be provided by different means than key-
defined in this document, namely "inline", which indicates that the params, however this is out of the scope of this document. Only one
keying material is provided in the key-info field itself. There is method is defined in this document, namely "inline", which indicates
a single name space for the key-method, i.e. the key-method is that the actual keying material is provided in the key-info field
transport independent. New key-methods (e.g. use of a URL) may be itself. There is a single name space for the key-method, i.e., the
defined in an IETF RFC in the future, in which case they may be used key-method is transport independent. New key-methods (e.g., use of
with any transport, provided the definitions for that transport a URL) may be defined in an IETF Standards Track RFC in the future.
support use of the new key-method. New key methods MUST be Although the key-method itself may be generic, the accompanying key-
registered with the IANA according to the procedures defined in info definition is specific not only to the key-method, but also to
Section 10.2.1. the transport in question. New key methods MUST be registered with
the IANA according to the procedures defined in Section 9.2.1.
Key-info is here just defined as a general character string (see Key-info is defined as a general character string (see Section 8.1
Section 8.1 for details); further transport and key-method specific for details); further transport and key-method specific syntax and
syntax and semantics MUST be provided in an IETF RFC for each semantics MUST be provided in an IETF RFC for each combination of
combination of transport and key-method that wants to use it; transport and key-method that wants to use it; definitions for SRTP
definitions for SRTP are provided in Section 5. Note that such are provided in Section 5. Note that such definitions are provided
definitions are provided within the context of both a particular within the context of both a particular transport (e.g., "RTP/SAVP")
transport (e.g. "RTP/SAVP") and a specific key-method (e.g. and a specific key-method (e.g., "inline"). IANA will register the
"inline"). 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 key is being used by a simple inspection possible to determine which of the keys is being used in a given
of the media packet received; a trial-and-error approach between the media packet by a simple inspection of the media packet received; a
possible keys MUST NOT be required. trial-and-error approach between the possible keys MUST NOT be
required.
For SRTP, this could for example be achieved by use of Master Key For SRTP, this could for example be achieved by use of Master Key
Identifiers (MKI), or <"From", "To"> values. Identifiers (MKI), or <"From", "To"> values [srtp].
3.3 Session Parameters In the offer/answer model, the key parameter is a declarative
parameter.
3.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 general framework, where they are just defined as is OPTIONAL in the general framework, where they are just defined as
a general character string. If session parameters are to be used a general character string. If session parameters are to be used
for a given transport, then key-method and transport-specific syntax for a given transport, then transport-specific syntax and semantics
and semantics MUST be provided in an IETF RFC for each transport MUST be provided in an IETF RFC; definitions for SRTP are provided
that wants to use it; definitions for SRTP are provided in Section in Section 5.
5. Note that such definitions are provided within the context of
both a specific key-method (e.g. "inline") and a particular
transport (e.g. "RTP/SAVP").
3.4 Example In the offer/answer model, session parameters may be either
negotiated or declarative; the definition of specific session
parameters MUST indicate whether they are negotiated or declarative.
Negotiated parameters apply to data sent in both directions, whereas
declarative parameters apply only to media sent by the entity that
generated the SDP. Thus, a declarative parameter in an offer
applies to media sent by the offerer, whereas a declarative
parameter in an answer applies to media sent by the answerer.
The first example shows use of the crypto attribute for the RTP/SAVP 3.5 Example
media transport type (as defined in Section 4). The a=crypto line
is actually one long line, although it is shown as two lines in this The first example shows use of the crypto attribute for the
document due to page formatting. "RTP/SAVP" media transport type (as defined in Section 4). The
"a=crypto" line is actually one long line; it is shown as two lines
due to page 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
t=2873397496 2873404696 t=2873397496 2873404696
m=video 51372 RTP/SAVP 31 m=video 51372 RTP/SAVP 31
a=crypto:AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
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: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 "RTP/SAVP" transport. Each has a crypto attribute for the
transport. These RTP/SAVP-specific descriptions are defined in the "RTP/SAVP" transport. These secure-RTP specific descriptions are
Section 5. defined in Section 5.
4. General Use of the crypto Attribute 4. 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 4.1 Use With Offer/Answer
In this section, we define the general rules for use of the crypto The general offer/answer rules for the crypto attribute are in
attribute with the offer/answer [RFC3264] model. These rules 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. unless otherwise noted. RFC 3264 defines operation for both unicast
and multicast streams; the sections below describe operation for
4.1.1 Generating the Initial Offer two-party unicast streams only, since support for multicast streams
(and multipoint unicast streams) is for further study.
4.1.1.1 Unicast Streams 4.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 one or more crypto attributes present for each media stream for
which security is desired. The ordering of multiple "a=crypto" which security is desired. Each crypto attribute for a given media
lines is significant: The most-preferred crypto line is listed stream MUST contain a unique tag.
first. Each crypto attribute describes the crypto-suite, key(s) and The ordering of multiple "a=crypto" lines is significant: The most
possibly session parameters offered for the media stream. In preferred crypto line is listed first. Each crypto attribute
general, a "more preferred" crypto suite SHOULD be stronger describes the crypto-suite, key(s) and possibly session parameters
cryptographically than a "less preferred" crypto suite. offered for the media stream. In general, a "more preferred"
crypto-suite SHOULD be cryptographically stronger than a "less
The crypto-suite always applies to media in all directions supported preferred" crypto-suite.
by the media stream (e.g. send and receive).
The key(s) apply to media in the direction from the offerer to the The crypto-suite always applies to media in the directions supported
answerer; if the media stream is marked as "recvonly", a key MUST by the media stream (e.g., send and receive). The key(s), however,
still be provided. apply to media in the direction from the offerer to the answerer; if
the media stream is marked as "recvonly", a key MUST still be
provided.
This is done for consistency. Also, in the case of for example This is done for consistency. Also, in the case of SRTP, for
SRTP, secure RTCP will still be flowing in both the send and example, secure RTCP will still be flowing in both the send and
receive direction for a unidirectional stream. receive direction for a unidirectional stream.
There are no general offer/answer rules for the session parameters; The offer may include session parameters. There are no general
instead, specific rules are provided as part of the transport and offer rules for the session parameters; instead, specific rules may
key-method specific definitions of any session parameters. be provided as part of the transport specific definitions of any
session parameters.
When issuing an offer, the offerer MUST be prepared to support media When issuing an offer, the offerer MUST be prepared to support media
security in accordance with any of the crypto attributes included in security in accordance with any of the crypto attributes included in
the offer. There are however two problems associated with this. the offer. There are however two problems associated with this.
First of all, the offerer does not know which key the answerer will First of all, the offerer does not know which key the answerer will
be using for media sent to the offerer; the answerer may or may not be using for media sent to the offerer. Since media may arrive
choose the same key as the offerer chose in his sending direction prior to the answer, delay or clipping can occur. If this is
(in fact, the answerer SHOULD NOT use the same key as explained in unacceptable to the offerer, the offerer SHOULD use a mechanism
Section 4.1.2.1). Since media may arrive prior to the answer, delay outside the scope of this document to prevent the above problem.
or clipping may occur. If this is unacceptable to the offerer, the
offerer SHOULD use a mechanism outside the scope of this document to
prevent the above problem.
For example, a "security" precondition [RFC3312] could be defined For example, in SIP [RFC3261], a "security" precondition as
to solve the above problem. defined in [sprecon] could solve the above problem.
Another problem can occur when the offerer includes multiple crypto Another problem can occur when the offerer includes multiple crypto
attributes, since the offerer may not be able to deduce which of the attributes: The offerer may not be able to deduce which of the
offered crypto attributes was accepted by the answerer until the offered crypto attributes was accepted by the answerer until the
answer is received, yet media may arrive before the answer. answer is received, yet media may arrive before the answer.
If this is unacceptable to the offerer, the offerer either SHOULD If this is unacceptable to the offerer, the offerer either SHOULD
NOT include multiple crypto attributes in the offer, or a mechanism NOT include multiple crypto attributes in the offer, or a mechanism
outside the scope of this document SHOULD be used to prevent the outside the scope of this document SHOULD be used to prevent the
above problem (e.g. a "security" precondition). above problem (e.g., a "security" precondition).
4.1.1.2 Multicast Streams
The rules for multicast streams are similar to those for unicast
streams, except as noted below:
* In order to ensure that all participants use the same crypto
parameters, there MUST be exactly one crypto attribute per media
stream.
* The key(s) provided apply to media in all directions supported by
the media stream, as opposed to just the sending direction.
4.1.2 Generating the Initial Answer
4.1.2.1 Unicast Streams 4.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 attributes for a given unicast media stream, the answerer MUST
either accept exactly one of the offered crypto attributes, or the either accept exactly one of the offered crypto attributes, or the
offered stream MUST be rejected. offered 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 attributes, those can be listed by use of the SDP Simple
Capability Declaration [RFC3407] extensions. Capability Declaration [RFC3407] extensions.
Only crypto attributes that are valid, i.e. do not violate any of Only crypto attributes that are valid can be accepted; valid
general rules defined for security descriptions as well as any attributes do not violate any of the general rules defined for
specific rules defined for the transport and key method in question security descriptions as well as any specific rules defined for the
can be accepted. When selecting one of the valid crypto attributes, transport and key-method in question. When selecting one of the
the answerer SHOULD select the most preferred crypto attribute it valid crypto attributes, the answerer SHOULD select the most
can support, i.e. the first valid supported crypto attribute in the preferred crypto attribute it can support, i.e., the first valid
list, considering the answerer's capabilities and security policies. supported crypto attribute in the list, considering the answerer's
capabilities and security policies.
If there is one or more crypto attributes in the offer, but none of If there are one or more crypto attributes in the offer, but none of
them are valid, or none of the valid ones are supported, the offered them are valid, or none of the valid ones are supported, the offered
media stream MUST be rejected. media stream MUST be rejected.
The crypto attribute in the answer MUST contain the following: When an offered crypto attribute is accepted, the crypto attribute
in the answer MUST contain the following:
* The crypto-suite from the accepted crypto attribute in the offer * The tag and crypto-suite from the accepted crypto attribute in the
(the same crypto-suite must be used in the send and receive offer (the same crypto-suite MUST be used in the send and receive
direction). direction).
* The key(s) the answerer will be using for media sent to the * The key(s) the answerer will be using for media sent to the
offerer. offerer. Note that a key MUST be provided, irrespective of any
direction attributes in the offer or answer.
There are no general offer/answer rules for the session parameters; Furthermore, any session parameters that are negotiated MUST be
instead, specific rules are provided as part of the transport and included in the answer. Declarative session parameters provided by
key-method specific definitions of any session parameters. the offerer are not included in the answer, however the answerer may
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.2.2 Multicast Streams 4.1.3 Offerer Processing of the Initial Answer - Unicast Streams
The rules for multicast streams are similar to those for unicast
streams, except as noted below:
* The crypto-suite in the answer MUST be the same as the one in the
offer (unless the offered media stream is rejected). Since no
more than one crypto attribute can be offered for a multicast
stream, this is satisfied trivially.
* The key(s) provided apply to media in all directions supported by
the media stream, as opposed to just the sending direction.
Consequently, the key(s) in the answer MUST be the same as the
key(s) in the offer.
4.1.3 Offerer Processing of the Initial Answer
4.1.3.1 Unicast Streams
When the offerer receives the answer, the offerer MUST verify, that When the offerer receives the answer, the offerer MUST verify, that
exactly one of the offered crypto attributes was accepted. one of the initially offered crypto suites and its accompanying tag
Otherwise, the offerer MUST consider the offer/answer negotiation to was accepted and echoed in the answer. Also, the answer MUST
have failed for that stream. include one or more keys, which will be used for media sent from the
answerer to the offerer.
The key(s) included in the answer are the key(s) that will be used
for media sent from the answerer to the offerer and hence the
offerer MUST use those key(s) to process media received; the key(s)
might not be the same as the key(s) used by the offerer for sending
media to the answerer.
There are no general offer/answer rules for the session parameters;
instead, specific rules are provided as part of the transport and
key-method specific definitions of any session parameters.
4.1.3.2 Multicast Streams
When the offerer receives the answer, the offerer MUST verify, that If the offer contained any mandatory negotiated session parameters
the offered crypto attribute and key(s) were accepted and echoed in (see section 5.3.6), the offerer MUST verify that said parameters
the answer. Otherwise, the offerer MUST consider the offer/answer are included in the answer. If the answer contains any mandatory
negotiation to have failed for that stream for *that answerer* and declarative session parameters, the offerer MUST be able to support
hence the answerer is not considered a participant in that media those.
stream. If there are other participants in the multimedia session,
the session may continue unaffected by this particular answerer's
failure.
There are no general offer/answer rules for the session parameters; If any of the above fails, the negotiation MUST be deemed to have
instead, specific rules are provided as part of the transport and failed.
key-method specific definitions of any session parameters.
4.1.4 Modifying the Session 4.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
keying or change the crypto-suite. If media stream security using re-keying or change the crypto-suite. If media stream security
the general security descriptions defined is still desired, the using the general security descriptions defined here is still
crypto attribute MUST be included in these new offer/answer desired, the crypto attribute MUST be included in these new
exchanges. The procedures are similar to those defined in Section offer/answer exchanges. The procedures are similar to those defined
4.1.1, 4.1.2, 4.1.3 subject to the considerations provided in RFC in Section 4.1.1, 4.1.2, 4.1.3 of this document, subject to the
3264 Section 8. considerations provided in RFC 3264 Section 8.
4.2 Use Outside Offer/Answer: Advertising 4.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. For example, when using the Session Announcement offer/answer where there is no negotiation of the crypto suite,
Protocol (SAP) [RFC2974], there is no negotiation of the media cryptographic key or session parameters. In this case, the sender
streams described by the SDP; instead media streams are simply determines security parameters for the stream. Since there is no
advertised. negotiation mechanisms, the sender MUST include exactly one crypto
attribute and the receiver MUST either accept it or else SHOULD NOT
The crypto attribute defined here can be used in such environments receive the associated stream. The sender SHOULD select the
where the crypto parameters are advertised in a single message security description that it deems most secure for its purposes.
rather than being negotiated in a roundtrip (an offer and an
answer), albeit with certain restrictions:
* There MUST be exactly one crypto attribute.
There are no general rules for the session parameters; instead,
specific rules for advertising session parameters are provided as
part of the transport and key-method specific definitions of any
session parameters.
4.3 General Backwards Compatibility Considerations 4.3 General Backwards Compatibility Considerations
It is possible that the answerer supports a given secure transport
and accepts the offered media stream, yet the answerer does not In the offer/answer model, it is possible that the answerer supports
support the crypto attribute defined here. The offerer can a given secure transport (e.g., "RTP/SAVP") and accepts the offered
media stream, yet the answerer does not support the crypto attribute
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 be deemed to have failed. security negotiation defined here MUST be deemed to have failed.
Similar issues exist when security descriptions are used outside of
the offer/answer model.
5. SRTP Security Descriptions 5. SRTP Security Descriptions
In this section, we provide definitions for security descriptions In this section, we provide definitions for security descriptions
for SRTP media streams. In the next Section, we define how to use for SRTP media streams. In the next section, we define how to use
SRTP security descriptions with and without the offer/answer model. SRTP security descriptions with and without the offer/answer model.
SRTP security descriptions for a media stream MUST only be used for SRTP security descriptions for a media stream MUST only be used for
media streams that use the "RTP/SAVP" transport in the media (m=) media streams that use the SRTP transport (e.g., "RTP/SAVP" or
line and SHALL apply to that media stream only. "RTP/SAVPF") in the media (m=) line and SHALL apply to that media
stream only. The following specifies rules for the "RTP/SAVP"
profile defined in [srtp], however it is expected that other secure
RTP profiles (e.g., "RTP/SAVPF") can use the same rules.
There is no assurance that an endpoint is capable of configuring its There is no assurance that an endpoint is capable of configuring its
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 (per [SDPnew]) and hence, if it supports SRTP, it will ignore it according to the SDP. Hence the endpoint will simply
simply assume use of default SRTP parameters. Such an endpoint will assume use of default SRTP parameters, if it supports SRTP. Such an
not correctly process the particular media stream. By using the endpoint will not correctly process the particular media stream. By
Offer/Answer model, the offerer and answerer can negotiate the using the Offer/Answer model, the offerer and answerer can negotiate
crypto parameters to be used before commencement of the multimedia the crypto parameters to be used before commencement of the
session (see Section 6.1). multimedia session (see Section 6.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, moreover, there is usually no need to provide unique establishment, moreover, 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
security description parameters as follows: security description parameters as follows:
* crypto-suite: Identifies the encryption and authentication * crypto-suite: Identifies the encryption and authentication
transforms transforms
* key parameter: SRTP keying material and parameters * key parameter: SRTP keying material and parameters
* session parameters: The following parameters are defined: * session parameters: The following parameters are defined:
- SRC: An <SSRC, ROC, SEQ> triple
- KDR: The SRTP Key Derivation Rate is the rate that a - KDR: The SRTP Key Derivation Rate is the rate that a
pseudo-random function is applied to a master key pseudo-random function is applied to a master key
- UNENCRYPTED_SRTP: SRTP messages are not encrypted - UNENCRYPTED_SRTP: SRTP messages are not encrypted
- UNENCRYPTED_SRTCP: SRTCP messages are not encrypted - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted
- UNAUTHENTICATED_SRTP: SRTP messages are not authenticated - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated
- FEC_ORDER: Order of forward error correction (FEC) - FEC_ORDER: Order of forward error correction (FEC)
relative to SRTP services relative to SRTP services
- WSH: Window Size Hint - WSH: Window Size Hint
- Extensions: Extension parameters can be defined - Extensions: Extension parameters can be defined
Please refer to the SRTP specification for a complete list of Please refer to the SRTP specification for a complete list of
parameters and their descriptions [Section 8.2, srtp]. The key parameters and their descriptions [Section 8.2, srtp]. The key
parameter, the crypto-suite, and the session parameters shown above parameter, the crypto-suite, and the session parameters shown above
are described in detail in the following sections. are described in detail in the following subsections.
5.1.1.1 SRTP Key Parameter 5.1 SRTP Key Parameter
SRTP security descriptions define use of the "inline" key method as SRTP security descriptions define use of the "inline" key method as
described in the following. Use of any other keying method for SRTP described in the following. Use of any other keying method, e.g.,
security descriptions is for further study. URL, for SRTP security descriptions is for further study.
The "inline" type of key contains the keying material and all policy The "inline" type of key contains the keying material (master key
relating to that key, including how long it can be used (lifetime) and salt) and all policy related to that master key, including how
and whether or not it uses a master key identifier (MKI) to long it can be used (lifetime) and whether or not it uses a master
associate an incoming SRTP packet with a particular master key. key identifier (MKI) to associate an incoming SRTP packet with a
Compliant implementations obey the policies associated with a master particular master key. Compliant implementations obey the policies
key, and MUST NOT accept incoming packets that violate the policy associated with a master key, and MUST NOT accept incoming packets
(e.g. after the key lifetime has expired). that violate the policy (e.g., after the master key lifetime has
expired).
The key parameter contains a semi-colon separated list of The key parameter contains one or more cryptographic master keys,
cryptographic master keys, each of which MUST be a unique each of which MUST be a unique cryptographically random [RFC1750]
cryptographically random [RFC1750] value with respect to other value with respect to other master keys in the entire SDP message
master keys in the entire SDP message (i.e. including master keys (i.e., including master keys for other streams). Each key follows
for other streams). Each key in the list follows the format (a the format (the formal definition is provided in Section 8.2):
formal definition is provided in Section 8.2):
"inline:" <key salt> "|" [<lifetime] "|" [MKI:length / FromTo] "inline:" <key||salt> "|" [lifetime] "|" [MKI ":" length / FromTo]
key||salt concatenated key and salt, base64 encoded key||salt concatenated master key and salt, base64 encoded
lifetime key lifetime (number of packets) (see [RFC3548], Section 3)
MKI:length MKI and length of the MKI field in SRTP packets. lifetime master key lifetime (max number of SRTP or SRTCP
packets using this master key)
MKI:length MKI and length of the MKI field in SRTP packets
FromTo <"From", "To"> values, specifying the lifetime for FromTo <"From", "To"> values, specifying the lifetime for
a master key. a master key
The following definition provides an example for The following definition provides an example for
AES_CM_128_HMAC_SHA1_80: AES_CM_128_HMAC_SHA1_80:
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the
parameter is the cryptographic master key appended with the master parameter is the cryptographic master key appended with the master
salt; the two are first concatenated and then base64 encoded. The salt; the two are first concatenated and then base64 encoded. The
length of the concatenated key and salt is determined by the crypto- length of the concatenated key and salt is determined by the crypto-
suite for which the key applies. If the length (after being decoded suite for which the key applies. If the length (after being decoded
from base64) does not match that specified for the crypto-suite, the from base64) does not match that specified for the crypto-suite, the
entire crypto attribute MUST be considered invalid and an "invalid crypto attribute in question MUST be considered invalid. Each
key/salt" condition SHOULD be logged. Each master key and salt MUST master key and salt MUST be a cryptographically random number and
be a cryptographically random number and MUST be unique to the SDP MUST be unique to the entire SDP message. When base64 decoding the
message. key and salt, padding characters (i.e., one or two "=" at the end of
the base64 encoded data) are discarded (see [RFC3548] for details).
Base64 encoding assumes that the base64 encoding input is an
integral number of octets. If a given crypto-suite requires the use
of a concatenated key and salt with a length that is not an integral
number of octets, said crypto-suite MUST define a padding scheme
that results in the base64 input being an integral number of octets.
For 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
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 total number of packets using that key. The measured in maximum number of SRTP or SRTCP packets using that
lifetime value MAY be written as a non-zero, positive integer or as master key (i.e., the number of SRTP packets and the number of SRTCP
a power of 2 (see the grammar in Section 8.2 for details). The packets each have to be less than the lifetime). The lifetime value
"lifetime" value MUST NOT exceed the maximum packet lifetime for the MAY be written as a non-zero, positive integer or as a power of 2
crypto-suite. If the lifetime is too large or otherwise invalid (see the grammar in Section 8.2 for details). The "lifetime" value
then the entire crypto attribute MUST be considered invalid and an MUST NOT exceed the maximum packet lifetime for the crypto-suite.
"invalid lifetime" condition SHOULD be logged. The default MAY be If the lifetime is too large or otherwise invalid then the entire
implicitly signaled by omitting the lifetime value (i.e. "||"). crypto attribute MUST be considered invalid. The default MAY be
implicitly signaled by omitting the lifetime value (i.e., "||").
This is convenient when the SRTP cryptographic key lifetime is the This is convenient when the SRTP cryptographic key lifetime is the
default value. As a shortcut to avoid long decimal values, the default value. As a shortcut to avoid long decimal values, the
syntax of the lifetime allows using the literal "2^", which syntax of the lifetime allows using the literal "2^", which
indicates "two to the power of". The example above, shows a case indicates "two to the power of". The example above, shows a case
where the lifetime is specified as 2^20. The following example, where the lifetime is specified as 2^20. The following example,
which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default
for the lifetime field, which means the SRTP's and SRTCP's default for the lifetime field, which means that SRTP's and SRTCP's default
values will be used (2^31): values will be 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 either the Master Key The third field, which is also OPTIONAL, is either the Master Key
Identifier (MKI) and its byte length, or a <"From", "To"> value. Identifier (MKI) and its byte length, or a <"From", "To"> value.
"MKI" is the master key identifier associated with the SRTP master "MKI" is the master key identifier associated with the SRTP master
key. If the MKI is given, then the length of the MKI MUST also be key. If the MKI is given, then the length of the MKI MUST also be
given and separated from the MKI by a colon (":"). The MKI length given and separated from the MKI by a colon (":"). The MKI length
is the size of the MKI field in the SRTP packet, specified in bytes. is the size of the MKI field in the SRTP packet, specified in bytes.
If the MKI length is not given or if it exceeds 128 (bytes), then If the MKI length is not given or its value exceeds 128 (bytes),
the entire crypto attribute MUST be considered invalid and an then the entire crypto attribute MUST be considered invalid. The
"invalid MKI length" condition SHOULD be logged. The substring substring "1:4" in the first example assigns to the key a master key
"1:4" in the first example assigns to the key a master key
identifier of 1 that is 4 bytes long, and the second example assigns identifier of 1 that is 4 bytes long, and the second example assigns
a 4-byte key identifier of 1066 to the key. a 4-byte master key identifier of 1066 to the key.
<"From", "To"> specifies the lifetime for a master key, expressed in <"From", "To"> specifies the lifetime for a master key, expressed in
terms of the ROC and SEQ values inside whose range (including the terms of the ROC and SEQ values inside whose range (including the
range end-points) the master key is valid. <"From", "To"> is an range ends) the master key is valid. <"From", "To"> is an
alternative to the MKI and assumes that a master key is in one-to- alternative to the MKI and assumes that a master key is in one-to-
one correspondence with the SRTP session key on which the <"From", one correspondence with the SRTP session key on which the <"From",
"To"> range is defined. The following example illustrates the use "To"> range is defined (see [srtp, Section 8.1.1] for details). The
of the <"From", "To"> parameter: following example illustrates the use of the <"From", "To">
parameter:
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|FT=0:0,1:0 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|FT=0:0,1:0
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 MUST either include an MKI or a <"From", "To"> of the master keys in that key parameter MUST either include an MKI
value. Note that it is not permissible to mix and match use of the or a <"From", "To"> value. Note that it is not permissible to mix
two within a single key parameter (i.e., one crypto attribute); all the two within a single key parameter (i.e., one crypto attribute);
master keys in a given key parameter must use one or the other. all master keys in a given key parameter must use one or the other
(or neither). Furthermore, when using the MKI, the MKI length MUST
be the same for all keys in a given crypto attribute.
5.2 Crypto-suites 5.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 below are specification has defined three crypto-suites, which are described
described in the context of the SRTP security descriptions. further in the following subsections in the context of the SRTP
security descriptions. The table below provides an overview of the
crypto-suites and their parameters:
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Salt value | 112 bits | 112 bits | 112 bits |
| Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | F8 |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| Authentication tag | 80 bits | 32 bits | 80 bits |
| SRTP 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 5.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 [srtp]. The SRTP and SRTCP encryption key lengths are 128 first [Page 39, srtp].
bits. The SRTP and SRTCP authentication key lengths are 160 bits
(see Security Considerations in Section 7). The master salt value Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets,
is 112 bits in length and the session salt value is 112 bits in whichever comes first. SRTP security descriptions, however,
length. The pseudo-random function (PRF) is the default SRTP simplify the parameters to share a single upper bound of 2^31
pseudo-random function that uses AES Counter Mode with a 128-bit key packets. It is RECOMMENDED that automated key management allow
length. easy and efficient rekeying at intervals far smaller than 2^31
packets given today's media rates or even HDTV media rates.
The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP
and SRTCP authentication key lengths are 160 bits (see Security
Considerations in Section 7). The master salt value is 112 bits in
length and the session salt value is 112 bits in length. The
pseudo-random function (PRF) is the default SRTP pseudo-random
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 5.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 SRTP authentication key is 32 bits and the SRTCP that the authentication tag is 32 bits.
authentication key is 80 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 5.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 5.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 an IETF RFC. Sections 5.2.1 through 5.2.3 illustrate published in an IETF RFC. Sections 5.2.1 through 5.2.3 illustrate
how to define crypto-suite values for particular cryptographic how to define crypto-suite values for particular cryptographic
transforms. Any new crypto suites MUST be registered with IANA transforms. Any new crypto-suites MUST be registered with IANA
following the guidelines in section 10. following the procedures in section 9.
5.3 Session Parameters 5.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 and are described in the following. session for SRTP services. The session parameters provide session-
specific information to establish the SRTP cryptographic context.
5.3.1 SRC=SSRC/ROC/SEQ
The SRTP cryptographic context for a given SRTP session is
identified by the synchronization source (SSRC). Furthermore,
associated with a cryptographic context is the SRTP packet index
which is derived from the RTP sequence number (SEQ) and a rollover
counter (ROC). The SSRC and SEQ are included in the SRTP packets,
however they are not included in standard SDP (for various reasons).
The ROC is neither included in the SRTP packets nor standard SDP but
is instead derived algorithmically based on the total number of
packets sent. This presents a couple of challenges:
* If the master key is shared between two or more session
participants, SSRC collisions MUST be avoided; SSRC collision
detection and resolution is not an acceptable alternative as this
can lead to the two-time pad problem [srtp].
* If a participant joins an ongoing session (where the ROC is non-
zero), the participant needs to learn the ROC somehow.
* If the initial sequence number is close to the maximum sequence
number and the initial SRTP packets are lost, the receiver may not
update his ROC correctly.
* When joining a multicast RTP session with multiple participants, a
separate crypto context needs to be established for each
participant (SSRC). Even if the same master key is used by all
participants, the ROC for each still needs to be learned somehow.
The SRC session parameter provides information to establish the SRTP
cryptographic context. It contains information about one or more of
the following:
* SSRC: Synchronization source
* ROC: Roll-over counter
* SEQ: Sequence number
The ROC and sequence number are typically only needed for sessions
already in progress (as when rekeying or when joining a multicast
session).
Zero or more SRC parameters MAY appear in a crypto attribute. When
more than one SRC parameter is present, each of them MUST contain a
distinct SSRC value. Each SRC parameter defines a separate SRTP
crypto context (see section 3.2 of [srtp]) that SHALL share the
master key and salt defined by one or more inline key parameters.
The total number of all packets that are encrypted by keys derived
from this master key MUST NOT exceed the lifetime of the inline key.
The SRTP crypto contexts so defined SHALL also have a common
definition for the crypto-suite and all other crypto parameters.
SSRC is the RTP SSRC that is associated with the crypto context, and
is an integer in the range of 0..2^32-1. If an SSRC value is
invalid, the entire crypto attribute line MUST be considered invalid
and an "invalid SSRC" condition SHOULD be logged. If an SSRC value
collides with an SSRC for an existing participant in the session,
the entire crypto attribute line MUST be considered invalid and an
"SSRC collision" condition SHOULD be logged.
OPEN ISSUE: It would be nice to have a way of indicating this
condition in an answer SDP, but we quickly end up duplicating the
RTP collision detection and resolution, which we don't want to.
ROC is the SRTP rollover counter (ROC) in the range of 0..2^32-1 and
is zero by default. Typically the ROC value is specified as a non-
zero value for an ongoing SRTP stream in which the ROC has cycled
one or more times [srtp]. The receiver of the SDP message SHOULD
refresh the ROC value before joining an ongoing session. Depending
on the nature of the session control, the late-joining receiver
might need to refresh its ROC value through a unicast exchange or
through receipt of a multicast or unicast message containing a ROC
SRTP description. If the ROC is greater than 2^32-1, then the
entire crypto attribute line MUST be considered invalid and an
"invalid ROC" condition SHOULD be logged.
SEQ is the SRTP sequence number (SEQ), which MUST be in the range of
0..2^16-1. SRTP uses the RTP sequence number and the ROC to compute
the packet index [srtp]. For this reason, the initial SEQ SHOULD be
in the range of 0..2^15-1 to avoid an ambiguity when packets are
lost at the start of the session. At the start of a session, an
SSRC source that randomly selects a high sequence-number value can
put the receiver in an ambiguous situation: If initial packets are
lost in transit up to the point that the sequence number wraps
(exceeds 2^16-1), then the receiver might not recognize that its ROC
needs to be incremented. By restricting the initial SEQ to the
range of 0..2^15-1, SRTP packet-index determination will find the
correct ROC value, unless all of the first 2^15 packets are lost
(which seems, if not impossible, then rather unlikely). See Section
3.3.1 of the SRTP specification regarding packet-index determination
[srtp].
It is not necessary to signal SEQ and ROC at the start of the SRTP
session if the receivers do not join the session late, which is
typical in IP telephony, multimedia client/server, and similar
applications. Large-scale multicast applications, however, will
sometimes have late joiners to the session and MAY choose to use the
SRC session parameter to set the SEQ and the ROC. The SSRC MAY also
be initialized in the SRC parameter; this can for example be useful
to establish the crypto contexts (in particular the ROC) for all the
session participants.
Like SEQ and ROC, SSRC is OPTIONAL (unless there are multiple SRC
parameters in which case it is mandatory) and often need not be
signaled. If the master key is not shared among senders for their
encryption services, then SSRC uniqueness is NOT REQUIRED (see
Section 7.2) and the SSRC need not be signaled. In this way, each
master key is used for encryption by exactly one sender and used for
decryption by one or more receivers: In this case, there is no risk
of keystream reuse for the crypto-suite ciphers of Section 5.2.1,
5.2.2, and 5.2.3.
The SRTP crypto context can be established for the SRTP session
address in the connection (c=) line and the port in the media (m=)
line (or rtpmap) without having specified an SSRC value in the SRTP
security descriptions. This is called "late binding" by this
specification. If late binding is used, then when a packet arrives,
the SSRC that is contained in it can be bound to the crypto context
at the time of session commencement rather than at the time of
session signaling. With the arrival of the packet containing the
SSRC, all the data items (except the ROC if it is non-zero) needed
for the SRTP crypto context are held by the receiver. In other
words, the crypto context for an RTP/SAVP session using late binding
is initially identified by the SDP as:
<*, address, port>
where '*' is a wildcard SSRC, "address" is from the "c=" line, and
"port" is from the "m=" line. When the first packet arrives with
ssrcX in its SSRC field, the crypto context
<ssrcX, address, port>
is instantiated subject to the following constraints:
* Media packets are authenticated: Authentication MUST succeed;
otherwise, the crypto context is not instantiated.
* Media packets are not authenticated: Crypto context is
automatically instantiated.
It should be noted, that use of late binding when there is no
authentication of the SRTP media packets is subject to numerous
security attacks and consequently it is NOT RECOMMENDED (of course,
this can be said for unauthenticated SRTP in general). Endpoints
that do not wish to subject themselves to such security risks can
either signal the SSRC by out-of-band mechanisms (as defined here),
or ensure that only authenticated SRTP is being used.
5.3.2 KDR=n 5.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 {0,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^0 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 [srtp]. The default value is 0, which from an SRTP master key [srtp]. When the key derivation rate is not
causes the key derivation function to be invoked exactly once (since specified (i.e., the KDR parameter is omitted), a single initial key
2^0 is 1). derivation is performed [srtp].
5.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP In the offer/answer model, KDR is a declarative parameter.
5.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.
5.3.4 UNAUTHENTICATED_SRTP In the offer/answer model, these parameters are negotiated.
5.3.3 UNAUTHENTICATED_SRTP
SRTP and SRTCP packet payloads are authenticated by default. The SRTP and SRTCP packet payloads are authenticated by default. The
UNAUTHENTICATED_SRTP session parameter signals that SRTP messages UNAUTHENTICATED_SRTP session parameter signals that SRTP messages
are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT
RECOMMENDED (see Security Considerations). RECOMMENDED (see Security Considerations).
The SRTP specification requires use of message authentication for The SRTP specification requires use of message authentication for
SRTCP, but not for SRTP [srtp]. SRTCP, but not for SRTP [srtp].
5.3.5 FEC_ORDER=order In the offer/answer model, this parameter is negotiated.
5.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, SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC are FEC_SRTP, SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC
is applied before SRTP processing by the sender of the SRTP media is applied before SRTP processing by the sender of the SRTP media
and after SRTP processing by the receiver of the SRTP media; and after SRTP processing by the receiver of the SRTP media;
FEC_SRTP is the default. SRTP_FEC is the reverse processing. SPLIT FEC_SRTP is the default. SRTP_FEC is the reverse processing. SPLIT
signals that the sender performs SRTP encryption, followed by FEC signals that the sender performs SRTP encryption, followed by FEC
processing, followed by SRTP authentication; processing is reversed processing, followed by SRTP authentication; processing is reversed
on the receiver. on the receiver.
5.3.6 Window Size Hint (WSH) In the offer/answer model, FEC_ORDER is a declarative parameter.
SRTP defines the SRTP-WINDOW-SIZE [SRTP, section 3.3.2] parameter to 5.3.5 Window Size Hint (WSH)
protect against replay attacks. The minimum value, per [srtp], is
64, however this value may be considered too low for some SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to
applications (e.g. video). protect against replay attacks. The minimum value is 64 [srtp],
however this value may be considered too low for some applications
(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" and the bandwidth modifiers to allow a receiver to "a=maxprate" and the bandwidth modifiers to allow a receiver to
derive the parameter satisfactorily. Consequently, this value is derive the parameter satisfactorily. Consequently, this value is
only considered a hint to the receiver of the SDP which MAY choose only considered a hint to the receiver of the SDP which MAY choose
to ignore the value provided. to ignore the value provided.
5.3.7 SRTP Extension Session Parameters In the offer/answer model, WSH is a declarative parameter.
5.3.6 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 an IETF RFC and registered with IANA according to the be defined in an IETF RFC and registered with IANA according to the
registration procedures defined in Section 10. registration procedures defined in Section 9.
SRTP extension session parameters are by default mandatory. An SRTP New SRTP session parameters are by default mandatory. A newly-
extension session parameter that is prefixed with the dash character defined SRTP session parameter that is prefixed with the dash
("-") however is considered optional and MAY be ignored. If a SDP character ("-") however is considered optional and MAY be ignored.
is received with an unknown mandatory session parameter in a crypto If an SDP crypto attribute is received with an unknown session
attribute, that crypto attribute MUST be considered invalid and a parameter that is not prefixed with a "-" character, that crypto
"unknown session parameter" condition SHOULD be logged. attribute MUST be considered invalid.
6. SRTP-Specific Use of the crypto Attribute 5.4 SRTP Crypto Context Initialization
In this section, we describe the SRTP-specific use of the crypto In addition to the various SRTP parameters defined above, there are
attribute. three pieces of information that are critical to the operation of
the default SRTP ciphers:
6.1 Use with Offer/Answer * SSRC: Synchronization source
* ROC: Roll-over counter for a given SSRC
* SEQ: Sequence number for a given SSRC
In this section, we describe how the SRTP security descriptions are In a unicast session, as defined here, there are three constraints
used with the offer/answer model to negotiate cryptographic on these values.
capabilities and communicate SRTP master keys. The rules defined
below complement the general offer/answer rules defined in Section
4.1, which MUST be followed, unless otherwise specified.
6.1.1 Generating the Initial Offer The first constraint is on the SSRC, which makes an SRTP keystream
be unique from other participants. As explained in SRTP, the
keystream MUST NOT be reused on two or more different pieces of
plaintext. Keystream reuse makes the ciphertext vulnerable. One
vulnerability is that known-plaintext fields in one stream can
expose portions of the reused keystream and this could further
expose more plaintext in other streams. Since all current SRTP
encryption transforms use keystreams, key sharing is a general
problem [srtp]. SRTP mitigates this problem by including the SSRC
of the sender in the keystream. But SRTP does not solve this
problem in its entirety because Real-time Transport Protocol has
SSRC collisions, which are very rare [rtp], but quite possible.
During a collision, two or more SSRCs that share a master key will
have identical keystreams for overlapping portions of the RTP
sequence-number space. SRTP Security Descriptions avoids keystream
reuse by making unique master keys REQUIRED for the sender and
receiver of the security description. Thus, the first constraint is
satisfied.
6.1.1.1 Unicast Streams Also note, that there is a second problem with SSRC collisions:
The SSRC is used to identify the crypto context and thereby the
cipher, key, ROC, etc. to process incoming packets. In case of
SSRC collisions, crypto context identification becomes ambiguous
and correct packet processing may not occur. Furthermore, if an
RTCP BYE packet is to be sent for a colliding SSRC, that packet
may also have to be secured. In a (unicast) point-to-multipoint
scenario, this can be problematic for the same reasons, i.e., it
is not known which of the possible crypto contexts to use. Note
that these problems are not unique to the SDP security
descriptions; any use of SRTP needs to consider them.
When the initial offer is generated, the offerer MUST follow the The second constraint is that the ROC MUST be zero at the time that
steps in Section 4.1.1.1 as well as the following steps. each SSRC commences sending packets. Thus, there is no concept of a
"late joiner" in SRTP security descriptions, which are constrained
to be unicast and pairwise. The ROC and SEQ form a "packet index"
in the default SRTP transforms and the ROC is consistently set to
zero at session commencement, according to this document.
For each unicast media line (m=) using the "RTP/SAVP" transport The third constraint is that the initial value of SEQ SHOULD be
where the offerer wants to specify cryptographic parameters, the chosen to be within the range of 0..2^15-1; this avoids an ambiguity
offerer MUST provide at least one valid SRTP security description when packets are lost at the start of the session. If at the start
("a=crypto" line), as defined in Section 5. of a session, an SSRC source might randomly select a high sequence-
number value and put the receiver in an ambiguous situation: If
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 recognize that its ROC needs to be incremented. By
restricting the initial SEQ to the range of 0..2^15-1, SRTP packet-
index determination will find the correct ROC value, unless all of
the first 2^15 packets are lost (which seems, if not impossible,
then rather unlikely). See Section 3.3.1 of the SRTP specification
regarding packet-index determination [srtp].
The offerer MAY include one or more SRTP session parameters as The packet index, therefore, depends on the SSRC, the SEQ of an
defined in Section 5.3. Note however, that if any extension SRTP incoming packet and the ROC, which is an SRTP crypto context
session parameters are included, the negotiation will fail if the variable. Thus, SRTP has a big security dependency on SSRC
answerer does not support them. uniqueness. This fact might lead one to consider establishing the
SSRC by an entity that keeps these values from colliding. One
problem with this approach, however, is that the SSRC belongs to the
transport (RTP or SRTP) and not to the signaling. It would be an
imposition on RTP and SRTP to require that the SSRC be read and
written by an external system such as SDP.
6.1.1.2 Multicast Streams Given the above constraints, unicast SRTP crypto contexts can be
established without the need to negotiate SSRC values in the SRTP
security descriptions. Instead, an approach called "late binding"
is RECOMMENDED by this specification. When a packet arrives, the
SSRC that is contained in it can be bound to the crypto context at
the time of session commencement (i.e., SRTP packet arrival) rather
than at the time of session signaling (i.e., receipt of an SDP).
With the arrival of the packet containing the SSRC, all the data
items needed for the SRTP crypto context are held by the receiver
(note that the ROC value by definition is zero; if non-zero values
were to be supported, additional signaling would be required). In
other words, the crypto context for a secure RTP session using late
binding is initially identified by the SDP as:
When the initial offer is generated, the offerer MUST follow the <*, address, port>
steps in Section 4.1.1.2 as well as the following steps.
For each multicast media line (m=) using the "RTP/SAVP" transport where '*' is a wildcard SSRC, "address" is the local receive address
where the offerer wants to specify cryptographic parameters, the from the "c=" line, and "port" is the local receive port from the
offerer MUST provide at least one valid SRTP security description "m=" line. When the first packet arrives with ssrcX in its SSRC
("a=crypto" line), as defined in Section 5. Furthermore, the field, the crypto context
<"From", "To"> parameter in the key parameter MUST NOT be used,
unless the media stream is marked as "recvonly".
The <"From", "To"> value is SSRC specific, and hence will only <ssrcX, address, port>
work when there is a single sender in the multicast case, i.e. all
invited participants only receive media.
The offerer MAY include one or more SRTP session parameters as is instantiated subject to the following constraints:
defined in Section 5.3. Note however, that if any extension SRTP
session parameters are included, the negotiation will fail if the
answerer does not support them.
6.1.2 Generating the Initial Answer * Media packets are authenticated: Authentication MUST succeed;
otherwise, the crypto context is not instantiated.
6.1.2.1 Unicast Streams * Media packets are not authenticated: Crypto context is
automatically instantiated.
When the initial answer is generated, the answerer MUST follow the It should be noted, that use of late binding when there is no
steps in Section 4.1.2.1 as well as the following steps. authentication of the SRTP media packets is subject to numerous
security attacks and consequently it is NOT RECOMMENDED (of course,
this can be said for unauthenticated SRTP in general).
For each unicast media line using the "RTP/SAVP" transport that Note that use of late binding without authentication results in
contains one or more "a=crypto" lines in the offer, the answerer local state being created as a result of receiving a packet from
MUST either accept one of the crypto lines for that media stream, or any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT
it MUST reject the media stream. Only "a=crypto" lines that are RECOMMENDED because it invites easy denial-of-service attack. In
considered valid SRTP security descriptions as defined in Section 5 contrast, late binding with authentication does not suffer from
can be accepted. Furthermore, all parameters (crypto-suite, key this weakness.
parameter, and session parameters) MUST be acceptable to the
answerer in order for the offered media stream to be accepted.
When the answerer accepts an "RTP/SAVP" unicast media stream with a With the constraints and procedures described above, it is not
crypto line, the answerer indicates acceptance by including its own necessary to explicitly signal the SSRC, ROC and SEQ for a unicast
"a=crypto" line in the answer. The answer crypto line MUST include SRTP session.
at least the selected SRTP crypto-suite and one or more master keys
appropriate for the selected crypto algorithm; the master key(s)
included in the answer SHOULD be different from those in the offer.
If the master key(s) are not shared between the offerer and 5.5 Removal of Crypto Contexts
answerer, SSRC collisions are acceptable, which simplifies the
overall operation.
Session parameters MAY be included in the answer as well; any The mechanism defined above addresses the issue of creating crypto
session parameters included in the answer are independent of session contexts, however in practice, session participants may want to
parameters included in the offer. Use of extension SRTP session remove crypto contexts prior to session termination. Since a crypto
parameters SHOULD be avoided unless it is known that the offerer context contains information that can not automatically be recovered
supports these. (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 it cannot.
If the answerer cannot find any valid crypto line that it supports, Even when late binding is used for a unicast stream, the ROC is
or its configured policy prohibits any cryptographic key parameter lost and cannot be recovered automatically (unless it is zero)
(e.g. key length) or cryptographic session parameter (e.g. KDR, once the crypto context is removed.
FEC_ORDER), it MUST reject the media stream, unless it is able to
successfully negotiate use of "RTP/SAVP" by other means outside the
scope of this document (e.g., by use of MIKEY [mikey]).
6.1.2.2 Multicast Streams We resolve this problem as follows. When SRTP security descriptions
are being used, crypto contexts removal MUST follow the same rules
as 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
to inactivity. Inactive session participants that wish to ensure
their crypto contexts are not timed out MUST thus send SRTCP packets
at regular intervals.
When the initial answer is generated, the answerer MUST follow the 6. SRTP-Specific Use of the crypto Attribute
steps in Section 4.1.2.2 as well as the following steps.
For each multicast media stream using the "RTP/SAVP" transport that Section 4 describes general use of the crypto attribute, and this
contains an "a=crypto" line in the offer, the answerer MUST either section completes it by describing SRTP-specific use.
accept the first crypto line for that media stream (note that there
should only be one crypto line), or it MUST reject the media stream.
The crypto line MUST only be accepted if it is considered a valid
SRTP security description as defined in Section 5. Furthermore, all
parameters (crypto-suite, key parameter, and session parameters)
MUST be acceptable to the answerer in order for the offered media
stream to be accepted.
When the answerer accepts an "RTP/SAVP" multicast media stream with 6.1 Use with Offer/Answer
a crypto line, the answerer indicates acceptance by repeating the
crypto line from the offer in the answer, except for the session
parameters which SHOULD be excluded.
There is only a single view of a multicast stream (unlike In this section, we describe how the SRTP security descriptions are
unicast), and hence there is no reason to repeat optional used with the offer/answer model to negotiate cryptographic
parameters that cannot change anyway. capabilities and communicate SRTP master keys. The rules defined
below complement the general offer/answer rules defined in Section
4.1, which MUST be followed, unless otherwise specified. Note that
the rules below define unicast operation only; support for multicast
and multipoint unicast streams is for further study.
OPEN ISSUE: It is not clear that all session parameters should be 6.1.1 Generating the Initial Offer - Unicast Streams
excluded from the answer. In particular, we may want to allow for
inclusion of the SRC parameter, as this would enable a new-comer
to instantiate crypto-contexts for other participants in a
multicast conference, provided the conference is using a shared
key. If each sender uses a unique key, something else would be
needed (e.g. an offer/answer exchange with each participant or an
entirely different mechanism).
If the answerer cannot find any valid crypto line that it supports, When the initial offer is generated, the offerer MUST follow the
or its configured policy prohibits any cryptographic key parameter steps in Section 4.1.1 as well as the following steps.
(e.g. key length) or cryptographic session parameter (e.g. KDR,
FEC_ORDER), it MUST reject the media stream.
It should be noted, that multicast streams with more than one sender For each unicast media line (m=) using the secure RTP transport
that are negotiated by use of this mechanism will be using the same where the offerer wants to specify cryptographic parameters, the
master key for sending and receiving and hence SSRC collisions must offerer MUST provide at least one valid SRTP security description
be avoided. The mechanism defined here does not provide a way to ("a=crypto" line), as defined in Section 5.
avoid such SSRC collisions for multicast streams, and hence means
outside of the scope of this document are needed to ensure that SSRC
collisions are avoided. Examples of how this can be achieved
include a centralized controller supplying unique SSRCs to the
session participants or a separate protocol that can ensure SSRC
uniqueness prior to sending any SRTP packets.
6.1.3 Offerer Processing of the Initial Answer The offerer MAY include one or more other SRTP session parameters as
defined in Section 5.3. Note however, that if any SRTP session
parameters are included that are not known to the answerer, but are
nonetheless mandatory (see Section 5.3.6), the negotiation will fail
if the answerer does not support them.
6.1.3.1 Unicast Streams 6.1.2 Generating the Initial Answer - Unicast Streams
When the offerer receives the answer, it MUST perform the steps in When the initial answer is generated, the answerer MUST follow the
Section 4.1.3.1 as well as the following steps for each "RTP/SAVP" steps in Section 4.1.2 as well as the following steps.
media stream it offered with one or more crypto lines in it.
If the media stream was accepted and it contains a crypto line, it For each unicast media line which uses the secure RTP transport and
MUST be checked that the crypto line is valid according to the contains one or more "a=crypto" lines in the offer, the answerer
constraints specified in Section 5. 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"
lines that are considered valid SRTP security descriptions as
defined in Section 5 can be accepted. Furthermore, all parameters
(crypto-suite, key parameter, and mandatory session parameters) MUST
be acceptable to the answerer in order for the offered media stream
to be accepted.
If the crypto line contains any SRTP session parameters, those When the answerer accepts an SRTP unicast media stream with a crypto
parameters define SRTP behavior for media sent from the answerer to line, the answerer MUST include one or more master keys appropriate
the offerer. If the offerer either does not support or is not for the selected crypto algorithm; the master key(s) included in the
willing to honor one or more of the SRTP session parameters in the answer MUST be different from those in the offer.
answer, the offerer MUST consider the crypto line invalid.
If the crypto line is not valid, or the offerer's configured policy When the master key(s) are not shared between the offerer and
prohibits any cryptographic key parameter (e.g. key length) or answerer, SSRC collisions between the offerer and answerer will
cryptographic session parameter, the SRTP security negotiation MUST not lead to keystream reuse, and hence SSRC collisions do not
be deemed to have failed. necessarily have to be prevented.
6.1.3.2 Multicast Streams Declarative session parameters may be added to the answer as usual,
however the answerer SHOULD NOT add any mandatory session parameter
(see Section 5.3.6) that might be unknown to the offerer.
If the answerer cannot find any valid crypto line that it supports,
or if its configured policy prohibits any cryptographic key
parameter (e.g., key length) or cryptographic session parameter
(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
the scope of this document (e.g., by use of MIKEY [mikey]).
6.1.3 Offerer 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.2 as well as the following steps for each "RTP/SAVP" Section 4.1.3 as well as the following steps for each SRTP media
media stream it offered with a crypto line 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. If the crypto line includes any constraints specified in Section 5.
session parameters, those are simply ignored.
OPEN ISSUE: As noted in Section 6.1.2.2, it may make sense to If the offerer either does not support or is not willing to honor
allow for some session parameters, e.g. SRC, to be included. one or more of the SRTP parameters in the answer, the offerer MUST
consider the crypto line invalid.
If the crypto line is not valid, the SRTP security negotiation MUST If the crypto line is not valid, or the offerer's configured policy
be deemed to have failed for that particular answerer. prohibits any cryptographic key parameter (e.g. key length) or
cryptographic session parameter, the SRTP security negotiation MUST
be deemed to have failed.
6.1.4 Modifying the Session 6.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 4.1.4 as well
as the following steps. as the following steps.
Unicast Streams:
* The offerer SHOULD include the ROC and SEQ (unless both are made
available to the answerer by other means); this enables the
answerer to establish the complete crypto context in case he
currently does not have the ROC.
Multicast Streams:
* When the media stream is "recvonly", the offerer SHOULD include
the ROC and SEQ (unless both are made available to the answerer by
other means); this enables the answerer to establish the complete
crypto context in case he currently does not have the ROC.
It should be noted, that the mechanism defined here does not provide
a way to communicate the ROC for multiple senders, which may be
needed in some multicast scenarios, e.g. conferencing. If
renegotiation is needed, a separate mechanism, such as [GDOI], will
be needed for this. These methods are beyond the scope of this
document.
OPEN ISSUE: As noted in Section 6.1.2.2, it is not clear that we
couldn't do that with the SRC parameter.
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
traversal. The SRTP security descriptions offers two other ways traversal. The SRTP security descriptions offers two other ways
of dealing with this; use the MKI (which adds a few bytes to each of dealing with this; use the MKI (which adds a few bytes to each
SRTP packet) or the <"From","To"> mechanism (which doesn't add SRTP packet) or the <"From","To"> mechanism (which doesn't add
bytes to each SRTP packet) as described in Section 5.1.1.1. For bytes to each SRTP packet) as described in Section 5.1. For
further details on MKI and "<"From","To">, please refer to [srtp]. further details on MKI and "<"From","To">, please refer to [srtp].
* If the answerer changes its master key, the offerer will not be * If the answerer changes its master key, the offerer will not be
able to process packets secured via this master key until the able to process packets secured via this master key until the
answer is received. answer is received.
As noted in Section 4.1.1.1, this could for example be addressed As noted in Section 4.1.1, this could for example be addressed by
by defining a security "precondition" [RFC3312] using a security "precondition" [sprecon].
Finally note, that if the new offer is rejected, the old crypto Finally note, that if the new offer is rejected, the old crypto
parameters remain in place. parameters remain in place.
6.1.5 Offer/Answer Example 6.1.5 Offer/Answer Example
In this example, the offerer supports two crypto suites (F8 and In this example, the offerer supports two crypto suites (F8 and
AES). The a=crypto line is actually one long line, although it is AES). The a=crypto line is actually one long line, although it is
shown as two lines in this document due to page formatting. shown as two lines in this document due to page formatting.
Offerer sends: Offerer sends:
v=0 v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5 o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson) e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12 c=IN IP4 168.2.17.12
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0 m=audio 49170 RTP/SAVP 0
a=crypto:AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP SRC=//49126 FEC_ORDER=FEC_SRTP
a=crypto:F8_128_HMAC_SHA1_80 a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
FEC_ORDER=FEC_SRTP SRC=//49126 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP
Answerer replies: Answerer replies:
v=0 v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5 o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson) e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11 c=IN IP4 168.2.17.11
t=2873397526 2873405696 t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0 m=audio 32640 RTP/SAVP 0
a=crypto: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
SRC=/721/13
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. The answerer is also crypto suite for the RTP and RTCP traffic.
specifying both its current rollover counter (721), and sequence
number (13).
6.2 SRTP-Specific Use Outside Offer/Answer: Advertising 6.2 SRTP-Specific Use Outside Offer/Answer
The SRTP security descriptions can be used outside the context of These are the same as Section 4.2.
offer/answer as described in Section 4.2. In those cases, the
general rules defined in Section 4.2 as well as the SRTP-specific
rule defined below MUST be followed:
* If any SRTP session parameters are included, they MUST be 6.3 Support for SIP Forking
supported by the recipient of the SDP; otherwise, the recipient
MUST NOT join the SRTP session.
6.3 SRTP-Specific Backwards Compatibility Considerations As mentioned earlier, the security descriptions defined here do not
support multicast media streams or multipoint unicast streams.
However, in the SIP protocol, it is possible to receive several
answers to a single offer due to the use of forking (see [SIP]).
Receiving multiple answers leads to a couple of problems for the
SRTP security descriptions:
It is possible that the answerer supports the "RTP/SAVP" transport * Different answerers may choose different ciphers, keys, etc.,
and accepts the offered media stream, yet it does not support the however there is no way for the offerer to associate a particular
crypto attribute defined here. The offerer can recognize this incoming media packet with a particular answer.
situation by seeing an accepted "RTP/SAVP" media stream in the
answer that does not include a crypto line. In that case, the
security negotiation defined here MUST be deemed to have failed.
Also, if a media stream with transport set to "RTP/SAVP" is sent to * Two or more answerers may pick the same SSRC and hence the SSRC
a device that does not support "RTP/SAVP", that media stream will be collision problems mentioned earlier may arise.
rejected.
6.4 Operation with KEYMGT= and k= lines As stated earlier, the above point-to-multipoint cases are outside
the scope of the SDP security descriptions. However, there is a way
of supporting SIP forking: Change the multipoint scenario resulting
from SIP forking into multiple two-party unicast cases. This is
done as follows:
For each answer received beyond the initial answer, issue a new
offer to that particular answerer using a new receive transport
address (IP address and port); note that this requires support for
the SIP UPDATE method [RFC 3313]. Also, to ensure that two media
sessions are not inadvertently established prior to the UPDATE being
processed by one of them, use security preconditions [sprecon].
Finally, note that all the answerers will know the key(s) being
proposed by the initial offer. If the offerer wants to ensure
security with respect to other answerers, a new offer/answer
exchange with a new key needs to be performed with the first
answerer as well.
6.4 SRTP-Specific Backwards Compatibility Considerations
It is possible that the answerer supports the SRTP transport and
accepts the offered media stream, yet it does not support the crypto
attribute defined here. The offerer can recognize this situation by
seeing an accepted SRTP media stream in the answer that does not
include a crypto line. In that case, the security negotiation
defined here MUST be deemed to have failed.
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
media stream will be rejected.
6.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 it does not Per SDP rules, the answerer will ignore attribute lines that it does
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 [SDPnew]. Per An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP
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.
6.5 Removal of Crypto Contexts
The mechanism defined above addresses the issue of creating crypto
contexts, however in practice, session participants may want to
remove crypto contexts prior to session termination. Since a crypto
context contains information that can not automatically be recovered
(e.g. ROC and SEQ), it is important that the sender and receiver
agree on when a crypto context can be removed, and perhaps more
importantly when it cannot.
Even when late binding is used for a unicast stream, the ROC is
lost and cannot be recovered automatically once the crypt context
is removed.
We resolve this problem as follows. When SRTP security descriptions
are being used, crypto contexts removal MUST follow the same rules
as 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
to inactivity. Inactive session participants that wish to ensure
their crypto contexts are not timed out MUST thus send SRTCP packets
at regular intervals.
7. Security Considerations 7. Security Considerations
Like all SDP messages, SDP messages containing security Like all SDP messages, SDP messages containing security
descriptions, are conveyed in an encapsulating application protocol descriptions, are conveyed in an encapsulating application protocol
(e.g. SIP, MGCP, RTSP, SAP, etc.). It is the responsibility of the (e.g., SIP, MGCP, etc.). It is the responsibility of the
encapsulating protocol to ensure the protection of the SDP security encapsulating protocol to ensure the protection of the SDP security
descriptions. Therefore, the application protocol SHOULD either descriptions. Therefore, the application protocol SHOULD either
invoke its own security mechanisms to do so, or alternatively invoke its own security mechanisms (e.g., secure multiparts) or
utilize a lower-layer security service (e.g. TLS, IPSEC). This alternatively utilize a lower-layer security service (e.g., TLS, or
security service SHOULD provide strong message authentication and IPSec). This security service SHOULD provide strong message
packet-payload encryption as well as effective replay protection. authentication and packet-payload encryption as well as effective
replay protection.
7.1 Authentication of packets 7.1 Authentication of packets
Security descriptions as defined herein signal security services for Security descriptions as defined herein signal security services for
RTP packets. RTP messages are vulnerable to a variety of attacks RTP packets. RTP messages are vulnerable to a variety of attacks
such as replay and forging. To limit these attacks, SRTP message such as replay and forging. To limit these attacks, SRTP message
integrity mechanisms SHOULD be used (SRTP replay protection is integrity mechanisms SHOULD be used (SRTP replay protection is
always enabled). Source authentication (i.e. data-origin always enabled).
authentication) of unicast SRTP messages SHOULD be performed [srtp].
7.2 Keystream Reuse 7.2 Keystream Reuse
Security descriptions as defined herein signal configuration SRTP security descriptions signal configuration parameters for SRTP
parameters for SRTP sessions. Misconfigured SRTP sessions are sessions. Misconfigured SRTP sessions are vulnerable to attacks on
vulnerable to attacks on their encryption services when running the their encryption services when running the crypto suites defined in
crypto suites defined in Sections 5.2.1, 5.2.2, and 5.2.3. An SRTP Sections 5.2.1, 5.2.2, and 5.2.3. An SRTP encryption service is
encryption service is "misconfigured" when two or more media streams "misconfigured" when two or more media streams are encrypted using
are encrypted using the same AES keystream. When senders and the same AES keystream. When senders and receivers share derived
receivers share derived session keys, SRTP requires that the SSRCs session keys, SRTP requires that the SSRCs of session participants
of session participants serve to make their corresponding keystreams serve to make their corresponding keystreams unique, which is
unique, which is violated in the case of SSRC collision: SRTP SSRC violated in the case of SSRC collision: SRTP SSRC collision
collision drastically weakens SRTP or SRTCP payload encryption drastically weakens SRTP or SRTCP payload encryption during the time
during the time that identical keystreams were used [srtp]. An that identical keystreams were used [srtp]. An attacker, for
attacker, for example, might collect SRTP and SRTCP messages and example, might collect SRTP and SRTCP messages and await a
await a collision. This attack on the AES-CM and AES-f8 encryption collision. This attack on the AES-CM and AES-f8 encryption is
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, as this document key in both the send and receive direction. This specification
RECOMMENDS (see Section 6.1.2.1), i.e. keys are not shared between restricts use of SDP security description to unicast point-to-point
multiple media streams, and the keys used in the send and receive streams so that keys are not shared between SRTP hosts, and the
direction for a given media stream are unique. master keys used in the send and receive direction for a given media
stream are unique.
SRTP multicast operation requires that each host-sender have a
unique SRTP keystream. This can be accomplished by ensuring that
each sender be allocated a unique key or by ensuring that the SSRC
of each sender will not collide. Since SSRC collision might occur,
the latter condition is avoided when all SSRCs are assigned by a
central authority such as a 3rd-party key server [srtp]. The
RECOMMENDED approach of this document is to allocate a different
master key for each host-participant of an SRTP session.
7.3 Signaling Authentication and Signaling Encryption 7.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
itself send unencrypted SRTP and leave its data exposed to snooping. itself send unencrypted SRTP and leave its data exposed to snooping.
Thus, IPsec, TLS, or some other data security service SHOULD be used Thus, MIME secure multiparts, IPsec, TLS, or some other data
to provide message authentication for the encapsulating protocol security service SHOULD be used to provide message authentication
that carries the SDP messages having a crypto attribute (a=crypto). for the encapsulating protocol that carries the SDP messages having
Furthermore, encryption of the encapsulating payload SHOULD be used a crypto attribute (a=crypto). Furthermore, encryption of the
because a master key parameter (inline) appears in the message. encapsulating payload SHOULD be used because a master key parameter
Failure to encrypt the SDP message containing an inline SRTP master (inline) appears in the message. Failure to encrypt the SDP message
key renders the SRTP authentication or encryption service useless in containing an inline SRTP master key renders the SRTP authentication
practically all circumstances. Failure to authenticate an SDP or encryption service useless in practically all circumstances.
message that carries SRTP parameters renders the SRTP authentication Failure to authenticate an SDP message that carries SRTP parameters
or encryption service useless in most practical applications. renders the SRTP authentication or encryption service useless in
most practical applications.
When the communication path of the SDP message is routed through
intermediate systems that inspect parts of the SDP message, security
protocols such as IPsec or TLS SHOULD NOT be used for encrypting
and/or authenticating the security description. In the case of
intermediate-system processing of a message containing SDP security
descriptions, the "a=crypto" attributes SHOULD be protected end-to-
end so that the intermediate system can neither modify the security
description nor access the keying material. Network or transport
security protocols that terminate at each intermediate system,
therefore, SHOULD NOT be used for protecting SDP security
descriptions. A security protocol SHOULD allow the security
descriptions to be encrypted and authenticated end-to-end
independently of the portions of the SDP message that any
intermediate system modifies or inspects: MIME secure multiparts
are RECOMMENDED for the protection of SDP messages that are
processed by intermediate systems.
When the SDP parameters cannot be carried in an encrypted and When the SDP parameters cannot be carried in an encrypted and
authenticated SDP message, it is RECOMMENDED that a key management authenticated SDP message, it is RECOMMENDED that a key management
protocol be used instead of the security descriptions defined here protocol be used instead of the security descriptions defined here
(a=crypto). The proposed SDP key-mgmt extension [keymgt] allows (a=crypto). The proposed SDP key-mgmt extension [keymgt] allows
authentication and encryption of the key management protocol data authentication and encryption of the key management protocol data
independently of the SDP message that carries it. The security of independently of the SDP message that carries it. The security of
the SDP SRTP attribute, however, is as good as the data security the SDP SRTP attribute, however, is as good as the data security
protocol that protects the SDP message. For example, if an IPsec protocol that protects the SDP message. For example, if an IPSec
security association exists between the source and destination security association exists between the SDP source and destination
endpoints, then this solution is more secure than use of the key- endpoints, then this solution is more secure than use of the key-
mgmt statement in an unauthenticated SDP message, which is mgmt statement in an unauthenticated SDP message, which is
vulnerable to tampering. vulnerable to tampering.
There are practical cases, however, where SDP security is not end-
to-end: If there is a third-party provider between the sender and
receiver, then the data-security session might not be end-to-end.
That is, one possible configuration might have an IPsec or TLS
connection between the sender of the SDP message and the provider,
such as a VoIP service provider, with a second secure connection
between the provider and the receiver:
signaling controller---(network-b)---signaling controller
| |
(network a) (network c)
| |
sender----------------(SRTP bearer)--------------receiver
where all of link a, b, and c are encrypted with TLS or IPsec.
In this case, the third-party provider has access to the contents of
the SRTP descriptions in the SDP message. SDP key-mgmt statement,
however, allows true end-to-end security that is independent of the
service provider, who often needs access to some parts of the SDP
message to render its services. The SRTP attribute SHOULD NOT be
used when end-to-end authentication or confidentiality is needed but
the SDP message is not secured end-to-end (such as the above example
where a third-party provider maintains the security associations
with the endpoints for the SDP message).
8. Grammar 8. Grammar
In this section we first provide the ABNF grammar for the generic
crypto attribute, and then we provide the ABNF grammar for the SRTP
specific use of the crypto attribute.
8.1 Generic "Crypto" Attribute Grammar 8.1 Generic "Crypto" Attribute Grammar
The ABNF grammar for the crypto attribute is defined below: The ABNF grammar for the crypto attribute is defined below:
"a=crypto:" crypto-suite 1*WSP key-params *(1*WSP session-param) "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*ALPHANUM
crypto-suite = 1*(ALPHA / DIGIT / "_") crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-params) 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 / %x3B-7E ; visible (printing) characters key-info = %x21-3A / %x3C-7E ; visible (printing) characters
; except semi-colon ; except semi-colon
session-param = 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 8.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
skipping to change at page 29, line 53 skipping to change at page 28, line 54
srtp-crypto-suite-ext srtp-crypto-suite-ext
srtp-key-method = "inline" srtp-key-method = "inline"
srtp-key-info = key-salt "|" [lifetime] "|" [mki / FromTo] srtp-key-info = key-salt "|" [lifetime] "|" [mki / FromTo]
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.1.1 for "2^" lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^"
mki = mki-value ":" mki-length mki = mki-value ":" mki-length
mki-value = 1*DIGIT mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128. mki-length = 1*3DIGIT ; range 1..128.
FromTo = "FT=" ftval "," ftval FromTo = "FT=" ftval "," ftval
ftval = roc ":" seq ; packet index expressed in terms ftval = roc ":" seq ; packet index expressed in terms
; of ROC and SEQ. ; of ROC and SEQ.
roc = 1*DIGIT ; range 0..2^32-1
seq = 1*DIGIT ; range 0..2^16-1
srtp-session-param = src / srtp-session-param = kdr /
kdr /
"UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" / "UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" / "UNAUTHENTICATED_SRTP" /
fec-order / fec-order /
wsh / wsh /
srtp-session-extension srtp-session-extension
src = "SRC=" [ssrc] "/" [roc] "/" [seq]
ssrc = 1*DIGIT ; range 0..2^32-1
roc = 1*DIGIT ; range 0..2^32-1
seq = 1*DIGIT ; range 0..2^16-1
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" / "SPLIT" fec-type = "FEC_SRTP" / "SRTP_FEC" / "SPLIT"
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. Open Issues 9. IANA Considerations
The following is a list of open issues in this document:
* The use of security descriptions, and in particular SRTP security
descriptions, with multicast streams where offer/answer is being
used is not well understood and requires further consideration.
* The security descriptions do not deal with hierarchically encoded
streams (or at least they have not been considered).
* The current mechanism does not allow for a key to be specified as
being an encryption or decryption key or both; instead this is
inferred from the context (e.g. unicast offer). Should there be a
mechanism to allow a key to be tagged as an encryption, decryption
or both key ?
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 3
10.2 New IANA Registries and Registration Procedures 9.2 New IANA Registries and Registration Procedures
The following sub-sections define several new IANA registries to be The following sub-sections define a new IANA registry with
used for the security descriptions. It is suggested that the associated sub-registries to be used for the SDP security
following registry structure be used for these: descriptions. The IANA is hereby requested to create an SDP
Security Description registry as shown below and further described
in the following sections:
Security Descriptions SDP Security Descriptions
|
+- Key Methods (described in 10.2.1)
| |
+- Media Stream Transports +- Key Methods (described in 9.2.1)
| |
+- SRTP +- Media Stream Transports (described in 9.2.2)
| |
+- SRTP crypto suites (described in Section 10.2.2) +- Transport1 (e.g. SRTP)
| |
| +- Supported Key Methods (e.g. inline)
| |
| +- crypto suites
| |
| +- session parameters
| |
+- SRTP session parameters (described in Section 10.2.3) +- Transport2
: :
10.2.1 Security Descriptions Key Method Registry and Registration 9.2.1Security Descriptions Key Method Registry and Registration
The IANA is hereby requested to create a new registry 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 IETF RFC and it MUST provide the name of MUST be documented in an IETF Standards Track RFC and it MUST
the key method in accordance with the grammar for key-method-ext provide the name of the key method in accordance with the grammar
defined in Section 8.1. for key-method-ext defined in Section 8.1.
10.2.2 SRTP Crypto Suite Registry and Registration
The IANA is hereby requested to create a new registry for SRTP
crypto suites. An IANA crypto suite registration MUST indicate the
crypto suite name in accordance with the grammar for srtp-crypto-
suite-ext defined in Section 8.2.
The semantics of the crypto suite MUST be described in an IETF RFC, 9.2.2Security Description Media Stream Transport Registry and
including the semantics of the "inline" key-method and any special Registration
semantics of parameters.
10.2.3 SRTP Session Parameter Registration The IANA is hereby requested to create a new subregistry for SDP
security description Media Stream Transports. An IANA media stream
transport registration MUST be documented in an RFC in accordance
with the procedures defined in Section 3 and 4 of this document.
The registration MUST provide the name of the transport and a list
of supported key methods.
The IANA is hereby requested to create a new registry for SRTP In addition, each new media stream transport registry must contain a
session parameters. An IANA SRTP session parameter registration crypto-suite registry and a session parameter registry as well as
MUST indicate the session parameter name (srtp-session-extension as IANA instructions for how to populate these registries.
defined in Section 8.2); the name MUST NOT begin with the dash
character ("-").
The semantics of the parameter MUST be described in an IETF RFC. If 9.3 Initial Registrations
values can be assigned to the parameter, then the format and
possible values that can be assigned MUST be described in the IETF
RFC as well.
10.3 Initial Registrations 9.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
The IANA is hereby requested to create an SDP Security Description
Media Stream Transport subregistry for "SRTP". The key methods
supported is "inline". The reference for the SDP security
description for SRTP is this document.
9.3.2.1 SRTP Crypto Suite Registry and Registration
The IANA is hereby requested to create a new subregistry for SRTP
crypto suites under the SRTP transport of the SDP Security
Descriptions. An IANA SRTP crypto suite registration MUST indicate
the crypto suite name in accordance with the grammar for srtp-
crypto-suite-ext defined in Section 8.2.
The semantics of the SRTP crypto suite MUST be described in an IETF
RFC, including the semantics of the "inline" key-method and any
special semantics of 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.
9.3.2.2 SRTP Session Parameter Registration
The IANA is hereby requested to create a new subregistry for SRTP
session parameters under the SRTP transport of the SDP Security
Descriptions. An IANA SRTP session parameter registration MUST
indicate the session parameter name (srtp-session-extension as
defined in Section 8.2); the name MUST NOT begin with the dash
character ("-").
The semantics of the parameter MUST be described in an IETF RFC. If
values can be assigned to the parameter, then the format and
possible values that can be assigned MUST be described in the IETF
RFC as well. Also, it MUST be specified whether the parameter is
declarative or negotiated in the offer/answer model.
The following SRTP session parameters are hereby registered: The following SRTP session parameters are hereby registered:
SRC SRC
KDR KDR
UNENCRYPTED_SRTP UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP UNENCRYPTED_SRTCP
UNAUTHENTICATED_SRTP UNAUTHENTICATED_SRTP
FEC_ORDER FEC_ORDER
WSH WSH
The reference for these parameters is this document.
The ABNF for all of the above is already included in the ABNF 10. Acknowledgements
section of this document.
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 David McGrew, Mats Naslund, Mike benefited from discussions with Elisabetta Cararra, Earl Carter,
Thomas, Elisabetta Cararra, Brian Weis, Dave Oran, Bill Foster, Earl Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David
Carter, Matt Hammer and Dave Singer. These people shared McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer,
Mike Thomas, Brian Weis, and Magnus Westerlund. These people shared
observations, identified errors and made suggestions for improving observations, identified errors and made suggestions for improving
the specification. Mats made several valuable suggestions on the specification. Magnus provided many useful comments and Mats
parameters and syntax that are in the current draft. Dave Oran and made several valuable suggestions on parameters and syntax that are
Mike Thomas encouraged us to bring this work to the IETF for in the current draft. Dave Oran and Mike Thomas encouraged us to
standardization. David McGrew suggested the conservative approach bring this work to the IETF for standardization. David McGrew
of requiring unique master keys for each unicast SDP media stream as suggested the conservative approach of requiring unique master keys
followed in this document. Jonathan Rosenberg suggested reducing for each unicast SDP media stream as followed in this document.
the complexity by specifying only one security parameter for each Paul Kyzivat suggested how to handle SIP forking. Jonathan
media stream. Rosenberg suggested reducing the complexity by specifying only one
security parameter for each media stream.
12. Authors' Addresses 11. Authors' Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
499 Thornall Street, 8th Floor 499 Thornall Street, 8th Floor
Edison, New Jersey 08837 USA Edison, New Jersey 08837 USA
fandreas@cisco.com fandreas@cisco.com
Mark Baugher Mark Baugher
5510 SW Orchid Street 5510 SW Orchid Street
Portland, Oregon 97219 USA Portland, Oregon 97219 USA
mbaugher@cisco.com mbaugher@cisco.com
+1-408-853-4418
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
+1-408-902-3348
13. Normative References 12. 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,
July 2003, http://www.ietf.org/rfc/rfc3550.txt. 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.
[SDPnew] M. Handley, V. Jacobson, C. Perkins, "SDP: Session [SDP] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description
Description Protocol", Work in Progress. Protocol", Work in Progress.
[RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999, Generic Forward Error Correction", RFC 2733, December 1999,
http://www.ietf.org/rfc/rfc2733.txt. http://www.ietf.org/rfc/rfc2733.txt.
[RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
2000, http://www.ietf.org/rfc/rfc2828.txt. 2000, http://www.ietf.org/rfc/rfc2828.txt.
[RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2202, the Session Description Protocol (SDP)", RFC 3264, June 2202,
http://www.ietf.org/rfc/rfc3264.txt. http://www.ietf.org/rfc/rfc3264.txt.
[srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. [srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K.
Norrman, D. Oran, "The Secure Real-time Transport Protocol", Work in Norrman, D. Oran, "The Secure Real-time Transport Protocol", Work in
Progress. Progress.
[RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994, Recommendations for Security", RFC 1750, December 1994,
http://www.ietf.org/rfc/rfc1750.txt. http://www.ietf.org/rfc/rfc1750.txt.
14. Informative References [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
13. Informative References
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002, Capability Declaration", RFC 3407, October 2002,
http://www.ietf.org/rfc/rfc3407.txt. http://www.ietf.org/rfc/rfc3407.txt.
[Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols," in Proceedings of the Sixth Usenix Unix Security Protocols," in Proceedings of the Sixth Usenix Unix Security
Symposium, pp. 1-16, San Jose, CA, July 1996. Symposium, pp. 1-16, San Jose, CA, July 1996.
[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 35, line 21 skipping to change at page 34, line 37
Systems Symposium, San Diego, 1996. Systems Symposium, San Diego, 1996.
[RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt. 3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt.
[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000, Protocol", RFC 2974, October 2000,
http://www.ietf.org/rfc/rfc2974.txt . http://www.ietf.org/rfc/rfc2974.txt .
[srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security
Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 35, line 45 skipping to change at page 35, line 29
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright(C) The Internet Society 2003. All Rights Reserved. Copyright(C) The Internet Society 2004. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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