Subject: Access Control deferred?

From: Bob Mahoney <[email-masked]>
Date: Tue, 08 Dec 1998 12:17:10 -0500

Yesterday during the meeting I asked about the conflict between the
deferred items in section 4.9 and the apparent inclusion of security
measures in the slides shown.  Can one of the document authors clarify this?

I am concerned that we are designing an access protocol without access
control.  That would be unacceptable.  Clients need to provide a mechanism
for users to allow or disallow access to their personal calendars, and
relying on an administrator to take this action clearly does not scale.
(We consider our organization's calendar users to number ~16,000)

The slides seemed to conflict with the draft.  If I'm merely confused, can
someone clarify?

>4.9     Access Control (deferred)
>
>The ability to get and set access control data on calendars and
>calendar components is useful, but beyond the scope of the initial
>CAP specification. A CS may apply access control entries to calendars
>and components, but CAP need not specify how these are to be set and
>retrieved. Access control entries could be set and retrieved by
>administrators on the CS through another protocol. Additionally, a CS
>can enforce the class of each component, by restricting access to
>"confidential" and "private" components, without any design in CAP to

-Bob
>allow this.

---

From: "Mark Poepping" <[email-masked]>
Date: Wed, 16 Dec 1998 21:57:07 -0500

I confess only recent tracking of this activity, but comments
about the ACL issue prompt me to wonder what exactly we expect
to accomplish by standardizing CAP without ACL support..

Who among the vendors has plans to ship an administrative client
(separate from your cal product) to handle ACL's (presumably to
a non-native server)?

It seems to me that cal, more so than http or even imap, *must*
specify a way to manage access to objects from the start.  The
information in calendar objects is expected to be shared in more
ways than either http or imap are generally used today (the
"groupware" thing).

http is not a protocol for "updating" web pages, so it's hardly a
surprise that there's no support for controlling access to pages
that it can't edit.

As for imap, it *does* have support for ACL management, but most
of the clients don't implement it since mail stores are generally
thought of as personal stores (though we at CMU would certainly
argue that).

CAP *must* include update (or why bother), and unless you consider
this project as limited to shared storage of 'personal' calendar
information, I believe it's fundamental that you control access
to the objects you create (it's core functionality to all 'group'
calendar products I've ever seen).

So I think we should define a minimal, but sufficient standard
for CAP, and I believe that ACL's are necessary to sufficiency.

mark.

--

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Lisa Lippert (Dusseault) (Exchange)
> Sent: Tuesday, December 15, 1998 6:54 PM
> To: 'Bob Mahoney'; [email-masked]
> Subject: RE: Access Control deferred?
>
>
> HTTP is an example of a protocol that allows access to items (web pages)
> without defining how access control is done.  It only provides an
> error code
> to be used if access is denied.  Access control is done
> out-of-band.  Since
> HTTP is clearly not "unacceptable", we had the idea that maybe we could
> delay defining how to do access control for the first version of CAP.
>
> If we leave access control out of CAP, that does not stop implementations
> from doing access control, e.g. through an administrative
> interface, and it
> does not stop implementations from respecting access control
> settings.  The
> proposal is that CAP would just avoid saying how to set access
> control in an
> interoperable fashion.
>
> I'm glad to see so many comments on the list lately about our requirements
> -- is any other input on access control??
>
> Lisa

---

From: "Paul B. Hill" <[email-masked]>
Date: Mon, 21 Dec 1998 16:20:51 -0500

Hi,

On Tuesday, December 15th, Frank Dawson, Bob Mahoney, and I met in
Cambridge. We talked quite a bit about CAP and access control issues. From
that conversation and other feedback that I have received it is apparent
that the editors of the CAP draft would like to be able to address access
control but its sounds like they went down some dead ends, or wound up with
implementation concerns before they had developed a consensus on the access
control requirements.
 
Frank mentioned that he had shown Charlie Kaufman some of the ACL work and
Charlie had observed that there was lots of detail but he didnt find any
description of the requirements. Charlie is one of the authors of "Network
Security, PRIVATE Communication in a PUBLIC World" and an active
contributor to several of the IETF security working groups.

I started writing this message before Doug Royer's posting to the list.
Unfortunately a quick glance at Doug's posting convinced me that once
again, requirements were skipped in preference to defining the specification.

What disturbs me is that fact that every time I talk about access control
with someone the conversation quickly turns to talking about things like
the "difficulty in showing this attribute to that user, while hiding a
different attribute from a third user." Were not there yet. During a
breakout session at the LA meeting a small group concluded that CAP would
_not_ address administrative requirements. However, I dont think anyone
ever tried to enumerate what operations were considered to be
administrative vs. functional requirements for an end user.  Im pretty
sure that everyone at that breakout session would agree that migrating a
user from one server to another would be an administrative task that would
not be addressed by CAP.  But I am not sure that everyone at that breakout
session would agree that creating a delegate would be addressed by CAP or
not. 

Many working groups in the IETF have recently been addressing access
control issues. These include WedDAV (Distributed Authoring and
Versioning), LDAP, CAT (Common Authentication) and PIPM (Instant
Messaging). During the Orlando meeting WebDAV had a breakout session to
talk about access control, and after the instant messaging meeting a bunch
of security geeks talked to members of that group for about two hours to
try and determine what their security requirements were.

The access control problem faced by the WebDAV group is daunting. The
resources, often html documents, being manipulated by WebDAV tools are
often accessible via other protocols. For example, an html file placed onto
a file system using a WebDAV tool may also be accessible via FTP, HTTP,
SMB, NFS, AFS, or rcp.

It is important to the WebDAV contributors present at the breakout session
that access control operations performed via WebDAV be reflected in the
subsequent access to the resources via these other protocols. From this
goal it follows that the access control must map directly to the access
control of the underlying data store. In the case of a traditional static
html document, the data store is the file system. The access control to the
file system is the access control imposed by the underlying operating system. 

In the case of an html page that is generated dynamically as the result of
a query to an SQL database. The underlying data store is the database and
the access control is that which is imposed by the database server.

I believe that the Calsched groups problem is significantly simpler than
the WebDAV problem. The data in the CS is not expected to be accessible via
a wide variety of other servers accessible via other protocols, nor via
direct file access.

At the other extreme I see the "Access Control Framework for Distributed
Applications" from the CAT, Common Authentication Technologies, working
group. In the current draft, draft-ietf-cat-acc-cntrl-frmw-01.txt, the
abstract states:

This document describes a unified model to support authorization in a
wide range of applications, including metacomputing, remote printing,
video conference, and any other application which will require
interactions between entities across autonomous security domains.
 
The document proposes requirements for the support of:

   - flexible and expressive mechanism for representing
     and evaluating security policies 
 
   - uniform authorization service interface for facilitating access 
     control decisions for applications and requesting access control 
     information about a particular resource.

It appears that this draft wont meet our needs since it does not attempt
to deal with access control modification, which I feel is essential for
CAP. E.g. I think it is a requirement that end users be able to control who
is their designate.

However, this abstract does raise a point that the Calsched working group
does need to consider. Does CAP require access  control operations to occur
across autonomous security domains?

Would Steve Mansour at Netscape/AOL ever need to grant Frank Dawson of
Lotus/IBM delegate rights to his calendar, _without_ creating a guest
account for Frank within the Netscape/AOL security domain? Although I can
think of situations where this would be desirable, I do not find this to be
a requirement for purchasing an enterprise wide C&S system for my site.

What about fine granularity of read access across multiple security
domains? E.g.  Is it a requirement that I can enable users from On
Technologies and Crosswind to read my meeting descriptions but I can
prevent people from AOL and IBM from doing so? Again, I dont find this to
be a current requirement at my site.

However, in the case of invited attendees across security boundaries I do
see several requirements that need to be addressed. If I invite someone
from IBM to a meeting at MIT they must be able to view the meeting
description and agenda, and they must be able to accept or decline. 

The CAT working group also has draft-ietf-cat-xgssapi-acc-cntrl-03.txt,
"Extended Generic Security Service APIs: XGSS-APIs Access control and
delegation extensions" which states:

The primitives of the GSS-API do not currently allow support of 
   security attributes other than a single identity and do not allow 
   fine control of delegation. 
    
   The additional primitives described in this document provide support 
   for: 
    
   * the exchange of a variety of security attributes, and the 
   construction of authorization functions using these attributes, 
   including delegated ones, (attribute handling support functions), 
 
    * fine control over delegation by allowing specification of the 
   delegation method, the acceptor(s) of a security context, their type 
   and the restrictions that may apply (acceptor control and support 
   functions).

Unlike the ACF draft this draft at least tries to tackle changing access
control attributes instead of just querying them.

If we take a look at Access Control Requirements for LDAP,
draft-ietf-ldapext-acl-reqts-01.txt, from the LDAP working group we may
find something that is much closer to our current needs since we are still
talking about CAP requirements rather than the definition of the CAP
protocol. This draft breaks down the requirements into a few  broad
categories, General, Semantics / Policy, and Usability (Manageability).

 Below, I have taken large sections of the text from
draft-ietf-ldapext-acl-reqts-01.txt, and started to modify them to talk
about CAP, rather than LDAP. Does this make sense as a starting point for
discussion within the group?

3.1	General

G1.  Model SHOULD be general enough to support extensibility to add
desirable features in the future.

G2.  When in doubt, safer is better, especially when establishing defaults.

G3.  ACL administration SHOULD be part of the CAP protocol.  Access control
information MUST be an iCalendar attribute.

G4.  Object reuse protection SHOULD be provided and MUST NOT inhibit
implementation of object reuse. The CS SHOULD support policy controlling
the re-creation of deleted CNs, particularly in cases where they are
re-created for the purpose of assigning them to a subject other than the
owner of the deleted CN.

3.2	Semantics / Policy

S1.  More specific policies must override less specific ones (e.g.
individual user entry in ACL SHOULD take precedence over group entry) for
the evaluation of an ACL.

S2.  Multiple policies of equal specificity SHOULD be combined in some
easily-understood way (e.g. union or intersection).  This is best
understood by example.  Suppose user A belongs to 3 groups and those 3
groups are listed on the ACL. Also suppose that the permissions for each of
those groups are not identical. Each group is of equal specificity (e.g.
each group is listed on the ACL) and the policy for granting user A access
(given the example) SHOULD be combined in some easily understood way, such
as by intersection or union.  For example, an intersection policy here may
yield a more limited access for user A than a union policy.

S3.  Newly created calendars and CNs entries SHOULD be subject to a secure
default policy.

S4.  Access policy SHOULD NOT be expressed in terms of attributes which the
directory administrator or his organization cannot administer (e.g. groups
whose membership is administered by another organization).

S5.  Access policy SHOULD NOT be expressed in terms of attributes which are
easily forged (e.g. IP addresses).  There may be valid reasons for enabling
access based on attributes that are easily forged and the
behavior/implications of doing that should be documented.

S6.  Humans (including administrators) SHOULD NOT be required to manage
access policy on the basis of attributes which are not "human-readable"
(e.g. IP addresses).

S7.  It MUST be possible to deny a subject the right to invoke a calendar
operation.  The system SHOULD NOT require a specific implementation of
denial (e.g.  explicit denial, implicit denial).

S8.  The system MUST be able (semantically) to support either default-grant
or default-deny semantics (not simultaneously).

S9.  The system MUST be able to support either union semantics or
intersection semantics for aggregate subjects (not simultaneously).

S10.  Absence of policy SHOULD be interpretable as grant or deny. Deny
takes precedence over grant among entries of equal specificity.

S11.  ACL policy resolution MUST NOT depend on the order of entries in the
ACL.

S12.  Rights management MUST have no side effects. Granting a subject one
right to an object MUST NOT implicitly grant the same or any other subject
a different right to the same object.  Granting a privilege attribute to
one subject MUST NOT implicitly grant the same privilege attribute to any
other subject.  Granting a privilege attribute to one subject MUST NOT
implicitly grant a different privilege attribute to the same or any other
subject.  Definition: An ACLs "scope" is defined as the set of directory
objects governed by the policy it defines; this set of objects is a
sub-tree of the directory.  Changing the policy asserted by an ACL (by
changing one or more of its entries) MUST NOT implicitly change the policy
governed by an ACL in a different scope.

S13.  It SHOULD be possible to apply a single policy to multiple calendar
entries. Applying a single policy to multiple CN entries SHOULD NOT require
creation and storage of multiple copies of the policy data.  The system
SHOULD NOT require a specific implementation (e.g. nested groups, named
ACLs) of support for policy sharing.

3.3	Usability (Manageability)

U1.  When in doubt, simpler is better, both at the interface and in the
implementation.

U2.  Subjects MUST be drawn from the "natural" iCalendar namespace; they
should be CNs.

U3.  It SHOULD NOT be possible via ACL administration to lock all users,
including all administrators, out of the directory.

U4.  Administrators SHOULD NOT be required to evaluate arbitrary Boolean
predicates in order to create or understand policy.

U5.  Administrators SHOULD be able to administer access to components and
their attributes based on their sensitivity, without having to understand
the semantics of individual schema elements and their attributes (see U9).

U6.  Management of access to resources in an entirecalendar SHOULD require
only one ACL (at the subtree root).  Note that this makes access control
based explicitly on attribute types very hard, unless you constrain the
types of entries in calendars.  For example, another attribute is added to
an entry. That attribute may fall outside the grouping covered by the ACL
and hence require additional administration where the desired affect is
indeed a different ACL.  Access control information specified in one
administrative area MUST NOT have jurisdiction in another area.  You SHOULD
NOT be able to control access to the aliased entry in the alias.  You
SHOULD be able to control access to the alias name.

U7.  Override of calendar policy MUST be supported on a per-component-entry
basis.

U8.  Control of access to individual directory entry attributes (not just
the whole calendar entry) MUST be supported.

U9.  Administrator MUST be able to coarsen access policy granularity by
grouping attributes with similar access sensitivities.

U10.  Control of access on a per-user granularity MUST be supported.

U11.  Administrator MUST be able to aggregate users (for example, by
assigning them to groups or roles) to simplify administration.

U12.  It MUST be possible to review "effective access" of any user, group,
or role to any entrys attributes. This aids the administrator in setting
the correct policy.

U13.  A single administrator SHOULD be able to define policy for the entire
set of calendars.  An administrator MUST be able to delegate policy
administration for specific calendars to other users.  This allows for the
partitioning of the entire tree for policy administration, but still allows
a single policy to be defined for the entire tree independent of
partitioning.  (Partition in this context means scope of administration).
An administrator MUST be able to create new partitions at any point in the
tree, and MUST be able to merge a superior and subordinate partition.  An
administrator MUST be able to configure whether delegated access control
information from superior partitions is to be accepted or not.

U14.  It MUST be possible to authorize users to traverse calendar structure
even if they are not authorized to examine or modify some traversed
entries; it MUST also be possible to prohibit this.  The tree structure
MUST be able to be protected from view if so desired by the administrator.

U15.  It MUST be possible to create publicly readable entries, which may be
read even by unauthenticated clients.

U16.  The model for combining multiple access control list entries
referring to a single individual MUST be easy to understand.

U17.  Administrator MUST be able to determine where inherited policy
information comes from, that is, where ACLs are located and which ACLs were
applied. Where inheritance of ACLs is applied, it must be able to be shown
how/where that new ACL is derived from.

U18.  It SHOULD be possible for the administrator to configure the access
control system to permit users to grant additional access control rights
for entries which they create.

Paul

---

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Mon, 28 Dec 1998 10:57:30 -0800

The DAV group is taking on access control for distributed authoring and
versioning.  I'm closely involved in that effort.  The documents that have
been published so far (requirements, and one proposal) show a very general
framework that could be used by other protocols/applications. 

The IMAP group already did some access control design work.

LDAP is discussing access control, and there have been several proposals
published in that area.

Pat, you asked about how a generic access control framework could be used by
a special-purpose application such as calendaring.  The client s/w would
have to abstract the basic concepts such as the right to "read" an item, the
right to "read" a property of an item, or the right to "read" a
directory/container/folder (i.e. list the contents of a container).  Other
basic rights might include write, execute, read ACL, write ACL, delete,
createchild.  These basic concepts then would NOT be presented to the user
in their most basic form.  Instead, the client would present them in a much
more user-friendly fashion.  Using a whizbang calendaring application, the
human in the process would choose options like "Let Joe see my free-busy
time".  This whizbang application would then set the correct access control
levels on all items in the calendar, or in the calendar itself.  Depending
on how we build on top of the basic access control concepts, this might
involve setting property "read" rights for the "dtstart" and "dtend"
properties of things which are "vevents".  Or it might involve setting the
"read" right for an item which is the "vfreebusy" data.  

This is definitely more complicated for clients to implement.  The
advantages are greater flexibility and better security.

Lisa

-----Original Message-----
From: Pat Egen [mailto:[email-masked]]
Sent: Sunday, December 20, 1998 10:47 AM
To: Lisa Lippert (Dusseault) (Exchange)
Cc: 'Bob Mahoney'; [email-masked]
Subject: Re: Access Control deferred?

Lisa, which working groups are working on Access control and are any of the
participants on this mailing list working on those groups? If not, maybe
someone
should be to ensure that the ACL's have some of the granularity required for
calendar access.  It's going to be different than whether or not someone has
the
rights to see my mail, etc.  Calendaring could be needing to know is someone
a
part of a team, do they only see "busy times", do they see nothing at all,
can I
secure certain pieces of my calendar so that only members of my team can see
the
data, etc.  How can this be done by a generic ACL definition? Maybe I'm
missing
something here, but it seems like the CAP requirements need to set some sort
of
guidelines at least.

Lisa Lippert (Dusseault) (Exchange) wrote:

> You have great points and I agree with all of them.  My major concerns
about
> access control are:
>  - it's a very tough area to do properly (taking into account all the
> dependencies)
>  - this work is being taken on elsewhere in Apps, and the CalSched group
> might be able to take advantage of existing general solutions if CAP ACLs
> can be put off for a while
>  - Most of all, I'm very concerned about the schedule for CAP.  The plan
is
> very ambitious.
> From: Bob Mahoney [mailto:[email-masked]]
> Sent: Saturday, December 19, 1998 5:09 AM
> To: Lisa Lippert (Dusseault) (Exchange)
> Cc: [email-masked]
> >from doing access control, e.g. through an administrative interface, and
it
> >does not stop implementations from respecting access control settings.
The
> >proposal is that CAP would just avoid saying how to set access control in
> an
> >interoperable fashion.
>
> Having a separate administrative interface really is a losing idea.  I'm
> really not sure how the customer demographics for the large vendors breaks
> down, but for anything larger than a small work-group, this just won't
fly.
>  The end-user demands for maintaining access control on their calendars
> could represent a significant workload on the administrator.  I expect
that
> most administrative folks already have plenty of time-sensitive work
thrown
> at them by their users.
>
> (Wander down to the network/system admin folks in your building, and ask
> them if they want to take this task on for your organization...  :-)
>
> That this doesn't *stop* implementations from doing access control brings
> up an interesting thought.  If a particular feature, like access control,
> is present in most vendor's currently shipping products, doesn't that by
> itself make a strong argument that an interoperability protocol in this
> space should implement it as well?
>
> -Bob