Re: Thoughts on shared-key authentication

Charles Watt writes:
 
> When servicing a customer base of > 1 million account holders, it is:
> 
> 	1) an onerous administrative task
> 	2) a horrendous performance hit on the server
> 
> to use client-side certificates -- particularly in light of the fact 
> that most banks have already distributed via manual methods sufficient 
> information to authenticate customers (e.g., ATM cards and PINs) that 
> could be used in an automated fashion by an on-line bank server.

Ok, I can agree with that, although using client certificates only
doubles the amount of public-key operations that the server has to do
(which doesn't double the CPU time required to set up a TLS session
as there's more than just public-key operations in that CPU time).

My solution to your problem would be to use TLS
to negotiate a secure channel (i.e. SSL_RSA_WITH_RC4_128_MD5)
with the client, without client auth.  The server is authenticated in
the usual way.  Once the TLS handshake is done the user sends her
account number, PIN, whatever that authenticates her to the bank, in
the application protocol.  TLS is (supposedly) secure
so her authentication info is transmitted safely.
If the account number + PIN is considered by the bank to be
enough to authenticate the user, and its sent in a secure fashion, what
else is needed?

Once client certs are in place, the TLS server, when it accepts
the client cert, can notify the bank application that requires
the authentication so that it doesn't demand the PIN.
I think that this data (did the client provide a valid cert)
is probably required of any TLS API.


-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Friday, 11 October 1996 18:37:04 UTC