Re: Gen-ART LC Review of draft-zeilenga-ldap-dontusecopy-08

[Kurt Zeilenga <[e-mail]>]

Ben,

Thank you for your comments.  They have lead to a number of improvements in the I-D (new revision to be published shortly).  A few notes below.

-- Kurt

On Oct 11, 2010, at 2:39 PM, Ben Campbell wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-zeilenga-ldap-dontusecopy-08
> Reviewer: Ben Campbell
> Review Date: 2010-10-11
> IETF LC End Date: 2010-10-11
> IESG Telechat date: (if known)
> 
> Summary:
> 
> This draft is almost ready to be published as a proposed standard, but I have some comments that should be considered first.
> 
> Major issues: None
> 
> Minor issues:
> 
> -- General: 
> 
> (Let me preface my general comments with the admission that I am not an LDAP expert. Since this is a Gen-ART review, I'm approaching this as a generalist. If the answer is something like "Ben, if you new anything about LDAP this would all be obvious to you", that will not offend me in any way.)
> 
> I'd like to see more explanation of the problem this needs to be solved.

The short explanation is that acting upon slate data can introduce security vulnerabilities in directory applications.

Exactly how a directory application might be vulnerable depends a great deal on the particulars of the directory application.

The intent of this specification is merely to provide a tool, long present in X.500 directory applications, to LDAP directory applications.

> I assume that there is concern that copied or cached data may not be up to date, or otherwise not be authoritative. Some comments to that effect, along with reasoning for why this may happen in the first place would be helpful. A quick scan of 4511 and 4512 didn't turn up much about this, other than some passing references that some servers may shadow or cache dats from other servers., and not to accept modification requests against cached or shadowed data. Is there any other specification about LDAP cacheing, maintaining cache freshness, etc?

The reference, I guess, would be X.500 series of documents.  LDAP is specified as alternative access protocol to an X.500 directory service.

While this document only has an informative reference to its X.500 counterpart, I note that this document does contain a normative reference to the LDAP technical specification [RFC4510] which does include normative references to relevant X.500 specifications.   I do not reference X.500 normatively here as I believe a developer can well implement this control, by itself, without ever having read a X.500 specification.

> I get a gut feeling that this extension effectively patches a hole in an implied delegation model for LDAP, but I don't find much in the way of explicit specification for that in the referenced docs (Maybe I should be looking at X.500 specs?). I'm not saying that this document should be burdened with a formal specification of the LDAP delegation model. But I think a little more context would be helpful.

I really don't think it necessary to understand the particulars the X.500/LDAP delegation model to understand when and how this control ought to be used.  Basically, some knowledge a server might rely on in answering a question can be stale.  Use of stale data can be problematic.  This control says "don't use stale data".

> I'd also like to see some more guidance on when it's reasonable to use this extension. For example, wouldn't a client always want an authoritative answer to an interrogation?

Generally, clients should only use this control when there is a directory application need for it to be used.

> Why wouldn't it use this extension all the time?

Because that would eliminate all the benefits of caching and shadowing of data.

> Does it hurt anything if it does?

It can "break" the application.  In general, applications ought to be designed to well use copied information.

Anyways, I'll make some minor tweaks here to address these points.

> 
> -- section 3, 2nd paragraph:
> 
> I think this paragraph might be better restated normatively.

I'm not sure what you mean by "normatively" as I feel it obvious that whole section a normative part of the specification.   I guess what you might mean is use RFC 2119 keywords here.  I rather not.  Aside from RFC 2119 saying keywords ought to be sparingly, to me, MUST and SHOULDs are best used to impart implementation requirements and recommendations, especially those which if not followed will result in some significant peculiar behavior.

> 
> -- section 4:
> 
> The security consideration comments seem to be about caching in general. Does this extension make things any better or worse?

The extension is a tool which, if used well, can be used to mitigate certain threats.

I'll be replacing the security considerations text with the text provided by Phillip Hallam-Baker plus some, which should better cover this.

> RFC4510 has nothing to say about security beyond referring the reader to the security considerations in the technical specs.
> 
> Nits/editorial comments:
> 
> -- General
> 
> There seems to be inconsistent use of the terms "copy", "shadow", "cache",  "original" , and "master" between this draft and RFC 4510 and 4512.

I've tried to avoid some of the pitfalls of inconsistent LDAP/X.500 terminology in this document by trying not rely on any particular external use of the term, though I've added comments such as "original (master)" for clarification.

> Maybe adding these terms to the terminology sections would help.

Frankly, I would be hard pressed to clearly define these terms as LDAP/X.500 is a terminology mess.  The best I can do is make it clear to the read of this document the intended semantics of this control:  with control you get authoritative data or an error, without this control you may get non-authoritative data.

> 
> -- Section 1, paragraph 3:
> 
> Please expand DN on first use.
> 
>