draft-ietf-mmusic-sdescriptions-01.txt   draft-ietf-mmusic-sdescriptions-02.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: December 2003 Cisco Systems EXPIRES: April 2004 Cisco Systems
June 27, 2003 October 24, 2003
SDP Security Descriptions for Media Streams Session Description Protocol Security Descriptions
<draft-ietf-mmusic-sdescriptions-01.txt> for Media Streams
<draft-ietf-mmusic-sdescriptions-02.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 line 32 skipping to change at page 2, line ?
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2003). 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 media streams. The attribute describes
a cryptographic key and other parameters, which serve to configure a cryptographic key and other parameters, which serve to configure
security for a media stream. This document defines the Secure Real- security for a media stream in either a single message or a
time Transport Protocol (SRTP) parameters for the attribute. The roundtrip. The attribute can be used with a variety of SDP media
SDP crypto attribute requires the services of a data security transports and this document defines how to use it for the Secure
protocol to secure the SDP message. Real-time Transport Protocol (SRTP) media streams. The SDP crypto
attribute requires the services of a data security protocol to
secure the SDP message.
TABLE OF CONTENTS Table of Contents
1. Notational Conventions............................................2 1. Notational Conventions............................................3
2. Introduction......................................................3 2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters.............................4 3. SDP "Crypto" Attribute and Parameters.............................4
3.1 Crypto-suite....................................................4 3.1 Crypto-suite....................................................5
3.2 Key Parameter...................................................4 3.2 Key Parameters..................................................5
3.4 Session Parameters..............................................5 3.3 Session Parameters..............................................6
3.5 Examples........................................................5 3.4 Example.........................................................6
4. RTP/SAVP (SRTP) Security Descriptions.............................6 4. General Use of the crypto Attribute...............................6
4.1 Crypto-suites...................................................7 4.1 Use With Offer/Answer...........................................7
4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7 4.1.1 Generating the Initial Offer..............................7
4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7 4.1.2 Generating the Initial Answer.............................8
4.1.3 F8_128_HMAC_SHA1_80.........................................7 4.1.3 Offerer Processing of the Initial Answer..................9
4.1.4 Adding new CRYPTO-SUITE definitions.........................8 4.1.4 Modifying the Session....................................10
4.2 Key-param Parameter.............................................8 4.2 Use Outside Offer/Answer: Advertising..........................10
4.2.1 Key Usage...................................................8 4.3 General Backwards Compatibility Considerations.................10
4.2.2 INLINE Definition...........................................8 5. SRTP Security Descriptions.......................................11
4.3 Session Parameters.............................................10 5.2 Crypto-suites..................................................14
4.3.1 SRC=/SSRC/ROC/SEQ..........................................10 5.2.1 AES_CM_128_HMAC_SHA1_80..................................14
4.3.2 KEY_DERIVATION_RATE=n......................................11 5.2.2 AES_CM_128_HMAC_SHA1_32..................................14
4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................11 5.2.3 F8_128_HMAC_SHA1_80......................................15
4.3.4 FEC_ORDER=order............................................11 5.2.4 Adding new Crypto-suite Definitions......................15
4.3.5 UNAUTHENTICATED_SRTP.......................................12 5.3 Session Parameters.............................................15
5. Use with Offer/Answer............................................12 5.3.1 SRC=SSRC/ROC/SEQ.........................................15
5.1 Generating the Offer...........................................12 5.3.2 KDR=n....................................................18
5.2 Answerer Processing............................................12 5.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................18
5.4 Non-RTP/SAVP Answerers.........................................14 5.3.4 UNAUTHENTICATED_SRTP.....................................19
5.4 Offer/Answer Example: Receiver Supports SRTP...................14 5.3.5 FEC_ORDER=order..........................................19
5.7 Use of a=crypto With Active Media Streams......................15 5.3.6 Window Size Hint (WSH)...................................19
5.8 Operation with KEYMGT and Key lines............................15 5.3.7 SRTP Extension Session Parameters........................19
6. Security Considerations..........................................15 6. SRTP-Specific Use of the crypto Attribute........................20
6.1 Authentication of packets......................................16 6.1 Use with Offer/Answer..........................................20
6.1 Key-stream Reuse...............................................16 6.1.1 Generating the Initial Offer.............................20
6.2 Signaling Authentication and Signaling Encryption..............17 6.1.2 Generating the Initial Answer............................21
7. SRTP "Crypto" Attribute Grammar..................................18 6.1.3 Offerer Processing of the Initial Answer.................22
8. Open Issues......................................................19 6.1.4 Modifying the Session....................................23
9. Acknowledgements.................................................19 6.1.5 Offer/Answer Example.....................................24
10. Authors' Addresses..............................................19 6.2 SRTP-Specific Use Outside Offer/Answer: Advertising............25
11. Normative References............................................20 6.3 SRTP-Specific Backwards Compatibility Considerations...........25
Intellectual Property Statement.....................................21 6.4 Operation with KEYMGT= and k= lines............................26
Acknowledgement.....................................................22 6.5 Removal of Crypto Contexts.....................................26
7. Security Considerations..........................................26
7.1 Authentication of packets......................................27
7.2 Keystream Reuse................................................27
7.3 Signaling Authentication and Signaling Encryption..............27
8. Grammar..........................................................29
8.1 Generic "Crypto" Attribute Grammar.............................29
8.2 SRTP "Crypto" Attribute Grammar................................29
9. Open Issues......................................................30
10. IANA Considerations.............................................31
10.1 Registration of the "crypto" attribute........................31
10.2 New IANA Registries and Registration Procedures...............31
10.2.1 Security Descriptions Key Method Registry and Registration31
10.2.2 SRTP Crypto Suite Registry and Registration..............31
10.2.3 SRTP Session Parameter Registration......................32
10.3 Initial Registrations.........................................32
11. Acknowledgements................................................32
12. Authors' Addresses..............................................33
13. Normative References............................................33
14. Informative References..........................................34
Intellectual Property Statement.....................................35
Acknowledgement.....................................................36
1. Notational Conventions 1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
document are to be interpreted as described in [RFC2119]. The be interpreted as described in [RFC2119]. The terminology in this
terminology conforms to [RFC2828]. document conforms to [RFC2828], "Internet Security Glossary".
Andreasen, Baugher & Wing [Page 2] 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
through k inclusive. The abbreviation "iff" means "if and only if."
2. Introduction 2. Introduction
The Session Description Protocol (SDP) describes multimedia The Session Description Protocol (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 sessions. Security services such as data origin
authentication, integrity and confidentiality are often needed for authentication, integrity and confidentiality are often needed for
these media streams. The Secure Real-time Transport Protocol (SRTP) media streams. The Secure Real-time Transport Protocol (SRTP)
can be used to provide such security services, and use of it can be [srtp] provides such security services and is signaled by use of the
signaled by use of the "RTP/SAVP" transport in an SDP media (m=) "RTP/SAVP" transport in an SDP media (m=) line. However, there are
line. However, there are no means within SDP itself to configure no means within SDP itself to configure SRTP beyond using default
SRTP beyond using defaults values. This document specifies a new values. This document specifies a new SDP attribute called
SDP attribute called "crypto", which is used to signal and negotiate "crypto", which is used to signal and negotiate cryptographic
cryptographic parameters for SRTP. parameters for media streams in general, and SRTP in particular.
The crypto attribute might be extended to non-SRTP transports such The crypto attribute is defined in a generic way to enable its use
as whiteboard, modem, fax, and other transports that could use with secure transports besides SRTP that need to signal and
various security protocols such as IPsec or TLS. These extensions, negotiate cryptographic parameters, e.g. IPsec [ipsec], S/MIME
however, are beyond the scope of this document. Each type of SDP [s/mime], or TLS [tls], if and only if such parameters can either be
media stream needs its own definitions that assign values to its advertised in a single message, or negotiated in a single round-trip
crypto-attribute parameters. These definitions are unique to the by use of the offer/answer model [RFC3264]. Such extensions,
particular SDP transport and SHOULD be specified in an Internet RFC. however, are beyond the scope of this document. Each type of secure
This document defines the parameter values for SRTP. SDP media transport needs its own specification for the crypto-
attribute parameter. These definitions are frequently unique to the
particular type of transport and MUST be specified in an Internet
RFC and registered with IANA according to the procedures defined in
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 SRTP secures RTP packets or
IPsec secures IP packets. Data security protocols such as SRTP rely IPsec secures IP packets. Data security protocols such as SRTP rely
upon a separate key management system to securely establish upon a separate key management system to securely establish
encryption and/or authentication keys. Key management protocols encryption and/or authentication keys. Key management protocols
provide authenticated key establishment (AKE) procedures to provide authenticated key establishment (AKE) procedures to
authenticate the identity of each endpoint and protect against man- authenticate the identity of each endpoint and protect against man-
in-the-middle, reflection/replay, connection hijacking and some in-the-middle, reflection/replay, connection hijacking and some
denial of service attacks [skeme]. Along with the key, an AKE denial of service attacks [skeme]. Along with the key, an AKE
protocol such as MIKEY, GDOI, KINK, IKE or TLS securely disseminates protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE [ike]
information describing both the key and the data-security session or TLS [tls] securely disseminates information describing both the
(for example, whether SRTCP payloads are encrypted or unencrypted in key and the data-security session (for example, whether SRTCP
an SRTP session). AKE is needed because it is pointless to provide payloads are encrypted or unencrypted in an SRTP session). AKE is
a key over a medium where an attacker can snoop the key, alter the needed because it is pointless to provide a key over a medium where
definition of the key to render it useless, or change the parameters an attacker can snoop the key, alter the definition of the key to
of the security session to gain unauthorized access to session- render it useless, or change the parameters of the security session
related information. to gain unauthorized access to session-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 that follow do not add AKE services to
SDP. This specification is no replacement for a key management SDP. This specification is no replacement for a key management
protocol or for the conveyance of key management messages in SDP protocol or for the conveyance of key management messages in SDP
[keymgt]. The SDP security descriptions are suitable for restricted [keymgt]. The SDP security descriptions defined here are suitable
cases where IPsec, TLS, or some other encapsulating data-security for restricted cases only where IPsec, TLS, or some other
protocol (e.g. SIP secure multiparts) protects the SDP message. encapsulating data-security protocol (e.g. SIP secure multiparts)
This draft adds security descriptions to those encrypted and/or protects the SDP message. This document adds security descriptions
authenticated SDP messages through the "crypto" attribute, which to those encrypted and/or authenticated SDP messages through the
"crypto" attribute, which provides the cryptographic parameters of a
Andreasen, Baugher & Wing [Page 3] media stream. The "crypto" attribute can be adapted to any media
provides the cryptographic parameters of a media stream. The " transport, but its precise definition is frequently unique to a
crypto" attribute could be adapted to any media transport, but its particular transport. In Section 3, we introduce the general SDP
definition is unique to a particular transport. In Section 3, we crypto attribute, and in Section 4 we define how it is used with and
introduce the SDP crypto attribute, and in Section 4, we define the without the offer/answer model. In Section 5, we define the crypto
crypto attribute details needed for SRTP. In Section 5, we specify attribute details needed for SRTP, and in Section 6 we define SRTP-
how to use the crypto attribute for SRTP streams with the specific use of the attribute with and without the offer/answer
Offer/Answer model [RFC3264]. Section 6 recites security model. Section 7 recites security considerations, and Section 8
considerations, and Section 7 gives an Augmented-BNF grammar for the gives an Augmented-BNF grammar for the general crypto attribute as
SRTP security descriptions provided for the crypto attribute. A well as the SRTP-specific use of the crypto attribute. A list of
list of open issues is provided in Section 8. open issues is provided in Section 9 and IANA considerations are
provided in Section 10.
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
proceeding media line. The "crypto" attribute MUST only appear at preceding media line. The "crypto" attribute MUST only appear at
the SDP media level (not the session level). The "crypto" attribute the SDP media level (not the session level). The "crypto" attribute
is defined by the following ABNF [RFC2234]: follows the format (see Section 8.1 for a formal ABNF grammar):
"a=crypto:" crypto-suite SP key-param *(SP session-param)
where "SP" is the space character (see [RFC2234]); the fields
crypto-suite, key-param, and session-param are described in Section
3.1, 3.2, and 3.3.
The ordering of multiple "a=crypto" lines is significant: The most- a=crypto:<crypto-suite> <key-params> *<session-params>
preferred crypto line is listed first; see section 5 for details. We
now describe the crypto fields in more detail.
3.1 Crypto-suite The fields crypto-suite, key-params, and session-param are described
in the following sub-sections. Below we show an example of the
crypto attribute for the "RTP/SAVP" transport, i.e. SRTP (newlines
included for formatting reasons only):
The crypto-suite field describes all needed information about the a=crypto:AES_CM_128_HMAC_SHA1_80
encryption and authentication algorithms for the RTP/SAVP transport. inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The ABNF grammar for crypto-suite is: SRC=/721/13
crypto-suite = VCHAR 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-
param named "SRC".
where VCHAR is defined in [RFC2234]. The possible values for the 3.1 Crypto-suite
crypto-suite parameter is unique to the transport.
3.2 Key Parameter The crypto-suite field is an identifier (see Section 8.1 for
details) that describes the encryption and authentication algorithms
(e.g. AES_CM_128_HMAC_SHA1_80) for the transport in question. The
possible values for the crypto-suite parameter are defined within
the context of the transport, i.e. each transport defines a separate
namespace for the set of crypto-suites. For example, the crypto-
suite "AES_CM_128_HMAC_SHA1_80" defined within the context of the
"RTP/SAVP" transport applies to Secure RTP only; the string may be
reused for another transport, however a separate definition would be
needed.
The key-param field MUST either contain an inline key descriptor, 3.2 Key Parameters
or it MUST be a pointer to a uri which contains the actual key. The
ABNF grammar for key-param is:
key-param = inline-key / uri-key The key-params field provides one or more sets of keying material
inline-key = "inline:" key-descriptor for the crypto-suite in question. The field consists of a method
key-descriptor = VCHAR indicator followed by a colon, and the actual keying information as
uri-key = "uri:" absolute-uri shown below (a formal grammar is provided in Section 8.1):
absolute-uri = VCHAR
Andreasen, Baugher & Wing [Page 4] key-params = <key-method> ":" <key-info>
where VCHAR is defined in [RFC2234].
If the key parameter starts with the string "uri:", the URI method Keying material may be provided by different means. One method is
is used and the value that follows MUST be a Uniform Resource defined in this document, namely "inline", which indicates that the
Identifier. The URI is a resource that SHOULD be queried to obtain keying material is provided in the key-info field itself. There is
the cryptographic key for the session. The format or protocols used a single name space for the key-method, i.e. the key-method is
for the uri are beyond the scope of this document, however it is transport independent. New key-methods (e.g. use of a URL) may be
RECOMMENDED that such protocols provide both integrity and defined in an IETF RFC in the future, in which case they may be used
confidentiality. with any transport, provided the definitions for that transport
support use of the new key-method. New key methods MUST be
registered with the IANA according to the procedures defined in
Section 10.2.1.
The INLINE method is invoked when the key parameter starts with the Key-info is here just defined as a general character string (see
string "inline:"; the cryptographic key is encoded according to a Section 8.1 for details); further transport and key-method specific
transport-specific syntax subject to the general format provided syntax and semantics MUST be provided in an IETF RFC for each
above. Thus, the URI method is transport generic and the INLINE combination of transport and key-method that wants to use it;
method is transport specific. Section 4 describes the INLINE key- definitions for SRTP are provided in Section 5. Note that such
parameter syntax for RTP/SAVP (the SRTP media transport type). definitions are provided within the context of both a particular
transport (e.g. "RTP/SAVP") and a specific key-method (e.g.
"inline").
3.4 Session Parameters When multiple keys are included in the key parameters, it MUST be
possible to determine which key is being used by a simple inspection
of the media packet received; a trial-and-error approach between the
possible keys MUST NOT be required.
The session parameters are specific to the SDP media stream For SRTP, this could for example be achieved by use of Master Key
transport and are OPTIONAL. The ABNF grammar for session-param is: Identifiers (MKI), or <"From", "To"> values.
session-param = VCHAR 3.3 Session Parameters
where VCHAR is defined in [RFC2234]. Section 4 describes the session Session parameters are specific to a given transport and use of them
parameters for RTP/SAVP. is OPTIONAL in the general framework, where they are just defined as
a general character string. If session parameters are to be used
for a given transport, then key-method and transport-specific syntax
and semantics MUST be provided in an IETF RFC for each transport
that wants to use it; definitions for SRTP are provided in Section
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.5 Example 3.4 Example
The first example shows use of the crypto attribute for the RTP/SAVP The first 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, although it is shown as two lines in this is actually one long line, although it is shown as two lines in this
document due to page formatting. document 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:AES_CM_128_HMAC_SHA1_80
inline:d/16/14/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:AES_CM_128_HMAC_SHA1_32
inline:d/16/14/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
Andreasen, Baugher & Wing [Page 5]
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 RTP/SAVP
transport. These RTP/SAVP-specific descriptions are defined in the transport. These RTP/SAVP-specific descriptions are defined in the
next section. Section 5.
4. RTP/SAVP (SRTP) Security Descriptions 4. 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.
4.1 Use With Offer/Answer
In this section, we define the general rules for use of the crypto
attribute with the offer/answer [RFC3264] model. These rules are in
addition to the rules specified in RFC 3264, which MUST be followed,
unless otherwise noted.
4.1.1 Generating the Initial Offer
4.1.1.1 Unicast Streams
When generating an initial offer for a unicast stream, there MUST be
one or more crypto attributes present for each media stream for
which security is desired. The ordering of multiple "a=crypto"
lines is significant: The most-preferred crypto line is listed
first. Each crypto attribute describes the crypto-suite, key(s) and
possibly session parameters offered for the media stream. In
general, a "more preferred" crypto suite SHOULD be stronger
cryptographically than a "less preferred" crypto suite.
The crypto-suite always applies to media in all directions supported
by the media stream (e.g. send and receive).
The key(s) 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
SRTP, secure RTCP will still be flowing in both the send and
receive direction for a unidirectional stream.
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.
When issuing an offer, the offerer MUST be prepared to support media
security in accordance with any of the crypto attributes included in
the offer. There are however two problems associated with this.
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
choose the same key as the offerer chose in his sending direction
(in fact, the answerer SHOULD NOT use the same key as explained in
Section 4.1.2.1). Since media may arrive prior to the answer, delay
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
to solve the above problem.
Another problem can occur when the offerer includes multiple crypto
attributes, since the offerer may not be able to deduce which of the
offered crypto attributes was accepted by the answerer until the
answer is received, yet media may arrive before the answer.
If this is unacceptable to the offerer, the offerer either SHOULD
NOT include multiple crypto attributes in the offer, or a mechanism
outside the scope of this document SHOULD be used to prevent the
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
When the answerer receives the initial offer with one or more crypto
attributes for a given unicast media stream, the answerer MUST
either accept exactly one of the offered crypto attributes, or the
offered stream MUST be rejected.
If the answerer wishes to indicate support for other crypto
attributes, those can be listed by use of the SDP Simple
Capability Declaration [RFC3407] extensions.
Only crypto attributes that are valid, i.e. do not violate any of
general rules defined for security descriptions as well as any
specific rules defined for the transport and key method in question
can be accepted. When selecting one of the valid crypto attributes,
the answerer SHOULD select the most preferred crypto attribute it
can support, i.e. the first valid 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
them are valid, or none of the valid ones are supported, the offered
media stream MUST be rejected.
The crypto attribute in the answer MUST contain the following:
* The crypto-suite from the accepted crypto attribute in the offer
(the same crypto-suite must be used in the send and receive
direction).
* The key(s) the answerer will be using for media sent to the
offerer.
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.
Once the answerer has accepted one of the offered crypto attributes,
the answerer MAY begin sending media to the offerer in accordance
with the selected crypto attribute. Note however, that the offerer
may not be able to process such media packets correctly until the
answer has been received.
4.1.2.2 Multicast 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
exactly one of the offered crypto attributes was accepted.
Otherwise, the offerer MUST consider the offer/answer negotiation to
have failed for that stream.
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
the offered crypto attribute and key(s) were accepted and echoed in
the answer. Otherwise, the offerer MUST consider the offer/answer
negotiation to have failed for that stream for *that answerer* and
hence the answerer is not considered a participant in that media
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;
instead, specific rules are provided as part of the transport and
key-method specific definitions of any session parameters.
4.1.4 Modifying the Session
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
be triggered by the security service, e.g. in order to perform a re-
keying or change the crypto-suite. If media stream security using
the general security descriptions defined is still desired, the
crypto attribute MUST be included in these new offer/answer
exchanges. The procedures are similar to those defined in Section
4.1.1, 4.1.2, 4.1.3 subject to the considerations provided in RFC
3264 Section 8.
4.2 Use Outside Offer/Answer: Advertising
The crypto attribute can also be used outside the context of
offer/answer. For example, when using the Session Announcement
Protocol (SAP) [RFC2974], there is no negotiation of the media
streams described by the SDP; instead media streams are simply
advertised.
The crypto attribute defined here can be used in such environments
where the crypto parameters are advertised in a single message
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
It is possible that the answerer supports a given secure transport
and accepts the offered media stream, yet the answerer does not
support the crypto attribute defined here. The offerer can
recognize this situation by seeing an accepted 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.
5. SRTP Security Descriptions
In this section, we provide definitions for security descriptions
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 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=) line media streams that use the "RTP/SAVP" transport in the media (m=)
and SHALL apply to that media stream only. line and SHALL apply to that media stream only.
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 crypto attribute defined in this values can be configured by the SRTP security descriptions defined
document. An endpoint that does not support the crypto attribute here. An endpoint that does not support the crypto attribute will
will ignore it (per [SDPnew]) and hence, if it supports SRTP, it ignore it (per [SDPnew]) and hence, if it supports SRTP, it will
will simply assume use of default SRTP parameters. Such an endpoint simply assume use of default SRTP parameters. Such an endpoint will
will not correctly process the particular media stream. By using not correctly process the particular media stream. By using the
the Offer/Answer model, the offerer and answerer can negotiate the Offer/Answer model, the offerer and answerer can negotiate the
crypto parameters to be used before commencement of the multimedia crypto parameters to be used before commencement of the multimedia
session (see Section 5.0). 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, however, 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. of SRTP parameter values for the security session. This approach is
followed by the SRTP security descriptions, which uses the general
security description parameters as follows:
SRTP Crypto Parameter Description * crypto-suite: Identifies the encryption and authentication
--------------------- ----------- transforms
CRYPTO-SUITE Encryption and authentication transforms * key parameter: SRTP keying material and parameters
INLINE SRTP and associated parameters * session parameters: The following parameters are defined:
SRC An <SSRC, ROC, SEQ> triple - SRC: An <SSRC, ROC, SEQ> triple
KEY_DERIVATION_RATE Rate that the pseudo-random function - KDR: The SRTP Key Derivation Rate is the rate that a
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
- Extensions: Extension parameters can be defined
Table 4-1: SRTP Crypto-suite, Key and Session Parameters
Andreasen, Baugher & Wing [Page 6]
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 CRYPTO- parameters and their descriptions [Section 8.2, srtp]. The key
SUITE, the key parameter, and the session parameters shown in the parameter, the crypto-suite, and the session parameters shown above
table above are described in the following sections. If a receiver are described in detail in the following sections.
cannot recognize a parameter or value, then the receiver MUST NOT
participate in the media stream and SHOULD log an "invalid name"
condition unless the receiver is participating in an Offer/Answer
exchange (Section 5).
4.1 Crypto-suites 5.1.1.1 SRTP Key Parameter
A crypto-suite value appears as the first parameter in a crypto SRTP security descriptions define use of the "inline" key method as
attribute. If a receiver does not support the particular crypto- described in the following. Use of any other keying method for SRTP
suite, then the receiver MUST NOT participate in the media stream security descriptions is for further study.
and SHOULD log an "unrecognized crypto-suite" condition unless the
receiver is participating in an Offer/Answer exchange (Section 5).
RTP/SAVP has three crypto-suites as described below.
4.1.1 AES_CM_128_HMAC_SHA1_80 The "inline" type of key contains the keying material and all policy
relating to that key, including how long it can be used (lifetime)
and whether or not it uses a master key identifier (MKI) to
associate an incoming SRTP packet with a particular master key.
Compliant implementations obey the policies associated with a master
key, and MUST NOT accept incoming packets that violate the policy
(e.g. after the key lifetime has expired).
This is the SRTP default AES Counter Mode cipher and HMAC-SHA1 The key parameter contains a semi-colon separated list of
message authentication having an 80-bit authentication tag. The cryptographic master keys, each of which MUST be a unique
master-key length is 128 bits and has a lifetime of a maximum of cryptographically random [RFC1750] value with respect to other
2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first master keys in the entire SDP message (i.e. including master keys
[srtp]. The SRTP and SRTCP encryption key lengths are 128 bits. for other streams). Each key in the list follows the format (a
The SRTP and SRTCP authentication key lengths are 160 bits (see formal definition is provided in Section 8.2):
Security Considerations). The master salt value is 112 bits and the
session salt value is 112 bits. The PRF is the default SRTP pseudo-
random function that uses AES Counter Mode with a 128-bit key
length.
4.1.2 AES_CM_128_HMAC_SHA1_32 "inline:" <key salt> "|" [<lifetime] "|" [MKI:length / FromTo]
The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message key||salt concatenated key and salt, base64 encoded
authentication having a 32-bit authentication tag for SRTP packets; lifetime key lifetime (number of packets)
SRTCP uses an 80-bit tag. The master-key length is 128 bits and has MKI:length MKI and length of the MKI field in SRTP packets.
a lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, FromTo <"From", "To"> values, specifying the lifetime for
whichever comes first [srtp]. The SRTP and SRTCP encryption key a master key.
lengths are 128 bits. The SRTP and SRTCP authentication key lengths
are 160 bits (see Security Considerations). The master salt value
is 112 bits and the session salt value is 112 bits. The PRF is the
default SRTP pseudo-random function that uses AES Counter Mode with
a 128-bit key length.
4.1.3 F8_128_HMAC_SHA1_80 The following definition provides an example for
AES_CM_128_HMAC_SHA1_80:
The SRTP f8 cipher is used with HMAC-SHA1 message authentication inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
having a 80-bit authentication tag. The master-key length is 128
bits and has a lifetime of a maximum of 2^48 SRTP packets or 2^31
SRTCP packets, whichever comes first [srtp]. The SRTP and SRTCP
encryption key lengths are 128 bits. The SRTP and SRTCP
Andreasen, Baugher & Wing [Page 7] The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the
authentication key lengths are 160 bits (see Security parameter is the cryptographic master key appended with the master
Considerations). The master salt value is 112 bits and the session salt; the two are first concatenated and then base64 encoded. The
salt value is 112 bits. The PRF is the default SRTP pseudo-random length of the concatenated key and salt is determined by the crypto-
function that uses AES Counter Mode with a 128-bit key length. suite for which the key applies. If the length (after being decoded
from base64) does not match that specified for the crypto-suite, the
entire crypto attribute MUST be considered invalid and an "invalid
key/salt" condition SHOULD be logged. Each master key and salt MUST
be a cryptographically random number and MUST be unique to the SDP
message.
4.1.4 Adding new CRYPTO-SUITE definitions The second field, is the OPTIONAL lifetime of the master key as
measured in maximum total number of packets using that key. The
lifetime value MAY be written as a non-zero, positive integer or as
a power of 2 (see the grammar in Section 8.2 for details). The
"lifetime" value MUST NOT exceed the maximum packet lifetime for the
crypto-suite. If the lifetime is too large or otherwise invalid
then the entire crypto attribute MUST be considered invalid and an
"invalid lifetime" condition SHOULD be logged. The default MAY be
implicitly signaled by omitting the lifetime value (i.e. "||").
This is convenient when the SRTP cryptographic key lifetime is the
default value. As a shortcut to avoid long decimal values, the
syntax of the lifetime allows using the literal "2^", which
indicates "two to the power of". The example above, shows a case
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
for the lifetime field, which means the SRTP's and SRTCP's default
values will be used (2^31):
If new transforms are added to SRTP, new definitions for those inline: YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4
transforms SHOULD be given for the SDP crypto attribute and
published in an Internet RFC. Sections 4.1.1 through 4.1.3
illustrate how to define CRYPTO-SUITE values for particular
cryptographic transforms. New definitions MAY be added to existing
transforms, moreover, to augment or modify definitions 4.1.1 through
4.1.3. For example, if AES_CM_128_HMAC_SHA1_80 were desired that
used a 160-bit master key, then a new crypto-suite MUST be defined
having a new name that is identical to AES_CM_128_HMAC_SHA1_80 but
with the size of the master key defined to be 160 bits instead of
128 bits.
4.2 Key-param Parameter The example shows a 30-character key and concatenated salt that is
base64 encoded: The 30-character key/salt concatenation is expanded
to 40 characters by the three-in-four encoding of base64.
If the key-param parameter has a "uri:" descriptor, the value is a The third field, which is also OPTIONAL, is either the Master Key
Uniform Resource Identifier value as described in Section 3. When Identifier (MKI) and its byte length, or a <"From", "To"> value.
the key-param parameter has an "inline:" descriptor, the value
contains a cryptographic master key that MUST be a unique
cryptographically random [RFC1750] value with respect to other
"inline:" values in the SDP message.
4.2.1 Key Usage "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
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.
If the MKI length is not given or if it exceeds 128 (bytes), then
the entire crypto attribute MUST be considered invalid and an
"invalid MKI length" condition SHOULD be logged. The 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
a 4-byte key identifier of 1066 to the key.
The "inline" type of key contains the keying material and all policy <"From", "To"> specifies the lifetime for a master key, expressed in
relating to that key, including how it can be used (for encryption, terms of the ROC and SEQ values inside whose range (including the
decryption, or both encryption and decryption), how long it can be range end-points) the master key is valid. <"From", "To"> is an
used (lifetime) and whether or not it uses a master key index alternative to the MKI and assumes that a master key is in one-to-
(master key index or MKI) to associate an incoming SRTP packet with one correspondence with the SRTP session key on which the <"From",
a master key. Compliant implementations obey the policies "To"> range is defined. The following example illustrates the use
associated with a master key, and MUST NOT accept incoming packets of the <"From", "To"> parameter:
that violate the policy (e.g. after the key lifetime has expired,
for example).
4.2.2 INLINE Definition inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|FT=0:0,1:0
If the identifier is "inline", the key-param descriptor has the As mentioned above, the key parameter can contain one or more master
format described in Section 7 (Grammar) and contains the following keys. When the key parameter contains more than one master key, all
fields: of the master keys MUST either include an MKI or a <"From", "To">
value. Note that it is not permissible to mix and match use of the
two within a single key parameter (i.e., one crypto attribute); all
master keys in a given key parameter must use one or the other.
use key use indicator 5.2 Crypto-suites
key_length key length
salt_length salt length
key||salt concatenated key and salt, BASE64-encoded
lifetime key lifetime (number of packets)
Andreasen, Baugher & Wing [Page 8] The SRTP crypto-suites define the encryption and authentication
MKI:length MKI and length of the MKI field in SRTP packets. transforms to be used for the SRTP media stream. The SRTP
specification has defined three crypto-suites, which below are
described in the context of the SRTP security descriptions.
The "use" indicator defines usage as one of three values which are 5.2.1 AES_CM_128_HMAC_SHA1_80
all provided from the perspective of the recipient of the SDP: "d"
means the key is used for decryption only, "e" means the key is used
for encryption only, and "b" means the key is used for both
encryption and decryption. If the crypto suite uses the same key
for both encryption and decryption, "b" MUST be specified.
The "key_length" is the integer length of the SRTP master key in AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher
bytes, and "salt_length" is the integer length of the master salt in and HMAC-SHA1 message authentication having an 80-bit authentication
bytes. Their sum MUST be exactly equal to the length of the tag. The master-key length is 128 bits and has a default lifetime
concatenated master key and salt provided in the fourth field. The of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes
key_length and salt_length MUST appear in the "inline" encoding. For first [srtp]. The SRTP and SRTCP encryption key lengths are 128
example, 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.
inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:4 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
attribute is considered invalid.
is a decryption key with a key length of 16 and a salt length of 14. 5.2.2 AES_CM_128_HMAC_SHA1_32
The fourth part of the "inline" encoding is the cryptographic master This crypto suite is identical to AES_CM_128_HMAC_SHA1_80 except
key appended with the master salt. Each master key and salt MUST be that the SRTP authentication key is 32 bits and the SRTCP
a cryptographically random number and MUST be unique to the SDP authentication key is 80 bits.
message. Both are concatenated and then base-64 encoded. If the
length of the concatenated key and salt (after being decoded from
base 64) does not equal the sum of the key_length and salt_length
indicated, the receiver MUST NOT use this crypto attribute line for
the media stream and SHOULD log a "inline encoding too short"
condition. For example,
inline:d/16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:4 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
attribute is considered invalid.
describes a decryption key with a key_length of 16, a salt_length of 5.2.3 F8_128_HMAC_SHA1_80
8, and a 32-character key and concatenated salt that is base-64
encoded: The 24-character key/salt concatenation is expanded to 32
characters by the three-in-four encoding of base 64.
The fifth part of the of the "inline" encoding is the OPTIONAL This crypto suite is identical to AES_CM_128_HMAC_SHA1_80 except the
lifetime of the master key as measured in number of packets using cipher is F8 [srtp].
that key. The lifetime value MAY be written as an non-zero,
positive integer or as a power of 2, see the ABNF in Section 7 for
details. The "lifetime" value MUST NOT exceed the maximum packet
lifetime for the crypto-suite. If lifetime is too large or
otherwise invalid, then the receiver MUST NOT use this crypto
attribute line for the media stream and SHOULD log an "invalid
lifetime" condition. The default MAY be implicitly signaled by
having no described value for lifetime (i.e. "//"). This is
convenient when the srtp crypto_key lifetime is allowed to default.
The first example, above, shows a case where the lifetime is
specified as 2^20 while the second example shows an empty lifetime,
Andreasen, Baugher & Wing [Page 9] The length of the base64 decoded key and salt value for this crypto-
which means the SRTP default value of 2^48 will be used with suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto
UNENCRYPTED_SRTCP and 2^31 will be used otherwise. attribute is considered invalid.
The MKI and its byte length are OPTIONAL (see Section 7). "MKI" is 5.2.4 Adding new Crypto-suite Definitions
the master key index associated with the SRTP_master 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 is the size
of the MKI field in the SRTP packet, specified in bytes. If the
MKI_length is not given or if the value exceeds 128, then the
receiver MUST NOT use this crypto attribute line for the media
stream and SHOULD log an "invalid MKI_length" condition. If the
value of the MKI is larger than allowed by MKI_length, then the
receiver MUST NOT use this crypto attribute line for the media
stream and SHOULD log an "invalid MKI" condition. The substring
"1:4" in the first example assigns to the key a master key index of
1 that is 4 bytes long, and the second example assigns a 4-byte key
index of 1066 to the key.
4.3 Session Parameters If new transforms are added to SRTP, new definitions for those
transforms SHOULD be given for the SRTP security descriptions and
published in an IETF RFC. Sections 5.2.1 through 5.2.3 illustrate
how to define crypto-suite values for particular cryptographic
transforms. Any new crypto suites MUST be registered with IANA
following the guidelines in section 10.
The "session" parameters are OPTIONAL and serve to override SRTP 5.3 Session Parameters
session defaults for the SRTP and SRTCP streams. These parameters
configure an RTP session for SRTP services.
4.3.1 SRC=SSRC/ROC/SEQ SRTP security descriptions define a set of "session" parameters,
which OPTIONALLY may be used to override SRTP session defaults for
the SRTP and SRTCP streams. These parameters configure an RTP
session for SRTP services and are described in the following.
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 The SRC session parameter provides information to establish the SRTP
cryptographic context. The ROC and sequence number are typically cryptographic context. It contains information about one or more of
only needed for sessions already in progress (as when rekeying or the following:
when joining a multicast session).
Zero or more SRC parameters MAY appear in a crypto attribute. Each * SSRC: Synchronization source
SRC parameter defines a separate SRTP crypto context (see section * ROC: Roll-over counter
3.2 of [srtp]) that SHALL share the master key and salt defined by * SEQ: Sequence number
an INLINE parameter. 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 OPTIONAL provided that either a ROC or a SEQ appear in the The ROC and sequence number are typically only needed for sessions
SRC parameter. SSRC is an integer in the range of 0..2^32-1 for the already in progress (as when rekeying or when joining a multicast
RTP SSRC parameter, which is undefined by default. This is the RTP session).
SSRC that is associated with the inline key. If the SSRC value is
invalid, the receiver MUST NOT use this crypto attribute line for
the media stream but SHOULD log an "invalid SSRC" condition. If
SSRC is specified and an SRTP packet is received with a different
SSRC value, the receiver SHOULD discard the packet and log an error.
ROC is OPTIONAL provided that either an SSRC or a SEQ appear in the Zero or more SRC parameters MAY appear in a crypto attribute. When
SRC parameter. ROC is an integer in the range of 0..2^32-1 for the 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.
Andreasen, Baugher & Wing [Page 10] SSRC is the RTP SSRC that is associated with the crypto context, and
SRTP rollover counter (ROC), which is zero by default. The ROC MAY is an integer in the range of 0..2^32-1. If an SSRC value is
be set to a non-zero value for an ongoing RTP/SAVP stream in which invalid, the entire crypto attribute line MUST be considered invalid
the SRTP ROC has cycled one or more times [srtp]. The receiver of and an "invalid SSRC" condition SHOULD be logged. If an SSRC value
the SDP message SHOULD refresh the ROC value before joining an collides with an SSRC for an existing participant in the session,
ongoing session. Depending on the nature of the session control, the entire crypto attribute line MUST be considered invalid and an
the late-joining receiver might need to refresh its ROC value "SSRC collision" condition SHOULD be logged.
through a unicast exchange or through receipt of a multicast or
unicast SDP message containing a ROC SRTP description. If ROC is
greater than 2^32-1, then the receiver MUST NOT use this crypto
attribute line for the media stream but SHOULD log an "invalid ROC"
condition.
SEQ is OPTIONAL provided that either an SSRC or a ROC appear in the OPEN ISSUE: It would be nice to have a way of indicating this
SRC parameter. SEQ is an integer in the range of 0..2^16-1 for the condition in an answer SDP, but we quickly end up duplicating the
SRTP sequence number (SEQ). SRTP uses the RTP sequence number (and RTP collision detection and resolution, which we don't want to.
the ROC) to compute the packet index [srtp]. At the start of a
session, an SSRC that randomly selects a high sequence-number value ROC is the SRTP rollover counter (ROC) in the range of 0..2^32-1 and
can put the receiver in an ambiguous situation: If initial packets is zero by default. Typically the ROC value is specified as a non-
are lost in transit up to the point that the sequence number wraps 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 (exceeds 2^16-1), then the receiver might not recognize that its ROC
needs to be incremented. See also section 3.3.1 of [srtp]. If SEQ needs to be incremented. By restricting the initial SEQ to the
is greater than 2^16-1, then the receiver MUST NOT use this crypto range of 0..2^15-1, SRTP packet-index determination will find the
attribute line for the media stream but SHOULD log an "invalid SEQ" correct ROC value, unless all of the first 2^15 packets are lost
condition. (which seems, if not impossible, then rather unlikely). See Section
3.3.1 of the SRTP specification regarding packet-index determination
[srtp].
4.3.2 KDR=n 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
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 {0,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^0 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]. The default value is 0, which
causes the key derivation function to be invoked exactly once (since causes the key derivation function to be invoked exactly once (since
2^0 is 1). 2^0 is 1).
4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 5.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP indicates that the SRTCP packet payloads are not SRTP and SRTCP packet payloads are encrypted by default. The
encrypted. UNENCRYPTED_SRTP indicates that the SRTP packet payloads UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the
are not encrypted. SRTP and SRTCP packet payloads are encrypted by default behavior of the crypto-suites with which they are used:
default.
4.3.4 FEC_ORDER=order * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not
encrypted.
The forward error correction values for "order" are FEC_SRTP, * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not
SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC is applied encrypted.
before SRTP processing on the sender and after SRTP processing on
the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse
processing. SPLIT signals that SRTP encryption occurs on the
Andreasen, Baugher & Wing [Page 11] 5.3.4 UNAUTHENTICATED_SRTP
sender, followed by FEC processing, followed by SRTP authentication;
processing is reversed on the receiver. If the receiver cannot
recognize the order value, then the receiver MUST NOT use this
crypto attribute line for the media stream but SHOULD log an
"invalid FEC_ORDER" condition.
4.3.5 UNAUTHENTICATED_SRTP SRTP and SRTCP packet payloads are authenticated by default. The
UNAUTHENTICATED_SRTP session parameter signals that SRTP messages
are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT
RECOMMENDED (see Security Considerations).
This parameter signals that SRTP messages are not authenticated. The SRTP specification requires use of message authentication for
SRTP authenticates SRTP messages by default. Use of SRTCP, but not for SRTP [srtp].
UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security
Considerations).
5. Use with Offer/Answer 5.3.5 FEC_ORDER=order
The Offer/Answer model [RFC 3264] enables parties that wish to FEC_ORDER signals the use of forward error correction for the RTP
engage in a multimedia session to negotiate the media stream packets [rfc2733]. The forward error correction values for "order"
parameters that will be used for the multimedia session. In this are FEC_SRTP, SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC
section, we detail how the security descriptions defined for SRTP is applied before SRTP processing by the sender of the SRTP media
are used with the offer/answer model to negotiate cryptographic and after SRTP processing by the receiver of the SRTP media;
capabilities and communicate SRTP master keys. FEC_SRTP is the default. SRTP_FEC is the reverse processing. SPLIT
signals that the sender performs SRTP encryption, followed by FEC
processing, followed by SRTP authentication; processing is reversed
on the receiver.
5.1 Generating the Offer 5.3.6 Window Size Hint (WSH)
For each SDP media line (m=) using the "RTP/SAVP" transport where SRTP defines the SRTP-WINDOW-SIZE [SRTP, section 3.3.2] parameter to
the offerer wants to specify cryptographic parameters, the offerer protect against replay attacks. The minimum value, per [srtp], is
MUST provide at least one "a=crypto" line. When multiple crypto 64, however this value may be considered too low for some
lines are provided, the a=crypto lines are specified in preference applications (e.g. video).
order, with the most preferred listed first. The offerer determines
the crypto parameters based on its capabilities and its security
policies.
The offerer obtains keying material for "inline", or obtains the uri The Window Size Hint (WSH) session parameter provides a hint for how
pointing to a key server. The mechanism to generate or obtain a key big this window should be to work satisfactorily (e.g. based on
is outside the scope of this specification. sender knowledge of number of packets per second). However, there
might be enough information given in SDP attributes like
"a=maxprate" and the bandwidth modifiers to allow a receiver to
derive the parameter satisfactorily. Consequently, this value is
only considered a hint to the receiver of the SDP which MAY choose
to ignore the value provided.
5.2 Answerer Processing 5.3.7 SRTP Extension Session Parameters
For each SDP media line using the "RTP/SAVP" transport that contains New SRTP session parameters for the SRTP security descriptions can
an "a=crypto" line in the offer, the answerer MUST either accept be defined in an IETF RFC and registered with IANA according to the
exactly one of the crypto lines for that media stream, or it MUST registration procedures defined in Section 10.
reject the media stream as described in RFC 3264. Note that if
there are no "a=crypto" lines for the media stream in the offer,
then the answerer MUST skip the following steps and instead use the
default SRTP/SRTCP parameters for that media stream (note that the
endpoint will then need to somehow obtain the correct master key as
well). When the answerer accepts an "RTP/SAVP" media stream with a
crypto line, the answerer MUST include exactly one "a=crypto" line
in the answer. The answer crypto line MUST include at least the
selected crypto-suite and a key-param parameter.
Andreasen, Baugher & Wing [Page 12] SRTP extension session parameters are by default mandatory. An SRTP
To determine if the answerer can accept any of the provided extension session parameter that is prefixed with the dash character
"a=crypto" lines, the answerer examines the crypto lines in order. ("-") however is considered optional and MAY be ignored. If a SDP
If an "a=crypto" line does not satisfy the constraints provided in is received with an unknown mandatory session parameter in a crypto
Section 4, that crypto line is deemed invalid and MUST be discarded. attribute, that crypto attribute MUST be considered invalid and a
The answerer selects the first valid crypto line that it supports, "unknown session parameter" condition SHOULD be logged.
considering the answerer's capabilities and security policies. If
the answerer cannot find any valid crypto line that it supports, or
its configured policy prohibits any cryptographic key parameter
(e.g. key length) or cryptographic session parameter (e.g. SSRC,
ROC, KDR, 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]).
After selecting a single crypto line, the answerer generates a 6. SRTP-Specific Use of the crypto Attribute
master key appropriate for the selected crypto algorithm(s), unless
the offered master key was specified to apply to both encryption and
decryption, in which case the offered master key MUST be used
instead. If the offered master key was for decryption, then the
answerer MUST use it to decrypt any incoming packets; the key
provided in the answer MUST also be marked as being for decryption,
since the answerer will be using it when encrypting it's packets.
Similarly, if the offered key was for encryption, then the answerer
MUST use it to encrypt any packets it sends and the key it provides
in its answer MUST be used to decrypt any incoming packets. The
master key in the answer MUST have the same key length and salt
length as the offer.
To set up the bi-directional media with transport set to RTP/SAVP, In this section, we describe the SRTP-specific use of the crypto
the answerer includes one "a=crypto" line after its media line with attribute.
transport set to RTP/SAVP.
5.3 Offerer Processing of the Answer 6.1 Use with Offer/Answer
When the offerer receives the answer, it MUST perform the following In this section, we describe how the SRTP security descriptions are
steps for each "RTP/SAVP" media stream it offerered with one or more used with the offer/answer model to negotiate cryptographic
crypto lines in it. 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
6.1.1.1 Unicast Streams
When the initial offer is generated, the offerer MUST follow the
steps in Section 4.1.1.1 as well as the following steps.
For each unicast media line (m=) using the "RTP/SAVP" transport
where the offerer wants to specify cryptographic parameters, the
offerer MUST provide at least one valid SRTP security description
("a=crypto" line), as defined in Section 5.
The offerer MAY include one or more SRTP session parameters as
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.1.2 Multicast Streams
When the initial offer is generated, the offerer MUST follow the
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 the offerer wants to specify cryptographic parameters, the
offerer MUST provide at least one valid SRTP security description
("a=crypto" line), as defined in Section 5. Furthermore, the
<"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
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
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
6.1.2.1 Unicast Streams
When the initial answer is generated, the answerer MUST follow the
steps in Section 4.1.2.1 as well as the following steps.
For each unicast media line using the "RTP/SAVP" transport that
contains one or more "a=crypto" lines in the offer, the answerer
MUST either accept 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 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
crypto line, the answerer indicates acceptance by including its own
"a=crypto" line in the answer. The answer crypto line MUST include
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
answerer, SSRC collisions are acceptable, which simplifies the
overall operation.
Session parameters MAY be included in the answer as well; any
session parameters included in the answer are independent of session
parameters included in the offer. Use of extension SRTP session
parameters SHOULD be avoided unless it is known that the offerer
supports these.
If the answerer cannot find any valid crypto line that it supports,
or 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 "RTP/SAVP" by other means outside the
scope of this document (e.g., by use of MIKEY [mikey]).
6.1.2.2 Multicast Streams
When the initial answer is generated, the answerer MUST follow the
steps in Section 4.1.2.2 as well as the following steps.
For each multicast media stream using the "RTP/SAVP" transport that
contains an "a=crypto" line in the offer, the answerer MUST either
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
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
unicast), and hence there is no reason to repeat optional
parameters that cannot change anyway.
OPEN ISSUE: It is not clear that all session parameters should be
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,
or 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.
It should be noted, that multicast streams with more than one sender
that are negotiated by use of this mechanism will be using the same
master key for sending and receiving and hence SSRC collisions must
be avoided. The mechanism defined here does not provide a way to
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
6.1.3.1 Unicast Streams
When the offerer receives the answer, it MUST perform the steps in
Section 4.1.3.1 as well as the following steps for each "RTP/SAVP"
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 If the media stream was accepted and it contains a crypto line, it
MUST be checked that the media line is valid according to the MUST be checked that the crypto line is valid according to the
constraints specified in Section 4. Furthermore, the offerer MUST constraints specified in Section 5.
validate, that the crypto-suite selected was one of the offered
crypto-suites for the media stream. If any of these checks fails,
the security negotiation defined here MUST be deemed to have failed.
It is possible that the answerer supports the "RTP/SAVP" transport If the crypto line contains any SRTP session parameters, those
and accepts the offered media stream, yet it does not support the parameters define SRTP behavior for media sent from the answerer to
crypto attribute defined here. The offerer can recognize this the offerer. If the offerer either does not support or is not
situation by seeing an accepted "RTP/SAVP" media stream in the willing to honor one or more of the SRTP session parameters in the
answer that does not include a crypto line. In that case, the answer, the offerer MUST consider the crypto line invalid.
security negotiation defined here MUST be deemed to have failed.
Andreasen, Baugher & Wing [Page 13] If the crypto line is not valid, or the offerer's configured policy
prohibits any cryptographic key parameter (e.g. key length) or
cryptographic session parameter, the SRTP security negotiation MUST
be deemed to have failed.
5.4 Non-RTP/SAVP Answerers 6.1.3.2 Multicast Streams
If a media stream with transport set to "RTP/SAVP" is sent to a When the offerer receives the answer, it MUST perform the steps in
device that doesn't support "RTP/SAVP", that media stream will be Section 4.1.3.2 as well as the following steps for each "RTP/SAVP"
rejected. media stream it offered with a crypto line in it.
In some cases, it is desirable to send SRTP when possible, but allow If the media stream was accepted and it contains a crypto line, it
use of RTP if SRTP isn't supported by a remote device. However, it MUST be checked that the crypto line is valid according to the
is ambiguous to send an extra media line with transport set to constraints specified in Section 5. If the crypto line includes any
"RTP/AVP" and with the same port as the "RTP/SAVP" line. Thus, an session parameters, those are simply ignored.
offerer MUST NOT specify multiple media lines with the same port.
Instead, such interoperability is obtained by first sending an offer OPEN ISSUE: As noted in Section 6.1.2.2, it may make sense to
with transport set to "RTP/SAVP". If that media line is rejected by allow for some session parameters, e.g. SRC, to be included.
the answerer, the offerer can, if its policy permits, send a new
offer with transport set to "RTP/AVP". Also, the SDP extensions
defined in RFC 3407 [RFC3407] can be used by both the offerer and
answerer to indicate capabilities above and beyond what is being
negotiated for the media stream. Another offer/answer exchange will
then be needed to negotiate use of any of these latent capabilities.
5.4 Offer/Answer Example: Receiver Supports SRTP If the crypto line is not valid, the SRTP security negotiation MUST
be deemed to have failed for that particular answerer.
In this example, the Offerer supports two crypto suites (F8 and 6.1.4 Modifying the Session
When a media stream using the SRTP security descriptions has been
established, and a new offer/answer exchange is performed, the
offerer and answerer MUST follow the steps in Section 4.1.4 as well
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
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,
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
media according to both the old and the new offer/answer exchange.
This requirement applies here as well, however the following should
be noted:
* When authentication is not being used, it may not be possible for
either the offerer or the answerer to determine if a given packet
is encrypted according to the old or new offer/answer exchange.
RFC 3264 defines a couple of techniques to address this problem,
e.g. changing the payload types used and/or the transport
addresses. Note however that a change in transport addresses may
have an impact on Quality of Service as well as firewall and NAT
traversal. The SRTP security descriptions offers two other ways
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
bytes to each SRTP packet) as described in Section 5.1.1.1. For
further details on MKI and "<"From","To">, please refer to [srtp].
* If the answerer changes its master key, the offerer will not be
able to process packets secured via this master key until the
answer is received.
As noted in Section 4.1.1.1, this could for example be addressed
by defining a security "precondition" [RFC3312]
Finally note, that if the new offer is rejected, the old crypto
parameters remain in place.
6.1.5 Offer/Answer Example
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:AES_CM_128_HMAC_SHA1_80
inline:d/16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/2^20/1:32 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP SRC=17174//49126 FEC_ORDER=FEC_SRTP SRC=//49126
a=crypto:F8_128_HMAC_SHA1_80 a=crypto:F8_128_HMAC_SHA1_80
inline:d/16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/2^20/1:32 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4
FEC_ORDER=FEC_SRTP SRC=17174//49126 FEC_ORDER=FEC_SRTP SRC=//49126
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)
Andreasen, Baugher & Wing [Page 14]
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:AES_CM_128_HMAC_SHA1_80
inline:d/16/14/PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR/2^20/1:32 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
SRC=88131/721/13 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. The answerer is also
specifying both its initial SSRC (88131), rollover counter (721), specifying both its current rollover counter (721), and sequence
and rollover counter (13). number (13).
5.7 Use of a=crypto With Active Media Streams 6.2 SRTP-Specific Use Outside Offer/Answer: Advertising
When an active SRTP session is rekeyed, this is indicated by sending The SRTP security descriptions can be used outside the context of
a new SDP. Rekeying is done following the rules described for a offer/answer as described in Section 4.2. In those cases, the
normal Offer/Answer exchange. The Answerer can take this general rules defined in Section 4.2 as well as the SRTP-specific
opportunity to rekey the traffic it is sending, if the Answerer rule defined below MUST be followed:
desires. During rekeying, the session parameters cannot be changed
and MUST NOT be specified in the Offer or the Answer.
When the Offerer needs to rekey, the offerer MUST send an "a=crypto" * If any SRTP session parameters are included, they MUST be
line with same crypto-suite, key length, and salt length that was supported by the recipient of the SDP; otherwise, the recipient
previously accepted by the Answerer. MUST NOT join the SRTP session.
If the answerer selected "a=crypto" lines using the "inline" method, 6.3 SRTP-Specific Backwards Compatibility Considerations
the exact same "a=crypto" line(s) as agreed to in the answer MUST be
sent and a new new inline key MUST be sent.
If the answerer selected "a=crypto" lines using the "uri" method, It is possible that the answerer supports the "RTP/SAVP" transport
the sender MAY transmit the same uri, and the recipient MUST fetch and accepts the offered media stream, yet it does not support the
the new key using the uri. crypto attribute defined here. The offerer can recognize this
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.
5.8 Operation with KEYMGT and Key lines Also, if a media stream with transport set to "RTP/SAVP" is sent to
a device that does not support "RTP/SAVP", that media stream will be
rejected.
An Offer MAY include both a=crypto and a=keymgt lines [keymgt]. Per 6.4 Operation with KEYMGT= and k= lines
SDP rules, the Answerer will ignore attribute lines it doesn't
understand. If the Answerer supports both a=crypto and [keymgt],
the Answer MUST include either a=crypto or [keymgt], as including
both is undefined.
6. Security Considerations An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt].
Per SDP rules, the answerer will ignore attribute lines it does not
understand. If the answerer supports both "a=crypto" and
"a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt"
but not both, as including both is undefined.
An offer MAY include both "a=crypto" and "k=" lines [SDPnew]. Per
SDP rules, the answerer will ignore attribute lines it does not
understand. If the answerer supports both "a=crypto" and "k=", the
answer MUST include either "a=crypto" or "k=" but not both, as
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
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, RTSP, SAP, 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, that protocol should either invoke its own descriptions. Therefore, the application protocol SHOULD either
security mechanisms to do so, or alternatively utilize a lower-layer invoke its own security mechanisms to do so, or alternatively
security service (e.g. TLS, IPSEC) where that service is deemed utilize a lower-layer security service (e.g. TLS, IPSEC). This
adequate for protecting the encapsulating protocol itself. Where security service SHOULD provide strong message authentication and
packet-payload encryption as well as effective replay protection.
Andreasen, Baugher & Wing [Page 15]
the encapsulating protocol is used in both a hop-by-hop and end-to-
end context (e.g. SIP), an end-to-end security service SHOULD be
provided by that protocol for all sensitive information including
SDP's security parameters. This service SHOULD provide strong
message authentication and packet-payload encryption as well as
effective replay protection. As an example, SIP with S/MIME bodies
satisfies these requirements.
6.1 Authentication of packets 7.1 Authentication of packets
RTP messages are vulnerable to a variety of attacks such as replay Security descriptions as defined herein signal security services for
and forging. To limit these attacks, SRTP message integrity RTP packets. RTP messages are vulnerable to a variety of attacks
mechanisms SHOULD be used (SRTP replay protection is always such as replay and forging. To limit these attacks, SRTP message
enabled). Source authentication of unicast SRTP messages SHOULD be integrity mechanisms SHOULD be used (SRTP replay protection is
performed [srtp]. Note that SRTP source-message authentication does always enabled). Source authentication (i.e. data-origin
not authenticate the IP-address of the SRTP source, but ensures that authentication) of unicast SRTP messages SHOULD be performed [srtp].
the SRTP message that the SRTP receiver had received is exactly what
the SRTP sender had sent. Source authentication of multicast SRTP
messages is today non-standard and hence for further study. But
even in multicast sessions, SRTP packet authentication ensures that
the packet originated from a member of the secure group. Use of the
UNAUTHENTICATED_SRTP parameter, therefore, is NOT RECOMMENDED.
6.1 Key-stream Reuse 7.2 Keystream Reuse
Misconfigured SRTP sessions, moreover, are vulnerable to attacks on Security descriptions as defined herein signal configuration
their encryption services when running the crypto suites defined in parameters for SRTP sessions. Misconfigured SRTP sessions are
Sections 4.1.1, 4.1.2 and 4.1.3. An SRTP encryption service is vulnerable to attacks on their encryption services when running the
"mis-configured" when two or more media streams are encrypted using crypto suites defined in Sections 5.2.1, 5.2.2, and 5.2.3. An SRTP
the same AES keystream. When senders and receivers share derived encryption service is "misconfigured" when two or more media streams
session keys, SRTP requires that the SSRCs of session participants are encrypted using the same AES keystream. When senders and
make their corresponding keystreams unique, which is violated in the receivers share derived session keys, SRTP requires that the SSRCs
case of SSRC collision: SRTP SSRC collision drastically weakens SRTP of session participants serve to make their corresponding keystreams
or SRTCP payload encryption during the time that identical unique, which is violated in the case of SSRC collision: SRTP SSRC
keystreams were used [srtp]. An attacker, for example, might collision drastically weakens SRTP or SRTCP payload encryption
collect SRTP and SRTCP messages and await a collision. This attack during the time that identical keystreams were used [srtp]. An
on the AES-CM and AES-f8 encryption is avoided entirely when each attacker, for example, might collect SRTP and SRTCP messages and
media stream has its own unique master key, as this document await a collision. This attack on the AES-CM and AES-f8 encryption
RECOMMENDS (Section 4.2). is avoided entirely when each media stream has its own unique master
key in both the send and receive direction, as this document
RECOMMENDS (see Section 6.1.2.1), i.e. keys are not shared between
multiple media streams, and the 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 SRTP multicast operation requires that each host-sender have a
unique SRTP keystream. This can be accomplished by ensuring that unique SRTP keystream. This can be accomplished by ensuring that
each sender be allocated a unique key or by ensuring that the SSRC each sender be allocated a unique key or by ensuring that the SSRC
of each sender will not collide. Since SSRC collision might occur, of each sender will not collide. Since SSRC collision might occur,
the latter condition is avoided when all SSRCs are assigned by a the latter condition is avoided when all SSRCs are assigned by a
central authority such as a 3rd-party key server [srtp]. This is central authority such as a 3rd-party key server [srtp]. The
for further study. The RECOMMENDED approach of this document is to RECOMMENDED approach of this document is to allocate a different
allocate a different master key for each host-participant of an SRTP master key for each host-participant of an SRTP session.
session.
Andreasen, Baugher & Wing [Page 16]
6.2 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.
IPsec, TLS, encapsulating-protocol security or some other data Thus, IPsec, TLS, or some other data security service SHOULD be used
security service SHOULD be used to provide message authentication to provide message authentication for the encapsulating protocol
for SDP messages that carry the SRTP attribute. Message encryption that carries the SDP messages having a crypto attribute (a=crypto).
SHOULD be used because a master key parameter appears in the Furthermore, encryption of the encapsulating payload SHOULD be used
message. Failure to encrypt the SDP message containing an inline because a master key parameter (inline) appears in the message.
SRTP master key renders the SRTP authentication or encryption Failure to encrypt the SDP message containing an inline SRTP master
service useless in practically all circumstances. Failure to key renders the SRTP authentication or encryption service useless in
authenticate an SDP message that carries SRTP parameters renders the practically all circumstances. Failure to authenticate an SDP
SRTP authentication or encryption service useless in most practical message that carries SRTP parameters renders the SRTP authentication
applications. or encryption service useless in most practical applications.
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. The proposed SDP key-mgmt extension [keymgt] protocol be used instead of the security descriptions defined here
allows authentication and encryption of the key management protocol (a=crypto). The proposed SDP key-mgmt extension [keymgt] allows
data independently of the SDP message that carries it. The security authentication and encryption of the key management protocol data
of the SDP SRTP attribute, however, is as good as the data security independently of the SDP message that carries it. The security of
the SDP SRTP attribute, however, is as good as the data security
protocol that protects the SDP message. For example, if an IPsec protocol that protects the SDP message. For example, if an IPsec
security association exists between the source endpoint, its security association exists between the source and destination
signaling controller, and the destination endpoints, then this endpoints, then this solution is more secure than use of the key-
solution is more secure than use of the key-mgmt statement in an mgmt statement in an unauthenticated SDP message, which is
unauthenticated SDP message, which is vulnerable to tampering. vulnerable to tampering.
There are practical cases, however, where SDP security is not end- There are practical cases, however, where SDP security is not end-
to-end: If there is a third-party provider between the sender and 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. receiver, then the data-security session might not be end-to-end.
That is, one possible configuration might have an IPsec or TLS That is, one possible configuration might have an IPsec or TLS
connection between the sender of the SDP message and the provider, connection between the sender of the SDP message and the provider,
such as a VoIP service provider, with a second secure connection such as a VoIP service provider, with a second secure connection
between the provider and the receiver: between the provider and the receiver:
signaling controller---(network-b)---signaling controller signaling controller---(network-b)---signaling controller
| | | |
(network a) (network c) (network a) (network c)
| | | |
sender----------------(SRTP bearer)--------------receiver sender----------------(SRTP bearer)--------------receiver
where all of link a, b, and c are encrypted with TLS or IPsec. where all of link a, b, and c are encrypted with TLS or IPsec.
Andreasen, Baugher & Wing [Page 17] In this case, the third-party provider has access to the contents of
In this case, the third-party provider gets the contents of the SRTP the SRTP descriptions in the SDP message. SDP key-mgmt statement,
descriptions in the SDP message. SDP key-mgmt statement, however, however, allows true end-to-end security that is independent of the
allows true end-to-end security that is independent of the service service provider, who often needs access to some parts of the SDP
provider, who often needs access to some parts of the SDP message to message to render its services. The SRTP attribute SHOULD NOT be
render its services. The SRTP attribute SHOULD NOT be used when used when end-to-end authentication or confidentiality is needed but
end-to-end authentication or confidentiality is needed but the SDP the SDP message is not secured end-to-end (such as the above example
message is not secured end to end (such as the above example where a where a third-party provider maintains the security associations
third-party provider maintains the security associations with the with the endpoints for the SDP message).
endpoints for the SDP message).
7. SRTP "Crypto" Attribute Grammar 8. Grammar
This section provides an Augmented BNF grammar for the SRTP profile 8.1 Generic "Crypto" Attribute Grammar
of the SDP crypto attribute. ABNF is defined in [RFC2234].
key-param = method-inline / method-uri The ABNF grammar for the crypto attribute is defined below:
crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "a=crypto:" crypto-suite 1*WSP key-params *(1*WSP session-param)
"F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80"
method-inline = "inline:" key-info *(SP session-param) crypto-suite = 1*(ALPHA / DIGIT / "_")
method-uri = "uri:<" absoluteURI ">" ; absoluteURI defined in
; [RFC2396]
key-info = key-use "/" key-length "/" salt-length "/" key-salt key-params = key-param *(";" key-params)
"/" [lifetime] "/" [mki] key-param = key-method ":" key-info
key-method = "inline" | key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = %x21-3A / %x3B-7E ; visible (printing) characters
; except semi-colon
session-param = VCHAR ; visible (printing) characters
key-use = "d" / "e" / "b" ; decrypt, encrypt, or both where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234].
key-length = 1*DIGIT
salt-length = 1*DIGIT 8.2 SRTP "Crypto" Attribute Grammar
This section provides an Augmented BNF [RFC2234] grammar for the
SRTP-specific use of the SDP crypto attribute:
crypto-suite = srtp-crypto-suite
key-method = srtp-key-method
key-info = srtp-key-info
session-param = srtp-session-param
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext
srtp-key-method = "inline"
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) lifetime = ["2^"] 1*(DIGIT) ; see section 5.1.1.1 for "2^"
mki = mki-length ":" mki-value mki = mki-value ":" mki-length
mki-length = 1*DIGIT ; real value is 2^mki-length, max 128
mki-value = 1*DIGIT mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
FromTo = "FT=" ftval "," ftval
ftval = roc ":" seq ; packet index expressed in terms
; of ROC and SEQ.
session-param = src / srtp-session-param = src /
kdr / kdr /
"UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" / "UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" / "UNAUTHENTICATED_SRTP" /
fec-order fec-order /
wsh /
srtp-session-extension
Andreasen, Baugher & Wing [Page 18]
src = "SRC=" [ssrc] "/" [roc] "/" [seq] src = "SRC=" [ssrc] "/" [roc] "/" [seq]
ssrc = 1*DIGIT ; range 0...2^32-1 ssrc = 1*DIGIT ; range 0..2^32-1
roc = 1*DIGIT ; range 0...2^32-1 roc = 1*DIGIT ; range 0..2^32-1
seq = 1*DIGIT ; range 0...2^16-1 seq = 1*DIGIT ; range 0..2^16-1
kdr = "KDR=" 1*(DIGIT) 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
base64 = ALPHA / DIGIT / "+" / "/" / "=" base64 = ALPHA / DIGIT / "+" / "/" / "="
8. Open Issues srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234]
; first character must not be dash ("-")
9. Open Issues
The following is a list of open issues in this document: The following is a list of open issues in this document:
* The crypto attribute can be used with or without offer/answer, * The use of security descriptions, and in particular SRTP security
however, details on usage outside of offer/answer are missing. descriptions, with multicast streams where offer/answer is being
used is not well understood and requires further consideration.
* The offer/answer procedures need to be expanded to better describe * The security descriptions do not deal with hierarchically encoded
unidirectional and inactive streams, unicast versus multicast, as streams (or at least they have not been considered).
well as additional detail for some of the session parameters.
9. Acknowledgements * 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 ?
This document benefited from discussions with David McGrew, Mats 10. IANA Considerations
Naslund, Mike Thomas, Elisabetta Cararra, Brian Weis, Dave Oran,
Bill Foster, Earl Carter, Matt Hammer and Dave Singer. These people 10.1 Registration of the "crypto" attribute
shared observations, identified errors and made suggestions for
improving the specification. Mats made several valuable suggestions The IANA is hereby requested to register a new SDP attribute as
on parameters and syntax that are in the current draft. Dave Oran follows:
and Mike Thomas encouraged us to bring this work to the IETF for
Attribute name: crypto
Long form name: Security description cryptographic attribute
for media streams
Type of attribute: Media-level
Subject to charset: No
Purpose: Security descriptions
Appropriate values: See Section 3
10.2 New IANA Registries and Registration Procedures
The following sub-sections define several new IANA registries to be
used for the security descriptions. It is suggested that the
following registry structure be used for these:
Security Descriptions
|
+- Key Methods (described in 10.2.1)
|
+- Media Stream Transports
|
+- SRTP
|
+- SRTP crypto suites (described in Section 10.2.2)
|
+- SRTP session parameters (described in Section 10.2.3)
10.2.1 Security Descriptions Key Method Registry and Registration
The IANA is hereby requested to create a new registry for SDP
security description key methods. An IANA key method registration
MUST be documented in an IETF RFC and it MUST provide the name of
the key method in accordance with the grammar 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,
including the semantics of the "inline" key-method and any special
semantics of parameters.
10.2.3 SRTP Session Parameter Registration
The IANA is hereby requested to create a new registry for SRTP
session parameters. 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.
10.3 Initial Registrations
The following security descriptions key methods are hereby
registered:
inline
The following SRTP crypto suites are hereby registered:
AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80
The following SRTP session parameters are hereby registered:
SRC
KDR
UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP
UNAUTHENTICATED_SRTP
FEC_ORDER
WSH
The ABNF for all of the above is already included in the ABNF
section of this document.
11. Acknowledgements
This document is a product of the IETF MMUSIC working group and has
benefited from comments from its participants. This document also
benefited from discussions with David McGrew, Mats Naslund, Mike
Thomas, Elisabetta Cararra, Brian Weis, Dave Oran, Bill Foster, Earl
Carter, Matt Hammer and Dave Singer. These people shared
observations, identified errors and made suggestions for improving
the specification. Mats made several valuable suggestions on
parameters and syntax that are in the current draft. Dave Oran and
Mike Thomas encouraged us to bring this work to the IETF for
standardization. David McGrew suggested the conservative approach standardization. David McGrew suggested the conservative approach
of using unique master keys for each SDP media stream as followed in of requiring unique master keys for each unicast SDP media stream as
this document. Jonathan Rosenberg suggested reducing the complexity followed in this document. Jonathan Rosenberg suggested reducing
by specifying only one security parameter for each media stream. the complexity by specifying only one security parameter for each
media stream.
10. Authors' Addresses 12. Authors' Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
499 Thornall Street, 8th Floor 499 Thornall Street, 8th Floor
Edison, New Jersey 08837 USA Edison, New Jersey 08837 USA
fandreas@cisco.com fandreas@cisco.com
Mark Baugher Mark Baugher
5510 SW Orchid Street 5510 SW Orchid Street
Portland, Oregon 97219 USA Portland, Oregon 97219 USA
mbaugher@cisco.com mbaugher@cisco.com
+1-408-853-4418 +1-408-853-4418
Andreasen, Baugher & Wing [Page 19]
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 +1-408-902-3348
11. Normative References 13. Normative References
[RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP: [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
A Transport Protocol for Real-Time Applications", January 1996, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550,
http://www.ietf.org/rfc/rfc1889.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," 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 [SDPnew] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
Description Protocol,", Work in Progress. Description Protocol", Work in Progress.
[RFC2828] R. Shirey, "Internet Security Glossary", May 2000, [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for
http://www.ietf.org/rfc/rfc2828.txt Generic Forward Error Correction", RFC 2733, December 1999,
http://www.ietf.org/rfc/rfc2733.txt.
[RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
the Session Description Protocol (SDP)", June 2202, 2000, http://www.ietf.org/rfc/rfc2828.txt.
http://www.ietf.org/rfc/rfc3264.txt
[RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2202,
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", May Norrman, D. Oran, "The Secure Real-time Transport Protocol", Work in
2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp- Progress.
08.txt, Work in 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.
12. Informative References 14. Informative References
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002. Capability Declaration", RFC 3407, October 2002,
http://www.ietf.org/rfc/rfc3407.txt.
[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
Domain of Interpretation", RFC 3547, July 2003,
http://www.ietf.org/rfc/rfc3547.txt.
[kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of
Keys (KINK)", Work in Progress.
[ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt.
[ipsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998,
http://www.ietf.org/rfc/rfc2401.txt.
[s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt.
[tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt.
[keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
"Key Management Extensions for SDP and RTSP", February 2003, "Key Management Extensions for SDP and RTSP", Work in Progress.
http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-
07.txt, Work in Progress.
Andreasen, Baugher & Wing [Page 20]
[mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
"MIKEY: Multimedia Internet KEYing", July 2002, "MIKEY: Multimedia Internet KEYing", Work in Progress.
http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt,
Work in Progress.
[RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
November 1996, http://www.ietf.org/rfc/rfc2045.txt. 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", November 1997, for Message Authentication", RFC 2014, November 1997,
http://www.ietf.org/rfc/rfc2104.txt. http://www.ietf.org/rfc/rfc2104.txt.
[skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for the Internet", ISOC Secure Networks and Distributed Mechanism for the Internet", ISOC Secure Networks and Distributed
Systems Symposium, San Diego, 1996. Systems Symposium, San Diego, 1996.
[RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt.
[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000,
http://www.ietf.org/rfc/rfc2974.txt .
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 line 1084 skipping to change at page 35, line 54
Copyright(C) The Internet Society 2003. All Rights Reserved. Copyright(C) The Internet Society 2003. 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
Andreasen, Baugher & Wing [Page 21]
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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
skipping to change at line 1107 skipping to change at line 1777
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Andreasen, Baugher & Wing [Page 22]
 End of changes. 

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