idnits 2.17.1 draft-ietf-msec-mikey-rsa-r-07.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 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC3830, but the header doesn't have an 'Updates:' line to match this. 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 (August 8, 2006) is 6469 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 257, but not defined == Missing Reference: 'IDr' is mentioned on line 257, but not defined == Missing Reference: 'SP' is mentioned on line 233, but not defined == Unused Reference: 'I-D.ietf-msec-newtype-keyid' is defined on line 754, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) == Outdated reference: A later version (-13) exists of draft-ietf-ntp-ntpv4-proto-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ignjatic 3 Internet-Draft Polycom 4 Updates: RFC3830 (if approved) L. Dondeti 5 Intended status: Standards Track QUALCOMM 6 Expires: February 9, 2007 F. Audet 7 P. Lin 8 Nortel 9 August 8, 2006 11 An additional mode of key distribution in MIKEY: MIKEY-RSA-R 12 draft-ietf-msec-mikey-rsa-r-07 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 February 9, 2007. 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 solution that addresses multimedia 47 scenarios (e.g., SIP calls and RTSP sessions) -- using pre-shared 48 keys, public keys, and optionally a Diffie-Hellman key exchange. In 49 the public-key mode, the Initiator encrypts a random key with the 50 Responder's public key and sends it to the Responder. In many 51 communication scenarios, the Initiator may not know the Responder's 52 public key, or in some cases the Responder's ID (e.g., call 53 forwarding) in advance. We propose a new MIKEY mode that works well 54 in such scenarios. This mode also enhances the group key management 55 support in MIKEY; it supports member-initiated group key download (in 56 contrast to group manager pushing the group keys to all members). 57 This document updates RFC 3830 with the RSA-R mode. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology used in this document . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Description of the MIKEY modes . . . . . . . . . . . . . . 3 65 2.2. Use case motivating the proposed mode . . . . . . . . . . 5 66 3. A new MIKEY-RSA mode: MIKEY-RSA-R . . . . . . . . . . . . . . 5 67 3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Group communication using the MIKEY RSA-R mode . . . . . . 6 69 3.3. Preparing RSA-R messages . . . . . . . . . . . . . . . . . 6 70 3.4. Components of the I_MESSAGE . . . . . . . . . . . . . . . 7 71 3.5. Processing the I_MESSAGE . . . . . . . . . . . . . . . . . 8 72 3.6. Components of the R_MESSAGE . . . . . . . . . . . . . . . 9 73 3.7. Processing the R_MESSAGE . . . . . . . . . . . . . . . . . 10 74 3.8. Certificate handling . . . . . . . . . . . . . . . . . . . 10 75 3.9. Additions to RFC 3830 message types and other values . . . 11 76 3.9.1. Modified Table 6.1a from RFC 3830 . . . . . . . . . . 11 77 3.9.2. Modified Table 6.12 from RFC 3830 . . . . . . . . . . 12 78 3.9.3. Modified Table 6.15 from RFC 3830 . . . . . . . . . . 12 79 4. Applicability of the RSA-R and RSA modes . . . . . . . . . . . 12 80 4.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 5.1. Impact of the Responder choosing the TGK . . . . . . . . . 15 83 5.2. Updates to Security Considerations in RFC3830 . . . . . . 15 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 Intellectual Property and Copyright Statements . . . . . . . . . . 19 92 1. Introduction 94 The MIKEY protocol [RFC3830] has three different methods for key 95 transport or exchange: a pre-shared key mode (PSK), a public-key 96 (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode. In 97 addition, there is also an optional DH-HMAC mode 98 [I-D.ietf-msec-mikey-dhhmac], bringing the total number of modes to 99 four. The primary motivation for the MIKEY protocol design is low- 100 latency requirements of real-time communication, and thus all the 101 exchanges finish in one-half to 1 round-trip; note that this offers 102 no room for security parameter negotiation of the key management 103 protocol itself. In this document, we note that the MIKEY modes 104 defined in RFC3830 [RFC3830] and [I-D.ietf-msec-mikey-dhhmac] are 105 insufficient to address some deployment scenarios and common use 106 cases, and propose a new mode called MIKEY-RSA in Reverse mode, or 107 simply as MIKEY-RSA-R. This document updates RFC 3830 with the 108 addition of this new mode to that specification. 110 1.1. Terminology used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14, RFC 2119 115 [RFC2119]. 117 Furthermore, this document reuses the terminology of the MIKEY 118 specification [RFC3830]. 120 2. Motivation 122 As noted in the introduction, the MIKEY specification and other 123 proposals define four different modes of efficient key management for 124 real-time applications. Those modes differ from each other in either 125 the authentication method of choice (public-key, or symmetric shared 126 key-based), or the key establishment method of choice (key download, 127 or key agreement using a Diffie-Hellman exchange). We summarize 128 these modes below, including their advantages and shortcomings. We 129 then discuss the use cases where these modes are unusable or 130 inefficient. 132 2.1. Description of the MIKEY modes 134 The PSK mode requires that the Initiator and the Responder have a 135 common secret key established offline. In this mode, the Initiator 136 selects a TEK Generation Key (TGK), encrypts it with a key derived 137 from the PSK, and sends it to the Responder as part of the first 138 message, namely, I_MESSAGE. The I_MESSAGE is replay protected with 139 timestamps, and integrity protected with another key derived from the 140 PSK. An optional Verification message from the Responder to the 141 Initiator provides mutual authentication. This mode does not scale 142 well as it requires pre-establishment of a shared key between 143 communicating parties; for example, consider the use cases where any 144 user may want to communicate to any other user in an Enterprise or 145 the Internet at large. The RSA mode might be more suitable for such 146 applications. 148 In the RSA mode, the Initiator selects a TGK, encrypts and 149 authenticates it with an envelope key, and sends it to the Responder 150 as part of the I_MESSAGE. The Initiator includes the envelope key, 151 encrypted with the Responder's public key, in I_MESSAGE. The 152 I_MESSAGE is replay protected with timestamps, and signed with the 153 Initiator's public key. The Initiator's ID, Certificate (CERT) and 154 the Responder's ID that the Initiator intends to talk may be included 155 in I_MESSAGE. If the Initiator knows several public-keys of the 156 Responder, it can indicate the key used in the optional CHASH 157 payload. An optional Verification message from the Responder to the 158 Initiator provides mutual authentication. The RSA mode works well if 159 the Initiator knows the Responder's ID and the corresponding CERT (or 160 can obtain the CERT independent of the MIKEY protocol). RFC 3830 161 suggests that an Initiator, in the event that it does not have the 162 Responder's CERT, may obtain the CERT from a directory agent using 163 one or more round trips. However, in some cases, the Initiator may 164 not even know the Responder's ID in advance, and because of that or 165 for other reasons cannot obtain the Responder's CERT. 167 In addition to the case where the Responder may have several IDs, 168 some applications may allow for the Responder's ID to change 169 unilaterally, as is typical in telephony (e.g., forwarding). In 170 those cases and in others, the Initiator might be willing to let the 171 other party establish identity and prove it via an Initiator-trusted 172 third party (e.g., a Certification Authority (CA)). 174 The DH mode or the DH-HMAC mode of MIKEY might be useful in cases 175 where the Initiator does not have access to the Responder's exact 176 identity and/or CERT. In these modes, the two parties engage in an 177 authenticated DH exchange to derive the TGK. On the downside, the DH 178 modes have higher computational and communication overhead compared 179 to the RSA and the PSK modes. More importantly, these modes are 180 unsuitable for group key distribution. The DH-HMAC mode also 181 requires establishment of PSKs between all possible communicating 182 entities and thus has similar scaling issues as any PSK-based key 183 management protocol. 185 In summary, in some communication scenarios -- where the Initiator 186 might not have the correct ID and/or the CERT of the Responder -- 187 none of the MIKEY modes described in [RFC3830] or 188 [I-D.ietf-msec-mikey-dhhmac] are suitable and efficient for 189 multimedia session key establishment. 191 2.2. Use case motivating the proposed mode 193 In addition to the issues listed above, there are some types of 194 applications that motivate the new MIKEY mode design proposed in this 195 document. 197 Note that in the MIKEY-RSA mode (as in case of the PSK mode), the 198 Initiator proposes the session security policy, and chooses the TGK. 199 However, it is also possible that the Initiator wants to allow the 200 Responder to specify the security policy and send the TGK. Consider 201 for example the case of a conferencing scenario where the convener 202 sends an invitation to a group of people to attend a meeting. The 203 procedure then might be for the invitees to request the convener for 204 group key material by sending a MIKEY I_MESSAGE. Thus, in the MIKEY 205 definition of initiators and responders, the Initiator is asking the 206 Responder for keying material. Note that this mode of operation is 207 inline with the MSEC group key management architecture [RFC4046]. 209 3. A new MIKEY-RSA mode: MIKEY-RSA-R 211 3.1. Outline 213 The proposed MIKEY mode requires 1 full round trip. The Initiator 214 sends a signed I_MESSAGE to the intended Responder requesting the 215 Responder to send the traffic keying material. The I_MESSAGE MAY 216 contain the Initiator's CERT or a link (URL) to the CERT, and 217 similarly the Responder's reply, R_MESSAGE MAY contain the 218 Responder's CERT or a link to it. The Responder can use the 219 Initiator's public key from the CERT in the I_MESSAGE to send the 220 encrypted TGK in the R_MESSAGE. Upon receiving the R_MESSAGE, the 221 Initiator can use the CERT in the R_MESSAGE to verify whether the 222 Responder is in fact the party that it wants to communicate to, and 223 accept the TGK. We refer to this protocol as MIKEY-RSA in the 224 reverse mode, or simply as MIKEY-RSA-R. 226 The MIKEY-RSA-R mode exchange is defined as follows: 228 Initiator Responder 229 --------- --------- 231 I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], {SP}, SIGNi 233 R_MESSAGE = HDR, [GenExt(CSB_ID)], T, [RAND], [IDr|CERTr], [SP], 234 KEMAC, PKE, SIGNr 236 Figure 1: MIKEY-RSA-R Unicast Mode 238 3.2. Group communication using the MIKEY RSA-R mode 240 For group conferencing using MIKEY RSA-R mode, the members receive an 241 invitation to initiate MIKEY with the group key server to download 242 the secure session information. In this case, the Responder is 243 either the group sender or group key server. Group members request 244 group policy and keying material as MIKEY RSA-R initiators. 245 Initiators MUST NOT send the SP payload. The Responder sends all the 246 payloads necessary to distribute the secure group policy as well as 247 payloads used in the group key derivation: specifically, the SP 248 payload is used to convey the session policy, the GenExt(CSB-ID), TGK 249 and the RAND payloads selected by the Responder and included in the 250 R_Message are used to compute the SRTP session keys. 252 MIKEY RSA-R for group communication: 254 Initiator Responder 255 --------- --------- 257 I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], SIGNi 259 R_MESSAGE = HDR, GenExt(CSB_ID), T, RAND, [IDr|CERTr], SP, 260 KEMAC, PKE, SIGNr 262 Figure 2: MIKEY-RSA-R in Group Mode 264 Note that the SP payload in the I_MESSAGE is not present. In the 265 R_MESSAGE, the CSB_ID, RAND and SP payloads are not optional. 267 3.3. Preparing RSA-R messages 269 Preparation and parsing of RSA-R messages is as described in Sections 270 5.2 and 5.3 of RFC 3830. Error handling is described in Section 271 5.1.2 and replay protection guidelines are in Section 5.4 of RFC 272 3830. In the following, we describe the components of RSA-R messages 273 and specify message processing and parsing rules in addition to those 274 in RFC 3830. 276 3.4. Components of the I_MESSAGE 278 MIKEY-RSA-R requires a full round trip to download the TGKs. The 279 I_MESSAGE MUST have the MIKEY HDR and the timestamp payload for 280 replay protection. The HDR field contains a CSB_ID (Crypto Session 281 Bundle ID) randomly selected by the Initiator. The V bit MUST be set 282 to '1' and ignored by the Responder, as a response is MANDATORY in 283 this mode. The Initiator SHOULD indicate the number of CSs 284 supported, and SHOULD fill in the CS ID map type and CS ID info 285 fields for the RTP/RTCP streams it originates. This is because the 286 sender of the streams chooses the SSRC which is carried in the CS ID 287 info field; see Section 6.1.1 of RFC 3830. The exception to 288 Initiators not specifying SSRC values is to allow the Responder pick 289 them to avoid SSRC collisions. Initiators of MIKEY messages that do 290 not originate RTP streams MUST specify a '0' as the number of CSs 291 supported. This typically applies to group communication and to the 292 entities in the listen-only mode. 294 The I_MESSAGE MUST be signed by the Initiator following the procedure 295 to sign MIKEY messages specified in RFC 3830. The SIGNi payload 296 contains this signature. Thus the I_MESSAGE is integrity and replay 297 protected. 299 The RAND payload SHOULD be included in the I_MESSAGE when MIKEY-RSA-R 300 mode is used for unicast communication. The reason for recommending 301 the inclusion of the RAND payload in the I_MESSAGE for unicast 302 communication is to allow the Initiator to contribute entropy to the 303 key derivation process (in addition to the CSB_ID). When the RAND 304 payload is not included, the Initiator will be relying on the 305 Responder to supply all the entropy for SRTP key generation, which is 306 in fact similar (but with the reversal of roles) to the MIKEY-RSA 307 mode, where the Responder supplies all the entropy. 309 The RAND payload MAY be included when MIKEY-RSA-R is used to 310 establish group keys. However, the RAND payload in the I_MESSAGE 311 MUST NOT be used for MIKEY key generation, in case of group 312 communication. The Responder MUST include a RAND payload in the 313 R_MESSAGE for TEK generation from a TGK when MIKEY-RSA-R is used for 314 group communication. 316 IDi and CERTi SHOULD be included, but they MAY be left out when it is 317 expected that the peer already knows the Initiating party's ID (or 318 can obtain the certificate in some other manner). For example, this 319 could be the case if the ID is extracted from SIP. For certificate 320 handling, authorization, and policies, see Sections 4.3 and 6.7 of 321 RFC 3830. If CERTi is included, it MUST correspond to the private 322 key used to sign the I_MESSAGE. 324 If the Responder has multiple Identities, the Initiator MAY also 325 include the specific identity, IDr, of the Responder with whom 326 communication is desired. If the Initiator's policy does not allow 327 acceptance of an R_MESSAGE from any entity other than one that can 328 assert a specific identity, the Initiator MUST include that specific 329 identity in an IDr payload in the I_MESSAGE. 331 The Initiator MAY also send security policy (SP) payload(s) 332 containing all the security policies that it supports. If the 333 Responder does not support any of the policies included, it SHOULD 334 reply with an Error message of type "Invalid SPpar" (Error no. 10). 335 The Responder has the option not to send the Error message in MIKEY 336 if a generic session establishment failure indication is deemed 337 appropriate and communicated via other means (see Section 4.1.2 of 338 [I-D.ietf-mmusic-kmgmt-ext] for additional guidance). 340 SIGNi is a signature covering the Initiator's MIKEY message, 341 I_MESSAGE, using the Initiator's signature key (see Section 5.2 of 342 RFC 3830 for the exact definition). The signature assures the 343 Responder that the claimed Initiator has indeed generated the 344 message. This automatically provides message integrity as well. 346 3.5. Processing the I_MESSAGE 348 Upon receiving an I_MESSAGE of the RSA-R format, the Responder MUST 349 respond with one of the following messages: 350 o The Responder SHOULD send an Error message "Message type not 351 supported" (Error no. 13), if it cannot correctly parse the 352 received MIKEY message. Error message format is as specified in 353 Section 5.1.2 of RFC 3830. Error no. 13 is not defined in RFC 354 3830, and so RFC 3830 compliant implementations MAY return "an 355 unspecified error occurred" (Error no. 12). 356 o The Responder MUST send an R_MESSAGE, if SIGNi can be correctly 357 verified and the timestamp is current; if an SP payload is present 358 in the I_MESSAGE the Responder MUST return one of the proposed 359 security policies that matches the Responder's local policy. 360 o If a RAND payload is present in the I_MESSAGE, both sides use that 361 RAND payload as the RAND value in the MIKEY key computation. In 362 case of multicast, if a RAND payload is present in the I_MESSAGE, 363 the Responder SHOULD ignore the payload. In any case, the 364 R_MESSAGE for multicast communication MUST contain a RAND payload 365 and that RAND payload is used for key computation. 366 o The rest of the error message rules are as described in Section 367 5.1.2 of RFC 3830, and message processing rules are as described 368 in Section 5.3 of RFC 3830. 370 3.6. Components of the R_MESSAGE 372 The HDR payload in the R_MESSAGE is formed following the procedure 373 described in RFC 3830. Specifically, the CSB_ID in the HDR payload 374 MUST be the same as the one in the HDR of the I_MESSAGE. The 375 Responder MUST fill in the number of CSs and the CS ID map type and 376 CS ID info fields of the HDR payload. 378 For group communication, all the members MUST use the same CSB_ID and 379 CS ID in computing the traffic keying material. Therefore, for group 380 key establishment, the Responder MUST include a General Extension 381 Payload containing a new CSB_ID in the R_MESSAGE. If a new CSB_ID is 382 present in the R_MESSAGE, the Initiator and the Responder MUST use 383 that value in key material computation. Furthermore, the CS ID map 384 type and CS ID map info MUST be populated by the Responder. The 385 General Extension Payload carrying a CSB_ID MUST NOT be present in 386 case of unicast communication. 388 The T payload is exactly the same as that received in the I_MESSAGE. 390 If the I_MESSAGE did not include the RAND payload, it MUST be present 391 in the R_MESSAGE. In case it has been included in the I_MESSAGE, it 392 MUST NOT be present in the R_MESSAGE. In group communication, the 393 Responder always sends the RAND payload and in unicast communication, 394 either the Initiator or the Responder (but not both) generate and 395 send the RAND payload. 397 IDr and CERTr SHOULD be included, but they MAY be left out when it 398 can be expected that the peer already knows the other party's ID (or 399 can obtain the certificate in some other manner). For example, this 400 could be the case if the ID is extracted from SIP. For certificate 401 handling, authorization, and policies, see Section 4.3. of RFC 3830. 402 If CERTr is included, it MUST correspond to the private key used to 403 sign the R_MESSAGE. 405 An SP payload MAY be included in the R_MESSAGE. If an SP payload was 406 in the I_MESSAGE, then R_MESSAGE MUST contain an SP payload 407 specifying the security policies of the secure RTP session being 408 negotiated. More specifically, the Initiator may have provided 409 multiple options, but the Responder MUST choose one option per 410 Security Policy Parameter. 412 The KEMAC payload contains a set of encrypted sub-payloads and a MAC: 413 KEMAC = E(encr_key, IDr || {TGK}) || MAC. The first payload (IDr) in 414 KEMAC is the identity of the Responder (not a certificate, but 415 generally the same ID as the one specified in the certificate). Each 416 of the following payloads (TGK) includes a TGK randomly and 417 independently chosen by the Responder (and possible other related 418 parameters, e.g., the key lifetime). The encrypted part is then 419 followed by a MAC, which is calculated over the KEMAC payload. The 420 encr_key and the auth_key are derived from the envelope key, env_key, 421 as specified in Section 4.1.4. of RFC 3830. The payload definitions 422 are specified in Section 6.2 of RFC 3830. 424 The Responder encrypts and integrity protects the TGK with keys 425 derived from a randomly or pseudo-randomly chosen envelope key, and 426 encrypts the envelope key itself with the public key of the 427 Initiator. The PKE payload contains the encrypted envelope key, 428 env_key: PKE = E(PKi, env_key). PKi denotes the Initiator's public 429 key. Note that, as suggested in RFC 3830, the envelope key MAY be 430 cached and used as the PSK for re-keying. 432 To compute the signature that goes in the SIGNr payload, the 433 Responder MUST sign: 435 R_MESSAGE (excluding the SIGNr payload itself) || IDi || IDr || T. 437 Note that the added identities and timestamp are identical to those 438 transported in the ID and T payloads. 440 3.7. Processing the R_MESSAGE 442 In addition to the processing rules in RFC 3830, the following rules 443 apply to processing of the R_MESSAGE of MIKEY RSA-R mode. 445 If the I_MESSAGE contained a RAND payload, the Initiator MUST 446 silently discard an R_MESSAGE that contains a RAND payload. 447 Similarly, if the I_MESSAGE did not contain a RAND payload, the 448 Initiator MUST silently discard an R_MESSAGE that does not contain 449 a RAND payload. 450 If the SP payload contains a policy not specified in the SP 451 message, if present, in the I_MESSAGE, such and R_MESSAGE MUST be 452 discarded silently. 454 3.8. Certificate handling 456 If a Certificate payload is present the X.509v3 URL Cert type from 457 Table 6.7.b [RFC3830] is the default method in RSA-R mode and MUST be 458 implemented. The HTTP URL to fetch a certificate as specified in RFC 459 2585 [RFC2585] MUST be supported. Devices are not required to 460 support the FTP URLs. When retrieving data from the URL, 461 application/pkix-cert MIME type with X.509 certificates DER encoded 462 MUST be supported. 464 The RECOMMENDED way of doing certificate validation is by using OCSP 465 as specified by RFC 2560 [RFC2560]. When OCSP is used and nextUpdate 466 time is present in the response it defines how long the certificate 467 can be considered valid and cached. If OCSP is not supported or 468 nextUpdate time is not present in the response the certificate cache 469 timeout is a matter of local policy. 471 The communicating peers (such as SIP UAs for instance) MAY choose to 472 create a URL pointing to certificate files residing on themselves or 473 by appending their ID and a ".cer" extension to a provisioned root 474 path to the certificate. Other methods MAY also be used, subject to 475 local policy. 477 3.9. Additions to RFC 3830 message types and other values 479 This document introduces two new message types (Table 6.1a of RFC 480 3830), an Error no (Table 6.12 of RFC 3830), and a general extension 481 payload (Table 6.15 of RFC 3830). This section specifies those 482 additions. 484 3.9.1. Modified Table 6.1a from RFC 3830 486 Modified Table 6.1a from RFC 3830: 488 Data type | Value | Comment 489 ------------------------------------------------------------------ 490 Pre-shared | 0 | Initiator's pre-shared key message 491 PSK ver msg | 1 | Verification message of a Pre-shared key msg 492 Public key | 2 | Initiator's public-key transport message 493 PK ver msg | 3 | Verification message of a public-key message 494 D-H init | 4 | Initiator's DH exchange message 495 D-H resp | 5 | Responder's DH exchange message 496 Error | 6 | Error message 497 DHHMAC init | 7 | DH HMAC message 1 498 DHHMAC resp | 8 | DH HMAC message 2 499 RSA-R I_MSG | 9 | Initiator's RSA-R public-key message (NEW) 500 RSA-R R_MSG | 10 | Responder's RSA-R public-key message (NEW) 502 Figure 3: Table 6.1a from RFC 3830 (Revised) 504 3.9.2. Modified Table 6.12 from RFC 3830 506 Modified Table 6.12 from RFC 3830: 508 Error no | Value | Comment 509 ------------------------------------------------------- 510 Auth failure | 0 | Authentication failure 511 Invalid TS | 1 | Invalid timestamp 512 Invalid PRF | 2 | PRF function not supported 513 Invalid MAC | 3 | MAC algorithm not supported 514 Invalid EA | 4 | Encryption algorithm not supported 515 Invalid HA | 5 | Hash function not supported 516 Invalid DH | 6 | DH group not supported 517 Invalid ID | 7 | ID not supported 518 Invalid Cert | 8 | Certificate not supported 519 Invalid SP | 9 | SP type not supported 520 Invalid SPpar | 10 | SP parameters not supported 521 Invalid DT | 11 | not supported Data type 522 Unspecified error | 12 | an unspecified error occurred 523 Unsupported | | 524 message type | 13 | unparseable MIKEY message (NEW) 526 Figure 4: Table 6.12 from RFC 3830 (Revised) 528 3.9.3. Modified Table 6.15 from RFC 3830 530 Modified Table 6.15 from RFC 3830: 532 Type | Value | Comments 533 --------------------------------------- 534 Vendor ID | 0 | Vendor specific byte string 535 SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in 536 | | [I-D.ietf-mmusic-kmgmt-ext]) 537 TESLA I-Key| 2 | [I-D.ietf-msec-bootstrapping-tesla] 538 Key ID | 3 | information on type and identity of keys 539 | | [I-D.ietf-mmusic-kmgmt-ext]) 540 CSB_ID | 4 | Responder's modified CSB_ID (group mode) 542 Figure 5: Table 6.15 from RFC 3830 (Revised) 544 4. Applicability of the RSA-R and RSA modes 546 MIKEY-RSA-R mode and RSA mode are both very useful: deciding on which 547 mode to use depends on the application. 549 The RSA-R mode is useful when you have reasons to believe that the 550 Responder may be a different party than the one to which the MIKEY 551 I_MESSAGE was sent. This is quite common in telephony and multimedia 552 applications where the session or the call can be retargeted or 553 forwarded. When the security policy allows it, leaving some 554 flexibility for the Initiator to see who the Responder may turn out 555 to be, before making the decision to continue or discontinue the 556 session may be appropriate. In such cases, the main objective of the 557 Initiator's RSA-R message is to present its public key/certificate to 558 the Responder, and wait for a Responder to present its identity. 560 The second scenario is when the Initiator already has the Responder's 561 certificate but wants to allow the Responder to come up with all the 562 keying material. This is applicable in conferences where the 563 Responder is the key distributor and the Initiators contact the 564 Responder to initiate key download. Notice that this is quite 565 similar to the group key download model as specified in GDOI 566 [RFC3547], GSAKMP [I-D.ietf-msec-gsakmp-sec], and GKDP 567 [I-D.ietf-msec-gkdp] protocols (also see [RFC4046]). The catch 568 however is that the participating entities must know that they need 569 to contact a well-known address as far as that conferencing group is 570 concerned. Note that they only need the Responder's address, not 571 necessarily its CERT. If the group members have the Responder's 572 CERT, there is no harm; they simply do not need the CERT to compose 573 I_MESSAGE. 575 The RSA mode is useful when the Initiator knows the Responder's 576 identity and CERT. This mode is also useful when the key exchange is 577 happening in an established session with a Responder (for example, 578 when switching from a non-secure mode to a secure mode), and when the 579 policy is such that it is only appropriate to establish a MIKEY 580 session with the Responder that is targeted by the Initiator. 582 4.1. Limitations 584 The RSA-R mode may not easily support 3-way calling, under the 585 assumptions that motivated the design. An extra message may be 586 required compared to the MIKEY-RSA mode specified in RFC 3830. 587 Consider that A wants to talk to B and C, but does not have B's or 588 C's CERT. A might contact B and request that B supply a key for a 589 3-way call. Now if B knows C's CERT, then B can simply use the 590 MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If not, 591 then the solution is not straightforward. For instance, A might ask 592 C to contact B or itself to get the TGK, in effect initiating a 3-way 593 exchange. It should be noted that 3-way calling is typically 594 implemented using a bridge, in which case there are no issues (it 595 looks like 3 point-to-point sessions, where one end of each session 596 is a bridge mixing the traffic into a single stream). 598 5. Security Considerations 600 We offer a brief overview of the security properties of the exchange. 601 There are two messages: the I_MESSAGE and the R_MESSAGE. The 602 I_MESSAGE is a signed request by an Initiator requesting the 603 Responder to select a TGK to be used to protect multimedia (e.g., 604 Secure RTP or SRTP [RFC3711] ) sessions. 606 The message is signed, which assures the Responder that the claimed 607 Initiator has indeed generated the message. This automatically 608 provides message integrity as well. 610 There is a timestamp in the I_MESSAGE, which when generated and 611 interpreted in the context of the MIKEY specification, assures the 612 Responder that the request is live and not a replay. Indirectly, 613 this also provides protection against a DoS attack in that the 614 I_MESSAGE must itself be signed. The Responder however would have to 615 verify the Initiator's signature and the timestamp, and thus would 616 spend significant computing resources. It is possible to mitigate 617 this by caching recently received and verified requests. 619 Note that the I_MESSAGE in this method basically equals DoS 620 protection properties of the DH method and not the public key method 621 as there are no payloads encrypted by the Responder's public key in 622 I_MESSAGE. If IDr is not included in the I_MESSAGE, the Responder 623 will accept the message and a response (and state) would be created 624 for the malicious request. 626 The R_MESSAGE is quite similar to the I_MESSAGE in the MIKEY-RSA mode 627 and has all the same security properties. 629 When using the RSA-R mode, the Responder may be a different party 630 than the one to which the MIKEY I_MESSAGE was sent. It is the 631 responsibility of the Initiator to verify that the identity of the 632 Responder is acceptable (based on its local policy) if it changes 633 from the party to which the MIKEY I_MESSAGE was sent, and to take 634 appropriate action based on the outcome. In some cases, it could be 635 appropriate to accept Responder's identity if it can be strongly 636 authenticated; in other cases, a blacklist or a whitelist may be 637 appropriate. 639 When both unicast and multicast streams need to be negotiated it is 640 RECOMMENDED to use multiple instances of MIKEY-RSA-R rather than a 641 single instance in group mode. This is to avoid potential key reuse 642 with counter mode. 644 5.1. Impact of the Responder choosing the TGK 646 In the MIKEY-RSA or PSK modes, the Initiator chooses the TGK and the 647 Responder has the option to accept the key or not. In the RSA-R mode 648 for unicast communication, the RECOMMENDED mode of operation is for 649 the Initiator and the Responder to contribute random information in 650 generating the TEK (RAND from the Initiator and the TGK from the 651 Responder). For group communication, the sender (MIKEY Responder) 652 will choose the TGK and the RAND; note that it is in the interest of 653 the sender to provide sufficient entropy to TEK generation since the 654 TEK protects data sent by the Responder. 656 Thus, in case of unicast communication, the RSA-R mode is slightly 657 better than the RSA mode in that it allows the Initiator as well as 658 the Responder to contribute entropy to the TEK generation process. 659 This comes at the expense of the additional message. However, as 660 noted earlier, the new mode needs the additional message to allow 661 simpler provisioning. 663 5.2. Updates to Security Considerations in RFC3830 665 MIKEY requires clock synchronization and a secure network clock 666 synchronization protocol SHOULD be used, e.g., [ISO3] or secure NTP 667 [I-D.ietf-ntp-ntpv4-proto]. 669 RFC 3830 has additional notes on the security properties of the MIKEY 670 protocol, key derivation functions and other components. 672 6. IANA Considerations 674 This specification requires the following IANA assignments to the 675 MIKEY registry : 676 Add to "Error Payload namespace:" 678 Unsupported message type ------- 13 680 Add to "Common Header payload name spaces:" 682 RSA-R I_MSG ------------- 9 683 RSA-R R_MSG ------------- 10 685 General Extensions payload name spaces: 687 CSB_ID ----------------- 4 688 (Note: if not available, please assign the next available 689 number) 691 7. Acknowledgments 693 Many thanks to Mark Baugher, Steffen Fries, Russ Housley, Cullen 694 Jennings, and Vesa Lehtovirta for their reviews of earlier version of 695 this document. 697 8. References 699 8.1. Normative References 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 705 Adams, "X.509 Internet Public Key Infrastructure Online 706 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 708 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 709 Infrastructure Operational Protocols: FTP and HTTP", 710 RFC 2585, May 1999. 712 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 713 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 714 August 2004. 716 8.2. Informative References 718 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 719 Group Domain of Interpretation", RFC 3547, July 2003. 721 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 722 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 723 RFC 3711, March 2004. 725 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 726 "Multicast Security (MSEC) Group Key Management 727 Architecture", RFC 4046, April 2005. 729 [I-D.ietf-msec-mikey-dhhmac] 730 Euchner, M., "HMAC-authenticated Diffie-Hellman for 731 MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in 732 progress), April 2005. 734 [I-D.ietf-msec-gsakmp-sec] 735 Harney, H., "GSAKMP: Group Secure Association Group 736 Management Protocol", draft-ietf-msec-gsakmp-sec-10 (work 737 in progress), May 2005. 739 [I-D.ietf-msec-gkdp] 740 Dondeti, L., "GKDP: Group Key Distribution Protocol", 741 draft-ietf-msec-gkdp-01 (work in progress), March 2006. 743 [I-D.ietf-mmusic-kmgmt-ext] 744 Arkko, J., "Key Management Extensions for Session 745 Description Protocol (SDP) and Real Time Streaming 746 Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in 747 progress), June 2005. 749 [I-D.ietf-msec-bootstrapping-tesla] 750 Fries, S. and H. Tschofenig, "Bootstrapping TESLA", 751 draft-ietf-msec-bootstrapping-tesla-03 (work in progress), 752 January 2006. 754 [I-D.ietf-msec-newtype-keyid] 755 Carrara, E., "The Key ID Information Type for the General 756 Extension Payload in MIKEY", 757 draft-ietf-msec-newtype-keyid-05 (work in progress), 758 March 2006. 760 [I-D.ietf-ntp-ntpv4-proto] 761 Burbank, J., "The Network Time Protocol Version 4 Protocol 762 Specification", draft-ietf-ntp-ntpv4-proto-02 (work in 763 progress), May 2006. 765 [ISO3] ISO, "ISO/IEC 18014 Information technology - Security 766 techniques - Time-stamping services, Part 1-3", 2002. 768 Authors' Addresses 770 Dragan Ignjatic 771 Polycom 772 1000 W. 14th Street 773 North Vancouver, BC V7P 3P3 774 Canada 776 Phone: +1 604 982 3424 777 Email: dignjatic@polycom.com 778 Lakshminath Dondeti 779 QUALCOMM 780 5775 Morehouse drive 781 San Diego, CA 92121 782 US 784 Phone: +1 858 845 1267 785 Email: ldondeti@qualcomm.com 787 Francois Audet 788 Nortel 789 4655 Great America Parkway 790 Santa Clara, CA 95054 791 US 793 Phone: +1 408 495 3756 794 Email: audet@nortel.com 796 Ping Lin 797 Nortel 798 250 Sidney St. 799 Belleville, Ontario K8P3Z3 800 Canada 802 Phone: +1 613 967 5343 803 Email: linping@nortel.com 805 Full Copyright Statement 807 Copyright (C) The Internet Society (2006). 809 This document is subject to the rights, licenses and restrictions 810 contained in BCP 78, and except as set forth therein, the authors 811 retain all their rights. 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Intellectual Property 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at 843 ietf-ipr@ietf.org. 845 Acknowledgment 847 Funding for the RFC Editor function is provided by the IETF 848 Administrative Support Activity (IASA).