Kadmin service principal revisited

[Nicolas Williams]

On Fri, Aug 29, 2003 at 04:36:55PM -0400, Sam Hartman wrote:
> Greetings.  As you may recall we agreed some time early this year that
> we would change the kadmin service principal from kadmin/admin at REALM
> to kadmin/hostname at REALM in order to be compatible with Sun as we
> picked up the the new RPC code.
> 
> Having audited many of  the related patches, I'd like to revisit this
> decision.  
> 
> This change seems to have a number of negative effects.  First, it
> assumes than the hostname returned by gethostname() is related to the
> name of the interface on which clients will connect.  I.E. it assumes
> that gethostbyname(gethostname()) will give you right principal
> component to use.
> 
> I'm concerned that this will be a regression in usability.  In
> particular, I believe it will work less well with multi-homed hosts,
> will have more of a DNS dependence, and will  be harder to support.

I believe others have taken care of this concern already.  This is a
non-issue because: a) the name of the kadmin server will generally be
obtained from either local configuration or from DNS SRV RRs.  If a
kadmin server has multiple addresses and canonical names this is still
not an issue (the client knows which name it wants and will obtain the
right set of addresses for it).

If a kadmin server has multiple addresses, multiple canonical names and
servers multiple realms, then either it will run multiple instances of
kadmind, one for each realm and bound to a single canonical hostname's
addresses, or it will run a single kadmind for all of those realms and
it will use GSS_C_NO_CREDENTIAL to accept GSS-API contexts for all of
its principal names.  (Note too that, even if kadmind is using the KDB
as its keytab, using GSS_C_NO_CREDENTIAL as the acceptor credential does
not introduce any replay issues because: a) RPCSEC_GSS has its own
replay protection and b) because kadmind can always inquire the GSS
contexts to determine what the client named it and, therefore, what
realm the client means to admin, plus, the server can reject any
requests where the target principal name was not a kadmin name.)

> However, if we keep kadmin/admin, we will have replay cache issues if
> we ever go to a multi-master setup and we will have an unnecessary
> incompatibility with Sun.  It's my understanding from Sun that they
> consider any compatibility with our admin protocol an accident, so
> even if we happen to be compatible with Sun, there is no guarantee
> that will be the case in the future.

Firstly, RPCSEC_GSS has its own replay protection[*].  Kadmin is an ONC
RPC protocol using the AUTH_GSSAPI (MIT) or RPCSEC_GSS (Sun) ONC RPC
security flavors, and we're talking here about MIT adding support for
RPCSEC_GSS, so we don't have to worry about replay caches here (as long
as clients do not use any one target principal name with RPC and non-RPC
protocols, which kadmin clients wouldn't do).

Secondly, while we do not currently guarantee that the MIT kadmin +
RPCSEC_GSS would be compatible with Sun's, and while we are interested
in replacing kadmin with an LDAP-based KDB admin interface[**], we are
also interested in interoperability between MIT's and Sun's kadmin
implementation at least until such a kadmin replacement is available.
Therefore, once MIT has RPCSEC_GSS support Sun may commit to supporting
interoperability between MIT's and Sun's kadmin

[*]   The AUTH_GSSAPI flavor that MIT uses now also appears to offer
      replay protection.  The replay protection afforded by RPCSEC_GSS
      does depend on the server RPC layer issuing sufficiently
      unpredictable context handles.

[**]  As discussed in the KRB WG and kdc-info lists.

Cheers,

Nico
--