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

From: aki.niemi at Nokia.com (Aki Niemi)
Date: Tue Mar 6 06:49:20 2007

Hi Jay,

I punched this issue in as #80 in the tracker.

I suspect we're in for an even more extensive revamp of the Security
Considerations section, and your proposal seems like a good start.

Specifically, I think the section should ultimately talk about exactly
what's in scope of RFC2445bis, and more importantly what's *not* in
scope. I would assume transport security for instance only really
becomes an issue in iTIP/iMIP.

Any volunteers?

Cheers,
Aki

ext Jay Batson wrote:
> 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)
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify