Re: WWW-Authenticate / Proxy-Authenticate with 200 response

We're currently reusing a Authentication-Info: header in our proposal for new
authentication scheme (Mutual).
It seems to be generic enough to reuse it with schemes other than Digest, and I
do not like to require numbers of separate headers for numbers of future schemes.

Also, considering several implementations and backward compatibilities
I prefer using a separate Authentication-Info header over overloading semantics
of WWW-Authenticate.  Several clients treat WWW-Authenticate in 200 headers in
different and inconsistent ways (to ignore, or to treat as if it were 401).

However, to force changing all existing schemes is not a good way.
I personally think that the best way to resolve is:

 - Use Authentication-Info for Digest and any other future schemes.
 - Reserve WWW-Authenticate for backward-compatibility with
   existing schemes only and deprecate sending it with other than those.
 - If reasonable, recommend a best practice for handling WWW-Authenticate
   in a successful responses other than those (may be to ignore it).

If there will be a consensus about the way to encode a server-to-client
authentication-related information, we will follow it.

On 2010/12/07 8:43, Mark Nottingham wrote:
> Without knowing much about SPEGNO, this seems like a use case for the Authentication-Info header (see RFC2617), at least conceptually. Right now it's specific to Digest, but it would be reasonable to talk about changing it to allow extensions, or to use a different header if that isn't workable.
> 
> Regards,
> 
> 
> On 18/11/2010, at 11:06 AM, Adrien de Croy wrote:
> 
>>
>> Hi all
>>
>> I've just been doing some research on this, since I've seen a case where SPNEGO is being used (for proxy auth actually which seems to contravene SPNEGO RFC 4559 S.6 para 3) resulting in a final chunk of auth protocol data lying around needing to go back to the client even though the auth was successful.
>>
>> My initial thoughts were to drop this, since obviously one mustn't send a WWW-Authenticate or Proxy-Authenticate header in a 200 response.  Wrong.
>>
>> The SPNEGO spec actually indicates it's intended to send such a header in a success response.
>>
>> I'm just wondering while we're updating the specs for authentication, whether the prose around the WWW-Authenticate and Proxy-Authenticate headers should indicate it may also appear in responses other than 401/407 respectively.  At the moment it states the header MUST appear in a 401/407 but that's it.  It's not intuitive to expect to see one in another response.
>>
>> Why anyone would use NTLM over SPNEGO over HTTP is beyond me though.  Makes a painful 3-request NTLM handshake seem like bliss compared to the extra steps involved and resulting SPNEGO agony.  Especially since the browser cannot know apriori if the server/proxy will require auth for any particular request/connection.  This is one of the problems of offloading this task to an underlying system (SSPI) that doesn't know what it's being layered over.
>>
>> Regards
>>
>> Adrien
>>
>>
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

-- 
大岩 寛   Yutaka Oiwa                       独立行政法人 産業技術総合研究所
            情報セキュリティ研究センター ソフトウェアセキュリティ研究チーム
                                      <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Thursday, 9 December 2010 01:38:05 UTC