[Kdc-info] kdc-info meeting at ietf56

[Ken Raeburn]

Some random notes here, written up from memory after the meeting,
since we didn't think to have anyone take notes during it.  Feel free
to supply any corrections or missing details.

We had about eight or nine of us: me, Leif, Wyllys, Mortezza, Kurt
Zeilenga, Bob Morgan, Bob Joslin, and I know I'm forgetting (or didn't
catch) one or two other names; sorry about that.  We hadn't heard
anything from Donna, and assumed she wasn't around.  So we went to
find some space to talk for a while.

There was some discussion on administrative information model
specification versus KDC implementation details, and how we're
intentionally ignoring the latter for now.

We discussed minimal versus more comprehensive information models.
After concluding that a minimal model could leave out nearly
everything (e.g., principal expiration times may not be required, if
you can simply delete them; ticket lifetime limits may not be
important if your implementation always use short lifetimes), and
wouldn't be very useful at all, we started discussing what sort of
things might be in a more comprehensive model.  (As I recall, at the
last IETF, with a few more people involved, we had decided to start
working on a minimal useful model, though I don't recall the specific
arguments.  So I'm not convinced this new direction is necessarily
good.)

How should the realm be figured into the information model?

Kurt brought up the point that in an LDAP schema, information may be
distributed or may be per-server.  The MIT model, at least, assumes
everything is fully replicated from the master to the slave KDCs, and
nothing is updated by the slaves in normal usage.  This will be a more
interesting issue when we go from the information model to a schema.

Leif will start on a rough list of concepts from the various Kerberos
implementations, and send it to the list for further input.

Ken will review the LDAP password-modify and password-policy documents
and see how well they match what we're doing or what we need in
Kerberos.

Ken