RE: [Fwd: Shared Key Authentication for the TLS Protocol-- an Alternative]

>From: 	Peter Williams[SMTP:peter@verisign.com]
>
>I would disgaree that its necessary to modify SSL standard (in TLS) to
>accomplish the
>goal which Barb has established. I see SSL's integrity channel as something
>which
>should simply always be there on any TCP frame henceforth. A server
>side RSA key is simple to manage, and key management costs are marginal. The
>wonder of RSA math means only one side needs keying and substantial
>improvement
>in default end-end channel integrity is provided, always.
>
>To now add authentication exchanges to implement authentication services
>which
>are not standarized by SSL (exploiting whichever cipherSuite) should not
>require a change
>to SSL per se. Any numer of intermediate layers of protocol exchnage can be
>layered within
>the SSL-integrity-protected frames, to implement whatever the parties agree.
>They
>can use the default scalable authentication service provided by SSL which is
>application
>and stack and netweork and vendor and platform indepedent, else use their own
>proprietary
>design, as per NT's proprietary challenge-response mechanism on the web.
>Exploiting SSL basic
>integrity channel is simply a matter of organizing winsock hooks, not
>fighting over standards to
>win market share wars or level playing fields in infrastructure deployment
>battles.The means
>of agreeing the capabilities can be certs, or ISAKMP, or port assignment.

Similarly, public-key-based client authentication does not have to be in
SSL/TLS either, since it could easily be layered on top of it.  An
advantage of incorporating it into the protocol is, as Peter points out,
interoperability.  Exactly the same argument applies in the case of
shared-key-based authentication; a single, non-proprietary
shared-key-based authentication standard embedded in TLS (which is what
our proposal provides) allows independent client-builders and
server-builders to implement shared-key authentication interoperably. 

There is another justification for this incorporation in the case of
shared-key authentication that does not apply in the case of public-key
authentication:  if for any reason the channel used is not strongly
encrypted, and the shared key being used for authentication is guessable
(as is often the case for user-remembered passwords), then any fully
layered solution will be vulnerable to brute-force offline attacks.
Incorporating the authentication protocol into TLS allows a special
exception to be made for the authentication data, strongly protecting it
even if the normal traffic is not strongly encrypted.


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com




>

Received on Tuesday, 1 October 1996 18:45:53 UTC