[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new/pending/delayed work items
I agree with Dan and Ran that extending IPSEC to deal with multicast is
an important work item. I strongly support forming a separate
working group for secure multicast. It is certainly a wide, important,
and unsolved enough work item.
To demonstrate the complexity of secure multicast (and to invoke some
thought :), let me list a number of questions that have to be
answered in the design process. These questions will greatly affect how the
solution/s will look like, both from cryptographic and systemic points of
view. (The list is just a random sample, there are many more issues.)
1. Do we want to have a "multicast group center" with cryptographic
capabilities? Do we want/expect the group members to trust this center?
Alternatively, do we want that the trust be distributed among
several entities?
2. Do we want group access control? If so, who will run it?
3. Do we want the group members to be able to verify the identity
of the source of a message? Or is it enough that
we know that the message was sent from some group-member?
4. Do we want groups where only one member can authenticate/encrypt
its messages and the others can only verify/decrypt?
5. Do we want to trust the group members to keep their keys secret?
If we don't, then do we want the group members (or the group center)
to be able to detect the source of a leakage?
6. Do we want the routers to take part in the cryptographic responsibilities
of multicast (since they have multicast group information anyway),
or do we want only group-members to deal with that?
Also, do we want dedicated servers?
I suspect that we will eventually want several types of multicast groups,
characterized by different sets of answers to the above questions
(as well as many others). A first goal of a secure multicast
working group should be to prioritize, and settle on one (or a small
number of) multicast group types to start working on.
Ran Canetti
Ran
BTW, I also support forming a dedicated group for secure multicast.
It is certainly a wide, important, and unsolved enough work item.