Skip to main content

Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control
RFC 4370

Discuss


Yes

(Ted Hardie)

No Objection

(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Scott Hollenbeck)

Abstain


Note: This ballot was opened for revision 13 and is now closed.

(Ned Freed; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2004-02-12)
This document says:

   The criticality MUST be present and MUST be TRUE. This requirement 
   protects clients from submitting a request that is executed with an 
   unintended authorization identity. 
    
Client requirements like this only protect clients that follow the rules.
A server requirement, on the other hand, protects against broken clients.
Given the likihood of security violations and screwy behavior if this
isn't enforced, I suggest changing this to read something like this:

   Clients MUST include the criticality flag and MUST set it to TRUE.
   Servers MUST reject any request containing a Proxy Authorization
   Control without a criticality flag or with the flag set to FALSE
   with a <?> error. These requirements protects clients from
   submitting a request that is executed with an unintended
   authorization identity. 

I'm not wild about leaving the determination of proxy access rights
as an implementation detail, but given the situation surrounding
access control in LDAP in general I suppose we can do no better
at this time.

Nit: (date) in copyright field

(Ted Hardie; former steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection (2004-03-17)
My no-objection is based on a lack of time to review the preceding work on LDAP 
authentication and authorization that seems to be presumed here.  It would be a
good idea if there some delineation of these dependencies, even if brief.   (I'm
not requiring a change, must making the comment).

(Bert Wijnen; former steering group member) No Objection

No Objection (2004-03-18)
Mmmm.. I see reference:

   [KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
        Requirement Levels", draft-bradner-key-words-03.txt, January,
        1997.

I guess that should just be RFC2119 !!

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-03-17)
Spencer Dawkins, Gen-ART reviewer, has made some editorial comments.
To save space on the evaluation form, I've recorded these in the tracker log.
They are also at <http://www.alvestrand.no/ietf/gen/reviews/draft-weltman-ldapv3-proxy-12-dawkins.txt>

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2004-02-17)
  No one is happy with the current situation regarding access control
  in LDAP.  Leaving the determination of proxy access rights as an
  implementation detail is not going to improve the situation, and it
  will probably make it worse.  However, I have no guidance to offer.

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Steven Bellovin; former steering group member) (was Discuss) Abstain

Abstain (2004-03-18)
I'm very confused by this document -- what, precisely, does it define? 
Is its whole purpose the definition of the OID?  Proxies done properly
are typically bound to the principal to whom some access right is being
delegated, and often contain a set of restrictions as well.  This seems
to give carte blanche to anyone who has the magic string to do anything
at all.