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:
- 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