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 16:00:57 +0200

Hi Ran,

Indeed it could be a good idea. As explained in my last mail to the MSEC mailing
list, FMKE could be considered as a use case or an extension of GDOI , with some
additional features.
We are going to precisely identify these additional features, and maybe we can
discuss this at the next MSEC meeting .

Best regards,

Laurence Duquerroy

canetti <[email-masked]> on 27/06/2003 08:03:12

Pour :    Brian Weis <[email-masked]>
cc :  [email-masked]
      Lakshminath Dondeti <[email-masked]>
      [email-masked]
      [email-masked] (ccc : Laurence Duquerroy/ALCATEL-SPACE)
Objet :   Re: [MSEC] Réf. : Re: [MSEC]  Réf. : [MSEC] [Fwd: I-D ACTION:
      draft-duquer-fmke-00.txt]

Laurence,

It would be *very* nice if we could avoid having yet another key
management protocol in addition to the ones we have (GDOI,MIKEY,GSAKMP).
One way to try to do that is to get involved in the design of GDOIv2
(the new version of GDOI that will be based on IKEv2) and make sure that
the end product satisfies your needs. This effort is under way, or at
least so I understand; Brian Weis is a good contact.

Best,

Ran

On Mon, 23 Jun 2003, Brian Weis wrote:

> 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.
>
> 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.
>
>
> > 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
>
>
> > Don't hesitate to contact us if you want further clarification or
information
> >
> > Best regards,
> >
> > Laurence Duquerroy
> >
> > Lakshminath Dondeti <[email-masked]> on 19/06/2003 14:48:16
> >
> > Pour :    [email-masked]
> > cc :  [email-masked]
> >       [email-masked] (ccc : Laurence
Duquerroy/ALCATEL-SPACE)
> > Objet :   Re: [MSEC] Réf. : [MSEC] [Fwd: I-D
ACTION:draft-duquer-fmke-00.txt]
> >
> > Hi,
> >
> > Many thanks for your email.  I was wondering about the motivation for
> > yet another protocol for group key management.  We have too many already.
> >
> > Could you explain how FMKE is different from GDOI, GKMP, GSAKMP-classic,
> > GSAKMP and MIKEY, and the requirements that motivate the need for FMKE?
> >
> > regards,
> > Lakshminath
> >
> > [email-masked] wrote:
> > >
> > > Hi all,
> > >
> > > In  the context of the SatIP6 IST project, Alcatel Space studies a
multicast
> > > security scheme optimised to protect large multicast groups. Such a scheme
is
> > > designed for IP over Satellite, Wifi or DVB systems; it is a security
solution
> > > for the satellite segment. An implementation over DVB-S/RCS is planned in
the
> > > SatIP6 demonstrator.
> > >
> > > We have started to write an Internet Draft detailing our key exchange
protocol
> > > (called "Flat Multicast Key Exchange (FMKE)"), and we thought that it
could be
> > > submitted to the MSEC Working Group (In fact, we thought it was too late
to
> > > submit it  for the next IETF meeting.)
> > >
> > > We would be ready to present it to the next MSEC Working Group meeting at
> > IETF57
> > > in Vienna.
> > >
> > > This solution is designed to provide a security solution optimized for
> > satellite
> > > systems. It is defined to be low ressource consuming in bandwidth, to
provide
> > a
> > > reliable key distribution, to be used in one-to-many and many-to-many
> > scenarios,
> > > and to be scalable in these scenarios...
> > >
> > > We hope that you will find interest in it, and thank you in advance for
your
> > > comments and questions.
> > >
> > > Our e-mail addresses are :
> > > [email-masked]
> > > [email-masked]
> > >
> > >
> > > Best regards,
> > >
> > > Laurence Duquerroy
> > > Sébastien Josset
> > >
> > >
> > >
> > >
> > >
> > > Lakshminath Dondeti <[email-masked]> on 18/06/2003 20:11:54
> > >
> > > Pour :    [email-masked]
> > > cc :   (ccc : Laurence Duquerroy/ALCATEL-SPACE)
> > > Objet :   [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt]
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > Hi all,
> > >
> > > I forwarded this new I-D announcement from IETF-Announce to a small
> > > group of MSEC regulars and no one was aware of it.  Assuming that others
> > > haven't seen it either, here it is on Thomas's request.
> > >
> > > Could the authors (if they see this) please send their email addresses
> > > to the group (not in I-D)?  I have some questions on the I-D. Thanks.
> > >
> > > regards,
> > > Lakshminath
> > >
> > > -------- Original Message --------
> > > Subject: I-D ACTION:draft-duquer-fmke-00.txt
> > > Date: Wed, 18 Jun 2003 07:52:40 -0400
> > > From: [email-masked]
> > > Reply-To: [email-masked]
> > > To: IETF-Announce: ;
> > >
> > > 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]
>
> _______________________________________________
> 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