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

From: batsonjay at plumcanary.com (Jay Batson)
Date: Mon Feb 26 05:23:58 2007

Re-sending the message below, because I believe it still to be an  
issue, and there was no response from the list regarding my point.

Since Eliot seems to be collecting the "definitive list," and this  
wasn't on it, I hope this will make it onto the radar screen.
-jb

------------- Original message ---------------

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  
entries are replicated to team members through some mechanism);
- 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.

Real-life user behaviors will dictate that users want (at least) 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, change dates when all agree on the  
need for change (but the original assignor isn't present to make the  
change), etc.

Note:  Our task management software uses iCal for tasks, and 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 only 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 details 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/20070226/823776ee/attachment-0001.htm