Subject: Re: HTTP sasl draft in last call

From: Lisa Dusseault <[email-masked]>
Date: Mon, 3 May 2004 11:42:57 -0700

I share Joe's concern with definition of 235/236 success codes.  They 
are unnecessary
and introduce a round-trip, and this makes SASL authentication work 
unlike Digest
(and Basic).  I don't see the justification for the change and the 
extra complexity.
Instead, when authentication succeeds, the response to the authorized 
request should
immediately be the regular success response, whether that's 200 OK with 
the body
of the requested resource, or some other success code, with the 
WWW-Authenticate
success header moved from the 235 (236) code response to the real 
success
response.

Joe, why is CONNECT not going to work?  Can you forward your explanation
for that?  Also, why is redefining OPTIONS not going to work (and how 
exactly
are they redefining OPTIONS?)

Ted, I'll forward the 1st para above to the IESG separately as an 
official last call comment.

Lisa

On Apr 30, 2004, at 4:23 PM, Ted Hardie wrote:

>
> Hi Joe,
> 	Can you send your last call comments to the IESG,
> so they can be considered with the draft?
> 			thanks,
> 				Ted
>
>
>
> At 11:47 PM +0100 04/30/2004, Joe Orton wrote:
>> On Fri, Apr 30, 2004 at 11:34:15AM -0700, Ted Hardie wrote:
>>>  http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-11.txt
>>>
>>>  is currently in last call; working group members may wish to review
>>>  it, as it specifies HTTP status codes and SASL mechanisms which may
>>>  be relevant to the work of WEBDAV.
>>
>> The last call is "aarrgggh".... well, how about removing "HTTP/1.1" 
>> from
>> the title so this spec isn't confused with a real HTTP/1.1
>> authentication scheme?
>>
>> What are these new 235/236 status codes for?  They seem to be entirely
>> redundant.  Trying to redefine OPTIONS is still not going to work,
>> neither is the CONNECT-to-port-80 stuff, etc etc as per previous
>> reviews.
>>
>> joe
>

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 10 May 2004 09:41:56 -0700

On May 7, 2004, at 8:06 AM, Alexey Melnikov wrote:

> Nystrom, Magnus wrote:
>
>> Lisa,
>>
>> Thanks again for your review.
>>
>> The reason for introduction of 235/236 status codes is that they 
>> allow for
>> a clean introduction of a SASL security layer. With 200 alone, one 
>> must
>> ask when the SASL security layer actually goes into effect. Clearly 
>> not
>> all headers can be included in it, since for example there could be a
>> final WWW-Authenticate header from the server which is needed for the
>> client to calculate session keys etc. OTOH, any body clearly must be
>> protected by them. So, after some discussion, and while realizing 
>> that the
>> 235/236 will require an extra roundtrip, we felt the advantages 
>> outweighed
>> the disadvantages.
>>
>> Of course, I would be grateful for any suggestions on how to solve 
>> this
>> problem without the introduction of new status codes.
>>
> I agree with everything that Magnus said. I am wondering if this 
> explanation should be part of the document itself?

Unfortunately, I think the architecture that "necessitates" adding 
235/236 requires a rethink.  It's very un-HTTP and ill-defined to 
create a security layer in this way.  We could try to have some 
discussions about how to solve this differently - Roy suggested one 
approach, and there are obvious variations.

Lisa