idnits 2.17.00 (12 Aug 2021) /tmp/idnits53807/draft-ietf-msec-mikey-rsa-r-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** 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: ---------------------------------------------------------------------------- == 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 -- 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 () is 738693 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) == Missing Reference: 'RAND' is mentioned on line 218, but not defined == Missing Reference: 'IDr' is mentioned on line 216, but not defined == Missing Reference: 'SP' is mentioned on line 218, but not defined == Missing Reference: 'KMASDP' is mentioned on line 412, but not defined == Unused Reference: 'I-D.ietf-msec-gkdp' is defined on line 585, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) == Outdated reference: draft-ietf-msec-mikey-dhhmac has been published as RFC 4650 == Outdated reference: draft-ietf-msec-gsakmp-sec has been published as RFC 4535 == Outdated reference: A later version (-01) exists of draft-ietf-msec-gkdp-00 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC WG D. Ignjatic 3 Internet-Draft Polycom 4 Expires: August 4, 2006 L. Dondeti 5 QUALCOMM 6 F. Audet 7 P. Lin 8 Nortel 9 JAN 31, 2006 11 An additional mode of key distribution in MIKEY: MIKEY-RSA-R 12 draft-ietf-msec-mikey-rsa-r-02 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 4, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The Multimedia Internet Keying (MIKEY) specification describes 46 several modes of key distribution to setup Secure Real-time Rransport 47 Protocol (SRTP) sessions -- using pre-shared keys, public keys, and 48 optionally a Diffie-Hellman key exchange. In the public-key mode, 49 the Initiator encrypts a random key with the Responder's public key 50 and sends it to the Responder. In many communication scenarios, the 51 Initiator may not know the Responder's public key, or in some cases 52 the Responder's ID (e.g., call forwarding) in advance. We propose a 53 new MIKEY mode that works well in such scenarios. This mode also 54 enhances the group key management support in MIKEY; it supports 55 member-initiated group key download (in contrast to group manager 56 pushing the group keys to all members). 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology used in this document . . . . . . . . . . . . 3 62 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Description of the MIKEY modes . . . . . . . . . . . . . . 3 64 2.2. Use case motivating the proposed mode . . . . . . . . . . 4 65 3. A new MIKEY-RSA mode: MIKEY-RSA-R . . . . . . . . . . . . . . 5 66 3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Components of the I_MESSAGE . . . . . . . . . . . . . . . 5 68 3.3. Components of the R_MESSAGE . . . . . . . . . . . . . . . 6 69 3.4. Additions to RFC 3830 message types and other values . . . 8 70 3.4.1. Modified Table 6.1a from RFC 3830 . . . . . . . . . . 9 71 3.4.2. Modified Table 6.12 from RFC 3830 . . . . . . . . . . 9 72 3.4.3. Modified Table 6.15 from RFC 3830 . . . . . . . . . . 10 73 4. Applicability of the RSA-R and RSA modes . . . . . . . . . . . 10 74 4.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 5.1. Impact of the Responder choosing the TGK . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Intellectual Property and Copyright Statements . . . . . . . . . . 15 85 1. Introduction 87 The MIKEY protocol [RFC3830] has three different methods for key 88 transport or exchange: a pre-shared key mode (PSK), a public-key 89 (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode. In 90 addition, there is also an optional DH-HMAC mode [I-D.ietf-msec- 91 mikey-dhhmac], bringing the total number of modes to four. The 92 primary motivation for the MIKEY protocol design is low-latency 93 requirements of real-time communication, and thus all the exchanges 94 finish in one-half to 1 round-trip; note that this offers no room for 95 security parameter negotiation of the key management protocol itself. 96 In this document, we note that the MIKEY modes defined in RFC3830 97 [RFC3830] and [I-D.ietf-msec-mikey-dhhmac] are insufficient to 98 address some deployment scenarious and common use cases, and propose 99 a new mode called MIKEY-RSA in Reverse mode, or simply as 100 MIKEY-RSA-R. 102 1.1. Terminology used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in BCP 14, RFC 2119 107 [RFC2119]. 109 2. Motivation 111 As noted in the introduction, the MIKEY specification and other 112 proposals define four different modes of efficient key management for 113 real-time applications. Those modes differ from each other in either 114 the authentication method of choice (public-key, or symmetric shared 115 key-based), or the key establishment method of choice (key download, 116 or key agreement using a Diffie-Hellman exchange). We summarize the 117 modes, their advantages, and shortcomings in the following and also 118 describe use cases where these modes are unusable or inefficient. 120 2.1. Description of the MIKEY modes 122 The PSK mode requires that the Initiator and the Responder have a 123 common secret key established offline. In this mode, the Initiator 124 selects a TEK Generation Key (TGK), encrypts it with a key derived 125 from the PSK, and sends it to the Responder as part of the first 126 message, namely, I_MESSAGE. The I_MESSAGE is replay protected with 127 timestamps, and integrity protected with another key derived from the 128 PSK. An optional Verification message from the Responder to the 129 Initiator provides mutual authentication. This mode does not scale 130 well as it requires pre-establishment of a shared key between 131 communicating parties; for example, consider the use cases where any 132 user may want to communicate to any other user in an Enterprise or 133 the Internet at large. The RSA mode might be more suitable for such 134 applications. 136 In the RSA mode, the Initiator selects a TGK, encrypts and 137 authenticates it with an envelope key, and sends it to the Responder 138 as part of the I_MESSAGE. The Initiator includes the envelope key, 139 encrypted with the Responder's public key, in I_MESSAGE. The 140 I_MESSAGE is replay protected with timestamps, and signed with the 141 Initiator's public key. The Initiator's ID, Certificate (CERT) and 142 the Responder's ID that the Initiator intends to talk may be included 143 in I_MESSAGE. If the Initiator knows several public-keys of the 144 Responder, it can indicate the key used in the optional CHASH 145 payload. An optional Verification message from the Responder to the 146 Initiator provides mutual authentication. The RSA mode works well if 147 the Initiator knows the Responder's ID and the corresponding CERT (or 148 can obtain the CERT independent of the MIKEY protocol). RFC 3830 149 suggests that an Initiator, in the event that it does not have the 150 Responder's CERT, may obtain the CERT from a directory agent using 151 one or more round trips. However, in some cases, the Initiator may 152 not even know the Responder's ID in advance, and because of that or 153 for other reasons cannot obtain the Responder's CERT. 155 In addition to the case where the Responder may have several IDs, 156 some applications may allow for the Responder's ID to change 157 unilaterally, as is typical in telephony (e.g., forwarding). In 158 those cases and in others, the Initiator might be willing to let the 159 other party establish identity and prove it via an Initiator-trusted 160 third party (e.g., a Certification Authority or CA). 162 The DH mode or the DH-HMAC mode of MIKEY might be useful in cases 163 where the Initiator does not have access to the Responder's exact 164 identity and/or CERT. In these modes, the two parties engage in an 165 authenticated DH exchange to derive the TGK. On the downside, the DH 166 modes have higher computational and communication overhead compared 167 to the RSA and the PSK modes. More importantly, these modes are 168 unsuitable for group key distribution. 170 In summary, in some communication scenarios -- where the Initiator 171 might not have the correct ID and/or the CERT of the Responder -- 172 none of the MIKEY modes described in [RFC3830] and [I-D.ietf-msec- 173 mikey-dhhmac] are suitable/efficient for SRTP [RFC3711] key 174 establishment. 176 2.2. Use case motivating the proposed mode 178 In addition to the issues listed above, there are some types of 179 applications that motivate the new MIKEY mode design proposed in this 180 document. 182 Note that in the MIKEY-RSA mode (as in case of the PSK mode), the 183 Initiator proposes the SRTP security policy, and chooses the TGK. 184 However, it is also possible that the Initiator wants to allow the 185 Responder to specify the security policy and send the TGK. Consider 186 for example the case of a conferencing scenario where the convener 187 sends an invitation to a group of people to attend a meeting. The 188 procedure then might be for the invitees to request the convener for 189 group key material by sending a MIKEY I_MESSAGE. Thus, in the MIKEY 190 definition of initiators and responders, the Initiator is asking the 191 Responder for keying material. Note that this mode of operation is 192 inline with the MSEC group key management architecture [RFC4046]. 194 3. A new MIKEY-RSA mode: MIKEY-RSA-R 196 3.1. Outline 198 The proposed MIKEY mode requires 1 full round trip. The Initiator 199 sends a signed I_MESSAGE to the intended Responder requesting the 200 Responder to send the SRTP keying material. The I_MESSAGE MAY 201 contain the Initiator's CERT or a link (URL) to the CERT, and 202 similarly the Responder's reply, R_MESSAGE MAY contain the 203 Responder's CERT or a link to it. The Responder can use the 204 Initiator's public key from the CERT in the I_MESSAGE to send the 205 encrypted TGK in the R_MESSAGE. Upon receiving the R_MESSAGE, the 206 Initiator can use the CERT in the R_MESSAGE to verify whether the 207 Responder is in fact the party that it wants to communicate to, and 208 accept the TGK. We refer to this protocol as MIKEY-RSA in the 209 reverse mode, or simply as MIKEY-RSA-R. 211 The MIKEY-RSA-R mode exchange is defined as follows: 213 Initiator Responder 214 --------- --------- 216 I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], {SP}, SIGNi 218 R_MESSAGE = HDR, [GenExt(CSB-ID)], T, [RAND], [IDr|CERTr], [SP], 219 KEMAC, PKE, SIGNr 221 Figure 1: MIKEY-RSA-R mode 223 3.2. Components of the I_MESSAGE 225 MIKEY-RSA-R requires a full round trip to download the TGKs. The 226 I_MESSAGE MUST have the MIKEY HDR and the timestamp payload for 227 replay protection. The HDR field contains a CSB_ID (Crypto Session 228 Bundle ID) randomly selected by the Initiator. The V bit MUST be set 229 to '1' and ignored by the Responder, as a response is MANDATORY in 230 this mode. The Initiator MAY indicate the number of CSs supported, 231 and SHOULD/MUST fill in the CS ID map type and CS ID info fields for 232 the RTP/RTCP streams it originates (This is because the sender of the 233 streams chooses the SSRC which is carried in the CS ID info field; 234 see Section 6.1.1 of RFC 3830). The I_MESSAGE MUST be signed by the 235 Initiator following the procedure to sign MIKEY messages specified in 236 RFC 3830. The SIGNi payload contains this signature. Thus the 237 I_MESSAGE is integrity and replay protected. 239 The RAND payload SHOULD be included in the I_MESSAGE when MIKEY-RSA-R 240 mode is used for unicast communication. It MUST be omitted when this 241 mode is used to establish group keys. The reason for the inclusion 242 of the RAND payload in unicast scenarios is to allow for the 243 Initiator to contribute entropy to the key derivation process (in 244 addition to the CSB_ID). 246 IDi and CERTi SHOULD be included, but they MAY be left out when it is 247 expected that the peer already knows the Initiating party's ID (or 248 can obtain the certificate in some other manner). For example, this 249 could be the case if the ID is extracted from SIP. For certificate 250 handling, authorization, and policies, see Section 4.3. of RFC 3830. 251 If CERTi is included, it MUST correspond to the private key used to 252 sign the I_MESSAGE. 254 If the Responder has multiple Identities, the Initiator MAY also 255 include the specific ID, IDr, of the Responder that it wants to 256 communicate with. 258 The Initiator MAY also send security policy (SP) payload(s) 259 containing all the security policies that it supports. If the 260 Responder does not support any of the policies included, it should 261 reply with an Error message of type "Invalid SPpar" (Error no. 10). 263 SIGNi is a signature covering the Initiator's MIKEY message, 264 I_MESSAGE, using the Initiator's signature key (see Section 5.2 of 265 RFC 3830 for the exact definition). The I_MESSAGE is signed to 266 protect against DoS attacks. 268 3.3. Components of the R_MESSAGE 270 Upon receiving an I_MESSAGE of the RSA-R format, the Responder MUST 271 respond with one of the following messages: 272 o The Responder SHOULD send an Error message "Message type not 273 supported" (Error no. 13), if it cannot correctly parse the 274 received MIKEY message. Error no. 13 is not defined in RFC 3830, 275 and so RFC 3830 compliant implementations MAY return "an 276 unspecified error occurred" (Error no. 12). 277 o The Responder MUST send an Error message "Invalid SPpar" (Error 278 no. 10), if it does not support any of the security policies 279 included in the SP payload. 280 o The Responder MUST send an R_MESSAGE, if SIGNi can be correctly 281 verified and the timestamp is current; if an SP payload is present 282 in the I_MESSAGE the Responder MUST return one of the proposed 283 security policies that matches the Responder's local policy. 285 The HDR payload in the R_MESSAGE is formed following the procedure 286 described in RFC 3830. Specifically, the CSB ID in the HDR payload 287 MUST be the same as the one in the HDR of the I_MESSAGE. The 288 Responder MUST fill in the number of CSs and the CS ID map type and 289 CS ID info fields of the HDR payload. 291 For group communication, all the members MUST use the same CSB ID and 292 CS ID in computing the SRTP keying material. Therefore, for group 293 key establishment, the Responder MUST include a General Extension 294 Payload containing a new CSB ID in the R_MESSAGE. If a new CSB ID is 295 present in the R_MESSAGE, the Initiator and the Responder MUST use 296 that value in key material computation. Furthermore, the complete CS 297 map SHOULD be populated by the Responder. The General Extension 298 Payload carrying a CSB ID MUST NOT be present in case of one-to-one 299 communication. 301 When used in group scenarios with bi-directional media, the Responder 302 SHOULD include two TGKs or TEKs in the KEMAC payload. The first TGK 303 or TEK SHOULD be used for receiving media on the Initiator's side and 304 the second one to encrypt/authenticate media originating on the 305 Initiator's side. This allows all the multicast traffic to be 306 encrypted/authenticated by the same group key while keys used for 307 unicast streams from all the group members can still be independent. 309 The T payload is exactly the same as that received in the I_MESSAGE. 311 If the I_MESSAGE did not include the RAND payload, it MUST be present 312 in the R_MESSAGE. In case it has been included in the I_MESSAGE, it 313 MUST NOT be present in the R_MESSAGE. In group communication, the 314 RAND payload is always sent by the Responder and in unicast 315 communication, either the Initiator or the Responder (but not both) 316 generate and send the RAND payload. 318 IDr and CERTr SHOULD be included, but they MAY be left out when it 319 can be expected that the peer already knows the other party's ID (or 320 can obtain the certificate in some other manner). For example, this 321 could be the case if the ID is extracted from SIP. For certificate 322 handling, authorization, and policies, see Section 4.3. of RFC 3830. 324 If CERTr is included, it MUST correspond to the private key used to 325 sign the R_MESSAGE. 327 An SP payload MAY be included in the R_MESSAGE. If an SP payload was 328 in the I_MESSAGE, then R_MESSAGE MUST contain an SP payload 329 specifying the security policies of the secure RTP session being 330 negotiated. More specifically, the Initiator may have provided 331 multiple options, but the Responder must choose one option per 332 Security Policy Parameter. 334 The KEMAC payload contains a set of encrypted sub-payloads and a MAC: 335 KEMAC = E(encr_key, IDr || {TGK}) || MAC. The first payload (IDr) in 336 KEMAC is the identity of the Responder (not a certificate, but 337 generally the same ID as the one specified in the certificate). Each 338 of the following payloads (TGK) includes a TGK randomly and 339 independently chosen by the Responder (and possible other related 340 parameters, e.g., the key lifetime). The encrypted part is then 341 followed by a MAC, which is calculated over the KEMAC payload. The 342 encr_key and the auth_key are derived from the envelope key, env_key, 343 as specified in Section 4.1.4. of RFC 3830. The payload definitions 344 are specified in Section 6.2 of RFC 3830. 346 The Responder encrypts and integrity protects the TGK with keys 347 derived from a randomly/pseudo-randomly chosen envelope key, and 348 encrypts the envelope key itself with the public key of the 349 Initiator. The PKE payload contains the encrypted envelope key: PKE 350 = E(PKi, env_key). It is encrypted using the Initiator's public key 351 (PKi). Note that, as suggested in RFC 3830, the envelope key MAY be 352 cached and used as the PSK for re-keying. 354 To compute the signature that goes in the SIGNr payload, the 355 Responder MUST sign R_MESSAGE (excluding the SIGNr payload itself) || 356 IDi || IDr || T. Note that the added identities and timestamp are 357 identical to those transported in the ID and T payloads. 359 3.4. Additions to RFC 3830 message types and other values 360 3.4.1. Modified Table 6.1a from RFC 3830 362 Modified Table 6.1a from RFC 3830: 364 Data type | Value | Comment 365 ------------------------------------------------------------------ 366 Pre-shared | 0 | Initiator's pre-shared key message 367 PSK ver msg | 1 | Verification message of a Pre-shared key msg 368 Public key | 2 | Initiator's public-key transport message 369 PK ver msg | 3 | Verification message of a public-key message 370 D-H init | 4 | Initiator's DH exchange message 371 D-H resp | 5 | Responder's DH exchange message 372 Error | 6 | Error message 373 DHHMAC init | 7 | DH HMAC message 1 374 DHHMAC resp | 8 | DH HMAC message 2 375 RSA-R I_MSG | 9 | Initiator's public-key message in RSA-R mode 376 RSA-R R_MSG | 10 | Responder's public-key message in RSA-R mode 378 Figure 2: Table 6.1a from RFC 3830 (Revised) 380 3.4.2. Modified Table 6.12 from RFC 3830 382 Modified Table 6.12 from RFC 3830: 384 Error no | Value | Comment 385 ------------------------------------------------------- 386 Auth failure | 0 | Authentication failure 387 Invalid TS | 1 | Invalid timestamp 388 Invalid PRF | 2 | PRF function not supported 389 Invalid MAC | 3 | MAC algorithm not supported 390 Invalid EA | 4 | Encryption algorithm not supported 391 Invalid HA | 5 | Hash function not supported 392 Invalid DH | 6 | DH group not supported 393 Invalid ID | 7 | ID not supported 394 Invalid Cert | 8 | Certificate not supported 395 Invalid SP | 9 | SP type not supported 396 Invalid SPpar | 10 | SP parameters not supported 397 Invalid DT | 11 | not supported Data type 398 Unspecified error | 12 | an unspecified error occurred 399 Unsupported | | 400 message type | 13 | unparseable MIKEY message 402 Figure 3: Table 6.12 from RFC 3830 (Revised) 404 3.4.3. Modified Table 6.15 from RFC 3830 406 Modified Table 6.15 from RFC 3830: 408 Type | Value | Comment 409 ------------------------------------------------------- 410 Vendor ID | 0 | Vendor specific byte string 411 SDP IDs | 1 | List of SDP key mgmt IDs 412 | | (allocated for use in [KMASDP]) 413 CSB-ID | 2 | Responder's modified CSB-ID (group mode) 415 Figure 4: Table 6.15 from RFC 3830 (Revised) 417 4. Applicability of the RSA-R and RSA modes 419 MIKEY-RSA-R mode and RSA mode are both very useful: deciding on which 420 mode to use depends on the application. 422 The RSA-R mode is useful when you have reasons to believe that the 423 Responder may be different from who you are sending the MIKEY message 424 to. This is quite common in telephony and multimedia applications 425 where the session/call can be retargeted/forwarded. When the 426 security policy allows it, it may be appropriate for the Initiator to 427 have some flexibility in who the Responder may turn out to be. In 428 such cases, the main objective of the Initiator's RSA-R message is to 429 present its public key/certificate to the Responder. 431 The second scenario is when the Initiator already has the Responder's 432 certificate but wants to allow the Responder to come up with all the 433 keying material. This is applicable in conferences where the 434 Responder is the key distributor and the Initiators contact the 435 Responder to initiate key download. Notice that this is quite 436 similar to the group key download model as specified in GDOI 437 [RFC3547], GSAKMP [I-D.ietf-msec-gsakmp-sec], and GKDP [I-D.ietf- 438 msec-gkdp] protocols (also see [RFC4046]). The catch however is that 439 the participating entities must know that they need to contact a 440 well-known address as far as that conferencing group is concerned. 441 Note that they only need the Responder's address, not necessarily its 442 CERT. If the group members have the Responder's CERT, there is no 443 harm; they simply do not need the CERT to compose I_MESSAGE. 445 The RSA mode is useful when the Initiator knows the Responder's 446 identity and CERT. This mode is also useful when the key exchange is 447 happening in an established session with a Responder (for example, 448 when switching from a non-secure mode to a secure mode), and when the 449 policy is such that it is only appropriate to establish a MIKEY 450 session with the Responder that is targeted by the Initiator. 452 4.1. Limitations 454 The RSA-R mode may not easily support 3-way calling, under the 455 assumptions that motivated the design. An extra message may be 456 required compared to the MIKEY-RSA mode specified in RFC 3830. 457 Consider that A wants to talk to B and C, but does not have B's or 458 C's CERT. A might contact B and request that B supply a key for a 459 3-way call. Now if B knows C's CERT, then B can simply use the 460 MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If not, 461 then the solution is not straightforward. For instance, A might ask 462 C to contact B or itself to get the TGK, in effect initiating a 3-way 463 exchange. It should be noted that 3-way calling is typically 464 implemented using a bridge, in which case there are no issues (it 465 looks like 3 point-to-point sessions, where one end of each session 466 is a bridge mixing the traffic into a single stream). 468 5. Security Considerations 470 We offer a brief overview of the security properties of the exchange. 471 There are two messages, viz., I_MESSAGE and R_MESSAGE. I_MESSAGE is 472 a signed request by an Initiator requesting the Responder to select a 473 TGK to be used to protect SRTP and SRTCP sessions. 475 The message is signed, which assures the Responder that the claimed 476 Initiator has indeed generated the message. This automatically 477 provides message integrity as well. 479 There is a timestamp in the I_MESSAGE, which when generated and 480 interpreted in the context of the MIKEY specification, assures the 481 Responder that the request is live and not a replay. Indirectly, 482 this also provides protection against a DoS attack in that the 483 I_MESSAGE must itself be signed. The Responder however would have to 484 verify the Initiator's signature and the timestamp, and thus would 485 spend significant computing resources. It is possible to mitigate 486 this by caching recently received and verified requests. 488 Note that the I_MESSAGE in this method basically equals DoS 489 protection properties of the DH method and not the public key method 490 as there are no payloads encrypted by the Responder's public key in 491 I_MESSAGE. If IDr is not included in the I_MESSAGE, the Responder 492 will accept the message and a response (and state) would be created 493 for the malicious request. 495 The R_MESSAGE is quite similar to the I_MESSAGE in the MIKEY-RSA mode 496 and has all the same security properties. 498 When using the RSA-R mode, the Responder may turn out to be different 499 from who the Initiator sent the MIKEY message to. It is the 500 responsibility of the Initiator to verify that the identity of the 501 Responder is acceptable (based on its local policy) if it changes 502 from the intended Responder, and to take appropriate action based on 503 the outcome. In some cases, it could be appropriate to accept 504 Responder's identity if it can be strongly authenticated; in other 505 cases, a blacklist or a whitelist may be appropriate. 507 When both unicast and multicast streams are negotiated it is 508 suggested to use multiple instances of MIKEY rather than a single 509 instance in group mode. Unicast and multicast keys have different 510 security properties and should not be derived from the same pool. 511 The authors believe that multiple TGK payloads can be used for this 512 purpose but the exact method is not specified in MIKEY. 514 5.1. Impact of the Responder choosing the TGK 516 In the MIKEY-RSA or PSK modes, the Initiator chooses the TGK and the 517 Responder has the option to accept the key or not. In the RSA-R mode 518 for unicast communication, the Initiator and the Responder contribute 519 random information in generating the TEK (RAND from the Initiator and 520 the TGK from the Responder). For group communication, the sender 521 will choose the TGK and the RAND; note that it is in the interest of 522 the sender to provide sufficient entropy to TEK generation since the 523 TEK protects data sent by the Responder. 525 Thus, in case of one-to-one communication, the RSA-R mode is slightly 526 better than the RSA mode in that it allows the Initiator as well as 527 the Responder to contribute entropy to the TEK generation process. 528 This comes at the expense of the additional message. However, as 529 noted earlier, the new mode needs the additional message to allow 530 simpler provisioning. 532 RFC 3830 has additional notes on the security properties of the MIKEY 533 protocol, key derivation functions and other components. 535 6. IANA Considerations 537 This specification requires the following IANA assignments to the 538 MIKEY registry : 539 Add to "Error Payload namespace:" 540 Unsupported message type ------- 13 541 Add to "Common Header payload name spaces:" 542 RSA-R I_MSG ------------ 9 543 RSA-R R_MSG ------------- 10 545 General Extensions payload name spaces: 546 CSB-ID ----------------- 2 (Note: another draft may use '2'; 547 please assign next available number) 549 7. Acknowledgments 551 8. References 553 8.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 559 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 560 August 2004. 562 8.2. Informative References 564 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 565 "Multicast Security (MSEC) Group Key Management 566 Architecture", RFC 4046, April 2005. 568 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 569 Group Domain of Interpretation", RFC 3547, July 2003. 571 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 572 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 573 RFC 3711, March 2004. 575 [I-D.ietf-msec-mikey-dhhmac] 576 Euchner, M., "HMAC-authenticated Diffie-Hellman for 577 MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in 578 progress), April 2005. 580 [I-D.ietf-msec-gsakmp-sec] 581 Harney, H., "GSAKMP: Group Secure Association Group 582 Management Protocol", draft-ietf-msec-gsakmp-sec-10 (work 583 in progress), May 2005. 585 [I-D.ietf-msec-gkdp] 586 Dondeti, L. and J. Xiang, "GKDP: Group Key Distribution 587 Protocol", draft-ietf-msec-gkdp-00 (work in progress), 588 September 2005. 590 Authors' Addresses 592 Dragan Ignjatic 593 Polycom 594 1000 W. 14th Street 595 North Vancouver, BC V7P 3P3 596 Canada 598 Phone: +1 604 982 3424 599 Email: dignjatic@polycom.com 601 Lakshminath Dondeti 602 QUALCOMM 603 5775 Morehouse drive 604 San Diego, CA 92121 605 US 607 Phone: +1 858 845 1267 608 Email: ldondeti@qualcomm.com 610 Francois Audet 611 Nortel 612 4655 Great America Parkway 613 Santa Clara, CA 95054 614 US 616 Phone: +1 408 495 3756 617 Email: audet@nortel.com 619 Ping Lin 620 Nortel 621 250 Sidney St. 622 Belleville, Ontario K8P3Z3 623 Canada 625 Phone: +1 613 967 5343 626 Email: linping@nortel.com 628 Intellectual Property Statement 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org. 652 Disclaimer of Validity 654 This document and the information contained herein are provided on an 655 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 656 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 657 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 658 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 659 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 660 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Copyright Statement 664 Copyright (C) The Internet Society (2006). This document is subject 665 to the rights, licenses and restrictions contained in BCP 78, and 666 except as set forth therein, the authors retain all their rights. 668 Acknowledgment 670 Funding for the RFC Editor function is currently provided by the 671 Internet Society.