Internet DRAFT - draft-wing-mmusic-sdes-early-media
draft-wing-mmusic-sdes-early-media
MMUSIC R. Raymond
Internet-Draft CounterPath Solutions, Inc.
Expires: April 19, 2006 D. Wing
Cisco Systems
October 16, 2005
Security Descriptions Extension for Early Media
draft-wing-mmusic-sdes-early-media-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document extends security descriptions to allow early media to
be received and decrypted. This extension is useful when security
preconditionss isn't used.
Raymond & Wing Expires April 19, 2006 [Page 1]
Internet-Draft Security Descriptions Early Media October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Usage with MKI . . . . . . . . . . . . . . . . . . . . . . 4
4. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Offer and Accepted Answer . . . . . . . . . . . . . . . . 5
5.2. Answerer Doesn't Understand "req:" . . . . . . . . . . . . 5
5.3. Offer With Multiple Crypto Suites . . . . . . . . . . . . 6
5.4. Offer With Multiple Keys . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informational References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Raymond & Wing Expires April 19, 2006 [Page 2]
Internet-Draft Security Descriptions Early Media October 2005
1. Introduction
Security Descriptions [5] provides a mechanism to indicate SRTP keys
in SDP[3]. In Security Descriptions, the transmitter indicates the
key used to transmit their RTP or RTCP packets.
In the SDP offer/answer model [6], without security preconditions
[4], an answerer might begin transmitting SRTP media towards an
offerer before the offerer has received the answer containing the
SRTP keys necessary to decrypt the SRTP stream. This is called
'early media' [7].
This document provides an extension to security descriptions which
allows the offerer to decrypt this early media without requiring the
offerer or answerer to implement security preconditions.
2. Requirements Language
The key words "MUST", "MUST NOT" "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. Mechanism
A new security descriptions session parameter "req", indicates the
offerer is requesting that the answerer use a specific key and salt
for encrypting RTP and RTCP traffic the answerer transmits. An offer
MAY contain the session parameter "req".
If the answerer is willing to use this requested key parameter (key,
salt, MKI, lifetime) and SRTP session parameters (KDR, FEC_ORDER,
etc.) as indicated the offer, the answerer can establish its SRTP
crypto context using that infomation, begin sending SRTP packets
immediately, and generate an answer indicating it accepted these SRTP
key parameters and SRTP session parameters. An answer MUST NOT
contain the session parameter "req".
If the offerer receives SRTP packets before receiving the answer, the
offerer SHOULD assume the answerer supports the extension described
in this document and attempt to authenticate the incoming SRTP
packet. If the packet is authenticated the early media can be played
to the user. If the packet doesn't authenticate, the answer will
need to be received before the packet can be processed. This will be
the situation if the answerer doesn't support the extension described
in this document, the answerer rejected the offered key parameters or
session parameters. Typically, in a case where early media is
Raymond & Wing Expires April 19, 2006 [Page 3]
Internet-Draft Security Descriptions Early Media October 2005
received and can't be authenticated, the SRTP packet will simply be
discarded.
The technique described in this document is valuable if the answerer
sends early media and if the offerer and answerer both use SRTP
authentication.
3.1. Usage with MKI
Some implementations may find MKI to be useful when offering multiple
crypto-suites to identify which crypto-suite was chosen by the
answerer before the answer arrives. For example, an offer might
contain several a=crypto lines for one media line, and each a=cryto
line might offer a different crypto suite and a different MKI. When
the offerer receives an SRTP packet before receiving the answer, the
offerer can determine which a=crypto line was selected by the MKI
value of the arriving packets. To provide this functionality, the
answerer MUST use the same MKI value of the first key of the selected
a=crypto line in the offer; if no MKI is present in the offer, the
answerer MUST NOT use use an MKI for its early media. If the offer
contained MKI and the answerer chooses to generate its own key (that
is, it doesn't use the requested key), the answerer SHOULD use a
different MKI value than any of the a=crypto lines for that media
stream; by doing this the offerer avoids attempting to authenticate
early media until the answer arrives.
As MKI incurs some per-packet overhead it is often desirable, after a
successful offer/answer exchange, to send packets without MKI. To
accomplish this, another offer should be generated with the same
a=crypto parameters but without an MKI. When this new offer is
accepted, the offerer and answerer can send SRTP packets without MKI,
thus conserving bandwidth.
In order for early media to be decrypted, an offer MUST have the same
MKI length for all a=crypto lines of a media stream.
4. ABNF
Security Descriptions [5] is extended to allow the offerer to suggest
a key for the answerer to use. Following the ABNF [2] in Security
Descriptions, the following new session parameter is defined:
srtp-session-extension = "req:" key-salt
Raymond & Wing Expires April 19, 2006 [Page 4]
Internet-Draft Security Descriptions Early Media October 2005
5. Examples
In all of the examples below, long a=crypto lines are shown split
into separate lines with indentation due to formatting restrictions
of this document.
5.1. Offer and Accepted Answer
This is an offer with the extension described in this document.
v=0
...
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
req:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy
...
After receiving the above offer, the answerer may immediately begin
sending SRTP media using the key and salt indicated by "req:", and
lifetime and MKI indicated by "inline:".
This is the answer generated from the above offer, which shows the
acceptance of the "req" key and salt and the same lifetime and MKI
values.
v=0
...
m=video 42511 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|1:32
...
5.2. Answerer Doesn't Understand "req:"
Using the same offer as the previous example, the following answer
was generated by an answerer that doesn't support the extension
defined in this document, or by an answerer that rejected the key,
salt, or session parameters in the offer and wanted to set its own
negotiated parameters. Note the answerer's MKI value (231) is
different from the offerer's MKI value (1) because the answerer
didn't use the requested key. If the answerer had chosen the same
MKI value, the offerer might waste CPU cycles attempting to
autehnticate early media which won't authenticate.
Raymond & Wing Expires April 19, 2006 [Page 5]
Internet-Draft Security Descriptions Early Media October 2005
v=0
...
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:F0CxoxnxGNdapPn3BRKtYHaGWQUsBI1nqSLhUDzu|2^20|231:32
...
As can be seen, the answer uses a different key and MKI than the
original offer. Of course, if the answerer starts sending SRTP media
to the offerer before the offerer receives this answer, the offerer
won't be able to decrypt that SRTP media until the offerer receives
the answer.
5.3. Offer With Multiple Crypto Suites
This is an offer with the extension described in this document, with
multiple crypto suites each with its own MKI. The MKI is used to
identify the crypto-suite that the answerer selected when early media
is received.
v=0
...
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|101:32
req:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:FAGbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPl07Fc|2^20|102:32
req:4gZGUgYXBveW8gbXV0dW88QlI+PEEgaHJlZj0izE
...
The answerer would select one of the a=crypto lines, as described in
security descriptions. In this example, the answerer selected the
a=crypto line with the tag "1". So that the offerer can decrypt
early media, the answerer would also use the same MKI, 101, as in the
original offer for the a=crypto line it selected. Thus, the answerer
can begin immediately sending SRTP encrypted media and be confident
that the offerer can successfully authenticate and decrypt that
media. The answer would look like this:
v=0
...
m=video 42511 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|101:32
...
Raymond & Wing Expires April 19, 2006 [Page 6]
Internet-Draft Security Descriptions Early Media October 2005
5.4. Offer With Multiple Keys
This is an offer with the extension described in this document, with
multiple keys in the first a=crypto line and in the second a=crypto
line.
v=0
...
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|101:32;
inline:3MgVW5pZG9zLCBlcyB1biBwYXF1ZXRlIHF1ZSBzZ|2^20|102:32
req:s0GbsbrbKRhetTr3FV3xCLeKAUYwFM1ruWPlYHdy
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:WdyYWNp824geSBBc3VudG9zIFJlbGlnaW9zb3Mje|2^20|103:32;
inline:0ZXJpYSBtaWdyYXRvcmlhLCBwYXJhIGxvIGN1YWw|2^20|104:32
req:JJKbsbrbKRhetTr3FVOuCLeKAUYwFM1ruWPlY8jQ
...
In this example, the answerer selected the first a=crypto line (with
tag "1"). To allow the offerer to decrypt early media, the answerer
would also use the same MKI, 101, as the first key in the original
offer for the a=crypto line it selected. Thus, the answerer can
begin immediately sending SRTP encrypted media and be confident that
the offerer can successfully authenticate and decrypt that media. In
the example below, the answer shows the requested key (s0Gb...) was
selected with an MKI of 101, and additional keys with other MKIs are
also indicated in the answer. These other keys can overlap MKIs with
the offer.
v=0
...
m=video 42511 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:s0GbsbrbKRhetTr3FVOxCLeKAUYwFM1ruWPlYHdy|2^20|102:32;
inline:LFTCBVTklWRVJTQUw8QlI+PC9CPkVsIHN1YnNlY3|2^20|105:32;
inline:3MgbWlncmFudGVzIG1leGljYW5vcywgeWEgc2VhI|2^20|106:32
...
6. Security Considerations
The answerer may find it objectionable to trust the randomness of an
encryption key for its own traffic that is provided by a remote peer.
In such cases, the requested key described in this document would be
ignored and the answerer would generate its own key.
Raymond & Wing Expires April 19, 2006 [Page 7]
Internet-Draft Security Descriptions Early Media October 2005
7. IANA Considerations
This document does not add new IANA registrations.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] Andreasen, F. and D. Wing, "Security Preconditions for Session
Description Protocol Media Streams",
draft-ietf-mmusic-securityprecondition-00 (work in progress),
February 2005.
[5] Andreasen, F., Baugher, M., and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-11 (work in progress),
June 2005.
8.2. Informational References
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.
Raymond & Wing Expires April 19, 2006 [Page 8]
Internet-Draft Security Descriptions Early Media October 2005
Authors' Addresses
Rob Raymond
CounterPath Solutions, Inc.
8th Floor
100 West Pender Street
Vancouver, British Columbia V6B 1R8
Canada
Phone: +1.604.878.0440
Fax:
Email: rob@counterpath.com
URI:
Dan Wing
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Raymond & Wing Expires April 19, 2006 [Page 9]
Internet-Draft Security Descriptions Early Media October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Raymond & Wing Expires April 19, 2006 [Page 10]
