idnits 2.17.1 draft-ietf-msec-gkdp-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 664. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: GKCS-CERT: This optional payload SHOULD not be any different than in the registration. -- 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 (Mar 2006) is 6589 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: 'CERTREQ' is mentioned on line 228, but not defined == Missing Reference: 'N' is mentioned on line 464, but not defined == Missing Reference: 'GKCS-CERT' is mentioned on line 448, but not defined == Missing Reference: 'D' is mentioned on line 464, but not defined == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'I-D.ipsec-rfc2401bis' is defined on line 610, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC WG L. Dondeti 3 Internet-Draft QUALCOMM 4 Expires: September 2, 2006 J. Xiang 5 Nortel Networks 6 S. Rowles 7 Cisco 8 Mar 2006 10 GKDP: Group Key Distribution Protocol 11 draft-ietf-msec-gkdp-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 2, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document specifies a group key distribution protocol (GKDP) 45 based on IKEv2, the IPsec key management protocol; the new protocol 46 is similar to IKEv2 in message and payload formats, and message 47 semantics to a large extent. The protocol in conformance with MSEC 48 key management architecture contains two components: member 49 registration and group rekeying, and downloads a group security 50 association from the GCKS to a member. This protocol is independent 51 of IKEv2 except in its likeness. 53 Conventions Used In This Document 55 This document recommends, as policy, what specifications for Internet 56 protocols -- and, in particular, IETF standards track protocol 57 documents -- should include as normative language within them. The 58 capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in 59 the sense of how they would be used within other documents with the 60 meanings as specified in BCP 14, RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Revision History . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 66 2.1. Why do we need another GSA management protocol? . . . . . 3 67 2.2. GKDP usage scenarios . . . . . . . . . . . . . . . . . . . 4 68 3. GKDP protocol . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Member registration and secure channel establishment . . . 4 70 3.1.1. Initial exchange:GSA_INIT_EXCH . . . . . . . . . . . . 4 71 3.1.2. Authenticated exchange:GSA_AUTH_EXCH . . . . . . . . . 6 72 3.2. GSA maintenance channel . . . . . . . . . . . . . . . . . 9 73 3.2.1. GSA rekey protocol . . . . . . . . . . . . . . . . . . 9 74 4. Informational exchange . . . . . . . . . . . . . . . . . . . . 11 75 4.1. Notify exchange . . . . . . . . . . . . . . . . . . . . . 11 76 4.2. Error message . . . . . . . . . . . . . . . . . . . . . . 11 77 5. Traffic selectors . . . . . . . . . . . . . . . . . . . . . . 11 78 6. GKDP protocol design details . . . . . . . . . . . . . . . . . 11 79 7. Header and payload formats . . . . . . . . . . . . . . . . . . 12 80 7.1. GKDP header . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 Intellectual Property and Copyright Statements . . . . . . . . . . 16 90 1. Revision History 92 GKDP-xx: Draft tag and title changed to gkdp-xx 93 Version 01: The protocol has been renamed GKDP for Group Key 94 Distribution Protocol as per discussions at the MSEC meeting at 95 IETF-60 and mailing list discussions. The name GDOIv2 will be 96 used for a revision of GDOI which may retain the DOI concept and 97 build upon RFC 3547. 98 Version 02: This is a major revision with the following additions to 99 the specification: 101 * 103 2. Introduction and Overview 105 Security encapsulation protocols such as IPsec and SRTP provide 106 confidentiality, message integrity, replay protection, and in some 107 instances access control, and data origin authentication. These 108 security services require state establishment, maintenance, and 109 teardown for correct operation. While these security associations 110 can be managed manually, automatic key management protocols are 111 essential for efficient and scalable operation. In case of point-to- 112 point security associations, IKE and its successor IKEv2 are widely 113 used for IPsec SAs, and MIKEY for SRTP associations. For multi-point 114 SAs or group SAs (GSA), GDOI, GSAKMP, and MIKEY have been specified 115 by the MSEC WG. GKDP is designed to be a counterpart - for GSA 116 distribution and maintenance - to IKEv2 so we can reuse the work put 117 in to its design and analysis, and of course implementation. 119 2.1. Why do we need another GSA management protocol? 121 Given the collection of key management protocols mentioned above, 122 there is a question on the need for yet another group key management 123 protocol. First a look back at history: So far, we have two 124 experimental RFCs, viz., RFC 1949 [RFC1949] and RFC 2093 [RFC2093], 125 and a standards track RFC, RFC 3547 [RFC3547] specifying or 126 describing group key management protocols. Furthermore there is 127 GSAKMP, currently a standards track MSEC I-D, which borrows quite a 128 few concepts from IKEv2, but not quite similar to IKEv2. The 129 protocol we propose is mainly to reuse as much as the IKEv2 codebase, 130 similar to GDOI reusing payload and message formats of IKE [RFC2409] 131 and ISAKMP [RFC2408] . Consequently, GKDP requires fewer messages 132 compared to GDOI, specifically 4 in most cases, compared to 10 in 133 main mode and 7 in aggressive mode of GDOI. We discuss the 134 advantages of GKDP, the shortcomings and remedies to address those 135 shortcomings. 137 2.2. GKDP usage scenarios 139 GKDP is a key download protocol. Key download as opposed to key 140 negotiation has several interesting use cases. 142 o The first application is multicast security. As with GDOI, the 143 current version of the GKDP spec limits the scope to single sender 144 multicast applications. 145 o The second intended application is point to point data security 146 associations facilitated by a centralized group key server. 147 o Others to be listed! 149 3. GKDP protocol 151 3.1. Member registration and secure channel establishment 153 The first of two components in GSA establishment and maintenance is 154 member registration. 156 3.1.1. Initial exchange:GSA_INIT_EXCH 158 The first step in the registration protocol is to establish a secure 159 channel with the group controller and key server (GCKS). This 160 exchange is similar to IKE_SA_INIT exchange of IKEv2. The 161 registering member proposes various combinations of algorithms in 162 SAi1 to constitute the secure channel, along with a nonce, Ni, and a 163 DH exponent, KEi. The GCKS has several options: 165 o In the first, it honors the member's request for registration and 166 sends the necessary information to complete the DH exchange: it 167 selects and specifies the parameters of the secure channel, and 168 includes a nonce Nr, and a public DH value of its own, KEr. 169 o The second option is for the GCKS to consider if the request for 170 secure channel establishment is spurious. The GCCKS has no way to 171 tell except to throttle such requests by making the initiator do 172 some work before it invests any computing resources. We refer to 173 this mode as the denial-of-service or DoS protection mode 174 specified in detail in Section 3.1.1.1 . 175 o Finally, if none of the proposals are acceptable to the GCKS, it 176 may reject the initial exchange itself. 178 GSA_INIT_EXCH message is as follows: 180 Member->GCKS: M1: HDR, SAi1, KEi, Ni 181 GCKS->Member: M2: HDR, SAr1, KEr, Nr, [CERTREQ] 183 Figure 1: Secure channel establishment 185 3.1.1.1. DoS protection mode 187 In typical deployments of multicast or group security services, the 188 GCKS address is well-known, which allows adversaries to launch a DoS 189 attack by sending bogus GSA_INIT_EXCH messages. In the normal mode 190 of operation, the GCKS responds and needs to maintain state 191 (including storing Messages 1 and 2) corresponding to each exchange 192 in progress. Notice that this process might result in the GCKS 193 storing unnecessary state about bogus exchanges. To avoid this 194 attack, the GCKS may first choose to verify whether the Intiator is 195 live and responding to and processing GKDP messages. 197 The GCKS verifies whether a prospective member (or the initiatior of 198 the key exchange protocol) is live using the following procedure. 199 The GCKS responds to the Initiator's message, by sending a challenge 200 - a notify message (see Section 4), containing a a random value or 201 generally referred to as a COOKIE; the GCKS MUST choose the COOKIE 202 size between 1 and 64 octets. The Intiator is expected to include 203 the received COOKIE as part of modified Message 1, which we refer to 204 as "Response Message." (see Figure 2). 206 The GCKS may choose to store the COOKIE and other relevant additional 207 information such as Initiator's identity (thus reducing the amount of 208 state to be stored, but not entirely eliminating it), to verify that 209 the Initiator indeed used the COOKIE that was sent by the GCKS. 210 Alternatively, it may generate the COOKIE following a local procedure 211 (that the Initiator cannot repeat to generate another valid cookie) 212 to encode the Initiator's identity, Message 1 etc. For instance the 213 IKEv2 specification suggests the following derivation to generate 214 cookies: 216 COOKIE = VersionIDofGCKS-Secret | Hash(Ni | IPi | SPIi | GCKS-secret) 218 The GCKS may use (TBD) method to expand or truncate the above value 219 to generate the COOKIE of size (MUST be between 1-64 octets) based on 220 local policy. 222 DoS protection exchange is as follows: 224 Member->GCKS: M1: HDR(A,0), SAi1, KEi, Ni 225 GCKS->Member: CM: HDR(A,0), N(COOKIE) 227 Member->GCKS: RM: HDR(A,0), N(COOKIE), SAi1, KEi, Ni 228 GCKS->Member: M2: HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 230 CM: Challenge Message from the GCKS 231 RM: Challenge-Response Message from the Member 233 Figure 2: DoS protection mode of GSA_INIT_EXCH 235 3.1.2. Authenticated exchange:GSA_AUTH_EXCH 237 The GSA_INIT_EXCH (2 message or 4 message version) establishes an 238 unauthenticated secure channel between a prospective member and the 239 GCKS. The next step is for the member to request the GCKS to join a 240 group; the GCKS evaluates the request and based on the evaluation a) 241 accept the request and send the corresponding GSA 243 GSA_AUTH_EXCH message is as follows: 245 Member->GCKS: M3: HDR, SK{ G-ID, IDi, [ID_CERT,] [ID_CERTREQ,] AUTH, 246 [IDr,] [GM_CERT,] [GM_CERTREQ,] [POP_I] } 247 GCKS->Member: M4: HDR, SK{ IDr, [ID_CERT,] AUTH, GSA, [,KD] [,SEQ] 248 [GCKS_CERT,] [,POP_R]} 250 Figure 3: Authenticated Exchange 252 The various payloads in the GSA_AUTH_EXCH messages have the following 253 purposes: 255 o G-ID: The group identity payload constructed using the IKEv2 256 Identification Payload specifies the secure group that M3 wants to 257 join. 258 o ID_CERT: The optional ID_CERT payload contains a certificate(s) 259 asserting the GCKS's or a member's claimed identity as in IDi or 260 IDr payloads. 261 o GM_CERT: The optional GM_CERT payload contains a certificate 262 asserting the group member's authorization to join the group G-ID 263 as member. 265 o GCKS_CERT: The optional GCKS_CERT payload contains a certificate 266 asserting the GCKS's authorization to serve the role of a group 267 controller and key server for the group G-ID. 268 o AUTH: The AUTH payload constitues the "authenticated" portion of 269 the 4 or 6 message AKE. In other words, the member in M3 and the 270 GCKS in M4 prove that they are indeed the entities that sent M1 271 and M2 respectively. A pre-established shared secret or a 272 certificate (optionally specified in the CERT payload) may be used 273 for entity authentication. 274 o POP: Similar to the AUTH payload's use in providing host/entity 275 authentication, the POP payload is for member/GCKS authorization 276 to assume their claimed roles. The GM_CERT or GCKS_CERT is used 277 to sign a block of data, specified below, to constitute the POP 278 payload. 279 o GSA: The GSA payload contains the rekey and data security SA 280 payloads. Note that this SA is not negotiated; the GCKS simply 281 sends this SA. 282 o KD: The KD payload contains the secret keys corresponding the 283 rekey and the data security SAs included in the GSA payload. 284 o SEQ: The optional SEQ payload MUST be included if the GSA payload 285 contains a rekey SA. The SEQ payload contains a SEQ number for 286 replay protection of the rekey messages. 288 3.1.2.1. Key material computation 290 The key material computation and the AUTH payload are identical to 291 that described in the IKEv2 specification. 293 Key material and registration SA keys are computed as follows: 295 SKEYSEED = prf(Ni | Nr, g^ir) 297 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 298 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ), where 300 prf+ is defined as follows: 302 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 304 where: 305 T1 = prf (K, S | 0x01) 306 T2 = prf (K, T1 | S | 0x02) 307 T3 = prf (K, T2 | S | 0x03) 308 T4 = prf (K, T3 | S | 0x04) 310 Figure 4: Registration SA key material computation 312 3.1.2.2. Member and GCKS authentication and authorization 314 GKDP requires mutual authentication between each member and a GCKS, 315 as well as mutual authorization. First the member and the GCKS 316 authenticate to each other using pre-shared keys or certificates 317 prior to establishing a secure channel. M3 and M4 contain AUTH 318 payloads that essentially protect against man-in-the-middle attacks 319 against the DH exchange in M1 and M2. The member and the GCKS 320 construct AUTH payloads by computing an HMAC over or signing a block 321 of data containing the message M1 or M2 they sent earlier, the other 322 party's nonce payload, and a prf over own identity. More formally, 323 the block of data for HMAC or signature is as follows: 325 Auth payload computation: 327 Auth payload in M3 is computed over: 329 auth-block-M3: M1 || Nr-Payload || prf(SK_pi, IDi-Payload) 331 Auth payload in M4 is computed over: 333 auth-block-M4: M2 || Ni-Payload || prf(SK_pr, IDr-Payload) 335 For shared secret based host authentication AUTH payload is 336 computed as follows: 338 AUTH = prf(prf(Shared Secret,"KeyPad:GKDP-AUTH-MX"), 339 ) 341 Figure 5: Auth payload computation 343 3.1.2.2.1. Use of asymmetric authentication methods 345 GKDP also allows the member and the GCKS to use different 346 authentication methods, similar to TLS and IKEv2. More specifically, 347 the GCKS uses a cert to authenticate itself and establish a secure 348 channel, and the member uses EAP to send its authentication 349 information via the secure channel. 351 Members may also use EAP to prove their authorization to join a 352 secure group. For instance, consider a use case where a member may 353 use a SIM card for authentication, or a pre-paid SIM card to pay for 354 content distributed to a secure group. In these cases, the 355 authentication or authorization information can be sent via EAP. 357 3.1.2.2.2. Proof of possession 359 Proof of possession payload (POP) provides a mechanism so that 360 members and/or GCKS can prove to the other party that they are indeed 361 authorized to be a member or the GCKS, respectively. For POP payload 362 derivation in GKDP, the member or the GCKS first constructs a message 363 block, POP-HASH, containing the two nonces exchanged in GSA_INIT_EXCH 364 and the prf over the ID payload as defined in the AUTH payload 365 construction. Next, the member or the GCKS signs the POP-HASH value. 367 POP-HASH construction is as follows: 369 POP payload : 371 POP payload in M3 is constructed over the following message block: 373 POP-HASH-M3: "KeyPad:GKDP-POP-M3" || 374 Ni-Payload || Nr-Payload || prf(SK_pi, IDi-Payload) 376 POP payload in M4 is computed over: 378 POP-HASH-M4: "KeyPad:GKDP-POP-M4" || 379 Ni-Payload || Nr-Payload || prf(SK_pr, IDr-Payload) 381 Figure 6: POP payload computation block 383 3.2. GSA maintenance channel 385 3.2.1. GSA rekey protocol 387 GSA rekey protocol is optional to implement, but it plays a crucial 388 role for large and dynamic groups. 390 The GCKS is responsible for rekeying of the secure group as per the 391 group policy. The GCKS uses multicast or multi-unicast to transport 392 the rekey message. When multi-unicast is used, it may be appropriate 393 in some scenarios to have a reply message from the member(s) to the 394 GCKS. The reply message is optional. 396 Rekey message is as follows: 398 Multicast: 399 GCKS->Member: HDR, SK {[N], SEQ, GSA, KD, [GCKS_CERT,] SIG} 401 Unicast: 402 GCKS->Member: HDR, SK {N, SEQ, GSA, KD, [GCKS_CERT,] SIG} 403 [Member->GCKS]: [HDR, SK {N, SEQ, AUTH}] 405 Figure 7: Rekey message 407 3.2.1.1. Multicast Rekey 409 The multicast rekey is multicasted to all the group members that have 410 completed the member registration in section 3.1. 412 The HDR is the GKDP Header defined in section 5.1 414 The Notify Payload MAY be used by the GKCS to inform the group member 415 of the type of rekey that is being conveyed or if there is an error 416 state to convey to the group member. The Notify Message may be one 417 of the following: 419 STATUS NOTIFY TYPE 420 KEKUPDATE 40960 Notify the member that rekey SA has expired 421 TEKUPDATE 40961 Notify the member that Data SA has expired 422 KEKTEKUPDATE 40962 Both the types of SA have expired and will be 423 refreshed 425 ERROR NOTIFY TYPE 426 TBD 428 The SEQ payload contains a sequence number that orders the rekey 429 messages. The group member MUST check to see that the sequence 430 number is greater than in the previous rekey message, before acting 431 any further on the message. The sequence number for a new rekey SA 432 will start from one. 434 The GSA payload contains the current rekey and data security SA 435 payloads. The GSA may contain a new data security SA or a new rekey 436 SA or both. The GSA MAY also contain an LKH rekey SA, TBD. 438 The KD represents the keys for the policy sent in the GSA. If the 439 data security SA is being refreshed in this rekey message, the IPSec 440 keys are updated in the KD, and/or if the rekey SA is being refreshed 441 in this rekey message, the rekey Key is updated in the KD payload. 443 GKCS-CERT: This optional payload SHOULD not be any different than in 444 the registration. 446 The SIG payload is a signature of the hash of the message, not 447 including the GKDP header, prefixed with the string "GKDP-rekey". 448 Hash {"GKDP-rekey", [N], SEQ, GSA, KD, [GKCS-CERT] } 450 After adding the Signature of the above Hash to the rekey message, it 451 is then encrypted with the rekey SA and multicasted to the group 452 members which are registered with the GKCS. 454 3.2.1.2. Group Member Reply 456 3.2.1.3. Delete via Rekey SA 458 The GKCS may want to delete the data security and/or rekey SAs for 459 various reasons. One or more Delete Payloads [RFC 4306, Section 460 3.11] MAY follow the SEQ payload in a REKEY message in order to 461 delete keys. If the GKCS has no further SAs to send to the group 462 members, the GSA and KD payloads must be omitted from the rekey 463 message. 464 HDR, SK {[N], SEQ, D, [D], SIG} 466 4. Informational exchange 468 4.1. Notify exchange 470 4.2. Error message 472 5. Traffic selectors 474 Traffic Selector(TS) allows the GCKS to communicate what kind of 475 packets will be forwarded over the newly downloaded GSA. It can be 476 used to implement a Secure Policy Database (SPD). It can also be 477 used to solve other problems such as the replay window with QoS 478 issue. Unlike negotiated key protocol, in whichTraffic Selector can 479 be negotiated down e.g. the responder can choose a subset of the 480 traffic proposed by the initiator; GKDP is a key downloading protocol 481 in which the Traffic Selector sent by the GCKS together with the GSA 482 specifies the selection criteria for packets forwarded over the new 483 GSA. For rekeys, TS needs not be specified. 485 6. GKDP protocol design details 486 7. Header and payload formats 488 GKDP payload design is based on IKEv2 payloads, to allow reuse of the 489 IKEv2 payload processing code. Furthermore, we draw on the GDOI 490 design specified in RFC3547, where possible and appropriate to avoid 491 reinvention. 493 7.1. GKDP header 495 GKDP messages use UDP ports GKDP-PORT and GKDP-NAT-PORT (TBA-IANA), 496 with one GKDP message per datagram. The source and destination IP 497 addresses from the IP header are used with role reversal to send the 498 response messages. GKDP messages sent/received on UDP port GKDP-PORT 499 follow the format of a UDP header followed by a GDKP header. GKDP 500 messages sent/received on UDP port GKDP-NAT-PORT have four octets of 501 zero immediately following the UDP header; the GKDP header follows 502 the zeros. The zeros are not part of part of the GKDP message and 503 therefore not part of the payload length fields. All GKDP messages 504 begin with the GKDP header. 506 Following the GKDP header -denoted by HDR in GKDP messages - are one 507 or more GKDP payloads each identified by a "Next Payload" field in 508 the preceding payload. Payloads are processed in the order in which 509 they appear in an GKDP message by invoking the appropriate processing 510 routine according to the "Next Payload" field in the IKE header and 511 subsequently according to the "Next Payload" field in the IKE payload 512 itself until a "Next Payload" field of zero indicates that no 513 payloads follow. If a payload of type "Encrypted" is found, that 514 payload is decrypted and its contents parsed as additional payloads. 515 An Encrypted payload MUST be the last payload in a packet and an 516 encrypted payload MUST NOT contain another encrypted payload. 518 IPsecbis multicast group address or the destination address in the IP 519 header and the Recipient SPI in the GKDP header identifies an 520 instance of an GKDP security association. 522 The format of the GKDP header is shown in Figure Figure 11: 524 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 ! GKDP Initiator's SPI ! 528 ! ! 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 ! GKDP Responder's SPI ! 531 ! ! 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 ! Message ID ! 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 ! Length ! 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Figure 11: GKDP Header Format 542 8. Security considerations 544 TBD 546 Since GKDP piggybacks on the IKEv2 protocol and completes 547 registration in the last two messages, of the ikev2 protocol, there 548 is no opportunity for the group member to reply back to the GKCS that 549 it cannot handle the policy sent in the GSA. In this case, the group 550 member can send an informational message to the GKCS, which will then 551 have to tear down any state regarding this group member. 553 9. IANA Considerations 555 This document defines a number of new exchanges, fields and values 556 where future assignments are needed from IANA. This section lists 557 what future IANA assignments are needed. 559 UDP port number for GKDP exchanges. 560 GSA_INIT_EXCH exchange type 561 GSA_AUTH_EXCH exchange type 562 GSA_INFO_EXCH exchange type 563 GSA_REKEY exchange type 564 new Payload Types 565 G-ID 566 SEQ 567 GSA 568 POP 569 KD 571 10. Acknowledgments 573 GKDP is based on IKEv2 and GDOI. Several sections of this document 574 are quite identical to IKEv2 and GDOI specifications; in some cases 575 the text may be identical to the text in those specifications. We 576 included the text for completeness of this specification. We 577 appreciate the efforts of the contributors and editors of those 578 protocols. 580 11. References 582 11.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 588 Group Domain of Interpretation", RFC 3547, July 2003. 590 [I-D.ietf-ipsec-ikev2] 591 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 592 draft-ietf-ipsec-ikev2-17 (work in progress), 593 October 2004. 595 11.2. Informative References 597 [RFC1949] Ballardie, T., "Scalable Multicast Key Distribution", 598 RFC 1949, May 1996. 600 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 601 Protocol (GKMP) Specification", RFC 2093, July 1997. 603 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 604 Security Association and Key Management Protocol 605 (ISAKMP)", RFC 2408, November 1998. 607 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 608 (IKE)", RFC 2409, November 1998. 610 [I-D.ipsec-rfc2401bis] 611 "Security Architecture for the Internet Protocol", 612 draft-ipsec-rfc2401bis-00 (work in progress), 613 October 2003. 615 Authors' Addresses 617 Lakshminath Dondeti 618 QUALCOMM 619 5775 Morehouse Drive 620 San Diego, CA 92121 621 US 623 Phone: +1 858 845 1267 624 Email: ldondeti@qualcomm.com 626 Jing Xiang 627 Nortel Networks 628 600 Technology Park drive 629 Billerica, MA 01821 630 US 632 Phone: +1 978 288 8985 633 Email: jxiang@nortel.com 635 Sheela Rowles 636 Cisco 637 US 639 Phone: 640 Email: 642 Intellectual Property Statement 644 The IETF takes no position regarding the validity or scope of any 645 Intellectual Property Rights or other rights that might be claimed to 646 pertain to the implementation or use of the technology described in 647 this document or the extent to which any license under such rights 648 might or might not be available; nor does it represent that it has 649 made any independent effort to identify any such rights. Information 650 on the procedures with respect to rights in RFC documents can be 651 found in BCP 78 and BCP 79. 653 Copies of IPR disclosures made to the IETF Secretariat and any 654 assurances of licenses to be made available, or the result of an 655 attempt made to obtain a general license or permission for the use of 656 such proprietary rights by implementers or users of this 657 specification can be obtained from the IETF on-line IPR repository at 658 http://www.ietf.org/ipr. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights that may cover technology that may be required to implement 663 this standard. Please address the information to the IETF at 664 ietf-ipr@ietf.org. 666 Disclaimer of Validity 668 This document and the information contained herein are provided on an 669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 671 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 672 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 673 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 676 Copyright Statement 678 Copyright (C) The Internet Society (2006). This document is subject 679 to the rights, licenses and restrictions contained in BCP 78, and 680 except as set forth therein, the authors retain all their rights. 682 Acknowledgment 684 Funding for the RFC Editor function is currently provided by the 685 Internet Society.