Using enterprise principal name in GSS-API

[Alan Braggins]

On 23/09/16 15:50, Greg Hudson wrote:
> On 09/23/2016 03:52 AM, Isaac Boukris wrote:
>> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME,
>> though I guess it's more complicated than it sounds :)
>
> I think that might be reasonable for this use case.  I've seen requests
> to be able to import enterprise principal names before, although (IIRC)
> sometimes for use cases where it might not have made as much sense.
>
> The concerns I can immediately think of are:
>
> * Is there any prior art we should try to be compatible with?  I don't
> see any in Heimdal, and MS doesn't directly implement GSS-API, so I
> don't think there is.
>
> * If someone uses one of these GSS names in a different scenario (e.g.
> for an acceptor credential), will it fail gracefully?  I believe that's
> generally the case.
>
> * Does canonicalization at cred acquisition time pose any issues for the
> GSS-API model, because the name you get creds for won't be the same as
> the name you asked for?  gss_acquire_cred_with_password() is an
> extension, not a standardized part of the API, so I think it shouldn't
> be a problem.

I do have a patch that adds gss_nt_krb5_name_enterprise as a
recognised OID (szOID_NT_PRINCIPAL_NAME 1.3.6.1.4.1.311.20.2.3),
and replaces a call to krb5_parse_name with krb5_parse_name_flags
with KRB5_PRINCIPAL_PARSE_ENTERPRISE in gssapi/krb5/import_name.c

It doesn't address any of your concerns though, and I'd welcome
suggestions for a better approach.

(I'm using gss_acquire_cred_impersonate_name with protocol transfer
and constrained delegation.)

-- 
Alan Braggins