Subject: [MSEC] Réf. : Re: [MSEC] Réf. : Re: [MSEC] Réf. : [MSEC] [Fwd: I-D ACTION: draft-duquer-fmke-00.txt]

From: [email-masked]
Date: Fri, 27 Jun 2003 15:56:22 +0200

Hi Brian,

Thanks a lot for your very interesting comments. You will find below the answers
to your questions.

Best regards,

Laurence
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

>Hi Laurence,

>Thanks for explaining a little more about FMKE. I have some questions
>below.

>[email-masked] wrote:
>>
>> Hi,
>>
>> Thank you for your interest.
>>
>> FMKE can be seen as an extension of the group key management protocols
defined
>> in MSEC (and more precisely of GDOI), which aims at providing  an optimized
>> scheme for satellite systems. Indeed, satellite based systems have specific
>> features which imply specific requirements :
>>           - bandwidth limitation, which implies overhead and signaling
>> information volume minimization.
>>           - High transmission delays
>>           - A flat architecture with a high number of satellite terminals
>> (senders and receivers) (for instance 60000 satellite terminals)
>>           - Need for reliable exchanges
>>
>> Thus, FMKE is designed to limit the number of messages exchanged between
group
>> members and GCKS. For instance the FMKE phase 2 is less resource consuming
than
>> the GDOI ?group key push?, as it requires less messages for an equal number
of
>> SAs to transmit.
>>
>> Moreover, on the contrary of the MSEC protocols, FMKE implements reliable key
>> distribution exchanges (multicast and unicast). Besides the reliability
>> mechanisms are optimized with regards to the bandwidth.

>I'm wondering if the Phase 3 messages are distributed along with the
>data traffic? For example, if a satellite terminal realizes that it has
>missed a Phase 3 message, will it have time to request a retransmission
>(by sending a NACK) before it needs to use the keys? If so, do you
>expect that it will need to store them until the messages is
>retransmitted? I don't know much about satellite terminals, so I was
>wondering if they sufficient memory to store a lot of packets.

Phase 3 messages are indeed distributed along with the data traffic.
In fact, when a new key has to be transmitted, the GCKS has to plan to send a
phase 3 message containing the key sufficiently early so that several
retransmissions can be realised (requested by group members) before group
members need the key (for instance before the old key expires). Thanks to these
retransmissions, all  satellite  terminals should receive the key in time.

>Also, I wonder if the GCKS would be able to handle very large numbers of
>NACKs? For example, if there is a wide scale problem and a large group
>of satellite terminals discovered that they had missed one or more Phase
>3 messages, they'd all send NACKs. If the GCKS has to spend a lot of
>time interpreting NACKs, the system won't be very efficient.

The GCKS should not handle very large numbers of NACKs. Indeed, when a satellite
terminal determines that one message is missing, it waits a pre-determined time
before sending its NACK. The waiting time varies for each satellite terminal,
and follows a pre-calculated distribution, based on link budgets and physical
satellite terminal location, optimised to avoid massive NACK emission in case of
packet loss, and congestion at GCKS side : thus few satellite terminals will be
authorised to send a NACK at the beginning, and it is expected that these
messages will be sufficient so that all satellite terminals receive the GCKS
messages. We avoid therefore that all Group members which have not received a
message send a NACK message.
The figure below represents a possible distribution of the waiting time.

       | % of group members
 100|                                      .     .     .
      |                                .
      |                                            .
      |                     .
      |                   .
      |                              .
      |                           .
      |      .    .     .    .
    0|________________________________________________
                                    waiting time

>> Another difference is that in the context of satellite systems, satellite
>> terminals (= group members) have to protect traffic that they do not generate
>> themselves (they are generated by user equipment behind satellite terminals).
So
>> they know very few information about it. It is therefore more adapted that
they
>> receive directly data SAs from the GCKS for the traffic they have to protect,
>> instead of requesting them. In FMKE they receive directly all the SAs they
are
>> authorized to get access to, belonging to one or several groups, without
having
>> to send a request.

>The GDOI protocol allows a wide variety of usage models. In the
>satellite setting, a GDOI group member can also directly receive data
>SAs from the GCKS for the traffic they have to protect. A satellite
>terminal would not need to know very much information -- only the
>"group" identifier that it sends in the GDOI registration ("Phase 2")
>protocol. In a satellite environment, I would expect the group
>identifier to represent a set of channels, or some other collection of
>services. This is used by the GDOI GCKS to check authorization of the
>group member, to ensure that it actually does belong to the group. Once
>authorized, the GCKS would return just the KEK for the group. The group
>member would then listen for multicasted rekey messages (what you call
>"Phase 3" messages) protected by that KEK. When it receives rekey
>messages, it then becomes aware of what traffic it needs to protect. In
>this manner, I believe that a GDOI group member can also directly
>receive data SAs from the GCKS for the traffic they have to protect.

>It occurs to me that the GCKS could choose to ignore the group ID if it
>has a different method of deciding to which group the satellite terminal
>belongs. The GCKS would send the appropriate KEK to the satellite
>terminal just as before, and the process would be exactly the same. But
>in this way the satellite terminal wouldn't have to know anything at all
>beforehand, and the registration messages would be relatively
>low-bandwidth messages.

>I hope this explanation makes sense. If not, please let me know.

>Thanks,
>Brian

I agree with your explanation. Your scenario indeed implies low bandwidth
messages, and as explained in your mail, the knowledge of the Group ID by
satellite terminal is no more an issue. In fact FMKE can be seen as a use case
(and as an extension) of GDOI, particularly for this scenario where FMKE
provides similar message exchanges. The only main difference between FMKE and
GDOI is the reliability of the FMKE Phase 3 ( = the GDOI "Group key push").
The scenario where the satellite terminal is entirely configured in unicast ,
that is to say where it directly receives all Data-SAs and Re-key SA during the
FMKE phase 2,  could also be requested for some cases (the phase 3 would then be
used only to update the security configurations of the satellite terminals).
In that case FMKE is more optimized with regards to the bandwidth consumption.

>> Don't hesitate to contact us if you want further clarification or information
>> Best regards,
>>
>> Laurence Duquerroy
>

> > 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-00.txt
> >      Pages          : 30
> >      Date      : 2003-6-17
> >
> > 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.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-duquer-fmke-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >      "get draft-duquer-fmke-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >      [email-masked].
> > In the body type:
> >      "FILE /internet-drafts/draft-duquer-fmke-00.txt".
> >
> > NOTE:     The mail server at ietf.org can return the document in
> >      MIME-encoded form by using the "mpack" utility.  To use this
> >      feature, insert the command "ENCODING mime" before the "FILE"
> >      command.  To decode the response(s), you will need "munpack" or
> >      a MIME-compliant mail reader.  Different MIME-compliant mail readers
> >      exhibit different behavior, especially when dealing with
> >      "multipart" MIME messages (i.e. documents which have been split
> >      up into multiple messages), so check your local documentation on
> >      how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> >
> >
> > _______________________________________________
> > msec mailing list
> > [email-masked]
> > http://www.pairlist.net/mailman/listinfo/msec
> >
> >
> >
> >
> > 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]
>
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec
>
> 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]
>
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec

--
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

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]

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

---

From: Mark Baugher <[email-masked]>
Date: Fri, 27 Jun 2003 08:13:35 -0700

Laurence,
   We discussed putting reliability mechanisms into GDOI about three years 
ago.  The decision of the secure multicast research group (SMuG) at that 
time was to use the mechanisms that are being developed by another group, 
the reliable multicast group, rather than develop our own.  MSEC has also 
taken this approach.

   So, before we incorporate reliable multicast into an MSEC key management 
protocol, we need to revisit this decision and discuss the pro's and con's 
of having an ACK or NAK mechanism built into key management versus using a 
separate layer.  The advantage that I see of using a separate layer is what 
one generally gets from design modularity:  We can choose among the best 
mechanisms for a particular application.  As new reliable multicast 
protocols and algorithms are developed, these can be used by the key 
management protocol without the need to change the specification of the key 
management protocol.

   Now, what are the advantages to mixing up reliable multicast with key 
establishment?

   Finally, I don't see any difference between your Phase 3 and the MSEC 
Rekey protocol (called "groupkey push" in GDOI).  Are there significant 
differences?  I think the similarities in the protocols favor Ran's 
suggestion of including this work with the GDOIv2 effort that MSEC is 
likely to begin.

Mark