v11-03 COMMENT: (following) 19.1 Authentication of Clients

Paul Leach, John Franks, and I had worked out (and submitted to Jim
Gettys) these words regarding multiple authnetication schemes.  They
don't appear to have made it into spec-03 but should have.

Dave Kristol
=========

19.? Offering a Choice of 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 in
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 as the challenge to be made
to the user the first one that the user agent understands.

When the server offers choices of authentication schemes using the
WWW-Authenticate header, the ``security'' of the authentication is only
as good as the security of the weakest of the authentication schemes.
A malicious user could capture the set of challenges and try to
authenticate him/herself using the weakest of the authentication
schemes.  Thus, the ordering serves more to protect the user's
credentials than the server's information.

A possible man-in-the-middle (MITM) attack would be to add a weak
authentication scheme to the set of choices, hoping that the client
will use one that exposes the user's credentials (e.g. password). For
this reason, the client should always use the strongest scheme that
it understands from the choices accepted.

An even better MITM attack would be to remove all offered choices, and
to insert a challenge that requests Basic authentication. For this
reason, user agents that are concerned about this kind of attack could
remember the strongest authentication scheme ever requested by a
server and produce a warning message that requires user confirmation
before using a weaker one.  A particularly insidious way to mount such
a MITM attack would be to offer a "free" proxy caching service to
gullible users.

Received on Monday, 13 May 1996 10:01:10 UTC