RE: ACL Draft

> ----------
> From: 	hep@netscape.com[SMTP:hep@netscape.com]
> Sent: 	Thursday, October 23, 1997 4:40 PM
> To: 	Paul Leach
> Cc: 	'Larry Masinter'; Yaron Goland; W3c-Dist-Auth (E-mail)
> Subject: 	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.]
> 
I think you got the direction of my implication backwards, because the
above example doesn't invalidate my statement -- I said that if wasn't
authenticated it isn't secure. I did NOT say that if it was
authenticated then it was secure.

Your example points out that there are additional reasons which it might
not be secure. If you include privacy in the face of eavesdropping in
your security requirements, then you also need to encrypt the channel.
If you want to authenticate each message, not just the connection, then
you need to integrity check every message.

Lets assume that this is being done, or that we have a physically secure
channel. It has no bearing on principal IDs or ACLs -- they only need to
assume that whatever information is included in the principal ID is
authentic (known securely).

> 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.
> 
To completely useless effect. When Bob gets the ACL in your last step,
the "user #8392741..." is completely opaque and worthless, unless one
_also_ provides a way to ask for what it means in some commonly
understood manner, i.e., with reference to what was exchanged as a
principal identifier in the authentication phase. I believe you asked
for such mechanisms in a previous message, but I don't see why one would
want them. I don't doubt that one can add as many levels of indirection
as one wants, but we should have a good reason for it.

> 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.
> 
That's what they all said about X.500, and X.400 e-mail addresses. It
ain't true. And, unlike lots of other UI, a security UI that hides
things can fool the user about the security state, so that they think
something is secure when it isn't. If we keep the underlying machanism
simpler, the UI can be simpler without introducing distortion.

> 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.
> 
And by lack of good cheap authentication, which is why they used bad
cheap authentication (spoofable IP addresses and DNS names).

> > 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.
> 
That's all I was trying to do. I didn't mean to lecture.

>   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.
> 
That's actually not what I wanted. To use the original example, if
"fred" is accessing a server from "xyz.blah.com", and _if_ we care in
our security model where the accesses come from, then I would want the
principal ID to be "fred from xyz.blah.com" (colloquially expressed).
That's completely independent of whether an ACE is allowed to be
complicated, as in "* from *.blah.com has rights a,b,c" or only allowed
to be simple, as in "fred from foo.blah.com has rights a,b,c".

> 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.
> 
"Principal specifier" is a perfectly fine term for an expression that
determines to which principal IDs an ACE applies.

> I guess the user identity part of the principal, when present, is
> "user id"?
> 
If you wish. Like I said, it shouldn't be relevant to the ACL model. (By
which I mean I'm sure that one could complexify the ACL model enough to
make it be relevant, but I'd rather not.) I would prefer the principal
ID to be an opaque, atomic, output of the authentication process, which
is fed into the ACL model without making any requirements on what's in
it, or (e.g.) on the ability to pick it apart and evaluate expressions
on the parts. (Notions of groups might stretch this principle -- we need
to work through groups.)

> > >   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.
> 
I'm sorry, but it wasn't clear to me. "User object" was, and is, a
completely undefined concept in the authorization model of the draft,
and so far in this discussion as well. So far (briefly), we've got
principal IDs, exchanged and validated by an authentication mechanism,
and ACLs, which can be read and written (over secure channels) as
properties on resources. What's a "user object" and how does it relate
to these?

> > 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.
> 
Fine --- I left that out for simplicity.

> > 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.
> 
Will do.

Paul

Received on Thursday, 23 October 1997 20:50:10 UTC