Internet Engineering Task Force L. Duquerroy
INTERNET-DRAFT S.Josset
Expires: February, 2005
September, 2004
The Flat Multicast Key Exchange protocol
<draft-duquer-fmke-01.txt>
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
Sbastien 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