Re: LDAP ACLs

["Paul Leach" <paulle@microsoft.com>]

-----BEGIN PGP SIGNED MESSAGE-----


- -----Original Message-----
From: Chris Newman <Chris.Newman@innosoft.com>
To: Paul Leach <paulle@MICROSOFT.com>
Cc: ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>
Date: Wednesday, April 29, 1998 2:37 PM
Subject: Re: LDAP ACLs


>On Wed, 29 Apr 1998, Paul Leach wrote:
>> This is similar to the approach adopted by WebDAV (and possibly
IMAP
>> - -- we had reports from IMAP WG people when WebDAV was considering
>> ACLs, and that's what I thought they said, but I'm not positive I
>> understood it completely. I do recall they said that they were
unable
>> to come up with any universal ACL format.)
>
>The IMAP ACL extension (RFC 2086) is one of the first serious
experiments
>with ACLs in an application protocol in the IETF (of which I'm
aware). 
>The current extension has been implemented by multiple client and
server
>vendors, but includes very few mandatory semantics for ACLs.  The
>implementation experience from clients is that this is inadequate:
the
>ACLs should have much more precisely specified semantics because it's
very
>hard to build an acceptable GUI otherwise.  There will probably be an
>IMAPEXT WG formed to revise this extension and look at other proposed
>extensions which interact with it.
>
>As a result, the ACLs included in ACAP (RFC 2244) have more mandatory
>semantics.

Thanks for the info. Looking at these will be useful. We should
definitely do our best to assure that LDAP ACLs aren't gratuitously
different.

>
>> My proposal was this:  
>> 1. any given server implementation would store and support exactly
one
>> kind of ACL -- the kind that it could enforce, either itself or
with
>> the help of its friendly local OS.
>>  2. However, there might be several different kinds of ACL formats,
>> for different servers. Each format would have an OID associated
with
>> it.
>> 3. There would be a standardazed was for clients to ask a server
for
>> the ACL associated with an object. What that request would return
>> would be an ACL format OID, and then the ACL in that format.
>> 4. There would be a standardized way for clients to ask a server to
>> set the ACL associated with an object. That request would take an
ACL
>> format OID, and then an ACL in that format. If the format wasn't
the
>> one supported by that server, the request would fail.
>
>I wouldn't object to this under the condition that there was one set
of
>ACL semantics (with one label) that was mandatory-to-implement. 
Without a
>single set of mandatory-to-implement semantics, there's no
>interoperability.

That's not quite true. There must be one or more
mandatory-to-implement semantics to have interoperability. In the case
of my proposal, servers have to implemement one-of-many, clients have
to implement all.

>  I know you're familiar with this problem in related
>fields.

Quite. There is a difference, though: in that area (authentication) I
think the semantics of user identity are close enough that many
authentication protocols are essentially equivalent; the problem with
access control is that so many example are demonstrably significantly
different.

>
>While I understand the problems you have with implementing another
ACL
>model when there is already a system-wide model on your OS-of-choice,
the
>IETF has no requirement to accommodate those needs since the ACL
models on
>the various operating systems out there are not IETF standards.

Of course not. But it shouldn't be designed in a vacuum, either (as
you say below).
And for most protocols, difficulty of support on one OS or another
isn't a primary consideration; its usually possible to support both,
even if hard. But I do believe that "security is different" -- I have
argued that support of both will reduce security. 

> In fact,
>some operating system ACL models (e.g., POSIX) are so arcane they
serve as
>a good example of what not to do.  While considering existing ACL
models
>is important, the IETF needs to be free to design an ACL model which
best
>serves the protocol in question.  Eventually, I'd like to see an IETF
ACL
>model across all IETF protocols if possible, but I don't think we
have
>enough experience to do that yet.

In that other area you mentioned, what was the experience that arose
from each application protocol designing an authentication protocol
that "best serves the protocol in question"? Are you suggesting we
repeat that experience?

I would not be opposed to an Experimental RFC for LDAP ACLs to help
provide the experience needed for an IETF ACL model.

However, I think we can already see the train wreck coming. What if
the LDAP ACL model is incompatible with the IMAP and ACAP models?  And
what about HTTP/DAV? Shouldn't that give pause? Shouldn't the fact
that supporting all four if they were different would require four
SRMs with four ACL formats, which is opposed to time-honored "best
practice" in security design of one SRM and the smallest possible TCB,
give pause? And that's the best case, which assumes we can partition
the objects so that only one protocol can be used to access each kind
of object. If many protocols can be used to access the same object and
the ACLs were intrisically incompatible, then such a scheme is
inherently insecure, as opposed to just sub-optinmal design.


If we have to go down this track, then I think intellectual honesty
would require a security considerations section or an applicability
statement that clearly described the difficulties in integrating with
local system security and the risks attendant thereto. It would need
to be sufficient to make it clear to customers why we couldn't support
it in a way that was integrated with the rest of our system.

- ---------------------
Paul J. Leach <paulle@microsoft.com>
PGP Key ID: 0x978829DD
Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8
Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5

iQCVAwUBNUetJcqlCdSXiCndAQG54AP+MLpF2YMiXTFqhFoSEMaDXIizFCGnztxF
BUkfG0IjG2KaTpkW09IIpgH69f3VU1/nEmvKxz6aNMSdlbRa9zgNniG27Pxwsi70
2EJdizJOjfz7PqeYiXjH35owe9M5mkHFMdFlOORcf8UXQCcBgyllGPjlEE0kFWmd
CCtbKOKZraM=
=xucO
-----END PGP SIGNATURE-----