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

              SDP Security Descriptions for Media Streams
               <draft-ietf-mmusic-sdescriptions-00.txt>
               <draft-ietf-mmusic-sdescriptions-01.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

Abstract

   This Internet Draft gives document defines a cryptographic attribute to Session Description Protocol (SDP)
   cryptographic attribute for media streams.  The attribute describes
   a cryptographic key and other parameters, which serve to configure
   security for a media stream.  This draft also document defines the SRTP Secure Real-
   time Transport Protocol (SRTP) parameters for the attribute.  The
   SDP crypto attribute requires the services of a data security
   protocol to secure the SDP message.

   TABLE OF CONTENTS

1.0

1. Notational Conventions...........................................2
2.0 Introduction.....................................................3
3.0 Conventions............................................2
2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters............................4 Parameters.............................4
 3.1 Crypto-suite....................................................4
 3.2 Application Parameter...........................................4
 3.3 Key Parameter...................................................4
 3.4 Session Parameters..............................................5
 3.5 Examples........................................................5
4.0
4. RTP/SAVP (SRTP) Security Descriptions............................6 Descriptions.............................6
 4.1 Crypto-suites...................................................7
   4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7
   4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7
   4.1.3 F8_128_HMAC_SHA1_80.........................................7
   4.1.4 F8_128_HMAC_SHA1_32.........................................7
   4.1.5 Adding new CRYPTO-SUITE definitions.........................8
 4.2 Application Parameter...........................................8
 4.3 Key-param Parameter.............................................8
   4.2.1 Key Parameter...................................................8
   4.3.1 Usage...................................................8
   4.2.2 INLINE Usage................................................8
   4.3.2 INLINE Definition...........................................9
 4.4 Definition...........................................8
 4.3 Session Parameters.............................................10
   4.4.1 SSRC=n.....................................................10
   4.4.2 ROC=n......................................................11
   4.4.3
   4.3.1 SRC=/SSRC/ROC/SEQ..........................................10
   4.3.2 KEY_DERIVATION_RATE=n......................................11
   4.4.4 UNENCRYPTED................................................11
   4.4.5 FEC_ORDER=order............................................12
   4.4.6 UNAUTHENTICATED............................................12
5.0
   4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................11
   4.3.4 FEC_ORDER=order............................................11
   4.3.5 UNAUTHENTICATED_SRTP.......................................12
5. Use with Offer/Answer...........................................12 Offer/Answer............................................12
 5.1 Offerer Processing.............................................12 Generating the Offer...........................................12
 5.2 Answerer Processing............................................13
 5.3 Processing............................................12
 5.4 Non-RTP/SAVP Answerers.........................................13 Answerers.........................................14
 5.4 Offer/Answer Example: Receiver Supports SRTP...................14
 5.5 Offer/Answer Example: Different SRTP and SRTCP keys............14
 5.6
 5.7 Use of a=crypto With Active Media Streams......................15
6.0
 5.8 Operation with KEYMGT and Key lines............................15
6. Security Considerations.........................................16 Considerations..........................................15
 6.1 Authentication of packets......................................16
 6.1 Reuse of Keying Material ("Two-Time Pad")......................16 Key-stream Reuse...............................................16
 6.2 Signaling Authentication and Signaling Encryption..............17
7.0 Grammar.........................................................18
8.0 Acknowledgements................................................19
9.0
7. SRTP "Crypto" Attribute Grammar..................................18
8. Open Issues......................................................19
9. Acknowledgements.................................................19
10. Authors' Addresses..............................................20
10.0 References.....................................................20
11.0 Full Copyright Statement.......................................21

1.0 Addresses..............................................19
11. Normative References............................................20
Intellectual Property Statement.....................................21
Acknowledgement.....................................................22

1. Notational Conventions

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

2.0

Andreasen, Baugher & Wing                                     [Page 2] 

2. Introduction

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

   Thus, the SDP crypto attribute provides both generic and specific
   security descriptions for SDP media streams that can be used for
   various transports, including SRTP.  In this way, the

   The crypto attribute can might be extended to non-SRTP transports such
   as white
   board, whiteboard, modem, fax, and other transports that could use
   various security protocols such as IPsec or TLS.  These extensions,
   however, are beyond the scope of this document.  Each type of SDP
   media stream,
   however, stream needs its own definitions that assign values to crypto-
   attribute its
   crypto-attribute parameters.  These definitions are unique to the
   particular SDP transport and SHOULD be specified in an Internet RFC.
   This document defines the parameter values for SRTP.  With this document, an
   application developer can describe an SRTP key and its configuration
   according to application-specific needs.

   It would be self-defeating, however, to self-defeating not to secure cryptographic keys and
   other parameters at least as well as SRTP secures RTP
   messages packets or
   IPsec secures IP packets.  Data security protocols such as SRTP rely
   upon a separate key management system to securely establish
   encryption and/or authentication keys.  Key management protocols
   provide authenticated key establishment (AKE) procedures to
   authenticate the identity of each endpoint and protect against
   man-in-the-middle, man-
   in-the-middle, reflection/replay, connection hijacking and some
   denial of service attacks [skeme].  Along with the key, an AKE
   protocol such as MIKEY, GDOI, KINK, IKE or TLS securely disseminates
   information describing both the key and the data-security session
   (for example, whether SRTCP is 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 information.

   SDP

   SDP, however, was not designed to provide AKE services, and the
   media security descriptions that follow do not add AKE services to
   SDP.  This specification is no replacement for a key management
   protocol or for the conveyance of key management messages in SDP
   [keymgt].  The SDP
   media-stream security descriptions are suitable for restricted
   cases where IPsec, TLS, or some other encapsulating data-security
   protocol (e.g. SIP secure multiparts) protects the SDP message.
   This draft adds security descriptions to those encrypted and/or
   authenticated SDP messages through a new
   SDP attribute named "crypto", the "crypto" attribute, which

Andreasen, Baugher & Wing                                     [Page 3] 
   provides the cryptographic parameters of a media stream. The crypto "
   crypto" attribute MAY contain a
   cryptographic key and other parameters that describe the key.
   a=crypto MAY also contain "security session parameters" that are
   unique to a transport.

   The a=crypto parameter is applicable to all media transports, but
   its value MAY be unique to could be adapted to any media transport, but its
   definition is unique to a particular transport.  In Section 3
   specifies 3, we
   introduce the SDP crypto attribute generically. attribute, and in Section 4 defines 4, we define the
   crypto attribute details needed for SRTP.  In Section 5 discusses 5, we specify
   how to use of the crypto attribute in for SRTP streams with the
   Offer/Answer exchanges. model [RFC3264].  Section 6 recites security
   considerations, and Section 7 gives an Augmented-BNF grammar for the
   SRTP security descriptions.

3.0 descriptions provided for the crypto attribute.  A
   list of open issues is provided in Section 8.

3. SDP "Crypto" Attribute and Parameters

   A new media-level SDP attribute called "crypto" describes the
   cryptographic suite, key parameters, and security-session session parameters for one or more the
   proceeding media
   entries.  "a=crypto" line.  The "crypto" attribute MUST NOT only appear at
   the SDP media level (not the session level.

          a=crypto:<crypto-suite> <application> <key> [<session>] level).  The "crypto" attribute
   is defined by the following ABNF [RFC2234]:

     "a=crypto:" crypto-suite SP key-param *(SP session-param)

   where "SP" is the space character (see [RFC2234]); the fields
   crypto-suite, key-param, and session-param are described in Section
   3.1, 3.2, and 3.3.

   The ordering of multiple a=crypto "a=crypto" lines is significant, and the
   most-preferred significant:  The most-
   preferred crypto line is listed first; see section 5. The next sections
   describes these 5 for details. We
   now describe the crypto fields in more detail.

3.1 Crypto-suite

   "Crypto-suite"

   The crypto-suite field describes all needed information about the
   encryption and authentication algorithms for the RTP/SAVP transport.
   The "crypto-suite" ABNF grammar for crypto-suite is:

     crypto-suite = VCHAR

   where VCHAR is defined in [RFC2234]. The possible values for the
   crypto-suite parameter is unique to the transport.

3.2 Application Parameter

   A particular transport can have multiple protocols that are secured
   differently.  For example, when using the RTP/SAVP transport, both
   the SRTP and SRTCP protocols will be used, but the security for each
   MAY be different: A longer authentication output tag might be
   desired for the SRTCP control protocol than for the SRTP media
   stream. The "application" parameter allows separate security
   descriptions for separate protocols of a transport.

3.3 Key Parameter

   The key parameter can key-param field  MUST either contain an inline key descriptor,
   or can it MUST be a pointer to a uri which contains the actual key:

      inline:key-descriptor
      uri:absolute-uri key. The
   ABNF grammar for key-param is:

     key-param           = inline-key / uri-key
     inline-key          = "inline:" key-descriptor
     key-descriptor      = VCHAR
     uri-key             = "uri:" absolute-uri
     absolute-uri        = VCHAR

Andreasen, Baugher & Wing                                     [Page 4] 
   where VCHAR is defined in [RFC2234].

   If the key parameter starts with the string "uri:", the URI method
   is used and the value that follows is MUST be a Uniform Resource
   Identifier. The URI is a resource that SHOULD be queried to obtain
   the cryptographic key for the session.  The format or protocols used
   for the uri are beyond the scope of this document.

   The INLINE method document, however it is invoked when the key parameter
   RECOMMENDED that such protocols provide both integrity and
   confidentiality.

   The INLINE method is invoked when the key parameter starts with the
   string "inline:"  - and "inline:"; the cryptographic key is encoded according to a
   transport-specific syntax. syntax subject to the general format provided
   above.  Thus, the URI method is transport generic and the INLINE
   method is transport specific.  Section 4 describes the INLINE key-parameter key-
   parameter syntax for RTP/SAVP, the RTP/SAVP (the SRTP media transport type.

   If SDP descriptions for new media-stream transports are defined in
   the future, new methods MAY be defined in an Internet RFC. type).

3.4 Session Parameters

   "Session"

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

     session-param  = VCHAR

   where VCHAR is defined in [RFC2234]. Section 4 describes the session
   parameters for RTP/SAVP.

3.5 Examples Example

   The first example shows a=crypto use of the crypto attribute for the RTP/SAVP
   media transport type (as defined in Section 4).  The a=crypto line
   is actually one long line, although it is shown as two lines in this
   document due to page formatting.

     v=0
     o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
     s=SDP Seminar
     i=A Seminar on the session description protocol
     u=http://www.example.com/seminars/sdp.pdf
     e=j.doe@example.com (Jane Doe)
     c=IN IP4 224.2.17.12/127 161.44.17.12/127
     t=2873397496 2873404696
     a=recvonly
     m=video 51372 RTP/SAVP 31
     a=crypto:AES_CM_128_HMAC_SHA1_80 both
       inline:16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32
      inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_32 srtp
       inline:16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32
     a=crypto:AES_CM_128_HMAC_SHA1_80 srtcp
       inline:16/14/ ZkBkQythOTg3NjU0MSEzMDMyMT01NDg5N2RlRkF/2^20/1:32
      inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32
     m=application 32416 udp wb
     a=orient:portrait

Andreasen, Baugher & Wing                                     [Page 5] 
   This SDP message describes three "recvonly" media streams, two of which use the
   RTP/SAVP transport.  The first a=crypto line appears
   in the m=video media entry; it is associated with the RTP/SAVP
   transport of the m=video line and uses the SRTP default crypto-
   suite, "AES_CM_128_HMAC_SHA1_80," and its key parameter carries the
   SRTP master key data and descriptors inline. The m=video a=crypto
   attribute applies to both SRTP and SRTCP.  The m=audio media entry
   uses the "crypto-suite=AES_CM_128_HMAC_SHA1_32," having  Each has a short 32-
   bit tag for SRTP, and it uses AES_CM_128_HMAC_SHA1_80 crypto attribute for SRTCP.
   The the RTP/SAVP
   transport.  These RTP/SAVP-specific descriptions are defined in the
   next section.

4.0

4. RTP/SAVP (SRTP) Security Descriptions

   The generic

   SRTP security descriptions of the preceding section need
   parameter values for specific media transports; this section defines
   the crypto attribute values and parameters for the RTP/SAVP (SRTP)
   transport.  SRTP services for a media stream MUST only be signaled
   through used for
   media streams that use the presence of an RTP/SAVP transport descriptor in the m= media (m=) line
   and SHALL apply only to that media entry. stream only.

   There is no assurance that a receiver an endpoint is capable of configuring its
   SRTP service with a particular crypto attribute parameter, but SRTP
   guarantees minimal interoperability among SRTP systems endpoints through the
   default SRTP parameters [srtp].  More capable SRTP receivers endpoints support
   a variety of parameter values beyond the SRTP defaults and these
   values can be configured by the crypto attribute.  A receiver attribute defined in this
   document.  An endpoint that does not
   recognize a=crypto support the crypto attribute
   will ignore it (per [SDPnew]) and assumes hence, if it supports SRTP, it
   will simply assume use of default SRTP parameters might receive
   a stream that uses non-default parameters, which parameters.  Such an endpoint
   will cause that
   receiver to fail.  An Offer/Answer capabilities exchange, however,
   allows sender not correctly process the particular media stream.  By using
   the Offer/Answer model, the offerer and receiver to agree on answerer can negotiate the
   crypto parameters to be used before commencement of the multimedia
   session (see Section 5.0).

   There are over twenty cryptographic parameters listed in the SRTP
   specification.  Many of these parameters have fixed values for
   particular cryptographic transforms.  At the time of session
   establishment, however, there is usually no need to provide unique
   settings for many of the SRTP parameters. parameters, such as salt length and
   pseudo-random function (PRF).  Thus, it is possible to simplify the
   list of parameters in by defining "cryptographic suites" that fix a set
   of SRTP parameter values for the security session.  The list of
   SRTP parameters, including the crypto-suite parameter for SDP
   a=crypto follows.

     SDP

     SRTP Crypto Parameter    Description
     ------------------
     ---------------------    -----------
     CRYPTO-SUITE             Encryption and authentication transforms
     SSRC                     SSRC of the sender of the SDP message
     ROC                      Roll-over counter
     INLINE                   SRTP and associated parameters
     SRC                      An <SSRC, ROC, SEQ> triple
     KEY_DERIVATION_RATE      Rate that the pseudo-random function
                                is applied to a master key
     UNENCRYPTED              Protocol
     UNENCRYPTED_SRTP         SRTP messages are not encrypted
     UNENCRYPTED_SRTCP        SRTCP messages are not encrypted
     UNAUTHENTICATED
     UNAUTHENTICATED_SRTP     SRTP messages are not authenticated
     FEC_ORDER                Order of forward error correction (FEC)
                                relative to SRTP services

         Table 4-1: SRTP Crypto-suite, Key and Session Parameters

Andreasen, Baugher & Wing                                     [Page 6] 
   Please refer to the SRTP specification for a complete list of
   parameters and their descriptions [Section 8.2, srtp].  The CRYPTO-
   SUITE
   SUITE, the key parameter, and the five session parameters shown in the
   table above are described in the following sections. If a receiver
   cannot recognize a parameter or value, then the receiver MUST NOT
   participate in the media stream and SHOULD log an "invalid name"
   condition unless the receiver is participating in an Offer/Answer
   exchange (Section 5).

4.1 Crypto-suites

   A crypto-suite value appears as the first parameter in a=crypto. The
   CRYPTO-SUITE value MAY be different for SRTP and SRTCP as described
   in Section 4.2. a crypto
   attribute.  If a receiver does not support the particular
   crypto-suite, crypto-
   suite, then the receiver MUST NOT participate in the media stream
   and SHOULD log an "unrecognized crypto-suite" condition unless the
   receiver is participating in an Offer/Answer exchange (Section 5).
   RTP/SAVP has four three crypto-suites as described below.

4.1.1 AES_CM_128_HMAC_SHA1_80

   This is the SRTP default AES Counter Mode cipher and HMAC-SHA1
   message authentication having a an 80-bit authentication tag.  The
   encryption
   master-key length is 128 bits and authentication has a lifetime of a maximum of
   2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first
   [srtp].  The SRTP and SRTCP encryption key lengths are 128 bits.
   The SRTP and SRTCP authentication key lengths are 160 bits (see
   Security Considerations).  The master salt value is 112 bits and the
   session salt value is 112 bits.  The PRF is the default SRTP pseudo-random pseudo-
   random function that uses AES Counter Mode with a 128-bit key
   length.

4.1.2 AES_CM_128_HMAC_SHA1_32

   The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message
   authentication having an a 32-bit authentication tag for SRTP packets;
   SRTCP uses an 80-bit tag.  The encryption master-key length is 128 bits and authentication has
   a lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets,
   whichever comes first [srtp].  The SRTP and SRTCP encryption key
   lengths are 128 bits.  The SRTP and SRTCP authentication key lengths
   are 160 bits (see Security Considerations).  The master salt value
   is 112 bits and the session salt value is 112 bits.  These values
   apply to SRTP and to SRTCP.  The PRF is the
   default SRTP pseudo-
   random pseudo-random function that uses AES Counter Mode with
   a 128-bit key length.

4.1.3 F8_128_HMAC_SHA1_80

   The SRTP f8 cipher is used with HMAC-SHA1 message authentication
   having a 80-bit authentication tag.  The encryption master-key length is 128
   bits and
   authentication has a lifetime of a maximum of 2^48 SRTP packets or 2^31
   SRTCP packets, whichever comes first [srtp].  The SRTP and SRTCP
   encryption key lengths are 128 bits.  The SRTP and SRTCP

Andreasen, Baugher & Wing                                     [Page 7] 
   authentication key lengths are 160 bits (see Security
   Considerations).  The master salt value is 112 bits and the session
   salt value is 112 bits.  The PRF is the default SRTP pseudo-random
   function that uses AES Counter Mode with a 128-bit key length.

4.1.4 F8_128_HMAC_SHA1_32

   The SRTP f8 cipher is used with HMAC-SHA1 message authentication
   having a 32-bit authentication tag.  The encryption and
   authentication key lengths are 128 bits.  The master salt value is
   112 bits and the session salt value is 112 bits.  The PRF is the
   default SRTP pseudo-random function that uses AES Counter Mode with
   a 128-bit key length.

4.1.5 Adding new CRYPTO-SUITE definitions

   If new transforms are added to SRTP, new definitions for those
   transforms SHOULD be given for the SDP crypto attribute and
   published in an Internet RFC. Sections 4.1.1 through 4.1.4 4.1.3
   illustrate how to define CRYPTO-SUITE values for particular
   cryptographic transforms.  New definitions MAY be added to existing
   transforms, moreover, to augment or modify definitions 4.1.1 through
   4.1.4.

4.2 Application Parameter

   The "application" parameter indicates
   4.1.3.  For example, if this a=crypto line applies
   to only secure RTP, only secure RTCP, or to both secure RTP and
   RTCP.  The values for this are "srtp", "srtcp", or "both".  If AES_CM_128_HMAC_SHA1_80 were desired that
   used a
   receiver finds an "srtp" a=crypto without 160-bit master key, then a corresponding "srtcp"
   a=crypto, or vice versa, it new crypto-suite MUST NOT participate in be defined
   having a new name that is identical to AES_CM_128_HMAC_SHA1_80 but
   with the media stream
   and SHOULD log an "missing crypto attribute" condition.

4.3 Key size of the master key defined to be 160 bits instead of
   128 bits.

4.2 Key-param Parameter

   If the "key" key-param parameter has a "uri:" descriptor, the value is a
   Uniform Resource Identifier value as described in Section 3.  When
   key-parameter
   the key-param parameter has an "inline:" descriptor, the value
   contains a cryptographic master key that MUST be a unique
   cryptographically random [RFC1750] value with respect to other
   "inline:" values in the SDP message.

4.3.1 INLINE

4.2.1 Key Usage

   The "inline:" descriptor is applicable to SDP media-entries having a
   "recvonly," "sendonly" or "sendrecv" direction attribute.  In
   general, the source "inline" type of data will generate the master key to protect
   its data, but this is a matter of local policy and application
   preference.  Multicast applications, for example, often will use a
   third-party provider of a master key.  Thus, when contains the inline key is
   used, keying material and all policy
   relating to that key, including how it SHOULD can be used for a recvonly media-entry (for encryption,
   decryption, or for the
   received stream of sendrecv media-entry.  The inline key MAY both encryption and decryption), how long it can be
   used
   for a sendonly media-entry or for streams that are sent (lifetime) and received
   on whether or not it uses a sendrecv media-entry.  The following paragraphs add detail to
   these inline-key recommendations for recvonly, sendonly, and
   sendrecv media entries.

   In the recvonly case, the inline SRTP master key SHOULD be used to
   derive keys [SRTP] index
   (master key index or MKI) to decrypt/authenticate associate an incoming SRTP messages.
   When the a=crypto "application" parameter is set to "both," the
   receiver also derives keys from packet with
   a master key.  Compliant implementations obey the same policies
   associated with a master key to
   decrypt/authenticate key, and MUST NOT accept incoming SRTCP messages.  When packets
   that receiver
   sends RTP Receiver Reports for violate the incoming SRTP stream, it SHOULD
   derive keys from policy (e.g. after the same master key to encrypt/authenticate
   outgoing SRTCP messages lifetime has expired,
   for that SRTP stream.

   In the sendonly case, the inline SRTP master key SHOULD be used to
   derive keys [SRTP] to encrypt and authenticate outgoing SRTP
   messages.  When example).

4.2.2 INLINE Definition

   If the a=crypto "application" parameter identifier is set to
   "both," "inline", the sender also derives keys from key-param descriptor has the same SRTP master
   format described in Section 7 (Grammar) and contains the following
   fields:

     use            key use indicator
     key_length     key length
     salt_length    salt length
     key||salt      concatenated key
   to encrypt and authenticate outgoing SRTCP message.  When that
   sender sends RTP Sender Reports for salt, BASE64-encoded
     lifetime       key lifetime (number of packets)

Andreasen, Baugher & Wing                                     [Page 8] 
     MKI:length     MKI and length of the outgoing MKI field in SRTP stream, it
   SHOULD derive keys packets.

   The "use" indicator defines usage as one of three values which are
   all provided from the same master key to encrypt/authenticate
   outgoing SRTCP messages for perspective of the outgoing SRTP stream.

   In recipient of the sendrecv case, SDP: "d"
   means the inline SRTP master key SHOULD be is used as
   in for decryption only, "e" means the recvonly case described above but MAY also be key is used as in
   for encryption only, and "b" means the
   sendonly case.

4.3.2 INLINE Definition key is used for both
   encryption and decryption.  If the identifier is "inline", crypto suite uses the key-descriptor same key
   for both encryption and decryption, "b" MUST have the
   following format.

      key_length/salt_length/BASE64(key||salt)/lifetime/MKI:MKI_length be specified.

   The "key_length" is the integer length of the SRTP master key in
   bytes, and "salt_length" is the integer length of the master salt in
   bytes.  If their sum is less than the  Their sum of MUST be exactly equal to the lengths length of the
   concatenated master key and salt of the crypto suite, then provided in the receiver fourth field.  The
   key_length and salt_length MUST NOT
   participate in the media stream and SHOULD log a "key length too
   short" condition. If their sum is greater than the crypto-suite sum,
   then bytes are truncated from the right (i.e. "little end").  The
   key_length and salt_length MUST appear appear in the "inline" encoding. For
   example,

   inline:16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32  (1)

   has

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

   is a key_length decryption key with a key length of 16 and a salt_length salt length of 14.

   The third fourth part of the "inline" encoding is the cryptographic master
   key appended with the master salt ("||" denotes concatenation). salt.  Each master key and salt MUST be
   a cryptographically random number and MUST be unique to the SDP
   message.  Both are concatenated and then base-64 encoded.  If the
   length of the concatenated keys key and salt (after being decoded from
   base 64) does not equal or exceed the sum of the key_length and
   salt_length, salt_length
   indicated, the receiver MUST NOT participate in use this crypto attribute line for
   the media stream and SHOULD log a "inline encoding too short"
   condition.  For example,

   inline:16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:32            (2)
   has

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

   describes a decryption key with a key_length of 16, a salt_length of
   8, and a 32-character key and concatenated salt that is base-64
   encoded: The 24-character key/salt concatenation is expanded to 32
   characters by the three-in-
   four three-in-four encoding of base 64.

   The fourth fifth part of the of the "inline" encoding is the OPTIONAL
   lifetime of the master key as measured in number of packets
   encrypted or authenticated with using
   that key.  The lifetime value MAY be written as an non-zero,
   positive integer or as a power of 2, and is
   indicated with "2^"; see the ABNF in Section 7 for
   details. The
   default value is 2^48, which is 2^48 packets encrypted with a master
   key according to the SRTP standard [srtp].  The "lifetime" value MUST NOT exceed the maximum packets packet
   lifetime for the crypto-suite
   (e.g. 2^48 for AES Counter Mode with a 128-bit key). crypto-suite.  If lifetime is too large or
   otherwise invalid, then the receiver MUST NOT
   participate in use this crypto
   attribute line for the media stream and SHOULD log an "invalid
   lifetime" condition.  The default MAY be implicitly signaled by
   having no described value for lifetime (i.e. "//").  This is
   convenient when the srtp crypto_key lifetime is allowed to default.  Trailing
   slashes ("/") MUST follow the master key and lifetime; otherwise,
   the receiver MUST NOT participate in the media stream and SHOULD log
   an "invalid inline encoding" condition.  Example (1),
   The first example, above, shows a case where the lifetime is
   specified as 2^20 while the second example (2) shows an empty lifetime that implicitly uses lifetime,

Andreasen, Baugher & Wing                                     [Page 9] 
   which means the SRTP default value of
   2^48. 2^48 will be used with
   UNENCRYPTED_SRTCP and 2^31 will be used otherwise.

   The MKI value is OPTIONAL as is and its specified bit byte length are OPTIONAL (see Section 7).  "MKI" is
   the master key index associated with the
   srtp_master 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 bits, and MUST be a positive multiple of 8. bytes.  If the
   MKI_length is not given or if the value exceeds 128, then the
   receiver MUST NOT participate in use this crypto attribute line for the media
   stream and SHOULD log an "invalid MKI_length" condition.  If the
   value of the MKI is larger than allowed by MKI_length, then the
   receiver MUST NOT participate
   in use this crypto attribute line for the media
   stream and SHOULD log an "invalid MKI" condition.  The substring "1:32"
   "1:4" in the first example (1) assigns to the key a master key index of
   1 that is 32 bits 4 bytes long, and the second example (2) assigns a 32-bit 4-byte key
   index of 1066 to the key.

4.4

4.3 Session Parameters

   The "session" parameters are OPTIONAL and MAY serve to override SRTP
   session defaults for the SRTP and SRTCP streams.  These parameters
   configure an RTP session for SRTP services.

4.4.1 SSRC=n

4.3.1 SRC=SSRC/ROC/SEQ

   The value n is an integer in SRC session parameter provides information to establish the range of 0..2^32-1 SRTP
   cryptographic context.  The ROC and sequence number are typically
   only needed for the RTP SSRC
   parameter, which is undefined by default. This is the RTP SSRC of
   the sender of the SDP message. If n is invalid, the receiver sessions already in progress (as when rekeying or
   when joining a multicast session).

   Zero or more SRC parameters MAY appear in a crypto attribute.  Each
   SRC parameter defines a separate SRTP crypto context (see section
   3.2 of [srtp]) that SHALL share the master key and salt defined by
   an INLINE parameter.  The total number of all packets that are
   encrypted by keys derived from this master key MUST NOT participate exceed the
   lifetime of the INLINE key.  The SRTP crypto contexts so defined
   SHALL also have a common definition for the crypto-suite and all
   other crypto parameters.

   SSRC is OPTIONAL provided that either a ROC or a SEQ appear in the
   SRC parameter.  SSRC is an integer in the range of 0..2^32-1 for the
   RTP SSRC parameter, which is undefined by default.  This is the RTP
   SSRC that is associated with the inline key. If the SSRC value is
   invalid, the receiver MUST NOT use this crypto attribute line for
   the media stream but SHOULD log an "invalid SSRC" condition.  If
   SSRC MAY be is specified when the setting of the "application"
   parameter and an SRTP packet is "srtp" or "both."  Otherwise received with a different
   SSRC value, the receiver MUST NOT
   participate in SHOULD discard the media stream packet and SHOULD log an "invalid session
   parameter" condition.

4.4.2 ROC=n

   The value "n" error.

   ROC is OPTIONAL provided that either an SSRC or a SEQ appear in the
   SRC parameter.  ROC is an integer in the range of 0..2^32-1 for the

Andreasen, Baugher & Wing                                    [Page 10] 
   SRTP rollover counter (ROC), which is zero by default.  The ROC MAY
   be set to a non-zero value for an ongoing RTP/SAVP stream in which
   the SRTP ROC has cycled one or more times [srtp].  The receiver of
   the SDP message SHOULD refresh the ROC value before joining a session
   "late."  How "late" is defined depends on the rate of the particular
   RTP stream and the time that has elapsed since its commencement. an
   ongoing session.  Depending on the nature of the session control,
   the late-joining receiver might need to refresh its ROC value
   through a unicast exchange or through receipt of a multicast or
   unicast SDP message. message containing a ROC SRTP description. If n ROC is
   invalid,
   greater than 2^32-1, then the receiver MUST NOT participate in use this crypto
   attribute line for the media stream but SHOULD log an "invalid ROC"
   condition.

   ROC MAY be specified when the setting of the "application" parameter

   SEQ is "srtp" OPTIONAL provided that either an SSRC or "both."  Otherwise a ROC appear in the receiver MUST NOT participate
   SRC parameter.  SEQ is an integer in the range of 0..2^16-1 for the
   SRTP sequence number (SEQ).  SRTP uses the RTP sequence number (and
   the ROC) to compute the packet index [srtp].  At the start of a
   session, an SSRC that randomly selects a high sequence-number value
   can put the receiver in an ambiguous situation:  If initial packets
   are lost in transit up to the point that the sequence number wraps
   (exceeds 2^16-1), then the receiver might not recognize that its ROC
   needs to be incremented.  See also section 3.3.1 of [srtp].  If SEQ
   is greater than 2^16-1, then the receiver MUST NOT use this crypto
   attribute line for the media stream and but SHOULD log an "invalid session parameter" SEQ"
   condition.

4.4.3 KEY_DERIVATION_RATE=n

4.3.2 KDR=n

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

   The value n may MUST be an integer in the set {1,2,4,...,2^24}, i.e. {0,1,2,...,24}, which
   denotes a power of 2 between from 2^0 to 2^24, inclusive.  The SRTP key
   derivation rate controls how frequently a new session key is derived
   from an SRTP master key [SRTP].  The default value is 0, which
   causes the key derivation function to be invoked exactly once.

   Key_Derivation_Rate MAY be specified when the "application"
   parameter setting once (since
   2^0 is "srtp" or "both". Otherwise the receiver MUST
   NOT participate in the media stream 1).

4.3.3 UNENCRYPTED_SRTCP and SHOULD log an "invalid
   session parameter" condition.

4.4.4 UNENCRYPTED

   This UNENCRYPTED_SRTP

   UNENCRYPTED_SRTCP indicates that the SRTP or SRTCP stream is packet payloads are not
   encrypted.  UNENCRYPTED_SRTP indicates that the SRTP packet payloads
   are not encrypted.  SRTP and SRTCP messages packet payloads are encrypted by
   default.

   UNENCRYPTED MAY be specified for "srtp", "srtcp", or "both".  If the
   a=crypto "application" setting is "both," then both the SRTP and
   SRTCP streams are unencrypted.

4.4.5

4.3.4 FEC_ORDER=order

   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 on the sender and after SRTP processing on
   the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse
   processing.  SPLIT signals that SRTP encryption occurs on the

Andreasen, Baugher & Wing                                    [Page 11] 
   sender, followed by FEC processing, followed by SRTP authentication;
   processing is reversed on the receiver.  If the receiver cannot
   recognize the order value, then the receiver MUST NOT participate in use this
   crypto attribute line for the media stream but SHOULD log an
   "invalid FEC_ORDER" condition.

   If specified, it MUST only be specified with "srtp" or "both."
   Otherwise the receiver MUST NOT participate in the media stream and
   SHOULD log an "invalid session parameter" condition.

4.4.6 UNAUTHENTICATED

4.3.5 UNAUTHENTICATED_SRTP

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

   If specified, it MUST only be specified

5. Use with "srtp", or "both" since
   it applies only Offer/Answer

   The Offer/Answer model [RFC 3264] enables parties that wish to the SRTP stream: Authentication is mandatory for
   secure RTCP.  If UNAUTHENTICATED appears in an a=crypto with an
   "srtcp" application parameter, the receiver MUST NOT participate
   engage in a multimedia session to negotiate the media stream and SHOULD log an "invalid session parameter"
   condition.

5.0 Use with Offer/Answer

   A receiver that does not recognize a=crypto and assumes default SRTP
   parameters might receive a stream that uses non-default parameters,
   which will cause that receiver to fail.  An Offer/Answer
   capabilities exchange, however, allows sender and receiver to agree
   on parameters before commencement of be used for the multimedia session.  The
   sender and receiver use an Offer/Answer exchange [RFC3264] to match
   cryptographic capabilities.

   This section discusses Offer/Answer exchanges only for the RTP/SAVP
   (SRTP).  A future revision of  In this document will consider
   Offer/Answer exchanges for
   section, we detail how the security descriptions in general. defined for SRTP
   are used with the offer/answer model to negotiate cryptographic
   capabilities and communicate SRTP master keys.

5.1 Offerer Processing

   On Generating the Offer

   For each SDP media line (m=) using the "RTP/SAVP" transport where
   the <transport> is "RTP/SAVP", offerer wants to specify cryptographic parameters, the offerer MAY follow that media line with
   MUST provide at least one a=crypto "a=crypto" line.
   The  When multiple crypto
   lines are provided, the a=crypto lines are specified in preference
   order, with the most preferred listed first.  The offerer determines
   the crypto parameters based on its capabilities and its security
   policies.

   To specify a list of preferred crypto suites for RTP, RTCP, or both,
   the offerer includes separate a=crypto lines, in preference order.
   Each offer is grouped.  If separate rtp and rtcp keys are wanted,
   the srtp a=crypto line MUST be sent first, and both the RTP and RTCP
   keys MUST always be sent, even if the endpoint is recvonly.

   The offerer obtains keying material for "inline", or obtains the uri
   pointing to a
   keyserver by means that are key server.  The mechanism to generate or obtain a key
   is outside the scope of this specification
   (e.g. the offerer could generate the material or request the
   material from a third party). specification.

5.2 Answerer Processing

   For each SDP media line where using the <transport> is RTP/SAVP and "RTP/SAVP" transport that contains
   an "a=crypto" line in the
   stream is bi-directional stream will be created, offer, the answer answerer MUST
   include a media line with its <transport> set to RTP/SAVP in order
   to either accept
   exactly one of the offer; otherwise, the offer is rejected crypto lines for that media
   entry.

   The answerer examines stream, or it MUST
   reject the a=crypto lines, media stream as described in order.  If RFC 3264.  Note that if
   there are no "a=crypto" lines for the a=crypto
   line indicates media stream in the application is rtp, and offer,
   then the answerer MUST skip the line immediately following indicates steps and instead use the application is rtcp,
   default SRTP/SRTCP parameters for that media stream (note that the receiver groups
   these two lines together; otherwise, this group is ignored
   endpoint will then need to somehow obtain the correct master key as it is
   syntactically invalid.  If
   well).  When the a=crypto answerer accepts an "RTP/SAVP" media stream with a
   crypto line, the answerer MUST include exactly one "a=crypto" line indicates
   in the
   application is "both", it is grouped by itself.

   After grouping, answer.  The answer crypto line MUST include at least the
   selected crypto-suite and a key-param parameter.

Andreasen, Baugher & Wing                                    [Page 12] 
   To determine if the answerer can accept any of the provided
   "a=crypto" lines, the answerer examines the crypto lines in order.
   If an "a=crypto" line does not satisfy the constraints provided in
   Section 4, that crypto line is deemed invalid and MUST be discarded.
   The answerer selects the first group of a=crypto valid crypto line that it supports,
   considering the answerer's capabilities and its security policies.  If
   the answerer cannot find any valid crypto line that it supports, or
   its configured policy prohibits any cryptographic key parameter
   (e.g. key length) or cryptographic session parameter (e.g. SSRC,
   ROC, KDR, FEC_ORDER), it MUST reject the media stream, unless it is
   able to successfully negotiate use of "RTP/SAVP" by other means
   outside the scope of this document (e.g. by use of MIKEY [mikey]).

   After selecting one group, a single crypto line, the answerer obtains keys generates a
   master key appropriate for the selected crypto algorithm(s).  The key MUST have algorithm(s), unless
   the same offered master key
   length was specified to apply to both encryption and salt length as
   decryption, in which case the offer.

   To set up offered master key MUST be used
   instead.  If the bi-directional media with <transport> set to RTP/SAVP, offered master key was for decryption, then the
   answerer includes one or two a=crypto lines after the media
   line.  If MUST use it to decrypt any incoming packets; the offer indicated separate keys for RTP and RTCP, key
   provided in the answer MUST do also be marked as being for decryption,
   since the same. answerer will be using it when encrypting it's packets.
   Similarly, if the offered key was for encryption, then the answerer
   MUST use it to encrypt any packets it sends and the key it provides
   in its answer MUST be used to decrypt any incoming packets. The
   master key in the answer MUST have the same key length and salt
   length as the offer.

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

5.3 Offerer Processing of the Answer

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

   If the media stream was accepted and it contains a crypto line, it
   MUST be checked that the media line is valid according to the
   constraints specified in Section 4.  Furthermore, the offerer MUST
   validate, that the crypto-suite selected was one of the offered
   crypto-suites for the media stream.  If any of these checks fails,
   the security negotiation defined here MUST be deemed to have failed.

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

Andreasen, Baugher & Wing                                    [Page 13] 

5.4 Non-RTP/SAVP Answerers

   If a media line stream with <transport> transport set to RTP/SAVP "RTP/SAVP" is sent to a
   device that doesn't suppport RTP/SAVP, support "RTP/SAVP", that media line stream will not be
   processed.

   If an offerer wants
   rejected.

   In some cases, it is desirable to interoperate with such a device, albeit
   without the benefits send SRTP when possible, but allow
   use of RTP if SRTP or SRTCP, the offerer MUST include isn't supported by a remote device.  However, it
   is ambiguous to send an
   additional extra media line with <transport> transport set to RTP/AVP,
   "RTP/AVP" and other
   values in that line MUST match with the values of same port as the associated "RTP/SAVP" media line.  This second  Thus, an
   offerer MUST NOT specify multiple media line would be specified
   after all of the attribute (a=) lines for with the RTP/SAVP same port.

   Instead, such interoperability is obtained by first sending an offer
   with transport set to "RTP/SAVP".  If that media

5.4 Offer/Answer Example: Receiver Supports SRTP

   In this example, line is rejected by
   the answerer, the offerer supports two crypto suites (F8 and
   AES).  When presented can, if its policy permits, send a new
   offer with multiple "a=crypto" lines for an "m="
   line, transport set to "RTP/AVP".  Also, the answerer will chose SDP extensions
   defined in RFC 3407 [RFC3407] can be used by both the first crypto suite that it
   supports, offerer and the
   answerer MUST reply with only one "a=crypto" line
   per "m=" line

   Offerer transmits:
     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 224.2.17.12/127
     t=2873397496 2873404696
     a=recvonly
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80 both
       inline:16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/20/1:32
     a=crypto:F8_128_HMAC_SHA1_80 both
       inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32

   Answerer transmits:
     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 224.2.17.11/128
     t=2873397526 2873405696
     a=sendonly
     m=audio 32640 RTP/SAVP 0
     a=crypto:F8_128_HMAC_SHA1_80 both
       inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32

   In this case, the session would use the F8_128_HMAC_SHA1_80 crypto
   suite to indicate capabilities above and beyond what is being
   negotiated for the RTP and RTCP traffic it generates.

5.5 media stream.  Another offer/answer exchange will
   then be needed to negotiate use of any of these latent capabilities.

5.4 Offer/Answer Example: Different Receiver Supports SRTP and SRTCP keys

   In this example, the offerer requests use of one crypto suite for
   SRTP (AES) and a different Offerer supports two crypto suite for RTCP. 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 transmits: 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 224.2.17.12/127 168.2.17.12
     t=2873397496 2873404696
     a=recvonly
     m=audio 49170 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80 rtp
       inline:16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/20/1:32
      inline:d/16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/2^20/1:32
      FEC_ORDER=FEC_SRTP SRC=17174//49126
     a=crypto:F8_128_HMAC_SHA1_80 rtcp
       inline:16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/20/1:32
      inline:d/16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/2^20/1:32
      FEC_ORDER=FEC_SRTP SRC=17174//49126

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

Andreasen, Baugher & Wing                                    [Page 14] 
     c=IN IP4 224.2.17.11/128 168.2.17.11
     t=2873397526 2873405696
     a=sendonly
     m=audio 32640 RTP/SAVP 0
     a=crypto:AES_CM_128_HMAC_SHA1_80 rtp
       inline:16/14/8NxJiu9zZW1jdGwgKCkgewkyMjA7fQp9CnVubTnC/20/1:32
     a=crypto:F8_128_HMAC_SHA1_80 rtcp
       16/14/c2VtZ2V0KSkgewogICAgc3V/20/1:32

5.6
      inline:d/16/14/PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR/2^20/1:32
      SRC=88131/721/13

   In this case, the session would use the AES_CM_128_HMAC_SHA1_80
   crypto suite for the RTP and RTCP traffic.  The answerer is also
   specifying both its initial SSRC (88131), rollover counter (721),
   and rollover counter (13).

5.7 Use of a=crypto With Active Media Streams

   When an active SRTP session is rekeyed, this is indicated by sending
   a new SDP.  Rekey MUST NOT be  Rekeying is done with an Offer/Answer exchange,
   but rather as a unidirectional SDP transmission.

   When following the Offerer needs rules described for a
   normal Offer/Answer exchange.  The Answerer can take this
   opportunity to rekey, rekey the Offerer MUST only send a=crypto
   lines which match a=crypto lines traffic it had received is sending, if the Answerer
   desires.  During rekeying, the session parameters cannot be changed
   and MUST NOT be specified in the Offer or the Answer.

   When an SRTP or SRTCP transmitter the Offerer needs to rekey, the only new
   values permitted in the a=crypto line(s) are the new offerer MUST send an "a=crypto"
   line with same crypto-suite, key length, and new salt -- other cryptographic parameters MUST NOT be changed. length that was
   previously accepted by the Answerer.

   If the Answerer answerer selected a=crypto "a=crypto" lines using the "inline" method,
   the exact same a=crypto "a=crypto" line(s) as agreed to in the Answer answer MUST be
   sent and a new new inline key MUST be sent.

   If the Answer answerer selected a=crypto "a=crypto" lines using the "uri" method,
   the sender MAY transmit the same uri, and the recipient MUST re-fetch fetch
   the new key using the uri.

6.0

5.8 Operation with KEYMGT and Key lines

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

6. Security Considerations

   One needs

   Like all SDP messages, SDP messages containing security
   descriptions, are conveyed in an encapsulating application protocol
   (e.g. SIP, MGCP, RTSP, SAP, etc.). It is the responsibility of the
   encapsulating protocol to define ensure the protection of the SDP security descriptions for
   descriptions.  Therefore, that protocol should either invoke its own
   security mechanisms to do so, or alternatively utilize a specific SDP
   media transport lower-layer
   security service (e.g. TLS, IPSEC) where that service is deemed
   adequate for a=crypto to be useful.  The definitions SHOULD
   be specified protecting the encapsulating protocol itself.  Where

Andreasen, Baugher & Wing                                    [Page 15] 
   the encapsulating protocol is used in both a hop-by-hop and end-to-
   end context (e.g. SIP), an Internet RFC, which has end-to-end security implications
   that MUST service SHOULD be considered in the RFC. This section considers the SRTP
   descriptions
   provided by that protocol for the RTP/SAVP transport all sensitive information including
   SDP's security parameters.  This service SHOULD provide strong
   message authentication and packet-payload encryption as specified in this
   Internet Draft. well as
   effective replay protection.  As an example, SIP with S/MIME bodies
   satisfies these requirements.

6.1 Authentication of packets

   RTP messages are vulnerable to a variety of attacks such as replay
   and forging.  To limit these attacks, SRTP message integrity and
   anti-replay
   mechanisms SHOULD be used. used (SRTP replay protection is always
   enabled). Source authentication of unicast SRTP messages SHOULD be
   performed [srtp].  Note that SRTP source-message authentication does
   not authenticate the IP-address of the SRTP source, but ensures that
   the SRTP message that the SRTP receiver had received is exactly what
   the SRTP sender had sent.  Source authentication of multicast SRTP
   messages is today non-
   standard non-standard and hence for further study.  But
   even in multicast sessions, SRTP packet authentication ensures that
   the packet originated from a member of the secure group.  Use of the UNAUTHENTICATED
   parameter
   UNAUTHENTICATED_SRTP parameter, therefore, is NOT RECOMMENDED. SRTP supports this setting,
   however, for voice applications where authentication is implicit in
   the application [srtp].  In general, applications SHOULD NOT set
   UNAUTHENTICATED.

6.1 Key-stream Reuse of Keying Material ("Two-Time Pad")

   Misconfigured SRTP sessions, moreover, are vulnerable to attacks on
   their encryption services when running the crypto suites of defined in
   Sections 4.1.1, 4.1.2 and 4.1.3.  An SRTP encryption service is "mis-
   configured"
   "mis-configured" 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
   make them their corresponding keystreams unique, which is violated in the
   case of SSRC collision:
   RTP SRTP SSRC collision reveals drastically weakens SRTP
   or SRTCP plaintext 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, as this document requires
   RECOMMENDS (Section 4.2).  There is risk of
   attack, however, when an SDP media stream has an "a=sendrecv"
   direction attribute and a pair of senders are sharing a master key
   for their encryption (i.e. a weaker condition than sharing a master
   key).  It is RECOMMENDED, therefore, that a sendrecv stream have two
   SRTP master keys, one for each directional stream.  By implication,
   the SDP message that describes the sendrecv stream MUST NOT be a
   multicast media stream that provides inline keys from multiple
   receivers. For the same reason, the risk recurs when a media stream
   has an "a=sendonly" direction attribute in an multicast SDP message.

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

Andreasen, Baugher & Wing                                    [Page 16] 

6.2 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 set sets UNENCRYPTED for the SRTP stream in
   an Offer, offer, this could result in the Answerer answerer not decrypting the
   encrypted SRTP messages.  In the worst case, the Answerer answerer might
   itself send unencrypted SRTP and leave its data exposed to snooping.

   IPsec, TLS, S/MIME encapsulating-protocol security or some other data
   security service SHOULD be used to provide message authentication
   for SDP messages that carry the SRTP attribute.  Message encryption
   SHOULD be used when because a master key parameter appears in the
   message.  Failure to encrypt the SDP message containing an inline
   SRTP master key renders the SRTP authentication or encryption
   service useless in practically all circumstances.  Failure to
   authenticate an SDP message that carries SRTP parameters renders the
   SRTP authentication or encryption service useless in most practical
   applications.

   When the SDP parameters cannot be carried in an encrypted and
   authenticated SDP message, it is RECOMMENDED that a key management
   protocol be used.  The proposed SDP key-mgmt statement 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 endpoint, its
   signaling controller, and the 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.

Andreasen, Baugher & Wing                                    [Page 17] 
   In this case, the third-party provider is provided gets the contents of the SRTP attribute
   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
   MUST SHOULD NOT be used when
   end-to-end authentication or confidentiality is needed but the SDP
   message is not secured end to end (such as the above example where a
   third-party provider maintains the security associations with the
   endpoints for the SDP message).

7.0

7. SRTP "Crypto" Attribute Grammar

   This section provides an Augmented BNF grammar for the SRTP profile
   of the SDP crypto-attribute.  ABNF is defined in [RFC2234].  The
   rule names <att-field> and <att-value> are from SDP [RFC2327].

     att-field = "crypto"
     att-value = cipher application

     application = cipher-both / cipher-srtp / cipher-srtcp

     cipher-both  = key-parameter *[SP sess-par-both]
     cipher-srtp  = key-parameter *[SP sess-par-srtp]
     cipher-srtcp = key-parameter *[SP sess-par-srtcp]

     key-parameter the SDP crypto attribute.  ABNF is defined in [RFC2234].

     key-param      = method-inline / method-uri

     cipher

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

     sess-par-both = roc /              ; Roll-Over Counter
                     kdr /              ; Key Derivation Rate
                     "UNENCRYPTED"

     sess-par-srtp  = ssrc / fec-order

     sess-par-srtcp = "UNAUTHENTICATED"

     method-inline   = "inline:" key-info *(SP session-param)
     method-uri      = "uri:<" absoluteURI ">" ; absoluteURI defined in
                                               ; [RFC2396]

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

     key-length = 1*(DIGIT)          ; length in bytes
     salt-length

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

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

     lifetime = ["2^"] 1*(DIGIT)
     mki = "/" mki-length ":" mki-value
     mki-length = 1*3(DIGIT)         ; MUST be multiple of 8 and 1*DIGIT         ; MUST not exceed real value is 2^mki-length, max 128
     mki-value = 1*(base64)

     roc 1*DIGIT

     session-param  = "ROC:" 1*(DIGIT) src /
                      kdr /
                      "UNENCRYPTED_SRTP" /
                      "UNENCRYPTED_SRTCP" /
                      "UNAUTHENTICATED_SRTP" /
                      fec-order

Andreasen, Baugher & Wing                                    [Page 18] 
     src = "KDR:" 1*(DIGIT) "SRC=" [ssrc] "/" [roc] "/" [seq]

     ssrc = "SSRC:" ssrc-value
     ssrc-value 1*DIGIT                 ; range 0...2^32-1
     roc  = 1*DIGIT                 ; range 0...2^32-1
     seq  = 1*DIGIT                 ; range 0...2^16-1

     kdr = "KDR=" 1*(DIGIT) *["," ssrc-value]

     fec-order = "FEC:" 1*(DIGIT) "FEC_ORDER=" fec-type
     fec-type = "FEC_SRTP" / "SRTP_FEC" / "SPLIT"

     base64 =  ALPHA / DIGIT / "+" / "/" / "="

8.0

8. Open Issues

   The following is a list of open issues in this document:

   * The crypto attribute can be used with or without offer/answer,
     however, details on usage outside of offer/answer are missing.

   * The offer/answer procedures need to be expanded to better describe
     unidirectional and inactive streams, unicast versus multicast, as
     well as additional detail for some of the session parameters.

9. Acknowledgements

   This document benefited from discussions with Flemming Andreasen, David McGrew, Mats
   Naslund, Mike Thomas, Elisabetta Cararra, Brian Weis, Dave Oran,
   Bill Foster, Earl Carter, Matt Hammer and Dave Singer.  These people
   shared observations, identified errors and made suggestions for
   improving the specification.  Mats made several valuable suggestions
   on parameters and syntax that are in the current draft.  Dave Oran recommended the generic approach
   and Mike Thomas encouraged us to the
   SDP media-stream security descriptions that is followed in bring this
   draft.  Flemming Andreasen suggested some changes work to an earlier
   draft that greatly simplify this document. the IETF for
   standardization.  David McGrew suggested the conservative approach
   of using unique master keys for each SDP media stream as followed in
   this document.  Jonathan Rosenberg suggested reducing the complexity
   by specifying only one security parameter for each media stream.

9.0

10. 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
   mbaugher@rdrop.com  97219 USA
   mbaugher@cisco.com
   +1-408-853-4418

Andreasen, Baugher & Wing                                    [Page 19] 
   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134  USA
   dwing@cisco.com
   +1 408 525 5314

10.0
   +1-408-902-3348

11. Normative References

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

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

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

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

   [RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
   the Session Description Protocol (SDP)", 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", May
   2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-
   08.txt, Work in Progress

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

12. Informative References

   [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
   Capability Declaration", RFC 3407, October 2002.

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

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

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

   [RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP:
   A Transport Protocol for Real-Time Applications", January 1996,
   http://www.ietf.org/rfc/rfc1889.txt Progress.

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

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

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

   [RFC2327] M. Handley, V. Jacobson, "SDP: Session Description
   Protocol", April 1998, http://www.ietf.org/rfc/rfc2327.txt
   [RFC2828] R. Shirey, "Internet Security Glossary", May 2000,
   http://www.ietf.org/rfc/rfc2828.txt

   [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
   Resource Identifiers (URI): Generic Syntax", August 1998,
   http://www.ietf.org/rfc/rfc2396.txt

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

   [srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K.
   Norrman, D. Oran, "The Secure Real-time Transport Protocol", June
   2002, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-
   05.txt, Work

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 Progress

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

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing

Andreasen, Baugher & Wing                                    [Page 21] 
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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

Andreasen, Baugher & Wing                                    [Page 22]