[x500standard] Re: New draft on password policy
- From: David Chadwick <d.w.chadwick@xxxxxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Tue, 22 Sep 2009 11:45:17 +0100
HI Howard
continuing from yesterday, these are the additional things we have done
to address your concerns.
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.
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.
b) the same consideration applies to userPwd vs encUserPwd.
c) clients should always supply plaintext, the DSA should perform any
encryption as needed to validate the credentials.
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.
we have added a new operation AdministerPassword. This operation is
intended to be carried out by an administrator and does not require
knowledge of the existing password.
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?
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?
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.
Concerning both pwdExpiryDate and pwdEndTime we have altered these to be
optional attributes that can be set by an administrator. If they are
absent from an entry then they will be automatically computed by the
DSA, but if they are present they will override the default and will not
change if the pwdMaxAge or pwdExpiryAge are altered.
b) pwdEndDate is shown as pwdEndTime in Figure 10 and 11.
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.
this is now dealt with as described above.
d) expPwdCreationTime is redundant, it is obviously the same time as
pwdCreationTime.
You are correct. It has been removed, thanks. The diagram has also been
updated to reflect this.
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.
When an old password is changed, the new one is created :-). So the name
is OK. However we have updated its description to say that it can be
created via the change password operation.
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.
We agree. We will change the attribute to gracesUsed
I believe we have now dealt with all your issues. One final topic we
have not fully resolved at the meeting is the issue of the user sending
hashed passwords instead of clear text ones. We realise that the user
will need access to the salt to the used, without needing to remember it
himself, but if the salt is fixed this gives an attacker time to do a
pre-computed hash attack. If the salt varies each time, then the DSA
will need to store the clear password. So perhaps the only solution is
to send the password in the clear and let the DSA hash it in its own way
regards
David
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.
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.
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:
