RE: Closing on shared-key authentication


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

>From: 	Eric Murray[]
>Sent: 	Friday, October 11, 1996 12:44 PM
>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
>Eric Murray
>PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29

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