Re: Another issue on SASL draft

I'm not sure this connection-oriented approach will really work for
existing HTTP/WebDAV software.  For example, the Java HTTP servlet API
treats each request as independent.  It's a major architectural change 
to
have authentication credentials (or any state) last for more than one 
request.
The "HTTP way" is to re-establish context information with every 
request.
For example, the ETag the client expects the entity to have is sent 
with every
HTTP request; and WebDAV clients send the lock token they are using
with every request.

There are other options like having the server provide a SASL session-ID
(you can require that this only be used over secured connections) and 
the
SASL session ID is used to identify the SASL authentication context 
without
re-authentication.

Lisa

On May 3, 2004, at 1:44 PM, Nystrom, Magnus wrote:

> Lisa,
>
> Thanks for reviewing our document. Alex is on holidays right now but in
> the interest of time I'll try to answer right away.
>
> The idea is that when sending the last request, the client already 
> knows
> that it has been authenticated and there was no need to send another
> WWW-Authenticate header for the server (and no need to include an
> Authorization header for the client). The fact that the client is
> authenticated is something the server will have to make note of. This 
> is
> different from Basic/Digest where the client pre-emptively may include 
> an
> Authorization header for requests within the original request-URIs
> protection space, but it is a consequence of the open nature of the 
> SASL
> framework - it may not be possible, or it may be very costly, to
> re-authenticate with a particular SASL mechanism, especially
> pre-emptively.
>
> I will answer your question regarding the 235 response in a separate
> email.
>
> -- Magnus
>
> On Mon, 3 May 2004, Lisa Dusseault wrote:
>
>> I just noticed something else I don't understand in the SASL draft.
>> Can you clarify?
>>
>> Example 6, in section 4.7.6, shows the client attempting to 
>> authenticate
>> but without using the CONNECT request.  So far so good -- the client
>> doesn't want a SASL layer, the client simply wants to authenticate.
>> The last GET request in the example shows no WWW-Authenticate header,
>> thus no authorization information -- yet the server responds
>> successfully.  Shouldn't every request include the WWW-Authenticate
>> header, until the point where the client decides to "log out"?
>>
>> This problem wouldn't exist if the 235 error was removed and if SASL
>> worked like Digest/Basic -- the 2nd GET request would clearly contain
>> the authentication, and the response would be 200 OK.

Received on Tuesday, 4 May 2004 17:36:24 UTC