Extensible kadm5 policies

[Russ Allbery]

Nico Williams <nico at cryptonector.com> writes:

> The point: we need a decent, stable, generic kadmin API and protocol.
> It's about time we had one.  Maybe we should settle on Russ' rem_ctl?
> or Roland's krb5_admin?  But since those are layered above the core KDC
> kadmin/kadm5 interfaces, even settling on those is risky as long as the
> kadmin/kadm5 interfaces are unstable.

I haven't taken a detailed look at krb5_admin, so I can't comment on it.

I've thought about proposing my remctl API or something similar to it as a
better Kerberos administrative API, but after more consideration, I don't
think that, at least by itself, is the right direction to go.  remctl is
very intentionally an 80% solution; it's designed to very quickly turn a
set of command-line tools into an SOA so that one has no excuse for not
creating an SOA.  With that goal, it's very effective.  But that doesn't
necessarily make it a good choice when designing a network protocol for
complex data administration from scratch or close to.

One of the tradeoffs that remctl makes in order to be dead-simple and
super-fast to deploy is that the protocol itself does not structure the
data.  It essentially just exports the UNIX command line interface over
the network with authentication and privacy.  You can, of course, send
structured data over that protocol, but it doesn't help you.

The Kerberos administrative interface really wants structured data.  What
form that structure takes is likely to be a huge argument; these days,
since I'm doing more and more web stuff, I tend to prefer XML or JSON, but
I'm sure others would rather use an RPC layer, and Kerberos has a lot of
binary data, which has to be encoded to put into XML or JSON.  But either
way, there should be structure, and the API should be defined in terms of
passing structured and typed data.

All remctl really gives you is a Kerberos-authenticated and encrypted
network pipe.  My slight understanding of krb5_admin is that it uses a
similar sort of underlying pipe (provided by knc) to build something more
akin to an RPC layer that can support structured data, which would make it
a more natural choice.

Unfortunately, the way the networking protocol world seems to work at the
moment is that the widely implemented and super-popular structured data
formats (XML and JSON) come with protocols with horrible security stories
(HTTP), and the protocols with good security stories (such as various
Kerberos-authenticated RPC layers, or even things like LDAP that use SASL)
use opaque and annoying structured data formats that involve things like
ASN.1 and which no one uses outside of those specific application areas.

krb5_admin, from what I know about it, avoids both of those problems, but
does have the issue that I don't think either its network protocol or its
RPC layer are used by anything other than it, and therefore the software
ecosystem around it is not large.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>