W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Digest Authentication Challenge Ordering

From: Patrick McManus <mcmanus@appliedtheory.com>
Date: Fri, 24 Jul 1998 14:05:29 -0400 (EDT)
Message-Id: <199807241805.OAA01004@pat.appliedtheory.com>
To: http working group <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/239
This is a message I've been meaning to send for a while, but other
projects have a way of getting in the way.. I apologize for a certain
lack of precision that will follow, but I wanted to raise the issue.

Ronald and I did a bit of interoperability testing wrt Digest
Authentication.. and we discovered what might be a problem (From the
auth draft)

::     4.6 Weakness Created by Multiple Authentication Schemes
::     An HTTP/1.1 server may return multiple challenges with a 401
::     (Authenticate) response, and each challenge may use a different scheme.
::     The order of the challenges returned to the user agent is the order that
::     the server would prefer they be chosen. The server should order its
::     challenges with the "most secure" authentication scheme first. A user
::     agent should choose to use  the first challenge it understands and
::     request credentials from the user based upon that challenge.

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.. and if I do list basic first then I am suggesting to clients
(as per 4.6) that I want that more than digest, which is definitely
not the case.

                                   (basic,digest)     (digest, basic)
lynx 2.8.1 dev 17(and prev)             Y		       N
netscape 4.05				Y		       Y
msie 4					Y		       N

Y = interoperable

(netscape has some strange behavior.. it will send basic responses no
matter the challenge type... even if only digest!)

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.

    2] introduce q values



Received on Friday, 24 July 1998 11:06:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC