Re: [ldapext] DBIS - new IETF drafts

[Mark R Bannister <[e-mail]>]

On 06/01/2014 21:57, Howard Chu wrote:
> Mark R Bannister wrote:
>> Do you have any more alarming problems that can be turned into simple
>> requests?
>
> Just read thru 
> http://www.ietf.org/id/draft-bannister-dbis-policy-02.txt and again 
> there's a lot of redundant work here, this time in regards to 
> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10

Originally I had shadow attributes mingled in with the user and group 
document, as it is in RFC2307, however I decided quite late on in fact 
that it would be better as a separate bolt-on option.  So it went into 
its own draft.  I thought I'd already made it clear in the drafts that 
password policies are best handled a separate way, however, DBIS would 
be incomplete if it did not support the old NIS way of doing it as 
well.  I don't personally like the idea of having per-user shadow 
attributes, however some might see it as a feature and there may be some 
edge cases where this is exactly what is required.  So, what's the harm 
in supporting it?  As long as I make it clear that it is not 
recommended, which is the intention of the following paragraph in 
section 1.1.1:

    It is RECOMMENDED that password policies are managed using native
    features in the LDAP Directory Server if available, or using
    Pluggable Authentication Modules [PAM] to provide consistency of
    security and centralised administration.  Whether or not the shadow
    attributes are used by the policy will vary between implementations.

Perhaps we can work this paragraph better.  I must admit I haven't seen 
draft-behera-ldap-password-policy-10 so I shall add that to my reading list.

>
> The obvious issue is collisions in some attribute descriptors with the 
> ppolicy spec, which is already widely deployed.

draft-behera-ldap-password-policy-10 is already widely deployed, you 
say?  Then it must go higher up in my reading list.

>
> More problematic is the data model itself, again. Storing the actual 
> policy settings in the user entries will be unmanageable for any 
> moderately large sized user population. This is one reason why 
> draft-behera uses dedicated policy objects. It is the client side 
> DUA's job to adapt the universal data store to the local host's 
> security implementation. And we already have 
> pam_ldap/nss_ldap/nss-pam-ldapd/nssov to perform these adaptations, so 
> I don't see much value in defining yet another new broken data model 
> that has no existing client support.

Indeed, I agree, as stated earlier on I would whole-heartedly recommend 
against having user-specific policy settings.  However, providing the 
facility as an option for those who want to make minimal changes to 
their NIS environment is harmless.

>
> As much as you claim to have read and absorbed the prior work in this 
> area, it really appears that you have ignored most of it.

Appearances can be deceptive.  If you ask me for a reason why I did 
something in a particular way, you'll realise I have actually put a lot 
of thought into the entire design.  I haven't ignored RFC2307 nor 
RFC2307bis, nor indeed any of the RFCs I make reference to in my 
drafts.  I was unaware of draft-behera-ldap-password-policy-10 so thank 
you for pointing this out.  I suspect it will not make a big difference 
short of perhaps becoming the recommended approach.  I'll review it and 
let you know what I think afterwards.

Best regards,
Mark.