Subject: [MSEC] new Internet draft : use case of GDOI

From: [email-masked]
Date: Thu, 16 Sep 2004 09:23:20 +0200

Hello all,

You will find below  the announcement for the new version of an internet
draft whose last version was
presented  to the group last year, at the Vienna meeting, in July 2003
(sorry for the long delay!) .

The protocol described in this draft is entitled "Flat Multicast Key
Exchange". It is destined to be a use case of GDOI adapted for satellite
networks.
It is defined to be low ressource consuming in bandwidth, to be used in any
satellite networks topologies and to implement a reliable key distribution

Taking into account the comments we received , the draft has been updated
in order to present FMKE as a use case of GDOI and to underline the
differences between both protocols (for the time being , we have not
changed the name of the protocol, but it could be relevant to do so).

The draft has been submitted to the IETF secretariat as an individual draft
related to no group. We hope that you will find interest in it, and that it
can be officially submitted  as a MSEC draft afterwards.  We thank you in
advance for your comments and questions.

Best regards,

Laurence Duquerroy
Sebastien Josset

ALCATEL SPACE
RT/ST
Research Department / Advanced Telecom Satellite Systems
Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
E-Mail : [email-masked]

- - - - - - -  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -  - - - - - - - - - - - - - - - - - - - - - - - - - - -
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

      Title       : The Flat Multicast Key Exchange protocol
      Author(s)   : L. Duquerroy, S. Josset
      Filename    : draft-duquer-fmke-01.txt
      Pages       : 38
      Date        : 2004-9-15

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-duquer-fmke-01.txt

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Fri, 17 Sep 2004 09:53:54 -0700

hi Laurence, Sebastien,
    I have a few questions and comments.

1. The first figure shows two cases but there are three:  
star-bidirectional, star-unidirectional, and mesh.  Do I understand 
this correctly?  (It would be helpful to label the figure).

2. I don't understand a sentence on page 5: "Unlike GDOI, this phase 
takes place once, after the Phase 1."  The phase 2, which I think 
you're describing always takes place after phase 1.  After reading this 
paragraph a few times, it seems that you are defining a new phase 2 
pull exchange that allows more than one group to be specified in an ID 
payload so that all groups can be downloaded in one exchange (not 
necessarily in one message because of MTU and fragmentation issues).  
Do I understand this correctly?

3. Also on page 5, the innovation introduced to GDOI is to add a 
reliability mechanism to the groupkey-push message is it not?

4. On page 6 you discuss the phase 1 but not how the phase 1 is 
established in the star-unidirectional case.  Is this an oversight?  A 
forward reference to 6.1 would help here.

5. On page 6, the phase 2 is initiated by the GCKS.  What causes the 
GCKS to initiate this message?  I assume that the first GCKS message is 
sent exactly twice?

6.  How are groups identified in the new phase 2?  I don't see the ID 
payload.

7. On page 7, the SEQ is redefined to apply to the groupkey-pull and 
not the groupkey-push, if I understand this correctly.  I think it 
would be better not to reuse the name for such a different purpose, 
which I don't yet understand.  Don't we need a SEQ for the original 
purpose of ordering pushed messages?

8. On page 10, it appears that the SEQ is used in the phase 3 so I'm 
confused.  I also don't immediately grasp why the LSEQ is needed since 
the SEQ performs an LSEQ function, or so it seems.

9. On page 10 there is also a push message that originates from the 
member.  GDOI reuses the phase 2 for this purpose or a similar purpose. 
  Why not use the GDOI phase 2?

10. On page 13, section 6.1 should be referenced earlier when the 
star-unidirectional topology is described.

11. I'm not sure why the manual configuration of phase 1 SAs cannot 
obviate the need to modify the phase 2 into a push.  In the original 
GDOI design, I thought that the groupkey-push, what you call the phase 
3, would be all that is needed for one-way systems.

12. On page 14, it seems odd to have to modify a pushed message because 
there is no backchannel, since the objective of the push message is to 
operate without a backchannel.  I'm not sure what role the LSEQ plays 
when there is no backchannel:  Why not just send the complete message, 
let the SEQ perform the function of the LSEQ, and send the needed 
payloads in the message?

13. Page 15 states that the SEQ is used but does not mention that it 
was redefined as stated earlier in the document.  Also, the list of 
GDOI payloads used is incomplete, isn't it?  What happened to POP?

At this point, I am skipping the details of the payloads to ask a 
question:  Would it be possible to modify GDOI as it is without 
developing a new DOI?  I'm sure that there are features missing in GDOI 
for broadcast and for unidirectional networks.  We talked a lot about 
adding reliability mechanisms into GDOI and that's a big topic.  There 
are a number of different reliable multicast algorithms to choose from 
and a "chicken and egg problem" since GDOI is needed to establish keys 
to protect reliable multicast systems.  Speaking strictly for myself, I 
wanted to defer the issue until we had a real system with real experts 
to help.  And here you are.

My first choice would be to try to minimize the fmke changes and fold 
them into GDOI, publish a new version of GDOI, and cycle on Proposed 
Standard.  The advantage to doing this is that fmke can then benefit 
more directly to bug fixes (such as the POP problem that Catherine and 
her co-author identified), new features (possibly such as sibling SAs), 
and general improvements.  If fmke is incorporated into GDOI, then 
these things don't need to be done twice.

It might be the case that it's too complicated to try and handle two 
different scenaria in a single protocol, and we'll want to separate 
them.  But 2/3 of your topologies are topologies that GDOI is supposed 
to handle but needs added functionality for reliable multicast.  I 
personally expected that we would need to introduce changes for this.

Mark