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

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Dec 2010 10:43:00 +1100

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/

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 09 Dec 2010 10:33:18 +0900

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.

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