[Kdc-info] blasphemy

[Ken Raeburn]

Leif Johansson <leifj at it.su.se> writes:
>     * Is the keyversion associated with the key or with the principal?

With the key -- or, perhaps, a set of keys.  We might want the model
to reinforce "my key is at version 4 and supports triple-DES and RC4"
rather than "my DES key is at version 4 and my AES key is at version
5".  At least, I *think* that's the way it needs to work.  I haven't
tried to really wrap my head around a way of making the second
approach work, but I don't think it would.  But maybe the model
doesn't necessarily need to reinforce that.

Not associated with the principal -- if you want to rekey a service,
you want to keep the old key around on the KDC a while so people can
renew tickets previously issued.

What "flags" do you imagine being associated with a key?
At this level, isn't it appropriate to spell them out?

>     * Is the auxilliary key data (I was thinking about AES
> requirements) appropriate?

We need something like that, but I'm not sure how to store it.  All
the KDC would care about would be the octet string form, but that's
not what the admin system is going to care about.

>     * What exactly goes into password policy?

Good question.  I'll try to get to looking over the LDAP password
policy stuff soon, for some ideas.

Some random thoughts:

I think there would be at least two categories of password-related
policies: (1) when is a password change needed (including "now"); (2)
what new passwords are allowed.  I don't know if they'd be entirely
independent; "you chose a short password, so you're going to have to
change it again tomorrow."  "When is a password change permitted"
needs to be covered, but probably would fit in one of those two
categories.

Non-password policies and other info:

 - require preauth? what kind? handle for auxiliary data for preauth
   system, which might or might not be associated with key version
   numbers. (srp: probably associated with key and kvno; smart card:
   not associated)

 - can initial tickets be issued for this principal?  (probably not
   for many random service principals, in many environments)  boolean?

 - can service tickets be issued for this principal?  (probably not
   for most user principals with relatively weak keys) boolean?

 - supported encryption types for service principals, since Kerberos
   doesn't allow the client and server to negotiate.  MIT currently
   overloads the set of service keys for this purpose, but they really
   should be separate.

Principal aliases?

(Sorry for the rambling, I'm trying to head home shortly, and just
want to get some of this down so I don't forget it.  Let me know if
I'm diving into too low a level of detail for the stuff we want.)


BTW, I'm wondering if we should revisit the conclusion we came to (in
Atlanta?) that the "minimal model" approach boiled down to almost
nothing and thus wasn't interesting.  A "minimum practical model"
probably wouldn't use some of the hacks we were talking about (like
having clients renew tickets frequently in lieu of storing max ticket
lifetimes and/or expiration dates in the database), but wouldn't need
nearly all the features the current KDC databases support.

I think Sam or someone else at the London(?) meeting argued for it,
and wasn't there when we decided to drop it.  I don't recall the
arguments for doing the miminal model.

Ken