[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Réf. : Re: Réf. : Re: "Flat Multicast Key Exchange (FMKE)" -Internet Draft
Hi Haitham ,
Thanks again for your comments. You will find below the answers to your
questions.
FYI, FMKE will be presented at the next IETF MSEC working group meeting in
Vienna ( in July) (but the I-D is still an independent I-D)
Best regards,
Laurence
>Hi again Laurence,
>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.
Indeed, by MESH topology, we mean mesh satellite systems 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.
Indeed FMKE an LKH are different things :
* FMKE is a group key distribution protocol, which can be used to distribute any
types of keys :
- keys from a flat key system (i.e. 1 KEK and TEKs shared by all group
members)
- keys from a hierarchical key system (i.e. LKH)
* LKH is an algorithm which defines how to build a key tree, which keys in the
tree have to be renewed when a group member leaves the group, which the order of
the distribution of these keys is and how they have to be renewed (keys to use
to encrypt them, transmission in multicast or unicast ?...). This system is very
useful for large and highly dynamic groups.
Thus FMKE can be used to distribute keys from a key tree. We have for a group no
more a single KEK, but a set of KEKs (KEK array) which is different for each
Group member, and TEKs which are the root of the tree and which are shared by
all group members.
The name of the protocol "Flat multicast key exchange" is maybe confusing. It
does not mean that we address flat key system, but that the protocol is destined
to "Flat environment",that is to say that it allows to flexibly set up large
secure multicast networks in flat environment (no intermediate routers between
the GCKS and a large amount of group members).
>>
>> 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
>> 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.
For a flat key system, if only TEKs have to be renewed, this can be done in
multicast by using the FMKE Phase 3 messages (transmission is protected by the
Re-key SA (KEK)).
For a key tree architecture,we determine the KEKs of the KEK array to use ( I
think they are the two keys which are just under the root) and we use them to
send the TEKs in multicast( by using the FMKE phase 3).
For a flat key system, if TEKs and the KEK are compromised or if a member leaves
the group, we have to renew KEK and TEKs. A solution is to distribute the new
KEK in unicast to all remaining group members by using the FMKE phase 2
exchange, and then to distribute the new TEKs in multicast by using Phase 3
messages (encrypted with the new KEK of the Re-key SA).
For a key tree architecture, if a member leaves a group or if TEKs and some of
the KEKs are compromised, we determine with the LKH algorithm which keys of the
tree have to be changed, the order of the distribution of these keys, and how
they have to be renewed (in multicast or in unicast? Encrypted with which other
KEK?). We use then FMKE phase 2 and Phase 3 exchanges to achieve it.
This solution needs less messages than the solution for the flat key system.
>> >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
>>> >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/
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