[1]:
- Provides a rigorous definition of join/leave methods and key generation
in the context of a binary tree architecture.
- Assumes the availability of a PKI.
- An excellent paper to implement in the case of distributed group management
function.
[2]:
- Assumes PKI.
- Central group authority and group controller
- Suggests scheme for multicast emulation if it is not available (which
it generally isn't)
- Rekey done periodically and in response to joins
- Nice resource because it gives concrete examples of header implementations
and message formats.
[3]:
- CBT accounting method.
- Distributed key multicasting.
- Necessitates CBT multicasting protocol support (which is non-existent)
- Claims a more simplified approach when compared to GKMP; a more distributed
approach
- Details the join procedure, but not the leave procedure.
[4]:
- Provides some well-thought guidelines against which to check various proposed
security architectures.
- Point out some drawbacks of key trees on pg 12.
[5]:
- Contains enhancements to their first paper, [6], including definition of
the transitions between Tree, Centralized Flat, and Distributed Flat methods
- Not within the scope of this project.
[6]:
- Assumes Reliable IP Multicast support (or else soft-state approach).
- Perfect forward secrecy; no 3rd party group key manager.
- Provides 3 schemes (centralized, c-flat, and distributed-flat).
- Join and leave operations described in sufficient detail to implement them
in all schemes.
- Nice idea with the key revision to avoid some key distribution during joins.
- Intuitive proofs of forward and backward secrecy provided.
[7]:
- Again uses binary trees for key management.
- Aims at making joins and leaves more efficient in terms of number of messages
sent.
- Perhaps implement as an optimization.
- Strictly a theoretical paper, no implementation presented.
[8]:
- Another summary of principles suggested for group security, similar to RFC
1949, but with more abstract terminology
- Doesn't really add anything to the discussion at this point.
- Nice list of desired properties.
[9]:
- Rigorous proofs/definitions for both a centralized and distributed approach.
- Instead of a physical key manager its proposal is a cooperative approach
to maintaining a complete key graph.
- Has been implemented and tested, but the steps to get there are not as clear
here as in other papers.
[10]:
- For curiosity only, is out of the scope of this project.
[11]:
- Commercial offering
- Uses "trusted" third party: the SCIM server through which messages initially
pass
- Connect to the server using RSA, send TEK with this public information,
then optionally set up P2P TEK to bypass the server.
[12]:
- Interesting early paper, but proposes to implement security functions at
the network layer instead of the application layer. Therefore it is
clearly not applicable to this project.