Internet Engineering Task Force J. Arkko MSEC Working Group E. Carrara INTERNET-DRAFT F. Lindholm Expires: December 2002 M. Naslund K. Norrman Ericsson June, 2002 MIKEY: Multimedia Internet KEYing Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract 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. Such a solution has to be suitable to be used in the context of conversational multimedia in a heterogeneous environment. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. Arkko, et al. [Page 1] INTERNET-DRAFT msec-mikey-02 June 2002 TABLE OF CONTENTS 1. Introduction.....................................................3 1.1. Notational Conventions.........................................4 1.2. Definitions....................................................4 1.3. Abbreviations..................................................5 1.4. Outline........................................................5 2. Basic Overview...................................................6 2.1. Scenarios......................................................6 2.2. Design Goals...................................................7 2.3. System Overview................................................7 2.4. Relation to GKMARCH............................................8 2.5. Existing solutions.............................................9 3. Basic Key Transport and Exchange Methods.........................9 3.1. Pre-shared key................................................10 3.2. Public-key encryption.........................................11 3.3. Diffie-Hellman key exchange...................................13 4. Key Management..................................................14 4.1. Key Calculation...............................................14 4.1.1. Assumptions.................................................14 4.1.2. Notation....................................................14 4.1.3. PRF Description.............................................15 4.1.4. Generating keys from TGK....................................15 4.1.5. Generating keys from an envelope/pre-shared key.............15 4.2 Pre-defined Transforms and Timestamp Formats...................16 4.2.1 Hash functions...............................................16 4.2.2 Pseudo random number generator and PRF.......................16 4.2.3 Key data transport encryption................................16 4.2.4 MAC and Verification Message function........................17 4.2.5 Envelope Key encryption......................................17 4.2.6 Digital Signatures...........................................17 4.2.7 Diffie-Hellman Groups........................................17 4.2.8. Timestamps..................................................17 4.2.9. Adding new parameters to MIKEY..............................17 4.3. Policies......................................................18 4.4. Retrieving the Data SA........................................18 4.5. TGK re-keying and CSB updating................................19 5. Behavior and message handling...................................20 5.1. General.......................................................20 5.1.1. Capability Discovery........................................20 5.1.2. Error Handling..............................................21 5.2. Creating a message............................................21 5.3. Parsing a message.............................................23 5.4. Replay handling and timestamp usage...........................23 5.5. Reliability...................................................25 6. Payload Encoding................................................25 6.1. Common header payload (HDR)...................................25 6.1.1. SRTP ID.....................................................27 6.2. Key data transport payload (KEMAC)............................28 6.3. Envelope data payload (PKE)...................................29 Arkko, et al. [Page 2] INTERNET-DRAFT msec-mikey-02 June 2002 6.4. DH data payload (DH)..........................................30 6.5. Signature payload (SIGN)......................................31 6.6. Timestamp payload (T).........................................31 6.7. ID payload (ID) / Certificate payload (CERT)..................32 6.8. Cert hash payload (CHASH).....................................32 6.9. Ver msg payload (V)...........................................33 6.10. Security Policy payload (SP).................................33 6.10.1. SRTP policy................................................34 6.11. RAND payload (RAND)..........................................36 6.12. Error payload (ERR)..........................................36 6.13. Key data sub-payload.........................................37 6.14. Key validity data............................................38 6.15. General Extension Payload....................................39 7. Integration with session establishment protocols................40 7.1. SDP integration...............................................40 7.2. MIKEY within SIP..............................................40 7.3. MIKEY with RTSP...............................................41 7.4. MIKEY Interface...............................................42 8. Groups..........................................................42 8.1. Simple one-to-many............................................43 8.2. Small-size interactive group..................................43 9. Security Considerations.........................................44 9.1. General.......................................................44 9.2. Key lifetime..................................................45 9.3. Timestamps....................................................45 9.4. Identity protection...........................................46 9.5. Denial of Service.............................................46 9.6. Session establishment.........................................46 10. IANA considerations............................................47 11. Conclusions....................................................49 12. Acknowledgments................................................49 13. Author's Addresses.............................................49 14. References.....................................................50 14.1. Normative References.........................................50 14.2. Informative References.......................................50 Appendix A. - MIKEY - SRTP relation................................52 Revision history...................................................52 1. Introduction There has recently been work to define a security protocol for the protection of real-time applications running over RTP, [SRTP]. However, a security protocol needs a key management solution to exchange keys, security parameters, etc. There are some fundamental properties that such a key management scheme has to fulfil with respect to the kind of real-time applications (streaming, unicast, groups, multicast, etc.) and to the heterogeneous nature of the scenarios dealt with. Arkko, et al. [Page 3] INTERNET-DRAFT msec-mikey-02 June 2002 This document describes a key management solution, that address multimedia scenarios (e.g. SIP calls and 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. 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 RFC-2119. 1.2. Definitions Crypto Session (CS): uni- or bi-directional data stream(s), protected by a single instance of a security protocol. E.g. when SRTP is used, the Crypto Session may contain two streams, an RTP stream and the corresponding RTCP as they are both protected by a single instance of SRTP (i.e. they share key and some other parameters). Crypto Session Bundle (CSB): collection of one or more Crypto Sessions, which can have common TEK Generation Keys and security parameters. Crypto Session ID: unique identifier for the Crypto Session within an CSB. Crypto Session Bundle 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 TEK Generation Key, Traffic- encrypting Keys can then be generated without need of further communication. Traffic-encrypting Key (TEK): the key used by the security protocol to protect the crypto session (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the 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. Data SA: information for the security protocol, including a TEK and a set of parameters/policies. PRF(k,x): a keyed pseudo-random function. E(k,m): encryption of m with the key k. Arkko, et al. [Page 4] INTERNET-DRAFT msec-mikey-02 June 2002 PKx: the public key of x [] an optional piece of information {} denotes zero or more occurrences || concatenation | OR (selection operator) ^ exponentiation XOR binary exclusive or Bit and byte ordering: throughout the document bits and bytes are as usual indexed from left to right, with the leftmost bits/bytes being the most significant. 1.3. Abbreviations AES Advanced Encryption Standard CM Counter Mode 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 PS Pre-Shared key RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure RTP TEK Traffic-encrypting key TGK TEK Generation Key 1.4. 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. As MIKEY can be carried in SDP over SIP or RTSP, Section 7 describes how to integrate and use MIKEY in these scenarios. Arkko, et al. [Page 5] INTERNET-DRAFT msec-mikey-02 June 2002 Section 8 focuses on how MIKEY is used in group scenarios. The Security Considerations section (Section 9), gives a deeper explanation on different security related topics. 2. Basic Overview 2.1. Scenarios MIKEY is intended to be used for peer-to-peer, simple one-to-many, and small-size (interactive) groups. One of the main multimedia scenarios is the conversational multimedia scenario, where users may interact and communicate in real-time. In these scenarios it can be expected that peers set up multimedia sessions between each other, where a multimedia session may consist of one or more 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 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) 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. Arkko, et al. [Page 6] INTERNET-DRAFT msec-mikey-02 June 2002 c) many-to-many, with a centralized control unit, e.g. for larger groups with some kind of Group Controller that sets up the security. d) simple one-to-many (multicast), e.g. real-time presentations, where the sender is in charge of setting up the security. The key management solutions may be different in the above scenarios. MIKEY addresses all of the above, except case c. 2.2. Design Goals The key management protocol is designed to have the following characteristics: * End-to-end security. Only the participants have access to the generated key(s). * Simplicity. * Efficiency. Designed to have: - low bandwidth consumption, - low computational workload, - small code size, and - minimal number of roundtrips. * Tunneling. Possibility to "tunnel"/integrate MIKEY in session establishment protocols (e.g. SIP and RTSP). * Independent of any specific security functionality of the underlying transport. 2.3. System Overview One objective of MIKEY is to produce a Data security protocol SA (Data SA), including a traffic-encrypting key (TEK), which is used as the input to the security protocol. MIKEY supports the possibility to negotiate keys and parameters for more than one security protocol at the same time. Therefore, the concept of Crypto Session Bundle (CSB) is used, which is a collection of one or more Crypto Sessions that can have common TEK Generation Keys and security parameters. 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 TEK Generation Key(s) (TGK) are agreed upon for the Crypto Session Bundle (this is done by one of the three alternative key transport/exchange mechanisms, see Section 3). Arkko, et al. [Page 7] INTERNET-DRAFT msec-mikey-02 June 2002 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 policy parameters represent the Data SA, which is used as the input to the Security Protocol. +-----------------+ | CSB | | Key transport | | /exchange | +-----------------+ | : | TGK : v : +----------+ : CS ID ->| TEK | : Security protocol |derivation| : parameters (policies) +----------+ : TEK | : v v Data SA | v +-------------------+ | Crypto Session | |(Security Protocol)| +-------------------+ Figure 2.2: Overview of the 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 derive a new TGK (and consequently the TEKs) or to update some other specific Crypto Session 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 Arkko, et al. [Page 8] INTERNET-DRAFT msec-mikey-02 June 2002 are a group controller/key server (GCKS), the receiver(s), and the sender(s). In MIKEY the GCKS and the sender can be viewed as the same entity, which pushes down keys to the receiver(s). Note that e.g., 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). 2.5. Existing solutions There is work done in IETF to develop key management schemes. For example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and the MSEC WG is developing other schemes, addressed to group communication [GDOI, GSAKMP]. For reasons discussed, there is however a need for a scheme with low latency, suitable for demanding cases such as real-time data over heterogeneous networks, and small interactive groups. 3. Basic Key Transport and Exchange Methods The following sub-sections define three different methods to transport/exchange a TEK Generation Key (TGK): with the use of a pre- shared key, public-key encryption, and Diffie-Hellman (DH) key exchange. The two first methods are of key transport type. In the following we for simplicity assume unicast communication. 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.4. The pre-shared case is, by far, the most efficient way to handle the key transport due to the use of symmetric cryptography only. This approach has also the advantage that only a small amount of data has to be exchanged. Of course, the problematic issue is scalability. 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). The Diffie-Hellman (DH) key exchange method has in general a higher resource consumption (both computationally and in bandwidth) than the previous ones. However, it has the advantage of providing perfect forward secrecy (PFS). Note that by using the DH method, the two involved parties will generate a unique random key (which neither of the parties are likely to significantly affect the outcome of). Therefore, it is not Arkko, et al. [Page 9] INTERNET-DRAFT msec-mikey-02 June 2002 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 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. See Section 6.6 for payload definition and also Section 5.4 for other timestamp related information. IDx: The identity of x. See Section 6.7 for payload definition. RAND: Random bit-string, which is always included in the first message from the Initiator. It is not included in update messages of a CSB. See Section 6.11 for payload definition. 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) as described in Section 4.1.5. The encryption and authentication transforms are described in Section 4.2. Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi], {SP}, KEMAC ---> R_MESSAGE = [<---] HDR, T, [IDr], V The main objective of the Initiator's message is to transport one or more TGKs and a set of data protocol parameters 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(auth_key, I_MESSAGE). The KEMAC payload contains a set of encrypted sub-payloads and a MAC. Each sub-payload includes a, by the Initiator, randomly and Arkko, et al. [Page 10] INTERNET-DRAFT msec-mikey-02 June 2002 independently chosen TGK (and possible other related parameters, e.g., the key lifetime). The MAC is a Message Authentication Code covering the entire MIKEY message (with the exception of the MAC field) using the authentication key, auth_key. See Section 6.2 for payload definition and Section 5.2 for exact definition of the MAC calculation. The main objective of the verification message from the Responder is to obtain mutual authentication. V = MAC(auth_key, R_MESSAGE||IDi||IDr||T). The verification, V, is a MAC computed over the Responder's entire message (with the exception of the MAC field), the timestamp (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 MAC calculation and Section 6.9 for payload definition. 3.2. Public-key encryption Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], {SP}, [CHASH], KEMAC, PKE, SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V The main objective of the Initiator's message is to transport one or more TGKs and a set of data protocol 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 chosen "envelope key". The envelope key is sent to the Responder encrypted with the public key of the Responder. 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 = K || M K = E(encr_key, IDi || {TGK}) M = MAC(auth_key, K). The KEMAC contains a set of encrypted sub-payloads and a MAC. The first sub-payload 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 sub-payloads includes a, by the Initiator, randomly and independently chosen TGK (and possible other related parameters, e.g., the key lifetime). The encrypted part is Arkko, et al. [Page 11] INTERNET-DRAFT msec-mikey-02 June 2002 then followed by a MAC, which is calculated over the KEMAC payload (except the MAC field). The encr_key and the auth_key is derived from the envelope key, env_key (see Section 4.1.5). See also Section 6.2 for payload definition. The PKE contains the encrypted envelope key. It is encrypted using the Responder's public key. If the Responder posses several public keys, the Initiator can use CHASH to indicate the key used. The SIGNi is a signature covering the entire MIKEY message, I_MESSAGE, using the Initiator's signature key. The main objective of the verification message from the Responder is to obtain mutual authentication. It is calculated in the same way as for the one 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 IDr and possibly also one unencrypted IDr. The encrypted one is needed to avoid certain man-in- the-middle attacks, while the unencrypted is always useful for the Responder to immediately identify the Initiator. It is possible to cache the envelope key, so that it can be used as a pre-shared key. It is not recommended to cache this key indefinitely (however it is up to the local policy to decide this). This function may be very convenient during the life-time of a Crypto Session Bundle, 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 life-time of the entire CSB. Certificate handling may involve a number of additional tasks not shown here, and effect the inclusion of certain parts of the message. The following observations can, however, be made: * the Initiator typically has to find the certificate of the Responder in order to send the first message. If the Initiator does not have the Responder's certificate already, this may involve one or more roundtrips to a central directory agent. * it will be possible for the Initiator to omit its own certificate and rely on the Responder getting this certificate using other means. However, we recommend doing this, only when it is reasonable to expect that the Responder has cached the certificate from a previous connection. Otherwise accessing the certificate would mean additional roundtrips for the Responder as well. * verification of the certificates using Certificate Revocation Lists (CRLs) or an on-line verification protocol may mean additional roundtrips for both parties. If a small number of roundtrips is Arkko, et al. [Page 12] INTERNET-DRAFT msec-mikey-02 June 2002 required for acceptable performance, it may be necessary to omit some of these checks. 3.3. Diffie-Hellman key exchange For a fixed, agreed upon, group, (G,*), for g in G and a natural number x, we let g^x denote g*g*..*g (x times). Choices for the parameters are given in Section 4.2.7. The other transforms below are described in Section 4.2. With this method only one key is created, i.e. the DH-key, which is used as the TGK. Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi], {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 (i.e., DHi = g^xi, where xi is randomly and secretly chosen) and a set of data protocol parameters. The SIGNi is a signature covering the Initiator's MIKEY message, I_MESSAGE, using the Initiator's signature key. The main objective of the Responder's message is to, in a secure way, provide the Initiator with its own DH value (i.e., DHr = g^xr, where xr is randomly and secretly chosen). The SIGNr is a signature covering the Responder's MIKEY message, R_MESSAGE, using the Responder's signature key. The group parameters (e.g., the group G) are a set of parameters chosen by the Initiator. 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 posses any of the responder's certificate before the setup. Instead, it is sufficient that the responder includes it's signing certificate in the response. Arkko, et al. [Page 13] INTERNET-DRAFT msec-mikey-02 June 2002 4. Key Management 4.1. Key Calculation We define in the following a general method (pseudo random function) to derive one or more keys from a "master" key. This method is used to derive: * TEKs from a TGK and the RAND value, * encryption, authentication, or salting key from a pre-shared/ envelope key and the RAND value. 4.1.1. Assumptions We assume that the following parameters are in place: csb_id: Crypto Session Bundle ID (32-bits unsigned integer) cs_id: The Crypto Session ID (8-bits unsigned integer) RAND: An (at least) 128-bit random bit-string sent by the Initiator in the initial exchange. The key derivation method has the following input parameters: inkey: the input key to the derivation function. inkey_len: the length in bits of the input key. label: a specific label, dependent on the type of the key to be derived, the RAND, and the session IDs. outkey_len: desired length in bits of the output key. The key derivation method has the following output: outkey: the output key of desired length. 4.1.2. Notation Let HMAC be the SHA1 based message authentication function, see [HMAC,SHA1]. Similar to [TLS], define: P (s, label, m) = HMAC (s, A_1 || label) || HMAC (s, A_2 || label) || ... HMAC (s, A_m || label) where A_0 = label, A_i = HMAC (s, A_(i-1)). While SHA-1 is the default, HMAC using other hash function MAY be used, see Section 4.2.2. Arkko, et al. [Page 14] INTERNET-DRAFT msec-mikey-02 June 2002 4.1.3. PRF Description The following procedure describes a pseudo-random function, denoted PRF(inkey,label), applied to compute the output key, outkey: * let n = inkey_len / 512, rounded up to the nearest integer * split the inkey into n blocks, inkey = s_1 || ... || s_n, where all s_i, except possibly s_n, are 512 bits each * let m = outkey_len / 160, rounded up to the nearest integer If another hash function than SHA1 is used, "512" and "160" MUST be replaced by the appropriate input/output block-sizes of that function. Then, the output key, outkey, is obtained as the outkey_len most significant bits of PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ... XOR P(s_n, label, m). 4.1.4. Generating keys from TGK The key derivation method should be executed with the following parameters to generate a TEK: inkey: TGK inkey_len: length of TGK label: 0x2AD01C64 || cs_id || csb_id || RAND outkey_len: length of the output TEK. If the security protocol does not support key derivation for authentication and encryption itself from the TEK, separate authentication and encryption keys MAY directly be created for the security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and 0x15798CEF respectively, and outkey_len by the desired key-length(s) in each case. A salt key can be derived from the TGK as well. This is done by using the constant 0x39A2C14B. Note that the 32-bit constant integers (i.e. 0x2AD01C64 or the one replacing it) are taken from the decimal digits of e (i.e. 2.7182...), and where each constant consist of nine decimals digits (e.g. the first nine decimal digits 718281828 = 0x2AD01C64). The strings of nine decimal digits are not chosen at random, but as consecutive "chunks" from the decimal digits of e. 4.1.5. Generating keys from an envelope/pre-shared key inkey: the envelope key or the pre-shared key inkey_len: the length of inkey Arkko, et al. [Page 15] INTERNET-DRAFT msec-mikey-02 June 2002 label: 0x150533E1 || 0xFF || csb_id || RAND (for encryption key) or 0x2D22AC75 || 0xFF || csb_id || RAND (for auth. key) or 0x29B88916 || 0xFF || csb_id || RAND (for salting key) outkey_len: desired length of the authentication/encryption/salting key. 4.2 Pre-defined Transforms and Timestamp Formats This section identifies standard transforms for MIKEY. The following transforms are mandatory to implement and support in the respective case. New transforms can be added in the future (see Section 4.2.9 for further guidelines). 4.2.1 Hash functions In MIKEY, SHA-1 is the default hash function that is mandatory to implement. 4.2.2 Pseudo random number generator and PRF A cryptographically secure pseudo random number generator MUST be used for the generation of the keying material and nonces, e.g. [BMGL]. However, it is implementation specific which one to use (as the choice will not affect the interoperability). For the key derivations, the PRF specified in Section 4.1, using SHA- 1 is mandatory to implement. This PRF MAY be extended by using SHA- 256, SHA-384, or SHA-512, instead of SHA-1. However, it is not mandatory to support these. 4.2.3 Key data transport encryption The default and mandatory-to-implement key transport encryption is AES in counter mode, as defined in [SRTP], using a key as derived in Section 4.1.5, and using initialization vector IV = [S XOR (0x0000 || CSB ID || T)] || 0x0000, where S is a 112-bit salting key, also derived as in Section 4.1.5, and where T is the timestamp sent by the Initiator. Note: this restricts the maximum size of the transported key to 2^23 bits, which is still enough for all practical purposes. The NULL encryption algorithm (i.e., no encryption) can be used (but is not mandatory to implement). Note that this MUST NOT be used unless the underlying protocols can guarantee the security. The main reason for including this is for certain specific SIP scenarios, Arkko, et al. [Page 16] INTERNET-DRAFT msec-mikey-02 June 2002 where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method and the NULL encryption and authentication algorithm while relying on the security of SIP. Use this option with caution! 4.2.4 MAC and Verification Message function MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 as the mandatory to implement method, see [HMAC]. Authentication keys are derived according to Section 4.1.5. The NULL authentication algorithm (i.e., no MAC) can be used together with the NULL encryption algorithm (but is not mandatory to implement). Note that this MUST NOT be used unless the underlying protocols can guarantee the security. The main reason for including this is for certain specific SIP scenarios, where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method and the NULL encryption and authentication algorithm while relying on the security of SIP. Use this option with caution! 4.2.5 Envelope Key encryption The public key encryption algorithm applied is defined in, and dependent on the certificate used. 4.2.6 Digital Signatures The signature algorithm applied is defined in, and dependent on the certificate used. 4.2.7 Diffie-Hellman Groups The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are not mandatory to implement). 4.2.8. Timestamps The current defined timestamp is as defined in NTP [NTP], i.e. a 64- bit number in seconds relative to 0h on 1 January 1900. An implementation must be aware of (and take into account) the fact that the counter will overflow approximately every 136th year. It is RECOMMENDED that the time is always specified in UTC. 4.2.9. Adding new parameters to MIKEY There are two different parameter sets that can be added to MIKEY. The first is a set of MIKEY transforms (needed for the exchange itself), and the second is the data security protocol policies/ parameters. Arkko, et al. [Page 17] INTERNET-DRAFT msec-mikey-02 June 2002 New transforms and parameters SHALL be added by registering a new number for the payload, and also if necessary, document how the new transform/parameter is used. Sometimes it might be enough to point to an already specified document for the usage, e.g., when adding a new already standardized hash function. When adding support for a new data security protocol, the following MUST be specified: * A map sub payload (see Section 6.1). This is used to be able to map a crypto session to the right instance of the data security protocol and possibly also to provide individual parameters for each data security protocol. * a policy payload, i.e., specification of parameters and supported values. * general guidelines of usage. 4.3. Policies Included in the message exchange, policies for the Data security protocol are transmitted. The policies are defined in a separate payload and are specific to the security protocol (see also Section 6.10). Together with the keys, the validity period of these can also be specified. This can be done e.g., with an SPI (or SRTP MKI) or with an Interval (e.g. a sequence number interval for SRTP). Whether an SPI or an Interval should be used, depends on the security protocol. New parameters can be added to a policy by documenting how they should be interpreted by MIKEY and also by registering new values in the appropriate name space. If a completely new policy is needed, see Section 4.2.9 for guidelines. 4.4. Retrieving the Data SA The retrieval of a Data SA will depend on the security protocol as different security protocols will have different characteristics. When adding support for a security protocol to MIKEY, some interface of how the security protocol retrieves the Data SA from MIKEY MUST be specified (together with policies that can be negotiated etc.). For SRTP the SSRC (see [SRTP]) is one of the parameters used to retrieve the Data SA. However, the SSRC is not sufficient. For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that the MIKEY implementation supports a lookup using destination network address and port together with SSRC. Note that MIKEY does not send network addresses or ports. One reason for this is that they may not be known in advance, as well as if a NAT exists in-between, problems may arise. When SIP or RTSP is used, the local view of the destination Arkko, et al. [Page 18] INTERNET-DRAFT msec-mikey-02 June 2002 address and port can be obtained from either SIP or RTSP. MIKEY can then use these addresses as the index for the Data SA lookup. 4.5. TGK re-keying and CSB updating MIKEY provides the means to update the CSB (e.g. transporting a new TGK/TEK or adding a new Crypto Session to the CSB). The updating of the CSB is done by the Initiator and performed by executing MIKEY again e.g. before a TEK expires, or when a new Crypto Session is added to the CSB. Note that MIKEY does not provide re-keying in the GKMARCH sense, only updating of the keys by normal unicast messages. When MIKEY is executed again to update the CSB, it is not necessary to include certificates and other information that was provided in the first exchange, i.e. all parameters that are static or optional to include may be left out. The new message exchange uses the same CSB ID as the initial exchange, but a new timestamp. A new RAND is NOT included in the message exchange (the RAND will only have affect in the Initial exchange). New Crypto Sessions are added if desired in the update message. Therefore, the new MIKEY message does not need to contain keys. As explained in Section 3.2, the envelope key can be "cached" as a pre-shared key (this is indicated by the Initiator in the first message sent). If so, the "update message" is a pre-shared key message (with the cached envelope key as the pre-shared key), i.e., it MUST NOT be a public key message. If the public key message is used, but the envelope key is not cached, the Initiator MUST provide a new encrypted envelope key that can be used in the verification message. However, the Initiator does not need to provide any other keys. Figure 4.1 visualizes the update messages that can be sent, including the optional parts. The big differences from the original message is mainly that it is optional to include TGKs (or DH values in the DH method). Initiator Responder Pre-shared key method: I_MESSAGE = HDR, T, [IDi], {SP}, KEMAC ---> R_MESSAGE = [<---] HDR, T, [IDr], V Arkko, et al. [Page 19] INTERNET-DRAFT msec-mikey-02 June 2002 Public key method: I_MESSAGE = HDR, T, [IDi|CERTi], {SP}, {CHASH}, [KEMAC], PKE, SIGNi ---> R_MESSAGE = [<---] HDR, T, [IDr], V DH method: I_MESSAGE = HDR, T, [IDi|CERTi], {SP}, [DHi], SIGNi ---> R_MESSAGE = <--- HDR, T, [IDr|CERTr], IDi, [DHr, DHi], SIGNr Figure 4.1: Update messages. By definition, a Crypto Session Bundle can contain several Crypto Sessions. A problem that then might occur is to synchronize the TGK re-keying if an SPI (or similar functionality, e.g., MKI) is not used. It is therefore recommended that an SPI or MKI is used, if more than one Crypto Session is used. 5. Behavior and message handling Each message that is sent by the Initiator or the Responder, is built by a set of payloads. This section describes how messages are created and also when they can be used. 5.1. General 5.1.1. Capability Discovery The initiator indicates the security policy to use (i.e. in terms of security protocol algorithms etc). If the Responder does not support it (for some reason), the Responder can together with an error message (indicating that it does not support the parameters), send back its own capabilities (negotiation) to let the Initiator choose a common set of parameters. This is done by including one or more security policy payloads. Multiple attributes can be provided in sequence in the response. This is done to reduce the number of roundtrips as much as possible (i.e. in most cases, where the policy is accepted the first time, one roundtrip is enough). If the Responder does not accept the offer, the Initiator must go out with a new MIKEY message. Arkko, et al. [Page 20] INTERNET-DRAFT msec-mikey-02 June 2002 If the Responder is not willing/capable to provide security or the parties simply cannot agree, it is up to the parties' policies how to behave, i.e. accept an insecure communication or reject it. Note that it is not the intention of this protocol to have a very broad variety of options, as it is assumed that it should not be too common that an offer is denied. 5.1.2. Error Handling All errors due to the key management protocol SHOULD be reported to the peer(s) by an error message. The Initiator SHOULD therefore always be prepared to receive such message back from the Responder. If the Responder does not support the set of parameters suggested by the Initiator, the error message SHOULD include the supported parameters (see also Section 5.1.2). The error message should be formed as: HDR, T, {ERR}, [V|SIGNr] Note that if the failure is due to the inability to authenticate the peer, the error message is OPTIONAL, and does not need to be authenticated. It is up to the local policy how to treat this kind of messages. However, if a signed error message in response to a failed authentication is returned this can be used for DoS purposes. Similarly, an unauthenticated error message could be sent to the Initiator in order to fool her to tear down the CSB. The local policy MUST take this into consideration. One advice would be not to authenticate such an error message, and when receiving an unauthenticated error message only see it as a recommendation of what may have gone wrong. 5.2. Creating a message To create a MIKEY message, a Common header payload is first created. This payload is then followed, depending on the message type, by a set of information payloads (e.g. DH-value payload, Signature payload, Security Protocol payload). The defined payloads and the exact encoding of each payload are described in Section 6. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version ! data type ! next payload ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + ~ Common Header... ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! next payload ! Payload 1 ... ! Arkko, et al. [Page 21] INTERNET-DRAFT msec-mikey-02 June 2002 +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! next payload ! Payload x ... ! +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MAC/Signature ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.1. MIKEY payload message example. The process of generating a MIKEY message consists of the following steps: * Create an initial MIKEY message starting with the Common header payload. * Concatenate necessary payloads to the MIKEY message (see the exchange definitions for payloads that may be included and recommended order). * As a last step (for messages that must be authenticated, this also include the verification message), create and concatenate the MAC/signature payload without the MAC/signature field filled in (if a Next payload field is included in this payload, it is set to Last payload). * Calculate the MAC/signature over the entire MIKEY message, except the MAC/Signature field, and add put the MAC/signature in the field. In the case of the verification message, the IDi || IDr || T MUST follow directly after the MIKEY message in the MAC calculation. In the public key case, the Key data transport payload is generated by concatenating the IDi with the TGKs. This is then encrypted and placed in the data field. The MAC is calculated over the entire Key data transport payload except the MAC field. Before calculating the MAC, the Next payload field is set to zero. Note that all messages from the Initiator MUST use a unique timestamp. The Responder does not create a new timestamp, but uses the timestamp used by the Initiator. Arkko, et al. [Page 22] INTERNET-DRAFT msec-mikey-02 June 2002 5.3. Parsing a message In general, parsing of a MIKEY message is done by extracting payload by payload and checking that no errors occur (the exact procedure is implementation specific). However, for the Responder, it is RECOMMENDED that the following procedure is followed: * Extract the Timestamp and check that it is within the allowable clock skew (if not, discard the message). Also check the replay cache so that the message is not replayed (see also Section 5.4). If the message is replayed, discard it. * Extract ID and authentication algorithm (if not included, assume the default one). * Verify the MAC/signature. * If the authentication is not successful, an Auth failure Error message is possibly sent to the Initiator (if SIP is used, this is signaled to SIP as a rejection of the offer). The message is then discarded from further processing. See also Section 5.1.2 for treatment of errors. * If the authentication is successful, the message is processed. Though how it is processed is implementation specific. * If any unsupported parameters or errors occur during the processing, these are reported to the Initiator by sending an error message. The processing is then aborted. The error message can also include payloads to describe the supported parameters. If SIP is used, this is signaled to SIP as a rejection of the offer (see also Section 7.2). * If the processing was successful and if needed, a verification/ response message is created and sent to the Initiator. 5.4. Replay handling and timestamp usage MIKEY does not use a challenge-response mechanism for replay handling, instead timestamps are used. This requires that the clocks are synchronized. The required synchronization is dependent on the number of messages that can be cached. If we could assume an unlimited cache, the terminals would not need to be synchronized at all (as the cache could then contain all previously messages). However, if there are restrictions on the size of the replay cache, the clocks will need to be synchronized to some extent. In short, one can in general say that it is a tradeoff between the size of the replay cache and the required synchronization. Timestamp usage prevents against replay attacks under the following assumptions: Arkko, et al. [Page 23] INTERNET-DRAFT msec-mikey-02 June 2002 * Each host have a clock which is at least "loosely synchronized" to the clocks of the other hosts. * If the clocks are to be synchronized over the network, a secure network clock synchronization protocol is used. * Each Responder utilize a replay cache in order to remember the messages presented within an allowable clock skew (which is set by the local policy). * Replayed and outdated messages, i.e., messages that can be found in the replay cache or which have an outdated timestamp, are discarded and not processed. * If the host loses track of the incoming requests (e.g. due to overload), it rejects all incoming requests until the clock skew interval has passed. In a client-server scenario, servers may be the entities that will have the highest work load. It is therefore RECOMMENDED that the servers are the Initiators of MIKEY. This will result in that the servers will not need to manage any significant replay cache as they will refuse all incoming messages that are not a response to an already (by the server) sent message. In general, a client may not expect a very high load of incoming messages and may therefore allow the degree of looseness to be on the order of minutes (5-10 minutes are believed to be acceptable). If a DoS attack is launched and the replay cache grows too large, MIKEY MAY dynamically decrease the looseness so that the replay cache becomes manageable. The maximum number of messages that a client will need to cache may vary depending on the capacity of the client itself and the network, but also the number of expected messages should be taken into account. For example, assume that we can at most spend 6kB on a replay cache. Assume further that we need to store 30 bytes for each incoming message (the hash of the message is 20 bytes). This implies that it is possible to cache approximately 204 messages. If the expected number of messages per minute can be estimated, the clock skew can easily be calculated. E.g., in a SIP scenario where the client is expected in the most extreme case, a few calls per minute (assume 10 at most in this example), the clock skew that can be used is approximately 20 minutes. In a more extreme case, where the maximum number of incoming messages are assumed to be on the order of 120 messages per minute, and a Arkko, et al. [Page 24] INTERNET-DRAFT msec-mikey-02 June 2002 requirement that the clock skew is on the order of 10 minutes, a 48kB replay cache would be required. One recommendation is to fix a size for the replay cache, and let the allowable clock skew be large. As the replay cache grows, the clock skew is decreased depending on how many percent of the replay cache that are used. In case of a DoS attack, the client will in most cases be able to handle the replay cache. A bigger problem will probably be to process the messages (verify signatures/MACs), due to the computational workload this implies. 5.5. Reliability If MIKEY is sent on an unreliable transport, the basic processing applied to ensure protocol reliability is the following. The transmitting entity (Initiator or Responder) MUST: * Set a timer and initialize a retry counter * If the timer expires, the message is resent and the retry counter is decreased. * If the retry counter reaches zero (0), the event MAY be logged in the appropriate system audit file. 6. Payload Encoding This section describes in detail all the payloads. For all encoding, Network byte order is always used. 6.1. Common header payload (HDR) The Common header payload MUST always be present as the first payload in each message. The common header includes general description of the exchange message. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version ! data type ! next payload !V! PRF func ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! CSB ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! #CS ! CS ID map type! CS ID map info ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The common header contains the following information: Arkko, et al. [Page 25] INTERNET-DRAFT msec-mikey-02 June 2002 * version: the version number of MIKEY. version = 1 * data type: describes the type of message (e.g. public-key transport message, verification message, error message). Data type | Value | Comment -------------------------------------- Pre-shared | 0 | Initiator's pre-shared key message PS ver msg | 1 | Verification message of a Pre-shared | | key message Public key | 2 | Initiator's public-key transport message PK ver msg | 3 | Verification message of a public-key | | message D-H init | 4 | Initiator's DH exchange message D-H resp | 5 | Responder's DH exchange message Error | 6 | Error message * next payload: identifies the payload that is added after this payload. Next payload | Value | Section ------------------------------ Last payload | 0 | - KEMAC | 1 | 6.2 PKE | 2 | 6.3 DH | 3 | 6.4 SIGN | 4 | 6.5 T | 5 | 6.6 ID | 6 | 6.7 CERT | 7 | 6.7 CHASH | 8 | 6.8 V | 9 | 6.9 SP | 10 | 6.10 RAND | 11 | 6.11 ERR | 12 | 6.12 Key data | 20 | 6.13 General Ext. | 21 | 6.15 Note that some of the payloads cannot possibly come right after the header (such as "Last payload", "Signature", etc.). However, the Next payload field is generic for all payloads. Therefore, a value is allocated for each payload. * V: flag to indicate whether a verification message is expected or not (this has only meaning when it is set by the Initiator). V = 0 ==> no response expected V = 1 ==> response expected Arkko, et al. [Page 26] INTERNET-DRAFT msec-mikey-02 June 2002 * PRF func: Indicates the PRF function that has been/will be used for key derivation etc. PRF func | Value | Comments -------------------------------------------------------- MIKEY-1 | 0 | Mandatory, Default (see Section 4.1.2-3) MIKEY-256 | 1 | (as MIKEY-1 but using a HMAC with SHA256) MIKEY-384 | 2 | (as MIKEY-1 but using a HMAC with SHA384) MIKEY-512 | 3 | (as MIKEY-1 but using a HMAC with SHA512) * CSB ID: A 32-bit integer to identify the CSB. It is RECOMMENDED that it is chosen at random by the Initiator. This ID MUST be unique between each Initiator-Responder pair, i.e., not globally unique. An Initiator MUST check for collisions when choosing the ID (if the Initiator already has one or more established CSB with the Responder). The Responder uses the same CSB ID in the response. * #CS: Indicates the number of Crypto Sessions that will be handled. Note that even though it is possible to use 255 CSs, it is not likely that a CSB will include this many CSs. The integer 0 is interpreted as no CS included. This may be the case in an initial setup message. * CS ID map type: specifies the method to uniquely map Crypto Sessions to the security protocol sessions. CS ID map type | Value ----------------------- SRTP-ID | 0 * CS ID map info: Identifies the crypto session(s) that the SA should be created for. The currently defined map type is the SRTP-ID (defined in Section 6.1.1). 6.1.1. SRTP ID 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy no 1 ! SSRC 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SSRC 1 (cont) ! ROC 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ROC 1 (cont) ! Policy no 2 ! SSRC 2 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SSRC 2 (cont) ! ROC 2 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ROC 2 (cont) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Arkko, et al. [Page 27] INTERNET-DRAFT msec-mikey-02 June 2002 : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy no #CS ! SSRC #CS ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~SSRC #CS (cont)! ROC #CS ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ROC #CS (cont)! +-+-+-+-+-+-+-+-+ * Policy no x: The policy applied for the stream with SSRC x. The same policy may apply for all CSs. * SSRC x: specifies the SSRC that MUST be used for the SRTP streams. Note that it is the sender of the streams who chooses the SSRC. Therefore, it might be that the Initiator of MIKEY can not fill in all fields. In this case, SSRCs that are not chosen by the Initiator are set to zero and the Responder fills in these field in the response message. It is in general RECOMMENDED or required to use unique SSRCs (both to avoid RTP SSRC collision, and from an SRTP perspective, to avoid two-time pad problems if the same TEK is used for more than one stream). * ROC x: Current rollover counter used in SRTP. If the SRTP session has not started, this field is set to 0. This field is used to be able for a member to join and synchronize to an already started stream. NOTE: The stream using SSRC x will also have Crypto Session ID equal to x (NOT to SSRC). 6.2. Key data transport payload (KEMAC) The Key data transport payload contains encrypted Key data payloads (see Section 6.13 for definition of Key data payloads). It may contain one or more Key data payloads each including a TGK. The last Key data payload has its Next payload field set to Last payload. For an update message (see also Section 4.5), it is allowed to skip the Key data payloads (which will result in that the Encr data len is equal to 0). If the transport method used is the pre-shared key method, this Key data transport payload is the last payload in the message (note that the Next payload field is set to Last payload). The MAC is then calculated over the entire MIKEY message (as described in Section 5.2). If the transport method used is the public-key method, the Initiator's identity is added in the encrypted data. This is done by adding the ID payload as the first payload, which then are followed by the Key data payloads. Note that for an update message, the ID is Arkko, et al. [Page 28] INTERNET-DRAFT msec-mikey-02 June 2002 still sent encrypted to the Responder (this is to avoid certain re- direction attacks) even though no Key data payloads is added after. The MAC field is in the public-key case calculated only over the Key data transport payload except the MAC field and where the Next payload field has been set to zero (see also Section 5.2). 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Encr alg ! Encr data len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Encr data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Mac alg ! MAC ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload (see Section 6.1 for defined values). * Encr alg: The encryption algorithm used to encrypt the TGK. Encr alg | Value | Comments ------------------------------------------- AES-CM | 1 | Mandatory (as defined in Section 4.2.3) NULL | 2 | Very restricted usage, see Section 4.2.3! * Encr len: Length of encrypted part (in bytes). * Encr data: The encrypted TGK sub-payloads (see Section 6.13). * MAC alg specifies the authentication algorithm used. MAC alg | Value | Comments -------------------------------------- HMAC-SHA1-160 | 0 | Mandatory (see Section 4.2.4) NULL | 1 | Very restricted usage, see Section 4.2.4! * MAC: The message authentication code of the entire message. 6.3. Envelope data payload (PKE) The Envelope data payload contains the encrypted envelope key that is used in the public-key transport to protect the data in the Key data transport payload. The encryption algorithm used is implicit from the certificate/public key used. Arkko, et al. [Page 29] INTERNET-DRAFT msec-mikey-02 June 2002 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! C ! Data len ! Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. * C: Envelope key cache indicator (see also Section 3.2, for more information of the usage). Cache type | Value | Comments -------------------------------------- No cache | 0 | The envelope key MUST NOT be cached Cache | 1 | The envelope key MUST be cached Cache for CSB | 2 | The envelope key MUST be cached, but only | | to be used for the specific CSB. * Data len: The length of the data field (in bytes). * Data: The encrypted envelope key (if nothing else stated in the certificate, padding and formatting is done according to RSA/PKCS#1 if RSA is used). 6.4. DH data payload (DH) The DH data payload carries the DH-value and indicates the DH-group used. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! DH-Group ! DH-value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Reserv! KV ! KV data (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. * DH-Group: identifies the DH group used. DH-Group | Value | Comments -------------------------------------- OAKLEY 5 | 0 | Mandatory OAKLEY 1 | 1 | OAKLEY 2 | 2 | * DH-value: The public DH-value (the length is implicit from the group used). Arkko, et al. [Page 30] INTERNET-DRAFT msec-mikey-02 June 2002 * KV: Indicates the type of key validity period specified. This may be done by using an SPI (alternatively an MKI) or by providing an interval in which the key is valid (e.g. in the latter case, for SRTP this will be the index range where the key is valid). See Section 6.13 for pre-defined values. * KV data: This includes either the SPI/MKI or an interval (see Section 6.14). If KV is NULL, this field is not included. 6.5. Signature payload (SIGN) The Signature payload carries the signature and its related data. The signature payload is always the last payload in the PK transport and DH exchange messages. The signature algorithm used is implicit from the certificate/public key used. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Signature len ! Signature ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Signature len: The length of the signature field (in bytes). * Signature: The signature (if nothing else stated in the certificate, padding and formatting is done according to RSA/PKCS#1 if RSA is used). 6.6. Timestamp payload (T) The timestamp payload carries the timestamp information. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! TS type ! TS value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. If no more payload follows, it MUST be set to Last payload. See Section 6.1 for values. * TS type: specifies the timestamp type used. TS type | Value | Comments ------------------------------------- NTP-UTC | 0 | Mandatory (64-bits) NTP | 1 | Mandatory (64-bits) * TS-value: The timestamp value of the specified TS type. Arkko, et al. [Page 31] INTERNET-DRAFT msec-mikey-02 June 2002 6.7. ID payload (ID) / Certificate payload (CERT) The ID payload carries a uniquely-defined identifier. The certificate payload contains an indicator of the certificate provided as well as the certificate data. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! ID/Cert Type ! ID/Cert len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID/Certificate Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. See Section 6.1 for values. * ID Type: specifies the identifier type used. ID Type | Value | Comments ---------------------------------------------- NAI | 0 | Mandatory (see [NAI]) URI | 1 | Mandatory (see [URI]) * Cert Type: specifies the certificate type used. Cert Type | Value | Comments ---------------------------------------------- X.509v3 | 0 | Mandatory X.509v3 URL | 1 | plain ASCII URL to the location of the Cert X.509v3 Sign | 2 | Mandatory (used for signatures only) X.509v3 Encr | 3 | Mandatory (used for encryption only) * ID/Cert len: The length of the ID or Certificate field (in bytes). * ID/Certificate: The ID or Certificate data. The X.509 [X.509] certificates are included as a bytes string using DER encoding as specified in X.509. 6.8. Cert hash payload (CHASH) The Cert hash payload contains the hash of the certificate used. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Hash func ! Hash ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arkko, et al. [Page 32] INTERNET-DRAFT msec-mikey-02 June 2002 * next payload: identifies the payload that is added after this payload. * Hash func: Indicates the hash function that is used (see also Section 4.2.1). Hash func | Value ---------------------- SHA-1 | 0 Mandatory SHA256 | 1 SHA384 | 2 SHA512 | 3 MD5 | 4 * Hash: The hash data. Note: the hash length is implicit from the hash function used. 6.9. Ver msg payload (V) The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods. Note that the MAC is calculated over the entire MIKEY message as well as the IDs and Timestamp (see also Section 5.2). 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Auth alg ! Ver data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. If no more payload follows, it is set to Last payload. See Section 6.1 for values. * Auth alg: specifies the MAC algorithm used for the verification message. See Section 6.2 for defined (MAC field) for defined values. * Ver data: The verification message data. Note: the length is implicit from the authentication algorithm used. 6.10. Security Policy payload (SP) The Security Policy payload defines a set of policies that applies to a specific security protocol. Arkko, et al. [Page 33] INTERNET-DRAFT msec-mikey-02 June 2002 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Policy no ! Prot type ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ length (cont) ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload: identifies the payload that is added after this payload. See Section 6.1 for values. * Policy no: Each security policy payload must be given a distinct number. * Prot type: defines the security protocol. Prot type | Value | --------------------------- SRTP | 0 | * Policy param length: defines the total length of the policy parameters for the specific security protocol. * Policy param: defines the policy for the specific security protocol. The Policy param part is built up by a set of Type/Length/Value fields. For each security protocol, a set of possible types/values that can be negotiated are defined. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! Length ! Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Type: specifies the type of the parameter. * Length: specifies the length of the Value field (in bytes). * Value: specifies the value of the parameter. 6.10.1. SRTP policy This policy specifies the policy for SRTP and SRTCP. The types/values that can be negotiated are defined by the following table: Arkko, et al. [Page 34] INTERNET-DRAFT msec-mikey-02 June 2002 Type | Meaning | Possible values ---------------------------------------------------- 0 | Encryption algorithm | see below 1 | Session Encr. key length | depends on cipher used 2 | Authentication algorithm | see below 3 | Session Auth. key length | depends on MAC used 4 | Session Salt key length | see [SRTP] for recommendations 5 | SRTP Pseudo Random Function | see below 6 | Key derivation rate | see [SRTP] for recommendations 7 | SRTP encryption off/on | 0 if off, 1 if on 8 | SRTCP encryption off/on | 0 if off, 1 if on 9 | FEC order | see below 10 | SRTP authentication off/on | 0 if off, 1 if on 11 | Authentication tag length | in bytes 12 | SRTP prefix length | in bytes Note that if a Type/Value is not set, the default one is used (according to SRTPs own criteria). For the Encryption algorithm, it is enough with a one byte length and the currently defined possible Values are: SRTP encr alg | Value --------------------- NULL | 0 AES-CM | 1 AES-F8 | 2 where AES-CM is AES in CM and AES-F8 is AES in f8 mode. For the Authentication algorithm, it is enough with a one byte length and the currently define possible Values are: SRTP auth alg | Value --------------------- NULL | 0 HMAC-SHA1 | 1 For the SRTP pseudo random function, it is also enough with a one byte length and the currently define possible Values are: SRTP PRF | Value --------------------- AES-CM | 0 If FEC is used at the same time as SRTP is used, MIKEY can negotiate the order in which these should be applied. Arkko, et al. [Page 35] INTERNET-DRAFT msec-mikey-02 June 2002 FEC order | Value | Comments -------------------------------- FEC-SRTP | 0 | First FEC, then SRTP SRTP-FEC | 1 | First SRTP, then FEC SPLIT | 2 | SRTP encr., then FEC, finally SRTP auth 6.11. RAND payload (RAND) The RAND payload consist of a random bit-string. The RAND MUST be chosen at random and per CSB (note that the if a CSB has several members, the Initiator MUST use the same RAND to all the members). 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! RAND len ! RAND ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload: identifies the payload that is added after this payload. * RAND len: Length of the RAND (in bytes). SHOULD be at least 16. * RAND: a randomly chosen bit-string. 6.12. Error payload (ERR) The Error payload is used to specify the error(s) that may have occurred. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Error no ! Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. If no more payload follows, it is set to Last payload. See Section 6.1 for values. * Error no indicates the type of error that was encountered. Error no | Value | Comment ------------------------------------------------------- Auth failure | 0 | Authentication failure Invalid TS | 1 | Invalid timestamp Invalid PRF | 2 | PRF function not supported Invalid MAC | 3 | MAC algorithm not supported Invalid EA | 3 | Encryption algorithm not supported Invalid HA | 3 | Hash function not supported Invalid DH | 4 | DH group not supported Invalid ID | 5 | ID not supported Arkko, et al. [Page 36] INTERNET-DRAFT msec-mikey-02 June 2002 Invalid Cert | 6 | Certificate not supported Invalid SP | 7 | SP type not supported Invalid SPpar | 8 | SP parameters not supported 6.13. Key data sub-payload The Key data payload contains TGKs. The Key data payloads are never included in clear, but as an encrypted part of the Key data transport payload. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Type ! KV ! Key data len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Salt len (optional) ! Salt data (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! KV data (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload: identifies the payload that is added after this payload. * Type: Indicates the type of the key included in the payload. Note that generally TEKs are not sent directly, but a TGK, which is then used to derive the TEK (or TEKs if there are several crypto sessions) as described in Section 4.1.4. Type | Value | Comments --------------------------------------- TGK | 0 | A TGK (used to derive TEKs from) TGK+SALT | 1 | A TGK + a salt key are included TEK | 2 | A plain TEK TEK+SALT | 3 | A plain TEK + a salt key are included Note that the possibility to include a TEK (instead of using the TGK is provided). However, if this is used, the TEK can generally not be shared between more than one Crypto Session. The recommended use of a TEK instead of a TGK is when pre-encrypted material exist and therefore, the TEK must be known in advance. * KV: Indicates the type of key validity period specified. This may be done by using an SPI/MKI or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). Arkko, et al. [Page 37] INTERNET-DRAFT msec-mikey-02 June 2002 KV | Value | Comments ------------------------------------------- Null | 0 | No specific usage rule (e.g. a TEK | | that has no specific lifetime) SPI | 1 | The key is associated with the SPI/MKI Interval | 2 | The key has a start and expiration time | | (e.g. an SRTP TEK) Note that when NULL is specified, any SPI or Interval is valid. For an Interval this means that the key is valid from the first observed sequence number until the key is replaced (or the security protocol is shutdown). * Key data len: The length of the Key data field (in bytes). * Key data: The TGK data. * Salt len: The salt key length in bytes. Note that this field is only included if the salt is specified in the Type-field. * Salt data: The salt key data. Note that this field is only included if the salt is specified in the Type-field. (For SRTP, this is the so-called master salt.) * KV data: This includes either the SPI or an interval (see Section 6.14). If KV is NULL, this field is not included. 6.14. Key validity data The Key validity data is not a standalone payload, but part of either the Key data payload (see Section 6.13) or the DH payload (see Section 6.4). The Key validity data gives a guideline of when the key should be used. This can be done, using an SPI/MKI or a lifetime range. SPI/MKI 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI Length ! SPI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * SPI Length: The length of the SPI (or MKI) in bytes. * SPI: The SPI (or MKI) value. Arkko, et al. [Page 38] INTERNET-DRAFT msec-mikey-02 June 2002 Interval 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! VF Length ! Valid from ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! VT Length ! Valid to (expires) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * VF Length: Length of the Valid From field in bytes. * Valid From: Sequence number, index, timestamp, or other start value that the security protocol uses to identify the start position of the key usage. * VT Length: Length of the Valid To field in bytes. * Valid to: Sequence number, index, timestamp, or other expiration value that the security protocol can use to identify the expiration of the key usage. Note that for SRTP usage, the key validity period for a TGK should be specified with either an interval, where the VF/VT length is equal to 6 bytes (i.e., the size of the index), or, with an MKI. It is RECOMMENDED that if more than one SRTP stream is sharing the same keys and key update/re-keying is desired, this is handled using MKI rather than the From-To method. 6.15. General Extension Payload The General extensions payload is included to allow possible extensions to MIKEY without the need to define a complete new payload each time. This payload can be used in any MIKEY message. Currently the only use defined, is to transport Vendor Id. Support of the Vendor ID is OPTIONAL. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload: identifies the payload that is added after this payload. * Type: identifies the type of the general payload. Arkko, et al. [Page 39] INTERNET-DRAFT msec-mikey-02 June 2002 Type | Value | Comments --------------------------------------- Vendor ID | 0 | Vendor specific byte string * Length: the length in bytes of the Data field. * Data: the general payload data. 7. Integration with session establishment protocols This section describes how MIKEY should be integrated with SDP, SIP and RTSP. It is based on [KMASDP], which describes extensions to SDP and SIP to carry key management protocol information. 7.1. SDP integration SDP descriptions [SDP] can be carried by several protocols, such as SIP and RTSP. Both SIP and RTSP often use SDP to describe the media sessions. Therefore, it is also convenient to be able to integrate the key management in the session description it is supposed to protect. [KMASDP] describes attributes that should be used by a key management protocol that is integrated in SDP. We refer to [KMASDP] for both definitions and examples. Note that MIKEY uses the name "mikey" as a protocol name in SDP and RTSP. The key management data that is placed in SDP or RTSP MUST be base64 encoded. 7.2. MIKEY within SIP In e.g., a basic SIP call between two parties (see Figure 7.1.), SIP (Session Initiation Protocol, [SIP]) is used as a session establishment protocol between two or more parties. In general an offer is made, whereby it is either accepted or rejected by the answerer. SIP complies to the offer/answer model [OFFANS], to which MIKEY over SIP MUST be compliant with as well. --------- --------- |A's SIP| <.......> |B's SIP| |Server | SIP/MIKEY |Server | --------- --------- ^ ^ . . ++++ SIP/MIKEY . . SIP/MIKEY ++++ | | <............. ..............> | | | | | | ++++ <-------------------------------------------> ++++ SRTP Fig 7.1.: SIP-based call example. The two parties uses MIKEY over SIP to set up an SRTP stream between A and B. Arkko, et al. [Page 40] INTERNET-DRAFT msec-mikey-02 June 2002 The SIP offerer will be the MIKEY Initiator and the SIP answerer will be the MIKEY Responder. This implies that in the offer, the MIKEY Initiator's message is included, and in the answer to the offer, the MIKEY Responder's message is included. If the MIKEY part of the offer is not accepted, a MIKEY error message is provided in the answer (following Section 5.1.2). The MIKEY implementation signals to the SIP implementation whether the MIKEY message was an acceptable offer or not. It may be assumed that the offerer knows the identity of the answerer. However, unless the Initiator's identity can be derived from SIP itself, the Initiator (caller) MUST provide the identity to the callee. It is RECOMMENDED to use the same identity for both SIP and MIKEY. Updating of the CSB (e.g. TEK update) is only supposed to be seen as a new offer. Note that it might not be necessary to send all information, such as the certificate, due to the already established call (see also Section 4.5). 7.3. MIKEY with RTSP The Real Time Streaming Protocol (RTSP) [RTSP] is used to control media streaming from a server. The media session is typically obtained via an SDP description, received by a DESCRIBE message, or by other means (e.g., HTTP). To be able to pass the MIKEY messages in RTSP messages which does not contain an SDP description, the RTSP KeyMgmt header (defined in [KMASDP]) is used. This header includes basically the same fields as the SDP extensions. As for SDP, "mikey" is used as the protocol identifier. In an RTSP scenario, the RTSP server and the MIKEY Initiator will be the same entity. The Initiator/RTSP server includes the MIKEY message in an SDP description. When responding to this, the client uses the defined RTSP header to send back the answer (included in the SETUP message). Note that it is the server that will be the Initiator of MIKEY in this case. This has some advantages. First, the server will always be able to choose the key for the content it distributes. Secondly, it will then have the possibility to use the same key for the same content that are streamed/sent to more than one client. To be able to have a server-initiated CSB update procedure, the ANNOUNCE message is used to send the updated MIKEY material. Note that the ANNOUNCE method has the ability to send SDP descriptions to update previous ones (i.e., it is not required to use the RTSP KeyMgmt header from server to client). Arkko, et al. [Page 41] INTERNET-DRAFT msec-mikey-02 June 2002 7.4. MIKEY Interface The SDP, SIP, and RTSP processing is defined in [KMASDP]. However, it is necessary that MIKEY can work properly with these protocols. This subsection describes some aspects which implementers SHOULD consider. If the MIKEY implementation is separate from the SDP/SIP/RTSP, an application programming interface (API) between MIKEY and these protocols is needed with certain functionality (however, exactly what it looks like is implementation dependent). Implementers of MIKEY are RECOMMENDED to consider providing at least the following functionality: * the possibility for MIKEY to receive information about the sessions negotiated. This is to some extent implementation dependent. But it is RECOMMENDED that, in the case of SRTP streams, the number of SRTP streams are included (and the direction of these). The destination addresses and ports is also RECOMMENDED to be provided to MIKEY. * the possibility for MIKEY to receive incoming MIKEY messages and return a status code from/to the SIP/RTSP application. * the possibility for the SIP or RTSP applications to receive information from MIKEY. This would typically include the receiving of the CSB ID or the SSRCs for SRTP. It is also RECOMMENDED that extra information about errors can be received. * the possibility for the SIP or RTSP application to receive outgoing MIKEY messages. * the possibility to tear down a MIKEY CSB (e.g. if the SIP session is closed, the CSB SHOULD also be closed). Note that if a CSB has already been established, it is still valid for the SIP or RTSP implementation to request a new message from MIKEY, e.g. when a new offer is issued. MIKEY SHOULD then send an update message to the Responder (see also Section 4.5). 8. Groups What has been discussed up to now is not limited to single peer-to- peer communication (except for the DH method), but can be used to distribute group keys for small-size interactive groups and simple one-to-many scenarios. This section describes how MIKEY is used in a group scenario. Arkko, et al. [Page 42] INTERNET-DRAFT msec-mikey-02 June 2002 8.1. Simple one-to-many ++++ |S | | | ++++ | --------+-------------- - - | | | v v v ++++ ++++ ++++ |A | |B | |C | | | | | | | ++++ ++++ ++++ Figure 8.1. Simple one-to-many scenario. In the simple one-to-many scenario, a server is streaming to a small group of clients. RTSP or SIP is used for the registration and the key management set up. The streaming server acts as the Initiator of MIKEY. In this scenario the pre-shared key or public key transport mechanism will be appropriate to use to transport the same TGK to all the clients (which will result in common TEKs for the group). Note, if the same TGK/TEK(s) should be used by all the group members, the streaming server MUST specify the same CSB_ID and CS_ID(s) for the session to all the group members. 8.2. Small-size interactive group ++++ ++++ |A | -------> |B | | | <------- | | ++++ ++++ ^ | | ^ | | | | | | ++++ | | | --->|C |<--- | ------| |------ ++++ Figure 8.2. Small-size group without centralized controller. As described in the overview section, for small-size interactive groups, one may expect that each client will be in charge for setting up the security for its outgoing streams. In these scenarios, the pre-shared key or the public-key transport method is used. One scenario may then be that the client sets up a three-part call, using SIP. Due to the small size of the group, unicast SRTP is used Arkko, et al. [Page 43] INTERNET-DRAFT msec-mikey-02 June 2002 between the clients. Each client sets up the security for its outgoing stream(s) to the others. As for the simple one-to-many case, the streaming client specifies the same CSB_ID and CS_ID(s) for its outgoing sessions if the same TGK/TEK(s) is used for all the group members. 9. Security Considerations 9.1. General No chain is stronger than its weakest link. The cryptographic functions protecting the keys during transport/exchange SHOULD offer a security at least corresponding to the (symmetric) keys they protect. For instance, with current state of the art, see [LV], protecting a 128-bit AES key by a 512-bit RSA [RSA] key offers an overall security below 64-bits. On the other hand, protecting a 64- bit symmetric key by a 2048-bit RSA key appears to be an "overkill", leading to unnecessary time delays. Therefore, key size for the key- exchange mechanism SHOULD be weighed against the size of the exchanged key. We refer to [LV] for concrete key size recommendations. Moreover, if the TGKs are not random, a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo) random generators for TGK generation. For the selection of the hash function, SHA-1 with 160-bit output is the default one. In general, hash sizes should be twice the "security level", indicating that SHA1-256, [SHA256], should be used for the default 128-bit level. However, due to the real-time aspects in the scenarios we are treating, hash size slightly below 256 are acceptable as the normal "existential" collision probabilities would be of secondary importance. In a Crypto Session Bundle, the Crypto Sessions can share the same TGK as discussed earlier. From a security point of view, the criterion to be satisfied is that the encryption of the individual Crypto Sessions are performed "independently". In MIKEY this is accomplished by having unique Crypto Session identifiers (see also Section 4.1). The TEK derivation method assures this by providing cryptographically independent TEKs to distinct Crypto Sessions (within the Crypto Session Bundle), regardless of the security protocol used. Specifically, the key derivations are implemented by a pseudo-random function. The one used here is a simplified version of that used in TLS [TLS]. Here, only one single hash function is used, whereas TLS uses two different functions. This choice is motivated by the high Arkko, et al. [Page 44] INTERNET-DRAFT msec-mikey-02 June 2002 confidence in the SHA-1 hash function, and, by efficiency and simplicity of design (complexity does not imply security). Note that the use of the RAND nonce in the key derivation is essential to protect against off-line time/memory trade-off attacks. In the pre-shared key and public-key schemes, the TGK is generated by a single party (Initiator). This makes MIKEY more sensitive if the Initiator uses a bad random number generator. It should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy. If mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman method is to be used. Forward/backward security: if the TGK is exposed, all TEKs generated from it are compromised. However, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same TGK. All the pre-defined transforms in MIKEY use state-of-the-art algorithms that has undergone large amounts of public evaluation. 9.2. Key lifetime Even if the lifetime of a TGK (or TEK) is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data. It is not possible to here state general key life- time bounds, universally applicable; each security protocol should define such maximum amount and trigger a re-keying procedure before the "exhaustion" of the key. E.g., according to SRTP [SRTP] the TEK MUST be changed at least every 2^48 SRTP packet (i.e. every time the ROC + SEQ no in SRTP wraps). Still, the following can be said as a rule of thumb. If the security protocol uses an "ideal" b-bit block cipher (in CBC mode, counter mode, or a feedback mode with full b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is (with constant probability) expected to occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). For security margin, re-keying MUST be triggered well in advance compared to the above bound. See [BDJR] for more details. For use of a dedicated stream cipher, we refer to the analysis and documentation of said cipher in each specific case. 9.3. Timestamps The use of timestamps instead of challenge-response requires the systems to have synchronized clocks. Of course, if two clients are not synchronized, they will have difficulties with setting up the security. The current timestamp based solution has been selected to Arkko, et al. [Page 45] INTERNET-DRAFT msec-mikey-02 June 2002 allow a maximum of one roundtrip (i.e., two messages), but still provide a reasonable replay protection. A (secure) challenge-response based version would require at least three messages. For a detailed description of the timestamp and replay handling in MIKEY, see Section 5.4. Practical experiences of Kerberos and other timestamp based systems indicate that it is not always necessary to synchronize the terminals over the network. Manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high). However, the choice must be carefully based with respect to the usage scenario. 9.4. Identity protection Identity protection was not a main design goal for MIKEY. Such feature will add more complexity to the protocol and was therefore chosen not to be included. As MIKEY is anyway proposed to be transported over e.g. SIP, the identity may be exposed by this. However, if the transporting protocol is secured and also provides identity protection, MIKEY might inherit the same feature. How this should be done is for future study. 9.5. Denial of Service This protocol is resistant to Denial of Service attacks in the sense that a Responder does not construct any state (at the key management protocol level) before it has authenticated the Initiator. However, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests. This may e.g., be solved by letting the protocol transporting MIKEY do an IP address validity test. For example, the SIP protocol can provide this using the anonymous authentication challenge mechanism (specified in Section 22.1 of [SIP]). 9.6. Session establishment It should be noted that if the session establishment protocol is insecure there may be attacks on this that will have indirect security implications on the secured media streams. This however only applies to groups (and is not specific to MIKEY). The threat is that one group member may re-direct a stream from one group member to another. This will have the same implication as when a member tries to impersonate another member, e.g. by changing its IP address. If this is seen as a problem, it is RECOMMENDED that a Source Origin Authentication (SOA) scheme (e.g., digital signatures) is applied to the security protocol. Re-direction of streams can of course be done even if it is not a group. However, the effect will not be the same compared to a group where impersonation can be done if SOA is not used. Instead, re- Arkko, et al. [Page 46] INTERNET-DRAFT msec-mikey-02 June 2002 direction will only deny the receiver the possibility to receive (or just delay) the data. 10. IANA considerations This document defines several new name spaces associated with the MIKEY payloads. This section summarize the name spaces for which IANA is requested to manage the allocation of values. IANA is requested to record the pre-defined values defined in the given sections for each name space. IANA is also requested to manage the definition of additional values in the future. Unless explicitly stated otherwise, values in the range 0-240 for each name space should be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use. The name spaces for the following fields in the Common header payload (from Section 6.1) are requested to be managed by IANA: * version * data type * Next payload * PRF func. This name space is between 0-127 where values between 0- 111 should be approved by the process of IETF consensus and values between 112-127 are reserved for Private Use. * CS ID map type The name spaces for the following fields in the Key data transport payload (from Section 6.2) are requested to be managed by IANA: * Encr alg * MAC alg The name spaces for the following fields in the DH data payload (from Section 6.4) are requested to be managed by IANA: * DH-Group The name spaces for the following fields in the Timestamp payload (from Section 6.6) are requested to be managed by IANA: * TS type Arkko, et al. [Page 47] INTERNET-DRAFT msec-mikey-02 June 2002 The name spaces for the following fields in the ID payload and the Certificate payload (from Section 6.7) are requested to be managed by IANA: * ID type * Cert type The name spaces for the following fields in the Cert hash payload (from Section 6.8) are requested to be managed by IANA: * Hash func The name spaces for the following fields in the Security policy payload (from Section 6.10) are requested to be managed by IANA: * Prot type From Section 6.10.1. * SRTP Type * SRTP encr alg * SRTP auth alg * SRTP PRF * FEC order The name spaces for the following fields in the Error payload (from Section 6.12) are requested to be managed by IANA: * Error no The name spaces for the following fields in the Key data payload (from Section 6.13) are requested to be managed by IANA: * Type. This name space is between 0-16 which should be approved by the process of IETF consensus. * KV. This name space is between 0-16 which should be approved by the process of IETF consensus. The name spaces for the following fields in the General Extensions payload (from Section 6.15) are requested to be managed by IANA: * Type Arkko, et al. [Page 48] INTERNET-DRAFT msec-mikey-02 June 2002 11. Conclusions Work for securing real-time applications have started to appear. This has brought forward the need for a key management solution to support the security protocol. The key management has to fulfil requirements, which make it suitable in the context of conversational multimedia in a heterogeneous environment and small interactive groups. MIKEY is designed to fulfill such requirements and optimized so that it also may be integrated in other protocols such as SIP and RTSP. MIKEY is designed to be used in scenarios for peer-to-peer communication, simple one-to-many, and for small-size interactive groups without a centralized group server. 12. Acknowledgments The authors would like to thank Mark Baugher, Ran Canetti, Martin Euchner, the rest of the MSEC WG, Pasi Ahonen (with his group), Rolf Blom, and Magnus Westerlund, for their valuable feedback. 13. Author's Addresses Jari Arkko Ericsson 02420 Jorvas Phone: +358 40 5079256 Finland Email: jari.arkko@ericsson.com Elisabetta Carrara Ericsson Research SE-16480 Stockholm Phone: +46 8 50877040 Sweden EMail: elisabetta.carrara@era.ericsson.se Fredrik Lindholm Ericsson Research SE-16480 Stockholm Phone: +46 8 58531705 Sweden EMail: fredrik.lindholm@era.ericsson.se Mats Naslund Ericsson Research SE-16480 Stockholm Phone: +46 8 58533739 Sweden EMail: mats.naslund@era.ericsson.se Karl Norrman Ericsson Research SE-16480 Stockholm Phone: +46 8 4044502 Sweden EMail: karl.norrman@era.ericsson.se Arkko, et al. [Page 49] INTERNET-DRAFT msec-mikey-02 June 2002 14. References 14.1. Normative References [AES] Advanced Encryption Standard (AES), Federal Information Processing Standard Publications (FIPS PUBS) 197, November 2001. [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and Norrman, K., "Key Management Extensions for SDP and RTSP", Internet Draft, Work in Progress (MMUSIC WG). [NAI] Aboba, B. and Beadles, M., "The Network Access Identifier", IETF, RFC 2486, January 1999. [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998. [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with SDP", Internet Draft, IETF, Work in progress (MMUSIC). [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [SDP] Handley, M., and Jacobson, V., "Session Description Protocol (SDP), IETF, RFC2327 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.ps [SIP] Rosenberg, J. et al, "SIP: Session Initiation Protocol", IETF, RFC3261. [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", Internet Draft, IETF, Work in Progress (AVT WG). [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", IETF, RFC 2396. [X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", IETF, RFC 3280. 14.2. Informative References [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes Arkko, et al. [Page 50] INTERNET-DRAFT msec-mikey-02 June 2002 of Operation", in Proceedings of the 38th Symposium on Foundations of Computer Science, IEEE, 1997, pp. 394-403. [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt'01, Lecture Notes in Computer Science vol 2248, pp. 442- 459. [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F., "Group Key Management Architecture", Internet Draft, Work in Progress (MSEC WG). [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group Domain of Interpretation", Internet Draft, Work in Progress (MSEC WG). [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R., "Group Secure Association Key Management Protocol", Internet Draft, Work in Progress (MSEC WG). [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for Cryptosystems", http://www.cryptosavvy.com/suggestions.htm [NTP] Mills, D., "Network Time Protocol (Version 3) specification, implementation and analysis", RFC 1305, March 1992. [PKCS1] PKCS #1 - RSA Cryptography Standard, http://www.rsalabs.com/pkcs/pkcs-1/ [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems". Communications of the ACM. Vol.21. No.2. pp.120-126. 1978. [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf [TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0", IETF, RFC 2246. Arkko, et al. [Page 51] INTERNET-DRAFT msec-mikey-02 June 2002 Appendix A. - MIKEY - SRTP relation The terminology in MIKEY differs from the one used in SRTP as MIKEY needs to be more general. Therefore it might be hard to see the relations between keys and parameters generated in MIKEY and the ones used by SRTP. This section provides some hints on their relation. MIKEY | SRTP ------------------------------------------------- Crypto Session | SRTP stream Data SA | input to SRTP's crypto context TEK | SRTP master key The Data SA is built up by a TEK and the security policy exchanged. SRTP may use a MKI to index the TEK. The TEK is then derived from the TGK that have the corresponding MKI. Revision history Changes from -01 draft: * Removed: Support for Re-key SA including KEK transport for all methods. * Timestamp required explicitly in the verification message * Renamed R flag in Common header to V (for verification) * Change of notation - Pre-Master Key (PMK) --> TEK Generation Key (TGK) - Multimedia Crypto Session (MCS) --> Crypto Session Bundle (CSB) - Some payloads have also had their name changed. - Seed (in the PRF definition) --> Label * General extensions payload added. * Possibility to send a TEK only (instead of a TGK) is provided for pre-encryption purposes. * General updates of all sections (trying to address all comments received from the list). * IANA considerations added This Internet-Draft expires in December 2002. Arkko, et al. [Page 52]