draft-ietf-mmusic-sdescriptions-04.txt   draft-ietf-mmusic-sdescriptions-05.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: November 2004 Cisco Systems EXPIRES: December 2004 Cisco Systems
May, 2004 June, 2004
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-04.txt> <draft-ietf-mmusic-sdescriptions-05.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 ?
1. Notational Conventions............................................3 1. Notational Conventions............................................3
2. Introduction......................................................3 2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters.............................5 3. SDP "Crypto" Attribute and Parameters.............................5
3.1 Tag.............................................................5 3.1 Tag.............................................................5
3.2 Crypto-suite....................................................5 3.2 Crypto-suite....................................................5
3.3 Key Parameters..................................................6 3.3 Key Parameters..................................................6
3.4 Session Parameters..............................................7 3.4 Session Parameters..............................................7
3.5 Example.........................................................7 3.5 Example.........................................................7
4. General Use of the crypto Attribute...............................8 4. General Use of the crypto Attribute...............................8
4.1 Use With Offer/Answer...........................................8 4.1 Use With Offer/Answer...........................................8
4.1.1 Generating the Initial Offer - Unicast Streams............8 4.1.1 Generating the Initial Offer - Unicast Streams.............8
4.1.2 Generating the Initial Answer - Unicast Streams...........9 4.1.2 Generating the Initial Answer - Unicast Streams............9
4.1.3 Offerer Processing of the Initial Answer - Unicast Streams10 4.1.3 Processing of the Initial Answer - Unicast Streams........10
4.1.4 Modifying the Session....................................10 4.1.4 Modifying the Session.....................................10
4.2 Use Outside Offer/Answer.......................................10 4.2 Use Outside Offer/Answer.......................................10
4.3 General Backwards Compatibility Considerations.................10 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions.......................................11 5. SRTP Security Descriptions.......................................11
5.1 SRTP Key Parameter.............................................12 5.1 SRTP Key Parameter.............................................12
5.2 Crypto-suites..................................................14 5.2 Crypto-suites..................................................14
5.2.1 AES_CM_128_HMAC_SHA1_80..................................15 5.2.1 AES_CM_128_HMAC_SHA1_80...................................15
5.2.2 AES_CM_128_HMAC_SHA1_32..................................15 5.2.2 AES_CM_128_HMAC_SHA1_32...................................15
5.2.3 F8_128_HMAC_SHA1_80......................................16 5.2.3 F8_128_HMAC_SHA1_80.......................................16
5.2.4 Adding new Crypto-suite Definitions......................16 5.2.4 Adding new Crypto-suite Definitions.......................16
5.3 Session Parameters.............................................16 5.3 Session Parameters.............................................16
5.3.1 KDR=n....................................................16 5.3.1 KDR=n.....................................................16
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................16 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP....................16
5.3.3 UNAUTHENTICATED_SRTP.....................................17 5.3.3 UNAUTHENTICATED_SRTP......................................17
5.3.4 FEC_ORDER=order..........................................17 5.3.4 FEC_ORDER=order...........................................17
5.3.5 FEC_KEY=key-params.......................................17 5.3.5 FEC_KEY=key-params........................................17
5.3.6 Window Size Hint (WSH)...................................18 5.3.6 Window Size Hint (WSH)....................................18
5.3.7 Defining New SRTP Session Parameters.....................18 5.3.7 Defining New SRTP Session Parameters......................18
5.4 SRTP Crypto Context Initialization.............................18 5.4 SRTP Crypto Context Initialization.............................18
5.5 Removal of Crypto Contexts.....................................20 5.5 Removal of Crypto Contexts.....................................20
6. SRTP-Specific Use of the crypto Attribute........................21 6. SRTP-Specific Use of the crypto Attribute........................21
6.1 Use with Offer/Answer..........................................21 6.1 Use with Offer/Answer..........................................21
6.1.1 Generating the Initial Offer - Unicast Streams...........21 6.1.1 Generating the Initial Offer - Unicast Streams............21
6.1.2 Generating the Initial Answer - Unicast Streams..........22 6.1.2 Generating the Initial Answer - Unicast Streams...........22
6.1.3 Offerer Processing of the Initial Answer - Unicast Streams22 6.1.3 Processing of the Initial Answer - Unicast Streams........22
6.1.4 Modifying the Session....................................23 6.1.4 Modifying the Session.....................................23
6.1.5 Offer/Answer Example.....................................24 6.1.5 Offer/Answer Example......................................24
6.2 SRTP-Specific Use Outside Offer/Answer.........................25 6.2 SRTP-Specific Use Outside Offer/Answer.........................25
6.3 Support for SIP Forking........................................25 6.3 Support for SIP Forking........................................25
6.4 SRTP-Specific Backwards Compatibility Considerations...........26 6.4 SRTP-Specific Backwards Compatibility Considerations...........26
6.5 Operation with KEYMGT= and k= lines............................26 6.5 Operation with KEYMGT= and k= lines............................26
7. Security Considerations..........................................26 7. Security Considerations..........................................26
7.1 Authentication of packets......................................26 7.1 Authentication of packets......................................26
7.2 Keystream Reuse................................................27 7.2 Keystream Reuse................................................27
7.3 Signaling Authentication and Signaling Encryption..............27 7.3 Signaling Authentication and Signaling Encryption..............27
8. Grammar..........................................................28 8. Grammar..........................................................28
8.1 Generic "Crypto" Attribute Grammar.............................28 8.1 Generic "Crypto" Attribute Grammar.............................28
8.2 SRTP "Crypto" Attribute Grammar................................29 8.2 SRTP "Crypto" Attribute Grammar................................29
9. IANA Considerations..............................................30 9. IANA Considerations..............................................30
9.1 Registration of the "crypto" attribute.........................30 9.1 Registration of the "crypto" attribute.........................30
9.2 New IANA Registries and Registration Procedures................30 9.2 New IANA Registries and Registration Procedures................30
9.2.1 Security Descriptions Key Method Registry and Registration31 9.2.1 Key Method Registry and Registration......................30
9.2.2 Security Description Media Stream Transport Registry and 9.2.2 Media Stream Transport Registry and Registration..........31
Registration.....................................................31
9.3 Initial Registrations..........................................31 9.3 Initial Registrations..........................................31
9.3.1 Key Method...............................................31 9.3.1 Key Method................................................31
9.3.2 SRTP Media Stream Transport..............................31 9.3.2 SRTP Media Stream Transport...............................31
10. Acknowledgements................................................32 10. Acknowledgements................................................32
11. Authors' Addresses..............................................33 11. Authors' Addresses..............................................33
12. Normative References............................................33 12. Normative References............................................33
13. Informative References..........................................34 13. Informative References..........................................34
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
skipping to change at page 3, line 46 skipping to change at page 3, line 45
Explanatory notes are provided in several places throughout the Explanatory notes are provided in several places throughout the
document; these notes are indented two spaces from the surrounding document; these notes are indented two spaces from the surrounding
text. text.
2. Introduction 2. Introduction
The Session Description Protocol (SDP) [SDP] describes multimedia The Session Description Protocol (SDP) [SDP] describes multimedia
sessions, which can be audio, video, whiteboard, fax, modem, and sessions, which can be audio, video, whiteboard, fax, modem, and
other media streams. Security services such as data origin other media streams. Security services such as data origin
authentication, integrity and confidentiality are often needed for authentication, integrity and confidentiality are often needed for
those streams. The Secure Real-time Transport Protocol (SRTP) those streams. The Secure Real-time Transport Protocol (SRTP) [srtp]
[srtp] provides security services for RTP media and is signaled by provides security services for RTP media and is signaled by use of
use of secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP
SDP media (m=) line. However, there are no means within SDP itself media (m=) line. However, there are no means within SDP itself to
to configure SRTP beyond using default values. This document configure SRTP beyond using default values. This document specifies
specifies a new SDP attribute called "crypto", which is used to a new SDP attribute called "crypto", which is used to signal and
signal and negotiate cryptographic parameters for media streams in negotiate cryptographic parameters for media streams in general, and
general, and SRTP in particular. The definition of the crypto SRTP in particular. The definition of the crypto attribute in this
attribute in this document is limited to two-party unicast media document is limited to two-party unicast media streams where each
streams where each source has a unique cryptographic key; support source has a unique cryptographic key; support for multicast media
for multicast media streams or multipoint unicast streams is for streams or multipoint unicast streams is for further study.
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 SRTP and any other secure transports that can establish with SRTP and any other secure transports that can establish
cryptographic parameters with only a single message or in a single cryptographic parameters with only a single message or in a single
round-trip exchange using the offer/answer model [RFC3264]. round-trip exchange using the offer/answer model [RFC3264].
Extension to transports other than SRTP, however, is beyond the Extension to transports other than SRTP, however, is beyond the scope
scope of this document. Each type of secure media transport needs of this document. Each type of secure media transport needs its own
its own specification for the crypto-attribute parameter. These specification for the crypto-attribute parameter. These definitions
definitions are frequently unique to the particular type of are frequently unique to the particular type of transport and must be
transport and must be specified in a Standards Track RFC and specified in a Standards Track RFC and registered with IANA according
registered with IANA according to the procedures defined in Section to the procedures defined in Section 9. This document defines the
9. This document defines the security parameters and keying security parameters and keying material for SRTP only.
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
other parameters at least as well as the data is secured. Data parameters at least as well as the data is secured. Data security
security protocols such as SRTP rely upon a separate key management protocols such as SRTP rely upon a separate key management system to
system to securely establish encryption and/or authentication keys. securely establish encryption and/or authentication keys. Key
Key management protocols provide authenticated key establishment management protocols provide authenticated key establishment (AKE)
(AKE) procedures to authenticate the identity of each endpoint and procedures to authenticate the identity of each endpoint and protect
protect against man-in-the-middle, reflection/replay, connection against man-in-the-middle, reflection/replay, connection hijacking
hijacking and some denial of service attacks [skeme]. Along with and some denial of service attacks [skeme]. Along with the key, an
the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE
[kink], IKE [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS] [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS] securely
securely disseminates information describing both the key and the disseminates information describing both the key and the data-
data-security session. AKE is needed because it is pointless to security session. AKE is needed because it is pointless to provide a
provide a key over a medium where an attacker can snoop the key, key over a medium where an attacker can snoop the key, alter the
alter the definition of the key to render it useless, or change the definition of the key to render it useless, or change the parameters
parameters of the security session to gain unauthorized access to of the security session to gain unauthorized access to session-
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
media security descriptions defined in this document do not add AKE security descriptions defined in this document do not add AKE
services to SDP. This specification is no replacement for a key services to SDP. This specification is no replacement for a key
management protocol or for the conveyance of key management messages management protocol or for the conveyance of key management messages
in SDP [keymgt]. The SDP security descriptions defined here are in SDP [keymgt]. The SDP security descriptions defined here are
suitable for restricted cases only where IPsec, TLS, or some other suitable for restricted cases only where IPsec, TLS, or some other
encapsulating data-security protocol (e.g., SIP secure multiparts) encapsulating data-security protocol (e.g., SIP 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 new to those encrypted and/or authenticated SDP messages through the new
SDP "crypto" attribute, which provides the cryptographic parameters SDP "crypto" attribute, which provides the cryptographic parameters
of a media stream. of a media stream.
The "crypto" attribute can be adapted to any media transport, but The "crypto" attribute can be adapted to any media transport, but its
its precise definition is unique to a particular transport. precise definition is unique to a particular transport.
In Section 3, we introduce the general SDP crypto attribute, and in In Section 3, we introduce the general SDP crypto attribute, and in
Section 4 we define how it is used with and without the offer/answer Section 4 we define how it is used with and without the offer/answer
model. In Section 5, we define the crypto attribute details needed model. In Section 5, we define the crypto attribute details needed
for SRTP, and in Section 6 we define SRTP-specific use of the for SRTP, and in Section 6 we define SRTP-specific use of the
attribute with and without the offer/answer model. Section 7 attribute with and without the offer/answer model. Section 7 recites
recites security considerations, and Section 8 gives an Augmented- security considerations, and Section 8 gives an Augmented-BNF grammar
BNF grammar for the general crypto attribute as well as the SRTP- for the general crypto attribute as well as the SRTP-specific use of
specific use of the crypto attribute. IANA considerations are the crypto attribute. IANA considerations are provided in Section 9.
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 unicast media line. The "crypto" attribute MUST only preceding unicast media line. The "crypto" attribute MUST only
appear at the SDP media level (not at the session level). The appear at the SDP media level (not at the session level). The
"crypto" attribute follows the format (see Section 8.1 for the "crypto" attribute follows the format (see Section 8.1 for the formal
formal ABNF grammar): ABNF grammar):
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>] a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
The fields tag, crypto-suite, key-params, and session-params are The fields tag, crypto-suite, key-params, and session-params are
described in the following sub-sections. Below we show an example described in the following sub-sections. Below we show an example of
of the crypto attribute for the "RTP/SAVP" transport, i.e., the the crypto attribute for the "RTP/SAVP" transport, i.e., the secure
secure RTP extension to the Audio/Video Profile [srtp]. In the RTP extension to the Audio/Video Profile [srtp]. In the following,
following, newlines are included for formatting reasons only: newlines are included for formatting reasons only:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined
by the text starting with "inline:", and session-params is omitted. by the text starting with "inline:", and session-params is omitted.
3.1 Tag 3.1 Tag
The tag is a decimal number used as an identifier for a particular The tag is a decimal number used as an identifier for a particular
crypto attribute (see Section 8.1 for details). The tag MUST be crypto attribute (see Section 8.1 for details). The tag MUST be
unique among all crypto attributes for a given media line. It is unique among all crypto attributes for a given media line. It is
used with the offer/answer model to determine which of several used with the offer/answer model to determine which of several
offered crypto attributes were chosen by the answerer (see Section offered crypto attributes were chosen by the answerer (see Section
4.1). 4.1).
In the offer/answer model, the tag is a negotiated parameter. In the offer/answer model, the tag is a negotiated parameter.
3.2 Crypto-suite 3.2 Crypto-suite
The crypto-suite field is an identifier that describes the The crypto-suite field is an identifier that describes the encryption
encryption and authentication algorithms (e.g., and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for
AES_CM_128_HMAC_SHA1_80) for the transport in question (see Section the transport in question (see Section 8.1 for details). The
8.1 for details). The possible values for the crypto-suite possible values for the crypto-suite parameter are defined within the
parameter are defined within the context of the transport, i.e., context of the transport, i.e., each transport defines a separate
each transport defines a separate namespace for the set of crypto- namespace for the set of crypto-suites. For example, the crypto-
suites. For example, the crypto-suite "AES_CM_128_HMAC_SHA1_80" suite "AES_CM_128_HMAC_SHA1_80" defined within the context
defined within the context "RTP/SAVP" transport applies to Secure "RTP/SAVP" transport applies to Secure RTP only; the string may be
RTP only; the string may be reused for another transport (e.g., reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a
"RTP/SAVPF" [srtpf]), but a separate definition would be needed. separate definition would be needed.
In the offer/answer model, the crypto-suite is a negotiated In the offer/answer model, the crypto-suite is a negotiated
parameter. parameter.
3.3 Key Parameters 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
for the crypto-suite in question. The field consists of a method the crypto-suite in question. The field consists of a method
indicator followed by a colon, and the actual keying information as indicator followed by a colon, and the actual keying information as
shown below (the formal grammar is provided in Section 8.1): shown below (the formal grammar is provided in Section 8.1):
key-params = <key-method> ":" <key-info> key-params = <key-method> ":" <key-info>
Keying material might be provided by different means than key- Keying material might be provided by different means than key-params,
params, however this is out of scope. Only one method is defined in however this is out of scope. Only one method is defined in this
this document, namely "inline", which indicates that the actual document, namely "inline", which indicates that the actual keying
keying material is provided in the key-info field itself. There is material is provided in the key-info field itself. There is a single
a single name space for the key-method, i.e., the key-method is name space for the key-method, i.e., the key-method is transport
transport independent. New key-methods (e.g., use of a URL) may be independent. New key-methods (e.g., use of a URL) may be defined in
defined in a Standards Track RFC in the future. Although the key- a Standards Track RFC in the future. Although the key-method itself
method itself may be generic, the accompanying key-info definition may be generic, the accompanying key-info definition is specific not
is specific not only to the key-method, but also to the transport in only to the key-method, but also to the transport in question. New
question. New key methods MUST be registered with the IANA key methods MUST be registered with the IANA according to the
according to the procedures defined in Section 9.2.1. procedures defined in Section 9.2.1.
Key-info is defined as a general character string (see Section 8.1 Key-info is defined as a general character string (see Section 8.1
for details); further transport and key-method specific syntax and for details); further transport and key-method specific syntax and
semantics MUST be provided in a Standards Track RFC for each semantics MUST be provided in a Standards Track RFC for each
combination of transport and key-method that use it; definitions for combination of transport and key-method that use it; definitions for
SRTP are provided in Section 5. Note that such definitions are SRTP are provided in Section 5. Note that such definitions are
provided within the context of both a particular transport (e.g., provided within the context of both a particular transport (e.g.,
"RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will
register the list of supported key methods for each transport. register the list of supported key methods for each transport.
When multiple keys are included in the key parameters, it MUST be When multiple keys are included in the key parameters, it MUST be
possible to determine which of the keys is being used in a given possible to determine which of the keys is being used in a given
media packet by a simple inspection of the media packet received; a media packet by a simple inspection of the media packet received; a
trial-and-error approach between the possible keys MUST NOT be trial-and-error approach between the possible keys MUST NOT be
performed. performed.
For SRTP, this could be achieved by use of Master Key Identifiers For SRTP, this could be achieved by use of Master Key Identifiers
(MKI), or <"From", "To"> values [srtp]. (MKI) [srtp]. Use of <"From, "To"> values are not supported in
SRTP security descriptions for reasons explained in Section 5.1,
below.
In the offer/answer model, the key parameter is a declarative In the offer/answer model, the key parameter is a declarative
parameter. parameter.
3.4 Session Parameters 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 security descriptions framework, where they are is OPTIONAL in the security descriptions framework, where they are
just defined as general character strings. If session parameters just defined as general character strings. If session parameters are
are to be used for a given transport, then transport-specific syntax to be used for a given transport, then transport-specific syntax and
and semantics MUST be provided in a Standards Track RFC; definitions semantics MUST be provided in a Standards Track RFC; definitions for
for SRTP are provided in Section 5. SRTP are provided in Section 5.
In the offer/answer model, session parameters may be either In the offer/answer model, session parameters may be either
negotiated or declarative; the definition of specific session negotiated or declarative; the definition of specific session
parameters MUST indicate whether they are negotiated or declarative. parameters MUST indicate whether they are negotiated or declarative.
Negotiated parameters apply to data sent in both directions, whereas Negotiated parameters apply to data sent in both directions, whereas
declarative parameters apply only to media sent by the entity that declarative parameters apply only to media sent by the entity that
generated the SDP. Thus, a declarative parameter in an offer generated the SDP. Thus, a declarative parameter in an offer applies
applies to media sent by the offerer, whereas a declarative to media sent by the offerer, whereas a declarative parameter in an
parameter in an answer applies to media sent by the answerer. answer applies to media sent by the answerer.
3.5 Example 3.5 Example
This example shows use of the crypto attribute for the "RTP/SAVP" This example shows use of the crypto attribute for the "RTP/SAVP"
media transport type (as defined in Section 4). The "a=crypto" line media transport type (as defined in Section 4). The "a=crypto" line
is actually one long line; it is shown as two lines due to page is actually one long line; it is shown as two lines due to page
formatting: formatting:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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
The general offer/answer rules for the crypto attribute are in The general offer/answer rules for the crypto attribute are in
addition to the rules specified in RFC 3264, which MUST be followed, addition to the rules specified in RFC 3264, which MUST be followed,
unless otherwise noted. RFC 3264 defines operation for both unicast unless otherwise noted. RFC 3264 defines operation for both unicast
and multicast streams; the sections below describe operation for and multicast streams; the sections below describe operation for two-
two-party unicast streams only, since support for multicast streams party unicast streams only, since support for multicast streams (and
(and multipoint unicast streams) is for further study. multipoint unicast streams) is for further study.
4.1.1 Generating the Initial Offer - 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
which security is desired. Each crypto attribute for a given media security is desired. Each crypto attribute for a given media stream
stream MUST contain a unique tag. MUST contain a unique tag.
The ordering of multiple "a=crypto" lines is significant: The most The ordering of multiple "a=crypto" lines is significant: The most
preferred crypto line is listed first. Each crypto attribute preferred crypto line is listed first. Each crypto attribute
describes the crypto-suite, key(s) and possibly session parameters describes the crypto-suite, key(s) and possibly session parameters
offered for the media stream. In general, a "more preferred" offered for the media stream. In general, a "more preferred" crypto-
crypto-suite SHOULD be cryptographically stronger than a "less suite SHOULD be cryptographically stronger than a "less preferred"
preferred" crypto-suite. crypto-suite.
The crypto-suite always applies to media in the directions supported The crypto-suite always applies to media in the directions supported
by the media stream (e.g., send and receive). The key(s), however, by the media stream (e.g., send and receive). The key(s), however,
apply to media in the direction from the offerer to the answerer; if 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 the media stream is marked as "recvonly", a key MUST still be
provided. provided.
This is done for consistency. Also, in the case of SRTP, for This is done for consistency. Also, in the case of SRTP, for
example, 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.
The offer may include session parameters. There are no general The offer may include session parameters. There are no general offer
offer rules for the session parameters; instead, specific rules may rules for the session parameters; instead, specific rules may be
be provided as part of the transport-specific definitions of any provided as part of the transport-specific definitions of any session
session parameters. 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. Second, the offerer may not be using for media sent to the offerer. Second, the offerer may not
be able to deduce which of the offered crypto attributes were be able to deduce which of the offered crypto attributes were
accepted. Since media may arrive prior to the answer, delay or accepted. Since media may arrive prior to the answer, delay or
clipping can occur. If this is unacceptable to the offerer, the clipping can occur. If this is unacceptable to the offerer, the
offerer SHOULD use a mechanism outside the scope of this document to offerer SHOULD use a mechanism outside the scope of this document to
prevent the above problem. prevent the above problem.
For example, in SIP [RFC3261], a "security" precondition as For example, in SIP [RFC3261], a "security" precondition as defined
defined in [sprecon] could solve the above problem. in [sprecon] could solve the above problem.
4.1.2 Generating the Initial Answer - 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
either accept exactly one of the offered crypto attributes, or the accept exactly one of the offered crypto attributes, or the offered
offered stream MUST be rejected. stream MUST be rejected.
If the answerer wishes to indicate support for other crypto If the answerer wishes to indicate support for other crypto
attributes, those can be listed by use of the SDP Simple attributes, those can be listed by use of the SDP Simple Capability
Capability Declaration [RFC3407] extensions. Declaration [RFC3407] extensions.
Only crypto attributes that are valid can be accepted; valid Only crypto attributes that are valid can be accepted; valid
attributes do not violate any of the general rules defined for attributes do not violate any of the general rules defined for
security descriptions as well as any specific rules defined for the security descriptions as well as any specific rules defined for the
transport and key-method in question. When selecting one of the transport and key-method in question. When selecting one of the
valid crypto attributes, the answerer SHOULD select the most valid crypto attributes, the answerer SHOULD select the most
preferred crypto attribute it can support, i.e., the first valid preferred crypto attribute it can support, i.e., the first valid
supported crypto attribute in the list, considering the answerer's supported crypto attribute in the list, considering the answerer's
capabilities and security policies. capabilities and security policies.
If there are 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.
When an offered crypto attribute is accepted, the crypto attribute When an offered crypto attribute is accepted, the crypto attribute in
in the answer MUST contain the following: the answer MUST contain the following:
* The tag and crypto-suite from the accepted crypto attribute in the * The tag and crypto-suite from the accepted crypto attribute in the
offer (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. Note that a key MUST be provided, irrespective of any offerer. Note that a key MUST be provided, irrespective of any
direction attributes in the offer or answer. direction attributes in the offer or answer.
Furthermore, any session parameters that are negotiated MUST be Furthermore, any session parameters that are negotiated MUST be
included in the answer. Declarative session parameters provided by included in the answer. Declarative session parameters provided by
the offerer are not included in the answer, however the answerer may the offerer are not included in the answer, however the answerer may
provide its own set of declarative session parameters. provide its own set of declarative session parameters.
Once the answerer has accepted one of the offered crypto attributes, Once the answerer has accepted one of the offered crypto attributes,
the answerer MAY begin sending media to the offerer in accordance the answerer MAY begin sending media to the offerer in accordance
with the selected crypto attribute. Note however, that the offerer with the selected crypto attribute. Note however, that the offerer
may not be able to process such media packets correctly until the may not be able to process such media packets correctly until the
answer has been received. answer has been received.
4.1.3 Offerer Processing of the Initial Answer - Unicast Streams 4.1.3 Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, the offerer MUST verify, that When the offerer receives the answer, the offerer MUST verify, that
one of the initially offered crypto suites and its accompanying tag one of the initially offered crypto suites and its accompanying tag
was accepted and echoed in the answer. Also, the answer MUST was accepted and echoed in the answer. Also, the answer MUST include
include one or more keys, which will be used for media sent from the one or more keys, which will be used for media sent from the answerer
answerer to the offerer. to the offerer.
If the offer contained any mandatory negotiated session parameters If the offer contained any mandatory negotiated session parameters
(see section 5.3.7), the offerer MUST verify that said parameters (see section 5.3.7), the offerer MUST verify that said parameters are
are included in the answer and support them. If the answer contains included in the answer and support them. If the answer contains any
any mandatory declarative session parameters, the offerer MUST be mandatory declarative session parameters, the offerer MUST be able to
able to support those. support those.
If any of the above fails, the negotiation MUST fail. If any of the above fails, the negotiation MUST fail.
4.1.4 Modifying the Session 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 be triggered by the security service, e.g., in order to perform a re-
re-keying or change the crypto-suite. If media stream security keying or change the crypto-suite. If media stream security using
using the general security descriptions defined here is still the general security descriptions defined here is still desired, the
desired, the crypto attribute MUST be included in these new crypto attribute MUST be included in these new offer/answer
offer/answer exchanges. The procedures are similar to those defined exchanges. The procedures are similar to those defined in Section
in Section 4.1.1, 4.1.2, 4.1.3 of this document, subject to the 4.1.1, 4.1.2, 4.1.3 of this document, subject to the considerations
considerations provided in RFC 3264 Section 8. provided in RFC 3264 Section 8.
4.2 Use Outside Offer/Answer 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 where there is no negotiation of the crypto suite, offer/answer where there is no negotiation of the crypto suite,
cryptographic key or session parameters. In this case, the sender cryptographic key or session parameters. In this case, the sender
determines security parameters for the stream. Since there is no determines security parameters for the stream. Since there is no
negotiation mechanisms, the sender MUST include exactly one crypto negotiation mechanisms, the sender MUST include exactly one crypto
attribute and the receiver MUST either accept it or else SHOULD NOT attribute and the receiver MUST either accept it or else SHOULD NOT
receive the associated stream. The sender SHOULD select the receive the associated stream. The sender SHOULD select the security
security description that it deems most secure for its purposes. description that it deems most secure for its purposes.
4.3 General Backwards Compatibility Considerations 4.3 General Backwards Compatibility Considerations
In the offer/answer model, it is possible that the answerer supports In the offer/answer model, it is possible that the answerer supports
a given secure transport (e.g., "RTP/SAVP") and accepts the offered a given secure transport (e.g., "RTP/SAVP") and accepts the offered
media stream, yet the answerer does not support the crypto attribute media stream, yet the answerer does not support the crypto attribute
defined in this document and hence ignores it. The offerer can defined in this document and hence ignores it. The offerer can
recognize this situation by seeing an accepted media stream in the recognize this situation by seeing an accepted media stream in the
answer that does not include a crypto line. In that case, the answer that does not include a crypto line. In that case, the
security negotiation defined here MUST fail. security negotiation defined here MUST fail.
Similar issues exist when security descriptions are used outside of Similar issues exist when security descriptions are used outside of
the offer/answer model. But the source of a non-negotiated security the offer/answer model. But the source of a non-negotiated security
description has no indication that the receiver has ignored the description has no indication that the receiver has ignored the
crypto attribute. crypto attribute.
5. SRTP Security Descriptions 5. SRTP Security Descriptions
In this section, we provide definitions for security descriptions In this section, we provide definitions for security descriptions for
for SRTP media streams. In the next section, we define how to use SRTP media streams. In the next section, we define how to use SRTP
SRTP security descriptions with and without the offer/answer model. security descriptions with and without the offer/answer model.
SRTP security descriptions MUST only be used with the SRTP transport SRTP security descriptions MUST only be used with the SRTP transport
(e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security
descriptions for the "RTP/SAVP" profile defined in [srtp], however descriptions for the "RTP/SAVP" profile defined in [srtp], however it
it is expected that other secure RTP profiles (e.g., "RTP/SAVPF") is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can
can use the same descriptions, which are in accordance with the SRTP use the same descriptions, which are in accordance with the SRTP
protocol specification [srtp]. protocol specification [srtp].
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 according to the SDP. Hence the endpoint will simply ignore it according to the SDP. Hence the endpoint will simply
skipping to change at page 12, line 47 skipping to change at page 12, line 47
associated with a master key, and MUST NOT accept incoming packets associated with a master key, and MUST NOT accept incoming packets
that violate the policy (e.g., after the master key lifetime has that violate the policy (e.g., after the master key lifetime has
expired). expired).
The key parameter contains one or more cryptographic master keys, The key parameter contains one or more cryptographic master keys,
each of which MUST be a unique cryptographically random [RFC1750] each of which MUST be a unique cryptographically random [RFC1750]
value with respect to other master keys in the entire SDP message value with respect to other master keys in the entire SDP message
(i.e., including master keys for other streams). Each key follows (i.e., including master keys for other streams). Each key follows
the format (the formal definition is provided in Section 8.2): the format (the formal definition is provided in Section 8.2):
"inline:" <key||salt> "|" [lifetime] "|" [MKI ":" length / FromTo] "inline:" <key||salt> "|" [lifetime] "|" [MKI ":" length]
key||salt concatenated master key and salt, base64 encoded key||salt concatenated master key and salt, base64 encoded
(see [RFC3548], Section 3) (see [RFC3548], Section 3)
lifetime master key lifetime (max number of SRTP or SRTCP lifetime master key lifetime (max number of SRTP or SRTCP
packets using this master key) packets using this master key)
MKI:length MKI and length of the MKI field in SRTP packets MKI:length MKI and length of the MKI field in SRTP packets
FromTo <"From", "To"> values, specifying the lifetime for
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
crypto attribute in question MUST be considered invalid. Each crypto attribute in question MUST be considered invalid. Each master
master key and salt MUST be a cryptographically random number and key and salt MUST be a cryptographically random number and MUST be
MUST be unique to the entire SDP message. When base64 decoding the unique to the entire SDP message. When base64 decoding the key and
key and salt, padding characters (i.e., one or two "=" at the end of salt, padding characters (i.e., one or two "=" at the end of the
the base64 encoded data) are discarded (see [RFC3548] for details). base64 encoded data) are discarded (see [RFC3548] for details).
Base64 encoding assumes that the base64 encoding input is an Base64 encoding assumes that the base64 encoding input is an integral
integral number of octets. If a given crypto-suite requires the use number of octets. If a given crypto-suite requires the use of a
of a concatenated key and salt with a length that is not an integral concatenated key and salt with a length that is not an integral
number of octets, said crypto-suite MUST define a padding scheme number of octets, said crypto-suite MUST define a padding scheme that
that results in the base64 input being an integral number of octets. results in the base64 input being an integral number of octets. For
For example, if the length defined was 250 bits, then 6 padding bits example, if the length defined was 250 bits, then 6 padding bits
would be needed, which could be defined to be the last 6 bits in a would be needed, which could be defined to be the last 6 bits in a
256 bit input. 256 bit input.
The second field, is the OPTIONAL lifetime of the master key as The second field, is the OPTIONAL lifetime of the master key as
measured in maximum number of SRTP or SRTCP packets using that measured in maximum number of SRTP or SRTCP packets using that master
master key (i.e., the number of SRTP packets and the number of SRTCP key (i.e., the number of SRTP packets and the number of SRTCP packets
packets each have to be less than the lifetime). The lifetime value each have to be less than the lifetime). The lifetime value MAY be
MAY be written as a non-zero, positive integer or as a power of 2 written as a non-zero, positive integer or as a power of 2 (see the
(see the grammar in Section 8.2 for details). The "lifetime" value grammar in Section 8.2 for details). The "lifetime" value MUST NOT
MUST NOT exceed the maximum packet lifetime for the crypto-suite. exceed the maximum packet lifetime for the crypto-suite. If the
If the lifetime is too large or otherwise invalid then the entire lifetime is too large or otherwise invalid then the entire crypto
crypto attribute MUST be considered invalid. The default MAY be attribute MUST be considered invalid. The default MAY be implicitly
implicitly signaled by omitting the lifetime value (i.e., "||"). signaled by omitting the lifetime value (i.e., "||"). This is
This is convenient when the SRTP cryptographic key lifetime is the convenient when the SRTP cryptographic key lifetime is the default
default value. As a shortcut to avoid long decimal values, the value. As a shortcut to avoid long decimal values, the syntax of the
syntax of the lifetime allows using the literal "2^", which lifetime allows using the literal "2^", which indicates "two to the
indicates "two to the power of". The example above, shows a case power of". The example above, shows a case where the lifetime is
where the lifetime is specified as 2^20. The following example, specified as 2^20. The following example, which is for the
which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime
for the lifetime field, which means that SRTP's and SRTCP's default field, which means that SRTP's and SRTCP's default values will be
values will be used (see [srtp]): used (see [srtp]):
inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4
The example shows a 30-character key and concatenated salt that is The example shows a 30-character key and concatenated salt that is
base64 encoded: The 30-character key/salt concatenation is expanded base64 encoded: The 30-character key/salt concatenation is expanded
to 40 characters by the three-in-four encoding of base64. to 40 characters by the three-in-four encoding of base64.
The third field, which is also OPTIONAL, is either the Master Key The third field, which is also OPTIONAL, is the Master Key Identifier
Identifier (MKI) and its byte length, or a <"From", "To"> value. (MKI) and its byte length.
"MKI" is the master key identifier associated with the SRTP master "MKI" is the master key identifier associated with the SRTP master
key. If the MKI is given, then the length of the MKI MUST also be key. If the MKI is given, then the length of the MKI MUST also be
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
is the size of the MKI field in the SRTP packet, specified in bytes. the size of the MKI field in the SRTP packet, specified in bytes. If
If the MKI length is not given or its value exceeds 128 (bytes), the MKI length is not given or its value exceeds 128 (bytes), then
then the entire crypto attribute MUST be considered invalid. The the entire crypto attribute MUST be considered invalid. The
substring "1:4" in the first example assigns to the key a master key substring "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 master 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 SRTP offers a second feature for specifying the lifetime of a master
terms of the ROC and SEQ values inside whose range (including the key in terms of two values, called "From" and "To," which are defined
range ends) the master key is valid. <"From", "To"> is an on the SRTP sequence number space [srtp]. This SRTP Security
alternative to the MKI and assumes that a master key is in one-to- Descriptions specification, however, does not support the
one correspondence with the SRTP session key on which the <"From", <"From","To"> feature since the lifetime of an AES master key is 2^48
"To"> range is defined (see [srtp, Section 8.1.1] for details). The SRTP packets, which means that there is no cryptographic reason to
following example illustrates the use of the <"From", "To"> replace a master key for practical point-to-point applications. For
parameter: this reason, there is no need to support two means for signaling key
update. The MKI is chosen over <"From","To"> by this specification
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|FT=0:0,1:0 for the very few applications that need it since the MKI feature is
simpler (though the MKI adds additional bytes to each packet whereas
<"From", "To"> does not).
As mentioned above, the key parameter can contain one or more master As mentioned above, the key parameter can contain one or more master
keys. When the key parameter contains more than one master key, all keys. When the key parameter contains more than one master key, all
of the master keys in that key parameter MUST either include an MKI of the master keys in that key parameter MUST include an MKI value.
or a <"From", "To"> value. Note that it is not permissible to mix When using the MKI, the MKI length MUST be the same for all keys in a
the two within a single key parameter (i.e., one crypto attribute); given crypto attribute.
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 are described specification has defined three crypto-suites, which are described
further in the following subsections in the context of the SRTP further in the following subsections in the context of the SRTP
security descriptions. The table below provides an overview of the security descriptions. The table below provides an overview of the
crypto-suites and their parameters: crypto-suites and their parameters:
skipping to change at page 17, line 30 skipping to change at page 17, line 30
The SRTP specification requires use of message authentication for The SRTP specification requires use of message authentication for
SRTCP, but not for SRTP [srtp]. SRTCP, but not for SRTP [srtp].
In the offer/answer model, this parameter is negotiated. In the offer/answer model, this parameter is negotiated.
5.3.4 FEC_ORDER=order 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 or SRTP_FEC. FEC_SRTP signals that FEC is applied are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied
before SRTP processing by the sender of the SRTP media and after before SRTP processing by the sender of the SRTP media and after SRTP
SRTP processing by the receiver of the SRTP media; FEC_SRTP is the processing by the receiver of the SRTP media; FEC_SRTP is the
default. SRTP_FEC is the reverse processing. default. SRTP_FEC is the reverse processing.
In the offer/answer model, FEC_ORDER is a declarative parameter. In the offer/answer model, FEC_ORDER is a declarative parameter.
5.3.5 FEC_KEY=key-params 5.3.5 FEC_KEY=key-params
FEC_KEY signals the use of separate master key(s) for a Forward FEC_KEY signals the use of separate master key(s) for a Forward
Error Correction (FEC) stream. The master key(s) are specified with Error Correction (FEC) stream. The master key(s) are specified with
the exact same format as the SRTP Key Parameter defined in Section the exact same format as the SRTP Key Parameter defined in Section
5.1, and the semantic rules are the same - in particular, the master 5.1, and the semantic rules are the same - in particular, the master
skipping to change at page 18, line 39 skipping to change at page 18, line 39
New SRTP session parameters are by default mandatory. A newly- New SRTP session parameters are by default mandatory. A newly-
defined SRTP session parameter that is prefixed with the dash defined SRTP session parameter that is prefixed with the dash
character ("-") however is considered optional and MAY be ignored. character ("-") however is considered optional and MAY be ignored.
If an SDP crypto attribute is received with an unknown session If an SDP crypto attribute is received with an unknown session
parameter that is not prefixed with a "-" character, that crypto parameter that is not prefixed with a "-" character, that crypto
attribute MUST be considered invalid. attribute MUST be considered invalid.
5.4 SRTP Crypto Context Initialization 5.4 SRTP Crypto Context Initialization
In addition to the various SRTP parameters defined above, there are In addition to the various SRTP parameters defined above, there are
three pieces of information that are critical to the operation of three pieces of information that are critical to the operation of the
the default SRTP ciphers: default SRTP ciphers:
* SSRC: Synchronization source * SSRC: Synchronization source
* ROC: Roll-over counter for a given SSRC * ROC: Roll-over counter for a given SSRC
* SEQ: Sequence number for a given SSRC * SEQ: Sequence number for a given SSRC
In a unicast session, as defined here, there are three constraints In a unicast session, as defined here, there are three constraints on
on these values. these values.
The first constraint is on the SSRC, which makes an SRTP keystream The first constraint is on the SSRC, which makes an SRTP keystream be
be unique from other participants. As explained in SRTP, the unique from other participants. As explained in SRTP, the keystream
keystream MUST NOT be reused on two or more different pieces of MUST NOT be reused on two or more different pieces of plaintext.
plaintext. Keystream reuse makes the ciphertext vulnerable to Keystream reuse makes the ciphertext vulnerable to cryptanalysis.
cryptanalysis. One vulnerability is that known-plaintext fields in One vulnerability is that known-plaintext fields in one stream can
one stream can expose portions of the reused keystream and this expose portions of the reused keystream and this could further expose
could further expose more plaintext in other streams. Since all more plaintext in other streams. Since all current SRTP encryption
current SRTP encryption transforms use keystreams, key sharing is a transforms use keystreams, key sharing is a general problem [srtp].
general problem [srtp]. SRTP mitigates this problem by including SRTP mitigates this problem by including the SSRC of the sender in
the SSRC of the sender in the keystream. But SRTP does not solve the keystream. But SRTP does not solve this problem in its entirety
this problem in its entirety because Real-time Transport Protocol because Real-time Transport Protocol has SSRC collisions, which are
has SSRC collisions, which are very rare [rtp] but quite possible. very rare [rtp] but quite possible. During a collision, two or more
During a collision, two or more SSRCs that share a master key will SSRCs that share a master key will have identical keystreams for
have identical keystreams for overlapping portions of the RTP overlapping portions of the RTP sequence-number space. SRTP Security
sequence-number space. SRTP Security Descriptions avoids keystream Descriptions avoids keystream reuse by making unique master keys
reuse by making unique master keys REQUIRED for the sender and REQUIRED for the sender and receiver of the security description.
receiver of the security description. Thus, the first constraint is Thus, the first constraint is satisfied.
satisfied.
Also note, that there is a second problem with SSRC collisions: Also note, that there is a second problem with SSRC collisions: The
The SSRC is used to identify the crypto context and thereby the SSRC is used to identify the crypto context and thereby the cipher,
cipher, key, ROC, etc. to process incoming packets. In case of key, ROC, etc. to process incoming packets. In case of SSRC
SSRC collisions, crypto context identification becomes ambiguous collisions, crypto context identification becomes ambiguous and
and correct packet processing may not occur. Furthermore, if an correct packet processing may not occur. Furthermore, if an RTCP
RTCP BYE packet is to be sent for a colliding SSRC, that packet BYE packet is to be sent for a colliding SSRC, that packet may also
may also have to be secured. In a (unicast) point-to-multipoint have to be secured. In a (unicast) point-to-multipoint scenario,
scenario, this can be problematic for the same reasons, i.e., it this can be problematic for the same reasons, i.e., it is not known
is not known which of the possible crypto contexts to use. Note which of the possible crypto contexts to use. Note that these
that these problems are not unique to the SDP security problems are not unique to the SDP security descriptions; any use
descriptions; any use of SRTP needs to consider them. of SRTP needs to consider them.
The second constraint is that the ROC MUST be zero at the time that The second constraint is that the ROC MUST be zero at the time that
each SSRC commences sending packets. Thus, there is no concept of a each SSRC commences sending packets. Thus, there is no concept of a
"late joiner" in SRTP security descriptions, which are constrained "late joiner" in SRTP security descriptions, which are constrained to
to be unicast and pairwise. The ROC and SEQ form a "packet index" be unicast and pairwise. The ROC and SEQ form a "packet index" in
in the default SRTP transforms and the ROC is consistently set to the default SRTP transforms and the ROC is consistently set to zero
zero at session commencement, according to this document. at session commencement, according to this document.
The third constraint is that the initial value of SEQ SHOULD be The third constraint is that the initial value of SEQ SHOULD be
chosen to be within the range of 0..2^15-1; this avoids an ambiguity chosen to be within the range of 0..2^15-1; this avoids an ambiguity
when packets are lost at the start of the session. If at the start when packets are lost at the start of the session. If at the start
of a session, an SSRC source might randomly select a high sequence- of a session, an SSRC source might randomly select a high sequence-
number value and put the receiver in an ambiguous situation: If number value and put the receiver in an ambiguous situation: If
initial packets are lost in transit up to the point that the initial packets are lost in transit up to the point that the sequence
sequence number wraps (i.e., exceeds 2^16-1), then the receiver number wraps (i.e., exceeds 2^16-1), then the receiver might not
might not recognize that its ROC needs to be incremented. By recognize that its ROC needs to be incremented. By restricting the
restricting the initial SEQ to the range of 0..2^15-1, SRTP packet- initial SEQ to the range of 0..2^15-1, SRTP packet-index
index determination will find the correct ROC value, unless all of determination will find the correct ROC value, unless all of the
the first 2^15 packets are lost (which seems, if not impossible, first 2^15 packets are lost (which seems, if not impossible, then
then rather unlikely). See Section 3.3.1 of the SRTP specification rather unlikely). See Section 3.3.1 of the SRTP specification
regarding packet-index determination [srtp]. regarding packet-index determination [srtp].
The packet index, therefore, depends on the SSRC, the SEQ of an The packet index, therefore, depends on the SSRC, the SEQ of an
incoming packet and the ROC, which is an SRTP crypto context incoming packet and the ROC, which is an SRTP crypto context
variable. Thus, SRTP has a big security dependency on SSRC variable. Thus, SRTP has a big security dependency on SSRC
uniqueness. uniqueness.
Given the above constraints, unicast SRTP crypto contexts can be Given the above constraints, unicast SRTP crypto contexts can be
established without the need to negotiate SSRC values in the SRTP established without the need to negotiate SSRC values in the SRTP
security descriptions. Instead, an approach called "late binding" security descriptions. Instead, an approach called "late binding" is
is RECOMMENDED by this specification. When a packet arrives, the RECOMMENDED by this specification. When a packet arrives, the SSRC
SSRC that is contained in it can be bound to the crypto context at that is contained in it can be bound to the crypto context at the
the time of session commencement (i.e., SRTP packet arrival) rather time of session commencement (i.e., SRTP packet arrival) rather than
than at the time of session signaling (i.e., receipt of an SDP). at the time of session signaling (i.e., receipt of an SDP). With the
With the arrival of the packet containing the SSRC, all the data arrival of the packet containing the SSRC, all the data items needed
items needed for the SRTP crypto context are held by the receiver for the SRTP crypto context are held by the receiver (note that the
(note that the ROC value by definition is zero; if non-zero values ROC value by definition is zero; if non-zero values were to be
were to be supported, additional signaling would be required). In supported, additional signaling would be required). In other words,
other words, the crypto context for a secure RTP session using late the crypto context for a secure RTP session using late binding is
binding is initially identified by the SDP as: initially identified by the SDP as:
<*, address, port> <*, address, port>
where '*' is a wildcard SSRC, "address" is the local receive address where '*' is a wildcard SSRC, "address" is the local receive address
from the "c=" line, and "port" is the local receive port from the from the "c=" line, and "port" is the local receive port from the
"m=" line. When the first packet arrives with ssrcX in its SSRC "m=" line. When the first packet arrives with ssrcX in its SSRC
field, the crypto context field, the crypto context
<ssrcX, address, port> <ssrcX, address, port>
skipping to change at page 20, line 41 skipping to change at page 20, line 38
otherwise, the crypto context is not instantiated. otherwise, the crypto context is not instantiated.
* Media packets are not authenticated: Crypto context is * Media packets are not authenticated: Crypto context is
automatically instantiated. automatically instantiated.
It should be noted, that use of late binding when there is no It should be noted, that use of late binding when there is no
authentication of the SRTP media packets is subject to numerous authentication of the SRTP media packets is subject to numerous
security attacks and consequently it is NOT RECOMMENDED (of course, security attacks and consequently it is NOT RECOMMENDED (of course,
this can be said for unauthenticated SRTP in general). this can be said for unauthenticated SRTP in general).
Note that use of late binding without authentication will result Note that use of late binding without authentication will result in
in local state being created as a result of receiving a packet local state being created as a result of receiving a packet from
from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT
RECOMMENDED because it invites easy denial-of-service attack. In RECOMMENDED because it invites easy denial-of-service attack. In
contrast, late binding with authentication does not suffer from contrast, late binding with authentication does not suffer from
this weakness. this weakness.
With the constraints and procedures described above, it is not With the constraints and procedures described above, it is not
necessary to explicitly signal the SSRC, ROC and SEQ for a unicast necessary to explicitly signal the SSRC, ROC and SEQ for a unicast
SRTP session. SRTP session.
5.5 Removal of Crypto Contexts 5.5 Removal of Crypto Contexts
The mechanism defined above addresses the issue of creating crypto The mechanism defined above addresses the issue of creating crypto
contexts, however in practice, session participants may want to contexts, however in practice, session participants may want to
remove crypto contexts prior to session termination. Since a crypto remove crypto contexts prior to session termination. Since a crypto
context contains information that can not automatically be recovered context contains information that can not automatically be recovered
(e.g., ROC), it is important that the sender and receiver agree on (e.g., ROC), it is important that the sender and receiver agree on
when a crypto context can be removed, and perhaps more importantly when a crypto context can be removed, and perhaps more importantly
when it cannot. when it cannot.
Even when late binding is used for a unicast stream, the ROC is Even when late binding is used for a unicast stream, the ROC is
lost and cannot be recovered automatically (unless it is zero) lost and cannot be recovered automatically (unless it is zero) once
once the crypto context is removed. the crypto context is removed.
We resolve this problem as follows. When SRTP security descriptions We resolve this problem as follows. When SRTP security descriptions
are being used, crypto-context removal MUST follow the same rules as are being used, crypto-context removal MUST follow the same rules as
SSRC removal from the member table [RFC 3550]; note that this can SSRC removal from the member table [RFC 3550]; note that this can
happen as the result of an SRTCP BYE packet or a simple time-out due happen as the result of an SRTCP BYE packet or a simple time-out due
to inactivity. Inactive session participants that wish to ensure to inactivity. Inactive session participants that wish to ensure
their crypto contexts are not timed out MUST thus send SRTCP packets their crypto contexts are not timed out MUST thus send SRTCP packets
at regular intervals. at regular intervals.
6. SRTP-Specific Use of the crypto Attribute 6. SRTP-Specific Use of the crypto Attribute
skipping to change at page 22, line 29 skipping to change at page 22, line 29
Error Correction with a different IP-address and/or port than the Error Correction with a different IP-address and/or port than the
media stream itself, a FEC_KEY parameter MUST be included, as media stream itself, a FEC_KEY parameter MUST be included, as
described in Section 5.3.5. described in Section 5.3.5.
When the answerer accepts an SRTP unicast media stream with a crypto When the answerer accepts an SRTP unicast media stream with a crypto
line, the answerer MUST include one or more master keys appropriate line, the answerer MUST include one or more master keys appropriate
for the selected crypto algorithm; the master key(s) included in the for the selected crypto algorithm; the master key(s) included in the
answer MUST be different from those in the offer. answer MUST be different from those in the offer.
When the master key(s) are not shared between the offerer and When the master key(s) are not shared between the offerer and
answerer, SSRC collisions between the offerer and answerer will answerer, SSRC collisions between the offerer and answerer will not
not lead to keystream reuse, and hence SSRC collisions do not lead to keystream reuse, and hence SSRC collisions do not
necessarily have to be prevented. necessarily have to be prevented.
If Forward Error Correction to a separate IP-address and/or port is If Forward Error Correction to a separate IP-address and/or port is
included, the answer MUST include a FEC_KEY parameter, as described included, the answer MUST include a FEC_KEY parameter, as described
in Section 5.3.5. in Section 5.3.5.
Declarative session parameters may be added to the answer as usual, Declarative session parameters may be added to the answer as usual,
however the answerer SHOULD NOT add any mandatory session parameter however the answerer SHOULD NOT add any mandatory session parameter
(see Section 5.3.6) that might be unknown to the offerer. (see Section 5.3.6) that might be unknown to the offerer.
If the answerer cannot find any valid crypto line that it supports, If the answerer cannot find any valid crypto line that it supports,
or if its configured policy prohibits any cryptographic key or if its configured policy prohibits any cryptographic key
parameter (e.g., key length) or cryptographic session parameter parameter (e.g., key length) or cryptographic session parameter
(e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it
is able to successfully negotiate use of SRTP by other means outside is able to successfully negotiate use of SRTP by other means outside
the scope of this document (e.g., by use of MIKEY [mikey]). the scope of this document (e.g., by use of MIKEY [mikey]).
6.1.3 Offerer Processing of the Initial Answer - Unicast Streams 6.1.3 Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, it MUST perform the steps in When the offerer receives the answer, it MUST perform the steps in
Section 4.1.3 as well as the following steps for each SRTP media Section 4.1.3 as well as the following steps for each SRTP media
stream it offered with one or more crypto lines in it. stream it offered with one or more crypto lines in it.
If the media stream was accepted and it contains a crypto line, it If the media stream was accepted and it contains a crypto line, it
MUST be checked that the crypto line is valid according to the MUST be checked that the crypto line is valid according to the
constraints specified in Section 5 (including any FEC constraints). constraints specified in Section 5 (including any FEC constraints).
If the offerer either does not support or is not willing to honor If the offerer either does not support or is not willing to honor
skipping to change at page 23, line 41 skipping to change at page 23, line 41
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 use the MKI to deal with
of dealing with this; use the MKI (which adds a few bytes to each this (which adds a few bytes to each SRTP packet) as described in
SRTP packet) or the <"From","To"> mechanism (which doesn't add Section 5.1. For further details on the MKI, please refer to
bytes to each SRTP packet) as described in Section 5.1. For [srtp].
further details on MKI and "<"From","To">, please refer to [srtp].
* If the answerer changes its master key, the offerer will not * If the answerer changes its master key, the offerer will not
be able to process packets secured via this master key until the be able to process packets secured via this master key until the
answer is received. This could be addressed by using a security answer is received. This could be addressed by using a security
"precondition" [sprecon]. "precondition" [sprecon].
If the offerer includes an IP address and/or port that differs from If the offerer includes an IP address and/or port that differs from
that used previously for a media stream (or FEC stream), the offerer that used previously for a media stream (or FEC stream), the offerer
MUST include a new master key with the offer (and in so doing, it MUST include a new master key with the offer (and in so doing, it
will be creating a new crypto context with the ROC set to zero). will be creating a new crypto context with the ROC set to zero).
skipping to change at page 24, line 30 skipping to change at page 24, line 28
if the relay changes the media endpoint on one side transparently to if the relay changes the media endpoint on one side transparently to
the other side, the relay cannot operate as a simple packet the other side, the relay cannot operate as a simple packet
reflector but will have to actively engage in SRTP packet processing reflector but will have to actively engage in SRTP packet processing
and transformation (i.e., decryption and re-encryption, etc.). and transformation (i.e., decryption and re-encryption, etc.).
Finally note, that if the new offer is rejected, the old crypto Finally note, that if the new offer is rejected, the old crypto
parameters remain in place. parameters remain in place.
6.1.5 Offer/Answer Example 6.1.5 Offer/Answer Example
In this example, the offerer supports two crypto suites (F8 and In this example, the offerer supports two crypto suites (F8 and AES).
AES). The a=crypto line is actually one long line, although it is The a=crypto line is actually one long line, although it is shown as
shown as two lines in this document due to page formatting. 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
skipping to change at page 29, line 25 skipping to change at page 29, line 25
key-method = srtp-key-method key-method = srtp-key-method
key-info = srtp-key-info key-info = srtp-key-info
session-param = srtp-session-param session-param = srtp-session-param
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" / "AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext srtp-crypto-suite-ext
srtp-key-method = "inline" srtp-key-method = "inline"
srtp-key-info = key-salt "|" [lifetime] "|" [mki / FromTo] srtp-key-info = key-salt "|" [lifetime] "|" [mki]
key-salt = 1*(base64) ; binary key and salt values key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then ; concatenated together, and then
; base64 encoded [section 6.8 of ; base64 encoded [section 6.8 of
; RFC2046] ; RFC2046]
lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^" lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^"
mki = mki-value ":" mki-length mki = mki-value ":" mki-length
mki-value = 1*DIGIT mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128. mki-length = 1*3DIGIT ; range 1..128.
FromTo = "FT=" ftval "," ftval
ftval = roc ":" seq ; packet index expressed in terms
; of ROC and SEQ.
roc = 1*DIGIT ; range 0..2^32-1
seq = 1*DIGIT ; range 0..2^16-1
srtp-session-param = kdr / srtp-session-param = kdr /
"UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" / "UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" / "UNAUTHENTICATED_SRTP" /
fec-order / fec-order /
fec-key / fec-key /
wsh / wsh /
srtp-session-extension srtp-session-extension
skipping to change at page 30, line 30 skipping to change at page 30, line 25
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
9.2 New IANA Registries and Registration Procedures 9.2 New IANA Registries and Registration Procedures
The following sub-sections define a new IANA registry with The following sub-sections define a new IANA registry with associated
associated sub-registries to be used for the SDP security sub-registries to be used for the SDP security descriptions. The
descriptions. The IANA is hereby requested to create an SDP IANA is hereby requested to create an SDP Security Description
Security Description registry as shown below and further described registry as shown below and further described in the following
in the following sections: sections:
SDP Security Descriptions SDP Security Descriptions
| |
+- Key Methods (described in 9.2.1) +- Key Methods (described in 9.2.1)
| |
+- Media Stream Transports (described in 9.2.2) +- Media Stream Transports (described in 9.2.2)
| |
+- Transport1 (e.g. SRTP) +- Transport1 (e.g. SRTP)
| | | |
| +- Supported Key Methods (e.g. inline) | +- Supported Key Methods (e.g. inline)
| | | |
| +- crypto suites | +- crypto suites
| | | |
| +- session parameters | +- session parameters
| |
+- Transport2 +- Transport2
: : : :
9.2.1 Security Descriptions Key Method Registry and Registration 9.2.1 Key Method Registry and Registration
The IANA is hereby requested to create a new subregistry for SDP The IANA is hereby requested to create a new subregistry for SDP
security description key methods. An IANA key method registration security description key methods. An IANA key method registration
MUST be documented in an RFC in accordance with the RFC 2434 MUST be documented in an RFC in accordance with the RFC 2434
Standards Action and it MUST provide the name of the key method in Standards Action and it MUST provide the name of the key method in
accordance with the grammar for key-method-ext defined in Section accordance with the grammar for key-method-ext defined in Section
8.1. 8.1.
9.2.2 Security Description Media Stream Transport Registry and 9.2.2 Media Stream Transport Registry and Registration
Registration
The IANA is hereby requested to create a new subregistry for SDP The IANA is hereby requested to create a new subregistry for SDP
security description Media Stream Transports. An IANA media stream security description Media Stream Transports. An IANA media stream
transport registration MUST be documented in an RFC in accordance transport registration MUST be documented in an RFC in accordance
with the RFC 2434 Standards Action and the procedures defined in with the RFC 2434 Standards Action and the procedures defined in
Section 3 and 4 of this document. The registration MUST provide the Section 3 and 4 of this document. The registration MUST provide the
name of the transport and a list of supported key methods. name of the transport and a list of supported key methods.
In addition, each new media stream transport registry must contain a In addition, each new media stream transport registry must contain a
crypto-suite registry and a session parameter registry as well as crypto-suite registry and a session parameter registry as well as
 End of changes. 

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