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

RE: Passphrases in or out

From: Dan Simon <dansimon@microsoft.com>
Date: Fri, 2 Aug 1996 17:14:49 -0700
Message-ID: <c=US%a=_%p=msft%l=RED-92-MSG-960803001449Z-12732@tide21.microsoft.com>
To: "'Keith Ball'" <Keith_Ball@novell.com>, "'Christopher Allen'" <ChristopherA@consensus.com>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
>
>From: 	Christopher Allen[SMTP:ChristopherA@consensus.com]
>
>At 12:43 PM -0700 8/2/96, Dan Simon wrote:
>>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.
>
>Ok, so far this is the only requirement that I've seen that can't be done
>with TLS now.
>
>As summarize Dan's requirement, TLS while securing a transport using an
>exportable cypher (say RC4-40) would allow passphrases to be secured at a
>full (RC4-128) level. Thus if you were using FTP with SSL, the
>username/password could be sent at the high encryption level.
>
>However, again, is this really necessary? Since you have shared secrets,
>can't you use something like the APOP framework where you send a date, hash
>it with the password and send the hash back? Isn't that as secure (or more
>secure) as sending the password encrypted with RC4-128? And that can be
>done at the application level, and already exists in some form in a number
>of IETF protocols.

No, this is not as secure as strong protection of the password-based
response.  This method allows brute-force offline search for the
password; if the latter was poorly chosen, then it may be quite easy to
find.  Strong protection of the response with a key derived from a
public-key key exchange solves the problem.
>
>At 9:48 AM -0700 8/2/96, Keith Ball wrote:
>>I still havent seen any movement towards resolution.  The issues havent
>>changed substantially. So, how is this to be resolved?  I think Dan Simon's
>>suggestions are useful from our perspective, but I dont see any agreement
>>that
>>it will or will not be adopted.
>>
>>1) How will this issue be resolved?  What happens when consensu doesnt
>>appear
>>to be reached (or reachable) on the mailing list?
>
>I could be persuaded to drop my objections if there was the following:
>
>a) A concrete proposal, to the bits level, of how you can protect
>password-based challege-response bits at a higher level of encryption than
>the exportable SSL stream, and how this proposal fits into the the broader
>TLS protocol, and *DOESN'T* try to do more than this.

I presented exactly such a proposal in a brief post-meeting rump session
after the working group meeting in Montreal.  The text of it will be
posted to this list shortly.
>
>b) An evaluation of whether this couldn't better be done through another
>"standard" technique like APOP or some of the other AUTH frameworks at the
>application level, or by using some out-of-band technique.

My comments above, together with my response to Taher's email, hopefully
clear up this question.
>
>c) An evaluation of whether this really is exportable.

This is unfortunately a terribly touchy question, as exportability is
something of an empirical science.  As far as I know, there is no
official oracle which will rule on the exportability of a generic method
like a protocol, as opposed to a particular implementation.  However, I
expect that those who are familiar with export approval procedures will
agree that the method I have been advocating stands as good a chance as
any inexact science will allow.  :^)  
>
>d) Some comments on if adding a feature because of only US export issues
>that could impact security is acceptable.

Has anyone complained about the EXPORT cipher suites yet?
>
>e) Some other parties besides Netscape, MicroSoft, and CompuServe to speak
>up on the proposal.

Excellent idea--I encourage as many disparate voices as possible to come
forward. 
>
>f) Some cryptographers to speak up on the proposal.

I believe I count as one (at least, that's what my business card says).
Bennet Yee could be considered another.  Taher would be a third.  I
would, of course, love to hear from more.  But then we should probably
have as many cryptographers as possible root through the entire TLS
protocol, not just the shared-key authentication feature.
>
>g) An "exit" strategy, so that we can be sure that this hack has a sunset,
>and that it would not be a requirement of TLS to always support this in the
>future.

I'm not sure what is meant by "a requirement of TLS to always support
this in the future".  Certainly, it was never anyone's intention to
force support for this feature on any implementer of TLS.  Given that
support for it would in any event be completely optional, I see no
reason to consider this feature any more or less permanent than, say,
support for the IDEA cipher.
>
>I'll summarize my objections so far:
>
>1) It is inelegant architecturally.

I've heard this complaint a number of times, and I've never understood
it.  If public-key-based client authentication belongs in TLS, then how
could shared-key-based client authentication belong anywhere else?  So
what if they work slightly differently--isn't architectural elegance a
matter of first locating functionality, then allowing alternate
mechanisms for providing that functionality to be inserted as needed?
>
>2) It serves a need that can be just as easily answered at the application
>protocol level.

See my comments above.
>
>3) I'm concerned about security issues (I'm not a cryptographer, so I can't
>say that it is not secure, only that I've not heard enough from them to
>feel more confident.)

As a cryptographer, I will freely grant that there are security risks
associated with shared-key authentication that don't exist in the
public-key case.  Unfortunately, in the real world, security is only one
of many concerns, and practical obstacles to public-key authentication
may in some cases outweigh the security advantages.  That is hardly a
rare occurence in cryptography; any cryptographer can identify dozens of
such concessions to practicality in the current TLS document, for
example.  Normally, cryptographers try to decide only the no-brainers
ourselves (getting rid of blatantly broken ciphers, for instance), and
provide enough information about the trickier trade-offs so that
cryptography's consumers, thus armed, can make informed choices.
>
>4) I'm concerned that it will delay implementation of client certificates.

My own view is that if anything, it will expedite the implementation of
client certificates.  But suppose that I'm wrong, and Christopher is
right--as John Macko has pointed out, what would it say about the
relative attractiveness of client certificates, if implementers, given
all the facts, still had to be bludgeoned into using client certificates
by a ban on the use of something they'd prefer if they had the option?

No, I believe that implementers, administrators and users will migrate
to client certificates when they decide that client certificates are
preferable to passwords.  (And I also believe that that day is not far
off.)  Trying to coerce them by rendering password-based schemes less
secure than they could be, on the other hand, will not only not convince
many people--it will also win us (the working group, the IETF, standards
bodies and cryptographers in general) enemies while weakening overall
Internet security.


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


>
>
>
Received on Friday, 2 August 1996 20:14:57 EDT

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