httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Spreitzer" <>
Subject RE: Kerberos authentication and authentication (proxy ticket forwarding)
Date Sat, 06 Nov 1999 11:43:49 GMT
> Taking NTLM as an example, the challenge (WWW-Authenticate header) is
> sent each time you create a new connection. The ensuing handshake (NTLM
> does more than just a single challenge-response) is carried out, and
> after that all requests on that connection do not require any
> Authorization header to be sent, irrespective of which resource they
> access.

Hmm, I haven't tried lawyering this issue really carefully before, but I
suppose I'll have to now.  Looking at RFC 2617, which starts out with an
exposition of HTTP's "Access Authentication Framework", the following two
excerpts catch my attention:

   The realm directive (case-insensitive) is required for all
   authentication schemes that issue a challenge. The realm value
   (case-sensitive), in combination with the canonical root URL (the
   absoluteURI for the server whose abs_path is empty; see section 5.1.2
   of [2]) of the server being accessed, defines the protection space.
   The protection space determines the domain over which credentials can
   be automatically applied. If a prior request has been authorized, the
   same credentials MAY be reused for all other requests within that
   protection space for a period of time determined by the
   authentication scheme, parameters, and/or user preference.

So it seems to me that Windows' NTLM authorization scheme is compliant in
this regard.

> Also, you can't preemptively send auth info when you open a
> connection (well, you can send some info, but that will only shorten
> the handshake from 5 to 3 messages).

Hmm, I find RFC 2617 a bit inconsistent on this issue.  The fact that the
RFC uses the terminology of "challenge" and "response", and explicitly
provides "auth-params" that can be used to convey a nonce or other
particulars of a challenge, strongly suggests to me that it is intended to
allow what you complain about.  However, I also see the following text,
which seems more sympathetic to your position:

   A user agent that wishes to authenticate itself with an origin
   server--usually, but not necessarily, after receiving a 401
   (Unauthorized)--MAY do so by including an Authorization header field
   with the request. A client that wishes to authenticate itself with a
   proxy--usually, but not necessarily, after receiving a 407 (Proxy
   Authentication Required)--MAY do so by including a Proxy-
   Authorization header field with the request.  Both the Authorization
   field value and the Proxy-Authorization field value consist of
   credentials containing the authentication information of the client
   for the realm of the resource being requested.

> In short, NTLM-auth authenticates the connection, not the request.
> HTTP authentication (e.g. Basic and Digest) does not care about
> connections, only about requests.

As indicated above, I'm not sure this is the correct way of analyzing the

Now, on to your original question.  I haven't actually seen the source
code, nor even experimented with the available betas and release
candidates, so I can't make too strong a claim.  Just looking at the
underlying technology, it seems that NTLM needs an exchange whereas
Kerberos can just prepend an "authorization header" to the start of the
client's data.  So I think there's good reason to hope that the Win2K
client/server interaction in the Kerberos case is simpler than in the NTLM


View raw message