[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
this.
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.
Issues:
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).
Cheers,
Nico
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
>