Re: Réf. : Re: "Flat Multicast Key Exchange (FMKE)" -Internet Draft

[Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>]

Hi again Luarence,

Many thanks for your detailed reply.  I am very pleased that you have produced such
detailed work and most of your comments are OK.

However to keep the discussions going in ip-dvb mailing list, see my comments
inline:

Laurence.Duquerroy@space.alcatel.fr wrote:

> Dear  Haitham,
>
> Thank you very much for your comments. They will help me to improve the draft.
> Please find in the following the answers to your questions.
>
> >Dear Laurence
>
> >Sorry for the delay in my reply.  I read your proposed Internet Draft "Flat
> >Multicast Key Exchange (FMKE)" and I have the following comments:
>
> >1. Fundamental question:  I remember your presentation at the ESTEC workshop
> "IP
> >networking over satellites" few weeks ago.  I remember that you said that this
> >solution will be implemented in the link level (for example DVB-S link level).
> >That is something is not clear in my mind yet, because your proposal is IPSEC
> >based.
>
> In this solution, the control plane (i.e. the Flat Multicast Key Exchange) and
> the dataplane (functions encrypting and authenticating data) are separated.
> FMKE is indeed implemented in the layer 3 over IP, as it is based on ISAKMP,
> like IKE.
> In fact, this is the dataplane which can be implemented at link level (or in
> layer 3). My presentation at the ESTEC workshop dealed with a security dataplane
> implemented into the IP dedicated protocol.

It is very good to separate security control and data planes.  Between University of
Surrey and Logica (UK) in the ESA project, we have a full implementation GSAKMP
which is another security  framework for managing group communications.  We think of
GSAKMP as an application that produces keys that can be used in the data plane
(network level: IPSEC ESP or AH modes ; or link level: such as DVB-S link level).
So your idea is good to separate control and data planes.

>
>
> However, we envisage to define a security solution (control plane + dataplane)
> fully implemented at the link level, based on the DVB-RCS security messages
> (probably by re-using some of them and adding some messages based on the FMKE
> ones).
>
> > One more point, your Internet draft does not mention satellites.  May be you
> can
> > clarify this.
>
> The draft is indeed very general.
>
> The objective of this security solution is to secure the  satellite segment.The
> FMKE mechanims are implemented at the satellite terminal level. We can consider
> them as a module, which may  be directly implemented inside the stack of each
> satellite terminal, or  may be implemented in a separate box, located behind
> each ST.
>
> In the ID, a group member is therefore a satellite terminal (or the box behind),
> and the GCKS a server implemented for instance in a gateway.
> All FMKE messages are therefore exchanged on satellite links.
>
> This solution is able to establish in an optimized manner secure communication
> groups in Star and mesh architectures
>
> >By the way, ALCATEL ASP has a project with ESA on DVB-RCS security for
> >multicast and also University of Surrey and ALCATEL ASP have some documentation
> in
> >the GEOCAST project on how to modify DVB-RCS current security to cater for
> >multicast.
>
> The project that ALCATEL ASP has on DVB-RCS security, and security documentation
> of the GEOCAST project, define security mechanisms for star architectures. Some
> security features are missing to use them in MESH topology.

In my opinion, the MESH topology can only work effectively with satellite OBP.

>
> With FMKE, we look at a more long-term solution, which would provide an
> optimized security in STAR systems and in MESH systems (for one-to-many and
> many-to-many communications).
> Moreover, we define some supplementary and useful mechanisms (like multicast
> configuration and re-keying ...)
>
> >2.  As I understand that you will present your draft at the MSEC group at the
> IETF
> >meeting in Vienna.  Your proposal looks fairly similar to The Group Domain of
> >Interpretation (GDOI) and latest draft is draft-ietf-msec-gdoi-08.txt  (see:
> >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-08.txt), which is well
> >established and going to be an RFC soon.  Your work is duplicating GDOI and
> adding
> >phase 3 which does not exist in GDOI.  In fact, GDOI has flat key and LKH (tree
> >architecture) distribution mechanisms.  Can you clarify the differences between
> > FMKE and GDOI.
>
> FMKE and GDOI are based on similar principles. Both are based on a centralized
> management achieved by the GCKS, on 3 different exchanges or phases which have
> similar objectives, on similar security levels, on similar key system (KEKs and
> TEKs, and we intend to use LKH ).

I disagree here with you, FMKE and LKH are two different things: Flay key and tree
architecture (LKH) are not the same.  Flat key system is good for groups with low
volatility (groups with low rate of joins and leaves). LKH is more efficient  for
highly dynamic groups.

>
> However FMKE is designed to provide a solution more adapted to our context.
>
> * First of all, the main difference  between the GDOI "Group Key pull" exchange
> and the FMKE phase 2 concerns the initiator of the exchange. In GDOI, the phase
> is initiated by the potential Group Member (GM), and in FMKE by the GCKS.
> In the GDOI "Group key pull" exchange, the GM has to initiate the exchange in
> order to request the access to a particular group. It receives the SAs
> associated to this group if it is authorized. This exchange is realised several
> times, each time the GM decides to join another group.
> As the initiator is the GM, checking its liveliness is required. Indeed, as this
> exchange can be realised several times , a replay attack can easily be launched.
> This requirement implies that the exchange is composed of 4 messages ( the 3rd
> msg allows to prove the GM liveliness, and in the 4th message the group keys are
> transmitted).
>
> In FMKE the exchange is initiated by the GCKS. It transmits during this exchange
> all the SAs the member is authorized to get access to, belonging to one or
> several groups. The Client just has to send periodically acknowledgement
> messages in response.
> This phase is launched once; at the end of the first phase.
> Moreover,as only one phase 2 is realised and is initiated by the GCKS, verifying
> the client liveliness is not needed ( does not require the messages used in the
> Group key push)
>
> Therefore FMKE phase 2 is less resource consuming than GDOI "Group Key push", as
> it requires less messages for an equal number of SAs to transmit (for one group
> , GDOI requires 4 messages , whereas in FMKE the GCKS sends a message with the
> SAs, and waits for a periodic acknowledgement of the GM)
>
> * GDOI requires that group members know specific information and own specific
> functionality to be able to request the SAs of the groups they wish to join. On
> the contrary, 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. With the attributes contain in the SA payloads, they know which traffic
> flows they have to protect (for instance identified by a multicast destination
> address, a layer 2 label, a PID) .
> In the context considered by FMKE, satellite terminals have to protect traffic
> that they do not generate themselves. So they know very few information about
> it. Thus, it seems more adapted that they receive directly the data security
> configurations for the traffic they have to protect, instead of requesting them.
>
> * GDOI exchanges ("Group Key Pull" and "Group Key Push") are not reliable.
> Nothing guarantees that the GM(s) has(have) received the group keys transmitted
> by the GCKS.
> On the contrary, in FMKE, during the phase 2, each message from the GCKS has to
> be acknowledged by the GM, and is retransmitted if it is not acknowledged. In
> the phase 3, GMs can request the non received messages (this mechanism is
> optimized in order to avoid the congestion at the GCKS)

I have one more question:  How does the GCKS distribute new traffic keys (TEK) to
existing members in cases such as period rekeying (to stop cryptoanalysts) or if the
current data key is compromised (broken).  Thanks.

>
>
> >3. In section 8 (security consideration), you should state the remaining or
> >potential problems with your protocol.  One example is Denial of Service (DoS)
> >attacks, where you should state how your protocol and your security server can
> >cope with thousands of forged messages coming from false IP addresses. One
> >common practice is to use stateless COOKIES in order to minimize the memory
> >and CPU burden on the security server which is experiencing the DoS attack
> >(for more details see:
> >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-07.txt).
>
> Thank you, I am going to check the remaining attacks and add the necessary
> information

Especially DoS attacks.

Thanks again
Haitham

>
>
> >Please consider these as constructive comments and I hope they will improve
> your
> >draft.
> >Regards
> >Haitham
>
> Best regards,
>
> Laurence Duquerroy
>
> 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 : laurence.duquerroy@space.alcatel.fr

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/