FW: [Fwd: Shared Key Authentication for the TLS Protocol-- anAlternative]

>
>From: 	Jeff Williams[SMTP:jwkckid1@ix.netcom.com]
>
>  I suppose this would partly be a response to what Peter has rightly
>pointed out.  I guess where I get confused is how does this address in
>total, address standardazation of winsock's? 
>
>If two Winsock implementations support TLS, and TLS includes shared-key
>client authentication, then they would be able to do shared-key client
>authentication interoperably.  If you're thinking about APIs rather than wire
>formats, then a standardized API for shared-key authentication is no trickier
>to come up with than one that handles public-key authentication--it's just
>that this working group explicitly decided to avoid discussing APIs in its
>hoped-for standard.
>
>>
>>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.
>
>  Does this special exception for authentication data provide for
>interoperability?
>
>Certainly.  It would occur automatically and transparently--"under the
>covers", as it were.  No need for API changes, for example.
>
>
>				Daniel Simon
>				Cryptographer, Microsoft Corp.
>				dansimon@microsoft.com
>
>
>
>

Received on Wednesday, 2 October 1996 20:59:02 UTC