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

           Session Description Protocol Security Descriptions
                           for Media Streams
                <draft-ietf-mmusic-sdescriptions-02.txt>
                <draft-ietf-mmusic-sdescriptions-03.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). (2004).  All Rights Reserved.

Abstract

   This document defines a Session Description Protocol (SDP)
   cryptographic attribute for unicast media streams.  The attribute
   describes a cryptographic key and other parameters, which serve to
   configure security for a unicast media stream in either a single
   message or a
   roundtrip. roundtrip exchange.  The attribute can be used with a
   variety of SDP media transports and this document defines how to use
   it for the Secure Real-time Transport Protocol (SRTP) unicast media
   streams.  The SDP crypto attribute requires the services of a data
   security protocol to secure the SDP message.

Table of Contents

1. Notational Conventions............................................3
2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters.............................4 Parameters.............................5
 3.1 Crypto-suite....................................................5 Tag.............................................................5
 3.2 Key Parameters..................................................5 Crypto-suite....................................................5
 3.3 Key Parameters..................................................6
 3.4 Session Parameters..............................................6
 3.4 Example.........................................................6
 3.5 Example.........................................................7
4. General Use of the crypto Attribute...............................6 Attribute...............................7
 4.1 Use With Offer/Answer...........................................7 Offer/Answer...........................................8
   4.1.1  Generating the Initial Offer..............................7 Offer - Unicast Streams............8
   4.1.2  Generating the Initial Answer.............................8 Answer - Unicast Streams...........9
   4.1.3  Offerer Processing of the Initial Answer..................9 Answer - Unicast Streams10
   4.1.4  Modifying the Session....................................10
 4.2 Use Outside Offer/Answer: Advertising..........................10 Offer/Answer.......................................10
 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions.......................................11
 5.1 SRTP Key Parameter.............................................12
 5.2 Crypto-suites..................................................14
   5.2.1  AES_CM_128_HMAC_SHA1_80..................................14  AES_CM_128_HMAC_SHA1_80..................................15
   5.2.2  AES_CM_128_HMAC_SHA1_32..................................14  AES_CM_128_HMAC_SHA1_32..................................15
   5.2.3  F8_128_HMAC_SHA1_80......................................15  F8_128_HMAC_SHA1_80......................................16
   5.2.4  Adding new Crypto-suite Definitions......................15 Definitions......................16
 5.3 Session Parameters.............................................15 Parameters.............................................16
   5.3.1  SRC=SSRC/ROC/SEQ.........................................15  KDR=n....................................................16
   5.3.2  KDR=n....................................................18
   5.3.3  UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................18 UNENCRYPTED_SRTP...................16
   5.3.3  UNAUTHENTICATED_SRTP.....................................17
   5.3.4  UNAUTHENTICATED_SRTP.....................................19  FEC_ORDER=order..........................................17
   5.3.5  FEC_ORDER=order..........................................19
   5.3.6  Window Size Hint (WSH)...................................19
   5.3.7 (WSH)...................................17
   5.3.6  Defining New SRTP Extension Session Parameters........................19 Parameters.....................18
 5.4 SRTP Crypto Context Initialization.............................18
 5.5 Removal of Crypto Contexts.....................................20
6. SRTP-Specific Use of the crypto Attribute........................20 Attribute........................21
 6.1 Use with Offer/Answer..........................................20 Offer/Answer..........................................21
   6.1.1  Generating the Initial Offer.............................20 Offer - Unicast Streams...........21
   6.1.2  Generating the Initial Answer............................21 Answer - Unicast Streams..........21
   6.1.3  Offerer Processing of the Initial Answer.................22 Answer - Unicast Streams22
   6.1.4  Modifying the Session....................................23 Session....................................22
   6.1.5  Offer/Answer Example.....................................24 Example.....................................23
 6.2 SRTP-Specific Use Outside Offer/Answer: Advertising............25 Offer/Answer.........................24
 6.3 Support for SIP Forking........................................24
 6.4 SRTP-Specific Backwards Compatibility Considerations...........25
 6.4
 6.5 Operation with KEYMGT= and k= lines............................26
 6.5 Removal of Crypto Contexts.....................................26 lines............................25
7. Security Considerations..........................................26
 7.1 Authentication of packets......................................27 packets......................................26
 7.2 Keystream Reuse................................................27 Reuse................................................26
 7.3 Signaling Authentication and Signaling Encryption..............27 Encryption..............26
8. Grammar..........................................................29 Grammar..........................................................28
 8.1 Generic "Crypto" Attribute Grammar.............................29 Grammar.............................28
 8.2 SRTP "Crypto" Attribute Grammar................................29 Grammar................................28
9. Open Issues......................................................30
10. IANA Considerations.............................................31
 10.1 Considerations..............................................29
 9.1 Registration of the "crypto" attribute........................31
 10.2 attribute.........................29
 9.2 New IANA Registries and Registration Procedures...............31
   10.2.1 Procedures................29
   9.2.1  Security Descriptions Key Method Registry and Registration31
   10.2.2 SRTP Crypto Suite Registration30
   9.2.2  Security Description Media Stream Transport Registry and Registration..............31
   10.2.3 SRTP Session Parameter Registration......................32
 10.3
   Registration.....................................................30
 9.3 Initial Registrations.........................................32

11. Registrations..........................................30
   9.3.1  Key Method...............................................30
   9.3.2  SRTP Media Stream Transport..............................31
10. Acknowledgements................................................32
12.
11. Authors' Addresses..............................................33
13. Addresses..............................................32
12. Normative References............................................33
14. References............................................32
13. Informative References..........................................34 References..........................................33
Intellectual Property Statement.....................................35
Acknowledgement.....................................................36

1. Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
   NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
   be interpreted as described in [RFC2119].  The terminology in this
   document conforms to [RFC2828], "Internet Security Glossary".

   n^r is exponentiation where n is multiplied by itself r times; n and
   r are integers.  0..k is an integer range of all integers from 0
   through k inclusive.  The abbreviation "iff" means "if and only if."

   Explanatory notes are provided in several places throughout the
   document; these notes are indented two spaces from the surrounding
   text.

2. Introduction

   The Session Description Protocol (SDP) [SDP] describes multimedia
   sessions, which can be audio, video, whiteboard, fax, modem, and
   other media sessions. streams.  Security services such as data origin
   authentication, integrity and confidentiality are often needed for
   media
   those streams.  The Secure Real-time Transport Protocol (SRTP)
   [srtp] provides such security services for RTP media and is signaled by
   use of the
   "RTP/SAVP" secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an
   SDP media (m=) line.  However, there are no means within SDP itself
   to configure SRTP beyond using default values.  This document
   specifies a new SDP attribute called "crypto", which is used to
   signal and negotiate cryptographic parameters for media streams in
   general, and SRTP in particular.  The definition of the crypto
   attribute in this document is limited to two-party unicast media
   streams where each source has a unique cryptographic key; support
   for multicast media streams or multipoint unicast streams is for
   further study.

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

   It would be self-defeating not to secure cryptographic keys and
   other parameters at least as well as SRTP secures RTP packets or
   IPsec secures IP packets. the data is secured.  Data
   security protocols such as SRTP rely upon a separate key management
   system to securely establish encryption and/or authentication keys.
   Key management protocols provide authenticated key establishment
   (AKE) procedures to authenticate the identity of each endpoint and
   protect against man-
   in-the-middle, man-in-the-middle, reflection/replay, connection
   hijacking and some denial of service attacks [skeme].  Along with
   the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK
   [kink], IKE [ike] 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 defined in this document do not add AKE
   services to SDP.  This specification is no replacement for a key
   management protocol or for the conveyance of key management messages
   in SDP [keymgt].  The SDP security descriptions defined here are
   suitable for restricted cases only where IPsec, TLS, or some other
   encapsulating data-security protocol (e.g. (e.g., SIP secure multiparts)
   protects the SDP message.  This document adds security descriptions
   to those encrypted and/or authenticated SDP messages through the new
   SDP "crypto" attribute, which provides the cryptographic parameters
   of a media stream.

   The "crypto" attribute can be adapted to any media transport, but
   its precise definition is frequently unique to a particular
   transport.

   In Section 3, we introduce the general SDP crypto attribute, and in
   Section 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, and in Section 6 we define SRTP-
   specific SRTP-specific use of the
   attribute with and without the offer/answer model.  Section 7
   recites security considerations, and Section 8 gives an Augmented-BNF Augmented-
   BNF grammar for the general crypto attribute as well as the SRTP-specific SRTP-
   specific use of the crypto attribute.  A list of
   open issues is provided in Section 9 and  IANA considerations are
   provided in Section 10. 9.

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
   preceding unicast media line.  The "crypto" attribute MUST only
   appear at the SDP media level (not the session level).  The "crypto"
   attribute follows the format (see Section 8.1 for a the formal ABNF
   grammar):

     a=crypto:<crypto-suite>

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

   The fields tag, crypto-suite, key-params, and session-param session-params are
   described in the following sub-sections.  Below we show an example
   of the crypto attribute for the "RTP/SAVP" transport, i.e. SRTP i.e., the
   secure RTP extension to the Audio/Video Profile [srtp] (newlines
   included for formatting reasons only):

     a=crypto:AES_CM_128_HMAC_SHA1_80

     a=crypto:1 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 text starting with "inline:", and there session-params is a single session-
   param named "SRC". omitted.

3.1 Crypto-suite Tag

   The crypto-suite field tag is an identifier a decimal number (see Section 8.1 for details) that describes the encryption and authentication algorithms
   (e.g. used as an
   identifier for a particular crypto attribute.  The tag MUST be
   unique among all crypto attributes for a given media stream.  It is
   used with the offer/answer model (see Section 4.1) to determine
   which of several offered crypto attributes were chosen by the
   answerer.

   In the offer/answer model, the tag is a negotiated parameter.

3.2  Crypto-suite

   The crypto-suite field is an identifier (see Section 8.1 for
   details) that describes the encryption and authentication algorithms
   (e.g., AES_CM_128_HMAC_SHA1_80) for the transport in question.  The
   possible values for the crypto-suite parameter are defined within
   the context of the transport, i.e. i.e., each transport defines a
   separate namespace for the set of crypto-suites.  For example, the crypto-
   suite
   crypto-suite "AES_CM_128_HMAC_SHA1_80" defined within the context of the
   "RTP/SAVP" transport applies to Secure RTP only; the string may be
   reused for another transport, however transport (e.g., "RTP/SAVPF" [srtpf]), but a
   separate definition would be needed.

3.2

   In the offer/answer model, the crypto-suite is a negotiated
   parameter.

3.3  Key Parameters

   The key-params field provides one or more sets of keying material
   for the crypto-suite in question.  The field consists of a method
   indicator followed by a colon, and the actual keying information as
   shown below (a (the formal grammar is provided in Section 8.1):

     key-params = <key-method> ":" <key-info>

   Keying material may might be provided by different means. One means than key-
   params, however this is out of the scope of this document.  Only one
   method is defined in this document, namely "inline", which indicates
   that the actual keying material is provided in the key-info field
   itself.  There is a single name space for the key-method, i.e. i.e., the
   key-method is transport independent.  New key-methods (e.g. (e.g., use of
   a URL) may be defined in an IETF Standards Track RFC in the future, in which case they future.
   Although the key-method itself may be used
   with any transport, provided generic, the definitions for that transport
   support use of accompanying key-
   info definition is specific not only to the new key-method. key-method, but also to
   the transport in question.  New key methods MUST be registered with
   the IANA according to the procedures defined in Section 10.2.1. 9.2.1.

   Key-info is here just defined as a general character string (see Section 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 SRTP
   are provided in Section 5.  Note that such definitions are provided
   within the context of both a particular transport (e.g. (e.g., "RTP/SAVP")
   and a specific key-method (e.g. (e.g., "inline").  IANA will register the
   list of supported key methods for each transport.

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

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

3.3 values [srtp].

   In the offer/answer model, the key parameter is a declarative
   parameter.

3.4  Session Parameters

   Session parameters are specific to a given transport and use of them
   is OPTIONAL in 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; RFC; definitions for SRTP are provided
   in Section 5.  Note that such definitions are provided within

   In the context offer/answer model, session parameters may be either
   negotiated or declarative; the definition of specific session
   parameters MUST indicate whether they are negotiated or declarative.
   Negotiated parameters apply to data sent in both directions, whereas
   declarative parameters apply only to media sent by the entity that
   generated the SDP.  Thus, a specific key-method (e.g. "inline") and declarative parameter in an offer
   applies to media sent by the offerer, whereas a particular
   transport (e.g. "RTP/SAVP").

3.4 declarative
   parameter in an answer applies to media sent by the answerer.

3.5  Example

   The first example shows use of the crypto attribute for the RTP/SAVP
   "RTP/SAVP" media transport type (as defined in Section 4).  The a=crypto
   "a=crypto" line is actually one long line, although line; it is shown as two lines in this
   document
   due to page formatting. 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
     a=crypto:1 AES_CM_128_HMAC_SHA1_80
      inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_32
     a=crypto:1 AES_CM_128_HMAC_SHA1_32
      inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
     m=application 32416 udp wb
     a=orient:portrait

   This SDP message describes three media streams, two of which use the
   RTP/SAVP
   "RTP/SAVP" transport.  Each has a crypto attribute for the RTP/SAVP
   "RTP/SAVP" transport.  These RTP/SAVP-specific secure-RTP specific descriptions are
   defined in the Section 5.

4. General Use of the crypto Attribute

   In this section, we describe the general use of the crypto attribute
   outside of any transport or key-method specific rules.

4.1  Use With Offer/Answer

   In this section, we define the

   The general offer/answer rules for use of the crypto attribute with the offer/answer [RFC3264] model.  These rules are in
   addition to the rules specified in RFC 3264, which MUST be followed,
   unless otherwise noted.  RFC 3264 defines operation for both unicast
   and multicast streams; the sections below describe operation for
   two-party unicast streams only, since support for multicast streams
   (and multipoint unicast streams) is for further study.

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 for
   which security is desired.  Each crypto attribute for a given media
   stream MUST contain a unique tag.
   The ordering of multiple "a=crypto" lines is significant:  The most-preferred most
   preferred crypto line is listed first.  Each crypto attribute
   describes the crypto-suite, key(s) and possibly session parameters
   offered for the media stream.  In general, a "more preferred" crypto suite
   crypto-suite SHOULD be stronger cryptographically stronger than a "less
   preferred" crypto suite. crypto-suite.

   The crypto-suite always applies to media in all the directions supported
   by the media stream (e.g. (e.g., send and receive).  The key(s) key(s), however,
   apply to media in the direction from the offerer to the answerer; if
   the media stream is marked as "recvonly", a key MUST still be
   provided.

     This is done for consistency.  Also, in the case of for example SRTP, for
     example, secure RTCP will still be flowing in both the send and
     receive direction for a unidirectional stream.

   The offer may include session parameters.  There are no general offer/answer
   offer rules for the session parameters; instead, specific rules are may
   be provided as part of the transport and
   key-method specific definitions of any
   session parameters.

   When issuing an offer, the offerer MUST be prepared to support media
   security in accordance with any of the crypto attributes included in
   the offer.  There are however two problems associated with this.
   First of all, the offerer does not know which key the answerer will
   be using for media sent to the offerer; the answerer may or may not
   choose the same key as the offerer chose in his sending direction
   (in fact, the answerer SHOULD NOT use the same key as explained in
   Section 4.1.2.1). offerer.  Since media may arrive
   prior to the answer, delay or clipping may can occur.  If this is
   unacceptable to the offerer, the offerer SHOULD use a mechanism
   outside the scope of this document to prevent the above problem.

     For example, in SIP [RFC3261], a "security" precondition [RFC3312] could be as
     defined
     to in [sprecon] could solve the above problem.

   Another problem can occur when the offerer includes multiple crypto
   attributes, since the
   attributes:  The offerer may not be able to deduce which of the
   offered crypto attributes was accepted by the answerer until the
   answer is received, yet media may arrive before the answer.

   If this is unacceptable to the offerer, the offerer either SHOULD
   NOT include multiple crypto attributes in the offer, or a mechanism
   outside the scope of this document SHOULD be used to prevent the
   above problem (e.g. (e.g., a "security" precondition).

4.1.1.2   Multicast Streams

   The rules for multicast streams are similar to those for unicast
   streams, except as noted below:

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

   * The key(s) provided apply to media in all directions supported by
     the media stream, as opposed to just the sending direction.

4.1.2 Generating the Initial Answer

4.1.2.1 - Unicast Streams

   When the answerer receives the initial offer with one or more crypto
   attributes for a given unicast media stream, the answerer MUST
   either accept exactly one of the offered crypto attributes, or the
   offered stream MUST be rejected.

     If the answerer wishes to indicate support for other crypto
     attributes, those can be listed by use of the SDP Simple
     Capability Declaration [RFC3407] extensions.

   Only crypto attributes that are valid, i.e. valid can be accepted; valid
   attributes do not violate any of the general rules defined for
   security descriptions as well as any specific rules defined for the
   transport and key method key-method in question
   can be accepted. question.  When selecting one of the
   valid crypto attributes, the answerer SHOULD select the most
   preferred crypto attribute it can support, i.e. i.e., the first valid
   supported crypto attribute in the list, considering the answerer's
   capabilities and security policies.

   If there is are one or more crypto attributes in the offer, but none of
   them are valid, or none of the valid ones are supported, the offered
   media stream MUST be rejected.

   The

   When an offered crypto attribute is accepted, the crypto attribute
   in the answer MUST contain the following:

   * The tag and crypto-suite from the accepted crypto attribute in the
     offer (the same crypto-suite must MUST be used in the send and receive
     direction).
   * The key(s) the answerer will be using for media sent to the
     offerer.

   There are no general offer/answer rules for  Note that a key MUST be provided, irrespective of any
     direction attributes in the offer or answer.

   Furthermore, any session parameters;
   instead, specific rules parameters that are negotiated MUST be
   included in the answer.  Declarative session parameters provided as part of by
   the transport and
   key-method specific definitions offerer are not included in the answer, however the answerer may
   provide its own set of any declarative session parameters.

   Once the answerer has accepted one of the offered crypto attributes,
   the answerer MAY begin sending media to the offerer in accordance
   with the selected crypto attribute.  Note however, that the offerer
   may not be able to process such media packets correctly until the
   answer has been received.

4.1.2.2   Multicast Streams

   The rules for multicast streams are similar to those for unicast
   streams, except as noted below:

   * The crypto-suite in the answer MUST be the same as the one in the
     offer (unless the offered media stream is rejected).  Since no
     more than one crypto attribute can be offered for a multicast
     stream, this is satisfied trivially.

   * The key(s) provided apply to media in all directions supported by
     the media stream, as opposed to just the sending direction.
     Consequently, the key(s) in the answer MUST be the same as the
     key(s) in the offer.

4.1.3 Offerer Processing of the Initial Answer

4.1.3.1 - Unicast Streams

   When the offerer receives the answer, the offerer MUST verify, that
   exactly
   one of the initially offered crypto attributes suites and its accompanying tag
   was accepted.
   Otherwise, the offerer MUST consider the offer/answer negotiation to
   have failed for that stream.

   The key(s) included accepted and echoed in the answer are answer.  Also, the key(s) that answer MUST
   include one or more keys, which will be used for media sent from the
   answerer to the offerer and hence offerer.

   If the offer contained any mandatory negotiated session parameters
   (see section 5.3.6), the offerer MUST use those key(s) to process media received; verify that said parameters
   are included in the key(s)
   might not be answer. If the same as the key(s) used by answer contains any mandatory
   declarative session parameters, the offerer for sending
   media MUST be able to the answerer.

   There are no general offer/answer rules for the session parameters;
   instead, specific rules are provided as part of the transport and
   key-method specific definitions of support
   those.

   If any session parameters.

4.1.3.2   Multicast Streams

   When the offerer receives the answer, the offerer MUST verify, that
   the offered crypto attribute and key(s) were accepted and echoed in
   the answer.  Otherwise, of the offerer MUST consider above fails, the offer/answer negotiation MUST be deemed to have failed for that stream for *that answerer* and
   hence the answerer is not considered a participant in that media
   stream.  If there are other participants in the multimedia session,
   the session may continue unaffected by this particular answerer's
   failure.

   There are no general offer/answer rules for the session parameters;
   instead, specific rules are provided as part of the transport and
   key-method specific definitions of any session parameters.
   failed.

4.1.4 Modifying the Session

   Once a media stream has been established, it MAY be modified at any
   time, as described in RFC 3264, Section 8.  Such a modification MAY
   be triggered by the security service, e.g. e.g., in order to perform a re-
   keying
   re-keying or change the crypto-suite.  If media stream security
   using the general security descriptions defined here is still
   desired, the crypto attribute MUST be included in these new
   offer/answer exchanges.  The procedures are similar to those defined
   in Section 4.1.1, 4.1.2, 4.1.3 of this document, subject to the
   considerations provided in RFC 3264 Section 8.

4.2  Use Outside Offer/Answer: Advertising Offer/Answer

   The crypto attribute can also be used outside the context of
   offer/answer.  For example, when using the Session Announcement
   Protocol (SAP) [RFC2974],
   offer/answer where there is no negotiation of the media
   streams described by the SDP; instead media streams are simply
   advertised.

   The crypto attribute defined here can be used in such environments
   where suite,
   cryptographic key or session parameters.  In this case, the crypto sender
   determines security parameters are advertised in a single message
   rather than being negotiated in a roundtrip (an offer and an
   answer), albeit with certain restrictions:

   * There for the stream.  Since there is no
   negotiation mechanisms, the sender MUST be include exactly one crypto attribute.

   There are no general rules for the session parameters; instead,
   specific rules for advertising session parameters are provided as
   part of the transport
   attribute and key-method specific definitions of any
   session parameters.

4.3  General Backwards Compatibility Considerations
   It is possible that the answerer supports receiver MUST either accept it or else SHOULD NOT
   receive the associated stream.  The sender SHOULD select the
   security description that it deems most secure for its purposes.

4.3  General Backwards Compatibility Considerations

   In the offer/answer model, it is possible that the answerer supports
   a given secure transport (e.g., "RTP/SAVP") and accepts the offered
   media stream, yet the answerer does not support the crypto attribute
   defined here. in this document and hence ignores it.  The offerer can
   recognize this situation by seeing an accepted 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.

   Similar issues exist when security descriptions are used outside of
   the offer/answer model.

5. SRTP Security Descriptions

   In this section, we provide definitions for security descriptions
   for SRTP media streams.  In the next Section, section, we define how to use
   SRTP security descriptions with and without the offer/answer model.

   SRTP security descriptions for a media stream MUST only be used for
   media streams that use the "RTP/SAVP" SRTP transport (e.g., "RTP/SAVP" or
   "RTP/SAVPF") in the media (m=) line and SHALL apply to that media
   stream only.  The following specifies rules for the "RTP/SAVP"
   profile defined in [srtp], however it is expected that other secure
   RTP profiles (e.g., "RTP/SAVPF") can use the same rules.

   There is no assurance that an endpoint is capable of configuring its
   SRTP service with a particular crypto attribute parameter, but SRTP
   guarantees minimal interoperability among SRTP endpoints through the
   default SRTP parameters [srtp].  More capable SRTP endpoints support
   a variety of parameter values beyond the SRTP defaults and these
   values can be configured by the SRTP security descriptions defined
   here.  An endpoint that does not support the crypto attribute will
   ignore it (per [SDPnew]) and hence, if it supports SRTP, it according to the SDP.  Hence the endpoint will simply
   assume use of default SRTP parameters. parameters, if it supports SRTP.  Such an
   endpoint will not correctly process the particular media stream.  By
   using the Offer/Answer model, the offerer and answerer can negotiate
   the crypto parameters to be used before commencement of the
   multimedia session (see Section 6.1).

   There are over twenty cryptographic parameters listed in the SRTP
   specification.  Many of these parameters have fixed values for
   particular cryptographic transforms.  At the time of session
   establishment, moreover, there is usually no need to provide unique
   settings for many of the SRTP parameters, such 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
   of SRTP parameter values for the security session.  This approach is
   followed by the SRTP security descriptions, which uses the general
   security description parameters as follows:

     * crypto-suite:     Identifies the encryption and authentication
                         transforms
     * key parameter:    SRTP keying material and parameters
     * session parameters:    The following parameters are defined:
          - SRC:    An <SSRC, ROC, SEQ> triple
          - KDR:    The SRTP Key Derivation Rate is the rate that a
                    pseudo-random function is applied  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 of forward error correction (FEC)
                         relative to SRTP services
          - WSH:         Window Size Hint
          - Extensions:  Extension parameters can be defined

   Please refer to the SRTP specification for a complete list of
   parameters and their descriptions [Section 8.2, srtp].  The key
   parameter, the crypto-suite, and the session parameters shown above
   are described in detail in the following sections.

5.1.1.1 subsections.

5.1  SRTP Key Parameter

   SRTP security descriptions define use of the "inline" key method as
   described in the following.  Use of any other keying method method, e.g.,
   URL, for SRTP security descriptions is for further study.

   The "inline" type of key contains the keying material (master key
   and salt) and all policy
   relating related to that master key, including how
   long it can be used (lifetime) and whether or not it uses a master
   key 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. (e.g., after the master key lifetime has
   expired).

   The key parameter contains a semi-colon separated list of one or more cryptographic master keys,
   each of which MUST be a unique cryptographically random [RFC1750]
   value with respect to other master keys in the entire SDP message (i.e.
   (i.e., including master keys for other streams).  Each key in the list follows
   the format (a (the formal definition is provided in Section 8.2):

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

     key||salt      concatenated master key and salt, base64 encoded
                    (see [RFC3548], Section 3)
     lifetime       master key lifetime (number (max number of packets) SRTP or SRTCP
                    packets using this master key)
     MKI:length     MKI and length of the MKI field in SRTP packets. packets
     FromTo         <"From", "To"> values, specifying the lifetime for
                    a master key. key
   The following definition provides an example for
   AES_CM_128_HMAC_SHA1_80:

     inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4

   The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the
   parameter is the cryptographic master key appended with the master
   salt; the two are first concatenated and then base64 encoded.  The
   length of the concatenated key and salt is determined by the crypto-
   suite for which the key applies.  If the length (after being decoded
   from base64) does not match that specified for the crypto-suite, the
   entire
   crypto attribute in question MUST be considered invalid and an "invalid
   key/salt" condition SHOULD be logged. invalid.  Each
   master key and salt MUST be a cryptographically random number and
   MUST be unique to the entire SDP message.  When base64 decoding the
   key and salt, padding characters (i.e., one or two "=" at the end of
   the base64 encoded data) are discarded (see [RFC3548] for details).
   Base64 encoding assumes that the base64 encoding input is an
   integral number of octets.  If a given crypto-suite requires the use
   of a concatenated key and salt with a length that is not an integral
   number of octets, said crypto-suite MUST define a padding scheme
   that results in the base64 input being an integral number of octets.
   For example, if the length defined was 250 bits, then 6 padding bits
   would be needed, which could be defined to be the last 6 bits in a
   256 bit input.

   The second field, is the OPTIONAL lifetime of the master key as
   measured in maximum total number of SRTP or SRTCP packets using that key.
   master key (i.e., the number of SRTP packets and the number of SRTCP
   packets each have to be less than the lifetime).  The lifetime value
   MAY be written as a non-zero, positive integer or as a power of 2
   (see the grammar in Section 8.2 for details).  The "lifetime" value
   MUST NOT exceed the maximum packet lifetime for the crypto-suite.
   If the lifetime is too large or otherwise invalid then the entire
   crypto attribute MUST be considered invalid and an
   "invalid lifetime" condition SHOULD be logged. invalid.  The default MAY be
   implicitly signaled by omitting the lifetime value (i.e. (i.e., "||").
   This is convenient when the SRTP cryptographic key lifetime is the
   default value.  As a shortcut to avoid long decimal values, the
   syntax of the lifetime allows using the literal "2^", which
   indicates "two to the power of".  The example above, shows a case
   where the lifetime is specified as 2^20.  The following example,
   which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default
   for the lifetime field, which means the that SRTP's and SRTCP's default
   values will be used (2^31):

     inline: YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4 (see [srtp]):

     inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4

   The example shows a 30-character key and concatenated salt that is
   base64 encoded:  The 30-character key/salt concatenation is expanded
   to 40 characters by the three-in-four encoding of base64.

   The third field, which is also OPTIONAL, is either the Master Key
   Identifier (MKI) and its byte length, or a <"From", "To"> value.

   "MKI" is the master key identifier associated with the SRTP master
   key.  If the MKI is given, then the length of the MKI MUST also be
   given and separated from the MKI by a colon (":").  The MKI length
   is the size of the MKI field in the SRTP packet, specified in bytes.
   If the MKI length is not given or if it its value exceeds 128 (bytes),
   then the entire crypto attribute MUST be considered invalid and an
   "invalid MKI length" condition SHOULD be logged. invalid.  The
   substring "1:4" in the first example assigns to the key a master key
   identifier of 1 that is 4 bytes long, and the second example assigns
   a 4-byte master key identifier of 1066 to the key.

   <"From", "To"> specifies the lifetime for a master key, expressed in
   terms of the ROC and SEQ values inside whose range (including the
   range end-points) ends) the master key is valid.  <"From", "To"> is an
   alternative to the MKI and assumes that a master key is in one-to-
   one correspondence with the SRTP session key on which the <"From",
   "To"> range is defined. defined (see [srtp, Section 8.1.1] for details).  The
   following example illustrates the use of the <"From", "To">
   parameter:

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

   As mentioned above, the key parameter can contain one or more master
   keys.  When the key parameter contains more than one master key, all
   of the master keys in that key parameter MUST either include an MKI
   or a <"From", "To"> value.  Note that it is not permissible to mix and match use of
   the two within a single key parameter (i.e., one crypto attribute);
   all master keys in a given key parameter must use one or the other. other
   (or neither).  Furthermore, when using the MKI, the MKI length MUST
   be the same for all keys in a given crypto attribute.

5.2  Crypto-suites

   The SRTP crypto-suites define the encryption and authentication
   transforms to be used for the SRTP media stream.  The SRTP
   specification has defined three crypto-suites, which below are described
   further in the following subsections in the context of the SRTP
   security descriptions.  The table below provides an overview of the
   crypto-suites and their parameters:

   +---------------------+-------------+--------------+---------------+
   |                     |AES_CM_128_  | AES_CM_128_  | F8_128_       |
   |                     |HMAC_SHA1_80 | HMAC_SHA1_32 |  HMAC_SHA1_80 |
   +---------------------+-------------+--------------+---------------+
   | Master key length   |   128 bits  |   128 bits   |   128 bits    |
   | Salt value          |   112 bits  |   112 bits   |   112 bits    |
   | Default lifetime    | 2^31 packets| 2^31 packets | 2^31 packets  |
   | Cipher              | AES Counter | AES Counter  |    F8         |
   |                     | Mode        | Mode         |               |
   | Encryption key      |   128 bits  |   128 bits   |   128 bits    |
   | MAC                 |  HMAC-SHA1  |  HMAC-SHA1   |  HMAC-SHA1    |
   | Authentication tag  |    80 bits  |    32 bits   |    80 bits    |
   | SRTP auth. key      |   160 bits  |   160 bits   |   160 bits    |
   | SRTCP auth. key     |   160 bits  |   160 bits   |   160 bits    |
   +---------------------+-------------+--------------+---------------+

5.2.1     AES_CM_128_HMAC_SHA1_80

   AES_CM_128_HMAC_SHA1_80 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 a default lifetime
   of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes
   first [srtp].  The [Page 39, srtp].

     Technically, SRTP and SRTCP encryption key lengths are 128
   bits.  The allows 2^48 SRTP and packets or 2^31 SRTCP authentication packets,
     whichever comes first.  SRTP security descriptions, however,
     simplify the parameters to share a single upper bound of 2^31
     packets.  It is RECOMMENDED that automated key lengths are 160 management allow
     easy and efficient rekeying at intervals far smaller than 2^31
     packets given today's media rates or even HDTV media rates.

   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 session salt value is 112 bits in length.  The
   pseudo-random function (PRF) is the default SRTP pseudo-random
   function that uses AES Counter Mode with a 128-bit key length.

   The length of the base64 decoded key and salt value for this crypto-
   suite MUST be 30 characters, i.e. i.e., 240 bits; otherwise the crypto
   attribute is considered invalid.

5.2.2 AES_CM_128_HMAC_SHA1_32

   This crypto suite crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except
   that the SRTP authentication key tag is 32 bits and the SRTCP
   authentication key is 80 bits.

   The length of the base64-decoded key and salt value for this crypto-
   suite MUST be 30 characters, i.e. i.e., 240 bits; otherwise the crypto
   attribute is considered invalid.

5.2.3 F8_128_HMAC_SHA1_80

   This crypto suite crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the
   cipher is F8 [srtp].

   The length of the base64 decoded key and salt value for this crypto-
   suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto
   attribute is considered invalid.

5.2.4 Adding new Crypto-suite Definitions

   If new transforms are added to SRTP, new definitions for those
   transforms SHOULD be given for the SRTP security descriptions and
   published in an IETF RFC.  Sections 5.2.1 through 5.2.3 illustrate
   how to define crypto-suite values for particular cryptographic
   transforms.  Any new crypto suites crypto-suites MUST be registered with IANA
   following the guidelines procedures in section 10. 9.

5.3 Session Parameters

   SRTP security descriptions define a set of "session" parameters,
   which OPTIONALLY may be used to override SRTP session defaults for
   the SRTP and SRTCP streams.  These parameters configure an RTP
   session for SRTP services and are described in the following.

5.3.1     SRC=SSRC/ROC/SEQ services. The SRTP cryptographic context for a given SRTP session is
   identified by the synchronization source (SSRC).  Furthermore,
   associated with a cryptographic context is parameters provide session-
   specific information to establish the SRTP packet index
   which is derived from the RTP sequence number (SEQ) and a rollover
   counter (ROC).  The SSRC and SEQ are included in cryptographic context.

5.3.1     KDR=n

   KDR specifies the SRTP packets,
   however they are not included Key Derivation Rate, as described in standard SDP (for various reasons). section 4.3.1
   of [srtp].

   The ROC is neither included value n MUST be an integer in the SRTP packets nor standard SDP but
   is instead derived algorithmically based on the total number of
   packets sent.  This presents set {1,2,...,24}, which
   denotes a couple power of challenges:

   * If the master 2 from 2^1 to 2^24, inclusive.  The SRTP key is shared between two or more
   derivation rate controls how frequently a new session
     participants, SSRC collisions MUST be avoided; SSRC collision
     detection and resolution key is not derived
   from an acceptable alternative as this
     can lead to the two-time pad problem SRTP master key [srtp].

   * If a participant joins an ongoing session (where  When the ROC key derivation rate is non-
     zero), the participant needs to learn the ROC somehow.

   * If not
   specified (i.e., the KDR parameter is omitted), a single initial sequence number key
   derivation is close to performed [srtp].

   In the maximum sequence
     number offer/answer model, KDR is a declarative parameter.

5.3.2     UNENCRYPTED_SRTCP and the initial UNENCRYPTED_SRTP

   SRTP packets and SRTCP packet payloads are lost, the 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 master key is used encrypted by all
     participants, the ROC for each still needs to be learned somehow. default.  The SRC
   UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameter provides information to establish parameters modify the SRTP
   cryptographic context.  It contains information about one or more
   default behavior of the following:

   * SSRC:     Synchronization source crypto-suites with which they are used:

   * ROC:      Roll-over counter UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not
     encrypted.

   * SEQ:      Sequence number

   The ROC and sequence number UNENCRYPTED_SRTP signals that the SRTP packet payloads are typically only needed for sessions
   already in progress (as when rekeying or when joining a multicast
   session).

   Zero or more SRC not
     encrypted.

   In the offer/answer model, these parameters MAY appear in a 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 are negotiated.

5.3.3     UNAUTHENTICATED_SRTP

   SRTP
   crypto context (see section 3.2 of [srtp]) that SHALL share the
   master key and salt defined SRTCP packet payloads are authenticated by one or more inline key parameters. default.  The total number of all packets
   UNAUTHENTICATED_SRTP session parameter signals that SRTP messages
   are encrypted by keys derived
   from this master key MUST NOT exceed the lifetime not authenticated.  Use of the inline key. UNAUTHENTICATED_SRTP is NOT
   RECOMMENDED (see Security Considerations).

     The SRTP crypto contexts so defined SHALL also have a common
   definition specification requires use of message authentication for
     SRTCP, but not for SRTP [srtp].

   In the crypto-suite and all other crypto parameters.

   SSRC is the RTP SSRC that is associated with the crypto context, and offer/answer model, this parameter is an integer in negotiated.

5.3.4     FEC_ORDER=order

   FEC_ORDER signals the range use of 0..2^32-1.  If an SSRC value is
   invalid, the entire crypto attribute line MUST be considered invalid
   and an "invalid SSRC" condition SHOULD be logged.  If an SSRC value
   collides with an SSRC forward error correction for an existing participant in the session,
   the 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 RTP collision detection and resolution, which we don't want to.

   ROC
   packets [rfc2733].  The forward error correction values for "order"
   are FEC_SRTP, SRTP_FEC, or SPLIT [mikey].  FEC_SRTP signals that FEC
   is the applied before SRTP rollover counter (ROC) in processing by the range sender of 0..2^32-1 and
   is zero by default.  Typically the ROC value is specified as a non-
   zero value for an ongoing SRTP stream in which media
   and after SRTP processing by the ROC has cycled
   one or more times [srtp].  The receiver of the SDP message SHOULD
   refresh SRTP media;
   FEC_SRTP is the ROC value before joining an ongoing session.  Depending
   on default.  SRTP_FEC is the nature of reverse processing.  SPLIT
   signals that the session control, sender performs SRTP encryption, followed by FEC
   processing, followed by SRTP authentication; processing is reversed
   on the late-joining receiver
   might need to refresh its ROC value through a unicast exchange or
   through receipt of a multicast or unicast message containing receiver.

   In the offer/answer model, FEC_ORDER is a ROC declarative parameter.

5.3.5     Window Size Hint (WSH)

   SRTP description.  If defines the ROC SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to
   protect against replay attacks.  The minimum value is greater than 2^32-1, then the
   entire crypto attribute line MUST 64 [srtp],
   however this value may be considered invalid and an
   "invalid ROC" condition SHOULD 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 logged.

   SEQ is the SRTP sequence to work satisfactorily (e.g., based on
   sender knowledge of number (SEQ), which MUST of packets per second).  However, there
   might be enough information given in the range of
   0..2^16-1.  SRTP uses the RTP sequence number SDP attributes like
   "a=maxprate" and the ROC bandwidth modifiers to allow a receiver to compute
   derive the packet index [srtp].  For parameter satisfactorily.  Consequently, this reason, the initial SEQ SHOULD be
   in the range of 0..2^15-1 value is
   only considered a hint to avoid an ambiguity when packets are
   lost at the start receiver of the session.  At SDP which MAY choose
   to ignore the start of a session, an
   SSRC source that randomly selects a high sequence-number value can
   put provided.

   In the receiver offer/answer model, WSH is a declarative parameter.

5.3.6     Defining New SRTP Session Parameters

   New SRTP session parameters for the SRTP security descriptions can
   be defined in an ambiguous situation:  If initial packets are
   lost in transit up IETF RFC and registered with IANA according to the point
   registration procedures defined in Section 9.

   New SRTP session parameters are by default mandatory.  A newly-
   defined SRTP session parameter that is prefixed with the sequence number wraps
   (exceeds 2^16-1), then the receiver might dash
   character ("-") however is considered optional and MAY be ignored.
   If an SDP crypto attribute is received with an unknown session
   parameter that is not recognize prefixed with a "-" character, that its ROC
   needs to crypto
   attribute MUST be incremented.  By restricting the initial SEQ considered invalid.

5.4  SRTP Crypto Context Initialization

   In addition to the
   range of 0..2^15-1, various SRTP packet-index determination will find the
   correct ROC value, unless all parameters defined above, there are
   three pieces of the first 2^15 packets information that are lost
   (which seems, if not impossible, then rather unlikely).  See Section
   3.3.1 critical to the operation of
   the default SRTP specification regarding packet-index determination
   [srtp].

   It ciphers:

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

   In a unicast session, as defined here, there are three constraints
   on these values.

   The first constraint is not necessary to signal SEQ and ROC at the start of on the SSRC, which makes an SRTP
   session if keystream
   be unique from other participants.  As explained in SRTP, the receivers do not join
   keystream MUST NOT be reused on two or more different pieces of
   plaintext.  Keystream reuse makes the session late, which ciphertext vulnerable.  One
   vulnerability is
   typical that known-plaintext fields in IP telephony, multimedia client/server, and similar
   applications.  Large-scale multicast applications, however, will
   sometimes have late joiners to one stream can
   expose portions of the session reused keystream and MAY choose to this could further
   expose more plaintext in other streams.  Since all current SRTP
   encryption transforms use keystreams, key sharing is a general
   problem [srtp].  SRTP mitigates this problem by including the
   SRC session parameter to set the SEQ and the ROC.  The SSRC MAY also
   be initialized
   of the sender in the SRC parameter; keystream.  But SRTP does not solve this can
   problem in its entirety because Real-time Transport Protocol has
   SSRC collisions, which are very rare [rtp], but quite possible.
   During a collision, two or more SSRCs that share a master key will
   have identical keystreams for example be useful
   to establish the crypto contexts (in particular overlapping portions of the ROC) RTP
   sequence-number space.  SRTP Security Descriptions avoids keystream
   reuse by making unique master keys REQUIRED for all the
   session participants.

   Like SEQ sender and ROC, SSRC is OPTIONAL (unless there are multiple SRC
   parameters in which case it is mandatory) and often need not be
   signaled.  If
   receiver of the master key security description.  Thus, the first constraint is not shared among senders for their
   encryption services, then
   satisfied.

     Also note, that there is a second problem with SSRC collisions:
     The SSRC uniqueness is NOT REQUIRED (see
   Section 7.2) used to identify the crypto context and thereby the
     cipher, key, ROC, etc. to process incoming packets.  In case of
     SSRC need collisions, crypto context identification becomes ambiguous
     and correct packet processing may not be signaled.  In this way, each
   master key occur.  Furthermore, if an
     RTCP BYE packet is used for encryption by exactly one sender and used to be sent for
   decryption by one or more receivers: a colliding SSRC, that packet
     may also have to be secured.  In a (unicast) point-to-multipoint
     scenario, this case, there is no risk
   of keystream reuse can be problematic for the crypto-suite ciphers same reasons, i.e., it
     is not known which of Section 5.2.1,
   5.2.2, and 5.2.3.

   The SRTP the possible crypto context can be established for contexts to use.  Note
     that these problems are not unique to the SDP security
     descriptions; any use of SRTP session
   address in the connection (c=) line and needs to consider them.

   The second constraint is that the port in ROC MUST be zero at the media (m=)
   line (or rtpmap) without having specified an time that
   each SSRC value commences sending packets.  Thus, there is no concept of a
   "late joiner" in the SRTP security descriptions. This is called "late binding" by this
   specification.  If late binding is used, then when descriptions, which are constrained
   to be unicast and pairwise.  The ROC and SEQ form a packet arrives, "packet index"
   in the SSRC that default SRTP transforms and the ROC is contained in it can be bound consistently set to the crypto context
   zero at the time of session commencement rather than at the time commencement, according to this document.

   The third constraint is that the initial value of
   session signaling.  With SEQ SHOULD be
   chosen to be within the arrival range of 0..2^15-1; this avoids an ambiguity
   when packets are lost at the packet containing start of the
   SSRC, all session.  If at the data items (except start
   of a session, an SSRC source might randomly select a high sequence-
   number value and put the receiver in an ambiguous situation:  If
   initial packets are lost in transit up to the point that the
   sequence number wraps (i.e., exceeds 2^16-1), then the receiver
   might not recognize that its ROC if it is non-zero) needed
   for needs to be incremented.  By
   restricting the initial SEQ to the range of 0..2^15-1, SRTP crypto context packet-
   index determination will find the correct ROC value, unless all of
   the first 2^15 packets are held by lost (which seems, if not impossible,
   then rather unlikely).  See Section 3.3.1 of the receiver.  In other
   words, SRTP specification
   regarding packet-index determination [srtp].

   The packet index, therefore, depends on the crypto context for SSRC, the SEQ of an RTP/SAVP session using late binding
   is initially identified by
   incoming packet and the SDP as:

          <*, address, port>

   where '*' ROC, which is an SRTP crypto context
   variable.  Thus, SRTP has a wildcard SSRC, "address" is from big security dependency on SSRC
   uniqueness.  This fact might lead one to consider establishing the "c=" line, and
   "port" is
   SSRC by an entity that keeps these values from the "m=" line.  When the first packet arrives colliding.  One
   problem with
   ssrcX in its this approach, however, is that the SSRC field, belongs to the crypto context

          <ssrcX, address, port>

   is instantiated subject
   transport (RTP or SRTP) and not to the following constraints:

   * Media packets are authenticated:  Authentication MUST succeed;
     otherwise, signaling.  It would be an
   imposition on RTP and SRTP to require that the SSRC be read and
   written by an external system such as SDP.

   Given the above constraints, unicast SRTP crypto contexts can be
   established without the need to negotiate SSRC values in the SRTP
   security descriptions.  Instead, an approach called "late binding"
   is RECOMMENDED by this specification.  When a packet arrives, the
   SSRC that is contained in it can be bound to the crypto context at
   the time of session commencement (i.e., SRTP packet arrival) rather
   than at the time of session signaling (i.e., receipt of an SDP).
   With the arrival of the packet containing the SSRC, all the data
   items needed for the SRTP crypto context are held by the receiver
   (note that the ROC value by definition is zero; if non-zero values
   were to be supported, additional signaling would be required).  In
   other words, the crypto context for a secure RTP session using late
   binding is initially identified by the SDP as:

          <*, address, port>

   where '*' is a wildcard SSRC, "address" is the local receive address
   from the "c=" line, and "port" is the local receive port 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

     Note that only authenticated SRTP is use of late binding without authentication results in
     local state being used.

5.3.2     KDR=n

   KDR specifies the Key Derivation Rate, created 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 result of 2 from 2^0 to 2^24, inclusive.  The SRTP key
   derivation rate controls how frequently receiving a new session key is derived packet from an SRTP master key [srtp].  The default value
     any unknown SSRC.  UNAUTHENTICATED_SRTP, therefore is 0, which
   causes NOT
     RECOMMENDED because it invites easy denial-of-service attack.  In
     contrast, late binding with authentication does not suffer from
     this weakness.

   With the key derivation function to be invoked exactly once (since
   2^0 constraints and procedures described above, it is 1).

5.3.3     UNENCRYPTED_SRTCP not
   necessary to explicitly signal the SSRC, ROC and UNENCRYPTED_SRTP SEQ for a unicast
   SRTP and SRTCP packet payloads are encrypted by default. session.

5.5  Removal of Crypto Contexts

   The
   UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify mechanism defined above addresses the
   default behavior issue of the crypto-suites with which they are used:

   * UNENCRYPTED_SRTCP signals 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 the SRTCP packet payloads are can not
     encrypted.

   * UNENCRYPTED_SRTP signals automatically be recovered
   (e.g., ROC), it is important that the SRTP packet payloads are not
     encrypted.

5.3.4     UNAUTHENTICATED_SRTP

   SRTP sender and SRTCP packet payloads are authenticated by default.  The
   UNAUTHENTICATED_SRTP session parameter signals that SRTP messages
   are not authenticated.  Use of UNAUTHENTICATED_SRTP receiver agree on
   when a crypto context can be removed, and perhaps more importantly
   when it cannot.

     Even when late binding 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 used for a unicast stream, 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 ROC is SSRC specific,
     lost 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 cannot be recovered automatically (unless it MUST reject is zero)
     once the media stream.  Only "a=crypto" lines that are
   considered valid crypto context is removed.

   We resolve this problem as follows.  When SRTP security descriptions as defined in Section 5
   can be accepted.  Furthermore, all parameters (crypto-suite, key
   parameter, and session parameters)
   are being used, crypto contexts removal MUST be acceptable to follow the
   answerer in order for same rules
   as SSRC removal from the offered media stream to be accepted.

   When member table [RFC 3550]; note that this can
   happen as the answerer accepts result of an "RTP/SAVP" unicast media stream with SRTCP BYE packet or a simple time-out due
   to inactivity.  Inactive session participants that wish to ensure
   their crypto line, the answerer indicates acceptance by including its own
   "a=crypto" line in the answer.  The answer crypto line contexts are not timed out MUST include thus send SRTCP packets
   at least the selected SRTP crypto-suite and one or more master keys
   appropriate for regular intervals.

6. SRTP-Specific Use of the selected crypto algorithm; the master key(s)
   included in the answer SHOULD be different from those in Attribute

   Section 4 describes general use of the offer.

     If crypto attribute, and this
   section completes it by describing SRTP-specific use.

6.1  Use with Offer/Answer

   In this section, we describe how the master key(s) SRTP security descriptions are not shared between
   used with the offerer offer/answer model to negotiate cryptographic
   capabilities 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 communicate SRTP master keys.  The rules defined
   below complement the answer are independent of session
   parameters included general offer/answer rules defined in the offer.  Use of extension SRTP session
   parameters SHOULD Section
   4.1, which MUST be avoided followed, unless it is known that the offerer
   supports these.

   If the answerer cannot find any valid crypto line otherwise specified.  Note 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 rules below define unicast operation only; support for multicast
   and multipoint unicast streams is able to
   successfully negotiate use of "RTP/SAVP" by other means outside for further study.

6.1.1     Generating the
   scope of this document (e.g., by use of MIKEY [mikey]).

6.1.2.2   Multicast Initial Offer - Unicast Streams

   When the initial answer offer is generated, the answerer offerer MUST follow the
   steps in Section 4.1.2.2 4.1.1 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 unicast 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 (m=) using the answer.  In particular, we may want secure RTP transport
   where the offerer wants to allow for
     inclusion of specify cryptographic parameters, the SRC parameter,
   offerer MUST provide at least one valid SRTP security description
   ("a=crypto" line), as this would enable a new-comer
     to instantiate crypto-contexts for other participants defined 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 Section 5.

   The offerer MAY include one or an
     entirely different mechanism).

   If the answerer cannot find any valid crypto line more other SRTP session parameters as
   defined in Section 5.3.  Note however, that it supports,
   or its configured policy prohibits if any cryptographic key parameter
   (e.g. key length) or cryptographic SRTP 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
   parameters are included 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 known 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 answerer, but are avoided.  Examples of how this can be achieved
   include a centralized controller supplying unique SSRCs to
   nonetheless mandatory (see Section 5.3.6), the
   session participants or a separate protocol that can ensure SSRC
   uniqueness prior to sending any SRTP packets.

6.1.3     Offerer Processing of negotiation will fail
   if the answerer does not support them.

6.1.2     Generating the Initial Answer

6.1.3.1 - Unicast Streams

   When the offerer receives initial answer is generated, the answer, it answerer MUST perform follow the
   steps in Section 4.1.3.1 4.1.2 as well as the following steps for steps.

   For each "RTP/SAVP" unicast media stream it offered with line which uses the secure RTP transport and
   contains one or more "a=crypto" lines in the offer, the answerer
   MUST either accept one (and only 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 it.

   If Section 5 can be accepted.  Furthermore, all parameters
   (crypto-suite, key parameter, and mandatory session parameters) MUST
   be acceptable to the answerer in order for the offered media stream was accepted and it contains
   to be accepted.

   When the answerer accepts an SRTP unicast media stream with a crypto
   line, it the answerer MUST be checked that include one or more master keys appropriate
   for the selected crypto line is valid according to algorithm; the
   constraints specified master key(s) included in Section 5.

   If the crypto line contains any SRTP session parameters, those
   parameters define SRTP behavior for media sent
   answer MUST be different from those in the answerer to offer.

     When the offerer.  If master key(s) are not shared between the offerer either does and
     answerer, SSRC collisions between the offerer and answerer will
     not support or is lead to keystream reuse, and hence SSRC collisions do not
   willing
     necessarily have to honor one or more of the SRTP be prevented.

   Declarative session parameters in may be added to the
   answer, answer as usual,
   however the offerer MUST consider answerer SHOULD NOT add any mandatory session parameter
   (see Section 5.3.6) that might be unknown to the crypto line invalid. offerer.

   If the answerer cannot find any valid crypto line is not valid, that it supports,
   or the offerer's if its configured policy prohibits any cryptographic key
   parameter (e.g. (e.g., key length) or cryptographic session parameter, the SRTP security negotiation parameter
   (e.g., KDR, FEC_ORDER), it MUST
   be deemed reject the media stream, unless it
   is able to have failed.

6.1.3.2   Multicast successfully negotiate use of SRTP by other means outside
   the scope of this document (e.g., by use of MIKEY [mikey]).

6.1.3     Offerer Processing of the Initial Answer - Unicast Streams

   When the offerer receives the answer, it MUST perform the steps in
   Section 4.1.3.2 4.1.3 as well as the following steps for each "RTP/SAVP" SRTP media
   stream it offered with a one or more crypto line 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 offerer either does not support or is not willing to honor
   one or more of the SRTP parameters in the answer, the offerer MUST
   consider 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. 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 for that particular answerer. failed.

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, security descriptions has been
   established, and a separate mechanism, such as [GDOI], will
   be needed for this.  These methods are beyond new offer/answer exchange is performed, the scope of this
   document.

     OPEN ISSUE:  As noted
   offerer and answerer MUST follow the steps in Section 6.1.2.2, it is not clear that we
     couldn't do that with 4.1.4 as well
   as the SRC parameter. following steps.

   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.
     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. 5.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, 4.1.1, this could for example be addressed by defining
     using a security "precondition" [RFC3312] [sprecon].

   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
     a=crypto:1 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
     a=crypto:2 F8_128_HMAC_SHA1_80
      inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
      inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2: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
     a=crypto:1 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 Offer/Answer

   These are the context of
   offer/answer same as described in Section 4.2.  In those cases,

6.3 Support for SIP Forking

   As mentioned earlier, the
   general rules security descriptions defined here do not
   support multicast media streams or multipoint unicast streams.
   However, in Section 4.2 as well as the SRTP-specific
   rule defined below MUST be followed:

   * If any SIP protocol, it is possible to receive several
   answers to a single offer due to the use of forking (see [SIP]).
   Receiving multiple answers leads to a couple of problems for the
   SRTP session parameters security descriptions:

   * Different answerers may choose different ciphers, keys, etc.,
     however there is no way for the offerer to associate a particular
     incoming media packet with a particular answer.

   * Two or more answerers may pick the same SSRC and hence the SSRC
     collision problems mentioned earlier may arise.

   As stated earlier, the above point-to-multipoint cases are outside
   the scope of the SDP security descriptions. However, there is a way
   of supporting SIP forking: Change the multipoint scenario resulting
   from SIP forking into multiple two-party unicast cases.  This is
   done as follows:

   For each answer received beyond the initial answer, issue a new
   offer to that particular answerer using a new receive transport
   address (IP address and port); note that this requires support for
   the SIP UPDATE method [RFC 3313].  Also, to ensure that two media
   sessions are included, they MUST be
     supported by not inadvertently established prior to the recipient UPDATE being
   processed by one of them, use security preconditions [sprecon].

   Finally, note that all the SDP; otherwise, answerers will know the recipient
     MUST NOT join key(s) being
   proposed by the SRTP session.

6.3 initial offer.  If the offerer wants to ensure
   security with respect to other answerers, a new offer/answer
   exchange with a new key needs to be performed with the first
   answerer as well.

6.4  SRTP-Specific Backwards Compatibility Considerations

   It is possible that the answerer supports the "RTP/SAVP" SRTP 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" SRTP 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 a given SRTP transport set to "RTP/SAVP" (e.g.,
   "RTP/SAVP") is sent to a device that does not support "RTP/SAVP", SRTP, that
   media stream will be rejected.

6.4

6.5  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 that 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]. [SDP].  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.
   (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, mechanisms (e.g., secure multiparts) or
   alternatively utilize a lower-layer security service (e.g. (e.g., TLS, IPSEC). or
   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

   SRTP 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. direction.  This specification
   restricts use of SDP security description to unicast point-to-point
   streams so that keys are not shared between
   multiple media streams, SRTP hosts, and the
   master 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, MIME secure multiparts, 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 message.  Failure to encrypt the SDP message
   containing an inline SRTP master key renders the SRTP authentication
   or encryption service useless in practically all circumstances.
   Failure to authenticate an SDP message that carries SRTP parameters
   renders the SRTP authentication or encryption service useless in
   most practical applications.

   When the communication path of the SDP message is routed through
   intermediate systems that inspect parts of the SDP message, security
   protocols such as IPsec or TLS SHOULD NOT be used for encrypting
   and/or authenticating the security description.  In the case of
   intermediate-system processing of a message containing SDP security
   descriptions, the "a=crypto" attributes SHOULD be protected end-to-
   end so that the intermediate system can neither modify the security
   description nor access the keying material.  Network or transport
   security protocols that terminate at each intermediate system,
   therefore, SHOULD NOT be used for protecting SDP security
   descriptions.  A security protocol SHOULD allow the security
   descriptions to be encrypted and authenticated end-to-end
   independently of the portions of the SDP message containing an inline SRTP master
   key renders the SRTP authentication that any
   intermediate system modifies or encryption service useless in
   practically all circumstances.  Failure to authenticate an inspects:  MIME secure multiparts
   are RECOMMENDED for the protection of SDP
   message messages that carries SRTP parameters renders the SRTP authentication
   or encryption service useless in most practical applications. are
   processed by intermediate systems.

   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 encryption of the key management protocol data
   independently of the SDP message that carries it.  The security of
   the SDP SRTP attribute, however, is not secured end-to-end (such as good as the above example
   where a third-party provider maintains data security
   protocol that protects the SDP message.  For example, if an IPSec
   security associations
   with association exists between the endpoints for SDP source and destination
   endpoints, then this solution is more secure than use of the key-
   mgmt statement in an unauthenticated SDP message). message, which is
   vulnerable to tampering.

8. Grammar

   In this section we first provide the ABNF grammar for the generic
   crypto attribute, and then we provide the ABNF grammar for the SRTP
   specific use of the crypto attribute.

8.1 Generic "Crypto" Attribute Grammar

   The ABNF grammar for the crypto attribute is defined below:

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

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

   key-params       = key-param *(";" key-params) key-param)
   key-param        = key-method ":" key-info
   key-method       = "inline" | / key-method-ext
   key-method-ext   = 1*(ALPHA / DIGIT / "_")
   key-info         = %x21-3A / %x3B-7E %x3C-7E ; visible (printing) characters
                                        ; except semi-colon
   session-param    = VCHAR 1*(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 5.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.
     roc  = 1*DIGIT                 ; range 0..2^32-1
     seq  = 1*DIGIT                 ; range 0..2^16-1

     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 this document:

   * The use of security descriptions, and in particular SRTP security
     descriptions, with multicast streams where offer/answer is being
     used 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 a key to be specified as
     being an encryption or decryption key or both; instead this       = "WSH=" 2*DIGIT    ; minimum value is
     inferred from the context (e.g. unicast offer).  Should there be a
     mechanism to allow a key to 64
     base64    =  ALPHA / DIGIT / "+" / "/" / "="

     srtp-crypto-suite-ext  = 1*(ALPHA / DIGIT / "_")
     srtp-session-extension = ["-"] 1*(VCHAR)  ;visible chars [RFC2234]
                              ; first character must not be tagged as an encryption, decryption
     or both key ?

10. dash ("-")

9. IANA Considerations

10.1

9.1 Registration of the "crypto" attribute

   The IANA is hereby requested to register a new SDP attribute as
   follows:

   Attribute name:      crypto
   Long form name:      Security description cryptographic attribute
                        for media streams
   Type of attribute:   Media-level
   Subject to charset:  No
   Purpose:             Security descriptions
   Appropriate values:  See Section 3

10.2

9.2 New IANA Registries and Registration Procedures

   The following sub-sections define several a new IANA registries registry with
   associated sub-registries to be used for the SDP security
   descriptions.  It  The IANA is suggested that hereby requested to create an SDP
   Security Description registry as shown below and further described
   in the following registry structure be used for these: sections:

   SDP Security Descriptions
     |
     +- Key Methods (described in 10.2.1) 9.2.1)
     |
     +- Media Stream Transports (described in 9.2.2)
          |
          +- SRTP Transport1 (e.g. SRTP)
          |    |
          |    +- Supported Key Methods (e.g. inline)
          |    |
          |    +- SRTP crypto suites (described in Section 10.2.2)
          |    |
          |    +- SRTP session parameters (described
          |
          +- Transport2
          :    :

9.2.1Security Descriptions Key Method Registry and Registration

   The IANA is hereby requested to create a new subregistry for SDP
   security description key methods.  An IANA key method registration
   MUST be documented in an IETF Standards Track RFC and it MUST
   provide the name of the key method in accordance with the grammar
   for key-method-ext defined in Section 10.2.3)

10.2.1    Security Descriptions 8.1.

9.2.2Security Description Media Stream Transport Registry and
     Registration

   The IANA is hereby requested to create a new subregistry for SDP
   security description Media Stream Transports.  An IANA media stream
   transport registration MUST be documented in an RFC in accordance
   with the procedures defined in Section 3 and 4 of this document.
   The registration MUST provide the name of the transport and a list
   of supported key methods.

   In addition, each new media stream transport registry must contain a
   crypto-suite registry and a session parameter registry as well as
   IANA instructions for how to populate these registries.

9.3 Initial Registrations

9.3.1     Key Method Registry and Registration

   The following security descriptions key methods are hereby
   registered:

     inline

9.3.2     SRTP Media Stream Transport

   The IANA is hereby requested to create a new registry an SDP Security Description
   Media Stream Transport subregistry for "SRTP".  The key methods
   supported is "inline".  The reference for the SDP security
   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 grammar for key-method-ext
   defined in Section 8.1.

10.2.2 SRTP is this document.

9.3.2.1   SRTP Crypto Suite Registry and Registration

   The IANA is hereby requested to create a new registry subregistry for SRTP
   crypto suites. suites under the SRTP transport of the SDP Security
   Descriptions. An IANA SRTP crypto suite registration MUST indicate
   the crypto suite name in accordance with the grammar for srtp-crypto-
   suite-ext srtp-
   crypto-suite-ext defined in Section 8.2.

   The semantics of the SRTP crypto suite MUST be described in an IETF
   RFC, including the semantics of the "inline" key-method and any
   special semantics of parameters.

10.2.3

   The following SRTP crypto suites are hereby registered:

     AES_CM_128_HMAC_SHA1_80
     AES_CM_128_HMAC_SHA1_32
     F8_128_HMAC_SHA1_80

   The reference for these crypto-suites is provided in this document.

9.3.2.2   SRTP Session Parameter Registration

   The IANA is hereby requested to create a new registry subregistry for SRTP
   session parameters. parameters under the SRTP transport of the SDP Security
   Descriptions.  An IANA SRTP session parameter registration MUST
   indicate the session parameter name (srtp-session-extension as
   defined in Section 8.2); the name MUST NOT begin with the dash
   character ("-").

   The semantics of the parameter MUST be described in an IETF RFC.  If
   values can be assigned to the parameter, then the format and
   possible values that can be assigned MUST be described in the IETF
   RFC as 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  Also, it MUST be specified whether the parameter is
   declarative or negotiated in the offer/answer model.

   The following SRTP session parameters are hereby registered:

     SRC
     KDR
     UNENCRYPTED_SRTP
     UNENCRYPTED_SRTCP
     UNAUTHENTICATED_SRTP
     FEC_ORDER
     WSH
   The ABNF reference for all of the above these parameters is already included in the ABNF
   section of this document.

11.

10. Acknowledgements

   This document is a product of the IETF MMUSIC working group and has
   benefited from comments from its participants.  This document also
   benefited from discussions with Elisabetta Cararra, Earl Carter,
   Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David
   McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer,
   Mike Thomas, Elisabetta Cararra, Brian Weis, Dave Oran, Bill Foster, Earl
   Carter, Matt Hammer and Dave Singer. Magnus Westerlund.  These people shared
   observations, identified errors and made suggestions for improving
   the specification.  Magnus provided many useful comments and 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 requiring unique master keys
   for each unicast SDP media stream as followed in this document.
   Paul Kyzivat suggested how to handle SIP forking.  Jonathan
   Rosenberg suggested reducing the complexity by specifying only one
   security parameter for each media stream.

12.

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

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

13.

12. Normative References

   [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
   "RTP: A Transport Protocol for Real-Time Applications", 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]

   [SDP] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description
   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.

   [RFC3264] 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.

   [srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K.
   Norrman, D. Oran, "The Secure Real-time Transport Protocol", Work in
   Progress.

   [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
   Recommendations for Security", RFC 1750, December 1994,
   http://www.ietf.org/rfc/rfc1750.txt.

14.

   [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data
   Encodings", RFC 3548, July 2003.

13. Informative References

   [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
   Capability Declaration", RFC 3407, October 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", Work in Progress.

   [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
   "MIKEY: Multimedia Internet KEYing", 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 .
   http://www.ietf.org/rfc/rfc2974.txt.

   [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
   RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.

   [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
   A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
   Session Initiation Protocol", RFC 3261, June 2002.

   [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security
   Preconditions for Session Description Protocol Media Streams", work
   in progress, February 2004.

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