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

CHALLENGE-ORDER: proposed change

From: Scott Lawrence <lawrence@agranat.com>
Date: Fri, 31 Jul 1998 15:22:22 +0000
Message-Id: <35C1E12E.B304AF56@agranat.com>
To: http-wg@cuckoo.hpl.hp.com
Cc: Paul Leach <paulle@microsoft.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/279
[resent after bounce on first attempt]

I don't believe that leaving the choice of schemes to the browser creates
any problems that are not there anyway, so I propose the following
replacement for 4.6 (I could not find any other section that had any text on
this - please point it out if I missed it).  The first paragraph is changed
to remove the semantics associated with the offered order, and to add some
normative language about not sending replayable credentials.  The second is
unchanged except for striking the last sentence.

    4.6 Weakness Created by Multiple Authentication Schemes
    An HTTP/1.1 server MAY return multiple challenges with a 401
    (Unauthorized) response, and each challenge MAY use a different
    scheme.  The user is free to choose from among the offered challenges
    it understands and request credentials from the user based upon that
    challenge.  The user agent SHOULD choose the scheme it considers to be
    most secure; the Basic scheme, or any other scheme which transmits
    credentials in a way that allows for replay of those credentials,
    SHOULD NOT be used if there is an alternative available. 
    When the server offers choices of authentication schemes using the WWW-
    Authenticate header, the strength of the resulting authentication is
    only as good as that of the of the weakest of the authentication
    schemes. See section 4.8 below for discussion of particular attack
    scenarios which exploit multiple authentication schemes.

Scott Lawrence           Consulting Engineer      <lawrence@agranat.com>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/
Received on Friday, 31 July 1998 08:24:16 UTC

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