- From: David W. Morris <dwm@xpasc.com>
- Date: Fri, 31 Jul 1998 09:24:23 -0700 (PDT)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: http-wg@cuckoo.hpl.hp.com, Paul Leach <paulle@microsoft.com>, http-wg@hplb.hpl.hp.com
On Fri, 31 Jul 1998, Scott Lawrence wrote:
> [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
^^^^^^ client or user-agent but not user
> 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.
If I were a server owner, I would be very inclined to examine the HTTP
user-agent field and not offer multiple choices but rather the best
choice known to be supported by the UA. I wonder if some or
all of the following or other implementations suggestions should be
documented:
1. Tell the end user what the authentication scheme is ...
2. Provide a user-agent configuration option to allow the user to
refuse authentication using basic
3. Provide server owners with the ability to restrict basic usage
to UAs based on UA identity .. perhaps not much better in MIM case
but it would insure that a UA which could use digest would use it.
4. Provide applications with the ability to differentiate the level of
access based on authentication type. Read via basic but create/update
only by digest or better.
Dave Morris
Received on Friday, 31 July 1998 14:40:37 UTC