Design of authentication protocol (AUTH)
========================================

Author: Roland Raez, Bela Ban, Chris Mills
Version: $Id: AUTH.txt,v 1.1 2005/11/07 08:15:36 belaban Exp $

Goal: to prevent random members from joining a group. Members have to pass authentication
to join a group, otherwise they will be rejected

[pasted from Roland's email]

Recently I discussed with Bela Ban about a new Protocol called AUTH to
authenticate the joining of members.

I would like to implement this protocol. Here are my thoughts.

AUTH is the next layer under pbcast.GMS.  When pbcast.GMS sends a join
request (a GMS.GmsHeader.JOIN_REQ  header) AUTH just places the credential
for the authentication in its own header. The join message will be sent to
the coordinator and before the join will reach the GMS protocol the AUTH
protocol checks the auth header. When the header authenticated successfully,
it just passes up the join request and pbcast.GMS will accept the join and
sends the header GMS.GmsHeader.JOIN_RSP containing a pbcast.JoinRsp back.
When the authentication is not successful the AUTH protocol answers the
GMS.GmsHeader.JOIN_REQ itself and sends back a GMS.GmsHeader.JOIN_RSP
containing a pbcast.JoinRsp object with an error message.

The pbcast.ClientGmsImpl receives in both cases the GMS.GmsHeader.JOIN_RSP.
In the case where the join request could not be successfully authenticated
the message in pbcast.JoinRsp can be used to throw a RuntimeException.

Requirements for other Protocols:
 - pbcast.JoinRsp needs a new attribute (String), e.g. errorMsg
 - pbcast.ClientGmsImpl should use the attribute defined above and throw an
exception when there was an error.
 - Optionally ENCRYPT can be extended so that AUTH provides the symmetric
key

I think it would be fine when AUTH supports two authentication methods:

Token:
A simple token (String) based authentication using a configured String or a
String read from an external file which can be protected so that only
certain proceses can read the credential. Each member in the group needs to
have the same token else the authentication will not succeed:

 1. AUTH sends along with the GMS.GmsHeader.JOIN_REQ the hash of the
credential including its address (each address will produce another hash).
 2. The coordinator compares it's own hash with the one from the client.
When they match the JOIN_REQ is passed up, else negative JOIN_RSP (with
errorMsg set) is sent back (--> no further steps).
 3. Along with the positive response JOIN_RSP from the GMS protocol the
coordinator sends the hash of the credential including its address.
 4. The client verifies the hash of the coordinator. When the verification
is ok, he passes up the JOIN_RSP else he sends down a LEAVE_REQ.
Should the following LEAVE_RSP be discarded by the AUTH protocol layer?

Certificate:
Implementing Certificate based authentication is more secure because
spoofing IP addresses doesn't impact the security when additional message
encryption is used. I think that it is a requirement that each member in the
group can have the same certificate.
The following algorithm allows the usage of the same certificate for each
member in the group.



 1. The joiner (GMS client) sends with the JOIN_REQ message its certificate
and a nonce.
 2. The coordinator verifies if he trusts the certificate of the client by
checking the certificate chain. The authentication of the joiner is
performed in a later step! When he does not trust, he sends back a negative
GMS.GmsHeader.JOIN_RSP (--> no further steps).
 3. The coordinator create a AUTH.REQ message containing its certificate,
the nonce from the joiner encrypted with the private key of its certificate
and a new nonce
 4. The joiner verifies if he trusts the server by verifying the message
(decrypts the nonce with the public key from the coordinator (retrieved from
the certificate)) and optionally by checking the certificate chain. When the
verification is ok, he creates an AUTH.RSP message containing the nonce from
the coordinator encrypted with the private key of the joiner. When the
verification is not successful AUTH.RSP message containing an error message.
 5. The coordinator verifies the AUTH.RSP message. When it contains an error
message a negative JOIN_RSP is sent down else the joiner is authenticated by
decrypting the nonce with the public key of the joiner. When this is ok a
JOIN_REQ is sent up to GMS else a negative JOIN_RSP is sent down.
 6. The GMS protocols answers with a JOIN_RSP. When ENCRYPT and AUTH work
together the AUTH protocol or the ENCRYPT protocol sends along this JOIN_RSP
the new symmetric encryption key encrypted with the public key of the
joiner.

This protocol uses a lot of public private key encryptions (4 or five when
AUTH provides the key for ENCRYP) but I think this is ok (members usually
join not very often).


The session key created by the coordinator could be used in the ENCRPT
protocol for the message encryption.


For me there are the following open questions:
 - Are the two AUTH methods reasonable?
 - Should ENCRYTP be extended so that the AUTH protocol distributes the new
symmetric encryption key?
 - How would AUTH "send" the key to the ENCRYPT protocol? Using a header
which is cleared in the ENCRYPT layer would need that the ENCRYPT must be
below AUTH because of fragmentation. This would be ok for me.
 - Would it be ok that when a member leaves the group that still the same
symmetric key is used?