Internet Engineering Task Force J. Arkko MSEC Working Group E. Carrara INTERNET-DRAFT F. Lindholm Expires: May 2002 M. Naslund K. Norrman Ericsson November, 2001 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. Arkko, et al. [Page 1] INTERNET-DRAFT msec-mikey November 2001 TABLE OF CONTENTS 1. Introduction..............................................3 1.1. Notational Conventions..................................3 1.2. Definitions.............................................3 1.3. Abbreviations...........................................4 1.4. Outline.................................................5 2. Basic Overview............................................5 2.1. Scenarios...............................................5 2.2. Design Goals............................................6 2.3. System Overview.........................................7 2.4. Existing solutions......................................8 3. Basic Key Transport and Exchange Schemes..................8 3.1. Pre-shared key..........................................8 3.2. Public-key encryption...................................9 3.3. Diffie-Hellman key exchange.............................10 4. Key Management............................................11 4.1. TEK and Verification key Calculation....................11 4.1.1. Assumptions...........................................12 4.1.2. Notation..............................................12 4.1.3. Description...........................................12 4.2. Re-keying...............................................13 5. Behavior and message handling.............................14 5.1. General.................................................14 5.1.1. Capability discovery..................................14 5.1.2. Error handling........................................14 5.2. Creating a message......................................14 5.3. Parsing a message.......................................15 5.4. Replay handling.........................................16 5.5. Reliability.............................................17 6. SDP integration...........................................17 7. Key management with SIP...................................18 7.1. Integration.............................................18 7.2. Re-keying...............................................18 8. Key management with RTSP..................................19 8.1. Integration.............................................19 8.2. Re-keying...............................................19 9. Groups....................................................19 10. Security Considerations..................................21 10.1. General................................................21 10.2. Key lifetime...........................................22 10.3. Timestamps.............................................22 10.4. Identity protection....................................23 10.5. Denial of Service......................................23 11. Conclusions..............................................24 12. Acknowledgments..........................................24 13. Author's Addresses.......................................24 14. References...............................................25 Appendix A - Payload Encoding................................27 A.1. Common header payload..................................27 Arkko, et al. [Page 2] INTERNET-DRAFT msec-mikey November 2001 A.2. PS data payload........................................29 A.3. PK data payload........................................30 A.4. DH data payload........................................30 A.5. Signature payload......................................31 A.6. Timestamp payload......................................31 A.7. ID payload / Certificate payload........................32 A.8. Cert hash payload.......................................33 A.9. Ver msg payload.........................................33 A.10. n_start/n_end/SPI payload..............................34 A.11. SP payload.............................................34 A.12. Error payload..........................................36 Appendix B. - Payload usage summary..........................36 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. [REQS] lists in detail requirements for key management to work for conversational multimedia in heterogeneous environments. Following the requirements derived in [REQS], we discuss here some scenarios, and propose a key management solution. That is, the focus is on how to set up key management for secure multimedia sessions such that requirements in a heterogeneous environment are fulfilled. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 1.2. Definitions Crypto Session: 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, both the RTP and RTCP as they are both protected by a single instance of SRTP. Crypto Session ID: unique identifier for the Crypto Session. Multimedia Crypto Session (MCS): collection of one or more Crypto Sessions, which has a common Security Association and Pre-Master Key. Arkko, et al. [Page 3] INTERNET-DRAFT msec-mikey November 2001 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 security protocol). The TEKs are derived from the MCS's PMK. 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 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 | logical OR ^ binary exclusive OR ** exponentiation 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 MAC Message Authentication Code MIKEY Multimedia Internet KEYing OFB Output Feedback Mode PK Public-Key Arkko, et al. [Page 4] INTERNET-DRAFT msec-mikey November 2001 PS Pre-Shared RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SRTP Secure RTP 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. The basic key transport/exchange mechanisms are explained in detail in Section 3. The key derivation and re-keying procedures are described in Section 4. Section 5 describes the expected behavior of the involved parties. This also includes message creation and parsing. As MIKEY may be carried in SDP over SIP and RTSP, Section 6-8 describes how to integrate and use MIKEY in these scenarios. Section 9 focuses on how MIKEY may be used in group scenarios. The Security Considerations section (Section 10), 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 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 the security is either set up by mutual agreement or each party sets up the security for its own outgoing streams. Arkko, et al. [Page 5] INTERNET-DRAFT msec-mikey November 2001 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. 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. The key management solutions may be different in the above scenarios. For large scale multicast applications and big groups scalability is an issue, and we refer to other work in the MSEC WG. This specification only describes the peer-to-peer case, on which the simple one-to-many and small-size group then can be based. Section 9 brings up some more MIKEY related group issues. 2.2. Design Goals The goal has been to create a protocol that satisfies most of the requirements stated in [REQS]. 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, Arkko, et al. [Page 6] INTERNET-DRAFT msec-mikey November 2001 - small code size, and - minimal number of round-trips. * Piggy backing. Possibility to piggy back MIKEY in session establishment protocols (e.g. SIP and RTSP). * Independent of the security of the underlying transport. 2.3. System Overview One objective of MIKEY is to produce a traffic-encrypting key (TEK), which then can be used as key input to a Security Protocol. The procedure of setting up a Crypto Session and creating a TEK, is done in accordance to Figure 2.1.: 1. A Security Association (SA) and a Pre-Master Key (PMK) are created for the Multimedia Crypto Session (this is done by one of three alternative key transport/exchange mechanisms, see Section 4). 2. The PMK is used to derive (in a cryptographically secure way) a TEK for each Crypto Session. 3. The TEK is used as the key input to the Security Protocol. ------------------- | MCS | | Key transport | | /exchange | - - - - - - - - - - | SA | ------------------- | : | PMK : v : ------------ : CS ID ->| TEK | : Security Protocol |derivation| : Parameters ------------ : | TEK : v 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. Arkko, et al. [Page 7] INTERNET-DRAFT msec-mikey November 2001 The re-keying procedure is managed by running the transport/exchange phase once more to derive a new PMK (and consequently the TEKs). 2.4. 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 in Section 3 and in [REQS], there is however a need for a scheme more suitable for demanding cases such as real-time data over heterogeneous networks. 3. Basic Key Transport and Exchange Schemes The following sections propose 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 we call key transport. In the following we assume unicast communication. Note that in the general keys for encryption and signing in general MUST be different, though for simplicity we use the same notation for both cases. 3.1. Pre-shared key The pre-shared key case is done according to Figure 3.1. The Pre- Master Key (k_p) is randomly chosen by the initiator and then encrypted with the pre-shared key and sent to the responder. T is a timestamp added by the Initiator to prevent replay attacks. The entire message MUST be integrity protected by a Message Authentication Code (MAC). It is assumed that the pre-shared secret, s, consists of key material for both the encryption (encr_key) and the integrity protection (auth_key). The identity IDa MAY be sent to correctly select the pre-shared key to be used. A B K = [IDa],T, E(encr_key,k_p) A = MAC(auth_key,K) K, A --------------------- > V=MAC(k_v,IDa||IDb||T),[IDb] [V] <---------------------- Figure 3.1. Pre-shared key based transport mechanism. Arkko, et al. [Page 8] INTERNET-DRAFT msec-mikey November 2001 Authentication of the peers is provided by the MAC(s). The responder MAY return (if requested by Initiator) the verification message, V, showing that it knows the PMK. The verification message is created by applying the MAC function with a verification key, k_v. The verification key, k_v, is derived from the PMK according to Section 4.1. Note that 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 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. A B I=(IDa|Cert_A) K=E(PK_b,k_p) || T [|| I] [|| H(Cert_B)] S=Sign(SK_a,H(K)) K,S ----------------------> V=MAC(k_v,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 a randomly chosen value k_p, to be used as the PMK, with the responder's public key (which the initiator already has). The Initiator creates a message consisting of the encrypted k_p, a timestamp, and optionally its ID/Certificate and a hash of the certificate used to encrypt k_p. The message is then signed and sent to the responder. Arkko, et al. [Page 9] INTERNET-DRAFT msec-mikey November 2001 As mentioned, the initiator MAY include a hash of the certificate of the public key used to encrypt k_p. The responder uses the private key corresponding to the specified certificate to decrypt the encrypted PMK. The responder MAY send a verification message, V, (as in the pre- shared case) to the initiator, which proves that the responder has received the PMK correctly. This message uses a MAC (e.g. HMAC), with a verification key k_v, which is derived from the PMK according to Section 4.1. Certificate handling is in general complex; the scheme shown here is not the only one possible. For example, it is possible for B to fetch A's certificate via other means. Verification of certificate against Revocation Lists is not treated here, but may add extra delay. 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: - 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. For a fixed, agreed upon, group, (G,*), for g in G and a natural number x, we let g**x denote g*g*..*g (x times). Choices for the parameters are given in the DH payload in Appendix A.6. Note that the group MUST have a size of at least two to the power of the desired PMK size. Arkko, et al. [Page 10] INTERNET-DRAFT msec-mikey November 2001 A B I = (IDa|Cert_A) K = g**x || T [|| I] S = Sign (SK_a,H(K)) K,S I' = (IDb|Cert_B) ----------------------> K' = g**y || T [|| I'] S' = Sign (SK_b,H(K')) K',S' <---------------------- k_p= g**(xy) k_p=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 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). Both parties then calculate the PMK, g**(xy). The authentication is due to the signing of the DH key, 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 first of all, that both sides compute one signature, then one verification and finally two exponentiations. 4. Key Management 4.1. TEK and Verification key Calculation We define in the following a method to derive a Verification key and TEKs from the PMK. Arkko, et al. [Page 11] INTERNET-DRAFT msec-mikey November 2001 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): k_p: the PMK, which MUST be random and kept secret. The following parameter MAY be sent in the clear: mcs_id: Master Crypto Session ID cs_id: the Crypto Session ID pmk_len: the length of the PMK. tek_len: desired TEK length for the security protocol. 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) where A_0 = seed, A_i = HMAC (s, A_(i-1)). 4.1.3. Description The following procedure is applied to compute the TEK: * let n = pmk_len / 512, rounded up to the nearest integer * split the pre-master key into n blocks, k_p = s_1 || ... || s_n, where all s_i, except possibly s_n, are 512 bits each * let m = tek_len / 160, rounded up to the nearest integer * set seed = "MIKEYtek" || cs_id || mcs_id Then, the TEK is obtained as the tek_len most significant bits of P (s_1, seed, m) ^ P (s_2, seed, m) ^ ... ^ P (s_n, seed, m). The procedure of generating the Verification key, k_v, is the same, replacing the constant string "MIKEYtek" by the constant string "MIKEYver", and cs_id by 0. (This gives a verification key of length equal to tek_len). Arkko, et al. [Page 12] INTERNET-DRAFT msec-mikey November 2001 If the security protocol does not support key derivation for authentication and encryption itself from the TEK, authentication and encryption keys MAY directly be created for the security protocol by replacing "MIKEYtek" with "MIKEYaut" and "MIKEYenc" respectively, and tek_len by the desired key-length(s) in each case. 4.2. Re-keying A PMK 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. Re-keying is performed by executing MIKEY again before the PMK expires. The necessary parameter(s) to be defined to support the re-keying procedure is the new PMK and (when applicable) a signature (with the corresponding parameters as defined in Section 3.2 and 3.3). It may be necessary to specify the key lifetime range e.g. to trigger a new re-keying procedure during the on-going Multimedia Crypto Session. The parameters for re-keying are the following: Encrypted PMK, or DH-values (depending on method). This is sent to be able to derive a new PMK and thereby new TEKs. SPI is an identifier of the new k_p. This can only be used when it is supported by the security protocol. Note that the use of SPI will exclude the use of n_start and n_end. n_start and n_end define the lifetime range of the PMK k_p (and MAY be used instead of a SPI). The lifetime range MAY be expressed in terms of time, packet index, etc. The deployed security protocol MUST specify which unit is used. If n_start and n_end is not specified, the default n_start value SHOULD be that the key is valid from the first observed packet. For the n_end value, as default the key is valid 'until further notice'. This does not mean that the protocol will be able to run forever (all security protocols will 'exhaust' the TEK sooner or later). 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 then recommended that one main Crypto Session is identified from the MCS and the re-keying is done with respect to that. Exactly how this should be done is for future study. Note that 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. Arkko, et al. [Page 13] INTERNET-DRAFT msec-mikey November 2001 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. 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 a response 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.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 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 ... ! +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Arkko, et al. [Page 14] INTERNET-DRAFT msec-mikey November 2001 : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! next payload ! Payload x ... ! +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MAC/Signature payload ~ + + ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 what payloads MUST/MAY be used for the different messages). * As a last step (for messages that must be authenticated), 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. 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 the authentication is successful, the message SHOULD be processed. Though how it is processed is implementation specific. Arkko, et al. [Page 15] INTERNET-DRAFT msec-mikey November 2001 * 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 needed, a 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 10.3. for timestamp considerations). * 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). * 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-tolerant 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. Arkko, et al. [Page 16] INTERNET-DRAFT msec-mikey November 2001 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 6. SDP integration SDP descriptions [SDP] can be carried by several protocols, such as SIP and RTSP. One of the goals in the design of MIKEY was to be able to piggy-back it in other protocols (such as SIP and RTSP). Both SIP and RTSP often uses 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. 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 Arkko, et al. [Page 17] INTERNET-DRAFT msec-mikey November 2001 In this example the multimedia crypto session consists of two crypto sessions (one audio stream and one video stream). 7. Key management with SIP In a basic SIP call between two parties (see Figure 7.1.), SIP (Session Initiation Protocol, [SIP]) is used as a session establishment protocol between a caller A and a callee B. |A's SIP| <.......> |B's SIP| |Server | SIP |Server | --------- --------- ^ ^ . . ++++ SIP . . SIP ++++ | | <............. ..............> | | | | | | ++++ <-------------------------------------------> ++++ SRTP Fig 7.1.: SIP-based call example. The two parties uses SIP to set up an SRTP stream between A and B. 7.1. Integration SIP may carry SDP descriptions, since the participants negotiate the media encoding etc. Therefore, the SDP attributes previously described may be integrated inside the INVITE and the answer to that. Eventually, subsequent SIP messages may also be used, e.g., when parameter negotiation is needed. It may be assumed that the caller knows the identity of the callee. 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. 7.2. Re-keying A re-keying mechanism is necessary, e.g. when the key is compromised or simply because it has a restricted lifetime. When SIP is used as the session establishment protocol, a re-INVITE can be issued carrying SDP with the MIKEY data (this is sent by the Initiator of MIKEY). Note that it might not be necessary to send all information, such as the certificate, due to the already established call. Arkko, et al. [Page 18] INTERNET-DRAFT msec-mikey November 2001 8. Key management 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 not containing a SDP description, the RTSP KeyMgmt header (defined in [KMASDP]) is used. 8.1. Integration The server MUST include the necessary security parameters, key included, in the SDP part of the response to the initial DESCRIBE message. If a response is required, this should be included in the first SETUP message from the client to the server. Note that the SETUP message does not include a SDP description, why the RTSP KeyMgmt header (defined in [KMASDP]) MUST be used to pass the MIKEY 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. 8.2. Re-keying To be able to have a server initiated re-keying procedure, either the ANNOUNCE message or the SET_PARAMETER message SHOULD be used to send the re-keying material. A disadvantage of using these, are 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). 9. Groups What has been discussed up to now can be extended from the unicast case to small-size groups and simple one-to-many scenarios. However, key management is more complex in the case of groups. This section does not give a solution for how MIKEY should be used for groups (that will be a second step in the process of MIKEY). This section only describes some properties of the transport and exchange mechanisms that might be of importance for future work and extensions in the area. Arkko, et al. [Page 19] INTERNET-DRAFT msec-mikey November 2001 9.1. Simple one-to-many ++++ |S | | | ++++ | --------+-------------- - - | | | v v v ++++ ++++ ++++ |A | |B | |C | | | | | | | ++++ ++++ ++++ Figure 9.1. Simple one-to-many scenario. In the most simple one-to-many scenario, where 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 server would then act as the Initiator of MIKEY (see also Section 8.). In this scenario the pre-shared key or public key transport mechanism would be appropriate to use to transport the same PMK to all the clients (which will result in common TEKs for the group). However, as the group increases in size, scalability and management problems may arise. The Group Key Management Architecture [GARCH] describes a scalable architecture of handling this scenario. The architecture can be used as a base for how MIKEY should be used in order to handle scalable groups. Some minor extensions to MIKEY will be needed, such as the transport of a key-encrypting key (KEK). However, this document does not consider how MIKEY should be used with the architecture. 9.2. Small-size group ++++ ++++ |A | -------> |B | | | <------- | | ++++ ++++ ^ | | ^ | | | | | | ++++ | | | --->|C |<--- | ------| |------ ++++ Figure 9.2. Small-size group without centralized controller. Arkko, et al. [Page 20] INTERNET-DRAFT msec-mikey November 2001 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 should be used. One scenario may then be that the client sets up a three-part call, using SIP. Due to the small size group, unicast SRTP is used between the clients. Each client may set up the security for its outgoing streams to the others. A scenario like this would not require any modifications neither to MIKEY nor SIP/SDP. 10. Security Considerations 10.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. 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. Arkko, et al. [Page 21] INTERNET-DRAFT msec-mikey November 2001 Specifically, the TEK key derivation is 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, motivated by the risk of one of the hashes being broken. We motivate our simplification by the observation that if a single widely used hash, e.g. SHA1, is broken, the wide-spread use of that function means that we have much more to be worried about than the security of a single protocol. Also, SHA1 would need to have very serious flaws for our pseudo random function to be considered insecure. 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, k_p, 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. 10.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 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 b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is expected to occur after a total of roughly 2**(b/2) encrypted b-bit blocks (using random IVs). For some security margin, re-keying SHOULD 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. 10.3. Timestamps The timestamp prevents against replay attacks under the following assumptions: Arkko, et al. [Page 22] INTERNET-DRAFT msec-mikey November 2001 * 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. 10.4. Identity protection Identity protection was not a main design goal when designing MIKEY. Such feature would have added 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. 10.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 Arkko, et al. [Page 23] INTERNET-DRAFT msec-mikey November 2001 solved by letting the protocol transporting MIKEY do an IP address validity test. 11. Conclusions Work for securing real-time applications have started to appear. This has brought forward the need for a key management solution to support the security protocol. The key management has to fulfil requirements, which make it suitable in the context of conversational multimedia in a heterogeneous environment. 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 can be used in different scenarios, for peer-to-peer communication, simple one-to-many, and for small-size groups without a centralized group server. This specification focused on the basic peer-to-peer scenario, as this also will be the base for the group scenarios. 12. Acknowledgments The authors would like to thank, Mark Baugher, Ran Canetti, the rest of the msec WG, Pasi Ahonen, Rolf Blom, Vesa-Matti Mantyla, and Magnus Westerlund, for their valuable feedback. 13. Author's Addresses Jari Arkko Ericsson 02420 Jorvas Phone: +358 40 5079256 Finland Email: jari.arkko@ericsson.com Elisabetta Carrara Ericsson Research SE-16480 Stockholm Phone: +46 8 50877040 Sweden EMail: elisabetta.carrara@era.ericsson.se Fredrik Lindholm Ericsson Research SE-16480 Stockholm Phone: +46 8 58531705 Sweden EMail: fredrik.lindholm@era.ericsson.se Mats Naslund Ericsson Research SE-16480 Stockholm Phone: +46 8 58533739 Sweden EMail: mats.naslund@era.ericsson.se Arkko, et al. [Page 24] INTERNET-DRAFT msec-mikey November 2001 Karl Norrman Ericsson Research SE-16480 Stockholm Phone: +46 8 4044502 Sweden EMail: karl.norrman@era.ericsson.se 14. 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. [GARCH] Baugher, M., Canetti, R., and Dondeti, L., "Group Key Management Architecture", Internet Draft, June 2001, Work in Progress. [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group Domain of Interpretation", Internet Draft, February 2001, Work in Progress. [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R., "Group Secure Association Key Management Protocol", Internet Draft, March 2001, Work in Progress. [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", 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. Arkko, et al. [Page 25] INTERNET-DRAFT msec-mikey November 2001 [PKCS1] PKCS #1 - RSA Cryptography Standard, http://www.rsalabs.com/pkcs/pkcs-1/ [REQS] Blom, R., Carrara, E., Lindholm, F., and Arkko, J., "Design Criteria for Multimedia Session Key Management in Heterogeneous Networks", Internet Draft, July 2001, Work in Progress. [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 [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] 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 26] INTERNET-DRAFT msec-mikey November 2001 Appendix A - Payload Encoding This appendix describes in detail all the payloads. For all encoding, Network byte order MUST always be used. 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! Hash func ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MCS/CS ID type! ! +-+-+-+-+-+-+-+-+ + ~ MCS/CS ID ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 transport message PS ver msg | 1 | Verification message of a Pre-shared 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. Next payload | Value --------------------- Last payload | 0 PS data | 1 Arkko, et al. [Page 27] INTERNET-DRAFT msec-mikey November 2001 PK data | 2 DH data | 3 Signature | 4 Timestamp | 5 ID | 6 Certificate | 7 Cert hash | 8 Ver msg | 9 n_start | 10 n_end | 11 SPI | 12 SP | 13 Error | 14 * 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 * Hash func: Indicates the hash function that has been/will be used. Hash func | Value | Comments -------------------------------------------------------- SHA-1 | 0 | Mandatory, Default (see [SHA1]) MD5 | 1 | (see [MD5]) SHA256 | 2 | (see [SHA256]) SHA384 | 3 | (see [SHA256]) SHA512 | 4 | (see [SHA256]) * MCS/CS ID type: specifies the id used to uniquely identify the MCS and the CS(s). MCS/CS ID type | Value | Comments ------------------------------------- SRTP-ID | 0 | Mandatory * MCS/CS ID: Identifies the multimedia crypto session and/or the crypto session(s) that the SA should be created for. The currently defined IDs are: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! #CS ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ! Arkko, et al. [Page 28] INTERNET-DRAFT msec-mikey November 2001 + SRTP MCS ID (80 bits) + ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SSRC 1 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SSRC 2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SSRC #CS ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * #CS: Indicates the number of Crypto Sessions, i.e. the number of SRTP streams. * SRTP MCS ID: MUST be chosen at random by the Initiator (the Initiator SHOULD however check for collisions). The Responder MUST use the same MCS ID in the response. * 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 possible that the Initiator of MIKEY does 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. NOTE: A stream using SSRC x will also have Crypto Session ID x. A.2. PS data payload The PS (pre-shared) data payload contains the encrypted PMK and the MAC of the entire message. The PS data payload MUST be added as the last payload in the pre-shared transport 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! MAC alg ! Encr alg ! Encr data len | Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Encr data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MAC ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * MAC alg specifies the authentication algorithm used. MAC alg | Value | Comments -------------------------------------- HMAC-SHA1-160 | 0 | Mandatory Arkko, et al. [Page 29] INTERNET-DRAFT msec-mikey November 2001 HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length. * Encr alg: The encryption algorithm used to encrypt the PMK. Encr alg | Value | Comments ------------------------------------------- AES-CM-128 | 1 | Mandatory AES-CM-128 is AES in Counter Mode (as defined in [SRTP] where the salting key = 0) with 128-bit block size and key. The IV MUST be created as IV = MCS ID || T32 || 0...0, where T32 is the 32 least significant bits of the timestamp and 0...0 is 16 bits of zeros. * Encr data: The encrypted PMK. * MAC: The message authentication code of the entire message. A.3. PK data payload The PK (public-key) data payload contains the encrypted data from the PK transport. 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 ! Key data len ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Key data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. * Key data len: The length of the Key data field (in bytes). * Key data: The encrypted PMK (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. Arkko, et al. [Page 30] INTERNET-DRAFT msec-mikey November 2001 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 ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * 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 | See [OAKLEY] for the definitions of the Oakley groups. * DH-key len: The length of the DH-value field (in bytes). * DH-value: The public DH-value. 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). A.6. Timestamp payload The timestamp payload carries the time information. 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 Arkko, et al. [Page 31] INTERNET-DRAFT msec-mikey November 2001 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 GMT. 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-GMT | 0 | Mandatory (64-bits) NTP | 1 | Mandatory (64-bits) Note that NTP-GMT is the NTP time but calculated from GMT. This is to avoid time-zone problems. * 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. Arkko, et al. [Page 32] INTERNET-DRAFT msec-mikey November 2001 ID Type | Value | Comments ---------------------------------------------- NAI | 0 | Mandatory (see [NAI]) URI | 1 | Mandatory (see [URI]) * Cert Type: specifies the certificate type used. Cert Type | Value | Comments ---------------------------------------------- X.509 | 0 | Mandatory X.509 URL | 1 | * 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 ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. * 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. 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 33] INTERNET-DRAFT msec-mikey November 2001 * 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. n_start/n_end/SPI payload The n_start/n_end/SPI payload defines the n_start value, the n_end value or the SPI as defined in Section 4.2. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Length | ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Valid from/Expires/SPI ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * next payload: identifies the payload that is added after this payload. * Length: The length of the n_start/n_end/SPI field (in bytes). * Valid from: Indicates the Index/Sequence number when the key is valid from. The field size is dependent on the security protocol. For SRTP, this field MUST be 48 bits. * Expires: Indicates the Index/Sequence number when the key expires. The field size is dependent on the security protocol. For SRTP, this field MUST be 48 bits. * SPI: Indicates a SPI that MUST be associated with the new PMK. The field size may be dependent on the security protocol. A.11. SP payload The SP payload defines the security protocol that will be used, and its related parameters. Arkko, et al. [Page 34] INTERNET-DRAFT msec-mikey November 2001 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 ! SP ! SP 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. * SP defines the security protocol used. SP | Value --------------------- SRTP | 0 * SP param defines the parameters for the security protocol. SP param is dependent on the defined security protocol. For SRTP the SP param is currently defined as: 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 ! auth alg ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Salt len ! Salt key ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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 and key. AES-F8-128 is AES in f8 mode with 128-bit block size and key. * auth alg specifies the desired authentication algorithm to be used. auth alg | Value | Comments ------------------------------------------- NULL | 0 | Mandatory Arkko, et al. [Page 35] INTERNET-DRAFT msec-mikey November 2001 TMMH-16-16 | 1 | ? HMAC-SHA1-32 | 2 | ? TMMH-16-16 is TMMH/16 [TMMH] with a 16-bit tag length. HMAC-SHA1-32 is HMAC using SHA-1 with a 32-bits tag length. * Salt len: Length of the salting key. * Salt key: The salting key to SRTP (must be random). 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 | hash 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 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 Arkko, et al. [Page 36] INTERNET-DRAFT msec-mikey November 2001 * 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 ------------------------------------------------- PS data | M - - - - PK data | - M* - - - DH data | - - M - - Ver msg | - - - M - Error | - - - - M Timestamp | M M M - O ID | O O O O O Signature | - O M - - Certificate | - O O - - Cert hash | - O O - - n_start | O O O - - n_end | O O O - - SPI | O O O - - SP | O O O - O 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. This Internet-Draft expires in May 2002. Arkko, et al. [Page 37]