Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"

From: [email-masked]
Date: Thu, 06 Jul 2000 23:23:09 -0700

At 12:31 PM 6/29/00 -0700 on Thu, 29 Jun 2000, Kurt Zeilenga wrote:
> >I feel:
> >	a) an applicability statement is needed
> >	b) RFC2251-56,2829-30 need revision (some more than others)
> >
> >These, in my opinion, are separate issues.

I certainly agree.

Kurt then said on Thu, 29 Jun 2000 16:06:31:
> On second thought, I guess I would have to object to
> the progression of the AS if it included any changes
> to the technical specification.
> 
> If one were to rescind the IESG notice, I would think
> it appropriate to strength the Security Considerations
> of the specifications.  Something like:
>    Update functionality SHOULD be restricted to securely
>    authenticated clients.
> 
> As such, I cannot support progressing the AS in its
> current form as it would either result in inadequate
> specification of Security Considerations or would
> modify the technical specification.

RFC2829's explicit purpose is to provide exactly the enhancement to 
LDAPv3-as-a-whole's "Security Considerations" that you're calling for. From 
2829's introduction..

   It [LDAPv3] offers means of searching, fetching and manipulating 
   directory content, and ways to access a rich set of security functions.

   In order to function for the best of the Internet, it is vital that
   these security functions be interoperable; therefore there has to be
   a minimum subset of security functions that is common to all
   implementations that claim LDAPv3 conformance.

2829 goes on to specify, in detail, conformance requirements for security for 
LDAPv3 clients and servers. Note that 2829 is not Informational -- it is a 
standards-track doc and is at Proposed Std maturity level right along with 
2251..2256 & 2830.

All that the proposed LDAPv3 Applicability Statement 
(draft-hodges-ldapv3-as-00.txt)
is saying is..

  "the specific requirements of the IESG Note on 2251..2256 are now met, 
   thus the Note is rescinded, plus these  docs -- 2251..2256, 2829, 2830
   -- comprise LDAPv3". 

It seems to us that the present-day artifact that is LDAPv3 is still somewhat 
fuzzily defined in the absence of an AS saying these simple, specific things.

We've gone through a lot of work over the past several years to get 2829 & 
2830 to their present state -- much of the purpose behind that work was to be 
able to take the step of crisply delineating, sans IESG reservations, LDAPv3 
as-presently-constituted.

This does not mean that there is not lots of work remaining. And it does not 
mean at all that LDAPv3 as-specified by "2251..2256, 2829, 2830, + the AS" 
should progress to Draft or beyond without further work.

What it does mean is that we'll be providing an unambiguous definition, 
including security considerations, of what we mean ~today~ when we 
-- or any of the many implementors & vendors out there -- say "LDAPv3".

JeffH

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Jul 2000 13:21:23 -0700

>>    Update functionality SHOULD be restricted to securely

Note that RFC2829 nor RFC2830 adds a requirement similar
to the above statement.  They only "encourage" servers to prevent
update by anonymous users.  This, IMO, is insufficient.

Recall that the IESG notice states:
        "Update access requires secure authentication"

This could (though not my preferred solution) be addressed in the
Applicability Statement by adding:
   "Implementations of LDAPv3 SHOULD restrict update functionality
   described in RFC2251 to clients which have authenticated using
   a secure mechanism as described in RFC 2829."

>LDAPv3-as-a-whole's "Security Considerations" that you're calling for.

Where does it provide an explicit requirement statement which restricts,
with SHOULD or MUST, update functionality to securely authenticated
clients.  This is what I am calling for.

>fuzzily defined in the absence of an AS saying these simple, specific things.

I agree that LDAPv3 is still "somewhat fuzzy" and that an applicability
statement is needed.

>-- or any of the many implementors & vendors out there -- say "LDAPv3".

I find that the AS creates an unambiguous definition, in particular, in
regards to security considerations.   I would much rather publish an
AS which states that LDAPv3 'requires' implementation of the listed
RFCs WITHOUT rescinding the notice or otherwise updating the
specifications.  I believe rescinding of the notice is best left to later
revision of the technical specifications.