Internet Engineering Task Force J. Arkko MSEC Working Group E. Carrara INTERNET-DRAFT F. Lindholm Expires: August 2002 M. Naslund K. Norrman Ericsson February, 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 Work for securing real-time applications have started to appear. This has brought forward the need for a key management solution to support the security protocol. The key management has to fulfil requirements, which makes it suitable in the context of conversational multimedia in a heterogeneous environment. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. 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-01 February 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..................................... 9 2.5. Existing solutions...................................... 9 3. Basic Key Transport and Exchange Schemes.................. 9 3.1. Pre-shared key..........................................10 3.2. Public-key encryption...................................10 3.3. Diffie-Hellman key exchange.............................12 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 TEK from PMK...............................15 4.1.5. Generating keys from an envelope/pre-shared key.......16 4.1.6. Generating KEK from a DH-key..........................16 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..........................17 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.3. Policies................................................17 4.4. Indexing the Data SA....................................18 4.5. Re-keying and MCS updating..............................18 5. Behavior and message handling.............................19 5.1. General.................................................19 5.1.1. Capability discovery..................................19 5.1.2. Error handling........................................19 5.2. Creating a message......................................19 5.3. Parsing a message.......................................21 5.4. Replay handling.........................................21 5.5. Reliability.............................................22 6. Integration with session establishment protocols..........23 6.1. SDP integration.........................................23 6.2. MIKEY with SIP..........................................23 6.3. MIKEY with RTSP.........................................24 6.4. MIKEY Interface.........................................25 Arkko, et al. [Page 2] INTERNET-DRAFT msec-mikey-01 February 2002 7. Groups....................................................26 7.1. Simple one-to-"a few"...................................26 7.2. Small-size interactive group............................27 8. Security Considerations...................................27 8.1. General.................................................27 8.2. Key lifetime............................................28 8.3. Timestamps..............................................29 8.4. Identity protection.....................................30 8.5. Denial of Service.......................................30 8.6. Session establishment...................................30 9. Conclusions...............................................30 10. Acknowledgments..........................................31 11. Author's Addresses.......................................31 12. References...............................................31 Appendix A - Payload Encoding................................34 A.1. Common header payload...................................34 A.1.1. SRTP ID...............................................36 A.2. Key data transport payload..............................37 A.3. Envelope data payload...................................38 A.4. DH data payload.........................................38 A.5. Signature payload.......................................39 A.6. Timestamp payload.......................................40 A.7. ID payload / Certificate payload........................40 A.8. Cert hash payload.......................................41 A.9. Ver msg payload.........................................41 A.10. Security Policy payload................................42 A.10.1. SRTPbasic policy.....................................42 A.10.2. SRTPext policy.......................................44 A.10.3. Re-key policy........................................45 A.11. Rand payload...........................................46 A.12. Error payload..........................................46 A.13. Key data payload.......................................47 A.14. Key validity data .....................................48 Appendix B. - Payload usage summary..........................49 Revision History.............................................50 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. This document describes a key management solution, that address multimedia scenarios (e.g. SIP calls and RTSP sessions). The focus is Arkko, et al. [Page 3] INTERNET-DRAFT msec-mikey-01 February 2002 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: 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 ID: within an MCS unique identifier for the Crypto Session. Multimedia Crypto Session (MCS): collection of one or more Crypto Sessions, which has common Pre-Master Key and security parameters. Multimedia Crypto Session ID: unique identifier for the MCS. Security Association (SA): collection of information needed to secure a Multimedia Crypto Session. Pre-Master Key (PMK): a bit-string agreed upon by two or more parties, associated with a SA (and consequently MCS). From the pre- master key, Traffic-encrypting Keys can then be generated without need of further communication. Traffic-encrypting Key (TEK): the key used by the security protocol to protect the crypto session (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the MCS's PMK. Key-encryption key (KEK): a key to be used to protect other keys that are to be sent between the sender and the receiver. PMK re-keying: the process of re-negotiating the PMK (and consequently future TEK(s)). Initiator: the initiator of the key management protocol, not necessarily the initiator of the communication. Responder: the responder in the key management protocol. H(x): a cryptographic hash function with argument x Random(): a secure (pseudo-)random number generator Arkko, et al. [Page 4] INTERNET-DRAFT msec-mikey-01 February 2002 PRF(k,x): a keyed pseudo-random function E(k,m): encryption of m with the key k D(k,m): decryption of m with the key k Sign(k,m): the signature of message m with key k PK_x: the public key of x SK_x: the secret key of x Cert_x: Certificate of x k_p: the PMK [] an optional piece of information || concatenation | 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 being the most significant. 1.3. Abbreviations AES Advanced Encryption Standard CM Counter Mode DH Diffie-Hellman DoS Denial of Service KEK Key-encrypting Key MAC Message Authentication Code MIKEY Multimedia Internet KEYing PK Public-Key PMK Pre-Master 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 1.4. Outline Section 2 describes the basic scenario and the design goals that MIKEY are based on. It also gives a brief overview of the entire 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, re-keying, 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. Arkko, et al. [Page 5] INTERNET-DRAFT msec-mikey-01 February 2002 As MIKEY may be carried in SDP over SIP and RTSP, Section 6 describes how to integrate and use MIKEY in these scenarios. Section 7 focuses on how MIKEY is used in group scenarios. The Security Considerations section (Section 8), gives a deeper explanation on different security related topics. All definitions of the payloads in MIKEY are described in Appendix A and Appendix B includes a list of when the payloads MUST/MAY be used. 2. Basic Overview 2.1. Scenarios MIKEY is intended to be used for peer-to-peer, simple one-to-many, and small-size (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 multimedia streams (e.g. SRTP streams). We identify in the following some typical scenarios which involve the multimedia applications we are dealing with (see also Figure 1.1.). a) peer-to-peer (unicast), e.g. a SIP-based [SIP] call between two parties where 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 groups where each party may set up the security for its own outgoing media. c) many-to-many, with a centralized control unit, e.g. for larger groups with some kind of Group Controller that sets up the 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 the peer-to-peer case, one-to-many (one-to-"a few") and small-size interactive groups. Arkko, et al. [Page 6] INTERNET-DRAFT msec-mikey-01 February 2002 peer-to-peer/ many-to-many many-to-many one-to-many (distributed) (centralized) ++++ ++++ ++++ ++++ ++++ |. | |A | |B | |A |---- ----|B | --| ++++ | |----------| | | | \ / | | ++++ / ++|. | ++++ ++++ ++++ (S) ++++ |A |---------| ++++ \ / | | | \ ++|B | \ / | ++++ \-----| | \ ++++ / ++++ ++++ \|C |/ |C | | | | | ++++ ++++ Figure 1.1: Examples of the four scenarios: peer-to-peer, one-to- many, many-to-many without centralized server, and many-to-many with a centralized server. 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 round-trips. * Tunneling. Possibility to "tunnel" MIKEY in session establishment protocols (e.g. SIP and RTSP). * Independent of specific security functionality of the underlying transport. 2.3. System Overview One objective of MIKEY is to produce Data security protocol SA (Data SA), including a traffic-encrypting key (TEK), which then can be used as key input to a Security Protocol. MIKEY can also be used to distribute a Group Re-key SA, including a key-encrypting key (KEK). A re-key SA can be used as input for an external group re-key protocol (see also [GKMARCH] for more information about group re-keying). The procedure of setting up a Multimedia Crypto Session (MCS) and creating a TEK (and Data SA), is done in accordance to Figure 2.1.: Arkko, et al. [Page 7] INTERNET-DRAFT msec-mikey-01 February 2002 1. A set of security parameters and Pre-Master Key(s) (PMK) are created for the Multimedia Crypto Session (this is done by one of the three alternative key transport/exchange mechanisms, see Section 3). 2. The PMK(s) is used to derive (in a cryptographically secure way) a TEK for each Crypto Session. 3. The TEK, together with the security protocol parameters represent the Data SA, which is used as the input to the Security Protocol. +-----------------+ | MCS | +-----------------+ | Key transport | | External Group | | /exchange |--> Re-key SA -->| Re-key protocol | +-----------------+ +-----------------+ | : | PMK : v : +----------+ : CS ID ->| TEK | : Security Protocol |derivation| : Parameters +----------+ : TEK | : v v Data SA | v +-------------------+ | Crypto Session | |(Security Protocol)| +-------------------+ Figure 2.1. Overview of the key management procedure. The security protocol MAY then either use the TEK directly, or, if supported, derive further session keys from the TEK (e.g. see SRTP [SRTP]). It is however up to the security protocol to define how the TEK is used. Re-keying may be done by an external group re-key protocol using a Re-key SA (in accordance to the group key management architecture [GKMARCH]). However, a separate re-key protocol may be most useful for large scale groups. MIKEY can be used to update the TEKs without an external re-key protocol. This is then done by executing the transport/exchange phase once again to derive a new PMK (and consequently the TEKs). Arkko, et al. [Page 8] INTERNET-DRAFT msec-mikey-01 February 2002 2.4. Relation to GKMARCH The Group key management architecture (GKMARCH) [GKMARCH] describes a general architecture for group key management protocols. MIKEY is a part of this architecture, and can be used as a so called Registration protocol. The main entities involved in the architecture are 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. Note that e.g. in a SIP- initiated call, the sender may also be a receiver. As MIKEY address small interactive groups, a member may dynamically change between being a sender and receiver (or being both). 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 more suitable for demanding cases such as real- time data over heterogeneous networks, and small interactive groups. 3. Basic Key Transport and Exchange Schemes The following sections define three different ways to transport/ exchange a Pre-Master Key: with the use of a pre-shared key, public- key encryption, and Diffie-Hellman (DH) key exchange. The two first methods will be denoted key transport. In the following it is for simplicity assumed unicast communication. In addition to the PMK, a random "nonce", denoted Rand, is also transported. In all three cases, the PMK and Rand values are then used to derive TEKs as described in Section 4.1.4. Note that in general, keys for encryption and signing should be different, though for simplicity we use the same notation for both. Note also that in the following protocol definitions, things like security protocol parameters, headers etc., have intentionally been left out. In practice, the messages sent are constructed by a set of payloads (see Appendix A), wherein the different parameters may be fitted. The signature/MAC is then computed over the entire message (not only the specific values that are shown in the protocol definition). Arkko, et al. [Page 9] INTERNET-DRAFT msec-mikey-01 February 2002 3.1. Pre-shared key The pre-shared key case is done according to Figure 3.1. One or more Pre-Master Keys (PMKs) are randomly and independently chosen by the initiator together with zero or one randomly and independently chosen KEK. These are then encrypted with the pre-shared key and sent to the responder. A random bit-string, Rand, is added together with a timestamp, T. The entire message is integrity protected by a Message Authentication Code (MAC). The pre-shared secret, 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. A B Initialization: Rand, PMKs, KEK = Random () encr_key, auth_key = PRF(s,...||Rand) Protocol execution: K = [IDa],T, Rand, E(encr_key,PMKs[||KEK]) A = MAC(auth_key,K) K, A ----------------------> auth_key = PRF(s,..||Rand) V=MAC(auth_key,IDa||IDb||T),[IDb] [V] <---------------------- Figure 3.1. Pre-shared key based transport mechanism. Authentication of the peers is provided by the MAC(s). The responder MAY return (if requested by Initiator) the verification message, V. The verification message is created by applying the MAC function with an authentication key on the IDs and timestamp. As will be seen, 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. 3.2. Public-key encryption Public-key cryptography can be used to create a scalable system. A disadvantage with this approach is that it is more resource consuming Arkko, et al. [Page 10] INTERNET-DRAFT msec-mikey-01 February 2002 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). A B Initialization: Rand, PMKs, KEK = Random () encr_key, auth_key = PRF(env_key,...||Rand) Protocol execution: I=(IDa|Cert_A) O=E(encr_key,IDa||PMKs[||KEK]) P=MAC(auth_key,O) K=E(PK_b,env_key), O, P, T, Rand [, I] [, H(Cert_B)] S=Sign(SK_a,H(K)) K,S ----------------------> {retrieve env_key using SK_b} auth_key = PRF(env_key,...||Rand) V=MAC(auth_key,IDa||IDb||T),[IDb] [V] <---------------------- Figure 3.2. Key transport using public keys. The key transport mechanism is according to Figure 3.2. The initiator encrypts one or more PMKs, the IDa, and optionally a KEK. The encrypted keys MUST also be integrity protected. The keys for encryption (encr_key) of the keys and the MAC (auth_key) are derived from an "envelope" key (see Section 4.1.5). The envelope key is then encrypted using the responder's public key (which the initiator already has). While any public key techniques could be used, proposed encryption and signature transforms are described in Section 4.2. We also refer to Section 4.2 for key-encryption algorithm and MAC definitions. The Initiator creates a message consisting of the encrypted PMKs and KEK, a timestamp, a Rand, and optionally its ID/Certificate and a hash of the certificate used to encrypt the envelope key. The entire message is finally signed and sent to the responder. Arkko, et al. [Page 11] INTERNET-DRAFT msec-mikey-01 February 2002 As mentioned, the initiator MAY include a hash of the certificate of the public key used to encrypt the envelope key, env_key. The responder MUST then use the private key corresponding to the specified certificate to decrypt the encrypted envelope key. The responder MAY send a verification message, V, (as in the pre- shared case) to the initiator. This message uses a MAC (e.g. HMAC), with an authentication key, derived from the PMK according to Section 4.1.4. It is possible to cache the envelope key, so that it can be used as a pre-shared key. It is not recommended that this key should be cached indefinitely (however it is up to the local policy to decide this). This function may be very convenient during a Multimedia Crypto Session, if a new crypto session needs to be added (or an old on removed). Then, the pre-shared key can be used, instead of the public keys (see also Section 4.5.). 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: - party A typically has to find the certificate of B in order to send the first message. If A doesn't have B's certificate already, this may involve one or more roundtrips to a central directory agent. - it will be possible for A to omit its own certificate and rely on B getting this certificate using other means. However, we recommend doing this, only when it is reasonable to assume that B can be expected to have cached the certificate from a previous connection. Otherwise accessing the certificate would mean additional roundtrips for B as well. - verification of the certificates using Certificate Revocation Lists (CRLs) or an on-line verification protocol may mean additional roundtrips for both parties. If a small number of roundtrips is required for acceptable performance, it may be necessary to omit some of these checks. 3.3. Diffie-Hellman key exchange The possibility of using a Diffie-Hellman (DH) key exchange method is also offered. Though, this approach in general has a higher resource consumption (both computationally and in bandwidth) than the previous ones. With this method only one key is created, i.e. the DH-key. This may then be used either as a PMK or (indirectly) as a KEK. 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 Arkko, et al. [Page 12] INTERNET-DRAFT msec-mikey-01 February 2002 parameters are given in Section 4.2.7. The other transforms below are described in Section 4.2. A B Initialization: Rand, x = Random () y = Random () Protocol execution: I = (IDa|Cert_A) K = g^x, T, Rand [,I] S = Sign (SK_a,H(K)) K,S I' = (IDb|Cert_B) -----------------> K' = g^y,T,IDa,g^x [,I'] S' = Sign (SK_b,H(K')) K',S' <----------------- PMK=g^(xy) PMK=g^(xy) Figure 3.3. Diffie-Hellman key based exchange, where x and y are randomly chosen respectively by A and B. The key exchange is done according to Figure 3.3. The initiator chooses a random value x, and sends a signed message including g^x, a Rand, and a timestamp to the responder (optionally also including its certificate or identity). The group parameters (e.g., the group G) are a set of parameters chosen by the initiator. The responder chooses a random positive integer y, and sends a signed message including g^y and the timestamp to the initiator (optionally also providing its certificate). The signature must also cover the Initiator's id and the g^x value. Both parties then calculate the PMK, g^(xy). The authentication is due to the signing of the DH values (and identities), and is necessary to avoid man-in-the-middle attacks. Note that this approach does not require that the initiator has to posses any of the responder's certificate before the setup. Instead, it is sufficient that the responder includes it's signing certificate in the response. This approach is the most expensive approach. It requires that both sides compute one signature, one verification and two DH- exponentiations. Arkko, et al. [Page 13] INTERNET-DRAFT msec-mikey-01 February 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 should be used to derive: * TEKs from a PMK and the Rand, * a KEK from the DH-key and the Rand, * encryption, authentication, or salting key from a pre-shared/ envelope key and the Rand. 4.1.1. Assumptions We assume that the following parameters are in place (to be exchanged as security parameters, in connection to the actual key exchange): PMK: a Pre-Master Key, which MUST be random and kept secret. Note that there may be more than one PMK transported. The following parameter MAY be sent in the clear: mcs_id: Master Crypto Session 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. 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. seed: a specific seed, 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. 4.1.2. Notation Let HMAC be the SHA1 based message authentication function, see [HMAC,SHA1]. Similar to [TLS], define: P (s, seed, m) = HMAC (s, A_1 || seed) || HMAC (s, A_2 || seed) || ... HMAC (s, A_m || seed) Arkko, et al. [Page 14] INTERNET-DRAFT msec-mikey-01 February 2002 where A_0 = seed, A_i = HMAC (s, A_(i-1)). While this is the default, HMAC using other hash function MAY be used, see Section 4.2.1. 4.1.3. PRF Description The following procedure describes a pseudo-random function, denoted PRF(inkey,seed), 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,seed) = P(s_1,seed,m) XOR P(s_2,seed,m) XOR ... XOR P(s_n,seed,m). 4.1.4. Generating TEK from PMK The key derivation method should be executed with the following parameters: inkey: PMK seed: 0x2AD01C64 || cs_id || mcs_id || Rand outkey_len: length of the output TEK. Note, the cs_id is the id of the cs_id the TEK is supposed to be derived for. 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. Note that the 32-bit constant integers (i.e. 0x2AD01C64 and the once replacing it) is taken from the decimal digits of e (i.e. 2.7182...), Arkko, et al. [Page 15] INTERNET-DRAFT msec-mikey-01 February 2002 and where each constant consist of nine decimals digits (e.g. the first nine decimal digits 718281828 = 0x2AD01C64). 4.1.5. Generating keys from an envelope/pre-shared key inkey: the envelope key or the pre-shared key seed: 0x150533E1 || 0xFF || mcs_id || Rand (for encryption key) or 0x2D22AC75 || 0xFF || mcs_id || Rand (for auth. key) or 0x29B88916 || 0xFF || mcs_id || Rand (for salting key) outkey_len: desired length of the authentication/encryption/salting key. 4.1.6. Generating KEK from a DH-key inkey: DH-key seed: 0x39A2C14B || 0xFF || mcs_id || Rand outkey_len: desired length of the KEK. 4.2 Pre-defined Transforms and Timestamp Formats This section identifies standard transforms for MIKEY. The following transforms SHALL be used in the respective case. New transforms MAY be added in the future. It is however recommended to be sparse with extensions as it usually only creates interoperability problems between old and newer versions. 4.2.1 Hash functions MIKEY SHALL use one of the following hash function: SHA-1 (see [SHA1], MD5 (see [MD5]), SHA256, SHA384, or SHA512 (see [SHA256] for the last three). SHA-1 is default and the only mandatory to implement and support. 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]. For the key derivations, the PRF specified in Section 4.1. MUST be supported. This PRF MAY be extended by using SHA-256 or SHA-512, instead of SHA-1. Arkko, et al. [Page 16] INTERNET-DRAFT msec-mikey-01 February 2002 4.2.3 Key data transport encryption The default and mandatory-to-support key transport encryption is AES in counter mode, as defined in [SRTP, Section 4], using a key as derived in Section 4.1.5, and using initialization vector IV = [S XOR (0x0000 || MCS 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. Note: this restricts the maximum size of the transported key to 2^23 bits, which is still enough for all practical purposes. 4.2.4 MAC and Verification Message function MIKEY SHALL use 160-bit authentication tags, generated by HMAC with SHA-1 as the default and mandatory to implement method, see [HMAC]. Authentication keys SHALL be derived according to Section 4.1.5. 4.2.5 Envelope Key encryption When RSA is used for the envelope encryption, MIKEY SHALL use RSA/PKCS#1, see [PKCS1]. 4.2.6 Digital Signatures When RSA is used for the signatures, MIKEY SHALL use RSA/PKCS#1, see [PKCS1]. The default hash function SHALL be SHA-1. 4.2.7 Diffie-Hellman Groups Diffie-Hellman key exchange SHALL use one of the groups: OAKLEY 5, OAKLEY 1, or, OAKLEY 2, see [OAKLEY], where OAKLEY 5 is default and mandatory to support. 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.3. Policies Included in the message exchange, policies for the Data security protocol and/or the re-key protocol are transmitted. The policies are defined in a separate payload and are specific to the security/re-key protocol (see also Appendix A.10.). Together with the keys, the Arkko, et al. [Page 17] INTERNET-DRAFT msec-mikey-01 February 2002 validity period of theses SHOULD also be specified. This could either be done with an SPI (e.g. when a re-key protocol is used) 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 (or re-key protocol). 4.4. Indexing the Data SA The indexing of a Data SA will depend on the security protocol as different security protocols will have different characteristics. For SRTP the SSRC (see [SRTP]) is one of those. However, the SSRC is not sufficient. For the local lookup in the MIKEY SA data base, it is RECOMMENDED that the MIKEY implementation support a lookup using destination network address and port together with SSRC. Note that MIKEY does not send network addresses or ports. One reason to 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 address and port can be obtained form either SIP or RTSP. MIKEY can then use these addresses as the index for the Data SA lookup. 4.5. Re-keying and MCS updating A re-keying mechanism is necessary, e.g. when a key is compromised, when access control is desired, or simply when a key expires. Therefore, re-keying MUST be supported to allow a smooth (continuos) communication. In accordance to the GKMARCH, MIKEY supports the possibility to use an external group re-key protocol, by the re-key SA. However, an external group re-key protocol may not be necessary in a small group. Therefore, it is also possible to update the MCS (e.g. a TEK or a crypto session parameter) by using MIKEY. The updating of the MCS is performed by executing MIKEY again e.g. before a TEK expires, or a new crypto session is added to the MCS. When MIKEY is executed again to update the MCS, it MAY not be necessary to include certificates and other information that was provided in the first exchange, i.e. all parameters that are static or optional to include. The new message exchange MUST use the same MCS ID as the initial exchange, but a new timestamp. A new Rand MUST NOT be included in the message exchange (the Rand will only have affect in the Initial exchange). New Crypto Sessions may be 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 may be "cached" as a pre-shared key. If so, the "update message" SHOULD be a pre-shared key message, not a public key message. If the public key message is Arkko, et al. [Page 18] INTERNET-DRAFT msec-mikey-01 February 2002 used, but the envelope key was 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. A Multimedia Crypto Session MAY contain several Crypto Sessions. A problem that then MAY occur is to synchronize the re-keying if an SPI is not used. It is therefore recommended that an SPI 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 tries to guess the responder's capabilities in terms of security algorithms etc. If the guess is wrong, then the responder may send back its own capabilities (negotiation) to let the initiator choose a common set of parameters. Multiple attributes may be provided in sequence. This is done to reduce the number of roundtrips as much as possible. If the responder is not willing/capable to provide security or the parties simply cannot agree, it is up to the parties' policies how to behave, i.e. accept an insecure communication or reject it. 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.). 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 Arkko, et al. [Page 19] INTERNET-DRAFT msec-mikey-01 February 2002 payload, Security Protocol payload). The defined payloads and the exact encoding of each payload are described in Appendix A. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version ! data type ! next payload ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + ~ Common Header... ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! next payload ! Payload 1 ... ! +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! next payload ! Payload x ... ! +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MAC/Signature ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.1. MIKEY payload example. The process of generating a message consists of the following steps: * Create a master payload starting with the Common header payload. * Concatenate necessary payloads to the master payload (Appendix B lists which payloads MUST/MAY be used for the different messages). * As a last step (for messages that must be authenticated, this also include the verification message), concatenate the payload containing the MAC/signature, where the MAC/signature field is initiated with zeros. * Calculate the MAC/signature over the entire master payload and update the MAC/signature field with the MAC/signature. In the case of the verification message, the IDa || IDb || T MUST follow directly after the master payload in the MAC calculation. Note that all messages from the Initiator MUST use a new timestamp! Arkko, et al. [Page 20] INTERNET-DRAFT msec-mikey-01 February 2002 5.3. Parsing a message In general, parsing is done by extracting payload by payload and checking that no errors occur (the exact procedure is implementation specific). However, for the Responder, it is recommended that the following procedure is followed: * Extract the Timestamp and check that it is within the allowable clock skew. Also check the replay cache so that the message is not replayed (see also Section 5.4). * Extract ID and authentication algorithm (if not included, assume default one). * Verify the MAC/signature. * If the authentication is NOT successful, an Auth failure Error message MUST be sent to the initiator (if SIP is used, this should be signaled to SIP as a rejection of the offer). The message MUST then be discarded from further processing, and the event SHOULD be logged. * If the authentication is successful, the message SHOULD be processed. Though how it is processed is implementation specific. * If any unsupported parameters or errors occur during the processing, these SHOULD be reported to the Initiator by sending an error message. The processing SHOULD then be aborted. The error message MAY also include payloads to describe the supported parameters. If SIP is used, this should be signaled to SIP as a rejection of the offer (see also Section 6.2.). * If needed, a verification/response message is created and sent to the Initiator. 5.4. Replay handling * Each Responder MUST utilize a replay cache in order to remember the messages presented within the allowable clock skew (see also Section 8.3., timestamp considerations). * Replayed messages MUST NOT be processed. * A message SHOULD be deleted from the cache when it is outdated with respect to the clock skew. * Due to physical limitations, the replay cache SHOULD be set to store up to a maximum number of messages (see below for more details). Arkko, et al. [Page 21] INTERNET-DRAFT msec-mikey-01 February 2002 * If the host loses track of the incoming requests (e.g. due to overload), it MUST reject all incoming requests until the clock skew interval has passed. For a client, the maximum number of messages it will recall may vary depending on the capacity of the client itself and the network, but also the number of expected messages should be taken into account. The following is a recommendation of how the maximum size of the replay cache may be calculated: maxsize = Min (A, e*x) * block_size where A: maximum memory blocks possible to allocate (for simplicity: 1 memory block can contain the information from one message) e: fault-tolerance value (MUST be >1) x: #max expected messages per "clock skew" block_size: size of the message to be cached (note that it will probably not be needed to cache the entire message, instead a hash of the message and the timestamp might be enough). In case of a DoS attack, the client will in most cases be able to handle the replay cache. A bigger problem will probably be to process the messages (verify signatures/MACs), due to the computational workload this implies. 5.5. Reliability When MIKEY is integrated with a transporting protocol, the reliability scheme of the latter may be applied. Otherwise, the basic processing applied to ensure protocol reliability is the following. The transmitting entity (initiator or responder) MUST: * Set a timer and initialize a retry counter * If the timer expires, the message is resent and the retry counter is decreased. * If the retry counter reaches zero (0), the event MAY be logged in the appropriate system audit file Arkko, et al. [Page 22] INTERNET-DRAFT msec-mikey-01 February 2002 6. 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 MUST information. 6.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. The following two SDP attributes MUST be used by MIKEY. a=keymgmt-prot: a=keymgmt-data: The keymgmt-prot attribute indicates the key management protocol. Therefore, it MUST be set to "MIKEY", i.e. a=keymgmt-prot:MIKEY The data part is used to transport the actual key management payload message. Due to the text based nature of SDP, this part MUST be base64 encoded to avoid illegal characters but in the same time avoiding a too large message expansion. a=keymgmt-data: Example | a=keymgmt-prot:MIKEY | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... MCS < CS 1 < m=audio 49000 RTP/SAVP 98 | a=rtpmap:98 AMR/8000 | CS 2 < m=video 2232 RTP/SAVP 31 In this example the multimedia crypto session consists of two crypto sessions (one audio stream and one video stream) to be protected by SRTP (as indicated by the "RTP/SAVP" profile). 6.2. MIKEY with SIP In a basic SIP call between two parties (see Figure 6.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 Arkko, et al. [Page 23] INTERNET-DRAFT msec-mikey-01 February 2002 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 |Server | --------- --------- ^ ^ . . ++++ SIP . . SIP ++++ | | <............. ..............> | | | | | | ++++ <-------------------------------------------> ++++ SRTP Fig 6.1.: SIP-based call example. The two parties uses SIP to set up an SRTP stream between A and B. 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 message SHOULD be included, and in the answer to the offer, the MIKEY Responder message SHOULD be included. If the MIKEY part of the offer is not accepted, a MIKEY error message SHOULD be provided in the answer (following Section 5.1.). MIKEY MUST always signal to SIP 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 MCS (e.g. TEK update) SHOULD only 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.). 6.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. Arkko, et al. [Page 24] INTERNET-DRAFT msec-mikey-01 February 2002 In an RTSP scenario, the RTSP server and initiator will be the same entity. The Initiator/RTSP server includes the MIKEY message in a 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 chose the key for the content it distributes. Secondly, it will then have the possibility to use the same key for the same content that are streamed/sent to more than one client. To be able to have a server initiated MCS update procedure, either the ANNOUNCE message or the SET_PARAMETER message SHOULD be used to send the updated MIKEY material. A disadvantage of using these, is that they are not mandatory to implement. Note that the ANNOUNCE method has the possibility to send SDP descriptions to update previous ones (i.e. it is not needed to use the RTSP KeyMgmt header). 6.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. Therefore, the interface between MIKEY and these protocols MUST provide certain functionality (however, exactly how the interface looks like is very implementation dependent). MIKEY MUST have an interface towards the SIP/SDP or RTSP/SDP implementation that allows 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 provide to MIKEY. * MIKEY to receive incoming MIKEY messages. This MUST also include the possibility to return the status of the incoming message to SIP/SDP or to RTSP/SDP, i.e. whether the MIKEY message was accepted or not. * SIP/SDP or RTSP/SDP to receive information from MIKEY, this include the receiving the MCS ID, receiving the SSRCs for SRTP. It is also RECOMMENDED that extra information about errors can be received. * SIP/SDP or RTSP/SDP to receive outgoing MIKEY messages. * tearing down a MIKEY MCS (e.g. if the SIP sessions is shutdown, the MCS SHOULD also be shutdown) Arkko, et al. [Page 25] INTERNET-DRAFT msec-mikey-01 February 2002 Note that if a MCS has already been established, it is still valid for the SIP/SDP or RSP/SDP 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). 7. Groups What has been discussed up to now is not limited to single peer-to- peer communication, but can be used in small-size groups and simple one-to-many scenarios. This section describes how MIKEY is used in a group scenario. 7.1. Simple one-to-"a few" ++++ |S | | | ++++ | --------+-------------- - - | | | v v v ++++ ++++ ++++ |A | |B | |C | | | | | | | ++++ ++++ ++++ Figure 7.1. Simple one-to-many/"a few" scenario. In the most simple one-to-many/"a few" scenario, a server is streaming to a small group of clients. In this scenario RTSP or SIP could be used for the registration and the key management set up. The streaming server would act 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 PMK to all the clients (which will result in common TEKs for the group). Note, if the same PMK/TEK(s) should be used by all the group members, the streaming server MUST specify the same MCS_ID and CS_ID(s) for the session to all the group members. Security considerations arising from using the same key for several streams in the underlying security protocol MUST be considered. Arkko, et al. [Page 26] INTERNET-DRAFT msec-mikey-01 February 2002 7.2. Small-size interactive group ++++ ++++ |A | -------> |B | | | <------- | | ++++ ++++ ^ | | ^ | | | | | | ++++ | | | --->|C |<--- | ------| |------ ++++ Figure 7.2. Small-size group without centralized controller. As described in the overview section, for small-size groups one may expect that each client will be in charge for setting up the security for its outgoing streams. In these scenarios, the pre-shared key and the public-key transport methods will be 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 between the clients. Each client may set up the security for its outgoing stream(s) to the others. As for the one-to-"a few" case, the streaming client MUST specify the same MCS_ID and CS_ID(s) for its outgoing sessions if the same PMK/TEK(s) should be used for all the group members. The same security considerations for key-sharing also apply. 8. Security Considerations 8.1. General No chain is stronger than its weakest link. The cryptographic functions protecting the keys during transport/exchange SHOULD offer a security at least corresponding to the (symmetric) keys they protect. For instance, with current state of the art, see [LV], protecting a 128-bit AES key by a 512-bit RSA [RSA] key offers an overall security below 64-bits. On the other hand, protecting a 64- bit symmetric key by a 2048-bit RSA key appears to be an "overkill", leading to unnecessary time delays. Therefore, key size for the key- exchange mechanism SHOULD be weighed against the size of the exchanged key. Moreover, if the PMKs are not random, a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo) random generators for PMK generation. Arkko, et al. [Page 27] INTERNET-DRAFT msec-mikey-01 February 2002 For the selection of the hash function, SHA-1 with 160-bit output is the default one. In general, hash sizes should be twice the "security level", indicating that SHA1-256, [SHA256], should be used for the default 128-bit level. However, due to the real-time aspects in the scenarios we are treating, hash size slightly below 256 are acceptable as the normal "existential" collision probabilities would be of secondary importance. In a Multimedia Crypto Session, the Crypto Sessions (audio, video etc) share the same PMK as discussed earlier. From a security point of view, the criterion to be satisfied is that the encryption of the individual Crypto Sessions are performed "independently". In MIKEY this is accomplished by having unique Crypto Session identifiers (see also Section 4.1.). The TEK derivation method assures this by providing cryptographically independent TEKs to distinct Crypto Sessions (within the Multimedia Crypto Session), regardless of the security protocol used. 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, we use only one single hash function, whereas TLS uses two different functions. 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 PMK is generated by a single party (initiator). This makes MIKEY more sensitive if the initiator uses a bad random number generator. It should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy. If mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman scheme MUST be used. Forward/backward security: if the PMK is exposed, all TEKs generated from it are compromised. However, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same PMK. 8.2. Key lifetime Even if the lifetime of a PMK is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data. Each security protocol MUST define such maximum amount and trigger a re-keying procedure before the 'exhaustion' of the key. For SRTP the key MUST be changed at least for every 2^48 SRTP packet (i.e. every time the ROC + SEQ nr in SRTP wraps). As a rule of thumb, if the security protocol uses an 'ideal' b-bit block cipher (in CBC mode, counter mode, or a feedback mode with full Arkko, et al. [Page 28] INTERNET-DRAFT msec-mikey-01 February 2002 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. 8.3. Timestamps Timestamp usage prevents against replay attacks under the following assumptions: * Each host MUST have a clock which is at least "loosely synchronized" to the time of the other hosts. * If the clocks are to be synchronized over the network, a secure network clock synchronization protocol MUST be used. In general, a client may not expect a very high load of incoming messages and may therefore allow the degree of looseness to be on the order of minutes (5-10 minutes are believed to be ok). If a DoS attack is launched and the replay cache grows too large, MIKEY may dynamically decrease the looseness so that the replay cache becomes manageable. Servers may be the entities that will have the highest work load. It is also recommended that the servers are the Initiators of MIKEY. This will result in that the servers will not manage any significant replay cache as they will refuse all incoming messages that are not a response to an already (by the server) sent message. Practical experiences of Kerberos and other timestamp based system indicates that it is not always necessary to synchronize the terminals over the network. Manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high). However, the choice must be carefully based with respect to the usage scenario. The use of timestamps instead of challenge-response requires the systems to have synchronized clocks. Of course, if two clients are not synchronized, they will have difficulties with setting up the security. The current timestamp based solution has been selected to allow a maximum of one round-trip (i.e. two messages), but still provide a reasonable replay protection. A (secure) challenge-response based version would require at least three messages. Arkko, et al. [Page 29] INTERNET-DRAFT msec-mikey-01 February 2002 8.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. 8.5. Denial of Service This protocol is resistant to Denial of Service attacks in the sense that a responder does not construct any state (at the key management protocol level) before it has authenticated the initiator. However, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests. This MAY be solved by letting the protocol transporting MIKEY do an IP address validity test. 8.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 secure media streams. This however only applies to groups (and is not really that specific to MIKEY only). The threat is that one group member may re-direct a stream from one group member to another group member. 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 scheme is applied for the security protocol. 9. 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 was designed to fulfill such requirements and optimized so that it also may be integrated in other protocol 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. Arkko, et al. [Page 30] INTERNET-DRAFT msec-mikey-01 February 2002 10. Acknowledgments The authors would like to thank Mark Baugher, Ran Canetti, the rest of the MSEC WG, Pasi Ahonen (with his group), Rolf Blom, and Magnus Westerlund, for their valuable feedback. 11. 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 12. References [AES] Advanced Encryption Standard, www.nist.gov/aes [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes of Operation", in Proceedings of the 38th Symposium on Foundations of Computer Science, IEEE, 1997, pp. 394-403. [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt '01. Arkko, et al. [Page 31] INTERNET-DRAFT msec-mikey-01 February 2002 [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). [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and Norrman, K., "Key Management Extensions for SDP and RTSP", Internet Draft, Work in Progress (MMUSIC WG). [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for Cryptosystems", http://www.cryptosavvy.com/suggestions.htm [MD5] Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992. [NAI] Aboba, B. and Beadles, M., "The Network Access Identifier", IETF, RFC 2486, January 1999. [NTP] Mills, D., "Network Time Protocol (Version 3) specification, implementation and analysis", RFC 1305, March 1992. [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998. [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with SDP", Internet Draft, IETF, Work in progress (MMUSIC). [PKCS1] PKCS #1 - RSA Cryptography Standard, http://www.rsalabs.com/pkcs/pkcs-1/ [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems". Communications of the ACM. Vol.21. No.2. pp.120-126. 1978. [SDP] Handley, M., and Jacobson, V., "Session Description Protocol (SDP), IETF, RFC2327 Arkko, et al. [Page 32] INTERNET-DRAFT msec-mikey-01 February 2002 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.ps [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., "SIP: Session Initiation Protocol", IETF, RFC2543. [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). [TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0", IETF, RFC 2246. [TMMH] McGrew, D., "The Truncated Multi-Modular Hash Function (TMMH)", Internet Draft, IETF, Work in Progress. [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396 Arkko, et al. [Page 33] INTERNET-DRAFT msec-mikey-01 February 2002 Appendix A - Payload Encoding This appendix describes in detail all the payloads. For all encoding, Network byte order MUST always be used. Note that everything denoted Mandatory MUST be implemented, and everything denoted Default MUST be assumed to be selected if nothing else is stated. A.1. Common header payload The Common header payload MUST always be present as the first payload in each message. The common header includes general description of the exchange message. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version ! data type ! next payload !R! PRF func ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MCS ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! #CS ! CS ID map type! CS ID map info ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The common header contains the following information: * version: the version number of MIKEY. version = 1 * data type: describes the type of message (e.g. public-key transport message, verification message, error message). Data type | Value | Comment -------------------------------------- Pre-shared | 0 | Initiator's pre-shared key 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. If no more payload follows, it MUST be set to Last payload. Arkko, et al. [Page 34] INTERNET-DRAFT msec-mikey-01 February 2002 Next payload | Value | Appendix ------------------------------ Last payload | 0 | - Key data trnsp| 1 | A2 Env data | 2 | A3 DH data | 3 | A4 Signature | 4 | A5 Timestamp | 5 | A6 ID | 6 | A7 Certificate | 7 | A7 Cert hash | 8 | A8 Ver msg | 9 | A9 SP | 10 | A10 Rand | 11 | A11 Error | 12 | A12 Key data | 20 | A13 * R: flag to indicate whether a response is expected or not (this has only meaning when it is set by the Initiator). R = 0 ==> no response expected R = 1 ==> response expected * PRF func: Indicates the PRF function that has been/will be used for key derivation etc. Hash 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) * MCS ID: A 32-bit integer to identify the MCS. It is RECOMMENDED that it is chosen at random by the Initiator (the Initiator SHOULD however check for collisions). The Responder MUST use the same MCS ID in the response. * #CS: Indicates the number of Crypto Sessions that will be handled. Note that even though it is possible to use 256 CSs, this may not always be likely. * CS ID map type: specifies the method to uniquely map Crypto Sessions to the security protocol sessions. CS ID map type | Value | Comments ------------------------------------- SRTP-ID | 0 | Mandatory Arkko, et al. [Page 35] INTERNET-DRAFT msec-mikey-01 February 2002 * 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 A.1.1.). A.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 nr 1 ! SSRC 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SSRC 1 cont. ! ROC 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ROC 1 cont. ! Policy nr 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SSRC 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ROC 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy nr #CS ! SSRC #CS ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~SSRC #CS (cont)! ROC #CS ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ROC #CS (cont)! +-+-+-+-+-+-+-+-+ * Policy 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. * ROC x: Current roll-over 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: A stream using SSRC x will also have Crypto Session ID equal to x (NOT to SSRC). Arkko, et al. [Page 36] INTERNET-DRAFT msec-mikey-01 February 2002 A.2. Key data transport payload The Key data transport payload contains encrypted Key data payloads. It may contain one or more Key data payloads each including a PMK or a KEK. The last Key data payload MUST have 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 MUST be the last payload in the message (note that the Next payload field MUST be set to Last payload). The MAC is then calculated over the entire message (as described in Section 5.2.). If the transport method used is the public-key method, the Initiator's identity MUST be 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 MUST still be 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, where the MAC field and the Next payload field have been initiated with zeros. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Encr alg: The encryption algorithm used to encrypt the PMK. Encr alg | Value | Comments ------------------------------------------- AES-CM-128 | 1 | Mandatory (as defined in Section 4.2.3.) * Encr len: Length of encrypted part (in bytes). * Encr data: The encrypted PMK. * MAC alg specifies the authentication algorithm used. Arkko, et al. [Page 37] INTERNET-DRAFT msec-mikey-01 February 2002 MAC alg | Value | Comments -------------------------------------- HMAC-SHA1-160 | 0 | Mandatory (see Section 4.2.4.) * MAC: The message authentication code of the entire message. A.3. Envelope data payload 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. 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 should be cached Cache for MCS | 2 | The envelope key should be cached, but only | | to be used for the specific MCS. * Data len: The length of the data field (in bytes). * Data: The encrypted envelope key (padding and formatting MUST be done according to RSA/PKCS#1 if RSA is used). A.4. DH data payload The DH data payload carries the DH-value and indicates the DH-group 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-key len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DH-value ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! KV ! KV data (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arkko, et al. [Page 38] INTERNET-DRAFT msec-mikey-01 February 2002 * 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-key len: The length of the DH-value field (in bytes). * DH-value: The public DH-value. * Type: Indicates the type of the key included in the payload, i.e. if the resulting DH-key will be used as a PMK or KEK (in the second case, the DH-key is not used directly as a KEK, but is derived according to Section 4.1.6). See also Appendix A.13. for pre- defined values. * KV: Indicates the type of key validity period specified. This may be done by using an SPI or by providing an interval in which the key is valid (e.g. in the latter case, for SRTP this will be the SEQ nr range where the key is valid). See Appendix A.13. for pre- defined values. * KV data: This includes either the SPI or an interval (see Appendix A.14.). If KV is NULL, this field is not included. A.5. Signature payload The Signature payload carries the signature and its related data. The signature payload MUST always be the last payload in the PK transport and DH exchange messages. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Signature len ! Signature ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Signature len: The length of the signature field (in bytes). * Signature: The signature (padding and formatting MUST be done according to RSA/PKCS#1 if RSA is used). Arkko, et al. [Page 39] INTERNET-DRAFT msec-mikey-01 February 2002 A.6. Timestamp payload The timestamp payload carries the time 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 Appendix A.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. A.7. ID payload / Certificate payload The ID payload carries a uniquely-defined identifier. The certificate payload contains an indicator of the certificate provided as well as the certificate data. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! ID/Cert Type ! ID/Cert len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID/Certificate Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. If no more payload follows, it MUST be set to Last payload. See Appendix A.1. for values. * ID Type: specifies the identifier type used. ID Type | Value | Comments ---------------------------------------------- NAI | 0 | Mandatory (see [NAI]) URI | 1 | Mandatory (see [URI]) * Cert Type: specifies the certificate type used. Arkko, et al. [Page 40] INTERNET-DRAFT msec-mikey-01 February 2002 Cert Type | Value | Comments ---------------------------------------------- X.509 | 0 | Mandatory X.509 URL | 1 | X.509 Sign | 2 | Mandatory X.509 Encr | 3 | Mandatory * ID/Cert len: The length of the ID or Certificate field (in bytes). * ID/Certificate: The ID or Certificate data. A.8. Cert hash payload The Cert hash payload contains the hash of the certificate used. The hash function used MUST be the one specified in the Common header 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 ! Hash func ! Hash ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. * Hash func: Indicates the hash function that has been/will be used (see also Section 4.2.1.). Hash func | Value ---------------------- SHA-1 | 0 SHA256 | 1 SHA384 | 2 SHA512 | 3 MD5 | 4 * Hash: The hash data. Note: the hash length is implicit from the hash function used. A.9. Ver msg payload The Ver msg payload contains the calculated verification message in the PS/PK transport. Note that the MAC is calculated over the entire message as well as the IDs and Timestamp. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! Auth alg ! Ver data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arkko, et al. [Page 41] INTERNET-DRAFT msec-mikey-01 February 2002 * next payload: identifies the payload that is added after this payload. If no more payload follows, it MUST be set to Last payload. See Appendix A.1. for values. * Auth alg specified the authentication algorithm used for the verification message. Auth alg | Value | Comments ------------------------------------ HMAC-SHA1-160 | 0 | Mandatory HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length. * Ver data: The verification message data. Note: the length is implicit from the authentication algorithm used. A.10. Security Policy payload The Security Policy payload defines a set of policies that applies to a specific security/re-key protocol. 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 nr ! Prot type ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. If no more payload follows, it MUST be set to Last payload. See Appendix A.1. for values. * Policy nr: Each security policy payload must be given a distinct number. * Prot type: defines the security protocol or re-key protocol. Prot type | Value | --------------------------- SRTPbasic | 0 | see A.10.1. SRTPext | 1 | see A.10.2. Re-key | 2 | see A.10.3. * Policy param defines the policy for the security/re-key protocol. A.10.1. SRTPbasic policy This policy specifies the policy for SRTP and SRTCP. All defined transform applies to both SRTP and (if used) SRTCP. Arkko, et al. [Page 42] INTERNET-DRAFT msec-mikey-01 February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! encr alg ! encr key len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! auth alg ! auth key len ! auth tag len ! salt key len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SRTP PRF ! Key Der rate ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE: SRTP was not finalized by the date for this draft's submission. Therefore, these parameters might be an issue for update! * encr alg specifies the desired encryption algorithm to be used in SRTP (and SRTCP, if used by SRTP). encr alg | Value | Comments ------------------------------------------ NULL | 0 | Mandatory AES-CM-128 | 1 | Mandatory AES-F8-128 | 2 | AES-CM-128 is AES in CM with 128-bit block size. AES-F8-128 is AES in f8 mode with 128-bit block size. * encr key len: desired session encryption key length in bytes. * auth alg specifies the desired authentication algorithm to be used. auth alg | Value | Comments ------------------------------------------- NULL | 0 | Mandatory TMMH-16 | 1 | Mandatory HMAC-SHA1 | 2 | Mandatory * auth key len: desired session authentication key length in bytes. * auth tag len: desired length in bytes of the output tag of the MAC. * salt key len: The desired session salting key length in bytes. Note: do not mix this with the master salt that are exchanged. * PRF: Specifies the PRF used. SRTP PRF | Value | Comments ------------------------------------------- AES-CM | 0 | Mandatory * Key Der rate: The 2-logarithm of the desired key derivation rate. Note that this is possible as the key derivation rate must be a power of 2 in the range [0..2^16]. Arkko, et al. [Page 43] INTERNET-DRAFT msec-mikey-01 February 2002 A.10.2. SRTPext policy This policy separates the SRTP and SRTCP policies. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SRTP EA ! SRTP EKL ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SRTP AA ! SRTP AKL ! SRTP ATL ! SRTP SKL ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SRTxP PRF ! SRTP KDR ! SRTCP EA ! SRTCP EKL ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SRTCP AA ! SRTCP AKL ! SRTCP ATL ! SRTCP SKL ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SRTCP KDR ! +-+-+-+-+-+-+-+-+ * SRTP EA: encryption algorithm for SRTP (see Appendix A.10.1. for defined ciphers). * SRTP EAL: encryption key length in bytes for SRTP. * SRTP AA: authentication algorithm for SRTP (see Appendix A.10.1. for defined transforms). * SRTP AKL: authentication key length in bytes for SRTP. * SRTP ATL: authentication tag length in bytes for SRTP. * SRTP SKL: salting key length in bytes for SRTP. * SRTxP PRF: pseudo-random function for SRTP and SRTCP (see Appendix A.10.1. for defined PRFs). * SRTP KDR: the 2-logarithm of the key derivation rate for SRTP (see also Appendix A.10.1). * SRTCP EA: encryption algorithm for SRTCP (see Appendix A.10.1. for defined ciphers). * SRTCP EAL: encryption key length in bytes for SRTCP. * SRTCP AA: authentication algorithm for SRTCP (see Appendix A.10.1. for defined transforms). * SRTCP AKL: authentication key length in bytes for SRTCP. * SRTCP ATL: authentication tag length in bytes for SRTCP. Arkko, et al. [Page 44] INTERNET-DRAFT msec-mikey-01 February 2002 * SRTCP SKL: salting key length in bytes for SRTCP. * SRTCP KDR: the 2-logarithm of the key derivation rate for SRTCP (see also Appendix A.10.1). A.10.3. Re-key policy The following attributes is supported according to GKMARCH. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! KEK alg ! auth alg ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! KEK key len ! auth key len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! mm alg ! +-+-+-+-+-+-+-+-+ * KEK alg: The KEK ENCRYPTION ALGORITHM KEK alg | Value ----------------------- NULL | 0 3DES | 1 AES | 2 * auth alg: The AUTHENTICATION ALGORITHM auth alg | Value ----------------------- NULL | 0 HMAC-SHA1 | 1 HMAC-MD5 | 2 * KEK key len: The key length of the KEK * auth key len: The key length of the authentication key * mm alg: The MEMBERSHIP MANAGEMENT ALGORITHM mm alg | Value ----------------------- NULL | 0 LKH | 1 Arkko, et al. [Page 45] INTERNET-DRAFT msec-mikey-01 February 2002 A.11. Rand payload The Rand payload consist of a random bit-string. The Rand MUST be chosen at random and per MCS (note that the if a MCS 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. A.12. Error payload 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 nr ! Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. If no more payload follows, it MUST be set to Last payload. See Appendix A.1. for values. * Error nr indicates the type of error that was encountered. Error nr | Value | Comment ------------------------------------------------------- Auth failure | 0 | Authentication failure Invalid TS | 1 | Invalid timestamp Invalid hash | 2 | PRF function NOT supported Invalid MA | 3 | MAC algorithm NOT supported Invalid DH | 4 | DH group NOT supported Invalid ID | 5 | ID NOT supported Invalid Cert | 6 | certificate NOT supported Invalid SP | 7 | SP NOT supported Invalid SPpar | 8 | SP parameters NOT supported Arkko, et al. [Page 46] INTERNET-DRAFT msec-mikey-01 February 2002 A.13. Key data payload The key data payload contains PMKs and a optionally also a KEK. These 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 TEKs are not sent directly, but a PMK, which is then used to derive the TEK (or TEKs if there are several crypto sessions). Type | Value | Comments ------------------------------------------- PMK | 0 | A Pre-master key (used to derive TEKs from) PMK+SALT | 1 | A PMK + a salt key are included KEK | 2 | A Key-encrypting key * KV: Indicates the type of key validity period specified. This may be done by using an SPI or by providing an interval in which the key is valid (e.g. in the latter case, for SRTP this will be the SEQ nr range where the key is valid). 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 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). Arkko, et al. [Page 47] INTERNET-DRAFT msec-mikey-01 February 2002 * Key data: The PMK data or the KEK 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 Appendix A.14.). If KV is NULL, this field is not included. A.14. Key validity data The Key validity data is not a payload, but part of either the Key data payload (see Appendix A.13.) or the DH payload (see Appendix A.4.). The Key validity data gives a guideline of when the key should be used. This can be done, using an SPI or a lifetime range. SPI 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 for SRTP). 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, 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. Arkko, et al. [Page 48] INTERNET-DRAFT msec-mikey-01 February 2002 * Valid to: Sequence number, 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 PMK should be specified with either an interval, where the VF/VT length is equal to 6 bytes, or with an SPI (in SRTP denoted as a Master Key Identifier, 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 SPI rather than the From-To method. Appendix B. - Payload usage summary Depending on the type of message, different payloads MUST and MAY be included. There are five distinct types of messages: * Pre-shared key transport message * Public key transport message * Verification message (for either pre-shared key or public key) * DH exchange message (bi-directional) * Error message | Message Type Payload type | PS | PK | DH | Ver | Error ------------------------------------------------- Key data trnsp| M M# - - O+ Env data | - M - - - DH data | - - M# - - Ver msg | - - - M - Error | - - - - M Timestamp | M M M - O ID | O M M O O Signature | - M M - O+ Certificate | - O O - - Cert hash | - O O - - SP | O O O - O Rand | M@ M@ M@ - - # These messages are only mandatory for initial messages, i.e. for an update message of a MCS these are optional to include (see also Section 4.5.). + These messages may be included to authenticate the error message. However, before the other peer has been correctly authenticated, it Arkko, et al. [Page 49] INTERNET-DRAFT msec-mikey-01 February 2002 is not recommended that the error messages are sent authenticated (as this would open up for DoS attacks). @ MUST only be included by the Initiator in the initial exchange. When a payload is not included, the default values for the information carried by it SHALL be used (when applicable). The following table summarizes what messages may be included in a specific message. For the encrypted sub payloads in the Key data transport payload, the following should hold: | Message Type Payload type | PS | PK ----------------------------- Keydata/PMK | O O Keydata/KEK | O O ID | - M Revision history Changes from -00 draft: * Support for Re-key SA including KEK transport for all methods. * PK: Id included in the encrypted part to avoid "impersonation" attacks. * PK: Envelope approach for encryption of keys (as the size may exceed the limit that can be encrypted with one public-key operation). * Message processing updated * SDP, SIP and RTSP considerations updated * Group section updated * The use of Rand (instead of require a large and random MCS ID) * SRTP policies etc updated * Payload update (to support the above changes) * general editorial changes This Internet-Draft expires in August 2002. Arkko, et al. [Page 50]