its parameters are vulnerable to denial-of-service attacks when they
are carried in an unauthenticated SDP message. In some cases, the
integrity or confidentiality of the RTP stream can be compromised.
For example, if an attacker sets UNENCRYPTED for the SRTP stream in
an offer, this could result in the answerer’s not decrypting the
encrypted SRTP messages. In the worst case, the answerer might
itself send unencrypted SRTP and leave its data exposed to snooping.
Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or some
other data security service be used to provide message authentication
for the encapsulating protocol that carries the SDP messages having a
crypto attribute (a=crypto). Furthermore, IT IS REQUIRED that
encryption of the encapsulating payload be used whenever a master key
parameter (inline) appears in the message. Failure to encrypt the
SDP message containing an inline SRTP master key renders the SRTP
authentication or encryption service useless in practically all
circumstances. Failure to authenticate an SDP message that carries
SRTP parameters renders the SRTP authentication or encryption service
useless in most practical applications.
When the communication path of the SDP message is routed through
intermediate systems that inspect parts of the SDP message, security
protocols such as [IPsec] or TLS SHOULD NOT be used for encrypting
and/or authenticating the security description. In the case of
intermediate-system processing of a message containing SDP security
descriptions, the "a=crypto" attributes SHOULD be protected end-to-
end so that the intermediate system can neither modify the security
description nor access the keying material. Network or transport
security protocols that terminate at each intermediate system,
therefore, SHOULD NOT be used for protecting SDP security
descriptions. A security protocol SHOULD allow the security
descriptions to be encrypted and authenticated end-to-end
independently of the portions of the SDP message that any
intermediate system modifies or inspects: MIME secure multiparts are
RECOMMENDED for the protection of SDP messages that are processed by
intermediate systems.
9. Grammar
In this section, we first provide the ABNF grammar for the generic
crypto attribute, and then we provide the ABNF grammar for the SRTP-
specific use of the crypto attribute.
9.1. Generic "Crypto" Attribute Grammar
The ABNF grammar for the crypto attribute is defined below:
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = 1*(%x21-3A / %x3C-7E) ; visible (printing) chars
; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters
where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC4234].
9.2. SRTP "Crypto" Attribute Grammar
This section provides an Augmented BNF [RFC4234] grammar for the
SRTP-specific use of the SDP crypto attribute:
crypto-suite = srtp-crypto-suite
key-method = srtp-key-method
key-info = srtp-key-info
session-param = srtp-session-param
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext
srtp-key-method = "inline"
srtp-key-info = key-salt ["|" lifetime] ["|" mki]
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 3 of
; RFC3548
lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^"
mki = mki-value ":" mki-length
mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
srtp-session-param = kdr /
"UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" /
fec-order /
fec-key /
wsh /
srtp-session-extension
kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "="
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC4234]
; first character must not be dash ("-")
10. IANA Considerations
10.1. Registration of the "crypto" Attribute
The IANA has registered a new SDP attribute as
follows:
Attribute name: crypto
Long form name: Security description cryptographic attribute
for media streams
Type of attribute: Media-level
Subject to charset: No
Purpose: Security descriptions
Appropriate values: See Section 4
10.2. New IANA Registries and Registration Procedures
The following sub-sections define a new IANA registry with associated
sub-registries to be used for the SDP security descriptions. The
IANA has created an SDP Security Description registry as shown below
and further described in the following sections:
SDP Security Descriptions
|
+- Key Methods (described in 10.2.1)
|
+- Media Stream Transports (described in 10.2.2)
|
+- Transport1 (e.g., SRTP)
| |
| +- Supported Key Methods (e.g., inline)
| |
| +- crypto suites
| |
| +- session parameters
|
+- Transport2
: :
10.2.1. Key Method Registry and Registration
The IANA has created a new subregistry for SDP security description
key methods. An IANA key method registration MUST be documented in
an RFC in accordance with the [RFC2434] Standards Action, and it MUST
provide the name of the key method in accordance with the grammar for
key-method-ext defined in Section 9.1.
10.2.2. Media Stream Transport Registry and Registration
The IANA has created a new subregistry for SDP security description
Media Stream Transports. An IANA media stream transport registration
MUST be documented in an RFC in accordance with the RFC 2434
Standards Action and the procedures defined in Sections 4 and 5 of
this document. The registration MUST provide the name of the
transport and a list of supported key methods.
In addition, each new media stream transport registry must contain a
crypto-suite registry and a session parameter registry, as well as
IANA instructions for how to populate these registries.
10.3. Initial Registrations
10.3.1. Key Method
The following security descriptions key methods are hereby
registered:
inline
10.3.2. SRTP Media Stream Transport
The IANA has created an SDP Security Description Media Stream
Transport subregistry for "SRTP". The key methods supported is
"inline". The reference for the SDP security description for SRTP is
this document.
10.3.2.1. SRTP Crypto Suite Registry and Registration
The IANA has created a new subregistry for SRTP crypto suites under
the SRTP transport of the SDP Security Descriptions. An IANA SRTP
crypto suite registration MUST indicate the crypto suite name in
accordance with the grammar for srtp-crypto-suite-ext defined in
Section 9.2.
The semantics of the SRTP crypto suite MUST be described in an RFC in
accordance with the RFC 2434 Standards Action, including the
semantics of the "inline" key-method and any special semantics of
parameters.
The following SRTP crypto suites are hereby registered:
AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80
The reference for these crypto suites is provided in this document.
10.3.2.2. SRTP Session Parameter Registration
The IANA has created a new subregistry for SRTP session parameters
under the SRTP transport of the SDP Security Descriptions. An IANA
SRTP session parameter registration MUST indicate the session
parameter name (srtp-session-extension as defined in Section 9.2);
the name MUST NOT begin with the dash character ("-").
The semantics of the parameter MUST be described in an RFC in
accordance with the RFC 2434 Standards Action. If values can be
assigned to the parameter, then the format and possible values that
can be assigned MUST be described in the RFC in accordance with the
RFC 2434 Standards Action as well. Also, it MUST be specified
whether the parameter is declarative or negotiated in the
offer/answer model.
The following SRTP session parameters are hereby registered:
KDR
UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP
UNAUTHENTICATED_SRTP
FEC_ORDER
FEC_KEY
WSH
The reference for these parameters is this document.
11. Acknowledgements
This document is a product of the IETF MMUSIC working group and has
benefited from comments from its participants. This document also
benefited from discussions with Elisabetta Cararra, Earl Carter, Per
Cederqvist, Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat,
David McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave
Singer, Mike Thomas, Brian Weis, and Magnus Westerlund.
12. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
13. Informative References
[sprecon] Andreasen, F. and D. Wing, "Security Preconditions for
Session Description Protocol Media Streams", Work in
Progress, October 2005.
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[Bellovin] Bellovin, S., "Problem Areas for the IP Security
Protocols," in Proceedings of the Sixth Usenix Unix
Security Symposium, pp. 1-16, San Jose, CA, July 1996.
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[kink] Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber,
"Kerberized Internet Negotiation of Keys (KINK)", RFC
4430, March 2006.
[ike] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[ipsec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[maxprate] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", RFC
3890, September 2004.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, December
1999.
[s/mime] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[pgp/mime] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[keymgt] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[mikey] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[skeme] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for the Internet", ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", work in progress,
October 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, September 2002.
Appendix A - Rationale for Keying Material Directionality
SDP security descriptions define the keying material for the sending
direction, which is included in the SDP. Thus, the key that is
carried in an SDP message is a decryption key for the receiver of
that SDP message. This is in contrast to the majority of information
included in SDP, which describes information for the receiving (or
receiving and sending) direction. This reversed information
directionality generates some challenges with using the mechanism in
the offer/answer model and in particular with SIP, where early media
and forking require special consideration (as described in Section
7.3). There are however good reasons for why this was done, which
can be summarized as follows:
First of all, there is the general security philosophy of letting the
entity that sends traffic decide what key to use for protecting it.
SRTP uses counter mode, which is secure when counters do not overlap
among senders who share a master key; the surest way to avoid counter
overlap is for each endpoint to generate its own master key.
Secondly, if SDP security descriptions had been designed to keep the
normal SDP information directionality, it would have resulted in
problems with supporting early media and SIP forking: If an offer
generates multiple answers and the keying material was for the
receive direction, some of the parameter values (e.g. lifetime) would
have to be shared between all the answerers (senders of media), which
would lead to considerable complexity, possibly requiring changes or
extensions to SRTP. Other problems were discovered as well, which we
describe further below.
In the following scenarios, we analyze what would occur if SDP
security descriptions had been designed so that the keying material
was the receive keying material (rather than its actual design, where
the keying material is the sending keying material):
Scenario A: Non-Forking Case
In this scenario, the offer includes the receiving keying
material, the answerer receives it and starts sending data packets
towards the offerer. If there was a single crypto attribute in
the offer, there would be no ambiguity about which crypto suite
was being used and, hence, the incoming packet could be processed.
However, in the case where the offer included multiple alternative
crypto-attributes, the offerer would not know which one was
chosen, and hence, if the offerer received packets before the
answer came back, the offerer would be unable to process those
packets (problem 1). (Use of the MKI has been suggested as one
possible solution to that, however it incurs a per-packet
overhead.)
Scenario B: Serial Forking Case
In this scenario, Alice generates an offer to Bob, who starts
sending (early) media towards Alice (no answer returned yet). In
this scenario, we assume we aren’t also encountering Scenario A
(e.g., the offer includes only a single crypto-attribute) and that
Bob is using a Synchronization Source (SSRC) value of 1 for his
SRTP and SRTCP packets. Alice thus has a crypto-context for SSRC
1, including the associated ROC (Roll Over Counter) and SEQ (RTP
Sequence Number). Bob now forwards the call to Carol (Bob still
has not generated an answer). At this point, Bob has Alice’s key,
which sometimes might be a security weakness. As the exchange
proceeds, Carol gets the original offer, including the offered
crypto-attribute and starts sending media packets towards Alice.
It just so happens that Carol chooses an SSRC value of 1, as did
Bob. When Carol starts generating packets, there is a potential
for what RFC 3711 calls a "two-time pad" issue (problem 2), as
well as the potential for the ROC to be out of sync between Alice
and Carol (problem 3). Note that since Bob and Carol are
(presumably) using different source transport addresses, the SSRC
reuse does not constitute an SSRC collision (although it may still
be interpreted as such by Alice). Per RFC 3711, since the master
key would be shared between Bob and Carol in this case, it is
RECOMMENDED that Alice leave the session at that point in order to
avoid the two-time pad issue. It should also be noted that RFC
3711 recommends against sharing SRTP master keys, which forking
may accidentally introduce when the keying material is for the
receiving direction.
If we consider the above scenario again, but this time with keying
material in the offer (and answer) being the sending keying
material (as specified by SDP security descriptions), the scenario
instead looks as follows: Bob again chooses SSRC 1, and Bob will
need to send back an answer to Alice, since Alice needs to learn
Bob’s sending key. Bob also starts sending media towards Alice
(clipping may occur until Alice receives Bob’s answer). Bob again
forwards the call to Carol who also starts sending early media
using SSRC 1. However, Carol needs to generate a new answer (for
the dialog between Alice and Carol) in order for Alice to process
Carol’s packets . Upon receiving this answer, Alice can initiate a
new offer/answer exchange (to move the session to another
transport address as described in Section 7.3). In this case,
there is one master key per session and a unique keystream
regardless of whether or not SSRCs collide.
Scenario C: Parallel Forking Case
In this scenario, Alice generates an offer (with receive keying
material) that gets forked to Bob and Carol in parallel. Bob and
Carol both start sending packets (early media) to Alice. If Bob
and Carol choose different SSRCs, everything is fine initially.
However, one of the crypto context parameters is the master key
lifetime, and since Bob and Carol are sharing the same master key
(unbeknownst to either), they do not know when they need to rekey
(problem 4). If they choose the same SSRC, we have the two-time
pad problem again (problem 2).
In summary, if keying material were for the receive direction, we
would have the following problems:
- Problem 1: Offerer does not know which of multiple crypto offers
was chosen by answerer.
- Problem 2: SSRC reuse (or SSRC collisions) between multiple
answerers (serial or parallel forking) may lead to
the two-time pad issue.
- Problem 3: Part of the crypto context parameters (specifically