Summary:

Group communication systems are high-availability distributed systems
providing reliable and ordered message delivery, as well as a membership
service to group-oriented applications. Many such systems are built using a
distributed client-server architecture where a relatively small set of
servers share information about the groups in the system and provide service
to numerous clients.

In this paper, the authors are trying to show how group communication
systems can be enhanced with security services without sacrificing
robustness and performance.

The authors suggest that the minimal set of security services provided by
any group communication system should include client authentication, access
control, integrity and data source authentication, and confidentiality.

The paper discusses two general architectures for providing security for
group communication systems. First, a layered architecture, in which
security services are implemented in clients, and second an integrated
architecture, in which security services are implemented in servers.

The work presented in this paper is evolved from integrating security
services into Spread. Spread is a general purpose group communication system
for wide and local area networks. It provides reliable and ordered delivery
of messages, as well as membership service.

They propose a layered architecture and three integrated architectures for
securing Spread. The integrated architectures include a three-step
architecture, an architecture supporting virtual synchrony, and one
supporting extended virtual synchrony in an optimized fashion. In the
integrated architectures, a smaller number of servers run the expensive
distributed protocols, and in turn, serve numerous clients.

They present experimental results for the group key management and data
encryption parts on all their architecture variants in LAN and WAN settings.
In a nutshell, their experiments prove the superior scalability of the
integrated architectures.

In the end, the benefits and drawbacks of both types of architectures are
discussed. In brief, they conclude that the layered architecture has the
advantage that no trust is put into anything outside of the end-users
control, as well as being less complex and easier to develop. However its
major drawback is that it doesn't scale well. The integrated architectures
overcome the key management scalability problem by using the key agreement
to compute a secret key shared by the servers. Other advantages of
integrated architectures include ease of providing security services such as
client authentication and access control to perform group specific
operations.

Pros:
- Addresses a general set of group communication services
- Addresses performance concerns
- Does a great job defining and explaining acronyms
- Provides security solutions for higher-performance protocols (EVS)
- Guards against two types of attacks by non-members: eavesdropping and data
modification/fabrication.
- All messages are authenticated using digital signatures
- Protects both client-server and inter-server communications
- Costly key refreshes not necessary when group membership changes, only
when network connectivity does
- Supports EVS mode while also pushing most cryptographic burden to end
hosts
- Tradeoffs inherent in all alternative architectures are compared
- Can serve as a basic platform for end-to-end encrypted links

Cons:
- Not measuring performance for groups of large size
- Requires dedicated servers
- Lack of incentive
- (?) Sending the KeyId in clear text in (EVS)
- (?) Assumes every client has its own public key certificate
- They are not clear about their purpose in the introduction
- They have 13 computers and all the clients are located on those machines,
each running one server. So, the performance figures will be different with
the case were they are more distributed, but they don't talk about it.
- (?) Requiring synchronized clocks between servers
- DOS attacks on clients/servers (hard to avoid!)

Discussion:
Q) Lack of details about the control messages and handling failures.
A) Most of these details are in their previous papers. In this particular
paper, they only introduce architectures for "Securing" the already existing
GCSs, so it may not have been relevant to include all those details there.
Referred to the Cliques paper (reference 39 of the paper), and different
group key management algorithms (including TGDH).

Q) Everyone gets to know who is in the group.
A) True in the layered case, but in the client-server case, every server
gets to know the subset it is serving.

- Not clearly mention the application of their system (e.g. group
productivity software for a large company, or replicated servers?). In case
of the latter, group sizes of at most 100 that they talk about are fine, but
not for the former.

Votes:
We only asked for accept and reject, and everybody said accept (not 100%
sure honestly).