Subject: [APPS-REVIEW] Review of draft-wahl-ldap-adminaddr

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 25 May 2007 07:24:06 -0700

I reviewed this draft on behalf of the Apps Area Review team and the  
LDAP Directorate.
Such reviews have no special weight in the IETF.

Summary:  This I-D specifies the administratorsAddress attribute type  
for use in
LDAP directory services to hold contact information about an  
"administrator".

This document has a few minor issues.  Once addressed, I see no  
problem with publication
of this document.

The attribute type was described in an ASID WG draft as having  
dSAOperation usage,
which is generally appropriate for attributes providing information  
specific to the
DSA (server).   In this I-D it has directoryOperation usage.  I  
assume the change
was due to allowing the attribute not only to appear in the Root DSE,  
but in entries
at the context prefix.  I don't have any problem with this change,  
but it likely
should be noted.

Might be good to expand its applicability to other subentries.  For  
instance, when
placed in a collective attribute subentry, the attribute would  
contain the address of the
party responsible for the content of that subentry.  Expansion beyond  
this would likely
be problematic.

Should likely have an equality matching rule as well, but no ordering  
or substrings rule.

As the syntax, IA5String, is not constrained to URIs, the I-D should  
say something
about what clients should do when the value isn't a valid URI.   
(Treat it like an
non-resolvable URI.)

I do find the uses of SHOULD in the Security Consideration section  
kind of odd.  Use
of RFC 2119 keywords should be limited to specification of  
implementation requirements.
It would be appropriate to say that access to this attribute SHOULD  
be controlled
by the server's authorization mechanisms, any guidance to the server  
administrator
as to what access policy for this attribute should be stated as  
guidance.

    Since one use of this attribute is to find who is responsible if the
    server is not making authentication decisions properly, a directory
    server configuration SHOULD cause the attribute in the root DSE, if
    present, to be able to be returned in a search response to all users
    who are permitted to access the directory server.

If the user cannot authenticate, he's anonymous to the server, so by  
the above,
I assume you mean:
	Since one use of this attribute is to find who is responsible if the
	server is not making authentication decisions properly, it may be
	appropriate to allow anonymous access this information (with or without
	other administrative restrictions).
(your wording could be taken a number of odd ways)

I suggest stating that servers SHOULD allow the administrator to control
access to this attribute (via whatever access control mechanisms it  
offers).
And where they don't allow the administrator to control access, they  
MUST
allow the administrator to elect not to publish contact information.

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 30 May 2007 12:39:37 -0700

On May 30, 2007, at 9:36 AM, Mark Wahl wrote:

> Kurt Zeilenga wrote:
>> I reviewed this draft on behalf of the Apps Area Review team and  
>> the LDAP Directorate.
>
> Thanks for your comments on these drafts! I'll be reviewing your
> emails and will respond shortly with more details.
>
> If so, then RFC 2119 should be revised to incorporate that limitation,
> as I don't see that stated in 2119, and I observe in recently  
> published
> proposed standard RFCs the use of RFC 2119 terminology in the security
> considerations sections to make statements beyond implementation
> requirements, e.g., RFC 4875 "Specifications of applications within  
> the
> IETF MUST specify this mechanism" or RFC 4872 "RSVP signaling MUST be
> able to provide authentication and integrity".

There are plenty of examples of RFC 2119 keywords being oddly used...
(including RFC 2119 itself).  As I wasn't intending to start a debate on
use of RFC 2119 keywords,  I suggest you can take my RFC 2119  
comments as
indicating a concern that the document may not be clear as whom its
requirements are placed upon.  For instance,
   "The server's access control policy SHOULD allow this information to
    be visible to a suitable administrator in the same organization.

can be taken to mean:
    The server SHOULD restricted allowable access control policies to  
those
    which cause this information to be visible to suitable  
administrators in
    the same organization.

Which, if implemented in a server, would be quite bad.

To avoid such confusion, I recommend you only use RFC 2119 keywords  
to impart
requirements upon implementations of the specification and to word  
recommendations
to server administrators as guidance.

-- Kurt

---

From: Mark Wahl <[email-masked]>
Date: Wed, 30 May 2007 11:36:25 -0500

> I do find the uses of SHOULD in the Security Consideration section kind 
> of odd.  Use

If so, then RFC 2119 should be revised to incorporate that limitation,
as I don't see that stated in 2119, and I observe in recently published
proposed standard RFCs the use of RFC 2119 terminology in the security
considerations sections to make statements beyond implementation
requirements, e.g., RFC 4875 "Specifications of applications within the
IETF MUST specify this mechanism" or RFC 4872 "RSVP signaling MUST be
able to provide authentication and integrity".

Mark Wahl
Informed Control Inc.