Using enterprise principal name in GSS-API

[Isaac Boukris]

On Mon, Sep 26, 2016 at 7:09 PM, Greg Hudson <ghudson at mit.edu> wrote:
> On 09/25/2016 04:32 PM, Isaac Boukris wrote:
>> The more a look at the code and on wire traffic, I think
>> enterprise-name and canonicalization are different things (although
>> related).
>> Here is what my tests against AD (w2k3) seem to show so far.
>>
>> First, the 'kinit' man page says -E implies -C but it doesn't seem to
>> be correct (according to observations).
>
> I see that we don't set the canonicalize KDC option when -E is given.
> Our KDC implementation treats AS requests as having the canonicalize
> flag if the client principal name type is KRB5-NT-ENTERPRISE-PRINCIPAL,
> with the comment "Note that according to the referrals draft we should
> always canonicalize enterprise principal names".  My reading of RFC 6806
> is more ambiguous; in section 5 (defining the enterprise name type) it
> says "The KDC will recognize this name type and then transform the
> requested name into the true principal name if the client account
> resides in the local realm."  But in section 6 (defining the
> canonicalize flag) it doesn't say that the canonicalize flag should be
> inferred from the principal type, and its example AS-REQ scenario
> includes both an enterprise client principal name and the canonicalize flag.
>
>> In such a case (no canonicalization), if the user is found, the KDC
>> returns AS reply with the exact name and name-type (enterprise) as
>> requested.
>
> Interesting.  That's probably not a behavior we want; enterprise names
> should ideally only exist on the edge of the krb5 protocol.  I also
> don't think that's the behavior we would see with an MIT krb5 KDC
> (combined with a third-party KDB module that implements enterprise
> principal name lookup).

I think earlier drafts of the RFC sounded more like MIT implementation logic.

Quote from the third draft:
"The KDC will always return a different name type than
KRB-NT-ENTERPRISE-PRINCIPAL.
This is regardless of the presence of the "canonicalize" KDC option."

However the standardized draft sound a bit less decisive, quote (on
enterprise-name):
"It is used for conveying the alias name, not for the real principal
names within the realms, and thus is only useful when name
canonicalization is requested."

I've run more tests against w2k8 and the behavior seem the same as in
w2k3, meaning it returns enterprise name-type if no canonicalization
was requested.
I think the name in the returned ticket is also enterprise type as I
get the same name format on acceptor side (something like,
user\@suffix at REALM).
However, windows acceptor indicates the canonical username (perhaps it
takes it from the PAC).

>> We probably want to support both enterprise-name and canonicalization
>> in GSS-API (the latter could be set via conf).
>
> I think perhaps we should be setting the canonicalize option whenever we
> make an AS-REQ with an enterprise client principal name, although I'm
> not entirely confident about this because Heimdal doesn't seem to do it.
>  (Heimdal's kinit actually seems to do the reverse; its kinit
> --canonicalize parses the client principal as enterprise even if
> --enterprise isn't given.)

Heimdal's approach doesn't look right, as the RFC doesn't seem to
limit canonicalization to enterprise names.
In fact, the old version (03) even gives an example of an
KRB-NT-PRINCIPAL canonicalized to an KRB-NT-UID.

Perhaps we could change the -E option to (actually) imply
canonicalization but at the API level I think I would prefer to have
both options as each makes sense in its way (IMO).

- Using enterprise name type indicate the KDC to look up the user by
an alias (implementation dependent, globally unique identifier - like
email, phone, upn).
- Enabling canonicalization to allow KDC to change name and name-type.

> I'm not sure how gss_acquire_cred_with_password() with its current
> signature could express a desire for the canonicalize flag, other than
> by importing an enterprise name.

Yea, it would have been useful to have a flag argument to overload.
In cred-store API we could perhap implement a mech_flags store, but it
doesn't support acquiring with password.

So I think I agree the simplest way would be to introduce a GSS
enterprise-name which would also imply canonicalization.