[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ASN.1 BITSTRING and NegTokenInit.reqFlags



On Sat, 23 Feb 2008 11:29:06 +0100
Love Hörnquist Åstrand <lha@kth.se> wrote:

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

Excellent. So by the time I migrate from 0.7.2 it should all work.

Thanks,
Mike

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