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

From: [email-masked]
Date: Fri, 20 Jun 2003 14:57:16 +0200

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.

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.

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

---

From: Brian Weis <[email-masked]>
Date: Mon, 23 Jun 2003 15:43:32 -0700

Hi Laurence,

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

> 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.

> authorized to get access to, belonging to one or several groups, without having

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

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

---

From: canetti <[email-masked]>
Date: Fri, 27 Jun 2003 02:03:12 -0400 (EDT)

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