W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

RE: Repost of CompuServe Position on Passphrases

From: Don Schmidt <donsch@microsoft.com>
Date: Fri, 2 Aug 1996 17:29:13 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-86-MSG-960803002913Z-5734@tide19.microsoft.com>
To: Dan Simon <dansimon@microsoft.com>, "'elgamal@netscape.com'" <elgamal@netscape.com>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'Christopher Allen'" <ChristopherA@consensus.com>
Taher

But then the application has to provide the encryption, make sure it can
only be applied to auth data and not bulk user data, become involved in
key management...

From a service perspective, the purpose of a standard security provider
at the systems level is to offload these functions from applications.
From a security perspective, it is to make sure they are provided in a
consistent, robust manner.

If it is good to provide this support to applications for certificates.
Then why is it not also good to provide it for shared-secrets?

Don Schmidt
donsch@microsoft.com
Program Manager
Microsoft Corp

>----------
>From: 	elgamal@netscape.com[SMTP:elgamal@netscape.com]
>Sent: 	Friday, August 02, 1996 1:22 PM
>To: 	Dan Simon
>Cc: 	'ietf-tls@w3.org'; 'Christopher Allen'
>Subject: 	Re: Repost of CompuServe Position on Passphrases
>
>Dan,
>
>Exportable applications are allowed to encrypt passwords with any bit 
>length.
>
>Taher
>
>Dan Simon wrote:
>> 
>> >
>> >From:  Christopher Allen[SMTP:ChristopherA@consensus.com]
>> >
>> >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
>> password.
>> 
>> >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.
>>                                 dansimon@microsoft.com
>
>-- 
>Taher Elgamal	    elgamal@netscape.com
>Chief Scientist, Netscape Communications
>(T) 415 937 2898, (F) 415 428 4054
>
>
Received on Friday, 2 August 1996 20:32:00 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:50 EDT