Subject: [ldapext] RE:draft-behera-ldap-password-policy-07.txt

From: "Andrew Sciberras" <[email-masked]>
Date: Thu, 19 Feb 2004 12:21:14 +1100

Just some comments regarding the draft:

LDAP Ext mailing list's email address should be [email-masked]

LDAP should be spelt out (ie. Lightweight Directory Access Protocol) before
the acronym is used.

There is no mention as what LDAP Version this applies to. Is it unusable for
LDAPv2? or does that just eliminate the use of controls?

Section 2.1
>The password policy defined in this document can be applied to any
>attribute holding a user's password used for an authenticated LDAP
>bind operation.

Not limited to bind. Compare can be used for authenticating as well.

>This policy is typically applied to the userPassword attribute in
>the case of the LDAP simple authentication method [RFC-2251] or the
>case of password based SASL [RFC-2222] authentication such as CRAM-
>MD5 [RFC-2195] and HTTP-Digest [RFC-Digest].
Might need to be a little careful with the mention of HTTP-Digest.
I'll just qualify this statement with the fact that I don't have too much
knowledge of SASL or HTTP-Digest.
That being said, I believe that it may be encouraged (or at least stated)
that a digest of the username, realm and password could be stored instead of
the password itself.
I truly have no idea regarding the impact this has when a password policy is
applied to this data, but weird things may happen.
For example, a change in the realm, whilst retaining the same password,
would result in a different hash. Effectively making the password policy
think that the password has been changed and avoiding History restrictions.
Length and Quality checking become unenforceable.

Section 3.2
I would avoid referring to the userPassword attribute as the password policy
is flexible enough to be applied to a variety of attributes.

Section 4.3.1
>Since the password policy could apply to several attributes used to
>store passwords, each of the above operational attributes must have
>an option to specify which pwdAttribute is applies to.
s/is/it/

Section 4.3.3, 6.1.1
A 0 value for generalizedTime is mentioned. This is impossible as 0 is not a
valid value.
We use 0000010100Z.

Section 4.3.8
>This attribute holds a flag to indicate (when TRUE) that the
>password has been reset and therefore must be changed by the user on
>first authentication.
In what way is it restricted to the first authentication? Practically,
following the instructions for a bind operation, a person could bind many
times without ever changing their password.

Section 5.
Add the following statement, or something similar:
"Servers implementing the Password Policy controls SHOULD publish
1.3.6.1.4.1.42.2.27.8.5.1 as a value of 'supportedControl' [RFC2252] in
their root DSE."

Section 5.1
>The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality
>MUST be FALSE. There is no controlValue.
Why must the criticality be false?
Suppose I would like to set up my clients to only perform LDAP operations
against directories that recognise the LDAP Password Policy control. To do
this, I would send my LDAP Request with a Password Policy control and set
the criticality to TRUE. Therefore, my clients will only have their
operations processed if the directory recognises the password policy
control.
Alternatively, one could just check the directory's supportedControl to
identify if the password policy control is supported.
I fully recognise that the intention of the control is to make the server
aware that the client is able to handle a response control, but I still
think that the criticality of the control should be left upto the client.

Section 5.2
>PasswordPolicyResponseValue ::= SEQUENCE {
> warning   [0] CHOICE {
>  timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>  graceLoginsRemaining  [1] INTEGER (0 .. maxInt) } OPTIONAL
> error     [1] ENUMERATED {

Your missing a comma after OPTIONAL.

>  insufficientPasswordQuality   (5),
>The insufficientPasswordQuality error is set when a
>password doesn't pass quality checking.

Just as an aside, the encodings from BER (and DER, PER, etc.) remain the
same even though the name of the enumerated choice has changed. However, the
encoded data from XML based encoding rules (RXER (XED) and XER (ITU)) will
be different after such a name change is made.

Section 6.
>The server SHOULD enforce that the password attribute subject to a
>password policy as defined in this document, contains one and only
>one password value.
How do you suggest that the server enforce such a rule? Throw away
additional values? Return an unwillingToPerform error on modifications that
will result in multiple password values?

Section 6.1.2B Page 17
>The server MUST then disallow all operations issued by this
>user except modify password, bind, unbind, abandon and
>StartTLS extended operation.
Compare?

Section 6.1.2D Page 18 and 6.4.2C
>If the pwdExpirationWarned attribute is present and has a
>time value, the warning time is the value of the
>pwdExpirationWarned attribute plus the value of the
>pwdExpireWarning attribute minus the current time.

WarningTime = pwdExpirationWarned + pwdExpireWarning - Current Time

>If the pwdExpirationWarned attribute is not present, the
>server MUST subtract the current time from the time stored
>in pwdChangedTime to arrive at the password's age. If the
>age is greater than the value of the pwdMaxAge attribute
>minus the value of the pwdExpireWarning attribute, the
>server MUST set the current time as the value of the
>pwdExpirationWarned attribute, and the warning time is the
>value of pwdMaxAge minus the password's age.

PasswordAge = pwdChangeTime - CurrentTime
WarningTime = pwdMaxAge - PasswordAge

Firstly, I believe that the calculation of the PasswordAge is incorrect.
I think that the pwdChangeTime should be subtracted from the current time.

Following the warning time calculation steps described in the draft can also
lead to misleading results.
The example below will illustrate a scenario where this is the case.

pwdMaxAge = 100 seconds.
pwdExpireWarning = 50 seconds.
The user binds when the password is 80 seconds old.
PasswordAge = 80.
WarningTime = (pwdMaxAge - PasswordAge) = 20 seconds.
At this stage the user has been told that their password will expire in 20
seconds.

User binds again in 5 seconds time. (I.e. PasswordAge = 85 seconds).
Since the pwdExpirationWarned is now present we calculate the warning time
differently.

WarningTime = (pwdExpirationWarned + pwdExpireWarning - CurrentTime)
  = (pwdExpirationWarned - CurrentTime) + pwdExpireWarning
  = (-5) + 50
  = 45
The user is now told that their password will expire in 45 seconds.
Our implementation of the password policy will simply return
pwdExpireWarning as the first warning time value.

Section 6.1.2B (Page 20)
>If the number of these failures is greater or equal to the
>pwdMaxFailure attribute, the server MUST lock the account
>by setting the value of the pwdAccountLockedTime attribute
>to the current time. After locking the account, the server
>MUST send a bindResponse to the client with the
>resultCode: unwillingToPerform (53), and MUST include the
>passwordPolicyResponse in the controls field of the
>bindResponse message with the error: accountLocked (1).

I do not think that the return code should be unwillingToPerform. In this
scenario, the user has got their password wrong and this incorrect attempt
has made the number of failures exceed the pwdMaxFailure limit. In this case
the reason why the operation (BIND) is going to fail is because of the
incorrect password. The fact that the number of bind failures has exceeded a
policy limit is just a consequence of that.
For this reason I believe that the resultCode should be invalidCredentials.

Section 6.2.9
If an administrator is modifying the password then we should not remove the
pwdReset attribute.
This scenario is likely, because the definition that you provide in Section
3.2 states that:
"In this document, the term "modify password operation" refers to any
operation that is used to add or modify a password attribute."
The description provides no constraints on who is performing the modify
password operation.

Section 6.3.2B
>If the server is unable to check the length (due to a hashed
>password or otherwise), the value of pwdCheckSyntax MUST be
>evaluated. If the value is 1, operation MUST continue. If the
>value is 2, the server MUST send an addResponse to the client
>with the resultCode: constraintViolation (19), and MUST
>include the passwordPolicyResponse in the controls field of
>the addResponse message with the error: passwordTooShort (5).

A passwordTooShort error code here seems inappropriate. Since the server
could not determine the length due to the syntax of the password wouldn't it
be more appropriate to use a invalidPasswordQuality error code.

Section 6.3
You need a Step 4. Set the pwdReset value to TRUE.

Section 6.4.2A
How about removing the pwdAccountLockedTime attribute in the doc somewhere?
I think that sections 6.4.2A and 6.1.2A are prime locations.

Section 6.4.2D
>If the result of the compare operation is false, the server MUST
>do the following:
 <snip>
>D. If no errors were returned, the server MUST send a
>compareResponse with the resultCode: compareTrue (6), and
>MUST include the passwordPolicyResponse with nothing in
>the SEQUENCE.
Section D above is related to the fact that the compare was false. The
server should therefore return compareFalse.

7.1.2.
>The user is binding for the first time after the directory
>administrator set the password. In this scenario, the client
>SHOULD prompt the user to change his password immediately.
>
>resultCode:               success (0)
>passwordPolicyResponse:           error: changeAfterReset (2)

This scenario will occur for every single bind until the password has been
changed.

Section 7.5
>For operations other than bind, unbind, abandon, search or StartTLS,
>the client MUST check the following result code and control to
>determine if the user needs to change the password immediately.

I don't think that search should be in there.

Section 8
An administrativeRole operational attribute (as defined in RFC36720) must be
specified for the password policy.

I also think that this draft should contain a 'Known Limitation'(or similar)
section. A few things off the top of my head:
	* Password Attribute must only contain one value
	* No consideration for password attributes with options
	Eg, if I have the attributes userPassword;x-unix and userPassword;x-windows
with different passwords for different reasons. How do I set up individual
policies?
	* Password policy cannot be applied to X.500 attributes whose syntax don't
have an LDAP specific encoding.

Cheers,

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: John McMeeking <[email-masked]>
Date: Thu, 19 Feb 2004 08:40:32 -0600

> think that the criticality of the control should be left upto the client.

Following the discussions related to control criticality in ldapbis, I
think this document should only contain recommendations for criticality.
It might be appropriate to say that if the client is intended to
interoperate with servers that do not support password policy, it is
recommended that the control criticality be FALSE.

> >StartTLS extended operation.

Not compare. I think the intent is to allow operations needed by the user
to change his password. Compare is used by other applications (not under
the user's identity) to authenticate a user to the application.

> The description provides no constraints on who is performing the modify

There are cases where password changes are processed through an
applicatiuon that runs under some administrative identity; the user does
not have authority to change his entry directly.  I believe password policy
should still apply in such cases and behave much like the user was changing
his own password.  It is possible that such changes could be "safe"
changes.  Since we can get to step 9 in lots of ways, the pwdreset
processing needs to be expanded:

If the password change is a safe modify, the pwdreset attribute is removed.
If the password is changed by an administrator, the pwdreset attribute is
set according to the "password change after reset policy": pwdreset is set
to TRUE if this policy is in effect, and removed if this policy is not in
effect.

> I don't think that search should be in there.

And I would expect that the client SHOULD check the result code and control
for the bind operation.

> Adacel Technologies Ltd

John  McMeeking

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 19 Feb 2004 16:02:40 +0100

Andrew,

Thanks for your comments.
See some answers inlined...

>LDAP Ext mailing list's email address should be [email-masked]
Fixed

>LDAP should be spelt out (ie. Lightweight Directory Access Protocol) before
Ok

>LDAPv2? or does that just eliminate the use of controls?
I'll add a clarification but LDAPv2 has been moved to Historical status...

>Might need to be a little careful with the mention of HTTP-Digest.
The term HTTP-Digest has been replaced by DIGEST-MD5 in the -07 draft...

>Length and Quality checking become unenforceable.
I agree. Note that changing the realm for the server will invalidate ALL 
passwords, which make the use of the digest instead of the password 
undeployable.

>is flexible enough to be applied to a variety of attributes.
Ok.

>>an option to specify which pwdAttribute is applies to.
ok.

>A 0 value for generalizedTime is mentioned. This is impossible as 0 is not a
Nice catch. We use 000001010000Z which is another representation of the 
same value.
I'll change the wording to specific the generalizedTime 1st of Jan 0000, 
00h00mn and give a representation of the value.

>1.3.6.1.4.1.42.2.27.8.5.1 as a value of 'supportedControl' [RFC2252] in
Added to section 5.1.

>think that the criticality of the control should be left upto the client.
This is a valid requirement.
I've changed the criticality to be TRUE or FALSE and removed the MUST.

>Your missing a comma after OPTIONAL.
ok

>be different after such a name change is made.
Yes, but these password policy  are internet-drafts, and thus subject to 
changes...

>will result in multiple password values?
I would suggest that password attributes are defined as single-valued...
I know this is not the case for userPassword.
I think that servers should not throw away additional values, they 
should return an error... The error may be implementation specific.

>>StartTLS extended operation.
I don't think compare should be allowed. The idea is to only allow the 
user to modify his/her password which will require the user to be 
authenticated.
Also I think there is an issue here with applications that are only 
doing authentication... And thus will never call modify. The password 
will be used without being changed again by the user. Somehow, there 
should be a mechanism to prevent this usage.

>Firstly, I believe that the calculation of the PasswordAge is incorrect.
I agree that the wording is confusing... A - B is expressed in english 
as remove B from A... This needs to be corrected in numerous places.

>  = (pwdExpirationWarned - CurrentTime) + pwdExpireWarning
This is what our implementation does as well.
But I think this has the side effect of effectively extending the 
password life beyond the specified MaxAge.
The other solution is to make sure that the password expires after 
MaxAge (so the WarningTime whould be 15 seconds in the 2nd warning time 
value) and let grace logins deals with possible authentication after 
expiration of the password.

>For this reason I believe that the resultCode should be invalidCredentials.

Correct, in that case, it should be invalidCredentials (49).

>If an administrator is modifying the password then we should not remove the
I agree... It should be set to TRUE if pwdMustChange is TRUE.

>The description provides no constraints on who is performing the modify
I agree... And somehow the text right makes the assumption that it is 
the User.
I will change the wording.

>be more appropriate to use a invalidPasswordQuality error code.
OK.

>You need a Step 4. Set the pwdReset value to TRUE.
I'm not sure this is a MUST though. And it should be left out to 
Administrators to decide if the password must be reset or not.
I've added the following text:

4. Set the pwdReset attribute. The value SHOULD be TRUE if the 
pwdMustChange attribute is TRUE, and FALSE otherwise. However, this may 
be subject to specific configuration.

>I think that sections 6.4.2A and 6.1.2A are prime locations.
Yes. Both locations updated.

>server should therefore return compareFalse.
Ok.

>This scenario will occur for every single bind until the password has been
Agree... This reminds me that some customer would like to have a 
specific Expiration Time for Reseted passwords (shorter than the regular 
pwdMaxAge).

>I don't think that search should be in there.
Agree

>specified for the password policy.

I know. I've realized this when updating the text to reference RFC 3672.
The document will need an IANA Consideration section as well.

>have an LDAP specific encoding.
Willl think of it.

>Adacel Technologies Ltd
Thanks again for the review and the very valuable comments.

Regards,

Ludovic.

-- 
Ludovic Poitou
Directory Architect.
Directory Server Group, Grenoble, France
Sun Microsystems Inc.

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~