RFC 3830
MIKEY: Multimedia Internet KEYing
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.
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
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.
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.
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.
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 Key1.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.
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
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.
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.
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
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.
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.
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.
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
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)
