Password quality pluggable interface scope

[ghudson@MIT.EDU]

Before I even write up a project for the password quality interface, I
want to discuss what it should be capable of.

Currently, when you change your password, kadmind applies various
checks:

1. It rejects empty passwords.  This is the only check if the
   principal has no associated policy.

2. It checks against the realm's configured dictionary file.

3. It checks against elements of the principal name.

4. If built with hesiod support (I kind of hope no one does this), it
   looks up the Hesiod passwd information for each principal component
   and checks against the GECOS information therein.

5. It enforces the minimum length and minimum number of character
   classes as determined by the password policy.

6. It checks password history against one or more recent keys, and
   stores a password history entry for the current key set.

Russ's krb5-strength package contains a patch adding pluggability to
krb5 1.4.  It ties into the infrastructure for (2), so plugin modules
using this interface only run if the principal has a password policy.
Plugin modules get access to the realm's dictionary filename at init
time, and the principal name (as a string) and new password at check
time.  Modules using this interface could perform checks in the style
of (1)-(4) easily, but doing anything like (5)-(6) would be difficult
and probably unsafe.

I'm considering several options for the scope of the 1.9 password
quality pluggable interface.  In all cases, the interface will have
init, check, and cleanup methods, where the purpose of init/cleanup is
to allow the module to read in the realm's dictionary file and store
it in memory.

* The most basic: the module gets access to a krb5 context, the
  dictionary filename at init time, and the principal name (as a
  krb5_principal) and new password at check time.  This has similar
  properties to Russ's interface, allowing checks in the style of
  (1)-(4).  There are three sub-options here:

  - Only invoke check method if there's a password policy.
  - Invoke check method whether or not there's a policy.
  - Pass a boolean argument indicating whether there's a policy.

* The module's check method could also be given access to the password
  policy structure.  This makes the interface dependent on kadmin.h
  and kdb.h and thus inherently less stable, but allows checks in the
  style of (5).

* The module's check method could be given access to the KDB entry and
  be allowed to change it.  This allows checks in the style of (6),
  but provides the least isolation and safety between core code and
  plugin.

Any current checks which fit within the scope of the interface would
likely become built-in modules (which could then be disabled through
plugin configuration directives, although that's not important since
almost all of them can already be disabled in other ways).  Checks
which do not fit would be considered out of scope for the pluggable
interface.