RE: Repost of CompuServe Position on Passphrases

>From: 	Christopher Allen[]
>I don't see how not having this feature prevents CompuServe from creating a
>secure, server authenticated channel, then using their existing password
>infrastructure to then authenticate the client. I can do this today with
>SSL under FTP, NNTP and without certificate-based client authentication. In
>fact, many of our prospective licensees of the SSL Plus toolkit plan on
>doing just that.
>Tell me something that CompuServe can't do without this feature, and I
>might be more in favor of it. 

Okay, here's one thing:  they can't protect password-based
challenge-response transcripts with strong encryption while adhering to
export restrictions.  If the application is restricted to exportable
encryption, then it can't properly protect challenge-response pairs from
brute force attacks--first against the encryption, then against the

>But adding a password feature to a
>certificate based protocol where it doesn't fit invites security holes and
>poor implementations.

....As does *not* adding the feature, if the result is that most people
simply stick with application-level password authentication.
>BTW, I don't buy the reasoning "but now shared secrets will be done in a
>standard way under TLS". If everyone is going have to change things so that
>it is done in a "standard way" to support passwords under TLS, they might
>as well change it so that they use certs.

I'm hardly an implementation expert, but my impression is that there's a
huge difference between having to "change things" and converting to an
entirely new security architecture and client authentication
infrastructure.  If the only way to "change things" is to do the latter,
then I fear that few will bother to change at all.

				Daniel Simon
				Cryptographer, Microsoft Corp.

Received on Friday, 2 August 1996 15:43:57 UTC