Re: ACL Draft

Paul,

> > I'm trying to make a distinction between the credentials exchanged during
> > an
> > authentication process, and how the specification of a principal within an
> > ACE on the wire references a user identity.  I don't believe these need to
> > be the same, or even the same form.
> >
> Yes they do. Any information that isn't exhchanged in an authentication
> process isn't authenticated, and isn't secure.

If that's true, there are bigger problems.  Consider the following exchange
between a server (Server), client (Bob), and a hostile third party (Mallet):

[Bob initiates a connection to Server, but by pretending to be a router, Mallet
intercepts the connection, and thus is able to monitor and potentially modify
packets exchanged between the Server and Bob.]

Bob (unknowingly) to Mallet to Server: Hello

Server to Mallet to Bob: Who's that?

Bob to Mallet to Server: I'm Bob

Server to Mallet to Bob: Prove it, for example, by answering this challenge:
CIDJFU89hHKhkIGH0qioP

Bob to Mallet to Server: BUIHOL33yerV0AXrm

Server to Mallet to Bob: Hello, Bob, I can speak DAV if you like

[At this point, authentication has been completed "securely".  Mallet has
learned no secrets which would allow him to subsequently connect to the Server
and authenticate as Bob, unless the Server were stupid or unlucky enough to
issue the same challenge.

However, the connection between the Server and Bob is obviously NOT secure.]

Bob to Mallet: Set the following ACL on the /users/bob/private resource:
ACL {
  Deny (all) user=anyone AND dns=*.mallet.com;
  Allow (all) user=bob;
}

Mallet to Server: Set the following ACL on the /users/bob/private resource:
ACL {
  Allow (all) user=anyone AND dns=*.mallet.com;
  Allow (all) user=bob;
}

Server to Mallet to Bob: Done

Bob to Mallet to Server: Just checking, what was that ACL I set on
/users/bob/private?

Server to Mallet: It was:
ACL {
  Allow (all) user=anyone AND dns=*.mallet.com;
  Allow (all) user=bob;
}

Mallet to Bob: It was:
ACL {
  Deny (all) user=anyone AND dns=*.mallet.com;
  Allow (all) user=bob;
}

Bob to Mallet to Server: Thanks, I'm done

Server to Mallet to Bob: Have a nice day, Bob

The moral of the story (and something that should be stressed in our Security
Considerations section) is: viewing and setting ACLs over unsecure connections
can expose both the ACLs and the resources they protect to unauthorized viewing
or modification.

I've been operating under the assumption that everyone understood that.  So I
assume that if someone using the DAV access control protocol is concerned about
security, they are communicating over a connection which is either
cryptographically or physically secured.  So Bob and the Server can have a
conversation that goes:

Bob to Server: Let's set up a secure connection based on a shared secret or
mutual trust of a third party.

Server to Bob: Yes, let's

[Secure connection established.  Mutual authentication.]

Bob to Server: Who am I?

Server to Bob: I know you fondly as user #8392741 in domain #1125

Bob to Server: Who owns /users/bob/private?

Server to Bob: user #8392741 in domain #1125

Bob to Server: Set the following ACL on the /users/bob/private resource:
ACL {
  Deny (all) user=anyone AND dns=*.mallet.com;
  Allow (all) user="user #8392741 in domain #1125";
}

Server to Bob: Done

[etc]

That is, to return to my original point, the server CAN use a different form of
user identifier in DAV than in whatever authentication mechanism is used.  And
this most certainly is secure, because (if you care at all about security) the
entire connection is secure.

> I completely disagree. Users without degrees in computer science have to use
> ACLs. They don't understand boolean predicates. We get zillions of
> complaints that what we have is already too complicated. The only way I
> convince myself to swallow all this dynamic inheritence stuff is because I
> believe it means users have to understand less (more stuff is inherited and
> managed for them) -- and some days I'm not even sure about that.

I'm very sympathetic with your concern about the complexity, having personally
been involved in some of the early UI design for this stuff.  But, as Larry
pointed out, it can be dealt with in the UI.  The UI designer, by simply not
reflecting some of the underlying functionality in the UI, can make it as simple
as desired.  Or perhaps a good UI designer can make the full functionality
available in a way that is comprehensible to the end user.

Users do seem to want this kind of flexibility.  Don't take my word for it.
Look at what htaccess access control can do (ignoring its rather ad hoc
syntax).  My impression is that the functionality that you will find there was
driven by grassroots demand.

> Why can't you accept the traditional definition that the principal
> identifier is everything about request to access an object that determines
> what rights the request has to that object?   I.e., the security reference
> monitor contains a function
>         bool CheckAccess(principal-ID, method, object)
> that returns "true" if access is allowed, and "false" otherwise. The
> "principal-ID" is whatever combination of information that we decide is
> needed to make that decision -- it doesn't have to be just the user ID.
> (Whatever you do use, however, needs to be authenticated...)
>
> We gain nothing by inventing new terminology when there is already well
> established terminology.

I'll be glad to use whatever terminology you want.  I was just making a
suggestion.  We have much more interesting things to debate here.  When I throw
out a concept and use the wrong word for it, don't lecture me, just tell me what
you want to call it.  You can assign numbers to the concepts if it pleases you,
for all I care.  I can handle it.

My understanding is that you want to call the "principal" what I was suggesting
was the "ACE conditions".  I will endeavor to use "principal" in only that way.
Sometimes I may need to distinguish between the "principal specifier" which the
actual conditional in the ACE, and the "principal identifier", which is (in the
most general case) the state of universe, as perceived by the server, at the
time that the principal specifier is evaluated for a given request.

I guess the user identity part of the principal, when present, is "user id"?

> >   Conceptually, any authentication mechanism maps
> > authentication credentials to a user (or perhaps group) object, and once
> > that is done, the corresponding principal identifier can be retrieved from
> > the object, or constructed by using information in the object.  (In the
> > case
> > of certificate-based authentication, the client certificate might actually
> > be the user object.)
> >
> You could equally well say that an authentication mechanism maps
> authentication credentials to a set of principal identifiers -- the
> intermediate step just limits the possible implementations of the
> authentication mechanism.

I said "conceptually".  To me, that means "how you think about it", which is not
necessarily how you implement it.  As I pointed out (quite clearly I thought)
for the case of certificate-based authentication, the authentication credentials
can be the user object, so my conceptual model actually subsumes the one you
propose, and thus expands the set of possible implementations.

> CheckAccess(pid, method, object) {
>         acl = GetACL(object);           // get the acl for this object
>         rts = GetRights(method);        // get rights needed to allow this
> method
>         ace = FindACE(pid, acl);                // find the ACE that applies
> to this pid
>         return ((rts & ace.rights) == rts);             // return true if
> rights needed included in ace's rights
> };
>
> In these terms, as I understand it, you want FindACE to include a boolean
> predicate over the principal ID (or components of it), and that you want
> lots of stuff in the principal ID other than just the user ID. However, this
> doesn't require a change of the definition of what "principal ID" means.

You got it, basically.  However, if multiple rights are needed for a
method/object, they may be granted by several matching ACEs.

> I think I understand you now -- am I making myself clearer?

This is very difficult because we seem to have come from different planets or
something, but I think we're gradually finding common ground.  I guess we both
need to explain things in more detail and give more examples.

Howard

Received on Thursday, 23 October 1997 19:44:34 UTC