[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/