Fwd: [Spread-users] Secure Spread problem

Cristina Nita-Rotaru crisn at cnds.jhu.edu
Wed May 16 12:42:22 EDT 2001


>



>
> ===8<==============Original message text===============
> Hi,
>
> What if a normal user(attacker) Eve tries to join the secure group, assume Spread daemons are accessible by Eve, Eve knows the address of those Spread daemons, and even the group name those secure members are joining?
>
> I made a test using the demo program "user" provided by SSP 1.0.0. One group with secure group communication was setup successfully. However, when I use another demo program "user" provided by Spread-1.14 to connect this secure group, following events happened:
>

I assume that by 'user' provided by Spread-1.14, you mean the user program that comes with the
Spread distribution 3.14 or upper.  It is correct that it blocks.

Now an explanation of what's going on:  Secure Spread uses for communication the Flush library
that will not change the group till not everybody agreeds with that (by sending Flush OK).

Anybody that is not playing the protocol can block it. Also, securitywise nothing gets broken
if you mix different layers (Secure Spread and Spread in your case), but the protocol will block
because they don't speak the same language.

For instance in the case that you described when the user of Spread, joined, the Flush library
started to change the membership (that's why everybody got the flush request), but all the
members need to answer it. The only one that does not need to answer it is the guy that joined.
So Flush chahnges the group (by delivering a membership message to Secure Spread), Secure
Spread starts the key agreement. Because the key agreement we used is contributory, everybody
must take part of it, but the Spread user does not know anything about it, is like having people talking
different languages to agree on something.

This is a form of denial of service that we did not address yet. Practically to solve this problem you
need a protocol that will have progress and eventually finish even in cases when participants can lie
or just refuse to play the protocol.


-- Cristina



-- Cristina




> 1. Eve got all those member names in the secure group;
> 2. Each secure member received a FLUSH_REQ message;
> 3. Even after sending flush ok to the group, all secure members got stuck.
>
> Any comments?
>
> BTW, lots of thanks for Jonathan's comments of spread configuration problem.
>
> Yiqiang
>
> ===8<===========End of original message text===========
>
>   ------------------------------------------------------------------------
>                     Name: message.shtml
>    message.shtml    Type: Hypertext Markup Language (text/html)
>                 Encoding: quoted-printable






More information about the Spread-users mailing list