[Kdc-info] policy-as-code

[Ken Raeburn]

Leif Johansson <leifj at it.su.se> writes:
> I had a discussion with Love Hörnqvist-Åstrand who had an
> interesting point concerning policy-requirements in a kdc which
> makes me dobout the long-term feasability of modelling policy in the
> directory. The argument goes something like this (Love: Please
> correct me on the list if I got you wrong, ok?):

> Today policy can be described in terms of a fixed set of parameters
> (password expiry days for instance) but this may be inadequate to
> describe more complex but necessary policy. For instance try to
> express: all */admin must have more than 4 iterations in AES or only
> requests coming from a certain set of hosts are allowed to obtain
> tickets for foo-service/foo.example.com at EXAMPLE.COM.

The "can't obtain tickets" restriction based on random parameters
bothers me.  If we don't want the user to be able to use the service,
that's an authorization issue.  Why are we preventing the user from
*authenticating* to it?  Maybe there's some perceived "level" of
authenticity that's based on the IP address or iteration count?  Fine;
express it in the tickets, and make an *authorization* decision based
on that.  But, that aside....

I don't think I'd try to express that as one single policy.  It may
make more sense to an administrator that way, and it might be nice if
the UI would present it that way, but at the KDC level, I see it as at
least multiple policies applied at various times:

 - What iteration counts are acceptable for AES for this principal?
   This is relevant at password changing time, or whenever it is you
   allow the user or administrator to tweak the iteration count.

   It's not part of the change-password protocol, last I checked.  And
   it probably won't be in the LDAP password policy stuff we want to
   see about building on.

 - What constraints or privileges are applied to a TGT or other
   initial ticket issued to a client on a particular host?
   (can/cannot get foo-service tickets, okay/not-okay for really
   paranoid services in general, "level" of authenticity, etc)

 - Is a particular client on a particular server with a particular key
   type and X parameters allowed to get initial tickets for service Z?

Applying restrictions or privileges to the TGT based on the database
entry, the PBKDF2 iteration count, the encryption type chosen (you
probably wouldn't want to allow access to foo-service using single DES
either), the client IP address, and possibly other data, that's hard
to express in any general form without a programming language.

Maybe it would be better to just allow for additional locally-defined
(or not yet standardized) options referenced by name, OID, whatever,
and implemented through local code changes, perl scripts stored as
data, etc.  For the benefit of the UI, perhaps these local policy
knobs should have names and/or descriptions accessible in some
standardized way, and probably should be collected in a list somewhere
so a confused admin can't specify a policy object that doesn't exist.
It's not like arbitrary network entities have to be able to apply
arbitrary policies, is it?

Or does this lead to the cpim mess you mentioned?

Ken