[37723] in Kerberos
Re: Using enterprise principal name in GSS-API
daemon@ATHENA.MIT.EDU (Alan Braggins)
Thu Oct 6 14:29:36 2016
To: kerberos <kerberos@mit.edu>
From: Alan Braggins <alan.braggins@brocade.com>
Message-ID: <5d6e2a7f-e8c1-6d62-540d-e1cba20abcec@brocade.com>
Date: Thu, 6 Oct 2016 19:29:00 +0100
MIME-Version: 1.0
In-Reply-To: <917ff64e-8040-e732-b2d4-9acaa15c1da9@mit.edu>
Reply-To: alan.braggins@brocade.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
