Please have look at One-Time Password password policy

[thierry bordaz]

Hi,

I wrote a small design [1] about OTP password policy that I would like 
to start implementing.
Comments are welcome

[1] https://www.port389.org/docs/389ds/design/otp-password-policy.html

best regards
thierry

[William Brown]

Hey there,

I think that you also need:

pwdOTPValidFromTime

This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime.

I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time).

I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.

The OC should be named onetimepasswordPolicy instead.

Hope that helps!
> On 22 Mar 2021, at 21:30, thierry bordaz  wrote:
>
> Hi,
>
> I wrote a small design [1] about OTP password policy that I would like to start implementing.
> Comments are welcome
>
> [1] https://www.port389.org/docs/389ds/design/otp-password-policy.html
>
> best regards
> thierry
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia

[thierry bordaz]

Hi William

Thanks for you review. Some answers are inlined in the mail below.

On 3/23/21 12:33 AM, William Brown wrote:
> Hey there,
>
> I think that you also need:
>
> pwdOTPValidFromTime
>
> This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime.

That is a very nice idea. Note to be OTP the 'userpassword' of the 
account must be reset by an admin and the account inheriting password 
policy with OTP settings.
Assuming 'pwdOTPValidFromTime' is the account operational attribute 
holding a precise time. How should it be computed ? Directly from a 
precise time set in the password policy or computed from a ' 
'passwordOTPValidationDelay' (number of seconds after OTP reset time) or 
something else ?
> I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time).

ATM password policy ('passwordPolicy') only contains 'password*' 
attributes this is why I would prefer to keep 'passwordOTP*' (e.g. 
passwordOTPMaxUse, passwordOTPExpirationDelay, passwordOTPValidFromTime').
I agree that 'passwordOTP' looks weird ("password one time password") 
but the first 'password' is the way the password policy attribute are 
prefixed.

Then the account operational attributes updated via  password policy. 
There is a mix.
6 out of 10 start with 'password' (like 'passwordExpirationTime')
2 out of 10 start with 'pwd' (like 'pwdReset')
The two remaining are 'retryCountResetTime' and 'accountUnlockTime'.
I choose the 'pwdOTP' prefix because the feature is somehow related to 
'pwdReset' and also I preferred a different prefix than the password policy.
> I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.

Why ? Registration should be done after Now+ValidFromTime and before 
Now+passwordOTPExpDelay.
So the two are useful.
> The OC should be named onetimepasswordPolicy instead.

Do you suggest we have two password policies OC: passwordPolicy and 
OnTimePasswordPolicy.
OTP relying on 'passwordMustChange' then OnTimePasswordPolicy should 
allow 'passwordMustChange'
> Hope that helps!

Absolutely it helps a lot. Thanks !

thierry
> > On 22 Mar 2021, at 21:30, thierry bordaz  wrote:
> >
> > Hi,
> >
> > I wrote a small design [1] about OTP password policy that I would like to start implementing.
> > Comments are welcome
> >
> > [1] https://www.port389.org/docs/389ds/design/otp-password-policy.html
> >
> > best regards
> > thierry
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> _______________________________________________
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[William Brown]

> On 24 Mar 2021, at 02:12, thierry bordaz  wrote:
>
> Hi William
>
> Thanks for you review. Some answers are inlined in the mail below.
>
> On 3/23/21 12:33 AM, William Brown wrote:
> > Hey there,
> >
> > I think that you also need:
> >
> > pwdOTPValidFromTime
> >
> > This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime.
>
> That is a very nice idea. Note to be OTP the 'userpassword' of the account must be reset by an admin and the account inheriting password policy with OTP settings.
> Assuming 'pwdOTPValidFromTime' is the account operational attribute holding a precise time. How should it be computed ? Directly from a precise time set in the password policy or computed from a ' 'passwordOTPValidationDelay' (number of seconds after OTP reset time) or something else ?

I think maybe it could be easy to visualise it.

We have time going from past to future like:

past ---------------------------------------------------------> future

So we want a window of:

* When can the OTP start to be used?
* When is the OTP no longer able to be used?

So my thinking is:

past ---------------------------------------------------------> future
       ^          ^                 ^
       |          |                 |
   otp created    |                 |
               otp valid from       |
                                 otp expire at

So I would say otp valid from and the otp expire should be *absolute* date times in UTC.

And then within that otp valid from - expire at time window, we have the "max use" field of how many times it can be used.

Does that help?
> > I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time).
>
> ATM password policy ('passwordPolicy') only contains 'password*' attributes this is why I would prefer to keep 'passwordOTP*' (e.g. passwordOTPMaxUse, passwordOTPExpirationDelay, passwordOTPValidFromTime').
> I agree that 'passwordOTP' looks weird ("password one time password") but the first 'password' is the way the password policy attribute are prefixed.

Ahh I think I missed that this is using the userPassword and combined with passwordPolicy. That makes sense now.

Still better to keep it consistent - all pwd or all password. I think you mix/match these ....
> Then the account operational attributes updated via  password policy. There is a mix.
> 6 out of 10 start with 'password' (like 'passwordExpirationTime')
> 2 out of 10 start with 'pwd' (like 'pwdReset')
> The two remaining are 'retryCountResetTime' and 'accountUnlockTime'.
> I choose the 'pwdOTP' prefix because the feature is somehow related to 'pwdReset' and also I preferred a different prefix than the password policy.
> > I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.
>
> Why ? Registration should be done after Now+ValidFromTime and before Now+passwordOTPExpDelay.
> So the two are useful.

I'd see above :)
> > The OC should be named onetimepasswordPolicy instead.
>
> Do you suggest we have two password policies OC: passwordPolicy and OnTimePasswordPolicy.
> OTP relying on 'passwordMustChange' then OnTimePasswordPolicy should allow 'passwordMustChange'

Ignore this comment - I think I missed about the passwordPolicy bit :)
> > Hope that helps!
>
> Absolutely it helps a lot. Thanks !
>
> thierry
> > > On 22 Mar 2021, at 21:30, thierry bordaz  wrote:
> > >
> > > Hi,
> > >
> > > I wrote a small design [1] about OTP password policy that I would like to start implementing.
> > > Comments are welcome
> > >
> > > [1] https://www.port389.org/docs/389ds/design/otp-password-policy.html
> > >
> > > best regards
> > > thierry
> > > _______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs, Australia
> > _______________________________________________
> > 389-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia

[thierry bordaz]

On 3/24/21 12:16 AM, William Brown wrote:
> > On 24 Mar 2021, at 02:12, thierry bordaz  wrote:
> >
> > Hi William
> >
> > Thanks for you review. Some answers are inlined in the mail below.
> >
> > On 3/23/21 12:33 AM, William Brown wrote:
> > > Hey there,
> > >
> > > I think that you also need:
> > >
> > > pwdOTPValidFromTime
> > >
> > > This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime.
> >
> > That is a very nice idea. Note to be OTP the 'userpassword' of the account must be reset by an admin and the account inheriting password policy with OTP settings.
> > Assuming 'pwdOTPValidFromTime' is the account operational attribute holding a precise time. How should it be computed ? Directly from a precise time set in the password policy or computed from a ' 'passwordOTPValidationDelay' (number of seconds after OTP reset time) or something else ?
>
> I think maybe it could be easy to visualise it.
>
> We have time going from past to future like:
>
> past ---------------------------------------------------------> future
>
> So we want a window of:
> When can the OTP start to be used?
> When is the OTP no longer able to be used?
>
> So my thinking is:
>
> past ---------------------------------------------------------> future
>         ^          ^                 ^
>         |          |                 |
>     otp created    |                 |
>                 otp valid from       |
>                                   otp expire at
>
> So I would say otp valid from and the otp expire should be *absolute* date times in UTC.

Hi William

Good idea of that graphic. I am sorry to be so slow to understand but 
still things are not clear.
There are the attributes of the password policy and the operational 
attribute of the user account.

I think you meant and I agree with you that operational attributes (in 
the user account) should be absolute date.
What is not clear to me is how to compute those operational attributes 
from the password policy.
I see three options:

1. password policy contains absolute time (e.g.
    passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
 2. password policy contains a delay after OTP create/reset (e.g.
    passwordOTPValidFromDelay) => account.validFrom = Now +
    policyValidFromDelay
 3. password policy contains both and if both are set we should give the
    priority to one or the other

If a password policy is a stable entry, then they should not contain 
absolute time. If we imagine password policy created on purpose to do a 
bunch of registration, then that is okay if they contain absolute time.

Do you think we should support password policy with absolute time ?

thanks

thierry
> And then within that otp valid from - expire at time window, we have the "max use" field of how many times it can be used.
>
> Does that help?
> > > I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time).
> >
> > ATM password policy ('passwordPolicy') only contains 'password*' attributes this is why I would prefer to keep 'passwordOTP*' (e.g. passwordOTPMaxUse, passwordOTPExpirationDelay, passwordOTPValidFromTime').
> > I agree that 'passwordOTP' looks weird ("password one time password") but the first 'password' is the way the password policy attribute are prefixed.
>
> Ahh I think I missed that this is using the userPassword and combined with passwordPolicy. That makes sense now.
>
> Still better to keep it consistent - all pwd or all password. I think you mix/match these ....
> > Then the account operational attributes updated via  password policy. There is a mix.
> > 6 out of 10 start with 'password' (like 'passwordExpirationTime')
> > 2 out of 10 start with 'pwd' (like 'pwdReset')
> > The two remaining are 'retryCountResetTime' and 'accountUnlockTime'.
> > I choose the 'pwdOTP' prefix because the feature is somehow related to 'pwdReset' and also I preferred a different prefix than the password policy.
> > > I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.
> >
> > Why ? Registration should be done after Now+ValidFromTime and before Now+passwordOTPExpDelay.
> > So the two are useful.
>
> I'd see above :)
> > > The OC should be named onetimepasswordPolicy instead.
> >
> > Do you suggest we have two password policies OC: passwordPolicy and OnTimePasswordPolicy.
> > OTP relying on 'passwordMustChange' then OnTimePasswordPolicy should allow 'passwordMustChange'
>
> Ignore this comment - I think I missed about the passwordPolicy bit :)
> > > Hope that helps!
> >
> > Absolutely it helps a lot. Thanks !
> >
> > thierry
> > > > On 22 Mar 2021, at 21:30, thierry bordaz  wrote:
> > > >
> > > > Hi,
> > > >
> > > > I wrote a small design [1] about OTP password policy that I would like to start implementing.
> > > > Comments are welcome
> > > >
> > > > [1] https://www.port389.org/docs/389ds/design/otp-password-policy.html
> > > >
> > > > best regards
> > > > thierry
> > > > _______________________________________________
> > > > 389-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > >
> > > Senior Software Engineer, 389 Directory Server
> > > SUSE Labs, Australia
> > > _______________________________________________
> > > 389-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia

[Mark Reynolds]

On 3/24/21 6:14 AM, thierry bordaz wrote:
> On 3/24/21 12:16 AM, William Brown wrote:
> > > On 24 Mar 2021, at 02:12, thierry bordaz  wrote:
> > >
> > > Hi William
> > >
> > > Thanks for you review. Some answers are inlined in the mail below.
> > >
> > > On 3/23/21 12:33 AM, William Brown wrote:
> > > > Hey there,
> > > >
> > > > I think that you also need:
> > > >
> > > > pwdOTPValidFromTime
> > > >
> > > > This way an admin can pre-configure all the OTP's and they only "become valid from" that time frame. IE think university enrollment. You can configure all the OTP's a month before, and they become valid at a specific datetime.
> > >
> > > That is a very nice idea. Note to be OTP the 'userpassword' of the account must be reset by an admin and the account inheriting password policy with OTP settings.
> > > Assuming 'pwdOTPValidFromTime' is the account operational attribute holding a precise time. How should it be computed ? Directly from a precise time set in the password policy or computed from a ' 'passwordOTPValidationDelay' (number of seconds after OTP reset time) or something else ?
> >
> > I think maybe it could be easy to visualise it.
> >
> > We have time going from past to future like:
> >
> > past ---------------------------------------------------------> future
> >
> > So we want a window of:
> > When can the OTP start to be used?
> > When is the OTP no longer able to be used?
> >
> > So my thinking is:
> >
> > past ---------------------------------------------------------> future
> >         ^          ^                 ^
> >         |          |                 |
> >     otp created    |                 |
> >                 otp valid from       |
> >                                   otp expire at
> >
> > So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
>
> Hi William
>
> Good idea of that graphic. I am sorry to be so slow to understand but 
> still things are not clear.
> There are the attributes of the password policy and the operational 
> attribute of the user account.
>
> I think you meant and I agree with you that operational attributes (in 
> the user account) should be absolute date.
> What is not clear to me is how to compute those operational attributes 
> from the password policy.
> I see three options:
> password policy contains absolute time (e.g.
> passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> password policy contains a delay after OTP create/reset (e.g.
> passwordOTPValidFromDelay) => account.validFrom = Now +
> policyValidFromDelay
> password policy contains both and if both are set we should give
> the priority to one or the other
>
> If a password policy is a stable entry, then they should not contain 
> absolute time. If we imagine password policy created on purpose to do 
> a bunch of registration, then that is okay if they contain absolute time.
>
> Do you think we should support password policy with absolute time ?

No we should not store actual times in the config.  These time values 
need to live in the entry itself, just like passwordExpirationtime.  
Perhaps this is a good candidate to handle through the CLI (maybe even a 
new task that uses a filter, base, etc)?

Mark
> thanks
>
> thierry
> > And then within that otp valid from - expire at time window, we have the "max use" field of how many times it can be used.
> >
> > Does that help?
> > > > I think you should make it consistent with passwordOTPExpDelay to pwdOTPExpDelay. Better, OTP means "one time password" so why is it "password one time password". Just make the attributes "OTPExpDelay" or whatever. Alternately make it pwdOT (password one time).
> > >
> > > ATM password policy ('passwordPolicy') only contains 'password*' attributes this is why I would prefer to keep 'passwordOTP*' (e.g. passwordOTPMaxUse, passwordOTPExpirationDelay, passwordOTPValidFromTime').
> > > I agree that 'passwordOTP' looks weird ("password one time password") but the first 'password' is the way the password policy attribute are prefixed.
> >
> > Ahh I think I missed that this is using the userPassword and combined with passwordPolicy. That makes sense now.
> >
> > Still better to keep it consistent - all pwd or all password. I think you mix/match these ....
> > > Then the account operational attributes updated via  password policy. There is a mix.
> > > 6 out of 10 start with 'password' (like 'passwordExpirationTime')
> > > 2 out of 10 start with 'pwd' (like 'pwdReset')
> > > The two remaining are 'retryCountResetTime' and 'accountUnlockTime'.
> > > I choose the 'pwdOTP' prefix because the feature is somehow related to 'pwdReset' and also I preferred a different prefix than the password policy.
> > > > I think passwordOTPExpDelay can be remove if you have ValidFromTime instead.
> > >
> > > Why ? Registration should be done after Now+ValidFromTime and before Now+passwordOTPExpDelay.
> > > So the two are useful.
> >
> > I'd see above :)
> > > > The OC should be named onetimepasswordPolicy instead.
> > >
> > > Do you suggest we have two password policies OC: passwordPolicy and OnTimePasswordPolicy.
> > > OTP relying on 'passwordMustChange' then OnTimePasswordPolicy should allow 'passwordMustChange'
> >
> > Ignore this comment - I think I missed about the passwordPolicy bit :)
> > > > Hope that helps!
> > >
> > > Absolutely it helps a lot. Thanks !
> > >
> > > thierry
> > > > > On 22 Mar 2021, at 21:30, thierry bordaz  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I wrote a small design [1] about OTP password policy that I would like to start implementing.
> > > > > Comments are welcome
> > > > >
> > > > > [1]https://www.port389.org/docs/389ds/design/otp-password-policy.html
> > > > >
> > > > > best regards
> > > > > thierry
> > > > > _______________________________________________
> > > > > 389-devel mailing list [e-mail]
> > > > > To unsubscribe send an email [e-mail]
> > > > > Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives:https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > > > Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
> > > >
> > > > —
> > > > Sincerely,
> > > >
> > > > William Brown
> > > >
> > > > Senior Software Engineer, 389 Directory Server
> > > > SUSE Labs, Australia
> > > > _______________________________________________
> > > > 389-devel mailing list [e-mail]
> > > > To unsubscribe send an email [e-mail]
> > > > Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:https://lists.fedoraproject.org/archives/list/[e-mail]....
> > > > Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs, Australia
>
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[William Brown]

> > > I think maybe it could be easy to visualise it.
> > >
> > > We have time going from past to future like:
> > >
> > > past ---------------------------------------------------------> future
> > >
> > > So we want a window of:
> > > When can the OTP start to be used?
> > > When is the OTP no longer able to be used?
> > >
> > > So my thinking is:
> > >
> > > past ---------------------------------------------------------> future
> > >        ^          ^                 ^
> > >        |          |                 |
> > >    otp created    |                 |
> > >                otp valid from       |
> > >                                  otp expire at
> > >
> > > So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
> >
> > Hi William
> >
> > Good idea of that graphic. I am sorry to be so slow to understand but still things are not clear.
> > There are the attributes of the password policy and the operational attribute of the user account.
> >
> > I think you meant and I agree with you that operational attributes (in the user account) should be absolute date.
> > What is not clear to me is how to compute those operational attributes from the password policy.
> > I see three options:
> >    • password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> >    • password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
> >    • password policy contains both and if both are set we should give the priority to one or the other
> > If a password policy is a stable entry, then they should not contain absolute time. If we imagine password policy created on purpose to do a bunch of registration, then that is okay if they contain absolute time.
> >
> > Do you think we should support password policy with absolute time ?
>
> No we should not store actual times in the config.  These time values need to live in the entry itself, just like passwordExpirationtime.  Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?

I'm a bit confused about this answer but:

I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.

There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
> Mark

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia

[Mark Reynolds]

On 3/24/21 8:32 PM, William Brown wrote:
> > > > I think maybe it could be easy to visualise it.
> > > >
> > > > We have time going from past to future like:
> > > >
> > > > past ---------------------------------------------------------> future
> > > >
> > > > So we want a window of:
> > > > When can the OTP start to be used?
> > > > When is the OTP no longer able to be used?
> > > >
> > > > So my thinking is:
> > > >
> > > > past ---------------------------------------------------------> future
> > > >         ^          ^                 ^
> > > >         |          |                 |
> > > >     otp created    |                 |
> > > >                 otp valid from       |
> > > >                                   otp expire at
> > > >
> > > > So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
> > >
> > > Hi William
> > >
> > > Good idea of that graphic. I am sorry to be so slow to understand but still things are not clear.
> > > There are the attributes of the password policy and the operational attribute of the user account.
> > >
> > > I think you meant and I agree with you that operational attributes (in the user account) should be absolute date.
> > > What is not clear to me is how to compute those operational attributes from the password policy.
> > > I see three options:
> > >    • password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> > >    • password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
> > >    • password policy contains both and if both are set we should give the priority to one or the other
> > > If a password policy is a stable entry, then they should not contain absolute time. If we imagine password policy created on purpose to do a bunch of registration, then that is okay if they contain absolute time.
> > >
> > > Do you think we should support password policy with absolute time ?
> >
> > No we should not store actual times in the config.  These time values need to live in the entry itself, just like passwordExpirationtime.  Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?
>
> I'm a bit confused about this answer but:

Theirry thought you wanted to set:

dn: cn=config
     passwordOTPStartTime: 2021034578489754Z

But I was saying it should be in the entry, not cn=config, like how we 
use passwordExpirationtime:

uid=mark,dc=example,dc=com
     passwordOTPStartTime: 2021034578489754Z

Mark
> I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.
>
> There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
> > Mark
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia

[William Brown]

> On 25 Mar 2021, at 12:00, Mark Reynolds  wrote:
>
> On 3/24/21 8:32 PM, William Brown wrote:
> > > > > I think maybe it could be easy to visualise it.
> > > > >
> > > > > We have time going from past to future like:
> > > > >
> > > > > past ---------------------------------------------------------> future
> > > > >
> > > > > So we want a window of:
> > > > > When can the OTP start to be used?
> > > > > When is the OTP no longer able to be used?
> > > > >
> > > > > So my thinking is:
> > > > >
> > > > > past ---------------------------------------------------------> future
> > > > >        ^          ^                 ^
> > > > >        |          |                 |
> > > > >    otp created    |                 |
> > > > >                otp valid from       |
> > > > >                                  otp expire at
> > > > >
> > > > > So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
> > > >
> > > > Hi William
> > > >
> > > > Good idea of that graphic. I am sorry to be so slow to understand but still things are not clear.
> > > > There are the attributes of the password policy and the operational attribute of the user account.
> > > >
> > > > I think you meant and I agree with you that operational attributes (in the user account) should be absolute date.
> > > > What is not clear to me is how to compute those operational attributes from the password policy.
> > > > I see three options:
> > > >    • password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> > > >    • password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
> > > >    • password policy contains both and if both are set we should give the priority to one or the other
> > > > If a password policy is a stable entry, then they should not contain absolute time. If we imagine password policy created on purpose to do a bunch of registration, then that is okay if they contain absolute time.
> > > >
> > > > Do you think we should support password policy with absolute time ?
> > >
> > > No we should not store actual times in the config.  These time values need to live in the entry itself, just like passwordExpirationtime. Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?
> >
> > I'm a bit confused about this answer but:
>
> Theirry thought you wanted to set:
> dn: cn=config
> passwordOTPStartTime: 2021034578489754Z
>
>
> But I was saying it should be in the entry, not cn=config, like how we use passwordExpirationtime:
> uid=mark,dc=example,dc=com
> passwordOTPStartTime: 2021034578489754Z

Yep, this is exactly what I meant :)
> Mark
> > I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.
> >
> > There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
> > > Mark
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs, Australia
>
> --
>
> 389 Directory Server Development Team

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia

[thierry bordaz]

On 3/25/21 3:20 AM, William Brown wrote:
> > On 25 Mar 2021, at 12:00, Mark Reynolds  wrote:
> >
> > On 3/24/21 8:32 PM, William Brown wrote:
> > > > > > I think maybe it could be easy to visualise it.
> > > > > >
> > > > > > We have time going from past to future like:
> > > > > >
> > > > > > past ---------------------------------------------------------> future
> > > > > >
> > > > > > So we want a window of:
> > > > > > When can the OTP start to be used?
> > > > > > When is the OTP no longer able to be used?
> > > > > >
> > > > > > So my thinking is:
> > > > > >
> > > > > > past ---------------------------------------------------------> future
> > > > > >         ^          ^                 ^
> > > > > >         |          |                 |
> > > > > >     otp created    |                 |
> > > > > >                 otp valid from       |
> > > > > >                                   otp expire at
> > > > > >
> > > > > > So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
> > > > >
> > > > > Hi William
> > > > >
> > > > > Good idea of that graphic. I am sorry to be so slow to understand but still things are not clear.
> > > > > There are the attributes of the password policy and the operational attribute of the user account.
> > > > >
> > > > > I think you meant and I agree with you that operational attributes (in the user account) should be absolute date.
> > > > > What is not clear to me is how to compute those operational attributes from the password policy.
> > > > > I see three options:
> > > > >    • password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> > > > >    • password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
> > > > >    • password policy contains both and if both are set we should give the priority to one or the other
> > > > > If a password policy is a stable entry, then they should not contain absolute time. If we imagine password policy created on purpose to do a bunch of registration, then that is okay if they contain absolute time.
> > > > >
> > > > > Do you think we should support password policy with absolute time ?
> > > >
> > > > No we should not store actual times in the config.  These time values need to live in the entry itself, just like passwordExpirationtime. Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?
> > >
> > > I'm a bit confused about this answer but:
> >
> > Theirry thought you wanted to set:
> >  dn: cn=config
> >  passwordOTPStartTime: 2021034578489754Z
> >
> >
> > But I was saying it should be in the entry, not cn=config, like how we use passwordExpirationtime:
> >  uid=mark,dc=example,dc=com
> >  passwordOTPStartTime: 2021034578489754Z
>
> Yep, this is exactly what I meant :)
> > Mark
> > > I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.

Thanks Mark, William for the clarification.
Actually OTP is an extension of the current password policy. So there 
are new attribute in the password policy entry and new (operational) 
attributes in the account entry.

I understand and agree that attributes (in the account entry) that 
represent a window of validity will be absolute time.

For example we will have, assuming that an admin reset the userpassword 
of 'uid=mark' at 10AM we will have

dn: cn=config
passwordMustChange: on
passwordOTPValidFromDelay: 1800
passwordOTPExpireDelay: 3600
passwordOTPMaxUse: 3

dn: uid=mark,dc=example,dc=com
userpassword: xxx
pwdOTPReset: true
pwdOTPUseCount: 0
pwdOTPValidFrom: 20210325103000Z
pwdOTPExpireAt: 20210325110000Z

Meaning the user 'Mark' should complete his registration between 10:30AM 
and 11AM and he will be granted 3 tries to bind with the registration 
password and change his password

thanks
thierry
> > > There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
> > > > Mark
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > >
> > > Senior Software Engineer, 389 Directory Server
> > > SUSE Labs, Australia
> >
> > --
> >
> > 389 Directory Server Development Team
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia

[William Brown]

> On 25 Mar 2021, at 17:49, thierry bordaz  wrote:
>
> On 3/25/21 3:20 AM, William Brown wrote:
> > > On 25 Mar 2021, at 12:00, Mark Reynolds  wrote:
> > >
> > > On 3/24/21 8:32 PM, William Brown wrote:
> > > > > > > I think maybe it could be easy to visualise it.
> > > > > > > 
> > > > > > > 
> > > > > > > We have time going from past to future like:
> > > > > > > 
> > > > > > > 
> > > > > > > past ---------------------------------------------------------> future
> > > > > > > 
> > > > > > > 
> > > > > > > So we want a window of:
> > > > > > > 
> > > > > > > * When can the OTP start to be used?
> > > > > > > * When is the OTP no longer able to be used?
> > > > > > > 
> > > > > > > So my thinking is:
> > > > > > > 
> > > > > > > past ---------------------------------------------------------> future
> > > > > > >        ^          ^                 ^
> > > > > > >        |          |                 |
> > > > > > >    otp created    |                 |
> > > > > > >                otp valid from       |
> > > > > > >                                  otp expire at
> > > > > > > 
> > > > > > > 
> > > > > > > So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
> > > > > > > 
> > > > > > Hi William
> > > > > >
> > > > > > Good idea of that graphic. I am sorry to be so slow to understand but still things are not clear.
> > > > > > There are the attributes of the password policy and the operational attribute of the user account.
> > > > > >
> > > > > > I think you meant and I agree with you that operational attributes (in the user account) should be absolute date.
> > > > > > What is not clear to me is how to compute those operational attributes from the password policy.
> > > > > > I see three options:
> > > > > >    • password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> > > > > >    • password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
> > > > > >    • password policy contains both and if both are set we should give the priority to one or the other
> > > > > > If a password policy is a stable entry, then they should not contain absolute time. If we imagine password policy created on purpose to do a bunch of registration, then that is okay if they contain absolute time.
> > > > > >
> > > > > > Do you think we should support password policy with absolute time ?
> > > > >
> > > > > No we should not store actual times in the config.  These time values need to live in the entry itself, just like passwordExpirationtime. Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?
> > > >
> > > > I'm a bit confused about this answer but:
> > >
> > > Theirry thought you wanted to set:
> > > dn: cn=config
> > > passwordOTPStartTime: 2021034578489754Z
> > >
> > >
> > > But I was saying it should be in the entry, not cn=config, like how we use passwordExpirationtime:
> > > uid=mark,dc=example,dc=com
> > > passwordOTPStartTime: 2021034578489754Z
> >
> > Yep, this is exactly what I meant :)
> > > Mark
> > > > I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.
>
> Thanks Mark, William for the clarification.
> Actually OTP is an extension of the current password policy. So there are new attribute in the password policy entry and new (operational) attributes in the account entry.
>
> I understand and agree that attributes (in the account entry) that represent a window of validity will be absolute time.
>
> For example we will have, assuming that an admin reset the userpassword of 'uid=mark' at 10AM we will have
>
> dn: cn=config
> passwordMustChange: on
> passwordOTPValidFromDelay: 1800
> passwordOTPExpireDelay: 3600
> passwordOTPMaxUse: 3

I actually don't think any of these fields in cn=config are required, and actually limit the capability of this.
> dn: uid=mark,dc=example,dc=com
> userpassword: xxx
> pwdOTPReset: true
> pwdOTPUseCount: 0
> pwdOTPValidFrom: 20210325103000Z
> pwdOTPExpireAt: 20210325110000Z

You should add pwdOTPMaxUse: X here.

The reason I say this is it grants flexibility. Imagine say ... we are enrolling 10,000 students to a university and creating their new accounts. We want to set exact times on their accounts and say ... given them 10 tries or something.

But at the same time we need to reset someones account. For them, we want them to have say ... 1 attempt to do the reset, and have a different time window.

All the cn=config fields do here is confuse and complicate the system - what is their purpose but to "template" out some values into the entry?

In this matter, I think that all the OTP fields should be on the entry to allow more possibilities of how the pwdOTP can be used in diverse situations.
> Meaning the user 'Mark' should complete his registration between 10:30AM and 11AM and he will be granted 3 tries to bind with the registration password and change his password
>
> thanks
> thierry
> > > > There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
> > > > > Mark
> > > >
> > > > —
> > > > Sincerely,
> > > >
> > > > William Brown
> > > >
> > > > Senior Software Engineer, 389 Directory Server
> > > > SUSE Labs, Australia
> > >
> > > --
> > >
> > > 389 Directory Server Development Team
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs, Australia

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia

[thierry bordaz]

On 3/25/21 11:28 PM, William Brown wrote:
> > On 25 Mar 2021, at 17:49, thierry bordaz  wrote:
> >
> > On 3/25/21 3:20 AM, William Brown wrote:
> > > > On 25 Mar 2021, at 12:00, Mark Reynolds  wrote:
> > > >
> > > > On 3/24/21 8:32 PM, William Brown wrote:
> > > > > > >> I think maybe it could be easy to visualise it.
> > > > > > >>
> > > > > > >>
> > > > > > >> We have time going from past to future like:
> > > > > > >>
> > > > > > >>
> > > > > > >> past ---------------------------------------------------------> future
> > > > > > >>
> > > > > > >>
> > > > > > >> So we want a window of:
> > > > > > >>
> > > > > > >> * When can the OTP start to be used?
> > > > > > >> * When is the OTP no longer able to be used?
> > > > > > >>
> > > > > > >> So my thinking is:
> > > > > > >>
> > > > > > >> past ---------------------------------------------------------> future
> > > > > > >>         ^          ^                 ^
> > > > > > >>         |          |                 |
> > > > > > >>     otp created    |                 |
> > > > > > >>                 otp valid from       |
> > > > > > >>                                   otp expire at
> > > > > > >>
> > > > > > >>
> > > > > > >> So I would say otp valid from and the otp expire should be *absolute* date times in UTC.
> > > > > > >>
> > > > > > > Hi William
> > > > > > >
> > > > > > > Good idea of that graphic. I am sorry to be so slow to understand but still things are not clear.
> > > > > > > There are the attributes of the password policy and the operational attribute of the user account.
> > > > > > >
> > > > > > > I think you meant and I agree with you that operational attributes (in the user account) should be absolute date.
> > > > > > > What is not clear to me is how to compute those operational attributes from the password policy.
> > > > > > > I see three options:
> > > > > > > 	• password policy contains absolute time (e.g. passwordOTPValidFromUTC) => account.validFrom = policyValidFromUTC
> > > > > > > 	• password policy contains a delay after OTP create/reset (e.g. passwordOTPValidFromDelay) => account.validFrom = Now + policyValidFromDelay
> > > > > > > 	• password policy contains both and if both are set we should give the priority to one or the other
> > > > > > > If a password policy is a stable entry, then they should not contain absolute time. If we imagine password policy created on purpose to do a bunch of registration, then that is okay if they contain absolute time.
> > > > > > >
> > > > > > > Do you think we should support password policy with absolute time ?
> > > > > > >
> > > > > > No we should not store actual times in the config.  These time values need to live in the entry itself, just like passwordExpirationtime. Perhaps this is a good candidate to handle through the CLI (maybe even a new task that uses a filter, base, etc)?
> > > > >
> > > > > I'm a bit confused about this answer but:
> > > >
> > > > Theirry thought you wanted to set:
> > > >  dn: cn=config
> > > >  passwordOTPStartTime: 2021034578489754Z
> > > >
> > > >
> > > > But I was saying it should be in the entry, not cn=config, like how we use passwordExpirationtime:
> > > >  uid=mark,dc=example,dc=com
> > > >  passwordOTPStartTime: 2021034578489754Z
> > >
> > > Yep, this is exactly what I meant :)
> > > > Mark
> > > > > I think there are no "operational" attributes here. These should all be absolute dates, set on the entry. No calculation or whatever needed.
> >
> > Thanks Mark, William for the clarification.
> > Actually OTP is an extension of the current password policy. So there are new attribute in the password policy entry and new (operational) attributes in the account entry.
> >
> > I understand and agree that attributes (in the account entry) that represent a window of validity will be absolute time.
> >
> > For example we will have, assuming that an admin reset the userpassword of 'uid=mark' at 10AM we will have
> >
> > dn: cn=config
> > passwordMustChange: on
> > passwordOTPValidFromDelay: 1800
> > passwordOTPExpireDelay: 3600
> > passwordOTPMaxUse: 3
>
> I actually don't think any of these fields in cn=config are required, and actually limit the capability of this.

This was an example for global password policy settings. These new 
attributes are supported in global pwp but also in pwpolicysubentries.
> > dn: uid=mark,dc=example,dc=com
> > userpassword: xxx
> > pwdOTPReset: true
> > pwdOTPUseCount: 0
> > pwdOTPValidFrom: 20210325103000Z
> > pwdOTPExpireAt: 20210325110000Z
>
> You should add pwdOTPMaxUse: X here.
>
> The reason I say this is it grants flexibility. Imagine say ... we are enrolling 10,000 students to a university and creating their new accounts. We want to set exact times on their accounts and say ... given them 10 tries or something.
>
> But at the same time we need to reset someones account. For them, we want them to have say ... 1 attempt to do the reset, and have a different time window.
>
> All the cn=config fields do here is confuse and complicate the system - what is their purpose but to "template" out some values into the entry?

The only benefit I see (but I may miss something) in adding pwdOTPMaxUse 
in the account entry is in the case the password policies may change 
frequently. If we want to be sure the exact setting of the password 
policy at the time of the reset will be enforced, even if the password 
policy change later, then we have to copy that value in the entry.
During a bind attempts, we are retrieving the password policy that 
applies to that target bind entry and we can enforce the pwp without 
storing it in the target entry.

thanks
thierry
> In this matter, I think that all the OTP fields should be on the entry to allow more possibilities of how the pwdOTP can be used in diverse situations.
> > Meaning the user 'Mark' should complete his registration between 10:30AM and 11AM and he will be granted 3 tries to bind with the registration password and change his password
> >
> > thanks
> > thierry
> > > > > There is no policy at all. Basicly you just have a mechanic that sets on the account that this password is only valid in these time windows, and can only be used a maximum number of times.
> > > > > > Mark
> > > > >
> > > > > —
> > > > > Sincerely,
> > > > >
> > > > > William Brown
> > > > >
> > > > > Senior Software Engineer, 389 Directory Server
> > > > > SUSE Labs, Australia
> > > >
> > > > --
> > > >
> > > > 389 Directory Server Development Team
> > >
> > > —
> > > Sincerely,
> > >
> > > William Brown
> > >
> > > Senior Software Engineer, 389 Directory Server
> > > SUSE Labs, Australia
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia