Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3830

MIKEY: Multimedia Internet KEYing

Pages: 66
Proposed Standard
Errata
Updated by:  47386309
Part 1 of 4 – Pages 1 to 15
None   None   Next

Top   ToC   RFC3830 - 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   ToC   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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   RFC3830 - 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 Section