[x500standard] Re: New draft on password policy
- From: David Chadwick <d.w.chadwick@xxxxxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Mon, 21 Sep 2009 17:28:04 +0100
Hi Howard
Here are our responses from today to the issues you raised below. If an
issue has not been answered, this means we have not had time to address
it yet and will do so tomorrow. Any comments you have on our
deliberations so far will be appreciated
Howard Chu wrote:
Erik Andersen wrote:
Hi Folks,
SC6 has made the latest draft of Password Policy available. It may be
downloaded from http://www.x500standard.com/index.php?n=Ig.Extension.
SC6 has authorised that we bring this document forward to PDAM status
during the September 2009 meeting.
Please provide comments in time for that meeting.
Based on experience implementing various revisions of the LDAP Password
Policy Draft
http://tools.ietf.org/draft/draft-behera-ldap-password-policy/
and concerns raised in Kurt's newer draft
http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00
I have several concerns, some related to keeping this X.500 draft
cross-compatible with LDAP, and some related to password policy
management in general.
1) relying on clients to know that they should be using an encrypted
password, and to know which algorithm to use, seems impractical in the
real world. IMO whether and how the password is encrypted should be a
matter private to the DSA.
we still allow this as an option, but we think it is more secure if the
directory never knows the user's password so is not able to store it in
audit trails or anywhere. Hence we think this option should be allowed.
a) the use of separate pwdHistory and encPwdHistory attributes is
redundant; there should probably just be a single attribute whose values
are tagged with their encryption method. One method should be reserved
to mean "cleartext" i.e. unencrypted.
This is a good idea and we will adopt it. The encUserPwd will be the
only password attribute we need. (SSL already has a similar idea and has
defined the null encryption algorithm.) So we will store clear passwords
and encrypted ones in the same attribute.
b) the same consideration applies to userPwd vs encUserPwd.
agreed
c) clients should always supply plaintext, the DSA should perform any
encryption as needed to validate the credentials.
we disagree with this for several security reasons, but concerning
storage in a pw attribute, and passing in the Bind protocol, both plain
and encrypted passwords can be supported since Bind already allows
encrypted passwords and algorithm ids to be passed. As long as the
algorithm and enc password in the Bind match the stored value, then the
user is authenticated.
2) Change of Password, section 8.3:
a) There doesn't seem to be any provision for an administrator to
change another user's password. I.e., 8.3.2 requires the oldPwd to
always be supplied. But the most frequent use case in the real world is
for users who have forgotten their password, and need an administrator
to reset it for them. As such, it must be valid within the definition of
this operation to execute it without supplying the oldPwd, and other
policy settings should determine when or for whom oldPwd is or is not
required.
ChangePassword is only meant for users to self administer their
passwords. It is not meant for administrator use. We dont want the
operation to be supported without knowing the existing password.
But this does not stop there being an administrative interface to change
a user's password without knowing the old password. This would need to
be a separate (new) operation. Are you requesting this?.
b) It seems redundant to have a specific policy item and error code
for "passwordModNotAllowed." Why aren't regular access control
mechanisms already sufficient for this case?
you are correct. We could use the generic insufficientAccessRights
error. We will remove it.
c) noPasswordSlot error - this appears to be an open invitation to
Denial-of-Service. What if the last password was known to be stolen and
needs to be changed immediately?
we have fixed this by adding a pwdMinTimeInHistory attribute (default
zero secs) which allows a password to be removed from the history list
if the min time has been exceeded. The reason for allowing admin to set
a non-zero time is to stop users recycling through passwords quickly in
succession so that they can use their old password again immediately
after it has expired. Admins that want to allow this can, by keeping the
default time of zero.
3) Password Policy, section 18.1.3:
a) Maintaining a pwdExpiryDate attribute is redundant information and
imposes undue overhead. E.g., when the pwdExpiryAge is changed, the
pwdExpiryDate for every affected entry must be recomputed and rewritten
into the directory. It's best not to store this attribute at all, and
always compute its value on the fly as needed.
This is cpu vs storage, a recurrent theme in computing. If we change the
current text "Its value may be obtained by addition of the pwdExpiryAge
to the pwdCreationTime of the entry or set by an administrator."
to
"It is an implementation option whether the value is dynamically
computed by addition of the pwdExpiryAge to the pwdCreationTime of the
entry, in which case it does not need to be stored in the directory
entry, or is set by an administrator, in which case it shall be stored
in the directory entry".
it should solve your issue.
b) pwdEndDate is shown as pwdEndTime in Figure 10 and 11.
we will fix this
c) Allowing pwdEndDate to either be manually set or automatically
computed from pwdMaxAge is error-prone. If pwdMaxAge is changed, should
all pwdEndDates be recomputed as well? IMO the answer is No; as an admin
I create accounts with a specific termination date and subsequent policy
changes should not alter that date. IMO pwdMaxAge is ambiguous at best
and unsafe at worst.
d) expPwdCreationTime is redundant, it is obviously the same time as
pwdCreationTime.
Section 18.1.5:
a) the name "pwdChangedTime" seems more intuitive than
"pwdCreationTime" - any rationale behind this particular choice? Clearly
it is set both at initial creation and at all subsequent updates.
b) remAuthAttempts is ambiguous and discards information. For example,
if pwdGraces is changed, the true number of grace logins that have
occurred is lost. There should be a gracesUsed attribute instead of
remAuthAttempts.
Section 18.1.6:
a) why is pwdQualityRule single-valued? Without an initial set of
rules to serve as examples, it's difficult to evaluate the usefulness of
this attribute. I would expect that multiple orthogonal rules will be
defined and that a policy would allow combinations of these rules to be
chosen. IMO this attribute should be multi-valued and at least one or
two prototypical rules need to be part of the spec. As an example, a
rule that validates the plaintext of a password against a regular
expression would be useful.
We have changed this into a set of password quality attributes, which
include: max length, forbidden vocabularies, mandatory character sets,
and forbidden URL dictionaries.
Annex L:
Presumably all of the "encryption" algorithms available here are
intended to be non-reversible, since there is no provision anywhere for
storing an encryption key. In this case it would be more understandable
to refer to these as "hashed" passwords, not encrypted.
agreed, and we do this on the Bind by using the HASH of the password. We
will look at making a global edit to this tomorrow.
regards
David
Other:
One feature that both X.509 certificates and Kerberos tickets provide,
that is missing in this and the LDAP specs, is a pwdStartDate parameter.
There are expiration attributes to control when a credential stops being
valid, but no corresponding parameter to control when it starts being
valid.
In addition to allowing credentials to be disabled due to failed
authentications, and due to passing a fixed expiration date,
administrators frequently request a generic "disabled" boolean flag, for
miscellaneous non-time-related reasons.
As noted in Kurt Zeilenga's draft, users are frequently poor at choosing
passwords. It would be helpful to add a provision for DSA-generated
passwords as a standard feature. E.g., there are a number of publicly
available algorithms for generating "pronounceable" random passwords any
of which are superior to the strings users are likely to invent on their
own.
In discussions regarding how to leverage LDAP password policy for use by
SASL and Kerberos KDCs a number of issues were pointed out. Basically,
in order for external authentication providers to benefit from LDAP
password policy, they must actually perform an LDAP Bind operation
first. For most of these strong authentication mechanisms this is
impractical since a plaintext password is required but is not available.
It was suggested that we define a new extended operation, "ExternalBind"
which simply provides a user name and a success/fail status. The DSA
would then execute the password policy machinery accordingly and return
any relevant status codes. Given that one of the goals of the LDAP
Password Policy initiative was to define policies that may be useful to
other security mechanisms, I believe this new ExternalBind operation
should also be an integral part of the Password Policy specification.
I think that covers my list of issues for now.
--
-------------------------------------------------------------
The Israeli group Breaking the Silence has just released a collection of
testimonies by Israeli soldiers that took part in the Gaza attack last
December and January. The testimonies expose significant gaps between
the official stances of the Israeli military and events on the ground.
See http://www.shovrimshtika.org/news_item_e.asp?id=30
The Israeli government defies Obama, and continues its settlement expansion
Israel plans to allocate $250 million over the next two years for
settlements
http://www.palestinecampaign.org/index7b.asp?m_id=1&l1_id=4&l2_id=24&Content_ID=698
whilst simultaneously continuing to bulldoze Palestinian homes
http://salsa.democracyinaction.org/o/301/t/9462/campaign.jsp?campaign_KEY=27357
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxx
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
