Fixes for S3 DCE/RPC GSSAPI with Heimdal

[Luke Howard]

>> The only problem with this is that some mechanisms may return dynamically allocated OIDs. e.g. in the GSS EAP mechanism, we don't know the complete set of mechanisms at compile time (think dynamic sub-mechanisms). For the concrete mechanisms we know about, we can intern the OIDs (so they are constant), but otherwise we may return allocated OIDs.
> 
> Wouldn't they eventually return static data from inside the
> sub-mechanism?

Not necessarily because the mechanism variation is composed at runtime. For example, the GSS EAP OID is a prefix concatenated with an integer representing the RFC 4121 encryption type; we enumerate the supported encryption types at runtime.

> The problem I have with this is that the only documentation I can find
> for this function (from man pages in proprietary unixes) make it clear
> it's constant.  Samba can't be the only application with this puzzle. 

You can see RFC 2078, it's not really that clear either (and it doesn't appear in RFC 2744). Ask Nico Williams, he will have some thoughts.

> Can you point me at a spec for how exactly this should work?  I would
> far rather use something like this that doesn't have Samba parsing
> AD-IF-RELEVENT blobs manually.  

You do gss_get_name_attribute(name, "urn:mspac:") (or, even, gss_get_name_attribute(name, "urn:mspac:logon-info") and you get back a blob and an authenticated/complete flag. Check the authenticated flag is TRUE and then process the data. The code is in src/lib/krb5/krb/pac.c, in MIT.

At some point I need to write a plugin that decomposes the PAC even further so you can do gss_get_name_attribute(name, "urn:mspac:logon-info:userid")...

-- Luke