[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 3830

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

                                                          February, 2002

                   MIKEY: Multimedia Internet KEYing

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

   The list of Internet-Draft Shadow Directories can be accessed at


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

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

Arkko, et al.                                                   [Page 1]

INTERNET-DRAFT                msec-mikey-01                February 2002


   1. Introduction.............................................. 3
   1.1. Notational Conventions.................................. 4
   1.2. Definitions............................................. 4
   1.3. Abbreviations........................................... 5
   1.4. Outline................................................. 5
   2. Basic Overview............................................ 6
   2.1. Scenarios............................................... 6
   2.2. Design Goals............................................ 7
   2.3. System Overview......................................... 7
   2.4. Relation to GKMARCH..................................... 9
   2.5. Existing solutions...................................... 9
   3. Basic Key Transport and Exchange Schemes.................. 9
   3.1. Pre-shared key..........................................10
   3.2. Public-key encryption...................................10
   3.3. Diffie-Hellman key exchange.............................12
   4. Key Management............................................14
   4.1. Key Calculation.........................................14
   4.1.1. Assumptions...........................................14
   4.1.2. Notation..............................................14
   4.1.3. PRF Description.......................................15
   4.1.4. Generating TEK from PMK...............................15
   4.1.5. Generating keys from an envelope/pre-shared key.......16
   4.1.6. Generating KEK from a DH-key..........................16
   4.2 Pre-defined Transforms and Timestamp Formats.............16
   4.2.1 Hash functions.........................................16
   4.2.2 Pseudo random number generator and PRF.................16
   4.2.3 Key data transport encryption..........................17
   4.2.4 MAC and Verification Message function..................17
   4.2.5 Envelope Key encryption................................17
   4.2.6 Digital Signatures.....................................17
   4.2.7 Diffie-Hellman Groups..................................17
   4.2.8. Timestamps............................................17
   4.3. Policies................................................17
   4.4. Indexing the Data SA....................................18
   4.5. Re-keying and MCS updating..............................18
   5. Behavior and message handling.............................19
   5.1. General.................................................19
   5.1.1. Capability discovery..................................19
   5.1.2. Error handling........................................19
   5.2. Creating a message......................................19
   5.3. Parsing a message.......................................21
   5.4. Replay handling.........................................21
   5.5. Reliability.............................................22
   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

Arkko, et al.                                                   [Page 2]

INTERNET-DRAFT                msec-mikey-01                February 2002

   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. Common header payload...................................34
   A.1.1. SRTP ID...............................................36
   A.2. Key data transport payload..............................37
   A.3. Envelope data payload...................................38
   A.4. DH data payload.........................................38
   A.5. Signature payload.......................................39
   A.6. Timestamp payload.......................................40
   A.7. ID payload / Certificate payload........................40
   A.8. Cert hash payload.......................................41
   A.9. Ver msg payload.........................................41
   A.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. Error payload..........................................46
   A.13. Key data payload.......................................47
   A.14. Key validity data .....................................48
   Appendix B. - Payload usage summary..........................49
   Revision History.............................................50

1. Introduction

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

   This document describes a key management solution, that address
   multimedia scenarios (e.g. SIP calls and RTSP sessions). The focus is

Arkko, et al.                                                   [Page 3]

INTERNET-DRAFT                msec-mikey-01                February 2002

   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",
   this document are to be interpreted as described in RFC-2119.

1.2. Definitions

   Crypto Session: uni- or bi-directional data stream(s), protected by a
   single instance of a security protocol. E.g. when SRTP is used, the
   Crypto Session may contain two streams, 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

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

   Multimedia Crypto Session ID: unique identifier for the MCS.

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

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

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

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

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

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

   Responder: the responder in the key management protocol.

   H(x):      a cryptographic hash function with argument x
   Random():  a secure (pseudo-)random number generator

Arkko, et al.                                                   [Page 4]

INTERNET-DRAFT                msec-mikey-01                February 2002

   PRF(k,x):  a keyed pseudo-random function
   E(k,m):    encryption of m with the key k
   D(k,m):    decryption of m with the key k
   Sign(k,m): the signature of message m with key k
   PK_x:      the public key of x
   SK_x:      the secret key of x
   Cert_x:    Certificate of x
   k_p:       the PMK
   []         an optional piece of information
   ||         concatenation
   |          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 being the
   most significant.

1.3. Abbreviations

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

1.4. Outline

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

   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.

Arkko, et al.                                                   [Page 5]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

2. Basic Overview

2.1. Scenarios

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

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

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

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

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

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

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

Arkko, et al.                                                   [Page 6]

INTERNET-DRAFT                msec-mikey-01                February 2002

      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

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

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

   * Independent of specific security functionality of the underlying

2.3. System Overview

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

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

Arkko, et al.                                                   [Page 7]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

   Figure 2.1. Overview of the key management procedure.

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

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

Arkko, et al.                                                   [Page 8]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

2.5. Existing solutions

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

3. Basic Key Transport and Exchange Schemes

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

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

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

Arkko, et al.                                                   [Page 9]

INTERNET-DRAFT                msec-mikey-01                February 2002

3.1. Pre-shared key

   The pre-shared key case 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 the pre-shared key and sent to the
   responder. A random bit-string, Rand, is added together with a
   timestamp, T. The entire message is integrity protected by a Message
   Authentication Code (MAC).

   The pre-shared secret, 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
   Rand, PMKs, KEK = Random ()
   encr_key, auth_key = PRF(s,...||Rand)

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

                               K, A
                                       auth_key = PRF(s,..||Rand)

   Figure 3.1. Pre-shared key based transport mechanism.

   Authentication of the peers is provided by the MAC(s). The responder
   MAY return (if requested by Initiator) the verification message, V.
   The verification message is created by applying the MAC function with
   an authentication key on the IDs and timestamp.

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

3.2. Public-key encryption

   Public-key cryptography can be used to create a scalable system. A
   disadvantage with this approach is that it is more resource consuming

Arkko, et al.                                                  [Page 10]

INTERNET-DRAFT                msec-mikey-01                February 2002

   than the pre-shared key approach. Another disadvantage is that in
   most cases a PKI (Public Key Infrastructure) is needed to handle the
   distribution of public keys. Of course, it is possible to use public
   keys as pre-shared keys (e.g. by using self-signed certificates).

          A                                             B

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

   Protocol execution:

     O, P, T, Rand
     [, I]
     [, H(Cert_B)]

                                       {retrieve env_key using SK_b}
                                       auth_key = PRF(env_key,...||Rand)

   Figure 3.2. Key transport using public keys.

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

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

Arkko, et al.                                                  [Page 11]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

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

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

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

3.3. Diffie-Hellman key exchange

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

   For a fixed, agreed upon, group, (G,*), for g in G and a natural
   number x, we let g^x denote g*g*..*g (x times). Choices for the

Arkko, et al.                                                  [Page 12]

INTERNET-DRAFT                msec-mikey-01                February 2002

   parameters are given in Section 4.2.7. The other transforms below are
   described in Section 4.2.

               A                                  B

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

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

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

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

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

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

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

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

   This approach is the most expensive approach. It requires that both
   sides compute one signature, one verification and two DH-

Arkko, et al.                                                  [Page 13]

INTERNET-DRAFT                msec-mikey-01                February 2002

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
   used to derive:

   * TEKs from a PMK and the Rand,

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

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

4.1.1. Assumptions

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

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

   The following parameter MAY be sent in the clear:

   mcs_id: Master Crypto Session ID (32-bits unsigned integer)
   cs_id:  the Crypto Session ID (8-bits unsigned integer)
   Rand:   An (at least) 128-bit random bit-string sent by the

   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:       a specific seed, dependent on the type of the key to be
               derived, the 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.

4.1.2. Notation

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

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

Arkko, et al.                                                  [Page 14]

INTERNET-DRAFT                msec-mikey-01                February 2002


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

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

4.1.3. PRF Description

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

   * let n = 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 another hash function than SHA1 is used, "512" and "160" MUST be
   replaced by the appropriate input/output block-sizes of that

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

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

4.1.4. Generating TEK from PMK

   The key derivation method should be executed with the following

   inkey:      PMK
   seed:       0x2AD01C64 || cs_id || mcs_id || 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.

   Note that the 32-bit constant integers (i.e. 0x2AD01C64 and the once
   replacing it) is taken from the decimal digits of e (i.e. 2.7182...),

Arkko, et al.                                                  [Page 15]

INTERNET-DRAFT                msec-mikey-01                February 2002

   and where each constant consist of nine decimals digits (e.g. the
   first nine decimal digits 718281828 = 0x2AD01C64).

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

   inkey:      the envelope key or the pre-shared key

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

   outkey_len: desired length of the authentication/encryption/salting

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 in the respective case. New transforms MAY
   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.

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). SHA-1 is default and the only mandatory to implement
   and support.

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.

   For the key derivations, the PRF specified in Section 4.1. MUST be
   supported. This PRF MAY be extended by using SHA-256 or SHA-512,
   instead of SHA-1.

Arkko, et al.                                                  [Page 16]

INTERNET-DRAFT                msec-mikey-01                February 2002

4.2.3 Key data transport encryption

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

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

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

   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

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

4.2.5 Envelope Key encryption

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

4.2.6 Digital Signatures

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

4.2.7 Diffie-Hellman Groups

   Diffie-Hellman key exchange SHALL use one of the groups: OAKLEY 5,
   OAKLEY 1, or, OAKLEY 2, see [OAKLEY], where OAKLEY 5 is default and
   mandatory to support.

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 are transmitted. The policies are
   defined in a separate payload and are specific to the security/re-key
   protocol (see also Appendix A.10.). Together with the keys, the

Arkko, et al.                                                  [Page 17]

INTERNET-DRAFT                msec-mikey-01                February 2002

   validity period of theses SHOULD also be specified. This could either
   be done with an SPI (e.g. when a re-key protocol is used) or with an
   Interval (e.g. a sequence number interval for SRTP). Whether an SPI
   or an Interval should be used, depends on the security protocol (or
   re-key protocol).

4.4. Indexing the Data SA

   The indexing of a Data SA will depend on the security protocol as
   different security protocols will have different characteristics. For
   SRTP the SSRC (see [SRTP]) is one of those. However, the SSRC is not
   sufficient. For the local lookup in the MIKEY SA data base, it is
   RECOMMENDED that the MIKEY implementation support a lookup using
   destination network address and port together with SSRC. Note that
   MIKEY does not send network addresses or ports. One reason to this is
   that they may not be known in advance, as well as if a NAT exists in-
   between, problems may arise.

   When SIP or RTSP is used, the local view of the destination address
   and port can be obtained form either SIP or RTSP. MIKEY can then use
   these addresses as the index for the Data SA lookup.

4.5. Re-keying and MCS 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 the re-key
   SA. However, an external group re-key protocol may not be necessary
   in a small group. Therefore, it is also possible to update the MCS
   (e.g. a TEK or a crypto session parameter) by using MIKEY.

   The updating of the MCS is performed by executing MIKEY again e.g.
   before a TEK expires, or a new crypto session is added to the MCS.

   When MIKEY is executed again to update the MCS, it MAY not be
   necessary to include certificates and other information that was
   provided in the first exchange, i.e. all parameters that are static
   or optional to include.

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

   As explained in Section 3.2., the envelope key may be "cached" as a
   pre-shared key. If so, the "update message" SHOULD be a pre-shared
   key message, not a public key message. If the public key message is

Arkko, et al.                                                  [Page 18]

INTERNET-DRAFT                msec-mikey-01                February 2002

   used, but the envelope key was 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

   A Multimedia Crypto Session MAY contain several Crypto Sessions. A
   problem that then MAY occur is to synchronize the re-keying if an SPI
   is not used. It is therefore recommended that an SPI is used, if more
   than one Crypto Session is used.

5. Behavior and 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 the responder's capabilities in terms of
   security algorithms etc. If the guess is wrong, then the responder
   may send back its own capabilities (negotiation) to let the initiator
   choose a common set of parameters. Multiple attributes may be
   provided in sequence. This is done to reduce the number of roundtrips
   as much as possible.

   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.

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

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

Arkko, et al.                                                  [Page 19]

INTERNET-DRAFT                msec-mikey-01                February 2002

   payload, Security Protocol payload). The defined payloads and the
   exact encoding of each payload are described in Appendix A.

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

   Figure 5.1. MIKEY payload example.

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

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

   * Concatenate necessary payloads to the master payload (Appendix B
    lists which payloads MUST/MAY be used for the different messages).

   * As a last step (for messages that must be authenticated, this also
    include the verification message), concatenate the payload
    containing the MAC/signature, where the MAC/signature field is
    initiated with zeros.

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

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

Arkko, et al.                                                  [Page 20]

INTERNET-DRAFT                msec-mikey-01                February 2002

5.3. Parsing a message

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

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

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

   * Verify the MAC/signature.

   * If the authentication is NOT successful, an Auth failure Error
    message MUST be sent to the initiator (if SIP is used, this should
    be signaled to SIP as a rejection of the offer). The message MUST
    then be discarded from further processing, and the event SHOULD be

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

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

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

5.4. Replay handling

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

   * Replayed messages MUST NOT be processed.

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

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

Arkko, et al.                                                  [Page 21]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

   For a client, the maximum number of messages it will recall may vary
   depending on the capacity of the client itself and the network, but
   also the number of expected messages should be taken into account.
   The following is a recommendation of how the maximum size of the
   replay cache may be calculated:

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


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

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

   x: #max expected messages per "clock skew"

   block_size: size of the message to be cached (note that it will
   probably not be needed to cache the entire message, instead a hash of
   the message and the timestamp might be enough).

   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 MIKEY is integrated with a transporting protocol, the
   reliability scheme of the latter may be applied. Otherwise, the basic
   processing applied to ensure protocol reliability is the following.

   The transmitting entity (initiator or responder) MUST:

   * Set a 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

Arkko, et al.                                                  [Page 22]

INTERNET-DRAFT                msec-mikey-01                February 2002

6. Integration with session establishment protocols

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

6.1. SDP integration

   SDP descriptions [SDP] can be carried by several protocols, such as
   SIP and RTSP. Both SIP and RTSP often use SDP to describe the media
   sessions. Therefore, it is also convenient to be 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 in SDP. The following two SDP
   attributes MUST be used by MIKEY.


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


   The data part is used to transport the actual key management payload
   message. Due to the text based nature of SDP, this part MUST be
   base64 encoded to avoid illegal characters but in the same time
   avoiding a too large message expansion.

   a=keymgmt-data:<base64 encoded data>


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

   In this example the multimedia crypto session consists 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

Arkko, et al.                                                  [Page 23]

INTERNET-DRAFT                msec-mikey-01                February 2002

   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    |Server |
                          ---------           ---------
                               ^                ^
                               .                .
             ++++         SIP  .                .   SIP         ++++
             |  | <.............                ..............> |  |
             |  |                                               |  |
             ++++ <-------------------------------------------> ++++

   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 that in the offer, the MIKEY
   Initiator message SHOULD be included, and in the answer to the offer,
   the MIKEY Responder message SHOULD be included.

   If the MIKEY part of the offer is not accepted, a MIKEY error message
   SHOULD be provided in the answer (following Section 5.1.). MIKEY MUST
   always signal to SIP whether the MIKEY message was an acceptable
   offer or not.

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

   Updating of the MCS (e.g. TEK update) SHOULD only be seen as a new
   offer. Note that 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 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 MIKEY messages in
   RTSP messages which does not contain an SDP description, the RTSP
   KeyMgmt header (defined in [KMASDP]) is used. This header includes
   basically the same fields as the SDP extensions.

Arkko, et al.                                                  [Page 24]

INTERNET-DRAFT                msec-mikey-01                February 2002

   In an RTSP scenario, the RTSP server and initiator will be the same
   entity. The Initiator/RTSP server includes the MIKEY message in a SDP
   description. When responding to this, the client uses the defined
   RTSP header to send back the answer (included in the SETUP message).

   Note that it is the server that will be the Initiator of MIKEY 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 the same key for the same
   content that are streamed/sent to more than one client.

   To be able to have a server initiated MCS update procedure, either
   the ANNOUNCE message or the SET_PARAMETER message SHOULD be used to
   send the updated MIKEY material. A disadvantage of using these, is
   that they are not mandatory to implement. Note that the ANNOUNCE
   method has the possibility to send SDP descriptions to update
   previous ones (i.e. it is not needed 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 and these protocols MUST
   provide certain functionality (however, exactly how the interface
   looks like is very implementation dependent).

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

   * MIKEY to 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 the direction of these). The destination addresses
    and ports is also recommended to provide to MIKEY.

   * MIKEY to receive incoming MIKEY messages. This MUST also include
    the possibility to return the status of the incoming message to
    SIP/SDP or to RTSP/SDP, i.e. whether the MIKEY message was accepted
    or not.

   * SIP/SDP or RTSP/SDP to receive information from MIKEY, this include
    the receiving the MCS ID, receiving the SSRCs for SRTP. It is also
    RECOMMENDED that extra information about errors can be received.

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

   * tearing down a MIKEY MCS (e.g. if the SIP sessions is shutdown, the
    MCS SHOULD also be shutdown)

Arkko, et al.                                                  [Page 25]

INTERNET-DRAFT                msec-mikey-01                February 2002

   Note that if a MCS has already been established, it is still valid
   for the SIP/SDP or RSP/SDP implementation to request a new message
   from MIKEY, e.g. when a new offer is issued. MIKEY SHOULD then send
   an update message to the Responder (see also Section 4.5).

7. Groups

   What has been discussed up to now is not limited to single peer-to-
   peer communication, but can be 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 is
   streaming to a small group of clients. In this scenario RTSP or SIP
   could be used for the registration and the key management set up. The
   streaming server would act as the Initiator of MIKEY. In this
   scenario the pre-shared key or public key transport mechanism will be
   appropriate to use to transport the same PMK to all the clients
   (which will result in common TEKs for the group).

   Note, if the same PMK/TEK(s) should be used by all the group members,
   the streaming server MUST specify the same MCS_ID and CS_ID(s) for
   the session to all the group members. Security considerations arising
   from using the same key for several streams in the underlying
   security protocol MUST be considered.

Arkko, et al.                                                  [Page 26]

INTERNET-DRAFT                msec-mikey-01                February 2002

7.2. Small-size interactive group

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

   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 the security
   for its outgoing streams. In these scenarios, the pre-shared key and
   the public-key transport methods will be used.

   One scenario may then be that the client sets up a three-part call,
   using SIP. Due to the small size of the group, unicast SRTP is used
   between the clients. Each client may set up the security for its
   outgoing stream(s) to the others.

   As for the one-to-"a few" case, the streaming client MUST specify the
   same MCS_ID and CS_ID(s) for its outgoing sessions if the same
   PMK/TEK(s) should be used for all the group members. The same
   security considerations for key-sharing also apply.

8. Security Considerations

8.1. General

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

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

Arkko, et al.                                                  [Page 27]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

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

8.2. Key lifetime

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

   As a rule of thumb, if the security protocol uses an 'ideal' b-bit
   block cipher (in CBC mode, counter mode, or a feedback mode with full

Arkko, et al.                                                  [Page 28]

INTERNET-DRAFT                msec-mikey-01                February 2002

   b-bit feedback), degenerate behavior in the crypto stream, possibly
   useful for an attacker, is (with constant probability) expected to
   occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using
   random IVs). For security margin, re-keying MUST be triggered well in
   advance compared to the above bound. See [BDJR] for more details.

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

8.3. Timestamps

   Timestamp usage prevents against replay attacks under the following

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

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

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

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

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

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

Arkko, et al.                                                  [Page 29]

INTERNET-DRAFT                msec-mikey-01                February 2002

8.4. Identity protection

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

8.5. Denial of Service

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

8.6. Session establishment

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

9. Conclusions

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

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

Arkko, et al.                                                  [Page 30]

INTERNET-DRAFT                msec-mikey-01                February 2002

10. Acknowledgments

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

11. Author's Addresses

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

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

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

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

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

12. References

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

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

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

Arkko, et al.                                                  [Page 31]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

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

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

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

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

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

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

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

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

   [PKCS1] PKCS #1 - RSA Cryptography Standard,

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

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

   [SDP] Handley, M., and Jacobson, V., "Session Description Protocol
   (SDP), IETF, RFC2327

Arkko, et al.                                                  [Page 32]

INTERNET-DRAFT                msec-mikey-01                February 2002

   [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

   [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",

   [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

Arkko, et al.                                                  [Page 33]

INTERNET-DRAFT                msec-mikey-01                February 2002

Appendix A - Payload Encoding

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

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

A.1. Common header payload

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

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

   The common header contains the following information:

   * version: the version number of MIKEY.

     version = 1

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

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

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

Arkko, et al.                                                  [Page 34]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

     Hash 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

Arkko, et al.                                                  [Page 35]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

A.1.1. SRTP ID

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

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

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

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

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

Arkko, et al.                                                  [Page 36]

INTERNET-DRAFT                msec-mikey-01                February 2002

A.2. Key data transport payload

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

   If the transport method used is the pre-shared key method, this Key
   data transport payload MUST be the last payload in the message (note
   that the Next payload field MUST be set to Last payload). The MAC is
   then calculated over the entire message (as described in Section

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

   The MAC field is in the public-key case calculated only over the Key
   data transport payload, where the MAC field and the Next payload
   field have been initiated with zeros.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   ! Next payload  ! Encr alg      ! Encr data len                 !
   !                        Encr data                              ~
   ! Mac alg       !        MAC                                    ~

   * Encr alg: 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 of encrypted part (in bytes).

   * Encr data: The encrypted PMK.

   * MAC alg specifies the authentication algorithm used.

Arkko, et al.                                                  [Page 37]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

A.3. Envelope data payload

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

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

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

   * C: Envelope key cache indicator (see also Section 3.2., for more
    information of the usage).

     Cache type    | Value | Comments
     No cache      |     0 | The envelope key MUST NOT be cached
     Cache         |     1 | The envelope key should be cached
     Cache for MCS |     2 | The envelope key should be cached, but only
                   |       | to be used for the specific MCS.

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

   * Data: The encrypted envelope key (padding and formatting MUST be
    done according to RSA/PKCS#1 if RSA is used).

A.4. DH data payload

   The DH data payload carries the DH-value and indicates the DH-group

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   !  Next Payload !   DH-Group    !  DH-key len                   !
   ~                        DH-value                               ~
   !                                                               !
   ! Type  ! KV    ! KV data (optional)                            ~

Arkko, et al.                                                  [Page 38]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

   * DH-Group: identifies the DH group used.

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

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

   * DH-value: The public DH-value.

   * Type: Indicates the type of the key included in the payload, i.e.
    if the resulting DH-key will be used as a PMK or KEK (in the second
    case, the DH-key is not used directly as a KEK, but is derived
    according to Section 4.1.6). See also Appendix A.13. for pre-
    defined values.

   * KV: Indicates the type of key validity period specified. This may
    be done by using an SPI or by providing an interval in which the
    key is valid (e.g. in the latter case, for SRTP this will be the
    SEQ nr range where the key is valid). See Appendix A.13. for pre-
    defined values.

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

A.5. Signature payload

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

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   ! Signature len                 ! Signature                     ~

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

   * Signature: The signature (padding and formatting MUST be done
    according to RSA/PKCS#1 if RSA is used).

Arkko, et al.                                                  [Page 39]

INTERNET-DRAFT                msec-mikey-01                February 2002

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 the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * 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 of the specified TS type.

A.7. ID payload / Certificate payload

   The ID payload carries a uniquely-defined identifier.

   The certificate payload contains an indicator of the certificate
   provided as well as 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 the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * ID Type: specifies the identifier type used.

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

   * Cert Type: specifies the certificate type used.

Arkko, et al.                                                  [Page 40]

INTERNET-DRAFT                msec-mikey-01                February 2002

     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 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 the hash of the certificate used. The
   hash function used MUST be the one specified in the Common header
                        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 is added after this

   * Hash func: Indicates 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: the hash length is implicit from the
    hash function used.

A.9. Ver msg payload

   The Ver msg payload contains the calculated verification message in
   the PS/PK transport. Note that the MAC is calculated over the entire
   message as well as the IDs and Timestamp.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   ! Next Payload  ! Auth alg      ! Ver data                      ~

Arkko, et al.                                                  [Page 41]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

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

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

   * Ver data: The verification message data. Note: the length is
    implicit from the authentication algorithm used.

A.10. Security Policy payload

   The Security Policy payload defines a set of policies that applies to
   a specific security/re-key protocol.

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

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

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

   * Prot type: defines 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 the policy for the security/re-key protocol.

A.10.1. SRTPbasic policy

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

Arkko, et al.                                                  [Page 42]

INTERNET-DRAFT                msec-mikey-01                February 2002

                        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, these parameters might be an issue for update!

   * encr alg specifies the desired encryption algorithm to be used in
    SRTP (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 is AES in f8 mode with 128-bit block size.

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

   * auth alg specifies the desired authentication algorithm to 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.

   * auth tag len: desired length in bytes of the output tag of the MAC.

   * salt key len: The desired session salting key length in bytes.
    Note: do not mix this with the master salt that are exchanged.

   * PRF: Specifies the PRF used.

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

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

Arkko, et al.                                                  [Page 43]

INTERNET-DRAFT                msec-mikey-01                February 2002

A.10.2. SRTPext policy

   This policy separates the SRTP and SRTCP policies.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   ! SRTP EA       ! SRTP EKL      !
   ! 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 in bytes for SRTP.

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

   * SRTP KDR: the 2-logarithm of the 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 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.

Arkko, et al.                                                  [Page 44]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

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

A.10.3. Re-key policy

   The following attributes is supported according to GKMARCH.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   !  KEK alg      !  auth alg     !
   !  KEK key len                  ! auth key len                  !
   !  mm alg       !


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


     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        | Value
     NULL          |     0
     LKH           |     1

Arkko, et al.                                                  [Page 45]

INTERNET-DRAFT                msec-mikey-01                February 2002

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 the payload that is added after this

   * Rand len: Length of the Rand (in bytes). SHOULD be at least 16.

   * Rand: a randomly chosen bit-string.

A.12. Error payload

   The Error payload is used to specify the error(s) that may have

                        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 the payload that is added after this
    payload. If no more payload follows, it MUST be set to Last
    payload. See Appendix A.1. for values.

   * 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

Arkko, et al.                                                  [Page 46]

INTERNET-DRAFT                msec-mikey-01                February 2002

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 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 the payload that is added after this

   * Type: Indicates the type of the key included in the payload. Note
    that TEKs are not sent directly, but a PMK, which is then used 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 + a salt key are included
     KEK           |     2 | A Key-encrypting key

   * KV: Indicates the type of key validity period specified. This may
    be done by using an SPI or by providing an interval in which the
    key is valid (e.g. in the latter case, for SRTP this will be the
    SEQ nr range where the key is valid).

     KV            | Value | Comments
     Null          |     0 | No specific usage rule (e.g. a TEK
                   |       | that has no specific lifetime)
     SPI           |     1 | The key is associated with the SPI
     Interval      |     2 | The key has a start and expiration time
                   |       | (e.g. an SRTP TEK)

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

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

Arkko, et al.                                                  [Page 47]

INTERNET-DRAFT                msec-mikey-01                February 2002

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

   * Salt len: The salt key length in bytes. Note that this field is
    only included if the salt is specified in the Type-field.

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

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

A.14. Key validity data

   The Key validity data is not a payload, but part of either the Key
   data payload (see Appendix A.13.) or the DH payload (see Appendix
   A.4.). The Key validity data gives a guideline of when the key should
   be used. This can be done, using an SPI or a lifetime range.


                        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 of the SPI (or MKI) in bytes.

   * SPI: The SPI (or MKI for SRTP).

                        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
   ! VF Length     ! Valid from                                    ~
   ! VT Length     ! Valid to (expires)                            ~

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

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

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

Arkko, et al.                                                  [Page 48]

INTERNET-DRAFT                msec-mikey-01                February 2002

   * Valid to: Sequence number, timestamp, or other expiration value
    that the security protocol can use to identify the expiration 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 Key Identifier,
   MKI). It is recommended that if more than one SRTP stream is sharing
   the same keys and key update/re-keying is desired, this is handled
   using SPI rather than the From-To method.

Appendix B. - Payload usage summary

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

   * Pre-shared key transport message

   * Public key transport message

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

   * DH exchange message (bi-directional)

   * Error message

                 |          Message Type
   Payload type  | PS   | PK   | DH   | Ver  | Error
   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      -      O
   Rand          | M@     M@     M@     -      -

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

   + These messages may be included to authenticate the error message.
    However, before the other peer has been correctly authenticated, it

Arkko, et al.                                                  [Page 49]

INTERNET-DRAFT                msec-mikey-01                February 2002

    is not recommended that the error messages are sent authenticated
    (as this would open up for DoS attacks).

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

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

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

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

Revision history

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

   This Internet-Draft expires in August 2002.

Arkko, et al.                                                  [Page 50]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/