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

Re: [xad] Re: FW: SSPI client

Ok, I looked around a bit more and spent 5 min with an older Heimdal on 

Here's how far I got on the ASN.1 SPNEGO front:

1. I made an spengo.asn1 file and pasted in the ASN.1 from the SPNEGO 
RFC (2478?)
2. I changed "NegotiationToken" from a CHOICE to a SEQUENCE, with the 
two members being optional
3. I changed the one ENUMERATED (negResult) to INTEGER
4. I changed MechType to be "OCTET STRING"

This runs just fine through Heimdal's ASN.1 compiler and is pretty 
close, but not enough, to the RFC's defs.


1. Heimdal's ASN.1 compiler doesn't grok OIDs. Since GSS-API is so light 
on ASN.1 and the OIDs are all constant, Heimdal hacks that in when 
encapsulating the krb5 mech token

2. Heimdal doesn't do CHOICE. It should be fairly simple to either make 
Heimdal's asn compiler support CHOICE *or* hack it.

3. Heimdal doesn't support ENUMERATED types. Good news: ENUMERATED is 
encoded the same as INTEGER, but with a type tag of 0xA0 instead of 
0x02. Bad news: Heimdal's ASN.1 compiler caters to krb5 ASN.1, which is 
not true ASN.1 because MIT krb5 violates the ASN.1/DER specs in some 
places, like with INTEGER, where, IIRC, MIT krb5 (and therefore all 
other Kerberos V implementors) always writes four bytes for INTEGERs on 
the wire, even though the minimum needed might be one byte. In the case 
of negResult, it will always need only one byte of the integer written 
on the wire... Perhaps, similarly with the BIT STRING encoding.

So, the upshot is:

A. CHOICE must be dealt with manually (easy, it's the top-level of 
SPNEGO anyways) or support must be added to the ASN.1 compiler.

B. Support for OBJECT IDENTIFIER is needed in Heimdal's ASN.1 compiler, 
though not full support. Just enough that the C code can pass in the 
existing constant OIDs.

C. Heimdal's ASN.1 compiler and supporting encoding/decoding functions 
need to have support for ENUMERATED. This should be fairly easy. I think.

Finally, one more note: I've never seen rtaces of real SPNEGO packets, 
so I don't know whether the SPNEGO spec caters to the bastardized krb5 
ASN.1 or to the real ASN.1 spec and there is one more potential issue on 
that front: the ContextFlags BIT STRING. MIT krb5 also doesn't write the 
min number of bytes needed to encode a given BIT STRING value.

Eventually Heimdal's compiler will have to be made to support 
bastardized MIT krb5 ASN.1 and true ASN.1 (or a subset thereof), or the 
new krb5 ASN.1 description you can see in the RFC1510 revisions draft 
(which tries to fix the bastardized ASN.1). Or it could be replaced, I 
suppose; maybe SNACC is upto the task, maybe something else, but I think 
Heimdal's is pretty decent as it stands (it does the job).



Luke Howard wrote:

>>Heimdal contains an ASN.1 parser/compiler. It lacks support for CHOICE. 
>>But CHOICE is a really simple concept. It shouldn't be hard to implement 
>>it. I'll see if I can get my head around the Heimdal ASN.1 parser code...
>Well, if Assar is working on it I'll likely leave it to him. But yes,
>we probably only need to negotiate krb5 now, although I think it
>would be real easy to write a GSS-API mechanism in terms of Luke
>Leighton's ntlmssp library -- particularly as Microsoft do not
>use ASN.1 for it!
>>Once you have support for CHOICE in Heimdal's ASN.1 compiler it should 
>>be fairly straightforward... To build an SPNEGO token you first build a 
>>krb5 GSS token, sans GSS-wrapper, then stuff it into a negTokenInit as 
>>the mechToken, make a mechTypes, do a GetMIC on that, stuff that into 
>>the negTokenInit as the mechListMIC, add in the reqFlags and then make 
>>the NegotiationToken, which in turn becomes the mechToken for the actual 
>>GSS token. Pretty simple. And NegotiationToken is just a CHOICE, meaning 
>>nothing, there's nothing to it really.
>>So even without CHOICE support in the parser, it should be possible to 
>>muddle through by just ignoring the CHOICE altogether.
>Was that a pun (muddle)? :-)
>-- Luke
>Luke Howard | lukehoward.com
>PADL Software | www.padl.com