Kadmin service principal revisited

[Nicolas Williams]

On Tue, Sep 02, 2003 at 02:31:47PM -0400, Sam Hartman wrote:
> I'm sort of disappointed in the responses I got on this issue.  The
> responses seemed to fall into two categories: responses that focused
> on the wrong issues or responses based on false assumptions about how
> the proposed patches actually work.
> 
> The focus on the wrong issues are my fault and I'll try and clarify
> what I'm asking about.  The client handling of the behavior is
> actually reasonably simple.  The proposed patches do not seem to do
> all the canonicalization steps I'd expect; they seem to pull a name
> directly out of a configuration file and not canonicalize it
> additionally.  But that can be changed.  The only real client-side
> concern is the change in the meaning of the arguments to the kadmin
> API.

<flashbacks to KDC-side target principal aliasing & secure client-side
principal name canonicalization discussions>

> The real concern is on the server side and on database setup.  That's
> where gethostname() is called and where a hastname-based principal
> name is used.

I've proposed GSS_C_NO_CREDENTIAL.  See below.

[...]
> But I'm more concerned about usability regressions when compared to
> the previous kadmin than about whether other parts of the system have
> the same usability bugs.
> 
> Many people suggested allowing multiple principal names.  That's not
> supported by the contributed RPC library either at the API or code
> level.  Using GSS_C_NO_CREDENTIAL is not an acceptable option, because
> the "keytab" in question is the entire KDC database.  I could add
> support--either using GSS_C_NO_CREDENTIAL and then checking the
> result, or using several credentials and trying each.  

I think either using GSS_C_NO_CREDENTIAL + gss_inquire_context() to
verify that the target name used by the client is a kadmin name, OR
using several credentials and trying each in succession would work fine.

The Sun RPCSEC_GSS API cannot currently support either mode without
overloading the semantics of rpc_gss_set_svc_name() or otherwise
extending the API (see below).

> But my question is what is the justification for this work.  Do we get
> anything out of kadmin/hostname over kadmin/admin than Sun
> compatibility?  I'm not saying that Sun compatibility isn't enough,
> simply that I want to understand what tradeoff I'm making.

Sun compatibility is one reason.  The lack of a GSS-API name type
corresponding to "kadmin/admin" is another.  

The Sun RPCSEC_GSS API assumes the use of host-based service principal
names.  Specifically, rpc_gss_set_svc_name() and rpc_gss_seccreate()
assume the use of host-based service principal names.

Perhaps the RPCSEC_GSS API should be enhanced to support other GSS-API
principal name forms.  But there exist only two useful GSS-API name
types and no instance of those maps into "kadmin/admin" Kerberos names.

So what to do?

One answer may be that, though kadmin uses ONC RPC it doesn't have to
support generic GSS-API mechanisms, so to hell with the name type issue,
just fix the API to support kadmin/admin.  Another answer may be to add
a new name type to the GSS-API and extend the RPCSEC_GSS API to support
all GSS-API name types.  Or we can stick to hostbased service principal
names for RPCSEC_GSS servers and go from there.

Here's what I propose: use host-based principal names for kadmind and
overload the "principal" argument of rpc_gss_set_svc_name() to support
an extended principal name syntax, e.g., "<service>@*" name syntax
(whose semantics would be as described above, using either
GSS_C_NO_CREDENTIAL+gss_inquire_context() or multiple credentials with
names corresponding to the server's names (canonical and, possibly,
aliases).

Clearly, the <service>@* / GSS_C_NO_CREDENTIAL+gss_inquire_context()
approach is the simplest, but what is the impact of using that with the
KDB as the keytab?  With the use of <service>@* syntax the RPCSEC_GSS
layer can send back an error (and not the AP-REP) if the client used a
non-kadmin name, and replays of other kadmin conversations won't work
(because RPCSEC_GSS has its own replay protection).

Cheers,

Nico
--