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

                                                          February,

                                                              June, 2002

                   MIKEY: Multimedia Internet KEYing
                     <draft-ietf-msec-mikey-01.txt>
                     <draft-ietf-msec-mikey-02.txt>

Status of this memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

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

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

Abstract

   Work

   Security protocols for securing real-time multimedia applications have started
   to appear. This has brought forward the need for a key management
   solution to support
   the security protocol. The key management these protocols. Such a solution has to fulfil requirements,
   which makes it be
   suitable to be used 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.................................. 4 Conventions.........................................4
   1.2. Definitions............................................. 4 Definitions....................................................4
   1.3. Abbreviations........................................... 5 Abbreviations..................................................5
   1.4. Outline................................................. 5 Outline........................................................5
   2. Basic Overview............................................ 6 Overview...................................................6
   2.1. Scenarios............................................... 6 Scenarios......................................................6
   2.2. Design Goals............................................ 7 Goals...................................................7
   2.3. System Overview......................................... 7 Overview................................................7
   2.4. Relation to GKMARCH..................................... 9 GKMARCH............................................8
   2.5. Existing solutions...................................... 9 solutions.............................................9
   3. Basic Key Transport and Exchange Schemes.................. 9 Methods.........................9
   3.1. Pre-shared key..........................................10 key................................................10
   3.2. Public-key encryption...................................10 encryption.........................................11
   3.3. Diffie-Hellman key exchange.............................12 exchange...................................13
   4. Key Management............................................14 Management..................................................14
   4.1. Key Calculation.........................................14 Calculation...............................................14
   4.1.1. Assumptions...........................................14 Assumptions.................................................14
   4.1.2. Notation..............................................14 Notation....................................................14
   4.1.3. PRF Description.......................................15 Description.............................................15
   4.1.4. Generating TEK keys from PMK...............................15 TGK....................................15
   4.1.5. Generating keys from an envelope/pre-shared key.......16
   4.1.6. Generating KEK from a DH-key..........................16 key.............15
   4.2 Pre-defined Transforms and Timestamp Formats.............16 Formats...................16
   4.2.1 Hash functions.........................................16 functions...............................................16
   4.2.2 Pseudo random number generator and PRF.................16 PRF.......................16
   4.2.3 Key data transport encryption..........................17 encryption................................16
   4.2.4 MAC and Verification Message function..................17 function........................17
   4.2.5 Envelope Key encryption................................17 encryption......................................17
   4.2.6 Digital Signatures.....................................17 Signatures...........................................17
   4.2.7 Diffie-Hellman Groups..................................17 Groups........................................17
   4.2.8. Timestamps............................................17 Timestamps..................................................17
   4.2.9. Adding new parameters to MIKEY..............................17
   4.3. Policies................................................17 Policies......................................................18
   4.4. Indexing Retrieving the Data SA....................................18 SA........................................18
   4.5. Re-keying TGK re-keying and MCS updating..............................18 CSB updating................................19
   5. Behavior and message handling.............................19 handling...................................20
   5.1. General.................................................19 General.......................................................20
   5.1.1. Capability discovery..................................19 Discovery........................................20
   5.1.2. Error handling........................................19 Handling..............................................21
   5.2. Creating a message......................................19 message............................................21
   5.3. Parsing a message.......................................21 message.............................................23
   5.4. Replay handling.........................................21 handling and timestamp usage...........................23
   5.5. Reliability.............................................22 Reliability...................................................25
   6. Integration with session establishment protocols..........23
   6.1. SDP integration.........................................23
   6.2. MIKEY with SIP..........................................23
   6.3. MIKEY with RTSP.........................................24
   6.4. MIKEY Interface.........................................25
   7. Groups....................................................26
   7.1. Simple one-to-"a few"...................................26
   7.2. Small-size interactive group............................27
   8. Security Considerations...................................27
   8.1. General.................................................27
   8.2. Key lifetime............................................28
   8.3. Timestamps..............................................29
   8.4. Identity protection.....................................30
   8.5. Denial of Service.......................................30
   8.6. Session establishment...................................30
   9. Conclusions...............................................30
   10. Acknowledgments..........................................31
   11. Author's Addresses.......................................31
   12. References...............................................31

   Appendix A - Payload Encoding................................34
   A.1. Encoding................................................25
   6.1. Common header payload...................................34
   A.1.1. payload (HDR)...................................25
   6.1.1. SRTP ID...............................................36
   A.2. ID.....................................................27
   6.2. Key data transport payload..............................37
   A.3. payload (KEMAC)............................28
   6.3. Envelope data payload...................................38
   A.4. payload (PKE)...................................29
   6.4. DH data payload.........................................38
   A.5. payload (DH)..........................................30
   6.5. Signature payload.......................................39
   A.6. payload (SIGN)......................................31
   6.6. Timestamp payload.......................................40
   A.7. payload (T).........................................31
   6.7. ID payload (ID) / Certificate payload........................40
   A.8. payload (CERT)..................32
   6.8. Cert hash payload.......................................41
   A.9. payload (CHASH).....................................32
   6.9. Ver msg payload.........................................41
   A.10. payload (V)...........................................33
   6.10. 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. Rand payload...........................................46
   A.12. payload (SP).................................33
   6.10.1. SRTP policy................................................34
   6.11. RAND payload (RAND)..........................................36
   6.12. Error payload..........................................46
   A.13. payload (ERR)..........................................36
   6.13. Key data payload.......................................47
   A.14. sub-payload.........................................37
   6.14. Key validity data .....................................48 data............................................38
   6.15. General Extension Payload....................................39
   7. Integration with session establishment protocols................40
   7.1. SDP integration...............................................40
   7.2. MIKEY within SIP..............................................40
   7.3. MIKEY with RTSP...............................................41
   7.4. MIKEY Interface...............................................42
   8. Groups..........................................................42
   8.1. Simple one-to-many............................................43
   8.2. Small-size interactive group..................................43
   9. Security Considerations.........................................44
   9.1. General.......................................................44
   9.2. Key lifetime..................................................45
   9.3. Timestamps....................................................45
   9.4. Identity protection...........................................46
   9.5. Denial of Service.............................................46
   9.6. Session establishment.........................................46
   10. IANA considerations............................................47
   11. Conclusions....................................................49
   12. Acknowledgments................................................49
   13. Author's Addresses.............................................49
   14. References.....................................................50
   14.1. Normative References.........................................50
   14.2. Informative References.......................................50
   Appendix B. A. - Payload usage summary..........................49 MIKEY - SRTP relation................................52
   Revision History.............................................50 history...................................................52

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.

   This document describes a key management solution, that address
   multimedia scenarios (e.g. SIP calls and 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: Session (CS): 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, an RTP stream and the
   corresponding RTCP as they are both protected by a single instance of
   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): Bundle (CSB): collection of one or more Crypto
   Sessions, which has can have common Pre-Master Key TEK Generation Keys 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 Session within an
   CSB.

   Crypto Session Bundle ID: unique identifier for the CSB.

   TEK Generation Key (PMK): (TGK): a bit-string agreed upon by two or more
   parties, associated with a SA (and consequently MCS). CSB. From the pre-
   master key, Traffic-encrypting TEK Generation 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 CSB's TGK.

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

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

   Responder: the responder Responder in the key management protocol.

   H(x):

   Data SA: information for the security protocol, including a cryptographic hash function with argument x
   Random(): TEK and a secure (pseudo-)random number generator
   set of parameters/policies.

   PRF(k,x):  a keyed pseudo-random function function.
   E(k,m):    encryption of m with the key k
   D(k,m):    decryption of m with k.

   PKx:       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 public key of x
   Cert_x:    Certificate of x
   k_p:       the PMK
   []         an optional piece of information
   {}         denotes zero or more occurrences
   ||         concatenation
   |          OR (selection operator)
   ^          exponentiation
   XOR        binary exclusive or

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

1.3. Abbreviations

   AES    Advanced Encryption Standard
   CM     Counter Mode
   CS     Crypto Session
   CSB    Crypto Session Bundle
   DH     Diffie-Hellman
   DoS    Denial of Service
   KEK    Key-encrypting Key
   MAC    Message Authentication Code
   MIKEY  Multimedia Internet KEYing
   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
   TGK    TEK Generation Key

1.4. Outline

   Section 2 describes the basic scenario scenarios and the design goals that for
   which MIKEY are based on. is intended. It also gives a brief overview of the entire
   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, re-keying, and 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.

   All definitions of the payloads in MIKEY are described in Section 6.

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

   Section 7 8 focuses on how MIKEY is used in group scenarios.

   The Security Considerations section (Section 8), 9), 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 secured
   multimedia streams (e.g. SRTP streams).

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

   Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one-
   to-many, many-to-many without centralized server (also denoted as
   small interactive group), and many-to-many with a centralized server.

   We identify in the following some typical scenarios which involve the
   multimedia applications we are dealing with (see also Figure 1.1.). 2.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 small-
      size interactive 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 all of 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.

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, above, except case c.

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

   * Tunneling. Possibility to "tunnel" "tunnel"/integrate MIKEY in session
     establishment protocols (e.g. SIP and RTSP).

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

2.3. System Overview

   One objective of MIKEY is to produce a Data security protocol SA
   (Data SA), including a traffic-encrypting key (TEK), which then can be is used as key
   the input to a Security Protocol. the security protocol.

   MIKEY can also be used supports the possibility to
   distribute a Group Re-key SA, including a key-encrypting key (KEK). A
   re-key SA can be used as input negotiate keys and parameters for an external group re-key
   more than one security protocol
   (see also [GKMARCH] for at the same time. Therefore, the
   concept of Crypto Session Bundle (CSB) is used, which is a collection
   of one or more information about group re-keying). Crypto Sessions that can have common TEK Generation
   Keys and security parameters.

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

   1. A set of security parameters and Pre-Master TEK Generation Key(s) (PMK) (TGK) are
     created
      agreed upon for the Multimedia Crypto Session Bundle (this is done by one of
      the three alternative key transport/exchange mechanisms, see
      Section 3).

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

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

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

   Figure 2.1. 2.2: Overview of the key management procedure.

   The security protocol MAY can 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.

   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. and the Crypto Sessions in a current
   Crypto Session Bundle (see Section 4.5). This is then done by executing
   the transport/exchange phase once again to derive a new PMK TGK (and
   consequently the TEKs). TEKs) or to update some other specific Crypto
   Session parameters.

2.4. Relation to GKMARCH

   The Group key management architecture (GKMARCH) [GKMARCH] describes a
   general architecture for group key management protocols. MIKEY is 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. receiver(s). Note that e.g. e.g., in a SIP-
   initiated call, the sender may also be a receiver. As MIKEY address addresses
   small interactive groups, a member may dynamically change between
   being a sender and receiver (or being both). both simultaneously).

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 with low latency, suitable for demanding cases
   such as real-
   time real-time data over heterogeneous networks, and small
   interactive groups.

3. Basic Key Transport and Exchange Schemes Methods

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

   Note that in general, keys for encryption and signing should be
   different, though for simplicity we use

   The pre-shared case is, by far, the same notation for both.

   Note also that in most efficient way to handle the following protocol definitions, things like
   security protocol parameters, headers etc., have intentionally been
   left out. In practice,
   key transport due to the messages sent are constructed by use of symmetric cryptography only. This
   approach has also the advantage that only a set small amount of
   payloads (see Appendix A), wherein data has
   to be exchanged. Of course, the different parameters may problematic issue is scalability.

   Public-key cryptography can be
   fitted. The signature/MAC used to create a scalable system. A
   disadvantage with this approach 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 it is done according to Figure 3.1. 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 resource consuming
   than the pre-shared key and sent to the
   responder. A random bit-string, Rand, is added together with a
   timestamp, T. The entire message approach. Another disadvantage is integrity protected by that in
   most cases a Message
   Authentication Code (MAC).

   The pre-shared secret, s, PKI (Public Key Infrastructure) is used 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).

   The Diffie-Hellman (DH) key exchange method has in general a higher
   resource consumption (both computationally and in bandwidth) than the
   previous ones. However, it has the advantage of providing perfect
   forward secrecy (PFS).

   Note that by using the DH method, the two involved parties will
   generate a unique random key (which neither of the parties are likely
   to significantly affect the outcome of). Therefore, it is not
   possible to use this DH method to establish a group TEK (as the
   different parties in the group would end up with different TEKs). It
   is not the intention of the DH method to work in this scenario, but
   be a good alternative in the special peer-to-peer case.

   The following general notation is used:

   HDR:  The general MIKEY header, which includes MIKEY CSB related data
         (e.g. CSB ID) and information mapping to the specific security
         protocol used. See Section 6.1 for payload definition.

   T:    The timestamp. See Section 6.6 for payload definition and also
         Section 5.4 for other timestamp related information.

   IDx:  The identity of x. See Section 6.7 for payload definition.

   RAND: Random bit-string, which is always included in the first
         message from the Initiator. It is not included in update
         messages of a CSB. See Section 6.11 for payload definition.

   SP:   The security policies for the data security protocol. See
         Section 6.10 for payload definition.

3.1. Pre-shared key

   In this method, the pre-shared secret key, s, is used to derive key
   material for both the encryption (encr_key) and the integrity
   protection (auth_key) as described in Section 4.1.5. The 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, Rand, E(encr_key,PMKs[||KEK])
   A

   Initiator                                 Responder

   I_MESSAGE = MAC(auth_key,K)

                               K, A
                    ---------------------->
                                       auth_key
   HDR, T, RAND, [IDi],
        {SP}, KEMAC          --->
                                         R_MESSAGE = PRF(s,..||Rand)
                                       V=MAC(auth_key,IDa||IDb||T),[IDb]
                               [V]
                    <----------------------

   Figure 3.1. Pre-shared key based transport mechanism.

   Authentication
                            [<---]       HDR, T, [IDr], V

   The main objective of the peers Initiator's message is provided by to transport one or
   more TGKs and a set of data protocol parameters to the MAC(s). The responder
   MAY return (if requested by Initiator) Responder in a
   secure manner. As the verification message, V.
   The verification message from the Responder is created
   optional, the Initiator indicates in the HDR whether it requires a
   verification message or not from the Responder.

   KEMAC = E(encr_key, {TGK}) || MAC(auth_key, I_MESSAGE).

   The KEMAC payload contains a set of encrypted sub-payloads and a MAC.
   Each sub-payload includes a, by applying the MAC function with
   an authentication Initiator, randomly and
   independently chosen TGK (and possible other related parameters,
   e.g., the key on lifetime). The MAC is a Message Authentication Code
   covering the IDs entire MIKEY message (with the exception of the MAC
   field) using the authentication key, auth_key. See Section 6.2 for
   payload definition and timestamp.

   As will be seen, Section 5.2 for exact definition of the pre-shared case is, by far, MAC
   calculation.

   The main objective of the most efficient
   way to handle verification message from the key transport due Responder is
   to obtain mutual authentication.

   V = MAC(auth_key, R_MESSAGE||IDi||IDr||T).

   The verification, V, is a MAC computed over the use Responder's entire
   message (with the exception of symmetric
   cryptography only. This approach has the MAC field), the timestamp (that
   was included in the Initiator's message), and the two parties
   identities, using the authentication key. See also Section 5.2 for
   the advantage that only a
   small amount exact definition of data has to be exchanged. Of course, the problematic
   issue is scalability. MAC calculation and Section 6.9 for
   payload definition.

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

   Initiator                                          Responder

   I_MESSAGE =
   HDR, T, RAND, [IDi|CERTi], {SP},
       [CHASH], KEMAC, PKE, SIGNi    --->
                                                   R_MESSAGE =
                                      [<---]       HDR, T, [IDr], V

   The main objective of the pre-shared key approach. Another disadvantage is that in
   most cases a PKI (Public Key Infrastructure) Initiator's message 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)
   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
                    ---------------------->
                                       {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, TGKs and optionally a KEK. The
   encrypted keys MUST also be integrity protected. The keys for
   encryption (encr_key) set of data protocol parameters to the keys and Responder in a
   secure manner. This is done using an envelope approach where the MAC (auth_key) TGKs
   are encrypted (and integrity protected) with keys derived from an "envelope" key (see Section 4.1.5). a
   randomly chosen "envelope key". The envelope key is then sent to the
   Responder encrypted using with the responder's public key (which of the Responder.

   As the verification message from the Responder is optional, 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 indicates in the HDR whether it requires a verification
   message consisting of or not from the encrypted PMKs and
   KEK, a timestamp, Responder.

   KEMAC = K || M
   K = E(encr_key, IDi || {TGK})
   M = MAC(auth_key, K).

   The KEMAC contains a Rand, and optionally its ID/Certificate set of encrypted sub-payloads and a
   hash of the certificate used to encrypt the envelope key. MAC. The entire
   message
   first sub-payload is finally signed and sent to the responder.

   As mentioned, identity of the initiator MAY include Initiator (not a hash of
   certificate, but generally the certificate of same ID as the public key used to encrypt one specified in the envelope key, env_key. The
   responder MUST then use
   certificate). Each of the private key corresponding to following sub-payloads includes a, by the
   specified certificate to decrypt
   Initiator, randomly and independently chosen TGK (and possible other
   related parameters, e.g., the encrypted envelope key. key lifetime). The responder MAY send encrypted part is
   then followed by a verification message, V, (as in MAC, which is calculated over the pre-
   shared case) to KEMAC payload
   (except the initiator. This message uses a MAC (e.g. HMAC),
   with an authentication key, field). The encr_key and the auth_key is derived from
   the PMK according envelope key, env_key (see Section 4.1.5). See also Section 6.2
   for payload definition.

   The PKE contains the encrypted envelope key. It is encrypted using
   the Responder's public key. If the Responder posses several public
   keys, the Initiator can use CHASH to indicate the key used.

   The SIGNi is a signature covering the entire MIKEY message,
   I_MESSAGE, using the Initiator's signature key.

   The main objective of the verification message from the Responder is
   to obtain mutual authentication. It is calculated in the same way as
   for the one in the pre-shared key mode (see also Section
   4.1.4. 5.2 for the
   exact definition). See Section 6.9 for payload definition.

   Note that there will be one encrypted IDr and possibly also one
   unencrypted IDr. The encrypted one is needed to avoid certain man-in-
   the-middle attacks, while the unencrypted is always useful for the
   Responder to immediately identify the Initiator.

   It is possible to cache the envelope key, so that it can be used as a
   pre-shared key. It is not recommended that to cache this key should be cached indefinitely
   (however it is up to the local policy to decide this). This function
   may be very convenient during the life-time of a Multimedia Crypto
   Session, Session
   Bundle, if a new crypto session needs to be added (or an old on expired one
   removed). Then, the pre-shared key can be used, instead of the public
   keys (see also Section 4.5.). 4.5). If the Initiator indicates that the
   envelope key should be cached, the key is at least to be cached
   during the life-time of the entire CSB.

   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

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

     -

   * it will be possible for A the Initiator to omit its own certificate
     and rely on
      B the Responder getting this certificate using other
     means. However, we recommend doing  this, only when it is
     reasonable to assume expect that
      B can be expected to have the Responder has cached the certificate
     from a previous connection. Otherwise accessing the certificate
     would mean additional roundtrips for B the Responder 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

   For a Diffie-Hellman (DH) key exchange method is
   also offered. Though, this approach fixed, agreed upon, group, (G,*), for g 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 G and a natural
   number x, we let g^x denote g*g*..*g (x times). Choices for the
   parameters are given in Section 4.2.7. The other transforms below are
   described in Section 4.2.

               A                                  B

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

   Protocol execution:
   I = (IDa|Cert_A)
   K

   With this method only one key is created, i.e. the DH-key, which is
   used as the TGK.

   Initiator                                          Responder

   I_MESSAGE = g^x,
   HDR, T, Rand [,I]
   S = Sign (SK_a,H(K))
                              K,S        I' = (IDb|Cert_B)
                    ----------------->   K' RAND, [IDi|CERTi],
        {SP}, DHi, SIGNi       --->
                                     R_MESSAGE = g^y,T,IDa,g^x [,I']
                                         S'
                               <---  HDR, T, [IDr|CERTr], IDi,
                                          DHr, DHi, SIGNr

   The main objective of the Initiator's message is to, in a secure way,
   provide the Responder with its DH value (i.e., DHi = Sign (SK_b,H(K'))
                             K',S'
                    <-----------------

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

   Figure 3.3. Diffie-Hellman key based exchange, g^xi, where x and y are xi
   is randomly chosen respectively by A and B. secretly chosen) and a set of data protocol
   parameters.

   The key exchange SIGNi is done according to Figure 3.3. The initiator
   chooses a random value x, and sends a signed signature covering the Initiator's MIKEY message,
   I_MESSAGE, using the Initiator's signature key.

   The main objective of the Responder's message including g^x, is to, in a
   Rand, secure way,
   provide the Initiator with its own DH value (i.e., DHr = g^xr, where
   xr is randomly and secretly chosen).

   The SIGNr is a timestamp to signature covering the responder (optionally also including its
   certificate or identity). Responder's MIKEY message,
   R_MESSAGE, using the Responder's signature key.

   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 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. Initiator. Both parties then calculate the PMK, g^(xy). The authentication is
   due to the signing of TGK, g^(xi*xr)
   from the DH values (and identities), and is
   necessary to avoid man-in-the-middle attacks. exchanged DH-values.

   Note that this approach does not require that the initiator 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 that both
   sides compute one signature, one verification and two DH-
   exponentiations.

4. Key Management

4.1. Key Calculation

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

   * TEKs from a PMK and the Rand,

   * a KEK from the DH-key TGK and the Rand, RAND value,

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

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

   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 place:

   csb_id: Crypto Session Bundle ID (32-bits unsigned integer)
   cs_id:  the  The Crypto Session ID (8-bits unsigned integer)
   Rand:
   RAND:   An (at least) 128-bit random bit-string sent by the
   Initiator. Initiator
          in the initial exchange.

   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 input key.
   seed:
   label:      a specific seed, label, dependent on the type of the key to be
               derived, the Rand, RAND, and the session IDs.
   outkey_len: desired length in bits of the output key.

   The key derivation method has the following output:

   outkey: the output key. key of desired length.

4.1.2. Notation

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

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

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

   While this SHA-1 is the default, HMAC using other hash function MAY be
   used, see Section 4.2.1. 4.2.2.

4.1.3. PRF Description

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

   * let n = inkey_len / 512, rounded up to the nearest integer
   * split the inkey into n blocks, inkey = s_1 || ... || s_n, where all
     s_i, except possibly s_n, are 512 bits each
   * let m = outkey_len / 160,  rounded up to the nearest integer

   (If

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

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

   PRF(inkey,seed)

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

4.1.4. Generating TEK keys from PMK TGK

   The key derivation method should be executed with the following
   parameters:
   parameters to generate a TEK:

   inkey:      PMK
   seed:      TGK
   inkey_len:  length of TGK
   label:      0x2AD01C64 || cs_id || mcs_id csb_id || Rand RAND
   outkey_len: length of the output TEK.

   Note, the cs_id is the id of the cs_id the TEK is supposed to 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 0x2AD01C64 with 0x1B5C7973 and
   0x15798CEF respectively, and outkey_len by the desired key-length(s)
   in each case.

   A salt key can be derived from the TGK as well. This is done by using
   the constant 0x39A2C14B.

   Note that the 32-bit constant integers (i.e. 0x2AD01C64 and or the once one
   replacing it) is are taken from the decimal digits of e (i.e.
   2.7182...), and where each constant consist of nine decimals digits
   (e.g. the first nine decimal digits 718281828 = 0x2AD01C64). The
   strings of nine decimal digits are not chosen at random, but as
   consecutive "chunks" from the decimal digits of e.

4.1.5. Generating keys from an envelope/pre-shared key

   inkey:      the envelope key or the pre-shared key

   seed:
   inkey_len:  the length of inkey
   label:      0x150533E1 || 0xFF || mcs_id csb_id || Rand RAND (for encryption key)
               or
               0x2D22AC75 || 0xFF || mcs_id csb_id || Rand RAND (for auth. key)
               or
               0x29B88916 || 0xFF || mcs_id csb_id || Rand RAND (for salting key)

   outkey_len: desired length of the 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 KEK.

4.2 Pre-defined Transforms and Timestamp Formats

   This section identifies standard transforms for MIKEY. The following
   transforms SHALL be used are mandatory to implement and support in the respective
   case. New transforms MAY can be added in the future. It is however recommended to be sparse with
   extensions as it usually only creates interoperability problems
   between old and newer versions. future (see Section 4.2.9
   for further guidelines).

4.2.1 Hash functions

   MIKEY SHALL use one of the following hash function: SHA-1 (see
   [SHA1], MD5 (see [MD5]), SHA256, SHA384, or SHA512 (see [SHA256] for
   the last three).

   In MIKEY, SHA-1 is default and the only default hash function that is mandatory to implement
   and support.
   implement.

4.2.2 Pseudo random number generator and PRF

   A cryptographically secure pseudo random number generator MUST be
   used for the generation of the keying material and nonces, e.g.
   [BMGL]. However, it is implementation specific which one to use (as
   the choice will not affect the interoperability).

   For the key derivations, the PRF specified in Section 4.1. MUST be
   supported. 4.1, using SHA-
   1 is mandatory to implement. This PRF MAY be extended by using SHA-256 SHA-
   256, SHA-384, or SHA-512, instead of SHA-1. However, it is not
   mandatory to support these.

4.2.3 Key data transport encryption

   The default and mandatory-to-support mandatory-to-implement key transport encryption is
   AES in counter mode, as defined in [SRTP, Section 4], [SRTP], using a key as derived in
   Section 4.1.5, and using initialization vector

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

   where S is a 112-bit salting key, also derived as in Section 4.1.5,
   and where T is the timestamp. timestamp sent by the Initiator.

   Note: this restricts the maximum size of the transported key to 2^23
   bits, which is still enough for all practical purposes.

4.2.4 MAC and Verification Message function

   The NULL encryption algorithm (i.e., no encryption) can be used (but
   is not mandatory to implement). Note that this MUST NOT be used
   unless the underlying protocols can guarantee the security. The main
   reason for including this is for certain specific SIP scenarios,
   where SDP is protected end-to-end. For this scenario, MIKEY SHALL use MAY be
   used with the pre-shared key method and the NULL encryption and
   authentication algorithm while relying on the security of SIP. Use
   this option with caution!

4.2.4 MAC and Verification Message function

   MIKEY uses a 160-bit authentication tags, tag, generated by HMAC with SHA-1
   as the default and mandatory to implement method, see [HMAC]. Authentication keys SHALL be
   are derived according to Section 4.1.5.

   The NULL authentication algorithm (i.e., no MAC) can be used together
   with the NULL encryption algorithm (but is not mandatory to
   implement). Note that this MUST NOT be used unless the underlying
   protocols can guarantee the security. The main reason for including
   this is for certain specific SIP scenarios, where SDP is protected
   end-to-end. For this scenario, MIKEY MAY be used with the pre-shared
   key method and the NULL encryption and authentication algorithm while
   relying on the security of SIP. Use this option with caution!

4.2.5 Envelope Key encryption

   When RSA

   The public key encryption algorithm applied is used for defined in, and
   dependent on the envelope encryption, MIKEY SHALL use
   RSA/PKCS#1, see [PKCS1]. certificate used.

4.2.6 Digital Signatures

   When RSA

   The signature algorithm applied is used for defined in, and dependent on the signatures, MIKEY SHALL use RSA/PKCS#1, see
   [PKCS1]. The default hash function SHALL be SHA-1.
   certificate used.

4.2.7 Diffie-Hellman Groups

   The Diffie-Hellman key exchange SHALL use one of the groups: OAKLEY 5,
   OAKLEY 1, or, OAKLEY 2, see [OAKLEY], where uses OAKLEY 5 is default [OAKLEY] as mandatory
   to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are
   not mandatory to support. implement).

4.2.8. Timestamps

   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) the 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 and/or the re-key protocol

4.2.9. Adding new parameters to MIKEY

   There are transmitted. two different parameter sets that can be added to MIKEY.
   The first is a set of MIKEY transforms (needed for the exchange
   itself), and the second is the data security protocol policies/
   parameters.

   New transforms and parameters SHALL be added by registering a new
   number for the payload, and also if necessary, document how the new
   transform/parameter is used. Sometimes it might be enough to point to
   an already specified document for the usage, e.g., when adding a new
   already standardized hash function.

   When adding support for a new data security protocol, the following
   MUST be specified:

   * A map sub payload (see Section 6.1). This is used to be able to map
     a crypto session to the right instance of the data security
     protocol and possibly also to provide individual parameters for
     each data security protocol.

   * a policy payload, i.e., specification of parameters and supported
     values.

   * general guidelines of usage.

4.3. Policies

   Included in the message exchange, policies for the Data security
   protocol are transmitted. The policies are defined in a separate
   payload and are specific to the security/re-key security protocol (see also Appendix A.10.). Section
   6.10). Together with the keys, the validity period of theses SHOULD these can also
   be specified. This could either can be done e.g., with an SPI (e.g. when a re-key protocol is used) (or SRTP MKI) or
   with an Interval (e.g. a sequence number interval for SRTP). Whether
   an SPI or an Interval should be used, depends on the security protocol (or
   re-key protocol).
   protocol.

   New parameters can be added to a policy by documenting how they
   should be interpreted by MIKEY and also by registering new values in
   the appropriate name space. If a completely new policy is needed, see
   Section 4.2.9 for guidelines.

4.4. Indexing Retrieving the Data SA

   The indexing retrieval of a Data SA will depend on the security protocol as
   different security protocols will have different characteristics.
   When adding support for a security protocol to MIKEY, some interface
   of how the security protocol retrieves the Data SA from MIKEY MUST be
   specified (together with policies that can be negotiated etc.).

   For SRTP the SSRC (see [SRTP]) is one of those. the parameters used to
   retrieve the Data SA. However, the SSRC is not sufficient. For the local lookup in
   retrieval of the MIKEY Data SA data base, from MIKEY, it is RECOMMENDED that the MIKEY
   implementation support supports a lookup using destination network address
   and port together with SSRC. Note that MIKEY does not send network
   addresses or ports. One reason to for this is that they may not be known
   in advance, as well as if a NAT exists in-
   between, in-between, problems may
   arise. When SIP or RTSP is used, the local view of the destination
   address and port can be obtained form from either SIP or RTSP. MIKEY can
   then use these addresses as the index for the Data SA lookup.

4.5. Re-keying TGK re-keying and MCS CSB updating

   A 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. In accordance to the GKMARCH,

   MIKEY supports the
   possibility to use an external group re-key protocol, by provides the re-key
   SA. However, an external group re-key protocol may not be necessary
   in a small group. Therefore, it is also possible means to update the MCS CSB (e.g. transporting a TEK new
   TGK/TEK or adding a crypto session parameter) by using MIKEY. new Crypto Session to the CSB). The updating of
   the MCS CSB is done by the Initiator and performed by executing MIKEY
   again e.g. before a TEK expires, or when a new crypto session Crypto Session is
   added to the MCS. CSB. Note that MIKEY does not provide re-keying in the
   GKMARCH sense, only updating of the keys by normal unicast messages.

   When MIKEY is executed again to update the MCS, CSB, it MAY is 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. include may be left out.

   The new message exchange MUST use uses the same MCS CSB ID as the initial
   exchange, but a new timestamp. A new Rand MUST RAND is NOT be included in the
   message exchange (the Rand RAND will only have affect in the Initial
   exchange). New Crypto Sessions may be are added if desired in the update
   message. Therefore, the new MIKEY message does not need to contain
   keys.

   As explained in Section 3.2., 3.2, the envelope key may can be "cached" as a
   pre-shared key. key (this is indicated by the Initiator in the first
   message sent). If so, the "update message" SHOULD be is a pre-shared key message, not
   message (with the cached envelope key as the pre-shared key), i.e.,
   it MUST NOT be a public key message. If the public key message is
   used, but the envelope key was is not cached, the Initiator MUST provide
   a new encrypted envelope key that can be used in the verification
   message. However, the Initiator does not need to provide any other
   keys.

   A Multimedia

   Figure 4.1 visualizes the update messages that can be sent, including
   the optional parts. The big differences from the original message is
   mainly that it is optional to include TGKs (or DH values in the DH
   method).

   Initiator                                       Responder

   Pre-shared key method:

   I_MESSAGE =
   HDR, T, [IDi], {SP}, KEMAC          --->
                                               R_MESSAGE =
                                      [<---]   HDR, T, [IDr], V
   Public key method:

   I_MESSAGE =
   HDR, T, [IDi|CERTi], {SP}, {CHASH},
        [KEMAC], PKE, SIGNi           --->
                                               R_MESSAGE =
                                      [<---]   HDR, T, [IDr], V

   DH method:

   I_MESSAGE =
   HDR, T, [IDi|CERTi], {SP},
        [DHi], SIGNi                  --->
                                            R_MESSAGE =
                                      <---  HDR, T, [IDr|CERTr], IDi,
                                                 [DHr, DHi], SIGNr

   Figure 4.1: Update messages.

   By definition, a Crypto Session MAY Bundle can contain several Crypto
   Sessions. A problem that then MAY might occur is to synchronize the TGK
   re-keying if an SPI (or similar functionality, e.g., MKI) is not
   used. It is therefore recommended that an SPI or MKI is used, if more
   than one Crypto Session is used.

5. Behavior and message handling

   Each message that is sent by the Initiator or the Responder, is 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 indicates the responder's capabilities security policy to use (i.e. in terms of
   security protocol algorithms etc. etc). If the guess is wrong, then Responder does not support
   it (for some reason), the responder
   may Responder can together with an error
   message (indicating that it does not support the parameters), send
   back its own capabilities (negotiation) to let the initiator Initiator choose a
   common set of parameters. This is done by including one or more
   security policy payloads. Multiple attributes may can be provided in sequence.
   sequence in the response. This is done to reduce the number of
   roundtrips as much as possible. possible (i.e. in most cases, where the policy
   is accepted the first time, one roundtrip is enough). If the responder
   Responder does not accept the offer, the Initiator must go out with a
   new MIKEY message.

   If the Responder is not willing/capable to provide security or the
   parties simply cannot agree, it is up to the parties' policies how to
   behave, i.e. accept an insecure communication or reject it.

   Note that it is not the intention of this protocol to have a very
   broad variety of options, as it is assumed that it should not be too
   common that an offer is denied.

5.1.2. Error Handling

   All errors due to the key management protocol SHOULD be reported to
   the peer(s) by an error message. The Initiator SHOULD therefore
   always be prepared to receive such message back from the responder. Responder.

   If the responder Responder does not support the set of parameters suggested by
   the initiator, Initiator, the error message SHOULD include the supported
   parameters (see also Section 5.1.). 5.1.2).

   The error message should be formed as:

   HDR, T, {ERR}, [V|SIGNr]

   Note that if the failure is due to the inability to authenticate the
   peer, the error message is OPTIONAL, and does not need to be
   authenticated. It is up to the local policy how to treat this kind of
   messages. However, if a signed error message in response to a failed
   authentication is returned this can be used for DoS purposes.
   Similarly, an unauthenticated error message could be sent to the
   Initiator in order to fool her to tear down the CSB. The local policy
   MUST take this into consideration. One advice would be not to
   authenticate such an error message, and when receiving an
   unauthenticated error message only see it as a recommendation of what
   may have gone wrong.

5.2. Creating a message

   To create a MIKEY message, a Common header payload is first created.
   This payload is then followed, depending on the message type, by a
   set of information payloads (e.g. DH-value payload, Signature
   payload, Security Protocol payload). The defined payloads and the
   exact encoding of each payload are described in Appendix A. Section 6.

                        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 message example.

   The process of generating a MIKEY message consists of the following
   steps:

   * Create a master payload an initial MIKEY message starting with the Common header
     payload.

   * Concatenate necessary payloads to the master payload (Appendix B
    lists which MIKEY message (see the
     exchange definitions for payloads MUST/MAY that may be used for the different messages). included and
     recommended order).

   * As a last step (for messages that must be authenticated, this also
     include the verification message), create and concatenate the
     MAC/signature payload
    containing the MAC/signature, where without the MAC/signature field filled in
     (if a Next payload field is
    initiated with zeros. included in this payload, it is set to
     Last payload).

   * Calculate the MAC/signature over the entire master payload MIKEY message, except
     the MAC/Signature field, and
    update add put the MAC/signature field with in the MAC/signature.
     field. In the case of the verification message, the IDa IDi || IDb IDr ||
     T MUST follow directly after the master payload MIKEY message in the MAC
     calculation.

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

5.3. Parsing a message

   In general, parsing is done by extracting payload the public key case, the Key data transport payload is generated
   by concatenating the IDi with the TGKs. This is then encrypted and
   placed in the data field. The MAC is calculated over the entire Key
   data transport payload except the MAC field. Before calculating the
   MAC, the Next payload field is set to zero.

   Note that all messages from the Initiator MUST use a unique
   timestamp. The Responder does not create a new timestamp, but uses
   the timestamp used by the Initiator.

5.3. Parsing a message

   In general, parsing of a MIKEY message is done by extracting payload
   by payload and checking that no errors occur (the exact procedure is
   implementation specific). However, for the Responder, it is recommended
   RECOMMENDED that the following procedure is followed:

   * Extract the Timestamp and check that it is within the allowable
     clock skew. skew (if not, discard the message). Also check the replay
     cache so that the message is not replayed (see also Section 5.4).
     If the message is replayed, discard it.

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

   * Verify the MAC/signature.

   * If the authentication is NOT not successful, an Auth failure Error
     message MUST be is possibly sent to the initiator Initiator (if SIP is used, this should
    be is
     signaled to SIP as a rejection of the offer). The message MUST is then be
     discarded from further processing, and the event SHOULD be
    logged. processing. See also Section 5.1.2 for
     treatment of errors.

   * If the authentication is successful, the message SHOULD be is processed.
     Though how it is processed is implementation specific.

   * If any unsupported parameters or errors occur during the
     processing, these SHOULD be are reported to the Initiator by sending an
     error message. The processing SHOULD is then be aborted. The error message MAY
     can also include payloads to describe the supported parameters. If
     SIP is used, this should be is signaled to SIP as a rejection of the offer
     (see also Section 6.2.). 7.2).

   * If the processing was successful and if needed, a verification/response verification/
     response message is created and sent to the Initiator.

5.4. Replay handling

   * Each Responder MUST utilize and timestamp usage

   MIKEY does not use a challenge-response mechanism for replay cache in order to remember
   handling, instead timestamps are used. This requires that the
    messages presented within clocks
   are synchronized. The required synchronization is dependent on the allowable clock skew (see also
    Section 8.3., timestamp considerations).

   * Replayed
   number of messages MUST NOT that can be processed.

   * A message SHOULD cached. If we could assume an
   unlimited cache, the terminals would not need to be deleted from synchronized at
   all (as the cache when it is outdated with
    respect to could then contain all previously messages).
   However, if there are restrictions on the clock skew.

   * Due to physical limitations, size of the replay cache SHOULD be set cache,
   the clocks will need to
    store up be synchronized to a maximum number some extent. In short, one
   can in general say that it is a tradeoff between the size of the
   replay cache and the required synchronization.

   Timestamp usage prevents against replay attacks under the following
   assumptions:

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

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

   * Each Responder utilize a replay cache in order to remember the
     messages (see below for more
    details). presented within an allowable clock skew (which is set by
     the local policy).

   * Replayed and outdated messages, i.e., messages that can be found in
     the replay cache or which have an outdated timestamp, are
     discarded and not processed.

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

   For

   In a client-server scenario, servers may be the entities that will
   have the highest work load. It is therefore RECOMMENDED that the
   servers are the Initiators of MIKEY. This will result in that the
   servers will not need to 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.

   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 acceptable). If a client,
   DoS attack is launched and the replay cache grows too large, MIKEY
   MAY dynamically decrease the looseness so that the replay cache
   becomes manageable.

   The maximum number of messages it that a client will recall need to cache may
   vary depending on the capacity of the client itself and the network,
   but also the number of expected messages should be taken into
   account.
   The following is

   For example, assume that we can at most spend 6kB on a recommendation of how the maximum size replay cache.
   Assume further that we need to store 30 bytes for each incoming
   message (the hash of the
   replay cache may be calculated:

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

   where

   A: maximum memory blocks message is 20 bytes). This implies that it
   is possible to allocate (for simplicity: 1
   memory block can contain cache approximately 204 messages. If the information from one message)

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

   x: #max expected
   number of messages per "clock skew"

   block_size: size of minute can be estimated, the message to clock skew can
   easily be cached (note calculated. E.g., in a SIP scenario where the client is
   expected in the most extreme case, a few calls per minute (assume 10
   at most in this example), the clock skew that it will
   probably not can be needed used is
   approximately 20 minutes.

   In a more extreme case, where the maximum number of incoming messages
   are assumed to cache be on the entire message, instead order of 120 messages per minute, and a hash
   requirement that the clock skew is on the order of 10 minutes, a 48kB
   replay cache would be required.

   One recommendation is to fix a size for the message replay cache, and let the timestamp might
   allowable clock skew be enough). large. As the replay cache grows, the clock
   skew is decreased depending on how many percent of the replay cache
   that are used.

   In case of a DoS attack, 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

   If MIKEY is integrated with a transporting protocol, the
   reliability scheme of the latter may be applied. Otherwise, sent on an unreliable transport, the basic processing
   applied to ensure protocol reliability is the following.

   The transmitting entity (initiator (Initiator or responder) Responder) MUST:

   * Set a timer and initialize a retry counter

   * If the 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 file.

6. Integration with session establishment protocols Payload Encoding

   This section describes how MIKEY should be integrated with SDP, SIP
   and RTSP. It in detail all the payloads. For all encoding,
   Network byte order is based on [KMASDP], which describes extensions to SDP
   and SIP to carry key management protocol MUST information. always used.

6.1. SDP integration

   SDP descriptions [SDP] can Common header payload (HDR)

   The Common header payload MUST always be carried by several protocols, such present as
   SIP and RTSP. Both SIP and RTSP often use SDP to describe the media
   sessions. Therefore, it is also convenient to be able to integrate
   the key management in the session description it is supposed to
   protect. [KMASDP] describes attributes that SHOULD be used by a key
   management protocol that is integrated first payload
   in SDP. The following two SDP
   attributes MUST be used by MIKEY.

   a=keymgmt-prot:<protocol>
   a=keymgmt-data:<data> each message. The keymgmt-prot attribute indicates common header includes general description of
   the key management protocol.
   Therefore, it MUST be set to "MIKEY", i.e.

   a=keymgmt-prot:MIKEY

   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 part is used to transport the actual key management type    ! next payload
   message. Due to  !V! PRF func    !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         CSB ID                                !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! #CS           ! CS ID map type! CS ID map info                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The common header contains the text based nature following information:

   * version: the version number of SDP, this part MUST be
   base64 encoded to avoid illegal characters but in MIKEY.

     version = 1

   * data type: describes the same time
   avoiding a too large type of message expansion.

   a=keymgmt-data:<base64 encoded data>

   Example

        |          a=keymgmt-prot:MIKEY
        |          a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
   MCS <   CS (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 <  m=audio 49000 RTP/SAVP 98 |          a=rtpmap:98 AMR/8000 Verification message of a Pre-shared
                   |       | key message
     Public key    |  CS     2 <  m=video 2232 RTP/SAVP 31

   In this example the multimedia crypto session consists | Initiator's public-key transport message
     PK ver msg    |     3 | Verification message of two crypto
   sessions (one audio stream and one video stream) to be protected by
   SRTP (as indicated by the "RTP/SAVP" profile).

6.2. MIKEY with SIP

   In a basic SIP call between two parties (see Figure 6.1.), SIP
   (Session Initiation Protocol, [SIP]) is used as a session
   establishment protocol between two or more parties. In general an
   offer is made, whereby it is either accepted or rejected by the
   answerer. SIP complies to 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 offer/answer model [OFFANS], to which
   MIKEY over SIP MUST be compliant with as well.

                          ---------           ---------
                          |A's SIP| <.......> |B's SIP|
                          |Server payload that is added after this
     payload.

     Next payload  |    SIP    |Server Value |
                          ---------           ---------
                               ^                ^
                               .                .
             ++++         SIP  .                .   SIP         ++++ Section
     ------------------------------
     Last payload  |     0 | <.............                ..............> -
     KEMAC         |     1 | 6.2
     PKE           |     2 | 6.3
     DH            |     3 |
             ++++ <-------------------------------------------> ++++
                                      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 MIKEY Initiator and the SIP answerer will
   be the MIKEY responder. This implies 6.4
     SIGN          |     4 | 6.5
     T             |     5 | 6.6
     ID            |     6 | 6.7
     CERT          |     7 | 6.7
     CHASH         |     8 | 6.8
     V             |     9 | 6.9
     SP            |    10 | 6.10
     RAND          |    11 | 6.11
     ERR           |    12 | 6.12
     Key data      |    20 | 6.13
     General Ext.  |    21 | 6.15

     Note that in some of the offer, payloads cannot possibly come right after
     the MIKEY
   Initiator message SHOULD be included, and in header (such as "Last payload", "Signature", etc.). However,
     the answer Next payload field is generic for all payloads. Therefore, a
     value is allocated for each payload.

   * V: flag to the offer,
   the MIKEY Responder indicate whether a verification message SHOULD be included.

   If the MIKEY part of the offer is expected or
     not accepted, a MIKEY error message
   SHOULD be provided in (this has only meaning when it is set by the answer (following Initiator).

     V = 0  ==> no response expected
     V = 1  ==> response expected
   * PRF func: Indicates the PRF function that has been/will be used for
     key derivation etc.

     PRF func      | Value | Comments
     --------------------------------------------------------
     MIKEY-1       |     0 | Mandatory, Default (see Section 5.1.). MIKEY MUST
   always signal 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)

   * CSB ID: A 32-bit integer to SIP whether identify the MIKEY message was an acceptable
   offer or not. CSB. It may be assumed is RECOMMENDED
     that it is chosen at random by the offerer knows Initiator. This ID MUST be
     unique between each Initiator-Responder pair, i.e., not globally
     unique. An Initiator MUST check for collisions when choosing the identity of
     ID (if the
   answerer. However, unless Initiator already has one or more established CSB with
     the initiator's identity can be derived
   from SIP itself, Responder). The Responder uses the initiator (caller) MUST provide same CSB ID in the identity to
     response.

   * #CS: Indicates the callee. It number of Crypto Sessions that will be handled.
     Note that even though it is recommended possible to use the same identity for both SIP
   and MIKEY.

   Updating of the MCS (e.g. TEK update) SHOULD only be seen as a new
   offer. Note that 255 CSs, it might not be necessary to send all information,
   such as the certificate, due to the 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 not
     likely that a server. CSB will include this many CSs. The media session integer 0 is typically
   obtained via an SDP description, received by a DESCRIBE message, or
   by other means (e.g., HTTP). To
     interpreted as no CS included. This may be able to pass the MIKEY messages in
   RTSP messages which does not contain an SDP description, the RTSP
   KeyMgmt header (defined case in [KMASDP]) is used. This header includes
   basically the same fields as the SDP extensions.

   In an RTSP scenario, the RTSP server and initiator will be the same
   entity. The Initiator/RTSP server includes initial
     setup message.

   * CS ID map type: specifies the MIKEY message in a SDP
   description. When responding method to this, the client uses the defined
   RTSP header uniquely map Crypto
     Sessions to send back the answer (included in security protocol sessions.

     CS ID map type | Value
     -----------------------
     SRTP-ID        |     0

   * CS ID map info: Identifies the SETUP message).

   Note crypto session(s) that it is the server that will SA should
     be created for. The currently defined map type is the Initiator of MIKEY SRTP-ID
     (defined in
   this case. This has some advantages. First, the server will always be
   able to chose the key for the content it distributes. Secondly, it
   will then have the possibility to use Section 6.1.1).

6.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 no 1   ! SSRC 1                                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ SSRC 1 (cont) ! ROC 1                                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ ROC 1 (cont)  ! Policy no 2   ! SSRC 2                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ SSRC 2 (cont)                 ! ROC 2                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ ROC 2 (cont)                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

   :                               :                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Policy no #CS !           SSRC #CS                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~SSRC #CS (cont)!           ROC #CS                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ ROC #CS (cont)!
   +-+-+-+-+-+-+-+-+

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

   * SSRC x: specifies the same
   content SSRC that are streamed/sent to more than one client.

   To MUST be able to have a server initiated MCS update procedure, either used for the ANNOUNCE message or SRTP streams.
     Note that it is the SET_PARAMETER message SHOULD sender of the streams who chooses the SSRC.
     Therefore, it might be used to
   send that the updated MIKEY material. A disadvantage Initiator of using these, is MIKEY can not fill in
     all fields. In this case, SSRCs that they are not mandatory chosen by the
     Initiator are set to implement. Note that zero and the ANNOUNCE
   method has Responder fills in these field
     in the possibility to send SDP descriptions to update
   previous ones (i.e. it response message. It is not needed in general RECOMMENDED or required
     to use the RTSP KeyMgmt header).

6.4. MIKEY Interface

   The SDP, SIP, and RTSP processing is defined in [KMASDP]. However, it
   is necessary that MIKEY can work properly with these protocols.
   Therefore, the interface between MIKEY unique SSRCs (both to avoid RTP SSRC collision, and these protocols MUST
   provide certain functionality (however, exactly how the interface
   looks like is very implementation dependent).

   MIKEY MUST have from an interface towards the SIP/SDP or RTSP/SDP
   implementation that allows for:

   * MIKEY
     SRTP perspective, to receive information about avoid two-time pad problems if the sessions negotiated. This is
    to some extent implementation dependent. But it same TEK
     is recommended
    that, used for more than one stream).

   * ROC x: Current rollover counter used in SRTP. If the case of SRTP streams, the number of SRTP streams are
    included (and the direction of these). The destination addresses
    and ports session
     has not started, this field is also recommended set to provide 0. This field is used to MIKEY.

   * MIKEY be
     able for a member to receive incoming MIKEY messages. This MUST join and synchronize to an already started
     stream.

   NOTE: The stream using SSRC x will also include
    the possibility have Crypto Session ID equal
   to return the status of the incoming message x (NOT to
    SIP/SDP SSRC).

6.2. Key data transport payload (KEMAC)

   The Key data transport payload contains encrypted Key data payloads
   (see Section 6.13 for definition of Key data payloads). It may
   contain one or more Key data payloads each including a TGK. The last
   Key data payload has its Next payload field set to RTSP/SDP, i.e. whether the MIKEY Last payload. For
   an update message was accepted
    or not.

   * SIP/SDP or RTSP/SDP (see also Section 4.5), it is allowed to receive information from MIKEY, this include
    the receiving skip the MCS ID, receiving
   Key data payloads (which will result in that the SSRCs for SRTP. It Encr data len is also
    RECOMMENDED that extra information about errors can be received.

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

   * tearing down a MIKEY MCS (e.g. if 0).

   If the SIP sessions transport method used is shutdown, the
    MCS SHOULD also be shutdown)
   Note that if a MCS has already been established, it pre-shared key method, this Key
   data transport payload is still valid
   for the SIP/SDP or RSP/SDP implementation to request a new last payload in the message
   from MIKEY, e.g. when a new offer (note that
   the Next payload field is issued. MIKEY SHOULD then send
   an update message set to Last payload). The MAC is then
   calculated over the Responder (see also entire MIKEY message (as described in Section 4.5).

7. Groups

   What has been discussed up to now is not limited to single peer-to-
   peer communication, but can be
   5.2).

   If the transport method used in small-size groups and simple
   one-to-many scenarios. This section describes how MIKEY is used in a
   group 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 most simple one-to-many/"a few" scenario, a server public-key method, the
   Initiator's identity is
   streaming to a small group of clients. In this scenario RTSP or SIP
   could be used for added in the registration and encrypted data. This is done by
   adding the key management set up. The
   streaming server would act ID payload as the Initiator of MIKEY. In this
   scenario first payload, which then are followed
   by the pre-shared key or public key transport mechanism will be
   appropriate to use to transport Key data payloads. Note that for an update message, the same PMK ID is
   still sent encrypted to all the clients
   (which will result Responder (this is to avoid certain re-
   direction attacks) even though no Key data payloads is added after.

   The MAC field is in common TEKs for the group).

   Note, if the same PMK/TEK(s) should be used by all the group members, public-key case calculated only over the streaming server MUST specify Key
   data transport payload except the same MCS_ID MAC field and CS_ID(s) for where the session Next
   payload field has been set to all the group members. Security considerations arising
   from using zero (see also Section 5.2).

                        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  ! Encr alg      ! Encr data len                 !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        Encr data                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Mac alg       !        MAC                                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the same key payload that is added after this
     payload (see Section 6.1 for several streams in defined values).

   * Encr alg: The encryption algorithm used to encrypt the underlying
   security protocol MUST be considered.

7.2. Small-size interactive group

                    ++++          ++++
                    |A TGK.

     Encr alg      | -------> |B Value | Comments
     -------------------------------------------
     AES-CM        |     1 | <------- Mandatory (as defined in Section 4.2.3)
     NULL          |     2 |
                    ++++          ++++
                     ^ Very restricted usage, see Section 4.2.3!

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

   * Encr data: The encrypted TGK sub-payloads (see Section 6.13).

   * MAC alg specifies the authentication algorithm used.

     MAC alg       | Value | ^
                     | |          | |
                     | |   ++++ Comments
     --------------------------------------
     HMAC-SHA1-160 |     0 | Mandatory (see Section 4.2.4)
     NULL          | --->|C |<---     1 |
                     ------|  |------
                           ++++

   Figure 7.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 Very restricted usage, see Section 4.2.4!

   * MAC: The message authentication code of the security
   for its outgoing streams. In these scenarios, entire message.

6.3. Envelope data payload (PKE)

   The Envelope data payload contains the pre-shared encrypted envelope key and that is
   used in 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 protect the small size of data in the group, unicast SRTP is Key data
   transport payload. The encryption algorithm used
   between the clients. Each client may set up is implicit from the security for its
   outgoing stream(s) to
   certificate/public key used.

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

   As payload that is added after this
     payload.

   * C: Envelope key cache indicator (see also Section 3.2, for more
     information of the one-to-"a few" case, the streaming client usage).

     Cache type    | Value | Comments
     --------------------------------------
     No cache      |     0 | The envelope key MUST specify the
   same MCS_ID and CS_ID(s) for its outgoing sessions if the same
   PMK/TEK(s) should NOT be used for all the group members. cached
     Cache         |     1 | The same
   security considerations envelope key MUST be cached
     Cache for key-sharing also apply.

8. Security Considerations

8.1. General

   No chain is stronger than its weakest link. CSB |     2 | 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 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 envelope key appears to MUST be an "overkill",
   leading cached, but only
                   |       | to unnecessary time delays. Therefore, key size for the key-
   exchange mechanism SHOULD be weighed against used for the size specific CSB.

   * Data len: The length of the
   exchanged key.

   Moreover, if the PMKs are not random, a brute force search may be
   facilitated, again lowering the effective data field (in bytes).

   * Data: The encrypted envelope key size. Therefore, care
   MUST be taken when designing the (pseudo) random generators for PMK
   generation.

   For the selection of (if nothing else stated in the hash function, SHA-1 with 160-bit output
     certificate, padding and formatting 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 done according to
     RSA/PKCS#1 if RSA is used).

6.4. DH data payload (DH)

   The DH data payload carries the real-time aspects in the
   scenarios we are treating, hash size slightly below 256 are
   acceptable as DH-value and indicates the normal "existential" collision probabilities would
   be of secondary importance.

   In a Multimedia Crypto Session, the Crypto Sessions (audio, video
   etc) share DH-group
   used.

                        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-value                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Reserv! KV    ! KV data (optional)                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the same PMK as discussed earlier. From a security point
   of view, payload that is added after this
     payload.

   * DH-Group: identifies the criterion to be satisfied DH group used.

     DH-Group      | Value | Comments
     --------------------------------------
     OAKLEY 5      |     0 | Mandatory
     OAKLEY 1      |     1 |
     OAKLEY 2      |     2 |

   * DH-value: The public DH-value (the length is that implicit from the encryption of
     group used).

   * KV: Indicates the
   individual Crypto Sessions are performed "independently". In MIKEY
   this is accomplished type of key validity period specified. This may
     be done by having unique Crypto Session identifiers (see
   also Section 4.1.). The TEK derivation method assures this using an SPI (alternatively an MKI) or by providing cryptographically independent TEKs to distinct Crypto
   Sessions (within the Multimedia Crypto Session), regardless of the
   security protocol used.

   Specifically, an
     interval in which the key derivations are implemented by a pseudo-random
   function. The one used here is a simplified version of that used valid (e.g. in
   TLS [TLS]. Here, we use only one single hash function, whereas TLS
   uses two different functions. Note that the use of latter case, for
     SRTP this will be the Rand nonce in index range where 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). valid). See
     Section 6.13 for pre-defined values.

   * KV data: 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 includes either the public-key scheme provides
   perfect forward secrecy. If mutual contribution SPI/MKI or perfect forward
   secrecy an interval (see
     Section 6.14). If KV is desired, the Diffie-Hellman scheme MUST be used.

   Forward/backward security: if NULL, this field is not included.

6.5. Signature payload (SIGN)

   The Signature payload carries the PMK signature and its related data. The
   signature payload is exposed, all TEKs generated
   from it are compromised. However, under always the assumption that last payload in the
   derivation function PK transport and
   DH exchange messages. The signature algorithm used is a pseudo-random function, disclosure of an
   individual TEK does not compromise other (previous or later) TEKs
   derived implicit from
   the same PMK.

8.2. Key lifetime

   Even if the lifetime certificate/public key used.

                        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                 ! Signature                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Signature len: The length of a PMK is not specified, it MUST be taken into
   account that the encryption transform signature field (in bytes).

   * Signature: The signature (if nothing else stated 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
     certificate, padding 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, formatting is done according to
     RSA/PKCS#1 if RSA is used).

6.6. Timestamp payload (T)

   The timestamp payload carries 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 timestamp 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                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the crypto stream, possibly
   useful for an attacker, payload that is (with constant probability) expected to
   occur added after a total of roughly 2^(b/2) encrypted b-bit blocks (using
   random IVs). For security margin, re-keying this
     payload. If no more payload follows, it MUST be triggered well in
   advance compared set to the above bound. Last
     payload. See [BDJR] Section 6.1 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: values.

   * Each host MUST have a clock which is at least "loosely
    synchronized" to the time of TS type: specifies the other hosts. timestamp type used.

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

   * If TS-value: The timestamp value of 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 specified TS type.

6.7. ID payload (ID) / Certificate payload (CERT)

   The ID payload carries a very high load of incoming
   messages and may therefore allow the degree of looseness to be on the
   order uniquely-defined identifier.

   The certificate payload contains an indicator 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 certificate
   provided as well as the replay cache becomes
   manageable.

   Servers may be 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload ! ID/Cert Type  ! ID/Cert len                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                       ID/Certificate Data                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the entities payload that will have the highest work load. It is also recommended that added after this
     payload. See Section 6.1 for values.

   * ID Type: specifies the servers are identifier type used.

     ID Type       | Value | Comments
     ----------------------------------------------
     NAI           |     0 | Mandatory (see [NAI])
     URI           |     1 | Mandatory (see [URI])

   * Cert Type: specifies the Initiators certificate type used.

     Cert Type     | Value | Comments
     ----------------------------------------------
     X.509v3       |     0 | Mandatory
     X.509v3 URL   |     1 | plain ASCII URL to the location of MIKEY.
   This will result in that the servers will not manage any significant
   replay cache as they will refuse all incoming messages that Cert
     X.509v3 Sign  |     2 | Mandatory (used for signatures only)
     X.509v3 Encr  |     3 | Mandatory (used for encryption only)

   * ID/Cert len: The length of the ID or Certificate field (in bytes).

   * ID/Certificate: The ID or Certificate data. The X.509 [X.509]
     certificates are not included as a
   response to an already (by bytes string using DER encoding as
     specified in X.509.

6.8. Cert hash payload (CHASH)

   The Cert hash payload contains the server) sent message.

   Practical experiences hash of Kerberos and other timestamp based system
   indicates the certificate used.

                        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  ! Hash func     ! Hash                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * next payload: identifies the payload that it is not always necessary to synchronize added after this
     payload.

   * Hash func: Indicates the
   terminals over hash function that is used (see also
     Section 4.2.1).

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

   * Hash: The hash data. Note: the network. Manual configuration could be a feasible
   alternative in many cases (especially hash length is implicit from the
     hash function used.

6.9. Ver msg payload (V)

   The Ver msg payload contains the calculated verification message in scenarios where
   the degree
   of looseness is high). However, pre-shared key and the choice must be carefully based
   with respect to public-key transport methods. Note that
   the usage scenario.

   The use of timestamps instead of challenge-response requires MAC is calculated over 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 entire MIKEY is anyway proposed to be
   transported over e.g. SIP, the identity may be exposed by this.
   However, if message as well as the transporting protocol is secured
   IDs and Timestamp (see also provides
   identity protection, MIKEY might inherit Section 5.2).

                        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      ! Ver data                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the same feature. How this
   should be done payload that is for future study.

8.5. Denial of Service

   This protocol added after this
     payload. If no more payload follows, it is resistant set to Denial of Service attacks in Last payload.
     See Section 6.1 for values.

   * Auth alg: specifies the sense
   that a responder does not construct any state (at MAC algorithm used for the key management
   protocol level) before it has authenticated verification
     message. See Section 6.2 for defined (MAC field) for defined
     values.

   * Ver data: The verification message data. Note: the initiator. However,
   this protocol, like many others, length is open to attacks that use spoofed
   IP addresses to create
     implicit from the authentication algorithm used.

6.10. Security Policy payload (SP)

   The Security Policy payload defines a large number set 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 policies 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 specific security 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next payload  ! Policy no     ! Prot type     ! Policy param  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ length (cont) ! Policy param                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Next payload: identifies 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 payload that a Source Origin Authentication scheme is applied added after this
     payload. See Section 6.1 for
   the values.

   * Policy no: Each security protocol.

9. Conclusions

   Work for securing real-time applications have started to appear. This
   has brought forward the need for policy payload must be given a key management solution to support distinct
     number.

   * Prot type: defines the security protocol. The key management has to fulfil requirements,
   which make it suitable in

     Prot type     | Value |
     ---------------------------
     SRTP          |     0 |

   * Policy param length: defines the context total length 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 the policy
     parameters 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 specific security protocol.

   * Policy param: defines the MSEC WG, Pasi Ahonen (with his group), Rolf Blom, and Magnus
   Westerlund, policy 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 specific security
     protocol.

   The Policy param part is built up by a set of the 38th Symposium on Foundations Type/Length/Value
   fields. For each security protocol, a set of
   Computer Science, IEEE, 1997, pp. 394-403.

   [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and
   Analysis possible types/values
   that can be negotiated are defined.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Type          ! Length        ! Value                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Type: specifies the type of Pseduo-randomness Primitives", Proceedings the parameter.

   * Length: specifies the length 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 the Value field (in bytes).

   * Value: specifies the value 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 the parameter.

6.10.1. SRTP policy

   This policy specifies the policy 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., SRTP and
   Norrman, K., "Key Management Extensions SRTCP. The types/values
   that can be negotiated are defined by the following table:

     Type | Meaning                     | Possible values
     ----------------------------------------------------
        0 | Encryption algorithm        | see below
        1 | Session Encr. key length    | depends on cipher used
        2 | Authentication algorithm    | see below
        3 | Session Auth. key length    | depends on MAC used
        4 | Session Salt key length     | see [SRTP] for SDP and RTSP", Internet
   Draft, Work in Progress (MMUSIC WG).

   [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting recommendations
        5 | SRTP Pseudo Random Function | see below
        6 | Key Sizes derivation rate         | see [SRTP] 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 recommendations
        7 | SRTP encryption off/on      | 0 if off, 1 if on
        8 | SRTCP encryption off/on     | 0 if off, 1 if on
        9 | FEC order                   | see below
       10 | SRTP authentication off/on  | 0 if off, 1 if on
       11 | Authentication tag length   | in progress (MMUSIC).

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

   [RTSP] Schulzrinne, H., Rao, A., bytes
       12 | SRTP prefix length          | in bytes

   Note that if a Type/Value is not set, the default one is used
   (according to SRTPs own criteria).

   For the Encryption algorithm, it is enough with a one byte length and Lanphier, R., "Real Time
   Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RSA] Rivest, R., Shamir, A.,
   the currently defined possible Values are:

     SRTP encr alg | Value
     ---------------------
     NULL          |     0
     AES-CM        |     1
     AES-F8        |     2

   where AES-CM is AES in CM and Adleman, L. "A Method for Obtaining
   Digital Signatures AES-F8 is AES in f8 mode.

   For the Authentication algorithm, it is enough with a one byte length
   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 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. currently define possible Values are:

     SRTP auth alg | Value
     ---------------------
     NULL          |     0
     HMAC-SHA1     |     1

   For all encoding,
   Network the SRTP pseudo random function, it is also enough with a one
   byte order MUST always be used.

   Note that everything denoted Mandatory MUST be implemented, length and
   everything denoted Default MUST be assumed to be selected if nothing
   else the currently define possible Values are:

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

   If FEC is stated.

A.1. Common header payload

   The Common header payload MUST always be present used at the same time as SRTP is used, MIKEY can negotiate
   the first payload order in each message. The common header includes general description of
   the exchange message.

                        1                   2                   3 which these should be applied.

     FEC order     | Value | Comments
     --------------------------------
     FEC-SRTP      |     0 | First FEC, then SRTP
     SRTP-FEC      |     1 | First SRTP, then FEC
     SPLIT         |     2 3 4 5 6 7 8 | SRTP encr., then FEC, finally SRTP auth

6.11. RAND payload (RAND)

   The RAND payload consist of a random bit-string. The RAND MUST be
   chosen at random and per CSB (note that the if a CSB has several
   members, the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  version      !  data type    ! next Next payload  !R! PRF func    !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         MCS ID                                !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ! #CS RAND len      ! CS ID map type! CS ID map info RAND                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The common header contains the following information:

   * version: Next payload: identifies the version number payload that is added after this
     payload.

   * RAND len: Length of MIKEY.

     version = 1 the RAND (in bytes). SHOULD be at least 16.

   * data type: describes RAND: a randomly chosen bit-string.

6.12. Error payload (ERR)

   The Error payload is used to specify the type of message (e.g. public-key transport
    message, verification message, error message).

     Data type     | Value | Comment
     --------------------------------------
     Pre-shared    | error(s) that may have
   occurred.
                        1                   2                   3
    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 | 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 ! Error message no      !           Reserved            !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

     Next payload
     See Section 6.1 for values.

   * Error no indicates the type of error that was encountered.

     Error no      | Value | Appendix
     ------------------------------
     Last payload Comment
     -------------------------------------------------------
     Auth failure  |     0 | -
     Key data trnsp| Authentication failure
     Invalid TS    |     1 | A2
     Env data Invalid timestamp
     Invalid PRF   |     2 | A3
     DH data PRF function not supported
     Invalid MAC   |     3 | A4
     Signature MAC algorithm not supported
     Invalid EA    |     3 | Encryption algorithm not supported
     Invalid HA    |     3 | Hash function not supported
     Invalid DH    |     4 | A5
     Timestamp DH group not supported
     Invalid ID    |     5 | A6 ID not supported
     Invalid Cert  |     6 | A7 Certificate not supported
     Invalid SP    |     7 | A7
     Cert hash SP type not supported
     Invalid SPpar |     8 | A8
     Ver msg       |     9 | A9 SP            |    10 | A10
     Rand          |    11 | A11
     Error         |    12 | A12 parameters not supported

6.13. Key data      |    20 | A13

   * R: flag to indicate whether a response is expected or not (this has
    only meaning when it is set by sub-payload

   The Key data payload contains TGKs. The Key data payloads are never
   included in clear, but as an encrypted part of the Initiator).

     R = Key data transport
   payload.

                        1                   2                   3
    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 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 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 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.  Next Payload ! Policy nr 2 Type  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ KV    !                           SSRC 2 Key data len                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                           ROC 2                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                               :                               :                         Key data                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Policy nr #CS Salt len (optional)   !           SSRC #CS Salt data (optional)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~SSRC #CS (cont)!           ROC #CS
   !                        KV data (optional)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ 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 Next payload: identifies the SRTP streams.
    Note payload that it is added after this
     payload.

   * Type: Indicates the sender type of the streams who chooses key included in the SSRC.
    Therefore, it might be that the Initiator of MIKEY can not fill in
    all fields. In this case, SSRCs payload. Note
     that generally TEKs are not chosen by sent directly, but a TGK, which is
     then used to derive the
    Initiator TEK (or TEKs if there are set several crypto
     sessions) as described in Section 4.1.4.

     Type     | Value | Comments
     ---------------------------------------
     TGK      |     0 | A TGK (used to zero derive TEKs from)
     TGK+SALT |     1 | A TGK + a salt key are included
     TEK      |     2 | A plain TEK
     TEK+SALT |     3 | A plain TEK + a salt key are included

     Note that the possibility to include a TEK (instead of using the
     TGK is provided). However, if this is used, the TEK can generally
     not be shared between more than one Crypto Session. The
     recommended use of a TEK instead of a TGK is when pre-encrypted
     material exist and therefore, the Responder fills TEK must be known in these field advance.

   * KV: Indicates the type of key validity period specified. This may
     be done by using an SPI/MKI or by providing an interval in which
     the response message.

   * ROC x: Current roll-over counter used key is valid (e.g., in SRTP. If the latter case, for SRTP session
    has not started, this field will be
     the index range where the key is set to 0. This field valid).

     KV            | Value | Comments
     -------------------------------------------
     Null          |     0 | No specific usage rule (e.g. a TEK
                   |       | that has no specific lifetime)
     SPI           |     1 | The key is used to be
    able for associated with the SPI/MKI
     Interval      |     2 | The key has a member to join start and synchronize to expiration time
                   |       | (e.g. 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 SRTP TEK)

     Note that when NULL is specified, any SPI or
   a KEK. The last Key data payload MUST have its Next payload field set
   to Last payload. Interval is valid.
     For an update message (see also Section 4.5.), it is
   allowed to skip the Key data payloads (which will result in Interval this means that the
   Encr data len key is equal to 0).

   If valid from the transport method used is first
     observed sequence number until the pre-shared key method, this is replaced (or the
     security protocol is shutdown).

   * Key data transport payload MUST be len: The length of the last payload Key data field (in bytes).

   * Key data: The TGK data.

   * Salt len: The salt key length in the message (note bytes. Note that the Next payload this field MUST be set to Last payload). The MAC is
   then calculated over
     only included if the entire message (as described salt is specified in Section
   5.2.).

   If the transport method used Type-field.

   * Salt data: The salt key data. Note that this field is only included
     if the public-key method, the
   Initiator's identity MUST be added salt is specified in the encrypted data. This Type-field. (For SRTP, this is
   done by adding the ID payload as the first payload, which then are
   followed by
     so-called master salt.)

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

6.14. Key validity data payloads. Note that for an update message,
   the ID MUST still be sent encrypted to the Responder (this is to
   avoid certain re-direction attacks) even though no

   The Key validity data payloads is added after.

   The MAC field is in the public-key case calculated only over not a standalone payload, but part of either
   the Key data transport payload, where the MAC field and payload (see Section 6.13) or the Next DH payload
   field have been initiated with zeros. (see
   Section 6.4). The Key validity data gives a guideline of when the key
   should be used. This can be done, using an SPI/MKI or a lifetime
   range.

   SPI/MKI

                        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  ! Encr alg      ! Encr data len                 !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        Encr data                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Mac alg SPI Length    !        MAC SPI                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Encr alg: SPI Length: The encryption algorithm used to encrypt the PMK.

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

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

   * Encr data: The encrypted PMK.

   * MAC alg specifies the authentication algorithm used.

     MAC alg       | Value | Comments
     --------------------------------------
     HMAC-SHA1-160 |     0 | Mandatory (see Section 4.2.4.) SPI (or MKI) in bytes.

   * MAC: The message authentication code of the entire message.

A.3. Envelope data payload SPI: 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. SPI (or MKI) value.

   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     ! C Valid from                                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Data len VT Length     ! Data Valid to (expires)                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies VF Length: Length of the payload that is added after this
    payload. Valid From field in bytes.

   * C: Envelope key cache indicator (see also Section 3.2., for more
    information Valid From: Sequence number, index, timestamp, or other start value
     that the security protocol uses to identify the start position of
     the usage).

     Cache type    | Value | Comments
     --------------------------------------
     No cache      |     0 | The envelope key MUST NOT be cached
     Cache         |     1 | The envelope usage.

   * VT Length: Length of the Valid To field in bytes.

   * Valid to: Sequence number, index, timestamp, or other expiration
     value that the security protocol can use to identify the
     expiration of the key should be cached
     Cache usage.

   Note that for MCS |     2 | The envelope SRTP usage, the key validity period for a TGK should be cached, but only
                   |       | to be used for
   specified with either an interval, where the specific MCS.

   * Data len: The VF/VT length is equal to
   6 bytes (i.e., the size of the data field (in bytes).

   * Data: The encrypted envelope key (padding and formatting MUST be
    done according to RSA/PKCS#1 index), or, with an MKI. It is
   RECOMMENDED that if RSA more than one SRTP stream is used).

A.4. DH data payload sharing the same
   keys and key update/re-keying is desired, this is handled using MKI
   rather than the From-To method.

6.15. General Extension Payload

   The DH data General extensions payload carries is included to allow possible
   extensions to MIKEY without the DH-value and indicates need to define a complete new payload
   each time. This payload can be used in any MIKEY message. Currently
   the DH-group
   used. only use defined, is to transport Vendor Id. Support of the
   Vendor ID is OPTIONAL.

                        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  !   DH-Group Type          !  DH-key len Length                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        DH-value                               ~
   !
   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Type  ! KV    ! KV data (optional)                            ~ Data                                                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   * DH-Group: Type: identifies the DH group used.

     DH-Group type of the general payload.

     Type      | Value | Comments
     --------------------------------------
     OAKLEY 5
     ---------------------------------------
     Vendor ID |     0 | Mandatory
     OAKLEY 1      |     1 |
     OAKLEY 2      |     2 | Vendor specific byte string

   * DH-key len: The Length: the length in bytes of the DH-value field (in bytes).

   * DH-value: The public DH-value. Data field.

   * Type: Indicates the type of Data: the general payload data.

7. 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 included in the payload, i.e.
    if the resulting DH-key will management protocol information.

7.1. SDP integration

   SDP descriptions [SDP] can be used carried by several protocols, such as a PMK or KEK (in the second
    case,
   SIP and RTSP. Both SIP and RTSP often use SDP to describe the DH-key is not used directly as a KEK, but media
   sessions. Therefore, it is derived
    according to Section 4.1.6). See also Appendix A.13. for pre-
    defined values.

   * KV: Indicates convenient to be able to integrate
   the type of key validity period specified. This may
    be done by using an SPI or by providing an interval management in which the session description it is supposed to
   protect. [KMASDP] describes attributes that should be used by a key
   management protocol that is valid (e.g. integrated in the latter case, SDP. We refer to [KMASDP]
   for SRTP this will be the
    SEQ nr range where both definitions and examples. Note that MIKEY uses the name
   "mikey" as a protocol name in SDP and RTSP. The key management data
   that is valid). See Appendix A.13. for pre-
    defined values.

   * KV data: This includes either the SPI or an interval placed in SDP or RTSP MUST be base64 encoded.

7.2. MIKEY within SIP

   In e.g., a basic SIP call between two parties (see Appendix
    A.14.). If KV Figure 7.1.), SIP
   (Session Initiation Protocol, [SIP]) is NULL, this field used as a session
   establishment protocol between two or more parties. In general an
   offer is not included.

A.5. Signature payload

   The Signature payload carries made, whereby it is either accepted or rejected by the signature
   answerer. SIP complies to the offer/answer model [OFFANS], to which
   MIKEY over SIP MUST be compliant with as well.

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

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

   The
   signature payload MUST always SIP offerer will be the last payload MIKEY Initiator and the SIP answerer will
   be the MIKEY Responder. This implies that 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Signature len                 ! Signature                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Signature len: The length of offer, the signature field (in bytes).

   * Signature: The signature (padding MIKEY
   Initiator's message is included, and formatting MUST be done
    according in the answer to RSA/PKCS#1 if RSA is used).

A.6. Timestamp payload

   The timestamp payload carries the 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                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies offer, the payload that
   MIKEY Responder's message is added after this
    payload. included.

   If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * TS type: specifies the timestamp type used.

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

   * TS-value: The timestamp value MIKEY part of the specified TS type.

A.7. ID payload / Certificate payload

   The ID payload carries offer is not accepted, a uniquely-defined identifier. MIKEY error message
   is provided in the answer (following Section 5.1.2). The certificate payload contains MIKEY
   implementation signals to the SIP implementation whether the MIKEY
   message was an indicator acceptable offer or not.

   It may be assumed that the offerer knows the identity of the certificate
   provided as well as
   answerer. However, unless the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload ! ID/Cert Type  ! ID/Cert len                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                       ID/Certificate Data                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies Initiator's identity can be derived
   from SIP itself, the payload that is added after this
    payload. If no more payload follows, it Initiator (caller) MUST be set to Last
    payload. See Appendix A.1. for values.

   * ID Type: specifies provide the identifier type used.

     ID Type       | Value | Comments
     ----------------------------------------------
     NAI           |     0 | Mandatory (see [NAI])
     URI           |     1 | Mandatory (see [URI])

   * Cert Type: specifies identity to
   the certificate type used.

     Cert Type     | Value | Comments
     ----------------------------------------------
     X.509         |     0 | Mandatory
     X.509 URL     |     1 |
     X.509 Sign    |     2 | Mandatory
     X.509 Encr    |     3 | Mandatory

   * ID/Cert len: The length callee. It is RECOMMENDED to use the same identity for both SIP
   and MIKEY.

   Updating of the ID or Certificate field (in bytes).

   * ID/Certificate: The ID or Certificate data.

A.8. Cert hash payload

   The Cert hash payload contains CSB (e.g. TEK update) is only supposed to be seen as
   a new offer. Note that it might not be necessary to send all
   information, such as the hash of certificate, due to the certificate used. already established
   call (see also Section 4.5).

7.3. MIKEY with RTSP

   The
   hash function Real Time Streaming Protocol (RTSP) [RTSP] is used MUST to control
   media streaming from a server. 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 the one specified MIKEY messages in
   RTSP messages which does not contain an SDP description, the Common RTSP
   KeyMgmt 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  ! Hash func     ! Hash                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies the payload that (defined in [KMASDP]) is added after this
    payload.

   * Hash func: Indicates used. This header includes
   basically the 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

   * Hash: The hash data. Note: same fields as the hash length SDP extensions. As for SDP, "mikey"
   is implicit from used as the
    hash function used.

A.9. Ver msg payload protocol identifier.

   In an RTSP scenario, the RTSP server and the MIKEY Initiator will be
   the same entity. The Ver msg payload contains Initiator/RTSP server includes the calculated verification MIKEY message
   in an SDP description. When responding to this, the PS/PK transport. Note that the MAC is calculated over client uses the entire
   message as well as
   defined RTSP header to send back 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  ! Auth alg      ! Ver data                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * next payload: identifies answer (included in the payload SETUP
   message).

   Note that it is added after the server that will be the Initiator of MIKEY in
   this
    payload. If no more payload follows, it MUST case. This has some advantages. First, the server will always be set
   able to Last
    payload. See Appendix A.1. for values.

   * Auth alg specified choose the authentication algorithm used key 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 content it distributes. Secondly, it
   will then have the authentication algorithm used.

A.10. Security Policy payload

   The Security Policy payload defines a set of policies that applies possibility 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next payload  ! Policy nr     ! Prot type     ! Policy param  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies use the payload same key for the same
   content that is added after this
    payload. If no are streamed/sent to more payload follows, it MUST than one client.

   To be set able to Last
    payload. See Appendix A.1. for values.

   * Policy nr: Each security policy payload must be given have a distinct
    number.

   * Prot type: defines server-initiated CSB update procedure, the 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
   ANNOUNCE message is used to send the policy for updated MIKEY material. Note
   that the security/re-key protocol.

A.10.1. SRTPbasic policy

   This policy specifies ANNOUNCE method has the policy for SRTP and SRTCP. All defined
   transform applies ability to both SRTP send SDP descriptions to
   update previous ones (i.e., it is not required to use the RTSP
   KeyMgmt header from server to client).

7.4. MIKEY Interface

   The SDP, SIP, 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  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! auth alg      ! auth key len  ! auth tag len  ! salt key len  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTP PRF      ! Key Der rate  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NOTE: SRTP was not finalized by the date for this draft's submission.
   Therefore, RTSP processing is defined in [KMASDP]. However, it
   is necessary that MIKEY can work properly with these parameters might be protocols. This
   subsection describes some aspects which implementers SHOULD consider.
   If the MIKEY implementation is separate from the SDP/SIP/RTSP, an issue for update!
   application programming interface (API) between MIKEY and these
   protocols  is needed with certain functionality  (however, exactly
   what it looks like is implementation dependent).

   Implementers of MIKEY are RECOMMENDED to consider providing at least
   the following functionality:

   * encr alg specifies the desired encryption algorithm possibility for MIKEY to be used receive information about the sessions
     negotiated. This is to some extent implementation dependent. But
     it is RECOMMENDED that, in the case of SRTP streams, the number of
     SRTP streams are included (and SRTCP, if used by SRTP).

     encr alg      | Value | Comments
     ------------------------------------------
     NULL          |     0 | Mandatory
     AES-CM-128    |     1 | Mandatory
     AES-F8-128    |     2 |

     AES-CM-128 is AES in CM with 128-bit block size.
     AES-F8-128 the direction of these). The
     destination addresses and ports is AES in f8 mode with 128-bit block size.

   * encr key len: desired session encryption key length in bytes. also RECOMMENDED to be provided
     to MIKEY.

   * auth alg specifies the desired authentication algorithm possibility for MIKEY to be used.

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

   * auth key len: desired session authentication key length in bytes. receive incoming MIKEY messages and
     return a status code from/to the SIP/RTSP application.

   * auth tag len: desired length in bytes of the output tag possibility for the SIP or RTSP applications to receive
     information from MIKEY. This would typically include the receiving
     of the MAC.

   * salt key len: The desired session salting key length in bytes.
    Note: do not mix this with CSB ID or the master salt SSRCs for SRTP. It is also RECOMMENDED that are exchanged.
     extra information about errors can be received.

   * PRF: Specifies the PRF used.

     SRTP PRF      | Value | Comments
     -------------------------------------------
     AES-CM        |     0 | Mandatory possibility for the SIP or RTSP application to receive outgoing
     MIKEY messages.

   * Key Der rate: The 2-logarithm of the desired key derivation rate. possibility to tear down a MIKEY CSB (e.g. if the SIP session
     is closed, the CSB SHOULD also be closed).

   Note that this if a CSB has already been established, it is possible as still valid
   for the key derivation rate must be SIP or RTSP implementation to request a
    power of 2 in new message from
   MIKEY, e.g. when a new offer is issued. MIKEY SHOULD then send an
   update message to the range [0..2^16].

A.10.2. SRTPext policy

   This policy separates Responder (see also Section 4.5).

8. Groups

   What has been discussed up to now is not limited to single peer-to-
   peer communication (except for the SRTP DH method), but can be used to
   distribute group keys for small-size interactive groups 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      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTP AA       ! SRTP AKL      ! SRTP ATL      ! SRTP SKL      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTxP PRF     ! SRTP KDR      ! SRTCP EA      ! SRTCP EKL     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTCP AA      ! SRTCP AKL     ! SRTCP ATL     ! SRTCP SKL     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SRTCP KDR     !
   +-+-+-+-+-+-+-+-+

   * SRTP EA: encryption algorithm for SRTP (see Appendix A.10.1. for
    defined ciphers).

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

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

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

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

   * SRTP SKL: salting key length simple
   one-to-many scenarios. This section describes how MIKEY is used in bytes for SRTP.

   * SRTxP PRF: pseudo-random function a
   group scenario.

8.1. Simple one-to-many

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

               Figure 8.1. Simple one-to-many scenario.

   In the simple one-to-many  scenario, a server is streaming to a small
   group of clients. RTSP or SIP is used for SRTP the registration and SRTCP (see Appendix
    A.10.1. for defined PRFs).

   * SRTP KDR: the 2-logarithm
   key management set up. The streaming server acts as the Initiator of
   MIKEY. In this scenario the pre-shared key derivation rate for SRTP (see
    also Appendix A.10.1).

   * SRTCP EA: encryption algorithm for SRTCP (see Appendix A.10.1. for
    defined ciphers).

   * SRTCP EAL: encryption or public 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 transport
   mechanism will be appropriate to use to transport the same TGK to all
   the clients (which will result in bytes common TEKs for SRTCP.

   * SRTCP KDR: the 2-logarithm of group).

   Note, if the key derivation rate same TGK/TEK(s) should be used by all the group members,
   the streaming server MUST specify the same CSB_ID and CS_ID(s) for SRTCP
    (see also Appendix A.10.1).

A.10.3. Re-key policy

   The following attributes is supported according
   the session 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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   !  KEK alg      !  auth alg     !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  KEK key len                  ! auth key len                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  mm alg       !
   +-+-+-+-+-+-+-+-+

   * KEK alg: The KEK ENCRYPTION ALGORITHM

     KEK alg all the group members.

8.2. Small-size interactive group

                    ++++          ++++
                    |A | Value
     -----------------------
     NULL -------> |B |     0
     3DES
                    |     1
     AES  |     2

   * auth alg: The AUTHENTICATION ALGORITHM

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

   * KEK key len: The key length of the KEK

   * auth key len: The key length of the authentication key

   * mm alg: The MEMBERSHIP MANAGEMENT ALGORITHM

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

A.11. Rand payload

   The Rand payload consist of a random bit-string. The Rand MUST be
   chosen at random and per MCS (note that the if a MCS has several
   members, the 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  ! Rand len      ! Rand                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Next payload: identifies |
                     | |   ++++   | |
                     | --->|C |<--- |
                     ------|  |------
                           ++++

   Figure 8.2. Small-size group without centralized controller.

   As described in the payload overview section, for small-size interactive
   groups, one may expect that is added after this
    payload.

   * Rand len: Length of each client will be in charge for setting
   up the Rand (in bytes). SHOULD security for its outgoing streams. In these scenarios, the
   pre-shared key or the public-key transport method is used.

   One scenario may then be at least 16.

   * Rand: that the client sets up a randomly chosen bit-string.

A.12. Error payload

   The Error payload is used three-part call,
   using SIP. Due to specify the 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 ! Error nr      !           Reserved            !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * next payload: identifies small size of the payload that group, unicast SRTP is added after this
    payload. If no more payload follows, it MUST be set used
   between the clients. Each client sets up the security for its
   outgoing stream(s) to Last
    payload. See Appendix A.1. the others.

   As for values.

   * Error nr indicates the type of error that 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 key data payload contains PMKs and a optionally also a KEK. These
   are never included in clear, but as an encrypted part of simple one-to-many case, 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 ! Type  ! KV    ! Key data len                  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Key data                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Salt len (optional)   ! Salt data (optional)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                        KV data (optional)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Next payload: identifies streaming client specifies
   the payload that is added after this
    payload.

   * Type: Indicates same CSB_ID and CS_ID(s) for its outgoing sessions if the type of same
   TGK/TEK(s) is used for all the key included in group members.

9. Security Considerations

9.1. General

   No chain is stronger than its weakest link. The cryptographic
   functions protecting the payload. Note
    that TEKs are not sent directly, but keys during transport/exchange SHOULD offer
   a PMK, which is then used security at least corresponding to
    derive the 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 + (symmetric) keys they
   protect. For instance, with current state of the art, see [LV],
   protecting a salt 128-bit AES key are included
     KEK           |     2 | A Key-encrypting by a 512-bit RSA [RSA] key

   * KV: Indicates offers an
   overall security below 64-bits. On the type of other hand, protecting a 64-
   bit symmetric key validity period specified. This may
    be done by using an SPI or by providing a 2048-bit RSA key appears to be an interval in which the "overkill",
   leading to unnecessary time delays. Therefore, key is valid (e.g. in the latter case, size for SRTP this will the key-
   exchange mechanism SHOULD be weighed against the
    SEQ nr range where size of the
   exchanged key. We refer to [LV] for concrete key is valid).

     KV            | Value | Comments
     -------------------------------------------
     Null          |     0 | No specific usage rule (e.g. size
   recommendations.

   Moreover, if the TGKs are not random, a TEK
                   |       | that has no specific lifetime)
     SPI           |     1 | The key is associated with brute force search may be
   facilitated, again lowering the SPI
     Interval      |     2 | The effective key has a start and expiration time
                   |       | (e.g. an SRTP TEK)

    Note that size. Therefore, care
   MUST be taken when NULL is specified, any SPI or Interval is valid. For
    an Interval this means that designing the key is valid from (pseudo) random generators for TGK
   generation.

   For the first
    observed sequence number until selection of the key hash function, SHA-1 with 160-bit output 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 default one. In general, hash sizes should be twice the KEK data.

   * Salt len: The salt key length in bytes. Note "security
   level", indicating that this field is
    only included if SHA1-256, [SHA256], should be used for the salt is specified
   default 128-bit level. However, due to the real-time aspects in the Type-field.

   * Salt data: The salt key data. Note that this field is only included
    if
   scenarios we are treating, hash size slightly below 256 are
   acceptable as the salt is specified in normal "existential" collision probabilities would
   be of secondary importance.

   In a Crypto Session Bundle, the Type-field. (For SRTP, this is Crypto Sessions can share the
    so-called master salt.)

   * KV data: This includes either same
   TGK as discussed earlier. From a security point of view, the SPI or an interval (see Appendix
    A.14.). If KV
   criterion to be satisfied is NULL, that the encryption of the individual
   Crypto Sessions are performed "independently". In MIKEY this field is not included.

A.14. Key validity data
   accomplished by having unique Crypto Session identifiers (see also
   Section 4.1). The Key validity data is not a payload, but part TEK derivation method assures this by providing
   cryptographically independent TEKs to distinct Crypto Sessions
   (within the Crypto Session Bundle), regardless of either the Key
   data payload (see Appendix A.13.) or security
   protocol used.

   Specifically, the DH payload (see Appendix
   A.4.). key derivations are implemented by a pseudo-random
   function. The Key validity data gives one used here is a guideline simplified version of when the key should
   be used. This can be done, using an SPI that used in
   TLS [TLS]. Here, only one single hash function is used, whereas TLS
   uses two different functions. This choice is motivated by the high
   confidence in the SHA-1 hash function, and, by efficiency and
   simplicity of design (complexity does not imply security). 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 TGK 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 method is to be used.

   Forward/backward security: if the TGK is exposed, all TEKs generated
   from it are compromised. However, under the assumption that the
   derivation function is a lifetime range.

   SPI

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! SPI Length    ! SPI                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * SPI Length: The length pseudo-random function, disclosure of an
   individual TEK does not compromise other (previous or later) TEKs
   derived from the SPI (or MKI) same TGK.

   All the pre-defined transforms in bytes.

   * SPI: The SPI MIKEY use state-of-the-art
   algorithms that has undergone large amounts of public evaluation.

9.2. Key lifetime

   Even if the lifetime of a TGK (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 TEK) 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. It is not possible to here state general key life-
   time bounds, universally applicable; each security protocol should
   define such maximum amount and trigger a re-keying procedure before
   the "exhaustion" of the key. E.g., according to SRTP [SRTP] the TEK
   MUST be changed at least every 2^48 SRTP packet (i.e. every time the
   ROC + SEQ no in SRTP wraps).

   Still, the following can be said 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.

9.3. Timestamps

   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 roundtrip (i.e., two messages), but still
   provide a reasonable replay protection. A (secure) challenge-response
   based version would require at least three messages. For a detailed
   description of the timestamp and replay handling in MIKEY, see
   Section 5.4.

   Practical experiences of Kerberos and other timestamp based systems
   indicate 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.

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

9.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
   e.g., be solved by letting the protocol transporting MIKEY do an IP
   address validity test. For example, the SIP protocol can provide this
   using the anonymous authentication challenge mechanism (specified in
   Section 22.1 of [SIP]).

9.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 secured media streams. This however only
   applies to groups (and is not specific to MIKEY). The threat is that
   one group member may re-direct a stream from one group member to
   another. 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 (SOA) scheme (e.g., digital signatures) is applied to
   the security protocol.

   Re-direction of streams can of course be done even if it is not a
   group. However, the effect will not be the same compared to a group
   where impersonation can be done if SOA is not used. Instead, re-
   direction will only deny the receiver the possibility to receive (or
   just delay) the data.

10. IANA considerations

   This document defines several new name spaces associated with the
   MIKEY payloads. This section summarize the name spaces for which IANA
   is requested to manage the allocation of values.

   IANA is requested to record the pre-defined values defined in the
   given sections for each name space. IANA is also requested to manage
   the definition of additional values in the future. Unless explicitly
   stated otherwise, values in the range 0-240 for each name space
   should be approved by the process of IETF consensus and values in the
   range 241-255 are reserved for Private Use.

   The name spaces for the following fields in the Common header payload
   (from Section 6.1) are requested to be managed by IANA:

   * version

   * data type

   * Next payload

   * PRF func. This name space is between 0-127 where values between 0-
     111 should be approved by the process of IETF consensus and values
     between 112-127 are reserved for Private Use.

   * CS ID map type

   The name spaces for the following fields in the Key data transport
   payload (from Section 6.2) are requested to be managed by IANA:

   * Encr alg

   * MAC alg

   The name spaces for the following fields in the DH data payload (from
   Section 6.4) are requested to be managed by IANA:

   * DH-Group

   The name spaces for the following fields in the Timestamp payload
   (from Section 6.6) are requested to be managed by IANA:

   * TS type
   The name spaces for the following fields in the ID payload and the
   Certificate payload (from Section 6.7) are requested to be managed by
   IANA:

   * ID type

   * Cert type

   The name spaces for the following fields in the Cert hash payload
   (from Section 6.8) are requested to be managed by IANA:

   * Hash func

   The name spaces for the following fields in the Security policy
   payload (from Section 6.10) are requested to be managed by IANA:

   * Prot type

   From Section 6.10.1.

   * SRTP Type

   * SRTP encr alg

   * SRTP auth alg

   * SRTP PRF

   * FEC order

   The name spaces for the following fields in the Error payload (from
   Section 6.12) are requested to be managed by IANA:

   * Error no

   The name spaces for the following fields in the Key data payload
   (from Section 6.13) are requested to be managed by IANA:

   * Type. This name space is between 0-16 which should be approved by
     the process of IETF consensus.

   * KV. This name space is between 0-16 which should be approved by the
     process of IETF consensus.

   The name spaces for the following fields in the General Extensions
   payload (from Section 6.15) are requested to be managed by IANA:

   * Type

11. 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 is
   designed to fulfill such requirements and optimized so that it also
   may be integrated in other protocols 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.

12. Acknowledgments

   The authors would like to thank Mark Baugher, Ran Canetti, Martin
   Euchner, the rest of the MSEC WG, Pasi Ahonen (with his group), Rolf
   Blom, and Magnus Westerlund, 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 9 0 1 2 3 4 5 6 7 58533739
     Sweden                   EMail:  mats.naslund@era.ericsson.se

     Karl Norrman
     Ericsson Research
     SE-16480 Stockholm       Phone:  +46 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! VF Length     ! Valid from                                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! VT Length     ! Valid to (expires)                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * VF Length: Length 4044502
     Sweden                   EMail:  karl.norrman@era.ericsson.se

14. References

14.1. Normative References

   [AES] Advanced Encryption Standard (AES), Federal Information
   Processing Standard Publications (FIPS PUBS) 197, November 2001.

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

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

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

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

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

   [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

   [SIP] Rosenberg, J. et al, "SIP: Session Initiation Protocol", IETF,
   RFC3261.

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

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

   [X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet
   X.509 Public Key Infrastructure Certificate and Certificate
   Revocation List (CRL) Profile", IETF, RFC 3280.

14.2. Informative References

   [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A
   Concrete Analysis of Symmetric Encryption: Analysis of the Valid From field DES Modes
   of Operation", in bytes.

   * Valid From: Sequence number, timestamp, or other start value that
    the security protocol uses to identify the start position Proceedings of the
    key usage.

   * VT Length: Length 38th Symposium on Foundations of the Valid To field
   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, Lecture Notes in bytes.

   * Valid to: Sequence number, timestamp, or other expiration value
    that the security protocol can use to identify the expiration Computer Science vol 2248, pp. 442-
   459.

   [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
    the key usage.

   Note that 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 bytes, or with an SPI (in SRTP denoted as a Master Interpretation", Internet Draft, Work in Progress (MSEC
   WG).

   [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
   R., "Group Secure Association Key Identifier,
   MKI). It is recommended that if more than one SRTP stream is sharing
   the same keys Management Protocol", Internet
   Draft, Work in Progress (MSEC WG).

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

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

   [NTP] Mills, D., "Network Time Protocol (Version 3) specification,
   implementation and key update/re-keying is desired, this is handled
   using SPI rather than the From-To method.

Appendix B. analysis", RFC 1305, March 1992.

   [PKCS1] PKCS #1 - Payload usage summary

   Depending on RSA Cryptography Standard,
   http://www.rsalabs.com/pkcs/pkcs-1/

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

   [SHA256] NIST, "Description of message, different payloads MUST SHA-256, SHA-384, 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
   -------------------------------------------------
   Key data trnsp| M      M#     -      -      O+
   Env data      | -      M      -      -      -
   DH data       | -      -      M#     -      -
   Ver msg       | -      -      -      M      -
   Error         | -      -      -      -      M
   Timestamp     | M      M      M      -      O
   ID            | O      M      M      O      O
   Signature     | -      M      M      -      O+
   Certificate   | -      O      O      -      -
   Cert hash     | -      O      O      -      -
   SP            | O      O      O SHA-512",
   http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf

   [TLS] Dierks, T. and Allen, C., "The TLS Protocol -      O
   Rand          | M@     M@     M@ Version 1.0",
   IETF, RFC 2246.

Appendix A. - MIKEY -

   # 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 SRTP relation

   The terminology in MIKEY differs from the other peer has been correctly authenticated, one used in SRTP as MIKEY
   needs to be more general. Therefore it
    is not recommended that the error messages are sent authenticated
    (as this would open up for DoS attacks).

   @ MUST only might be included by hard to see the Initiator
   relations between keys and parameters generated in MIKEY and the initial exchange.

   When a payload is not included, the default values for the
   information carried by it SHALL be ones
   used (when applicable). by SRTP. This section provides some hints on their relation.

   MIKEY            | SRTP
   -------------------------------------------------
   Crypto Session   | SRTP stream
   Data SA          | input to SRTP's crypto context
   TEK              | SRTP master key

   The
   following table summarizes what messages Data SA is built up by a TEK and the security policy exchanged.
   SRTP may be included in use a
   specific message.

   For MKI to index the encrypted sub payloads in TEK. The TEK is then derived from the Key data transport payload,
   TGK that have the
   following should hold:

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

Revision history

   Changes from -00 -01 draft:
   * Removed: Support for Re-key SA including KEK transport for all
     methods.
   * PK: Id included Timestamp required explicitly in the encrypted part verification message
   * Renamed R flag in Common header to avoid "impersonation"
    attacks. V (for verification)
   * PK: Envelope approach for encryption Change of keys (as the size may
    exceed notation
     - Pre-Master Key (PMK) --> TEK Generation Key (TGK)
     - Multimedia Crypto Session (MCS) --> Crypto Session Bundle (CSB)
     - Some payloads have also had their name changed.
     - Seed (in the limit that can be encrypted with one public-key
    operation).
   * Message processing updated
   * SDP, SIP and RTSP considerations updated PRF definition) --> Label
   * Group section updated General extensions payload added.
   * The use of Rand Possibility to send a TEK only (instead of require a large and random MCS ID)
   * SRTP policies etc updated TGK) is provided for
     pre-encryption purposes.
   * Payload update (to support General updates of all sections (trying to address all comments
     received from the above changes) list).
   * general editorial changes IANA considerations added

   This Internet-Draft expires in August December 2002.