Internet Engineering Task Force L. Duquerroy INTERNET-DRAFT S.Josset Expires: February, 2005 September, 2004 The Flat Multicast Key Exchange protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange), derived from the Group Domain of Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is to Manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols such as the IPSEC ESP protocol. The FMKE protocol is destined to provide an optimized solution for very large groups with direct connections such as in satellite systems, or wireless systems such as WIFI. It can be considered as a GDOI use case adapted for satellite networks. Duquerroy , et al. [Page 1] The Flat Multicast Key Exchange September , 2004 Table of Contents 1.0 Introduction......................................................3 2.0 Phase 1 ..........................................................6 3.0 Phase 2 Exchange..................................................6 3.1 Messages......................................................6 3.2 Reliability...................................................8 3.3 ISAKMP Header Configuration...................................9 4.0 Phase 3 Exchange..................................................9 4.1 Messages......................................................9 4.2 Reliability..................................................11 4.3 ISAKMP Header Configuration..................................12 4.4 Phase 3 utilization..........................................12 5.0 Deletion of SAs..................................................12 6.0 Utilization of FMKE exchanges according to satellite network topologies.......................................................13 6.1 Utilization in one-way systems...............................13 7.0 Payloads and defined SA attributes...............................15 7.1 Last Sequence Number Payload (LSEQ)..........................15 7.2 Acknowledgement Payload (ACK)................................16 7.3 Selective Acknowledgement Payload(SACK)......................17 7.4 Negative Acknowledgement Payload (NACK)......................17 7.5 Sequence Number Payload (SEQ)................................18 7.6 Security Association Payload (SA)............................19 7.6.1 Payloads following the SA payload......................20 7.7 SA KEK payload...............................................21 7.7.1 KEK attributes ........................................23 7.7.2 KEK_MANAGEMENT_ALGORITHM ..............................23 7.7.3. KEK_ALGORITHM........................................23 7.7.4. KEK_KEY_LENGTH ......................................24 7.7.5. KEK_KEY_LIFETIME ....................................24 7.7.6. SIG_HASH_ALGORITHM ..................................24 7.7.7. SIG_ALGORITHM........................................24 7.7.8. SIG_KEY_LENGTH ......................................25 7.7.9. KE_OAKLEY_GROUP......................................25 7.7.10. HASH_ALGORITHM.......................................25 7.7.11. NEXT_SEQ_NUMBER......................................25 7.8 SA TEK payload...............................................25 7.8.1 PROTO_IPSEC_ESP........................................26 7.9 Key Download Payload.........................................29 7.9.1. TEK Download Type....................................30 7.9.2. KEK Download Type....................................31 8.0 Domain of Interpretation for FMKE................................32 8.1 Payloads.....................................................32 8.2 New Exchange types...........................................32 8.3 Security Association attributes..............................33 9.0 Security Considerations..........................................33 9.1 ISAKMP Phase 1...............................................33 9.1.1 Authentication.........................................34 9.1.2 Confidentiality........................................34 Duquerroy , et al. [Page 2] The Flat Multicast Key Exchange September, 2004 9.1.3 Man-in-the-middle Attack Protection....................34 9.1.4 Replay/Reflection Attack Protection....................34 9.2 Phase 2 Exchange.............................................34 9.2.1 Authentication.........................................35 9.2.2 Confidentiality........................................35 9.2.3 Man-in-the-middle Attack Protection....................35 9.2.4 Replay/Reflection Attack Protection....................35 9.3 Phase 3 Exchange.............................................35 9.3.1 Authentication.........................................35 9.3.2 Confidentiality........................................36 9.3.3 Man-in-the-middle Attack Protection....................36 9.3.4 Replay/Reflection Attack Protection....................36 10.0 IANA considerations.............................................36 10.1 ISAKMP DOI..................................................36 10.2 Payload types...............................................36 10.3 New Name spaces.............................................36 11.0 Acknowledgements............................................... 36 12.0 References..................................................... 37 1.0 Introduction This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange). Its objective is to manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols such as the IPSec ESP protocol, for the securisation of group communications. FMKE exchanges take place between the GCKS and Group members. The protocol establishes Data-security SAs and Re-key SAs in the authorized Group members. FMKE is derived from the Group Domain of Interpretation (GDOI) [RFC 3547], and can be seen as a GDOI use case adapted and optimized for satellite networks: - FMKE is destined to manage securely group SA in any satellite network topologies. These SA protect key-encrypting keys, traffic-encrypting keys, or data, transmitted on satellite links and shared by Group members. In Star topology, the Gateway (GW) is a terminal access concentrator. Communications take place only between the GW and Satellite terminals (ST) through the satellite. End users are located behind the STs. Communications between GW and each ST can be bi-directional(two-way systems : in such a case, the ST has a return channel), or unidirectional, from GW to ST (one-way systems : in such a case, the ST does not have a return channel). In Mesh topology, communications take place directly between STs (they are bi-directional). Duquerroy , et al. [Page 3] The Flat Multicast Key Exchange September , 2004 The FMKE objective is thus to establish group SA in group members (located in each ST and GW) in any types of topology (Remark : GCKS is located in GW in Star topology, and in a ST in Mesh topology). GW ST-----ST / | \ | \ / | / | \ | \ / | / | \ | \ | / | \ | / \ | / | \ | / \ | ST ST ST ST-----ST Star Topology Mesh Topology - Satellite networks can require reliable key distribution, in unicast and in multicast. For that purpose, FMKE defines specific mechanisms, implemented in the exchanges between GCKS and members. - In satellite networks, bandwidth is limited. FMKE aims at reducing the overhead generated by the establishment of group SAs. Thus FMKE changes the philosophy of the key distribution in order to limit the consumed bandwidth. - In satellite networks, data to be protected by Data-security SA are generated by end-users located behind STs or GW. These end-users are distinct from group members. Group members shall therefore encapsulate data in tunnels. For that purpose, FMKE defines additional information specifying the associated tunnel in the definition of Data-security SAs. FMKE uses several payloads introduced by GDOI: - GDOI SA - SA KEK (SAK) which follows the SA payload - Key Download Array (KD) - Sequence Number (SEQ) FMKE also extends the definition of the following GDOI payload: - SA TEK (SAT) which follows the SA payload FMKE defines new payloads : - Last Sequence Number (LSEQ) - Acknowledgement (ACK) - Selective Acknowledgement (SACK) - Negative Acknowledgement (NACK) Duquerroy , et al. [Page 4] The Flat Multicast Key Exchange September , 2004 Like the GDOI, FMKE MUST be protected by a Phase 1 security association. Similarly to [RFC3547], this document incorporates the Phase 1 security association (SA) definition from the Internet DOI [RFC2407, RFC2409]. FMKE defines two new exchanges derived from both exchanges of GDOI : 1/ The FMKE Phase 2 is derived from the GDOI "GROUKEY-PULL". Like the "GROUKEY-PULL" exchange, it is protected by the Phase 1 ISAKMP SA, and the GCKS transmits securely Data-Security SAs and Re-key SAs the Group member is authorized to get access to (i.e SAs of groups whose it is a member). A Re-key SA includes a key encrypting key, or KEK, common to a group; a Data-security SA includes a data encryption key, or TEK, used by a data-security protocol to encrypt or decrypt data traffic. Unlike GDOI, this phase takes place once, after the Phase 1. The member can receive directly all SAs it is authorized to get access to, without having to send a request for each group. This way FMKE limits the consumed bandwidth. Indeed the member does not have to send a request for each group, and a FMKE message from the GCKS can contain SAs from different groups. Moreover in order to provide reliability, the member sends periodically acknowledgement messages. 2/ The FMKE Phase 3 is derived from the GDOI "GROUKEY-PUSH". Like the "GROUKEY-PUSH" exchange, it is dedicated to a group, and is protected by the Re-key SA, which is shared by all Group members. In this phase, the GCKS transmits securely SAs to the Group members. It can create or update Re-key SA and/or Data-security SAs in group members. Unlike GDOI, this phase is defined with reliability mechanisms so that all Group members receive each new or updated SA. FMKE introduces new exchanges, new security payloads and new SA attributes with regard to the IPSec DOI or GDOI. FMKE requires therefore a new Domain Of Interpretation (DOI). The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. Duquerroy , et al. [Page 5] The Flat Multicast Key Exchange September , 2004 2.0 Phase 1. FMKE MUST be protected by a "phase 1" protocol. The phase 1 protocol provides a mutual authentication between GCKS and Group member, and establishes a security association between them , ensuring confidentiality, integrity and source authentication. The Phase 1 is then used to protect FMKE exchanges. Similarly to the GDOI, it is proposed to use the ISAKMP phase 1 (Main-Mode with pre-Shared key or Public Key for Authentication" phase 1) as defined in [RFC2409], as a "Phase 1" protocol for FMKE. It realizes a mutual authentication and establishes an ISAKMP SA, which provides all needed security services. During this phase, the DOI value mentioned in the ISAKMP Header of the exchanged messages MUST correspond to the DOI which defines the FMKE exchanges (c.f. 8.0). Besides, like GDOI, FMKE MUST NOT run on port 500 (the port commonly used for IKE), but on a port assigned to FMKE(the GDOI port is 848). 3.0 Phase 2 exchange. The goal of the Phase 2 exchange is to establish Re-keys SAs and/or Data-security SAs at the member. The transmitted SAs belong to the same or to different groups. There is one Re-key SA per group. During this phase, the member can receive all the Data security SAs and Re- key SAs it is authorized to get access to (the SAs of all the groups whose it is a member). The Phase 2 exchange takes place once, after the Phase 1; and is initiated by the GCKS. It is protected by the Phase 1 SA. 3.1 Messages. Group Member GCKS ------------------ ---------------- <-- HDR*, HASH(1), SEQ, SA, KD <-- HDR*, HASH(1), SEQ, SA, KD HDR*, HASH(2), ACK, [,SACK] --> <-- HDR*, HASH(1), SEQ, SA, KD HDR*, HASH(2), ACK, [,SACK] --> ... * Protected by the Phase 1 SA, encryption occurs after HDR Hashes are computed as follows : HASH(1) = prf(SKEYID_a, SEQ | SA |KD ) HASH(2) = prf(SKEYID_a, ACK [ | SACK ]) Duquerroy , et al. [Page 6] The Flat Multicast Key Exchange September , 2004 Phase 2 messages are protected by the Phase 1 SA. The Phase 1 computes SKEYID_a, which is the key used to compute the hash value contained in the HASH payload of the Phase 2 messages, and K (derived from SKEYID_e), which is the key used to encrypt/decrypt the Phase 2 messages. SKEYID_a and K are derived according to [RFC2409]. Phase 2 exchange is composed of two types of messages : the messages sent by the GCKS, which contain the SA attributes and keys the member is authorized to get access to, and the messages sent by the member, which are used to acknowledge the previous messages. The number of messages transmitted by the GCKS is variable: it depends on the number of SAs to establish. Acknowledgement messages are sent periodically by the member. Their number is variable. HDR is an ISAKMP payload that uses the Phase 1 cookies. SA is the SA payload. It contains all the policy attributes of the SAs to establish, like in GDOI. KD is the Key Download payload defined in GDOI. If one or more Re-Key SAs are defined in the SA payload, KD will contain the KEKs. If one or more Data SAs are defined in the SA payload, KD will contains the TEKs. During a phase 2, the GCKS can transmit several Re-key SAs (one per group) and/or several Data-security SAs. The Re-Key SAs are identified by an ISAKMP cookie pair, which is included in the SA payload. This cookie pair is not negotiated, but determined and downloaded by the GCKS. The Data SAs are identified by a SPI (Secure Parameter Index), which is included in the SA payload. The SPI is not negotiated, but determined and downloaded by the GCKS. The signification of the value contained in the SEQ payload is different from the signification of the value of the GDOI GROUPKEY-PULL: it represents the value of a counter which is used to order the phase 2 messages of GCKS. In the member messages, the value contained in the ACK payload mentions the sequence number of the last correctly received message. The SACK payload can be optionally included in the Phase 2 member messages. When one or several GCKS messages are missing, it allows to mention the sequence numbers of following messages already received (c.f. 3.2). Duquerroy , et al. [Page 7] The Flat Multicast Key Exchange September , 2004 The HASH payload proves that the messages have not been modified during transmission and that the peer knows the Phase 1 secret(SKEYID_a). The HASH payload also guarantees that messages are not replayed from an old session establishment, as they required the secret of the last Phase 1. The SEQ payload in the GCKS messages allows the member to delete all messages already received in the Phase 2, as it has to check that the sequence number is greater than in the previous SEQ payloads. In FMKE, verifying the liveliness of the member is not needed, because there is only one Phase 2, which begins just after the Phase 1, and because the Phase 2 is initiated by the GCKS. If the member cannot acknowledge the GCKS messages, the connection is closed. The liveliness of the GCKS is proved thanks to the HASH and to the SEQ payloads, which guarantee that it owns the Phase 1 secret and the current sequence number. 3.2 Reliability. FMKE requires reliable session establishment phases. In the Phase 2, reliability mechanisms are based on positive acknowledgements (the member acknowledges received messages), retransmission of non acknowledged messages and optionally selective acknowledgements (Sack). Thus, the member sends periodically positive acknowledgements to acknowledge GCKS messages. For that purpose, a sequence number is assigned to each GCKS message (mentioned in the SEQ payload), which orders these messages. In acknowledgement messages, the value contained in the ACK payload mentions the sequence number of the last correctly received message. The SACK payload can be optionally included in the member messages. When one or several GCKS messages are missing, it allows to mention the numbers of following messages already received. Ex : First sequence number used : 1 Sequence numbers of the messages sent by the GCKS : 1 2 3 4 5 6 7 8 9 Sequence numbers of the messages received by the Member : 1 2 3 4 . 6 7 . 9 (5 and 8 are lost) Acknowledgement sent by the member : Ack : 4 , Sack : 6-7, Sack : 9-9 (this acknowledgement must trigger the retransmission of the messages 5 and 8). Duquerroy , et al. [Page 8] The Flat Multicast Key Exchange September , 2004 3.3 ISAKMP Header configuration (Hdr) The Initiator Cookie field is the cookie of the Group member, generated during the Phase 1 according to ISAKMP [RFC2408]. The Responder Cookie field is the cookie of the GCKS, generated during the Phase 1 according to ISAKMP [RFC2408]. Next Payload identifies an ISAKMP, GDOI or FMKE payload. Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408]. The Exchange Type field is set to "FMKE_unicast_Push" (c.f. 8.2) Flags, Messages ID and Length are according to ISAKMP[RFC2408]. 4.0 Phase 3 exchange During Phase 3, the GCKS sends securely control information to Group members using group communications. Typically this will be using IP multicast. Like in GDOI, the goal of the Phase 3 exchange is to create new Data security SAs, and/or replace the Re-key SA into Group members (of a same group). The Phase 3 is protected by the Re-key SA of the group. The GCKS pushes the new SA attributes. 4.1 Messages Group Member GCKS ------------------ ---------------- <-- HDR*, SEQ, SA, KD, SIG x<- HDR*, SEQ, SA, KD, SIG <-- HDR*, LSEQ, SIG HDR*, HASH, NACK --> <-- HDR*, SEQ, SA, KD, SIG ... * protected by the Re-Key SA; encryption occurs after HDR The Phase 3 messages are protected by the Re-key SA. They are encrypted and authenticated according to the Re-key SA attributes. In the Phase 3, the GCKS sends two types of messages. The first type Messages contain the SA and KD payloads, and is used to create and/or replace new SAs. Like in Phase 2, a SEQ payload is included in each message, containing a sequence number value. Duquerroy , et al. [Page 9] The Flat Multicast Key Exchange September , 2004 The second type messages are sent periodically. They contain a LSEQ payload whose value mentions the last sequence number used by the GCKS. This payload is used to enable reliability (c.f. 4.2). The Group member sends only one type of messages. These messages are used as Non-acknowledgement messages: they request the retransmission, in multicast, of the message(s), whose sequence number(s) is(are) mentioned in the NACK payload(s). HDR is an ISAKMP payload that uses the Re-key SA cookies (c.f. 3.1). SA is the SA payload, containing the policy attributes for a Re-key SA and/or Data-Security SAs. KD is the Key Download payload. If the SA defines a Re-key SA, KD contains a KEK. This SA has a new cookie pair and replaces the Re-key SA for the group. If the SA defines new Data-SA, KD contains the TEK associated to each SA. In the GCKS's first type messages, the SEQ payload contains a sequence number whose value orders these messages. Each Group member has received included in the Re-key SA attributes (during the Re-key SA establishment in Phase 2) the value of the sequence number which will be used in the next GCKS message (of the phase 3). In the GCKS's second type messages, the LSEQ payload mentions the last used sequence number. In the member messages, the values contained in the NACK payload(s) mention the sequence numbers of messages that the member requests for retransmission. The SIG payload contains the digital signature of the entire message before encryption (including the header and excluding the SIG payload itself), prefixed with the string "rekey" like in GDOI. The signature guarantees source data authentication, i.e. the source of this message is the GCKS. The SIG payload of the GCKS messages proves that the messages have not been modified during transmission, and that it has been generated by the GCKS. The SEQ payload of the GCKS messages allows Group members to detect replayed messages : they delete all already received messages. The value contained in the HASH payload of the Group member messages proves that the messages have not been modified during transmission, and that the source is a Group member. We do not need to know exactly which the source is for this type of messages (Non acknowledgement). Duquerroy , et al. [Page 10] The Flat Multicast Key Exchange September , 2004 The Hash value is calculated with the symmetric authentication key and the authentication algorithm which are mentioned in the Re-key SA attributes. The Group member messages could be replayed, but the GCKS cannot retransmit a message an infinity of times. The number of retransmissions is limited and must allow all Group members to receive each message. 4.2 Reliability FMKE requires reliable session establishment phases. In the Phase 3, reliability mechanisms are based on negative acknowledgements with retransmission : when a Group member determines that it has not received one or several messages, it requests for their retransmission by sending a Non-acknowledgement message (Nack). Retransmission is achieved in multicast. Like in the second phase, a sequence number is assigned to each GCKS message (mentioned in the SEQ payload). Its value orders these messages. Each Group member has received included the Re-key SA attributes (during the Re-key SA establishment in Phase 2) the value of the sequence number which will be used in the next GCKS message (of the phase 3). Moreover, the GCKS sends periodically in multicast a message with the last used sequence number (in the LSEQ payload). Thus, a Group member can easily determine that it has not received one or several messages, and can send a Non-acknowledgement message in unicast to the GCKS, containing the missing sequence numbers. This message triggers the retransmission in multicast of the missing messages (with the same sequence numbers). Ex : Next sequence number used by the GCKS (configuration) : 5 Sequence number of the messages sent by the GCKS : 5 6 7 8 9 Sequence number of the messages received by a Member : . 6 7 . 9 (5 and 8 are missing) Non-Acknowledgement sent by the Member : Nack : 5-5 , Nack : 8-8 (this acknowledgement must trigger the retransmission of the messages 5 and 8). When a Group member determines that one message is missing, he waits a predetermined time before sending its Non-acknowledgement message. The time before sending a Nack varies for each Group member, in order to avoid massive Nack emission and thus the congestion at GCKS side. The Group member waiting time follows a pre-calculated distribution: few of them will be authorized to send a Nack at the beginning, and it is expected that these messages will be sufficient so that all Group members receive the GCKS messages. Duquerroy , et al. [Page 11] The Flat Multicast Key Exchange September , 2004 4.3 ISAKMP Header configuration The cookie pair identifies the Re-key SA. These cookies are assigned by the GCKS (c.f. 3.1). The first 8 octets of the cookie pair become the "Initiator Cookie" field and the second 8 octets become the "Responder Cookie" field in the ISAKMP header. Next Payload identifies an ISAKMP, GDOI or FMKE payload. Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408]. The Exchange Type field is set to "FMKE_multicast_Push" (c.f. 8.2) In the Flags field, the encryption bit is set to 1 and the others bits MUST be set to 0. Messages ID and Length are according to ISAKMP[RFC2408]. 4.4 Phase 3 utilization The Phase 3 allows to configure and update simultaneously Group members. This phase can be initiated for instance when several Group members establish a connection with the GCKS at the same time. The Phase 2 is required only to provide each Group Member with the Re-key SA. The Phase 3 is then used to transmit simultaneously to all the Group members the Data-security SAs. This phase can also be used to guarantee the common evolution of the Group members' SAs. The Phase 2 and 3 are complementary. 5.0 Deletion of SAs There are times the GCKS may want to signal to receivers to delete SAs, for example at the end of a broadcast. Like in GDOI, deletion of keys may be accomplished by sending an ISAKMP Delete payload [RFC2408, Section 3.15]. However it can be sent as part of a FMKE phase 2 or phase 3 message contrary to GDOI. One or more Delete payloads MAY be placed following the SEQ payload in a GCKS phase 2 message or in a GCKS phase 3 message. If a GCKS has no further SAs to send to group members, the SA and KD payloads MUST be omitted from the message. The following fields of the Delete Payload are further defined as follows: o The Domain of Interpretation field contains the FMKE DOI. Duquerroy , et al. [Page 12] The Flat Multicast Key Exchange September , 2004 o The Protocol-Id field contains TEK protocol id values defined in Section 7.8 of this document. To delete a KEK SA, the value of zero MUST be used as the protocol id. Note that only one protocol id value can be defined in a Delete payload. If a TEK SA and a KEK SA must be deleted, they must be sent in different Delete payloads. 6.0 Utilization of FMKE exchanges according to satellite network topologies. FMKE is used as described previously in STAR topologies with return channel, and in MESH topologies. In the case of one-way systems (without return channel), some adaptations are necessary. The following part describes the utilization of FMKE in one-way systems. It requires few modifications. 6.1 Utilization in one-way systems. - Phase 1 : FMKE MUST be protected by a "phase 1" protocol SA, e.g. an ISAKMP SA. For one-way systems, all SA attributes and policy (keys included) will be manually and initially configured in GCKS and Group member (one distinct SA for each member). - FMKE Phase 2 : Few modifications are required in the FMKE phase 2 exchange. This exchange is indeed initiated by the GCKS, and does not require the transmission of critical information by the Group member, except to enable reliable key distribution. For one-way systems, acknowledgements mechanisms are therefore disabled, and the Group member sends no messages. GCKS messages are not modified. Group Member GCKS ------------------ ---------------- <-- HDR*, HASH(1), SEQ, SA, KD <-- HDR*, HASH(1), SEQ, SA, KD * Protected by the Phase 1 SA, encryption occurs after HDR The HASH payload proves that the messages have not been modified during transmission and that the peer knows the Phase 1 secret (SKEYID_a). Duquerroy , et al. [Page 13] The Flat Multicast Key Exchange September , 2004 The HASH payload also guarantees that messages are not replayed from an old session establishment, as they required the last configured Phase 1 secret. The value contained in the SEQ payload (initialized to 0) allows the member to delete all messages already received in the Phase 2, as it has to check that the sequence number is greater than in the previous SEQ payloads. - FMKE phase 3: Few modifications are required in the FMKE phase 3 exchange. This exchange is indeed initiated by the GCKS and does not require the transmission of critical information by Group members, except to enable reliable key distribution. For one-way systems, Non-Acknowledgements mechanisms are therefore disabled, and Group members send no messages. GCKS messages are not modified. Group Member GCKS ------------------ ---------------- <-- HDR*, SEQ, SA, KD, SIG <-- HDR*, SEQ, SA, KD, SIG <-- HDR*, LSEQ, SIG * protected by the Re-Key SA; encryption occurs after HDR The SIG payload contains the digital signature of the entire message before encryption (including the header and excluding the SIG payload itself), prefixed with the string "rekey" like in GDOI. The signature guarantees source data authentication. The SIG payload of the GCKS messages proves that the messages have not been modified during transmission, and that it has been generated by the GCKS. The SEQ payload allows Group members to detect replayed messages : they delete all already received messages. In order to guarantee the compatibility between the both uses of FMKE in two-way systems and in one-way systems, the profile of each group member (with or without return channel) MUST be configured in the GCKS. Besides, for one-way systems, in order to guarantee a more reliable distribution, each GCKS phase 2 or 3 message may be sent several times (e.g. 3 times). Duquerroy , et al. [Page 14] The Flat Multicast Key Exchange September , 2004 7.0 Payload and defined SA attributes. FMKE uses several payloads defined in GDOI [RFC3547]: Next Payload Type Value ----------------- ----- SA KEK Payload (SAK) 15 Key Download (KD) 17 Sequence Number (SEQ) 18 FMKE also uses the extension of the SA payload proposed in GDOI [RFC 3547]: Next Payload Type Value ----------------- ----- Security Association (SA) 1 FMKE extends the SAT payload defined in GDOI [RFC3547]: Next Payload Type Value ----------------- ----- SA TEK Payload (SAT) 16 FMKE defines new payloads. Their value is chosen in the ISAKMP "Private USE" range. Next Payload Type Value ----------------- ----- Last Sequence Number (LSEQ) 133 Acknowledgement (ACK) 134 Selective Acknowledgement (SACK) 135 Negative Acknowledgement (NACK) 136 7.1 Last Sequence Number payload (LSEQ) The Last Sequence Number payload contains a sequence number value which allows to enable reliable Phase 3 exchanges. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Last Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Last Sequence Number Payload fields are defined as follows: Duquerroy , et al. [Page 15] The Flat Multicast Key Exchange September , 2004 o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Last Sequence Number (4 octets) - This field contains a counter value, and more particularly the last counter value used by the GCKS to order its messages. This value allows Group members to determine which messages they have not received. 7.2 Acknowledgement payload (ACK) The Acknowledgement payload contains a sequence number value which allows to realize acknowledgements during phase 2. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Acknowledged Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Acknowledgement payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Acknowledged Sequence Number (4 octets) - This field contains a sequence number value. In the phase 2, the Group member sends periodically messages with an ACK payload containing the sequence number value of the last correctly received message. Duquerroy , et al. [Page 16] The Flat Multicast Key Exchange September , 2004 7.3 Selective Acknowledgement payload (SACK) The Selective Acknowledgement payload contains the values of two sequence numbers, and allows to realize selective acknowledgement during Phase 2. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Start Acknowledged Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! End Acknowledged Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Selective Acknowledgement Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Start Acknowledged Sequence Number (4 octets) - this field contains a counter value o End Acknowledged Sequence Number (4 octets) - this field contains a counter value >= Start Acknowledged Sequence Number value The SACK payload is used during Phase 2 by the Group member. When one or several GCKS messages are missing, it allows to mention the sequence following numbers of messages already received. If there is only one message, the Start Acknowledged Sequence Number and the End Acknowledged Sequence Number fields contain the value of its sequence number. If there are several consecutive messages, the Start Acknowledged Sequence Number field contains the sequence number value of the first message, and the End Acknowledged Sequence Number field contains the one of the last message. 7.4 Negative Acknowledgement payload (NACK) The Negative Acknowledgement payload contains the values of two sequence numbers, and allows to realize negative acknowledgements during Phase 3. Duquerroy , et al. [Page 17] The Flat Multicast Key Exchange September , 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Start Non Acknowledged Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! End Non Acknowledged Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Negative Acknowledgement Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Start Non Acknowledged Sequence Number (4 octets) - this field contains a counter value o End Non Acknowledged Sequence Number (4 octets) - this field contains a counter value >= Start Non Acknowledged Sequence Number value In the Phase 3, the NACK payload is used by Group members to mention the sequence numbers of the messages they have not received. If there is only one message, the Start Non Acknowledged Sequence Number and the End Non Acknowledged Sequence Number fields contain the value of its sequence number. If there are several consecutive messages, the Start Non Acknowledged Sequence Number field contains the sequence number value of the first message, and the End Non Acknowledged Sequence Number field contains the one of the last message. 7.5 Sequence Number Payload (SEQ) The Sequence Number payload is a payload defined by GDOI [RFC 3547]. In FMKE it contains a sequence number value which allows to introduce reliable exchanges and to provide an anti-replay protection for FMKE Phase 2 and Phase 3 exchanges. Duquerroy , et al. [Page 18] The Flat Multicast Key Exchange September , 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Sequence Number ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sequence Number Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) - Unused, set to zero. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Sequence Number (4 octets) - This field contains a monotonically increasing counter value. It is initialized to 0 by the GCKS and is incremented in each subsequently-transmitted message. In Phase 2, the GCKS messages contains a SEQ payload with the current value of the sequence number. Thus the first packet sent in a phase 2 will have a Sequence Number of 1. The FMKE implementation keeps a sequence counter as an attribute for the Registration SA and increments the counter upon receipt of a GCKS phase 2 message. It must also keep a sliding receive window for it. In the phase 3, the sequence number included in the SEQ payload orders the messages sent by the GCKS. The first packet sent for a given Rekey SA will have a Sequence Number of 1. The FMKE implementation keeps a sequence counter as an attribute for the Rekey SA and increments the counter upon receipt of a GCKS phase 3 message. The current value of the sequence number must be initially transmitted to Group members during the phase 2 as an attribute of the Re-key SA. The group members must also keep a sliding window for this counter. Each phase 2 or 3 therefore has its own counter. 7.6. Security Association Payload The Security Association payload is defined in RFC 2408. FMKE re-uses the extension proposed in GDOI [RFC 3547]. This payload is used to assert security attributes for both Re-key and Data-security SAs. Duquerroy , et al. [Page 19] The Flat Multicast Key Exchange September , 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DOI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SA Attribute Next Payload ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The Security Association Payload fields are defined as follows: o Next Payload (1 octet) -- Identifies the next payload. The next payload MUST NOT be a SAK Payload or SAT Payload type, but the next non-Security Association type payload. o RESERVED (1 octet) -- Must be zero. o Payload Length (2 octets) -- Is the octet length of the current payload including the generic header and all TEK and KEK payloads. o DOI (4 octets) - FMKE DOI value (the GDOI value is 2). o Situation (4 octets) -- Must be zero. o SA Attribute Next Payload (1 octet) -- Must be either a SAK Payload or a SAT Payload. See section 7.6.1 for a description of which circumstances are required for each payload type to be present. o RESERVED (2 octets) -- Must be zero. 7.6.1 Payloads following the SA payload FMKE re-uses the SA KEK payload, and extends the SA TEK payload defined in GDOI [RFC 3547]. The payloads following the SA payload defined specific security association attributes for KEKs and/or TEKs used by one or several groups. In phase 2, there may be zero, one or several SAK Payloads (corresponding to different groups), and zero or more SAT Payloads (associated to the same or to different groups), where either one SAK or SAT payload MUST be present. In phase 3, there may be zero or one SAK Payload (for the considered group), and zero or more SAT Payloads (associated to the considered group), where either one SAK or SAT payload MUST be present. Duquerroy , et al. [Page 20] The Flat Multicast Key Exchange September , 2004 7.7. SA KEK payload The SA KEK (SAK) payload is used as defined in GDOI [RFC3547]. However FMKE introduces supplementary KEK attributes. The SAK payload contains security attributes for the KEK method for a group. The source and destination identities describe the identities used for the phase 2 datagrams. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol ! SRC ID Type ! SRC ID Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !SRC ID Data Len! SRC Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST ID Type ! DST ID Port !DST ID Data Len! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ~ SPI ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! POP Algorithm ! POP Key Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ KEK Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The SAK Payload fields are defined as follows: o Next Payload (1 octet) -- Identifies the next payload. The only valid next payload types for this message are a SAT or SAK Payload or zero to indicate there is no SAK or SAT payload. o RESERVED (1 octet) -- Must be zero. o Payload Length (2 octets) -- Length of this payload, including the KEK attributes. o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) for the rekey datagram. o SRC ID Type (1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. Duquerroy , et al. [Page 21] The Flat Multicast Key Exchange September , 2004 o SRC ID Port (2 octets) -- Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field should be ignored. o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field. o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type. o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. o DST ID Port (2 octets) -- Value specifying a port associated with the source Id. o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field. o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type. o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the "Initiator Cookie" field, and the second 8 octets become the "Responder Cookie" of the ISAKMP header of the Phase 3 messages (i.e. of the messages protected by the Re-key SA). As described above, these cookies are assigned by the GCKS. o POP Algorithm (2 octets) -- The POP payload algorithm. Defined values are specified in the following table. If no POP algorithm is defined by the KEK policy this field must be zero. Algorithm Type Value -------------- ----- RESERVED 0 POP_ALG_RSA 1 POP_ALG_DSS 2 POP_ALG_ECDSS 3 RESERVED 4-127 Private Use 128-255 o POP Key Length (2 octets) -- Length of the POP payload key. If no POP algorithm is defined in the KEK policy, this field must be zero. Duquerroy , et al. [Page 22] The Flat Multicast Key Exchange September , 2004 o KEK Attributes -- Contains KEK policy attributes associated with the group. The following sections describe the possible attributes. Any or all attributes may be optional, depending on the group policy. 7.7.1. KEK Attributes FMKE defines 2 more attributes : HASH_ALGORITHM and NEXT_SEQ_NUMBER. The following table presents all the attributes which may be present in a SAK Payload. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes which follow the Type/Value (TV) format are marked as Basic (B); attributes which follow the Type/Length/Value (TLV) format are marked as Variable(V). ID Class Value Type -------- ----- ---- RESERVED 0 KEK_MANAGEMENT_ALGORITHM 1 B KEK_ALGORITHM 2 B KEK_KEY_LENGTH 3 B KEK_KEY_LIFETIME 4 V SIG_HASH_ALGORITHM 5 B SIG_ALGORITHM 6 B SIG_KEY_LENGTH 7 B KE_OAKLEY_GROUP 8 B HASH_ALGORITHM 9 B NEXT_SEQ_NUMBER 10 B 7.7.2. KEK_MANAGEMENT_ALGORITHM (Defined in GDOI) The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management algorithm used to provide forward or backward access control (i.e., used to exclude group members). Defined values are specified in the following table. KEK Management Type Value ------------------- ----- RESERVED 0 LKH 1 RESERVED 2-127 Private Use 128-255 7.7.3. KEK_ALGORITHM (Defined in GDOI) The KEK_ALGORITHM class specifies the encryption algorithm using with the KEK. Defined values are specified in the following table. Duquerroy , et al. [Page 23] The Flat Multicast Key Exchange September , 2004 Algorithm Type Value -------------- ----- RESERVED 0 KEK_ALG_DES 1 KEK_ALG_3DES 2 KEK_ALG_AES 3 RESERVED 4-127 Private Use 128-255 7.7.4. KEK_KEY_LENGTH(Defined in GDOI) The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in bits). 7.7.5. KEK_KEY_LIFETIME(Defined in GDOI) The KEK_KEY_LIFETIME class specifies the maximum time for which the KEK is valid. The GCKS may refresh the KEK at any time before the end of the valid period. The value is a four (4) octet number defining a valid time period in seconds. 7.7.6. SIG_HASH_ALGORITHM(Defined in GDOI) SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The following tables define the algorithms for SIG_HASH_ALGORITHM. Algorithm Type Value -------------- ----- RESERVED 0 SIG_HASH_MD5 1 SIG_HASH_SHA1 2 RESERVED 3-127 Private Use 128-255 7.7.7. SIG_ALGORITHM(Defined in GDOI) The SIG_ALGORITHM class specifies the SIG payload signature algorithm. Defined values are specified in the following table. Algorithm Type Value -------------- ----- RESERVED 0 SIG_ALG_RSA 1 SIG_ALG_DSS 2 SIG_ALG_ECDSS 3 RESERVED 4-127 Private Use 128-255 Duquerroy , et al. [Page 24] The Flat Multicast Key Exchange September , 2004 7.7.8. SIG_KEY_LENGTH(Defined in GDOI) The SIG_KEY_LENGTH class specifies the length of the SIG payload key. 7.7.9. KE_OAKLEY_GROUP(Defined in GDOI) The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL exchange. This attribute uses the values assigned to Group Definitions in the IANA IPsec-registry [IPSEC-REG]. 7.7.10. HASH_ALGORITHM The HASH_ALGORITHM class specifies the hash algorithm to use for the HASH payload. Defined values are specified in the following table. Algorithm Type Value -------------- ----- RESERVED 0 HASH_ALG_MD5 1 HASH_ALG_SHA 2 RESERVED 3-127 Private Use 128-255 7.7.11. NEXT_SEQ_NUMBER The NEXT_SEQUENCE_NUMBER class specifies the next sequence number used by the GCKS in the Phase 3 messages protected by the considered Re-key SA . 7.8. SA TEK Payload FMKE uses the SA TEK (SAT) payload defined in GDOI [RFC 3547]. In the SAT, it modifies the TEK Protocol-Specific Payload for ESP. The SA TEK (SAT) payload contains security attributes for a single TEK associated with a group. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol-ID ! TEK Protocol-Specific Payload ~ +-+-+-+-+-+-+-+-+ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The SAT Payload fields are defined as follows: Duquerroy , et al. [Page 25] The Flat Multicast Key Exchange September , 2004 o Next Payload (1 octet) -- Identifies the next payload. The only valid next payload types for this message are another SAT or SAK Payload or zero to indicate there are no more security association attributes. o RESERVED (1 octet) -- Must be zero. o Payload Length (2 octets) -- Length of this payload, including the TEK Protocol-Specific Payload. o Protocol-ID (1 octet) -- Value specifying the Security Protocol. The following table defines values for the Security Protocol Protocol ID Value ----------- ----- RESERVED 0 FMKE_PROTO_IPSEC_ESP 1 RESERVED 2-127 Private Use 128-255 o TEK Protocol-Specific Payload (variable) -- Payload which describes the attributes specific for the Protocol-ID. 7.8.1. PROTO_IPSEC_ESP FMKE extends the TEK Protocol-Specific payload for ESP, defined in the GDOI. As a matter of fact, satellite networks require to use ESP in tunnel mode. Tunnel identifiers MUST therefore be mentioned : 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Protocol ! SRC ID Type ! SRC ID Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !SRC ID Data Len! SRC Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST ID Type ! DST ID Port !DST ID Data Len! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !TNL SRC ID Type! TNL SRC ID Port !TNL SRC ID Len ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! TNL SRC Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !TNL DST ID Type! TNL DST ID Port !TNL DST ID Len ! Duquerroy , et al. [Page 26] The Flat Multicast Key Exchange September , 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! TNL DST Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Transform ID ! SPI ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI ! RFC 2407 SA Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The SAT Payload fields are defined as follows: o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP). A value of zero means that the Protocol field should be ignored. o SRC ID Type (1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. o SRC ID Port (2 octets) -- Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field should be ignored. o SRC ID Data Len (1 octet) -- Value specifying the length of the SRC Identification Data field. o SRC Identification Data (variable length) -- Value, as indicated by the SRC ID Type. Set to three bytes of zero for multiple-source multicast groups that use a common TEK for all senders. o DST ID Type (1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. o DST ID Port (2 octets) -- Value specifying a port associated with the dest. Id. A value of zero means that the DST ID Port field should be ignored. o DST ID Data Len (1 octet) -- Value specifying the length of the DST Identification Data field. o DST Identification Data (variable length) -- Value, as indicated by the DST ID Type. Duquerroy , et al. [Page 27] The Flat Multicast Key Exchange September , 2004 o TNL SRC ID Type (1 octet) -- Value describing the identity information found in the TNL SRC Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. o TNL SRC ID Port (2 octets) -- Value specifying a port associated with the Tunnel source Id. A value of zero means that the TNL SRC ID Port field should be ignored. o TNL SRC ID Data Len (1 octet) -- Value specifying the length of the TNL SRC Identification Data field. o TNL SRC Identification Data (variable length) -- Value, as indicated by the TNL SRC ID Type. Set to three bytes of zero for multiple-source multicast groups that use a common TEK for all senders. o TNL DST ID Type (1 octet) -- Value describing the identity information found in the TNL DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG]. o TNL DST ID Port (2 octets) -- Value specifying a port associated with the tunnel dst Id. A value of zero means that the DST ID Port field should be ignored. o TNL DST ID Data Len (1 octet) -- Value specifying the length of the TNL DST Identification Data field. o TNL DST Identification Data (variable length) -- Value, as indicated by the TNL DST ID Type. o Transform ID (1 octet) -- Value specifying which ESP transform is to be used. The list of valid values is defined in the IPSEC ESP Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-REG]. o SPI (4 octets) -- Security Parameter Index for ESP. o RFC 2407 Attributes -- ESP Attributes from RFC 2407 Section 4.5. FMKE like GDOI supports all IPSEC DOI SA Attributes for PROTO_IPSEC_ESP excluding the Group Description [RFC2407, section 4.5], which MUST NOT be sent by a FMKE implementation and is ignored by a FMKE implementation if received. All mandatory IPSEC DOI attributes are mandatory in FMKE PROTO_IPSEC_ESP. The Authentication Algorithm attribute of the IPSEC DOI is group authentication in FMKE. Duquerroy , et al. [Page 28] The Flat Multicast Key Exchange September , 2004 7.9. Key Download Payload FMKE re-uses the Key Download payload as defined by the GDOI [RFC 3547]. The Key Download Payload contains group keys corresponding to SAKs or/and SATs specified in the SA payload . 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Number of Key Packets ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packets ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! The Key Download Payload fields are defined as follows: o Next Payload (1 octet) -- Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero. o RESERVED (1 octet) -- Unused, set to zero. o Payload Length (2 octets) -- Length in octets of the current payload, including the generic payload header. o Number of Key Packets (2 octets) -- Contains the total number of both TEK and Rekey arrays being passed in this data block. o Key Packets Several types of key packets are defined. Each Key Packet has the following format. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! KD Type ! RESERVED ! KD Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! SPI Size ! SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Key Packet Attributes ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! o Key Download (KD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet. Duquerroy , et al. [Page 29] The Flat Multicast Key Exchange September , 2004 Key Download Type Value ----------------- ----- RESERVED 0 TEK 1 KEK 2 LKH 3 RESERVED 4-127 Private Use 128-255 "KEK" is a single key whereas LKH is an array of key-encrypting keys. o RESERVED (1 octet) -- Unused, set to zero. o Key Download Length (2 octets) -- Length in octets of the Key Packet data, including the Key Packet header. o SPI Size (1 octet) -- Value specifying the length in octets of the SPI as defined by the Protocol-Id. o SPI (variable length) -- Security Parameter Index which matches a SPI previously sent in an SAK or SAT Payload. o Key Packet Attributes (variable length) -- Contains Key information. The format of this field is specific to the value of the KD Type field. The following sections describe the format of each KD Type. 7.9.1. TEK Download Type FMKE re-uses the TEK Download Type as defined in the GDOI The following attributes may be present in a TEK Download Type. Exactly one attribute matching each type sent in the SAT payload MUST be present. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes defined as TV are marked as Basic (B);attributes defined as TLV are marked as Variable (V). TEK Class Value Type --------- ----- ---- RESERVED 0 TEK_ALGORITHM_KEY 1 V TEK_INTEGRITY_KEY 2 V TEK_SOURCE_AUTH_KEY 3 V If no TEK key packets are included in a Registration KD, the group member can expect to receive the TEK as part of a Re-key SA (during a phase 3). At least one TEK must be included in each Re-key KD payload. Multiple TEKs may be included if multiple streams associated with the SA are to be rekeyed. Duquerroy , et al. [Page 30] The Flat Multicast Key Exchange September , 2004 7.9.1.1. TEK_ALGORITHM_KEY The TEK_ALGORITHM_KEY class declares that the encryption key for this SPI is contained as the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAT payload. In the case that the algorithm requires multiple keys (e.g., 3DES), all keys will be included in one attribute. DES keys will consist of 64 bits (the 56 key bits with parity bit). Triple DES keys will be specified as a single 192 bit attribute (including parity bits) in the order that the keys are to be used for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). 7.9.1.2. TEK_INTEGRITY_KEY The TEK_INTEGRITY_KEY class declares that the integrity key for this SPI is contained as the Key Packet Attribute. The integrity algorithm that will use this key was specified in the SAT payload. Thus, GDOI assumes that both the symmetric encryption and integrity keys are pushed to the member. SHA keys will consist of 160 bits, and MD5 keys will consist of 128 bits. 7.9.1.3. TEK_SOURCE_AUTH_KEY The TEK_SOURCE_AUTH_KEY class declares that the source authentication key for this SPI is contained in the Key Packet Attribute. The source authentication algorithm that will use this key was specified in the SAT payload. 7.9.2 KEK Download Type FMKE re-uses the KEK Download type but introduces a new attribute: KEK_GROUP_AUTH_KEY. The following attributes may be present in a KEK Download Type. Exactly one attribute matching each type sent in the SAK payload MUST be present. The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes defined as TV are marked as Basic (B); attributes defined as TLV are marked as Variable (V). KEK Class Value Type --------- ----- ---- RESERVED 0 KEK_ALGORITHM_KEY 1 V SIG_ALGORITHM_KEY 2 V KEK_GROUP_AUTH_KEY 3 V Duquerroy , et al. [Page 31] The Flat Multicast Key Exchange September , 2004 Contrary to the GDOI, several KEK key packets can be included in a Registration KD payload. 7.9.2.1. KEK_ALGORITHM_KEY The KEK_ALGORITHM_KEY class declares the encryption key for this SPI is contained in the Key Packet Attribute. The encryption algorithm that will use this key was specified in the SAK payload. If the mode of operation for the algorithm requires an Initialization Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY before the actual key. 7.9.2.2. SIG_ALGORITHM_KEY The SIG_ALGORITHM_KEY class declares that the public key for this SPI is contained in the Key Packet Attribute, which may be useful when no public key infrastructure is available. The signature algorithm that will use this key was specified in the SAK payload. 7.9.2.3. KEK_GROUP_AUTH_KEY The KEK_GROUP_AUTH_KEY class declares that the group authentication key for this SPI is contained in the Key Packet Attribute. The group authentication algorithm that will use this key was specified in the SAK payload. 8.0 Domain of Interpretation for FMKE. FMKE requires a specific DOI, as it introduces new exchange types, payloads, security association attributes... RFC 2408 recommends that the designer of the new DOI begins with an existing DOI and customizes only the parts that are unacceptable. For FMKE, we based this specific DOI on the Group Domain of Interpretation (GDOI). 8.1 Payloads. FMKE defines 4 new payloads with regard to the GDOI (and the IPSEC DOI): Last Sequence Number (LSEQ),Acknowledgement (ACK), Selective Acknowledgement (SACK), Negative Acknowledgement (NACK) payloads. It also extends the SAT defined by the GDOI (c.f. 7.0). 8.2 New exchange types. FMKE introduces two additional exchange types. The value of these exchanges is mentioned in the Exchange Type field of the ISAKMP header of the messages in FMKE Phase 2 and 3. Duquerroy , et al. [Page 32] The Flat Multicast Key Exchange September , 2004 The exchange type of the phase 2 is called : FMKE_unicast_Push and the exchange type of the phase 3 is called : FMKE_multicast_Push . Exchange type Value ---------------- ----------- FMKE_unicast_Push 240 FMKE_multicast_Push 241 8.3 Security Association attributes. With regard to GDOI, FMKE defines two new attributes for Re-key SA : HASH_ALGORITHM and NEXT_SEQ_NUMBER, and a new key class : KEK_GROUP_AUTH_KEY. 9.0 Security considerations. FMKE is a security association (SA) management protocol for groups It is adapted to satellite networks, to protect group data transmitted on satellite links. Its objective is to establish securely security associations at group members (which are distinct from data initial source and final receivers - FMKE is not destined to provide end-to-end security). This protocol achieves first the entity authentication of the GCKS and the Group member, then it establishes a secure channel for the key management messages which ensures confidentiality, integrity and source authentication. This protocol uses security mechanisms in order to ensure confidentiality, entity and data origin authentication, and to avoid man-in-the-middle, replay attacks. FMKE assumes the network is not secure and may be under the complete control of an attacker, but it assumes that the communication endpoints are secure. Group members must be trusted to protect authentication values (pre-shared key), encryption/decryption keys and message authentication keys. FMKE is composed of 3 phases : an ISAKMP Phase 1, and two new exchanges : the Phase 2 which is protected by the ISAKMP Phase 1, and the Phase 3. Security considerations for each phase are addressed separately in the following. 9.1 ISAKMP Phase 1 FMKE uses the Phase 1 exchange defined in [RFC2409] to protect the FMKE Phase 2. Therefore all security properties and considerations of those exchanges (as noted in [RFC2409]) are relevant for FMKE. Duquerroy , et al. [Page 33] The Flat Multicast Key Exchange September , 2004 9.1.1 Authentication Authentication is provided via the mechanisms defined in [RFC2409], based on Pre-Shared Keys (Public Key encryption could also be considered). 9.1.2 Confidentiality Confidentiality is achieved in Phase 1 through a Diffie-Hellman exchange that provides keying material, and through negotiation of encryption transforms. 9.1.3 Man-in-the-Middle Attack Protection FMKE relies on Phase 1 authentication to defeat man-in-the-middle attacks. 9.1.4 Replay/Reflection Attack Protection FMKE relies on the Phase 1 nonce mechanism in combination with a hash-based message authentication code to protect against the replay or reflection of previous key management messages. Indeed, the authentication is successful only if the hash value contained in the HASH payload depends on the pre-shared key and on the Nonces randomly generated during the current Phase 1. 9.1.5. Denial of Service Protection A denial of service attacker sends messages to an entity to cause that entity to perform unneeded message authentication operations. FMKE, like GDOI, uses the Phase 1 cookie mechanism to identify spurious messages prior to cryptographic hash processing. This is considered as a "weak" form of denial of service protection in that the entity must check for good cookies, which can be successfully imitated by a sophisticated attacker. 9.2 Phase 2 Exchange During the Phase 2, the Group member receives securely from the GCKS, SAs of groups whose it is a member. Messages are protected by the Phase 1 security association. 9.2.1 Authentication Peer authentication is not required in the Phase 2 protocol, as the Phase 1 protocol has previously authenticated the identity of the peer. Message authentication is provided by HASH payloads in each message, where the hash value contained in HASH is computed with the SKEYID_a authentication key (derived in the Phase 1 exchange), over all payloads in the message. Duquerroy , et al. [Page 34] The Flat Multicast Key Exchange September , 2004 As only the GCKS and the Group member know the SKEYID_a value, this provides message source authentication. 9.2.2 Confidentiality Confidentiality is provided by the Phase 1 security association, according to the manner described in [RFC2409]. 9.2.3 Man-in-the-Middle Attack Protection As messages are encrypted, and recipients can authenticate their source (as being the GCKS or the Group member), man-in-middle attacks are avoided. Indeed an attacker would not be able if it changes a message to build a valid hash value. 9.2.4 Replay/Reflection Attack Protection The HASH payloads guarantee that messages are not replayed messages from an old session establishment, as they required the secret of the last Phase 1. Besides, the SEQ payloads (including a sequence number)in the GCKS messages allows the group member to delete all messages already received in the Phase 2, as it has to check that the sequence number is greater than in the previous SEQ payloads. 9.2.5 Denial of Service Protection A receiver identifies its messages using a cookie pair from the Phase 1 exchange that precedes it. The cookies provide a weak form of denial of service protection as described above, in the sense that a message with invalid cookies will be discarded. 9.3 Phase 3 Exchange In the phase 3, the GCKS establishes and/or updates SAs in Group members. Messages are protected by the Re-key SA. 9.3.1 Authentication The messages sent by the GCKS are digitally signed. The signature is contained in the SIG payload, and the private key, which is used for the signature, is known only by the GCKS. The corresponding public key that is used for authentication is an attribute of the Re-key SA, established in the phase 2. The signature guarantees source data authentication. Concerning the messages sent by group members, message authentication is provided by HASH payloads in each message, where the mentioned hash value is computed with a symmetric authentication key, which is an attribute of the Re-key SA. As only the GCKS and Group members know this key, this provides group message authentication. Duquerroy , et al. [Page 35] The Flat Multicast Key Exchange September , 2004 9.3.2 Confidentiality Messages are encrypted with the symmetric encryption key and the encryption algorithm mentioned in the Re-key SA attributes. 9.3.3 Man-in-the-Middle Attack Protection As messages are encrypted, and recipients can authenticate their source (as being the GCKS or a Group member), man-in-middle attacks are avoided. 9.3.4 Replay/Reflection Attack Protection The SEQ payload of the GCKS messages, which contains a monotonically increasing sequence number, allows group member to detect replayed messages : they delete all already received messages. Group member messages (Nack) can be replayed, but the GCKS cannot retransmit a message an infinity of times. The number of retransmissions is limited and must allow all Group members to receive each message. 9.3.5 Denial of Service Protection A cookie pair identifies the security association for the Phase 3 message. The cookies thus serve as a weak form of denial-of-service. 10.0 IANA Considerations 10.1 ISAKMP DOI A new ISAKMP DOI number needs to be assigned, in order to define FMKE. 10.2 Payload Types New ISAKMP Next Payload types need to be allocated for FMKE payload types. See Section 7.0 for the payloads defined in this document. 10.3 New Name spaces The present document describes some new name spaces for use in the FMKE payloads. Those may be found in 7.0 and 8.0. 11.0 Acknowledgements Duquerroy , et al. [Page 36] The Flat Multicast Key Exchange September , 2004 2.0 References [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", November 1998. [RFC2407] D. Piper, "The Internet IP Domain of Interpretation for ISAKMP", November 1998. [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol", November 1998. [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", November, 1998. [RFC2547] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group Domain of Interpretation", July 2003 [FIPS46-3] "Data Encryption Standard (DES)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 46-3, October 1999. [FIPS81] "DES Modes of Operation", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 81, December 1980. [FIPS186-2] "Digital Signature Standard (DSS)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 186-2, January 2000. [FIPS197] "Advanced Encryption Standard (AES)", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 197, November 2001. [IPSEC-REG] http://www.iana.org/assignments/ipsec-registry [ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry Duquerroy , et al. [Page 37] The Flat Multicast Key Exchange September , 2004 Authors Addresses Laurence Duquerroy Alcatel Space 26, avenue J.-F. Champollion B.P. 1187 31037 Toulouse Cedex 1 , France +33 (0)5 34 35 63 06 S‰bastien Josset Alcatel Space 26, avenue J.-F. Champollion B.P. 1187 31037 Toulouse Cedex 1 , France +33 (0)5 34 35 51 04 This Internet-Draft expires in February, 2005 Duquerroy , et al. Expires February, 2005 [Page 38] 1