Internet Engineering Task Force                  Flemming Andreasen
   MMUSIC Working Group                                   Mark Baugher
   INTERNET-DRAFT                                             Dan Wing
   EXPIRES: December 2003 April 2004                                   Cisco Systems
                                                         June 27,
                                                      October 24, 2003

              SDP

           Session Description Protocol Security Descriptions
                           for Media Streams
               <draft-ietf-mmusic-sdescriptions-01.txt>
                <draft-ietf-mmusic-sdescriptions-02.txt>

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document defines a Session Description Protocol (SDP)
   cryptographic attribute for media streams.  The attribute describes
   a cryptographic key and other parameters, which serve to configure
   security for a media stream.  This stream in either a single message or a
   roundtrip.  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
   Real-time Transport Protocol (SRTP) parameters for the attribute. media streams.  The SDP crypto
   attribute requires the services of a data security protocol to
   secure the SDP message.

   TABLE OF CONTENTS

Table of Contents

1. Notational Conventions............................................2 Conventions............................................3
2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters.............................4
 3.1 Crypto-suite....................................................4 Crypto-suite....................................................5
 3.2 Key Parameter...................................................4
 3.4 Parameters..................................................5
 3.3 Session Parameters..............................................5
 3.5 Examples........................................................5 Parameters..............................................6
 3.4 Example.........................................................6
4. RTP/SAVP (SRTP) Security Descriptions.............................6 General Use of the crypto Attribute...............................6
 4.1 Crypto-suites...................................................7 Use With Offer/Answer...........................................7
   4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7  Generating the Initial Offer..............................7
   4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7  Generating the Initial Answer.............................8
   4.1.3 F8_128_HMAC_SHA1_80.........................................7  Offerer Processing of the Initial Answer..................9
   4.1.4 Adding new CRYPTO-SUITE definitions.........................8  Modifying the Session....................................10
 4.2 Key-param Parameter.............................................8
   4.2.1 Key Usage...................................................8
   4.2.2 INLINE Definition...........................................8 Use Outside Offer/Answer: Advertising..........................10
 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions.......................................11
 5.2 Crypto-suites..................................................14
   5.2.1  AES_CM_128_HMAC_SHA1_80..................................14
   5.2.2  AES_CM_128_HMAC_SHA1_32..................................14
   5.2.3  F8_128_HMAC_SHA1_80......................................15
   5.2.4  Adding new Crypto-suite Definitions......................15
 5.3 Session Parameters.............................................10
   4.3.1 SRC=/SSRC/ROC/SEQ..........................................10
   4.3.2 KEY_DERIVATION_RATE=n......................................11
   4.3.3 Parameters.............................................15
   5.3.1  SRC=SSRC/ROC/SEQ.........................................15
   5.3.2  KDR=n....................................................18
   5.3.3  UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................11
   4.3.4 FEC_ORDER=order............................................11
   4.3.5 UNAUTHENTICATED_SRTP.......................................12
5. UNENCRYPTED_SRTP...................18
   5.3.4  UNAUTHENTICATED_SRTP.....................................19
   5.3.5  FEC_ORDER=order..........................................19
   5.3.6  Window Size Hint (WSH)...................................19
   5.3.7  SRTP Extension Session Parameters........................19
6. SRTP-Specific Use of the crypto Attribute........................20
 6.1 Use with Offer/Answer............................................12
 5.1 Offer/Answer..........................................20
   6.1.1  Generating the Offer...........................................12
 5.2 Answerer Processing............................................12
 5.4 Non-RTP/SAVP Answerers.........................................14
 5.4 Initial Offer.............................20
   6.1.2  Generating the Initial Answer............................21
   6.1.3  Offerer Processing of the Initial Answer.................22
   6.1.4  Modifying the Session....................................23
   6.1.5  Offer/Answer Example: Receiver Supports SRTP...................14
 5.7 Example.....................................24
 6.2 SRTP-Specific Use of a=crypto With Active Media Streams......................15
 5.8 Outside Offer/Answer: Advertising............25
 6.3 SRTP-Specific Backwards Compatibility Considerations...........25
 6.4 Operation with KEYMGT KEYMGT= and Key lines............................15
6. k= lines............................26
 6.5 Removal of Crypto Contexts.....................................26
7. Security Considerations..........................................15
 6.1 Considerations..........................................26
 7.1 Authentication of packets......................................16
 6.1 Key-stream Reuse...............................................16
 6.2 packets......................................27
 7.2 Keystream Reuse................................................27
 7.3 Signaling Authentication and Signaling Encryption..............17
7. Encryption..............27
8. Grammar..........................................................29
 8.1 Generic "Crypto" Attribute Grammar.............................29
 8.2 SRTP "Crypto" Attribute Grammar..................................18
8. Open Issues......................................................19 Grammar................................29
9. Acknowledgements.................................................19 Open Issues......................................................30
10. Authors' Addresses..............................................19 IANA Considerations.............................................31
 10.1 Registration of the "crypto" attribute........................31
 10.2 New IANA Registries and Registration Procedures...............31
   10.2.1 Security Descriptions Key Method Registry and Registration31
   10.2.2 SRTP Crypto Suite Registry and Registration..............31
   10.2.3 SRTP Session Parameter Registration......................32
 10.3 Initial Registrations.........................................32

11. Acknowledgements................................................32
12. Authors' Addresses..............................................33
13. Normative References............................................20 References............................................33
14. Informative References..........................................34
Intellectual Property Statement.....................................21
Acknowledgement.....................................................22 Statement.....................................35
Acknowledgement.....................................................36

1. Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "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].

Andreasen, Baugher & Wing                                     [Page 2] [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 abbreviation "iff" means "if and only if."

2. Introduction

   The Session Description Protocol (SDP) describes multimedia
   sessions, which can be audio, video, whiteboard, fax, modem modem, and
   other media sessions.  Security services such as data origin
   authentication, integrity and confidentiality are often needed for
   these
   media streams.  The Secure Real-time Transport Protocol (SRTP)
   can be used to provide
   [srtp] provides such security services, services and use of it can be is signaled by use of the
   "RTP/SAVP" transport in an SDP media (m=) line.  However, there are
   no means within SDP itself to configure SRTP beyond using defaults default
   values.  This document specifies a new SDP attribute called
   "crypto", which is used to signal and negotiate cryptographic
   parameters for SRTP. media streams in general, and SRTP in particular.

   The crypto attribute might be extended is defined in a generic way to non-SRTP transports such
   as whiteboard, modem, fax, and other enable its use
   with secure transports besides SRTP that could use
   various security protocols such as need to signal and
   negotiate cryptographic parameters, e.g. IPsec [ipsec], S/MIME
   [s/mime], or TLS.  These extensions,
   however, are beyond the scope of this document.  Each type of SDP
   media stream TLS [tls], if and only if such parameters can either be
   advertised in a single message, or negotiated in a single round-trip
   by use of the offer/answer model [RFC3264].  Such extensions,
   however, are beyond the scope of this document.  Each type of secure
   SDP media transport needs its own definitions that assign values to its
   crypto-attribute parameters. specification for the crypto-
   attribute parameter.  These definitions are frequently unique to the
   particular SDP type of transport and SHOULD MUST be specified in an Internet RFC.
   RFC and registered with IANA according to the procedures defined in
   Section 10.  This document defines the parameter values security parameters and
   keying material for SRTP. SRTP only.

   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
   protocol such as MIKEY, GDOI, KINK, MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE [ike]
   or TLS [tls] securely disseminates information describing both the
   key and the data-security session (for example, whether SRTCP
   payloads are encrypted or unencrypted in an SRTP 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 session-related information.

   SDP, however, was not designed to provide AKE services, and the
   media security descriptions that follow 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 secure multiparts)
   protects the SDP message. This draft document adds security descriptions
   to those encrypted and/or authenticated SDP messages through the
   "crypto" attribute, which

Andreasen, Baugher & Wing                                     [Page 3] provides the cryptographic parameters of a
   media stream. The "
   crypto" "crypto" attribute could can be adapted to any media
   transport, but its precise definition is frequently unique to a
   particular transport.  In Section 3, we introduce the general SDP
   crypto attribute, and in Section 4, 4 we define how it is used with and
   without the offer/answer model. In Section 5, we define the crypto
   attribute details needed for SRTP.  In SRTP, and in Section 5, 6 we specify
   how to define SRTP-
   specific use of the crypto attribute for SRTP streams with and without the
   Offer/Answer model [RFC3264]. offer/answer
   model.  Section 6 7 recites security considerations, and Section 7 8
   gives an Augmented-BNF grammar for the
   SRTP security descriptions provided for general crypto attribute as
   well as the SRTP-specific use of the crypto attribute.  A list of
   open issues is provided in Section 8. 9 and IANA considerations are
   provided in Section 10.

3. SDP "Crypto" Attribute and Parameters

   A new media-level SDP attribute called "crypto" describes the
   cryptographic suite, key parameters, and session parameters for the
   proceeding
   preceding 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 SP key-param *(SP session-param)

   where "SP" is
   follows the space character format (see [RFC2234]); the Section 8.1 for a formal ABNF grammar):

     a=crypto:<crypto-suite> <key-params> *<session-params>

   The fields crypto-suite, key-param, key-params, and session-param are described
   in Section
   3.1, 3.2, and 3.3.

   The ordering the following sub-sections.  Below we show an example of multiple "a=crypto" lines is significant:  The most-
   preferred the
   crypto line is listed first; see section 5 attribute for details. We
   now describe the crypto fields in more detail. "RTP/SAVP" transport, i.e. SRTP (newlines
   included for formatting reasons only):

     a=crypto:AES_CM_128_HMAC_SHA1_80
      inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
      SRC=/721/13

   The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined
   by the line starting with "inline:", and there is a single session-
   param named "SRC".

3.1 Crypto-suite

   The crypto-suite field is an identifier (see Section 8.1 for
   details) that describes all needed information about the encryption and authentication algorithms
   (e.g. AES_CM_128_HMAC_SHA1_80) for the RTP/SAVP transport. transport in question.  The ABNF grammar
   possible values for the crypto-suite is:

     crypto-suite = VCHAR

   where VCHAR is parameter are defined in [RFC2234]. The possible values within
   the context of the transport, i.e. each transport defines a separate
   namespace for the
   crypto-suite parameter is unique set of crypto-suites.  For example, the crypto-
   suite "AES_CM_128_HMAC_SHA1_80" defined within the context of the
   "RTP/SAVP" transport applies to Secure RTP only; the transport. string may be
   reused for another transport, however a separate definition would be
   needed.

3.2 Key Parameter Parameters

   The key-param key-params field  MUST either contain an inline key descriptor, provides one or it MUST be more sets of keying material
   for the crypto-suite in question.  The field consists of a pointer to method
   indicator followed by a uri which contains colon, and the actual key. The
   ABNF keying information as
   shown below (a formal grammar for key-param is:

     key-param           = inline-key / uri-key
     inline-key          = "inline:" key-descriptor
     key-descriptor      = VCHAR
     uri-key             = "uri:" absolute-uri
     absolute-uri is provided in Section 8.1):

     key-params = VCHAR

Andreasen, Baugher & Wing                                     [Page 4] 
   where VCHAR <key-method> ":" <key-info>

   Keying material may be provided by different means. One method is
   defined in [RFC2234].

   If the key parameter starts with the string "uri:", this document, namely "inline", which indicates that the URI method
   keying material is used and provided in the value that follows MUST be key-info field itself.  There is
   a Uniform Resource
   Identifier. The URI single name space for the key-method, i.e. the key-method is
   transport independent.  New key-methods (e.g. use of a resource that SHOULD URL) may be queried to obtain
   the cryptographic key for
   defined in an IETF RFC in the session.  The format or protocols future, in which case they may be used
   for the uri are beyond
   with any transport, provided the scope of this document, however it is
   RECOMMENDED definitions for that such protocols provide both integrity and
   confidentiality.

   The INLINE method is invoked when transport
   support use of the new key-method.  New key parameter starts methods MUST be
   registered with the
   string "inline:"; the cryptographic key is encoded IANA according to a
   transport-specific syntax subject to the general format provided
   above.  Thus, the URI method procedures defined in
   Section 10.2.1.

   Key-info is transport generic and the INLINE
   method is transport specific. here just defined as a general character string (see
   Section 4 describes the INLINE key-
   parameter 8.1 for details); further transport and key-method specific
   syntax and semantics MUST be provided in an IETF RFC for each
   combination of transport and key-method that wants to use it;
   definitions for RTP/SAVP (the SRTP media are provided in Section 5.  Note that such
   definitions are provided within the context of both a particular
   transport type).

3.4 (e.g. "RTP/SAVP") and a specific key-method (e.g.
   "inline").

   When multiple keys are included in the key parameters, it MUST be
   possible to determine which key is being used by a simple inspection
   of the media packet received; a trial-and-error approach between the
   possible keys MUST NOT be required.

    For SRTP, this could for example be achieved by use of Master Key
    Identifiers (MKI), or <"From", "To"> values.

3.3 Session Parameters

   The session

   Session parameters are specific to the SDP media stream a given transport and are OPTIONAL. The ABNF grammar for session-param is:

     session-param  = VCHAR

   where VCHAR use of them
   is defined OPTIONAL in [RFC2234]. Section 4 describes the general framework, where they are just defined as
   a general character string.  If session parameters are to be used
   for a given transport, then key-method and transport-specific syntax
   and semantics MUST be provided in an IETF RFC for each transport
   that wants to use it; definitions for RTP/SAVP.

3.5 SRTP are provided in Section
   5.  Note that such definitions are provided within the context of
   both a specific key-method (e.g. "inline") and a particular
   transport (e.g. "RTP/SAVP").

3.4 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
     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:AES_CM_128_HMAC_SHA1_80
      inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32
      inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_32
      inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32
      inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
     m=application 32416 udp wb
     a=orient:portrait

Andreasen, Baugher & Wing                                     [Page 5]

   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 RTP/SAVP-specific descriptions are defined in the
   next section.
   Section 5.

4. RTP/SAVP (SRTP) Security Descriptions

   SRTP security descriptions for a media stream MUST only be used for
   media streams that General Use of the crypto Attribute
   In this section, we describe the general use of the RTP/SAVP crypto attribute
   outside of any transport in the media (m=) line
   and SHALL apply or key-method specific rules.

4.1 Use With Offer/Answer

   In this section, we define the general rules for use of the crypto
   attribute with the offer/answer [RFC3264] model.  These rules are in
   addition to that the rules specified in RFC 3264, which MUST be followed,
   unless otherwise noted.

4.1.1 Generating the Initial Offer

4.1.1.1   Unicast Streams

   When generating an initial offer for a unicast stream, there MUST be
   one or more crypto attributes present for each media stream only.

   There is no assurance that an endpoint for
   which security is capable desired.  The ordering of configuring its
   SRTP service with a particular multiple "a=crypto"
   lines is significant:  The most-preferred crypto line is listed
   first.  Each crypto attribute parameter, but SRTP
   guarantees minimal interoperability among SRTP endpoints through describes the
   default SRTP crypto-suite, key(s) and
   possibly session parameters [srtp].  More capable SRTP endpoints support
   a variety of parameter values beyond offered for the SRTP defaults and these
   values can media stream.  In
   general, a "more preferred" crypto suite SHOULD be configured by the stronger
   cryptographically than a "less preferred" crypto attribute defined suite.

   The crypto-suite always applies to media in this
   document.  An endpoint that does not support all directions supported
   by the crypto attribute
   will ignore it (per [SDPnew]) media stream (e.g. send and hence, if it supports SRTP, it
   will simply assume use of default SRTP parameters.  Such an endpoint
   will not correctly process the particular receive).

   The key(s) apply to media stream.  By using in the Offer/Answer model, direction from 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
   answerer; if the media stream is marked as "recvonly", a key MUST
   still be provided.

     This is done for consistency.  Also, in the SRTP
   specification.  Many case of these parameters have fixed values for
   particular cryptographic transforms.  At example
     SRTP, secure RTCP will still be flowing in both the time of session
   establishment, however, there is usually send and
     receive direction for a unidirectional stream.

   There are no need to provide unique
   settings general offer/answer rules for many of the SRTP parameters, such session parameters;
   instead, specific rules are provided as salt length and
   pseudo-random function (PRF).  Thus, it is possible to simplify the
   list of parameters by defining "cryptographic suites" that fix a set part of SRTP parameter values for the security session.

     SRTP Crypto Parameter    Description
     ---------------------    -----------
     CRYPTO-SUITE             Encryption and authentication transforms
     INLINE                   SRTP transport and associated parameters
     SRC                      An <SSRC, ROC, SEQ> triple
     KEY_DERIVATION_RATE      Rate that
   key-method specific definitions of any session parameters.

   When issuing an offer, the pseudo-random function
                                is applied offerer MUST be prepared to a master key
     UNENCRYPTED_SRTP         SRTP messages are not encrypted
     UNENCRYPTED_SRTCP        SRTCP messages are not encrypted
     UNAUTHENTICATED_SRTP     SRTP messages are not authenticated
     FEC_ORDER                Order support media
   security in accordance with any of forward error correction (FEC)
                                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 crypto attributes included in
   the offer.  There are however two problems associated with this.
   First of
   parameters and their descriptions [Section 8.2, srtp].  The CRYPTO-
   SUITE, all, the offerer does not know which key parameter, and the session parameters shown in answerer will
   be using for media sent to the
   table above are described in offerer; the following sections. If a receiver
   cannot recognize a parameter answerer may or value, then may not
   choose the receiver MUST NOT
   participate same key as the offerer chose in his sending direction
   (in fact, the media stream and answerer SHOULD log an "invalid name"
   condition unless NOT use the receiver is participating same key as explained in an Offer/Answer
   exchange (Section 5).

4.1 Crypto-suites

   A crypto-suite value appears as
   Section 4.1.2.1).  Since media may arrive prior to the first parameter in a crypto
   attribute. answer, delay
   or clipping may occur.  If this is unacceptable to the offerer, the
   offerer SHOULD use a receiver does mechanism outside the scope of this document to
   prevent the above problem.

     For example, a "security" precondition [RFC3312] could be defined
     to solve the above problem.

   Another problem can occur when the offerer includes multiple crypto
   attributes, since the offerer may not support be able to deduce which of the particular crypto-
   suite, then
   offered crypto attributes was accepted by the receiver MUST NOT participate in answerer until the
   answer is received, yet media stream
   and SHOULD log an "unrecognized crypto-suite" condition unless may arrive before the
   receiver answer.

   If this is participating unacceptable to the offerer, the offerer either SHOULD
   NOT include multiple crypto attributes in an Offer/Answer exchange (Section 5).
   RTP/SAVP has three crypto-suites as described below.

4.1.1 AES_CM_128_HMAC_SHA1_80

   This is the SRTP default AES Counter Mode cipher and HMAC-SHA1
   message authentication having an 80-bit authentication tag.  The
   master-key length is 128 bits and has offer, or a lifetime mechanism
   outside the scope of this document SHOULD be used to prevent the
   above problem (e.g. 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. "security" precondition).

4.1.1.2   Multicast Streams

   The SRTP and SRTCP authentication key lengths rules for multicast streams are 160 bits (see
   Security Considerations).  The master salt value is 112 bits and similar to those for unicast
   streams, except as noted below:

   * In order to ensure that all participants use the
   session salt value is 112 bits. same crypto
     parameters, there MUST be exactly one crypto attribute per media
     stream.

   * The PRF is key(s) provided apply to media in all directions supported by
     the default SRTP pseudo-
   random function that uses AES Counter Mode with a 128-bit key
   length. media stream, as opposed to just the sending direction.

4.1.2 AES_CM_128_HMAC_SHA1_32

   The SRTP AES Counter Mode cipher is used Generating the Initial Answer

4.1.2.1   Unicast Streams

   When the answerer receives the initial offer with HMAC-SHA1 message
   authentication having a 32-bit authentication tag one or more crypto
   attributes for SRTP packets;
   SRTCP uses an 80-bit tag.  The master-key length is 128 bits and has
   a lifetime of a maximum given unicast media stream, the answerer MUST
   either accept exactly one of 2^48 SRTP packets the offered crypto attributes, or 2^31 SRTCP packets,
   whichever comes first [srtp].  The SRTP and SRTCP encryption key
   lengths 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 128 bits.  The SRTP valid, i.e. do not violate any of
   general rules defined for security descriptions as well as any
   specific rules defined for the transport and SRTCP authentication key lengths
   are 160 bits (see Security Considerations).  The master salt value
   is 112 bits and method in question
   can be accepted.  When selecting one of the session salt value is 112 bits.  The PRF is valid crypto attributes,
   the
   default SRTP pseudo-random function that uses AES Counter Mode with
   a 128-bit key length.

4.1.3 F8_128_HMAC_SHA1_80

   The SRTP f8 cipher is used with HMAC-SHA1 message authentication
   having a 80-bit authentication tag.  The master-key length is 128
   bits answerer SHOULD select the most preferred crypto attribute it
   can support, i.e. the first valid supported crypto attribute in the
   list, considering the answerer's capabilities and has a lifetime security policies.

   If there is one or more crypto attributes in the offer, but none of a maximum
   them are valid, or none 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

Andreasen, Baugher & Wing                                     [Page 7] 
   authentication key lengths the valid ones are 160 bits (see Security
   Considerations).  The master salt value is 112 bits and supported, the session
   salt value is 112 bits. offered
   media stream MUST be rejected.

   The PRF is crypto attribute in 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
   transforms SHOULD be given for answer MUST contain the SDP following:

   * The crypto-suite from the accepted crypto attribute and
   published in an Internet RFC. Sections 4.1.1 through 4.1.3
   illustrate how to define CRYPTO-SUITE values for particular
   cryptographic transforms.  New definitions MAY the offer
     (the same crypto-suite must be added to existing
   transforms, moreover, to augment or modify definitions 4.1.1 through
   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 in the send and receive
     direction).
   * The key(s) the answerer will be defined
   having a new name that is identical using for media sent to AES_CM_128_HMAC_SHA1_80 but
   with the size
     offerer.

   There are no general offer/answer rules for the session parameters;
   instead, specific rules are provided as part of the master key defined to be 160 bits instead transport and
   key-method specific definitions of
   128 bits.

4.2 Key-param Parameter

   If any session parameters.

   Once the key-param parameter answerer has a "uri:" descriptor, accepted one of the value is a
   Uniform Resource Identifier value as described offered crypto attributes,
   the answerer MAY begin sending media to the offerer in Section 3.  When accordance
   with the key-param parameter has an "inline:" descriptor, selected crypto attribute.  Note however, that the value
   contains a cryptographic master key that MUST offerer
   may not be a unique
   cryptographically random [RFC1750] value with respect able to other
   "inline:" values in process such media packets correctly until the SDP message.

4.2.1 Key Usage
   answer has been received.

4.1.2.2   Multicast Streams

   The "inline" type of key contains the keying material and all policy
   relating rules for multicast streams are similar to that key, including how it can those for unicast
   streams, except as noted below:

   * The crypto-suite in the answer MUST be used (for encryption,
   decryption, or both encryption and decryption), how long it the same as the one in the
     offer (unless the offered media stream is rejected).  Since no
     more than one crypto attribute can be
   used (lifetime) and whether or not it uses offered for a master key index
   (master key index or MKI) multicast
     stream, this is satisfied trivially.

   * The key(s) provided apply to associate an incoming SRTP packet with
   a master key.  Compliant implementations obey media in all directions supported by
     the policies
   associated with a master key, and MUST NOT accept incoming packets
   that violate media stream, as opposed to just the policy (e.g. after sending direction.
     Consequently, the key lifetime has expired,
   for example).

4.2.2 INLINE Definition

   If key(s) in the identifier is "inline", answer MUST be the key-param descriptor has same as the
   format described
     key(s) in Section 7 (Grammar) and contains the following
   fields:

     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)

Andreasen, Baugher & Wing                                     [Page 8] 
     MKI:length     MKI and length offer.

4.1.3 Offerer Processing of the MKI field in SRTP packets.

   The "use" indicator defines usage as one of three values which are
   all provided from Initial Answer

4.1.3.1   Unicast Streams

   When the perspective of offerer receives the recipient answer, the offerer MUST verify, that
   exactly one of the SDP: "d"
   means offered crypto attributes was accepted.
   Otherwise, the key is used for decryption only, "e" means offerer MUST consider the key is used offer/answer negotiation to
   have failed for encryption only, and "b" means that stream.

   The key(s) included in the key is answer are the key(s) that will be used
   for both
   encryption and decryption.  If media sent from the crypto suite uses answerer to the same key
   for both encryption offerer and decryption, "b" hence the
   offerer MUST be specified.

   The "key_length" is use those key(s) to process media received; the integer length of key(s)
   might not be the SRTP master key in
   bytes, and "salt_length" is same as the integer length of key(s) used by the master salt in
   bytes.  Their sum MUST be exactly equal offerer for sending
   media to the length of answerer.

   There are no general offer/answer rules for the
   concatenated master key and salt session parameters;
   instead, specific rules are provided in the fourth field.  The
   key_length and salt_length MUST appear in the "inline" encoding. For
   example,

    inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:4

   is a decryption key with a key length as part of 16 the transport and a salt length of 14.

   The fourth part
   key-method specific definitions of any session parameters.

4.1.3.2   Multicast Streams

   When the "inline" encoding is offerer receives the cryptographic master
   key appended with answer, the master salt.  Each master key and salt offerer MUST be
   a cryptographically random number verify, that
   the offered crypto attribute and key(s) were accepted and echoed in
   the answer.  Otherwise, the offerer MUST be unique to consider the SDP
   message.  Both are concatenated offer/answer
   negotiation to have failed for that stream for *that answerer* and then base-64 encoded.
   hence the answerer is not considered a participant in that media
   stream.  If there are other participants in the
   length of multimedia session,
   the concatenated key and salt (after being decoded from
   base 64) does not equal session may continue unaffected by this particular answerer's
   failure.

   There are no general offer/answer rules for the sum session parameters;
   instead, specific rules are provided as part of the key_length transport and salt_length
   indicated, the receiver MUST NOT use this crypto attribute line for
   key-method specific definitions of any session parameters.

4.1.4 Modifying the Session

   Once a media stream and SHOULD log a "inline encoding too short"
   condition.  For example,

     inline:d/16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:4

   describes a decryption key with a key_length of 16, a salt_length of
   8, and has been established, it MAY be modified at any
   time, as described in RFC 3264, Section 8.  Such a 32-character key and concatenated salt that is base-64
   encoded: The 24-character key/salt concatenation is expanded to 32
   characters modification MAY
   be triggered by the three-in-four encoding of base 64.

   The fifth part of security service, e.g. in order to perform a re-
   keying or change the of crypto-suite.  If media stream security using
   the "inline" encoding general security descriptions defined is still desired, the OPTIONAL
   lifetime of the master key as measured
   crypto attribute MUST be included in number of packets using
   that key. these new offer/answer
   exchanges.  The lifetime value MAY be written as an non-zero,
   positive integer or as a power of 2, see procedures are similar to those defined in Section
   4.1.1, 4.1.2, 4.1.3 subject to the ABNF considerations provided in RFC
   3264 Section 7 for
   details. 8.

4.2  Use Outside Offer/Answer: Advertising

   The "lifetime" value MUST NOT exceed crypto attribute can also be used outside the maximum packet
   lifetime for context of
   offer/answer.  For example, when using the crypto-suite.  If lifetime Session Announcement
   Protocol (SAP) [RFC2974], there is too large or
   otherwise invalid, then no negotiation of the receiver MUST NOT use this media
   streams described by the SDP; instead media streams are simply
   advertised.

   The crypto attribute line for defined here can be used in such environments
   where the media stream crypto parameters are advertised in a single message
   rather than being negotiated in a roundtrip (an offer and SHOULD log an "invalid
   lifetime" condition.  The default MAY
   answer), albeit with certain restrictions:

   * There MUST be implicitly signaled by
   having exactly one crypto attribute.

   There are no described value general rules 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 session parameters; instead,
   specific rules for advertising session parameters are provided as 2^20 while the second example shows an empty lifetime,

Andreasen, Baugher & Wing                                     [Page 9] 
   which means the SRTP default value
   part 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 transport and key-method specific definitions of any
   session parameters.

4.3  General Backwards Compatibility Considerations
   It is possible that the MKI MUST also be answerer supports a given secure transport
   and
   separated from the MKI by a colon (":").  The MKI_length is the size
   of the MKI field in accepts the SRTP packet, specified in bytes.  If offered media stream, yet the
   MKI_length is answerer does not given or if the value exceeds 128, then
   support the
   receiver MUST NOT use this crypto attribute line for the defined here.  The offerer can
   recognize this situation by seeing an accepted media stream and SHOULD log an "invalid MKI_length" condition.  If the
   value of in the MKI is larger than allowed by MKI_length, then
   answer that does not include a crypto line.  In that case, the
   receiver
   security negotiation defined here MUST NOT use be deemed to have failed.

5. SRTP Security Descriptions

   In this crypto attribute line section, we provide definitions for the security descriptions
   for SRTP media
   stream and SHOULD log an "invalid MKI" condition.  The substring
   "1:4" in streams.  In the first example assigns next Section, we define how to the key a master key index of
   1 that is 4 bytes long, use
   SRTP security descriptions with and without the second example assigns offer/answer model.

   SRTP security descriptions for a 4-byte key
   index of 1066 to media stream MUST only be used for
   media streams that use the key.

4.3 Session Parameters

   The "session" parameters are OPTIONAL "RTP/SAVP" transport in the media (m=)
   line and serve SHALL apply to override that media stream only.

   There is no assurance that an endpoint is capable of configuring its
   SRTP
   session defaults for the service with a particular crypto attribute parameter, but SRTP and SRTCP streams.  These parameters
   configure an RTP session for
   guarantees minimal interoperability among SRTP services.

4.3.1 SRC=SSRC/ROC/SEQ

   The SRC session parameter provides information to establish endpoints through the
   default SRTP
   cryptographic context.  The ROC and sequence number are typically
   only needed for sessions already in progress (as when rekeying or
   when joining a multicast session).

   Zero or more SRC parameters MAY appear in a crypto attribute.  Each
   SRC parameter defines a separate [srtp].  More capable SRTP crypto context (see section
   3.2 endpoints support
   a variety of [srtp]) that SHALL share parameter values beyond the master key SRTP defaults and salt defined by
   an INLINE parameter.  The total number of all packets that are
   encrypted these
   values can be configured by keys derived from this master key MUST NOT exceed the
   lifetime of the INLINE key.  The SRTP crypto contexts so security descriptions defined
   SHALL also have a common definition for
   here.  An endpoint that does not support the crypto-suite and all
   other crypto attribute will
   ignore it (per [SDPnew]) and hence, if it supports SRTP, it will
   simply assume use of default SRTP parameters.

   SSRC is OPTIONAL provided that either a ROC or a SEQ appear in the
   SRC parameter.  SSRC is  Such an integer in endpoint will
   not correctly process the range of 0..2^32-1 for particular media stream.  By using the
   RTP SSRC parameter, which is undefined by default.  This is
   Offer/Answer model, the RTP
   SSRC that is associated with offerer and answerer can negotiate the inline key. If
   crypto parameters to be used before commencement of the SSRC value is
   invalid, multimedia
   session (see Section 6.1).

   There are over twenty cryptographic parameters listed in the receiver MUST NOT use this crypto attribute line SRTP
   specification.  Many of these parameters have fixed values for
   particular cryptographic transforms.  At the media stream but SHOULD log an "invalid SSRC" condition.  If
   SSRC is specified and an SRTP packet time of session
   establishment, moreover, there is received with a different
   SSRC value, the receiver SHOULD discard usually no need to provide unique
   settings for many of the packet SRTP parameters, such as salt length and log an error.

   ROC
   pseudo-random function (PRF).  Thus, it is OPTIONAL provided possible to simplify the
   list of parameters by defining "cryptographic suites" that either an SSRC or fix a SEQ appear in the
   SRC parameter.  ROC is an integer in the range set
   of 0..2^32-1 SRTP parameter values for the

Andreasen, Baugher & Wing                                    [Page 10] 
   SRTP rollover counter (ROC), which security session.  This approach is zero
   followed by default.  The ROC MAY
   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 security descriptions, which uses the nature of general
   security description parameters as follows:

     * crypto-suite:     Identifies the encryption and authentication
                         transforms
     * key parameter:    SRTP keying material and parameters
     * 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 parameters:    The following parameters are defined:
          - SRC:    An <SSRC, ROC, SEQ> triple
          - KDR:    The SRTP description. If ROC Key Derivation Rate 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.

   SEQ is OPTIONAL provided rate that either an SSRC or a ROC appear in the
   SRC parameter.  SEQ
                    pseudo-random function 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) applied  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 master key
          - UNENCRYPTED_SRTP:      SRTP messages 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 encrypted
          - UNENCRYPTED_SRTCP:     SRTCP messages are not encrypted
          - UNAUTHENTICATED_SRTP:  SRTP messages are not authenticated
          - FEC_ORDER:   Order of forward error correction (FEC)
                         relative to SRTP services
          - WSH:         Window Size Hint
          - Extensions:  Extension parameters can be incremented.  See also section 3.3.1 of [srtp].  If SEQ
   is greater than 2^16-1, then defined

   Please refer to the receiver MUST NOT use this crypto
   attribute line SRTP specification for a complete list of
   parameters and their descriptions [Section 8.2, srtp].  The key
   parameter, the media stream but SHOULD log an "invalid SEQ"
   condition.

4.3.2 KDR=n

   KDR specifies crypto-suite, and the session parameters shown above
   are described in detail in the following sections.

5.1.1.1   SRTP Key Derivation Rate, Parameter

   SRTP security descriptions define use of the "inline" key method as
   described in section 4.3.1 the following. Use of [srtp]. any other keying method for SRTP
   security descriptions is for further study.

   The value n MUST be an integer in the set {0,1,2,...,24}, which
   denotes a power "inline" type of 2 from 2^0 to 2^24, inclusive.  The SRTP key
   derivation rate controls contains the keying material and all policy
   relating to that key, including how frequently long it can be used (lifetime)
   and whether or not it uses a new session master key is derived
   from identifier (MKI) to
   associate an incoming SRTP packet with a particular master key.
   Compliant implementations obey the policies associated with a master
   key, and MUST NOT accept incoming packets that violate the policy
   (e.g. after the key [SRTP]. lifetime has expired).

   The default value is 0, key parameter contains a semi-colon separated list of
   cryptographic master keys, each of which
   causes MUST be a unique
   cryptographically random [RFC1750] value with respect to other
   master keys in the entire SDP message (i.e. including master keys
   for other streams).  Each key derivation function to be invoked exactly once (since
   2^0 in the list follows the format (a
   formal definition is 1).

4.3.3 UNENCRYPTED_SRTCP provided in Section 8.2):

     "inline:" <key salt> "|" [<lifetime] "|" [MKI:length / FromTo]

     key||salt      concatenated key and UNENCRYPTED_SRTP

   UNENCRYPTED_SRTCP indicates that the SRTCP packet payloads are not
   encrypted.  UNENCRYPTED_SRTP indicates that salt, base64 encoded
     lifetime       key lifetime (number of packets)
     MKI:length     MKI and length of the MKI field in SRTP packet payloads
   are not encrypted.  SRTP and SRTCP packet payloads are encrypted by
   default.

4.3.4 FEC_ORDER=order packets.
     FromTo         <"From", "To"> values, specifying the lifetime for
                    a master key.

   The forward error correction values following definition provides an example for "order" are FEC_SRTP,
   SRTP_FEC, or SPLIT [mikey].  FEC_SRTP signals that FEC
   AES_CM_128_HMAC_SHA1_80:

     inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4

   The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the
   parameter is applied
   before SRTP processing on the sender and after SRTP processing on
   the receiver; FEC_SRTP is cryptographic master key appended with the default. SRTP_FEC is master
   salt; the reverse
   processing.  SPLIT signals that SRTP encryption occurs on two are first concatenated and then base64 encoded.  The
   length of the

Andreasen, Baugher & Wing                                    [Page 11] 
   sender, followed by FEC processing, followed by SRTP authentication;
   processing concatenated key and salt is reversed on determined by the receiver. crypto-
   suite for which the key applies.  If the receiver cannot
   recognize length (after being decoded
   from base64) does not match that specified for the order value, then crypto-suite, the receiver MUST NOT use this
   entire crypto attribute line for the media stream but SHOULD log MUST be considered invalid and an "invalid FEC_ORDER" condition.

4.3.5 UNAUTHENTICATED_SRTP

   This parameter signals that SRTP messages are not authenticated.
   SRTP authenticates SRTP messages by default.  Use of
   UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security
   Considerations).

5. Use with Offer/Answer

   The Offer/Answer model [RFC 3264] enables parties that wish to
   engage in
   key/salt" condition SHOULD be logged.  Each master key and salt MUST
   be a multimedia session cryptographically random number and MUST be unique to negotiate the media stream
   parameters SDP
   message.

   The second field, is the OPTIONAL lifetime of the master key as
   measured in maximum total number of packets using that will key.  The
   lifetime value MAY be used for written as a non-zero, positive integer or as
   a power of 2 (see the multimedia session.  In this
   section, we detail how grammar in Section 8.2 for details).  The
   "lifetime" value MUST NOT exceed the security descriptions defined maximum packet lifetime for SRTP
   are used with the offer/answer model to negotiate cryptographic
   capabilities and communicate SRTP master keys.

5.1 Generating
   crypto-suite.  If the Offer

   For each SDP media line (m=) using lifetime is too large or otherwise invalid
   then the "RTP/SAVP" transport where entire crypto attribute MUST be considered invalid and an
   "invalid lifetime" condition SHOULD be logged.  The default MAY be
   implicitly signaled by omitting the offerer wants to specify lifetime value (i.e. "||").
   This is convenient when the SRTP cryptographic parameters, key lifetime is the offerer
   MUST provide at least one "a=crypto" line.  When multiple crypto
   lines are provided,
   default value.  As a shortcut to avoid long decimal values, the a=crypto lines are specified in preference
   order, with
   syntax of the most preferred listed first. lifetime allows using the literal "2^", which
   indicates "two to the power of".  The offerer determines example above, shows a case
   where the crypto parameters based on its capabilities and its security
   policies. lifetime is specified as 2^20. The offerer obtains keying material following example,
   which is for "inline", or obtains the uri
   pointing to AES_CM_128_HMAC_SHA1_80 crypto-suite, has a key server. default
   for the lifetime field, which means the SRTP's and SRTCP's default
   values will be used (2^31):

     inline: YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4

   The mechanism to generate or obtain example shows a 30-character key and concatenated salt that is outside
   base64 encoded: The 30-character key/salt concatenation is expanded
   to 40 characters by the scope three-in-four encoding of this specification.

5.2 Answerer Processing

   For each SDP media line using the "RTP/SAVP" transport that contains
   an "a=crypto" line in the offer, the answerer MUST base64.

   The third field, which is also OPTIONAL, is either accept
   exactly one of the crypto lines for that media stream, Master Key
   Identifier (MKI) and its byte length, or it MUST
   reject a <"From", "To"> value.

   "MKI" is the media stream as described in RFC 3264.  Note that if
   there are no "a=crypto" lines for master key identifier associated with the media stream in SRTP master
   key.  If the offer, MKI is given, then the answerer MUST skip length of the following steps MKI MUST also be
   given and instead use separated from 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 MKI by a
   crypto line, the answerer MUST include exactly one "a=crypto" line
   in the answer. colon (":").  The answer crypto line MUST include at least the
   selected crypto-suite and a key-param parameter.

Andreasen, Baugher & Wing                                    [Page 12] 
   To determine if MKI length
   is the answerer can accept any size of the provided
   "a=crypto" lines, the answerer examines MKI field in the crypto lines SRTP packet, specified in order. bytes.
   If an "a=crypto" line does the MKI length is not satisfy given or if it exceeds 128 (bytes), then
   the constraints provided in
   Section 4, that entire crypto line is deemed attribute MUST be considered invalid and MUST an
   "invalid MKI length" condition SHOULD be discarded. logged.  The answerer selects substring
   "1:4" in the first valid crypto line that it supports,
   considering the answerer's capabilities and security policies.  If example assigns to the answerer cannot find any valid crypto line that it supports, or
   its configured policy prohibits any cryptographic key parameter
   (e.g. a master 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
   identifier of "RTP/SAVP" by other means
   outside 1 that is 4 bytes long, and the scope of this document (e.g. by use of MIKEY [mikey]).

   After selecting second example assigns
   a single crypto line, 4-byte key identifier of 1066 to the answerer generates key.

   <"From", "To"> specifies the lifetime for a master key appropriate for key, expressed in
   terms of the selected crypto algorithm(s), unless ROC and SEQ values inside whose range (including the
   range end-points) the offered master key was specified to apply is valid.  <"From", "To"> is an
   alternative to both encryption and
   decryption, in which case the offered MKI and assumes that a 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 is in one-to-
   one correspondence with 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 SRTP session key was for encryption, then on which the <"From",
   "To"> range is defined.  The following example illustrates the answerer
   MUST use it to encrypt any packets it sends and
   of the <"From", "To"> parameter:

    inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|FT=0:0,1:0

   As mentioned above, the key it provides
   in its answer MUST be used to decrypt any incoming packets. The parameter can contain one or more master key in the answer MUST have
   keys.  When the same key length and salt
   length as the offer.

   To set up the bi-directional media with transport set to RTP/SAVP,
   the answerer includes parameter contains more than one "a=crypto" line after its media line with
   transport set to RTP/SAVP.

5.3 Offerer Processing master key, all
   of the Answer

   When the offerer receives the answer, it master keys MUST perform the following
   steps for each "RTP/SAVP" media stream it offerered with one either include an MKI or more
   crypto lines in it.

   If the media stream was accepted and it contains a crypto line, it
   MUST be checked <"From", "To">
   value.  Note that the media line it is valid according not permissible to mix and match use of the
   constraints specified
   two within a single key parameter (i.e., one crypto attribute); all
   master keys in Section 4.  Furthermore, the offerer MUST
   validate, that the crypto-suite selected was a given key parameter must use one of or the offered other.

5.2 Crypto-suites

   The SRTP crypto-suites define the encryption and authentication
   transforms to be used for the SRTP media stream.  If any of these checks fails,
   the security negotiation  The SRTP
   specification has defined here MUST be deemed to have failed.

   It is possible that the answerer supports three crypto-suites, which below are
   described in the "RTP/SAVP" transport
   and accepts context of the offered media stream, yet it does not support SRTP security descriptions.

5.2.1     AES_CM_128_HMAC_SHA1_80

   AES_CM_128_HMAC_SHA1_80 is the
   crypto attribute defined here.  The offerer can recognize this
   situation by seeing SRTP default AES Counter Mode cipher
   and HMAC-SHA1 message authentication having an accepted "RTP/SAVP" media stream 80-bit authentication
   tag.  The master-key length is 128 bits and has a default lifetime
   of a maximum of 2^31 SRTP packets or 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 in Section 7).  The master salt value
   is 112 bits in length and the
   answer session salt value is 112 bits in
   length.  The pseudo-random function (PRF) is the default SRTP
   pseudo-random function that does not include uses AES Counter Mode with a crypto line.  In that case, 128-bit key
   length.

   The length of the
   security negotiation defined here base64 decoded key and salt value for this crypto-
   suite MUST be deemed to have failed.

Andreasen, Baugher & Wing                                    [Page 13] 

5.4 Non-RTP/SAVP Answerers

   If a media stream with transport set to "RTP/SAVP" 30 characters, i.e. 240 bits; otherwise the crypto
   attribute is sent to a
   device that doesn't support "RTP/SAVP", that media stream will be
   rejected.

   In some cases, it considered invalid.

5.2.2 AES_CM_128_HMAC_SHA1_32

   This crypto suite is desirable identical to send SRTP when possible, but allow
   use of RTP if AES_CM_128_HMAC_SHA1_80 except
   that the SRTP isn't supported by a remote device.  However, it authentication key is ambiguous to send an extra media line with transport set to
   "RTP/AVP" 32 bits and with the same port as SRTCP
   authentication key is 80 bits.

   The length of the "RTP/SAVP" line.  Thus, an
   offerer base64-decoded key and salt value for this crypto-
   suite MUST NOT specify multiple media lines with be 30 characters, i.e. 240 bits; otherwise the same port.

   Instead, such interoperability crypto
   attribute is obtained by first sending an offer
   with transport set considered invalid.

5.2.3 F8_128_HMAC_SHA1_80

   This crypto suite is identical to "RTP/SAVP".  If that media line AES_CM_128_HMAC_SHA1_80 except the
   cipher is rejected by F8 [srtp].

   The length of the answerer, base64 decoded key and salt value for this crypto-
   suite MUST be 30 characters, i.e. 240 bits; otherwise the offerer can, if its policy permits, send a crypto
   attribute is considered invalid.

5.2.4 Adding new
   offer with transport set Crypto-suite Definitions

   If new transforms are added to "RTP/AVP".  Also, the SDP extensions
   defined in RFC 3407 [RFC3407] can SRTP, new definitions for those
   transforms SHOULD be used by both given for the offerer SRTP security descriptions and
   answerer
   published in an IETF RFC.  Sections 5.2.1 through 5.2.3 illustrate
   how to indicate capabilities above and beyond what is being
   negotiated define crypto-suite values for particular cryptographic
   transforms.  Any new crypto suites MUST be registered with IANA
   following the media stream.  Another offer/answer exchange will
   then guidelines in section 10.

5.3 Session Parameters

   SRTP security descriptions define a set of "session" parameters,
   which OPTIONALLY may be needed used to negotiate use of any of these latent capabilities.

5.4 Offer/Answer Example: Receiver Supports override SRTP

   In this example, session defaults for
   the Offerer supports two crypto suites (F8 SRTP and
   AES). SRTCP streams.  These parameters configure an RTP
   session for SRTP services and are described in the following.

5.3.1     SRC=SSRC/ROC/SEQ

   The a=crypto line SRTP cryptographic context for a given SRTP session is actually one long line, although it
   identified by the synchronization source (SSRC).  Furthermore,
   associated with a cryptographic context is
   shown as two lines in this document due to page formatting.

   Offerer sends:
     v=0
     o=sam 2890844526 2890842807 IN IP4 10.47.16.5
     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 168.2.17.12
     t=2873397496 2873404696
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80
      inline:d/16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/2^20/1:32
      FEC_ORDER=FEC_SRTP SRC=17174//49126
     a=crypto:F8_128_HMAC_SHA1_80
      inline:d/16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/2^20/1:32
      FEC_ORDER=FEC_SRTP SRC=17174//49126

   Answerer replies:
     v=0
     o=jill 25690844 8070842634 IN IP4 10.47.16.5
     s=SRTP Discussion
     i=A discussion of Secure RTP
     u=http://www.example.com/seminars/srtp.pdf
     e=homer@example.com (Homer Simpson)

Andreasen, Baugher & Wing                                    [Page 14] 
     c=IN IP4 168.2.17.11
     t=2873397526 2873405696
     m=audio 32640 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80
      inline:d/16/14/PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR/2^20/1:32
      SRC=88131/721/13

   In this case, the session would use the AES_CM_128_HMAC_SHA1_80
   crypto suite for SRTP packet index
   which is derived from the RTP sequence number (SEQ) and RTCP traffic.  The answerer is also
   specifying both its initial SSRC (88131), a rollover
   counter (721), (ROC).  The SSRC and rollover counter (13).

5.7 Use of a=crypto With Active Media Streams

   When an active SEQ are included in the SRTP session is rekeyed, this packets,
   however they are not included in standard SDP (for various reasons).
   The ROC is indicated by sending
   a new SDP.  Rekeying neither included in the SRTP packets nor standard SDP but
   is done following instead derived algorithmically based on the rules described for total number of
   packets sent.  This presents a
   normal Offer/Answer exchange.  The Answerer can take this
   opportunity to rekey couple of challenges:

   * If the traffic it master key is sending, if the Answerer
   desires.  During rekeying, the shared between two or more session parameters cannot be changed
   and
     participants, SSRC collisions MUST NOT be specified in avoided; SSRC collision
     detection and resolution is not an acceptable alternative as this
     can lead to the Offer or two-time pad problem [srtp].

   * If a participant joins an ongoing session (where the Answer.

   When ROC is non-
     zero), the Offerer participant needs to rekey, the offerer MUST send an "a=crypto"
   line with same crypto-suite, key length, and salt length that was
   previously accepted by learn the Answerer. ROC somehow.

   * If the answerer selected "a=crypto" lines using the "inline" method,
   the exact same "a=crypto" line(s) as agreed initial sequence number is close to in the answer MUST be
   sent maximum sequence
     number and a new new inline key MUST be sent.

   If the answerer selected "a=crypto" lines using the "uri" method, initial SRTP packets are lost, the sender MAY transmit receiver may not
     update his ROC correctly.

   * When joining a multicast RTP session with multiple participants, a
     separate crypto context needs to be established for each
     participant (SSRC).  Even if the same uri, and the recipient MUST fetch
   the new master key using the uri.

5.8 Operation with KEYMGT and Key lines

   An Offer MAY include both a=crypto and a=keymgt lines [keymgt].  Per
   SDP rules, the Answerer will ignore attribute lines it doesn't
   understand.  If the Answerer supports both a=crypto and [keymgt],
   the Answer MUST include either a=crypto or [keymgt], as including
   both is undefined.

6. Security Considerations

   Like used by 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
     participants, the
   encapsulating protocol ROC for each still needs to ensure be learned somehow.

   The SRC session parameter provides information to establish the protection SRTP
   cryptographic context.  It contains information about one or more of
   the SDP security
   descriptions.  Therefore, that protocol should either invoke its own
   security mechanisms to do so, following:

   * SSRC:     Synchronization source
   * ROC:      Roll-over counter
   * SEQ:      Sequence number

   The ROC and sequence number are typically only needed for sessions
   already in progress (as when rekeying or alternatively utilize when joining 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 multicast
   session).

   Zero or more SRC parameters MAY appear in both a hop-by-hop and end-to-
   end crypto attribute.  When
   more than one SRC parameter is present, each of them MUST contain a
   distinct SSRC value.  Each SRC parameter defines a separate SRTP
   crypto context (e.g. SIP), an end-to-end security service SHOULD be
   provided by (see section 3.2 of [srtp]) that protocol for all sensitive information including
   SDP's security parameters.  This service SHOULD provide strong
   message authentication SHALL share the
   master key and packet-payload encryption as well as
   effective replay protection.  As an example, SIP with S/MIME bodies
   satisfies these requirements.

6.1 Authentication salt defined by one or more inline key parameters.
   The total number of all packets

   RTP messages are vulnerable to a variety of attacks such as replay
   and forging.  To limit these attacks, SRTP message integrity
   mechanisms SHOULD be used (SRTP replay protection is always
   enabled). Source authentication of unicast SRTP messages SHOULD be
   performed [srtp].  Note that SRTP source-message authentication does
   not authenticate are encrypted by keys derived
   from this master key MUST NOT exceed the IP-address lifetime of the inline key.
   The SRTP source, but ensures that crypto contexts so defined SHALL also have a common
   definition for the SRTP message crypto-suite and all other crypto parameters.

   SSRC is the RTP SSRC that is associated with the SRTP receiver had received crypto context, and
   is exactly what an integer in the SRTP sender had sent.  Source authentication range of multicast SRTP
   messages 0..2^32-1.  If an SSRC value is today non-standard
   invalid, the entire crypto attribute line MUST be considered invalid
   and hence an "invalid SSRC" condition SHOULD be logged.  If an SSRC value
   collides with an SSRC for further study.  But
   even an existing participant in multicast sessions, SRTP packet authentication ensures that the packet originated from a member of session,
   the secure group.  Use entire crypto attribute line MUST be considered invalid and an
   "SSRC collision" condition SHOULD be logged.

     OPEN ISSUE: It would be nice to have a way of indicating this
     condition in an answer SDP, but we quickly end up duplicating the
   UNAUTHENTICATED_SRTP parameter, therefore,
     RTP collision detection and resolution, which we don't want to.

   ROC is NOT RECOMMENDED.

6.1 Key-stream Reuse

   Misconfigured the SRTP sessions, moreover, are vulnerable to attacks on
   their encryption services when running the crypto suites defined rollover counter (ROC) in
   Sections 4.1.1, 4.1.2 the range of 0..2^32-1 and 4.1.3.  An SRTP encryption service
   is
   "mis-configured" when two zero by default.  Typically the ROC value is specified as a non-
   zero value for an ongoing SRTP stream in which the ROC has cycled
   one or more media streams are encrypted using times [srtp].  The receiver of the same AES keystream.  When senders and receivers share derived
   session keys, SRTP requires that SDP message SHOULD
   refresh the SSRCs ROC value before joining an ongoing session.  Depending
   on the nature of the session participants
   make their corresponding keystreams unique, which is violated in control, the
   case late-joining receiver
   might need to refresh its ROC value through a unicast exchange or
   through receipt of SSRC collision: SRTP SSRC collision drastically weakens SRTP a multicast or SRTCP payload encryption during the time that identical
   keystreams were used [srtp].  An attacker, for example, might
   collect SRTP and SRTCP messages and await unicast message containing a collision.  This attack
   on ROC
   SRTP description.  If the AES-CM ROC is greater than 2^32-1, then the
   entire crypto attribute line MUST be considered invalid and AES-f8 encryption an
   "invalid ROC" condition SHOULD be logged.

   SEQ is avoided entirely when each
   media stream has its own unique master key, as this document
   RECOMMENDS (Section 4.2).

   SRTP multicast operation requires that each host-sender have a
   unique the SRTP keystream.  This can be accomplished by ensuring that
   each sender sequence number (SEQ), which MUST be allocated a unique key or by ensuring that in the SSRC range of each sender will not collide.  Since SSRC collision might occur,
   0..2^16-1.  SRTP uses the latter condition is avoided when all SSRCs are assigned by a
   central authority such as a 3rd-party key server RTP sequence number and the ROC to compute
   the packet index [srtp].  This is
   for further study.  The RECOMMENDED approach of  For this document is to
   allocate a different master key for each host-participant reason, the initial SEQ SHOULD be
   in the range of 0..2^15-1 to avoid an SRTP ambiguity when packets are
   lost at the start of the session.

Andreasen, Baugher & Wing                                    [Page 16] 

6.2 Signaling Authentication and Signaling Encryption

   There is no reason to incur  At the complexity and computational expense start of SRTP, however, when its key establishment is exposed a session, an
   SSRC source 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
   unauthorized parties.  In most cases, the SRTP crypto attribute and point that the sequence number wraps
   (exceeds 2^16-1), then the receiver might not recognize that its parameters are vulnerable ROC
   needs to denial be incremented.  By restricting the initial SEQ to the
   range of service attacks when they
   are carried in an unauthenticated SDP message.  In some cases, 0..2^15-1, SRTP packet-index determination will find the
   integrity or confidentiality
   correct ROC value, unless all of the RTP stream can be compromised.
   For example, first 2^15 packets are lost
   (which seems, if an attacker sets UNENCRYPTED for not impossible, then rather unlikely).  See Section
   3.3.1 of the SRTP stream specification regarding packet-index determination
   [srtp].

   It is not necessary to signal SEQ and ROC at the start of the SRTP
   session if the receivers do not join the session late, which is
   typical in IP telephony, multimedia client/server, and similar
   applications.  Large-scale multicast applications, however, will
   sometimes have late joiners to the session and MAY choose to use the
   SRC session parameter to set the SEQ and the ROC.  The SSRC MAY also
   be initialized in the SRC parameter; this can for example be useful
   to establish the crypto contexts (in particular the ROC) for all the
   session participants.

   Like SEQ and ROC, SSRC is OPTIONAL (unless there are multiple SRC
   parameters in which case it is mandatory) and often need not be
   signaled.  If the master key is not shared among senders for their
   encryption services, then SSRC uniqueness is NOT REQUIRED (see
   Section 7.2) and the SSRC need not be signaled.  In this way, each
   master key is used for encryption by exactly one sender and used for
   decryption by one or more receivers: In this case, there is no risk
   of keystream reuse for the crypto-suite ciphers of Section 5.2.1,
   5.2.2, and 5.2.3.

   The SRTP crypto context can be established for the SRTP session
   address in the connection (c=) line and the port in the media (m=)
   line (or rtpmap) without having specified an SSRC value in the SRTP
   security descriptions. This is called "late binding" by this
   specification.  If late binding is used, then when a packet arrives,
   the SSRC that is contained in it can be bound to the crypto context
   at the time of session commencement rather than at the time of
   session signaling.  With the arrival of the packet containing the
   SSRC, all the data items (except the ROC if it is non-zero) needed
   for the SRTP crypto context are held by the receiver.  In other
   words, the crypto context for an RTP/SAVP session using late binding
   is initially identified by the SDP as:

          <*, address, port>

   where '*' is a wildcard SSRC, "address" is from the "c=" line, and
   "port" is from the "m=" line.  When the first packet arrives with
   ssrcX in its SSRC field, the crypto context

          <ssrcX, address, port>

   is instantiated subject to the following constraints:

   * Media packets are authenticated:  Authentication MUST succeed;
     otherwise, the crypto context is not instantiated.

   * Media packets are not authenticated:  Crypto context is
     automatically instantiated.

   It should be noted, that use of late binding when there is no
   authentication of the SRTP media packets is subject to numerous
   security attacks and consequently it is NOT RECOMMENDED (of course,
   this can be said for unauthenticated SRTP in general).  Endpoints
   that do not wish to subject themselves to such security risks can
   either signal the SSRC by out-of-band mechanisms (as defined here),
   or ensure that only authenticated SRTP is being used.

5.3.2     KDR=n

   KDR specifies the Key Derivation Rate, as described in section 4.3.1
   of [srtp].

   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).

5.3.3     UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP

   SRTP and SRTCP packet payloads are encrypted by default.  The
   UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the
   default behavior of the crypto-suites with which they are used:

   * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not
     encrypted.

   * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not
     encrypted.

5.3.4     UNAUTHENTICATED_SRTP

   SRTP and SRTCP packet payloads are authenticated by default.  The
   UNAUTHENTICATED_SRTP session parameter signals that SRTP messages
   are not authenticated.  Use of UNAUTHENTICATED_SRTP is NOT
   RECOMMENDED (see Security Considerations).

     The SRTP specification requires use of message authentication for
     SRTCP, but not for SRTP [srtp].

5.3.5     FEC_ORDER=order

   FEC_ORDER signals the use of forward error correction for the RTP
   packets [rfc2733].  The forward error correction values for "order"
   are FEC_SRTP, SRTP_FEC, or SPLIT [mikey].  FEC_SRTP signals that FEC
   is applied before SRTP processing by the sender of the SRTP media
   and after SRTP processing by the receiver of the SRTP media;
   FEC_SRTP is the default.  SRTP_FEC is the reverse processing.  SPLIT
   signals that the sender performs SRTP encryption, followed by FEC
   processing, followed by SRTP authentication; processing is reversed
   on the receiver.

5.3.6     Window Size Hint (WSH)

   SRTP defines the SRTP-WINDOW-SIZE [SRTP, section 3.3.2] parameter to
   protect against replay attacks.  The minimum value, per [srtp], is
   64, however this value may be considered too low for some
   applications (e.g. video).

   The Window Size Hint (WSH) session parameter provides a hint for how
   big this window should be to work satisfactorily (e.g. based on
   sender knowledge of number of packets per second).  However, there
   might be enough information given in SDP attributes like
   "a=maxprate" and the bandwidth modifiers to allow a receiver to
   derive the parameter satisfactorily.  Consequently, this value is
   only considered a hint to the receiver of the SDP which MAY choose
   to ignore the value provided.

5.3.7     SRTP Extension Session Parameters

   New SRTP session parameters for the SRTP security descriptions can
   be defined in an IETF RFC and registered with IANA according to the
   registration procedures defined in Section 10.

   SRTP extension session parameters are by default mandatory.  An SRTP
   extension session parameter that is prefixed with the dash character
   ("-") however is considered optional and MAY be ignored.  If a SDP
   is received with an unknown mandatory session parameter in a crypto
   attribute, that crypto attribute MUST be considered invalid and a
   "unknown session parameter" condition SHOULD be logged.

6. SRTP-Specific Use of the crypto Attribute

   In this section, we describe the SRTP-specific use of the crypto
   attribute.

6.1 Use with Offer/Answer

   In this section, we describe how the SRTP security descriptions are
   used with the offer/answer model to negotiate cryptographic
   capabilities and communicate SRTP master keys.  The rules defined
   below complement the general offer/answer rules defined in Section
   4.1, which MUST be followed, unless otherwise specified.

6.1.1     Generating the Initial Offer

6.1.1.1   Unicast Streams

   When the initial offer is generated, the offerer MUST follow the
   steps in Section 4.1.1.1 as well as the following steps.

   For each unicast media line (m=) using the "RTP/SAVP" transport
   where the offerer wants to specify cryptographic parameters, the
   offerer MUST provide at least one valid SRTP security description
   ("a=crypto" line), as defined in Section 5.

   The offerer MAY include one or more SRTP session parameters as
   defined in Section 5.3.  Note however, that if any extension SRTP
   session parameters are included, the negotiation will fail if the
   answerer does not support them.

6.1.1.2   Multicast Streams

   When the initial offer is generated, the offerer MUST follow the
   steps in Section 4.1.1.2 as well as the following steps.

   For each multicast media line (m=) using the "RTP/SAVP" transport
   where the offerer wants to specify cryptographic parameters, the
   offerer MUST provide at least one valid SRTP security description
   ("a=crypto" line), as defined in Section 5.  Furthermore, the
   <"From", "To"> parameter in the key parameter MUST NOT be used,
   unless the media stream is marked as "recvonly".

     The <"From", "To"> value is SSRC specific, and hence will only
     work when there is a single sender in the multicast case, i.e. all
     invited participants only receive media.

   The offerer MAY include one or more SRTP session parameters as
   defined in Section 5.3.  Note however, that if any extension SRTP
   session parameters are included, the negotiation will fail if the
   answerer does not support them.

6.1.2     Generating the Initial Answer

6.1.2.1   Unicast Streams

   When the initial answer is generated, the answerer MUST follow the
   steps in Section 4.1.2.1 as well as the following steps.

   For each unicast media line using the "RTP/SAVP" transport that
   contains one or more "a=crypto" lines in the offer, the answerer
   MUST either accept one of the crypto lines for that media stream, or
   it MUST reject the media stream.  Only "a=crypto" lines that are
   considered valid SRTP security descriptions as defined in Section 5
   can be accepted.  Furthermore, all parameters (crypto-suite, key
   parameter, and session parameters) MUST be acceptable to the
   answerer in order for the offered media stream to be accepted.

   When the answerer accepts an "RTP/SAVP" unicast media stream with a
   crypto line, the answerer indicates acceptance by including its own
   "a=crypto" line in the answer.  The answer crypto line MUST include
   at least the selected SRTP crypto-suite and one or more master keys
   appropriate for the selected crypto algorithm; the master key(s)
   included in the answer SHOULD be different from those in the offer.

     If the master key(s) are not shared between the offerer and
     answerer, SSRC collisions are acceptable, which simplifies the
     overall operation.

   Session parameters MAY be included in the answer as well; any
   session parameters included in the answer are independent of session
   parameters included in the offer.  Use of extension SRTP session
   parameters SHOULD be avoided unless it is known that the offerer
   supports these.

   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. 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]).

6.1.2.2   Multicast Streams

   When the initial answer is generated, the answerer MUST follow the
   steps in Section 4.1.2.2 as well as the following steps.

   For each multicast media stream using the "RTP/SAVP" transport that
   contains an "a=crypto" line in the offer, the answerer MUST either
   accept the first crypto line for that media stream (note that there
   should only be one crypto line), or it MUST reject the media stream.
   The crypto line MUST only be accepted if it is considered a valid
   SRTP security description as defined in Section 5.  Furthermore, all
   parameters (crypto-suite, key parameter, and session parameters)
   MUST be acceptable to the answerer in order for the offered media
   stream to be accepted.

   When the answerer accepts an "RTP/SAVP" multicast media stream with
   a crypto line, the answerer indicates acceptance by repeating the
   crypto line from the offer in the answer, except for the session
   parameters which SHOULD be excluded.

     There is only a single view of a multicast stream (unlike
     unicast), and hence there is no reason to repeat optional
     parameters that cannot change anyway.

     OPEN ISSUE:  It is not clear that all session parameters should be
     excluded from the answer.  In particular, we may want to allow for
     inclusion of the SRC parameter, as this would enable a new-comer
     to instantiate crypto-contexts for other participants in a
     multicast conference, provided the conference is using a shared
     key.  If each sender uses a unique key, something else would be
     needed (e.g. an offer/answer exchange with each participant or an
     entirely different mechanism).

   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. KDR,
   FEC_ORDER), it MUST reject the media stream.

   It should be noted, that multicast streams with more than one sender
   that are negotiated by use of this mechanism will be using the same
   master key for sending and receiving and hence SSRC collisions must
   be avoided.  The mechanism defined here does not provide a way to
   avoid such SSRC collisions for multicast streams, and hence means
   outside of the scope of this document are needed to ensure that SSRC
   collisions are avoided.  Examples of how this can be achieved
   include a centralized controller supplying unique SSRCs to the
   session participants or a separate protocol that can ensure SSRC
   uniqueness prior to sending any SRTP packets.

6.1.3     Offerer Processing of the Initial Answer

6.1.3.1   Unicast Streams

   When the offerer receives the answer, it MUST perform the steps in
   Section 4.1.3.1 as well as the following steps for each "RTP/SAVP"
   media stream it offered with one or more crypto lines in it.

   If the media stream was accepted and it contains a crypto line, it
   MUST be checked that the crypto line is valid according to the
   constraints specified in Section 5.

   If the crypto line contains any SRTP session parameters, those
   parameters define SRTP behavior for media sent from the answerer to
   the offerer.  If the offerer either does not support or is not
   willing to honor one or more of the SRTP session parameters in the
   answer, the offerer MUST consider the crypto line invalid.

   If the crypto line is not valid, or the offerer's configured policy
   prohibits any cryptographic key parameter (e.g. key length) or
   cryptographic session parameter, the SRTP security negotiation MUST
   be deemed to have failed.

6.1.3.2   Multicast Streams

   When the offerer receives the answer, it MUST perform the steps in
   Section 4.1.3.2 as well as the following steps for each "RTP/SAVP"
   media stream it offered with a crypto line in it.

   If the media stream was accepted and it contains a crypto line, it
   MUST be checked that the crypto line is valid according to the
   constraints specified in Section 5.  If the crypto line includes any
   session parameters, those are simply ignored.

     OPEN ISSUE:  As noted in Section 6.1.2.2, it may make sense to
     allow for some session parameters, e.g. SRC, to be included.

   If the crypto line is not valid, the SRTP security negotiation MUST
   be deemed to have failed for that particular answerer.

6.1.4     Modifying the Session

   When a media stream using the SRTP security descriptions has been
   established, and a new offer/answer exchange is performed, the
   offerer and answerer MUST follow the steps in Section 4.1.4 as well
   as the following steps.

   Unicast Streams:
   * The offerer SHOULD include the ROC and SEQ (unless both are made
     available to the answerer by other means); this enables the
     answerer to establish the complete crypto context in case he
     currently does not have the ROC.

   Multicast Streams:
   * When the media stream is "recvonly", the offerer SHOULD include
     the ROC and SEQ (unless both are made available to the answerer by
     other means); this enables the answerer to establish the complete
     crypto context in case he currently does not have the ROC.

   It should be noted, that the mechanism defined here does not provide
   a way to communicate the ROC for multiple senders, which may be
   needed in some multicast scenarios, e.g. conferencing.  If
   renegotiation is needed, a separate mechanism, such as [GDOI], will
   be needed for this.  These methods are beyond the scope of this
   document.

     OPEN ISSUE:  As noted in Section 6.1.2.2, it is not clear that we
     couldn't do that with the SRC parameter.

   When modifying the session, all negotiated aspects of the SRTP media
   stream can be modified. For example, a new crypto suite can be used
   or a new master key can be established.  As described in RFC 3264,
   when doing a new offer/answer exchange there will be a window of
   time, where the offerer and the answerer must be prepared to receive
   media according to both the old and the new offer/answer exchange.
   This requirement applies here as well, however the following should
   be noted:

   * When authentication is not being used, it may not be possible for
     either the offerer or the answerer to determine if a given packet
     is encrypted according to the old or new offer/answer exchange.
     RFC 3264 defines a couple of techniques to address this problem,
     e.g. changing the payload types used and/or the transport
     addresses.  Note however that a change in transport addresses may
     have an impact on Quality of Service as well as firewall and NAT
     traversal.  The SRTP security descriptions offers two other ways
     of dealing with this; use the MKI (which adds a few bytes to each
     SRTP packet) or the <"From","To"> mechanism (which doesn't add
     bytes to each SRTP packet) as described in Section 5.1.1.1.  For
     further details on MKI and "<"From","To">, please refer to [srtp].

   * If the answerer changes its master key, the offerer will not be
     able to process packets secured via this master key until the
     answer is received.

     As noted in Section 4.1.1.1, this could for example be addressed
     by defining a security "precondition" [RFC3312]

   Finally note, that if the new offer is rejected, the old crypto
   parameters remain in place.

6.1.5 Offer/Answer Example

   In this example, the offerer supports two crypto suites (F8 and
   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 sends:
     v=0
     o=sam 2890844526 2890842807 IN IP4 10.47.16.5
     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 168.2.17.12
     t=2873397496 2873404696
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80
      inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
      FEC_ORDER=FEC_SRTP SRC=//49126
     a=crypto:F8_128_HMAC_SHA1_80
      inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4
      FEC_ORDER=FEC_SRTP SRC=//49126

   Answerer replies:
     v=0
     o=jill 25690844 8070842634 IN IP4 10.47.16.5
     s=SRTP Discussion
     i=A discussion of Secure RTP
     u=http://www.example.com/seminars/srtp.pdf
     e=homer@example.com (Homer Simpson)
     c=IN IP4 168.2.17.11
     t=2873397526 2873405696
     m=audio 32640 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80
      inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
      SRC=/721/13

   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 current rollover counter (721), and sequence
   number (13).

6.2 SRTP-Specific Use Outside Offer/Answer: Advertising

   The SRTP security descriptions can be used outside the context of
   offer/answer as described in Section 4.2.  In those cases, the
   general rules defined in Section 4.2 as well as the SRTP-specific
   rule defined below MUST be followed:

   * If any SRTP session parameters are included, they MUST be
     supported by the recipient of the SDP; otherwise, the recipient
     MUST NOT join the SRTP session.

6.3  SRTP-Specific Backwards Compatibility Considerations

   It is possible that the answerer supports the "RTP/SAVP" transport
   and accepts the offered media stream, yet it does not support the
   crypto attribute defined here.  The offerer can recognize this
   situation by seeing an accepted "RTP/SAVP" media stream in the
   answer that does not include a crypto line.  In that case, the
   security negotiation defined here MUST be deemed to have failed.

   Also, if a media stream with transport set to "RTP/SAVP" is sent to
   a device that does not support "RTP/SAVP", that media stream will be
   rejected.

6.4  Operation with KEYMGT= and k= lines

   An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt].
   Per SDP rules, the answerer will ignore attribute lines it does not
   understand.  If the answerer supports both "a=crypto" and
   "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt"
   but not both, as including both is undefined.

   An offer MAY include both "a=crypto" and "k=" lines [SDPnew].  Per
   SDP rules, the answerer will ignore attribute lines it does not
   understand.  If the answerer supports both "a=crypto" and "k=", the
   answer MUST include either "a=crypto" or "k=" but not both, as
   including both is undefined.

6.5  Removal of Crypto Contexts

   The mechanism defined above addresses the issue of creating crypto
   contexts, however in practice, session participants may want to
   remove crypto contexts prior to session termination.  Since a crypto
   context contains information that can not automatically be recovered
   (e.g. ROC and SEQ), it is important that the sender and receiver
   agree on when a crypto context can be removed, and perhaps more
   importantly when it cannot.

     Even when late binding is used for a unicast stream, the ROC is
     lost and cannot be recovered automatically once the crypt context
     is removed.

   We resolve this problem as follows.  When SRTP security descriptions
   are being used, crypto contexts removal MUST follow the same rules
   as SSRC removal from the member table [RFC 3550]; note that this can
   happen as the result of an SRTCP BYE packet or a simple time-out due
   to inactivity.  Inactive session participants that wish to ensure
   their crypto contexts are not timed out MUST thus send SRTCP packets
   at regular intervals.

7. 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, the application protocol SHOULD either
   invoke its own security mechanisms to do so, or alternatively
   utilize a lower-layer security service (e.g. TLS, IPSEC).  This
   security service SHOULD provide strong message authentication and
   packet-payload encryption as well as effective replay protection.

7.1  Authentication of packets

   Security descriptions as defined herein signal security services for
   RTP packets.  RTP messages are vulnerable to a variety of attacks
   such as replay and forging.  To limit these attacks, SRTP message
   integrity mechanisms SHOULD be used (SRTP replay protection is
   always enabled).  Source authentication (i.e. data-origin
   authentication) of unicast SRTP messages SHOULD be performed [srtp].

7.2  Keystream Reuse

   Security descriptions as defined herein signal configuration
   parameters for SRTP sessions.  Misconfigured SRTP sessions  are
   vulnerable to attacks on their encryption services when running the
   crypto suites defined in Sections 5.2.1, 5.2.2, and 5.2.3.  An SRTP
   encryption service is "misconfigured" when two or more media streams
   are encrypted using the same AES keystream.  When senders and
   receivers share derived session keys, SRTP requires that the SSRCs
   of session participants serve to make their corresponding keystreams
   unique, which is violated in the case of SSRC collision: SRTP SSRC
   collision drastically weakens SRTP or SRTCP payload encryption
   during the time that identical keystreams were used [srtp].  An
   attacker, for example, might collect SRTP and SRTCP messages and
   await a collision.  This attack on the AES-CM and AES-f8 encryption
   is avoided entirely when each media stream has its own unique master
   key in both the send and receive direction, as this document
   RECOMMENDS (see Section 6.1.2.1), i.e. keys are not shared between
   multiple media streams, and the keys used in the send and receive
   direction for a given media stream are unique.

   SRTP multicast operation requires that each host-sender have a
   unique SRTP keystream.  This can be accomplished by ensuring that
   each sender be allocated a unique key or by ensuring that the SSRC
   of each sender will not collide.  Since SSRC collision might occur,
   the latter condition is avoided when all SSRCs are assigned by a
   central authority such as a 3rd-party key server [srtp].  The
   RECOMMENDED approach of this document is to allocate a different
   master key for each host-participant of an SRTP session.

7.3  Signaling Authentication and Signaling Encryption

   There is no reason to incur the complexity and computational expense
   of SRTP, however, when its key establishment is exposed to
   unauthorized parties.  In most cases, the SRTP crypto attribute and
   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 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, IPsec, TLS, or some other data security service SHOULD be used
   to provide message authentication for the encapsulating protocol
   that carries the SDP messages having a crypto attribute (a=crypto).
   Furthermore, encryption of the encapsulating payload SHOULD be used
   because 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 SDP parameters cannot be carried in an encrypted and
   authenticated SDP message, it is RECOMMENDED that a key management
   protocol be used instead of the security descriptions defined here
   (a=crypto).  The proposed SDP key-mgmt extension [keymgt] allows
   authentication and encryption of the key management protocol data
   independently of the SDP message that carries it.  The 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
   security association exists between the source and destination
   endpoints, then this solution is more secure than use of the key-
   mgmt statement in an unauthenticated SDP message, which is
   vulnerable to tampering.

   There are practical cases, however, where SDP security is not end-
   to-end: If there is a third-party provider between the sender and
   receiver, then the data-security session might not be end-to-end.
   That is, one possible configuration might have an IPsec or TLS
   connection between the sender of the SDP message and the provider,
   such as a VoIP service provider, with a second secure connection
   between the provider and the receiver:

     signaling controller---(network-b)---signaling controller
          |                                                |
     (network a)                                   (network c)
          |                                                |
     sender----------------(SRTP bearer)--------------receiver

   where all of link a, b, and c are encrypted with TLS or IPsec.

   In this case, the third-party provider has access to the contents of
   the SRTP descriptions in the SDP message. SDP key-mgmt statement,
   however, allows true end-to-end security that is independent of the
   service provider, who often needs access to some parts of the SDP
   message to render its services.  The SRTP attribute SHOULD NOT be
   used when end-to-end authentication or confidentiality is needed but
   the SDP message is not secured end-to-end (such as the above example
   where a third-party provider maintains the security associations
   with the endpoints for the SDP message).

8. Grammar

8.1 Generic "Crypto" Attribute Grammar

   The ABNF grammar for the crypto attribute is defined below:

   "a=crypto:" crypto-suite 1*WSP key-params *(1*WSP session-param)

   crypto-suite     = 1*(ALPHA / DIGIT / "_")

   key-params       = key-param *(";" key-params)
   key-param        = key-method ":" key-info
   key-method       = "inline" | key-method-ext
   key-method-ext   = 1*(ALPHA / DIGIT / "_")
   key-info         = %x21-3A / %x3B-7E ; visible (printing) characters
                                        ; except semi-colon
   session-param    = VCHAR   ; visible (printing) characters

   where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234].

8.2 SRTP "Crypto" Attribute Grammar

   This section provides an Augmented BNF [RFC2234] 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 / FromTo]

     key-salt       = 1*(base64)   ; binary key and salt values
                                   ; concatenated together, and then
                                   ; base64 encoded [section 6.8 of
                                   ; RFC2046]

     lifetime      = ["2^"] 1*(DIGIT)   ; see section 5.1.1.1 for "2^"
     mki            = mki-value ":" mki-length
     mki-value      = 1*DIGIT
     mki-length     = 1*3DIGIT   ; range 1..128.
     FromTo         = "FT=" ftval "," ftval
     ftval          = roc ":" seq  ; packet index expressed in terms
                                   ; of ROC and SEQ.

     srtp-session-param  = src /
                           kdr /
                           "UNENCRYPTED_SRTP" /
                           "UNENCRYPTED_SRTCP" /
                           "UNAUTHENTICATED_SRTP" /
                           fec-order /
                           wsh /
                           srtp-session-extension

     src  = "SRC=" [ssrc] "/" [roc] "/" [seq]

     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*2(DIGIT)  ; range 0..24, power of two

     fec-order = "FEC_ORDER=" fec-type
     fec-type  = "FEC_SRTP" / "SRTP_FEC" / "SPLIT"

     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 [RFC2234]
                              ; first character must not be dash ("-")

9. Open Issues

   The following is a list of open issues in
   an offer, this could result document:

   * The use of security descriptions, and in the answerer not decrypting the
   encrypted SRTP messages.  In the worst case, the answerer might
   itself send unencrypted particular SRTP and leave its data exposed to snooping.

   IPsec, TLS, encapsulating-protocol security or some other data security service SHOULD be
     descriptions, with multicast streams where offer/answer is being
     used to provide message authentication is not well understood and requires further consideration.

   * The security descriptions do not deal with hierarchically encoded
     streams (or at least they have not been considered).

   * The current mechanism does not allow for SDP messages that carry the SRTP attribute.  Message encryption
   SHOULD be used because a master key parameter 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 SDP parameters cannot be carried in specified as
     being an encrypted and
   authenticated SDP message, it is RECOMMENDED that a key management
   protocol be used.  The proposed SDP key-mgmt extension [keymgt]
   allows authentication and encryption of the or decryption key management protocol
   data independently of the SDP message that carries it.  The 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
   security association exists between the source endpoint, its
   signaling controller, and the destination endpoints, then or both; instead this
   solution is more secure than use of
     inferred from the key-mgmt statement in an
   unauthenticated SDP message, which is vulnerable to tampering.

   There are practical cases, however, where SDP security is not end-
   to-end: If context (e.g. unicast offer).  Should there is be a third-party provider between the sender and
   receiver, then the data-security session might not
     mechanism to allow a key to be end-to-end.
   That is, one possible configuration might have tagged as an IPsec encryption, decryption
     or TLS
   connection between the sender both key ?

10. IANA Considerations

10.1 Registration of the "crypto" attribute

   The IANA is hereby requested to register a new SDP message and the provider,
   such attribute as a VoIP service provider, with a second secure connection
   between the provider
   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 3

10.2 New IANA Registries and Registration Procedures

   The following sub-sections define several new IANA registries to be
   used for the receiver:

     signaling controller---(network-b)---signaling controller security descriptions.  It is suggested that the
   following registry structure be used for these:

   Security Descriptions
     |
     +- Key Methods (described in 10.2.1)
     |
     (network a)                                   (network c)
     +- Media Stream Transports
          |
          +- SRTP
               |
     sender----------------(SRTP bearer)--------------receiver

   where all of link a, b, and c are encrypted with TLS or IPsec.

Andreasen, Baugher & Wing                                    [Page 17] 
   In this case, the third-party provider gets the contents of the
               +- SRTP
   descriptions crypto suites (described in the SDP message. SDP key-mgmt statement, however,
   allows true end-to-end security that is independent of the service
   provider, who often needs access to some parts of the SDP message to
   render its services.  The Section 10.2.2)
               |
               +- SRTP attribute SHOULD NOT be used when
   end-to-end authentication or confidentiality is needed but the SDP
   message session parameters (described in Section 10.2.3)

10.2.1    Security Descriptions Key Method Registry and Registration

   The IANA is not secured end to end (such as the above example where hereby requested to create a
   third-party provider maintains the new registry for SDP
   security associations description key methods.  An IANA key method registration
   MUST be documented in an IETF RFC and it MUST provide the name of
   the key method in accordance with the
   endpoints grammar for the SDP message).

7. key-method-ext
   defined in Section 8.1.

10.2.2    SRTP "Crypto" Attribute Grammar

   This section provides an Augmented BNF grammar Crypto Suite Registry and Registration

   The IANA is hereby requested to create a new registry for the SRTP profile
   of
   crypto suites. An IANA crypto suite registration MUST indicate the SDP
   crypto attribute.  ABNF is defined suite name in [RFC2234].

     key-param      = method-inline / method-uri

     crypto-suite   = "AES_CM_128_HMAC_SHA1_32" /
                      "F8_128_HMAC_SHA1_32" /
                      "AES_CM_128_HMAC_SHA1_80"

     method-inline   = "inline:" key-info *(SP session-param)
     method-uri      = "uri:<" absoluteURI ">" ; absoluteURI accordance with the grammar for srtp-crypto-
   suite-ext defined in
                                               ; [RFC2396]

     key-info = key-use "/" key-length "/" salt-length "/" key-salt
                "/" [lifetime] "/" [mki]

     key-use =   "d" / "e" / "b"   ; decrypt, encrypt, or both
     key-length = 1*DIGIT
     salt-length = 1*DIGIT

     key-salt = 1*(base64)           ; binary key and salt values
                                     ; concatenated together, Section 8.2.

   The semantics of the crypto suite MUST be described in an IETF RFC,
   including the semantics of the "inline" key-method and then
                                     ; base64 encoded [section 6.8 any special
   semantics of
                                     ; RFC2046]

     lifetime = ["2^"] 1*(DIGIT)
     mki = mki-length ":" mki-value
     mki-length = 1*DIGIT         ; real value parameters.

10.2.3    SRTP Session Parameter Registration

   The IANA is 2^mki-length, max 128
     mki-value = 1*DIGIT

     session-param  = src /
                      kdr /
                      "UNENCRYPTED_SRTP" /
                      "UNENCRYPTED_SRTCP" /
                      "UNAUTHENTICATED_SRTP" /
                      fec-order

Andreasen, Baugher & Wing                                    [Page 18] 
     src = "SRC=" [ssrc] "/" [roc] "/" [seq]

     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 / "+" / "/" / "="

8. Open Issues hereby requested to create a new registry for SRTP
   session parameters.  An IANA SRTP session parameter registration
   MUST indicate the session parameter name (srtp-session-extension as
   defined in Section 8.2); the name MUST NOT begin with the dash
   character ("-").

   The following is a list semantics of open issues the parameter MUST be described in this document:

   * The crypto attribute an IETF RFC.  If
   values 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 assigned to better describe
     unidirectional the parameter, then the format and inactive streams, unicast versus multicast, as
     well
   possible values that can be assigned MUST be described in the IETF
   RFC as additional detail well.

10.3 Initial Registrations

   The following security descriptions key methods are hereby
   registered:

     inline

   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 following SRTP session parameters are hereby registered:

     SRC
     KDR
     UNENCRYPTED_SRTP
     UNENCRYPTED_SRTCP
     UNAUTHENTICATED_SRTP
     FEC_ORDER
     WSH

   The ABNF for some all of the session parameters.

9. above is already included in the ABNF
   section of 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 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 requiring unique master keys for each unicast 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.

12. Authors' Addresses

   Flemming Andreasen
   Cisco Systems, Inc.
   499 Thornall Street, 8th Floor
   Edison, New Jersey  08837 USA
   fandreas@cisco.com

   Mark Baugher
   5510 SW Orchid Street
   Portland, Oregon  97219 USA
   mbaugher@cisco.com
   +1-408-853-4418

Andreasen, Baugher & Wing                                    [Page 19]

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134  USA
   dwing@cisco.com
   +1-408-902-3348

11.

13. Normative References

   [RFC1889]

   [RFC3550] H. Schulzrinne, S. Casner, R. Fredrick, Frederick, V. Jacobson,
   "RTP: A Transport Protocol for Real-Time Applications", January 1996,
   http://www.ietf.org/rfc/rfc1889.txt. RFC 3550,
   July 2003, http://www.ietf.org/rfc/rfc3550.txt.

   [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
   Specifications: ABNF," RFC 2234, November 1997,
   http://www.ietf.org/rfc/rfc2234.txt.

   [SDPnew] M. Handley, V. Jacobson, C. Perkins, "SDP: Session
   Description Protocol,", Protocol", Work in Progress.

   [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for
   Generic Forward Error Correction", RFC 2733, December 1999,
   http://www.ietf.org/rfc/rfc2733.txt.

   [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
   2000,
   http://www.ietf.org/rfc/rfc2828.txt http://www.ietf.org/rfc/rfc2828.txt.

   [RFC3264] "J. J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
   the Session Description Protocol (SDP)", RFC 3264, June 2202,
   http://www.ietf.org/rfc/rfc3264.txt
   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
   Progress.

   [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
   Recommendations for Security", RFC 1750, December 1994.

12. 1994,
   http://www.ietf.org/rfc/rfc1750.txt.

14. Informative References

   [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
   Capability Declaration", RFC 3407, October 2002. 2002,
   http://www.ietf.org/rfc/rfc3407.txt.

   [Bellovin] Steven M. Bellovin, "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] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group
   Domain of Interpretation", RFC 3547, July 2003,
   http://www.ietf.org/rfc/rfc3547.txt.

   [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of
   Keys (KINK)", Work in Progress.

   [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
   2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt.

   [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998,
   http://www.ietf.org/rfc/rfc2401.txt.

   [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC
   2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt.

   [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
   2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt.

   [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
   "Key Management Extensions for SDP and RTSP", February 2003,
   http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-
   07.txt, Work in Progress.

Andreasen, Baugher & Wing                                    [Page 20]

   [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
   "MIKEY: Multimedia Internet KEYing", July 2002,
   http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt, Work in Progress.

   [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
   2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt.

   [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
   for Message Authentication", RFC 2014, November 1997,
   http://www.ietf.org/rfc/rfc2104.txt.

   [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
   Mechanism for the Internet", ISOC Secure Networks and Distributed
   Systems Symposium, San Diego, 1996.

   [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of
   Resource Management and Session Initiation Protocol (SIP)", RFC
   3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt.

   [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement
   Protocol", RFC 2974, October 2000,
   http://www.ietf.org/rfc/rfc2974.txt .

Intellectual Property 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.

   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
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   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
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Andreasen, Baugher & Wing                                    [Page 22]