[Docs] [txt|pdf] [Tracker] [WG] [Email] [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: May 2002                                             M. Naslund
                                                              K. Norrman

                                                          November, 2001

                   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.

Arkko, et al.                                                   [Page 1]

INTERNET-DRAFT                 msec-mikey                  November 2001


   1. Introduction..............................................3
   1.1. Notational Conventions..................................3
   1.2. Definitions.............................................3
   1.3. Abbreviations...........................................4
   1.4. Outline.................................................5
   2. Basic Overview............................................5
   2.1. Scenarios...............................................5
   2.2. Design Goals............................................6
   2.3. System Overview.........................................7
   2.4. Existing solutions......................................8
   3. Basic Key Transport and Exchange Schemes..................8
   3.1. Pre-shared key..........................................8
   3.2. Public-key encryption...................................9
   3.3. Diffie-Hellman key exchange.............................10
   4. Key Management............................................11
   4.1. TEK and Verification key Calculation....................11
   4.1.1. Assumptions...........................................12
   4.1.2. Notation..............................................12
   4.1.3. Description...........................................12
   4.2. Re-keying...............................................13
   5. Behavior and message handling.............................14
   5.1. General.................................................14
   5.1.1. Capability discovery..................................14
   5.1.2. Error handling........................................14
   5.2. Creating a message......................................14
   5.3. Parsing a message.......................................15
   5.4. Replay handling.........................................16
   5.5. Reliability.............................................17
   6. SDP integration...........................................17
   7. Key management with SIP...................................18
   7.1. Integration.............................................18
   7.2. Re-keying...............................................18
   8. Key management with RTSP..................................19
   8.1. Integration.............................................19
   8.2. Re-keying...............................................19
   9. Groups....................................................19
   10. Security Considerations..................................21
   10.1. General................................................21
   10.2. Key lifetime...........................................22
   10.3. Timestamps.............................................22
   10.4. Identity protection....................................23
   10.5. Denial of Service......................................23
   11. Conclusions..............................................24
   12. Acknowledgments..........................................24
   13. Author's Addresses.......................................24
   14. References...............................................25

   Appendix A - Payload Encoding................................27
   A.1.  Common header payload..................................27

Arkko, et al.                                                   [Page 2]

INTERNET-DRAFT                 msec-mikey                  November 2001

   A.2.  PS data payload........................................29
   A.3.  PK data payload........................................30
   A.4.  DH data payload........................................30
   A.5.  Signature payload......................................31
   A.6.  Timestamp payload......................................31
   A.7. ID payload / Certificate payload........................32
   A.8. Cert hash payload.......................................33
   A.9. Ver msg payload.........................................33
   A.10. n_start/n_end/SPI payload..............................34
   A.11. SP payload.............................................34
   A.12. Error payload..........................................36

   Appendix B. - Payload usage summary..........................36

1. Introduction

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

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

1.1. Notational Conventions

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

1.2. Definitions

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

   Crypto Session ID: unique identifier for the Crypto Session.

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

Arkko, et al.                                                   [Page 3]

INTERNET-DRAFT                 msec-mikey                  November 2001

   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
   security protocol). The TEKs are derived from the MCS's PMK.

   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
   E(k,m):    encryption of m with the key k
   D(k,m):    decryption of m with the key k
   Sign(k,m): the signature of message m with key k
   PK_x:      the public key of x
   SK_x:      the secret key of x
   Cert_x:    Certificate of x
   k_p:       the PMK
   []         an optional piece of information
   ||         concatenation
   |          logical OR
   ^          binary exclusive OR
   **         exponentiation

   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
   MAC    Message Authentication Code
   MIKEY  Multimedia Internet KEYing
   OFB    Output Feedback Mode
   PK     Public-Key

Arkko, et al.                                                   [Page 4]

INTERNET-DRAFT                 msec-mikey                  November 2001

   PS     Pre-Shared
   RTP    Real-time Transport Protocol
   RTSP   Real Time Streaming Protocol
   SDP    Session Description Protocol
   SIP    Session Initiation Protocol
   SRTP   Secure RTP

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

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

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

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

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

   The Security Considerations section (Section 10), 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 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 the security is either set up by mutual agreement or
     each party sets up the security for its own outgoing streams.

Arkko, et al.                                                   [Page 5]

INTERNET-DRAFT                 msec-mikey                  November 2001

   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.

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

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

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

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

2.2. Design Goals

   The goal has been to create a protocol that satisfies most of the
   requirements stated in [REQS]. The key management protocol is
   designed to have the following characteristics:

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

   * Simplicity.

   * Efficiency. Designed to have:
     - low bandwidth consumption,
     - low computational workload,

Arkko, et al.                                                   [Page 6]

INTERNET-DRAFT                 msec-mikey                  November 2001

     - small code size, and
     - minimal number of round-trips.

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

   * Independent of the security of the underlying transport.

2.3. System Overview

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

   The procedure of setting up a Crypto Session and creating a TEK, is
   done in accordance to Figure 2.1.:
   1. A Security Association (SA) and a Pre-Master Key (PMK) are created
     for the Multimedia Crypto Session (this is done by one of three
     alternative key transport/exchange mechanisms, see Section 4).
   2. The PMK is used to derive (in a cryptographically secure way) a
     TEK for each Crypto Session.
   3. The TEK is used as the key input to the Security Protocol.

                         |       MCS       |
                         |  Key transport  |
                         |    /exchange    |
                         - - - - - - - - - -
                         |       SA        |
                                  |      :
                                  | PMK  :
                                  v      :
                            ------------ :
                    CS ID ->|   TEK    | : Security Protocol
                            |derivation| : Parameters
                            ------------ :
                                  | TEK  :
                                  v      v
                               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.

Arkko, et al.                                                   [Page 7]

INTERNET-DRAFT                 msec-mikey                  November 2001

   The re-keying procedure is managed by running the transport/exchange
   phase once more to derive a new PMK (and consequently the TEKs).

2.4. 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 in Section 3 and
   in [REQS], there is however a need for a scheme more suitable for
   demanding cases such as real-time data over heterogeneous networks.

3. Basic Key Transport and Exchange Schemes

   The following sections propose three different ways to transport/
   exchange a Pre-Master Key: with the use of a pre-shared key, public-
   key encryption, and Diffie-Hellman (DH) key exchange. The two first
   methods we call key transport. In the following we assume unicast

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

3.1. Pre-shared key

   The pre-shared key case is done according to Figure 3.1. The Pre-
   Master Key (k_p) is randomly chosen by the initiator and then
   encrypted with the pre-shared key and sent to the responder. T is a
   timestamp added by the Initiator to prevent replay attacks. The
   entire message MUST be integrity protected by a Message
   Authentication Code (MAC). It is assumed that the pre-shared secret,
   s, consists of key material for both the encryption (encr_key) and
   the integrity protection (auth_key). The identity IDa MAY be sent to
   correctly select the pre-shared key to be used.

                  A                                     B

   K = [IDa],T, E(encr_key,k_p)
   A = MAC(auth_key,K)

                               K, A
                    --------------------- >

   Figure 3.1. Pre-shared key based transport mechanism.

Arkko, et al.                                                   [Page 8]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

   Note that 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

3.2. Public-key encryption

   Public-key cryptography can be used to create a scalable system. A
   disadvantage with this approach is that it is more resource consuming
   than the pre-shared key approach. Another disadvantage is that in
   most cases a PKI (Public Key Infrastructure) is needed to handle the
   distribution of public keys.

          A                                             B

     || T
     [|| I]
     [|| H(Cert_B)]



   Figure 3.2. Key transport using public keys.

   The key transport mechanism is according to Figure 3.2. The initiator
   encrypts a randomly chosen value k_p, to be used as the PMK, with the
   responder's public key (which the initiator already has). The
   Initiator creates a message consisting of the encrypted k_p, a
   timestamp, and optionally its ID/Certificate and a hash of the
   certificate used to encrypt k_p. The message is then signed and sent
   to the responder.

Arkko, et al.                                                   [Page 9]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

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

   Certificate handling is in general complex; the scheme shown here is
   not the only one possible. For example, it is possible for B to fetch
   A's certificate via other means. Verification of certificate against
   Revocation Lists is not treated here, but may add extra delay.

   Certificate handling 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:

     - 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

   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
   parameters are given in the DH payload in Appendix A.6. Note that the
   group MUST have a size of at least two to the power of the desired
   PMK size.

Arkko, et al.                                                  [Page 10]

INTERNET-DRAFT                 msec-mikey                  November 2001

               A                                  B

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

   k_p= g**(xy)                               k_p=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
   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

   Both parties then calculate the PMK, g**(xy).

   The authentication is due to the signing of the DH key, and is
   necessary to avoid man-in-the-middle attacks.

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

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

4. Key Management

4.1. TEK and Verification key Calculation

   We define in the following a method to derive a Verification key and
   TEKs from the PMK.

Arkko, et al.                                                  [Page 11]

INTERNET-DRAFT                 msec-mikey                  November 2001

4.1.1. Assumptions

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

   k_p: the PMK, which MUST be random and kept secret.

   The following parameter MAY be sent in the clear:

   mcs_id: Master Crypto Session ID

   cs_id: the Crypto Session ID

   pmk_len: the length of the PMK.

   tek_len: desired TEK length for the security protocol.

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)

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

4.1.3. Description

   The following procedure is applied to compute the TEK:

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

   Then, the TEK is obtained as the tek_len most significant bits of

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

   The procedure of generating the Verification key, k_v, is the same,
   replacing the constant string "MIKEYtek" by the constant string
   "MIKEYver", and cs_id by 0. (This gives a verification key of length
   equal to tek_len).

Arkko, et al.                                                  [Page 12]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

4.2. Re-keying

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

   The necessary parameter(s) to be defined to support the re-keying
   procedure is the new PMK and (when applicable) a signature (with the
   corresponding parameters as defined in Section 3.2 and 3.3). It may
   be necessary to specify the key lifetime range e.g. to trigger a new
   re-keying procedure during the on-going Multimedia Crypto Session.

   The parameters for re-keying are the following:

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

   SPI is an identifier of the new k_p. This can only be used when it is
   supported by the security protocol. Note that the use of SPI will
   exclude the use of n_start and n_end.

   n_start and n_end define the lifetime range of the PMK k_p (and MAY
   be used instead of a SPI). The lifetime range MAY be expressed in
   terms of time, packet index, etc. The deployed security protocol MUST
   specify which unit is used.

   If n_start and n_end is not specified, the default n_start value
   SHOULD be that the key is valid from the first observed packet. For
   the n_end value, as default the key is valid 'until further notice'.
   This does not mean that the protocol will be able to run forever (all
   security protocols will 'exhaust' the TEK sooner or later).

   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 then recommended that one main Crypto Session is
   identified from the MCS and the re-keying is done with respect to
   that. Exactly how this should be done is for future study.

   Note that 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.

Arkko, et al.                                                  [Page 13]

INTERNET-DRAFT                 msec-mikey                  November 2001

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.

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 a response 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.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
   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 ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~

Arkko, et al.                                                  [Page 14]

INTERNET-DRAFT                 msec-mikey                  November 2001

   :                             :                                 :
   :                             :                                 :
   ! next payload  !   Payload x ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   ~                   MAC/Signature payload                       ~
   +                                                               +
   !                                                               !

   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 what payloads MUST/MAY be used for the different messages).

   * As a last step (for messages that must be authenticated),
    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.

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 the authentication is successful, the message SHOULD be
    processed. Though how it is processed is implementation specific.

Arkko, et al.                                                  [Page 15]

INTERNET-DRAFT                 msec-mikey                  November 2001

   * 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

   * If needed, a 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 10.3. for timestamp considerations).

   * 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

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

Arkko, et al.                                                  [Page 16]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

6. SDP integration

   SDP descriptions [SDP] can be carried by several protocols, such as
   SIP and RTSP. One of the goals in the design of MIKEY was to be able
   to piggy-back it in other protocols (such as SIP and RTSP). Both SIP
   and RTSP often uses 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


   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.

   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

Arkko, et al.                                                  [Page 17]

INTERNET-DRAFT                 msec-mikey                  November 2001

   In this example the multimedia crypto session consists of two crypto
   sessions (one audio stream and one video stream).

7. Key management with SIP

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

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

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

7.1. Integration

   SIP may carry SDP descriptions, since the participants negotiate the
   media encoding etc. Therefore, the SDP attributes previously
   described may be integrated inside the INVITE and the answer to that.
   Eventually, subsequent SIP messages may also be used, e.g., when
   parameter negotiation is needed.

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

7.2. Re-keying

   A re-keying mechanism is necessary, e.g. when the key is compromised
   or simply because it has a restricted lifetime. When SIP is used as
   the session establishment protocol, a re-INVITE can be issued
   carrying SDP with the MIKEY data (this is sent by the Initiator of
   MIKEY). Note that it might not be necessary to send all information,
   such as the certificate, due to the already established call.

Arkko, et al.                                                  [Page 18]

INTERNET-DRAFT                 msec-mikey                  November 2001

8. Key management 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 not containing a SDP description, the RTSP KeyMgmt
   header (defined in [KMASDP]) is used.

8.1. Integration

   The server MUST  include the necessary security parameters, key
   included, in the SDP part of the response to the initial DESCRIBE

   If a response is required, this should be included in the first SETUP
   message from the client to the server. Note that the SETUP message
   does not include a SDP description, why the RTSP KeyMgmt header
   (defined in [KMASDP]) MUST be used to pass the MIKEY 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.

8.2. Re-keying

   To be able to have a server initiated re-keying procedure, either the
   ANNOUNCE message or the SET_PARAMETER message SHOULD be used to send
   the re-keying material. A disadvantage of using these, are 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).

9. Groups

   What has been discussed up to now can be extended from the unicast
   case to small-size groups and simple one-to-many scenarios. However,
   key management is more complex in the case of groups. This section
   does not give a solution for how MIKEY should be used for groups
   (that will be a second step in the process of MIKEY). This section
   only describes some properties of the transport and exchange
   mechanisms that might be of importance for future work and extensions
   in the area.

Arkko, et al.                                                  [Page 19]

INTERNET-DRAFT                 msec-mikey                  November 2001

9.1. Simple one-to-many

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

               Figure 9.1. Simple one-to-many scenario.

   In the most simple one-to-many scenario, where 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 server
   would then act as the Initiator of MIKEY (see also Section 8.). In
   this scenario the pre-shared key or public key transport mechanism
   would be appropriate to use to transport the same PMK to all the
   clients (which will result in common TEKs for the group).

   However, as the group increases in size, scalability and management
   problems may arise. The Group Key Management Architecture [GARCH]
   describes a scalable architecture of handling this scenario. The
   architecture can be used as a base for how MIKEY should be used in
   order to handle scalable groups. Some minor extensions to MIKEY will
   be needed, such as the transport of a key-encrypting key (KEK).
   However, this document does not consider how MIKEY should be used
   with the architecture.

9.2. Small-size group

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

   Figure 9.2. Small-size group without centralized controller.

Arkko, et al.                                                  [Page 20]

INTERNET-DRAFT                 msec-mikey                  November 2001

   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 should be used.

   One scenario may then be that the client sets up a three-part call,
   using SIP. Due to the small size group, unicast SRTP is used between
   the clients. Each client may set up the security for its outgoing
   streams to the others. A scenario like this would not require any
   modifications neither to MIKEY nor SIP/SDP.

10. Security Considerations

10.1. General

   No chain is stronger than its weakest link. The cryptographic
   functions protecting the keys during transport/exchange SHOULD offer
   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

   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.

Arkko, et al.                                                  [Page 21]

INTERNET-DRAFT                 msec-mikey                  November 2001

   Specifically, the TEK key derivation is 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, motivated by the risk of
   one of the hashes being broken. We motivate our simplification by the
   observation that if a single widely used hash, e.g. SHA1, is broken,
   the wide-spread use of that function means that we have much more to
   be worried about than the security of a single protocol. Also, SHA1
   would need to have very serious flaws for our pseudo random function
   to be considered insecure.

   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, k_p, 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.

10.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
   packet (i.e. every time the ROC + SEQ nr in SRTP wraps).

   As a rule of thumb, if the security protocol uses an 'ideal' b-bit
   block cipher (in CBC mode, counter mode, or a feedback mode with full
   b-bit feedback), degenerate behavior in the crypto stream, possibly
   useful for an attacker, is expected to occur after a total of roughly
   2**(b/2) encrypted b-bit blocks (using random IVs). For some security
   margin, re-keying SHOULD be triggered well 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.

10.3. Timestamps

   The timestamp prevents against replay attacks under the following

Arkko, et al.                                                  [Page 22]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

10.4. Identity protection

   Identity protection was not a main design goal when designing MIKEY.
   Such feature would have added more complexity to the protocol and was
   therefore chosen not 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.

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

Arkko, et al.                                                  [Page 23]

INTERNET-DRAFT                 msec-mikey                  November 2001

   solved by letting the protocol transporting MIKEY do an IP address
   validity test.

11. Conclusions

   Work for securing real-time applications have started to appear. This
   has brought forward 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. 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 can be used in different scenarios, for peer-to-peer
   communication, simple one-to-many, and for small-size groups without
   a centralized group server. This specification focused on the basic
   peer-to-peer scenario, as this also will be the base for the group

12. Acknowledgments

   The authors would like to thank, Mark Baugher, Ran Canetti, the rest
   of the msec WG, Pasi Ahonen, Rolf Blom, Vesa-Matti Mantyla, and
   Magnus Westerlund, for their valuable feedback.

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

Arkko, et al.                                                  [Page 24]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

14. References

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

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

   [GARCH] Baugher, M., Canetti, R., and Dondeti, L., "Group Key
   Management Architecture", Internet Draft, June 2001, Work in

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

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

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

Arkko, et al.                                                  [Page 25]

INTERNET-DRAFT                 msec-mikey                  November 2001

   [PKCS1] PKCS #1 - RSA Cryptography Standard,

   [REQS] Blom, R., Carrara, E., Lindholm, F., and Arkko, J., "Design
   Criteria for Multimedia Session Key Management in Heterogeneous
   Networks", Internet Draft, July 2001, Work in Progress.

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

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

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

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

   [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] 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 26]

INTERNET-DRAFT                 msec-mikey                  November 2001

Appendix A - Payload Encoding

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

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! Hash func   !
   ! MCS/CS ID type!                                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                           MCS/CS ID                           ~
   !                                                               !

   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 transport message
   PS ver msg    |     1 | Verification message of a Pre-shared 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

   Next payload  | Value
   Last payload  |     0
   PS data       |     1

Arkko, et al.                                                  [Page 27]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

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

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

   * Hash func: Indicates the hash function that has been/will be used.

   Hash func     | Value | Comments
   SHA-1         |     0 | Mandatory, Default (see [SHA1])
   MD5           |     1 | (see [MD5])
   SHA256        |     2 | (see [SHA256])
   SHA384        |     3 | (see [SHA256])
   SHA512        |     4 | (see [SHA256])

   * MCS/CS ID type: specifies the id used to uniquely identify the MCS
    and the CS(s).

   MCS/CS ID type | Value | Comments
   SRTP-ID        |     0 | Mandatory

   * MCS/CS ID: Identifies the multimedia crypto session and/or the
    crypto session(s) that the SA should be created for. The currently
    defined IDs are:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   !   #CS         !                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   !                                                               !

Arkko, et al.                                                  [Page 28]

INTERNET-DRAFT                 msec-mikey                  November 2001

   +                       SRTP MCS ID (80 bits)                   +
   !                                                               !
   !                           SSRC 1                              !
   !                           SSRC 2                              !
   :                               :                               :
   !                           SSRC #CS                            !

   * #CS: Indicates the number of Crypto Sessions, i.e. the number of
    SRTP streams.

   * SRTP MCS ID: MUST be chosen at random by the Initiator (the
    Initiator SHOULD however check for collisions). The Responder MUST
    use the same MCS ID in the response.

   * 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 possible that the Initiator of MIKEY does
    can not fill in all fields. In this case, SSRCs that are not chosen
    by the Initiator are set to zero and the Responder fills in these
    field in the response message.

   NOTE: A stream using SSRC x will also have Crypto Session ID x.

A.2. PS data payload

   The PS (pre-shared) data payload contains the encrypted PMK and the
   MAC of the entire message. The PS data payload MUST be added as the
   last payload in the pre-shared transport 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
   ! MAC alg       ! Encr alg      ! Encr data len | Reserved      !
   ~                        Encr data                              ~
   !                                                               !
   ~                        MAC                                    ~
   !                                                               !

   * MAC alg specifies the authentication algorithm used.

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

Arkko, et al.                                                  [Page 29]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

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

   Encr alg      | Value | Comments
   AES-CM-128    |     1 | Mandatory

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

   * Encr data: The encrypted PMK.

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

A.3. PK data payload

   The PK (public-key) data payload contains the encrypted data from the
   PK transport.

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

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

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

   * Key data: The encrypted PMK (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

Arkko, et al.                                                  [Page 30]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

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

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

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

   * DH-value: The public DH-value.

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

A.6. Timestamp payload

   The timestamp payload carries the time information. The current
   defined timestamp is as defined in NTP [NTP], i.e. a 64-bit number in
   seconds relative to 0h on 1 January 1900. An implementation must be

Arkko, et al.                                                  [Page 31]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

                        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-GMT       |     0 | Mandatory (64-bits)
   NTP           |     1 | Mandatory (64-bits)

   Note that NTP-GMT is the NTP time but calculated from GMT. This is to
   avoid time-zone problems.

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

Arkko, et al.                                                  [Page 32]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

   * Cert Type: specifies the certificate type used.

   Cert Type     | Value | Comments
   X.509         |     0 | Mandatory
   X.509 URL     |     1 |

   * 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                              ~
   !                                                               !

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

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

                        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 33]

INTERNET-DRAFT                 msec-mikey                  November 2001

   * 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. n_start/n_end/SPI payload

   The n_start/n_end/SPI payload defines the n_start value, the n_end
   value or the SPI as defined in Section 4.2.

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

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

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

   * Valid from: Indicates the Index/Sequence number when the key is
    valid from. The field size is dependent on the security protocol.
    For SRTP, this field MUST be 48 bits.

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

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

A.11. SP payload

   The SP payload defines the security protocol that will be used, and
   its related parameters.

Arkko, et al.                                                  [Page 34]

INTERNET-DRAFT                 msec-mikey                  November 2001

                        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  ! SP            ! SP 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.

   * SP defines the security protocol used.

   SP            | Value
   SRTP          |     0

   * SP param defines the parameters for the security protocol. SP param
    is dependent on the defined security protocol.

   For SRTP the SP param is currently defined as:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   !  encr alg     !  auth alg     !
   !  Salt len     !  Salt key                                     ~

   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.

   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 and key.
   AES-F8-128 is AES in f8 mode with 128-bit block size and key.

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

   auth alg      | Value | Comments
   NULL          |     0 | Mandatory

Arkko, et al.                                                  [Page 35]

INTERNET-DRAFT                 msec-mikey                  November 2001

   TMMH-16-16    |     1 | ?
   HMAC-SHA1-32  |     2 | ?

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

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

   * Salt len: Length of the salting key.

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

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 | hash function NOT supported
   Invalid MA    |     3 | MAC algorithm NOT supported
   Invalid DH    |     4 | DH group NOT supported
   Invalid ID    |     5 | ID NOT supported
   Invalid Cert  |     6 | certificate NOT supported
   Invalid SP    |     7 | SP NOT supported
   Invalid SPpar |     8 | SP parameters NOT supported

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

Arkko, et al.                                                  [Page 36]

INTERNET-DRAFT                 msec-mikey                  November 2001

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

   * DH exchange message (bi-directional)

   * Error message

                 |          Message Type
   Payload type  | PS   | PK   | DH   | Ver  | Error
   PS data       | M      -      -      -      -
   PK data       | -      M*     -      -      -
   DH data       | -      -      M      -      -
   Ver msg       | -      -      -      M      -
   Error         | -      -      -      -      M
   Timestamp     | M      M      M      -      O
   ID            | O      O      O      O      O
   Signature     | -      O      M      -      -
   Certificate   | -      O      O      -      -
   Cert hash     | -      O      O      -      -
   n_start       | O      O      O      -      -
   n_end         | O      O      O      -      -
   SPI           | O      O      O      -      -
   SP            | O      O      O      -      O

   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.

   This Internet-Draft expires in May 2002.

Arkko, et al.                                                  [Page 37]

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