Request for Comments: 4568 M. Baugher
Category: Standards Track D. Wing
Cisco Systems
July 2006
Session Description Protocol (SDP)
Security Descriptions for Media Streams
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a Session Description Protocol (SDP)
cryptographic attribute for unicast media streams. The attribute
describes a cryptographic key and other parameters that serve to
configure security for a unicast media stream in either a single
message or a roundtrip exchange. The attribute can be used with a
variety of SDP media transports, and this document defines how to use
it for the Secure Real-time Transport Protocol (SRTP) unicast media
streams. The SDP crypto attribute requires the services of a data
security protocol to secure the SDP message.
Table of Contents
1. Introduction ....................................................3
2. Notational Conventions ..........................................5
3. Applicability ...................................................5
4. SDP "Crypto" Attribute and Parameters ...........................5
4.1. Tag ........................................................6
4.2. Crypto-Suite ...............................................6
4.3. Key Parameters .............................................7
4.4. Session Parameters .........................................8
4.5. Example ....................................................8
5. General Use of the crypto Attribute .............................9
5.1. Use with Offer/Answer ......................................9
5.1.1. Generating the Initial Offer - Unicast Streams ......9
5.1.2. Generating the Initial Answer - Unicast Streams ....10
5.1.3. Processing of the Initial Answer - Unicast
Streams ............................................11
5.1.4. Modifying the Session ..............................11
5.2. Use Outside Offer/Answer ..................................11
5.3. General Backwards Compatibility Considerations ............12
6. SRTP Security Descriptions .....................................12
6.1. SRTP Key Parameter ........................................13
6.2. Crypto-Suites .............................................16
6.2.1. AES_CM_128_HMAC_SHA1_80 ............................16
6.2.2. AES_CM_128_HMAC_SHA1_32 ............................17
6.2.3. F8_128_HMAC_SHA1_80 ................................17
6.2.4. Adding New Crypto-Suite Definitions ................17
6.3. Session Parameters ........................................17
6.3.1. KDR=n ..............................................18
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP .............18
6.3.3. UNAUTHENTICATED_SRTP ...............................18
6.3.4. FEC_ORDER=order ....................................19
6.3.5. FEC_KEY=key-params .................................19
6.3.6. Window Size Hint (WSH) .............................19
6.3.7. Defining New SRTP Session Parameters ...............20
6.4. SRTP Crypto Context Initialization ........................20
6.4.1. Late Binding of One or More SSRCs to a
Crypto Context .....................................21
6.4.2. Sharing Cryptographic Contexts among
Sessions or SSRCs ..................................22
6.5. Removal of Crypto Contexts ................................23
7. SRTP-Specific Use of the Crypto Attribute ......................23
7.1. Use with Offer/Answer .....................................23
7.1.1. Generating the Initial Offer - Unicast Streams .....23
7.1.2. Generating the Initial Answer - Unicast Streams ....24
7.1.3. Processing of the Initial Answer - Unicast
Streams ............................................25
7.1.4. Modifying the Session ..............................25
7.1.5. Offer/Answer Example ...............................27
7.2. SRTP-Specific Use Outside Offer/Answer ....................28
7.3. Support for SIP Forking ...................................28
7.4. SRTP-Specific Backwards Compatibility Considerations ......29
7.5. Operation with KEYMGT= and k= lines .......................29
8. Security Considerations ........................................29
8.1. Authentication of Packets .................................30
8.2. Keystream Reuse ...........................................30
8.3. Signaling Authentication and Signaling Encryption .........31
9. Grammar ........................................................32
9.1. Generic "Crypto" Attribute Grammar ........................32
9.2. SRTP "Crypto" Attribute Grammar ...........................32
10. IANA Considerations ...........................................34
10.1. Registration of the "crypto" Attribute ...................34
10.2. New IANA Registries and Registration Procedures ..........34
10.2.1. Key Method Registry and Registration ..............34
10.2.2. Media Stream Transport Registry and Registration ..35
10.3. Initial Registrations ....................................35
10.3.1. Key Method ........................................35
10.3.2. SRTP Media Stream Transport .......................35
10.3.2.1. SRTP Crypto Suite Registry and
Registration .............................35
10.3.2.2. SRTP Session Parameter Registration ......36
11. Acknowledgements ..............................................36
12. Normative References ..........................................36
13. Informative References ........................................37
Appendix A - Rationale for Keying Material Directionality .........40
1. Introduction
The Session Description Protocol (SDP) [RFC4566] describes multimedia
sessions, which can be audio, video, whiteboard, fax, modem, and
other media streams. Security services such as data origin
authentication, integrity, and confidentiality are often needed for
those streams. The Secure Real-time Transport Protocol (SRTP)
[RFC3711] provides security services for RTP media and is signaled by
use of secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an
SDP media (m=) line. However, there are no means within SDP itself
to configure SRTP beyond using default values. This document
specifies a new SDP attribute called "crypto", which is used to
signal and negotiate cryptographic parameters for media streams in
general, and for SRTP in particular. The definition of the crypto
attribute in this document is limited to two-party unicast media
streams where each source has a unique cryptographic key; support for
multicast media streams or multipoint unicast streams is for further
study.
The crypto attribute is defined in a generic way to enable its use
with SRTP and any other secure transports that can establish
cryptographic parameters with only a single message or in a single
round-trip exchange using the offer/answer model [RFC3264].
Extensions to transports other than SRTP, however, is beyond the
scope of this document. Each type of secure media transport needs
its own specification for the crypto-attribute parameter. These
definitions are frequently unique to the particular type of transport
and must be specified in a Standards-Track RFC and registered with
IANA according to the procedures defined in Section 10. This
document defines the security parameters and keying material for SRTP
only.
It would be self-defeating not to secure cryptographic keys and other
parameters at least as well as the data are secured. 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 protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE
[ike], Secure Multiparts [s/mime, pgp/mime], or TLS [TLS] securely
disseminates information describing both the key and the data-
security session. AKE is needed because it is pointless to provide 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
of the security session to gain unauthorized access to session-
related information.
SDP, however, was not designed to provide AKE services, and the media
security descriptions defined in this document do not add AKE
services to SDP. This specification is no replacement for a key
management protocol or for the conveyance of key management messages
in SDP [keymgt]. The SDP security descriptions defined here are
suitable for restricted cases only where IPsec, TLS, or some other
encapsulating data-security protocol (e.g., SIP S/MIME) protects the
SDP message. This document adds security descriptions to those
encrypted and/or authenticated SDP messages through the new SDP
"crypto" attribute, which provides the cryptographic parameters of a
media stream.
The "crypto" attribute can be adapted to any media transport, but its
precise definition is unique to a particular transport.
In Section 2, we provide notational conventions followed by an
applicability statement for the crypto attribute in Section 3. In
Section 4, we introduce the general SDP crypto attribute, and in
Section 5, we define how it is used with and without the offer/answer
model. In Section 6, we define the crypto attribute details needed
for SRTP, and in Section 7, we define SRTP-specific use of the
attribute with and without the offer/answer model. Section 8 recites
security considerations, and Section 9 gives an Augmented-BNF grammar
for the general crypto attribute as well as the SRTP-specific use of
the crypto attribute. IANA considerations are provided in Section
10.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary".
n^r is exponentiation, where n is multiplied by itself r times; n and
r are integers. 0..k is an integer range of all integers from 0
through k, inclusive.
The terms ’transport’ and ’media transport’ are used to mean
’transport protocol’ as defined in RFC 4566.
Explanatory notes are provided in several places throughout the
document; these notes are indented three spaces from the surrounding
text.
3. Applicability
RFC 4567 provides similar cryptographic key distribution capabilities
and is intended for use when the signaling is to be confidential
and/or integrity-protected separately from the keying material.
In contrast, this specification carries the keying material within
the SDP message, and it is intended for use when the keying material
is protected along with the signaling. Implementations MUST employ
security mechanisms that provide confidentiality and integrity for
the keying material. When this specification is used in the context
of SIP [RFC3261], the application SHOULD employ either the SIPS URI
or S/MIME to provide protection for the SDP message and the keying
material that it contains. The use of transport layer or IP layer
security in lieu of the SIPS URI or S/MIME protection is NOT
RECOMMENDED since the protection of the SDP message and the keying
material that it contains cannot be ensured through all intermediate
entities such as SIP proxies.
4. SDP "Crypto" Attribute and Parameters
A new media-level SDP attribute called "crypto" describes the
cryptographic suite, key parameters, and session parameters for the
preceding unicast media line. The "crypto" attribute MUST only
appear at the SDP media level (not at the session level). The
"crypto" attribute follows the format (see Section 9.1 for the formal
ABNF grammar):
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
The fields tag, crypto-suite, key-params, and session-params are
described in the following sub-sections. The values of each of these
fields is case-insensitive, unless otherwise noted. However,
implementers are encouraged to use the actual case shown in this
document and any extensions to it. Note that per normal SDP rules,
the "crypto" attribute name itself is case-sensitive. Below, we show
an example of the crypto attribute for the "RTP/SAVP" transport,
i.e., the secure RTP extension to the Audio/Video Profile [RFC3711].
In the following, newlines are included for formatting reasons only:
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined by
the text starting with "inline:", and session-params is omitted.
4.1. Tag
The tag is a decimal number used as an identifier for a particular
crypto attribute (see Section 9.1 for details); leading zeroes MUST
NOT be used. The tag MUST be unique among all crypto attributes for
a given media line. It is used with the offer/answer model to
determine which of several offered crypto attributes were chosen by
the answerer (see Section 5.1).
In the offer/answer model, the tag is a negotiated parameter.
4.2. Crypto-Suite
The crypto-suite field is an identifier that describes the encryption
and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for the
transport in question (see Section 9.1 for details). The possible
values for the crypto-suite parameter are defined within the context
of the transport, i.e., each transport defines a separate namespace
for the set of crypto-suites. For example, the crypto-suite
"AES_CM_128_HMAC_SHA1_80" defined within the context "RTP/SAVP"
transport applies to Secure RTP only; the string may be reused for
another transport (e.g., "RTP/SAVPF" [srtpf]), but a separate
definition would be needed.
In the offer/answer model, the crypto-suite is a negotiated
parameter.
4.3. Key Parameters
The key-params field provides one or more sets of keying material for
the crypto-suite in question. The field consists of a method
indicator followed by a colon, and the actual keying information as
shown below (the formal grammar is provided in Section 9.1):
key-params = <key-method> ":" <key-info>
Keying material might be provided by different means from that for
key-params; however, this is out of scope. Only one method is
defined in this document, namely, "inline", which indicates that the
actual keying material is provided in the key-info field itself.
There is a single name space for the key-method, i.e., the key-method
is transport independent. New key-methods (e.g., use of a URL) may
be defined in a Standards-Track RFC in the future. Although the
key-method itself may be generic, the accompanying key-info
definition is specific not only to the key-method, but also to the
transport in question. Key-info encodes keying material for a crypto
suite, which defines that keying material. New key methods MUST be
registered with the IANA according to the procedures defined in
Section 10.2.1.
Key-info is defined as a general octet string (see Section 9.1 for
details); further transport and key-method specific syntax and
semantics MUST be provided in a Standards-Track RFC for each
combination of transport and key-method that uses it; definitions for
SRTP are provided in Section 6. Note that such definitions are
provided within the context of both a particular transport (e.g.,
"RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will
register the list of supported key methods for each transport.
When multiple keys are included in the key parameters, it MUST be
possible to determine which of the keys is being used in a given
media packet by a simple inspection of the media packet received; a
trial-and-error approach between the possible keys MUST NOT be
performed.
For SRTP, this could be achieved by use of Master Key Identifiers
(MKI) [RFC3711]. Use of <"From, "To"> values are not supported in
SRTP security descriptions for reasons explained in Section 6.1,
below.
In the offer/answer model, the key parameter is a declarative
parameter.
4.4. Session Parameters
Session parameters are specific to a given transport and use of them
is OPTIONAL in the security descriptions framework, where they are
just defined as general character strings. If session parameters are
to be used for a given transport, then transport-specific syntax and
semantics MUST be provided in a Standards-Track RFC; definitions for
SRTP are provided in Section 6.
In the offer/answer model, session parameters may be either
negotiated or declarative; the definition of specific session
parameters MUST indicate whether they are negotiated or declarative.
Negotiated parameters apply to data sent in both directions, whereas
declarative parameters apply only to media sent by the entity that
generated the SDP. Thus, a declarative parameter in an offer applies
to media sent by the offerer, whereas a declarative parameter in an
answer applies to media sent by the answerer.
4.5. Example
This example shows use of the crypto attribute for the "RTP/SAVP"
media transport type (as defined in Section 5). The "a=crypto" line
is actually one long line; it is shown as two lines due to page
formatting.
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb
a=orient:portrait
This SDP message describes three media streams, two of which use the
"RTP/SAVP" transport. Each has a crypto attribute for the "RTP/SAVP"
transport. These secure-RTP specific descriptions are defined in
Section 6.
5. General Use of the crypto Attribute
In this section, we describe the general use of the crypto attribute
outside of any transport or key-method specific rules.
5.1. Use with Offer/Answer
The general offer/answer rules for the crypto attribute are in
addition to the rules specified in RFC 3264, which MUST be followed,
unless otherwise noted. RFC 3264 defines operation for both unicast
and multicast streams; the sections below describe operation for
two-party unicast streams only, since support for multicast streams
(and multipoint unicast streams) is for further study.
5.1.1. Generating the Initial Offer - Unicast Streams
When generating an initial offer for a unicast stream, there MUST be
one or more crypto attributes present for each media stream for which
security is desired. Each crypto attribute for a given media stream
MUST contain a unique tag.
The ordering of multiple "a=crypto" lines is significant: the most
preferred crypto line is listed first. Each crypto attribute
describes the crypto-suite, key(s), and possibly session parameters
offered for the media stream. In general, a "more preferred"
crypto-suite SHOULD be cryptographically stronger than a "less
preferred" crypto-suite.
The crypto-suite always applies to media in the directions supported
by the media stream (e.g., send and receive). The key(s), however,
apply to data packets (e.g., SRTP and SRTCP packets) that will be
sent by the same party that generated the SDP. That is, each
endpoint determines its own transmission keys and sends those keys,
in SDP, to the other endpoint.
This is done for consistency. Also, in the case of SRTP, for
example, secure RTCP will still be flowing in both the send and
receive direction for a unidirectional stream.
The inline parameter conveys the keying material used by an endpoint
to encrypt the media streams transmitted by that endpoint. The same
keying material is used by the recipient to decrypt those streams.
The offer may include session parameters. There are no general offer
rules for the session parameters; instead, specific rules may be
provided as part of the transport-specific definitions of any session
parameters.
When issuing an offer, the offerer MUST be prepared to support media
security in accordance with any of the crypto attributes included in
the offer. There are, however, two problems associated with this.
First of all, the offerer does not know which key the answerer will
be using for media sent to the offerer. Second, the offerer may not
be able to deduce which of the offered crypto attributes were
accepted. Since media may arrive prior to the answer, delay or
clipping can occur. If this is unacceptable to the offerer, the
offerer SHOULD use a mechanism outside the scope of this document to
prevent the above problem.
For example, in SIP [RFC3261], a "security" precondition as
defined in [sprecon] could solve the above problem.
5.1.2. Generating the Initial Answer - Unicast Streams
When the answerer receives the initial offer with one or more crypto
attributes for a given unicast media stream, the answerer MUST either
accept exactly one of the offered crypto attributes, or the offered
stream MUST be rejected.
If the answerer wishes to indicate support for other crypto
attributes, those can be listed by use of the SDP Simple
Capability Declaration [RFC3407] extensions.
Only crypto attributes that are valid can be accepted; valid
attributes do not violate any of the general rules defined for
security descriptions, nor any specific rules defined for the
transport and key-method in question. When selecting one of the
valid crypto attributes, the answerer SHOULD select the most
preferred crypto attribute it can support, i.e., the first valid
supported crypto attribute in the list, according to the answerer’s
capabilities and security policies.
If there are one or more crypto attributes in the offer, but none of
them are valid or none of the valid ones are supported, the offered
media stream MUST be rejected.
When an offered crypto attribute is accepted, the crypto attribute in
the answer MUST contain the following:
* The tag and crypto-suite from the accepted crypto attribute in the
offer (the same crypto-suite MUST be used in the send and receive
direction).
* The key(s) the answerer will be using for media sent to the
offerer. Note that a key MUST be provided, irrespective of any
direction attributes in the offer or answer.
Furthermore, any session parameters that are negotiated MUST be
included in the answer. Declarative session parameters provided by
the offerer are not included in the answer; however, the answerer may
provide its own set of declarative session parameters.
Once the answerer has accepted one of the offered crypto attributes,
the answerer MAY begin sending media to the offerer in accordance
with the selected crypto attribute. Note, however, that the offerer
may not be able to process such media packets correctly until the