Re: [x500standard] Password policy PDAM

Howard Chu wrote:
> I'll followup later with another review in terms of the current LDAP ppolicy
> draft.

As David Chadwick suggested, it would be a good idea to align the names and 
OIDs of the policy elements that are semantically the same. Here's a 
comparison of where things stand right now.

X.500			LDAP
pwdAdminSubentryList/
pwdPolicySubentry	pwdPolicySubentry

    The LDAP definition is single-valued; only one policy is allowed to apply
    to the password attribute of an entry. (But if multiple password
    attributes are in use, then each can have its own policy.) In LDAP if
    multiple policies have overlapping coverage the behavior is undefined.

pwdAdminSubentry	pwdPolicy

myPwdAttribute		pwdAttribute

passwordHistory		pwdHistory

    Currently it looks like these two are not compatible.

recentlyExpiredPassword

    No analogue in LDAP spec. Could be added I guess.

passwordHistoryMatch

    No analogue in LDAP, history just uses octetStringMatch.

pwdStartTime		pwdStartTime

    Basically the same, but X.500 pwdStartTime is also set whenever a
    password is changed. LDAP uses pwdChangedTime for this purpose. The
    reason for the distinction: an admin may decide to set a password
    on an account, but leave it disabled until some time in the future.

    The most common example use-case is in schools/universities - hundreds
    or thousands of accounts may be created in advance for an incoming
    class of students. Their pwdStartTime will be set to the first day of
    class, while their pwdChangedTime will reflect the time their password
    was actually created.

pwdExpiryTime

    No analogue in LDAP. Could be added.

pwdEndTime		pwdEndTime
	
    Basically the same. We should adopt the X.500 description for the
    LDAP spec.

pwdFails

    LDAP uses pwdFailureTime which records the timestamps of the failures,
    not just a count of the failures.

gracesUsed

    LDAP uses pwdGraceUseTime which records the timestamps of each
    usage, not just a count.

The LDAP spec has 3 more operational attributes that appear to be missing from 
the X.500 spec:
	pwdAccountLockedTime - the time that an account was locked.
	pwdReset - a boolean that indicates a user must change their password (e.g. 
because it was set by an administrator).
	pwdLastSuccess - the timestamp of the last successful authentication


Policy schema:

X.500			LDAP

modifyEntryPwdAllowed

     No analogue in LDAP

changePwdAllowed	pwdAllowUserChange

     Basically the same

pwdMaxAge

     Missing in LDAP. Adding it will be tricky since we already use a 
pwdMaxAge attribute, for expiration.

pwdExpiryAge		pwdMaxAge

     Basically the same meaning; LDAP is missing the ordering rule.

minPwdLength		pwdMinLength

     Basically the same. LDAP also has pwdMaxLength, as some systems only work
     with some small length (e.g. 8 or 16 on some legacy platforms).

pwdVocabulary
pwdAlphabet
pwdDictionaries

     Missing in LDAP. Should consider adding them.

pwdExpiryWarning	pwdExpireWarning
pwdGraces		pwdGraceAuthNLimit
pwdLockoutDuration	pwdLockoutDuration
pwdMaxFailures		pwdMaxFailure

     Basically the same, besides choice of spelling. LDAP is missing the
     ordering rule.

pwdFailureDuration	pwdMinDelay

     LDAP also requires pwdMaxDelay if pwdMinDelay is set.

pwdMaxTimeInHistory
pwdMinTimeInHistory

     No analogue in LDAP, should consider adding it.

pwdHistorySlots		pwdInHistory

     Similar; LDAP doesn't specify a minimum value. Absence / 0 implies no
     history tracking.

recentlyExpiredPwdDuration

     No analogue in LDAP.

pwdEncryptionAlg

     No analogue in LDAP. Password hashing is implementation-specific.

The LDAP spec also defines pwdMinAge, pwdCheckQuality, pwdGraceExpiry,
pwdLockout, pwdFailureCountInterval, pwdMustChange, pwdSafeModify, pwdMaxIdle.

Kurt Zeilenga's draft makes an argument against using pwdMinAge, we should 
consider dropping it from the LDAP spec and augmenting the history policy 
attributes instead. pwdCheckQuality would be superseded by pwdVocabulary,
pwdAlphabet and pwdDictionaries.

pwdGraceExpiry should probably be added to the X.500 spec; i.e. there should 
be some provision for aging out grace logins.

pwdLockout simply controls whether failure-based lockouts will be enforced or not.

pwdFailureCountInterval defines the number of seconds after which password
failures are automatically purged, even though no successful authentication
occurred. It's a bit of a bandaid to allow recovering from a failure lockout.

pwdMustChange controls whether administrative password changes will require 
the user to change their password immediately on next login.

pwdSafeModify controls whether the old password is required or not in a 
PasswordModify operation.

pwdMaxIdle disables an account if it has not been logged into within the 
specified interval. It may be a good idea to add this to the X.500 spec.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/