Subject: My proposal for CALSCH-ACLs

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Tue, 15 Sep 1998 19:11:04 -0700 (PDT)

Access control lists (somewhat long).

The issues here:

	(1) The level of ACL support.

	(2) Use existing draft/RFC ACLs or not.
	    I say 'not'

	(3) ACL as iCAL-ish container or inside of XML.
	    I say 'iCAL-ish' (What is the name for that format?)

	(4) My proposal for the ACL model after discussing and
	    advice with some in private email and the Chicago
	    hallway meetings

1.0) What level of ACL support.

	(1) No ACL support in CAP. I do not think this is a
	    valid option. My arguments below.
	
	(2) ACL support in CAP - except not ACL administration in CAP.
	    I say no to this also. I think that both ACLs and ACL
	    administration need to be over the CAP-wire in the first
	    version of CAP.
	
	(3) ACL and ACL administration in CAP.

1.1)	No ACL support in CAP.

       	External Access Control. Should all access control
	exist outside of the CAP protocol?

	I say no - ACLs can not be defined outside of the first
	version of CAP.

	Without the ACL model in the first CAP standard I feel
	that CUAs would have to be developed with their own
	understanding of the access model. This would result in
	incompatible versions. Making a later CALSCH-ACL impossible.

1.2)	ACL support in CAP - except not ACL administration in CAP.

	Should the ACL administration be out of band and only
	the result of the enforcement of the ACL be over the wire?
	Should CAP define ACL administration over the wire?	

	I am not sure. I think that the ACL model and the METHOD
	property are compatible. METHODs (method names from iTIP):

		ADD			yes - Add an ACL or a set of ACLs.
		REPLY			yes - The reply to ADD.

		PUBLISH			no  - Not used.
		REQUEST			no  - Not used.
		CANCEL			no  - Not used.
		COUNTER			no  - Not used.
		DECLINECOUNTER		no  - Not used.

	And a new method (also can be used for other things as
	described in future email):

		QUERY			yes - How to get the ACL list.

	If this would work, then ACL administration can be done
	over the wire in the first version of CAP.

1.3) ACL and ACL administration in CAP.

	Level of complexity for CALSCH-ACL

	Some of the arguments that I have heard are:

	- Keep it SIMPLE, an operation simply succeeds or fails.
	  No ACL administration over the wire.

	  I do not think this is a good idea. If we do not iron our
	  ACL administration in the first draft we may find that we
	  created an ACL model with holes.

	- ACL control at the calendar and calendar property level.
	
	  I think that everyone says yes.
	  
	- ACL control at the component level.

	  I think that everyone says yes.
	  
	- ACL control at the property level.

	  I and others say yes. I have not heard anyone say
	  they had a problem with this.

	  Example: Only user 'DOUG' can edit the SUMMARY
	  and DESCRIPTION in the component with UID of 12345.

	- ACL at the property value level. Example,
	  In a calendar can the attendee of an appointment modify
	  the PARTSTAT, DELEGATED-FROM, DELEGATED-TO in ATTENDEE?

	  It would seem the answer is yes.

	  For a single users calendar they may receive the reply
	  in iMIP form, so they will have the ability to update
	  their own calendar ATTENDEE status. This could imply
	  that it would not need to be separately defined as an ACL.

	  However in a shared calendar like a public calendar
	  its possible that the ATTENDEEs themselves would need
	  to update their status if they were to attend or not
	  attend an existing group meeting. Example, "I will
	  not be attending the baseball team meeting this week".
	  They would need change their PARTSTAT from ACCEPTED
	  to DECLINED in the shared public calendar.

	  Its possible that after thinking through the existing
	  definitions of ATTENDEE a set of predefined rules could
	  solve this kind of problem and would not have to be done
	  with ACLs. However if a new component type were to be
	  developed in the future it may need property value ACLs.

	  Another approach is that to specify that all property value
	  specific ACLs must specify the ACL definition and rules
	  as part of the iana registration for the property value
	  specific ACL. This is the approach that I am taking.

--

2.0) Use existing draft/RFC ACLs or not.

	I have read:

	  1) RFC-2086 - IMAP4 ACL Extension.

	  2) draft-ietf-webdav-acl-reqts-00.txt - WebDAV Access Control Goals

	     draft-ietf-webdav-acl-00.txt - WebDAV ACL Protocol

	  3) draft-ietf-ldapext-acl-reqts-01.txt - Access Control
	       Requirements for LDAP

	     draft-ietf-ldapext-acl-model-00.txt - Access Control
	       Model for LDAP

My comments on how we can use/expand/ignore these drafts to
help accelerate CALSCH-ACL work.

2.1) RFC-2086 - IMAP4 ACL Extension.

RFC-2086 does not define generic ACL types.

IMAP defines 9 ACL types:

	l - lookup (mailbox is visible to LIST/LSUB commands)

	r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL,
	    SEARCH, COPY from mailbox)

	s - keep seen/unseen information across sessions (STORE SEEN flag)

	w - write (STORE flags other than SEEN and DELETED)

	i - insert (perform APPEND, COPY into mailbox)

	p - post (send mail to submission address for mailbox,
	    not enforced by IMAP4 itself)

	c - create (CREATE new sub-mailboxes in any implementation-defined
	    hierarchy)

	d - delete (STORE DELETED flag, perform EXPUNGE)

	a - administer (perform SETACL)

These could be overridden to mean calendar - I think this would be a kludge.
They also do not address all of the CALSCH needs (Calendar, Component,
UID, and Property, and Parameter).

2.1.2) The "webdav-acl" drafts:

These drafts describes ACLs wrapped in XML. We could use some/all of
the ideas. However a CALSCH ACL could not be described as a WEBDEV ACL.
I do not think that we should define a second container type (XML) as
part of CAP.

2.1.3) The "ldapext-acl" drafts:

The abstract from the requirements draft has an important point:

             This document describes the fundamental requirements of
             an access control list (ACL) model for the Lightweight
             Directory Application Protocol (LDAP) directory service.
             It is intended to be a gathering place for access control
             requirements needed to provide authorized access to and
             interoperatibility between directories. The RFC 2119

Interoperability between directories services. It is not designed to be
used between applications that need ACLs.

It is a way for LDAP servers to control access to LDAP entries.

Again we can snag some/many of the ideas. I just do not think
that we can say that a CALSCH ACL is an LDAP ACL.

We could use the same model. However we can not use the 'same'
scheme as it would interfere and be indistinguishable from
the entries that have been entered and used as access control
for LDAP entries.

There are also other issues with the LDAP draft that do not apply
to CALSCH. Example:

	Section 4.1.4 of the LDAP ACL model draft.

	Access Permissions.

	8	Use	Execute; useful in a controlling access to
			the objects referred to by directory
			entries than in controlling access to the
			directory entries themselves.

Now this applies to LDAP as you can use an entry without being
able to read it. I can't think of single example in CALSCH where
you would need to do anything with an iCalendar object when you did
not have READ permission.

If this were the only one or ones like this, then we could say
a CALSCH-ACL is an LDAP-ACL minus <a list>. But there are model
differences between the needs of LDAP-ACLs and CALSCH-ACLs.

I do not feel that the LDAP model fits CALSCH.

--

3.0) ACL as iCAL-ish container or inside of XML.

Above with the WebDAV ACLs I stated that I do not think that we should
define a second container type (XML) as part of CAP.

If we want to be able to transfer an entire calendar in an iCalendar-ish
way? I think yes.

How could we embed an XML object in an iCalendar object?
I do not think we want that. It would look messy and break
the parsers that know the [iV]Calendar containers.

How could we embed an iCalendar object in an XML object?
My feelings are that if there is a need to describe a calendar
in an XML object then that can be a separate standard. And after all
of the iCalendar objects are defined. After reading about XML I know
that it could be done. I just think that it is not in scope at this time.

--

4.0) My proposal for the ACL model after discussions and advice with some
     in private email.

	acl =		"BEGIN" ":" "ACL" CRLF
			1*acl-entry
			"END" ":" "ACL" CRLF

	; Where param is as defined in section 4.1 of iCalendar.
	; Currently no parameters exist for ACLs
	;
	acl-entry =	"CALENDAR-ACL" *( ";" param) 
			":" authenticated-user-list
			*acl-type *( ';' acl-type )
			CRLF

	acl-type =	( 
			   append-acl
			 / appendToAcl-acl
			 / appendCalProp-acl
			 / attendeeSelf-acl
			 / class-acl
			 / create-acl
			 / delete-acl
			 / iana-acl
			 / modify-acl
			 / modifyAcl-acl
			 / modifyCalProp-acl
			 / property-acl
			 / read-acl
			 / readAcl-acl
			 / readCalProp-acl
			 / uid-acl
			 / x-acl
			)

	; authenticated-user is the user login name that is associated
	; with the entity allowed under the ACL.
	;
	authenticated-user-list
		=	authenticated-user *("," authenticated-user)

	x-acl	=	; Any ACL that starts with X- or x-

	iana-acl =	; Any ACL registered by iana.

	; Where uid-text is the text value of UID as described
	; in section 4.8.4.7 of iCalendar.
	;
	uid-acl =	"UID" "=" uid-text

	; Where classvalue is defined in section 4.8.1.3
	; of iCalendar.
	;
	class-aclvalue = ( "ALL" / classvalue )
	class-acl =	 "CLASS" "=" class-aclvalue *( "," class-aclvalue )
					
	; Where name is as defined in iCalendar section 4.1 .
	; It is any property name that is legal in iCalendar.
	;
	property-acl =	"PROPERTY" "=" name *( "," name)

	create-acl =	"CREATE" "=" calendar-type *( "," calendar-type)
	delete-acl =	"DELETE" "=" calendar-type *( "," calendar-type)
	;
	; Each calendar-type MUST NOT be occur more than once per acl-entry.
	;
	calendar-type = ( "SUB-CALENDAR" / "CALENDAR" )

	append-acl =	    "APPEND" "=" comp-name-list

	; Can append to the list of ACLs.
	appendToAcl-acl =   "APPEND-TO-ACL"	; Can append new ACLs.

	; Can append new Calendar property.
	; If cal-prop-list is empty, then user may append any
	; calendar property.
	appendCalProp-acl = "APPEND-CAL-PROP"	*cal-prop-list

	cal-prop-list =		"=" cal-property *( "," cal-property )
	;
	; NOTE: Where cal-property is a calendar property that will
	; be defined in a separate email.

	modify-acl =	    "MODIFY" "=" comp-name-list

	; Can modify existing ACL list.
	modifyAcl-acl =	    "MODIFY-ACL"

	; Can modify existing Calendar property.
	; If cal-prop-list is empty, then user may modify any
	; existing calendar property.
	modifyCalProp-acl = "MODIFY-CAL-PROP" *cal-prop-list

	read-acl =	"READ" "=" comp-name-list

	; Can read (retrieve) the ACL list
	readAcl-acl =	"READ-ACL"

	; Can read existing Calendar property.
	; If cal-prop-list is empty, then user may read any
	; existing calendar property.
	readCalProp-acl =	"READ-CAL-PROP" *cal-prop-list

	; Each comp-name MUST NOT be occur more than once.
	;
	comp-name-list = comp-name *( "," comp-name )

	; Where ical-component-name is any component name
	; registered by iana for iCalendar, or the word "ALL".
	;
	; "ALL" is a shorthand for all valid tokens for comp-name.
	;
	comp-name =	"ALL" / ical-component-name

	; This ACL gives permission for attendee to edit/update/remove
	; their own "ATTENDEE" line only, and only specific parts
	; of the iCalendar property value.
	;
	; There is no need for the "ALL" value as it would have
	; the same meaning as the "PROPERTY=ATTENDEE" ACL.
	;
	; Where attparam is defined in iCalendar section 4.8.4.1 .
	;
	attendeeSelf-acl =	"ATTENDEE-SELF" "="
				attparam *( "," attparam)

4.1) ATTENDEE-SELF ACL

	An "ATTENDEE-SELF" ACL allows only the modification of the named
	field values for the iCalendar "ATTENDEE" content line where
	the cal-address matches the authenticated user.

4.1.1) ATTENDEE ical-address vs. authenticated user name.

	One of the iCalendar unresolavable problems is when user names
	do not match email addresses. Example:

	Login name (authenticated user): dougr

	Email addresses:		[email-masked]
					[email-masked]
					[email-masked]

	Are all valid email address and this problem is not
	unique to iCalendar. There is no standard way to map email
	address to an authenticated user name.

	The proposal here does not attempt to resolve this issue.
	It will be up to the server implementation to determine if
	the authenticated-user matches any email or group email listed
	in the iCalendar "ATTENDEE" content lines.

4.2) Example:

	BEGIN:ACL
	CALENDAR-ACL:Frank;READ=ALL;APPEND=ALL;MODIFY=ALL;
	 READ-ACL;MODIFY-ACL;APPEND-ACL;
	 READ-CAL-PROP;MODIFY-CAL-PROP;APPEND-CAL-PROP;
	 DELETE=CALENDAR,SUB-CALENDAR;CREATE=CALENDAR,SUB-CALENDAR;
	 CLASS=ALL
	CALENDAR-ACL:Doug,Tony;READ=ALL;MODIFY=ALL;CLASS=PUBLIC
	CALENDAR-ACL:Doug;READ=ALL;CLASS=CONFIDENTIAL
	CALENDAR-ACL:Lisa;READ=VEVENT,VJOURNAL;MODIFY=VEVENT,
	 CLASS=PUBLIC,CONFIDENTIAL
	CALENDAR-ACL:Bruce;READ=VEVENT;MODIFY=VEVENT;UID=12345
	CALENDAR-ACL:Alec;READ=VEVENT;UID=5678
	CALENDAR-ACL:Alec;MODIFY=VEVENT;UID=5678,PROPERTY=SUMMARY,DESCRIPTION
	CALENDAR-ACL:anonymous;READ=ALL;CLASS=PUBLIC
	CALENDAR-ACL:dougr;ATTENDEE-SELF=PARTSTAT;CLASS=PUBLIC
	END:ACL

Broken down as:

4.2.1)
	CALENDAR-ACL:Frank;READ=ALL;APPEND=ALL;MODIFY=ALL;
	 READ-ACL;MODIFY-ACL;APPEND-ACL;
	 READ-CAL-PROP;MODIFY-CAL-PROP;APPEND-CAL-PROP;
	 DELETE=CALENDAR,SUB-CALENDAR;CREATE=CALENDAR,SUB-CALENDAR;
	 CLASS=ALL

	User 'Frank' has:

		"READ" permission on "ALL" component types and,

		"APPEND" permission on "ALL" component types and,

		"MODIFY" permission on "ALL" component types and,

		"READ-ACL" permission - can read ACL list and,

		"MODIFY-ACL" permission - can modify ACL list and,

		"APPEND-ACL" permission - can append new ACLs and,

		"READ-CAL-PROP" permission - can read
				calendar properties and,

		"MODIFY-CAL-PROP" permission - can modify
				  calendar properties and,

		"APPEND-CAL-PROP" permission - can append new
				  calendar properties and,

		"DELETE" ability to DELETE calendars (subject to
		that calendars ACL list) and SUB-CALENDARS (of 
		this calendar).

		"CREATE" ability to CREATE new calendars and
		 SUB-CALENDARS in this calendar. The ability
		to create sub-calendars on other calendars is
		subject to that calendars ACL list.

		on "ALL" "CLASS"s ("PRIVATE", "CONFIDENTIAL",
		"PUBLIC', and x-name).

4.2.2)
	CALENDAR-ACL:Doug,Tony;READ=ALL;MODIFY=ALL;CLASS=PUBLIC

	Users 'Doug' and 'Tony' have:

		"READ" permission on "ALL" components and,

		"MODIFY" permission on "ALL" components,

		that are "PUBLIC".

4.2.3)
	CALENDAR-ACL:Doug;READ=ALL;CLASS=CONFIDENTIAL

	User 'Doug' has:

		"READ" permission on "ALL" components,

		that are "CONFIDENTIAL".

4.2.4)
	CALENDAR-ACL:Lisa;READ=VEVENT,VJOURNAL;MODIFY=VEVENT,
	 CLASS=PUBLIC,CONFIDENTIAL
	
	User 'Lisa' has:

		"READ" permission on "VEVENT"s and "VJOURNAL"s,

		that are "PUBLIC" and "CONFIDENTIAL".

4.2.5)
	CALENDAR-ACL:anonymous;READ=ALL;CLASS=PUBLIC

	An anonymous user, the default ACL for this calendar is:

		"READ" permission on "ALL" components,

		that are "PUBLIC".

4.2.6)
	CALENDAR-ACL:Bruce;READ=VEVENT;MODIFY=VEVENT;MODIFY=VEVENT;UID=12345

	User 'Bruce' has:

		"READ" and "MODIFY" permission on the "VEVENT" component,

		that is identified by "UID" 12345.

4.2.7)
	CALENDAR-ACL:Alec;READ=VEVENT;UID=12345

	User 'Alec' has:

		"READ" permission on the "VEVENT" component,

		that is identified by "UID" 12345.

4.2.8)
	CALENDAR-ACL:Alec;MODIFY=VEVENT;UID=12345,PROPERTY=SUMMARY,DESCRIPTION

	User 'Alec' has:

		"MODIFY" permission on the "VEVENT" component,

		that is identified by "UID" 12345,

		but can only "MODIFY" the "SUMMARY" and "DESCRIPTION"
		properties.

4.2.9)
	Examples at 4.2.7 and 4.2.8 combine to mean that user
	Alec can read "VEVENT" that matches "UID" 12345, and can
	"MODIFY" only the "DESCRIPTION" and "SUMMARY" properties
	of the matching "UID".

4.2.10)

	CALENDAR-ACL:dougr;ATTENDEE-SELF=PARTSTAT;CLASS=PUBLIC

	Authenticated user 'dougr' can update only the "PARTSTAT"
	of any "PUBLIC" event where the attendee has a iCalendar
	"ATTENDEE" cal-address that matches or is equivalent to 'dougr'.

4.3) Notes on ACLs

4.3.1) If a user is not listed, their ACLs are the same as the
       "anonymous" users entry.

4.3.2) If a user is not listed and there is not an "anonymous" user
       entry - access is denied.

4.3.3) A uid-acl becomes invalid and MUST be removed when the component
       that is uniquely identified by the uid-text is deleted.

4.3.4) When it is determined that an authenticated-user is no longer
       valid that user MUST be removed from the ACL lists (all acl-entry's).

4.3.5) When a authenticated-user-list is empty, then entire
       content-line (acl-entry) MUST be removed.

4.3.6) An acl with no acl-type's denies access.

	Example

		CALENDAR-ACL:anonymous

	Denies "anonymous" and all users not specificly listed with ACLs.

		CALENDAR-ACL:spamKing

	Denies the user name 'spamKing' from all access.

4.4) ACL INHERITANCE.

	The default mode for calendars is that they inherit their
	parents ACL list.

	The calendar property (to be fully defined in a separate 
	'calendar property' email) "ACL-INHERITANCE" controls this
	behavior.

	Only sub-calendars would have parents.

	It is also possible that default ACLs be defined and
	configurable in the implementation of the CS. Any such
	detail is out of scope to this proposal.

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/dougr.html
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Chris Newman <[email-masked]>
Date: Wed, 16 Sep 1998 10:13:56 -0700 (PDT)

> 	     draft-ietf-ldapext-acl-model-00.txt - Access Control

RFC 2244 also includes ACL support.  It is interesting because ACLs can be
applied to an entire dataset (equivalent abstraction level to a calendar),
to a given attribute across all entries in a dataset (equivalent
abstraction to a calendar property across all components), or to a
specific instance of a property in a dataset (equivalent abstraction to a
single property in a single component).

> not have READ permission.

The concept of "search" permission is quite common.  It allows you to
discover something exists without reading it.  For example, I might have a
UID for a calendar component and want to find out if there's an entry for
that UID, even if I may not be able to get a list of all UIDs in a
calendar.  Thus by granting "search permission" to the UID attribute I
give people the ability to find out if I've store a given component in my
calendar, without being able to count or identify all the components in my
calendar.  This is a contrived example, but people more familiar with
calendars may have a better one.

		- Chris