Subject: [ldapext] Re: Password Policy for LDAP Directories

From: Andrew Sciberras <[email-masked]>
Date: Fri, 10 Sep 2004 09:28:49 +1000

Hi Gabriele,

I too have noticed this strange calculation of the warning time and sent 
a comment to this mailing list on the 20th November 2003. A copy of this 
message can be found in the archives:
http://www.openldap.org/lists/ietf-ldapext/200311/msg00027.html

Basically, at the end of the day, our implementation will simply return 
the pwdExpireWarning as the first warning value.

My comments were made in regards to the -05 version of the draft. 
Currently the 'Password Policy for LDAP Directories' draft has expired 
so I am uncertain as to what the authors intend to do about this.

The solution to this is certainly consistency. There are two paths that 
you could go down:
     * Consistently expire at the MaxAge time, which is how you describe 
IBM's solution.
     * Always provide a warning time of pwdExpireWarning seconds.

I would argue that the way that the Tivoli Directory Server handles this 
is incorrect. It's my opinion, which also reflects our implementation, 
that the second option is preferable. For example, imagine that a server 
has the following rules:
     pwdMaxAge -> 500 seconds
     pwdExpireWarning -> 100 seconds

And the user logs on for the first time at t=495, then they should 
receive a whole 100 seconds to change their password, instead of the 5 
seconds that the Tivoli Directory Server would provide.

Regards,
______________________________________
Andrew Sciberras
eB2Bcom - Software Engineer
EMail:    [email-masked]
Web    http://www.eb2bcom.com

Gabriele Garuglieri wrote:

> I 'm writing some java classes that are dealing with 
> PasswordPolicyResponseValue and i'm having some doubts about the Behera 
> draft. I'd be glad if someone could clarify the points that follow these 
> two quotes from Behera draft:
> -------
> 4.3.4 pwdExpirationWarned
> 
>   This attribute contains the time when the password expiration
>   warning was first sent to the client. The password will expire in
>   the pwdExpireWarning time.
> 
> -------
>      D. Calculates whether the time before expiration warning should
>         be sent.
> 
>         If the pwdExpireWarning attribute is present and contains a
>         value, the server MUST perform the following steps.
> 
>             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.
> 
>             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.
> -------
> 
> Reading the above  i  come to the following assumptions, please correct 
> me if they are wrong:
> 
> 1- the password will expire at (pwdExpirationWarned plus 
> pwdExpireWarning) date.
> 2- the first time i bind within the warning period, when the 
> pwdExpirationWarned  is not yet initialized, the calculated warning time 
> is equal to (pwdChangedTime plus pwdMaxAge) minus current time.
> 3- the second time i bind within the warning period, when the 
> pwdExpirationWarned  is already initialized, the calculated warning time 
> is equal to (pwdExpirationWarned plus pwdExpireWarning) minus current 
> time, which is a a value surely larger than the one calculated during 
> the first bind.
> 
> The last two points have the following implications:
> 
> 4- if i calculate the expiration date using the returned warning time i 
> obtain two different values between first and any subsequent bind within 
> the warning period, which i think is not very consistent.
> 5- the real expiration date can be extended well beyond the 
> (pwdChangedTime plus pwdMaxAge), depending on when i first bind during 
> the warning period, almost up to (pwdChangedTime plus pwdMaxAge plus 
> pwdExpireWarning) if my fist bind within the warning period falls within 
> the last usable second of  (pwdChangedTime plus pwdMaxAge) time.
> 
> Last but least, i'm experimenting with Tivoli Directory server 5.1, 
> whose behaviour seems to be happily ignoring all of the above, because 
> the returned warning time, independently from any pwdExpirationWarned  
> value, is ALWAYS (pwdChangedTime plus pwdMaxAge) minus current time.
> Can, please, someone shed some light on the correct Behera draft meaning?
> 
> Thanks, Gabriele.
> 
> 

-- 
_________________________________________
Andrew Sciberras
eB2Bcom - Software Engineer

Woodhouse Corporate Centre
Suite 3, 935 Station Street
Box Hill North, Victoria 3129, Australia

phone:	+61 3 9896 7833
fax: 	+61 3 9896 7801
mobile:	0412 098 771

EMail:	[email-masked]
Web	http://www.eb2bcom.com

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

---

From: Neil Dunbar <[email-masked]>
Date: Fri, 10 Sep 2004 10:27:38 +0100

> seconds that the Tivoli Directory Server would provide.

Hmm. I'm not so sure. Are you saying that if you've passed the maximum
age, then you go into the "grace login" period, where the only allowable
operation is to change your password? If so, does that get overridden by
the "number of grace logins" setting in the password policy? If not,
then the maximum age of the password is not a boundary on the worthiness
of the password. I'd argue that this would be a bad thing.

The pwdMaxAge should be the absolute maximum time that the password can
be used by anyone as a credential. The pwdExpirationWarning time, I
think, should be the earliest opportunity that the directory server can
warn the user that his/her password is approaching expiry. If the user
comes into the expiry period late in the game - tough. You can always
use the grace logins feature to allow the user with the dud password to
change it after it has ceased to be a meaningful credential for general
directory operations.

When I prototyped the code for the password policy module for OpenLDAP,
I used the same logic as the Tivoli system. I tried to make sense of the
I-D, but couldn't turn it into clear code. That said, since Howard Chu
of Symas rewrote the prototype into a real module, he may have altered
the logic. I'll check later.

Cheers,

Neil

---

From: Andrew Sciberras <[email-masked]>
Date: Wed, 15 Sep 2004 11:48:25 +1000

Hi Niel,

Neil Dunbar wrote:
<SNIP>
> directory operations 
</SNIP>

If someone was to implement the draft in its current form, their first 
warning time would indicate the time difference between the current time 
and the time that the password is due to expire. Subsequent logins would 
result in a warning time that will go beyond the specified pwdMaxAge 
allowing the user to receive their full warning period.

Our implementation, which was based around the -05 version of the draft 
handled this inconsistency by returning an initial warning message of 
pwdExpireWarning.

I've now noticed, in version -07 of the draft, that the following new 
line exists within the description of pwdExpireWarning:
If not 0, the value must be smaller than the value of the pwdMaxAge 
attribute.

This seriously implies that the author's intention is to ensure that the 
warning time does not exceed the maximum age of the password.

I'm not extremely passionate about whether a user should receive their 
full warning period. Some consensus on this issue, and the author's 
opinion (Jim?) would be good though.

Andrew Sciberras