Re: ASN.1 BITSTRING and NegTokenInit.reqFlags

[Love Hörnquist Åstrand <lha@kth.se>]

Hello Michael,

> Heimdal's NegTokenInit.reqFlags is unconditionally set to NULL in
> lib/gssapi/spnego/init_sec_context.c:spnego_initial. It seems this
> causes AD to think that it should do whatever it wants which is to use
> both integrity and confidentiality. If you then don't use integrity on
> LDAP SASL buffers, AD will simply not respond and the LDAP operation
> will timeout. If you don't use confidentiality on LDAP SASL buffers,
> AD will return encrypted responses.
>
> It seems the last time I looked into this the ultimate source of the
> issue was that ASN.1 BITSTRING fields where not encoded in the way AD
> wanted. Is this still an issue? If not, has there been any thought to
> getting the NegTokenInit.reqFlags included properly so we can turn off
> integrity and confidentiality if desired?
>
> Currently it's not a big deal because I can simply add integrity if  
> the
> cred is SPNEGO and I would be happy to provide a fix for this when I
> migrate from 0.7.2 to the latest Heimdal (assuming BITSTRINGs are  
> encoded
> ok now).

BITSTRINGs are now encoded in SPNEGO as the asn.1 standard specifies.

The Kerberos BITSTRING are tweeked with "asn1_compile --encode-rfc1510- 
bit-string" to make them encode all 32 bits and and not drops the  
trailing zeros as it should be done when using name bitstrings.

One additions problem is that the Kerberos mech always show support  
for INT + CONF, so its hard to know what was selected. See Stefans  
mail about this issue a couple of days ago. I started to add a flag to  
the initial cred to allow not sending INT + CONF flags yesterday,  
still working on that.

Love