RE: comments on access control requirements

Section 2.0 - Introduction - I would like to see something along the
lines of the following two sentences appear in the requirements
document: "The protocol MUST NOT place any restrictions on the content
of principal identifiers" and "This protocol MUST NOT restrict or
influence choice of authentication mechanism." This gets us out of the
business of worrying about IP based authentication or what have you. BTW
there are certain intranet scenarios where IP based authentication is
totally appropriate. As for your suggested alternative text, I can live
with them as motivating statements for the two requirements list above.

Section 3.0 - Terminology - Damn Damn Damn Damn the definition ended up
somewhere on the editing room floor. Dan Connolly had a really good
definition that we stole but it seems to have fallen out of the spec.
Jim, do we still have it around? In a nutshell a principal is ANY
authenticated entity. The method of authentication is completely
undefined and principal identifiers are treated as opaque tokens by the
protocol. The client and/or server may understand it but the protocol
does not need to. The ACL spec comes in once identification and
authentication have been dealt with.

Section 4.0 - General Principals - What is the compelling reason for
requiring principal identifiers to always be non-opaque? I can see the
reason why sometimes it would be extremely useful to have non-opaque
principal identifiers but I do not see the compelling reason why the ACL
protocol would need to require the use of such non-opaque identifiers in
order to execute all of its duties.

Section 5.1 - Access Control - I don't know if there are alternative
proposals but Paul Leach and I will be submitting this week a protocol
draft which meets the requirements of the requirement draft as it now
stands and is based on ACEs. That is, of course, just one proposal.
However I thought it would be useful to let people see what this stuff
looks like when implemented on top of DAV. BTW the proposal WILL support
having ACLs on properties.

Section 5.2 - Inheritance - I basically agree across the board, except
that I believe the protocol MUST specify inheritance in the case of
creating a new resource. Additionally, given the design of DAV I don't
believe that ACLs can apply to external members, external members are
records not resources. That having been said one could apply ACLs to the
ability to create and remove external members. 

Section 5.4 - ACLs on the ability to set/view ACLs - Oh major ick. I can
live with the language but I would bet money that the final protocol
will support an ACL which controls the ability to set/view ACLs. I think
it is o.k. to let certain issues "hang out" for a while until the group
has had some time to chew over the ideas. This is just the first
official version of the draft.

Section 5.5 - ACE Model - I actually prefer a model more along the lines
of 
principal->grant->right, right, right, right, ...
            |
            ->deny->right, right, right, right, ...

The decision to grant or deny is completely based on authentication of
the principal, how that happens is outside the scope of the ACL
protocol.

Section 5.6 - Discovery - What is the compelling reason for a text
requirement?

			Yaron

> -----Original Message-----
> From:	hep@netscape.com [SMTP:hep@netscape.com]
> Sent:	Monday, October 13, 1997 9:04 PM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: comments on access control requirements
> 
> Yaron,
> 
> > Section 2.0 - Introduction
> > "Native operating system methodsare ineffective because the users
> > responsible for modifyinginformation on the Web site are generally
> not
> > logged ininteractively to the server in a manner that maps their
> > identityto a local user-id."
> > While I am aware of systems, such as FrontPage, which create
> user-ids
> > that only exist for FrontPage and not the underlying system, the
> > majority of web servers I am familiar with map web based
> authentication
> > directly to user IDs. The use of the clear text password challenge
> is
> > often used to map users to their UNIX Ids and the use of NTLM is
> widely
> > used in NT environments to map users to their accounts. I think the
> next
> > sentence, regarding different types of ACL systems is strong enough
> to
> > justify the existence of this draft, the sentence quoted above is
> not,
> > in my opinion, needed.
> 
> What you're saying is often true for intranets, but is often not true
> for
> extranets or ISPs.  How about if we change it to:
> 
> "Native operating system methods are not always applicable because web
> server user identities are not always mapped to native operating
> system
> identities, especially in situations where the web server may be
> accessed by
> users outside of the enterprise which maintains it."
> 
> It might also be reasonable to add:
> 
> "In many cases, web server access control is based on the IP addresses
> or
> DNS names of clients.  Native operating systems do not generally
> support
> this type of access control on a per-resource basis."
> 
> A fundamental question for our access control requirements is whether
> the
> protocol should support this type of access control.  I'd vote yes,
> simply
> because it is widely used.  It could be argued that we should take a
> stand
> for better security and deprecate this practice by not supporting it,
> but
> who is to say that IP addresses and DNS names will not be more secure
> in the
> future?
> 
> 
> > Section 3 - Terminology
> >
> > I think the term principal should be defined in DAV and, at best,
> > repeated verbatim in the ACL draft. I also believe a definition
> should
> > be provided for both policy and ACL. As I have learned talking to
> > different folks about security there are a lot of subtle differences
> in
> > the way people use security terms. For example I use the word ACL in
> a
> > way that most folks use the word ACE. Also, I agree with your
> comments
> > that we will have to require the definition of some sort of
> > extensibility mechanism along with some basic access controls. I
> believe
> > you are dead on when you say that just passing around blobs that
> will
> > get defined at some point in the future buys us nothing.
> 
> Does a "principal" consist of a user identity, as determined by some
> authentication method, or does it also take into account client IP
> address,
> DNS name, and possibly other properties?  Is a principal defined by a
> description in terms of attributes, or is defined as a specific,
> authenticated user identity?
> 
> > This having been said I would like to see the terms Application and
> > Server Based Application both stricken from the terminology section.
> The
> > definitions aren't, in my opinion, useful.
> 
> Going, going...
> 
> > Section 4 - General Principles
> >
> > I agree that this section requires significant work.
> >
> > Also, URLs are generally opaque to clients. Servers spit them out,
> > clients just move them around. I suggest we follow the same rule
> when it
> > comes to identifying principals. The requirement document should not
> > require that principals can generate or even dissect principal
> > identifiers. Rather I suggest we intentionally leave undefined how
> it is
> > a principal comes into possession of a principal identifier.
> >
> > In fact I would suggest we stick to the agreements made at the Orem
> > meeting that the DAV ACL mechanism would ignore issues of how
> principal
> > identifiers are created or what they represent and instead define
> what a
> > principal can do once they have such an identifier and the
> authorization
> > to use it.
> 
> While I understand and agree with a desire to support "open user
> authentication", I don't see that this by itself implies that
> references to
> user identities should not be standardized in the access control
> protocol.
> Once a user has authenticated to a server in some way, the server
> could map
> the authenticated identity to a WebDAV-specified form of user
> reference.
> Access control policy could be conveyed between client and server,
> using
> this standardized form of reference to users.
> 
> The need to reference unique user identities goes beyond access
> control per
> se.  I notice that for purposes of identifying a lock owner, XML is
> used
> (section 5.6.2.5 of the DAV spec).  If a client program wants to
> compare
> user identities for equality, for example, to test if the current user
> is
> the lock owner, how is that done?  It seems that the XML user
> reference must
> contain some component that uniquely identifies a user with respect to
> the
> server, and the client must understand enough about the particular XML
> schema being used to compare the appropriate parts of the XML text in
> an
> appropriate way.
> 
> No doubt this is a hard problem, and one for which I don't claim to
> have all
> the answers, but just specifying an XML representation, while
> wonderful for
> extensibility, does not seem to advance the cause of interoperability
> much.
> 
> > Section 5.1 - Setting of Access
> >
> > Not to be picky but can we please use the word "control" instead of
> > "constraints"? I believe the later to be common usage. We also need
> a
> > very detailed definition of what an access control is. Otherwise, we
> > don't know what it is we are requiring.
> 
> I prefer "access control" myself, but the more important thing is to
> define
> what it is, as you suggest.  I understand/like models with ACLs made
> up of
> ACEs, with each ACE allowing or denying specified access rights under
> certain specified conditions, which usually have to do with attributes
> of
> the client user, potentially including references to authenticated
> user
> identities.  Are there any alternative proposals?
> 
> > Section 5.2 - Inheritance
> >
> > I am not clear as to what problem is introduced into the protocol by
> > lazy inheritance. Inheritance is a mechanism to specify ACL
> information
> > for resources within a certain scope. If a resource is available in
> the
> > scope, regardless of how it got there, then it is expected to have
> the
> > specified ACL information. So, examining the situation strictly from
> the
> > view "on the wire" there is no discernable difference between lazy
> and
> > normal inheritance. As such we should be able to specify them the
> same
> > way.
> 
> Lazy inheritance need not affect the protocol design if we so choose.
> However, I think that means that when viewing the access control on a
> resource, you would not see or be able to set any lazily inherited
> controls
> from a WebDAV client, although you would still be subject to these
> controls
> when attempting to access the resource.  That would tend to relegate
> the
> administration of lazily inherited controls to server administrators,
> or
> encourage proprietary extensions to WebDAV to enable end-user
> administration.  I have no problem with that.
> 
> If the access control protocol does convey lazily inherited access
> control
> information between client and server, then it must, at a minimum,
> provide a
> mechanism to distinguish between access controls which are directly
> bound to
> a resource and those which are lazily inherited.  It may also be
> necessary
> to distinguish between types of access control placed on a collection,
> as
> applying to the collection itself, or applying (via lazy inheritance)
> to
> resources in the collection.  With internal and external members of
> collections, there is a potential for even finer distinctions.
> 
> > Either way I do not believe we can escape inheritance. Just about
> every
> > ACL system I am aware of, from UNIX to the high end document
> management
> > servers support inheritance as a way for someone to allow controlled
> > access to creation capabilities within their namespace.
> 
> I don't disagree, but the inheritance model needs to be elucidated,
> even if
> it's just to say that inheritance is server-specific and outside the
> scope
> of this protocol design.  Even with that statement, I'd add:
> 
> "
>  1) The WebDAV access protocol conveys only access controls which are
> directly bound to, and applicable to accesses to, a given resource.
> There
> may be access controls bound to a resource which do not affect
> accesses to
> the resource, and there may be access controls which are not directly
> bound
> to the resource, which nevertheless may affect accesses to the
> resource.
> 
> Rationale: Allows servers to implement lazy inheritance of access
> controls,
> if desired.
> 
> 2) Access controls may be implicitly bound to a resource as a
> side-effect of
> resource creation, through mechanisms outside the scope of this
> specification.
> 
> Rationale: Allows servers to implement non-lazy (got a better word?)
> inheritance of access controls, if desired.
> "
> 
> One could replace "inheritance" with "assignment" in the above, and it
> would
> be less biased toward the mechanism of inheritance, per se.
> 
> > Section 5.3 - Reporting to Server-Based Applications
> >
> > I believe this section is inappropriate to a protocol requirements
> > document and should be removed. We are dealing strictly with the
> > protocol definition and the expected behaviors from the commands
> passed
> > through that protocol. How those behaviors get enforced on the
> server is
> > out of scope for both the requirements and the protocol.
> 
> Going, going...
> 
> > Section 5.4 - Access Control [Judy: for Access Constraints]
> >
> > Ahh the snake biting its own tail. I would recommend that the
> > requirements only state that there be a way to control who has the
> right
> > to change access controls. The actual form of that mechanism should
> be
> > left to the protocol group.
> 
> Well, that's fine with me, but won't the protocol group's first
> question
> about this be:  what is the requirement?  If access controls are
> allowed on
> viewing/setting access controls, there must be some way to end the
> potential
> recursion, and if attachment of access controls by reference is
> allowed,
> then cycles should be prohibited.  I'd say that server implementors
> ought to
> be able limit how many levels of this they'll support, including not
> supporting it at all.  What access control applies to the most meta of
> the
> access controls should also be left to the implementor.
> 
> So I'd propose a requirement:
> 
> "The protocol must provide an optional mechanism for setting access
> controls
> on the viewing and setting of access controls, but need not (and
> probably
> should not) support cyclic bindings.  The protocol should provide a
> mechanism for a server to reject such an operation as unsupported, and
> ideally provide a way for the client to determine, without
> side-effects,
> whether the server supports this operation, and if so, how many levels
> are
> supported."
> 
> Or, if the group prefers:
> 
> "There is no requirement for the protocol to enable access controls to
> be
> set on the viewing and setting of other access controls.  The
> mechanisms for
> administering the controls on the viewing and setting of access
> controls are
> outside the scope of the protocol."
> 
> > Section 5.5 - Standard Access Attributes
> >
> > While I think it is appropriate for the requirements document to
> mandate
> > that some set of rights MUST be supported by all servers I
> additional
> > believe that we need to make it clear that it is up to the protocol
> to
> > decide how to group these rights. For example we may create a "list"
> > right which provides both the rights Judy lists in section 5.5.2
> rather
> > then two separate rights. The final decision should remain with the
> > protocol designers.
> 
> The list of standard access attributes seems to me to be a
> requirements
> issue, although I can imagine valid reasons for postponing the
> decision.
> Could you elaborate on why you think it should be deferred?
> 
> By the way, is there a good reason to call these "access attributes"
> instead
> of "access rights"?  I notice that you seem to prefer "rights", as do
> I.  I
> guess if your model of ACEs is:
> 
> if <attribute-expression> then <allow/deny>
> 
> where rights may be part of the <attribute-expression>, e.g.:
> 
> if (access-type=read AND dns="*.foo.com") OR (access-type=modify) then
> deny
> 
> then these rights might behave just like other attributes which might
> be
> used in the <attribute-expression>.  But then I would use "access
> attributes" to refer to all of the kinds of attributes that may appear
> in
> the <attribute-expression>, and refer to the rights as "rights", or
> maybe
> "access types".
> 
> Personally, I prefer a model of ACEs that is more like:
> 
> if <attribute-expression> then <allow/deny> <rights>
> 
> which makes it a little easier to sort out the ACEs that apply to a
> particular access type and to understand their effect..
> 
> > Section 5.6 - Discovery
> >
> > "Plain"? I think that term is inappropriate. I believe the
> requirements
> > document should restrict itself to specify that discovery must be
> > possible through a mechanism that is capable of producing machine
> > processable output. Human readable descriptions, in my experience,
> > actually hinder rather than help interoperability.
> 
> I agree.  The rationale:
> 
> 
> > 5.6.1 Rationale
> >
> > It will be necessary for WebDAV tools to understand what the WebDAV
> > server understands insofar as access control, as well as a
> description
> > in human-readable terms of how the server will treat changes to a
> > particular access control [Judy: constraint].
> >
> 
> seems to imply that software interpretation, as well as
> human-readability
> are required.  Perhaps the text of 5.6.1 belongs in 5.6, and a new
> 5.6.1 is
> needed, one which would justify the need for each of these.  Perhaps
> the
> requirement for human-readability should actually be a requirement for
> a
> textual representation, suggesting the use of XML, without making a
> value
> judgment about its readability.
> 
> Thanks for the feedback.
> 
> Howard
>

Received on Tuesday, 14 October 1997 03:07:04 UTC