ietf
[Top] [All Lists]

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

2011-01-06 15:59:43
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.



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Gen-ART LC Review of draft-zeilenga-ldap-dontusecopy-08, Kurt Zeilenga <=