Subject: [ldapext] Password Policy OIDs

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 25 Oct 2004 18:43:49 -0600

This does bring up another point I wanted to discuss though...
 
This draft was written way back when it was popular to assign OIDs in
I-D's. A practice that has lost favor partly due to implementations
using those OIDs and experiencing problems as semantics changed but OIDs
didn't.
 
I'd like to move this I-D forward, and I don't want to be tied to any
semantics defined in previous versions. I propose that we replace the
existing OIDs with requests for IANA OIDs. This way, existing
implementations won't appear to be invalid according to the current and
future revisions, and I won't have to worry so much about breaking
existing implementations.
 
What do other's think?
 
Jim

>>> Andrew Sciberras <[email-masked]> 10/25/04 6:08:05 PM
>>>
Sorry Jim... I see where your coming from now :)

Yep I agree.

Andrew.

Jim Sermersheim wrote:

> Actually, I suggested that the password expire at its max age
(regardles
> of whether any warnings have been sent).
> 
> Jim
> 
> 
>>>>Andrew Sciberras < [email-masked] > 10/25/04 3:36:19
PM
>>>>
> 
> G'Day
> 
> I'm generally satisfied with this.
> 
> If any directories exist today that use the following model:
> * pwdMaxAge - Absolute maximum age of the password
> * pwdExpireWarning - Time period before the max age in which warnings

> will be delivered,
> 
> Then changing the semantics of these attributes would lead to
> unexpected 
> behavior if an organization upgraded their directory server to the
new
> 
> functionality.
> 
> Eg. A directory that wants to warn people 6 months before their
> password 
> is due to expire.
> pwdMaxAge = 31536000 (1 year)
> pwdExpireWarning = 15768000 (6 Months)
> 
> Updating the directory server to one that supports Jim's suggestion 
> below will result in the password reaching its max age, then
remaining
> 
> valid for another 6 months.
> 
> 
> I'm not too sure if this is likely to be a serious problem for 
> implementations, but some text in the security considerations of the

> draft indicating this might be appropriate.
> 
> Cheers
> _________________________________________
> Andrew Sciberras
> eB2Bcom - Software Engineer
> 
> 
> Jim Sermersheim wrote:
> 
> 
>>I believe the intent (however wrongly formulated) was to allow the
> 
> user
> 
>>to receive a warning no matter what. Even if the password's max age
> 
> has
> 
>>passed, the user would be allowed pwdExpireWarning seconds to change
> 
> the
> 
>>pwd. The definition of pwdExpireWarning talks about this in a not
> 
> very
> 
>>precise way (The number of seconds before the password will expire
> 
> after
> 
>>the user is first warned of its upcoming expiration.)
>>
>>Some history to help make sense of things:
>>
>>The password policy I-D was created as a blend of the (then)
> 
> Netscape
> 
>>and Novell directory password policies.
>>
>>I believe the original implementors of pwdExpireWarning (Netscape)
> 
> used
> 
>>this to both warn of expiration, and also allow some kind of grace
> 
> login
> 
>>period.
>>Novell's implementation didn't include the notion of a warning
> 
> period.
> 
>>Only a number of grace logins.
>>
>>So now we have two ways of achieving 'grace login'.
>>
>>A better way of specifying the pwdExpireWarning and pwdMaxAge
> 
> concepts
> 
>>would have been to use one attribute to specify an age at which an
>>expiration warning is sent, and another attribute specified how long
>>these warnings will continue before the password finally expires.
>>
>>I dislike having two similar but different grace mechanisms, so I
>>propose that we remove pwdExpireWarned, and expire the password when
> 
> it
> 
>>reaches pwdMaxAge (regardless of whether any warnings have been
> 
> sent).
> 
>>I'll update the I-D to reflect this without debate (because the
>>deadline is so near), and we can go from there.
>>
>>Jim
>>
>>
>>
>>>>>Andrew Sciberras < [email-masked] > 9/14/04 7:48:25
> 
> PM
> 
>>Hi Niel,
>>
>>
>>Neil Dunbar wrote:
>><SNIP>
>>
>>>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 
>>
>></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
>>eB2Bcom - Software Engineer
>>
>>
>>
>>
>>
> 
>
------------------------------------------------------------------------
> 
>>_______________________________________________
>>Ldapext mailing list
>> [email-masked] 
>> https://www1.ietf.org/mailman/listinfo/ldapext 
> 
> 
> 
> 

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

---

From: Andrew Sciberras <[email-masked]>
Date: Tue, 26 Oct 2004 12:11:01 +1000

G'Day Jim,

I think that this is a good idea, however your email suggests that 
changing the OID's will disambiguate the semantics by which a password 
policy is being enforced. Do you plan to change the short name 
descriptors of the attributes as well?

Andrew Sciberras