Shared Key Authentication for the TLS Protocol-- an Alternative

Shared Key Authentication for the TLS Protocol--an Alternative

1.  Introduction

This document presents an alternative to the shared-key authentication 
mechanism proposed for the TLS protocol on the IETF TLS mailing list in 
late July 1996.  This alternative mechanism accomplishes the same goals 
(including enabling three-party "pass-through" authentication) in a 
slightly more straightforward manner.  A discussion of the arguments for 
and against the inclusion of shared-key authentication in the TLS 
protocol can be found in that original shared-key authentication 
document.


2.  Summary of Changes From the Previous Proposal

In the previous proposal, a key derived from the master key and several 
other inputs was used in a stream-cipher-like manner to protect a 
shared-key authentication response from eavesdroppers.  In this 
proposal, a separate secret, called an authentication secret, is derived 
directly from the master secret and incorporated into the authentication 
response.  Thus in the case of pass-through authentication, the server 
must pass not only the authentication response but also this 
authentication secret to the authentication service verifying the 
response.

The previous proposal also reused the CertificateRequest handshake 
message for shared-key authentication requests.  In the new proposal, 
all shared-key-related data is contained in new handshake messages 
(implementations that support the proposed changes can thus be made to 
interoperate with implementations that do not, but ignore invalid 
handshake messages).  Also, a "private" shared-key authentication 
response format, originally proposed to allow arbitrary authentication 
response formats between co-operating clients and servers, has been 
removed from this proposal.  Since the response field is in any event 
opaque, implementations of an alternative shared-key authentication 
format for a particular authentication service can simply have clients 
detect the specific authentication service, and construct their 
authentication responses accordingly.

Finally, extra challenge and display string fields have been associated 
with each authentication service name provided by the server, the former 
to facilitate pass-through authentication with service-supplied 
challenges, and the latter to help the implementation to identify the 
authentication service to the user.


2.  Proposed Protocol Additions

Starting from SSL version 3.0 notation and formats, the following two
new HandshakeTypes would would be added, and included in the Handshake 
message definition:

shared_key_request(31), shared_key_verify(32)

The SharedKeyRequest message would have the following structure:

struct { DistinguishedName auth_service_name;
         opaque display_string<0..65535>;
         opaque challenge<0..255>;
} AuthService;

struct {
     AuthService auth_services_server<1..65535>;
} SharedKeyRequest;

This optional message would be sent immediately following the server's 
first set of consecutive messsages, which includes the ServerHello and 
(possibly) the Certificate, CertificateRequest and ServerKeyExchange 
messages.  The auth_services_server field would contain a list of 
distinguished names of shared-key authentication services by which the 
client can authenticate.  The challenge field accompanying each 
authentication service name would contain an optional extra 
authentication challenge, in case the server needs to obtain one from an 
authentication service for pass-through authentication.  If none is 
required, then it would simply be an empty (zero-length) field.  
Similarly, the display_string field could contain an extra field to be 
displayed to the user during authentication, if needed. 

The SharedKeyVerify message would be sent in response to a 
SharedKeyRequest message from the server, and would have the following 
structure:

struct {
     AuthService auth_service;
     opaque identity<1..65535>;
     opaque shared_key_response<1..255>;
} SharedKeyVerify;

The value of auth_service would be required to be selected from the list 
in SharedKeyRequest.auth_services_server.  The format of the identity 
field would be left to the implementation, and should be inferable from 
the accompanying value of auth_service.  The value of 
shared_key_response would be defined as

SharedKeyVerify.shared_key_response
     hash (auth_write_secret + pad_2 + 
            hash (auth_write_secret + pad_1 + hash (handshake_messages)                   
                  + SharedKeyVerify.auth_service.auth_service_name
                  + SharedKeyVerify.auth_service.display_string
                  + SharedKeyVerify.auth_service.challenge
                  + SharedKeyVerify.identity + shared_key) )
     
Here "+" denotes concatenation.  The hash function used (hash) would be 
taken from the pending cipher spec.  The client_auth_write_secret and 
server_auth_write_secret values would be obtained by extending the 
key_block by CipherSpec.hash_size bytes beyond the server_write_key (or 
the server_write_IV, if it is derived from key_block as well), and using 
this extended portion as the client_auth_write_secret value.  The value 
of handshake_messages would be the concatenation of all handshake 
messages from the first one sent up to (but not including) the 
shared_key_verify message.  The pad1 and pad2 values correspond to the 
ones used for MAC computation in the application_data message.  The 
fields from the SharedKeyVerify message would be input with their length 
prefixes included.  


3.  Normal Authentication

A shared-key-based client authentication would proceed as follows:  the 
server would send a SharedKeyRequest handshake message containing a list 
of names of one or more authentication services.  The client, on 
receiving the SharedKeyRequest message, would select an authentication 
service from the server's list and construct the appropriate 
authentication response as described above, sending it back, along with 
its identity and choice of authentication service, in a SharedKeyVerify 
handshake message.  The server would also itself construct the correct 
authentication response using the known shared key, and check it against 
the one provided by the client.  The authentication would be successful 
if the two matched exactly.  Note that if the shared key is password-
based, then it would typically be derived from the password using a one-
way cryptographic hash function, rather than being the password itself, 
so that the original password need not be remembered by anyone but the 
client.


4.  Pass-through Authentication
 
In some circumstances, it is preferable for shared keys to be stored in 
one place (a central, well-protected site, for instance) while servers 
that actually communicate with clients are elsewhere (possibly widely 
distributed, but maintaining secure connections to the central shared-
key server).  One of the advantages of the shared-key authentication 
method proposed here is that it allows "pass-through" authentication by 
a third party, if the server accepting the public-key key exchange and 
the server sharing the key with the client happen to be different.  (The 
use of a separately derived authentication key in the response 
computation makes this possible.)  

Pass-through authentication might work as follows:  The server would 
either collect random challenges in advance from its authentication 
services, or request them as needed.  The server would then send a list 
of authentication services and associated challenges in a 
SharedKeyRequest message.  The client would then select an 
authentication service (if more than one is offered), compute the 
correct authentication response using the above proposed formula, and 
send it to the server in a SharedKeyVerify message.

The server, on receiving a response from a client, would pass it through 
to the authentication service, along with the values necessary to 
recalculate it:  the client_auth_write_key, the hash of all the 
handshake messages and the identity field from the certificate verify 
message.  The authentication service would then use the values provided, 
along with the secret key it shares with the client and the challenge it 
supplied, to reconstruct the correct value of the response.  If this 
value exactly matches the one provided by the server, then the 
authentication would succeed; otherwise it would fail.  


5.  Addendum--The SharedKeys Message

In cases where pass-through authentication is used, it would be useful 
for clients to be able to notify servers in advance of one or more 
authentication services sharing a key with the client, so that the 
server need only fetch (or use up) a challenge from a single service for 
that client.  An additional optional message accompanying the 
ClientHello would accomplish that purpose.  It is proposed here for 
consideration, with the following HandshakeType:

shared_keys(30)

The SharedKeys message would have the following structure:

struct {
     DistinguishedName auth_services_client<1..65535>;
} SharedKeys;

This optional message would be sent immediately following the 
ClientHello message, and would contain a list of distinguished names of 
authentication services to which the client is willing to authenticate.  
This message could also be useful in non-pass-through situations; for 
example, the client may share several keys with the server, associated 
with identities on different systems (corresponding to different 
``authentication services'' residing on the same server).  If a server 
receives a SharedKeys message, then any subsequent SharedKeyRequest 
message could contain a single authentication service selected from the 
client's list.  

Note that sending a SharedKeys message does not in itself normally 
reveal significant information about the client's as-yet-unspecified 
identity or identities.  However, if information about the set of 
authentication services supported by a particular client is at all 
sensitive, then the client should not send this message.

Barbara Fox
bfox@microsoft.com

Received on Monday, 30 September 1996 22:20:09 UTC