Hello,
I've implemented SASL binds for GSSAPI and GSS-SPNEGO using a Sockbuf_IO_Desc handler instead of libsasl. Everything works great but I've noticed some behavior from the server I'm using that is not consistent with the available documentation (RFC 2222 and draft-ietf-sasl-gssapi-03 by Melnikov). Would anyone happen to know where I might ask about GSS-SPNEGO protocol details? Is there an IETF mailing list somewhere?
There are three issues:
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).
2) GSS-SPNEGO does not appear to use the additional bind exchange to negotiate the security-layer bit mask like GSSAPI does.
3) GSSAPI can use what is apparently the DN of an account called the "authorization identity". The actual values for this field do not appear to be documented anywhere.
I don't suppose I should care since the code works fine but I do. Any pointers are appreciated.
Mike
Michael B Allen wrote:
Hello,
I've implemented SASL binds for GSSAPI and GSS-SPNEGO using a Sockbuf_IO_Desc handler instead of libsasl. Everything works great but I've noticed some behavior from the server I'm using that is not consistent with the available documentation (RFC 2222 and draft-ietf-sasl-gssapi-03 by Melnikov). Would anyone happen to know where I might ask about GSS-SPNEGO protocol details? Is there an IETF mailing list somewhere?
Have you already read RFC2478?
There are three issues:
- 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.
- GSS-SPNEGO does not appear to use the additional bind exchange to
negotiate the security-layer bit mask like GSSAPI does.
- GSSAPI can use what is apparently the DN of an account called the
"authorization identity". The actual values for this field do not appear to be documented anywhere.
An authorization identity is a standard concept in SASL. It can be a simple username or a DN.
I don't suppose I should care since the code works fine but I do. Any pointers are appreciated.
Mike .
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. 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.
Any ideas?
Volker
Volker Lendecke 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. 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.
When invoked from Cyrus SASL it will only offer confidentiality if the sasl-secprops are set with minssf > 1. Since you're talking about your own private SASL implementations obviously we can't tell.
On Tue, Jan 30, 2007 at 12:13:01AM -0800, Howard Chu wrote:
When invoked from Cyrus SASL it will only offer confidentiality if the sasl-secprops are set with minssf > 1. Since you're talking about your own private SASL implementations obviously we can't tell.
Hmmm. I have to look at Cyrus SASL, but I don't see a way how it would be able to not negotiate it. I'm talking about line 514ff in src/lib/gssapi/krb5/init_sec_context.c of MIT krb 1.5.1:
ctx->gss_flags = (GSS_C_INTEG_FLAG | GSS_C_CONF_FLAG | GSS_C_TRANS_FLAG | ((req_flags) & (GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_SEQUENCE_FLAG | GSS_C_DELEG_FLAG)));
This way it does not look at the req_flags given to it via gss_init_sec_context(), it just unconditionally sets GSS_C_CONF_FLAG. If I change it to take GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG from req_flags, then it does work as I would expect.
I hope I don't look stupid here... :-)
Volker
Volker Lendecke wrote:
On Tue, Jan 30, 2007 at 12:13:01AM -0800, Howard Chu wrote:
When invoked from Cyrus SASL it will only offer confidentiality if the sasl-secprops are set with minssf > 1. Since you're talking about your own private SASL implementations obviously we can't tell.
Hmmm. I have to look at Cyrus SASL, but I don't see a way how it would be able to not negotiate it. I'm talking about line 514ff in src/lib/gssapi/krb5/init_sec_context.c of MIT krb 1.5.1:
Sounds like a question for an MIT Kerberos list. I haven't looked at the MIT code in a while and don't plan to any time soon. Anyway, it's not an appropriate use of this list to explore those details here.
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
-
Howard Chu -
Michael B Allen -
Volker Lendecke