Kerberos 5 and NTLMv2 without SPNEGO?

Michael B Allen ioplex at gmail.com
Thu Jul 3 14:41:18 GMT 2008


On 7/3/08, Steve Langasek <vorlon at debian.org> wrote:
> On Wed, Jul 02, 2008 at 10:06:12AM -0400, Michael B Allen wrote:
>  > On 7/2/08, Luke Howard <lukeh at padl.com> wrote:
>  > > On 02/07/2008, at 7:22 PM, Nilesh Lonari wrote:
>
>  > > > No, both Kerberos and NTLMSSP can't be done without SPNEGO support.
>
>  > > > Without SPNEGO, we would not be able to negotiate with the server which
>  > > one
>  > > > to use between the 2.
>  > <snip>
>  > >  [MS-SMB] section 5.2 implies that any GSS-API mechanism is supported
>
>  > The funny thing about SPNEGO w/ NTLM and Kerberos as mechs that many
>  > people don't realize is that it does not actually negotiate anything.
>
>  > Consider the two cases:
>
>  > a) Client sends NTLM but server wan'ts Kerberos: If a Windows client
>  > can't do Kerberos it doesn't send the Keberos OID so it leaves the
>  > server no choices.
>
>  > b) Client sends Kerberos but server want's NTLM: If the client was
>  > able to acquire a Kerberos service ticket the server has a valid
>  > service account so there should be no reason to reject it.
>
>  > SPNEGO is basically dead weight.
>
>
> If the server doesn't (want to) support kerberos, then this up-front SPNEGO
>  declaration, coming as it does in the negprot response packet (which already
>  has to be sent as part of the handshake), saves the client a round-trip to
>  the KDC to try to acquire a ticket.
>
>  And if the server declares that it doesn't support a particular mech, the
>  client knows not to bother with that mech; there's no need to generate more
>  pointless network traffic for an authentication that's guaranteed to fail.
>
>  That's not dead weight at all, it's a straightforward authentication
>  negotiation.

The MO that you describe is a hack and is not how the SPNEGO authors
intended it to be used. You will never see the server reject the
optimistic mech-token and request something else. That server
initiated SPNEGO business is unique to SMB. Also, I'm pretty sure
clients cache information about what was or was not successful so it's
questionable as to whether or not the server-initiated SPNEGO hack is
even worth it.

I don't know if SPNEGO provides any advantages regarding the
negotiation of integrity and confidentiality but otherwise, unless
some other mechs come into the fold, it's pretty much dead weight.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/


More information about the samba-technical mailing list