Subject: RE: [ldapext] Password Policy OIDs

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 26 Oct 2004 13:49:33 +1000

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: [email-masked] [mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Tuesday, 26 October 2004 10:44
To: [email-masked]
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 <[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: "Jim Sermersheim" <[email-masked]>
Date: Tue, 26 Oct 2004 08:46:59 -0600

>>> Neil Dunbar <[email-masked]> 10/26/04 3:02:38 AM >>>
>
>Are we talking about replacing all OIDs, or just the schema OIDs? It
>seems that if we change the ones for the LDAP Request/Response
controls
>then I can see a lot of implementations falling over (or at least
>failing to pass proper response information).
>
>Schema re-OIDing isn't that much of a hassle, for us at least.

All of them. Without looking, I think the ASN.1 of the response control
has been updated at least once.
 
Jim

---

From: Andrew Sciberras <[email-masked]>
Date: Thu, 28 Oct 2004 09:34:40 +1000

Jim Sermersheim wrote:
>>>> Andrew Sciberras <[email-masked]> 10/27/04
>>>> 4:15:15 PM >>>
> There is a TODO statement in -08 for this (Section 10).

Sorry, I guess I should open my eyes!

> 
> FWIW, this is what finally pushed me into raising the thread on the
> list * Do I get another OID from the Netscape folks? Do I add the
> first IANA_ASSIGNED oid? I'd rather move to all IANA_ASSIGNED oids at
> the same time I assign the administrative role OID.
> 
Here's what we did:
* Defined our own temporary internal OID for the admin role

> We also need to dscribe how these administrative areas work. Can they
> overlap? 
* No overlapping - i.e Specific Administrative Area
We made this decision based on the comment:
"It SHOULD be possible to overwrite the password policy for one
user by defining a new policy in a subentry of the user entry."

>Can they be defined in a way that causes some objects to be
> governed by no pwd policy subentry?
* Yes, we can do this through the subtreeSpecification attribute

> Can one object be governed by multiple pwd policy subentries? 
 > If so, must each governing subentry list a unique pwd attribute?
Not sure what your asking here... Is an object and entry or a password 
attribute?
Many subentries can apply to a single entry. If there are multiple 
password policy subentries under the one administrative point then I 
think that they should all be distinctly different. Essentially, no two 
policies should be able to be applied to the attribute within an entry. 
This may be hard to manage, so it probably would be easier to simply say 
that "each governing subentry list a unique pwd attribute".

> Jim

Andrew Sciberras.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 27 Oct 2004 17:57:14 -0600

>>> Andrew Sciberras <[email-masked]> 10/27/04 5:34:40 PM
>>>
<snip> 
 
>user by defining a new policy in a subentry of the user entry."

Right, but someone may want to define one policy for person objects,
and another policy for widget objects, where persons and widgets fall
under the same hierarchy.
 
<snip>

>that "each governing subentry list a unique pwd attribute".

I'm just saying, we need to decide and specify these things. AFAIK,
administrative policy specifications are responsible to make statements
as to whether policies may be combined, and how (...for each specific
aspect of administrative authority, a definition is required of the
method of combination of administrative information when it is possible
for entries to be included in more than one subtree or subtree
refinement...). For example, while we _may_ want to allow multiple
password policy subentries to apply to a single object (each associated
with a different attribute), other administrative areas do not allow
multiple subentries to apply to a single object (like subschema). The
limits and allowances for these kinds of things are supposed to be
called out in the specification, but the pwd policy specification makes
no (or very few, vague) statements along these lines.

Jim

---

From: Andrew Sciberras <[email-masked]>
Date: Thu, 28 Oct 2004 10:07:53 +1000

> under the same hierarchy.

I'm not sure to what extent the SubtreeSpecification attribute is 
supported within LDAP directories, but you can certainly achieve your 
above statement by using the substreeSpecification att. This is due to 
the 'Refinement' choice within the SubtreeSpecification structure that 
allows you to filter which entries the policy applies to based on their 
object class.

Andrew

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 28 Oct 2004 19:54:40 -0600

Thanks for the clarification.
 
So I think we want to specify these things for the pwd policy (is there
such a thing pwdPolicy inner administrative area? Can a pwdPolicy
administrative point have multiple subentries?)
 
I think I'm hearing Yes, and Maybe Not (respectively).
 
To allow multiple subentries, some requirement must be given such that
no two subentries govern the same pwd attribute. Also, the state
information doen't currently allow for multiple policies (Ludo and I
worked on that solution once, and gave up).
 
Jim

>>> Steven Legg <[email-masked]> 10/28/04 6:17:14 PM >>>

Jim,

Jim Sermersheim wrote:
> Right, I know the mechanism used for this, but...
> 
> I was under the impression that a specification of an administrative

> policy is responsible to make statements as to whether or not such 
> things are allowed. And if allowed, what restrictions exist (in pwd 
> policy's case, one restriction is to not allow a single object to be

> governed by two pwd policy subentries each specifying the same pwd 
> attribute).
> 
> For example, the specification for the subschema administrative area

> makes some statement (though I can't find it now) which restricts an

> object to only being governed by a single subschema subentry.

FYI, it comes about as a consequence of there being no such thing as a
subschema
inner administrative area, and the requirement that a subschema
administrative
point have no more than one subschema subentry.

Regards,
Steven

> 
> Jim
> 
> >>> Andrew Sciberras < [email-masked] > 10/27/04
6:07:53 PM >>>

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 28 Oct 2004 20:01:53 -0600

Something I said below is wrong:
 
Ludo and I worked on that solution and it's still part of the draft
(Section 5.3.1 Password Policy State Attribute Option).
 
So there is a provision to place multiple pwd policy subentries under a
single AP, we just need to specify that they can't govern the same pwd
attribute.
 
I think I'll take a break...
 
Jim
 
>>> Jim Sermersheim >>>

 
 
Jim

Jim,

Regards,
Steven

6:07:53 PM >>>