[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: [ldapext] Password Policy OIDs



It appears not to have that effect. Unless you change the names as well, you can have an old client appearing to communicate with a new server, or a new client appearing to communicate with an old server, and yet they can misunderstand each other.
 
Ron
-----Original Message-----
From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim
Sent: Tuesday, 26 October 2004 10:44
To: ldapext@ietf.org
Subject: [ldapext] Password Policy OIDs

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 <andrew.sciberras@eB2Bcom.com> 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 < andrew.sciberras@eB2Bcom.com > 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 < andrew.sciberras@eB2Bcom.com > 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
>> Ldapext@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
>

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext