re: the "guessing limit" - as braindead as this feature may be, many sites are
required to support it due to Sarbanes-Oxley or various other government
regulations. I think the best thing to do here is note that it is
bass-ackwards from a security point of view, but because ignorant policy
makers require it, it is included in the spec. I.e., provide the feature but
fully document why it's a bad feature and provide alternatives to use in its
place.

re: lockout - it may be beyond the scope of "password policy" management but
the solution is needed. In the absence of any additional work occurring in
this area in a year and a half, it seems best to simply expand the scope of
this spec - to include rudimentary account management - and define formal
mechanisms for account expiration and disablement.

re: protocol extension - that section appears to be missing from the draft.
While providing this info at other times may be useful, the most common case
for users to interact with the password policy machinery is at login time, so
it's not clear what other cases you wanted to allow for. If I successfully
change my password and get a reply "by the way - your password will expire in
90 days" I will promptly forget it, nor do I actually need to spend any time
thinking about it until shortly before it expires again.

re: bind and compare - ok, certainly we should discourage use of Compare as an
authentication method.

re: password history storage - it may be a local matter, but I think we should
still provide an Informational definition here, because leaving it up to each
individual site to implement will cause too much wheel-reinvention and will
harm interoperability.

At this point we have several years worth of accumulated experience with
deployments of the Behera draft. We shouldn't throw that away. Most of the
issues you address can be fixed as an incremental revision of Behera.

Requests for an absolute expiration/lockout mechanism keep coming up time and
again. It's too small a feature to merit its own document. We should simply
add a couple new attributes to the existing Policy schema and be done with it.

Another item that has come up from my perusal of Kerberos KDC policy - in
addition to specifying a time when a password stops being valid, it would be
nice to provide an attribute specifying the time when a password *starts*
being valid.