Evaluation: draft-ietf-webdav-acl-12

[Russ Housley <housley@vigilsec.com>]

  WebDAV Access Control Protocol (Proposed Standard)

  Russ Housley         [   ]     [   ]     [   ]     [ X ]

  This specification is ambitious and daunting in its generality; it seeks 
to define and manage an abstract meta-model of reference monitor 
behavior.  What's primarily being specified here isn't a protocol for 
performing access control (mediating requests for data objects), but rather 
a management protocol for ACLs (a control interface to adjust the metadata 
that enables those requests to be mediated subsequently).  As such, "WebDAV 
Authorization Management Model and Protocol" might be a more descriptive title.

  WebDAV and this ancillary specification use some novel concepts (new 
HTTP methods, XML multistatus elements encapsulating HTTP exceptions along 
with other data) which integrate with HTTP at a lower sublayer than most 
current web service work.

  There is an unusual interoperability goal being addressed here.  The 
idea is to allow a single client using this protocol to manage ACLs that 
may exist in different servers, where those servers may apply semantics and 
group privileges in different ways.  A lot of the features are driven by UI 
design concerns, which are important to the intended application even 
though often considered to be a local matter, outside the scope of an IETF 
protocol perspective.

  The indirection and nesting of aggregate privileges adds considerable 
complexity.  It is not clear  that the approach is sufficient to enable a 
user to administer ACLs in a comprehensible and security-consistent way on 
servers that apply different groupings.

  Some specific points:

    *  The introduction refers to client software as one of the
       principal types; how are software modules to be authenticated
       in a distributed fashion?

    *  The discussion of inherited ACLs in section 5.6 could benefit
       from some more explicit treatment of denial entries and of
       cases when different ACLs contain ACEs that have matches on
       different subsets of the overall set of privileges.

    *  In section 8.1.1, implementations should give precedence to
       returning a 403 (Forbidden) rather than a 409 (Conflict);
       otherwise, an attacker lacking the authorization to read ACEs
       belonging to other principals could infer their values by
       observing the results to attempts to change those ACEs.

    *  In the Security Considerations, the point that the
       protocol-accessible facility for enumerating principals could
       easily compromise privacy of stored identities en masse, and
       that implementors and deployers should consider carefully
       what's made readable to accessors who have not been
       authenticated as belonging to a constrained set of recognized
       principals.