idnits 2.17.1 draft-ietf-msec-mikey-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1623 has weird spacing: '...ectives in...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IDi' is mentioned on line 1155, but not defined == Missing Reference: 'IDr' is mentioned on line 1165, but not defined == Missing Reference: 'CHASH' is mentioned on line 1163, but not defined == Missing Reference: 'KEMAC' is mentioned on line 1162, but not defined == Missing Reference: 'DHi' is mentioned on line 1174, but not defined == Missing Reference: 'DHr' is mentioned on line 1174, but not defined == Unused Reference: 'AES' is defined on line 2703, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 2724, but no explicit reference was found in the text == Unused Reference: 'AKE' is defined on line 2747, but no explicit reference was found in the text == Unused Reference: 'LOA' is defined on line 2800, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'OAKLEY') -- Possible downref: Non-RFC (?) normative reference: ref. 'PSS' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRTP' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. 'AESKW') -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RAND') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. 'RTSP') (Obsoleted by RFC 7826) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-15 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 MSEC Working Group E. Carrara 4 INTERNET-DRAFT F. Lindholm 5 Expires: June 2004 M. Naslund 6 K. Norrman 7 Ericsson 8 December, 2003 10 MIKEY: Multimedia Internet KEYing 11 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 Security protocols for real-time multimedia applications have started 38 to appear. This has brought forward the need for a key management 39 solution to support these protocols. 41 This document describes a key management scheme that can be used for 42 real-time applications (both for peer-to-peer communication and group 43 communication). In particular, its use to support the Secure Real- 44 time Transport Protocol is described in detail. 46 TABLE OF CONTENTS 48 1. Introduction.....................................................3 49 1.1. Existing solutions.............................................4 50 1.2. Notational Conventions.........................................4 51 1.3. Definitions....................................................4 52 1.4. Abbreviations..................................................5 53 1.5. Outline........................................................6 54 2. Basic Overview...................................................6 55 2.1. Scenarios......................................................6 56 2.2. Design Goals...................................................7 57 2.3. System Overview................................................8 58 2.4. Relation to GKMARCH............................................9 59 3. Basic Key Transport and Exchange Methods........................10 60 3.1. Pre-shared key................................................11 61 3.2. Public-key encryption.........................................12 62 3.3. Diffie-Hellman key exchange...................................14 63 4. Selected Key Management Functions...............................15 64 4.1. Key Calculation...............................................15 65 4.1.1. Assumptions.................................................15 66 4.1.2. Default PRF Description.....................................16 67 4.1.3. Generating keys from TGK....................................17 68 4.1.4. Generating keys for MIKEY messages from 69 an envelope/pre-shared key..................................18 70 4.2 Pre-defined Transforms and Timestamp Formats...................18 71 4.2.1 Hash functions...............................................19 72 4.2.2 Pseudo-random number generator and PRF.......................19 73 4.2.3 Key data transport encryption................................19 74 4.2.4 MAC and Verification Message function........................20 75 4.2.5 Envelope Key encryption......................................20 76 4.2.6 Digital Signatures...........................................20 77 4.2.7 Diffie-Hellman Groups........................................20 78 4.2.8. Timestamps..................................................20 79 4.2.9. Adding new parameters to MIKEY..............................20 80 4.3. Certificates, Policies and Authorization......................21 81 4.3.1. Certificate handling........................................21 82 4.3.2. Authorization...............................................22 83 4.3.3. Data Policies...............................................23 84 4.4. Retrieving the Data SA........................................23 85 4.5. TGK re-keying and CSB updating................................23 86 5. Behavior and message handling...................................25 87 5.1. General.......................................................25 88 5.1.1. Capability Discovery........................................25 89 5.1.2. Error Handling..............................................26 90 5.2. Creating a message............................................26 91 5.3. Parsing a message.............................................28 92 5.4. Replay handling and timestamp usage...........................28 93 6. Payload Encoding................................................30 94 6.1. Common Header payload (HDR)...................................31 95 6.1.1. SRTP ID.....................................................33 96 6.2. Key data transport payload (KEMAC)............................34 97 6.3. Envelope data payload (PKE)...................................35 98 6.4. DH data payload (DH)..........................................36 99 6.5. Signature payload (SIGN)......................................37 100 6.6. Timestamp payload (T).........................................37 101 6.7. ID payload (ID) / Certificate payload (CERT)..................38 102 6.8. Cert hash payload (CHASH).....................................39 103 6.9. Ver msg payload (V)...........................................40 104 6.10. Security Policy payload (SP).................................40 105 6.10.1. SRTP policy................................................41 106 6.11. RAND payload (RAND)..........................................43 107 6.12. Error payload (ERR)..........................................43 108 6.13. Key data sub-payload.........................................44 109 6.14. Key validity data............................................45 110 6.15. General Extension Payload....................................46 111 7. Transport protocols.............................................47 112 8. Groups..........................................................47 113 8.1. Simple one-to-many............................................48 114 8.2. Small-size interactive group..................................48 115 9. Security Considerations.........................................49 116 9.1. General.......................................................49 117 9.2. Key lifetime..................................................51 118 9.3. Timestamps....................................................52 119 9.4. Identity protection...........................................52 120 9.5. Denial of Service.............................................52 121 9.6. Session establishment.........................................53 122 10. IANA considerations............................................53 123 10.1 MIME Registration.............................................55 124 11. Acknowledgments................................................56 125 12. Author's Addresses.............................................56 126 13. References.....................................................56 127 13.1. Normative References.........................................56 128 13.2. Informative References.......................................57 129 Appendix A. - MIKEY - SRTP relation................................59 131 1. Introduction 133 There has recently been work to define a security protocol for the 134 protection of real-time applications running over RTP, [SRTP]. 135 However, a security protocol needs a key management solution to 136 exchange keys and related security parameters. There are some 137 fundamental properties that such a key management scheme has to 138 fulfill to serve streaming and real-time applications (such as 139 unicast and multicast), in particular in heterogeneous (mix of wired 140 and wireless) networks. 142 This document describes a key management solution that addresses 143 multimedia scenarios (e.g. SIP [SIP] calls and RTSP [RTSP] sessions). 144 The focus is on how to set up key management for secure multimedia 145 sessions such that requirements in a heterogeneous environment are 146 fulfilled. 148 1.1. Existing solutions 150 There is work done in IETF to develop key management schemes. For 151 example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and 152 the MSEC WG is developing other schemes, addressed to group 153 communication [GDOI, GSAKMP]. For reasons discussed below, there is 154 however a need for a scheme with lower latency, suitable for 155 demanding cases such as real-time data over heterogeneous networks, 156 and small interactive groups. 158 An option in some cases might be to use [SDP], as SDP defines one 159 field to transport keys, the "k=" field. However, this field cannot 160 be used for more general key management purposes, as it cannot be 161 extended from the current definition. 163 1.2. Notational Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 167 this document are to be interpreted as described in RFC 2119 168 [RFC2119]. 170 1.3. Definitions 172 (Data) Security Protocol: the security protocol used to protect the 173 actual data traffic. Examples of security protocols are IPsec and 174 SRTP. 176 Data Security Association (Data SA): information for the security 177 protocol, including a TEK and a set of parameters/policies. 179 Crypto Session (CS): uni- or bi-directional data stream(s), protected 180 by a single instance of a security protocol. E.g. when SRTP is used, 181 the Crypto Session will often contain two streams, an RTP stream and 182 the corresponding RTCP which are both protected by a single SRTP 183 Cryptographic Context, i.e. they share key data and the bulk of 184 security parameters in the SRTP Cryptographic Context (default 185 behavior in [SRTP]). In the case of IPsec, a Crypto Session would 186 represent an instantiation of an IPsec SA. A Crypto Session can be 187 viewed as a Data SA (as defined in [GKMARCH]) and could therefore be 188 mapped to other security protocols if needed. 190 Crypto Session Bundle (CSB): collection of one or more Crypto 191 Sessions, which can have common TGKs (see below) and security 192 parameters. 194 Crypto Session ID: unique identifier for the CS within a CSB. 196 Crypto Session Bundle ID (CSB ID): unique identifier for the CSB. 198 TEK Generation Key (TGK): a bit-string agreed upon by two or more 199 parties, associated with CSB. From the TGK, Traffic-encrypting Keys 200 can then be generated without need of further communication. 202 Traffic-Encrypting Key (TEK): the key used by the security protocol 203 to protect the CS (this key may be used directly by the security 204 protocol or may be used to derive further keys depending on the 205 security protocol). The TEKs are derived from the CSB's TGK. 207 TGK re-keying: the process of re-negotiating/updating the TGK (and 208 consequently future TEK(s)). 210 Initiator: the Initiator of the key management protocol, not 211 necessarily the Initiator of the communication. 213 Responder: the Responder in the key management protocol. 215 Salting key: a random or pseudo-random (see [RAND, HAC]) string used 216 to protect against some off-line pre-computation attacks on the 217 underlying security protocol. 219 PRF(k,x): a keyed pseudo-random function (see [HAC]). 220 E(k,m): encryption of m with the key k. 221 PKx: the public key of x 222 [] an optional piece of information 223 {} denotes zero or more occurrences 224 || concatenation 225 | OR (selection operator) 226 ^ exponentiation 227 XOR exclusive or 229 Bit and byte ordering: throughout the document bits and bytes are as 230 usual indexed from left to right, with the leftmost bits/bytes being 231 the most significant. 233 1.4. Abbreviations 235 AES Advanced Encryption Standard 236 CM Counter Mode (as defined in [SRTP]) 237 CS Crypto Session 238 CSB Crypto Session Bundle 239 DH Diffie-Hellman 240 DoS Denial of Service 241 MAC Message Authentication Code 242 MIKEY Multimedia Internet KEYing 243 PK Public-Key 244 PSK Pre-Shared key 245 RTP Real-time Transport Protocol 246 RTSP Real Time Streaming Protocol 247 SDP Session Description Protocol 248 SIP Session Initiation Protocol 249 SRTP Secure RTP 250 TEK Traffic-encrypting key 251 TGK TEK Generation Key 253 1.5. Outline 255 Section 2 describes the basic scenarios and the design goals for 256 which MIKEY is intended. It also gives a brief overview of the entire 257 solution and its relation to the group key management architecture 258 [GKMARCH]. 260 The basic key transport/exchange mechanisms are explained in detail 261 in Section 3. The key derivation, and other general key management 262 procedures are described in Section 4. 264 Section 5 describes the expected behavior of the involved parties. 265 This also includes message creation and parsing. 267 All definitions of the payloads in MIKEY are described in Section 6. 269 Section 7 deals with transport considerations, while Section 8 270 focuses on how MIKEY is used in group scenarios. 272 The Security Considerations section (Section 9), gives a deeper 273 explanation of important security related topics. 275 2. Basic Overview 277 2.1. Scenarios 279 MIKEY is mainly intended to be used for peer-to-peer, simple one-to- 280 many, and small-size (interactive) groups. One of the main multimedia 281 scenarios considered when designing MIKEY has been the conversational 282 multimedia scenario, where users may interact and communicate in 283 real-time. In these scenarios it can be expected that peers set up 284 multimedia sessions between each other, where a multimedia session 285 may consist of one or more secured multimedia streams (e.g. SRTP 286 streams). 288 peer-to-peer/ many-to-many many-to-many 289 simple one-to-many (distributed) (centralized) 290 ++++ ++++ ++++ ++++ ++++ 291 |. | |A | |B | |A |---- ----|B | 292 --| ++++ | |----------| | | | \ / | | 293 ++++ / ++|. | ++++ ++++ ++++ (S) ++++ 294 |A |---------| ++++ \ / | 295 | | \ ++|B | \ / | 296 ++++ \-----| | \ ++++ / ++++ 297 ++++ \|C |/ |C | 298 | | | | 299 ++++ ++++ 301 Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one- 302 to-many, many-to-many without centralized server (also denoted as 303 small interactive group), and many-to-many with a centralized server. 305 We identify in the following some typical scenarios which involve the 306 multimedia applications we are dealing with (see also Figure 2.1). 308 a) peer-to-peer (unicast), e.g. a SIP-based [SIP] call between two 309 parties where it may be desirable that the security is either set up 310 by mutual agreement or that each party sets up the security for its 311 own outgoing streams. 313 b) simple one-to-many (multicast), e.g. real-time presentations, 314 where the sender is in charge of setting up the security. 316 c) many-to-many, without a centralized control unit, e.g. for small- 317 size interactive groups where each party may set up the security for 318 its own outgoing media. Two basic models may be used here. In the 319 first model, the Initiator of the group acts as the group server (and 320 is the only one authorized to include new members). In the second 321 model, authorization information to include new members can be 322 delegated to other participants. 324 d) many-to-many, with a centralized control unit, e.g. for larger 325 groups with some kind of Group Controller that sets up the security. 327 The key management solutions may be different in the above scenarios. 328 When designing MIKEY, the main focus has been on case a, b, and c. 329 For scenario c, only the first model is covered by this document. 331 2.2. Design Goals 333 The key management protocol is designed to have the following 334 characteristics: 336 * End-to-end security. Only the participants involved in the 337 communication have access to the generated key(s). 339 * Simplicity. 341 * Efficiency. Designed to have: 342 - low bandwidth consumption, 343 - low computational workload, 344 - small code size, and 345 - minimal number of roundtrips. 347 * Tunneling. Possibility to "tunnel"/integrate MIKEY in session 348 establishment protocols (e.g. SDP and RTSP). 350 * Independent of any specific security functionality of the 351 underlying transport. 353 2.3. System Overview 355 One objective of MIKEY is to produce a Data SA for the security 356 protocol, including a traffic-encrypting key (TEK), which is derived 357 from a TEK Generation Key (TGK), and used as input to the security 358 protocol. 360 MIKEY supports the possibility to establish keys and parameters for 361 more than one security protocol (or for several instances of the same 362 security protocol) at the same time. The concept of Crypto Session 363 Bundle (CSB) is used to denote a collection of one or more Crypto 364 Sessions that can have common TGK and security parameters, but which 365 obtain distinct TEKs from MIKEY. 367 The procedure of setting up a CSB and creating a TEK (and Data SA), 368 is done in accordance with Figure 2.2: 370 1. A set of security parameters and TGK(s) are agreed upon for the 371 Crypto Session Bundle (this is done by one of the three alternative 372 key transport/exchange mechanisms, see Section 3). 374 2. The TGK(s) is used to derive (in a cryptographically secure way) a 375 TEK for each Crypto Session. 377 3. The TEK, together with the security protocol parameters, represent 378 the Data SA, which is used as the input to the security protocol. 380 +-----------------+ 381 | CSB | 382 | Key transport | (see Section 3) 383 | /exchange | 384 +-----------------+ 385 | : 386 | TGK : 387 v : 388 +----------+ : 389 CS ID ->| TEK | : Security protocol (see Section 4) 390 |derivation| : parameters (policies) 391 +----------+ : 392 TEK | : 393 v v 394 Data SA 395 | 396 v 397 +-------------------+ 398 | Crypto Session | 399 |(Security Protocol)| 400 +-------------------+ 402 Figure 2.2: Overview of MIKEY key management procedure. 404 The security protocol can then either use the TEK directly, or, if 405 supported, derive further session keys from the TEK (e.g. see SRTP 406 [SRTP]). It is however up to the security protocol to define how the 407 TEK is used. 409 MIKEY can be used to update TEKs and the Crypto Sessions in a current 410 Crypto Session Bundle (see Section 4.5). This is done by executing 411 the transport/exchange phase once again to obtain a new TGK (and 412 consequently derive new TEKs) or to update some other specific CS 413 parameters. 415 2.4. Relation to GKMARCH 417 The Group key management architecture (GKMARCH) [GKMARCH] describes a 418 general architecture for group key management protocols. MIKEY is a 419 part of this architecture, and can be used as a so-called 420 Registration protocol. The main entities involved in the architecture 421 are the group controller/key server (GCKS), the receiver(s), and the 422 sender(s). 424 In MIKEY, the sender could act as GCKS and push down keys to the 425 receiver(s). 427 Note that e.g., in a SIP-initiated call, the sender may also be a 428 receiver. As MIKEY addresses small interactive groups, a member may 429 dynamically change between being a sender and receiver (or being both 430 simultaneously). 432 3. Basic Key Transport and Exchange Methods 434 The following sub-sections define three different methods to 435 transport/establish a TGK: with the use of a pre-shared key, public- 436 key encryption, and Diffie-Hellman (DH) key exchange. In the 437 following we for simplicity assume unicast communication. In addition 438 to the TGK, a random "nonce", denoted RAND, is also transported. In 439 all three cases, the TGK and RAND values are then used to derive TEKs 440 as described in Section 4.1.3. A timestamp is also sent, to avoid 441 replay attacks (see Section 5.4). 443 The pre-shared key method and the public-key method are both based on 444 key transport mechanisms, where the actual TGK is pushed (securely) 445 to the recipient(s). In the Diffie-Hellman method, the actual TGK is 446 instead derived from the Diffie-Hellman values exchanged between the 447 peers. 449 The pre-shared case is, by far, the most efficient way to handle the 450 key transport due to the use of symmetric cryptography only. This 451 approach has also the advantage that only a small amount of data has 452 to be exchanged. Of course, the problematic issue is scalability as 453 it is not always feasible to share individual keys with a large group 454 of peers. Therefore, this case mainly addresses scenarios such as 455 server-to-client and also those cases where the public-key modes have 456 already been used thus allowing to "cache" a symmetric key (see below 457 and Section 3.2). 459 Public-key cryptography can be used to create a scalable system. A 460 disadvantage with this approach is that it is more resource consuming 461 than the pre-shared key approach. Another disadvantage is that in 462 most cases a PKI (Public Key Infrastructure) is needed to handle the 463 distribution of public keys. Of course, it is possible to use public 464 keys as pre-shared keys (e.g. by using self-signed certificates). It 465 should also be noted that, as mentioned above, this method may be 466 used to establish a "cached" symmetric key that later can be used to 467 establish subsequent TGKs by using the pre-shared key method (hence, 468 the subsequent request can be executed more efficiently). 470 The Diffie-Hellman (DH) key agreement method has in general a higher 471 resource consumption (both computationally and in bandwidth) than the 472 previous ones, and needs certificates as the public-key case. 473 However, it has the advantage of providing perfect forward secrecy 474 (PFS) and flexibility by allowing implementation in several different 475 finite groups. 477 Note that by using the DH method, the two involved parties will 478 generate a unique unpredictable random key. Therefore, it is not 479 possible to use this DH method to establish a group TEK (as the 480 different parties in the group would end up with different TEKs). It 481 is not the intention of the DH method to work in this scenario, but 482 to be a good alternative in the special peer-to-peer case. 484 The following general notation is used: 486 HDR: The general MIKEY header, which includes MIKEY CSB related data 487 (e.g. CSB ID) and information mapping to the specific security 488 protocol used. See Section 6.1 for payload definition. 490 T: The timestamp, used mainly to prevent replay attacks. See 491 Section 6.6 for payload definition and also Section 5.4 for other 492 timestamp related information. 494 IDx: The identity of entity x (i=Initiator, r=Responder). See 495 Section 6.7 for payload definition. 497 RAND: Random/pseudo-random byte-string, which is always included in 498 the first message from the Initiator. RAND is used as freshness value 499 for the key generation. It is not included in update messages of a 500 CSB. See Section 6.11 for payload definition. For randomness 501 recommendations for security, see [RAND]. 503 SP: The security policies for the data security protocol. See 504 Section 6.10 for payload definition. 506 3.1. Pre-shared key 508 In this method, the pre-shared secret key, s, is used to derive key 509 material for both the encryption (encr_key) and the integrity 510 protection (auth_key) of the MIKEY messages, as described in Section 511 4.1.4. The encryption and authentication transforms are described in 512 Section 4.2. 514 Initiator Responder 516 I_MESSAGE = 517 HDR, T, RAND, [IDi], 518 {SP}, KEMAC ---> 519 R_MESSAGE = 520 [<---] HDR, T, [IDr], V 522 The main objective of the Initiator's message (I_MESSAGE) is to 523 transport one or more TGKs (carried into KEMAC) and a set of security 524 parameters (SPs) to the Responder in a secure manner. As the 525 verification message from the Responder is optional, the Initiator 526 indicates in the HDR whether it requires a verification message or 527 not from the Responder. 529 KEMAC = E(encr_key, {TGK}) || MAC 531 The KEMAC payload contains a set of encrypted sub-payloads and a MAC. 532 Each sub-payload includes a, by the Initiator, randomly and 533 independently chosen TGK (and possible other related parameters, 534 e.g., the key lifetime). The MAC is a Message Authentication Code 535 covering the entire MIKEY message using the authentication key, 536 auth_key. See Section 6.2 for payload definition and Section 5.2 for 537 exact definition of the MAC calculation. 539 The main objective of the verification message from the Responder is 540 to obtain mutual authentication. The verification message, V, is a 541 MAC computed over the Responder's entire message, the timestamp (the 542 same as the one that was included in the Initiator's message), and 543 the two parties identities, using the authentication key. See also 544 Section 5.2 for the exact definition of the Verification MAC 545 calculation and Section 6.9 for payload definition. 547 The ID fields SHOULD be included, but they MAY be left out when it 548 can be expected that the peer already knows the other party's ID 549 (otherwise it cannot look up the pre-shared key). This could e.g. be 550 the case if the ID is extracted from SIP. 552 This method is MANDATORY to implement. 554 3.2. Public-key encryption 556 Initiator Responder 558 I_MESSAGE = 559 HDR, T, RAND, [IDi|CERTi], {SP}, 560 KEMAC, [CHASH], PKE, SIGNi ---> 561 R_MESSAGE = 562 [<---] HDR, T, [IDr], V 564 As in the previous case, the main objective of the Initiator's 565 message is to transport one or more TGKs and a set of security 566 parameters to the Responder in a secure manner. This is done using an 567 envelope approach where the TGKs are encrypted (and integrity 568 protected) with keys derived from a randomly/pseudo-randomly chosen 569 "envelope key". The envelope key is sent to the Responder encrypted 570 with the public key of the Responder. 572 The PKE contains the encrypted envelope key: PKE = E(PKr, env_key). 573 It is encrypted using the Responder's public key (PKr). If the 574 Responder posses several public keys, the Initiator can indicate the 575 key used in the CHASH payload (see Section 6.8). 577 The KEMAC contains a set of encrypted sub-payloads and a MAC: 579 KEMAC = E(encr_key, IDi || {TGK}) || MAC 581 The first payload (IDi) in KEMAC is the identity of the Initiator 582 (not a certificate, but generally the same ID as the one specified in 583 the certificate). Each of the following payloads (TGK) includes a, by 584 the Initiator, randomly and independently chosen TGK (and possible 585 other related parameters, e.g., the key lifetime). The encrypted part 586 is then followed by a MAC, which is calculated over the KEMAC 587 payload. The encr_key and the auth_key are derived from the envelope 588 key, env_key, as specified in Section 4.1.4. See also Section 6.2 for 589 payload definition. 591 The SIGNi is a signature covering the entire MIKEY message, using the 592 Initiator's signature key (see also Section 5.2 for the exact 593 definition). 595 The main objective of the verification message from the Responder is 596 to obtain mutual authentication. As the verification message V from 597 the Responder is optional, the Initiator indicates in the HDR whether 598 it requires a verification message or not from the Responder. V is 599 calculated in the same way as in the pre-shared key mode (see also 600 Section 5.2 for the exact definition). See Section 6.9 for payload 601 definition. 603 Note that there will be one encrypted IDi and possibly also one 604 unencrypted IDi. The encrypted one is together with the MAC used as a 605 countermeasure for certain man-in-the-middle attacks, while the 606 unencrypted is always useful for the Responder to immediately 607 identify the Initiator. The encrypted IDi MUST always be verified to 608 be equal with the expected IDi. 610 It is possible to cache the envelope key, so that it can be used as a 611 pre-shared key. It is not recommended to cache this key indefinitely 612 (however it is up to the local policy to decide this). This function 613 may be very convenient during the lifetime of a CSB, if a new crypto 614 session needs to be added (or an expired one removed). Then, the pre- 615 shared key can be used, instead of the public keys (see also Section 616 4.5). If the Initiator indicates that the envelope key should be 617 cached, the key is at least to be cached during the lifetime of the 618 entire CSB. 620 The cleartext ID fields and certificate SHOULD be included, but they 621 MAY be left out when it can be expected that the peer already knows 622 the other party's ID, or can obtain the certificate in some other 623 manner. This could e.g. be the case if the ID is extracted from SIP. 625 For certificate handling, authorization and policies, see Section 626 4.3. 628 This method is MANDATORY to implement. 630 3.3. Diffie-Hellman key exchange 632 For a fixed, agreed upon, cyclic group, (G,*), we let g denote a 633 generator for this group. Choices for the parameters are given in 634 Section 4.2.7. The other transforms below are described in Section 635 4.2. 637 This method creates a DH-key, which is used as the TGK. This method 638 cannot be used to create group keys, only be used to create single 639 peer-to-peer keys. This method is OPTIONAL to implement. 641 Initiator Responder 643 I_MESSAGE = 644 HDR, T, RAND, [IDi|CERTi], 645 {SP}, DHi, SIGNi ---> 646 R_MESSAGE = 647 <--- HDR, T, [IDr|CERTr], IDi, 648 DHr, DHi, SIGNr 650 The main objective of the Initiator's message is to, in a secure way, 651 provide the Responder with its DH value (DHi) g^(xi), where xi MUST 652 be randomly/pseudo-randomly and secretly chosen, and a set of 653 security protocol parameters. 655 The SIGNi is a signature covering the Initiator's MIKEY message, 656 I_MESSAGE, using the Initiator's signature key (see Section 5.2 for 657 the exact definition). 659 The main objective of the Responder's message is to, in a secure way, 660 provide the Initiator with the Responder's value (DHr) g^(xr), where 661 xr MUST be randomly/pseudo-randomly and secretly chosen. The 662 timestamp that is included in the answer is the same as the one 663 included in the Initiator's message. 665 The SIGNr is a signature covering the Responder's MIKEY message, 666 R_MESSAGE, using the Responder's signature key (see Section 5.2 for 667 the exact definition). 669 The DH group parameters (e.g., the group G, the generator g, etc) are 670 chosen by the Initiator and signaled to the Responder. Both parties 671 calculate the TGK, g^(xi*xr) from the exchanged DH-values. 673 Note that this approach does not require that the Initiator has to 674 posses any of the Responder's certificates before the setup. Instead, 675 it is sufficient that the Responder includes its signing certificate 676 in the response. 678 The ID fields and certificate SHOULD be included, but they MAY be 679 left out when it can be expected that the peer already knows the 680 other party's ID (or can obtain the certificate in some other 681 manner). This could e.g. be the case if the ID is extracted from SIP. 683 For certificate handling, authorization and policies, see 684 Section 4.3. 686 4. Selected Key Management Functions 688 MIKEY manages symmetric keys in two main ways. Firstly, following key 689 transport or key exchange of TGK(s) (and other parameters) as defined 690 by any of the above three methods, MIKEY maintains a mapping between 691 Data SA identifiers and Data SAs, where the identifiers used depend 692 on the security protocol in question, see Section 4.4. Thus, when the 693 security protocol requests a Data SA, given such a Data SA 694 identifier, an up-to-date Data SA will be obtained. In particular, 695 correct keying material, TEK(s), might need to be derived. The 696 derivation of TEK(s) (and other keying material) is done from a TGK 697 and is described in Section 4.1.3. 699 Secondly, for use within MIKEY itself, two key management procedures 700 are needed: 702 * in the pre-shared case, deriving encryption and authentication key 703 material from a single pre-shared key, and 705 * in the public key case, deriving similar key material from the 706 transported envelope key. 708 These two key derivation methods are specified in section 4.1.4. 710 All the key derivation functionality mentioned above is based on a 711 pseudo-random function, defined next. 713 4.1. Key Calculation 715 We define in the following a general method (pseudo-random function) 716 to derive one or more keys from a "master" key. This method is used 717 to derive: 719 * TEKs from a TGK and the RAND value, 721 * encryption, authentication, or salting key from a pre-shared/ 722 envelope key and the RAND value. 724 4.1.1. Assumptions 726 We assume that the following parameters are in place: 728 csb_id : Crypto Session Bundle ID (32-bits unsigned integer) 729 cs_id : the Crypto Session ID (8-bits unsigned integer) 730 RAND : an (at least) 128-bit (pseudo-)random bit-string sent by the 731 Initiator in the initial exchange. 733 The key derivation method has the following input parameters: 735 inkey : the input key to the derivation function 736 inkey_len : the length in bits of the input key 737 label : a specific label, dependent on the type of the key to be 738 derived, the RAND, and the session IDs 739 outkey_len: desired length in bits of the output key. 741 The key derivation method has the following output: 743 outkey: the output key of desired length. 745 4.1.2. Default PRF Description 747 Let HMAC be the SHA-1 based message authentication function, see 748 [HMAC], [SHA-1]. Similar to [TLS], define: 750 P (s, label, m) = HMAC (s, A_1 || label) || 751 HMAC (s, A_2 || label) || ... 752 HMAC (s, A_m || label) 753 where 755 A_0 = label, 756 A_i = HMAC (s, A_(i-1)) 757 s is the input key 758 m is a positive integer. 760 Values of label depend on the case in which the PRF is invoked, and 761 values are specified in the following for the default PRF. Thus, note 762 that other PRFs later added to MIKEY MAY specify different input 763 parameters. 765 The following procedure describes a pseudo-random function, denoted 766 PRF(inkey,label), based on the above P-function, applied to compute 767 the output key, outkey: 769 * let n = inkey_len / 512, rounded up to the nearest integer if not 770 already an integer 771 * split the inkey into n blocks, inkey = s_1 || ... || s_n, where all 772 s_i, except possibly s_n, are 512 bits each 773 * let m = outkey_len / 160, rounded up to the nearest integer if not 774 already an integer 776 (The values "512" and "160" equals the input block-size and output 777 hash size, respectively, of the SHA-1 hash as part of the P- 778 function.) 780 Then, the output key, outkey, is obtained as the outkey_len most 781 significant bits of 783 PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ... 784 XOR P(s_n, label, m). 786 4.1.3. Generating keys from TGK 788 In the following, we describe how keying material is derived from a 789 TGK, thus assuming that mapping of Data SA identifier to the correct 790 TGK has already been done according to Section 4.4. 792 The key derivation method SHALL be executed using the above PRF with 793 the following input parameters: 795 inkey : TGK 796 inkey_len : bit length of TGK 797 label : constant || cs_id || csb_id || RAND 798 outkey_len : bit length of the output key. 800 The constant part of label depends on the type of key that is to be 801 generated. The constant 0x2AD01C64 is used to generate a TEK from 802 TGK. If the security protocol itself does not support key derivation 803 for authentication and encryption from the TEK, separate 804 authentication and encryption keys MAY be created directly for the 805 security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and 806 0x15798CEF respectively, and outkey_len by the desired key-length(s) 807 in each case. 809 A salt key can be derived from the TGK as well, by using the constant 810 0x39A2C14B. Note that the Key data sub-payload (Section 6.13) can 811 carry a salt. The security protocol in need of the salt key, SHALL 812 use the salt key carried in the Key data sub-payload (in the pre- 813 shared and public-key case), when present. If that is not sent, then 814 it is possible to derive the salt key via the key derivation 815 function, as described above. 817 The table below summarizes the values of constant, used to generate 818 keys from a TGK. 820 constant | derived key from the TGK 821 -------------------------------------- 822 0x2AD01C64 | TEK 823 0x1B5C7973 | authentication key 824 0x15798CEF | encryption key 825 0x39A2C14B | salting key 826 Table 4.1.3: Values of constant for the derivation of keys from TGK. 828 Note that these 32-bit constant values (listed in the table above) 829 are taken from the decimal digits of e (i.e. 2.7182...), and where 830 each constant consist of nine decimals digits (e.g. the first nine 831 decimal digits 718281828 = 0x2AD01C64). The strings of nine decimal 832 digits are not chosen at random, but as consecutive "chunks" from the 833 decimal digits of e. 835 4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared 836 key 838 This derivation is to form the symmetric encryption key (and salting 839 key) for the encryption of the TGK in the pre-shared key and public 840 key methods. This is also used to derive the symmetric key used for 841 the message authentication code in these messages, and the 842 corresponding verification messages. Hence, this derivation is needed 843 in order to get different keys for the encryption and the MAC (and in 844 the case of the pre-shared key, it will result in fresh key material 845 for each new CSB). The parameters for the default PRF are here: 847 inkey : the envelope key or the pre-shared key 848 inkey_len : the bit length of inkey 849 label : constant || 0xFF || csb_id || RAND 851 outkey_len : desired bit length of the output key. 853 The constant part of label depends on the type of key that is to be 854 generated from an envelope/pre-shared key, as summarized below. 856 constant | derived key 857 -------------------------------------- 858 0x150533E1 | encryption key 859 0x2D22AC75 | authentication key 860 0x29B88916 | salt key 862 Table 4.1.4: Values of constant for the derivation of keys from an 863 envelope/pre-shared key. 865 4.2 Pre-defined Transforms and Timestamp Formats 867 This section identifies standard transforms for MIKEY. The following 868 transforms are mandatory to implement and support in the respective 869 case. New transforms can be added in the future (see Section 4.2.9 870 for further guidelines). 872 4.2.1 Hash functions 874 In MIKEY, SHA-1 is the default hash function that is MANDATORY to 875 implement. 877 4.2.2 Pseudo-random number generator and PRF 879 A cryptographically secure random or pseudo-random number generator 880 MUST be used for the generation of the keying material and nonces, 881 e.g. [BMGL]. However, it is implementation specific which one to use 882 (as the choice will not affect the interoperability). 884 For the key derivations, the PRF specified in Section 4.1, is 885 MANDATORY to implement. Other PRFs MAY be added by writing standard- 886 track RFCs specifying the PRF constructions and their exact use 887 within MIKEY. 889 4.2.3 Key data transport encryption 891 The default and mandatory-to-implement key transport encryption is 892 AES in counter mode, as defined in [SRTP], using a 128-bit key as 893 derived in Section 4.1.4, and using initialization vector 895 IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000, 897 where S is a 112-bit salting key, also derived as in Section 4.1.4, 898 and where T is the 64-bit timestamp sent by the Initiator. 900 Note: this restricts the maximum size that can be encrypted to 2^23 901 bits, which is still enough for all practical purposes [SRTP]. 903 The NULL encryption algorithm (i.e., no encryption) can be used (but 904 is OPTIONAL to implement). Note that this MUST NOT be used unless the 905 underlying protocols can guarantee the security. The main reason for 906 including this is for certain specific SIP scenarios, where SDP is 907 protected end-to-end. For this scenario, MIKEY MAY be used with the 908 pre-shared key method and the NULL encryption and NULL authentication 909 algorithm (see Section 4.2.4) while relying on the security of SIP. 910 Use this option with caution! 912 The AES key wrap function [AESKW] is included as an OPTIONAL to 913 implement method. If the key wrap function is used in the public key 914 method, the NULL MAC is RECOMMENDED as the key wrap itself will 915 provide integrity of the encrypted content (note though that the NULL 916 MAC SHOULD NOT be used in the pre-shared key case, as the MAC in that 917 case covers the entire message). The 128-bit key and a 64-bit salt, 918 S, are derived in accordance to Section 4.1.4 and the key wrap IV is 919 then set to S. 921 4.2.4 MAC and Verification Message function 923 MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 924 as the MANDATORY to implement method, see [HMAC]. Authentication keys 925 are derived according to Section 4.1.4. Note that the authentication 926 key size SHOULD be equal to the size of the hash function's output 927 (e.g. for HMAC-SHA-1, a 160-bit authentication key is used) [HMAC]. 929 The NULL authentication algorithm (i.e., no MAC) can be used together 930 with the NULL encryption algorithm (but is OPTIONAL to implement). 931 Note that this MUST NOT be used unless the underlying protocols can 932 guarantee the security. The main reason for including this is for 933 certain specific SIP scenarios, where SDP is protected end-to-end. 934 For this scenario, MIKEY MAY be used with the pre-shared key method 935 and the NULL encryption and authentication algorithm while relying on 936 the security of SIP. Use this option with caution! 938 4.2.5 Envelope Key encryption 940 The public key encryption algorithm applied is defined by, and 941 dependent on the certificate used. It is MANDATORY to support RSA 942 PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS]. 944 4.2.6 Digital Signatures 946 The signature algorithm applied is defined by, and dependent on the 947 certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it 948 is RECOMMENDED to also support RSA PSS [PSS]. 950 4.2.7 Diffie-Hellman Groups 952 The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory 953 to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are 954 OPTIONAL to implement). 956 See Section 4.2.9 for the guidelines to specify a new DH Group to be 957 used within MIKEY. 959 4.2.8. Timestamps 961 The timestamp is as defined in NTP [NTP], i.e. a 64-bit number in 962 seconds relative to 0h on 1 January 1900. An implementation MUST be 963 aware of (and take into account) the fact that the counter will 964 overflow approximately every 136th year. It is RECOMMENDED that the 965 time is always specified in UTC. 967 4.2.9. Adding new parameters to MIKEY 969 There are two different parameter sets that can be added to MIKEY. 970 The first is a set of MIKEY transforms (needed for the exchange 971 itself), and the second is the Data SAs. 973 New transforms and parameters (including new policies) SHALL be added 974 by registering with IANA (according to [RFC2434], see also Section 975 10) a new number for the concerned payload, and also if necessary, 976 document how the new transform/parameter is used. Sometimes it might 977 be enough to point to an already specified document for the usage, 978 e.g., when adding a new already standardized hash function. 980 In the case of adding a new DH group, the group MUST be specified in 981 a companion standard-track RFC (it is RECOMMENDED that the specified 982 group uses the same format as used in [OAKLEY]). A number can then be 983 assigned by IANA for such a group to be used in MIKEY. 985 When adding support for a new data security protocol, the following 986 MUST be specified: 988 * A map sub-payload (see Section 6.1). This is used to be able to map 989 a crypto session to the right instance of the data security protocol 990 and possibly also to provide individual parameters for each data 991 security protocol. 993 * A policy payload, i.e., specification of parameters and supported 994 values. 996 * General guidelines of usage. 998 4.3. Certificates, Policies and Authorization 1000 4.3.1. Certificate handling 1002 Certificate handling may involve a number of additional tasks not 1003 shown here, and effect the inclusion of certain parts of the message 1004 (c.f. [X.509]). The following observations can, however, be made: 1006 * The Initiator typically has to find the certificate of the 1007 Responder in order to send the first message. If the Initiator 1008 does not have the Responder's certificate already, this may 1009 involve one or more roundtrips to a central directory agent. 1011 * It will be possible for the Initiator to omit its own certificate 1012 and rely on the Responder getting this certificate using other 1013 means. However, we recommend doing this, only when it is 1014 reasonable to expect that the Responder has cached the certificate 1015 from a previous connection. Otherwise accessing the certificate 1016 would mean additional roundtrips for the Responder as well. 1018 * Verification of the certificates using Certificate Revocation Lists 1019 (CRLs) [X.509] or protocols such as OCSP [OCSP] may be necessary. 1020 All parties in a MIKEY exchange should have a local policy which 1021 dictates whether such checks are made, how they are made, and how 1022 often they are made. Note that performing the checks may imply 1023 additional messaging. 1025 4.3.2. Authorization 1027 In general, there are two different models for making authorization 1028 decisions for both the Initiator and the Responder, in the context of 1029 the applications targeted by MIKEY: 1031 * Specific peer-peer configuration. The user has configured the 1032 application to trust a specific peer. 1034 When pre-shared secrets are used, this is pretty much the only 1035 available scheme. Typically, the configuration/entering of the 1036 pre-shared secret is taken to mean that authorization is implied. 1038 In some cases one could use this also with public keys, e.g. if 1039 two peers exchange keys offline and configure them to be used for 1040 the purpose of running MIKEY. 1042 * Trusted root. The user accepts all peers that can prove to have a 1043 certificate issued by a specific CA. The granularity of 1044 authorization decisions is not very precise in this method. 1046 In order to make this method possible, all participants in the 1047 MIKEY protocol need to configure one or more trusted roots. The 1048 participants also need to be capable of performing certificate 1049 chain validation, and possibly transfer more than a single 1050 certificate in the MIKEY messages (see also Section 6.7). 1052 In practice, a combination of both mentioned methods might be 1053 advantageous. Also, the possibility for a user to explicitly exclude 1054 a specific peer (or sub tree) in a trust chain might be needed. 1056 These authorization policies address the MIKEY scenarios a-c of 1057 Section 2.1, where the Initiator acts as the group owner and who is 1058 also the only one that can invite others. This implies that for each 1059 Responder, the distributed keys MUST NOT be re-distributed to other 1060 parties. 1062 In a many-to-many situation, where the group control functions are 1063 distributed (and/or where it is possible to delegate the group 1064 control function to others), there MUST exist means to distribute 1065 authorization information about who may be added to the group. 1066 However, it is out of scope for this document to specify how this 1067 should be done. 1069 For any broader communication situation, an external authorization 1070 infrastructure may be used (following the assumptions of [GKMARCH]). 1072 4.3.3. Data Policies 1074 Included in the message exchange, policies (i.e., security 1075 parameters) for the Data security protocol are transmitted. The 1076 policies are defined in a separate payload and are specific to the 1077 security protocol (see also Section 6.10). Together with the keys, 1078 the validity period of these can also be specified. This can be done 1079 e.g., with an SPI (or SRTP MKI) or with an Interval (e.g. a sequence 1080 number interval for SRTP), depending on the security protocol. 1082 New parameters can be added to a policy by documenting how they 1083 should be interpreted by MIKEY and also by registering new values in 1084 the appropriate name space in IANA. If a completely new policy is 1085 needed, see Section 4.2.9 for guidelines. 1087 4.4. Retrieving the Data SA 1089 The retrieval of a Data SA will depend on the security protocol, as 1090 different security protocols will have different characteristics. 1091 When adding support for a security protocol to MIKEY, some interface 1092 of how the security protocol retrieves the Data SA from MIKEY MUST be 1093 specified (together with policies that can be negotiated etc.). 1095 For SRTP the SSRC (see [SRTP]) is one of the parameters used to 1096 retrieve the Data SA (and e.g. the MKI may be used to indicate the 1097 TGK/TEK used for the Data SA). However, the SSRC is not sufficient. 1098 For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that 1099 the MIKEY implementation support a lookup using destination network 1100 address and port together with SSRC. Note that MIKEY does not send 1101 network addresses or ports. One reason for this is that they may not 1102 be known in advance, as well as if a NAT exists in-between, problems 1103 may arise. When SIP or RTSP is used, the local view of the 1104 destination address and port can be obtained from either SIP or RTSP. 1105 MIKEY can then use these addresses as the index for the Data SA 1106 lookup. 1108 4.5. TGK re-keying and CSB updating 1110 MIKEY provides the means to update the CSB (e.g. transporting a new 1111 TGK/TEK or adding a new Crypto Session to the CSB). The updating of 1112 the CSB is done by executing MIKEY again e.g. before a TEK expires, 1113 or when a new Crypto Session is added to the CSB. Note that MIKEY 1114 does not provide re-keying in the GKMARCH sense, only updating of the 1115 keys by normal unicast messages. 1117 When MIKEY is executed again to update the CSB, it is not necessary 1118 to include certificates and other information that was provided in 1119 the first exchange, i.e. all payloads that are static or optional to 1120 include may be left out (see Figure 4.1). 1122 The new message exchange MUST use the same CSB ID as the initial 1123 exchange, but MUST use a new timestamp. A new RAND MUST NOT be 1124 included in the message exchange (the RAND will only have effect in 1125 the Initial exchange). New Crypto Sessions are added if desired in 1126 the update message. Note that a MIKEY update message does not need to 1127 contain new keying material (i.e., new TGK). In this case the crypto 1128 session continues to use the previously established keying material, 1129 while updating the new information. 1131 As explained in Section 3.2, the envelope key can be "cached" as a 1132 pre-shared key (this is indicated by the Initiator in the first 1133 message sent). If so, the update message is a pre-shared key message 1134 (with the cached envelope key as the pre-shared key), i.e., it MUST 1135 NOT be a public key message. If the public key message is used, but 1136 the envelope key is not cached, the Initiator MUST provide a new 1137 encrypted envelope key that can be used in the verification message. 1138 However, the Initiator does not need to provide any other keys. 1140 Figure 4.1 visualizes the update messages that can be sent, including 1141 the optional parts. The big difference from the original message is 1142 mainly that it is optional to include TGKs (or DH values in the DH 1143 method). See also Section 3 for more details of the specific methods. 1145 By definition, a CSB can contain several CSs. A problem that then 1146 might occur is to synchronize the TGK re-keying if an SPI (or similar 1147 functionality, e.g., MKI in [SRTP]) is not used. It is therefore 1148 RECOMMENDED that an SPI or MKI is used, if more than one CS is used. 1150 Initiator Responder 1152 Pre-shared key method: 1154 I_MESSAGE = 1155 HDR, T, [IDi], {SP}, KEMAC ---> 1156 R_MESSAGE = 1157 [<---] HDR, T, [IDr], V 1159 Public key method: 1161 I_MESSAGE = 1162 HDR, T, [IDi|CERTi], {SP}, [KEMAC], 1163 [CHASH], PKE, SIGNi ---> 1164 R_MESSAGE = 1165 [<---] HDR, T, [IDr], V 1167 DH method: 1169 I_MESSAGE = 1170 HDR, T, [IDi|CERTi], {SP}, 1171 [DHi], SIGNi ---> 1172 R_MESSAGE = 1173 <--- HDR, T, [IDr|CERTr], IDi, 1174 [DHr, DHi], SIGNr 1176 Figure 4.1: Update messages. 1178 Note that for the DH method, if the Initiator includes the DHi 1179 payload, then the Responder MUST include DHr and DHi. If the 1180 Initiator does not include DHi, the Responder MUST NOT include DHr, 1181 DHi. 1183 5. Behavior and message handling 1185 Each message that is sent by the Initiator or the Responder is built 1186 by a set of payloads. This section describes how messages are created 1187 and also when they can be used. 1189 5.1. General 1191 5.1.1. Capability Discovery 1193 The Initiator indicates the security policy to use (i.e. in terms of 1194 security protocol algorithms etc). If the Responder does not support 1195 it (for some reason), the Responder can together with an error 1196 message (indicating that it does not support the parameters), send 1197 back its own capabilities (negotiation) to let the Initiator choose a 1198 common set of parameters. This is done by including one or more 1199 security policy payloads in the error message sent in answer (see 1200 Section 5.1.2.). Multiple attributes can be provided in sequence in 1201 the response. This is done to reduce the number of roundtrips as much 1202 as possible (i.e. in most cases, where the policy is accepted the 1203 first time, one roundtrip is enough). If the Responder does not 1204 accept the offer, the Initiator must go out with a new MIKEY message. 1206 If the Responder is not willing/capable to provide security or the 1207 parties simply cannot agree, it is up to the parties' policies how to 1208 behave, i.e. accept an insecure communication or reject it. 1210 Note that it is not the intention of this protocol to have a very 1211 broad variety of options, as it is assumed that it should not be too 1212 common that an offer is denied. 1214 In the one-to-many and many-to-many scenarios using multicast 1215 communication, one issue is of course that there MUST be a common 1216 security policy to all the receivers. This limits the possibility for 1217 negotiation. 1219 5.1.2. Error Handling 1221 All errors due to the key management protocol SHOULD be reported to 1222 the peer(s) by an error message. The Initiator SHOULD therefore 1223 always be prepared to receive such message from the Responder. 1225 If the Responder does not support the set of parameters suggested by 1226 the Initiator, the error message SHOULD include the supported 1227 parameters (see also Section 5.1.1). 1229 The error message is formed as: 1231 HDR, T, {ERR}, {SP}, [V|SIGNr] 1233 Note that if the failure is due to the inability to authenticate the 1234 peer, the error message is OPTIONAL, and does not need to be 1235 authenticated. It is up to the local policy how to treat this kind of 1236 messages. However, if a signed error message in response to a failed 1237 authentication is returned this can be used for DoS purposes (against 1238 the Responder). Similarly, an unauthenticated error message could be 1239 sent to the Initiator in order to fool her to tear down the CSB. It 1240 is highly RECOMMENDED that the local policy takes this into 1241 consideration. Therefore, in case of authentication failure, one 1242 advice would be not to authenticate such an error message, and when 1243 receiving an unauthenticated error message only see it as a 1244 recommendation of what may have gone wrong. 1246 5.2. Creating a message 1248 To create a MIKEY message, a Common Header payload is first created. 1249 This payload is then followed, depending on the message type, by a 1250 set of information payloads (e.g. DH-value payload, Signature 1251 payload, Security Policy payload). The defined payloads and the exact 1252 encoding of each payload are described in Section 6. 1254 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 ! version ! data type ! next payload ! ! 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + 1259 ~ Common Header... ~ 1260 ! ! 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 ! next payload ! Payload 1 ... ! 1263 +-+-+-+-+-+-+-+-+ + 1264 ~ ~ 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 : : : 1267 : : : 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 ! next payload ! Payload x ... ! 1270 +-+-+-+-+-+-+-+-+ + 1271 ~ ~ 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 ! MAC/Signature ~ 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 Figure 5.1. MIKEY payload message example. Note that the payloads are 1277 byte aligned and not 32-bit aligned. 1279 The process of generating a MIKEY message consists of the following 1280 steps: 1282 * Create an initial MIKEY message starting with the Common Header 1283 payload. 1285 * Concatenate necessary payloads to the MIKEY message (see the 1286 exchange definitions for payloads that may be included, and 1287 recommended order). 1289 * As a last step (for messages that must be authenticated, this also 1290 include the verification message), create and concatenate the 1291 MAC/signature payload without the MAC/signature field filled in (if a 1292 Next payload field is included in this payload, it is set to Last 1293 payload). 1295 * Calculate the MAC/signature over the entire MIKEY message, except 1296 the MAC/Signature field, and add the MAC/signature in the field. In 1297 the case of the verification message, the Identity_i || Identity_r || 1298 Timestamp MUST follow directly after the MIKEY message in the 1299 Verification MAC calculation. Note that the identities and the 1300 timestamp that are added are identical to those transported in the ID 1301 and T payloads. 1303 In the public key case, the Key data transport payload is generated 1304 by concatenating the IDi with the TGKs. This is then encrypted and 1305 placed in the data field. The MAC is calculated over the entire Key 1306 data transport payload except the MAC field. Before calculating the 1307 MAC, the Next payload field is set to zero. 1309 Note that all messages from the Initiator MUST use a unique 1310 timestamp. The Responder does not create a new timestamp, but uses 1311 the timestamp used by the Initiator. 1313 5.3. Parsing a message 1315 In general, parsing of a MIKEY message is done by extracting payload 1316 by payload and checking that no errors occur. The exact procedure is 1317 implementation specific; however, for the Responder, it is 1318 RECOMMENDED that the following procedure is followed: 1320 * Extract the Timestamp and check that it is within the allowable 1321 clock skew (if not, discard the message). Also check the replay cache 1322 (Section 5.4) so that the message is not replayed (see also Section 1323 5.4). If the message is replayed, discard it. 1325 * Extract ID and authentication algorithm (if not included, assume 1326 the default one). 1328 * Verify the MAC/signature. 1330 * If the authentication is not successful, an Auth failure Error 1331 message MAY be sent to the Initiator. The message is then discarded 1332 from further processing. See also Section 5.1.2 for treatment of 1333 errors. 1335 * If the authentication is successful, the message is processed and 1336 also added to the replay cache. How it is processed is implementation 1337 specific. Note also that it is only successfully authenticated 1338 messages that are stored in the replay cache. 1340 * If any unsupported parameters or errors occur during the 1341 processing, these MAY be reported to the Initiator by sending an 1342 error message. The processing is then aborted. The error message can 1343 also include payloads to describe the supported parameters. 1345 * If the processing was successful and in case the Initiator 1346 requested it, a verification/ response message MAY be created and 1347 sent to the Initiator. 1349 5.4. Replay handling and timestamp usage 1351 MIKEY does not use a challenge-response mechanism for replay 1352 handling; instead timestamps are used. This requires that the clocks 1353 are synchronized. The required synchronization is dependent on the 1354 number of messages that can be cached (note though, that the replay 1355 cache only contain messages that have been successfully 1356 authenticated). If we could assume an unlimited cache, the terminals 1357 would not need to be synchronized at all (as the cache could then 1358 contain all previous messages). However, if there are restrictions on 1359 the size of the replay cache, the clocks will need to be synchronized 1360 to some extent. In short, one can in general say that it is a 1361 tradeoff between the size of the replay cache and the required 1362 synchronization. 1364 Timestamp usage prevents against replay attacks under the following 1365 assumptions: 1367 * Each host has a clock which is at least "loosely synchronized" to 1368 the clocks of the other hosts. 1370 * If the clocks are to be synchronized over the network, a secure 1371 network clock synchronization protocol SHOULD be used, e.g. [ISO3]. 1373 * Each Responder utilizes a replay cache in order to remember the 1374 successfully authenticated messages presented within an allowable 1375 clock skew (which is set by the local policy). 1377 * Replayed and outdated messages, i.e., messages that can be found in 1378 the replay cache or which have an outdated timestamp, are discarded 1379 and not processed. 1381 * If the host loses track of the incoming requests (e.g. due to 1382 overload), it rejects all incoming requests until the clock skew 1383 interval has passed. 1385 In a client-server scenario, servers may encounter high workload, 1386 especially if a replay cache is needed. However, servers that assume 1387 the role of Initiators of MIKEY will not need to manage any 1388 significant replay cache as they will refuse all incoming messages 1389 that are not a response to a message previously sent by the server. 1391 In general, a client may not expect a very high load of incoming 1392 messages and may therefore allow the degree of looseness to be on the 1393 order of several minutes to hours. If a (D)DoS attack is launched and 1394 the replay cache grows too large, MIKEY MAY dynamically decrease the 1395 looseness so that the replay cache becomes manageable. However, note 1396 that such (D)DoS can only be performed by peers that can authenticate 1397 themselves (hence, such attack is very easy to trace and mitigate). 1399 The maximum number of messages that a client will need to cache may 1400 vary depending on the capacity of the client itself and the network, 1401 but also the number of expected messages should be taken into 1402 account. 1404 For example, assume that we can at most spend 6kB on a replay cache. 1405 Assume further that we need to store 30 bytes for each incoming 1406 authenticated message (the hash of the message is 20 bytes). This 1407 implies that it is possible to cache approximately 204 messages. If 1408 the expected number of messages per minute can be estimated, the 1409 clock skew can easily be calculated. E.g., in a SIP scenario where 1410 the client is expected in the most extreme case to receive 10 calls 1411 per minute, the clock skew needed is then approximately 20 minutes. 1412 In a not so extreme setting, where one could expect an incoming call 1413 every 5th minute, this would result in a clock skew on the order of 1414 16.5 hours (approx 1000 minutes). 1416 Consider a very extreme case, where the maximum number of incoming 1417 messages are assumed to be on the order of 120 messages per minute, 1418 and a requirement that the clock skew is on the order of 10 minutes, 1419 a 48kB replay cache would be required. 1421 Hence, one can note that the required clock skew will depend very 1422 much on the setting in which MIKEY is used. One recommendation is to 1423 fix a size for the replay cache, and let the allowable clock skew be 1424 large (the initial clock skew can be set depending on the application 1425 in which it is used). As the replay cache grows, the clock skew is 1426 decreased depending on how many percent of the replay cache that are 1427 used. Note that this is locally handled, which will not require 1428 interaction with the peer (even though it may indirectly affect the 1429 peer). Exactly how to implement such functionality is however out of 1430 the scope of this document and considered implementation specific. 1432 In case of a DoS attack, the client will most likely be able to 1433 handle the replay cache. A more likely (and serious) DoS attack is a 1434 CPU DoS attack where the attacker sends messages to the peer, which 1435 then needs to engage resources on verifying MACs/signatures of the 1436 incoming messages. 1438 6. Payload Encoding 1440 This section describes in detail all the payloads. For all encoding, 1441 network byte order is always used. While defining supported types, 1442 for example which hash functions are supported, the mandatory-to- 1443 implement are indicated (as Mandatory), as well as the default (note, 1444 default also implies mandatory to implement). The other types are 1445 implicitly assumed optional to support. 1447 Note that in the following the support for SRTP [SRTP] as security 1448 protocol is defined. This will help better understanding the purpose 1449 of the different payloads and fields. Other security protocol MAY be 1450 specified to use within MIKEY, see Section 10. 1452 In the following, the sign ~ indicates variable length field. 1454 6.1. Common Header payload (HDR) 1456 The Common Header payload MUST always be present as the first payload 1457 in each message. The Common Header includes general description of 1458 the exchange message. 1460 1 2 3 1461 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 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 ! version ! data type ! next payload !V! PRF func ! 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 ! CSB ID ! 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 ! #CS ! CS ID map type! CS ID map info ~ 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 * version (8 bits): the version number of MIKEY. 1472 version = 0x01 refers to MIKEY as defined in this document. 1474 * data type (8 bits): describes the type of message (e.g. public-key 1475 transport message, verification message, error message). 1477 Data type | Value | Comment 1478 -------------------------------------- 1479 Pre-shared | 0 | Initiator's pre-shared key message 1480 PSK ver msg | 1 | Verification message of a Pre-shared 1481 | | key message 1482 Public key | 2 | Initiator's public-key transport message 1483 PK ver msg | 3 | Verification message of a public-key 1484 | | message 1485 D-H init | 4 | Initiator's DH exchange message 1486 D-H resp | 5 | Responder's DH exchange message 1487 Error | 6 | Error message 1489 Table 6.1.a 1491 * next payload (8 bits): identifies the payload that is added after 1492 this payload. 1494 Next payload | Value | Section 1495 ------------------------------ 1496 Last payload | 0 | - 1497 KEMAC | 1 | 6.2 1498 PKE | 2 | 6.3 1499 DH | 3 | 6.4 1500 SIGN | 4 | 6.5 1501 T | 5 | 6.6 1502 ID | 6 | 6.7 1503 CERT | 7 | 6.7 1504 CHASH | 8 | 6.8 1505 V | 9 | 6.9 1506 SP | 10 | 6.10 1507 RAND | 11 | 6.11 1508 ERR | 12 | 6.12 1509 Key data | 20 | 6.13 1510 General Ext. | 21 | 6.15 1512 Table 6.1.b 1514 Note that some of the payloads cannot come right after the header 1515 (such as "Last payload", "Signature", etc.). However, the Next 1516 payload field is generic for all payloads. Therefore, a value is 1517 allocated for each payload. The Next payload field is set to zero 1518 (Last payload) if the current payload is the last payload. 1520 * V (1 bit): flag to indicate whether a verification message is 1521 expected or not (this has only meaning when it is set by the 1522 Initiator). The V flag SHALL be ignored by the receiver in the DH 1523 method (as the response is MANDATORY). 1525 V = 0 ==> no response expected 1526 V = 1 ==> response expected 1528 * PRF func (7 bits): indicates the PRF function that has been/will be 1529 used for key derivation. 1531 PRF func | Value | Comments 1532 -------------------------------------------------------- 1533 MIKEY-1 | 0 | Mandatory (see Section 4.1.3) 1535 Table 6.1.c 1537 * CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that it is 1538 chosen at random by the Initiator. This ID MUST be unique between 1539 each Initiator-Responder pair, i.e., not globally unique. An 1540 Initiator MUST check for collisions when choosing the ID (if the 1541 Initiator already has one or more established CSB with the 1542 Responder). The Responder uses the same CSB ID in the response. 1544 * #CS (8 bits): indicates the number of Crypto Sessions that will be 1545 handled within the CBS. Note that even though it is possible to use 1546 255 CSs, it is not likely that a CSB will include this many CSs. The 1547 integer 0 is interpreted as no CS included. This may be the case in 1548 an initial setup message. 1550 * CS ID map type (8 bits): specifies the method to uniquely map 1551 Crypto Sessions to the security protocol sessions. 1553 CS ID map type | Value 1554 ----------------------- 1555 SRTP-ID | 0 1557 Table 6.1.d 1559 * CS ID map info (16 bits): identifies the crypto session(s) that the 1560 SA should be created for. The currently defined map type is the SRTP- 1561 ID (defined in Section 6.1.1). 1563 6.1.1. SRTP ID 1565 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 ! Policy_no_1 ! SSRC_1 ! 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 ! SSRC_1 (cont) ! ROC_1 ! 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 ! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 ! 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 ! SSRC_2 (cont) ! ROC_2 ! 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 ! ROC_2 (cont) ! : 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 1578 : : : 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 ! Policy_no_#CS ! SSRC_#CS ! 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 !SSRC_#CS (cont)! ROC_#CS ! 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 ! ROC_#CS (cont)! 1585 +-+-+-+-+-+-+-+-+ 1587 * Policy_no_i (8 bits): The security policy applied for the stream 1588 with SSRC_i. The same security policy may apply for all CSs. 1590 * SSRC_i (32 bits): specifies the SSRC that MUST be used for the i-th 1591 SRTP stream. Note that it is the sender of the streams who chooses 1592 the SSRC. Therefore, it might be that the Initiator of MIKEY can not 1593 fill in all fields. In this case, SSRCs that are not chosen by the 1594 Initiator are set to zero and the Responder fills in these fields in 1595 the response message. Note that SRTP specifies requirements on the 1596 uniqueness of the SSRCs (to avoid two-time pad problems if the same 1597 TEK is used for more than one stream), see [SRTP]. 1599 * ROC_i (32 bits): Current rollover counter used in SRTP. If the SRTP 1600 session has not started, this field is set to 0. This field is used 1601 to be able for a member to join and synchronize to an already started 1602 stream. 1604 NOTE: The stream using SSRC_i will also have Crypto Session ID equal 1605 to no i (NOT to the SSRC). 1607 6.2. Key data transport payload (KEMAC) 1609 The Key data transport payload contains encrypted Key data sub- 1610 payloads (see Section 6.13 for definition of the Key data sub- 1611 payload). It may contain one or more Key data payloads each including 1612 e.g. a TGK. The last Key data payload has its Next payload field set 1613 to Last payload. For an update message (see also Section 4.5), it is 1614 allowed to skip the Key data sub-payloads (which will result in that 1615 the Encr data len is equal to 0). 1617 Note that the MAC coverage depends on the method used, i.e. pre- 1618 shared vs public key, see below. 1620 If the transport method used is the pre-shared key method, this Key 1621 data transport payload is the last payload in the message (note that 1622 the Next payload field is set to Last payload). The MAC is then 1623 calculated over the entire MIKEY message following the directives in 1624 Section 5.2. 1626 If the transport method used is the public-key method, the 1627 Initiator's identity is added in the encrypted data. This is done by 1628 adding the ID payload as the first payload, which then is followed by 1629 the Key data sub-payloads. Note that for an update message, the ID is 1630 still sent encrypted to the Responder (this is to avoid certain re- 1631 direction attacks) even though no Key data sub-payload is added 1632 after. 1634 The coverage of the MAC field is in the public-key case over the Key 1635 data transport payload only, instead of the complete MIKEY message, 1636 as in the pre-shared case. The MAC is therefore calculated over the 1637 Key data transport payload except the MAC field and where the Next 1638 payload field has been set to zero (see also Section 5.2). 1640 1 2 3 1641 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 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 ! Next payload ! Encr alg ! Encr data len ! 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 ! Encr data ~ 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 ! Mac alg ! MAC ~ 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 * Next payload (8 bits): identifies the payload that is added after 1651 this payload. See Section 6.1 for defined values. 1653 * Encr alg (8 bits): the encryption algorithm used to encrypt the 1654 Encr data field. 1656 Encr alg | Value | Comment 1657 ------------------------------------------- 1658 NULL | 0 | Very restricted usage, see Section 4.2.3! 1659 AES-CM-128 | 1 | Mandatory ; AES-CM using a 128-bit key, see 1660 Section 4.2.3) 1661 AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see 1662 Section 4.2.3 1664 Table 6.2.a 1666 * Encr data len (16 bits): length of Encr data (in bytes). 1668 * Encr data (variable length): the encrypted key sub-payloads (see 1669 Section 6.13). 1671 * MAC alg (8 bits): specifies the authentication algorithm used. 1673 MAC alg | Value | Comments | Length (bits) 1674 ------------------------------------------------------------------- 1675 NULL | 0 | restricted usage (Sec 4.2.4)| 0 1676 HMAC-SHA-1-160| 1 | Mandatory, Section 4.2.4 | 160 1678 Table 6.2.b 1680 * MAC (variable length): the message authentication code of the 1681 entire message. 1683 6.3. Envelope data payload (PKE) 1685 The Envelope data payload contains the encrypted envelope key that is 1686 used in the public-key transport to protect the data in the Key data 1687 transport payload. The encryption algorithm used is implicit from the 1688 certificate/public key used. 1690 1 2 3 1691 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 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 ! Next Payload ! C ! Data len ! Data ~ 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 * Next payload (8 bits): identifies the payload that is added after 1697 this payload. See Section 6.1 for values. 1699 * C (2 bits): envelope key cache indicator (Section 3.2). 1701 Cache type | Value | Comments 1702 -------------------------------------- 1703 No cache | 0 | The envelope key MUST NOT be cached 1704 Cache | 1 | The envelope key MUST be cached 1705 Cache for CSB | 2 | The envelope key MUST be cached, but only 1706 | | to be used for the specific CSB. 1707 Table 6.3 1709 * Data len (14 bits): the length of the data field (in bytes). 1711 * Data (variable length): the encrypted envelope key. 1713 6.4. DH data payload (DH) 1715 The DH data payload carries the DH-value and indicates the DH-group 1716 used. Notice that in this sub-section "MANDATORY" is conditioned upon 1717 DH being supported at all. 1719 1 2 3 1720 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 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 ! Next Payload ! DH-Group ! DH-value ~ 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 ! Reserv! KV ! KV data (optional) ~ 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 * Next payload (8 bits): identifies the payload that is added after 1728 this payload. See Section 6.1 for values. 1730 * DH-Group (8 bits): identifies the DH group used. 1732 DH-Group | Value | Comment | DH Value length (bits) 1733 --------------------------------------|--------------------- 1734 OAKLEY 5 | 0 | Mandatory | 1536 1735 OAKLEY 1 | 1 | | 768 1736 OAKLEY 2 | 2 | | 1024 1737 Table 6.4 1739 * DH-value (variable length): the public DH-value (the length is 1740 implicit from the group used). 1742 * KV (4 bits): indicates the type of key validity period specified. 1743 This may be done by using an SPI (alternatively an MKI) or by 1744 providing an interval in which the key is valid (e.g. in the latter 1745 case, for SRTP this will be the index range where the key is valid). 1746 See Section 6.13 for pre-defined values. 1748 * KV data (variable length): This includes either the SPI/MKI or an 1749 interval (see Section 6.14). If KV is NULL, this field is not 1750 included. 1752 6.5. Signature payload (SIGN) 1754 The Signature payload carries the signature and its related data. The 1755 signature payload is always the last payload in the PK transport and 1756 DH exchange messages. The signature algorithm used is implicit from 1757 the certificate/public key used. 1759 1 2 3 1760 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 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 ! S type| Signature len ! Signature ~ 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 * S type (4 bits): indicates the signature algorithm applied by 1766 signer. 1768 S type | Value | Comments 1769 ------------------------------------- 1770 RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature 1771 [PSS] 1772 RSA/PSS | 1 | RSASSA-PSS signature [PSS] 1774 Table 6.5 1776 * Signature len (12 bits): the length of the signature field (in 1777 bytes). 1779 * Signature (variable length): the signature (its formatting and 1780 padding depend on the type of signature). 1782 6.6. Timestamp payload (T) 1784 The timestamp payload carries the timestamp information. 1786 1 2 3 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 ! Next Payload ! TS type ! TS value ~ 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 * Next payload (8 bits): identifies the payload that is added after 1793 this payload. See Section 6.1 for values. 1795 * TS type (8 bits): specifies the timestamp type used. 1797 TS type | Value | Comments | length of TS value 1798 -------------------------------------|------------------- 1799 NTP-UTC | 0 | Mandatory | 64-bits 1800 NTP | 1 | Mandatory | 64-bits 1801 COUNTER | 2 | Optional | 32-bits 1803 Table 6.6 1805 Note: COUNTER SHALL be padded (with leading zeros) to 64-bit value 1806 when used as input to the default PRF. 1808 * TS-value (variable length): The timestamp value of the specified TS 1809 type. 1811 6.7. ID payload (ID) / Certificate payload (CERT) 1813 Note that the ID payload and the Certificate payload are two 1814 completely different payloads (having different payload identifiers). 1815 However, as they share the same payload structure they are described 1816 in the same section. 1818 The ID payload carries a uniquely defined identifier. 1820 The certificate payload contains an indicator of the certificate 1821 provided as well as the certificate data. If a certificate chain is 1822 to be provided, each certificate in the chain should be included in a 1823 separate CERT payload. 1825 1 2 3 1826 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 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 ! Next Payload ! ID/Cert Type ! ID/Cert len ! 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 ! ID/Certificate Data ~ 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 * Next payload (8 bits): identifies the payload that is added after 1834 this payload. See Section 6.1 for values. 1836 If the payload is an ID payload the following values applies for the 1837 ID type field: 1839 * ID Type (8 bits): specifies the identifier type used. 1841 ID Type | Value | Comments 1842 ---------------------------------------------- 1843 NAI | 0 | Mandatory (see [NAI]) 1844 URI | 1 | Mandatory (see [URI]) 1846 Table 6.7.a 1848 If the payload is an Certificate payload the following values applies 1849 for the Cert type field: 1851 * Cert Type (8 bits): specifies the certificate type used. 1853 Cert Type | Value | Comments 1854 ---------------------------------------------- 1855 X.509v3 | 0 | Mandatory 1856 X.509v3 URL | 1 | plain ASCII URL to the location of the Cert 1857 X.509v3 Sign | 2 | Mandatory (used for signatures only) 1858 X.509v3 Encr | 3 | Mandatory (used for encryption only) 1860 Table 6.7.b 1862 * ID/Cert len (16 bits): the length of the ID or Certificate field 1863 (in bytes). 1865 * ID/Certificate (variable length): The ID or Certificate data. The 1866 X.509 [X.509] certificates are included as a bytes string using DER 1867 encoding as specified in X.509. 1869 6.8. Cert hash payload (CHASH) 1871 The Cert hash payload contains the hash of the certificate used. 1873 1 2 3 1874 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 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 ! Next Payload ! Hash func ! Hash ~ 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 * Next payload (8 bits): identifies the payload that is added after 1880 this payload. See Section 6.1 for values. 1882 * Hash func (8 bits): indicates the hash function that is used (see 1883 also Section 4.2.1). 1885 Hash func | Value | Comment | hash length (bits) 1886 ------------------------------------------------- 1887 SHA-1 | 0 | Mandatory | 160 1888 MD5 | 1 | | 128 1890 Table 6.8 1892 * Hash (variable length): the hash data. The hash length is implicit 1893 from the hash function used. 1895 6.9. Ver msg payload (V) 1897 The Ver msg payload contains the calculated verification message in 1898 the pre-shared key and the public-key transport methods. Note that 1899 the MAC is calculated over the entire MIKEY message as well as the 1900 IDs and Timestamp (see also Section 5.2). 1902 1 2 3 1903 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 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 ! Next Payload ! Auth alg ! Ver data ~ 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 * Next payload (8 bits): identifies the payload that is added after 1909 this payload. See Section 6.1 for values. 1911 * Auth alg (8 bits): specifies the MAC algorithm used for the 1912 verification message. See Section 6.2 for defined values. 1914 * Ver data (variable length): the verification message data. The 1915 length is implicit from the authentication algorithm used. 1917 6.10. Security Policy payload (SP) 1919 The Security Policy payload defines a set of policies that applies to 1920 a specific security protocol. 1922 1 2 3 1923 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 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 ! Next payload ! Policy no ! Prot type ! Policy param ~ 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 ~ length (cont) ! Policy param ~ 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 * Next payload (8 bits): identifies the payload that is added after 1931 this payload. See Section 6.1 for values. 1933 * Policy no (8 bits): each security policy payload must be given a 1934 distinct number for the current MIKEY session by the local peer. This 1935 number is used to be able to map a crypto session to a specific 1936 policy (see also Section 6.1.1). 1938 * Prot type (8 bits): defines the security protocol. 1940 Prot type | Value | 1941 --------------------------- 1942 SRTP | 0 | 1944 Table 6.10 1946 * Policy param length (16 bits): defines the total length of the 1947 policy parameters for the specific security protocol. 1949 * Policy param (variable length): defines the policy for the specific 1950 security protocol. 1952 The Policy param part is built up by a set of Type/Length/Value 1953 fields. For each security protocol, a set of possible types/values 1954 that can be negotiated is defined. 1956 1 2 3 1957 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 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 ! Type ! Length ! Value ~ 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 * Type (8 bits): specifies the type of the parameter. 1964 * Length (8 bits): specifies the length of the Value field (in 1965 bytes). 1967 * Value (variable length): specifies the value of the parameter. 1969 6.10.1. SRTP policy 1971 This policy specifies the parameters for SRTP and SRTCP. The 1972 types/values that can be negotiated are defined by the following 1973 table: 1975 Type | Meaning | Possible values 1976 ---------------------------------------------------- 1977 0 | Encryption algorithm | see below 1978 1 | Session Encr. key length | depends on cipher used 1979 2 | Authentication algorithm | see below 1980 3 | Session Auth. key length | depends on MAC used 1981 4 | Session Salt key length | see [SRTP] for recommendations 1982 5 | SRTP Pseudo Random Function | see below 1983 6 | Key derivation rate | see [SRTP] for recommendations 1984 7 | SRTP encryption off/on | 0 if off, 1 if on 1985 8 | SRTCP encryption off/on | 0 if off, 1 if on 1986 9 | sender's FEC order | see below 1987 10 | SRTP authentication off/on | 0 if off, 1 if on 1988 11 | Authentication tag length | in bytes 1989 12 | SRTP prefix length | in bytes 1991 Table 6.10.1.a 1993 Note that if a Type/Value is not set, the default one is used 1994 (according to SRTPs own criteria). 1996 For the Encryption algorithm, it is enough with a one byte length and 1997 the currently defined possible Values are: 1999 SRTP encr alg | Value 2000 --------------------- 2001 NULL | 0 2002 AES-CM | 1 2003 AES-F8 | 2 2005 Table 6.10.1.b 2007 where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP]. 2009 For the Authentication algorithm, it is enough with a one byte length 2010 and the currently define possible Values are: 2012 SRTP auth alg | Value 2013 --------------------- 2014 NULL | 0 2015 HMAC-SHA-1 | 1 2017 Table 6.10.1.c 2019 For the SRTP pseudo-random function, it is also enough with a one 2020 byte length and the currently define possible Values are: 2022 SRTP PRF | Value 2023 --------------------- 2024 AES-CM | 0 2026 Table 6.10.1.d 2028 If FEC is used at the same time as SRTP is used, MIKEY can negotiate 2029 the order in which these should be applied at the sender side. 2031 FEC order | Value | Comments 2032 -------------------------------- 2033 FEC-SRTP | 0 | First FEC, then SRTP 2035 Table 6.10.1.e 2037 6.11. RAND payload (RAND) 2039 The RAND payload consists of a (pseudo-)random bit-string. The RAND 2040 MUST be independently generated per CSB (note that the if a CSB has 2041 several members, the Initiator MUST use the same RAND to all the 2042 members). For randomness recommendations for security, see [RAND]. 2044 1 2 3 2045 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 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 ! Next payload ! RAND len ! RAND ~ 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 * Next payload (8 bits): identifies the payload that is added after 2051 this payload. See Section 6.1 for values. 2053 * RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at 2054 least 16. 2056 * RAND (variable length): a (pseudo-)randomly chosen bit-string. 2058 6.12. Error payload (ERR) 2060 The Error payload is used to specify the error(s) that may have 2061 occurred. 2062 1 2 3 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 ! Next Payload ! Error no ! Reserved ! 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 * Next payload (8 bits): identifies the payload that is added after 2069 this payload. See Section 6.1 for values. 2071 * Error no (8 bits): indicates the type of error that was 2072 encountered. 2074 Error no | Value | Comment 2075 ------------------------------------------------------- 2076 Auth failure | 0 | Authentication failure 2077 Invalid TS | 1 | Invalid timestamp 2078 Invalid PRF | 2 | PRF function not supported 2079 Invalid MAC | 3 | MAC algorithm not supported 2080 Invalid EA | 4 | Encryption algorithm not supported 2081 Invalid HA | 5 | Hash function not supported 2082 Invalid DH | 6 | DH group not supported 2083 Invalid ID | 7 | ID not supported 2084 Invalid Cert | 8 | Certificate not supported 2085 Invalid SP | 9 | SP type not supported 2086 Invalid SPpar | 10 | SP parameters not supported 2087 Invalid DT | 11 | not supported Data type 2088 Unspecified error | 12 | an unspecified error occurred 2090 Table 6.12 2092 6.13. Key data sub-payload 2094 The Key data payload contains key material, e.g. TGKs. The Key data 2095 payloads are never included in clear, but as an encrypted part of the 2096 Key data transport payload. 2098 Note that a Key data transport payload can contain multiple Key data 2099 sub-payloads. 2101 1 2 3 2102 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 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 ! Next Payload ! Type ! KV ! Key data len ! 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 ! Key data ~ 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 ! Salt len (optional) ! Salt data (optional) ~ 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 ! KV data (optional) ~ 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 * Next payload (8 bits): identifies the payload that is added after 2114 this payload. See Section 6.1 for values. 2116 * Type (4 bits): indicates the type of the key included in the 2117 payload. 2119 Type | Value 2120 ----------------- 2121 TGK | 0 2122 TGK+SALT | 1 2123 TEK | 2 2124 TEK+SALT | 3 2126 Table 6.13.a 2128 Note that the possibility to include a TEK (instead of using the TGK) 2129 is provided. When sent directly, the TEK can generally not be shared 2130 between more than one Crypto Session (unless the Security protocol 2131 allows for this, e.g. [SRTP]). The recommended use of sending a TEK 2132 instead of a TGK is when pre-encrypted material exists and therefore, 2133 the TEK must be known in advance. 2135 * KV (4 bits): indicates the type of key validity period specified. 2136 This may be done by using an SPI (or MKI in the case of [SRTP]) or by 2137 providing an interval in which the key is valid (e.g., in the latter 2138 case, for SRTP this will be the index range where the key is valid). 2140 KV | Value | Comments 2141 ------------------------------------------- 2142 Null | 0 | No specific usage rule (e.g. a TEK 2143 | | that has no specific lifetime) 2144 SPI | 1 | The key is associated with the SPI/MKI 2145 Interval | 2 | The key has a start and expiration time 2146 | | (e.g. an SRTP TEK) 2148 Table 6.13.b 2150 Note that when NULL is specified, any SPI or Interval is valid. For 2151 an Interval this means that the key is valid from the first observed 2152 sequence number until the key is replaced (or the security protocol 2153 is shutdown). 2155 * Key data len (16 bits): the length of the Key data field (in 2156 bytes). Note that the sum of the overall length of all the Key data 2157 payloads contained in a single Key data transport payload (KEMAC) 2158 MUST be such that the KEMAC payload does not exceed a length of 2^16 2159 bytes (total length of KEMAC, see Section 6.2). 2161 * Key data (variable length): The TGK or TEK data. 2163 * Salt len (16 bits): The salt key length in bytes. Note that this 2164 field is only included if the salt is specified in the Type-field. 2166 * Salt data (variable length): The salt key data. Note that this 2167 field is only included if the salt is specified in the Type-field. 2168 (For SRTP, this is the so-called master salt.) 2170 * KV data (variable length): This includes either the SPI or an 2171 interval (see Section 6.14). If KV is NULL, this field is not 2172 included. 2174 6.14. Key validity data 2176 The Key validity data is not a standalone payload, but part of either 2177 the Key data payload (see Section 6.13) or the DH payload (see 2178 Section 6.4). The Key validity data gives a guideline of when the key 2179 should be used. There are two KV types defined (see Section 6.13), 2180 SPI/MKI (SPI) or a lifetime range (interval). 2182 SPI/MKI 2183 1 2 3 2184 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 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 ! SPI Length ! SPI ~ 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 * SPI Length (8 bits): the length of the SPI (or MKI) in bytes. 2191 * SPI (variable length): the SPI (or MKI) value. 2193 Interval 2194 1 2 3 2195 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 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 ! VF Length ! Valid From ~ 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 ! VT Length ! Valid To (expires) ~ 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 * VF Length (8 bits): length of the Valid From field in bytes. 2204 * Valid From (variable length): Sequence number, index, timestamp, or 2205 other start value that the security protocol uses to identify the 2206 start position of the key usage. 2208 * VT Length (8 bits): length of the Valid To field in bytes. 2210 * Valid To (variable length): sequence number, index, timestamp, or 2211 other expiration value that the security protocol can use to identify 2212 the expiration of the key usage. 2214 Note that for SRTP usage, the key validity period for a TGK/TEK 2215 should be specified with either an interval, where the VF/VT Length 2216 is equal to 6 bytes (i.e., the size of the index), or with an MKI. It 2217 is RECOMMENDED that if more than one SRTP stream is sharing the same 2218 keys and key update/re-keying is desired, this is handled using MKI 2219 rather than the From-To method. 2221 6.15. General Extension Payload 2223 The General extensions payload is included to allow possible 2224 extensions to MIKEY without the need to define a complete new payload 2225 each time. This payload can be used in any MIKEY message and is part 2226 of the authenticated/signed data part. 2228 1 2 3 2230 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 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 ! Next payload ! Type ! Length ! 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 ! Data ~ 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 * Next payload (8 bits): identifies the payload that is added after 2238 this payload. 2240 * Type (8 bits): identifies the type of the general payload. 2242 Type | Value | Comments 2243 --------------------------------------- 2244 Vendor ID | 0 | Vendor specific byte string 2245 SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in 2246 [KMASDP]) 2248 Table 6.15 2250 * Length (16 bits): the length in bytes of the Data field. 2252 * Data (variable length): the general payload data. 2254 7. Transport protocols 2256 MIKEY MAY be integrated within session establishment protocols. 2257 Currently integration of MIKEY within SIP/SDP and RTSP is defined in 2258 [KMASDP]. MIKEY MAY use other transport, in which case it has to be 2259 defined how MIKEY is transported over such transport protocol. 2261 8. Groups 2263 What has been discussed up to now is not limited to single peer-to- 2264 peer communication (except for the DH method), but can be used to 2265 distribute group keys for small-size interactive groups and simple 2266 one-to-many scenarios. Section 2.1. describes the scenarios in the 2267 focus of MIKEY. This section describes how MIKEY is used in a group 2268 scenario (though, see also Section 4.3 for issues related to 2269 authorization). 2271 8.1. Simple one-to-many 2273 ++++ 2274 |S | 2275 | | 2276 ++++ 2277 | 2278 --------+-------------- - - 2279 | | | 2280 v v v 2281 ++++ ++++ ++++ 2282 |A | |B | |C | 2283 | | | | | | 2284 ++++ ++++ ++++ 2286 Figure 8.1. Simple one-to-many scenario. 2288 In the simple one-to-many scenario, a server is streaming to a small 2289 group of clients. RTSP or SIP is used for the registration and the 2290 key management set up. The streaming server acts as the Initiator of 2291 MIKEY. In this scenario the pre-shared key or public key transport 2292 mechanism will be appropriate to use to transport the same TGK to all 2293 the clients (which will result in common TEKs for the group). 2295 Note, if the same TGK/TEK(s) should be used by all the group members, 2296 the streaming server MUST specify the same CSB_ID and CS_ID(s) for 2297 the session to all the group members. 2299 As the communication may be performed using multicast, the members 2300 need a common security policy if they want to be part of the group. 2301 This limits the possibility for negotiation. 2303 Furthermore, the Initiator should carefully consider whether to 2304 request the verification message in reply from each receiver, as this 2305 may result in a certain load for the Initiator itself, as the group 2306 size increases. 2308 8.2. Small-size interactive group 2310 As described in the overview section, for small-size interactive 2311 groups, one may expect that each client will be in charge for setting 2312 up the security for its outgoing streams. In these scenarios, the 2313 pre-shared key or the public-key transport method is used. 2315 ++++ ++++ 2316 |A | -------> |B | 2317 | | <------- | | 2318 ++++ ++++ 2319 ^ | | ^ 2320 | | | | 2321 | | ++++ | | 2322 | --->|C |<--- | 2323 ------| |------ 2324 ++++ 2326 Figure 8.2. Small-size group without centralized controller. 2328 One scenario may then be that the client sets up a three-part call, 2329 using SIP. Due to the small size of the group, unicast SRTP is used 2330 between the clients. Each client sets up the security for its 2331 outgoing stream(s) to the others. 2333 As for the simple one-to-many case, the streaming client specifies 2334 the same CSB_ID and CS_ID(s) for its outgoing sessions if the same 2335 TGK/TEK(s) is used for all the group members. 2337 9. Security Considerations 2339 9.1. General 2341 Key management protocols based on timestamps/counters and one- 2342 roundtrip key transport have previously been standardized in e.g., 2343 ISO [ISO1, ISO2]. The general security of these types of protocols 2344 can be found in various literature and articles, c.f. [HAC, AKE, 2345 LOA]. 2347 No chain is stronger than its weakest link. If a given level of 2348 protection is wanted, then the cryptographic functions protecting the 2349 keys during transport/exchange MUST offer a security at least 2350 corresponding to that level. 2352 For instance, if a security against attacks with complexity 2^96 is 2353 wanted, then one should choose a secure symmetric cipher supporting 2354 at least 96 bit keys (128 bits may be a practical choice) for the 2355 actual media protection, and a key transport mechanism that provides 2356 equivalent protection, e.g. MIKEY's pre-shared key transport with 128 2357 bit TGK, or, RSA with 1024 bit keys (which according to [LV] 2358 corresponds to the desired 96 bit level, with some margin). 2360 In summary, key size for the key-exchange mechanism MUST be weighed 2361 against the size of the exchanged TGK so that it offers at least the 2362 required level. For efficiency reasons, one SHOULD also avoid a 2363 security overkill, e.g. by not using a public key transport with 2364 public keys giving a security level that is orders of magnitude 2365 higher than length of the transported TGK. We refer to [LV] for 2366 concrete key size recommendations. 2368 Moreover, if the TGKs are not random (or pseudo-random), a brute 2369 force search may be facilitated, again lowering the effective key 2370 size. Therefore, care MUST be taken when designing the (pseudo-) 2371 random generators for TGK generation, see [FIPS][RAND]. 2373 For the selection of the hash function, SHA-1 with 160-bit output is 2374 the default one. In general, hash sizes should be twice the "security 2375 level", indicating that SHA-1-256, [SHA256], should be used for the 2376 default 128-bit level. However, due to the real-time aspects in the 2377 scenarios we are treating, hash size slightly below 256 are 2378 acceptable as the normal "existential" collision probabilities would 2379 be of secondary importance. 2381 In a Crypto Session Bundle, the Crypto Sessions can share the same 2382 TGK as discussed earlier. From a security point of view, the 2383 criterion to be satisfied in case the TGK is shared, is that the 2384 encryption of the individual Crypto Sessions are performed 2385 "independently". In MIKEY this is accomplished by having unique 2386 Crypto Session identifiers (see also Section 4.1) and a TEK 2387 derivation method that provides cryptographically independent TEKs to 2388 distinct Crypto Sessions (within the Crypto Session Bundle), 2389 regardless of the security protocol used. 2391 Specifically, the key derivations, as specified in Section 4.1, are 2392 implemented by a pseudo-random function. The one used here is a 2393 simplified version of that used in TLS [TLS]. Here, only one single 2394 hash function is used, whereas TLS uses two different functions. This 2395 choice is motivated by the high confidence in the SHA-1 hash 2396 function, and by efficiency and simplicity of design (complexity does 2397 not imply security). Indeed, as shown in [DBJ], if one of the two 2398 hashes is severely broken, the TLS PRF is actually less secure than 2399 if a single hash had been used on the whole key, as is done in MIKEY. 2401 In the pre-shared key and public-key schemes, the TGK is generated by 2402 a single party (Initiator). This makes MIKEY somewhat more sensitive 2403 if the Initiator uses a bad random number generator. It should also 2404 be noted that neither the pre-shared nor the public-key scheme 2405 provides perfect forward secrecy. If mutual contribution or perfect 2406 forward secrecy is desired, the Diffie-Hellman method is to be used. 2407 Authentication (e.g. signatures) in the Diffie-Hellman method is 2408 required to prevent man-in-the-middle attacks. 2410 Forward/backward security: if the TGK is exposed, all TEKs generated 2411 from it are compromised. However, under the assumption that the 2412 derivation function is a pseudo-random function, disclosure of an 2413 individual TEK does not compromise other (previous or later) TEKs 2414 derived from the same TGK. The Diffie-Hellman mode can be considered 2415 by cautious users as it is the only one that supports so called 2416 perfect forward secrecy (PFS). This is in contrast to a compromise of 2417 the pre-shared key (or the secret key of the public key mode), where 2418 future sessions and recorded session from the past are then also 2419 compromised. 2421 The use of random nonces (RANDs) in the key derivation is of utmost 2422 importance to counter off-line pre-computation attacks. Note however 2423 that update messages re-use the old RAND. This means that the total 2424 effective key entropy (relative to pre-computation attacks) for k 2425 consecutive key updates, assuming the TGKs and RAND are each n bits 2426 long, is about L = n*(k+1)/2 bits, compared to the theoretical 2427 maximum of n*k bits. In other words, a 2^L work effort MAY enable an 2428 attacker to get all k n-bit keys, which is better than brute force 2429 (except when k = 1). While this might seem as a defect, first note 2430 that for proper choice of n, the 2^L complexity of the attack is way 2431 out of reach. Moreover, the fact that more than one key can be 2432 compromised in a single attack is inherent to the key exchange 2433 problematic. Consider for instance a user who, using say a fixed 2434 1024-bit RSA key, exchanges keys and communicates during one or two 2435 years lifetime of the public key. Breaking this single RSA key will 2436 enable access to all exchanged keys and consequently the entire 2437 communication of that user over the whole period. 2439 All the pre-defined transforms in MIKEY use state-of-the-art 2440 algorithms that have undergone large amounts of public evaluation. 2441 One of the reasons to use AES-CM from SRTP [SRTP] is to have the 2442 possibility to limit the overall number of different encryption modes 2443 and algorithms, at the same time that it offers a high level of 2444 security. 2446 9.2. Key lifetime 2448 Even if the lifetime of a TGK (or TEK) is not specified, it MUST be 2449 taken into account that the encryption transform in the underlying 2450 security protocol can in some way degenerate after a certain amount 2451 of encrypted data. It is not possible to here state general key 2452 lifetime bounds, universally applicable; each security protocol 2453 should define such maximum amount and trigger a re-keying procedure 2454 before the "exhaustion" of the key. E.g., according to SRTP [SRTP] 2455 the TEK, together with the corresponding TGK, MUST be changed at 2456 least every 2^48 SRTP packet. 2458 Still, the following can be said as a rule of thumb. If the security 2459 protocol uses an "ideal" b-bit block cipher (in CBC mode, counter 2460 mode, or a feedback mode, e.g. OFB, with full b-bit feedback), 2461 degenerate behavior in the crypto stream, possibly useful for an 2462 attacker, is (with constant probability) expected to occur after a 2463 total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). 2464 For security margin, re-keying MUST be triggered well in advance 2465 compared to the above bound. See [BDJR] for more details. 2467 For use of a dedicated stream cipher, we refer to the analysis and 2468 documentation of said cipher in each specific case. 2470 9.3. Timestamps 2472 The use of timestamps instead of challenge-response requires the 2473 systems to have synchronized clocks. Of course, if two clients are 2474 not synchronized, they will have difficulties with setting up the 2475 security. The current timestamp based solution has been selected to 2476 allow a maximum of one roundtrip (i.e., two messages), but still 2477 provide a reasonable replay protection. A (secure) challenge-response 2478 based version would require at least three messages. For a detailed 2479 description of the timestamp and replay handling in MIKEY, see 2480 Section 5.4. 2482 Practical experiences of Kerberos and other timestamp-based systems 2483 indicate that it is not always necessary to synchronize the terminals 2484 over the network. Manual configuration could be a feasible 2485 alternative in many cases (especially in scenarios where the degree 2486 of looseness is high). However, the choice must be carefully based 2487 with respect to the usage scenario. 2489 9.4. Identity protection 2491 User privacy is a complex matter that to some extent can be enforced 2492 by cryptographic mechanisms, but also requires policy enforcement and 2493 various other functionalities. One particular facet of privacy is 2494 user identity protection. However, identity protection was not a main 2495 design goal for MIKEY. Such feature will add more complexity to the 2496 protocol and was therefore chosen not to be included. As MIKEY is 2497 anyway proposed to be transported over e.g. SIP, the identity may be 2498 exposed by this. However, if the transporting protocol is secured and 2499 also provides identity protection, MIKEY might inherit the same 2500 feature. How this should be done is for future study. 2502 9.5. Denial of Service 2504 This protocol is resistant to Denial of Service attacks in the sense 2505 that a Responder does not construct any state (at the key management 2506 protocol level) before it has authenticated the Initiator. However, 2507 this protocol, like many others, is open to attacks that use spoofed 2508 IP addresses to create a large number of fake requests. This may 2509 e.g., be solved by letting the protocol transporting MIKEY do an IP 2510 address validity test. For example, the SIP protocol can provide this 2511 using the anonymous authentication challenge mechanism (specified in 2512 Section 22.1 of [SIP]). 2514 As also discussed in Section 5.4, the tradeoff between time 2515 synchronization and the size of the replay cache, may be affected in 2516 case of e.g., a flooding type of DoS attack. However, if the 2517 recommendations of using a dynamic size of the replay cache are 2518 followed, it is believed that the client will in most cases be able 2519 to handle the replay cache. Of course, as the replay cache decreases 2520 in size, the required time synchronization is more restricted. 2521 However, a bigger problem during such attack would probably be to 2522 process the messages (e.g., verify signatures/MACs), due to the 2523 computational workload this implies. 2525 9.6. Session establishment 2527 It should be noted that if the session establishment protocol is 2528 insecure there may be attacks on this that will have indirect 2529 security implications on the secured media streams. This however only 2530 applies to groups (and is not specific to MIKEY). The threat is that 2531 one group member may re-direct a stream from one group member to 2532 another. This will have the same implication as when a member tries 2533 to impersonate another member, e.g. by changing its IP address. If 2534 this is seen as a problem, it is RECOMMENDED that a Source Origin 2535 Authentication (SOA) scheme (e.g., digital signatures) is applied to 2536 the security protocol. 2538 Re-direction of streams can of course be done even if it is not a 2539 group. However, the effect will not be the same compared to a group 2540 where impersonation can be done if SOA is not used. Instead, re- 2541 direction will only deny the receiver the possibility to receive (or 2542 just delay) the data. 2544 10. IANA considerations 2546 This document defines several new name spaces associated with the 2547 MIKEY payloads. This section summarizes the name spaces for which 2548 IANA is requested to manage the allocation of values. 2549 IANA is requested to record the pre-defined values defined in the 2550 given sections for each name space. IANA is also requested to manage 2551 the definition of additional values in the future. Unless explicitly 2552 stated otherwise, values in the range 0-240 for each name space 2553 SHOULD be approved by the process of IETF consensus and values in the 2554 range 241-255 are reserved for Private Use, according to [RFC2434]. 2556 The name spaces for the following fields in the Common header payload 2557 (from Section 6.1) are requested to be managed by IANA (in bracket is 2558 the reference to the table with initial registered values): 2560 * version 2562 * data type (Table 6.1.a) 2564 * Next payload (Table 6.1.b) 2565 * PRF func (Table 6.1.c). This name space is between 0-127 where 2566 values between 0-111 should be approved by the process of IETF 2567 consensus and values between 112-127 are reserved for Private Use. 2569 * CS ID map type (Table 6.1.d) 2571 The name spaces for the following fields in the Key data transport 2572 payload (from Section 6.2) are requested to be managed by IANA: 2574 * Encr alg (Table 6.2.a) 2576 * MAC alg (Table 6.2.b) 2578 The name spaces for the following fields in the Envelope data payload 2579 (from Section 6.3) are requested to be managed by IANA: 2581 * C (Table 6.3) 2583 The name spaces for the following fields in the DH data payload (from 2584 Section 6.4) are requested to be managed by IANA: 2586 * DH-Group (Table 6.4) 2588 The name spaces for the following fields in the Signature payload 2589 (from Section 6.5) are requested to be managed by IANA: 2591 * S type (Table 6.5) 2593 The name spaces for the following fields in the Timestamp payload 2594 (from Section 6.6) are requested to be managed by IANA: 2596 * TS type (Table 6.6) 2598 The name spaces for the following fields in the ID payload and the 2599 Certificate payload (from Section 6.7) are requested to be managed by 2600 IANA: 2602 * ID type (Table 6.7.a) 2604 * Cert type (Table 6.7.b) 2606 The name spaces for the following fields in the Cert hash payload 2607 (from Section 6.8) are requested to be managed by IANA: 2609 * Hash func (Table 6.8) 2611 The name spaces for the following fields in the Security policy 2612 payload (from Section 6.10) are requested to be managed by IANA: 2614 * Prot type (Table 6.10) 2615 For each security protocol that uses MIKEY, a set of unique 2616 parameters MAY be registered. 2618 From Section 6.10.1. 2620 * SRTP Type (Table 6.10.1.a) 2622 * SRTP encr alg (Table 6.10.1.b) 2624 * SRTP auth alg (Table 6.10.1.c) 2626 * SRTP PRF (Table 6.10.1.d) 2628 * FEC order (Table 6.10.1.e) 2630 The name spaces for the following fields in the Error payload (from 2631 Section 6.12) are requested to be managed by IANA: 2633 * Error no (Table 6.12) 2635 The name spaces for the following fields in the Key data payload 2636 (from Section 6.13) are requested to be managed by IANA: 2638 * Type (Table 6.13.a). This name space is between 0-16 which should 2639 be approved by the process of IETF consensus. 2641 * KV (Table 6.13.b). This name space is between 0-16 which should be 2642 approved by the process of IETF consensus. 2644 The name spaces for the following fields in the General Extensions 2645 payload (from Section 6.15) are requested to be managed by IANA: 2647 * Type (Table 6.15). 2649 10.1 MIME Registration 2651 This section gives instructions to IANA to register the 2652 application/mikey MIME media type. This registration is as follows: 2654 MIME media type name : application 2655 MIME subtype name : mikey 2656 Required parameters : none 2657 Optional parameters : version 2658 version: The MIKEY version number of the enclosed message 2659 (e.g., 1). If not present, the version defaults to 1. 2660 Encoding Considerations : binary, base64 encoded 2661 Security Considerations : see section 9 in this memo 2662 Interoperability considerations : none 2663 Published specification : this memo 2665 11. Acknowledgments 2667 The authors would like to thank Mark Baugher, Ran Canetti, Martin 2668 Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with 2669 his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov 2670 Vatn, and Erik Eliasson for their valuable feedback. 2672 12. Author's Addresses 2674 Jari Arkko 2675 Ericsson 2676 02420 Jorvas Phone: +358 40 5079256 2677 Finland Email: jari.arkko@ericsson.com 2679 Elisabetta Carrara 2680 Ericsson Research 2681 SE-16480 Stockholm Phone: +46 8 50877040 2682 Sweden EMail: elisabetta.carrara@ericsson.com 2684 Fredrik Lindholm 2685 Ericsson Research 2686 SE-16480 Stockholm Phone: +46 8 58531705 2687 Sweden EMail: fredrik.lindholm@ericsson.com 2689 Mats Naslund 2690 Ericsson Research 2691 SE-16480 Stockholm Phone: +46 8 58533739 2692 Sweden EMail: mats.naslund@ericsson.com 2694 Karl Norrman 2695 Ericsson Research 2696 SE-16480 Stockholm Phone: +46 8 4044502 2697 Sweden EMail: karl.norrman@ericsson.com 2699 13. References 2701 13.1. Normative References 2703 [AES] Advanced Encryption Standard (AES), Federal Information 2704 Processing Standard Publications (FIPS PUBS) 197, November 2001. 2706 [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 2707 for Message Authentication", RFC 2104, February 1997. 2709 [NAI] Aboba, B. and Beadles, M., "The Network Access Identifier", 2710 IETF, RFC 2486, January 1999. 2712 [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2713 2412, November 1998. 2715 [PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories, 2716 June 14, 2002, www.rsalabs.com 2718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2719 Requirement Levels", RFC 2119, March 1997. 2721 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 2722 Considerations Section in RFCs", RFC 2434, October 1998. 2724 [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining 2725 Digital Signatures and Public-Key Cryptosystems". Communications of 2726 the ACM. Vol.21. No.2. pp.120-126. 1978. 2728 [SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 2729 http://csrc.nist.gov/fips/fip180-1.ps 2731 [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, 2732 Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", 2733 Internet Draft, IETF, Work in Progress (AVT WG). 2735 [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource 2736 Identifiers (URI): Generic Syntax", IETF, RFC 2396. 2738 [X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet 2739 X.509 Public Key Infrastructure Certificate and Certificate 2740 Revocation List (CRL) Profile", IETF, RFC 3280. 2742 [AESKW] Schaad, J., Housley R., "Advanced Encryption Standard (AES) 2743 Key Wrap Algorithm", IETF, RFC 3394. 2745 13.2. Informative References 2747 [AKE] Canetti, R. and Krawczyk, H., "Analysis of Key-Exchange 2748 Protocols and their use for Building Secure Channels", Eurocrypt 2749 2001, LNCS 2054, pp. 453-474, 2001. 2751 [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P., "A 2752 Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes 2753 of Operation", in Proceedings of the 38th Symposium on Foundations of 2754 Computer Science, IEEE, 1997, pp. 394-403. 2756 [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and 2757 Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt 2758 '01, Lecture Notes in Computer Science vol 2248, pp. 442-459. 2760 [DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of 2761 MD5", Contribution to ANSI X9F1 WG, 2001. 2763 [FIPS] "Security Requirements for Cryptographic Modules", Federal 2764 Information Processing Standard Publications (FIPS PUBS) 140-2, 2765 December 2002. 2767 [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F., 2768 "Group Key Management Architecture", Internet Draft, Work in Progress 2769 (MSEC WG). 2771 [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group 2772 Domain of Interpretation", Internet Draft, Work in Progress (MSEC 2773 WG). 2775 [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, 2776 R., "Group Secure Association Key Management Protocol", Internet 2777 Draft, Work in Progress (MSEC WG). 2779 [HAC] Menezes, A., van Oorschot, P., and Vanstone, S., "Handbook of 2780 Applied Cryptography", CRC press, 1996. 2782 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", 2783 RFC 2409, November 1998. 2785 [ISO1] ISO/IEC 9798-3: 1997, Information technology - Security 2786 techniques - Entity authentication - Part 3: Mechanisms using digital 2787 signature techniques. 2789 [ISO2] ISO/IEC 11770-3: 1997, Information technology - Security 2790 techniques - Key management - Part 3: Mechanisms using digital 2791 signature techniques. 2793 [ISO3] ISO/IEC 18014 Information technology - Security techniques - 2794 Time-stamping services, Part 1-3. 2796 [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 2797 Norrman, K., "Key Management Extensions for SDP and RTSP", Internet 2798 Draft, Work in Progress (MMUSIC WG). 2800 [LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM 2801 Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36. 2803 [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for 2804 Cryptosystems", http://www.cryptosavvy.com/suggestions.htm 2806 [NTP] Mills, D., "Network Time Protocol (Version 3) specification, 2807 implementation and analysis", RFC 1305, March 1992. 2809 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams 2810 C., "X.509 Internet Public Key Infrastructure Online Certificate 2811 Status Protocol - OCSP", IETF, RFC 2560. 2813 [RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness 2814 Requirements for Security", RFC 1750, December 1994. 2816 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 2817 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2819 [SDP] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 2820 Description Protocol", Internet Draft, IETF, Work in progress 2821 (MMUSIC), draft-ietf-mmusic-sdp-new-15.txt. 2823 [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", 2824 http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf 2826 [SIP] Rosenberg, J. et al, "SIP: Session Initiation Protocol", IETF, 2827 RFC3261. 2829 [TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0", 2830 IETF, RFC 2246. 2832 Appendix A. - MIKEY - SRTP relation 2834 The terminology in MIKEY differs from the one used in SRTP as MIKEY 2835 needs to be more general, nor is tight to SRTP only. Therefore it 2836 might be hard to see the relations between keys and parameters 2837 generated in MIKEY and the ones used by SRTP. This section provides 2838 some hints on their relation. 2840 MIKEY | SRTP 2841 ------------------------------------------------- 2842 Crypto Session | SRTP stream (typically with related SRTCP stream) 2843 Data SA | input to SRTP's crypto context 2844 TEK | SRTP master key 2846 The Data SA is built up by a TEK and the security policy exchanged. 2847 SRTP may use a MKI to index the TEK, or TGK (the TEK is then derived 2848 from the TGK that is associated with the corresponding MKI), see 2849 below. 2851 A.1 MIKEY-SRTP interactions 2853 In the following, we give a brief outline of the interface between 2854 SRTP and MIKEY and the processing that takes place. We describe SRTP 2855 receiver side only, the sender side will require analogous 2856 interfacing. 2858 1. When an SRTP packet arrives at the receiver and is processed, the 2859 triple is extracted 2860 from the packet and used to retrieve the correct SRTP crypto context, 2861 hence the Data SA. (The actual retrieval can e.g. be done by an 2862 explicit request from the SRTP implementation to MIKEY, or, by the 2863 SRTP implementation accessing a "data base", maintained by MIKEY. The 2864 application will typically decide which implementation is preferred.) 2866 2. If an MKI is present in the SRTP packet, it is used to point to 2867 the correct key within the SA. (Alternatively, if SRTP�s 2868 feature is used, the ROC||SEQ of the packet is used to determine the 2869 correct key.) 2871 3. Depending on whether the key sent in MIKEY (as obtained in step 2) 2872 was a TEK or a TGK, there are now two cases. 2874 - If the key obtained in step 2 is the TEK itself, it is used 2875 directly by STRP as a master key. 2877 - If the key instead is a TGK, the mapping with the CS_ID (internal 2878 to MIKEY, Section 6.1.1) allows MIKEY to compute the correct TEK 2879 from the TGK as described in Section 4.1 before SRTP uses it. 2881 If multiple TGKs (or TEKs) are sent, it is RECOMMENDED to associate 2882 each TGK (or TEK) to a distinct MKI. It is RECOMMENDED to limit the 2883 use of in this scenario to very simple cases, e.g. one 2884 stream only. 2886 Besides the actual master key, other information in the Data SA (e.g. 2887 transform identifiers) will of course also be communicated from MIKEY 2888 to SRTP. 2890 IPR Notices 2892 The IETF takes no position regarding the validity or scope of any 2893 intellectual property or other rights that might be claimed to 2894 pertain to the implementation or use of the technology described in 2895 this document or the extent to which any license under such rights 2896 might or might not be available; neither does it represent that it 2897 has made any effort to identify any such rights. Information on the 2898 IETF's procedures with respect to rights in standards-track and 2899 standards-related documentation can be found in BCP-11. Copies of 2900 claims of rights made available for publication and any assurances of 2901 licenses to be made available, or the result of an attempt made to 2902 obtain a general license or permission for the use of such 2903 proprietary rights by implementors or users of this specification can 2904 be obtained from the IETF Secretariat. 2906 The IETF invites any interested party to bring to its attention any 2907 copyrights, patents or patent applications, or other proprietary 2908 rights which may cover technology that may be required to practice 2909 this standard. Please address the information to the IETF Executive 2910 Director. 2912 Copyright Notice 2913 Copyright (C) The Internet Society (2003). All Rights Reserved. 2915 This document and translations of it may be copied and furnished to 2916 others, and derivative works that comment on or otherwise explain it 2917 or assist in its implementation may be prepared, copied, published 2918 and distributed, in whole or in part, without restriction of any 2919 kind, provided that the above copyright notice and this paragraph are 2920 included on all such copies and derivative works. However, this 2921 document itself may not be modified in any way, such as by removing 2922 the copyright notice or references to the Internet Society or other 2923 Internet organizations, except as needed for the purpose of 2924 developing Internet standards in which case the procedures for 2925 copyrights defined in the Internet Standards process must be 2926 followed, or as required to translate it into languages other than 2927 English. 2929 The limited permissions granted above are perpetual and will not be 2930 revoked by the Internet Society or its successors or assigns. 2932 This document and the information contained herein is provided on an 2933 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2934 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2935 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2936 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2937 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2939 This Internet-Draft expires in June 2004.