SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion

[Todd Stecher]

I'm guessing that your workflow / product / code requires Kerberos (in  
the absence of a good open source NTLM story), and you're trying to  
figure out how to get SPNEGO wrapped kerberos tokens all of the time?

Its also extremely difficult to *always* get kerberos authentication  
(wrapped or unwrapped).

For example, if the target HTTP server is in another forest, then  
chances are the client will end up using NTLM due to SPN location  
issues.  Also, some IE policies will not even allow a kerberos or NTLM  
authentication over the HTTP transport to various zones.

My reading of the RFC is that it is truly "informational," describing  
how clients and servers use SPNEGO + HTTP, but not specifying every  
possible HTTP auth scheme.  Chances are the answer you got about raw  
NTLM being "OK" was passed through various layers of Microsoft from  
Larry Zhu, the author of the RFC itself, and based on not on  
"correctness" but rather on the behavior of millions of deployed  
clients and servers.  Even if you could get MS to change the behavior  
to your interpretation of the RFC, its not going to help much until  
every machine out there is updated.


Todd

On Mar 18, 2008, at 8:14 AM, Michael B Allen wrote:

> On 3/18/08, john at feith.com <john at feith.com> wrote:
>> On Mar 18, 12:59 am, "Michael B Allen" <iop... at gmail.com> wrote:
>>> If the HTTP server returns "WWW-Authenticate: NTLM" then the client
>>> must use NTLMSSP tokens. If it returns "WWW-Authenticate: Negotiate"
>>> then the tokens must be SPNEGO. If it returns both, then the client
>>> can pick.
>>
>>
>> Yep ... that's pretty much how I understand things.  In our case we
>> are
>> only returning "WWW-Authenticate: Negotiate".
>>
>>
>>> Otherwise, you need to explain the point of failure in more detail.
>>
>>
>> The IE client is responding to "WWW-Authenticate: Negotiate" with
>> a raw NTLM instead of SPNEGO.
>
> Well I just looked at some of my captures and I can see that raw
> NTLMSSP tokens can be sent in response to "WWW-Authenticate:
> Negotiate". And I now recall that raw Kerberos tokens can be used as
> well.
>
>>> If you're not sure then provide an HTTP client / server call  
>>> sequence
>>
>>
>> We're sure ... it's all been check / doubled checked using pack
>> sniffers,
>
> Well I'm glad you're sure but I'm not clear on what the point of
> failure is so if you want my input you'll have to explain the exact
> exchange. If you're seeing an XP client send a raw NTLM token in
> response to sending it "WWW-Authenticate: Negotiate" then I refer you
> to my original response.
>
>> etc.  Microsoft has also confirmed it and looked at their code.  They
>> say that it's intentional to return a raw NTLM instead of SPNEGO
>> regardless of the availability of Kerberos in some situations when
>> responding to "WWW-Authenticate: Negotiate".
>>
>>> the point of failure.
>>
>> The real problem is that Microsoft admits that this is intentionally
>> and claims that it is RFC4559 compliant.  I'm having great difficulty
>> in getting them to understand that RFC4559 * requires * that SPNEGO
>> be used.  I'm open to suggestions.
>
>> From glancing at RFC 4559 it indeed does not seem to include any
> mention that raw NTLM and Kerberos tokens are accepted. But I learned
> a long time ago that RFCs are not the law. What you see on the wire is
> the law.
>
> Mike
>
> -- 
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>