RE: ACL Draft

>Ok, but most of the Web-based access control mechanisms I've seen allow
the
>principal to be described or qualified by IP address or DNS name
patterns.
>If the intent is not to support that, I'd like to discuss that point in
>more detail.

Perhaps I'm missing something but how this is issue germane to the ACL
protocol? I can see how it would be relevant to the authentication
protocol but that isn't the topic at hand.

>So I'd claim that resolving conflicts between ACEs using specificity as
the
>dominant characteristic will not work unless the model is further
specified
>in such a way that specificity is always well-defined.  But I'd rather
see
>a model that assigns a controllable ordering or precedence to ACEs.
The
>Netscape model makes use of both syntactic ordering and a precedence
flag
>to resolve conflicts.  Granted rights and denied rights are specified
in
>separate ACEs, which is reasonable because conflicts are resolved in a
>uniform way.

Can you please provide an example where, using the conflict resolution
rules specified in the draft, an ambiguous result would occur?
Furthermore, using deny and allow lists is a simpler way to get the same
result as having deny-right and grant-right type rights. As such, your
counter proposal would appear to solve nothing as it does not increase
the expressive power of the system nor does it resolve conflicts.

>Maybe rights should be defined in a named "access rights profile",
which
>could be defined and registered for different types of resources.  We
could
>start with a profile for the generic rights.  Collecting the rights in
>profiles this way would enable the protocol to convey the list of
supported
>rights more efficiently by expressing it as a list of profiles.

I do not understand how this is any different from the current protocol
where rights already represent several different access options. For
example, the write right controls access to a number of methods. You
seem to be suggesting a feature that is already in the protocol.

>And yet again, the existence of generic and specific rights creates
another
>dimension in which conflicts can potentially occur between ACEs.

Again, if you could please provide an example where an ambiguous
situation would occur, I would appreciate it. It would be best if the
example were from a real world system so we can see how in real
implementations such conflicts would arise. This would provide a
compelling case for altering the protocol.

>I heartily endorse your terminology for what I was calling non-lazy and
>lazy inheritance.  However, I'm still concerned about the complications
>that can arise in supporting dynamic inheritance.  A fundamental
>requirement for access control policy is a certain clarity in its
>representation.  Lack of clarity ultimately can lead to lack of
security.
>Dynamic inheritance is a fairly large step away from clarity, in my
view.
>The same can be said of mechanisms for resolving ACE conflicts, when
these
>mechanisms are complex or vague.

Again, you make general assertions without providing any kind of
examples, generic or specific. How can I respond to general assertions
of discomfort without any sort of factual support? I appreciate your
concern about these issues but it is difficult to provide a cogent
response in the absence of facts. You declare that there is a "lack of
clarity" but you do not demonstrate this lack of clarity.

>That seems to imply that ACLs have some kind of "target" information,
which
>indicates whether they apply to properties of a resource, and if so, to
>which properties.  But that need only relate to the storage of ACLs on
the
>server.  In the protocol, it sounds like you intend that ACLs on
properties
>are independently addressable.

The need to record the ACLs of properties on the associated resource is
an artifact of the property based ACL mechanism. This requirement will
disappear in the next version of the draft when an ACL method is
introduced. However the goal is, as you identify, that ACLs on
properties be independently addressable from the ACL on the resource.
That way it is possible, for example, to provide read access to a
resource to everyone but reserve it on a particular property to a select
group.

>[Specifying an ACL as a property] sounds like a real enough concern,
but I don't think I understand it.
>Care to elaborate on how that could create a problem?

Sure, we are killing the ability to create value added extensions to
servers. For example, a company creates a bunch of extensions to some
HTTP server to support DAV properties. The company that created this
property extension will now be forced to also define the ACL extension
since we are using side effects from properties to define ACLs. So if
another company wanted to come along and provide an ACL extension it
couldn't do it because it would have to figure out how to hook into the
property extension the first company created. Now I admit that such a
scenario is wonderful for certain mega corporations (who shall remain
nameless =) who are more than happy to provide a "cradle to grave"
implementation of DAV. However it totally sucks for value added
companies who wish to be able to specialize in certain types of
functionality, say property management or access control, because they
will not be able to easily "drop in" support for their area. However, by
using methods, we make it easy for these companies to sell their
products since they only need to intercept a particular method.
In the specific case of ACLs, we are most likely preventing third party
property systems. The reason being that ACLs are integral to an
implementation and are likely to be provided by the same company that
provided the HTTP server. However by requiring that ACL functionality be
implemented through the property mechanism we de facto reserve the
ability to implement a property mechanism to the same company that
produced the server as only they will be able to properly hook in the
ACL support. Where as using a method base system means that while the
server provider will probably still have to provide ACL support, anyone
should be able to implement properties.
In a word, the reason using defined side effects of properties is bad is
"extensibility."

>Ok.  But can a compound principal describe an open set of principals in
>terms of attributes they may possess, or does it imply the existence of
>something like a user database, in which all of the principals
>corresponding to a compound principal can be enumerated?

The protocol has nothing to say on the topic. As such a principal could
represent ANYTHING, include a verifier program, a scripting language, a
structured data format, a database, anything that the underlying
authentication systems understand. A design principal which I think I
need to make much clearer in the draft is "It is the design assumption
of this ACL protocol that principal identifiers will be submitted to
some verifier in order to determine membership."

>That depends on how flexible you can be in defining compound
principals.
>For example, if a compound principal can be specified as "all Beatles
>except Ringo", you might find that you don't need both "grant" and
"deny".
>The Netscape model does have very flexible compound principal
>specifications, but I still advocated supporting both "allow" and
"deny",
>not because they were necessary to express particular kinds of
policies,
>but because I believe that they can contribute to the *clarity* of
>expressing certain policies.

O.k. I admit it, I'm totally lost. Weren't you arguing before that allow
and deny caused ambiguities and that is why you were against them? Now
you are arguing that you support them? HELP!!!!

>That goes against the grain of tradition in Web Servers, where no
access
>control meant no access control.  However, that originated in the days
when
>HTTP was read-only for the most part.  But it's no big deal either way,
>provided that a "universal principal" is defined, that is a reserved
>compound principal specification that refers to all principals, even
>principals who do not authenticate, e.g "anyone".  That way, it's easy
to
>attach an ACL that changes the default.

Huh??!?!?!?!?!?!? Section 9.1 defines the very principal identifier you
asked for!

>Ok, so rule 1 takes precedence over rule 2?  That's one way to do it:
>instead of ordering the ACEs, order the rules that resolve the
potential
>conflicts.  Been there.  Considered that.  Bleh!

Enough. It is clear to me that you wrote your responses as you read the
draft and did not bother to edit them once you finished. If you would
like to go back and edit your comments, adding facts that support your
views rather than just making assertions, I will be happy to respond.

			Yaron


> -----Original Message-----
> From:	hep@netscape.com [SMTP:hep@netscape.com]
> Sent:	Wednesday, October 22, 1997 4:01 AM
> To:	Yaron Goland
> Cc:	W3c-Dist-Auth (E-mail)
> Subject:	Re: ACL Draft
> 
> Yaron,
> 
> >    The basic model for access control, informally expressed, is that
> >    who you are determines how you can access a resource. The "who
> you
> >    are" is defined by a "principal name"; users, client software,
> and
> >    servers have principal names. The "how" is determined by an
> "access
> >    control list" (ACL) associated with a resource.
> 
> Ok, but most of the Web-based access control mechanisms I've seen
> allow the
> principal to be described or qualified by IP address or DNS name
> patterns.
> If the intent is not to support that, I'd like to discuss that point
> in
> more detail.
> 
> >    An ACL contains Access Control Elements (ACE). An ACE specifies a
> >    set of principals, a set of granted rights, and a set of denied
> >    rights.
> 
> As I mentioned before, I like the ACL/ACE model, but your model of the
> ACE
> seems more complicated than necessary.  I could see where it would
> make
> sense if only one ACE in one ACL would ever apply to a particular
> principal, but since you include the notion of a "compound principal",
> this
> cannot be guaranteed.  Therefore there must be a way to resolve or
> avoid
> conflicting access control policies between ACEs which happen to apply
> to
> the same principal.  One might suppose that this would be done by
> favoring
> the ACE with the most specific principal specification, but that would
> require some assumptions about the nature of compound principal
> specifications, such as a strict hierarchy of principal groups.  Even
> given
> that, what if the ACE with the more specific principal specification
> happens to be dynamically inherited from a collection, rather than
> attached
> to a specific resource?
> 
> So I'd claim that resolving conflicts between ACEs using specificity
> as the
> dominant characteristic will not work unless the model is further
> specified
> in such a way that specificity is always well-defined.  But I'd rather
> see
> a model that assigns a controllable ordering or precedence to ACEs.
> The
> Netscape model makes use of both syntactic ordering and a precedence
> flag
> to resolve conflicts.  Granted rights and denied rights are specified
> in
> separate ACEs, which is reasonable because conflicts are resolved in a
> uniform way.
> 
> >    Rights may be generic, such as "read", "write", or "delete", or
> they
> >    might be specific to the kind of resource protected by that ACL,
> >    such as (perhaps) "send-to", "unsubscribe", and "administer" for
> >    mailing lists.
> 
> Maybe rights should be defined in a named "access rights profile",
> which
> could be defined and registered for different types of resources.  We
> could
> start with a profile for the generic rights.  Collecting the rights in
> profiles this way would enable the protocol to convey the list of
> supported
> rights more efficiently by expressing it as a list of profiles.
> 
> And yet again, the existence of generic and specific rights creates
> another
> dimension in which conflicts can potentially occur between ACEs.
> 
> >    When a resource is created it inherits a set of default ACL
> >    properties from a designated resource, referred to as an ACL
> source.
> >    The inheritance can be "static", so that subsequent changes to
> the
> >    ACL source do not effect the new resources ACL properties; or it
> can
> >    be "dynamic", so that subsequent changes are reflected in the new
> >    resource's ACL properties.
> 
> I heartily endorse your terminology for what I was calling non-lazy
> and
> lazy inheritance.  However, I'm still concerned about the
> complications
> that can arise in supporting dynamic inheritance.  A fundamental
> requirement for access control policy is a certain clarity in its
> representation.  Lack of clarity ultimately can lead to lack of
> security.
> Dynamic inheritance is a fairly large step away from clarity, in my
> view.
> The same can be said of mechanisms for resolving ACE conflicts, when
> these
> mechanisms are complex or vague.
> 
> >    Properties on a resource have, by default, the same ACL as the
> >    resource. However individual properties can be given their own
> ACLs.
> >    The ACL property on the resource also contains information
> regarding
> >    the ACLs of any properties on the resource, if those ACLs are
> >    different from the resource's.
> 
> That seems to imply that ACLs have some kind of "target" information,
> which
> indicates whether they apply to properties of a resource, and if so,
> to
> which properties.  But that need only relate to the storage of ACLs on
> the
> server.  In the protocol, it sounds like you intend that ACLs on
> properties
> are independently addressable.
> 
> >    [Ed Note. This draft deserves the name "rough draft". It is being
> >    released for consideration of the ACL model it proposes. The
> >    intention is to replace the property based model defined herein
> with
> >    an ACL method. The reasoning being that it is a bad design
> decision
> >    to define any mechanism based on "side-effects." In this case, by
> >    setting the ACL property to a certain value the ACL on the
> resource
> >    gets set to the same value. The new ACL method based version
> should
> >    be out in a week or two.]
> 
> That sounds like a real enough concern, but I don't think I understand
> it.
> Care to elaborate on how that could create a problem?
> 
> > 2.   Granting and Denying Rights
> >
> >    An ACL can both grant and deny rights. The reason both types of
> >    grants are required is because of compound principals. A compound
> >    principal is a principal that represents a number of other
> >    principals. For example, a user group in UNIX.
> 
> Ok.  But can a compound principal describe an open set of principals
> in
> terms of attributes they may possess, or does it imply the existence
> of
> something like a user database, in which all of the principals
> corresponding to a compound principal can be enumerated?
> 
> >     The consequence of the existence of compound principals is that
> >    there are times when a compound principal may be granted a right
> but
> >    a particular member of the compound principal may need to be
> denied
> >    access. In order to make this possible an ACL must be able to
> list
> >    principals both allowed and denied a right.
> 
> That depends on how flexible you can be in defining compound
> principals.
> For example, if a compound principal can be specified as "all Beatles
> except Ringo", you might find that you don't need both "grant" and
> "deny".
> The Netscape model does have very flexible compound principal
> specifications, but I still advocated supporting both "allow" and
> "deny",
> not because they were necessary to express particular kinds of
> policies,
> but because I believe that they can contribute to the *clarity* of
> expressing certain policies.
> 
> >    By default all rights for a principal MUST be denied. Rights MAY
> >    only be granted to a principal by an explicit listing of that
> >    principal in a "grant" section of an ACL.
> 
> That goes against the grain of tradition in Web Servers, where no
> access
> control meant no access control.  However, that originated in the days
> when
> HTTP was read-only for the most part.  But it's no big deal either
> way,
> provided that a "universal principal" is defined, that is a reserved
> compound principal specification that refers to all principals, even
> principals who do not authenticate, e.g "anyone".  That way, it's easy
> to
> attach an ACL that changes the default.
> 
> >      The following rules, processed in order, MUST be used to
> resolve
> >    scope conflicts between rights.
> >
> >    1) In a conflict between a right granted by a parent and a right
> >    granted by a child, the right specified by the child MUST
> override.
> >
> >    2) In a conflict between a right granted or denied to a compound
> >    principal and a right granted or denied to a member of the
> compound
> >    principal, the reference to the member of the compound principal
> >    MUST override.
> >
> >    Note that rule 2 is conceptually identical to rule 1. The concept
> >    represented by rules 1 and 2, stated generally, is that a
> specific
> >    references always overrides a more general reference.
> 
> Ok, so rule 1 takes precedence over rule 2?  That's one way to do it:
> instead of ordering the ACEs, order the rules that resolve the
> potential
> conflicts.  Been there.  Considered that.  Bleh!
> 
> > 3.   ACL Inheritance
> >
> >    When a new resource is created it may inherit its ACL from its
> >    containing resource. This inherited ACL MUST be applied to the
> >    resource before it is available for manipulation. Thus the
> resource
> >    will never be in a state where it does not have access control
> >    protection.
> 
> Is "containing resource" a well-defined concept?  What about
> hierarchical
> collections of resources?  Are ACLs inherited from multiple levels?
> 
> >    Inheritance can either be static or dynamic.
> 
> I agree that the model should allow for access control to be applied
> to a
> resource during its creation, but I think it should deal only with
> static
> assignment of initial ACLs, and even then, not get into where the
> initial
> ACLs may have originated.  Basically, when you create a resource, a
> server
> may statically assign some ACLs to it at creation.  As the creator,
> you
> would normally be able to view and change these ACLs after resource
> creation.  On the other hand, dynamic inheritance need not be
> prohibited,
> but a client needs to be able to distinguish between views of ACLs on
> resource as including or not including dynamically inherited ACLs.
> You
> might want to see dynamic ACLs when you're trying to determine the
> rights
> of a particular principal, but the presence of dynamic ACLs could add
> significant complexity to the operation of setting ACLs.  For example,
> if
> the client cannot distinguish dynamic from static ACLs, what happens
> if the
> user unknowingly elects to change a dynamic ACL?  Some kind of dialog
> box
> like:
> 
>     "You don't realize what you're asking
>      and you're probably going to be sorry.
> 
>         Ok      Cancel      God Help Me"
> 
> ?
> Actually not, unless it came from the server, since the assumption was
> that
> the client can't distinguish between dynamic and static ACLs.
> 
> Perhaps I can use your dislike of "side-effects" to dampen your
> enthusiasm
> for dynamic inheritance?
> 
> > 4.   Properties and ACLs
> >
> >    Properties MAY have their own ACL independent of the associated
> >    resource. By default a property's ACL MUST be dynamically
> inherited
> >    from the associated resource.
> 
> Nevertheless, dynamic inheritance seems to make sense here.
> 
> >    For purposes of applying scoping conflict resolution rules the
> >    resource is the parent and the property is the child.
> 
> "containing resource" becomes clearer.
> 
> >    Compliant resources are not required to support setting ACLs
> >    directly on properties.
> 
> That's fine, but I think it would be good if the protocol definition
> included an optional, standard way to do it.
> 
> > 5.   Owner Property
> >
> >    Name:            owner
> >    Namespace:       http://www.ietf.org/standards/acl/
> >    Purpose:         Specifies the owner of the resource.
> >    Values=          Principal
> >    Description:     The owner property specifies the principal who
> owns
> >    the resource. The default value for this property is the
> principal
> >    who created the resource. The owner always retains the right to
> >    alter the ACL. So, for example, an owner who was not granted the
> >    right to read the resource could not read the resource. However
> the
> >    owner could alter the ACL so as to grant the read right to
> himself.
> >    A principal MUST have the writeowner right to change the owner
> >    property's value. All compliant resources MUST support the owner
> >    property.
> 
> The nature of a principal identifier should enable client software to
> answer the question,"Does the current user own (a certain)  resource?"
> Even if principal identifiers are opaque, they need to disallow
> aliases, or
> provide a way to enumerate the aliases of a principal, or provide a
> way to
> resolve an alias to a canonical form, in order for this to work.
> Alternatively, the protocol could provide a way to answer questions
> about
> relationships between principals, by posing those questions to the
> server.
> Questions such as:
> 
>   What is my principal identity?  (Require me to authenticate and
> return a
> principal identifier for my identity.)
> 
>   Do two given principal identifiers refer to the same principal?
> 
>   Is a given simple principal a member of the set of principals
> described
> by a given compound principal?
> 
> Actually I'd like to hear some arguments about why principal
> identifiers
> should be opaque, if you'd be kind enough to indulge me.  I claim that
> "open authentication" can be supported without this, since a principal
> identifier for our purposes need not be the same as a principal
> identifier
> used during authentication.  Authentication can be viewed as
> associating
> the user with a particular "user resource", and that user resource
> could
> contain, for example, an ASN.1 object identifier that could serve as
> the
> principal identifier for the user.  Or perhaps the "user resource"
> would
> actually have a corresponding URL that would serve.
> 
> However, it seems to me that "open authentication" does require a "who
> am
> I?" mechanism, whether principal identifiers are opaque or not...
> 
> ...unless the assumption is that only clients and servers which grok
> the
> same "opaque" format can interoperate with respect to access control
> management.
> 
> Howard
>

Received on Wednesday, 22 October 1997 14:51:12 UTC