Subject: [Ietf-calsify] Issues with Security / Spoofing section

From: batsonjay at plumcanary.com (Jay Batson)
Date: Fri Feb 2 01:22:20 2007

I was reviewing the latest draft, and finally (after not paying  
sufficient attention previously) noted that the Security section has  
a real problem.

The SPOOFING section is trouble waiting to happen.  Currently, that  
section says:

"... the "Organizer" is the only person authorized to make changes to  
an existing "VEVENT", "VTODO", "VJOURNAL" calendar component...."

(I'm going to restrict my comments to the application of that logic  
to VTODO and VJOURNAL components, because I think VEVENT may have  
different needs.)

ASSERTION:
In general, the current language isn't practical in real life.  When  
VTODOs (and/or VJOURNALs) are used in group task coordination  
applications, it is highly likely that other persons besides the  
"Organizer" will need to be able to modify these components after  
they are created.  Thus, the current restriction is not practical and  
should not remain.

ILLUSTRATIVE BACKGROUND:
Assume:
- a collaborative application that stores tasks assigned to people in  
a project team;
- tasks are stored as VTODO entries in a project.ics file (and  
the .ics file is regularly "synchronized" among team members);
- all users in a project have access to all the project information  
(e.g. all have read-rights to the .ics file)
- assume the software implements the current SPOOFING constraint --  
that only the "Organizer" (task assignor) can modify the task details.
(This is a "generalized" description of what our software does.   
Implementation is different, but the effect is the same.)

Our largest single feature request from users -- by a factor of at  
least 3 over others -- is that users want the "Attendees" to be able  
to modify the VTODO entry.  People often need to modify task  
descriptions to conform with changed requirements, add / modify /  
change assignees (e.g. remove somebody who left the company/team and  
whose PC/software-account you no longer have access to), change dates  
when all agree on the need for change (but the original assignor  
isn't present to make the change), etc.

Note:  In fact, most of our customers want *any* person in the  
project team to be able to modify the task details for *any* task in  
the project -- not just the "Attendees" of a project.  For instance,  
if Sally assigned task A to herself, but went to the hospital to have  
a baby this morning, and Jim is going to assume responsibility for  
it, Jim must have the ability to change the "Attendee" - and probably  
the due-date, too.

In real life, teams work together; it's not a strict hierarchy of  
assignor/assignee, and task detailss change constantly.  Therefore,  
the current SPOOFING restriction is simply not practical if iCalendar  
VTODOs are to be used in anything else than a single-user software  
application.

PROPOSAL:
2445 should simply be silent about who can, or cannot modify (at  
least) VTODO and VJOURNAL components.  Access control is outside the  
scope of the definition of task data.  If some application wants to  
decide to only grant write capabilities to the Organizer it can.  If  
another application wants to maintain ACLs outside the scope of the  
calendar object, it can.  If others want to add x-props to include  
ACL guidance (which could be difficult to enforce if there is no  
secure transit), it can.  It's not the role of 2445 to specify ACLs;  
it is only its role to define the listed components in *this* case  
(of tasks/journals).

I propose the SPOOFING section be rewritten to indicate that the RFC  
is providing no access control for these two components, identify the  
risks of uncontrolled access, and leave security implementation up to  
some externality, e.g. iTIP.  Here is some proposed text (though I  
suspect this needs LOTS of discussion before it goes in):

NEW LANGUAGE:
-----------
SPOOFING:
In this memo, there is no restriction on who is authorized to make  
changes to a "VTODO" or "VJOURNAL" calendar component entry.  Some  
applications using these components in a collaborative setting may  
intentionally desire to provide "Attendees" the ability to update  
this data based on ongoing actual activities, and communicate these  
changes to the "Attendees" as part of the collaborative process.   
Malicious behavior in this context can of course result in data  
changes or loss that is unexpected by the "Attendees".  This is an  
inherent risk in any situation where all "Attendees" are  
collaborating on "VTODO" or "VJOURNAL" entries, and it is up to the  
individuals, or to some other controlling technology, such as iTIP,  
document versioning, or other, to provide any desired control over  
the ability of "Attendees" to make changes in these components.
-----------

Note again that I cannot speak to the implications of changing the  
SPOOFING section relative to VEVENT components.  There must of course  
be SOME description of how to handle VEVENT components.  My language  
proposal above does NOT address this.  Somebody more versed in the  
implications of calendaring must come up with it.

Comments?
-jb

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070202/e3c0d066/attachment.html