idnits 2.17.1 draft-atwood-pim-gsam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 document seems to lack a Security Considerations section. == There are 10 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 11 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 21, 2014) is 3560 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) == Unused Reference: 'I-D.atwood-pim-sigmp' is defined on line 619, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-yeung-g-ikev2-07 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM W. Atwood 3 Internet-Draft B. Li 4 Intended status: Standards Track Concordia University/CSE 5 Expires: January 22, 2015 July 21, 2014 7 Group Security Association Management Protocol 8 draft-atwood-pim-gsam-00 10 Abstract 12 This document specifies a Group Security Association Management 13 (GSAM) protocol, which manages the IPsec Group Security Associations 14 that are used to protect some packets of Secure IGMP (SIGMP) and 15 Secure MLD (SMLD). In GSAM, one router is elected as the group 16 controller / key server to create group security associations for all 17 the interesting secure groups and distribute them to authorized users 18 and other routers. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 22, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Assumption . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. GSAM Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Phase 1: Registration . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Message Exchanges . . . . . . . . . . . . . . . . . . . . 5 60 4.1.1. GSAM_INIT Exchange . . . . . . . . . . . . . . . . . 5 61 4.1.2. GSAM_AUTH Exchange . . . . . . . . . . . . . . . . . 5 62 4.2. EU Operations . . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. Non-Querier Operations . . . . . . . . . . . . . . . . . 7 64 4.4. Querier Operations . . . . . . . . . . . . . . . . . . . 8 65 5. Phase 2: GSA Distribution . . . . . . . . . . . . . . . . . . 9 66 5.1. Message Exchanges . . . . . . . . . . . . . . . . . . . . 9 67 5.1.1. GSAM_PUSH Exchange . . . . . . . . . . . . . . . . . 9 68 5.1.2. GSAM_RE_DISTRIBUTION Exchange . . . . . . . . . . . . 10 69 5.2. Querier Operations . . . . . . . . . . . . . . . . . . . 11 70 5.3. GM Operations . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Handover of Q . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 8.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 This document specifies a Group Security Association Management 81 (GSAM) protocol, which manages the IPsec Group Security Associations 82 (GSAs) that are used to protect some packets of Secure IGMP (SIGMP) 83 [I-D.atwood-pim-sigmp]and Secure MLD (SMLD) (not yet issued). GSAM 84 is implemented in the multicast enabled segment. The Querier on this 85 segment is responsible for distributing GSAs to all the authorized 86 users and other routers. Negotiation of certain parameters of the 87 GSA may be triggered if necessary. 89 GSAM is similar to GDOI [RFC6407] and g-ikev2 [I-D.yeung-g-ikev2], 90 although it is different from these protocols in important ways. 91 First, GDOI and g-ikev2 deliver only the necessary keys for IPsec, 92 while all the parameters of the GSAs of the IPsec system are 93 distributed in GSAM. The GSAs include not only keys, but also 94 security parameter indexes (SPIs) of the IPsec system [RFC4301]. 95 Second, there is a super group, 224.0.0.22 in IPv4 system or 96 FF02:0:0:0:0:0:0:16 in IPv6 system, in GSAM. All the group members 97 registered in the super group are also registered in all other active 98 groups on this network segment. Third, GSAM is a link-local protocol 99 while GDOI and g-ikev2 are group domain protocols. In GSAM, the TTL 100 of all the messages is equal to 1. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 106 this document are to be interpreted as described in [RFC2119]. 108 In addition, the following terms are used in this document 110 Querier (Q): 112 A Querier is an edge router that has won in the querier election in 113 SIGMP or SMLD. In GSAM, it takes the role of group controller / 114 key server (GCKS). 116 Non-Querier (NQ): 118 A Non-Querier is an edge router that has lost in the querier 119 election in SIGMP or SMLD. 121 Group Member (GM): 123 Group Member is an end user or an edge router that has registered 124 in Q. 126 Secure Group Table (SGT): 128 Secure Group Table is a table in Q that records the secure groups 129 and the GMs in the secure groups. It consists of two fields: 130 multicast address (MA) and group member set (GMS). MA is an index 131 of SGT and its value is a secure multicast group address. GMS 132 contains the unicast addresses of GMs in a group identified by the 133 value of MA. The initial SGT only has one record whose MA field is 134 224.0.0.22 in IPv4 system or FF02:0:0:0:0:0:0:16 in IPv6 system and 135 whose GMS field is empty. 137 GSAM_TEK_SA: 139 GSAM_TEK_SA is a pair of GSAs, including GSA_q and GSA_r. GSA_q is 140 a GSA of IPsec system used to protect a secure group query in SIGMP 141 or SMLD. GSA_r is a GSA of IPsec system used to protect the secure 142 group report in SIGMP or SMLD. 144 GSAM_KEK_SA: 146 GSAM_KEK_SA is a pair of SAs, including KEK_USA and KEK_GSA. 147 KEK_USA is a unicast SA whose direction is from a GM to Q. It is 148 used to protect the messages in Phase 2 sent by GMs. KEK_GSA is a 149 GSA whose direction is from Q to a secure group. It is used to 150 protect the messages in Phase 2 sent by Q. 152 2. Assumption 154 The protocol GSAM is based on two assumptions as follows: 156 The end users have been authenticated and authorized at the 157 application layer. The authorized EU and its Q have shared the 158 same secret key, call MSSK, as a pre-shared key. The details of 159 how to authenticate and authorize users is not specified in this 160 document. It is implemented based on PANA [RFC5191] as shown in 161 draft-atwood-mboned-mrac-pana (not yet issued). 163 Instead of IGMP or MLD, SIGMP or SMLD is used by users (or routers) 164 to report (or learn) IP multicast group memberships to neighboring 165 multicast routers (or from the users that are only one IP hop away) 166 in an IPv4 network or an IPv6 network. 168 3. GSAM Overview 170 GSAM is a protocol that manages group security associations (GSAs) of 171 the IPsec system used to protect some packets of SIGMP or SMLD. The 172 network entities mentioned in GSAM are the same as those in SIGMP or 173 SMLD, including edge routers (ERs) and end users (EUs). In GSAM, an 174 ER (called Querier) plays the role of GCKS. It accepts the 175 registration from EUs and NQs and grants them the status of GMs in 176 secure groups. It creates or updates GSAs of IPsec system for secure 177 groups and distributes them to all GMs in the secure group. 179 Security parameter index (SPI) as a parameter of GSAs must be paid 180 specific attention. Different from a unicast SA that is used by only 181 one receiver, a GSA is shared by multiple receivers. As a result, 182 instead of one receiver to determine the SPI value, all the GMs in 183 the same secure group should negotiate the SPI value together in 184 order to avoid SPI collisions at GMs. In GSAM, Q suggests SPI values 185 first. If any GM rejects the offered suggestion, a negotiation will 186 be triggered to determine suitable SPI values. 188 4. Phase 1: Registration 190 In Phase 1, both NQs and EUs should register themselves in Q in order 191 to become GMs in a group. A pair of SAs, named GSAM_KEK_SA is 192 distributed to GMs. 194 4.1. Message Exchanges 196 The registration involves two message exchanges: GSAM_INIT exchange 197 and GSAM_AUTH exchange. An EU / NQ performs GSAM_INIT exchange only 198 once as long as no new Q is elected in SIGMP or SMLD. However, an EU 199 may perform a GSAM_AUTH exchange many times. The number of GSAM_AUTH 200 exchanges for an EU is equal to the number of secure groups that an 201 EU is authorized to join at the application layer. 203 4.1.1. GSAM_INIT Exchange 205 GSAM_INIT exchange is identical to IKE_SA_INIT of IKE v2 defined in 206 [RFC5996]. An EU / NQ takes the role of an initiator and Q takes the 207 role of a responder. 209 4.1.2. GSAM_AUTH Exchange 211 GSAM_AUTH exchange as shown in Figure 1 is similar to IKE_AUTH of IKE 212 v2. In this exchange, an EU / NQ and Q mutual authenticate for a 213 secure group. However, instead of being negotiated between two peers 214 as in IKE v2, an SA pair, named GSAM_KEK_SA, is downloaded from Q to 215 an EU / NQ. 217 EU / NQ -> Q: HDR, SK{ IDg, IDh, AUTH } 218 Q -> EU / NQ: HDR, SK{ IDg, SA, KD, AUTH} 220 Figure 1: GSAM_AUTH Exchange 222 HDR is a header payload whose format is identical to that in IKE v2. 223 The notation SK { ... } indicates that all the payloads in "{}" are 224 encrypted and integrity protected using an SA, called GSAM_INIT_SA, 225 which is negotiated in the GSAM_INIT Exchange. The message exchange 226 is explained as follows: 228 In the first message, an EU / NQ asserts its identification and the 229 identification of a secure group (i.e., for an EU, it is the group 230 that an EU requests to join in SIGMP or SMLD; for an NQ, it is the 231 group 224.0.0.22 in IPv4 system or FF02:0:0:0:0:0:0:16 in IPv6 232 system listened to by all ERs) in the payload of IDh and IDg 233 respectively. Moreover, an EU / NQ also declares a message 234 authentication code (MAC) or its signature in the AUTH payload. 235 The AUTH payload is used by the message receiver (Q) to 236 authenticate the two identifications in IDh and IDg and to protect 237 the integrity of the first message in the GSAM_INIT exchange. 239 In the second message, Q asserts its identification in payload IDq 240 and distributes an SA pair, called GSAM_KEK_SA, (and more KEK_GSAs 241 sometimes) in payloads SA and KD. Moreover, Q also declares a MAC 242 or its signature in AUTH payload. The AUTH payload is used by the 243 message receiver (an EU / NQ) to authenticate the identification in 244 payload IDq and protect the integrity of the second message in the 245 GSAM_INIT exchange. 247 4.2. EU Operations 249 An EU initiates a GSAM_INIT exchange when an EU requests GSAs to 250 secure SIGMP packets or SMLD packets for the first time or when an EU 251 discovers a new Q. The EU operations in a GSAM_INIT exchange are 252 identical to the initiator operations in the IKE_SA_INIT exchange of 253 IKE v2. 255 After the GSAM_INIT exchange, a new security association, named 256 GSAM_INIT_SA, has been negotiated. It will be used to protect the 257 GSAM_AUTH exchange and achieve private communication between an EU 258 and Q. Moreover, GSAM_INIT_SA will be maintained as a long-term 259 security association. No new GSAM_INIT exchange between an EU and Q 260 will be required for the subsequent request for GSAs as long as an EU 261 does not discover a new Q. 263 An EU initiates a GSAM_AUTH exchange when a request for GSAs is 264 received from SIGMP and GSAM_INIT_SA has been negotiated between an 265 EU and Q. An EU must use the pre-shared key authentication method to 266 finish the registration in the GSAM_AUTH exchange. 268 An EU calculates a MAC and encapsulates it in the AUTH payload of the 269 first message of GSAM_AUTH. The calculation of the MAC is the same 270 as that in IKE v2. The secret key used in the MAC is the MSSK for 271 the secure group calculated at the network layer. It has been 272 independently derived by the EU and the Q as a pre-shared key when an 273 EU has been authorized to join in the secure group at the application 274 layer. 276 Upon receiving the second message of GSAM_AUTH, an EU verifies the 277 value in the received AUTH payload using the MSSK to authenticate Q. 278 If verification fails, the EU will discard the received message. 279 Otherwise, verification succeeds and the EU will accept the 280 GSAM_KEK_SA specified in the SA and KD payloads. Moreover, an EU 281 marks itself as a GM in the requested secure group. The EU updates 282 its local GSPD [RFC5374] as shown in Table 1. G_IP is the IP address 283 of the group identified in the IDg payload. Q_IP and H_IP are the IP 284 addresses of the Q and the EU. The updated records in the GSPD 285 indicate that the SIGMP/SMLD packets that are sent from a GM / Q to 286 the group that a GM wants to join must be protected by IPsec. 288 +-------------------+---------------+----------------+--------------+ 289 | Destination | Source | Protocol | Action | 290 | address | address | number | | 291 +-------------------+---------------+----------------+--------------+ 292 | G_IP | Q_IP | SIGMP(2) | IPsec | 293 | | | | protect | 294 | G_IP | H_IP | SIGMP(2) | IPsec | 295 | | | | protect | 296 | G_IP | * | SIGMP(2) | Discard | 297 | G_IP | * | * | Bypass | 298 +-------------------+---------------+----------------+--------------+ 300 Table 1: Updated Records in local GSPD 302 Finally, the EU must update the SAD, to record the SA paremeters that 303 have been given to it. 305 4.3. Non-Querier Operations 307 An NQ initiates a GSAM_INIT exchange when an ER has just lost in the 308 querier election for SIGMP/SMLD and has become an NQ. NQ operations 309 in the GSAM_INIT exchange are identical to the initiator operations 310 in IKE_SA_INIT of IKE v2. 312 After the GSAM_INIT exchange, GSAM_INIT_SA has been negotiated. It 313 will be used to protect the GSAM_AUTH exchange and achieve private 314 communication between an NQ and Q. Moreover, the GSAM_INIT_SA will 315 be maintained as a long-term security association. No new GSAM_INIT 316 exchange between an NQ and Q is necessary as long as an NQ does not 317 discover a new Q. 319 An NQ initiates a GSAM_AUTH exchange when an ER where an NQ is 320 located has just lost in a querier election in SIGMP / SMLD and a 321 GSAM_INIT_SA has been negotiated between an NQ and Q. An NQ could 322 use any authentication method configured by the network administrator 323 to finish registration in GSAM_AUTH. 325 An NQ calculates a MAC or a signature according to the assigned 326 authentication method and encapsulates it into the AUTH payload of 327 the first message. Here the authentication method depends on the 328 configuration of the network administrator. 330 Upon receiving the second message of GSAM_AUTH, an NQ verifies the 331 value in the received AUTH payload to authenticate Q using the 332 assigned method. If verification fails, an NQ will discard the 333 received message. Otherwise, verification succeeds and an NQ will 334 accept the GSAM_KEK_SA (and more KEK_GSAs if existing) specified in 335 the SA and KD payloads. Moreover, an NQ marks itself as a GM in the 336 group 224.0.0.22 for IPv4 system or FF02:0:0:0:0:0:0:16 for IPv6 337 system (and also a GM in all the groups mentioned in KEK_GSAs). If 338 additional KEK_GSAs are specified in SA and KD payloads, NQ also 339 updates its local GSPD as shown in Table 1 and G_IP indicates all the 340 IP addresses of the groups mentioned in additional KEK_GSAs. 342 4.4. Querier Operations 344 Q operations in the GSAM_INIT exchange are identical to the responder 345 operations in IKE_SA_INIT of IKE v2. 347 Upon receiving the first message of GSAM_AUTH exchange, Q parses the 348 payload of IDg. If IDg identifies a super group (224.0.0.22 for IPv4 349 system or FF02:0:0:0:0:0:0:16 for IPv6 system), the sender of the 350 message is considered to be an NQ. Otherwise, the sender is 351 considered to be an EU. 353 If the sender is an EU, Q retrieves the pre-shared key MSSK shared 354 with the EU identified in the received IDh payload for a secure group 355 identified in the received IDg payload. Similarly, if the sender is 356 an NQ, Q retrieves a certification or a secret key of an NQ 357 identified in IDh payload. Then Q uses the retrieved key or 358 certification to verify the received AUTH payload. If retrieval or 359 verification fails, Q will discard the received message and terminate 360 the GSAM_AUTH exchange. Otherwise, it indicates that an EU has been 361 authorized to join the secure group at the application layer or an NQ 362 has been authorized by the network administrator in its configuration 363 file. In this case, Q starts the "registration" to an EU for the 364 secure group or an NQ for all secure groups. 366 The registration is based on a secure group table (SGT). For an NQ, 367 Q updates all the records in SGT: the source address of the received 368 message is added into GMS field of all the records. It means an NQ 369 becomes a GM in all the groups that Q is maintaining. For an EU, Q 370 searches its SGT to look for a record whose MA is the address of the 371 group identified in the received IDg payload. If the record is 372 found, the source address of the received message is added into GMS 373 of the found record. It means an EU becomes a GM in the group 374 identified in the received IDg payload. Otherwise, Q creates a new 375 record in SGT. In the new record, the value of the MA field is the 376 address of the group identified in the received IDg payload. The 377 addresses showing in the GMS field of the record indexed by 378 224.0.0.22 (or FF02:0:0:0:0:0:0:16) are copied into the GMS field of 379 the new record. Moreover, the source address of the received message 380 is also filled in the GMS of the new record. It means the EU and all 381 the registered NQs become GMs of the group identified in the received 382 IDg payloads. After the registration of an EU, Q updates its local 383 GSPD as Table 1. 385 After registration, Q creates an SA pair, named GSAM_KEK_SA, which 386 consists of two SAs: 1) KEK_GSA and 2) KEK_USA. KEK_GSA is a group 387 security association whose direction is from Q to a secure group 388 identified in the received IDg payload. In detail, when the exchange 389 is between an EU and Q, the direction of KEK_GSA is from Q to a 390 secure group that an EU requests to join. When the exchange is 391 between an NQ and Q, the direction is from Q to the group 224.0.0.22 392 or FF02:0:0:0:0:0:0:16. It is used to protect the messages in Phase 393 2 sent by Q. KEK_USA is a unicast security association whose 394 direction is from the new GM (an EU/NQ) to Q. It is used to protect 395 the message in Phase 2 sent by GMs. 397 Moreover, Q also calculates a new MAC or a signature according to the 398 negotiated authentication method. If the exchange is between an EU 399 and Q, the authentication method must be pre-shared key. Q uses the 400 retrieved MSSK as the secret key to calculate a MAC value. If the 401 exchange is between an NQ and Q, the authentication method depends on 402 the network configuration of an NQ. Q may calculate a MAC or a 403 signature for NQ. 405 After that, Q sends to an EU / NQ the second message as a response. 406 In the response to an EU, SA and KD payloads specify the newly 407 created GSAM_KEK_SA. In the response to an NQ, SA and KD payloads 408 specified not only the newly created GSAM_KEK_SA, but also all other 409 KEK_GSAs that Q is maintaining. the AUTH payload contains the new MAC 410 or signature. 412 5. Phase 2: GSA Distribution 414 In Phase 2, Q suggests GSAM_TEK_SA to GMs. If any GM rejects the 415 suggestion due to SPI collisions, a negotiation will be required 416 among GMs. 418 5.1. Message Exchanges 420 There are two exchanges in GSA distribution: GSAM_PUSH and 421 GSAM_RE_DISTRIBUTION. 423 5.1.1. GSAM_PUSH Exchange 425 GSAM_PUSH exchange is shown in Figure 2 . 427 Q -> GMs: HDR, SK{ SA, KD, AUTH} 429 Figure 2: GSAM_PUSH Exchange 431 In this message, Q distributes an SA pair (i.e., GSAM_TEK_SA, but 432 sometimes more GSAM_TEK_SAs) or an SA (i.e., KEK_GSAs) in the payload 433 SA and KD. Moreover, Q declares a signature in payload AUTH. The 434 notation SK {...} indicates that all the payloads in "{}" are 435 encrypted and integrity protected using a KEK_GSA. 437 5.1.2. GSAM_RE_DISTRIBUTION Exchange 439 The GSAM_RE_DISTRIBUTION exchange is triggered when any GM detects an 440 SPI collision and refuses to accept the GSAM_TEK_SA received in the 441 GSAM_PUSH message. In other words, it is just optional: there is no 442 GSAM_RE_DISTRIBUTION exchange if no SPI collisions are detected by 443 any GM. The GSAM_RE_DISTRIBUTION exchange is shown in Figure 3. All 444 the messages are protected by GSAM_KEK_SA. It is explained as 445 follows: 447 GM -> Q : HDR, SK{ IDg, REJ, AUTH } 448 Q -> GMs: HDR, SK{ S_REQ, AUTH } 449 GMs -> Q: HDR, SK{ SPI_LIST, AUTH } 450 Q -> GMs: HDR, SK{ SAtf, KDtf, AUTH } 452 Figure 3: GSAM_RE_DISTRIBUTION Exchange 454 In the first message, a GM that detects an SPI collision asserts 455 the identification of the secure group that is the destination 456 address of the rejected GSAM_TEK_GSA in payload IDg and shows its 457 rejection to the suggested GSAM_TEK_GSA in payload REJ. Moreover, 458 GM declares a MAC in payload AUTH. 460 Q multicasts the second message into a secure group identified by 461 the received IDg. In this message, Q requests a list, called 462 spi_list, in payload S_REQ and shows its signature in payload AUTH. 464 All GMs in the secure group will send the third message to respond 465 to the request from Q. In the third message, a GM reports its 466 spi_list in payload SPI_LIST and declares its MAC in the payload 467 AUTH. 469 The fourth message is the same as the GSAM_PUSH message. In the 470 fourth message, Q multicasts an SA pair (i.e., GSAM_TEK_SA) in 471 payload SA and KD and declares a signature in the AUTH payload. 472 However, the SPI parameter in GSAM_TEK_SA has been negotiated with 473 all GMs in the secure group and therefore it cannot cause any 474 collision. 476 5.2. Querier Operations 478 When an EU is registered as the first GM of a secure group in the 479 segment, Q will multicast the GSAM_PUSH exchange message in two 480 groups in order: (1) the group 224.0.0.22 or FF02:0:0:0:0:0:0:16 and 481 (2) the secure group that an EU requests to join. 483 Q multicasts the first multicast GSAM_PUSH message into group 484 224.0.0.22 or FF02:0:0:0:0:0:0:16. In this message, the KEK_GSA that 485 is just distributed to an EU using GSAM_AUTH exchange is specified in 486 the payloads of SA and KD. 488 Q creates a new SA pair, called GSAM_TEK_SA, which consists of two 489 GSAs: (1) GSA_q whose direction is from Q to the secure group that an 490 EU (the new GM) requests to join and (2) GSA_r whose direction is 491 from an EU to the secure group that an EU requests to join. The 492 values of important parameter of SPI in GSA_q and GSA_r are suggested 493 ones since they are assigned by Q with no negotiation with other GMs. 495 After making sure that all the NQs have received the previous 496 GSAM_PUSH message, Q starts to multicast the other GSAM_PUSH message 497 into the group that the EU has requested to join. In the second 498 message, the payloads SA and KD specify the parameter and key 499 material of the new SA pair (GSAM_TEK_SA). 501 After that, Q starts two timers, called q-timer and r-timer 502 respectively. When q-timer / r-timer expires, Q will update its 503 local SAD [RFC5374] according to GSA_q / GSA_r. The initial value of 504 q-timer should be large enough to make sure all GMs have updated 505 their local SADs according to the distributed GSA_q. 507 There must be an interval between the first GSAM_PUSH message and the 508 second one. The interval should be large enough to make sure the 509 first message has been received by GMs in 224.0.0.22 or 510 FF02:0:0:0:0:0:0:16 before the second one is sent. 512 If the registered EU is not the first GM of a secure group, Q 513 multicasts the second GSAM_PUSH message directly without the first 514 message. 516 When an NQ is registered as a GM in all the groups, Q will directly 517 multicast GSAM_PUSH exchange message in the group of 224.0.0.22 for 518 IPv4 system or FF02:0:0:0:0:0:0:16 for IPv6 system. In this message, 519 GSAM_TEK_GSAs for all the groups are specified in the payloads SA and 520 KD. If the only group Q is maintaining is the super group, no 521 GSAM_PUSH exchange is needed. 523 Upon receiving the first message of GSAM_RE_DISTRIBUTION, Q verifies 524 the value in the payload AUTH to authenticate a GM. If 525 authentication fails, Q discards the received message directly. 526 Otherwise, Q deletes the q_timer and r_timer if they exist. It 527 multicasts the second message of GSAM_RE_DISTRIBUTION to negotiate 528 SPI values with all the GMs in the secure group. 530 Upon receiving the third message, Q verifies the AUTH payload to 531 authenticate a GM. If authentication fails, Q discards the received 532 message directly. Otherwise, Q searches its local SGT and looks for 533 a record that is indexed by a secure group identified in the received 534 IDg. The GMS of the found record contains the addresses of all the 535 GMs in the secure group. Q compares the source addresses of the 536 received third messages with the values in the GMS until it has 537 received the third message from all the GMs in the secure group. 539 After that, Q starts to calculate a list, called spi_list_all, which 540 is a union of spi_lists received from all GMs in the secure group. 541 Then Q resets the values of SPI in GSAM_TEK_SA. The new SPI values 542 must not be in the spi_list_all to effectively avoid SPI collisions 543 at any GM. Then Q multicasts the fourth message of 544 GSAM_RE_DISTRIBUTION, whose payloads SA and KD specify the revised 545 GSAM_TEK_SA. Finally, Q re-starts q-timer and r-timer. When q-timer 546 / r-timer expires, Q updates its local SAD according to GSA_q / GSA_r 547 whose SPI value has been negotiated among GMs. 549 5.3. GM Operations 551 Upon receiving the GSAM_PUSH message, a GM verifies the value in the 552 payload AUTH to authenticate Q. If authentication fails, a GM 553 discards the received message directly. Otherwise, a GM parses the 554 received payloads SA and KD. If payloads SA and KD specify KEK_GSAs 555 and a GM is an NQ, a GM will accept the KEK_GSA directly and wait for 556 receiving the following GSAM_PUSH message protected by KEK_GSA. 557 Otherwise payloads SA and KD specify a GSAM_TEK_SA. In this case, a 558 GM checks SPI, an important parameter of GSAM_TEK_SA. If SPI values 559 in GSAM_TEK_SA have not used in its local SAD, a GM will start 560 q-timer and r-timer and no other exchange is needed. When q-timer/ 561 r-timer expires, a GM updates its local SAD according to GSA_q / 562 GSA_r. If the source address of received GSA_r is the same as a 563 local address, the initial value of r-timer should be large enough to 564 make sure all other GMs and Q have updated their local SADs according 565 to GSA_r. If the suggested SPI values in GSAM_TEK_SA have collided 566 with the used SPI values in local SAD, a GM must start 567 GSAM_RE_DISTRIBUTION exchange as follows. 569 A GM calculates a MAC and encapsulates it in AUTH payload. Then it 570 sends the first message of GSAM_RE_DISTRIBUTION to Q to show its 571 rejection. 573 Upon receiving the second message in GSAM_RE_DISTRIBUTION, a GM 574 verifies the received AUTH payload. If the verification fails, a GM 575 discards the received message. Otherwise, a GM deletes the pending 576 q-timer and r-timer at once if they exist. It accesses its local SAD 577 to obtain the all the used SPI values in the SAD and saves them in an 578 spi_list. After that, the status of local SADB is set as "read_only" 579 to prevent any modification from any other processes. The GM 580 encapsulates an spi_list in the payload SPI_LIST. Moreover, a MAC 581 value is calculated and encapsulated in the AUTH payload. After 582 that, the GM sends the third message with the payload SPI_LIST and 583 AUTH payload. 585 Upon receiving the fourth message in GSAM_RE_DISTRIBUTION, the GM 586 verifies the value in the payload AUTH to authenticate Q. If 587 authentication fails, the GM discards the received message directly. 588 Otherwise, the GM is forced to accept GSAM_TEK_SA specified in the 589 received payload SA and KD. It re-starts q-timer and r-timer. When 590 q-timer/r-timer expires, a GM updates its local SAD according to 591 GSA_q/GSA_r. After that, GMs clears the "read_only" status of its 592 local SAD to permit the modification to the SAD from other processes. 594 6. Handover of Q 596 Although ERs are usually stable, a new ER may be added into the 597 network and an old ER may fail to work. In these cases, a querier 598 election is caused and then a new Q may be elected in the link. The 599 new Q will take over the work of old Q automatically and become GCKS 600 soon in the link. All the EUs and NQs will discover the new Q since 601 they will receive the general query sent by the new Q in SIGMP/SMLD. 602 They initiate new GSAM sessions with the new Q. If they are 603 authenticated successfully, the new Q will distribute new 604 GSAM_TEK_SAs to them. SIGMP / SMLD messages will be protected by the 605 new GSAM_TEK_SAs. 607 7. IANA Considerations 609 GSAM runs over UDP. A UDP port should be assigned to GSAM. 611 8. References 612 8.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 8.2. Informative References 619 [I-D.atwood-pim-sigmp] 620 william.atwood@concordia.ca, w. and B. Li, "Secure 621 Internet Group Management Protocol", draft-atwood-pim- 622 sigmp-01 (work in progress), July 2014. 624 [I-D.yeung-g-ikev2] 625 Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 626 Management using IKEv2", draft-yeung-g-ikev2-07 (work in 627 progress), November 2013. 629 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 630 Internet Protocol", RFC 4301, December 2005. 632 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 633 Yegin, "Protocol for Carrying Authentication for Network 634 Access (PANA)", RFC 5191, May 2008. 636 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 637 Extensions to the Security Architecture for the Internet 638 Protocol", RFC 5374, November 2008. 640 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 641 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 642 5996, September 2010. 644 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 645 of Interpretation", RFC 6407, October 2011. 647 Authors' Addresses 649 William Atwood 650 Concordia University/CSE 651 1455 de Maisonneuve Blvd, West 652 Montreal, QC H3G 1M8 653 Canada 655 Phone: +1(514)848-2424 ext3046 656 Email: william.atwood@concordia.ca 657 URI: http://users.encs.concordia.ca/~bill 658 Bing Li 659 Concordia University/CSE 660 1455 de Maisonneuve Blvd, West 661 Montreal, QC H3G 1M8 662 Canada 664 Email: leebingice@gmail.com