RE: Closing on shared-key authentication

Eric:

Yes, we did review the latest password authentication scheme with the
NSA before posting it.  And I think there may be some confusion that we
are proposing this scheme only to circumvent US crypto export policy.
Not true.  The real objective is to have a *standard* way to do
passwords within the TLS protocol.  There's a lot more to it than
"non-export crypto" - but just about everything has already been said in
this discussion over the past couple of weeks. 

Tom Stephens
tomste@microsoft.com

>----------
>From: 	Eric Murray[SMTP:ericm@lne.com]
>Sent: 	Friday, October 11, 1996 12:44 PM
>To: 	marcvh@aventail.com
>Cc: 	tomw@netscape.com; ietf-tls@w3.org
>Subject: 	Re: Closing on shared-key authentication
>
>Marc VanHeyningen writes:
>> 
>> > No, you should certainly do something more than just send the password
>> > encrypted.  You should avoid sending the password at all, encrypted or
>> > otherwise.  Some sort of challenge/response mechanism would be
>> > appropriate, but you are protected from eavesdroppers if you encrypt
>> > the data.
>> 
>> True.  I'm clearly misunderstanding you then.  You said previously:
>> 
>> >There is no need to add a mechanism
>> >to TLS when all existing protocols already have a password mechanims.
>> 
>> I assumed the password mechanisms that you meant there were
>> cleartext ones, not more sophisticated ones based on challenge-response
>> or keyed hashes or anything else.  Was I wrong?
>
>Sort of.  They're cleartext unless the entire exchange is protected
>by TLS.  Then they're encrypted in whatever ciphersuite TLS
>negotiated.  Obviously when you are negotiating use/non-use
>of TLS in an existing protocol, you must start TLS before
>sending the username/password.
>
>> I believe there is a need to add a mechanism to TLS because, while all
>> existing protocols have password mechanisms, they're lousy ones.
>
>The only advantage to embedding passwords is being able to
>use "non-export" encryption on the password, _IF_ the protocol
>is designed so that no one can use the password field to
>exchange "random data".  If I can write an app to use
>TLS/password auth to send words (say as "login attempts")
>of my own choosing under strong encryption, the NSA will not
>allow export of the scheme.  I have not reviewed the latest
>TLS password proposal, so I do not know if it will meet
>the NSA's requirements.  Has anyone asked them yet?
>
>In any case, I agree with Tom that we should not be designing
>the TLS protocol to meet the US crypto policy flavor-of-the-month.
>Besides the fact that they can change it on any political
>whim, rendering our work invalid, TLS is an international
>standard.
>
>
>-- 
>Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
>PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29
>AF
>
>

Received on Saturday, 12 October 1996 20:00:19 UTC