Re: Digest Authentication Challenge Ordering

On Tue, 28 Jul 1998, Scott Lawrence wrote:

> Patrick McManus wrote:
> 
> > My problem is that if my server doesn't list Basic as the first choice
> > (but does list is as less preferred to Digest) some existing 1.0 clients
> > that can't do digest but can do basic don't realize that basic is an
> > option.. 
> 
> But those are buggy even with respect to 2068; it's one thing for us to aim
> for compatibility with software that conformed to the Proposed Standard, but
> to maintain compatibility with something that was broken with respect to
> them can be too difficult a standard to meet.

Heck, they're buggy even with respect to rfc-1945. However, I feel we
should try and find a solution because otherwise I fear deployment of
Digest might be hampered too much.

Let me explain why I see a problem. As a webmaster I'd like to set up
protectecd areas such that if the browser supports Digest it will use
Digest, else it will use Basic. Implicit in this is the emphasis that
this should work with the current (broken) browsers. Now, going by the
current authentication spec this would mean the server must send

WWW-Authenticate: Digest ..., Basic ...

However, because this breaks most currently used browsers I have to
instead configure

WWW-Authenticate: Basic ..., Digest ...

But unfortunately this then means that _all_ browsers (including the
ones implementing the current auth spec) will use Basic too - no one
will use Digest. This means we have no reasonable upgrade path and I
believe this will therefore definitely hamper the demployment of
Digest.

I see basically three solutions (ignoring the q-value approach given
by Patrick because I don't see how to do it without breaking current
browsers):

1) Reverse the order, i.e. have servers list from least preferable to
   most preferable.
2) Make Basic the exception: list Basic first (if it's used), and then
   from most preferable to least preferable
3) Let the client make decisision (i.e the order is irrelevant).

1) would be the simplest and most elegant solution. However, I think
this might cause problems with deployed M$ implementations (both clients
and servers) who use Basic and NTLM auth schemes - anyone from M$ care
to comment? 2) is ugly, and I don't think it's any better than 1) with
respect to current implementations.

3) is doable (i.e. clients will probably have a reasonable notion of
what is the most secure/prefered of the methods it implements), but
may not be acceptable to server folks who would like to specify the
preference. As an example I'm thinking of NTLM vs. Digest - some
webmasters might prefer that the client to use Digest instead of NTLM
(if implemented) because of it's better security, however some might
wish for NTLM to be used (if implemented) because of the greater
"transparency" (users don't have to enter username/password).

> > I'm generally in favor of 1 of two paths to resolve the issue:
> 
> >     1] remove the notion of server specified preference.. the
> >     credentials belong to the client, it seems to me they should
> >     understand what the risks are in sending them out on the
> >     network. In this way the challenge specifes understandable
> >     methods only.
> 
> It is only a preference, and does not mandate anything - a browser could
> send basic when it might have sent digest; since the server cannot tell what
> its complete capabilities are, it makes no difference.  Either basic is
> acceptable or not.  Eventually, I hope that digest will be supported well
> enough in browsers that I can recommend to my customers that they turn off
> support for basic, but we've a long way to go...

I agree. However, if the spec stays at it is and browsers implement it
that way then I wonder if we'll ever get there. I'd prefer not to force
or encourage more "this site only works with the foobar browser" crap.

> >     2] introduce q values
> 
> That only makes the situation worse by increasing the number of browsers
> that don't understand what you are doing.

I agree.


  Cheers,

  Ronald

Received on Friday, 31 July 1998 06:58:50 UTC