[Standards-JIG] Re: MUC and owner getting disconnected.

Jens Mikkelsen gyldenskjold at mail.dk
Thu Jan 13 21:46:18 UTC 2005


On Thu, 2005-01-13 at 22:23, Peter Saint-Andre wrote:
[...]
> > This is because I was working on an encrypted MU-C room. (It is finished
> > by the way). In the solution the server can be compromised, so it cannot
> > be trusted.
> > The encrypted MU-C work with symmetric encyption with one secret key
> > that all members share. To distribute the key asymmetric encryption is
> > used. Because the server isn't trusted, the owner keeps a local
> > memberlist, so he knows who he needs to distribute keys to. (If a member
> > i revoked a new key is send). If the key was distributed to all on the
> > memberlist on the server, an attacker could change the memberlist.
> > So if the owner were to leave the room, theres no local memberlist and
> > there cannot be any key negotiation. Hence the owner question. 
> > (2) is not handled on the server and cannot be, as there has to be a
> > local list.
> > 
> > I thought about this protocol, when implementing:
> > 1. An owner wants to leave the room.
> > 2. He sends the memberlist to another member encrypted either with the
> > symmetric key or the asymmetric key.
> > 3. Owner makes this member an owner.
> > 4. As members have to know who is the owner, owner broadcasts new owner.
> > (signed)
> > 5. Owner exits room.
> > 
> > This creates some practical problems though, so I went with the other
> > solution. Here the client exits the room if an owner exits the room.
> 
> Ah, that sounds interesting. :-)

Yes it has been. Unfortunally the documentation is in danish. But if you
have considerations about extending MU-C with encryption, I would be
glad to assist.

> 
> So what exactly happens if the owner leaves or his connection dies 
> (e.g., trips over a network cable)? To leave the room gracefully, it 
> seems that the owner would first destroy the room and then leave. But in 
> the ungraceful case, the other users would need to leave the room on 
> their own if the owner's server sends unavailable presence to the room 
> when it detects that the owner has gone offline. Or did you implement 
> some other solution?
> 

Well... When a owner adds a member, he sends the key directly to the
user he added and states the groupname. When the client receives the
first key, he sets the sender as owner of this room. This can be done,
because the key packet is signed by the owner. 
Now the member knows who the owner is, so if he was to receive an
'unavailable' packet for the owner he exits. If the 'unavailable' packet
is stopped, he can continue to talk in the room, but there can't be
added any members etc. Still it's not possible to evesdrop.
This means that an attacker can stop a groupchat, but the goal was not
to prevent this, but just to ensure that no evesdropping is possible.

-- 
Jens Mikkelsen <gyldenskjold at mail.dk>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20050113/8af1c301/attachment.sig>


More information about the Standards mailing list