Re: [ldapext] DBIS - new IETF drafts

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

On 06/01/2014 18:41, Simo wrote:
> I have to say I have to agree with Howard here, although I wouldn't 
> consider rfc2307bis *the* solution, at least it tried to fix some of 
> the most glaring issues ion rfc2307, there is lots that can be 
> improved of course, but the direction is good. 

As I wrote in my response to Howard just now, I considered both RFC2307 
and the improvements made in RFC2307bis when I wrote the DBIS drafts.  I 
have not disregarded lessons learned from the past, I am simply 
attempting to move it onto the next logical step.  Look harder, I think 
you'll see a lot of technical content you recognise (although admittedly 
I couldn't keep much of the descriptive text because it didn't fit the 
new model).

>> If you're going to all the trouble of storing data into a universally
>> accessible distributed database, you must store it in a canonical format, not
>> a particular OS-specific format as NIS/RFC2307 did.
> If there is a flawed model that should *not* be followed going forward that is NIS.
> And especially netgroups, please spare us from the disease of NIS
> netgroups, they should be buried, there are much better ways to group
> diverse objects.

Please provide a technical description of "disease" please, because it's 
hard to do anything constructive with a statement like that. Like it or 
not, there are very big installations out there using NIS or RFC2307 and 
netgroups.  If netgroups have been built into the way a corporation 
works, they'll possibly never be extracted.  Embrace and extend (without 
the extinguish) if you'd like to bring those corporations with you and 
make improvements for everyone.  Ignore them, and you get IPv6 all over 
again.  I have taken netgroups and tried to take the "disease" out of 
them, while providing a clear migration path, but was it the same 
disease you were suffering?  I don't know.  Perhaps.  More detail please.

>
>> A lot of the data elements and behaviors that the DBIS spec defines appear to
>> be client-implementation-specific details. It seems to me their definition is
>> inappropriate in (outside the scope of) a universally accessible distributed
>> data context.
> Same concerns here.

As before, I'm not sure I understand what you mean.  Please provide 
specific examples.

>> The discussion of caching here
>> http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example
>> - this is purely a client-side implementation issue. Also you give nscd as an
>> example, and nscd has been thoroughly discredited and is well known to be
>> unsuitable for real use. Critical deployments can use a local LDAP server with
>> a replica of the central data, to avoid error-prone caching implementations.
>> This is a commonly recommended approach when using OpenLDAP nssov, for example.
> I do not think this section is particularly bad though.
> It just mentions nscd (bad as it is) as an example but all it really
> does is to prescribe the use of a domain level ttl for all entries. That
> may be useful, but I am not sure it sufficient, at the very least you
> would have to define also how the client handles negative caching and
> have a different timeout there. In the SSSD project we also have
> additional knobs, it is a more complex than you think at first area, and
> using nscd as a blue print is a bad idea.

Yes I have also had similar thoughts about negative caching.  On the one 
hand, not mentioning it at all implies there is one TTL for everything 
(positive and negative) but leaves room for a local implementation to 
vary that.  On the other hand, if there is no standard place to store a 
negative TTL then we get fragmentation and I'd like to avoid that.  This 
was the whole point about putting a framework out there, because at the 
moment too many of these configuration attributes today are 
implementation specific and scattered around the place.  DBIS aims to 
provide a single place that describes how the whole domain is 
configured, right down to the nuts and bolts.  About all a local 
configuration file would need to know is how to contact the LDAP server 
and a base DN for the domain.  Everything else it needs to know is in a 
standard place in the DIT.

>> I agree that this area of spec needs to be polished up, but not by
>> disregarding all of the work that was done and experience that has been gained
>> since the original RFC2307 was published.
> Ack.
>
> For the security point of view I find it extremely amusing that the
> drafts assumes distribution of the hashes to clients (and mandates the
> use of CRYPT to top it all!). I think that is a very wrongheaded
> approach and should not be pursued at all.

CRYPT is a throwback to RFC2307bis and provides a place to start. That's 
why these are drafts, because they are a work in progress.  I need to 
support old clients as well as new clients, possibly old clients that 
cannot be upgraded.  Backwards compatibility is important.  If DBIS 
doesn't support CRYPT, how do I support the old clients?  Suggestions 
welcomed.  Now I was considering implementing pseudo NIS servers that 
act as a gateway for NIS clients that can't be upgraded, but the PAM 
modules on the old clients are going to expect passwords in CRYPT format 
I assume?  I had yet to prove this in a lab environment, but until now I 
assumed that CRYPT would have to be the lowest common denominator, I'd 
have to support it.  Better authentication schemes can be added as and 
when I found the time to further explore the options.

>
> Mark,
> you are obviously building new clients as nothing existing supports your
> schema so you have to implement new stuff. With this premise keeping
> distributing hashes to any machines on a network instead of relying on a
> LDAP bind operation and keeping hashes private is simply not acceptable
> in 2014 IMO and should not be ratified in IETF as a standard.
>
> Simo.
>
>

I agree the authentication piece always made me uncomfortable, but then 
I'm no expert on the subject.  Find me an expert, lock us in a room with 
a whiteboard, and I'm sure we'll come out with something that ticks all 
the right boxes, my previous paragraph notwithstanding.

Best regards,
Mark Bannister.

e: [e-mail]