tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3830

 Errata 
Proposed STD
Pages: 66
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MSEC

MIKEY: Multimedia Internet KEYing

Part 1 of 4, p. 1 to 15
None       Next RFC Part

Updated by:    4738    6309


Top       ToC       Page 1 
Network Working Group                                           J. Arkko
Request for Comments: 3830                                    E. Carrara
Category: Standards Track                                    F. Lindholm
                                                              M. Naslund
                                                              K. Norrman
                                                       Ericsson Research
                                                             August 2004


                   MIKEY: Multimedia Internet KEYing

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a key management scheme that can be used for
   real-time applications (both for peer-to-peer communication and group
   communication).  In particular, its use to support the Secure Real-
   time Transport Protocol is described in detail.

   Security protocols for real-time multimedia applications have started
   to appear.  This has brought forward the need for a key management
   solution to support these protocols.

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Existing Solutions . . . . . . . . . . . . . . . . . . .  4
       1.2.  Notational Conventions . . . . . . . . . . . . . . . . .  4
       1.3.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  4
       1.4.  Abbreviations. . . . . . . . . . . . . . . . . . . . . .  6
       1.5.  Outline. . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.1.  Scenarios. . . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.  Design Goals . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.  System Overview. . . . . . . . . . . . . . . . . . . . .  8
       2.4.  Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
   3.  Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
       3.1.  Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
       3.2.  Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
       3.3.  Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
   4.  Selected Key Management Functions. . . . . . . . . . . . . . . 15
       4.1.  Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
             4.1.1.  Assumptions. . . . . . . . . . . . . . . . . . . 16
             4.1.2.  Default PRF Description. . . . . . . . . . . . . 17
             4.1.3.  Generating keys from TGK . . . . . . . . . . . . 18
             4.1.4.  Generating keys for MIKEY Messages from
                     an Envelope/Pre-Shared Key . . . . . . . . . . . 19
       4.2.  Pre-defined Transforms and Timestamp Formats . . . . . . 19
             4.2.1.  Hash Functions . . . . . . . . . . . . . . . . . 19
             4.2.2.  Pseudo-Random Number Generator and PRF . . . . . 20
             4.2.3.  Key Data Transport Encryption. . . . . . . . . . 20
             4.2.4.  MAC and Verification Message Function. . . . . . 21
             4.2.5.  Envelope Key Encryption. . . . . . . . . . . . . 21
             4.2.6.  Digital Signatures . . . . . . . . . . . . . . . 21
             4.2.7.  Diffie-Hellman Groups. . . . . . . . . . . . . . 21
             4.2.8.  Timestamps . . . . . . . . . . . . . . . . . . . 21
             4.2.9.  Adding New Parameters to MIKEY . . . . . . . . . 22
       4.3.  Certificates, Policies and Authorization . . . . . . . . 22
             4.3.1.  Certificate Handling . . . . . . . . . . . . . . 22
             4.3.2.  Authorization. . . . . . . . . . . . . . . . . . 23
             4.3.3.  Data Policies. . . . . . . . . . . . . . . . . . 24
       4.4.  Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
       4.5.  TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
   5.  Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
       5.1.  General. . . . . . . . . . . . . . . . . . . . . . . . . 26
             5.1.1.  Capability Discovery . . . . . . . . . . . . . . 26
             5.1.2.  Error Handling . . . . . . . . . . . . . . . . . 27
       5.2.  Creating a Message . . . . . . . . . . . . . . . . . . . 28
       5.3.  Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
       5.4.  Replay Handling and Timestamp Usage. . . . . . . . . . . 30
   6.  Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32

Top      ToC       Page 3 
       6.1.  Common Header Payload (HDR). . . . . . . . . . . . . . . 32
             6.1.1.  SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
       6.2.  Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
       6.3.  Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
       6.4.  DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
       6.5.  Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
       6.6.  Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
       6.7.  ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
       6.8.  Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
       6.9.  Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
       6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
             6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
       6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
       6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
       6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
       6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
       6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
   7.  Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
   8.  Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
       8.1.  Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
       8.2.  Small-Size Interactive Group . . . . . . . . . . . . . . 51
   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 52
       9.1.  General. . . . . . . . . . . . . . . . . . . . . . . . . 52
       9.2.  Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
       9.3.  Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
       9.4.  Identity Protection. . . . . . . . . . . . . . . . . . . 55
       9.5.  Denial of Service. . . . . . . . . . . . . . . . . . . . 56
       9.6.  Session Establishment. . . . . . . . . . . . . . . . . . 56
   10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
       10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
   11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
       12.1. Normative References . . . . . . . . . . . . . . . . . . 60
       12.2. Informative References . . . . . . . . . . . . . . . . . 61
   Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 66

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 and related security parameters.  There are some
   fundamental properties that such a key management scheme has to
   fulfill to serve streaming and real-time applications (such as
   unicast and multicast), particularly in heterogeneous (mix of wired
   and wireless) networks.

Top      ToC       Page 4 
   This document describes a key management solution that addresses
   multimedia scenarios (e.g., SIP [SIP] calls and RTSP [RTSP]
   sessions).  The focus is on how to set up key management for secure
   multimedia sessions such that requirements in a heterogeneous
   environment are fulfilled.

1.1.  Existing Solutions

   There is work done in the 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 to address group
   communication [GDOI, GSAKMP].  However, for reasons discussed below,
   there is a need for a scheme with lower latency, suitable for
   demanding cases such as real-time data over heterogeneous networks
   and small interactive groups.

   An option in some cases might be to use [SDP], as SDP defines one
   field to transport keys, the "k=" field.  However, this field cannot
   be used for more general key management purposes, as it cannot be
   extended from the current definition.

1.2.  Notational Conventions

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

1.3.  Definitions

   (Data) Security Protocol: the security protocol used to protect the
   actual data traffic.  Examples of security protocols are IPsec and
   SRTP.

   Data Security Association (Data SA): information for the security
   protocol, including a TEK and a set of parameters/policies.

   Crypto Session (CS): uni- or bi-directional data stream(s), protected
   by a single instance of a security protocol.  For example, when SRTP
   is used, the Crypto Session will often contain two streams, an RTP
   stream and the corresponding RTCP, which are both protected by a
   single SRTP Cryptographic Context, i.e., they share key data and the
   bulk of security parameters in the SRTP Cryptographic Context
   (default behavior in [SRTP]).  In the case of IPsec, a Crypto Session
   would represent an instantiation of an IPsec SA.  A Crypto Session
   can be viewed as a Data SA (as defined in [GKMARCH]) and could
   therefore be mapped to other security protocols if necessary.

Top      ToC       Page 5 
   Crypto Session Bundle (CSB): collection of one or more Crypto
   Sessions, which can have common TGKs (see below) and security
   parameters.

   Crypto Session ID: unique identifier for the CS within a CSB.

   Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.

   TEK Generation Key (TGK): a bit-string agreed upon by two or more
   parties, associated with CSB.  From the TGK, Traffic-encrypting Keys
   can then be generated without needing further communication.

   Traffic-Encrypting Key (TEK): the key used by the security protocol
   to protect the CS (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 CSB's TGK.

   TGK re-keying: the process of re-negotiating/updating the TGK (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.

   Salting key: a random or pseudo-random (see [RAND, HAC]) string used
   to protect against some off-line pre-computation attacks on the
   underlying security protocol.

   PRF(k,x):  a keyed pseudo-random function (see [HAC]).
   E(k,m):    encryption of m with the key k.
   PKx:       the public key of x
   []         an optional piece of information
   {}         denotes zero or more occurrences
   ||         concatenation
   |          OR (selection operator)
   ^          exponentiation
   XOR        exclusive or

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

Top      ToC       Page 6 
1.4.  Abbreviations

   AES    Advanced Encryption Standard
   CM     Counter Mode (as defined in [SRTP])
   CS     Crypto Session
   CSB    Crypto Session Bundle
   DH     Diffie-Hellman
   DoS    Denial of Service
   MAC    Message Authentication Code
   MIKEY  Multimedia Internet KEYing
   PK     Public-Key
   PSK    Pre-Shared key
   RTP    Real-time Transport Protocol
   RTSP   Real Time Streaming Protocol
   SDP    Session Description Protocol
   SIP    Session Initiation Protocol
   SRTP   Secure RTP
   TEK    Traffic-encrypting key
   TGK    TEK Generation Key

1.5.  Outline

   Section 2 describes the basic scenarios and the design goals for
   which MIKEY is intended.  It also gives a brief overview of the
   entire solution and its relation to the group key management
   architecture [GKMARCH].

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

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

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

   Section 7 deals with transport considerations, while Section 8
   focuses on how MIKEY is used in group scenarios.

   The Security Considerations section (Section 9), gives a deeper
   explanation of important security related topics.

Top      ToC       Page 7 
2.  Basic Overview

2.1.  Scenarios

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

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

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

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

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

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

   c) many-to-many, without a centralized control unit, e.g., for
      small-size interactive groups where each party may set up the
      security for its own outgoing media.  Two basic models may be used
      here.  In the first model, the Initiator of the group acts as the

Top      ToC       Page 8 
      group server (and is the only one authorized to include new
      members).  In the second model, authorization information to
      include new members can be delegated to other participants.

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

   The key management solutions may be different in the above scenarios.
   When designing MIKEY, the main focus has been on case a, b, and c.
   For scenario c, only the first model is covered by this document.

2.2.  Design Goals

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

   *  End-to-end security.  Only the participants involved in the
      communication 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 roundtrips.

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

   *  Independence from any specific security functionality of the
      underlying transport.

2.3.  System Overview

   One objective of MIKEY is to produce a Data SA for the security
   protocol, including a traffic-encrypting key (TEK), which is derived
   from a TEK Generation Key (TGK), and used as input for the security
   protocol.

   MIKEY supports the possibility of establishing keys and parameters
   for more than one security protocol (or for several instances of the
   same security protocol) at the same time.  The concept of Crypto
   Session Bundle (CSB) is used to denote a collection of one or more
   Crypto Sessions that can have common TGK and security parameters, but
   which obtain distinct TEKs from MIKEY.

Top      ToC       Page 9 
   The procedure of setting up a CSB and creating a TEK (and Data SA),
   is done in accordance with Figure 2.2:

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

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

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

        +-----------------+
        |       CSB       |
        |  Key transport  |                      (see Section 3)
        |    /exchange    |
        +-----------------+
                 |      :
                 | TGK  :
                 v      :
           +----------+ :
   CS ID ->|   TEK    | : Security protocol      (see Section 4)
           |derivation| : parameters (policies)
           +----------+ :
              TEK |     :
                  v     v
                  Data SA
                    |
                    v
           +-------------------+
           |  Crypto Session   |
           |(Security Protocol)|
           +-------------------+

   Figure 2.2: Overview of MIKEY key management procedure.

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

   MIKEY can be used to update TEKs and the Crypto Sessions in a current
   Crypto Session Bundle (see Section 4.5).  This is done by executing
   the transport/exchange phase once again to obtain a new TGK (and
   consequently derive new TEKs) or to update some other specific CS
   parameters.

Top      ToC       Page 10 
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 the group controller/key server (GCKS), the
   receiver(s), and the sender(s).

   In MIKEY, the sender could act as GCKS and push keys down to the
   receiver(s).

   Note that, for example, in a SIP-initiated call, the sender may also
   be a receiver.  As MIKEY addresses small interactive groups, a member
   may dynamically change between being a sender and receiver (or being
   both simultaneously).

3.  Basic Key Transport and Exchange Methods

   The following sub-sections define three different methods of
   transporting/establishing a TGK: with the use of a pre-shared key,
   public-key encryption, and Diffie-Hellman (DH) key exchange.  In the
   following, we assume unicast communication for simplicity.  In
   addition to the TGK, a random "nonce", denoted RAND, is also
   transported.  In all three cases, the TGK and RAND values are then
   used to derive TEKs as described in Section 4.1.3.  A timestamp is
   also sent to avoid replay attacks (see Section 5.4).

   The pre-shared key method and the public-key method are both based on
   key transport mechanisms, where the actual TGK is pushed (securely)
   to the recipient(s).  In the Diffie-Hellman method, the actual TGK is
   instead derived from the Diffie-Hellman values exchanged between the
   peers.

   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 also has the advantage that only a small amount of data has
   to be exchanged.  Of course, the problematic issue is scalability as
   it is not always feasible to share individual keys with a large group
   of peers.  Therefore, this case mainly addresses scenarios such as
   server-to-client and also those cases where the public-key modes have
   already been used, thus allowing for the "cache" of a symmetric key
   (see below and Section 3.2).

   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

Top      ToC       Page 11 
   distribution of public keys.  Of course, it is possible to use public
   keys as pre-shared keys (e.g., by using self-signed certificates).
   It should also be noted that, as mentioned above, this method may be
   used to establish a "cached" symmetric key that later can be used to
   establish subsequent TGKs by using the pre-shared key method (hence,
   the subsequent request can be executed more efficiently).

   In general, the Diffie-Hellman (DH) key agreement method has a higher
   resource consumption (both computationally and in bandwidth) than the
   previous ones, and needs certificates as in the public-key case.
   However, it has the advantage of providing perfect forward secrecy
   (PFS) and flexibility by allowing implementation in several different
   finite groups.

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

   The following general notation is used:

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

   T:    The timestamp, used mainly to prevent replay attacks.  See
   Section 6.6 for payload definition and also Section 5.4 for other
   timestamp related information.

   IDx:  The identity of entity x (IDi=Initiator, IDr=Responder).  See
   Section 6.7 for payload definition.

   RAND: Random/pseudo-random byte-string, which is always included in
   the first message from the Initiator.  RAND is used as a freshness
   value for the key generation.  It is not included in update messages
   of a CSB.  See Section 6.11 for payload definition.  For randomness
   recommendations for security, see [RAND].

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

Top      ToC       Page 12 
3.1.  Pre-shared key

   In this method, the pre-shared secret key, s, is used to derive key
   material for both the encryption (encr_key) and the integrity
   protection (auth_key) of the MIKEY messages, as described in Section
   4.1.4.  The encryption and authentication transforms are described in
   Section 4.2.

   Initiator                                   Responder

      I_MESSAGE =
      HDR, T, RAND, [IDi],[IDr],
           {SP}, KEMAC                --->
                                                  R_MESSAGE =
                                     [<---]       HDR, T, [IDr], V

   The main objective of the Initiator's message (I_MESSAGE) is to
   transport one or more TGKs (carried into KEMAC) and a set of security
   parameters (SPs) to the Responder in a secure manner.  As the
   verification message from the Responder is optional, the Initiator
   indicates in the HDR whether it requires a verification message or
   not from the Responder.

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

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

   The main objective of the verification message from the Responder is
   to obtain mutual authentication.  The verification message, V, is a
   MAC computed over the Responder's entire message, the timestamp (the
   same as the one that was included in the Initiator's message), and
   the two parties identities, using the authentication key.  See also
   Section 5.2 for the exact definition of the Verification MAC
   calculation and Section 6.9 for payload definition.

   The ID fields SHOULD be included, but they MAY be left out when it
   can be expected that the peer already knows the other party's ID
   (otherwise it cannot look up the pre-shared key).  For example, this
   could be the case if the ID is extracted from SIP.

   It is MANDATORY to implement this method.

Top      ToC       Page 13 
3.2.  Public-key encryption

   Initiator                                        Responder

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

   As in the previous case, the main objective of the Initiator's
   message is to transport one or more TGKs and a set of security
   parameters to the Responder in a secure manner.  This is done using
   an envelope approach where the TGKs are encrypted (and integrity
   protected) with keys derived from a randomly/pseudo-randomly chosen
   "envelope key".  The envelope key is sent to the Responder encrypted
   with the public key of the Responder.

   The PKE contains the encrypted envelope key: PKE = E(PKr, env_key).
   It is encrypted using the Responder's public key (PKr).  If the
   Responder possesses several public keys, the Initiator can indicate
   the key used in the CHASH payload (see Section 6.8).

   The KEMAC contains a set of encrypted sub-payloads and a MAC:

   KEMAC = E(encr_key, IDi || {TGK}) || MAC

   The first payload (IDi) in KEMAC is the identity of the Initiator
   (not a certificate, but generally the same ID as the one specified in
   the certificate).  Each of the following payloads (TGK) includes a
   TGK randomly and independently chosen by the Initiator (and possible
   other related parameters, e.g., the key lifetime).  The encrypted
   part is then followed by a MAC, which is calculated over the KEMAC
   payload.  The encr_key and the auth_key are derived from the envelope
   key, env_key, as specified in Section 4.1.4.  See also Section 6.2
   for payload definition.

   The SIGNi is a signature covering the entire MIKEY message, using the
   Initiator's signature key (see also Section 5.2 for the exact
   definition).

   The main objective of the verification message from the Responder is
   to obtain mutual authentication.  As the verification message V from
   the Responder is optional, the Initiator indicates in the HDR whether
   it requires a verification message or not from the Responder.  V is
   calculated in the same way as in the pre-shared key mode (see also
   Section 5.2 for the exact definition).  See Section 6.9 for payload
   definition.

Top      ToC       Page 14 
   Note that there will be one encrypted IDi and possibly also one
   unencrypted IDi.  The encrypted one is used together with the MAC as
   a countermeasure for certain man-in-the-middle attacks, while the
   unencrypted one is always useful for the Responder to immediately
   identify the Initiator.  The encrypted IDi MUST always be verified to
   be equal with the expected IDi.

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

   The cleartext ID fields and certificate SHOULD be included, but they
   MAY be left out when it can be expected that the peer already knows
   the other party's ID, or can obtain the certificate in some other
   manner.  For example, this could be the case if the ID is extracted
   from SIP.

   For certificate handling, authorization, and policies, see Section
   4.3.

   It is MANDATORY to implement this method.

3.3.  Diffie-Hellman key exchange

   For a fixed, agreed upon, cyclic group, (G,*), we let g denote a
   generator for this group.  Choices for the parameters are given in
   Section 4.2.7.  The other transforms below are described in Section
   4.2.

   This method creates a DH-key, which is used as the TGK.  This method
   cannot be used to create group keys; it can only be used to create
   single peer-to-peer keys.  It is OPTIONAL to implement this method.

   Initiator                                          Responder

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

Top      ToC       Page 15 
   The main objective of the Initiator's message is to, in a secure way,
   provide the Responder with its DH value (DHi) g^(xi), where xi MUST
   be randomly/pseudo-randomly and secretly chosen, and a set of
   security protocol parameters.

   The SIGNi is a signature covering the Initiator's MIKEY message,
   I_MESSAGE, using the Initiator's signature key (see Section 5.2 for
   the exact definition).

   The main objective of the Responder's message is to, in a secure way,
   provide the Initiator with the Responder's value (DHr) g^(xr), where
   xr MUST be randomly/pseudo-randomly and secretly chosen.  The
   timestamp that is included in the answer is the same as the one
   included in the Initiator's message.

   The SIGNr is a signature covering the Responder's MIKEY message,
   R_MESSAGE, using the Responder's signature key (see Section 5.2 for
   the exact definition).

   The DH group parameters (e.g., the group G, the generator g) are
   chosen by the Initiator and signaled to the Responder.  Both parties
   calculate the TGK, g^(xi*xr) from the exchanged DH-values.

   Note that this approach does not require that the Initiator has to
   possess any of the Responder's certificates before the setup.
   Instead, it is sufficient that the Responder includes its signing
   certificate in the response.

   The ID fields and certificate SHOULD be included, but they MAY be
   left out when it can be expected that the peer already knows the
   other party's ID (or can obtain the certificate in some other
   manner).  For example, this could be the case if the ID is extracted
   from SIP.

   For certificate handling, authorization, and policies, see Section
   4.3.



(page 15 continued on part 2)

Next RFC Part