W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

Re: ACL Draft

From: Howard Palmer <hep@netscape.com>
Date: Wed, 22 Oct 1997 13:35:57 -0700
Message-ID: <344E63AD.3E061B1F@netscape.com>
To: Paul Leach <paulle@microsoft.com>
CC: "'Larry Masinter'" <masinter@parc.xerox.com>, Yaron Goland <yarong@microsoft.com>, "W3c-Dist-Auth (E-mail)" <w3c-dist-auth@w3.org>

> The traditional way of dealing with this is instead to say that the
> "who" can contain lots of internesting info, such as where you are
> connecting from. In other words, if it matters (for secuyrity purposes)
> that "who" connecting from home and "who" connecting from work, then
> they are different "who"s -- i.e., they are different principals.

I agree and completely support extensibility in what a principal describes.

> As such, this is all completely orthogonal from the ACL issue: we
> explicitly said that the form of principal names is a matter for the
> authentication mechanism, not for ACLs. If you want to include "where
> from" information in principal names, that's fine, as long as you
> propose an authentication mechanism that can securely verify such
> information.

I don't see it that way.  We could say that the description of access
control policies on the wire should take an opaque form, rather than being
expressed in terms of ACLs and ACEs, but we don't seem to be saying that.
We could *not* make a distinction between simple (unitary?) principals and
compound principals, and that would probably force the resolution of a
conflict between an ACE specified for a compound principal and an ACE
specified for a member principal of that compound principal, e.g.

  Grant (read) <all Beatles except Ringo>
  Deny (read) <Ringo>

to be left as an implementation issue, rather than as a point of debate.

The fact is, we are taking stands and even reaching agreement, on aspects
of the form that access control policies will take in the protocol.  The
principal is just another level of that form.  Yes, it needs to be
extensible, but that alone does not require it to be opaque, and the level
of interoperability stands to be improved if it is not opaque, exactly as
it is improved by not defining access control policy representations as
being opaque.

It's a slippery slope, no doubt.  If we're going to stop in the middle of
the slope, what is the criteria for choosing that point?  Personally, I
think concepts such as "login name", "DNS name", and "IP address", are
fairly easily defined, as evidenced by the fact that other protocols have
defined them.  I don't see a good reason why we would arbitrarily decide
not to define the structure of principal to the point where clients and
servers could communicate (without using extensibility provisions of the
standard) about access control policies at the level of these concepts.

As for the issue of securely verifying IP addresses and DNS names, I'd
argue that "secure" is not black and white.  Why do people put locks on
glass doors?  Because security itself is a cost/benefit trade-off, and
that's where they choose to make the trade-off.  Even for a secure system
in vault buried under a mountain, there is a certain risk/benefit trade-off
in deciding who is authorized to enter the vault.

IP addresses and DNS names are often the only practical mechanism that a
server on the Internet can use to apply different access control policies
to different clients, as the average Web surfer is reluctant to go through
a user registration process, if not for privacy concerns, then because they
simply don't want to have to think up and keep track of another password.
There will be other alternatives in time, of course, but that's mostly
where we're at today.

Received on Wednesday, 22 October 1997 16:37:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC