[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: GSS-SPNEGO Protocol Details

On Tue, 30 Jan 2007 08:53:31 +0100
Volker Lendecke <Volker.Lendecke@sernet.de> wrote:

> On Mon, Jan 29, 2007 at 08:59:36PM -0800, Howard Chu wrote:
> > >  1) GSS-SPNEGO search replies are sealed even though the request was
> > >  not and a capture of another client talking to the same server shows
> > >  replies as integ-only. A examination of the captures of my code and
> > >  the other client shows the packets are identical (minus ber encoding
> > >  differences and encrypted krb5 bits).
> > 
> > That would normally require the confidentiality flag to be set on the 
> > ContextFlags of the NegotiationToken.
> 
> This is one thing that I've got confused over recently as
> well. Just from coincidence I did pretty much the same
> Michael did last weekend and I discovered the same
> asymmetry. However I was told that a standard GSSAPI
> exchange always contains the conf and integ bits, at least
> MIT 1.5.1 does so.

Hey Volker,

Consider the places security layer flags can be passed or used:

1) GSSAPI SASL performs an additional bind request/reply that negotiates
   the security layer flags (GSS-SPNEGO SASL does not do this).
2) SPNEGO has the reqFlags BIT STRING field
3) The checksum in a Krb5 authenticator can be hijacked to carry them.
4) gss_*_sec_context has req_flags and/or ret_flags
6) gss_wrap takes a confidentiality flag

Throw in QOP and related settings and I'm completely confused by all
of this.

And again back to my original observation. I took a capture of a Windows
script doing a simple LDAP query. The NegTokenInit did not have reqFlags
field present at all and the replies where NOT sealed (I still have this
capture BTW). I do the same thing with OpenLDAP and the search replies
are sealed. The packets are logically identical. The only explaination I
can think of is that it either has something to do with the fact that in
my case the credential used was delegated from a web server or that the
machine from which the Windows script ran was a member of the Windows
domain and there's some kind of policy involved.

> If I patch MIT to not set the bits
> (Samba4 also would let me do it), then I can get Windows to
> send signed-only replies. Maybe it's a Windows thing not
> following RFCs, but I wonder how I would tell a Server to
> send signed-only given that MIT krb always offers
> confidentiality.

Interesting. I was just trying to do this test too. Saves me the
trouble. Thanks. Unfortunately Heimdal has similar problems of it's
own. The 0.7 release doesn't set reqFlags in the NegTokenInit at all
(and it's commented out in 0.8) and if I hack it to construct reqFlags
it seems the BIT STRING is not encoded properly.

I guess I shouldn't waste my time until I move to 0.8 which has a
significantly reworked gss infrastructure. I'll just have to live with
encrypted responses. It's a feature :->

Mike