idnits 2.17.1 draft-duquer-fmke-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 11) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 38 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC3547]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 201: '...e the GDOI, FMKE MUST be protected by ...' RFC 2119 keyword, line 239: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 240: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 247: '... FMKE MUST be protected by a "phase ...' RFC 2119 keyword, line 259: '...changed messages MUST correspond to th...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 909 has weird spacing: '...r as an attri...' == Line 1236 has weird spacing: '... valid next ...' == Line 1718 has weird spacing: '...will be disca...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC3547' is mentioned on line 985, but not defined ** Obsolete undefined reference: RFC 3547 (Obsoleted by RFC 6407) == Missing Reference: 'RFC 3547' is mentioned on line 1385, but not defined ** Obsolete undefined reference: RFC 3547 (Obsoleted by RFC 6407) == Missing Reference: 'RFC2119' is mentioned on line 242, but not defined == Unused Reference: 'RFC2406' is defined on line 1793, but no explicit reference was found in the text == Unused Reference: 'RFC2547' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: 'FIPS46-3' is defined on line 1808, but no explicit reference was found in the text == Unused Reference: 'FIPS81' is defined on line 1813, but no explicit reference was found in the text == Unused Reference: 'FIPS186-2' is defined on line 1818, but no explicit reference was found in the text == Unused Reference: 'FIPS197' is defined on line 1823, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISAKMP-REG' ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS46-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC-REG' Summary: 14 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Duquerroy 3 INTERNET-DRAFT S.Josset 4 Expires: February, 2005 5 September, 2004 7 The Flat Multicast Key Exchange protocol 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working groups. 17 Note that other groups may also distribute working documents as 18 Internet Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document presents a new group key management protocol called 34 FMKE (Flat Multicast Key Exchange), derived from the Group Domain of 35 Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is to 36 Manage securely group Security Associations (SA), i.e. establish and 37 update SAs in Group members. These security associations protect one 38 or more key-encrypting keys, traffic-encrypting keys, or data shared 39 by group members. This protocol is based on a centralized management, 40 achieved by the GCKS (Group Controller and Key Server). It is 41 destined to be used by Data Security protocols such as the IPSEC ESP 42 protocol. The FMKE protocol is destined to provide an optimized 43 solution for very large groups with direct connections such as in 44 satellite systems, or wireless systems such as WIFI. It can be 45 considered as a GDOI use case adapted for satellite networks. 47 The Flat Multicast Key Exchange September , 2004 49 Table of Contents 51 1.0 Introduction......................................................3 52 2.0 Phase 1 ..........................................................6 53 3.0 Phase 2 Exchange..................................................6 54 3.1 Messages......................................................6 55 3.2 Reliability...................................................8 56 3.3 ISAKMP Header Configuration...................................9 57 4.0 Phase 3 Exchange..................................................9 58 4.1 Messages......................................................9 59 4.2 Reliability..................................................11 60 4.3 ISAKMP Header Configuration..................................12 61 4.4 Phase 3 utilization..........................................12 62 5.0 Deletion of SAs..................................................12 63 6.0 Utilization of FMKE exchanges according to satellite network 64 topologies.......................................................13 65 6.1 Utilization in one-way systems...............................13 66 7.0 Payloads and defined SA attributes...............................15 67 7.1 Last Sequence Number Payload (LSEQ)..........................15 68 7.2 Acknowledgement Payload (ACK)................................16 69 7.3 Selective Acknowledgement Payload(SACK)......................17 70 7.4 Negative Acknowledgement Payload (NACK)......................17 71 7.5 Sequence Number Payload (SEQ)................................18 72 7.6 Security Association Payload (SA)............................19 73 7.6.1 Payloads following the SA payload......................20 74 7.7 SA KEK payload...............................................21 75 7.7.1 KEK attributes ........................................23 76 7.7.2 KEK_MANAGEMENT_ALGORITHM ..............................23 77 7.7.3. KEK_ALGORITHM........................................23 78 7.7.4. KEK_KEY_LENGTH ......................................24 79 7.7.5. KEK_KEY_LIFETIME ....................................24 80 7.7.6. SIG_HASH_ALGORITHM ..................................24 81 7.7.7. SIG_ALGORITHM........................................24 82 7.7.8. SIG_KEY_LENGTH ......................................25 83 7.7.9. KE_OAKLEY_GROUP......................................25 84 7.7.10. HASH_ALGORITHM.......................................25 85 7.7.11. NEXT_SEQ_NUMBER......................................25 86 7.8 SA TEK payload...............................................25 87 7.8.1 PROTO_IPSEC_ESP........................................26 88 7.9 Key Download Payload.........................................29 89 7.9.1. TEK Download Type....................................30 90 7.9.2. KEK Download Type....................................31 91 8.0 Domain of Interpretation for FMKE................................32 92 8.1 Payloads.....................................................32 93 8.2 New Exchange types...........................................32 94 8.3 Security Association attributes..............................33 95 9.0 Security Considerations..........................................33 96 9.1 ISAKMP Phase 1...............................................33 97 9.1.1 Authentication.........................................34 98 9.1.2 Confidentiality........................................34 100 The Flat Multicast Key Exchange September, 2004 102 9.1.3 Man-in-the-middle Attack Protection....................34 103 9.1.4 Replay/Reflection Attack Protection....................34 104 9.2 Phase 2 Exchange.............................................34 105 9.2.1 Authentication.........................................35 106 9.2.2 Confidentiality........................................35 107 9.2.3 Man-in-the-middle Attack Protection....................35 108 9.2.4 Replay/Reflection Attack Protection....................35 109 9.3 Phase 3 Exchange.............................................35 110 9.3.1 Authentication.........................................35 111 9.3.2 Confidentiality........................................36 112 9.3.3 Man-in-the-middle Attack Protection....................36 113 9.3.4 Replay/Reflection Attack Protection....................36 114 10.0 IANA considerations.............................................36 115 10.1 ISAKMP DOI..................................................36 116 10.2 Payload types...............................................36 117 10.3 New Name spaces.............................................36 118 11.0 Acknowledgements............................................... 36 119 12.0 References..................................................... 37 121 1.0 Introduction 123 This document presents a new group key management protocol called 124 FMKE (Flat Multicast Key Exchange). Its objective is to manage 125 securely group Security Associations (SA), i.e. establish and update 126 SAs in Group members. This protocol is based on a centralized 127 management, achieved by the GCKS (Group Controller and Key Server). 128 It is destined to be used by Data Security protocols such as the 129 IPSec ESP protocol, for the securisation of group communications. 130 FMKE exchanges take place between the GCKS and Group members. The 131 protocol establishes Data-security SAs and Re-key SAs in the 132 authorized Group members. 134 FMKE is derived from the Group Domain of Interpretation (GDOI) 135 [RFC 3547], and can be seen as a GDOI use case adapted and optimized 136 for satellite networks: 138 - FMKE is destined to manage securely group SA in any satellite 139 network topologies. These SA protect key-encrypting keys, 140 traffic-encrypting keys, or data, transmitted on satellite links and 141 shared by Group members. 142 In Star topology, the Gateway (GW) is a terminal access concentrator. 143 Communications take place only between the GW and Satellite terminals 144 (ST) through the satellite. End users are located behind the STs. 145 Communications between GW and each ST can be bi-directional(two-way 146 systems : in such a case, the ST has a return channel), or 147 unidirectional, from GW to ST (one-way systems : in such a case, the 148 ST does not have a return channel). 149 In Mesh topology, communications take place directly between STs 150 (they are bi-directional). 152 The Flat Multicast Key Exchange September , 2004 154 The FMKE objective is thus to establish group SA in group members 155 (located in each ST and GW) in any types of topology (Remark : GCKS is 156 located in GW in Star topology, and in a ST in Mesh topology). 158 GW ST-----ST 159 / | \ | \ / | 160 / | \ | \ / | 161 / | \ | \ | 162 / | \ | / \ | 163 / | \ | / \ | 164 ST ST ST ST-----ST 166 Star Topology Mesh Topology 168 - Satellite networks can require reliable key distribution, in unicast 169 and in multicast. For that purpose, FMKE defines specific mechanisms, 170 implemented in the exchanges between GCKS and members. 172 - In satellite networks, bandwidth is limited. FMKE aims at reducing 173 the overhead generated by the establishment of group SAs. Thus FMKE 174 changes the philosophy of the key distribution in order to limit the 175 consumed bandwidth. 177 - In satellite networks, data to be protected by Data-security SA 178 are generated by end-users located behind STs or GW. These end-users 179 are distinct from group members. Group members shall therefore 180 encapsulate data in tunnels. For that purpose, FMKE defines 181 additional information specifying the associated tunnel in the 182 definition of Data-security SAs. 184 FMKE uses several payloads introduced by GDOI: 185 - GDOI SA 186 - SA KEK (SAK) which follows the SA payload 187 - Key Download Array (KD) 188 - Sequence Number (SEQ) 190 FMKE also extends the definition of the following GDOI payload: 191 - SA TEK (SAT) which follows the SA payload 193 FMKE defines new payloads : 194 - Last Sequence Number (LSEQ) 195 - Acknowledgement (ACK) 196 - Selective Acknowledgement (SACK) 197 - Negative Acknowledgement (NACK) 199 The Flat Multicast Key Exchange September , 2004 201 Like the GDOI, FMKE MUST be protected by a Phase 1 security 202 association. Similarly to [RFC3547], this document incorporates the 203 Phase 1 security association (SA) definition from the Internet DOI 204 [RFC2407, RFC2409]. 206 FMKE defines two new exchanges derived from both exchanges of GDOI : 208 1/ The FMKE Phase 2 is derived from the GDOI "GROUKEY-PULL". 209 Like the "GROUKEY-PULL" exchange, it is protected by the Phase 1 210 ISAKMP SA, and the GCKS transmits securely Data-Security SAs and 211 Re-key SAs the Group member is authorized to get access to (i.e SAs 212 of groups whose it is a member). A Re-key SA includes a key 213 encrypting key, or KEK, common to a group; a Data-security SA 214 includes a data encryption key, or TEK, used by a data-security 215 protocol to encrypt or decrypt data traffic. 217 Unlike GDOI, this phase takes place once, after the Phase 1. The 218 member can receive directly all SAs it is authorized to get access 219 to, without having to send a request for each group. This way FMKE 220 limits the consumed bandwidth. Indeed the member does not have to 221 send a request for each group, and a FMKE message from the GCKS can 222 contain SAs from different groups. 223 Moreover in order to provide reliability, the member sends 224 periodically acknowledgement messages. 226 2/ The FMKE Phase 3 is derived from the GDOI "GROUKEY-PUSH". 227 Like the "GROUKEY-PUSH" exchange, it is dedicated to a group, and is 228 protected by the Re-key SA, which is shared by all Group members. 229 In this phase, the GCKS transmits securely SAs to the Group members. 230 It can create or update Re-key SA and/or Data-security SAs in group 231 members. 232 Unlike GDOI, this phase is defined with reliability mechanisms so 233 that all Group members receive each new or updated SA. 235 FMKE introduces new exchanges, new security payloads and new SA 236 attributes with regard to the IPSec DOI or GDOI. FMKE requires 237 therefore a new Domain Of Interpretation (DOI). 239 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 240 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 241 document, are to be interpreted as described in RFC 2119 [RFC2119]. 243 The Flat Multicast Key Exchange September , 2004 245 2.0 Phase 1. 247 FMKE MUST be protected by a "phase 1" protocol. 248 The phase 1 protocol provides a mutual authentication between GCKS 249 and Group member, and establishes a security association between them 250 , ensuring confidentiality, integrity and source authentication. The 251 Phase 1 is then used to protect FMKE exchanges. 252 Similarly to the GDOI, it is proposed to use the ISAKMP phase 1 253 (Main-Mode with pre-Shared key or Public Key for Authentication" 254 phase 1) as defined in [RFC2409], as a "Phase 1" protocol for FMKE. 255 It realizes a mutual authentication and establishes an ISAKMP SA, 256 which provides all needed security services. 258 During this phase, the DOI value mentioned in the ISAKMP Header of 259 the exchanged messages MUST correspond to the DOI which defines the 260 FMKE exchanges (c.f. 8.0). 261 Besides, like GDOI, FMKE MUST NOT run on port 500 (the port commonly used 262 for IKE), but on a port assigned to FMKE(the GDOI port is 848). 264 3.0 Phase 2 exchange. 266 The goal of the Phase 2 exchange is to establish Re-keys SAs and/or 267 Data-security SAs at the member. The transmitted SAs belong to the 268 same or to different groups. There is one Re-key SA per group. During 269 this phase, the member can receive all the Data security SAs and Re- 270 key SAs it is authorized to get access to (the SAs of all the groups 271 whose it is a member). The Phase 2 exchange takes place once, after 272 the Phase 1; and is initiated by the GCKS. It is protected by the 273 Phase 1 SA. 275 3.1 Messages. 277 Group Member GCKS 278 ------------------ ---------------- 279 <-- HDR*, HASH(1), SEQ, SA, KD 280 <-- HDR*, HASH(1), SEQ, SA, KD 281 HDR*, HASH(2), ACK, [,SACK] --> 282 <-- HDR*, HASH(1), SEQ, SA, KD 283 HDR*, HASH(2), ACK, [,SACK] --> 284 ... 285 * Protected by the Phase 1 SA, encryption occurs after HDR 287 Hashes are computed as follows : 288 HASH(1) = prf(SKEYID_a, SEQ | SA |KD ) 289 HASH(2) = prf(SKEYID_a, ACK [ | SACK ]) 291 The Flat Multicast Key Exchange September , 2004 293 Phase 2 messages are protected by the Phase 1 SA. The Phase 1 294 computes SKEYID_a, which is the key used to compute the hash value 295 contained in the HASH payload of the Phase 2 messages, and K 296 (derived from SKEYID_e), which is the key used to encrypt/decrypt 297 the Phase 2 messages. SKEYID_a and K are derived according to 298 [RFC2409]. 300 Phase 2 exchange is composed of two types of messages : the messages 301 sent by the GCKS, which contain the SA attributes and keys the member 302 is authorized to get access to, and the messages sent by the member, 303 which are used to acknowledge the previous messages. 304 The number of messages transmitted by the GCKS is variable: it 305 depends on the number of SAs to establish. 306 Acknowledgement messages are sent periodically by the member. Their 307 number is variable. 309 HDR is an ISAKMP payload that uses the Phase 1 cookies. 311 SA is the SA payload. It contains all the policy attributes of the 312 SAs to establish, like in GDOI. 314 KD is the Key Download payload defined in GDOI. If one or more 315 Re-Key SAs are defined in the SA payload, KD will contain the KEKs. 316 If one or more Data SAs are defined in the SA payload, KD will 317 contains the TEKs. 319 During a phase 2, the GCKS can transmit several Re-key SAs (one per 320 group) and/or several Data-security SAs. The Re-Key SAs are 321 identified by an ISAKMP cookie pair, which is included in the SA 322 payload. This cookie pair is not negotiated, but determined and 323 downloaded by the GCKS. 324 The Data SAs are identified by a SPI (Secure Parameter Index), which 325 is included in the SA payload. The SPI is not negotiated, but 326 determined and downloaded by the GCKS. 328 The signification of the value contained in the SEQ payload is 329 different from the signification of the value of the GDOI 330 GROUPKEY-PULL: it represents the value of a counter which is used to 331 order the phase 2 messages of GCKS. 333 In the member messages, the value contained in the ACK payload 334 mentions the sequence number of the last correctly received message. 335 The SACK payload can be optionally included in the Phase 2 member 336 messages. When one or several GCKS messages are missing, it allows to 337 mention the sequence numbers of following messages already received 338 (c.f. 3.2). 340 The Flat Multicast Key Exchange September , 2004 342 The HASH payload proves that the messages have not been 343 modified during transmission and that the peer knows the Phase 1 344 secret(SKEYID_a). The HASH payload also guarantees that messages are 345 not replayed from an old session establishment, as they required the 346 secret of the last Phase 1. The SEQ payload in the GCKS messages 347 allows the member to delete all messages already received in the 348 Phase 2, as it has to check that the sequence number is greater than 349 in the previous SEQ payloads. 351 In FMKE, verifying the liveliness of the member is not needed, 352 because there is only one Phase 2, which begins just after the Phase 353 1, and because the Phase 2 is initiated by the GCKS. If the member 354 cannot acknowledge the GCKS messages, the connection is closed. 355 The liveliness of the GCKS is proved thanks to the HASH and to the 356 SEQ payloads, which guarantee that it owns the Phase 1 secret and the 357 current sequence number. 359 3.2 Reliability. 361 FMKE requires reliable session establishment phases. In the Phase 2, 362 reliability mechanisms are based on positive acknowledgements (the 363 member acknowledges received messages), retransmission of non 364 acknowledged messages and optionally selective acknowledgements 365 (Sack). 367 Thus, the member sends periodically positive acknowledgements to 368 acknowledge GCKS messages. 369 For that purpose, a sequence number is assigned to each GCKS message 370 (mentioned in the SEQ payload), which orders these messages. In 371 acknowledgement messages, the value contained in the ACK payload 372 mentions the sequence number of the last correctly received message. 373 The SACK payload can be optionally included in the member messages. 374 When one or several GCKS messages are missing, it allows to mention 375 the numbers of following messages already received. 377 Ex : 378 First sequence number used : 1 380 Sequence numbers of the messages sent by the GCKS : 381 1 2 3 4 5 6 7 8 9 383 Sequence numbers of the messages received by the Member : 384 1 2 3 4 . 6 7 . 9 (5 and 8 are lost) 386 Acknowledgement sent by the member : 387 Ack : 4 , Sack : 6-7, Sack : 9-9 (this acknowledgement must 388 trigger the retransmission of the messages 5 and 8). 390 The Flat Multicast Key Exchange September , 2004 392 3.3 ISAKMP Header configuration (Hdr) 394 The Initiator Cookie field is the cookie of the Group member, 395 generated during the Phase 1 according to ISAKMP [RFC2408]. 396 The Responder Cookie field is the cookie of the GCKS, generated 397 during the Phase 1 according to ISAKMP [RFC2408]. 399 Next Payload identifies an ISAKMP, GDOI or FMKE payload. 401 Major Version is 1 and Minor Version is 0 according to ISAKMP 402 [RFC2408]. 404 The Exchange Type field is set to "FMKE_unicast_Push" (c.f. 8.2) 406 Flags, Messages ID and Length are according to ISAKMP[RFC2408]. 408 4.0 Phase 3 exchange 410 During Phase 3, the GCKS sends securely control information to 411 Group members using group communications. Typically this will be 412 using IP multicast. Like in GDOI, the goal of the Phase 3 exchange is 413 to create new Data security SAs, and/or replace the Re-key SA into 414 Group members (of a same group). The Phase 3 is protected by the 415 Re-key SA of the group. The GCKS pushes the new SA attributes. 417 4.1 Messages 419 Group Member GCKS 420 ------------------ ---------------- 421 <-- HDR*, SEQ, SA, KD, SIG 422 x<- HDR*, SEQ, SA, KD, SIG 423 <-- HDR*, LSEQ, SIG 424 HDR*, HASH, NACK --> 425 <-- HDR*, SEQ, SA, KD, SIG 426 ... 428 * protected by the Re-Key SA; encryption occurs after HDR 430 The Phase 3 messages are protected by the Re-key SA. They are 431 encrypted and authenticated according to the Re-key SA attributes. 433 In the Phase 3, the GCKS sends two types of messages. The first type 434 Messages contain the SA and KD payloads, and is used to create and/or 435 replace new SAs. Like in Phase 2, a SEQ payload is included in each 436 message, containing a sequence number value. 438 The Flat Multicast Key Exchange September , 2004 440 The second type messages are sent periodically. They contain a LSEQ 441 payload whose value mentions the last sequence number used by 442 the GCKS. This payload is used to enable reliability (c.f. 4.2). 444 The Group member sends only one type of messages. These messages are 445 used as Non-acknowledgement messages: they request the 446 retransmission, in multicast, of the message(s), whose sequence 447 number(s) is(are) mentioned in the NACK payload(s). 449 HDR is an ISAKMP payload that uses the Re-key SA cookies (c.f. 3.1). 451 SA is the SA payload, containing the policy attributes for a Re-key 452 SA and/or Data-Security SAs. 454 KD is the Key Download payload. If the SA defines a Re-key SA, KD 455 contains a KEK. This SA has a new cookie pair and replaces the 456 Re-key SA for the group. 457 If the SA defines new Data-SA, KD contains the TEK associated to 458 each SA. 460 In the GCKS's first type messages, the SEQ payload contains a 461 sequence number whose value orders these messages. Each Group member 462 has received included in the Re-key SA attributes (during the Re-key 463 SA establishment in Phase 2) the value of the sequence number which 464 will be used in the next GCKS message (of the phase 3). 465 In the GCKS's second type messages, the LSEQ payload mentions the last used 466 sequence number. 467 In the member messages, the values contained in the NACK payload(s) 468 mention the sequence numbers of messages that the member requests for 469 retransmission. 471 The SIG payload contains the digital signature of the entire message 472 before encryption (including the header and excluding the SIG payload 473 itself), prefixed with the string "rekey" like in GDOI. The signature 474 guarantees source data authentication, i.e. the source of this 475 message is the GCKS. 476 The SIG payload of the GCKS messages proves that the messages have 477 not been modified during transmission, and that it has been generated 478 by the GCKS. 480 The SEQ payload of the GCKS messages allows Group members to detect 481 replayed messages : they delete all already received messages. 483 The value contained in the HASH payload of the Group member messages 484 proves that the messages have not been modified during transmission, 485 and that the source is a Group member. We do not need to know exactly 486 which the source is for this type of messages (Non acknowledgement). 488 The Flat Multicast Key Exchange September , 2004 490 The Hash value is calculated with the symmetric authentication key 491 and the authentication algorithm which are mentioned in the Re-key SA 492 attributes. The Group member messages could be replayed, but the GCKS 493 cannot retransmit a message an infinity of times. The number of 494 retransmissions is limited and must allow all Group members to 495 receive each message. 497 4.2 Reliability 499 FMKE requires reliable session establishment phases. In the Phase 3, 500 reliability mechanisms are based on negative acknowledgements with 501 retransmission : when a Group member determines that it has not 502 received one or several messages, it requests for their 503 retransmission by sending a Non-acknowledgement message (Nack). 504 Retransmission is achieved in multicast. 506 Like in the second phase, a sequence number is assigned to each GCKS 507 message (mentioned in the SEQ payload). Its value orders these 508 messages. 509 Each Group member has received included the Re-key SA attributes 510 (during the Re-key SA establishment in Phase 2) the value of the 511 sequence number which will be used in the next GCKS message (of the 512 phase 3). 513 Moreover, the GCKS sends periodically in multicast a message with the 514 last used sequence number (in the LSEQ payload). Thus, a Group member 515 can easily determine that it has not received one or several 516 messages, and can send a Non-acknowledgement message in unicast to 517 the GCKS, containing the missing sequence numbers. This message 518 triggers the retransmission in multicast of the missing messages 519 (with the same sequence numbers). 521 Ex : 522 Next sequence number used by the GCKS (configuration) : 5 524 Sequence number of the messages sent by the GCKS : 5 6 7 8 9 526 Sequence number of the messages received by a Member : . 6 7 . 9 527 (5 and 8 are missing) 529 Non-Acknowledgement sent by the Member : Nack : 5-5 , Nack : 8-8 530 (this acknowledgement must trigger the retransmission of the 531 messages 5 and 8). 533 When a Group member determines that one message is missing, he waits 534 a predetermined time before sending its Non-acknowledgement 535 message. The time before sending a Nack varies for each Group member, 536 in order to avoid massive Nack emission and thus the congestion at 537 GCKS side. The Group member waiting time follows a pre-calculated 538 distribution: few of them will be authorized to send a Nack at the 539 beginning, and it is expected that these messages will be sufficient 540 so that all Group members receive the GCKS messages. 542 The Flat Multicast Key Exchange September , 2004 544 4.3 ISAKMP Header configuration 546 The cookie pair identifies the Re-key SA. These cookies are assigned 547 by the GCKS (c.f. 3.1). The first 8 octets of the cookie pair become 548 the "Initiator Cookie" field and the second 8 octets become the 549 "Responder Cookie" field in the ISAKMP header. 551 Next Payload identifies an ISAKMP, GDOI or FMKE payload. 553 Major Version is 1 and Minor Version is 0 according to ISAKMP 554 [RFC2408]. 556 The Exchange Type field is set to "FMKE_multicast_Push" (c.f. 8.2) 558 In the Flags field, the encryption bit is set to 1 and the others 559 bits MUST be set to 0. 561 Messages ID and Length are according to ISAKMP[RFC2408]. 563 4.4 Phase 3 utilization 565 The Phase 3 allows to configure and update simultaneously 566 Group members. This phase can be initiated for instance when several 567 Group members establish a connection with the GCKS at the same time. 568 The Phase 2 is required only to provide each Group Member with the 569 Re-key SA. The Phase 3 is then used to transmit simultaneously to all 570 the Group members the Data-security SAs. This phase can also be used 571 to guarantee the common evolution of the Group members' SAs. The 572 Phase 2 and 3 are complementary. 574 5.0 Deletion of SAs 576 There are times the GCKS may want to signal to receivers to delete 577 SAs, for example at the end of a broadcast. 578 Like in GDOI, deletion of keys may be accomplished by sending an 579 ISAKMP Delete payload [RFC2408, Section 3.15]. However it can be sent 580 as part of a FMKE phase 2 or phase 3 message contrary to GDOI. 582 One or more Delete payloads MAY be placed following the SEQ payload 583 in a GCKS phase 2 message or in a GCKS phase 3 message. If a GCKS has 584 no further SAs to send to group members, the SA and KD payloads MUST 585 be omitted from the message. 587 The following fields of the Delete Payload are further defined as 588 follows: 590 o The Domain of Interpretation field contains the FMKE DOI. 592 The Flat Multicast Key Exchange September , 2004 594 o The Protocol-Id field contains TEK protocol id values defined 595 in Section 7.8 of this document. To delete a KEK SA, the value 596 of zero MUST be used as the protocol id. Note that only one 597 protocol id value can be defined in a Delete payload. If a TEK 598 SA and a KEK SA must be deleted, they must be sent in different 599 Delete payloads. 601 6.0 Utilization of FMKE exchanges according to satellite network 602 topologies. 604 FMKE is used as described previously in STAR topologies with return 605 channel, and in MESH topologies. 607 In the case of one-way systems (without return channel), some 608 adaptations are necessary. The following part describes the 609 utilization of FMKE in one-way systems. It requires few 610 modifications. 612 6.1 Utilization in one-way systems. 614 - Phase 1 : 616 FMKE MUST be protected by a "phase 1" protocol SA, e.g. an ISAKMP SA. 617 For one-way systems, all SA attributes and policy (keys included) 618 will be manually and initially configured in GCKS and Group member 619 (one distinct SA for each member). 621 - FMKE Phase 2 : 623 Few modifications are required in the FMKE phase 2 exchange. 624 This exchange is indeed initiated by the GCKS, and does not require 625 the transmission of critical information by the Group member, except 626 to enable reliable key distribution. 627 For one-way systems, acknowledgements mechanisms are therefore 628 disabled, and the Group member sends no messages. 629 GCKS messages are not modified. 631 Group Member GCKS 632 ------------------ ---------------- 633 <-- HDR*, HASH(1), SEQ, SA, KD 634 <-- HDR*, HASH(1), SEQ, SA, KD 636 * Protected by the Phase 1 SA, encryption occurs after HDR 638 The HASH payload proves that the messages have not been modified 639 during transmission and that the peer knows the Phase 1 secret 640 (SKEYID_a). 642 The Flat Multicast Key Exchange September , 2004 644 The HASH payload also guarantees that messages are 645 not replayed from an old session establishment, as they required the 646 last configured Phase 1 secret. 647 The value contained in the SEQ payload (initialized to 0) allows the 648 member to delete all messages already received in the Phase 2, as it 649 has to check that the sequence number is greater than in the previous 650 SEQ payloads. 652 - FMKE phase 3: 654 Few modifications are required in the FMKE phase 3 exchange. 655 This exchange is indeed initiated by the GCKS and does not require 656 the transmission of critical information by Group members, except to 657 enable reliable key distribution. 658 For one-way systems, Non-Acknowledgements mechanisms are therefore 659 disabled, and Group members send no messages. 660 GCKS messages are not modified. 662 Group Member GCKS 663 ------------------ ---------------- 664 <-- HDR*, SEQ, SA, KD, SIG 665 <-- HDR*, SEQ, SA, KD, SIG 666 <-- HDR*, LSEQ, SIG 668 * protected by the Re-Key SA; encryption occurs after HDR 670 The SIG payload contains the digital signature of the entire message 671 before encryption (including the header and excluding the SIG payload 672 itself), prefixed with the string "rekey" like in GDOI. The signature 673 guarantees source data authentication. 674 The SIG payload of the GCKS messages proves that the messages have 675 not been modified during transmission, and that it has been generated 676 by the GCKS. 678 The SEQ payload allows Group members to detect replayed messages : 679 they delete all already received messages. 681 In order to guarantee the compatibility between the both uses of FMKE 682 in two-way systems and in one-way systems, the profile of each group 683 member (with or without return channel) MUST be configured in the GCKS. 685 Besides, for one-way systems, in order to guarantee a more reliable 686 distribution, each GCKS phase 2 or 3 message may be sent several 687 times (e.g. 3 times). 689 The Flat Multicast Key Exchange September , 2004 691 7.0 Payload and defined SA attributes. 693 FMKE uses several payloads defined in GDOI [RFC3547]: 695 Next Payload Type Value 696 ----------------- ----- 697 SA KEK Payload (SAK) 15 698 Key Download (KD) 17 699 Sequence Number (SEQ) 18 701 FMKE also uses the extension of the SA payload proposed in GDOI 702 [RFC 3547]: 704 Next Payload Type Value 705 ----------------- ----- 706 Security Association (SA) 1 708 FMKE extends the SAT payload defined in GDOI [RFC3547]: 710 Next Payload Type Value 711 ----------------- ----- 712 SA TEK Payload (SAT) 16 714 FMKE defines new payloads. Their value is chosen in the ISAKMP 715 "Private USE" range. 717 Next Payload Type Value 718 ----------------- ----- 719 Last Sequence Number (LSEQ) 133 720 Acknowledgement (ACK) 134 721 Selective Acknowledgement (SACK) 135 722 Negative Acknowledgement (NACK) 136 724 7.1 Last Sequence Number payload (LSEQ) 726 The Last Sequence Number payload contains a sequence number value 727 which allows to enable reliable Phase 3 exchanges. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 ! Next Payload ! RESERVED ! Payload Length ! 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 ! Last Sequence Number ! 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 The Last Sequence Number Payload fields are defined as follows: 739 The Flat Multicast Key Exchange September , 2004 741 o Next Payload (1 octet) - Identifier for the payload type of the 742 next payload in the message. If the current payload is the last in 743 the message, then this field will be zero. 745 o RESERVED (1 octet) - Unused, set to zero. 747 o Payload Length (2 octets) - Length in octets of the current 748 payload, including the generic payload header. 750 o Last Sequence Number (4 octets) - This field contains a counter 751 value, and more particularly the last counter value used by the GCKS 752 to order its messages. This value allows Group members to determine 753 which messages they have not received. 755 7.2 Acknowledgement payload (ACK) 757 The Acknowledgement payload contains a sequence number value which 758 allows to realize acknowledgements during phase 2. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 ! Next Payload ! RESERVED ! Payload Length ! 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 ! Acknowledged Sequence Number ! 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 The Acknowledgement payload fields are defined as follows: 770 o Next Payload (1 octet) - Identifier for the payload type of the 771 next payload in the message. If the current payload is the last in 772 the message, then this field will be zero. 774 o RESERVED (1 octet) - Unused, set to zero. 776 o Payload Length (2 octets) - Length in octets of the current 777 payload, including the generic payload header. 779 o Acknowledged Sequence Number (4 octets) - This field contains a 780 sequence number value. In the phase 2, the Group member sends 781 periodically messages with an ACK payload containing the sequence 782 number value of the last correctly received message. 784 The Flat Multicast Key Exchange September , 2004 786 7.3 Selective Acknowledgement payload (SACK) 788 The Selective Acknowledgement payload contains the values of two 789 sequence numbers, and allows to realize selective acknowledgement 790 during Phase 2. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 ! Next Payload ! RESERVED ! Payload Length ! 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 ! Start Acknowledged Sequence Number ! 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 ! End Acknowledged Sequence Number ! 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 The Selective Acknowledgement Payload fields are defined as follows: 804 o Next Payload (1 octet) - Identifier for the payload type of the 805 next payload in the message. If the current payload is the last in 806 the message, then this field will be zero. 808 o RESERVED (1 octet) - Unused, set to zero. 810 o Payload Length (2 octets) - Length in octets of the current 811 payload, including the generic payload header. 813 o Start Acknowledged Sequence Number (4 octets) - this field 814 contains a counter value 816 o End Acknowledged Sequence Number (4 octets) - this field 817 contains a counter value >= Start Acknowledged Sequence Number value 819 The SACK payload is used during Phase 2 by the Group member. When one 820 or several GCKS messages are missing, it allows to mention the 821 sequence following numbers of messages already received. 822 If there is only one message, the Start Acknowledged Sequence Number 823 and the End Acknowledged Sequence Number fields contain the value of 824 its sequence number. If there are several consecutive messages, the 825 Start Acknowledged Sequence Number field contains the sequence number 826 value of the first message, and the End Acknowledged Sequence Number 827 field contains the one of the last message. 829 7.4 Negative Acknowledgement payload (NACK) 831 The Negative Acknowledgement payload contains the values of two 832 sequence numbers, and allows to realize negative acknowledgements 833 during Phase 3. 835 The Flat Multicast Key Exchange September , 2004 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 ! Next Payload ! RESERVED ! Payload Length ! 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 ! Start Non Acknowledged Sequence Number ! 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 ! End Non Acknowledged Sequence Number ! 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 The Negative Acknowledgement Payload fields are defined as follows: 849 o Next Payload (1 octet) - Identifier for the payload type of the 850 next payload in the message. If the current payload is the last in 851 the message, then this field will be zero. 853 o RESERVED (1 octet) - Unused, set to zero. 855 o Payload Length (2 octets) - Length in octets of the current 856 payload, including the generic payload header. 858 o Start Non Acknowledged Sequence Number (4 octets) - this field 859 contains a counter value 861 o End Non Acknowledged Sequence Number (4 octets) - this field 862 contains a counter value >= Start Non Acknowledged Sequence Number 863 value 865 In the Phase 3, the NACK payload is used by Group members to mention 866 the sequence numbers of the messages they have not received. 867 If there is only one message, the Start Non Acknowledged Sequence 868 Number and the End Non Acknowledged Sequence Number fields contain 869 the value of its sequence number. If there are several consecutive 870 messages, the Start Non Acknowledged Sequence Number field contains 871 the sequence number value of the first message, and the End Non 872 Acknowledged Sequence Number field contains the one of the last 873 message. 875 7.5 Sequence Number Payload (SEQ) 877 The Sequence Number payload is a payload defined by GDOI [RFC 3547]. 878 In FMKE it contains a sequence number value which allows to introduce 879 reliable exchanges and to provide an anti-replay protection for FMKE 880 Phase 2 and Phase 3 exchanges. 882 The Flat Multicast Key Exchange September , 2004 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 ! Next Payload ! RESERVED ! Payload Length ! 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 ! Sequence Number ! 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 The Sequence Number Payload fields are defined as follows: 894 o Next Payload (1 octet) - Identifier for the payload type of the 895 next payload in the message. If the current payload is the last in 896 the message, then this field will be zero. 898 o RESERVED (1 octet) - Unused, set to zero. 900 o Payload Length (2 octets) - Length in octets of the current 901 payload, including the generic payload header. 903 o Sequence Number (4 octets) - This field contains a 904 monotonically increasing counter value. It is initialized to 0 by the 905 GCKS and is incremented in each subsequently-transmitted message. 906 In Phase 2, the GCKS messages contains a SEQ payload with the current 907 value of the sequence number. Thus the first packet sent in a phase 2 908 will have a Sequence Number of 1. The FMKE implementation keeps a 909 sequence counter as an attribute for the Registration SA and 910 increments the counter upon receipt of a GCKS phase 2 message. It 911 must also keep a sliding receive window for it. 912 In the phase 3, the sequence number included in the SEQ payload 913 orders the messages sent by the GCKS. The first packet sent for a 914 given Rekey SA will have a Sequence Number of 1. The FMKE 915 implementation keeps a sequence counter as an attribute for the 916 Rekey SA and increments the counter upon receipt of a GCKS phase 3 917 message. The current value of the sequence number must be initially 918 transmitted to Group members during the phase 2 as an attribute of 919 the Re-key SA. The group members must also keep a sliding window for 920 this counter. 921 Each phase 2 or 3 therefore has its own counter. 923 7.6. Security Association Payload 925 The Security Association payload is defined in RFC 2408. FMKE re-uses 926 the extension proposed in GDOI [RFC 3547]. This payload is used to 927 assert security attributes for both Re-key and Data-security SAs. 929 The Flat Multicast Key Exchange September , 2004 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 934 ! Next Payload ! RESERVED ! Payload Length ! 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 ! DOI ! 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 938 ! Situation ! 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 940 ! SA Attribute Next Payload ! RESERVED2 ! 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 943 The Security Association Payload fields are defined as follows: 945 o Next Payload (1 octet) -- Identifies the next payload. 946 The next payload MUST NOT be a SAK Payload or SAT Payload type, 947 but the next non-Security Association type payload. 949 o RESERVED (1 octet) -- Must be zero. 951 o Payload Length (2 octets) -- Is the octet length of the current 952 payload including the generic header and all TEK and KEK 953 payloads. 955 o DOI (4 octets) - FMKE DOI value (the GDOI value is 2). 957 o Situation (4 octets) -- Must be zero. 959 o SA Attribute Next Payload (1 octet) -- Must be either a SAK 960 Payload or a SAT Payload. See section 7.6.1 for a description 961 of which circumstances are required for each payload type to be 962 present. 964 o RESERVED (2 octets) -- Must be zero. 966 7.6.1 Payloads following the SA payload 968 FMKE re-uses the SA KEK payload, and extends the SA TEK payload 969 defined in GDOI [RFC 3547]. 970 The payloads following the SA payload defined specific security 971 association attributes for KEKs and/or TEKs used by one or several 972 groups. 973 In phase 2, there may be zero, one or several SAK Payloads 974 (corresponding to different groups), and zero or more SAT Payloads 975 (associated to the same or to different groups), where either one SAK 976 or SAT payload MUST be present. 977 In phase 3, there may be zero or one SAK Payload (for the considered 978 group), and zero or more SAT Payloads (associated to the considered 979 group), where either one SAK or SAT payload MUST be present. 981 The Flat Multicast Key Exchange September , 2004 983 7.7. SA KEK payload 985 The SA KEK (SAK) payload is used as defined in GDOI [RFC3547]. 986 However FMKE introduces supplementary KEK attributes. 987 The SAK payload contains security attributes for the KEK method for 988 a group. The source and destination identities describe the 989 identities used for the phase 2 datagrams. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 994 ! Next Payload ! RESERVED ! Payload Length ! 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 996 ! Protocol ! SRC ID Type ! SRC ID Port ! 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 998 !SRC ID Data Len! SRC Identification Data ~ 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1000 ! DST ID Type ! DST ID Port !DST ID Data Len! 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1002 ! DST Identification Data ~ 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1004 ! ! 1005 ~ SPI ~ 1006 ! ! 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1008 ! POP Algorithm ! POP Key Length ! 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1010 ~ KEK Attributes ~ 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1013 The SAK Payload fields are defined as follows: 1015 o Next Payload (1 octet) -- Identifies the next payload. 1016 The only valid next payload types for this message are a SAT or 1017 SAK Payload or zero to indicate there is no SAK or SAT payload. 1019 o RESERVED (1 octet) -- Must be zero. 1021 o Payload Length (2 octets) -- Length of this payload, including 1022 the KEK attributes. 1024 o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., 1025 UDP/TCP) for the rekey datagram. 1027 o SRC ID Type (1 octet) -- Value describing the identity 1028 information found in the SRC Identification Data field. 1029 Defined values are specified by the IPSEC Identification Type 1030 section in the IANA isakmpd-registry [ISAKMP-REG]. 1032 The Flat Multicast Key Exchange September , 2004 1034 o SRC ID Port (2 octets) -- Value specifying a port associated 1035 with the source Id. A value of zero means that the SRC ID Port 1036 field should be ignored. 1038 o SRC ID Data Len (1 octet) -- Value specifying the length of the 1039 SRC Identification Data field. 1041 o SRC Identification Data (variable length) -- Value, as 1042 indicated by the SRC ID Type. 1044 o DST ID Type (1 octet) -- Value describing the identity 1045 information found in the DST Identification Data field. 1046 Defined values are specified by the IPSEC Identification Type 1047 section in the IANA isakmpd-registry [ISAKMP-REG]. 1049 o DST ID Port (2 octets) -- Value specifying a port associated 1050 with the source Id. 1052 o DST ID Data Len (1 octet) -- Value specifying the length of the 1053 DST Identification Data field. 1055 o DST Identification Data (variable length) -- Value, as 1056 indicated by the DST ID Type. 1058 o SPI (16 octets) -- Security Parameter Index for the KEK. The 1059 SPI must be the ISAKMP Header cookie pair where the first 8 1060 octets become the "Initiator Cookie" field, and the second 8 1061 octets become the "Responder Cookie" of the ISAKMP header of 1062 the Phase 3 messages (i.e. of the messages protected by the 1063 Re-key SA). As described above, these cookies are assigned by 1064 the GCKS. 1066 o POP Algorithm (2 octets) -- The POP payload algorithm. Defined 1067 values are specified in the following table. If no POP 1068 algorithm is defined by the KEK policy this field must be zero. 1070 Algorithm Type Value 1071 -------------- ----- 1072 RESERVED 0 1073 POP_ALG_RSA 1 1074 POP_ALG_DSS 2 1075 POP_ALG_ECDSS 3 1076 RESERVED 4-127 1077 Private Use 128-255 1079 o POP Key Length (2 octets) -- Length of the POP payload key. If 1080 no POP algorithm is defined in the KEK policy, this field must 1081 be zero. 1083 The Flat Multicast Key Exchange September , 2004 1085 o KEK Attributes -- Contains KEK policy attributes associated 1086 with the group. The following sections describe the possible 1087 attributes. Any or all attributes may be optional, depending on 1088 the group policy. 1090 7.7.1. KEK Attributes 1092 FMKE defines 2 more attributes : HASH_ALGORITHM and NEXT_SEQ_NUMBER. 1093 The following table presents all the attributes which may be present 1094 in a SAK Payload. The attributes must follow the format defined in 1095 ISAKMP [RFC2408] section 3.3. In the table, attributes which follow 1096 the Type/Value (TV) format are marked as Basic (B); attributes which 1097 follow the Type/Length/Value (TLV) format are marked as Variable(V). 1099 ID Class Value Type 1100 -------- ----- ---- 1101 RESERVED 0 1102 KEK_MANAGEMENT_ALGORITHM 1 B 1103 KEK_ALGORITHM 2 B 1104 KEK_KEY_LENGTH 3 B 1105 KEK_KEY_LIFETIME 4 V 1106 SIG_HASH_ALGORITHM 5 B 1107 SIG_ALGORITHM 6 B 1108 SIG_KEY_LENGTH 7 B 1109 KE_OAKLEY_GROUP 8 B 1110 HASH_ALGORITHM 9 B 1111 NEXT_SEQ_NUMBER 10 B 1113 7.7.2. KEK_MANAGEMENT_ALGORITHM (Defined in GDOI) 1115 The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management 1116 algorithm used to provide forward or backward access control (i.e., 1117 used to exclude group members). Defined values are specified in the 1118 following table. 1120 KEK Management Type Value 1121 ------------------- ----- 1122 RESERVED 0 1123 LKH 1 1124 RESERVED 2-127 1125 Private Use 128-255 1127 7.7.3. KEK_ALGORITHM (Defined in GDOI) 1129 The KEK_ALGORITHM class specifies the encryption algorithm using with 1130 the KEK. Defined values are specified in the following table. 1132 The Flat Multicast Key Exchange September , 2004 1134 Algorithm Type Value 1135 -------------- ----- 1136 RESERVED 0 1137 KEK_ALG_DES 1 1138 KEK_ALG_3DES 2 1139 KEK_ALG_AES 3 1140 RESERVED 4-127 1141 Private Use 128-255 1143 7.7.4. KEK_KEY_LENGTH(Defined in GDOI) 1145 The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in 1146 bits). 1148 7.7.5. KEK_KEY_LIFETIME(Defined in GDOI) 1150 The KEK_KEY_LIFETIME class specifies the maximum time for which the 1151 KEK is valid. The GCKS may refresh the KEK at any time before the 1152 end of the valid period. The value is a four (4) octet number 1153 defining a valid time period in seconds. 1155 7.7.6. SIG_HASH_ALGORITHM(Defined in GDOI) 1157 SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The 1158 following tables define the algorithms for SIG_HASH_ALGORITHM. 1160 Algorithm Type Value 1161 -------------- ----- 1162 RESERVED 0 1163 SIG_HASH_MD5 1 1164 SIG_HASH_SHA1 2 1165 RESERVED 3-127 1166 Private Use 128-255 1168 7.7.7. SIG_ALGORITHM(Defined in GDOI) 1170 The SIG_ALGORITHM class specifies the SIG payload signature 1171 algorithm. Defined values are specified in the following table. 1173 Algorithm Type Value 1174 -------------- ----- 1175 RESERVED 0 1176 SIG_ALG_RSA 1 1177 SIG_ALG_DSS 2 1178 SIG_ALG_ECDSS 3 1179 RESERVED 4-127 1180 Private Use 128-255 1182 The Flat Multicast Key Exchange September , 2004 1184 7.7.8. SIG_KEY_LENGTH(Defined in GDOI) 1186 The SIG_KEY_LENGTH class specifies the length of the SIG payload key. 1188 7.7.9. KE_OAKLEY_GROUP(Defined in GDOI) 1190 The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute 1191 the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL 1192 exchange. This attribute uses the values assigned to Group 1193 Definitions in the IANA IPsec-registry [IPSEC-REG]. 1195 7.7.10. HASH_ALGORITHM 1197 The HASH_ALGORITHM class specifies the hash algorithm to use for the 1198 HASH payload. Defined values are specified in the following table. 1200 Algorithm Type Value 1201 -------------- ----- 1202 RESERVED 0 1203 HASH_ALG_MD5 1 1204 HASH_ALG_SHA 2 1205 RESERVED 3-127 1206 Private Use 128-255 1208 7.7.11. NEXT_SEQ_NUMBER 1210 The NEXT_SEQUENCE_NUMBER class specifies the next sequence number 1211 used by the GCKS in the Phase 3 messages protected by the 1212 considered Re-key SA . 1214 7.8. SA TEK Payload 1216 FMKE uses the SA TEK (SAT) payload defined in GDOI [RFC 3547]. In the 1217 SAT, it modifies the TEK Protocol-Specific Payload for ESP. 1218 The SA TEK (SAT) payload contains security attributes for a single 1219 TEK associated with a group. 1221 0 1 2 3 1222 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 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1224 ! Next Payload ! RESERVED ! Payload Length ! 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1226 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 1227 +-+-+-+-+-+-+-+-+ ~ 1228 ~ ~ 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1231 The SAT Payload fields are defined as follows: 1233 The Flat Multicast Key Exchange September , 2004 1235 o Next Payload (1 octet) -- Identifies the next payload. The only 1236 valid next payload types for this message are another SAT or 1237 SAK Payload or zero to indicate there are no more security 1238 association attributes. 1240 o RESERVED (1 octet) -- Must be zero. 1242 o Payload Length (2 octets) -- Length of this payload, including 1243 the TEK Protocol-Specific Payload. 1245 o Protocol-ID (1 octet) -- Value specifying the Security 1246 Protocol. The following table defines values for the Security 1247 Protocol 1249 Protocol ID Value 1250 ----------- ----- 1251 RESERVED 0 1252 FMKE_PROTO_IPSEC_ESP 1 1253 RESERVED 2-127 1254 Private Use 128-255 1256 o TEK Protocol-Specific Payload (variable) -- Payload which 1257 describes the attributes specific for the Protocol-ID. 1259 7.8.1. PROTO_IPSEC_ESP 1261 FMKE extends the TEK Protocol-Specific payload for ESP, defined in 1262 the GDOI. As a matter of fact, satellite networks require to use ESP 1263 in tunnel mode. Tunnel identifiers MUST therefore be mentioned : 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1268 ! Protocol ! SRC ID Type ! SRC ID Port ! 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1270 !SRC ID Data Len! SRC Identification Data ~ 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1272 ! DST ID Type ! DST ID Port !DST ID Data Len! 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1274 ! DST Identification Data ~ 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1276 !TNL SRC ID Type! TNL SRC ID Port !TNL SRC ID Len ! 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1278 ! TNL SRC Identification Data ~ 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1280 !TNL DST ID Type! TNL DST ID Port !TNL DST ID Len ! 1282 The Flat Multicast Key Exchange September , 2004 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1285 ! TNL DST Identification Data ~ 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1287 ! Transform ID ! SPI ! 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1289 ! SPI ! RFC 2407 SA Attributes ~ 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1292 The SAT Payload fields are defined as follows: 1294 o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., 1295 UDP/TCP). A value of zero means that the Protocol field should 1296 be ignored. 1298 o SRC ID Type (1 octet) -- Value describing the identity 1299 information found in the SRC Identification Data field. 1300 Defined values are specified by the IPSEC Identification Type 1301 section in the IANA isakmpd-registry [ISAKMP-REG]. 1303 o SRC ID Port (2 octets) -- Value specifying a port associated 1304 with the source Id. A value of zero means that the SRC ID Port 1305 field should be ignored. 1307 o SRC ID Data Len (1 octet) -- Value specifying the length of the 1308 SRC Identification Data field. 1310 o SRC Identification Data (variable length) -- Value, as 1311 indicated by the SRC ID Type. Set to three bytes of zero for 1312 multiple-source multicast groups that use a common TEK for all 1313 senders. 1315 o DST ID Type (1 octet) -- Value describing the identity 1316 information found in the DST Identification Data field. 1317 Defined values are specified by the IPSEC Identification Type 1318 section in the IANA isakmpd-registry [ISAKMP-REG]. 1320 o DST ID Port (2 octets) -- Value specifying a port associated 1321 with the dest. Id. A value of zero means that the DST ID Port 1322 field should be ignored. 1324 o DST ID Data Len (1 octet) -- Value specifying the length of the 1325 DST Identification Data field. 1327 o DST Identification Data (variable length) -- Value, as 1328 indicated by the DST ID Type. 1330 The Flat Multicast Key Exchange September , 2004 1332 o TNL SRC ID Type (1 octet) -- Value describing the identity 1333 information found in the TNL SRC Identification Data field. 1334 Defined values are specified by the IPSEC Identification Type 1335 section in the IANA isakmpd-registry [ISAKMP-REG]. 1337 o TNL SRC ID Port (2 octets) -- Value specifying a port 1338 associated with the Tunnel source Id. A value of zero means 1339 that the TNL SRC ID Port field should be ignored. 1341 o TNL SRC ID Data Len (1 octet) -- Value specifying the length 1342 of the TNL SRC Identification Data field. 1344 o TNL SRC Identification Data (variable length) -- Value, as 1345 indicated by the TNL SRC ID Type. Set to three bytes of zero 1346 for multiple-source multicast groups that use a common TEK for 1347 all senders. 1349 o TNL DST ID Type (1 octet) -- Value describing the identity 1350 information found in the TNL DST Identification Data field. 1351 Defined values are specified by the IPSEC Identification Type 1352 section in the IANA isakmpd-registry [ISAKMP-REG]. 1354 o TNL DST ID Port (2 octets) -- Value specifying a port 1355 associated with the tunnel dst Id. A value of zero means 1356 that the DST ID Port field should be ignored. 1358 o TNL DST ID Data Len (1 octet) -- Value specifying the length 1359 of the TNL DST Identification Data field. 1361 o TNL DST Identification Data (variable length) -- Value, as 1362 indicated by the TNL DST ID Type. 1364 o Transform ID (1 octet) -- Value specifying which ESP transform 1365 is to be used. The list of valid values is defined in the 1366 IPSEC ESP Transform Identifiers section of the IANA 1367 isakmpd-registry [ISAKMP-REG]. 1369 o SPI (4 octets) -- Security Parameter Index for ESP. 1371 o RFC 2407 Attributes -- ESP Attributes from RFC 2407 Section 1372 4.5. FMKE like GDOI supports all IPSEC DOI SA Attributes for 1373 PROTO_IPSEC_ESP excluding the Group Description [RFC2407, 1374 section 4.5], which MUST NOT be sent by a FMKE implementation 1375 and is ignored by a FMKE implementation if received. All 1376 mandatory IPSEC DOI attributes are mandatory in FMKE 1377 PROTO_IPSEC_ESP. The Authentication Algorithm attribute of the 1378 IPSEC DOI is group authentication in FMKE. 1380 The Flat Multicast Key Exchange September , 2004 1382 7.9. Key Download Payload 1384 FMKE re-uses the Key Download payload as defined by the GDOI 1385 [RFC 3547]. The Key Download Payload contains group keys 1386 corresponding to SAKs or/and SATs specified in the SA payload . 1388 0 1 2 3 1389 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 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1391 ! Next Payload ! RESERVED ! Payload Length ! 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1393 ! Number of Key Packets ! RESERVED2 ! 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1395 ~ Key Packets ~ 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1398 The Key Download Payload fields are defined as follows: 1400 o Next Payload (1 octet) -- Identifier for the payload type of 1401 the next payload in the message. If the current payload is the 1402 last in the message, then this field will be zero. 1404 o RESERVED (1 octet) -- Unused, set to zero. 1406 o Payload Length (2 octets) -- Length in octets of the current 1407 payload, including the generic payload header. 1409 o Number of Key Packets (2 octets) -- Contains the total number 1410 of both TEK and Rekey arrays being passed in this data block. 1412 o Key Packets 1413 Several types of key packets are defined. Each Key Packet has 1414 the following format. 1416 0 1 2 3 1417 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 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1419 ! KD Type ! RESERVED ! KD Length ! 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1421 ! SPI Size ! SPI (variable) ~ 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1423 ~ Key Packet Attributes ~ 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1426 o Key Download (KD) Type (1 octet) -- Identifier for the Key Data 1427 field of this Key Packet. 1429 The Flat Multicast Key Exchange September , 2004 1431 Key Download Type Value 1432 ----------------- ----- 1433 RESERVED 0 1434 TEK 1 1435 KEK 2 1436 LKH 3 1437 RESERVED 4-127 1438 Private Use 128-255 1440 "KEK" is a single key whereas LKH is an array of key-encrypting keys. 1442 o RESERVED (1 octet) -- Unused, set to zero. 1444 o Key Download Length (2 octets) -- Length in octets of the Key 1445 Packet data, including the Key Packet header. 1447 o SPI Size (1 octet) -- Value specifying the length in octets of 1448 the SPI as defined by the Protocol-Id. 1450 o SPI (variable length) -- Security Parameter Index which matches 1451 a SPI previously sent in an SAK or SAT Payload. 1453 o Key Packet Attributes (variable length) -- Contains Key 1454 information. The format of this field is specific to the value 1455 of the KD Type field. The following sections describe the 1456 format of each KD Type. 1458 7.9.1. TEK Download Type 1460 FMKE re-uses the TEK Download Type as defined in the GDOI 1461 The following attributes may be present in a TEK Download Type. 1462 Exactly one attribute matching each type sent in the SAT payload MUST 1463 be present. The attributes must follow the format defined in ISAKMP 1464 [RFC2408] section 3.3. In the table, attributes defined as TV are 1465 marked as Basic (B);attributes defined as TLV are marked as Variable 1466 (V). 1468 TEK Class Value Type 1469 --------- ----- ---- 1470 RESERVED 0 1471 TEK_ALGORITHM_KEY 1 V 1472 TEK_INTEGRITY_KEY 2 V 1473 TEK_SOURCE_AUTH_KEY 3 V 1475 If no TEK key packets are included in a Registration KD, the group 1476 member can expect to receive the TEK as part of a Re-key SA (during a 1477 phase 3). 1478 At least one TEK must be included in each Re-key KD payload. 1479 Multiple TEKs may be included if multiple streams associated with the 1480 SA are to be rekeyed. 1482 The Flat Multicast Key Exchange September , 2004 1484 7.9.1.1. TEK_ALGORITHM_KEY 1486 The TEK_ALGORITHM_KEY class declares that the encryption key for this 1487 SPI is contained as the Key Packet Attribute. The encryption 1488 algorithm that will use this key was specified in the SAT payload. 1490 In the case that the algorithm requires multiple keys (e.g., 3DES), 1491 all keys will be included in one attribute. 1493 DES keys will consist of 64 bits (the 56 key bits with parity bit). 1494 Triple DES keys will be specified as a single 192 bit attribute 1495 (including parity bits) in the order that the keys are to be used for 1496 encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). 1498 7.9.1.2. TEK_INTEGRITY_KEY 1500 The TEK_INTEGRITY_KEY class declares that the integrity key for this 1501 SPI is contained as the Key Packet Attribute. The integrity 1502 algorithm that will use this key was specified in the SAT payload. 1503 Thus, GDOI assumes that both the symmetric encryption and integrity 1504 keys are pushed to the member. SHA keys will consist of 160 bits, 1505 and MD5 keys will consist of 128 bits. 1507 7.9.1.3. TEK_SOURCE_AUTH_KEY 1509 The TEK_SOURCE_AUTH_KEY class declares that the source authentication 1510 key for this SPI is contained in the Key Packet Attribute. The 1511 source authentication algorithm that will use this key was specified 1512 in the SAT payload. 1514 7.9.2 KEK Download Type 1516 FMKE re-uses the KEK Download type but introduces a new attribute: 1517 KEK_GROUP_AUTH_KEY. 1518 The following attributes may be present in a KEK Download Type. 1519 Exactly one attribute matching each type sent in the SAK payload MUST 1520 be present. The attributes must follow the format defined in ISAKMP 1521 [RFC2408] section 3.3. In the table, attributes defined as TV are 1522 marked as Basic (B); attributes defined as TLV are marked as Variable 1523 (V). 1525 KEK Class Value Type 1526 --------- ----- ---- 1527 RESERVED 0 1528 KEK_ALGORITHM_KEY 1 V 1529 SIG_ALGORITHM_KEY 2 V 1530 KEK_GROUP_AUTH_KEY 3 V 1532 The Flat Multicast Key Exchange September , 2004 1534 Contrary to the GDOI, several KEK key packets can be included in 1535 a Registration KD payload. 1537 7.9.2.1. KEK_ALGORITHM_KEY 1539 The KEK_ALGORITHM_KEY class declares the encryption key for this SPI 1540 is contained in the Key Packet Attribute. The encryption algorithm 1541 that will use this key was specified in the SAK payload. 1543 If the mode of operation for the algorithm requires an Initialization 1544 Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY 1545 before the actual key. 1547 7.9.2.2. SIG_ALGORITHM_KEY 1549 The SIG_ALGORITHM_KEY class declares that the public key for this SPI 1550 is contained in the Key Packet Attribute, which may be useful when no 1551 public key infrastructure is available. The signature algorithm that 1552 will use this key was specified in the SAK payload. 1554 7.9.2.3. KEK_GROUP_AUTH_KEY 1556 The KEK_GROUP_AUTH_KEY class declares that the group authentication 1557 key for this SPI is contained in the Key Packet Attribute. 1558 The group authentication algorithm that will use this key was 1559 specified in the SAK payload. 1561 8.0 Domain of Interpretation for FMKE. 1563 FMKE requires a specific DOI, as it introduces new exchange types, 1564 payloads, security association attributes... 1565 RFC 2408 recommends that the designer of the new DOI begins with an 1566 existing DOI and customizes only the parts that are unacceptable. 1567 For FMKE, we based this specific DOI on the Group Domain of 1568 Interpretation (GDOI). 1570 8.1 Payloads. 1572 FMKE defines 4 new payloads with regard to the GDOI (and the IPSEC 1573 DOI): 1574 Last Sequence Number (LSEQ),Acknowledgement (ACK), Selective 1575 Acknowledgement (SACK), Negative Acknowledgement (NACK) payloads. 1576 It also extends the SAT defined by the GDOI (c.f. 7.0). 1578 8.2 New exchange types. 1580 FMKE introduces two additional exchange types. The value of these 1581 exchanges is mentioned in the Exchange Type field of the ISAKMP 1582 header of the messages in FMKE Phase 2 and 3. 1584 The Flat Multicast Key Exchange September , 2004 1586 The exchange type of the phase 2 is called : FMKE_unicast_Push and 1587 the exchange type of the phase 3 is called : FMKE_multicast_Push . 1589 Exchange type Value 1590 ---------------- ----------- 1591 FMKE_unicast_Push 240 1592 FMKE_multicast_Push 241 1594 8.3 Security Association attributes. 1596 With regard to GDOI, FMKE defines two new attributes for Re-key SA : 1597 HASH_ALGORITHM and NEXT_SEQ_NUMBER, and a new key class : 1598 KEK_GROUP_AUTH_KEY. 1600 9.0 Security considerations. 1602 FMKE is a security association (SA) management protocol for groups 1603 It is adapted to satellite networks, to protect group data 1604 transmitted on satellite links. Its objective is to establish 1605 securely security associations at group members (which are distinct 1606 from data initial source and final receivers - FMKE is not destined 1607 to provide end-to-end security). This protocol achieves first the 1608 entity authentication of the GCKS and the Group member, then it 1609 establishes a secure channel for the key management messages 1610 which ensures confidentiality, integrity and source authentication. 1612 This protocol uses security mechanisms in order to ensure 1613 confidentiality, entity and data origin authentication, and to avoid 1614 man-in-the-middle, replay attacks. 1616 FMKE assumes the network is not secure and may be under the complete 1617 control of an attacker, but it assumes that the communication 1618 endpoints are secure. Group members must be trusted to protect 1619 authentication values (pre-shared key), encryption/decryption keys 1620 and message authentication keys. 1622 FMKE is composed of 3 phases : an ISAKMP Phase 1, and two new 1623 exchanges : the Phase 2 which is protected by the ISAKMP Phase 1, and 1624 the Phase 3. Security considerations for each phase are addressed 1625 separately in the following. 1627 9.1 ISAKMP Phase 1 1629 FMKE uses the Phase 1 exchange defined in [RFC2409] to protect the 1630 FMKE Phase 2. Therefore all security properties and considerations of 1631 those exchanges (as noted in [RFC2409]) are relevant for FMKE. 1633 The Flat Multicast Key Exchange September , 2004 1635 9.1.1 Authentication 1637 Authentication is provided via the mechanisms defined in [RFC2409], 1638 based on Pre-Shared Keys (Public Key encryption could also be 1639 considered). 1641 9.1.2 Confidentiality 1643 Confidentiality is achieved in Phase 1 through a Diffie-Hellman 1644 exchange that provides keying material, and through negotiation of 1645 encryption transforms. 1647 9.1.3 Man-in-the-Middle Attack Protection 1649 FMKE relies on Phase 1 authentication to defeat man-in-the-middle 1650 attacks. 1652 9.1.4 Replay/Reflection Attack Protection 1654 FMKE relies on the Phase 1 nonce mechanism in combination with a 1655 hash-based message authentication code to protect against the replay 1656 or reflection of previous key management messages. Indeed, the 1657 authentication is successful only if the hash value contained in the 1658 HASH payload depends on the pre-shared key and on the Nonces randomly 1659 generated during the current Phase 1. 1661 9.1.5. Denial of Service Protection 1663 A denial of service attacker sends messages to an entity to cause 1664 that entity to perform unneeded message authentication operations. 1665 FMKE, like GDOI, uses the Phase 1 cookie mechanism to identify 1666 spurious messages prior to cryptographic hash processing. This is 1667 considered as a "weak" form of denial of service protection in that 1668 the entity must check for good cookies, which can be successfully 1669 imitated by a sophisticated attacker. 1671 9.2 Phase 2 Exchange 1673 During the Phase 2, the Group member receives securely from the GCKS, 1674 SAs of groups whose it is a member. Messages are protected by the 1675 Phase 1 security association. 1677 9.2.1 Authentication 1679 Peer authentication is not required in the Phase 2 protocol, as the 1680 Phase 1 protocol has previously authenticated the identity of the peer. 1681 Message authentication is provided by HASH payloads in each message, 1682 where the hash value contained in HASH is computed with the SKEYID_a 1683 authentication key (derived in the Phase 1 exchange), over all 1684 payloads in the message. 1686 The Flat Multicast Key Exchange September , 2004 1688 As only the GCKS and the Group member know the SKEYID_a value, this 1689 provides message source authentication. 1691 9.2.2 Confidentiality 1693 Confidentiality is provided by the Phase 1 security association, 1694 according to the manner described in [RFC2409]. 1696 9.2.3 Man-in-the-Middle Attack Protection 1698 As messages are encrypted, and recipients can authenticate their 1699 source (as being the GCKS or the Group member), man-in-middle attacks 1700 are avoided. Indeed an attacker would not be able if it changes a 1701 message to build a valid hash value. 1703 9.2.4 Replay/Reflection Attack Protection 1705 The HASH payloads guarantee that messages are not replayed messages from 1706 an old session establishment, as they required the secret of the last 1707 Phase 1. 1708 Besides, the SEQ payloads (including a sequence number)in the GCKS 1709 messages allows the group member to delete all messages already 1710 received in the Phase 2, as it has to check that the sequence number 1711 is greater than in the previous SEQ payloads. 1713 9.2.5 Denial of Service Protection 1715 A receiver identifies its messages using a cookie pair 1716 from the Phase 1 exchange that precedes it. The cookies provide a 1717 weak form of denial of service protection as described above, in the 1718 sense that a message with invalid cookies will be discarded. 1720 9.3 Phase 3 Exchange 1722 In the phase 3, the GCKS establishes and/or updates SAs in Group 1723 members. Messages are protected by the Re-key SA. 1725 9.3.1 Authentication 1727 The messages sent by the GCKS are digitally signed. The signature is 1728 contained in the SIG payload, and the private key, which is used for 1729 the signature, is known only by the GCKS. The corresponding public 1730 key that is used for authentication is an attribute of the Re-key SA, 1731 established in the phase 2. The signature guarantees source data 1732 authentication. 1733 Concerning the messages sent by group members, message authentication 1734 is provided by HASH payloads in each message, where the mentioned 1735 hash value is computed with a symmetric authentication key, which is 1736 an attribute of the Re-key SA. As only the GCKS and Group members 1737 know this key, this provides group message authentication. 1739 The Flat Multicast Key Exchange September , 2004 1741 9.3.2 Confidentiality 1743 Messages are encrypted with the symmetric encryption key and the 1744 encryption algorithm mentioned in the Re-key SA attributes. 1746 9.3.3 Man-in-the-Middle Attack Protection 1748 As messages are encrypted, and recipients can authenticate their 1749 source (as being the GCKS or a Group member), man-in-middle attacks 1750 are avoided. 1752 9.3.4 Replay/Reflection Attack Protection 1754 The SEQ payload of the GCKS messages, which contains a monotonically 1755 increasing sequence number, allows group member to detect replayed 1756 messages : they delete all already received messages. 1758 Group member messages (Nack) can be replayed, but the GCKS cannot 1759 retransmit a message an infinity of times. The number of 1760 retransmissions is limited and must allow all Group members to 1761 receive each message. 1763 9.3.5 Denial of Service Protection 1765 A cookie pair identifies the security association for the 1766 Phase 3 message. The cookies thus serve as a weak form of 1767 denial-of-service. 1769 10.0 IANA Considerations 1771 10.1 ISAKMP DOI 1773 A new ISAKMP DOI number needs to be assigned, in order to define FMKE. 1775 10.2 Payload Types 1777 New ISAKMP Next Payload types need to be allocated for FMKE payload 1778 types. See Section 7.0 for the payloads defined in this document. 1780 10.3 New Name spaces 1782 The present document describes some new name spaces for use in the 1783 FMKE payloads. Those may be found in 7.0 and 8.0. 1785 11.0 Acknowledgements 1787 The Flat Multicast Key Exchange September , 2004 1789 2.0 References 1791 [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry 1793 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 1794 (ESP)", November 1998. 1796 [RFC2407] D. Piper, "The Internet IP Domain of Interpretation for 1797 ISAKMP", November 1998. 1799 [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, "Internet 1800 Security Association and Key Management Protocol", November 1998. 1802 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1803 November, 1998. 1805 [RFC2547] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1806 Domain of Interpretation", July 2003 1808 [FIPS46-3] "Data Encryption Standard (DES)", United States of 1809 American, National Institute of Science and Technology, 1810 Federal Information Processing Standard (FIPS) 46-3, 1811 October 1999. 1813 [FIPS81] "DES Modes of Operation", United States of American, 1814 National Institute of Science and Technology, Federal 1815 Information Processing Standard (FIPS) 81, December 1816 1980. 1818 [FIPS186-2] "Digital Signature Standard (DSS)", United States of 1819 American, National Institute of Science and Technology, 1820 Federal Information Processing Standard (FIPS) 186-2, 1821 January 2000. 1823 [FIPS197] "Advanced Encryption Standard (AES)", United States of 1824 American, National Institute of Science and Technology, 1825 Federal Information Processing Standard (FIPS) 197, 1826 November 2001. 1828 [IPSEC-REG] http://www.iana.org/assignments/ipsec-registry 1830 [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry 1832 The Flat Multicast Key Exchange September , 2004 1834 Authors Addresses 1836 Laurence Duquerroy 1837 Alcatel Space 1838 26, avenue J.-F. Champollion 1839 B.P. 1187 1840 31037 Toulouse Cedex 1 , France 1841 +33 (0)5 34 35 63 06 1843 S�bastien Josset 1844 Alcatel Space 1845 26, avenue J.-F. Champollion 1846 B.P. 1187 1847 31037 Toulouse Cedex 1 , France 1848 +33 (0)5 34 35 51 04 1850 This Internet-Draft expires in February, 2005 1852 1