Kadmin service principal revisited
Nicolas.Williams at sun.com
Tue Sep 2 17:32:38 EDT 2003
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
<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,
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).
More information about the krbdev