draft-ietf-mmusic-sdescriptions-00.txt   draft-ietf-mmusic-sdescriptions-01.txt 
Internet Engineering Task Force Mark Baugher Internet Engineering Task Force Flemming Andreasen
MMUSIC Working Group Dan Wing MMUSIC Working Group Mark Baugher
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Dan Wing
EXPIRES: August 2003 February 24, 2003 EXPIRES: December 2003 Cisco Systems
June 27, 2003
SDP Security Descriptions for Media Streams SDP Security Descriptions for Media Streams
<draft-ietf-mmusic-sdescriptions-00.txt> <draft-ietf-mmusic-sdescriptions-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line ? skipping to change at line 34
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
Abstract Abstract
This Internet Draft gives a cryptographic attribute to Session This document defines a Session Description Protocol (SDP)
Description Protocol (SDP) media streams. The attribute describes a cryptographic attribute for media streams. The attribute describes
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 draft also defines the SRTP security for a media stream. This document defines the Secure Real-
parameters for the attribute. The SDP crypto attribute requires the time Transport Protocol (SRTP) parameters for the attribute. The
services of a data security protocol to secure the SDP message. SDP crypto attribute requires the services of a data security
protocol to secure the SDP message.
TABLE OF CONTENTS TABLE OF CONTENTS
1.0 Notational Conventions...........................................2 1. Notational Conventions............................................2
2.0 Introduction.....................................................3 2. Introduction......................................................3
3.0 SDP "Crypto" Attribute and Parameters............................4 3. SDP "Crypto" Attribute and Parameters.............................4
3.1 Crypto-suite....................................................4 3.1 Crypto-suite....................................................4
3.2 Application Parameter...........................................4 3.2 Key Parameter...................................................4
3.3 Key Parameter...................................................4
3.4 Session Parameters..............................................5 3.4 Session Parameters..............................................5
3.5 Examples........................................................5 3.5 Examples........................................................5
4.0 RTP/SAVP (SRTP) Security Descriptions............................6 4. RTP/SAVP (SRTP) Security Descriptions.............................6
4.1 Crypto-suites...................................................7 4.1 Crypto-suites...................................................7
4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7 4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7
4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7 4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7
4.1.3 F8_128_HMAC_SHA1_80.........................................7 4.1.3 F8_128_HMAC_SHA1_80.........................................7
4.1.4 F8_128_HMAC_SHA1_32.........................................7 4.1.4 Adding new CRYPTO-SUITE definitions.........................8
4.1.5 Adding new CRYPTO-SUITE definitions.........................8 4.2 Key-param Parameter.............................................8
4.2 Application Parameter...........................................8 4.2.1 Key Usage...................................................8
4.3 Key Parameter...................................................8 4.2.2 INLINE Definition...........................................8
4.3.1 INLINE Usage................................................8 4.3 Session Parameters.............................................10
4.3.2 INLINE Definition...........................................9 4.3.1 SRC=/SSRC/ROC/SEQ..........................................10
4.4 Session Parameters.............................................10 4.3.2 KEY_DERIVATION_RATE=n......................................11
4.4.1 SSRC=n.....................................................10 4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................11
4.4.2 ROC=n......................................................11 4.3.4 FEC_ORDER=order............................................11
4.4.3 KEY_DERIVATION_RATE=n......................................11 4.3.5 UNAUTHENTICATED_SRTP.......................................12
4.4.4 UNENCRYPTED................................................11 5. Use with Offer/Answer............................................12
4.4.5 FEC_ORDER=order............................................12 5.1 Generating the Offer...........................................12
4.4.6 UNAUTHENTICATED............................................12 5.2 Answerer Processing............................................12
5.0 Use with Offer/Answer...........................................12 5.4 Non-RTP/SAVP Answerers.........................................14
5.1 Offerer Processing.............................................12
5.2 Answerer Processing............................................13
5.3 Non-RTP/SAVP Answerers.........................................13
5.4 Offer/Answer Example: Receiver Supports SRTP...................14 5.4 Offer/Answer Example: Receiver Supports SRTP...................14
5.5 Offer/Answer Example: Different SRTP and SRTCP keys............14 5.7 Use of a=crypto With Active Media Streams......................15
5.6 Use of a=crypto With Active Media Streams......................15 5.8 Operation with KEYMGT and Key lines............................15
6.0 Security Considerations.........................................16 6. Security Considerations..........................................15
6.1 Authentication of packets......................................16 6.1 Authentication of packets......................................16
6.1 Reuse of Keying Material ("Two-Time Pad")......................16 6.1 Key-stream Reuse...............................................16
6.2 Signaling Authentication and Signaling Encryption..............17 6.2 Signaling Authentication and Signaling Encryption..............17
7.0 Grammar.........................................................18 7. SRTP "Crypto" Attribute Grammar..................................18
8.0 Acknowledgements................................................19 8. Open Issues......................................................19
9.0 Authors' Addresses..............................................20 9. Acknowledgements.................................................19
10.0 References.....................................................20 10. Authors' Addresses..............................................19
11.0 Full Copyright Statement.......................................21 11. Normative References............................................20
Intellectual Property Statement.....................................21
Acknowledgement.....................................................22
1.0 Notational Conventions 1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. The document are to be interpreted as described in [RFC2119]. The
terminology conforms to [RFC2828]. terminology conforms to [RFC2828].
2.0 Introduction Andreasen, Baugher & Wing [Page 2]
Session Description Protocol (SDP) describes multimedia sessions, 2. Introduction
such as Real-time Transport Protocol (RTP), white board, fax, modem
and other media sessions. Security services such as authentication
and confidentiality are often needed for these media streams. When
run under the RTP/SAVP profile, for example, an RTP stream uses the
Secure Real-time Transport Protocol (SRTP). The "RTP/SAVP"
descriptor in an SDP m=line signals the use of SRTP for a media
stream, but there are no means within SDP itself to configure SRTP
beyond using defaults values. This document specifies an SDP
attribute to signal a cryptographic parameters in addition to a key
for SRTP and other SDP media streams.
Thus, the SDP crypto attribute provides both generic and specific The Session Description Protocol (SDP) describes multimedia
security descriptions for SDP media streams that can be used for sessions, which can be audio, video, whiteboard, fax, modem and
various transports, including SRTP. In this way, the crypto other media sessions. Security services such as data origin
attribute can be extended to non-SRTP transports such as white authentication, integrity and confidentiality are often needed for
board, modem, fax, and other transports that could use various these media streams. The Secure Real-time Transport Protocol (SRTP)
security protocols such as IPsec or TLS. Each SDP media stream, can be used to provide such security services, and use of it can be
however, needs its own definitions that assign values to crypto- signaled by use of the "RTP/SAVP" transport in an SDP media (m=)
attribute parameters. These definitions are unique to the SDP line. However, there are no means within SDP itself to configure
transport and SHOULD be specified in an Internet RFC. This document SRTP beyond using defaults values. This document specifies a new
defines the parameter values for SRTP. With this document, an SDP attribute called "crypto", which is used to signal and negotiate
application developer can describe an SRTP key and its configuration cryptographic parameters for SRTP.
according to application-specific needs.
It would be self-defeating, however, to not secure cryptographic The crypto attribute might be extended to non-SRTP transports such
keys and other parameters at least as well as SRTP secures RTP as whiteboard, modem, fax, and other transports that could use
messages or IPsec secures IP packets. Data security protocols such various security protocols such as IPsec or TLS. These extensions,
as SRTP rely upon a separate key management system to securely however, are beyond the scope of this document. Each type of SDP
establish encryption and/or authentication keys. Key management media stream needs its own definitions that assign values to its
protocols provide authenticated key establishment (AKE) procedures crypto-attribute parameters. These definitions are unique to the
to authenticate the identity of each endpoint and protect against particular SDP transport and SHOULD be specified in an Internet RFC.
man-in-the-middle, reflection/replay, connection hijacking and some This document defines the parameter values for SRTP.
It would be self-defeating not to secure cryptographic keys and
other parameters at least as well as SRTP secures RTP packets or
IPsec secures IP packets. Data security protocols such as SRTP rely
upon a separate key management system to securely establish
encryption and/or authentication keys. Key management protocols
provide authenticated key establishment (AKE) procedures to
authenticate the identity of each endpoint and protect against man-
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, GDOI, KINK, IKE or TLS securely disseminates
information describing both the key and the data-security session information describing both the key and the data-security session
(for example, whether SRTCP is encrypted or unencrypted in an SRTP (for example, whether SRTCP payloads are encrypted or unencrypted in
session). AKE is needed because it is pointless to provide a key an SRTP session). AKE is needed because it is pointless to provide
over a medium where an attacker can snoop the key, alter the a key over a medium where an attacker can snoop the key, alter the
definition of the key to render it useless, or change the parameters definition of the key to render it useless, or change the parameters
of the security session to gain unauthorized access to session- of the security session to gain unauthorized access to session-
related information. related information.
SDP was not designed to provide AKE services, and the media security SDP, however, was not designed to provide AKE services, and the
descriptions that follow do not add AKE services to SDP. This media security descriptions that follow do not add AKE services to
specification is no replacement for a key management protocol or for SDP. This specification is no replacement for a key management
the conveyance of key management messages in SDP [keymgt]. SDP protocol or for the conveyance of key management messages in SDP
media-stream security descriptions are suitable for restricted cases [keymgt]. The SDP security descriptions are suitable for restricted
where IPsec, TLS, or some other data-security protocol protects the cases where IPsec, TLS, or some other encapsulating data-security
SDP message. protocol (e.g. SIP secure multiparts) protects the SDP message.
This draft adds security descriptions to those encrypted and/or
This draft adds security descriptions to SDP messages through a new authenticated SDP messages through the "crypto" attribute, which
SDP attribute named "crypto", which provides the cryptographic
parameters of a media stream. The crypto attribute MAY contain a
cryptographic key and other parameters that describe the key.
a=crypto MAY also contain "security session parameters" that are
unique to a transport.
The a=crypto parameter is applicable to all media transports, but Andreasen, Baugher & Wing [Page 3]
its value MAY be unique to a particular transport. Section 3 provides the cryptographic parameters of a media stream. The "
specifies the SDP crypto attribute generically. Section 4 defines crypto" attribute could be adapted to any media transport, but its
the crypto attribute for SRTP. Section 5 discusses use of the definition is unique to a particular transport. In Section 3, we
crypto attribute in Offer/Answer exchanges. Section 6 recites introduce the SDP crypto attribute, and in Section 4, we define the
security considerations, and Section 7 gives an Augmented-BNF crypto attribute details needed for SRTP. In Section 5, we specify
grammar for the security descriptions. how to use the crypto attribute for SRTP streams with the
Offer/Answer model [RFC3264]. Section 6 recites security
considerations, and Section 7 gives an Augmented-BNF grammar for the
SRTP security descriptions provided for the crypto attribute. A
list of open issues is provided in Section 8.
3.0 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 and security-session parameters for one or more media cryptographic suite, key parameters, and session parameters for the
entries. "a=crypto" MUST NOT appear at the SDP session level. proceeding media line. The "crypto" attribute MUST only appear at
the SDP media level (not the session level). The "crypto" attribute
is defined by the following ABNF [RFC2234]:
a=crypto:<crypto-suite> <application> <key> [<session>] "a=crypto:" crypto-suite SP key-param *(SP session-param)
The ordering of multiple a=crypto lines is significant, and the where "SP" is the space character (see [RFC2234]); the fields
most-preferred is listed first; see section 5. The next sections crypto-suite, key-param, and session-param are described in Section
describes these fields in more detail. 3.1, 3.2, and 3.3.
The ordering of multiple "a=crypto" lines is significant: The most-
preferred crypto line is listed first; see section 5 for details. We
now describe the crypto fields in more detail.
3.1 Crypto-suite 3.1 Crypto-suite
"Crypto-suite" describes all needed information about the encryption The crypto-suite field describes all needed information about the
and authentication algorithms for the transport. The "crypto-suite" encryption and authentication algorithms for the RTP/SAVP transport.
parameter is unique to the transport. The ABNF grammar for crypto-suite is:
3.2 Application Parameter crypto-suite = VCHAR
A particular transport can have multiple protocols that are secured where VCHAR is defined in [RFC2234]. The possible values for the
differently. For example, when using the RTP/SAVP transport, both crypto-suite parameter is unique to the transport.
the SRTP and SRTCP protocols will be used, but the security for each
MAY be different: A longer authentication output tag might be
desired for the SRTCP control protocol than for the SRTP media
stream. The "application" parameter allows separate security
descriptions for separate protocols of a transport.
3.3 Key Parameter 3.2 Key Parameter
The key parameter can contain an inline key descriptor, or can be a The key-param field MUST either contain an inline key descriptor,
pointer to a uri which contains the actual key: or it MUST be a pointer to a uri which contains the actual key. The
ABNF grammar for key-param is:
inline:key-descriptor key-param = inline-key / uri-key
uri:absolute-uri inline-key = "inline:" key-descriptor
key-descriptor = VCHAR
uri-key = "uri:" absolute-uri
absolute-uri = VCHAR
Andreasen, Baugher & Wing [Page 4]
where VCHAR is defined in [RFC2234].
If the key parameter starts with the string "uri:", the URI method If the key parameter starts with the string "uri:", the URI method
is used and the value that follows is a Uniform Resource Identifier. is used and the value that follows MUST be a Uniform Resource
The URI is a resource that SHOULD be queried to obtain the Identifier. The URI is a resource that SHOULD be queried to obtain
cryptographic key for the session. The format or protocols used for the cryptographic key for the session. The format or protocols used
the uri are beyond the scope of this document. for the uri are beyond the scope of this document, however it is
RECOMMENDED that such protocols provide both integrity and
confidentiality.
The INLINE method is invoked when the key parameter starts with the The INLINE method is invoked when the key parameter starts with the
string "inline:" - and the cryptographic key is encoded according string "inline:"; the cryptographic key is encoded according to a
to a transport-specific syntax. Thus, the URI method is transport transport-specific syntax subject to the general format provided
generic and the INLINE method is transport specific. Section 4 above. Thus, the URI method is transport generic and the INLINE
describes the INLINE key-parameter syntax for RTP/SAVP, the SRTP method is transport specific. Section 4 describes the INLINE key-
media transport type. parameter syntax for RTP/SAVP (the SRTP media transport type).
If SDP descriptions for new media-stream transports are defined in
the future, new methods MAY be defined in an Internet RFC.
3.4 Session Parameters 3.4 Session Parameters
"Session" parameters are specific to the SDP transport and optional. The session parameters are specific to the SDP media stream
Section 4 describes the session parameters for RTP/SAVP. transport and are OPTIONAL. The ABNF grammar for session-param is:
3.5 Examples session-param = VCHAR
The first example shows a=crypto for the RTP/SAVP transport type (as where VCHAR is defined in [RFC2234]. Section 4 describes the session
defined in Section 4). parameters for RTP/SAVP.
3.5 Example
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
is actually one long line, although it is shown as two lines in this
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 224.2.17.12/127 c=IN IP4 161.44.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly
m=video 51372 RTP/SAVP 31 m=video 51372 RTP/SAVP 31
a=crypto:AES_CM_128_HMAC_SHA1_80 both a=crypto:AES_CM_128_HMAC_SHA1_80
inline:16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32 inline:d/16/14/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 srtp a=crypto:AES_CM_128_HMAC_SHA1_32
inline:16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32 inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32
a=crypto:AES_CM_128_HMAC_SHA1_80 srtcp
inline:16/14/ ZkBkQythOTg3NjU0MSEzMDMyMT01NDg5N2RlRkF/2^20/1:32
m=application 32416 udp wb m=application 32416 udp wb
a=orient:portrait a=orient:portrait
This SDP message describes three "recvonly" media streams, two of Andreasen, Baugher & Wing [Page 5]
which use the RTP/SAVP transport. The first a=crypto line appears This SDP message describes three media streams, two of which use the
in the m=video media entry; it is associated with the RTP/SAVP RTP/SAVP transport. Each has a crypto attribute for the RTP/SAVP
transport of the m=video line and uses the SRTP default crypto- transport. These RTP/SAVP-specific descriptions are defined in the
suite, "AES_CM_128_HMAC_SHA1_80," and its key parameter carries the next section.
SRTP master key data and descriptors inline. The m=video a=crypto
attribute applies to both SRTP and SRTCP. The m=audio media entry
uses the "crypto-suite=AES_CM_128_HMAC_SHA1_32," having a short 32-
bit tag for SRTP, and it uses AES_CM_128_HMAC_SHA1_80 for SRTCP.
The RTP/SAVP-specific descriptions are defined in the next section.
4.0 RTP/SAVP (SRTP) Security Descriptions 4. RTP/SAVP (SRTP) Security Descriptions
The generic security descriptions of the preceding section need SRTP security descriptions for a media stream MUST only be used for
parameter values for specific media transports; this section defines media streams that use the RTP/SAVP transport in the media (m=) line
the crypto attribute values and parameters for the RTP/SAVP (SRTP) and SHALL apply to that media stream only.
transport. SRTP services for a media stream MUST be signaled
through the presence of an RTP/SAVP transport descriptor in the m=
line and SHALL apply only to that media entry.
There is no assurance that a receiver 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 systems through the guarantees minimal interoperability among SRTP endpoints through the
default SRTP parameters [srtp]. More capable SRTP receivers support default SRTP parameters [srtp]. More capable SRTP endpoints support
a variety of parameter values beyond the SRTP defaults and can be a variety of parameter values beyond the SRTP defaults and these
configured by the crypto attribute. A receiver that does not values can be configured by the crypto attribute defined in this
recognize a=crypto and assumes default SRTP parameters might receive document. An endpoint that does not support the crypto attribute
a stream that uses non-default parameters, which will cause that will ignore it (per [SDPnew]) and hence, if it supports SRTP, it
receiver to fail. An Offer/Answer capabilities exchange, however, will simply assume use of default SRTP parameters. Such an endpoint
allows sender and receiver to agree on parameters before will not correctly process the particular media stream. By using
commencement of the multimedia session (see Section 5.0). the Offer/Answer model, the offerer and answerer can negotiate the
crypto parameters to be used before commencement of the multimedia
session (see Section 5.0).
There are over twenty cryptographic parameters listed in the SRTP There are over twenty cryptographic parameters listed in the SRTP
specification. Many of these parameters have fixed values for specification. Many of these parameters have fixed values for
particular cryptographic transforms. At the time of session particular cryptographic transforms. At the time of session
establishment, however, there is usually no need to provide unique establishment, however, there is usually no need to provide unique
settings for many of the SRTP parameters. Thus, it is possible to settings for many of the SRTP parameters, such as salt length and
simplify the list of parameters in "cryptographic suites" that fix a pseudo-random function (PRF). Thus, it is possible to simplify the
set of SRTP parameter values for the security session. The list of list of parameters by defining "cryptographic suites" that fix a set
SRTP parameters, including the crypto-suite parameter for SDP of SRTP parameter values for the security session.
a=crypto follows.
SDP SRTP Parameter Description SRTP Crypto Parameter Description
------------------ ----------- --------------------- -----------
CRYPTO-SUITE Encryption and authentication transforms CRYPTO-SUITE Encryption and authentication transforms
SSRC SSRC of the sender of the SDP message INLINE SRTP and associated parameters
ROC Roll-over counter SRC An <SSRC, ROC, SEQ> triple
KEY_DERIVATION_RATE Rate that the pseudo-random function KEY_DERIVATION_RATE Rate that the pseudo-random function
is applied to a key is applied to a master key
UNENCRYPTED Protocol messages are not encrypted UNENCRYPTED_SRTP SRTP messages are not encrypted
UNAUTHENTICATED SRTP messages are not authenticated UNENCRYPTED_SRTCP SRTCP messages are not encrypted
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
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 CRYPTO-
SUITE and the five session parameters shown in the table above are SUITE, the key parameter, and the session parameters shown in the
described in the following sections. If a receiver cannot recognize table above are described in the following sections. If a receiver
a parameter or value, then the receiver MUST NOT participate in the cannot recognize a parameter or value, then the receiver MUST NOT
media stream and SHOULD log an "invalid name" condition unless the participate in the media stream and SHOULD log an "invalid name"
receiver is participating in an Offer/Answer exchange (Section 5). condition unless the receiver is participating in an Offer/Answer
exchange (Section 5).
4.1 Crypto-suites 4.1 Crypto-suites
A crypto-suite value appears as the first parameter in a=crypto. The A crypto-suite value appears as the first parameter in a crypto
CRYPTO-SUITE value MAY be different for SRTP and SRTCP as described attribute. If a receiver does not support the particular crypto-
in Section 4.2. If a receiver does not support the particular suite, then the receiver MUST NOT participate in the media stream
crypto-suite, then the receiver MUST NOT participate in the media and SHOULD log an "unrecognized crypto-suite" condition unless the
stream and SHOULD log an "unrecognized crypto-suite" condition receiver is participating in an Offer/Answer exchange (Section 5).
unless the receiver is participating in an Offer/Answer exchange RTP/SAVP has three crypto-suites as described below.
(Section 5). RTP/SAVP has four crypto-suites as described below.
4.1.1 AES_CM_128_HMAC_SHA1_80 4.1.1 AES_CM_128_HMAC_SHA1_80
This is the SRTP default AES Counter Mode cipher and HMAC-SHA1 This is the SRTP default AES Counter Mode cipher and HMAC-SHA1
message authentication having a 80-bit authentication tag. The message authentication having an 80-bit authentication tag. The
encryption and authentication key lengths are 128 bits. The master master-key length is 128 bits and has a lifetime of a maximum of
salt value is 112 bits and the session salt value is 112 bits. The 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first
PRF is the default SRTP pseudo-random function that uses AES Counter [srtp]. The SRTP and SRTCP encryption key lengths are 128 bits.
Mode with a 128-bit key length. The SRTP and SRTCP authentication key lengths are 160 bits (see
Security Considerations). The master salt value is 112 bits and the
4.1.2 AES_CM_128_HMAC_SHA1_32 session salt value is 112 bits. The PRF is the default SRTP pseudo-
The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message
authentication having an 32-bit authentication tag. The encryption
and authentication key lengths are 128 bits. The master salt value
is 112 bits and the session salt value is 112 bits. These values
apply to SRTP and to SRTCP. The PRF is the default SRTP pseudo-
random function that uses AES Counter Mode with a 128-bit key random function that uses AES Counter Mode with a 128-bit key
length. length.
4.1.3 F8_128_HMAC_SHA1_80 4.1.2 AES_CM_128_HMAC_SHA1_32
The SRTP f8 cipher is used with HMAC-SHA1 message authentication The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message
having a 80-bit authentication tag. The encryption and authentication having a 32-bit authentication tag for SRTP packets;
authentication key lengths are 128 bits. The master salt value is SRTCP uses an 80-bit tag. The master-key length is 128 bits and has
112 bits and the session salt value is 112 bits. The PRF is the 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 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 default SRTP pseudo-random function that uses AES Counter Mode with
a 128-bit key length. a 128-bit key length.
4.1.4 F8_128_HMAC_SHA1_32 4.1.3 F8_128_HMAC_SHA1_80
The SRTP f8 cipher is used with HMAC-SHA1 message authentication The SRTP f8 cipher is used with HMAC-SHA1 message authentication
having a 32-bit authentication tag. The encryption and having a 80-bit authentication tag. The master-key length is 128
authentication key lengths are 128 bits. The master salt value is bits and has a lifetime of a maximum of 2^48 SRTP packets or 2^31
112 bits and the session salt value is 112 bits. The PRF is the SRTCP packets, whichever comes first [srtp]. The SRTP and SRTCP
default SRTP pseudo-random function that uses AES Counter Mode with encryption key lengths are 128 bits. The SRTP and SRTCP
a 128-bit key length.
4.1.5 Adding new CRYPTO-SUITE definitions Andreasen, Baugher & Wing [Page 7]
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.4 Adding new CRYPTO-SUITE definitions
If new transforms are added to SRTP, new definitions for those If new transforms are added to SRTP, new definitions for those
transforms SHOULD be given for the SDP crypto attribute and transforms SHOULD be given for the SDP crypto attribute and
published in an Internet RFC. Sections 4.1.1 through 4.1.4 published in an Internet RFC. Sections 4.1.1 through 4.1.3
illustrate how to define CRYPTO-SUITE values for particular illustrate how to define CRYPTO-SUITE values for particular
cryptographic transforms. New definitions MAY be added to existing cryptographic transforms. New definitions MAY be added to existing
transforms, moreover, to augment or modify definitions 4.1.1 through transforms, moreover, to augment or modify definitions 4.1.1 through
4.1.4. 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
4.2 Application Parameter 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
The "application" parameter indicates if this a=crypto line applies 128 bits.
to only secure RTP, only secure RTCP, or to both secure RTP and
RTCP. The values for this are "srtp", "srtcp", or "both". If a
receiver finds an "srtp" a=crypto without a corresponding "srtcp"
a=crypto, or vice versa, it MUST NOT participate in the media stream
and SHOULD log an "missing crypto attribute" condition.
4.3 Key Parameter 4.2 Key-param Parameter
If the "key" parameter has a "uri:" descriptor, the value is a If the key-param parameter has a "uri:" descriptor, the value is a
Uniform Resource Identifier value as described in Section 3. When Uniform Resource Identifier value as described in Section 3. When
key-parameter has an "inline:" descriptor, the value contains a the key-param parameter has an "inline:" descriptor, the value
cryptographic key that MUST be a unique random value with respect to contains a cryptographic master key that MUST be a unique
other "inline:" values in the SDP message. cryptographically random [RFC1750] value with respect to other
"inline:" values in the SDP message.
4.3.1 INLINE Usage
The "inline:" descriptor is applicable to SDP media-entries having a 4.2.1 Key Usage
"recvonly," "sendonly" or "sendrecv" direction attribute. In
general, the source of data will generate the master key to protect
its data, but this is a matter of local policy and application
preference. Multicast applications, for example, often will use a
third-party provider of a master key. Thus, when the inline key is
used, it SHOULD be used for a recvonly media-entry or for the
received stream of sendrecv media-entry. The inline key MAY be used
for a sendonly media-entry or for streams that are sent and received
on a sendrecv media-entry. The following paragraphs add detail to
these inline-key recommendations for recvonly, sendonly, and
sendrecv media entries.
In the recvonly case, the inline SRTP master key SHOULD be used to The "inline" type of key contains the keying material and all policy
derive keys [SRTP] to decrypt/authenticate incoming SRTP messages. relating to that key, including how it can be used (for encryption,
When the a=crypto "application" parameter is set to "both," the decryption, or both encryption and decryption), how long it can be
receiver also derives keys from the same master key to used (lifetime) and whether or not it uses a master key index
decrypt/authenticate incoming SRTCP messages. When that receiver (master key index or MKI) to associate an incoming SRTP packet with
sends RTP Receiver Reports for the incoming SRTP stream, it SHOULD a master key. Compliant implementations obey the policies
derive keys from the same master key to encrypt/authenticate associated with a master key, and MUST NOT accept incoming packets
outgoing SRTCP messages for that SRTP stream. that violate the policy (e.g. after the key lifetime has expired,
for example).
In the sendonly case, the inline SRTP master key SHOULD be used to 4.2.2 INLINE Definition
derive keys [SRTP] to encrypt and authenticate outgoing SRTP
messages. When the a=crypto "application" parameter is set to
"both," the sender also derives keys from the same SRTP master key
to encrypt and authenticate outgoing SRTCP message. When that
sender sends RTP Sender Reports for the outgoing SRTP stream, it
SHOULD derive keys from the same master key to encrypt/authenticate
outgoing SRTCP messages for the outgoing SRTP stream.
In the sendrecv case, the inline SRTP master key SHOULD be used as If the identifier is "inline", the key-param descriptor has the
in the recvonly case described above but MAY also be used as in the format described in Section 7 (Grammar) and contains the following
sendonly case. fields:
4.3.2 INLINE Definition use key use indicator
key_length key length
salt_length salt length
key||salt concatenated key and salt, BASE64-encoded
lifetime key lifetime (number of packets)
If the identifier is "inline", the key-descriptor MUST have the Andreasen, Baugher & Wing [Page 8]
following format. MKI:length MKI and length of the MKI field in SRTP packets.
key_length/salt_length/BASE64(key||salt)/lifetime/MKI:MKI_length The "use" indicator defines usage as one of three values which are
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 The "key_length" is the integer length of the SRTP master key in
bytes, and "salt_length" is the integer length of the master salt in bytes, and "salt_length" is the integer length of the master salt in
bytes. If their sum is less than the sum of the lengths of the bytes. Their sum MUST be exactly equal to the length of the
master key and salt of the crypto suite, then the receiver MUST NOT concatenated master key and salt provided in the fourth field. The
participate in the media stream and SHOULD log a "key length too
short" condition. If their sum is greater than the crypto-suite sum,
then bytes are truncated from the right (i.e. "little end"). The
key_length and salt_length MUST appear in the "inline" encoding. For key_length and salt_length MUST appear in the "inline" encoding. For
example, example,
inline:16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32 (1) inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:4
has a key_length of 16 and a salt_length of 14. is a decryption key with a key length of 16 and a salt length of 14.
The third part of the "inline" encoding is the cryptographic master The fourth part of the "inline" encoding is the cryptographic master
key appended with the master salt ("||" denotes concatenation). key appended with the master salt. Each master key and salt MUST be
Each master key and salt MUST be a random number and MUST be unique a cryptographically random number and MUST be unique to the SDP
to the SDP message. Both are concatenated and then base-64 encoded. message. Both are concatenated and then base-64 encoded. If the
If the length of the concatenated keys (after being decoded from length of the concatenated key and salt (after being decoded from
base 64) does not equal or exceed the sum of the key_length and base 64) does not equal the sum of the key_length and salt_length
salt_length, the receiver MUST NOT participate in the media stream indicated, the receiver MUST NOT use this crypto attribute line for
and SHOULD log a "inline encoding too short" condition. For the media stream and SHOULD log a "inline encoding too short"
example, condition. For example,
inline:16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:32 (2) inline:d/16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:4
has a key_length of 16, a salt_length of 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 fourth part of the of the "inline" encoding is the OPTIONAL describes a decryption key with a key_length of 16, a salt_length of
lifetime of the master key as measured in number of packets 8, and a 32-character key and concatenated salt that is base-64
encrypted or authenticated with that key. The lifetime value MAY be encoded: The 24-character key/salt concatenation is expanded to 32
written as an non-zero, positive integer or as a power of 2, and is characters by the three-in-four encoding of base 64.
indicated with "2^"; see the ABNF in Section 7 for details. The
default value is 2^48, which is 2^48 packets encrypted with a master
key according to the SRTP standard [srtp]. The "lifetime" value
MUST NOT exceed the maximum packets lifetime for the crypto-suite
(e.g. 2^48 for AES Counter Mode with a 128-bit key). If lifetime is
too large or otherwise invalid, then the receiver MUST NOT
participate in 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. Trailing
slashes ("/") MUST follow the master key and lifetime; otherwise,
the receiver MUST NOT participate in the media stream and SHOULD log
an "invalid inline encoding" condition. Example (1), above, shows a
case where the lifetime is specified as 2^20 while example (2) shows
an empty lifetime that implicitly uses the SRTP default value of
2^48.
The MKI value is OPTIONAL as is its specified bit length (see The fifth part of the of the "inline" encoding is the OPTIONAL
Section 7). "MKI" is the master key index associated with the lifetime of the master key as measured in number of packets using
srtp_master key. If the MKI is given, then the length of the MKI that key. The lifetime value MAY be written as an non-zero,
MUST also be given and separated from the MKI by a colon (":"). The positive integer or as a power of 2, see the ABNF in Section 7 for
MKI_length is the size of the MKI field in the SRTP packet, details. The "lifetime" value MUST NOT exceed the maximum packet
specified in bits, and MUST be a positive multiple of 8. If the 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]
which means the SRTP default value of 2^48 will be used with
UNENCRYPTED_SRTCP and 2^31 will be used otherwise.
The MKI and its byte length are OPTIONAL (see Section 7). "MKI" is
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 MKI_length is not given or if the value exceeds 128, then the
receiver MUST NOT participate in the media stream and SHOULD log an receiver MUST NOT use this crypto attribute line for the media
"invalid MKI_length" condition. If the value of the MKI is larger stream and SHOULD log an "invalid MKI_length" condition. If the
than allowed by MKI_length, then the receiver MUST NOT participate value of the MKI is larger than allowed by MKI_length, then the
in the media stream and SHOULD log an "invalid MKI" condition. The receiver MUST NOT use this crypto attribute line for the media
substring "1:32" in example (1) assigns to the key a key index of 1 stream and SHOULD log an "invalid MKI" condition. The substring
that is 32 bits long, and example (2) assigns a 32-bit key index of "1:4" in the first example assigns to the key a master key index of
1066 to the key. 1 that is 4 bytes long, and the second example assigns a 4-byte key
index of 1066 to the key.
4.4 Session Parameters 4.3 Session Parameters
The "session" parameters are OPTIONAL and MAY override SRTP session The "session" parameters are OPTIONAL and serve to override SRTP
defaults for the SRTP and SRTCP streams. These parameters configure session defaults for the SRTP and SRTCP streams. These parameters
an RTP session for SRTP services. configure an RTP session for SRTP services.
4.4.1 SSRC=n 4.3.1 SRC=SSRC/ROC/SEQ
The value n is an integer in the range of 0..2^32-1 for the RTP SSRC The SRC session parameter provides information to establish the SRTP
parameter, which is undefined by default. This is the RTP SSRC of cryptographic context. The ROC and sequence number are typically
the sender of the SDP message. If n is invalid, the receiver MUST only needed for sessions already in progress (as when rekeying or
NOT participate in the media stream but SHOULD log an "invalid SSRC" when joining a multicast session).
condition.
SSRC MAY be specified when the setting of the "application" Zero or more SRC parameters MAY appear in a crypto attribute. Each
parameter is "srtp" or "both." Otherwise the receiver MUST NOT SRC parameter defines a separate SRTP crypto context (see section
participate in the media stream and SHOULD log an "invalid session 3.2 of [srtp]) that SHALL share the master key and salt defined by
parameter" condition. 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.
4.4.2 ROC=n SSRC is OPTIONAL provided that either a ROC or a SEQ appear in the
SRC parameter. SSRC is an integer in the range of 0..2^32-1 for the
RTP SSRC parameter, which is undefined by default. This is the RTP
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.
The value "n" is an integer in the range of 0..2^32-1 for the SRTP ROC is OPTIONAL provided that either an SSRC or a SEQ appear in the
rollover counter (ROC), which is zero by default. The ROC MAY be SRC parameter. ROC is an integer in the range of 0..2^32-1 for the
set to a non-zero value for an ongoing RTP/SAVP stream in which the
SRTP ROC has cycled one or more times [srtp]. The receiver of the
SDP message SHOULD refresh the ROC value before joining a session
"late." How "late" is defined depends on the rate of the particular
RTP stream and the time that has elapsed since its commencement.
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 SDP message. If n is
invalid, then the receiver MUST NOT participate in the media stream
but SHOULD log an "invalid ROC" condition.
ROC MAY be specified when the setting of the "application" parameter Andreasen, Baugher & Wing [Page 10]
is "srtp" or "both." Otherwise the receiver MUST NOT participate in SRTP rollover counter (ROC), which is zero by default. The ROC MAY
the media stream and SHOULD log an "invalid session parameter" be set to a non-zero value for an ongoing RTP/SAVP stream in which
the SRTP 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 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. condition.
4.4.3 KEY_DERIVATION_RATE=n SEQ is OPTIONAL provided that either an SSRC or a ROC appear in the
SRC parameter. SEQ is an integer in the range of 0..2^16-1 for the
SRTP sequence number (SEQ). SRTP uses the RTP sequence number (and
the ROC) to compute the packet index [srtp]. At the start of a
session, an SSRC that randomly selects a high sequence-number value
can put the receiver in an ambiguous situation: If initial packets
are lost in transit up to the point that the sequence number wraps
(exceeds 2^16-1), then the receiver might not recognize that its ROC
needs to be incremented. See also section 3.3.1 of [srtp]. If SEQ
is greater than 2^16-1, then the receiver MUST NOT use this crypto
attribute line for the media stream but SHOULD log an "invalid SEQ"
condition.
The value n may be an integer in the set {1,2,4,...,2^24}, i.e. a 4.3.2 KDR=n
power of 2 between 2^0 to 2^24, inclusive. The SRTP key derivation
rate controls how frequently a new session key is derived from an
SRTP master key [SRTP]. The default value is 0, which causes the
key derivation function to be invoked exactly once.
Key_Derivation_Rate MAY be specified when the "application" KDR specifies the Key Derivation Rate, as described in section 4.3.1
parameter setting is "srtp" or "both". Otherwise the receiver MUST of [srtp].
NOT participate in the media stream and SHOULD log an "invalid
session parameter" condition.
4.4.4 UNENCRYPTED 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
derivation rate controls how frequently a new session key is derived
from an SRTP master key [SRTP]. The default value is 0, which
causes the key derivation function to be invoked exactly once (since
2^0 is 1).
This indicates that the SRTP or SRTCP stream is not encrypted. SRTP 4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP
and SRTCP messages are encrypted by default.
UNENCRYPTED MAY be specified for "srtp", "srtcp", or "both". If the UNENCRYPTED_SRTCP indicates that the SRTCP packet payloads are not
a=crypto "application" setting is "both," then both the SRTP and encrypted. UNENCRYPTED_SRTP indicates that the SRTP packet payloads
SRTCP streams are unencrypted. are not encrypted. SRTP and SRTCP packet payloads are encrypted by
default.
4.4.5 FEC_ORDER=order 4.3.4 FEC_ORDER=order
The forward error correction values for "order" are FEC_SRTP, The forward error correction values for "order" are FEC_SRTP,
SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC is applied SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC is applied
before SRTP processing on the sender and after SRTP processing on before SRTP processing on the sender and after SRTP processing on
the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse
processing. SPLIT signals that SRTP encryption occurs on the processing. SPLIT signals that SRTP encryption occurs on the
Andreasen, Baugher & Wing [Page 11]
sender, followed by FEC processing, followed by SRTP authentication; sender, followed by FEC processing, followed by SRTP authentication;
processing is reversed on the receiver. If the receiver cannot processing is reversed on the receiver. If the receiver cannot
recognize the order value, then the receiver MUST NOT participate in recognize the order value, then the receiver MUST NOT use this
the media stream but SHOULD log an "invalid FEC_ORDER" condition. crypto attribute line for the media stream but SHOULD log an
"invalid FEC_ORDER" condition.
If specified, it MUST only be specified with "srtp" or "both."
Otherwise the receiver MUST NOT participate in the media stream and
SHOULD log an "invalid session parameter" condition.
4.4.6 UNAUTHENTICATED 4.3.5 UNAUTHENTICATED_SRTP
This parameter signals that SRTP messages are not authenticated. This parameter signals that SRTP messages are not authenticated.
SRTP authenticates SRTP messages by default (see Security SRTP authenticates SRTP messages by default. Use of
UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security
Considerations). Considerations).
If specified, it MUST only be specified with "srtp", or "both" since 5. Use with Offer/Answer
it applies only to the SRTP stream: Authentication is mandatory for
secure RTCP. If UNAUTHENTICATED appears in an a=crypto with an
"srtcp" application parameter, the receiver MUST NOT participate in
the media stream and SHOULD log an "invalid session parameter"
condition.
5.0 Use with Offer/Answer
A receiver that does not recognize a=crypto and assumes default SRTP
parameters might receive a stream that uses non-default parameters,
which will cause that receiver to fail. An Offer/Answer
capabilities exchange, however, allows sender and receiver to agree
on parameters before commencement of the multimedia session. The
sender and receiver use an Offer/Answer exchange [RFC3264] to match
cryptographic capabilities.
This section discusses Offer/Answer exchanges only for the RTP/SAVP
(SRTP). A future revision of this document will consider
Offer/Answer exchanges for security descriptions in general.
5.1 Offerer Processing The Offer/Answer model [RFC 3264] enables parties that wish to
engage in a multimedia session to negotiate the media stream
parameters that will be used for the multimedia session. In this
section, we detail how the security descriptions defined for SRTP
are used with the offer/answer model to negotiate cryptographic
capabilities and communicate SRTP master keys.
On each SDP media line (m=) where the <transport> is "RTP/SAVP", the 5.1 Generating the Offer
offerer MAY follow that media line with at least one a=crypto line.
The lines are specified in preference order, with the most preferred
listed first. The offerer determines the crypto parameters based on
its capabilities and its security policies.
To specify a list of preferred crypto suites for RTP, RTCP, or both, For each SDP media line (m=) using the "RTP/SAVP" transport where
the offerer includes separate a=crypto lines, in preference order. the offerer wants to specify cryptographic parameters, the offerer
Each offer is grouped. If separate rtp and rtcp keys are wanted, MUST provide at least one "a=crypto" line. When multiple crypto
the srtp a=crypto line MUST be sent first, and both the RTP and RTCP lines are provided, the a=crypto lines are specified in preference
keys MUST always be sent, even if the endpoint is recvonly. 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 or the uri pointing to a The offerer obtains keying material for "inline", or obtains the uri
keyserver by means that are outside the scope of this specification pointing to a key server. The mechanism to generate or obtain a key
(e.g. the offerer could generate the material or request the is outside the scope of this specification.
material from a third party).
5.2 Answerer Processing 5.2 Answerer Processing
For each SDP media line where the <transport> is RTP/SAVP and the For each SDP media line using the "RTP/SAVP" transport that contains
stream is bi-directional stream will be created, the answer MUST an "a=crypto" line in the offer, the answerer MUST either accept
include a media line with its <transport> set to RTP/SAVP in order exactly one of the crypto lines for that media stream, or it MUST
to accept the offer; otherwise, the offer is rejected for that media reject the media stream as described in RFC 3264. Note that if
entry. 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.
The answerer examines the a=crypto lines, in order. If the a=crypto Andreasen, Baugher & Wing [Page 12]
line indicates the application is rtp, and the line immediately To determine if the answerer can accept any of the provided
following indicates the application is rtcp, the receiver groups "a=crypto" lines, the answerer examines the crypto lines in order.
these two lines together; otherwise, this group is ignored as it is If an "a=crypto" line does not satisfy the constraints provided in
syntactically invalid. If the a=crypto line indicates the Section 4, that crypto line is deemed invalid and MUST be discarded.
application is "both", it is grouped by itself. The answerer selects the first valid crypto line that it supports,
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 grouping, the answerer selects the first group of a=crypto After selecting a single crypto line, the answerer generates a
that it supports, considering the answerer's capabilities and its master key appropriate for the selected crypto algorithm(s), unless
security policies. 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.
After selecting one group, the answerer obtains keys appropriate for To set up the bi-directional media with transport set to RTP/SAVP,
the selected crypto algorithm(s). The key MUST have the same key the answerer includes one "a=crypto" line after its media line with
length and salt length as the offer. transport set to RTP/SAVP.
To set up the bi-directional media with <transport> set to RTP/SAVP, 5.3 Offerer Processing of the Answer
the answerer includes one or two a=crypto lines after the media
line. If the offer indicated separate keys for RTP and RTCP, the
answer MUST do the same.
5.3 Non-RTP/SAVP Answerers When the offerer receives the answer, it MUST perform the following
steps for each "RTP/SAVP" media stream it offerered with one or more
crypto lines in it.
If a media line with <transport> set to RTP/SAVP is sent to a device If the media stream was accepted and it contains a crypto line, it
that doesn't suppport RTP/SAVP, that media line will not be MUST be checked that the media line is valid according to the
processed. constraints specified in Section 4. Furthermore, the offerer MUST
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.
If an offerer wants to interoperate with such a device, albeit It is possible that the answerer supports the "RTP/SAVP" transport
without the benefits of SRTP or SRTCP, the offerer MUST include an and accepts the offered media stream, yet it does not support the
additional media line with <transport> set to RTP/AVP, and other crypto attribute defined here. The offerer can recognize this
values in that line MUST match the values of the associated situation by seeing an accepted "RTP/SAVP" media stream in the
"RTP/SAVP" media line. This second media line would be specified answer that does not include a crypto line. In that case, the
after all of the attribute (a=) lines for the RTP/SAVP media security negotiation defined here MUST be deemed to have failed.
5.4 Offer/Answer Example: Receiver Supports SRTP Andreasen, Baugher & Wing [Page 13]
In this example, the offerer supports two crypto suites (F8 and 5.4 Non-RTP/SAVP Answerers
AES). When presented with multiple "a=crypto" lines for an "m="
line, the answerer will chose the first crypto suite that it
supports, and the answerer MUST reply with only one "a=crypto" line
per "m=" line
Offerer transmits: If a media stream with transport set to "RTP/SAVP" is sent to a
v=0 device that doesn't support "RTP/SAVP", that media stream will be
o=sam 2890844526 2890842807 IN IP4 10.47.16.5 rejected.
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/SAVP 0
a=crypto:AES_CM_128_HMAC_SHA1_80 both
inline:16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/20/1:32
a=crypto:F8_128_HMAC_SHA1_80 both
inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32
Answerer transmits: In some cases, it is desirable to send SRTP when possible, but allow
v=0 use of RTP if SRTP isn't supported by a remote device. However, it
o=jill 25690844 8070842634 IN IP4 10.47.16.5 is ambiguous to send an extra media line with transport set to
s=SRTP Discussion "RTP/AVP" and with the same port as the "RTP/SAVP" line. Thus, an
i=A discussion of Secure RTP offerer MUST NOT specify multiple media lines with the same port.
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 224.2.17.11/128
t=2873397526 2873405696
a=sendonly
m=audio 32640 RTP/SAVP 0
a=crypto:F8_128_HMAC_SHA1_80 both
inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32
In this case, the session would use the F8_128_HMAC_SHA1_80 crypto Instead, such interoperability is obtained by first sending an offer
suite for the RTP and RTCP traffic it generates. with transport set to "RTP/SAVP". If that media line is rejected by
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.5 Offer/Answer Example: Different SRTP and SRTCP keys 5.4 Offer/Answer Example: Receiver Supports SRTP
In this example, the offerer requests use of one crypto suite for In this example, the Offerer supports two crypto suites (F8 and
SRTP (AES) and a different crypto suite for RTCP. AES). The a=crypto line is actually one long line, although it is
shown as two lines in this document due to page formatting.
Offerer transmits: 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 224.2.17.12/127 c=IN IP4 168.2.17.12
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/SAVP 0 m=audio 49170 RTP/SAVP 0
a=crypto:AES_CM_128_HMAC_SHA1_80 rtp a=crypto:AES_CM_128_HMAC_SHA1_80
inline:16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/20/1:32 inline:d/16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/2^20/1:32
a=crypto:F8_128_HMAC_SHA1_80 rtcp FEC_ORDER=FEC_SRTP SRC=17174//49126
inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32 a=crypto:F8_128_HMAC_SHA1_80
inline:d/16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/2^20/1:32
FEC_ORDER=FEC_SRTP SRC=17174//49126
Answerer transmits: Answerer replies:
v=0 v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5 o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion s=SRTP Discussion
i=A discussion of Secure RTP i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson) e=homer@example.com (Homer Simpson)
c=IN IP4 224.2.17.11/128
Andreasen, Baugher & Wing [Page 14]
c=IN IP4 168.2.17.11
t=2873397526 2873405696 t=2873397526 2873405696
a=sendonly
m=audio 32640 RTP/SAVP 0 m=audio 32640 RTP/SAVP 0
a=crypto:AES_CM_128_HMAC_SHA1_80 rtp a=crypto:AES_CM_128_HMAC_SHA1_80
inline:16/14/8NxJiu9zZW1jdGwgKCkgewkyMjA7fQp9CnVubTnC/20/1:32 inline:d/16/14/PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR/2^20/1:32
a=crypto:F8_128_HMAC_SHA1_80 rtcp SRC=88131/721/13
16/14/c2VtZ2V0KSkgewogICAgc3V/20/1:32
5.6 Use of a=crypto With Active Media Streams 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
specifying both its initial SSRC (88131), rollover counter (721),
and rollover counter (13).
When an active SRTP session is rekeyed, this is indicated by sending 5.7 Use of a=crypto With Active Media Streams
a new SDP. Rekey MUST NOT be done with an Offer/Answer exchange,
but rather as a unidirectional SDP transmission.
When the Offerer needs to rekey, the Offerer MUST only send a=crypto When an active SRTP session is rekeyed, this is indicated by sending
lines which match a=crypto lines it had received in the Answer. a new SDP. Rekeying is done following the rules described for a
normal Offer/Answer exchange. The Answerer can take this
opportunity to rekey the traffic it is sending, if the Answerer
desires. During rekeying, the session parameters cannot be changed
and MUST NOT be specified in the Offer or the Answer.
When an SRTP or SRTCP transmitter needs to rekey, the only new When the Offerer needs to rekey, the offerer MUST send an "a=crypto"
values permitted in the a=crypto line(s) are the new key and new line with same crypto-suite, key length, and salt length that was
salt -- other cryptographic parameters MUST NOT be changed. previously accepted by the Answerer.
If the Answerer selected a=crypto lines using the "inline" method, If the answerer selected "a=crypto" lines using the "inline" method,
the exact same a=crypto line(s) as agreed to in the Answer MUST be 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. sent and a new new inline key MUST be sent.
If the Answer selected a=crypto lines using the "uri" method, the If the answerer selected "a=crypto" lines using the "uri" method,
sender MAY transmit the same uri, and the recipient MUST re-fetch the sender MAY transmit the same uri, and the recipient MUST fetch
the uri. the new key using the uri.
6.0 Security Considerations 5.8 Operation with KEYMGT and Key lines
One needs to define SDP security descriptions for a specific SDP An Offer MAY include both a=crypto and a=keymgt lines [keymgt]. Per
media transport for a=crypto to be useful. The definitions SHOULD SDP rules, the Answerer will ignore attribute lines it doesn't
be specified in an Internet RFC, which has security implications understand. If the Answerer supports both a=crypto and [keymgt],
that MUST be considered in the RFC. This section considers the SRTP the Answer MUST include either a=crypto or [keymgt], as including
descriptions for the RTP/SAVP transport as specified in this both is undefined.
Internet Draft.
6. Security Considerations
Like all SDP messages, SDP messages containing security
descriptions, are conveyed in an encapsulating application protocol
(e.g. SIP, MGCP, RTSP, SAP, etc.). It is the responsibility of the
encapsulating protocol to ensure the protection of the SDP security
descriptions. Therefore, that protocol should either invoke its own
security mechanisms to do so, or alternatively utilize a lower-layer
security service (e.g. TLS, IPSEC) where that service is deemed
adequate for protecting the encapsulating protocol itself. Where
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 6.1 Authentication of packets
RTP messages are vulnerable to a variety of attacks such as replay RTP messages are vulnerable to a variety of attacks such as replay
and forging. To limit these attacks, SRTP message integrity and and forging. To limit these attacks, SRTP message integrity
anti-replay mechanisms SHOULD be used. Source authentication of mechanisms SHOULD be used (SRTP replay protection is always
unicast SRTP messages SHOULD be performed [srtp]. Note that SRTP enabled). Source authentication of unicast SRTP messages SHOULD be
source-message authentication does not authenticate the IP-address performed [srtp]. Note that SRTP source-message authentication does
of the SRTP source, but ensures that the SRTP message that the SRTP not authenticate the IP-address of the SRTP source, but ensures that
receiver had received is exactly what the SRTP sender had sent. the SRTP message that the SRTP receiver had received is exactly what
Source authentication of multicast SRTP messages is today non- the SRTP sender had sent. Source authentication of multicast SRTP
standard and hence for further study. Use of the UNAUTHENTICATED messages is today non-standard and hence for further study. But
parameter therefore, is NOT RECOMMENDED. SRTP supports this setting, even in multicast sessions, SRTP packet authentication ensures that
however, for voice applications where authentication is implicit in the packet originated from a member of the secure group. Use of the
the application [srtp]. In general, applications SHOULD NOT set UNAUTHENTICATED_SRTP parameter, therefore, is NOT RECOMMENDED.
UNAUTHENTICATED.
6.1 Reuse of Keying Material ("Two-Time Pad") 6.1 Key-stream Reuse
Misconfigured SRTP sessions, moreover, are vulnerable to attacks on Misconfigured SRTP sessions, moreover, are vulnerable to attacks on
their encryption services when running crypto suites of Sections their encryption services when running the crypto suites defined in
4.1.1, 4.1.2 and 4.1.3. An SRTP encryption service is "mis- Sections 4.1.1, 4.1.2 and 4.1.3. An SRTP encryption service is
configured" when two or more media streams are encrypted using the "mis-configured" when two or more media streams are encrypted using
same AES keystream. When senders and receivers share derived the same AES keystream. When senders and receivers share derived
session keys, SRTP requires that the SSRCs of session participants session keys, SRTP requires that the SSRCs of session participants
make them unique, which is violated in the case of SSRC collision: make their corresponding keystreams unique, which is violated in the
RTP SSRC collision reveals SRTP or SRTCP plaintext during the time case of SSRC collision: SRTP SSRC collision drastically weakens SRTP
that identical keystreams were used [srtp]. An attacker, for or SRTCP payload encryption during the time that identical
example, might collect SRTP and SRTCP messages and await a keystreams were used [srtp]. An attacker, for example, might
collision. This attack on the AES-CM and AES-f8 encryption is collect SRTP and SRTCP messages and await a collision. This attack
avoided entirely when each media stream has its own unique master on the AES-CM and AES-f8 encryption is avoided entirely when each
key, as this document requires (Section 4.2). There is risk of media stream has its own unique master key, as this document
attack, however, when an SDP media stream has an "a=sendrecv" RECOMMENDS (Section 4.2).
direction attribute and a pair of senders are sharing a master key
for their encryption (i.e. a weaker condition than sharing a master
key). It is RECOMMENDED, therefore, that a sendrecv stream have two
SRTP master keys, one for each directional stream. By implication,
the SDP message that describes the sendrecv stream MUST NOT be a
multicast media stream that provides inline keys from multiple
receivers. For the same reason, the risk recurs when a media stream
has an "a=sendonly" direction attribute in an multicast SDP message.
SRTP multicast operation requires that each host-sender have a SRTP multicast operation requires that each host-sender have a
unique SRTP master key. This can be accomplished by ensuring that unique SRTP keystream. This can be accomplished by ensuring that
each receiver 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 receiver is unique. Since SSRC collision might occur, the of each sender will not collide. Since SSRC collision might occur,
latter condition is not possible unless 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]. This is
for further study. The RECOMMENDED approach of this document is to for further study. The RECOMMENDED approach of this document is to
allocate a different master key for each host-participant of an SRTP allocate a different master key for each host-participant of an SRTP
session. session.
Andreasen, Baugher & Wing [Page 16]
6.2 Signaling Authentication and Signaling Encryption 6.2 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 attribute and its unauthorized parties. In most cases, the SRTP crypto attribute and
parameters are vulnerable to denial of service attacks when they are its parameters are vulnerable to denial of service attacks when they
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 set 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, S/MIME or some other data security service SHOULD be IPsec, TLS, encapsulating-protocol security or some other data
used to provide message authentication for SDP messages that carry security service SHOULD be used to provide message authentication
the SRTP attribute. Message encryption SHOULD be used when a master for SDP messages that carry the SRTP attribute. Message encryption
key parameter appears in the message. Failure to encrypt the SDP SHOULD be used because a master key parameter appears in the
message containing an inline SRTP master key renders the SRTP message. Failure to encrypt the SDP message containing an inline
authentication or encryption service useless in practically all SRTP master key renders the SRTP authentication or encryption
circumstances. Failure to authenticate an SDP message that carries service useless in practically all circumstances. Failure to
SRTP parameters renders the SRTP authentication or encryption authenticate an SDP message that carries SRTP parameters renders the
service useless in most practical applications. SRTP authentication 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 statement [keymgt] protocol be used. The proposed SDP key-mgmt extension [keymgt]
allows authentication and encryption of the key management protocol allows authentication and encryption of the key management protocol
data independently of the SDP message that carries it. The security data independently of the SDP message that carries it. The security
of the SDP SRTP attribute, however, is as good as the data 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 endpoint, its
signaling controller, and the destination endpoints, then this signaling controller, and the destination endpoints, then this
solution is more secure than use of the key-mgmt statement in an solution is more secure than use of the key-mgmt statement in an
unauthenticated SDP message, which is vulnerable to tampering. unauthenticated SDP message, which is 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-
skipping to change at page 18, line 15 skipping to change at line 880
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.
In this case, the third-party provider is provided the contents of Andreasen, Baugher & Wing [Page 17]
the SRTP attribute descriptions in the SDP message. SDP key-mgmt In this case, the third-party provider gets the contents of the SRTP
statement, however, allows true end-to-end security that is descriptions in the SDP message. SDP key-mgmt statement, however,
independent of the service provider, who often needs access to some allows true end-to-end security that is independent of the service
parts of the SDP message to render its services. The SRTP attribute provider, who often needs access to some parts of the SDP message to
MUST NOT be used when end-to-end authentication or confidentiality render its services. The SRTP attribute SHOULD NOT be used when
is needed but the SDP message is not secured end to end (such as the end-to-end authentication or confidentiality is needed but the SDP
above example where a third-party provider maintains the security message is not secured end to end (such as the above example where a
associations with the endpoints for the SDP message). third-party provider maintains the security associations with the
endpoints for the SDP message).
7.0 Grammar 7. SRTP "Crypto" Attribute Grammar
This section provides an Augmented BNF grammar for the SRTP profile This section provides an Augmented BNF grammar for the SRTP profile
of the SDP crypto-attribute. ABNF is defined in [RFC2234]. The of the SDP crypto attribute. ABNF is defined in [RFC2234].
rule names <att-field> and <att-value> are from SDP [RFC2327].
att-field = "crypto"
att-value = cipher application
application = cipher-both / cipher-srtp / cipher-srtcp
cipher-both = key-parameter *[SP sess-par-both]
cipher-srtp = key-parameter *[SP sess-par-srtp]
cipher-srtcp = key-parameter *[SP sess-par-srtcp]
key-parameter = method-inline / method-uri key-param = method-inline / method-uri
cipher = "AES_CM_128_HMAC_SHA1_32" / crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" "AES_CM_128_HMAC_SHA1_80"
sess-par-both = roc / ; Roll-Over Counter method-inline = "inline:" key-info *(SP session-param)
kdr / ; Key Derivation Rate
"UNENCRYPTED"
sess-par-srtp = ssrc / fec-order
sess-par-srtcp = "UNAUTHENTICATED"
method-inline = "inline:" key-info
method-uri = "uri:<" absoluteURI ">" ; absoluteURI defined in method-uri = "uri:<" absoluteURI ">" ; absoluteURI defined in
; [RFC2396] ; [RFC2396]
key-info = "/" key-length "/" salt-length "/" key-salt key-info = key-use "/" key-length "/" salt-length "/" key-salt
"/" [lifetime] "/" [mki] "/" [lifetime] "/" [mki]
key-length = 1*(DIGIT) ; length in bytes key-use = "d" / "e" / "b" ; decrypt, encrypt, or both
salt-length = 1*(DIGIT) ; length in bytes key-length = 1*DIGIT
key = 1*(base64) salt-length = 1*DIGIT
salt = 1*(base64)
key-salt = key salt ; key and salt concatenated and key-salt = 1*(base64) ; binary key and salt values
; then base64 encoded [section ; concatenated together, and then
; 6.8 of RFC2045] ; base64 encoded [section 6.8 of
; RFC2046]
lifetime = ["2^"] 1*(DIGIT) lifetime = ["2^"] 1*(DIGIT)
mki = "/" mki-length ":" mki-value mki = mki-length ":" mki-value
mki-length = 1*3(DIGIT) ; MUST be multiple of 8 and mki-length = 1*DIGIT ; real value is 2^mki-length, max 128
; MUST not exceed 128 mki-value = 1*DIGIT
mki-value = 1*(base64)
roc = "ROC:" 1*(DIGIT) session-param = src /
kdr = "KDR:" 1*(DIGIT) kdr /
"UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" /
fec-order
ssrc = "SSRC:" ssrc-value Andreasen, Baugher & Wing [Page 18]
ssrc-value = 1*(DIGIT) *["," ssrc-value] src = "SRC=" [ssrc] "/" [roc] "/" [seq]
fec-order = "FEC:" 1*(DIGIT) ssrc = 1*DIGIT ; range 0...2^32-1
roc = 1*DIGIT ; range 0...2^32-1
seq = 1*DIGIT ; range 0...2^16-1
kdr = "KDR=" 1*(DIGIT)
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC" / "SPLIT"
base64 = ALPHA / DIGIT / "+" / "/" / "=" base64 = ALPHA / DIGIT / "+" / "/" / "="
8.0 Acknowledgements 8. Open Issues
This document benefited from discussions with Flemming Andreasen, The following is a list of open issues in this document:
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 recommended the generic approach to the
SDP media-stream security descriptions that is followed in this
draft. Flemming Andreasen suggested some changes to an earlier
draft that greatly simplify this document. David McGrew suggested
the conservative approach of using unique master keys for each SDP
media stream as followed in this document. Jonathan Rosenberg
suggested reducing the complexity by specifying only one security
parameter for each media stream.
9.0 Authors' Addresses * The crypto attribute can be used with or without offer/answer,
however, details on usage outside of offer/answer are missing.
* The offer/answer procedures need to be expanded to better describe
unidirectional and inactive streams, unicast versus multicast, as
well as additional detail for some of the session parameters.
9. Acknowledgements
This document 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
of using unique master keys for each SDP media stream as followed in
this document. Jonathan Rosenberg suggested reducing the complexity
by specifying only one security parameter for each media stream.
10. Authors' Addresses
Flemming Andreasen
Cisco Systems, Inc.
499 Thornall Street, 8th Floor
Edison, New Jersey 08837 USA
fandreas@cisco.com
Mark Baugher Mark Baugher
5510 SW Orchid Street 5510 SW Orchid Street
Portland, Oregon Portland, Oregon 97219 USA
mbaugher@rdrop.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 525 5314 +1-408-902-3348
10.0 References 11. Normative References
[RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", January 1996,
http://www.ietf.org/rfc/rfc1889.txt.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF," November 1997,
http://www.ietf.org/rfc/rfc2234.txt.
[SDPnew] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
Description Protocol,", Work in Progress.
[RFC2828] R. Shirey, "Internet Security Glossary", May 2000,
http://www.ietf.org/rfc/rfc2828.txt
[RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", June 2202,
http://www.ietf.org/rfc/rfc3264.txt
[srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K.
Norrman, D. Oran, "The Secure Real-time Transport Protocol", May
2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-
08.txt, Work in Progress
[RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
12. Informative References
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[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.
[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", June 2002, "Key Management Extensions for SDP and RTSP", February 2003,
http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext- http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-
06.txt, Work in Progress 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", July 2002,
http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt, http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt,
Work in Progress Work in Progress.
[RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", January 1996,
http://www.ietf.org/rfc/rfc1889.txt
[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",
November 1996, http://www.ietf.org/rfc/rfc2045.txt 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", November 1997,
http://www.ietf.org/rfc/rfc2104.txt http://www.ietf.org/rfc/rfc2104.txt.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", November 1997,
http://www.ietf.org/rfc/rfc2234.txt
[RFC2327] M. Handley, V. Jacobson, "SDP: Session Description
Protocol", April 1998, http://www.ietf.org/rfc/rfc2327.txt
[RFC2828] R. Shirey, "Internet Security Glossary", May 2000,
http://www.ietf.org/rfc/rfc2828.txt
[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998,
http://www.ietf.org/rfc/rfc2396.txt
[RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", June 2202,
http://www.ietf.org/rfc/rfc3264.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.
[srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. Intellectual Property Statement
Norrman, D. Oran, "The Secure Real-time Transport Protocol", June
2002, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-
05.txt, Work in Progress
11.0 Full Copyright Statement The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
"Copyright (C) The Internet Society 2003. All Rights Reserved. The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
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.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"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
Funding for the RFC Editor function is currently provided by the
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/