Internet Engineering Task Force                                 J. Arkko
MSEC Working Group                                            E. Carrara
INTERNET-DRAFT                                               F. Lindholm
Expires: May August 2002                                          M. Naslund
                                                              K. Norrman
                                                                Ericsson

                                                          November, 2001

                                                          February, 2002

                   MIKEY: Multimedia Internet KEYing
                     <draft-ietf-msec-mikey-00.txt>
                     <draft-ietf-msec-mikey-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

   Work for securing real-time applications have started to appear. This
   has brought forward the need for a key management solution to support
   the security protocol. The key management has to fulfil requirements,
   which makes it suitable in the context of conversational multimedia
   in a heterogeneous environment.

   This document describes a key management scheme that can be used for
   real-time applications (both for peer-to-peer communication and group
   communication), and shows how it may work together with protocols
   such as SIP and RTSP. In particular, its use to support the Secure
   Real-time Transport Protocol, [SRTP], is described in detail.

TABLE OF CONTENTS

   1. Introduction..............................................3 Introduction.............................................. 3
   1.1. Notational Conventions..................................3 Conventions.................................. 4
   1.2. Definitions.............................................3 Definitions............................................. 4
   1.3. Abbreviations...........................................4 Abbreviations........................................... 5
   1.4. Outline.................................................5 Outline................................................. 5
   2. Basic Overview............................................5 Overview............................................ 6
   2.1. Scenarios...............................................5 Scenarios............................................... 6
   2.2. Design Goals............................................6 Goals............................................ 7
   2.3. System Overview.........................................7 Overview......................................... 7
   2.4. Relation to GKMARCH..................................... 9
   2.5. Existing solutions......................................8 solutions...................................... 9
   3. Basic Key Transport and Exchange Schemes..................8 Schemes.................. 9
   3.1. Pre-shared key..........................................8 key..........................................10
   3.2. Public-key encryption...................................9 encryption...................................10
   3.3. Diffie-Hellman key exchange.............................10 exchange.............................12
   4. Key Management............................................11 Management............................................14
   4.1. TEK and Verification key Calculation....................11 Key Calculation.........................................14
   4.1.1. Assumptions...........................................12 Assumptions...........................................14
   4.1.2. Notation..............................................12 Notation..............................................14
   4.1.3. Description...........................................12
   4.2. Re-keying...............................................13 PRF Description.......................................15
   4.1.4. Generating TEK from PMK...............................15
   4.1.5. Generating keys from an envelope/pre-shared key.......16
   4.1.6. Generating KEK from a DH-key..........................16
   4.2 Pre-defined Transforms and Timestamp Formats.............16
   4.2.1 Hash functions.........................................16
   4.2.2 Pseudo random number generator and PRF.................16
   4.2.3 Key data transport encryption..........................17
   4.2.4 MAC and Verification Message function..................17
   4.2.5 Envelope Key encryption................................17
   4.2.6 Digital Signatures.....................................17
   4.2.7 Diffie-Hellman Groups..................................17
   4.2.8. Timestamps............................................17
   4.3. Policies................................................17
   4.4. Indexing the Data SA....................................18
   4.5. Re-keying and MCS updating..............................18
   5. Behavior and message handling.............................14 handling.............................19
   5.1. General.................................................14 General.................................................19
   5.1.1. Capability discovery..................................14 discovery..................................19
   5.1.2. Error handling........................................14 handling........................................19
   5.2. Creating a message......................................14 message......................................19
   5.3. Parsing a message.......................................15 message.......................................21
   5.4. Replay handling.........................................16 handling.........................................21
   5.5. Reliability.............................................17 Reliability.............................................22
   6. Integration with session establishment protocols..........23
   6.1. SDP integration...........................................17
   7. Key management integration.........................................23
   6.2. MIKEY with SIP..........................................23
   6.3. MIKEY with SIP...................................18 RTSP.........................................24
   6.4. MIKEY Interface.........................................25
   7. Groups....................................................26
   7.1. Integration.............................................18 Simple one-to-"a few"...................................26
   7.2. Re-keying...............................................18 Small-size interactive group............................27
   8. Key management with RTSP..................................19 Security Considerations...................................27
   8.1. Integration.............................................19 General.................................................27
   8.2. Re-keying...............................................19
   9. Groups....................................................19
   10. Security Considerations..................................21
   10.1. General................................................21
   10.2. Key lifetime...........................................22
   10.3. Timestamps.............................................22
   10.4. Key lifetime............................................28
   8.3. Timestamps..............................................29
   8.4. Identity protection....................................23
   10.5. protection.....................................30
   8.5. Denial of Service......................................23 Service.......................................30
   8.6. Session establishment...................................30
   9. Conclusions...............................................30
   10. Acknowledgments..........................................31
   11. Conclusions..............................................24
   12. Acknowledgments..........................................24
   13. Author's Addresses.......................................24
   14. References...............................................25 Addresses.......................................31
   12. References...............................................31

   Appendix A - Payload Encoding................................27 Encoding................................34
   A.1. Common header payload..................................27 payload...................................34
   A.1.1. SRTP ID...............................................36
   A.2.  PS Key data payload........................................29 transport payload..............................37
   A.3.  PK Envelope data payload........................................30 payload...................................38
   A.4. DH data payload........................................30 payload.........................................38
   A.5. Signature payload......................................31 payload.......................................39
   A.6. Timestamp payload......................................31 payload.......................................40
   A.7. ID payload / Certificate payload........................32 payload........................40
   A.8. Cert hash payload.......................................33 payload.......................................41
   A.9. Ver msg payload.........................................33 payload.........................................41
   A.10. n_start/n_end/SPI payload..............................34 Security Policy payload................................42
   A.10.1. SRTPbasic policy.....................................42
   A.10.2. SRTPext policy.......................................44
   A.10.3. Re-key policy........................................45
   A.11. SP payload.............................................34 Rand payload...........................................46
   A.12. Error payload..........................................36 payload..........................................46
   A.13. Key data payload.......................................47
   A.14. Key validity data .....................................48
   Appendix B. - Payload usage summary..........................36 summary..........................49
   Revision History.............................................50

1. Introduction

   There has recently been work to define a security protocol for the
   protection of real-time applications running over RTP, [SRTP].
   However, a security protocol needs a key management solution to
   exchange keys, security parameters, etc. There are some fundamental
   properties that such a key management scheme has to fulfil with
   respect to the kind of real-time applications (streaming, unicast,
   groups, multicast, etc.) and to the heterogeneous nature of the
   scenarios dealt with. [REQS] lists in detail requirements for

   This document describes a key management to work for conversational solution, that address
   multimedia in heterogeneous
   environments.

   Following the requirements derived in [REQS], we discuss here some
   scenarios, scenarios (e.g. SIP calls and propose a key management solution. That is, the RTSP sessions). The focus is
   on how to set up key management for secure multimedia sessions such
   that requirements in a heterogeneous environment are fulfilled.

1.1. Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.

1.2. Definitions

   Crypto Session: uni- or bi-directional data stream(s), protected by a
   single instance of a security protocol. E.g. when SRTP is used, the
   Crypto Session may contain two streams, both the an RTP stream and the
   corresponding RTCP as they are both protected by a single instance of SRTP.
   SRTP (i.e. they share key and some other parameters).

   Crypto Session ID: within an MCS unique identifier for the Crypto
   Session.

   Multimedia Crypto Session (MCS): collection of one or more Crypto
   Sessions, which has a common Security Association and Pre-Master Key. Key and security parameters.

   Multimedia Crypto Session ID: unique identifier for the MCS.

   Security Association (SA): collection of information needed to secure
   a Multimedia Crypto Session.

   Pre-Master Key (PMK): a bit-string agreed upon by two or more
   parties, associated with a SA (and consequently MCS). From the pre-
   master key, Traffic-encrypting Keys can then be generated without
   need of further communication.

   Traffic-encrypting Key (TEK): the key used by the security protocol
   to protect the crypto session (this key may be used directly by the
   security protocol or may be used to derive further keys depending on
   the security protocol). The TEKs are derived from the MCS's PMK.

   Key-encryption key (KEK): a key to be used to protect other keys that
   are to be sent between the sender and the receiver.

   PMK re-keying: the process of re-negotiating the PMK (and
   consequently future TEK(s)).

   Initiator: the initiator of the key management protocol, not
   necessarily the initiator of the communication.

   Responder: the responder in the key management protocol.

   H(x):      a cryptographic hash function with argument x
   Random():  a secure (pseudo-)random number generator
   PRF(k,x):  a keyed pseudo-random function
   E(k,m):    encryption of m with the key k
   D(k,m):    decryption of m with the key k
   Sign(k,m): the signature of message m with key k
   PK_x:      the public key of x
   SK_x:      the secret key of x
   Cert_x:    Certificate of x
   k_p:       the PMK
   []         an optional piece of information
   ||         concatenation
   |          logical          OR (selection operator)
   ^          exponentiation
   XOR        binary exclusive OR
   **         exponentiation or

   Bit and byte ordering: throughout the document bits and bytes are as
   usual indexed from left to right, with the leftmost bits being the
   most significant.

1.3. Abbreviations

   AES    Advanced Encryption Standard
   CM     Counter Mode
   DH     Diffie-Hellman
   DoS    Denial of Service
   KEK    Key-encrypting Key
   MAC    Message Authentication Code
   MIKEY  Multimedia Internet KEYing
   OFB    Output Feedback Mode
   PK     Public-Key
   PMK    Pre-Master key
   PS     Pre-Shared key
   RTP    Real-time Transport Protocol
   RTSP   Real Time Streaming Protocol
   SDP    Session Description Protocol
   SIP    Session Initiation Protocol
   SRTP   Secure RTP
   TEK    Traffic-encrypting key

1.4. Outline

   Section 2 describes the basic scenario and the design goals that
   MIKEY are based on. It also gives a brief overview of the entire
   solution.
   solution and its relation to the group key management architecture
   [GKMARCH].

   The basic key transport/exchange mechanisms are explained in detail
   in Section 3. The key derivation derivation, re-keying, and re-keying other general key
   management procedures are described in Section 4.

   Section 5 describes the expected behavior of the involved parties.
   This also includes message creation and parsing.

   As MIKEY may be carried in SDP over SIP and RTSP, Section 6-8 6 describes
   how to integrate and use MIKEY in these scenarios.

   Section 9 7 focuses on how MIKEY may be is used in group scenarios.

   The Security Considerations section (Section 10), 8), gives a deeper
   explanation on different security related topics.

   All definitions of the payloads in MIKEY are described in Appendix A
   and Appendix B includes a list of when the payloads MUST/MAY be used.

2. Basic Overview

2.1. Scenarios

   MIKEY is intended to be used for peer-to-peer, simple one-to-many,
   and small-size (interactive) groups. One of the main multimedia
   scenarios is the conversational multimedia scenario, where users may
   interact and communicate in real-time. In these scenarios it can be
   expected that peers set up multimedia sessions between each other,
   where a multimedia session may consist of one or more multimedia
   streams (e.g. SRTP streams).

   We identify in the following some typical scenarios which involve the
   multimedia applications we are dealing with (see also Figure 1.1.).

   a) peer-to-peer (unicast), e.g. a SIP-based [SIP] call between two
     parties where it may be desirable that the security is either set
     up by mutual agreement or that each party sets up the security for
     its own outgoing streams.

   b) many-to-many, without a centralized control unit, e.g. for small
     groups where each party may set up the security for its own
     outgoing media.

   c) many-to-many, with a centralized control unit, e.g. for larger
     groups with some kind of Group Controller that sets up the
     security.

   d) simple one-to-many (multicast), e.g. real-time presentations,
     where the sender is in charge of setting up the security.

   The key management solutions may be different in the above scenarios.
   MIKEY addresses the peer-to-peer case, one-to-many (one-to-"a few")
   and small-size interactive groups.

      peer-to-peer/         many-to-many           many-to-many
      one-to-many           (distributed)          (centralized)
              ++++        ++++          ++++     ++++           ++++
              |. |        |A |          |B |     |A |----   ----|B |
            --| ++++      |  |----------|  |     |  |    \ /    |  |
   ++++    /  ++|. |      ++++          ++++     ++++    (S)    ++++
   |A |---------| ++++       \          /                 |
   |  |    \    ++|B |        \        /                  |
   ++++     \-----|  |         \ ++++ /                  ++++
                  ++++          \|C |/                   |C |
                                 |  |                    |  |
                                 ++++                    ++++

   Figure 1.1: Examples of the four scenarios: peer-to-peer, one-to-
   many, many-to-many without centralized server, and many-to-many with
   a centralized server.

   The key management solutions may be different in the above scenarios.
   For large scale multicast applications and big groups scalability is
   an issue, and we refer to other work in the MSEC WG.

   This specification only describes the peer-to-peer case, on which the
   simple one-to-many and small-size group then can be based. Section 9
   brings up some more MIKEY related group issues.

2.2. Design Goals

   The goal has been to create a protocol that satisfies most of the
   requirements stated in [REQS].

2.2. Design Goals

   The key management protocol is designed to have the following
   characteristics:

   * End-to-end security. Only the participants have access to the
    generated key(s).

   * Simplicity.

   * Efficiency. Designed to have:
     - low bandwidth consumption,
     - low computational workload,
     - small code size, and
     - minimal number of round-trips.

   * Piggy backing. Tunneling. Possibility to piggy back "tunnel" MIKEY in session establishment
    protocols (e.g. SIP and RTSP).

   * Independent of the specific security functionality of the underlying
    transport.

2.3. System Overview

   One objective of MIKEY is to produce Data security protocol SA (Data
   SA), including a traffic-encrypting key (TEK), which then can be used
   as key input to a Security Protocol. MIKEY can also be used to
   distribute a Group Re-key SA, including a key-encrypting key (KEK). A
   re-key SA can be used as input for an external group re-key protocol
   (see also [GKMARCH] for more information about group re-keying).

   The procedure of setting up a Multimedia Crypto Session (MCS) and
   creating a TEK, TEK (and Data SA), is done in accordance to Figure 2.1.:

   1. A Security Association (SA) set of security parameters and a Pre-Master Key Key(s) (PMK) are
     created for the Multimedia Crypto Session (this is done by one of
     the three alternative key transport/exchange mechanisms, see
     Section 4). 3).

   2. The PMK PMK(s) is used to derive (in a cryptographically secure way) a
     TEK for each Crypto Session.

   3. The TEK TEK, together with the security protocol parameters represent
     the Data SA, which is used as the key input to the Security Protocol.

                         -------------------

            +-----------------+
            |       MCS       |                 +-----------------+
            |  Key transport  |                 |    /exchange External Group  |
                         - - - - - - - - - -
            |    /exchange    |--> Re-key SA -->| Re-key protocol |
                         -------------------
            +-----------------+                 +-----------------+
                     |      :
                     | PMK  :
                     v      :
                            ------------
               +----------+ :
       CS ID ->|   TEK    | : Security Protocol
               |derivation| : Parameters
                            ------------
               +----------+ :
                                  |
                  TEK |     :
                      v     v
                      Data SA
                        |
                        v
               +-------------------+
               |  Crypto Session
                            (Security Protocol)   |
               |(Security Protocol)|
               +-------------------+

   Figure 2.1. Overview of the key management procedure.

   The security protocol MAY then either use the TEK directly, or, if
   supported, derive further session keys from the TEK (e.g. see SRTP
   [SRTP]). It is however up to the security protocol to define how the
   TEK is used.

   The re-keying procedure

   Re-keying may be done by an external group re-key protocol using a
   Re-key SA (in accordance to the group key management architecture
   [GKMARCH]). However, a separate re-key protocol may be most useful
   for large scale groups. MIKEY can be used to update the TEKs without
   an external re-key protocol. This is managed then done by running executing the
   transport/exchange phase once more again to derive a new PMK (and
   consequently the TEKs).

2.4. Existing solutions

   There is work done in IETF Relation to develop GKMARCH

   The Group key management schemes. For
   example, IKE [IKE] is architecture (GKMARCH) [GKMARCH] describes a widely accepted unicast scheme
   general architecture for IPsec, and
   the MSEC WG is developing other schemes, addressed to group
   communication [GDOI, GSAKMP]. For reasons discussed in Section 3 and
   in [REQS], there key management protocols. MIKEY is however a
   part of this architecture, and can be used as a so called
   Registration protocol. The main entities involved in the architecture
   are a group controller/key server (GCKS), the receiver(s), and the
   sender(s).

   In MIKEY the GCKS and the sender can be viewed as the same entity,
   which pushes down keys to the receiver. Note that e.g. in a SIP-
   initiated call, the sender may also be a receiver. As MIKEY address
   small interactive groups, a member may dynamically change between
   being a sender and receiver (or being both).

2.5. Existing solutions

   There is work done in IETF to develop key management schemes. For
   example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and
   the MSEC WG is developing other schemes, addressed to group
   communication [GDOI, GSAKMP]. For reasons discussed, there is however
   a need for a scheme more suitable for demanding cases such as real-time real-
   time data over heterogeneous networks. networks, and small interactive groups.

3. Basic Key Transport and Exchange Schemes

   The following sections propose define three different ways to transport/
   exchange a Pre-Master Key: with the use of a pre-shared key, public-
   key encryption, and Diffie-Hellman (DH) key exchange. The two first
   methods we call will be denoted key transport. In the following we assume it is for
   simplicity assumed unicast communication. In addition to the PMK, a
   random "nonce", denoted Rand, is also transported. In all three
   cases, the PMK and Rand values are then used to derive TEKs as
   described in Section 4.1.4.

   Note that in the general general, keys for encryption and signing in general
   MUST should be
   different, though for simplicity we use the same notation for
   both cases. both.

   Note also that in the following protocol definitions, things like
   security protocol parameters, headers etc., have intentionally been
   left out. In practice, the messages sent are constructed by a set of
   payloads (see Appendix A), wherein the different parameters may be
   fitted. The signature/MAC is then computed over the entire message
   (not only the specific values that are shown in the protocol
   definition).

3.1. Pre-shared key

   The pre-shared key case is done according to Figure 3.1. The Pre-
   Master Key (k_p) is One or more
   Pre-Master Keys (PMKs) are randomly and independently chosen by the
   initiator together with zero or one randomly and independently chosen
   KEK. These are then encrypted with the pre-shared key and sent to the
   responder. T A random bit-string, Rand, is a
   timestamp added by the Initiator to prevent replay attacks. together with a
   timestamp, T. The entire message MUST be is integrity protected by a Message
   Authentication Code (MAC). It is assumed that the

   The pre-shared secret, s, consists of is used to derive key material for both the
   encryption (encr_key) and the integrity protection (auth_key). (auth_key) as
   described in Section 4.1.5. The identity IDa MAY be sent to
   correctly select the pre-shared key to be used. encryption and authentication
   transforms are described in Section 4.2.

                  A                                     B
   Initialization:
   Rand, PMKs, KEK = Random ()
   encr_key, auth_key = PRF(s,...||Rand)

   Protocol execution:
   K = [IDa],T, E(encr_key,k_p) Rand, E(encr_key,PMKs[||KEK])
   A = MAC(auth_key,K)

                               K, A
                    --------------------- >
                                            V=MAC(k_v,IDa||IDb||T),[IDb]
                    ---------------------->
                                       auth_key = PRF(s,..||Rand)
                                       V=MAC(auth_key,IDa||IDb||T),[IDb]
                               [V]
                    <----------------------

   Figure 3.1. Pre-shared key based transport mechanism.

   Authentication of the peers is provided by the MAC(s). The responder
   MAY return (if requested by Initiator) the verification message, V,
   showing that it knows the PMK. V.
   The verification message is created by applying the MAC function with a verification key, k_v. The
   verification key, k_v, is derived from
   an authentication key on the PMK according to Section
   4.1.

   Note that IDs and timestamp.

   As will be seen, the pre-shared case is, by far, the most efficient
   way to handle the key transport due to the use of symmetric
   cryptography only. This approach has also the advantage that only a
   small amount of data has to be exchanged. Of course, the problematic
   issue is scalability.

3.2. Public-key encryption

   Public-key cryptography can be used to create a scalable system. A
   disadvantage with this approach is that it is more resource consuming
   than the pre-shared key approach. Another disadvantage is that in
   most cases a PKI (Public Key Infrastructure) is needed to handle the
   distribution of public keys. Of course, it is possible to use public
   keys as pre-shared keys (e.g. by using self-signed certificates).

          A                                             B

   Initialization:
   Rand, PMKs, KEK = Random ()
   encr_key, auth_key = PRF(env_key,...||Rand)

   Protocol execution:
   I=(IDa|Cert_A)
   K=E(PK_b,k_p)
     || T
     [||
   O=E(encr_key,IDa||PMKs[||KEK])
   P=MAC(auth_key,O)

   K=E(PK_b,env_key),
     O, P, T, Rand
     [, I]
     [||
     [, H(Cert_B)]
   S=Sign(SK_a,H(K))

                              K,S
                    ---------------------->

                                            V=MAC(k_v,IDa||IDb||T),[IDb]
                                       {retrieve env_key using SK_b}
                                       auth_key = PRF(env_key,...||Rand)
                                       V=MAC(auth_key,IDa||IDb||T),[IDb]
                               [V]
                    <----------------------

   Figure 3.2. Key transport using public keys.

   The key transport mechanism is according to Figure 3.2. The initiator
   encrypts one or more PMKs, the IDa, and optionally a randomly chosen value k_p, to KEK. The
   encrypted keys MUST also be used as integrity protected. The keys for
   encryption (encr_key) of the PMK, with keys and the MAC (auth_key) are derived
   from an "envelope" key (see Section 4.1.5). The envelope key is then
   encrypted using the responder's public key (which the initiator
   already has). While any public key techniques could be used, proposed
   encryption and signature transforms are described in Section 4.2. We
   also refer to Section 4.2 for key-encryption algorithm and MAC
   definitions.

   The Initiator creates a message consisting of the encrypted k_p, PMKs and
   KEK, a timestamp, a Rand, and optionally its ID/Certificate and a
   hash of the certificate used to encrypt k_p. the envelope key. The entire
   message is then finally signed and sent to the responder.

   As mentioned, the initiator MAY include a hash of the certificate of
   the public key used to encrypt k_p. the envelope key, env_key. The
   responder uses MUST then use the private key corresponding to the
   specified certificate to decrypt the encrypted PMK. envelope key.

   The responder MAY send a verification message, V, (as in the pre-
   shared case) to the initiator, which proves that the responder has
   received the PMK correctly. initiator. This message uses a MAC (e.g. HMAC),
   with
   a verification key k_v, which is an authentication key, derived from the PMK according to Section 4.1.

   Certificate handling
   4.1.4.

   It is in general complex; possible to cache the scheme shown here envelope key, so that it can be used as a
   pre-shared key. It is not the only one possible. For example, recommended that this key should be cached
   indefinitely (however it is possible for B up to fetch
   A's certificate via other means. Verification of certificate against
   Revocation Lists is not treated here, but may add extra delay.

   Certificate handling the local policy to decide this).
   This function may involve a number of be very convenient during a Multimedia Crypto
   Session, if a new crypto session needs to be added (or an old on
   removed). Then, the pre-shared key can be used, instead of the public
   keys (see also Section 4.5.).

   Certificate handling may involve a number of additional tasks not
   shown here, and effect the inclusion of certain parts of the message.
   The following observations can, however, be made:

     - party A typically has to find the certificate of B in order to
      send the first message. If A doesn't have B's certificate
      already, this may involve one or more roundtrips to a central
      directory agent.

     - it will be possible for A to omit its own certificate and rely on
      B getting this certificate using other means. However, we
      recommend doing  this, only when it is reasonable to assume that
      B can be expected to have cached the certificate from a previous
      connection. Otherwise accessing the certificate would mean
      additional roundtrips for B as well.

     - verification of the certificates using Certificate Revocation
      Lists (CRLs) or an on-line verification protocol may mean
      additional roundtrips for both parties. If a small number of
      roundtrips is required for acceptable performance, it may be
      necessary to omit some of these checks.

3.3. Diffie-Hellman key exchange

   The possibility of using a Diffie-Hellman (DH) key exchange method is
   also offered. Though, this approach in general has a higher resource
   consumption (both computationally and in bandwidth) than the previous
   ones. With this method only one key is created, i.e. the DH-key. This
   may then be used either as a PMK or (indirectly) as a KEK.

   For a fixed, agreed upon, group, (G,*), for g in G and a natural
   number x, we let g**x g^x denote g*g*..*g (x times). Choices for the
   parameters are given in the DH payload Section 4.2.7. The other transforms below are
   described in Appendix A.6. Note that the
   group MUST have a size of at least two to the power of the desired
   PMK size. Section 4.2.

               A                                  B

   Initialization:
   Rand, x = Random ()                   y = Random ()

   Protocol execution:
   I = (IDa|Cert_A)
   K = g**x || T [|| I] g^x, T, Rand [,I]
   S = Sign (SK_a,H(K))
                              K,S        I' = (IDb|Cert_B)
                    ---------------------->
                    ----------------->   K' = g**y || T [|| I'] g^y,T,IDa,g^x [,I']
                                         S' = Sign (SK_b,H(K'))
                             K',S'
                    <----------------------

   k_p= g**(xy)                               k_p=g**(xy)
                    <-----------------

   PMK=g^(xy)                            PMK=g^(xy)

   Figure 3.3. Diffie-Hellman key based exchange, where x and y are
   randomly chosen respectively by A and B.

   The key exchange is done according to Figure 3.3. The initiator
   chooses a random value x, and sends a signed message including g**x g^x, a
   Rand, and a timestamp to the responder (optionally also including its
   certificate or identity).

   The group parameters (e.g., the group G) are a set of parameters
   chosen by the initiator. The responder chooses a random positive
   integer y, and sends a signed message including g**y g^y and the timestamp
   to the initiator (optionally also providing its certificate). The
   signature must also cover the Initiator's id and the g^x value.

   Both parties then calculate the PMK, g**(xy). g^(xy). The authentication is
   due to the signing of the DH key, values (and identities), and is
   necessary to avoid man-in-the-middle attacks.

   Note that this approach does not require that the initiator has to
   posses any of the responder's certificate before the setup. Instead,
   it is sufficient that the responder includes it's signing certificate
   in the response.

   This approach is the most expensive approach. It requires first of
   all, that both
   sides compute one signature, then one verification and
   finally two DH-
   exponentiations.

4. Key Management

4.1. TEK and Verification key Key Calculation

   We define in the following a general method (pseudo random function)
   to derive one or more keys from a Verification key and "master" key. This method should be
   used to derive:

   * TEKs from a PMK and the PMK. Rand,

   * a KEK from the DH-key and the Rand,

   * encryption, authentication, or salting key from a pre-shared/
    envelope key and the Rand.

4.1.1. Assumptions

   We assume that the following parameters are in place (to be exchanged
   as security parameters, in connection to the actual key exchange):

   k_p: the PMK,

   PMK: a Pre-Master Key, which MUST be random and kept secret. Note
   that there may be more than one PMK transported.

   The following parameter MAY be sent in the clear:

   mcs_id: Master Crypto Session ID (32-bits unsigned integer)
   cs_id:  the Crypto Session ID

   pmk_len: (8-bits unsigned integer)
   Rand:   An (at least) 128-bit random bit-string sent by the
   Initiator.

   The key derivation method has the following input parameters:

   inkey:      the input key to the derivation function.
   inkey_len:  the length in bits of the PMK.

   tek_len: input key.
   seed:       a specific seed, dependent on the type of the key to be
               derived, the Rand, and the session IDs.
   outkey_len: desired TEK length for in bits of the security protocol. output key.

   The key derivation method has the following output:

   outkey: the output key.

4.1.2. Notation

   Let HMAC be the SHA1 based message authentication function, see
   [HMAC,SHA1]. Similar to [TLS], define:

      P (s, seed, m) = HMAC (s, A_1 || seed) ||
                       HMAC (s, A_2 || seed) || ...
                       HMAC (s, A_m || seed)
   where

      A_0 = seed,
      A_i = HMAC (s, A_(i-1)).

4.1.3. Description

   The following procedure

   While this is applied to compute the TEK:

   * default, HMAC using other hash function MAY be
   used, see Section 4.2.1.

4.1.3. PRF Description

   The following procedure describes a pseudo-random function, denoted
   PRF(inkey,seed), applied to compute the output key, outkey:

   * let n = pmk_len inkey_len / 512, rounded up to the nearest integer
   * split the pre-master key inkey into n blocks, k_p inkey = s_1 || ... || s_n, where all
    s_i, except possibly s_n, are 512 bits each
   * let m = tek_len outkey_len / 160,  rounded up to the nearest integer
   * set seed = "MIKEYtek" || cs_id || mcs_id

   (If another hash function than SHA1 is used, "512" and "160" MUST be
   replaced by the appropriate input/output block-sizes of that
   function.)

   Then, the TEK output key, outkey, is obtained as the tek_len outkey_len most
   significant bits of

        P (s_1, seed, m) ^ P (s_2, seed, m) ^

   PRF(inkey,seed) = P(s_1,seed,m) XOR P(s_2,seed,m) XOR ... ^ P (s_n, seed, m).
                     XOR P(s_n,seed,m).

4.1.4. Generating TEK from PMK

   The procedure key derivation method should be executed with the following
   parameters:

   inkey:      PMK
   seed:       0x2AD01C64 || cs_id || mcs_id || Rand
   outkey_len: length of generating the Verification key, k_v, is output TEK.

   Note, the same,
   replacing cs_id is the constant string "MIKEYtek" by id of the constant string
   "MIKEYver", and cs_id by 0. (This gives a verification key of length
   equal the TEK is supposed to tek_len). be
   derived for.

   If the security protocol does not support key derivation for
   authentication and encryption itself from the TEK, separate
   authentication and encryption keys MAY directly be created for the
   security protocol by replacing "MIKEYtek" 0x2AD01C64 with "MIKEYaut" 0x1B5C7973 and "MIKEYenc"
   0x15798CEF respectively, and
   tek_len outkey_len by the desired key-length(s)
   in each case.

4.2. Re-keying

   A PMK re-keying mechanism is necessary, e.g. when a key is
   compromised, when access control is desired, or simply when a key
   expires. Therefore, re-keying MUST be supported to allow a smooth
   (continuos) communication. Re-keying is performed by executing MIKEY
   again before

   Note that the PMK expires.

   The necessary parameter(s) to be defined to support 32-bit constant integers (i.e. 0x2AD01C64 and the re-keying
   procedure once
   replacing it) is taken from the new PMK and (when applicable) a signature (with the
   corresponding parameters as defined in Section 3.2 decimal digits of e (i.e. 2.7182...),
   and 3.3). It may
   be necessary to specify where each constant consist of nine decimals digits (e.g. the
   first nine decimal digits 718281828 = 0x2AD01C64).

4.1.5. Generating keys from an envelope/pre-shared key lifetime range e.g. to trigger a new
   re-keying procedure during the on-going Multimedia Crypto Session.

   The parameters for re-keying are

   inkey:      the following:

   Encrypted PMK, envelope key or DH-values (depending on method). This is sent to be
   able to derive a new PMK and thereby new TEKs.

   SPI is an identifier of the new k_p. This can only be used when it is
   supported by the security protocol. Note that the use of SPI will
   exclude the use pre-shared key

   seed:       0x150533E1 || 0xFF || mcs_id || Rand (for encryption key)
               or
               0x2D22AC75 || 0xFF || mcs_id || Rand (for auth. key)
               or
               0x29B88916 || 0xFF || mcs_id || Rand (for salting key)

   outkey_len: desired length of n_start and n_end.

   n_start and n_end define the lifetime range authentication/encryption/salting
   key.

4.1.6. Generating KEK from a DH-key

   inkey:      DH-key

   seed:       0x39A2C14B || 0xFF || mcs_id || Rand

   outkey_len: desired length of the PMK k_p (and MAY KEK.

4.2 Pre-defined Transforms and Timestamp Formats

   This section identifies standard transforms for MIKEY. The following
   transforms SHALL be used instead of a SPI). The lifetime range in the respective case. New transforms MAY
   be expressed added in
   terms of time, packet index, etc. The deployed security protocol MUST
   specify which unit the future. It is used.

   If n_start however recommended to be sparse with
   extensions as it usually only creates interoperability problems
   between old and n_end is not specified, newer versions.

4.2.1 Hash functions

   MIKEY SHALL use one of the default n_start value
   SHOULD be that following hash function: SHA-1 (see
   [SHA1], MD5 (see [MD5]), SHA256, SHA384, or SHA512 (see [SHA256] for
   the key last three). SHA-1 is valid from the first observed packet. For
   the n_end value, as default and the key is valid 'until further notice'.
   This does not mean that the protocol will be able only mandatory to run forever (all
   security protocols will 'exhaust' the TEK sooner or later).

   A Multimedia Crypto Session MAY contain several Crypto Sessions. implement
   and support.

4.2.2 Pseudo random number generator and PRF

   A
   problem that then MAY occur is to synchronize cryptographically secure pseudo random number generator MUST be
   used for the re-keying if an SPI
   is not used. It is then recommended that one main Crypto Session is
   identified from generation of the MCS keying material and nonces, e.g.
   [BMGL].

   For the re-keying is done with respect to
   that. Exactly how this should key derivations, the PRF specified in Section 4.1. MUST be done is for future study.

   Note that it
   supported. This PRF MAY not be necessary to include certificates and other
   information that was provided in the first exchange, i.e. all
   parameters that are static or optional to include.

5. Behavior and message handling

   Each message that is sent extended by the Initiator using SHA-256 or the Responder, SHA-512,
   instead of SHA-1.

4.2.3 Key data transport encryption

   The default and mandatory-to-support key transport encryption is built
   by AES
   in counter mode, as defined in [SRTP, Section 4], using a set of payloads. This section describes how messages are created key as
   derived in Section 4.1.5, and using initialization vector

   IV = [S XOR (0x0000 || MCS ID || T)] || 0x0000,

   where S is a 112-bit salting key, also when they can be used.

5.1. General

5.1.1. Capability Discovery

   The initiator tries to guess the responder's capabilities derived as in terms Section 4.1.5,
   and where T is the timestamp.

   Note: this restricts the maximum size of
   security algorithms etc. If the guess transported key to 2^23
   bits, which is wrong, then still enough for all practical purposes.

4.2.4 MAC and Verification Message function

   MIKEY SHALL use 160-bit authentication tags, generated by HMAC with
   SHA-1 as the responder
   may send back its own capabilities (negotiation) default and mandatory to let the initiator
   choose a common set of parameters. Multiple attributes may implement method, see [HMAC].
   Authentication keys SHALL be
   provided in sequence. This is done derived according to reduce Section 4.1.5.

4.2.5 Envelope Key encryption

   When RSA is used for the number envelope encryption, MIKEY SHALL use
   RSA/PKCS#1, see [PKCS1].

4.2.6 Digital Signatures

   When RSA is used for the signatures, MIKEY SHALL use RSA/PKCS#1, see
   [PKCS1]. The default hash function SHALL be SHA-1.

4.2.7 Diffie-Hellman Groups

   Diffie-Hellman key exchange SHALL use one of roundtrips
   as much as possible.

   If the responder groups: OAKLEY 5,
   OAKLEY 1, or, OAKLEY 2, see [OAKLEY], where OAKLEY 5 is not willing/capable default and
   mandatory to provide security or the
   parties simply cannot agree, it support.

4.2.8. Timestamps

   The current defined timestamp is up to the parties' policies how to
   behave, as defined in NTP [NTP], i.e. accept an insecure communication or reject it.

5.1.2. Error Handling

   All errors due a 64-
   bit number in seconds relative to 0h on 1 January 1900. An
   implementation must be aware of (and take into account) the key management fact that
   the counter will overflow approximately every 136th year. It is
   RECOMMENDED that the time is always specified in UTC.

4.3. Policies

   Included in the message exchange, policies for the Data security
   protocol SHOULD be reported to and/or the peer(s) by an error message. re-key protocol are transmitted. The Initiator SHOULD therefore
   always be prepared to receive policies are
   defined in a response back from separate payload and are specific to the responder.

   If security/re-key
   protocol (see also Appendix A.10.). Together with the responder does not support keys, the set
   validity period of parameters suggested by
   the initiator, the error message theses SHOULD include the supported
   parameters (see also Section 5.1.1.).

5.2. Creating a message

   To create a MIKEY message, a Common header payload is first created. be specified. This payload could either
   be done with an SPI (e.g. when a re-key protocol is then followed, depending used) or with an
   Interval (e.g. a sequence number interval for SRTP). Whether an SPI
   or an Interval should be used, depends on the message type, by a
   set of information payloads (e.g. DH-value payload, Signature
   payload, Security Protocol payload). security protocol (or
   re-key protocol).

4.4. Indexing the Data SA

   The defined payloads and indexing of a Data SA will depend on the
   exact encoding security protocol as
   different security protocols will have different characteristics. For
   SRTP the SSRC (see [SRTP]) is one of each payload are described those. However, the SSRC is not
   sufficient. For the local lookup in Appendix A.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  version      !  data type    ! next payload  !               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...            +
   ~                   Common Header...                            ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! next payload  !   Payload 1 ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             :                                 :
   :                             :                                 :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! next payload  !   Payload x ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   MAC/Signature payload                       ~
   +                                                               +
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5.1. the MIKEY payload example.

   The process of generating a message consists of SA data base, it is
   RECOMMENDED that the following steps:

   * Create MIKEY implementation support a master payload starting lookup using
   destination network address and port together with the Common header payload.

   * Concatenate necessary payloads SSRC. Note that
   MIKEY does not send network addresses or ports. One reason to the master payload (Appendix B
    lists what payloads MUST/MAY be used for the different messages).

   * As a last step (for messages this is
   that must they may not be authenticated),
    concatenate the payload containing the MAC/signature, where the
    MAC/signature field known in advance, as well as if a NAT exists in-
   between, problems may arise.

   When SIP or RTSP is initiated with zeros.

   * Calculate used, the MAC/signature over local view of the entire master payload destination address
   and
    update port can be obtained form either SIP or RTSP. MIKEY can then use
   these addresses as the MAC/signature field with index for the MAC/signature.

5.3. Parsing a message

   In general, parsing is done by extracting payload by payload Data SA lookup.

4.5. Re-keying and
   checking that no errors occur (the exact procedure MCS updating

   A re-keying mechanism is implementation
   specific). However, for the Responder, it is recommended that the
   following procedure is followed:

   * Extract the Timestamp and check that it is within the allowable
    clock skew. Also check the replay cache so that the message necessary, e.g. when a key is not
    replayed (see also Section 5.4).

   * Extract ID and authentication algorithm (if not included, assume
    default one).

   * Verify the MAC/signature.

   * If the authentication compromised,
   when access control is NOT successful, an Auth failure Error
    message desired, or simply when a key expires.
   Therefore, re-keying MUST be sent supported to allow a smooth (continuos)
   communication. In accordance to the initiator.

   * If GKMARCH, MIKEY supports the authentication is successful,
   possibility to use an external group re-key protocol, by the message SHOULD re-key
   SA. However, an external group re-key protocol may not be
    processed. Though how necessary
   in a small group. Therefore, it is processed is implementation specific.

   * If any unsupported parameters or errors occur during the
    processing, these SHOULD be reported also possible to update the Initiator MCS
   (e.g. a TEK or a crypto session parameter) by sending an
    error message. The processing SHOULD then be aborted. using MIKEY.

   The error
    message MAY also include payloads to describe updating of the supported
    parameters.

   * If needed, a response message MCS is created and sent to the Initiator.

5.4. Replay handling

   * Each Responder MUST utilize performed by executing MIKEY again e.g.
   before a replay cache in order TEK expires, or a new crypto session is added to remember the
    messages presented within the allowable clock skew (see also
    Section 10.3. for timestamp considerations).

   * A message SHOULD be deleted from the cache when it MCS.

   When MIKEY is outdated with
    respect executed again to update the clock skew.

   * Due to physical limitations, the replay cache SHOULD MCS, it MAY not be set to
    store up
   necessary to a maximum number of messages (see below for more
    details).

   * If the host loses track of include certificates and other information that was
   provided in the incoming requests (e.g. due to
    overload), it must reject first exchange, i.e. all incoming requests until the clock
    skew interval has passed.

   For a client, the maximum number of messages it will recall may vary
   depending on the capacity of parameters that are static
   or optional to include.

   The new message exchange MUST use the client itself and same MCS ID as the network, initial
   exchange, but
   also the number of expected messages should be taken into account.
   The following is a recommendation of how new timestamp. A new Rand MUST NOT be included in the maximum size of
   message exchange (the Rand will only have affect in the
   replay cache Initial
   exchange). New Crypto Sessions may be calculated:

   maxsize = Min (A, e*x) * block_size

   where

   A: maximum memory blocks possible to allocate (for simplicity: 1
   memory block can contain added if desired in the information from one message)

   e: fault-tolerant value  (MUST be >1)

   x: #max expected messages per "clock skew"

   block_size: size of update
   message. Therefore, the new MIKEY message to be cached (note that it will
   probably does not be needed need to cache contain
   keys.

   As explained in Section 3.2., the entire message, instead envelope key may be "cached" as a hash of
   the message and
   pre-shared key. If so, the timestamp might "update message" SHOULD be enough).

   In case of a DoS attack, pre-shared
   key message, not a public key message. If the client will in most cases be able to
   handle the replay cache. A bigger problem will probably be to process
   the messages (verify signatures/MACs), due to the computational
   workload this implies.

5.5. Reliability

   When MIKEY public key message is integrated with a transporting protocol,
   used, but the
   reliability scheme of envelope key was not cached, the latter may Initiator MUST provide
   a new encrypted envelope key that can be applied. Otherwise, used in the basic
   processing applied verification
   message. However, the Initiator does not need to ensure protocol reliability provide any other
   keys.

   A Multimedia Crypto Session MAY contain several Crypto Sessions. A
   problem that then MAY occur is to synchronize the following.

   The transmitting entity (initiator or responder) MUST:

   * Set a timer re-keying if an SPI
   is not used. It is therefore recommended that an SPI is used, if more
   than one Crypto Session is used.

5. Behavior and initialize a retry counter

   * If message handling

   Each message that is sent by the timer expires, Initiator or the message Responder, is resent built
   by a set of payloads. This section describes how messages are created
   and also when they can be used.

5.1. General

5.1.1. Capability Discovery

   The initiator tries to guess the retry counter
    is decreased.

   * responder's capabilities in terms of
   security algorithms etc. If the retry counter reaches zero (0), guess is wrong, then the event MAY responder
   may send back its own capabilities (negotiation) to let the initiator
   choose a common set of parameters. Multiple attributes may be logged
   provided in sequence. This is done to reduce the appropriate system audit file

6. SDP integration

   SDP descriptions [SDP] can be carried by several protocols, such number of roundtrips
   as
   SIP and RTSP. One of the goals in the design of MIKEY was to be able
   to piggy-back it in other protocols (such much as SIP and RTSP). Both SIP
   and RTSP often uses SDP possible.

   If the responder is not willing/capable to describe provide security or the media sessions. Therefore,
   parties simply cannot agree, it is also convenient to be able up to integrate the key management in the
   session description parties' policies how to
   behave, i.e. accept an insecure communication or reject it.

   Note that it is supposed not the intention of this protocol to protect. [KMASDP] describes
   attributes that SHOULD be used by have a key management protocol that very
   broad variety of options, as it is
   integrated in SDP. The following two SDP attributes MUST be used by
   MIKEY.

   a=keymgmt-prot:<protocol>
   a=keymgmt-data:<data>

   The keymgmt-prot attribute indicates the key management protocol.
   Therefore, assumed that it MUST should not be set to "MIKEY", i.e.

   a=keymgmt-prot:MIKEY

   The data part too
   common that an offer is used denied.

5.1.2. Error Handling

   All errors due to transport the actual key management payload
   message. Due protocol SHOULD be reported to
   the text based nature of SDP, this part MUST peer(s) by an error message. The Initiator SHOULD therefore
   always be
   base64 encoded prepared to avoid illegal characters.

   a=keymgmt-data:<base64 encoded data>

   Example

        |          a=keymgmt-prot:MIKEY
        |          a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
   MCS <   CS 1 <  m=audio 49000 RTP/SAVP 98
        |          a=rtpmap:98 AMR/8000
        |  CS 2 <  m=video 2232 RTP/SAVP 31
   In this example receive such message back from the multimedia crypto session consists responder.

   If the responder does not support the set of two crypto
   sessions (one audio stream and one video stream).

7. Key management with SIP

   In a basic SIP call between two parties (see Figure 7.1.), SIP
   (Session Initiation Protocol, [SIP]) is used as a session
   establishment protocol between a caller A and a callee B.

                          |A's SIP| <.......> |B's SIP|
                          |Server |    SIP    |Server |
                          ---------           ---------
                               ^                ^
                               .                .
             ++++         SIP  .                .   SIP         ++++
             |  | <.............                ..............> |  |
             |  |                                               |  |
             ++++ <-------------------------------------------> ++++
                                      SRTP

   Fig 7.1.: SIP-based call example. The two parties uses SIP to set up
   an SRTP stream between A and B.

7.1. Integration

   SIP may carry SDP descriptions, since the participants negotiate the
   media encoding etc. Therefore, parameters suggested by
   the SDP attributes previously
   described may be integrated inside initiator, the INVITE and error message SHOULD include the answer to that.
   Eventually, subsequent SIP messages may supported
   parameters (see also be used, e.g., when
   parameter negotiation is needed.

   It may be assumed that the caller knows the identity of the callee.
   However, unless the initiator's identity can be derived from SIP
   itself, the initiator (caller) MUST provide the identity to the
   callee. It is recommended to use the same identity for both SIP and
   MIKEY.

7.2. Re-keying

   A re-keying mechanism is necessary, e.g. when the key is compromised
   or simply because it has Section 5.1.).

5.2. Creating a restricted lifetime. When SIP is used as
   the session establishment protocol, message

   To create a re-INVITE can be issued
   carrying SDP with the MIKEY data (this message, a Common header payload is sent by first created.
   This payload is then followed, depending on the Initiator message type, by a
   set of
   MIKEY). Note that it might not be necessary to send all information,
   such as the certificate, due to the already established call.

8. Key management with RTSP

   The Real Time Streaming information payloads (e.g. DH-value payload, Signature
   payload, Security Protocol (RTSP) [RTSP] is used to control
   media streaming from a server. payload). The media session is typically
   obtained via an SDP description, received by a DESCRIBE message, or
   by other means (e.g., HTTP). To be able to pass defined payloads and the MIKEY messages
   exact encoding of each payload are described in
   RTSP messages not containing Appendix A.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  version      !  data type    ! next payload  !               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...            +
   ~                   Common Header...                            ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! next payload  !   Payload 1 ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             :                                 :
   :                             :                                 :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! next payload  !   Payload x ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                   MAC/Signature                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5.1. MIKEY payload example.

   The process of generating a SDP description, message consists of the RTSP KeyMgmt
   header (defined in [KMASDP]) is used.

8.1. Integration

   The server MUST  include following steps:

   * Create a master payload starting with the Common header payload.

   * Concatenate necessary security parameters, key
   included, in the SDP part of the response payloads to the initial DESCRIBE
   message.

   If master payload (Appendix B
    lists which payloads MUST/MAY be used for the different messages).

   * As a response is required, this should last step (for messages that must be included in authenticated, this also
    include the first SETUP
   message from verification message), concatenate the client to payload
    containing the server. Note that MAC/signature, where the SETUP message
   does not include a SDP description, why MAC/signature field is
    initiated with zeros.

   * Calculate the RTSP KeyMgmt header
   (defined in [KMASDP]) MUST be used to pass MAC/signature over the MIKEY message.

   Note that it is entire master payload and
    update the server that will be MAC/signature field with the Initiator MAC/signature. In the case
    of MIKEY the verification message, the IDa || IDb || T MUST follow
    directly after the master payload in
   this case. This has some advantages, first the server will always be
   able to chose MAC calculation.

   Note that all messages from the key Initiator MUST use a new timestamp!

5.3. Parsing a message

   In general, parsing is done by extracting payload by payload and
   checking that no errors occur (the exact procedure is implementation
   specific). However, for the content it distributes, secondly, Responder, it
   will then have is recommended that the possibility to use
   following procedure is followed:

   * Extract the same key for Timestamp and check that it is within the same
   content allowable
    clock skew. Also check the replay cache so that are streamed/sent to more than one client.

8.2. Re-keying

   To be able to have a server initiated re-keying procedure, either the
   ANNOUNCE message or is not
    replayed (see also Section 5.4).

   * Extract ID and authentication algorithm (if not included, assume
    default one).

   * Verify the SET_PARAMETER MAC/signature.

   * If the authentication is NOT successful, an Auth failure Error
    message SHOULD MUST be used sent to send the re-keying material. A disadvantage of using these, are that they
   are not mandatory initiator (if SIP is used, this should
    be signaled to implement. Note that SIP as a rejection of the ANNOUNCE method has offer). The message MUST
    then be discarded from further processing, and the
   possibility to send SDP descriptions to update previous ones (i.e. it
   is not needed to use the RTSP KeyMgmt header).

9. Groups

   What has been discussed up to now can event SHOULD be extended from
    logged.

   * If the unicast
   case to small-size groups and simple one-to-many scenarios. However,
   key management authentication is more complex in successful, the case of groups. This section
   does not give a solution for how MIKEY should be used for groups
   (that will message SHOULD be a second step in the process of MIKEY). This section
   only describes some properties of
    processed. Though how it is processed is implementation specific.

   * If any unsupported parameters or errors occur during the transport and exchange
   mechanisms that might
    processing, these SHOULD be of importance for future work and extensions
   in reported to the area.

9.1. Simple one-to-many

                       ++++
                       |S |
                       |  |
                       ++++
                         |
                 --------+-------------- - -
                 |       |      |
                 v       v      v
               ++++    ++++   ++++
               |A |    |B |   |C |
               |  |    |  |   |  |
               ++++    ++++   ++++

               Figure 9.1. Simple one-to-many scenario.

   In Initiator by sending an
    error message. The processing SHOULD then be aborted. The error
    message MAY also include payloads to describe the most simple one-to-many scenario, where a server supported
    parameters. If SIP is streaming
   to a small group of clients. In used, this scenario RTSP or SIP could should be
   used for the registration and the key management set up. The server
   would then act signaled to SIP as the Initiator a
    rejection of MIKEY the offer (see also Section 8.). In
   this scenario the pre-shared key or public key transport mechanism
   would be appropriate to use 6.2.).

   * If needed, a verification/response message is created and sent to transport
    the same PMK Initiator.

5.4. Replay handling

   * Each Responder MUST utilize a replay cache in order to remember the
    messages presented within the allowable clock skew (see also
    Section 8.3., timestamp considerations).

   * Replayed messages MUST NOT be processed.

   * A message SHOULD be deleted from the cache when it is outdated with
    respect to the clock skew.

   * Due to physical limitations, the replay cache SHOULD be set to
    store up to a maximum number of messages (see below for more
    details).

   * If the host loses track of the incoming requests (e.g. due to
    overload), it MUST reject all incoming requests until the
   clients (which clock
    skew interval has passed.

   For a client, the maximum number of messages it will result in common TEKs for recall may vary
   depending on the group).

   However, as capacity of the group increases in size, scalability client itself and management
   problems may arise. The Group Key Management Architecture [GARCH]
   describes a scalable architecture the network, but
   also the number of handling this scenario. The
   architecture can expected messages should be used as taken into account.
   The following is a base for recommendation of how MIKEY should the maximum size of the
   replay cache may be used in
   order calculated:

   maxsize = Min (A, e*x) * block_size

   where

   A: maximum memory blocks possible to handle scalable groups. Some minor extensions allocate (for simplicity: 1
   memory block can contain the information from one message)

   e: fault-tolerance value  (MUST be >1)

   x: #max expected messages per "clock skew"

   block_size: size of the message to MIKEY be cached (note that it will
   probably not be needed, such as needed to cache the transport of entire message, instead a key-encrypting key (KEK).
   However, this document does not consider how MIKEY should be used
   with the architecture.

9.2. Small-size group

                    ++++          ++++
                    |A | -------> |B |
                    |  | <------- |  |
                    ++++          ++++
                     ^ |          | ^
                     | |          | |
                     | |   ++++   | |
                     | --->|C |<--- |
                     ------|  |------
                           ++++

   Figure 9.2. Small-size group without centralized controller.

   As described in the overview section, for small-size groups one may
   expect that each client will be in charge for setting up the security
   for its outgoing streams. In these scenarios, hash of
   the pre-shared key message and the public-key transport methods should be used.

   One scenario may then timestamp might be that enough).

   In case of a DoS attack, the client sets up a three-part call,
   using SIP. Due will in most cases be able to
   handle the small size group, unicast SRTP is used between
   the clients. Each client may set up replay cache. A bigger problem will probably be to process
   the security for its outgoing
   streams messages (verify signatures/MACs), due to the others. A scenario like computational
   workload this would not require any
   modifications neither to implies.

5.5. Reliability

   When MIKEY nor SIP/SDP.

10. Security Considerations

10.1. General

   No chain is stronger than its weakest link. The cryptographic
   functions protecting the keys during transport/exchange SHOULD offer integrated with a security at least corresponding to transporting protocol, the (symmetric) keys they
   protect. For instance, with current state
   reliability scheme of the art, see [LV],
   protecting latter may be applied. Otherwise, the basic
   processing applied to ensure protocol reliability is the following.

   The transmitting entity (initiator or responder) MUST:

   * Set a 128-bit AES key by timer and initialize a 512-bit RSA [RSA] key offers an
   overall security below 64-bits. On retry counter

   * If the other hand, protecting a 64-
   bit symmetric timer expires, the message is resent and the retry counter
    is decreased.

   * If the retry counter reaches zero (0), the event MAY be logged in
    the appropriate system audit file

6. Integration with session establishment protocols

   This section describes how MIKEY should be integrated with SDP, SIP
   and RTSP. It is based on [KMASDP], which describes extensions to SDP
   and SIP to carry key management protocol MUST information.

6.1. SDP integration

   SDP descriptions [SDP] can be carried by a 2048-bit RSA key appears several protocols, such as
   SIP and RTSP. Both SIP and RTSP often use SDP to describe the media
   sessions. Therefore, it is also convenient to be an "overkill",
   leading able to unnecessary time delays. Therefore, integrate
   the key size for management in the key-
   exchange mechanism session description it is supposed to
   protect. [KMASDP] describes attributes that SHOULD be weighed against the size of the
   exchanged key.

   Moreover, if the PMKs are not random, used by a brute force search may key
   management protocol that is integrated in SDP. The following two SDP
   attributes MUST be
   facilitated, again lowering used by MIKEY.

   a=keymgmt-prot:<protocol>
   a=keymgmt-data:<data>

   The keymgmt-prot attribute indicates the effective key size. management protocol.
   Therefore, care it MUST be taken when designing set to "MIKEY", i.e.

   a=keymgmt-prot:MIKEY

   The data part is used to transport the (pseudo) random generators for PMK
   generation.

   For actual key management payload
   message. Due to the selection text based nature of SDP, this part MUST be
   base64 encoded to avoid illegal characters but in the hash function, SHA-1 with 160-bit output is
   the default one. same time
   avoiding a too large message expansion.

   a=keymgmt-data:<base64 encoded data>

   Example

        |          a=keymgmt-prot:MIKEY
        |          a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
   MCS <   CS 1 <  m=audio 49000 RTP/SAVP 98
        |          a=rtpmap:98 AMR/8000
        |  CS 2 <  m=video 2232 RTP/SAVP 31

   In general, hash sizes should be twice the "security
   level", indicating that SHA1-256, [SHA256], should be used for the
   default 128-bit level. However, due to the real-time aspects in the
   scenarios we are treating, hash size slightly below 256 are
   acceptable as this example the normal "existential" collision probabilities would
   be multimedia crypto session consists of secondary importance.

   In a Multimedia Crypto Session, the Crypto Sessions (audio, two crypto
   sessions (one audio stream and one video
   etc) share the same PMK as discussed earlier. From a security point
   of view, the criterion stream) to be satisfied is that the encryption of the
   individual Crypto Sessions are performed "independently". In MIKEY
   this is accomplished protected by having unique Crypto Session identifiers (see
   also Section 4.1.). The TEK derivation method assures this
   SRTP (as indicated by
   providing cryptographically independent TEKs to distinct Crypto
   Sessions (within the Multimedia Crypto Session), regardless of the
   security protocol used.

   Specifically, the TEK key derivation is implemented by "RTP/SAVP" profile).

6.2. MIKEY with SIP

   In a pseudo-
   random function. The one used here basic SIP call between two parties (see Figure 6.1.), SIP
   (Session Initiation Protocol, [SIP]) is a simplified version of that used in TLS [TLS]. Here, we use only one single hash function,
   whereas TLS uses as a session
   establishment protocol between two different functions, motivated or more parties. In general an
   offer is made, whereby it is either accepted or rejected by the risk of
   one of
   answerer. SIP complies to the hashes being broken. We motivate our simplification by offer/answer model [OFFANS], to which
   MIKEY over SIP MUST be compliant with as well.

                          ---------           ---------
                          |A's SIP| <.......> |B's SIP|
                          |Server |    SIP    |Server |
                          ---------           ---------
                               ^                ^
                               .                .
             ++++         SIP  .                .   SIP         ++++
             |  | <.............                ..............> |  |
             |  |                                               |  |
             ++++ <-------------------------------------------> ++++
                                      SRTP

   Fig 6.1.: SIP-based call example. The two parties uses SIP to set up
   an SRTP stream between A and B.

   The SIP offerer will be the
   observation that if a single widely used hash, e.g. SHA1, is broken, MIKEY Initiator and the wide-spread use of that function means SIP answerer will
   be the MIKEY responder. This implies that we have much more to in the offer, the MIKEY
   Initiator message SHOULD be worried about than included, and in the security of a single protocol. Also, SHA1
   would need to have very serious flaws for our pseudo random function answer to the offer,
   the MIKEY Responder message SHOULD be considered insecure.

   In included.

   If the pre-shared key and public-key schemes, MIKEY part of the PMK offer is generated by not accepted, a single party (initiator). This makes MIKEY more sensitive if error message
   SHOULD be provided in the
   initiator uses a bad random number generator. answer (following Section 5.1.). MIKEY MUST
   always signal to SIP whether the MIKEY message was an acceptable
   offer or not.

   It should also may be noted assumed that neither the pre-shared nor offerer knows the public-key scheme provides
   perfect forward secrecy. If mutual contribution or perfect forward
   secrecy is desired, identity of the Diffie-Hellman scheme MUST be used.

   Forward/backward security: if
   answerer. However, unless the PMK, k_p, is exposed, all TEKs
   generated initiator's identity can be derived
   from it are compromised. However, under SIP itself, the assumption that initiator (caller) MUST provide the derivation function identity to
   the callee. It is a pseudo-random function, disclosure recommended to use the same identity for both SIP
   and MIKEY.

   Updating of an
   individual the MCS (e.g. TEK does update) SHOULD only be seen as a new
   offer. Note that it might not compromise other (previous or later) TEKs
   derived from be necessary to send all information,
   such as the same PMK.

10.2. Key lifetime

   Even if certificate, due to the lifetime of already established call (see
   also Section 4.5.).

6.3. MIKEY with RTSP

   The Real Time Streaming Protocol (RTSP) [RTSP] is used to control
   media streaming from a PMK server. The media session is not specified, it MUST typically
   obtained via an SDP description, received by a DESCRIBE message, or
   by other means (e.g., HTTP). To be taken into
   account that able to pass the encryption transform MIKEY messages in
   RTSP messages which does not contain an SDP description, the underlying security
   protocol can RTSP
   KeyMgmt header (defined in some way degenerate after a certain amount of
   encrypted data. Each security protocol MUST define such maximum
   amount and trigger a re-keying procedure before [KMASDP]) is used. This header includes
   basically the 'exhaustion' of same fields as the key. For SRTP SDP extensions.

   In an RTSP scenario, the key MUST RTSP server and initiator will be changed at least for every 2**48
   packet (i.e. every time the ROC + SEQ nr same
   entity. The Initiator/RTSP server includes the MIKEY message in SRTP wraps).

   As a rule of thumb, if SDP
   description. When responding to this, the security protocol client uses an 'ideal' b-bit
   block cipher (in CBC mode, counter mode, or a feedback mode with full
   b-bit feedback), degenerate behavior in the crypto stream, possibly
   useful for an attacker, is expected defined
   RTSP header to occur after a total of roughly
   2**(b/2) encrypted b-bit blocks (using random IVs). For some security
   margin, re-keying SHOULD be triggered well send back the answer (included in advance compared to the
   above bound. See [BDJR] for more details.

   For use of a dedicated stream cipher, we refer to SETUP message).

   Note that it is the analysis and
   documentation server that will be the Initiator of said cipher MIKEY in each specific
   this case.

10.3. Timestamps

   The timestamp prevents against replay attacks under This has some advantages. First, the following
   assumptions:

   * Each host MUST have a clock which is at least "loosely
    synchronized" server will always be
   able to chose the time of key for the other hosts.

   * If content it distributes. Secondly, it
   will then have the clocks are possibility to be synchronized over the network, a secure
    network clock synchronization protocol MUST be used.

   In general, a client may not expect a very high load of incoming
   messages and may therefore allow use the degree of looseness to be on same key for the
   order of minutes (5-10 minutes same
   content that are believed streamed/sent to more than one client.

   To be ok). If able to have a DoS
   attack is launched and the replay cache grows too large, MIKEY may
   dynamically decrease server initiated MCS update procedure, either
   the looseness so that ANNOUNCE message or the replay cache becomes
   manageable.

   Servers may SET_PARAMETER message SHOULD be used to
   send the entities that will have the highest work load. It updated MIKEY material. A disadvantage of using these, is also recommended
   that the servers they are the Initiators of MIKEY.
   This will result in not mandatory to implement. Note that the servers will not manage any significant
   replay cache as they will refuse all incoming messages that are ANNOUNCE
   method has the possibility to send SDP descriptions to update
   previous ones (i.e. it is not a
   response needed to an already (by use the server) sent message.

   Practical experiences of Kerberos RTSP KeyMgmt header).

6.4. MIKEY Interface

   The SDP, SIP, and other timestamp based system
   indicates that RTSP processing is defined in [KMASDP]. However, it
   is not always necessary to synchronize the
   terminals over that MIKEY can work properly with these protocols.
   Therefore, the network. Manual configuration could be a feasible
   alternative in many cases (especially in scenarios where interface between MIKEY and these protocols MUST
   provide certain functionality (however, exactly how the degree
   of looseness interface
   looks like is high). However, very implementation dependent).

   MIKEY MUST have an interface towards the choice must be carefully based
   with respect SIP/SDP or RTSP/SDP
   implementation that allows for:

   * MIKEY to receive information about the usage scenario.

   The use of timestamps instead sessions negotiated. This is
    to some extent implementation dependent. But it is recommended
    that, in the case of challenge-response requires SRTP streams, the
   systems to have synchronized clocks. Of course, if two clients number of SRTP streams are
   not synchronized, they will have difficulties with setting up
    included (and the
   security. direction of these). The current timestamp based solution has been selected destination addresses
    and ports is also recommended to
   allow a maximum of one round-trip (i.e. two messages), but still provide a reasonable replay protection. A (secure) challenge-response
   based version would require at least three messages.

10.4. Identity protection

   Identity protection was not a main design goal when designing MIKEY.
   Such feature would have added more complexity to the protocol and was
   therefore chosen not MIKEY.

   * MIKEY to be included. As receive incoming MIKEY is anyway proposed messages. This MUST also include
    the possibility to
   be transported over e.g. SIP, return the identity may be exposed by this.
   However, if status of the transporting protocol is secured and also provides
   identity protection, MIKEY might inherit incoming message to
    SIP/SDP or to RTSP/SDP, i.e. whether the same feature. How this
   should be done is for future study.

10.5. Denial of Service

   This protocol is resistant MIKEY message was accepted
    or not.

   * SIP/SDP or RTSP/SDP to Denial of Service attacks in receive information from MIKEY, this include
    the sense
   that a responder does not construct any state (at receiving the key management
   protocol level) before it has authenticated MCS ID, receiving the initiator. However,
   this protocol, like many others, SSRCs for SRTP. It is open to attacks also
    RECOMMENDED that use spoofed
   IP addresses extra information about errors can be received.

   * SIP/SDP or RTSP/SDP to create receive outgoing MIKEY messages.

   * tearing down a large number of fake requests. This MAY be
   solved by letting the protocol transporting MIKEY do an IP address
   validity test.

11. Conclusions

   Work for securing real-time applications have started to appear. This
   has brought forward MCS (e.g. if the need for a key management solution to support SIP sessions is shutdown, the security protocol. The key management
    MCS SHOULD also be shutdown)
   Note that if a MCS has to fulfil requirements,
   which make already been established, it suitable in is still valid
   for the context of conversational multimedia in SIP/SDP or RSP/SDP implementation to request a heterogeneous environment. new message
   from MIKEY, e.g. when a new offer is issued. MIKEY was designed SHOULD then send
   an update message to fulfill such
   requirements and optimized so that it the Responder (see also may Section 4.5).

7. Groups

   What has been discussed up to now is not limited to single peer-to-
   peer communication, but can be integrated used in other
   protocol such as SIP small-size groups and RTSP. simple
   one-to-many scenarios. This section describes how MIKEY can be is used in different scenarios, for peer-to-peer
   communication, simple one-to-many, and for small-size groups without a centralized
   group server. This specification focused on scenario.

7.1. Simple one-to-"a few"

                       ++++
                       |S |
                       |  |
                       ++++
                         |
                 --------+-------------- - -
                 |       |      |
                 v       v      v
               ++++    ++++   ++++
               |A |    |B |   |C |
               |  |    |  |   |  |
               ++++    ++++   ++++

               Figure 7.1. Simple one-to-many/"a few" scenario.

   In the basic
   peer-to-peer most simple one-to-many/"a few" scenario, a server is
   streaming to a small group of clients. In this scenario RTSP or SIP
   could be used for the registration and the key management set up. The
   streaming server would act as the Initiator of MIKEY. In this also
   scenario the pre-shared key or public key transport mechanism will be
   appropriate to use to transport the same PMK to all the base clients
   (which will result in common TEKs for the group).

   Note, if the same PMK/TEK(s) should be used by all the group
   scenarios.

12. Acknowledgments

   The authors would like to thank, Mark Baugher, Ran Canetti, members,
   the rest
   of streaming server MUST specify the msec WG, Pasi Ahonen, Rolf Blom, Vesa-Matti Mantyla, same MCS_ID and
   Magnus Westerlund, CS_ID(s) for their valuable feedback.

13. Author's Addresses

     Jari Arkko
     Ericsson
     02420 Jorvas             Phone:  +358 40 5079256
     Finland                  Email:  jari.arkko@ericsson.com

     Elisabetta Carrara
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 50877040
     Sweden                   EMail:  elisabetta.carrara@era.ericsson.se

     Fredrik Lindholm
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 58531705
     Sweden                   EMail:  fredrik.lindholm@era.ericsson.se

     Mats Naslund
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 58533739
     Sweden                   EMail:  mats.naslund@era.ericsson.se
     Karl Norrman
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 4044502
     Sweden                   EMail:  karl.norrman@era.ericsson.se

14. References

   [AES] Advanced Encryption Standard, www.nist.gov/aes

   [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A
   Concrete Analysis of Symmetric Encryption: Analysis of
   the DES Modes
   of Operation", in Proceedings of session to all the 38th Symposium on Foundations of
   Computer Science, IEEE, 1997, pp. 394-403.

   [GARCH] Baugher, M., Canetti, R., and Dondeti, L., "Group Key
   Management Architecture", Internet Draft, June 2001, Work group members. Security considerations arising
   from using the same key for several streams in
   Progress.

   [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
   Domain of Interpretation", Internet Draft, February 2001, Work the underlying
   security protocol MUST be considered.

7.2. Small-size interactive group

                    ++++          ++++
                    |A | -------> |B |
                    |  | <------- |  |
                    ++++          ++++
                     ^ |          | ^
                     | |          | |
                     | |   ++++   | |
                     | --->|C |<--- |
                     ------|  |------
                           ++++

   Figure 7.2. Small-size group without centralized controller.

   As described in
   Progress.

   [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
   R., "Group Secure Association Key Management Protocol", Internet
   Draft, March 2001, Work the overview section, for small-size groups one may
   expect that each client will be in Progress.

   [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing charge for Message Authentication", RFC 2104, February 1997.

   [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
   RFC 2409, November 1998.

   [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
   Norrman, K., "Key Management Extensions setting up the security
   for SDP", Internet Draft,
   Work in Progress (MMUSIC WG).

   [LV] Lenstra, A. K., its outgoing streams. In these scenarios, the pre-shared key and Verheul, E. R., "Suggesting Key Sizes for
   Cryptosystems", http://www.cryptosavvy.com/suggestions.htm

   [MD5]  Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992.

   [NAI] Aboba, B. and Beadles, M., "The Network Access Identifier",
   IETF, RFC 2486, January 1999.

   [NTP] Mills, D., "Network Time Protocol (Version 3) specification,
   implementation and analysis", RFC 1305, March 1992.

   [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC
   2412, November 1998.

   [PKCS1] PKCS #1 - RSA Cryptography Standard,
   http://www.rsalabs.com/pkcs/pkcs-1/

   [REQS] Blom, R., Carrara, E., Lindholm, F., and Arkko, J., "Design
   Criteria
   the public-key transport methods will be used.

   One scenario may then be that the client sets up a three-part call,
   using SIP. Due to the small size of the group, unicast SRTP is used
   between the clients. Each client may set up the security for Multimedia Session Key Management in Heterogeneous
   Networks", Internet Draft, July 2001, Work in Progress.

   [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
   Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method its
   outgoing stream(s) to the others.

   As for Obtaining
   Digital Signatures and Public-Key Cryptosystems". Communications of the ACM. Vol.21. No.2. pp.120-126. 1978.

   [SDP] Handley, M., one-to-"a few" case, the streaming client MUST specify the
   same MCS_ID and Jacobson, V., "Session Description Protocol
   (SDP), IETF, RFC2327

   [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
   http://csrc.nist.gov/fips/fip180-1.ps

   [SHA256] NIST, "Description CS_ID(s) for its outgoing sessions if the same
   PMK/TEK(s) should be used for all the group members. The same
   security considerations for key-sharing also apply.

8. Security Considerations

8.1. General

   No chain is stronger than its weakest link. The cryptographic
   functions protecting the keys during transport/exchange SHOULD offer
   a security at least corresponding to the (symmetric) keys they
   protect. For instance, with current state of SHA-256, SHA-384, and SHA-512",
   http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf the art, see [LV],
   protecting a 128-bit AES key by a 512-bit RSA [RSA] key offers an
   overall security below 64-bits. On the other hand, protecting a 64-
   bit symmetric key by a 2048-bit RSA key appears to be an "overkill",
   leading to unnecessary time delays. Therefore, key size for the key-
   exchange mechanism SHOULD be weighed against the size of the
   exchanged key.

   Moreover, if the PMKs are not random, a brute force search may be
   facilitated, again lowering the effective key size. Therefore, care
   MUST be taken when designing the (pseudo) random generators for PMK
   generation.

   For the selection of the hash function, SHA-1 with 160-bit output is
   the default one. In general, hash sizes should be twice the "security
   level", indicating that SHA1-256, [SHA256], should be used for the
   default 128-bit level. However, due to the real-time aspects in the
   scenarios we are treating, hash size slightly below 256 are
   acceptable as the normal "existential" collision probabilities would
   be of secondary importance.

   In a Multimedia Crypto Session, the Crypto Sessions (audio, video
   etc) share the same PMK as discussed earlier. From a security point
   of view, the criterion to be satisfied is that the encryption of the
   individual Crypto Sessions are performed "independently". In MIKEY
   this is accomplished by having unique Crypto Session identifiers (see
   also Section 4.1.). The TEK derivation method assures this by
   providing cryptographically independent TEKs to distinct Crypto
   Sessions (within the Multimedia Crypto Session), regardless of the
   security protocol used.

   Specifically, the key derivations are implemented by a pseudo-random
   function. The one used here is a simplified version of that used in
   TLS [TLS]. Here, we use only one single hash function, whereas TLS
   uses two different functions. Note that the use of the Rand nonce in
   the key derivation is essential to protect against off-line time/
   memory trade-off attacks.

   In the pre-shared key and public-key schemes, the PMK is generated by
   a single party (initiator). This makes MIKEY more sensitive if the
   initiator uses a bad random number generator. It should also be noted
   that neither the pre-shared nor the public-key scheme provides
   perfect forward secrecy. If mutual contribution or perfect forward
   secrecy is desired, the Diffie-Hellman scheme MUST be used.

   Forward/backward security: if the PMK is exposed, all TEKs generated
   from it are compromised. However, under the assumption that the
   derivation function is a pseudo-random function, disclosure of an
   individual TEK does not compromise other (previous or later) TEKs
   derived from the same PMK.

8.2. Key lifetime

   Even if the lifetime of a PMK is not specified, it MUST be taken into
   account that the encryption transform in the underlying security
   protocol can in some way degenerate after a certain amount of
   encrypted data. Each security protocol MUST define such maximum
   amount and trigger a re-keying procedure before the 'exhaustion' of
   the key. For SRTP the key MUST be changed at least for every 2^48
   SRTP packet (i.e. every time the ROC + SEQ nr in SRTP wraps).

   As a rule of thumb, if the security protocol uses an 'ideal' b-bit
   block cipher (in CBC mode, counter mode, or a feedback mode with full
   b-bit feedback), degenerate behavior in the crypto stream, possibly
   useful for an attacker, is (with constant probability) expected to
   occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using
   random IVs). For security margin, re-keying MUST be triggered well in
   advance compared to the above bound. See [BDJR] for more details.

   For use of a dedicated stream cipher, we refer to the analysis and
   documentation of said cipher in each specific case.

8.3. Timestamps

   Timestamp usage prevents against replay attacks under the following
   assumptions:

   * Each host MUST have a clock which is at least "loosely
    synchronized" to the time of the other hosts.

   * If the clocks are to be synchronized over the network, a secure
    network clock synchronization protocol MUST be used.

   In general, a client may not expect a very high load of incoming
   messages and may therefore allow the degree of looseness to be on the
   order of minutes (5-10 minutes are believed to be ok). If a DoS
   attack is launched and the replay cache grows too large, MIKEY may
   dynamically decrease the looseness so that the replay cache becomes
   manageable.

   Servers may be the entities that will have the highest work load. It
   is also recommended that the servers are the Initiators of MIKEY.
   This will result in that the servers will not manage any significant
   replay cache as they will refuse all incoming messages that are not a
   response to an already (by the server) sent message.

   Practical experiences of Kerberos and other timestamp based system
   indicates that it is not always necessary to synchronize the
   terminals over the network. Manual configuration could be a feasible
   alternative in many cases (especially in scenarios where the degree
   of looseness is high). However, the choice must be carefully based
   with respect to the usage scenario.

   The use of timestamps instead of challenge-response requires the
   systems to have synchronized clocks. Of course, if two clients are
   not synchronized, they will have difficulties with setting up the
   security. The current timestamp based solution has been selected to
   allow a maximum of one round-trip (i.e. two messages), but still
   provide a reasonable replay protection. A (secure) challenge-response
   based version would require at least three messages.

8.4. Identity protection

   Identity protection was not a main design goal for MIKEY. Such
   feature will add more complexity to the protocol and was therefore
   chosen not to be included. As MIKEY is anyway proposed to be
   transported over e.g. SIP, the identity may be exposed by this.
   However, if the transporting protocol is secured and also provides
   identity protection, MIKEY might inherit the same feature. How this
   should be done is for future study.

8.5. Denial of Service

   This protocol is resistant to Denial of Service attacks in the sense
   that a responder does not construct any state (at the key management
   protocol level) before it has authenticated the initiator. However,
   this protocol, like many others, is open to attacks that use spoofed
   IP addresses to create a large number of fake requests. This MAY be
   solved by letting the protocol transporting MIKEY do an IP address
   validity test.

8.6. Session establishment

   It should be noted that if the session establishment protocol is
   insecure there may be attacks on this that will have indirect
   security implications on the secure media streams. This however only
   applies to groups (and is not really that specific to MIKEY only).
   The threat is that one group member may re-direct a stream from one
   group member to another group member. This will have the same
   implication as when a member tries to impersonate another member,
   e.g. by changing its IP address. If this is seen as a problem, it is
   RECOMMENDED that a Source Origin Authentication scheme is applied for
   the security protocol.

9. Conclusions

   Work for securing real-time applications have started to appear. This
   has brought forward the need for a key management solution to support
   the security protocol. The key management has to fulfil requirements,
   which make it suitable in the context of conversational multimedia in
   a heterogeneous environment and small interactive groups. MIKEY was
   designed to fulfill such requirements and optimized so that it also
   may be integrated in other protocol such as SIP and RTSP.

   MIKEY is designed to be used in scenarios for peer-to-peer
   communication, simple one-to-many, and for small-size interactive
   groups without a centralized group server.

10. Acknowledgments

   The authors would like to thank Mark Baugher, Ran Canetti, the rest
   of the MSEC WG, Pasi Ahonen (with his group), Rolf Blom, and Magnus
   Westerlund, for their valuable feedback.

11. Author's Addresses

     Jari Arkko
     Ericsson
     02420 Jorvas             Phone:  +358 40 5079256
     Finland                  Email:  jari.arkko@ericsson.com

     Elisabetta Carrara
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 50877040
     Sweden                   EMail:  elisabetta.carrara@era.ericsson.se

     Fredrik Lindholm
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 58531705
     Sweden                   EMail:  fredrik.lindholm@era.ericsson.se

     Mats Naslund
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 58533739
     Sweden                   EMail:  mats.naslund@era.ericsson.se

     Karl Norrman
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 4044502
     Sweden                   EMail:  karl.norrman@era.ericsson.se

12. References

   [AES] Advanced Encryption Standard, www.nist.gov/aes

   [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A
   Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes
   of Operation", in Proceedings of the 38th Symposium on Foundations of
   Computer Science, IEEE, 1997, pp. 394-403.

   [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and
   Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt
   '01.

   [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.,
   "Group Key Management Architecture", Internet Draft, Work in Progress
   (MSEC WG).

   [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
   Domain of Interpretation", Internet Draft, Work in Progress (MSEC
   WG).

   [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
   R., "Group Secure Association Key Management Protocol", Internet
   Draft, Work in Progress (MSEC WG).

   [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
   for Message Authentication", RFC 2104, February 1997.

   [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
   RFC 2409, November 1998.

   [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
   Norrman, K., "Key Management Extensions for SDP and RTSP", Internet
   Draft, Work in Progress (MMUSIC WG).

   [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for
   Cryptosystems", http://www.cryptosavvy.com/suggestions.htm

   [MD5] Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992.

   [NAI] Aboba, B. and Beadles, M., "The Network Access Identifier",
   IETF, RFC 2486, January 1999.

   [NTP] Mills, D., "Network Time Protocol (Version 3) specification,
   implementation and analysis", RFC 1305, March 1992.

   [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC
   2412, November 1998.

   [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with
   SDP", Internet Draft, IETF, Work in progress (MMUSIC).

   [PKCS1] PKCS #1 - RSA Cryptography Standard,
   http://www.rsalabs.com/pkcs/pkcs-1/

   [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
   Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
   Digital Signatures and Public-Key Cryptosystems". Communications of
   the ACM. Vol.21. No.2. pp.120-126. 1978.

   [SDP] Handley, M., and Jacobson, V., "Session Description Protocol
   (SDP), IETF, RFC2327
   [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
   http://csrc.nist.gov/fips/fip180-1.ps

   [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
   http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf

   [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
   "SIP: Session Initiation Protocol", IETF, RFC2543.

   [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M,
   Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol",
   Internet Draft, IETF, Work in Progress (AVT WG).

   [TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0",
   IETF, RFC 2246.

   [TMMH] McGrew, D., "The Truncated Multi-Modular Version 1.0",
   IETF, RFC 2246.

   [TMMH] McGrew, D., "The Truncated Multi-Modular Hash Function
   (TMMH)", Internet Draft, IETF, Work in Progress.

   [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
   Identifiers (URI): Generic Syntax", RFC 2396

Appendix A - Payload Encoding

   This appendix describes in detail all the payloads. For all encoding,
   Network byte order MUST always be used.

   Note that everything denoted Mandatory MUST be implemented, and
   everything denoted Default MUST be assumed to be selected if nothing
   else is stated.

A.1. Common header payload

   The Common header payload MUST always be present as the first payload
   in each message. The common header includes general description of
   the exchange message.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  version      !  data type    ! next payload  !R! PRF func    !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         MCS ID                                !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! #CS           ! CS ID map type! CS ID map info                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The common header contains the following information:

   * version: the version number of MIKEY.

     version = 1

   * data type: describes the type of message (e.g. public-key transport
    message, verification message, error message).

     Data type     | Value | Comment
     --------------------------------------
     Pre-shared    |     0 | Initiator's pre-shared key message
     PS ver msg    |     1 | Verification message of a Pre-shared
                   |       | key message
     Public key    |     2 | Initiator's public-key transport message
     PK ver msg    |     3 | Verification message of a public-key
                   |       | message
     D-H init      |     4 | Initiator's DH exchange message
     D-H resp      |     5 | Responder's DH exchange message
     Error         |     6 | Error message

   * next payload: identifies the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload.

     Next payload  | Value | Appendix
     ------------------------------
     Last payload  |     0 | -
     Key data trnsp|     1 | A2
     Env data      |     2 | A3
     DH data       |     3 | A4
     Signature     |     4 | A5
     Timestamp     |     5 | A6
     ID            |     6 | A7
     Certificate   |     7 | A7
     Cert hash     |     8 | A8
     Ver msg       |     9 | A9
     SP            |    10 | A10
     Rand          |    11 | A11
     Error         |    12 | A12
     Key data      |    20 | A13

   * R: flag to indicate whether a response is expected or not (this has
    only meaning when it is set by the Initiator).

     R = 0  ==> no response expected
     R = 1  ==> response expected

   * PRF func: Indicates the PRF function that has been/will be used for
    key derivation etc.

     Hash Function
   (TMMH)", Internet Draft, IETF, Work in Progress.

   [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
   Identifiers (URI): Generic Syntax", RFC 2396

Appendix func     | Value | Comments
     --------------------------------------------------------
     MIKEY-1       |     0 | Mandatory, Default (see Section 4.1.2-3.)
     MIKEY-256     |     1 | (as MIKEY-1 but using a HMAC with SHA256)
     MIKEY-384     |     2 | (as MIKEY-1 but using a HMAC with SHA384)
     MIKEY-512     |     3 | (as MIKEY-1 but using a HMAC with SHA512)

   * MCS ID: A - Payload Encoding

   This appendix describes 32-bit integer to identify the MCS. It is RECOMMENDED
    that it is chosen at random by the Initiator (the Initiator SHOULD
    however check for collisions). The Responder MUST use the same MCS
    ID in the response.

   * #CS: Indicates the number of Crypto Sessions that will be handled.
    Note that even though it is possible to use 256 CSs, this may not
    always be likely.

   * CS ID map type: specifies the method to uniquely map Crypto
    Sessions to the security protocol sessions.

     CS ID map type | Value | Comments
     -------------------------------------
     SRTP-ID        |     0 | Mandatory
   * CS ID map info: Identifies the crypto session(s) that the SA should
    be created for. The currently defined map type is the SRTP-ID
    (defined in A.1.1.).

A.1.1. SRTP ID

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ! Policy nr 1   !  SSRC 1       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ SSRC 1 cont.                                  ! ROC 1         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ ROC 1 cont.                                   ! Policy nr 2   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                           SSRC 2                              !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                           ROC 2                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                               :                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Policy nr #CS !           SSRC #CS                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~SSRC #CS (cont)!           ROC #CS                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ ROC #CS (cont)!
   +-+-+-+-+-+-+-+-+

   * Policy x: The policy applied for the stream with SSRC x. The same
    policy may apply for all CSs.

   * SSRC x: specifies the SSRC that MUST be used for the SRTP streams.
    Note that it is the sender of the streams who chooses the SSRC.
    Therefore, it might be that the Initiator of MIKEY can not fill in detail
    all fields. In this case, SSRCs that are not chosen by the
    Initiator are set to zero and the Responder fills in these field in
    the response message.

   * ROC x: Current roll-over counter used in SRTP. If the SRTP session
    has not started, this field is set to 0. This field is used to be
    able for a member to join and synchronize to an already started
    stream.

   NOTE: A stream using SSRC x will also have Crypto Session ID equal to
   x (NOT to SSRC).

A.2. Key data transport payload

   The Key data transport payload contains encrypted Key data payloads.
   It may contain one or more Key data payloads each including a PMK or
   a KEK. The last Key data payload MUST have its Next payload field set
   to Last payload. For all encoding,
   Network byte order an update message (see also Section 4.5.), it is
   allowed to skip the Key data payloads (which will result in that the
   Encr data len is equal to 0).

   If the transport method used is the pre-shared key method, this Key
   data transport payload MUST always be used.

A.1. Common header the last payload in the message (note
   that the Next payload field MUST be set to Last payload). The Common header MAC is
   then calculated over the entire message (as described in Section
   5.2.).

   If the transport method used is the public-key method, the
   Initiator's identity MUST be added in the encrypted data. This is
   done by adding the ID payload as the first payload, which then are
   followed by the Key data payloads. Note that for an update message,
   the ID MUST always still be present as sent encrypted to the first payload
   in each message. Responder (this is to
   avoid certain re-direction attacks) even though no Key data payloads
   is added after.

   The common header includes general description of MAC field is in the exchange message. public-key case calculated only over the Key
   data transport payload, where the MAC field and the Next payload
   field have been initiated with zeros.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  version Next payload  !  data type Encr alg      ! next payload  !R! Hash func Encr data len                 !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! MCS/CS ID type!                                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                           MCS/CS ID                        Encr data                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Mac alg       !        MAC                                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Encr alg: The common header contains encryption algorithm used to encrypt the following information: PMK.

     Encr alg      | Value | Comments
     -------------------------------------------
     AES-CM-128    |     1 | Mandatory (as defined in Section 4.2.3.)

   * version: Encr len: Length of encrypted part (in bytes).

   * Encr data: The encrypted PMK.

   * MAC alg specifies the version number authentication algorithm used.

     MAC alg       | Value | Comments
     --------------------------------------
     HMAC-SHA1-160 |     0 | Mandatory (see Section 4.2.4.)

   * MAC: The message authentication code of MIKEY.

   version = the entire message.

A.3. Envelope data payload

   The Envelope data payload contains the encrypted envelope key that is
   used in the public-key transport to protect the data in the Key data
   transport payload.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  ! C ! Data len                  ! Data          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the payload that is added after this
    payload.

   * data type: describes the type C: Envelope key cache indicator (see also Section 3.2., for more
    information of message (e.g. public-key transport
    message, verification message, error message).

   Data the usage).

     Cache type    | Value | Comment Comments
     --------------------------------------
   Pre-shared
     No cache      |     0 | Initiator's pre-shared The envelope key transport message
   PS ver msg MUST NOT be cached
     Cache         |     1 | Verification message of a Pre-shared message
   Public The envelope key should be cached
     Cache for MCS |     2 | Initiator's public-key transport message
   PK ver msg    |     3 | Verification message of a public-key message
   D-H init      |     4 | Initiator's DH exchange message
   D-H resp      |     5 | Responder's DH exchange message
   Error The envelope key should be cached, but only
                   |     6       | Error message to be used for the specific MCS.

   * next payload: identifies Data len: The length of the payload that is added after this
    payload. If no more payload follows, it data field (in bytes).

   * Data: The encrypted envelope key (padding and formatting MUST be set
    done according to Last
    payload.

   Next RSA/PKCS#1 if RSA is used).

A.4. DH data payload  | Value
   ---------------------
   Last

   The DH data payload  | carries the DH-value and indicates the DH-group
   used.

                        1                   2                   3
    0
   PS data       | 1
   PK data       | 2
   DH data       | 3
   Signature     | 4
   Timestamp     | 5
   ID            | 6
   Certificate   | 7
   Cert hash     | 8
   Ver msg       | 9
   n_start       |    10
   n_end         |    11
   SPI           |    12
   SP            |    13
   Error         |    14

   * R: flag to indicate whether a response is expected or not (this has
    only meaning when it is set by the Initiator).

   R = 0  ==> no response expected
   R = 1  ==> response expected 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload !   DH-Group    !  DH-key len                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        DH-value                               ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Type  ! KV    ! KV data (optional)                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * Hash func: Indicates next payload: identifies the hash function payload that has been/will be is added after this
    payload.

   * DH-Group: identifies the DH group used.

   Hash func

     DH-Group      | Value | Comments
   --------------------------------------------------------
   SHA-1
     --------------------------------------
     OAKLEY 5      |     0 | Mandatory, Default (see [SHA1])
   MD5           | Mandatory
     OAKLEY 1      | (see [MD5])
   SHA256     1 |
     OAKLEY 2      | (see [SHA256])
   SHA384        |     3 | (see [SHA256])
   SHA512        |     4     2 | (see [SHA256])

   * MCS/CS ID type: specifies DH-key len: The length of the id DH-value field (in bytes).

   * DH-value: The public DH-value.

   * Type: Indicates the type of the key included in the payload, i.e.
    if the resulting DH-key will be used to uniquely identify as a PMK or KEK (in the MCS
    and second
    case, the CS(s).

   MCS/CS ID type | Value | Comments
   -------------------------------------
   SRTP-ID        |     0 | Mandatory DH-key is not used directly as a KEK, but is derived
    according to Section 4.1.6). See also Appendix A.13. for pre-
    defined values.

   * MCS/CS ID: Identifies KV: Indicates the multimedia crypto session and/or type of key validity period specified. This may
    be done by using an SPI or by providing an interval in which the
    crypto session(s) that
    key is valid (e.g. in the SA should latter case, for SRTP this will be created for. The currently the
    SEQ nr range where the key is valid). See Appendix A.13. for pre-
    defined IDs are:

   SRTP ID values.

   * KV data: This includes either the SPI or an interval (see Appendix
    A.14.). If KV is NULL, this field is not included.

A.5. Signature payload

   The Signature payload carries the signature and its related data. The
   signature payload MUST always be the last payload in the PK transport
   and DH exchange messages.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   !   #CS         !                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   !                                                               !
   +                       SRTP MCS ID (80 bits)                   +
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                           SSRC 1                              !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                           SSRC 2                              !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                               :                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                           SSRC #CS Signature len                 ! Signature                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * #CS: Indicates the number Signature len: The length of Crypto Sessions, i.e. the number of
    SRTP streams. signature field (in bytes).

   * SRTP MCS ID: Signature: The signature (padding and formatting MUST be chosen at random by the Initiator (the
    Initiator SHOULD however check for collisions). done
    according to RSA/PKCS#1 if RSA is used).

A.6. Timestamp payload

   The Responder MUST
    use the same MCS ID in timestamp payload carries the response. time information.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload !   TS type     ! TS-value                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * SSRC x: specifies the SSRC that MUST be used for next payload: identifies the SRTP streams.
    Note payload that it is the sender of the streams who chooses the SSRC.
    Therefore, added after this
    payload. If no more payload follows, it might MUST be possible that the Initiator of MIKEY does
    can not fill in all fields. In this case, SSRCs that are not chosen
    by the Initiator are set to zero and Last
    payload. See Appendix A.1. for values.

   * TS type: specifies the Responder fills in these
    field in timestamp type used.

     TS type       | Value | Comments
     -------------------------------------
     NTP-UTC       |     0 | Mandatory (64-bits)
     NTP           |     1 | Mandatory (64-bits)

   * TS-value: The timestamp value of the response message.

   NOTE: A stream using SSRC x will also have Crypto Session specified TS type.

A.7. ID x.

A.2. PS data payload / Certificate payload

   The PS (pre-shared) data ID payload carries a uniquely-defined identifier.

   The certificate payload contains the encrypted PMK and the
   MAC an indicator of the entire message. The PS data payload MUST be added certificate
   provided as well as the
   last payload in the pre-shared transport message. certificate data.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! MAC alg  Next Payload ! Encr alg ID/Cert Type  ! Encr data ID/Cert len | Reserved                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Encr data                              ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        MAC                       ID/Certificate Data                     ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * MAC alg next payload: identifies the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * ID Type: specifies the authentication algorithm identifier type used.

   MAC alg

     ID Type       | Value | Comments
   --------------------------------------
   HMAC-SHA1-160
     ----------------------------------------------
     NAI           |     0 | Mandatory
   HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length. (see [NAI])
     URI           |     1 | Mandatory (see [URI])

   * Encr alg: The encryption algorithm used to encrypt Cert Type: specifies the PMK.

   Encr alg certificate type used.

     Cert Type     | Value | Comments
   -------------------------------------------
   AES-CM-128
     ----------------------------------------------
     X.509         |     0 | Mandatory
     X.509 URL     |     1 |
     X.509 Sign    |     2 | Mandatory

   AES-CM-128 is AES in Counter Mode (as defined in [SRTP] where the
   salting key = 0) with 128-bit block size and key. The IV MUST be
   created as IV = MCS ID || T32 || 0...0, where T32 is the 32 least
   significant bits of the timestamp and 0...0 is 16 bits of zeros.

   *
     X.509 Encr data: The encrypted PMK.    |     3 | Mandatory

   * MAC: ID/Cert len: The message authentication code length of the entire message.

A.3. PK data ID or Certificate field (in bytes).

   * ID/Certificate: The ID or Certificate data.

A.8. Cert hash payload

   The PK (public-key) data Cert hash payload contains the encrypted data from hash of the
   PK transport. certificate used. The
   hash function used MUST be the one specified in the Common header
   payload.
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  ! Key data len                  ! Hash func     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   ~                        Key data Hash                          ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the payload that is added after this
    payload.

   * Key data len: The length of Hash func: Indicates the Key data field (in bytes). hash function that has been/will be used
    (see also Section 4.2.1.).

     Hash func     | Value
     ----------------------
     SHA-1         |     0
     SHA256        |     1
     SHA384        |     2
     SHA512        |     3
     MD5           |     4

   * Key data: Hash: The encrypted PMK (padding and formatting MUST be done
    according to RSA/PKCS#1 if RSA hash data. Note: the hash length is used).

A.4. DH data implicit from the
    hash function used.

A.9. Ver msg payload

   The DH data Ver msg payload carries contains the DH-value and indicates calculated verification message in
   the DH-group
   used. PS/PK transport. Note that the MAC is calculated over the entire
   message as well as the IDs and Timestamp.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !   DH-Group    !  DH-key len Auth alg      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        DH-value Ver data                      ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * next payload: identifies the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * DH-Group: identifies Auth alg specified the DH group used.

   DH-Group authentication algorithm used for the
    verification message.

     Auth alg      | Value | Comments
   --------------------------------------
   OAKLEY 5
     ------------------------------------
     HMAC-SHA1-160 |     0 | Mandatory
   OAKLEY 1      |     1 |
   OAKLEY 2      |     2 |

   See [OAKLEY] for the definitions of the Oakley groups.

     HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length.

   * DH-key len: Ver data: The verification message data. Note: the length of is
    implicit from the DH-value field (in bytes).

   * DH-value: The public DH-value.

A.5. Signature payload

   The Signature authentication algorithm used.

A.10. Security Policy payload carries the signature and its related data.

   The
   signature payload MUST always be the last Security Policy payload in the PK transport
   and DH exchange messages. defines a set of policies that applies to
   a specific security/re-key protocol.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Signature len                 ! Next payload  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                        Signature                              ~ Policy nr     ! Prot type     ! Policy param  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Signature len: The length of next payload: identifies the signature field (in bytes).

   * Signature: The signature (padding and formatting payload that is added after this
    payload. If no more payload follows, it MUST be done
    according set to RSA/PKCS#1 if RSA is used).

A.6. Timestamp payload

   The timestamp Last
    payload. See Appendix A.1. for values.

   * Policy nr: Each security policy payload carries the time information. The current
   defined timestamp is as defined in NTP [NTP], i.e. a 64-bit number in
   seconds relative to 0h on 1 January 1900. An implementation must be
   aware of (and take into account) given a distinct
    number.

   * Prot type: defines the fact that security protocol or re-key protocol.

     Prot type     | Value |
     ---------------------------
     SRTPbasic     |     0 | see A.10.1.
     SRTPext       |     1 | see A.10.2.
     Re-key        |     2 | see A.10.3.

   * Policy param defines the counter will
   overflow approximately every 136th year. It is RECOMMENDED that policy for the
   time is always specified in GMT. security/re-key protocol.

A.10.1. SRTPbasic policy

   This policy specifies the policy for SRTP and SRTCP. All defined
   transform applies to both SRTP and (if used) SRTCP.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ! encr alg      ! encr key len  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload auth alg      ! auth key len  !   TS type auth tag len  ! salt key len  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                        TS-value                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTP PRF      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies Key Der rate  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NOTE: SRTP was not finalized by the payload that is added after date for this
    payload. If no more payload follows, it MUST draft's submission.
   Therefore, these parameters might be set to Last
    payload. See Appendix A.1. an issue for values. update!

   * TS type: encr alg specifies the timestamp type used.

   TS type desired encryption algorithm to be used in
    SRTP (and SRTCP, if used by SRTP).

     encr alg      | Value | Comments
   -------------------------------------
   NTP-GMT
     ------------------------------------------
     NULL          |     0 | Mandatory (64-bits)
   NTP
     AES-CM-128    |     1 | Mandatory (64-bits)

   Note that NTP-GMT
     AES-F8-128    |     2 |

     AES-CM-128 is the NTP time but calculated from GMT. This AES in CM with 128-bit block size.
     AES-F8-128 is AES in f8 mode with 128-bit block size.

   * encr key len: desired session encryption key length in bytes.

   * auth alg specifies the desired authentication algorithm to
   avoid time-zone problems. be used.

     auth alg      | Value | Comments
     -------------------------------------------
     NULL          |     0 | Mandatory
     TMMH-16       |     1 | Mandatory
     HMAC-SHA1     |     2 | Mandatory

   * TS-value: The timestamp value auth key len: desired session authentication key length in bytes.

   * auth tag len: desired length in bytes of the specified TS type.

A.7. ID payload / Certificate payload output tag of the MAC.

   * salt key len: The ID payload carries a uniquely-defined identifier. desired session salting key length in bytes.
    Note: do not mix this with the master salt that are exchanged.

   * PRF: Specifies the PRF used.

     SRTP PRF      | Value | Comments
     -------------------------------------------
     AES-CM        |     0 | Mandatory

   * Key Der rate: The certificate payload contains an indicator 2-logarithm of the desired key derivation rate.
    Note that this is possible as the key derivation rate must be a
    power of 2 in the certificate
   provided as well as range [0..2^16].

A.10.2. SRTPext policy

   This policy separates the certificate data. SRTP and SRTCP policies.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ! SRTP EA       ! SRTP EKL      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload SRTP AA       ! ID/Cert Type SRTP AKL      ! ID/Cert len SRTP ATL      ! SRTP SKL      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       ID/Certificate Data                     ~
   ! SRTxP PRF     ! SRTP KDR      ! SRTCP EA      ! SRTCP EKL     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTCP AA      ! SRTCP AKL     ! SRTCP ATL     ! SRTCP SKL     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTCP KDR     !
   +-+-+-+-+-+-+-+-+

   * next payload: identifies the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See SRTP EA: encryption algorithm for SRTP (see Appendix A.1. A.10.1. for values.
    defined ciphers).

   * ID Type: specifies the identifier type used.

   ID Type       | Value | Comments
   ----------------------------------------------
   NAI           |     0 | Mandatory (see [NAI])
   URI           |     1 | Mandatory SRTP EAL: encryption key length in bytes for SRTP.

   * SRTP AA: authentication algorithm for SRTP (see [URI]) Appendix A.10.1.
    for defined transforms).

   * Cert Type: specifies the certificate type used.

   Cert Type     | Value | Comments
   ----------------------------------------------
   X.509         |     0 | Mandatory
   X.509 URL     |     1 | SRTP AKL: authentication key length in bytes for SRTP.

   * ID/Cert len: The SRTP ATL: authentication tag length in bytes for SRTP.

   * SRTP SKL: salting key length in bytes for SRTP.

   * SRTxP PRF: pseudo-random function for SRTP and SRTCP (see Appendix
    A.10.1. for defined PRFs).

   * SRTP KDR: the 2-logarithm of the ID or Certificate field (in bytes). key derivation rate for SRTP (see
    also Appendix A.10.1).

   * ID/Certificate: The ID or Certificate data.

A.8. Cert hash payload

   The Cert hash payload contains SRTCP EA: encryption algorithm for SRTCP (see Appendix A.10.1. for
    defined ciphers).

   * SRTCP EAL: encryption key length in bytes for SRTCP.

   * SRTCP AA: authentication algorithm for SRTCP (see Appendix A.10.1.
    for defined transforms).

   * SRTCP AKL: authentication key length in bytes for SRTCP.

   * SRTCP ATL: authentication tag length in bytes for SRTCP.

   * SRTCP SKL: salting key length in bytes for SRTCP.

   * SRTCP KDR: the hash 2-logarithm of the certificate used. key derivation rate for SRTCP
    (see also Appendix A.10.1).

A.10.3. Re-key policy

   The
   hash function used MUST be the one specified in the Common header
   payload. following attributes is supported according to GKMARCH.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   ! Next Payload  KEK alg      !  auth alg     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !
   +-+-+-+-+-+-+-+-+                                               +
   ~                             Hash                              ~  KEK key len                  ! auth key len                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  mm alg       !
   +-+-+-+-+-+-+-+-+

   * next payload: identifies the payload that is added after this
    payload. KEK alg: The KEK ENCRYPTION ALGORITHM

     KEK alg       | Value
     -----------------------
     NULL          |     0
     3DES          |     1
     AES           |     2

   * Hash: auth alg: The hash data. Note: AUTHENTICATION ALGORITHM

     auth alg      | Value
     -----------------------
     NULL          |     0
     HMAC-SHA1     |     1
     HMAC-MD5      |     2

   * KEK key len: The key length of the hash KEK

   * auth key len: The key length is implicit from of the
    hash function used.

A.9. Ver msg authentication key

   * mm alg: The MEMBERSHIP MANAGEMENT ALGORITHM

     mm alg        | Value
     -----------------------
     NULL          |     0
     LKH           |     1

A.11. Rand payload

   The Ver msg Rand payload contains consist of a random bit-string. The Rand MUST be
   chosen at random and per MCS (note that the calculated verification message in if a MCS has several
   members, the PS/PK transport. Initiator MUST use the same Rand to all the members).

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  ! Auth alg payload  ! Rand len      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + Rand                          ~                            Ver data                           ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next Next payload: identifies the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * Auth alg specified the authentication algorithm used for the
    verification message.

   Auth alg      | Value | Comments
   ------------------------------------
   HMAC-SHA1-160 |     0 | Mandatory

   HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length.

   * Ver data: The verification message data. Note: the length is
    implicit from is added after this
    payload.

   * Rand len: Length of the authentication algorithm used.

A.10. n_start/n_end/SPI Rand (in bytes). SHOULD be at least 16.

   * Rand: a randomly chosen bit-string.

A.12. Error payload

   The n_start/n_end/SPI Error payload defines the n_start value, the n_end
   value or is used to specify the SPI as defined in Section 4.2. error(s) that may have
   occurred.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next payload Payload !   Length      | Error nr      !           Reserved            !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                       Valid from/Expires/SPI                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the payload that is added after this
    payload.

   * Length: The length of the n_start/n_end/SPI field (in bytes).

   * Valid from: Indicates the Index/Sequence number when the key is
    valid from. The field size is dependent on the security protocol.
    For SRTP, this field If no more payload follows, it MUST be 48 bits. set to Last
    payload. See Appendix A.1. for values.

   * Expires: Indicates the Index/Sequence number when the key expires.
    The field size is dependent on Error nr indicates the security protocol. For SRTP,
    this field MUST be 48 bits.

   * SPI: Indicates a SPI type of error that MUST be associated with the new PMK. The
    field size may be dependent on the security protocol.

A.11. was encountered.

     Error nr      | Value | Comment
     -------------------------------------------------------
     Auth failure  |     0 | Authentication failure
     Invalid TS    |     1 | Invalid timestamp
     Invalid hash  |     2 | PRF function NOT supported
     Invalid MA    |     3 | MAC algorithm NOT supported
     Invalid DH    |     4 | DH group NOT supported
     Invalid ID    |     5 | ID NOT supported
     Invalid Cert  |     6 | certificate NOT supported
     Invalid SP    |     7 | SP NOT supported
     Invalid SPpar |     8 | SP parameters NOT supported

A.13. Key data payload

   The SP key data payload defines contains PMKs and a optionally also a KEK. These
   are never included in clear, but as an encrypted part of the security protocol that will be used, and
   its related parameters. Key data
   transport payload.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next payload Payload ! SP Type  ! SP param KV    ! Key data len                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Key data                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Salt len (optional)   ! Salt data (optional)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        KV data (optional)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next Next payload: identifies the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * SP defines Type: Indicates the security protocol used.

   SP            | Value
   ---------------------
   SRTP          |     0

   * SP param defines type of the parameters for key included in the security protocol. SP param payload. Note
    that TEKs are not sent directly, but a PMK, which is dependent on the defined security protocol.

   For SRTP then used to
    derive the SP param is currently defined as:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 TEK (or TEKs if there are several crypto sessions).

     Type          | Value | Comments
     -------------------------------------------
     PMK           |     0 | A Pre-master key (used to derive TEKs from)
     PMK+SALT      |     1 | A PMK + a salt key are included
     KEK           |     2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   !  encr alg     !  auth alg     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Salt len     !  Salt | A Key-encrypting key                                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NOTE: SRTP was not finalized by

   * KV: Indicates the date for this draft's submission.
   Therefore, these parameters might type of key validity period specified. This may
    be done by using an issue for update!

   * encr alg specifies SPI or by providing an interval in which the desired encryption algorithm to
    key is valid (e.g. in the latter case, for SRTP this will be used.

   encr alg the
    SEQ nr range where the key is valid).

     KV            | Value | Comments
     -------------------------------------------
   NULL
     Null          |     0 | Mandatory
   AES-CM-128 No specific usage rule (e.g. a TEK
                   |       | that has no specific lifetime)
     SPI           |     1 | Mandatory
   AES-F8-128 The key is associated with the SPI
     Interval      |     2 |

   AES-CM-128 The key has a start and expiration time
                   |       | (e.g. an SRTP TEK)

    Note that when NULL is AES specified, any SPI or Interval is valid. For
    an Interval this means that the key is valid from the first
    observed sequence number until the key is replaced (or the security
    protocol is shutdown).

   * Key data len: The length of the Key data field (in bytes).

   * Key data: The PMK data or the KEK data.

   * Salt len: The salt key length in CM with 128-bit block size and key.
   AES-F8-128 bytes. Note that this field is AES
    only included if the salt is specified in f8 mode with 128-bit block size and key. the Type-field.

   * auth alg specifies Salt data: The salt key data. Note that this field is only included
    if the desired authentication algorithm to salt is specified in the Type-field. (For SRTP, this is the
    so-called master salt.)

   * KV data: This includes either the SPI or an interval (see Appendix
    A.14.). If KV is NULL, this field is not included.

A.14. Key validity data

   The Key validity data is not a payload, but part of either the Key
   data payload (see Appendix A.13.) or the DH payload (see Appendix
   A.4.). The Key validity data gives a guideline of when the key should
   be used.

   auth alg      | Value | Comments
   -------------------------------------------
   NULL          | This can be done, using an SPI or a lifetime range.

   SPI

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 | Mandatory
   TMMH-16-16    | 1 | ?
   HMAC-SHA1-32  | 2 | ?

   TMMH-16-16 is TMMH/16 [TMMH] with a 16-bit tag length.

   HMAC-SHA1-32 is HMAC using SHA-1 with a 32-bits tag length.

   * Salt len: 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SPI Length    ! SPI                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * SPI Length: The length of the salting key. SPI (or MKI) in bytes.

   * Salt key: The salting key to SRTP (must be random).

A.12. Error payload SPI: The Error payload is used to specify the error(s) that may have
   occurred. SPI (or MKI for SRTP).

   Interval
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload VF Length     ! Error nr Valid from                                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !           Reserved VT Length     ! Valid to (expires)                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies VF Length: Length of the payload Valid From field in bytes.

   * Valid From: Sequence number, timestamp, or other start value that is added after this
    payload. If no more payload follows, it MUST be set
    the security protocol uses to Last
    payload. See Appendix A.1. for values. identify the start position of the
    key usage.

   * Error nr indicates VT Length: Length of the type Valid To field in bytes.

   * Valid to: Sequence number, timestamp, or other expiration value
    that the security protocol can use to identify the expiration of error
    the key usage.

   Note that was encountered.

   Error nr      | Value | Comment
   -------------------------------------------------------
   Auth failure  |     0 | Authentication failure
   Invalid TS    |     1 | Invalid timestamp
   Invalid hash  |     2 | hash function NOT supported
   Invalid MA    |     3 | MAC algorithm NOT supported
   Invalid DH    |     4 | DH group NOT supported
   Invalid ID    |     5 | ID NOT supported
   Invalid Cert  | for SRTP usage, the key validity period for a PMK should be
   specified with either an interval, where the VF/VT length is equal to
   6 | certificate NOT supported
   Invalid SP    |     7 | SP NOT supported
   Invalid SPpar |     8 | SP parameters NOT supported bytes, or with an SPI (in SRTP denoted as a Master Key Identifier,
   MKI). It is recommended that if more than one SRTP stream is sharing
   the same keys and key update/re-keying is desired, this is handled
   using SPI rather than the From-To method.

Appendix B. - Payload usage summary

   Depending on the type of message, different payloads MUST and MAY be
   included. There are five distinct types of messages:

   * Pre-shared key transport message

   * Public key transport message

   * Verification message (for either pre-shared key or public key)

   * DH exchange message (bi-directional)

   * Error message

                 |          Message Type
   Payload type  | PS   | PK   | DH   | Ver  | Error
   -------------------------------------------------
   PS
   Key data       | trnsp| M      M#     -      -      -      -
   PK      O+
   Env data      | -      M*      M      -      -      -
   DH data       | -      -      M      M#     -      -
   Ver msg       | -      -      -      M      -
   Error         | -      -      -      -      M
   Timestamp     | M      M      M      -      O
   ID            | O      O      O      M      M      O      O
   Signature     | -      O      M      M      -      -      O+
   Certificate   | -      O      O      -      -
   Cert hash     | -      O      O      -      -
   n_start
   SP            | O      O      O      -      -
   n_end         | O      O      O      -      -
   SPI
   Rand          | O      O      O      - M@     M@     M@     -
   SP            | O      O      O      -      O

   # These messages are only mandatory for initial messages, i.e. for an
    update message of a MCS these are optional to include (see also
    Section 4.5.).

   + These messages may be included to authenticate the error message.
    However, before the other peer has been correctly authenticated, it
    is not recommended that the error messages are sent authenticated
    (as this would open up for DoS attacks).

   @ MUST only be included by the Initiator in the initial exchange.

   When a payload is not included, the default values for the
   information carried by it SHALL be used (when applicable). The
   following table summarizes what messages may be included in a
   specific message.

   For the encrypted sub payloads in the Key data transport payload, the
   following should hold:

                 | Message Type
   Payload type  | PS   | PK
   -----------------------------
   Keydata/PMK   | O      O
   Keydata/KEK   | O      O
   ID            | -      M

Revision history

   Changes from -00 draft:
   * Support for Re-key SA including KEK transport for all methods.
   * PK: Id included in the encrypted part to avoid "impersonation"
    attacks.
   * PK: Envelope approach for encryption of keys (as the size may
    exceed the limit that can be encrypted with one public-key
    operation).
   * Message processing updated
   * SDP, SIP and RTSP considerations updated
   * Group section updated
   * The use of Rand (instead of require a large and random MCS ID)
   * SRTP policies etc updated
   * Payload update (to support the above changes)
   * general editorial changes

   This Internet-Draft expires in May August 2002.