httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die." <>
Subject Re: Kerberos authentication and authentication (proxy ticket forwarding)
Date Sat, 06 Nov 1999 21:07:49 GMT
One day, Mike Spreitzer wrote:
> > 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.

Err, no. There is no realm (after all, what for? it's authenticating a
connection, not a request). The handshake looks as follows (see for more details)

    1: C -> S   GET ...
    2: S -> C   401 Unauthorized
                WWW-Authenticate: NTLM
    3: C -> S   GET ...
                Authorization: NTLM <base64-encoded type-1-message>
    4: S -> C   401 Unauthorized
                WWW-Authenticate: NTLM <base64-encoded type-2-message>
    5: C -> S   GET ...
                Authorization: NTLM <base64-encoded type-3-message>
    6: S -> C   200 Ok

But that's not the point. The point is that the connection has to stay
open during the whole handshake (whereas real HTTP authentication does
not depend on such things, as they deal with requests/responses, not
with connections), and that requests sent after step 6 above (on the
same connection) do not include an Authorization header (I forget what
happens exactly if you try to send a 401 at that point - I think the
clients barf).

If you try to write an ntlm module it'll only barely work: A) you have
to make sure you always send a Content-Length header so the connection
stays open, and B) you need to force the connection close after each
non-auth-challenge response (step 6 above).



View raw message