Re: Closing on shared-key authentication

["Adam Cain" <acain@xxxxxxxxxxxxx>]

In the case of HTTP, digest authentication can be used.  It's part of
the HTTP/1.1 spec, and it's thought to be fairly strong.  See

	http://www.w3.org/pub/WWW/Protocols/Specs.html#Digest

In my book, Digest Auth over TLS (even export strength) is just fine for
shared secret authentication.  I believe other application protocols have
one-time-password extensions, or they could support a mechanism similar
to HTTP digest auth (adding it to telnet and ftp would be straightforward).

I don't see sufficient benefit added by shared secret auth in TLS to
justify the increased protocol and application complexity.

	Adam



On Oct 11, 12:44pm, Eric Murray wrote:
> 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@xxxxxxx  ericm@xxxxxxxxxxxxxx  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
>
>-- End of excerpt from Eric Murray