Internet Engineering Task Force L. Duquerroy INTERNET-DRAFT S.Josset Expires: October, 2003 May, 2003 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). Its objective is to manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These members can be identified for instance by a multicast IP address, a virtual LAN identifier, or a generic group label. 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 which wish to secure group communications. For the time being, the considered Data Security protocol is a multicast version of the IPSEC ESP protocol, but other Data Security protocols could be envisaged. The FMKE protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key Encryption Keys). The FMKE protocol is optimized for very large groups with direct connections such as satellite systems, or wireless systems such as WIFI. Duquerroy , et al. [Page 1] The Flat Multicast Key Exchange May, 2003 Table of Contents 1.0 Introduction......................................................3 2.0 Phase 1 ..........................................................4 3.0 Phase 2 Exchange..................................................5 3.1 Messages......................................................5 3.2 Reliability...................................................6 3.3 ISAKMP Header Configuration...................................7 4.0 Phase 3 Exchange..................................................8 4.1 Messages......................................................8 4.2 Reliability...................................................9 4.3 ISAKMP Header Configuration..................................10 4.4 Phase 3 utilization..........................................11 5.0 Re-keying........................................................11 5.1 Phase 2 Re-keying............................................11 5.2 Phase 3 Re-keying............................................12 6.0 Payloads and defined SA attributes...............................13 6.1 Sequence Number Payload (SEQ)................................13 6.2 Last Sequence Number Payload (LSEQ)..........................14 6.3 Acknowledgement Payload (ACK)................................15 6.4 Selective Acknowledgement Payload (SACK).....................15 6.5 Negative Acknowledgement Payload (NACK)......................16 6.6 Key Download Payload (KD)....................................17 6.7 Security Association Payload (SA)............................18 6.8 Proposal Payload (P).........................................19 6.9 Transform Payload (T)........................................20 6.10 Security Association attributes.............................21 6.10.1 Re-key SA.............................................21 6.10.2 Data-security SA......................................23 7.0 Domain of Interpretation for FMKE................................25 7.1 Security Protocol Identifiers................................25 7.1.1 PROTO_ISAKMP...........................................25 7.1.2 FMKE_PROTO_MGT.........................................25 7.1.3 FMKE_PROTO_IPSEC_ESP...................................25 7.2 Security Transform Identifiers...............................26 7.2.1 FMKE Re-key Transform identifier.......................26 7.2.2 ESP Transform identifier...............................26 7.3 Security Association attributes..............................26 7.4 Payloads.....................................................26 7.5 New Exchange types...........................................26 8.0 Security Considerations..........................................26 8.1 ISAKMP Phase 1...............................................26 8.1.1 Authentication.........................................27 8.1.2 Confidentiality........................................27 8.1.3 Man-in-the-middle Attack Protection....................27 8.1.4 Replay/Reflection Attack Protection....................27 8.2 Phase 2 Exchange.............................................28 8.2.1 Authentication.........................................28 8.2.2 Confidentiality........................................28 Duquerroy , et al. [Page 2] The Flat Multicast Key Exchange May, 2003 8.2.3 Man-in-the-middle Attack Protection....................28 8.2.4 Replay/Reflection Attack Protection....................28 8.3 Phase 3 Exchange.............................................28 8.3.1 Authentication.........................................29 8.3.2 Confidentiality........................................29 8.3.3 Man-in-the-middle Attack Protection....................29 8.3.4 Replay/Reflection Attack Protection....................29 9.0 IANA considerations..............................................29 9.1 ISAKMP DOI...................................................29 9.2 Payload types................................................29 9.3 New Name spaces..............................................30 10.0 Acknowledgements................................................30 11.0 References......................................................30 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 which wish to secure 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 composed of three phases (or exchanges). The Phase 1 is in charge of establishing a secure channel between the GCKS and a Group member, after having identified and authenticated the peers. This phase is used to protect the following exchanges. The chosen method is the "Main-Mode with pre-Shared key for Authentication " phase 1 defined in the IKE protocol [RFC2409], which establishes an ISAKMP SA. The Phase 2 is protected by the Phase 1 ISAKMP SA. This phase takes place once, after the Phase 1. 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). All SA attributes are transmitted, including specific information (filter) identifying the group, and the group encryption and authentication keys (TEK for Data-Security SA, and KEK for Re-Key SA). In order to achieve reliability, the member sends periodically acknowledgement messages. This phase can also be used for re-keying. Duquerroy , et al. [Page 3] The Flat Multicast Key Exchange May, 2003 The Phase 3 can be initiated by the GCKS as soon as the Re-key SA of a group is established in at least one Group member. This phase is protected by the Re-key SA, which is shared by all the Group members. In this phase, the GCKS transmits securely SAs to the Group members. It can create new Data-security SAs, and update Data-security SAs and the Re-key SA, in multiple group members. All SA attributes are transmitted, including specific information (filter) identifying the traffic to protect, and the group encryption and authentication keys. This phase can take place when several members of the same group establish a security session 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 Group members the SAs of the group. This phase can also be used to guarantee the common evolution of Group members' security configurations, and to renew the group keys in Group members. This phase is defined with reliability mechanisms so that all the Group members receive each new SA or key. When the three phases are completed, Group members are able to protect group communications. They encrypt/decrypt and authenticate group data according to the attributes of the Data-security SAs. Thus FMKE introduces new exchanges. It also introduces new security payloads (Sequence Number payload (SEQ), Acknowledgement payload (ACK), Selective Acknowledgement payload (SACK), Negative Acknowledgement payload (NACK), Last Sequence Number payload (LSEQ) and Key Download payload (KD)), and new SA attributes, according to the ISAKMP standard [RFC 2408]. FMKE requires therefore a new Domain Of Interpretation (DOI). It is foreseen to base it on the Internet IP Security Domain of Interpretation [RFC2407], and to customize only the parts that are unacceptable, as recommended in [RFC2408]. 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]. 2.0 Phase 1. The Phase 1 objectives are to provide a mutual authentication between the GCKS and the Group member, and to establish a secure channel between them, ensuring confidentiality, integrity and source authentication. The Phase 1 is used to protect the FMKE following exchanges. The "Main mode with pre-shared key for authentication" phase 1 of the IKE protocol [RFC2409] is used as the Phase 1. It realizes a mutual authentication and establishes an ISAKMP SA, which provides all needed security services. Duquerroy , et al. [Page 4] The Flat Multicast Key Exchange May, 2003 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. 7.0). 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, SA, SEQ <-- HDR*, HASH, SA, SEQ HDR*, HASH, ACK, [,SACK] --> <-- HDR*, HASH, SA, SEQ HDR*, HASH, ACK, [,SACK] --> ... * Protected by the Phase 1 SA, encryption occurs after HDR 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 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. The number is variable. Duquerroy , et al. [Page 5] The Flat Multicast Key Exchange May, 2003 HDR is an ISAKMP payload that uses the Phase 1 cookies. SA is the SA payload, containing all the attributes of the SAs to establish (TEK or KEK included). In the GCKS messages, the SEQ payload contains a sequence number which is used to order these messages. In the member messages, the value of 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 some already received next messages numbers (c.f. 3.2). 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 HASH payload [RFC 2409] proves that the messages have not been modified during transmission and that the peer knows the Phase 1 secret(SKEYID_a). The HASH payload guarantees also 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. Hashes are computed as follows : GCKS messages : HASH = prf(SKEYID_a, SA | SEQ) Group member messages : HASH = prf(SKEYID_a, ACK [ | SACK ]) 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). Duquerroy , et al. [Page 6] The Flat Multicast Key Exchange May, 2003 Thus, the GCKS transmits the SA attributes, while the member sends periodically positive acknowledgements. 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 some already received next messages numbers. 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). 3.3 ISAKMP Header configuration 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 or a 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. 7.5) Flags, Messages ID and Length are according to ISAKMP[RFC2408]. Duquerroy , et al. [Page 7] The Flat Multicast Key Exchange May, 2003 4.0 Phase 3 exchange During the Phase 3, the GCKS sends securely control information to multiple members using multicast addresses. The goal of the Phase 3 is to create, update, and/or replace Data security SAs, and/or to update 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*, SA, SEQ, SIG x<- HDR*, SA, SEQ, SIG <-- HDR*, LSEQ, SIG HDR*, HASH, NACK --> <-- HDR*, SA, SEQ, 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 contains the SA payload, and is used to create, update and/or replace new SAs (TEKs and KEKs are included). In these messages, as in Phase 2, a SEQ payload is included containing a sequence number which orders them. The second type messages are sent periodically. They contain a LSEQ payload whose value mentions the last sequence number used by the GCKS. They are required to ensure reliability (c.f. 4.2). The Group member sends only one type of messages. These messages are used as Non-acknowledgement messages, that is to say they request the retransmission, in multicast, of the message(s), whose sequence number(s) is(are) mentioned in the NACK payload(s). For a group, a Phase 3 exchange can be initiated by the GCKS as soon as the Re-key SA is established in at least one Group member. When the Re-key SA is established in a Group member, the next sequence number that the GCKS will use is mentioned in the Re-key SA attributes. Duquerroy , et al. [Page 8] The Flat Multicast Key Exchange May, 2003 HDR is an ISAKMP payload that uses the Re-key SA cookies (c.f. 3.1). SA is the SA payload, containing all the SA attributes (TEK and KEK included). In the GCKS's first type messages, the SEQ payload contains a sequence number whose value orders these messages. 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 the 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). The signature guarantees source data authentication, i.e. the source of these messages 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 HASH payload of the Group member messages proves that the messages have not been modified during transmission, and that the source is one of the Group members. We do not need to know exactly which the source is for this type of messages (Non acknowledgement). 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. Duquerroy , et al. [Page 9] The Flat Multicast Key Exchange May, 2003 As in the second phase, a sequence number is assigned to each GCKS message(mentioned in the SEQ payload). This sequence number orders these messages. Each Group member receives in the Re-key SA attributes (during the Re-key SA establishment) 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. 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 or a FMKE payload. Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408]. Duquerroy , et al. [Page 10] The Flat Multicast Key Exchange May, 2003 The Exchange Type field is set to "FMKE_multicast_Push" (c.f. 7.5) 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 multiple 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 Re-keying The GCKS is in charge of renewing periodically the keys of the established SAs (Data-security SAs and Re-Key SAs). Two re-keying modes are defined, based on the phase 2(unicast re-keying), or the phase 3(multicast re-keying) . 5.1 Phase 2 Re-keying Group Member GCKS ------------------ ---------------- <-- HDR*, HASH, SA, KD, SEQ HDR*, HASH, ACK, [,SACK] --> * Protected by the Phase 1 SA, encryption occurs after HDR This Re-keying mechanism is based on the Phase 2. Messages are similar to the ones defined in the Phase 2 (c.f. 3.1), and are also protected by the Phase 1 SA. Messages sent by the GCKS contain the new keys. The Group member sends the same messages as in 3.1., in order to acknowledge the GCKS messages. Duquerroy , et al. [Page 11] The Flat Multicast Key Exchange May, 2003 Security and reliability are based on the same mechanisms (HASH payloads, SEQ, ACK, SACK payloads). The same security and reliability services are provided (c.f. 3.2). The counter giving the sequence number mentioned in the SEQ payload of the GCKS messages and which is incremented for each new message, is the same as the one used for the SA establishment messages of the Phase 2. The GCKS messages are not completely similar, as the SA payload just identifies a SA, and does not include any SA attributes. The Key Download (KD) payload contains the new key(s), for the concerned SA. This re-keying scheme cannot be considered as the favorite one for group keys in large groups, as the re-keying message has to be sent as many times as the number of group members. The Phase 3 Re-keying scheme is more adapted in such a case. 5.2 Phase 3 Re-keying Group Member GCKS ------------------ ---------------- <-- HDR*, SA, KD, SEQ, SIG x<- HDR*, SA, KD, SEQ, SIG <-- HDR*, LSEQ, SIG HDR*, HASH, NACK --> <-- HDR*, SA, KD, SEQ, SIG * protected by the Re-Key SA; encryption occurs after HDR This Re-keying mechanism is based on the Phase 3. Messages are similar to the ones defined in the Phase 3 (c.f. 4.1.), and are also protected by the Re-Key SA. The GCKS sends two types of messages. The first type contains the new keys. The second type is the same one as in 4.1 : these messages are sent periodically and contain a LSEQ payload, whose value mentions the last sequence number used by the GCKS in the first type messages. The Group member sends the same messages as in 4.1, which are used as Non-acknowledgement messages. They request the retransmission of messages whose sequence numbers are mentioned in the NACK payload. Duquerroy , et al. [Page 12] The Flat Multicast Key Exchange May, 2003 Security and reliability are based on the same mechanisms (HASH, SIG payloads, SEQ, LSEQ, NACK payloads). The same security and reliability services are provided (c.f. 4.0). The counter giving the sequence number mentioned in the SEQ payload of the GCKS first type messages, and which is incremented for each new message, is the same as the one used for the SA establishment messages of the Phase 3. The GCKS first type messages are not completely similar, as the SA payload just identifies a SA, and does not include any SA attributes. The Key Download (KD) payload contains the new key(s), for the concerned SA. The advantage of that re-keying scheme is that only one message is needed to renew group keys in all group members, whatever the number of group members. 6.0 Payload and defined SA attributes. FMKE defines new payload types for its security exchanges. Their value is chosen in the ISAKMP "Private USE" range. Next Payload Type Value ----------------- ----- Sequence Number (SEQ) 133 Last Sequence Number (LSEQ) 134 Acknowledgement (ACK) 135 Selective Acknowledgement (SACK) 136 Negative Acknowledgement (NACK) 137 Key Download (KD) 138 FMKE uses also several ISAKMP payloads [RFC2408]. The specification of the following payloads is extended : Next Payload Type Value ----------------- ----- Security Association (SA) 1 Proposal(P) 2 Transform (T) 3 6.1 Sequence Number Payload (SEQ) The Sequence Number payload contains a sequence number value which allows to introduce reliable exchanges and to provide an anti-replay protection for the Phase 2 and the Phase 3 exchanges. Duquerroy , et al. [Page 13] The Flat Multicast Key Exchange May, 2003 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 by the GCKS and is incremented in each new-transmitted message. In the Phase 2, the GCKS messages contains a SEQ payload with the current value of the sequence number (it orders the messages). The Group member must 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 current value of the sequence number must be 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. Of course, each phase 2 or 3 has got its own counter. 6.2 Last Sequence Number payload (LSEQ) The Last Sequence Number payload contains a sequence number value which allows to introduce reliable exchanges for the Phase 3 exchange. 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 14] The Flat Multicast Key Exchange May, 2003 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 the messages they have not received. 6.3 Acknowledgement payload (ACK) The Acknowledgement payload contains a sequence number value which allows to realize acknowledgements. It participates in the introduction of reliable exchanges for the 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 counter value, and allows to realize acknowledgements. In the phase 2 , the Group member sends periodically messages with an ACK payload containing the value of the last correctly received message. 6.4 Selective Acknowledgement payload (SACK) Duquerroy , et al. [Page 15] The Flat Multicast Key Exchange May, 2003 The Selective Acknowledgement payload contains the values of two sequence numbers, and allows to realize selective acknowledgements. It participates in the introduction of reliable exchanges for the 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 in the Phase 2 by the Group member. When one or several GCKS messages are missing, it allows to mention some already received next messages numbers. 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. 6.5 Negative Acknowledgement payload (NACK) The Negative Acknowledgement payload contains the values of two sequence numbers, and allows to realize negative acknowledgements. It participates in the introduction of reliable exchanges in the Phase 3. Duquerroy , et al. [Page 16] The Flat Multicast Key Exchange May, 2003 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. 6.6 Key Download Payload (KD) The Key Download payload contains group keys for the SA specified in the SA payload. It is used in the Re-keying exchange, to transport new keys. Duquerroy , et al. [Page 17] The Flat Multicast Key Exchange May, 2003 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Key Download Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Key Download Data (variable) - the field contains the group keys for a SA (tbd) 6.7 Security Association Payload (SA) The Security Association, Proposal and Transform payloads are defined in [RFC 2408]. For FMKE, they are used to define both Re-key and Data-security SAs with their security attributes . When a GCKS message from the Phase 2 or 3 transports one or several SA tables, the global SA payload is composed of one SA payload, which defines the DOI and the Situation, followed by a Proposal and a Transform payloads for each SA. The Proposal payload defines the protocol id and the SPI of the SA, and the associated Transform payload defines its security attributes. 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Duquerroy , et al. [Page 18] The Flat Multicast Key Exchange May, 2003 The Security Association 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 0. This field MUST NOT contain the values for the Proposal or Transform payloads as they are considered part of the security association negotiation. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Security Association payload, including the SA payload, all Proposal payloads, and all Transform payloads associated with the proposed Security Association. o Domain of Interpretation (4 octets) - FMKE DOI o Situation (variable length) - Must be zero 6.8 Proposal Payload (P) 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! SPI (variable) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Proposal Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "2" or "0". If there are additional Proposal payloads in the message, then this field will be 2. If the current Proposal payload is the last within the security association proposal, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Proposal payload, including generic payload header, the Proposal payload, and all Transform payloads associated with this proposal. Duquerroy , et al. [Page 19] The Flat Multicast Key Exchange May, 2003 o Proposal # (1 octet) - Identifies the Proposal number for the current payload. o Protocol-Id (1 octet) - Value specifying the Security Protocol. In case of a Re-key SA, a specific protocol-Id has to be defined: FMKE_PROTO_MGT. In case of an ESP Data-security SA, the value is FMKE_PROTO_IPSEC_ESP (c.f. 7.1). Other values can be defined. o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of the Re-key SA, the SPI must be an ISAKMP cookie pair (16 octets). These cookies are assigned by the GCKS. 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 of the messages of the Phase 3 (i.e. of the messages protected by the Rekey-SA). In the case of an ESP Data security SA, the length defined by ESP is 4 octets. The SPI is assigned by the GCKS. o # of Transforms (1 octet) - Must be 1, as SA attributes are not negotiated o SPI (variable) - Security Parameter Index for the SA (Data- security or Re-key SA). 6.9 Transform Payload (T) 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform # ! Transform-Id ! RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ SA Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Transform Payload fields are defined as follows: o Next Payload (1 octet) - Must be zero. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, Transform values, and all SA Attributes. Duquerroy , et al. [Page 20] The Flat Multicast Key Exchange May, 2003 o Transform # (1 octet) - Must be 1 o Transform-Id (1 octet) - Specifies the Transform identifier for the protocol within the current proposal. For an ESP Data-security SA, the list of valid values are defined in the IPSec ESP Transform identifiers section of the IANA isakmpd- registery [ISAKMP-REG]. For Re-key SA, the value must be KEY_FMKE (c.f. 7.2.1) o RESERVED2 (2 octets) - Unused, set to 0. o SA Attributes (variable length) - This field contains the security association attributes as defined for the transform given in the Transform-Id field. The Part 6.10 defines the Security attributes for Re-key SA and for ESP Data-security SA. 6.10. Security Association attributes. 6.10.1 Re-key SA The following attributes may be present in the Transform of a Re-key SA. The attributes must follow the format defined in ISAKMP[RFC2408]. Attributes that follows the Type/Length/Value(TLV) format are marked as Variable (V), and attributes that follows the Type/Value(TV)format are marked as Basic(B) in the following table. Class Value Type ------------------------------------------------------------------ Encryption Algorithm 1 B Hash Algorithm 2 B KEK key length 3 B Signature Hash Algorithm 4 B Signature Algorithm 5 B Signature Key Length 6 B Life Type 7 B Life Duration 8 V Filter Type 9 B Filter Value 10 V Port 11 B KEK Encryption Key 12 V KEK Group Authentication Key 13 V Signature Key 14 V Next Sequence Number 15 B Duquerroy , et al. [Page 21] The Flat Multicast Key Exchange May, 2003 - Encryption Algorithm DES-CBC 1 IDEA-CBC 2 Blowfish-CBC 3 RC5-R16-B64-CBC 4 3DES-CBC 5 CAST-CBC 6 - Hash Algorithm MD5 1 SHA 2 - KEK Key Length Specifies the KEK Encryption and Group Authentication Key length. - Signature Hash Algorithm RESERVED 0 MD5 1 SHA1 2 RESERVED 3-127 Private Use 128-255 * table defined in GDOI - Signature Algorithm RESERVED 0 RSA 1 DSS 2 ECDSS 3 RESERVED 4-127 Private Use 128-255 * table defined in GDOI - Signature Key Length Specifies the length of the Signature Key - Life Type / Life Duration Specifies the time-to-live for the Re-key security association. - Filter Type / Filter Value Specifies the group destination (ex. : IPv4 address + mask ...) - Port Specifies the destination port Duquerroy , et al. [Page 22] The Flat Multicast Key Exchange May, 2003 - KEK Encryption Key Specifies the KEK encryption key, which is used to encrypt/ decrypt messages protected by the Re-key SA - KEK Group Authentication Key Specifies the KEK Group authentication key, which is used to provide group authentication for the messages protected by the Re-key SA - Signature Key Specifies the Public key of the Re-key SA (Public key of the GCKS). - Next Sequence Number Specifies the next sequence number used by the GCKS in the messages carrying SA information 6.10.2 Data-security SA Case of ESP SA : FMKE supports all IPSec DOI Attributes, excluding the Group Description. All mandatory IPSec DOI attributes are mandatory in FMKE. The DOI of FMKE defines other mandatory attributes (Filter type/value, Port, TEK encryption/group authentication keys). class Value Type ------------------------------------------------------------------- SA Life Type 1 B SA Life Duration 2 V Encapsulation Mode 3 B Authentication Algorithm 4 B Key Length 5 B Key Rounds 6 B Compress Dictionary Size 7 B Compress Private Algorithm 8 V Filter type 9 B Filter Value 10 V Port 11 B TEK Encryption Key 12 V TEK Group Authentication Key 13 V - SA Life Type / SA Life Duration Specifies the time-to-live for the Data-security SA. Duquerroy , et al. [Page 23] The Flat Multicast Key Exchange May, 2003 - Encapsulation Mode RESERVED 0 Tunnel 1 Transport 2 - Authentication algorithm RESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4 - Key Length RESERVED 0 There is no default value for Key Length, as it must be specified for transforms using ciphers with variable key lengths. For fixed length ciphers, the Key Length attribute MUST NOT be sent. - Key Rounds RESERVED 0 There is no default value for Key Rounds, as it must be specified for transforms using ciphers with varying numbers of rounds. - Compression Dictionary Size RESERVED 0 Specifies the log2 maximum size of the dictionary. There is no default value for dictionary size. - Compression Private Algorithm Specifies a private vendor compression algorithm. - Filter Type / Filter Value Specifies the group destination (IPv4 address + mask ...) - Port Specifies the destination port - TEK Encryption Key Specifies the TEK encryption key, which is used to encrypt/ decrypt messages protected by the Data-security SA. - TEK Group Authentication Key Specifies the TEK Group authentication key, which is used to provide group authentication for the messages protected by the Data-security SA Duquerroy , et al. [Page 24] The Flat Multicast Key Exchange May, 2003 For other data security protocols, additional information must be defined in the DOI of FMKE. Each protocol must own a Protocol_Id, a SPI size, and the transforms, the attributes and the keys needed. 7.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 IP Security Domain of Interpretation. 7.1 Security Protocol Identifiers. The following table lists the values for the Security Protocol Identifiers (Protocol ID) referenced in an ISAKMP Proposal Payload for the DOI of FMKE. Protocol ID Value ----------- ----- RESERVED 0 PROTO_ISAKMP 1 FMKE_PROTO_MGT 2 FMKE_PROTO_IPSEC_ESP 3 7.1.1 PROTO_ISAKMP The PROTO_ISAKMP type specifies message protection required during the Phase 1 and the Phase 2 of the FMKE protocol. The specific protection mechanism is the same as in the IPSEC DOI and is described in [IKE]. 7.1.2 FMKE_PROTO_MGT The FMKE_PROTO_MGT type specifies message protection required during the Phase 3 of FMKE, when messages are protected by the Re-key SA. 7.1.3 FMKE_PROTO_IPSEC_ESP The FMKE_PROTO_IPSEC_ESP type specifies IP packet confidentiality according to the IPSec ESP protocol. Authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication, integrity protection, replay detection, and confidentiality. Packet encapsulation is the same as with PROTO_IPSEC_ESP in the IPSec DOI. Duquerroy , et al. [Page 25] The Flat Multicast Key Exchange May, 2003 7.2 Security Transform Identifiers 7.2.1 FMKE Re-key Transform identifier. Transform Value --------- ----- RESERVED 0 KEY_FMKE 1 7.2.2 ESP Transform identifier. The list of valid values are defined in the IPSec ESP Transform identifiers section of the IANA isakmpd-registery [ISAKMP-REG] 7.3 Security Association attributes. C.f. 6.10.1, 6.10.2. 7.4 Payloads. FMKE defines 6 new payloads : Sequence Number(SEQ), Last Sequence Number (LSEQ), Acknowledgement (ACK), Selective Acknowledgement (SACK), Negative Acknowledgement (NACK) and Key Download (KD) payloads (c.f. 6.1-6). 7.5 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. 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.0 Security considerations. FMKE is a security association (SA) management protocol for groups of senders and receivers. Its objective is to establish securely security associations at communication endpoints. 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. Duquerroy , et al. [Page 26] The Flat Multicast Key Exchange May, 2003 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. 8.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. 8.1.1 Authentication Authentication is provided via the mechanisms defined in [RFC2409], based on Pre-Shared Keys (Public Key encryption could also be considered). 8.1.2 Confidentiality Confidentiality is achieved in Phase 1 through a Diffie-Hellman exchange that provides keying material, and through negotiation of encryption transforms. 8.1.3 Man-in-the-Middle Attack Protection FMKE relies on Phase 1 authentication to defeat man-in-the-middle attacks. 8.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. Duquerroy , et al. [Page 27] The Flat Multicast Key Exchange May, 2003 8.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. 8.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. As only the GCKS and the Group member know the SKEYID_a value, this provides message source authentication. 8.2.2 Confidentiality Confidentiality is provided by the Phase 1 security association, according to the manner described in [RFC2409]. 8.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. 8.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. 8.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. Duquerroy , et al. [Page 28] The Flat Multicast Key Exchange May, 2003 8.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. 8.3.2 Confidentiality Messages are encrypted with the symmetric encryption key and the encryption algorithm mentioned in the Re-key SA attributes. 8.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. 8.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.0 IANA Considerations 9.1 ISAKMP DOI A new ISAKMP DOI number needs to be assigned, in order to define FMKE. 9.2 Payload Types New ISAKMP Next Payload types need to be allocated for FMKE payload types. See Section 6.0 for the payloads defined in this document. Duquerroy , et al. [Page 29] The Flat Multicast Key Exchange May, 2003 9.3 New Name spaces The present document describes many new name spaces for use in the FMKE payloads. Those may be found in 6.0 and 7.0. 10.0 Acknowledgements 11.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. 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 October 2003. Duquerroy , et al. Expires October, 2003 [Page 30]