- From: Daniel F. Sullivan Jr. <dsulliva@mail.bcpl.lib.md.us>
- Date: Sat, 02 Nov 1996 20:57:16 +0000
- To: Dan Simon <dansimon@microsoft.com>
- Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
Dan Simon wrote: > > > > >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 > > > > > > > > unsubscribe
Received on Thursday, 3 October 1996 16:56:53 UTC