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

[Laurence.Duquerroy@space.alcatel.fr]

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.

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



>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


>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