Fixes for S3 DCE/RPC GSSAPI with Heimdal

[simo]

On Wed, 2011-04-20 at 17:05 +1000, Andrew Bartlett wrote:
> 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.

I think signatures were always verified, but I need to confirm that.
Alternatively I am ok with making this code incompatible with MIT < 1.7
(or whatever version we deem sufficiently secure) if we have no other
way to verify signatures.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>