Re: Passphrases in or out

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.

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.

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.

c) An evaluation of whether this really is exportable.

d) Some comments on if adding a feature because of only US export issues
that could impact security is acceptable.

e) Some other parties besides Netscape, MicroSoft, and CompuServe to speak
up on the proposal.

f) Some cryptographers to speak up on the proposal.

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'll summarize my objections so far:

1) It is inelegant architecturally.

2) It serves a need that can be just as easily answered at the application
protocol level.

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.)

4) I'm concerned that it will delay implementation of client certificates.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<ChristopherA@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  Security Integration Suite(tm)" <http://www.consensus.com/SSLPlus>..

Received on Friday, 2 August 1996 16:12:48 UTC