Fixes for S3 DCE/RPC GSSAPI with Heimdal

[Andrew Bartlett]

On Tue, 2011-04-19 at 14:24 +0200, Luke Howard wrote:
> >> 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,

Am I correct in saying that MIT kerberos versions (1.6?) that don't
provide gss_get_name_attribute() also do not provide any way for the
caller to verify the PAC?  In particular, I can't see a way to get the
service keyblock back from GSSAPI.  

The reason I ask is that it seems that it is impossible to securely use
the PAC in versions 1.6 and below, and I want to ensure we don't release
Samba 3.6 with a security hole.

Simo,

If this is the case, should we simply decide not to support GSSAPI
secured RPC against MIT 1.6? (that version I think had gss_wrap_iov but
not gss_get_name_attribute). 

I am writing a wrapper that checks the name and timestamp, but this
seems pointless if we don't check the actual signature on the PAC.

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org