idnits 2.17.1 draft-ietf-msec-mikey-dhhmac-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1236. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Other defined next payload values defined in [3] SHALL not be applied to DHHMAC. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: DHHMAC SHALL apply this payload for conveying the HMAC result along with the indicated authentication algorithm. KEMAC when used in conjunction with DHHMAC SHALL not convey any encrypted data; thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set to 0 and Encr data SHALL be left empty. The AES key wrap method (see [23]) SHALL not be applied for DHHMAC. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: * text allows both random and pseudo-random values. * exponentiation ** changed to ^. * Notation aligned with MIKEY-07. * Clarified that the HMAC is calculated over the entire MIKEY message excluding the MAC field. * Section 4.2: The AES key wrap method SHALL not be applied. * Section 1: Relationship with other, existing work mentioned. -- 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.) -- The document date (April 2005) is 6951 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'X' on line 1334 -- Looks like a reference, but probably isn't: 'Y' on line 1334 -- Looks like a reference, but probably isn't: 'RFC 3264' on line 326 -- Looks like a reference, but probably isn't: 'IDi' on line 429 -- Looks like a reference, but probably isn't: 'IDr' on line 432 -- Looks like a reference, but probably isn't: 'DHi' on line 448 -- Looks like a reference, but probably isn't: 'DHr' on line 448 -- Looks like a reference, but probably isn't: 'RFCxxxx' on line 1000 == Unused Reference: '1' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1126, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 1132, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '9') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '13') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '14') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '18') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2223 (ref. '19') (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '24') (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '30') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2511 (ref. '32') (Obsoleted by RFC 4211) -- Obsolete informational reference (is this intentional?): RFC 3978 (ref. '34') (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3979 (ref. '35') (Obsoleted by RFC 8179) -- Duplicate reference: RFC3830, mentioned in '37', was also mentioned in '3'. Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force - MSEC WG 3 Internet Draft M. Euchner 4 Intended Category: Proposed Standard 5 Expires: October 2005 April 2005 7 HMAC-authenticated Diffie-Hellman for MIKEY 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Comments should be sent to the MSEC WG mailing list at 34 msec@securemulticast.org and to the author. 36 Abstract 38 This document describes a light-weight point-to-point key management 39 protocol variant for the multimedia Internet keying (MIKEY) protocol 40 MIKEY, as defined in RFC 3830. In particular, this variant deploys 41 the classic Diffie-Hellman key agreement protocol for key 42 establishment featuring perfect forward secrecy in conjunction with 43 a keyed hash message authentication code for achieving mutual 44 authentication and message integrity of the key management messages 45 exchanged. This protocol addresses the security and performance 46 constraints of multimedia key management in MIKEY. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC-2119 [2]. 54 Table of Contents 56 1. Introduction................................................3 57 1.1. Definitions...............................................6 58 1.2. Abbreviations.............................................7 59 2. Scenario....................................................8 60 2.1. Applicability.............................................9 61 2.2. Relation to GKMARCH.......................................9 62 3. DHHMAC Security Protocol...................................10 63 3.1. TGK re-keying............................................12 64 4. DHHMAC payload formats.....................................13 65 4.1. Common header payload (HDR)..............................13 66 4.2. Key data transport payload (KEMAC).......................14 67 4.3. ID payload (ID)..........................................15 68 4.4. General Extension Payload................................15 69 5. Security Considerations....................................16 70 5.1. Security environment.....................................16 71 5.2. Threat model.............................................16 72 5.3. Security features and properties.........................19 73 5.4. Assumptions..............................................23 74 5.5. Residual risk............................................24 75 5.6. Authorization and Trust Model............................26 76 6. Acknowledgments............................................26 77 7. IANA considerations........................................26 78 8. References.................................................27 79 8.1 Normative References.......................................27 80 8.2 Informative References...................................27 81 Appendix A Usage of MIKEY-DHHMAC in H.235......................30 82 Full Copyright Statement........................................33 83 Expiration Date.................................................34 84 Revision History................................................34 85 Author's Addresses..............................................37 87 1. 88 Introduction 90 There is work done in IETF to develop key management schemes. For 91 example, IKE [14] is a widely accepted unicast scheme for IPsec, and 92 the MSEC WG is developing other schemes, addressed to group 93 communication [24], [25]. For reasons discussed below, there is 94 however a need for a scheme with low latency, suitable for demanding 95 cases such as real-time data over heterogeneous networks, and small 96 interactive groups. 98 As pointed out in MIKEY (see [3]), secure real-time multimedia 99 applications demand a particular adequate light-weight key management 100 scheme that cares for how to securely and efficiently establish 101 dynamic session keys in a conversational multimedia scenario. 103 In general, MIKEY scenarios cover peer-to-peer, simple-one-to-many 104 and small-sized groups. MIKEY in particular, describes three key 105 management schemes for the peer-to-peer case that all finish their 106 task within one round trip: 107 - a symmetric key distribution protocol (MIKEY-PS) based upon 108 pre-shared master keys; 110 - a public-key encryption-based key distribution protocol 111 (MIKEY-PK) assuming a public-key infrastructure with RSA-based 112 (Rivest, Shamir and Adleman) private/public keys and digital 113 certificates; 115 - and a Diffie-Hellman key agreement protocol (MIKEY-DHSIGN) 116 deploying digital signatures and certificates. 118 All these three key management protocols are designed such that they 119 complete their work within just one round trip. This requires 120 depending on loosely synchronized clocks and deploying timestamps 121 within the key management protocols. 123 However, it is known [7] that each of the three key management 124 schemes has its subtle constraints and limitations: 126 - The symmetric key distribution protocol (MIKEY-PS) is simple 127 to implement, however, was not intended to scale to support 128 any configurations beyond peer-to-peer, simple one-to-many, 129 and small-size (interactive) groups, due to the need of 130 mutually pre-assigned shared master secrets. 132 Moreover, the security provided does not achieve the property 133 of perfect forward secrecy; i.e. compromise of the shared 134 master secret would render past and even future session keys 135 susceptible to compromise. 137 Further, the generation of the session key happens just at the 138 initiator. Thus, the responder has to fully trust the 139 initiator on choosing a good and secure session secret; the 140 responder neither is able to participate in the key generation 141 nor to influence that process. This is considered as a 142 specific limitation in less trusted environments. 144 - The public-key encryption scheme (MIKEY-PK) depends upon a 145 public-key infrastructure that certifies the private-public 146 keys by issuing and maintaining digital certificates. While 147 such a key management scheme provides full scalability in 148 large networked configurations, public-key infrastructures are 149 still not widely available and in general, implementations are 150 significantly more complex. 152 Further, additional round trips and computational processing 153 might be necessary for each end system in order to ascertain 154 verification of the digital certificates. For example, 155 typical operations in the context of a public-key 156 infrastructure such as validating digital certificates (RFC 157 3029, [31]), ascertaining the revocation status of digital 158 certificates (RFC 2560, [30]) and asserting certificate 159 policies, construction of certification path(s) ([33]), 160 requesting and obtaining necessary certificates (RFC 2511, 161 [32]) and management of certificates for such purposes ([29]) 162 may involve extra network communication handshakes with the 163 public-key infrastructure and with certification authorities 164 and may typically involve additional processing steps in the 165 end systems. Such steps and tasks all result in further delay 166 of the key agreement or key establishment phase among the end 167 systems, negatively impacting setup time. Any extra PKI 168 handshakes and processing are not in scope of MIKEY and since 169 this document deploys symmetric security mechanisms only, 170 aspects of PKI, digital certificates and related processing 171 are not further covered in this document. 173 Finally, as in the symmetric case, the responder depends 174 completely upon the initiator choosing good and secure session 175 keys. 177 - The third MIKEY-DHSIGN key management protocol deploys the 178 Diffie-Hellman key agreement scheme and authenticates the 179 exchange of the Diffie-Hellman half-keys in each direction by 180 using a digital signature. This approach has the same 181 advantages and deficiencies as described in the previous 182 section in terms of a public-key infrastructure. 184 However, the Diffie-Hellman key agreement protocol is known 185 for its subtle security strengths in that it is able to 186 provide full perfect forward secrecy (PFS) and further have 187 both parties actively involved in session key generation. 188 This special security property - despite the somewhat higher 189 computational costs - makes Diffie-Hellman techniques 190 attractive in practice. 192 In order to overcome some of the limitations as outlined above, a 193 special need has been recognized for another efficient key agreement 194 protocol variant in MIKEY. This protocol variant aims to provide the 195 capability of perfect forward secrecy as part of a key agreement with 196 low latency without dependency on a public-key infrastructure. 198 This document describes such a fourth light-weight key management 199 scheme for MIKEY that could somehow be seen as a synergetic 200 optimization between the pre-shared key distribution scheme and the 201 Diffie-Hellman key agreement. 203 The idea of the protocol in this document is to apply the Diffie- 204 Hellman key agreement, but rather than deploying a digital signature 205 for authenticity of the exchanged keying material, instead uses a 206 keyed-hash upon using symmetrically pre-assigned shared secrets. 207 This combination of security mechanisms is called the HMAC- 208 authenticated Diffie-Hellman (DH) key agreement for MIKEY (DHHMAC). 210 The DHHMAC variant closely follows the design and philosophy of MIKEY 211 and reuses MIKEY protocol payload components and MIKEY mechanisms to 212 its maximum benefit and for best compatibility. 214 Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond 215 a point-to-point constellation; thus, both MIKEY Diffie-Hellman 216 protocols do not support group-based keying for any group size larger 217 than two entities. 219 1.1. Definitions 221 The definitions and notations in this document are aligned with 222 MIKEY, see [3], sections 1.3 - 1.4. 224 All large integer computations in this document should be understood 225 as being mod p within some fixed group G for some large prime p; see 227 [3] section 3.3; however, the DHHMAC protocol is applicable in 228 general to other appropriate finite, cyclical groups as well. 230 It is assumed that a pre-shared key s is known by both entities 231 (initiator and responder). The authentication key auth_key is 232 derived from the pre-shared secret s using the pseudo-random function 233 PRF; see [3] sections 4.1.3 and 4.1.5. 235 In this text, [X] represents an optional piece of information. 236 Generally throughout the text, X SHOULD be present unless certain 237 circumstance MAY allow X being optional and not be present thereby 238 resulting in weaker security potentially. Likewise [X, Y] represents 239 an optional compound piece of information where the pieces X and Y 240 SHOULD be either both present or MAY optionally be both absent. {X} 241 denotes zero or more occurrences of X. 243 1.2. Abbreviations 245 auth_key pre-shared authentication key, PRF-derived from 246 pre-shared key s. 247 DH Diffie-Hellman 248 DHi public Diffie-Hellman half key g^(xi) of the 249 Initiator 250 DHr public Diffie-Hellman half key g^(xr) of the 251 Responder 252 DHHMAC HMAC-authenticated Diffie-Hellman 253 DoS Denial-of-service 254 G Diffie-Hellman group 255 HDR MIKEY common header payload 256 HMAC keyed Hash Message Authentication Code 257 HMAC-SHA1 HMAC using SHA1 as hash function (160-bit result) 258 IDi Identity of initiator 259 IDr Identity of receiver 260 IKE Internet Key Exchange 261 IPsec Internet Protocol Security 262 MIKEY Multimedia Internet KEYing 263 MIKEY-DHHMAC MIKEY Diffie-Hellman key management protocol using 264 HMAC 265 MIKEY-DHSIGN MIKEY Diffie-Hellman key agreement protocol 266 MIKEY-PK MIKEY public-key encryption-based key distribution 267 protocol 268 MIKEY-PS MIKEY pre-shared key distribution protocol 269 p Diffie-Hellman prime modulus 270 PKI Public-key Infrastructure 271 PRF MIKEY pseudo-random function (see [3] section 272 4.1.3.) 273 RSA Rivest, Shamir and Adleman 274 s pre-shared key 275 SDP Session Description Protocol 276 SOI Son-of-IKE, IKEv2 277 SP MIKEY Security Policy (Parameter) Payload 278 T timestamp 279 TEK Traffic Encryption Key 280 TGK MIKEY TEK Generation Key as the common Diffie- 281 Hellman shared secret 282 TLS Transport Layer Security 283 xi secret, (pseudo) random Diffie-Hellman key of the 284 Initiator 285 xr secret, (pseudo) random Diffie-Hellman key of the 286 Responder 288 2. 289 Scenario 291 The HMAC-authenticated Diffie-Hellman key agreement protocol (DHHMAC) 292 for MIKEY addresses the same scenarios and scope as the other three 293 key management schemes in MIKEY address. 295 DHHMAC is applicable in a peer-to-peer group where no access to a 296 public-key infrastructure can be assumed available. Rather, pre- 297 shared master secrets are assumed available among the entities in 298 such an environment. 300 In a pair-wise group, it is assumed that each client will be setting 301 up a session key for its outgoing links with its peer using the DH- 302 MAC key agreement protocol. 304 As is the case for the other three MIKEY key management protocols, 305 DHHMAC assumes, at least, loosely synchronized clocks among the 306 entities in the small group. 308 To synchronize the clocks in a secure manner, some operational or 309 procedural means are recommended. MIKEY-DHHMAC does not define any 310 secure time synchronization measures, however, sections 5.4 and 9.3 311 of [3] provide implementation guidance on clock synchronization and 312 timestamps. 314 2.1. Applicability 316 MIKEY-DHHMAC, as well as the other MIKEY key management protocols, is 317 intended for application-level key management and is optimized for 318 multimedia applications with real-time session setup and session 319 management constraints. 321 As the MIKEY-DHHMAC key management protocol terminates in one 322 roundtrip, DHHMAC is applicable for integration into two-way 323 handshake session- or call signaling protocols such as 325 a) SIP/SDP where the encoded MIKEY messages are encapsulated and 326 transported in SDP containers of the SDP offer/answer [RFC 3264] 327 handshake as described in [5], 328 b) H.323 (see [22]) where the encoded MIKEY messages are transported 329 in the H.225.0 fast start call signaling handshake. Appendix A 330 outlines the usage of MIKEY-DHHMAC within H.235. 332 MIKEY-DHHMAC is offered as option to the other MIKEY key management 333 variants (MIKEY-pre-shared, MIKEY-public-key and MIKEY-DH-SIGN) for 334 all those cases where DHHMAC has its particular strengths (see 335 section 5). 337 2.2. Relation to GKMARCH 339 The Group key management architecture (GKMARCH) [26] describes a 340 generic architecture for multicast security group key management 341 protocols. In the context of this architecture, MIKEY-DHHMAC may 342 operate as a registration protocol, see also [3] section 2.4. The 343 main entities involved in the architecture are a group 344 controller/key server (GCKS), the receiver(s), and the sender(s). 345 Due to the pair-wise nature of the Diffie-Hellman operation and 346 the 1-roundtrip constraint, usage of MIKEY-DHHMAC rules out any 347 deployment as a group key management protocol with more than two 348 group entities. Only the degenerate case with two peers is 349 possible where for example the responder acts as the group 350 controller. 352 Note that MIKEY does not provide re-keying in the GKMARCH sense, 353 only updating of the keys by normal unicast messages. 355 3. 356 DHHMAC Security Protocol 358 The following figure defines the security protocol for DHHMAC: 360 Initiator Responder 362 I_message = HDR, T, RAND, [IDi], IDr, 363 {SP}, DHi, KEMAC 364 -----------------------> R_message = HDR, T, 365 [IDr], IDi, DHr, 366 DHi, KEMAC 367 <---------------------- 369 Figure 1: HMAC-authenticated Diffie-Hellman key based exchange, 370 where xi and xr are (pseudo) randomly chosen respectively 371 by the initiator and the responder. 373 The DHHMAC key exchange SHALL be done according to Figure 1. The 374 initiator chooses a (pseudo) random value xi, and sends an HMACed 375 message including g^(xi) and a timestamp to the responder. It is 376 recommended that the initiator SHOULD always include the identity 377 payloads IDi and IDr within the I_message; unless the receiver can 378 defer the initiator's identity by some other means, then IDi MAY 379 optionally be omitted. The initiator SHALL always include the 380 recipient's identity. 382 The group parameters (e.g., the group G) are a set of parameters 383 chosen by the initiator. Note, that like in the MIKEY protocol, 384 both sender and receiver explicitly transmit the Diffie-Hellman 385 group G within the Diffie-Hellman payload DHi or DHr through an 386 encoding (e.g., OAKLEY group numbering, see [3] section 6.4); the 387 actual group parameters g and p however are not explicitly 388 transmitted but can be deduced from the Diffie-Hellman group G. 389 The responder chooses a (pseudo) random positive integer xr, and 390 sends an HMACed message including g^(xr) and the timestamp to the 391 initiator. The responder SHALL always include the initiator's 392 identity IDi regardless of whether the I_message conveyed any IDi. 393 It is RECOMMENDED that the responder SHOULD always include the 394 identity payload IDr within the R_message; unless the initiator 395 can defer the responder's identity by some other means, then IDr 396 MAY optionally be left out. 398 Both parties then calculate the TGK as g^(xi * xr). 400 The HMAC authentication provides authentication of the DH half- 401 keys, and is necessary to avoid man-in-the-middle attacks. 403 This approach is less expensive than digitally signed Diffie- 404 Hellman in that both sides compute first one exponentiation and 405 one HMAC, then one HMAC verification and finally another Diffie- 406 Hellman exponentiation. 408 With off-line pre-computation, the initial Diffie-Hellman half-key 409 MAY be computed before the key management transaction and thereby 410 MAY further reduce the overall round trip delay as well as reduce 411 the risk of denial-of-service attacks. 413 Processing of the TGK SHALL be accomplished as described in MIKEY 414 [3] chapter 4. 416 The computed HMAC result SHALL be conveyed in the KEMAC payload 417 field where the MAC fields holds the HMAC result. The HMAC SHALL 418 be computed over the entire message excluding the MAC field using 419 auth_key, see also section 4.2. 421 3.1. TGK re-keying 423 TGK re-keying for DHHMAC generally proceeds as described in [3] 424 section 4.5. Specifically, figure 2 provides the message exchange 425 for the DHHMAC update message. 427 Initiator Responder 429 I_message = HDR, T, [IDi], IDr, 430 {SP}, [DHi], KEMAC 431 -----------------------> R_message = HDR, T, 432 [IDr], IDi, 433 [DHr, DHi], KEMAC 434 <---------------------- 436 Figure 2: DHHMAC update message 438 TGK re-keying supports two procedures: 439 a) True re-keying by exchanging new and fresh Diffie-Hellman half- 440 keys. For this, the initiator SHALL provide a new, fresh DHi 441 and the responder SHALL respond with a new, fresh DHr and the 442 received DHi. 444 b) Non-key related information update without any Diffie-Hellman 445 half-keys included in the exchange. Such transaction does not 446 change the actual TGK but updates other information like 447 security policy parameters for example. To only update the 448 non-key related information, [DHi] and [DHr, DHi] SHALL be left 449 out. 451 4. 452 DHHMAC payload formats 454 This section specifies the payload formats and data type values for 455 DHHMAC, see also [3] chapter 6 for a definition of the MIKEY 456 payloads. 458 This document does not define new payload formats but re-uses MIKEY 459 payloads for DHHMAC as referenced: 461 * Common header payload (HDR), see section 4.1 and [3] section 6.1 463 * SRTP ID sub-payload, see [3] section 6.1.1, 465 * Key data transport payload (KEMAC), see section 4.2 and [3] section 466 6.2 468 * DH data payload, see [3] section 6.4 470 * Timestamp payload, [3] section 6.6 472 * ID payload, [3] section 6.7 474 * Security Policy payload (SP), [3] section 6.10 476 * RAND payload (RAND), [3] section 6.11 478 * Error payload (ERR), [3] section 6.12 480 * General Extension Payload, [3] section 6.15 482 4.1. Common header payload (HDR) 484 Referring to [3] section 6.1, for DHHMAC the following data types 485 SHALL be used: 487 Data type | Value | Comment 488 ------------------------------------------------------------- 489 DHHMAC init | 7 | Initiator's DHHMAC exchange message 490 DHHMAC resp | 8 | Responder's DHHMAC exchange message 491 Error | 6 | Error message, see [3] section 6.12 493 Table 4.1.a 495 Note: A responder is able to recognize the MIKEY DHHMAC protocol 496 by evaluating the data type field as 7 or 8. This is how the 497 responder can differentiate between MIKEY and MIKEY DHHMAC. 499 The next payload field SHALL be one of the following values: 500 Next payload| Value | Section 501 ---------------------------------------------------------------- 502 Last payload| 0 | - 503 KEMAC | 1 | section 4.2 and [3] section 6.2 504 DH | 3 | [3] section 6.4 505 T | 5 | [3] section 6.6 506 ID | 6 | [3] section 6.7 507 SP | 10 | [3] section 6.10 508 RAND | 11 | [3] section 6.11 509 ERR | 12 | [3] section 6.12 510 General Ext.| 21 | [3] section 6.15 512 Table 4.1.b 514 Other defined next payload values defined in [3] SHALL not be 515 applied to DHHMAC. 517 The responder in case of a decoding error or of a failed HMAC 518 authentication verification SHALL apply the Error payload data 519 type. 521 4.2. Key data transport payload (KEMAC) 523 DHHMAC SHALL apply this payload for conveying the HMAC result 524 along with the indicated authentication algorithm. KEMAC when used 525 in conjunction with DHHMAC SHALL not convey any encrypted data; 526 thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set 527 to 0 and Encr data SHALL be left empty. The AES key wrap method 528 (see [23]) SHALL not be applied for DHHMAC. 530 For DHHMAC, this key data transport payload SHALL be the last 531 payload in the message. Note that the Next payload field SHALL be 532 set to Last payload. The HMAC is then calculated over the entire 533 MIKEY message excluding the MAC field using auth_key as described 534 in [3] section 5.2 and then stored within the MAC field. 536 MAC alg | Value | Comments 537 ------------------------------------------------------------------ 538 HMAC-SHA-1 | 0 | Mandatory, Default (see [4]) 539 NULL | 1 | Very restricted use, see 540 | [3] section 4.2.4 542 Table 4.2.a 544 HMAC-SHA-1 is the default hash function that MUST be implemented 545 as part of the DHHMAC. The length of the HMAC-SHA-1 result is 160 546 bits. 548 4.3. ID payload (ID) 550 For DHHMAC, this payload SHALL only hold a non-certificate based 551 identity. 553 4.4. General Extension Payload 555 For DHHMAC and to avoid bidding-down attacks, this payload SHALL 556 list all key management protocol identifiers of a surrounding 557 encapsulation protocol such as for example, SDP [5]. The General 558 Extension Payload SHALL be integrity-protected with the HMAC using 559 the shared secret. 561 Type | Value | Comments 562 SDP IDs | 1 | List of SDP key management IDs (allocated for 563 use in [5]); see also [3] section 6.15. 565 Table 4.4.a 567 5. 568 Security Considerations 570 This document addresses key management security issues throughout. 571 For a comprehensive explanation of MIKEY security considerations, 572 please refer to MIKEY [3] section 9. 574 In addition to that, this document addresses security issues 575 according to [8] where the following security considerations apply in 576 particular to this document: 578 5.1. Security environment 580 Generally, the DHHMAC security protocol described in this document 581 focuses primarily on communication security; i.e. the security issues 582 concerned with the MIKEY DHHMAC protocol. Nevertheless, some system 583 security issues are of interest as well that are not explicitly 584 defined by the DHHMAC protocol, but should be provided locally in 585 practice. 587 The system that runs the DHHMAC protocol entity SHALL provide the 588 capability to generate (pseudo) random numbers as input to the 589 Diffie-Hellman operation (see [9], [15]). Furthermore, the system 590 SHALL be capable of storing the generated (pseudo) random data, 591 secret data, keys and other secret security parameters securely (i.e. 592 confidential and safe from unauthorized tampering). 594 5.2. Threat model 596 The threat model, to which this document adheres, covers the issues 597 of end-to-end security in the Internet generally, without ruling out 598 the possibility that MIKEY DHHMAC can be deployed in a corporate, 599 closed IP environment. This also includes the possibility that MIKEY 600 DHHMAC can be deployed on a hop-by-hop basis with some intermediate 601 trusted "MIKEY DHHMAC proxies" involved. 603 Since DHHMAC is a key management protocol, the following security 604 threats are of concern: 606 * Unauthorized interception of plain TGKs: 607 For DHHMAC this threat does not occur since the TGK is not actually 608 transmitted on the wire (not even in encrypted fashion). 610 * Eavesdropping of other, transmitted keying information: 611 DHHMAC protocol does not explicitly transmit the TGK at all. 612 Instead, by using the Diffie-Hellman "encryption" operation, which 613 conceals the secret (pseudo) random values, only partial 614 information (i.e. the DH- half key) for construction of the TGK is 615 transmitted. It is fundamentally assumed that availability of such 616 Diffie-Hellman half-keys to an eavesdropper does not result in any 617 substantial security risk; see 5.4. Furthermore, the DHHMAC 618 carries other data such as timestamps, (pseudo) random values, 619 identification information or security policy parameters; 620 eavesdropping of any such data is considered not to yield any 621 significant security risk. 623 * Masquerade of either entity: 624 This security threat must be avoided and if a masquerade attack 625 would be attempted, appropriate detection means must be in place. 626 DHHMAC addresses this threat by providing mutual peer entity 627 authentication. 629 * Man-in-the-middle attacks: 630 Such attacks threaten the security of exchanged, non-authenticated 631 messages. Man-in-the-middle attacks usually come with masquerade 632 and or loss of message integrity (see below). Man-in-the-middle 633 attacks must be avoided, and if present or attempted must be 634 detected appropriately. DHHMAC addresses this threat by providing 635 mutual peer entity authentication and message integrity. 637 * Loss of integrity: 638 This security threat relates to unauthorized replay, deletion, 639 insertion and manipulation of messages. While any such attacks 640 cannot be avoided they must be detected at least. DHHMAC addresses 641 this threat by providing message integrity. 643 * Bidding-down attacks: 645 When multiple key management protocols each of a distinct security 646 level are offered (e.g., such as is possible by SDP [5]), avoiding 647 bidding-down attacks is of concern. DHHMAC addresses this threat 648 by reusing the MIKEY General Extension Payload mechanism, where 649 all key management protocol identifiers are be listed within the 650 MIKEY General Extension Payload. 652 Some potential threats are not within the scope of this threat model: 654 * Passive and off-line cryptanalysis of the Diffie-Hellman algorithm: 655 Under certain reasonable assumptions (see 5.4 below) it is widely 656 believed that DHHMAC is sufficiently secure and that such attacks 657 are infeasible, although the possibility of a successful attack 658 cannot be ruled out. 660 * Non-repudiation of the receipt or of the origin of the message: 661 These are not requirements within the context of DHHMAC in this 662 environment and thus related countermeasures are not provided at 663 all. 665 * Denial-of-service or distributed denial-of-service attacks: 666 Some considerations are given on some of those attacks, but DHHMAC 667 does not claim to provide full countermeasure against any of those 668 attacks. For example, stressing the availability of the entities 669 are not thwarted by means of the key management protocol; some 670 other local countermeasures should be applied. Further, some DoS 671 attacks are not countered such as interception of a valid DH- 672 request and its massive instant duplication. Such attacks might at 673 least be countered partially by some local means that are outside 674 the scope of this document. 676 * Identity protection: 677 Like MIKEY, identity protection is not a major design requirement 678 for MIKEY-DHHMAC either, see [3]. No security protocol is known so 679 far, that is able to provide the objectives of DHHMAC as stated in 680 section 5.3 including identity protection within just a single 681 roundtrip. MIKEY-DHHMAC trades identity protection for better 682 security for the keying material and shorter roundtrip time. Thus, 683 MIKEY-DHHMAC does not provide identity protection on its own but 684 may inherit such property from a security protocol underneath that 685 actually features identity protection. 687 The DHHMAC security protocol (see section 3) and the TGK re-keying 688 security protocol (see section 3.1) provide the option not to 689 supply identity information. This option is only applicable if 690 some other means are available of supplying trustworthy identity 691 information; e.g., by relying on secured links underneath of MIKEY 692 that supply trustworthy identity information otherwise. However, 693 it is understood that without identity information present, the 694 MIKEY key management security protocols might be subject to 695 security weaknesses such as masquerade, impersonation and 696 reflection attacks particularly in end-to-end scenarios where no 697 other secure means of assured identity information is provided. 699 Leaving identity fields optional if possible thus should not be 700 seen as a privacy method either, but rather as a protocol 701 optimization feature. 703 5.3. Security features and properties 705 With the security threats in mind, this draft provides the following 706 security features and yields the following properties: 708 * Secure key agreement with the establishment of a TGK at both peers: 709 This is achieved using an authenticated Diffie-Hellman key 710 management protocol. 712 * Peer-entity authentication (mutual): 713 This authentication corroborates that the host/user is authentic in 714 that possession of a pre-assigned secret key is proven using keyed 715 HMAC. Authentication occurs on the request and on the response 716 message, thus authentication is mutual. 718 The HMAC computation corroborates for authentication and message 719 integrity of the exchanged Diffie-Hellman half-keys and associated 720 messages. The authentication is absolutely necessary in order to 721 avoid man-in-the-middle attacks on the exchanged messages in 722 transit and in particular, on the otherwise non-authenticated 723 exchanged Diffie-Hellman half keys. 725 Note: This document does not address issues regarding 726 authorization; this feature is not provided explicitly. However, 727 DHHMAC authentication means support and facilitate realization of 728 authorization means (local issue). 730 * Cryptographic integrity check: 731 The cryptographic integrity check is achieved using a message 732 digest (keyed HMAC). It includes the exchanged Diffie-Hellman 733 half-keys but covers the other parts of the exchanged message as 734 well. Both mutual peer entity authentication and message integrity 735 provide effective countermeasures against man-in-the-middle 736 attacks. 738 The initiator may deploy a local timer that fires when the awaited 739 response message did not arrive in a timely manner. This is to 740 detect deletion of entire messages. 742 * Replay protection of the messages is achieved using embedded 743 timestamps. In order to detect replayed messages it is essential 744 that the clocks among initiator and sender be roughly synchronized. 745 The reader is referred to [3] section 5.4 and [3] section 9.3 that 746 provide further considerations and give guidance on clock 747 synchronization and timestamp usage. Should the clock 748 synchronization be lost, then end systems cannot detect replayed 749 messages anymore resulting that the end systems cannot securely 750 establish keying material. This may result in a denial-of-service, 751 see [3] section 9.5. 753 * Limited DoS protection: 754 Rapid checking of the message digest allows verifying the 755 authenticity and integrity of a message before launching CPU 756 intensive Diffie-Hellman operations or starting other resource 757 consuming tasks. This protects against some denial-of-service 758 attacks: malicious modification of messages and spam attacks with 759 (replayed or masqueraded) messages. DHHMAC probably does not 760 explicitly counter sophisticated distributed, large-scale denial- 761 of-service attacks that compromise system availability for example. 762 Some DoS protection is provided by inclusion of the initiator's 763 identity payload in the I_message. This allows the recipient to 764 filter out those (replayed) I_messages that are not targeted for 765 him and avoids the recipient from creating unnecessary MIKEY 766 sessions. 768 * Perfect-forward secrecy (PFS): 769 Other than the MIKEY pre-shared and public-key based key 770 distribution protocols, the Diffie-Hellman key agreement protocol 771 features a security property called perfect forward secrecy. That 772 is, that even if the long-term pre-shared key would be compromised 773 at some point in time, this would not render past or future session 774 keys compromised. 776 Neither the MIKEY pre-shared nor the MIKEY public-key protocol 777 variants are able to provide the security property of perfect- 778 forward secrecy. Thus, none of the other MIKEY protocols is able 779 to substitute the Diffie-Hellman PFS property. 781 As such, DHHMAC, as well as digitally signed DH, provides a far 782 superior security level over the pre-shared or public-key based key 783 distribution protocol in that respect. 785 * Fair, mutual key contribution: 786 The Diffie-Hellman key management protocol is not a strict key 787 distribution protocol per se with the initiator distributing a key 788 to its peers. Actually, both parties involved in the protocol 789 exchange are able to equally contribute to the common Diffie- 790 Hellman TEK traffic generating key. This reduces the risk of 791 either party cheating or unintentionally generating a weak session 792 key. This makes the DHHMAC a fair key agreement protocol. One may 793 view this property as an additional distributed security measure 794 that is increasing security robustness over the case where all the 795 security depends just on the proper implementation of a single 796 entity. 798 In order for Diffie-Hellman key agreement to be secure, each party 799 SHALL generate its xi or xr values using a strong, unpredictable 800 pseudo-random generator if a source of true randomness is not 801 available. Further, these values xi or xr SHALL be kept private. 802 It is RECOMMENDED that these secret values be destroyed once the 803 common Diffie-Hellman shared secret key has been established. 805 * Efficiency and performance: 806 Like the MIKEY-public key protocol, the MIKEY DHHMAC key agreement 807 protocol securely establishes a TGK within just one roundtrip. 808 Other existing key management techniques like IPsec-IKE [14], 809 IPsec-IKEv2 [21] and TLS [13] and other schemes are not deemed 810 adequate in addressing sufficiently those real-time and security 811 requirements; they all use more than a single roundtrip. All the 812 MIKEY key management protocols are able to complete their task of 813 security policy parameter negotiation including key-agreement or 814 key distribution in one roundtrip. However, the MIKEY pre-shared 815 and the MIKEY public-key protocol both are able to complete their 816 task even in a half-round trip when the confirmation messages are 817 omitted. 819 Using HMAC in conjunction with a strong one-way hash function such 820 as SHA1 may be achieved more efficiently in software than expensive 821 public-key operations. This yields a particular performance 822 benefit of DHHMAC over signed DH or the public-key encryption 823 protocol. 825 If a very high security level is desired for long-term secrecy of 826 the negotiated Diffie-Hellman shared secret, longer hash values may 827 be deployed such as SHA256, SHA384 or SHA512 provide, possibly in 828 conjunction with stronger Diffie-Hellman groups. This is left as 829 for further study. 831 For the sake of improved performance and reduced round trip delay 832 either party may off-line pre-compute its public Diffie-Hellman 833 half-key. 835 On the other side and under reasonable conditions, DHHMAC consumes 836 more CPU cycles than the MIKEY pre-shared key distribution 837 protocol. The same might hold true quite likely for the MIKEY 838 public-key distribution protocol (depending on choice of the 839 private and public key lengths). 841 As such, it can be said that DHHMAC provides sound performance when 842 compared with the other MIKEY protocol variants. 844 The use of optional identity information (with the constraints 845 stated in section 5.2) and optional Diffie-Hellman half-key fields 846 provides a means to increase performance and shorten the consumed 847 network bandwidth. 849 * Security infrastructure: 850 This document describes the HMAC-authenticated Diffie-Hellman key 851 agreement protocol that completely avoids digital signatures and 852 the associated public-key infrastructure as would be necessary for 853 the X.509 RSA public-key based key distribution protocol or the 854 digitally signed Diffie-Hellman key agreement protocol as described 855 in MIKEY. Public-key infrastructures may not always be available 856 in certain environments nor may they be deemed adequate for real- 857 time multimedia applications when taking additional steps for 858 certificate validation and certificate revocation methods with 859 additional round-trips into account. 861 DHHMAC does not depend on PKI nor do implementations require PKI 862 standards and thus is believed to be much simpler than the more 863 complex PKI facilities. 865 DHHMAC is particularly attractive in those environments where 866 provisioning of a pre-shared key has already been accomplished. 868 * NAT-friendliness: 869 DHHMAC is able to operate smoothly through firewall/NAT devices as 870 long as the protected identity information of the end entity is not 871 an IP /transport address. 873 * Scalability: 874 Like the MIKEY signed Diffie-Hellman protocol, DHHMAC does not 875 scale to any larger configurations beyond peer-to-peer groups. 877 5.4. Assumptions 878 This document states a couple of assumptions upon which the security 879 of DHHMAC significantly depends. It is assumed, that 881 * the parameters xi, xr, s and auth_key are to be kept secret. 883 * the pre-shared key s has sufficient entropy and cannot be 884 effectively guessed. 886 * the pseudo-random function (PRF) is secure, yields indeed the 887 pseudo-random property and maintains the entropy. 889 * a sufficiently large and secure Diffie-Hellman group is applied. 891 * the Diffie-Hellman assumption holds saying basically that even with 892 knowledge of the exchanged Diffie-Hellman half-keys and knowledge 893 of the Diffie-Hellman group, it is infeasible to compute the TGK or 894 to derive the secret parameters xi or xr. The latter is also 895 called the discrete logarithm assumption. Please see [7], [11] or 896 [12] for more background information regarding the Diffie-Hellman 897 problem and its computational complexity assumptions. 899 * the hash function (SHA1) is secure; i.e. that it is computationally 900 infeasible to find a message which corresponds to a given message 901 digest, or to find two different messages that produce the same 902 message digest. 904 * the HMAC algorithm is secure and does not leak the auth_key. In 905 particular, the security depends on the message authentication 906 property of the compression function of the hash function H when 907 applied to single blocks (see [6]). 909 * a source capable of producing sufficiently many bits of (pseudo) 910 randomness is available. 912 * the system upon which DHHMAC runs is sufficiently secure. 914 5.5. Residual risk 915 Although these detailed assumptions are non-negligible, security 916 experts generally believe that all these assumptions are reasonable 917 and that the assumptions made can be fulfilled in practice with 918 little or no expenses. 920 The mathematical and cryptographic assumptions of the properties of 921 the PRF, the Diffie-Hellman algorithm (discrete log-assumption), the 922 HMAC algorithm and SHA1 algorithms have been neither proven or 923 disproven at this time. 925 Thus, a certain residual risk remains, which might threaten the 926 overall security at some unforeseeable time in the future. 928 The DHHMAC would be compromised as soon as any of the listed 929 assumptions do not hold anymore. 931 The Diffie-Hellman mechanism is a generic security technique that is 932 not only applicable to groups of prime order or of characteristic 933 two. This is because of the fundamental mathematical assumption that 934 the discrete logarithm problem is also a very hard one in general 935 groups. This enables Diffie-Hellman to be deployed also for GF(p)*, 936 for sub-groups of sufficient size and for groups upon elliptic 937 curves. RSA does not allow such generalization, as the core 938 mathematical problem is a different one (large integer 939 factorization). 941 RSA asymmetric keys tend to become increasingly lengthy (1536 bits 942 and more) and thus very computationally intensive. Nevertheless, 943 elliptic curve Diffie-Hellman (ECDH) allows to cut-down key lengths 944 substantially (say 170 bits or more) while maintaining at least the 945 security level and providing even more significant performance 946 benefits in practice. Moreover, it is believed that elliptic curve 947 techniques provide much better protection against side channel 948 attacks due to the inherent redundancy in the projective coordinates. 949 For all these reasons, one may view elliptic-curve-based Diffie- 950 Hellman as being more "future-proof" and robust against potential 951 threats than RSA. Note, that an elliptic-curve Diffie-Hellman 952 variant of MIKEY remains for further study. 954 It is not recommended to deploy DHHMAC for any other usage than 955 depicted in section 2. Otherwise any such misapplication might lead 956 to unknown, undefined properties. 958 5.6. Authorization and Trust Model 960 Basically, similar remarks on authorization as stated in [3] section 961 4.3.2. hold also for DHHMAC. However, as noted before, this key 962 management protocol does not serve full groups. 964 One may view the pre-established shared secret to yield some pre- 965 established trust relationship between the initiator and the 966 responder. This results in a much simpler trust model for DHHMAC 967 than would be the case for some generic group key management protocol 968 and potential group entities without any pre-defined trust 969 relationship. The common group controller in conjunction with the 970 assumption of a shared key simplifies the communication setup of the 971 entities. 973 One may view the pre-established trust relationship through the pre- 974 shared secret as some means for pre-granted, implied authorization. 975 This document does not define any particular authorization means but 976 leaves this subject to the application. 978 6. Acknowledgments 980 This document incorporates kindly valuable review feedback from 981 Steffen Fries, Hannes Tschofenig, Fredrick Lindholm, Mary Barnes and 982 Russell Housley and general feedback by the MSEC WG. 984 7. IANA considerations 986 This document does not define its own new name spaces for DHHMAC, 987 beyond the IANA name spaces that have been assigned for MIKEY, see 988 [3] section 10 and section 10.1, see also IANA MIKEY payload name 989 spaces [37]. 991 In order to align Table 4.1.a with [3] table 6.1.a, IANA is 992 requested to add the following entries to their MIKEY Payload Name 993 Space: 995 Data Type Value Reference 997 --------------- ----- --------- 999 DHHMAC init 7 [RFCxxxx] 1000 DHHMAC resp 8 [RFCxxxx] 1002 [Note to the RFC editor: Please replace RFCxxxx with the RFC number of 1003 this document prior to publication.] 1005 8. References 1006 8.1 Normative References 1008 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 1009 BCP 9, RFC 2026, October 1996. 1011 [2] Bradner, S., "Key words for use in RFCs to Indicate 1012 Requirement Levels", BCP 14, RFC 2119, March 1997. 1014 [3] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman; 1015 "MIKEY: Multimedia Internet KEYing", RFC 3830 IETF, August 2004. 1017 [4] NIST, FIBS-PUB 180-1, "Secure Hash Standard", April 1995, 1018 http://csrc.nist.gov/fips/fip180-1.ps. 1020 [5] J. Arkko, E. Carrara et al: "Key Management Extensions for SDP 1021 and RTSP", Internet Draft , 1022 Work in Progress (MMUSIC WG), IETF, March 2005. 1024 [6] H. Krawczyk, M. Bellare, R. Canetti: "HMAC: Keyed-Hashing for 1025 Message Authentication", RFC 2104, February 1997. 1027 8.2 Informative References 1029 [7] A.J. Menezes, P. van Oorschot, S. A. Vanstone: "Handbook of 1030 Applied Cryptography", CRC Press 1996. 1032 [8] E. Rescorla, B. Korver: " Guidelines for Writing RFC Text on 1033 Security Considerations", RFC 3552, IETF, July 2003. 1035 [9] D. Eastlake, S. Crocker: "Randomness Recommendations for 1036 Security", RFC 1750, IETF, December 1994. 1038 [10] S.M. Bellovin, C. Kaufman, J. I. Schiller: "Security 1039 Mechanisms for the Internet", RFC 3631, IETF, December 2003. 1041 [11] Ueli M. Maurer, S. Wolf: "The Diffie-Hellman Protocol", 1042 Designs, Codes, and Cryptography, Special Issue Public Key 1043 Cryptography, Kluwer Academic Publishers, vol. 19, pp. 147-171, 1044 2000. ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol00c.ps 1046 [12] Discrete Logarithms and the Diffie-Hellman Protocol; 1047 http://www.crypto.ethz.ch/research/ntc/dldh/ 1049 [13] T. Dierks, C. Allen: "The TLS Protocol Version 1.0.", RFC 2246, 1050 IETF, January 1999. 1052 [14] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE).", RFC 1053 2409, IETF, November 1998. 1055 [15] Donald E. Eastlake, Jeffrey I. Schiller, Steve Crocker: 1056 "Randomness Requirements for Security"; ; Work in Progress, IETF, January 2005. 1059 [16] J. Schiller: "Strong Security Requirements for Internet 1060 Engineering Task Force Standard Protocols", RFC 3365, IETF, 1061 2002. 1063 [17] C. Meadows: "Advice on Writing an Internet Draft Amenable to 1064 Security Analysis", Work in Progress, , IRTF, October 2002. 1067 [18] T. Narten: "Guidelines for Writing an IANA Considerations 1068 Section in RFCs", RFC 2434, IETF, October 1998. 1070 [19] J. Reynolds: "Instructions to Request for Comments (RFC) 1071 Authors", Work in Progress, , IETF, August 2004. 1074 [20] J. Rosenberg et all: "SIP: Session Initiation Protocol", RFC 1075 3261, IETF, June 2002. 1077 [21] Ch. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Work in 1078 Progress (IPSEC WG), , Internet 1079 Draft, Work in Progress (IPSEC WG). 1081 [22] ITU-T Recommendation H.235 Annex G: "Usage of the MIKEY 1082 Key Management Protocol for the Secure Real Time Transport 1083 Protocol (SRTP) within H.235"; 1/2005. 1085 [23] Schaad, J., Housley R.: "Advanced Encryption Standard (AES) 1086 Key Wrap Algorithm", RFC 3394, IETF, September 2002. 1088 [24] Baugher, M., Weis, B., Hardjono, T., Harney, H.: "The Group 1089 Domain of Interpretation", RFC 3547, IETF, July 2003. 1091 [25] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R.: 1092 "Group Secure Association Key Management Protocol", , Internet Draft, Work in Progress (MSEC 1094 WG). 1096 [26] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.: "Group 1097 Key Management Architecture", , 1098 Internet Draft, Work in Progress (MSEC WG). 1100 [27] Baugher, McGrew, Oran, Blom, Carrara, Naslund: "The Secure 1101 Real-time Transport Protocol", RFC 3711, IETF, March 2004. 1103 [28] ITU-T Recommendation H.235V3Amd1 Corr1, "Security and 1104 encryption for H-series (H.323 and other H.245-based) multimedia 1105 terminals", (01/2005). 1107 [29] C. Adams et al: "Internet X.509 Public Key Infrastructure 1108 Certificate Management Protocols"; draft-ietf-pkix-rfc2510bis- 1109 09.txt, Internet Draft, Work in Progress (PKIX WG). 1111 [30] M. Myers et al: "X.509 Internet Public Key Infrastructure 1112 Online Certificate Status Protocol - OCSP", RFC 2560, IETF, June 1113 1999. 1115 [31] C. Adams et al: "Internet X.509 Public Key Infrastructure Data 1116 Validation and Certification Server Protocols", RFC 3029, IETF, 1117 February 2001. 1119 [32] M. Myers: "Internet X.509 Certificate Request Message Format", 1120 RFC 2511, IETF, March 1999. 1122 [33] M. Cooper et al: "Internet X.509 Public Key Infrastructure: 1123 Certification Path Building", , Internet Draft, Work in Progress (PKIX WG). 1126 [34] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, 1127 March 2005. 1129 [35] Bradner, S., "Intellectual Property Rights in IETF Technology", 1130 BCP 79, RFC 3979, March 2005. 1132 [36] J. Rosenberg, H. Schulzrinne: "An Offer/Answer Model with the 1133 Session Description Protocol (SDP)", RFC 3264, IETF, June 2002. 1135 [37] IANA MIKEY Payload Name Spaces per [RFC3830], see 1136 http://www.iana.org/assignments/mikey-payloads 1138 Appendix A Usage of MIKEY-DHHMAC in H.235 1140 This appendix provides informative overview how MIKEY-DHHMAC can be 1141 applied in some H.323-based multimedia environments. Generally, 1142 MIKEY is applicable for multimedia applications including IP 1143 telephony. [22] describes various use cases of the MIKEY key 1144 management protocols (MIKEY-PS, MIKEY-PK, MIKEY-DHSIGN and MIKEY- 1145 DHHMAC) with the purpose to establish TGK keying material among 1146 H.323 endpoints. The TGKs are then used for media encryption by 1147 applying SRTP [27]. Addressed scenarios include point-to-point with 1148 one or more intermediate gatekeepers (trusted or partially trusted) 1149 in-between. 1151 One particular use case addresses MIKEY-DHHMAC to establish a media 1152 connection from an endpoint B calling (through a gatekeeper) to 1153 another endpoint A that is located within that same gatekeeper zone. 1154 While EP-A and EP-B typically do not share any auth_key a priori, 1155 some separate protocol exchange means are achieved outside the 1156 actual call setup procedure to establish an auth_key for the time 1157 while endpoints are being registered with the gatekeeper; such 1158 protocols exist [22] but are not shown in this document. The 1159 auth_key between the endpoints is being used to authenticate and 1160 integrity protect the MIKEY-DHHMAC messages. 1162 To establish a call, it is assumed that endpoint B has obtained 1163 permission from the gatekeeper (not shown). Endpoint B as the 1164 caller builds the MIKEY-DHHMAC I_message(see section 3) and sends 1165 the I_message encapsulated within the H.323-SETUP to endpoint A. A 1166 routing gatekeeper (GK) would forward this message to endpoint B; in 1167 case of a non-routing gatekeeper, endpoint B sends the SETUP 1168 directly to endpoint A. In either case, H.323 inherent security 1169 mechanisms [28] are applied to protect the (encapsulation) message 1170 during transfer. This is not depicted here. The receiving endpoint 1171 A is able to verify the conveyed I_message and can compute a TGK. 1172 Assuming that endpoint A would accept the call, EP-A then builds the 1173 MIKEY-DHHMAC R_message and sends the response as part of the 1174 CallProceeding-to-Connect message back to the calling endpoint B 1175 (possibly through a routing gatekeeper). Endpoint B processes the 1176 conveyed R_message to compute the same TGK as the called endpoint A. 1178 1.) EP-B -> (GK) -> EP-A: SETUP(I_fwd_message [, I_rev_message]) 1179 2.) EP-A -> (GK) -> EP-B: CallProceeding-to-CONNECT(R_fwd_message [, 1180 R_rev_message]) 1182 Notes: If it is necessary to establish directional TGKs for full- 1183 duplex links in both directions B->A and A->B, then the 1184 calling endpoint B instantiates the DHHMAC protocol twice: 1185 once in the direction B->A using I_fwd_message and another 1186 run in parallel in the direction A->B using I_rev_message. 1187 In that case, two MIKEY-DHHMAC I_messages are encapsulated 1188 within SETUP (I_fwd_message and I_rev_message) and two 1189 MIKEY-DHHMAC R_messages (R_fwd_message and R_rev_message) 1190 are encapsulted within CallProceeding-to-CONNECT. The 1191 I_rev_message corresponds with the I_fwd_message. 1192 Alternatively, the called endpoint A may instantiate the 1193 DHHMAC protocol in a separate run with endpoint B (not 1194 shown); however, this requires a third handshake to 1195 complete. 1197 For more details on how the MIKEY protocols may be deployed 1198 with H.235, please refer to [22]. 1200 Full Copyright Statement 1202 Copyright (C) The Internet Society (2004). This document is subject 1203 to the rights, licenses and restrictions contained in BCP 78, and 1204 except as set forth therein, the authors retain all their rights. 1206 This document and the information contained herein are provided on an 1207 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1208 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1209 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1210 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1211 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1212 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1214 Intellectual Property Rights 1216 The IETF takes no position regarding the validity or scope of any 1217 Intellectual Property Rights or other rights that might be claimed 1218 to pertain to the implementation or use of the technology described 1219 in this document or the extent to which any license under such 1220 rights might or might not be available; nor does it represent that 1221 it has made any independent effort to identify any such rights. 1222 Information on the procedures with respect to rights in RFC 1223 documents can be found in BCP 78 and BCP 79. 1225 Copies of IPR disclosures made to the IETF Secretariat and any 1226 assurances of licenses to be made available, or the result of an 1227 attempt made to obtain a general license or permission for the use 1228 of such proprietary rights by implementers or users of this 1229 specification can be obtained from the IETF on-line IPR repository 1230 at http://www.ietf.org/ipr. 1232 The IETF invites any interested party to bring to its attention any 1233 copyrights, patents or patent applications, or other proprietary 1234 rights that may cover technology that may be required to implement 1235 this standard. Please address the information to the IETF at 1236 ietf-ipr@ietf.org. 1238 Expiration Date 1240 This Internet Draft expires on 30 October 2005. 1242 [Note to the RFC editor: Please remove the entire following section 1243 prior to publication.] 1245 Revision History 1247 Changes against draft-ietf-msec-mikey-dhhmac-10.txt: 1248 * A few editorial bugs removed. 1249 * References updated. 1251 Changes against draft-ietf-msec-mikey-dhhmac-09.txt: 1252 *IESG review feedback incorporated; generally, only editorial 1253 corrections. 1254 * Section 2.1.1 moved into new Appendix A. 1255 * IANA considerations section reworked and clarified. 1257 Changes against draft-ietf-msec-mikey-dhhmac-08.txt: 1258 * PKIX removed; some minor editorials. 1260 Changes against draft-ietf-msec-mikey-dhhmac-07.txt: 1262 * Feedback addressed from AD review. 1263 * added considerations on the possible impact of PKIX protocols and 1264 operations to end systems with real-time constraints (section 1). 1265 * added note that DH group is transmitted explicitly but not the 1266 parameters g and p; see section 3. 1267 * added considerations on clock synchronization and timestamps in 1268 section 2 and in section 5.3 in the view of consequences on replay 1269 protection. 1270 * references updated. 1271 * editorial corrections and cleanup. 1273 Changes against draft-ietf-msec-mikey-dhhmac-06.txt: 1275 * Abstract reworded. 1277 * used new RFC boilerplate: changed/moved IPR statement (now at 1278 the beginning), status of Memo, and Intellectual Property Rights 1279 section in accordance with RFC 3667, RFC 3668. 1280 * ID nits removal. 1281 * References updated. 1282 * Note added to section 4.1 explaining how to differentiate 1283 between MIKEY and DHHMAC. 1284 * New section 4.4 added that describes the use of the general 1285 extension payload to avoid bidding-down attacks. 1286 * Description of the bidding-down avoidance mechanism removed from 1287 the threat model in section 5.2. 1288 * IANA considerations section re-written and aligned with MIKEY. 1289 * Open issue on KMID pointed in IANA considerations section. 1290 * editorial clean-up. 1292 Changes against draft-ietf-msec-mikey-dhhmac-05.txt: 1294 * HMAC-SHA1-96 option removed (see section 1.2, 4.2, 5.3,). This 1295 option does not really provide much gain; removal reduces 1296 number 1297 of options. 1298 * IDr added to I_message for DoS protection of the recipient; see 1299 section 3, 3.1, 5.3. 1300 * References updated. 1302 Changes against draft-ietf-msec-mikey-dhhmac-04.txt: 1304 * Introduction section modified: PFS property of DH, requirement 1305 for 4th MIKEY key management variant motivated. 1306 * MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2 1307 Abbreviations. 1308 * Note on secure time synchronization added to section 2.0. 1309 * New section 2.2 "Relation to GMKARCH" added. 1310 * New section 2.1.1 "Usage in H.235" added: this section outlines 1311 a use case of DHHMAC in the context of H.235. 1312 * Trade-off between identity-protection and security & performance 1313 added to section 5.1. 1314 * New section 5.6 "Authorization and Trust Model" added. 1315 * Some further informative references added. 1317 Changes against draft-ietf-msec-mikey-dhhmac-03.txt: 1319 * RFC 3552 available; some references updated. 1321 Changes against draft-ietf-msec-mikey-dhhmac-02.txt: 1323 * text allows both random and pseudo-random values. 1324 * exponentiation ** changed to ^. 1325 * Notation aligned with MIKEY-07. 1326 * Clarified that the HMAC is calculated over the entire MIKEY 1327 message excluding the MAC field. 1328 * Section 4.2: The AES key wrap method SHALL not be applied. 1329 * Section 1: Relationship with other, existing work mentioned. 1331 Changes against draft-ietf-msec-mikey-dhhmac-01.txt: 1333 * bidding-down attacks addressed (see section 5.2). 1334 * optional [X], [X, Y] defined and clarified (see section 1.1, 1335 5.3). 1336 * combination of options defined in key update procedure (see 1337 section 3.1). 1338 * ID payloads clarified (see section 3 and 5.2). 1339 * relationship with MIKEY explained (roundtrip, performance). 1340 * new section 2.1 on applicability of DHHMAC for SIP/SDP and 1341 H.323 added. 1342 * more text due to DH resolution incorporated in section 5.3 1343 regarding PFS, security robustness of DH, generalization 1344 capability of DH to general groups in particular EC and 1345 "future-proofness". 1346 * a few editorials and nits. 1347 * references adjusted and cleaned-up. 1349 Changes against draft-ietf-msec-mikey-dhhmac-00.txt: 1351 * category set to proposed standard. 1352 * identity protection clarified. 1353 * aligned with MIKEY-05 DH protocol, notation and with payload 1354 * some editorials and nits. 1356 Changes against draft-euchner-mikey-dhhmac-00.txt: 1358 * made a MSEC WG draft 1359 * aligned with MIKEY-03 DH protocol, notation and with payload 1360 formats 1361 * clarified that truncated HMAC actually truncates the HMAC result 1362 rather than the SHA1 intermediate value. 1363 * improved security considerations section completely rewritten in 1364 the spirit of [8]. 1365 * IANA consideration section added 1366 * a few editorial improvements and corrections 1367 * IPR clarified and IPR section changed. 1369 Author's Addresses 1371 Martin Euchner 1372 Email: martin_euchner@hotmail.com 1373 Phone: +49 89 722 55790 Hofmannstr. 51 1374 Fax: +49 89 722 62366 1376 81359 Munich, Germany