Last Call Review of draft-desruisseaux-caldav-sched-
review-desruisseaux-caldav-sched-secdir-lc-wierenga-2012-03-08-00

Request Review of draft-desruisseaux-caldav-sched
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-03-08
Requested 2012-02-15
Other Reviews Genart Last Call review of - by Vijay Gurbani (diff)
Review State Completed
Reviewer Klaas Wierenga
Review review-desruisseaux-caldav-sched-secdir-lc-wierenga-2012-03-08
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg03137.html
Draft last updated 2012-03-08
Review completed: 2012-03-08

Review
review-desruisseaux-caldav-sched-secdir-lc-wierenga-2012-03-08

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This draft defines the calendar-auto-schedule feature, a standard way of scheduling of iCalendar based calendar components between calendar users leveraging the iCalendar Transport-independent Interoperability Protocol (iTIP).

I have read the document specifically from a security PoV but will share my other comments with you as well. Some of them may be due to a lack of understanding of the underlying protocols, in that case apologies.

Regards,

Klaas

======

1.2 approach
------------------
bullet 1 and 2 together seem to form 1 problem, bullet 1 is just stating a fact.

something that must have been discussed in extremes, but I can't help wondering what the reasoning is for not making the server responsible for sending and processing scheduling messages, is that a legacy thing? It seems to overly complicate this document that always 2 cases need to be distinguished.

1.3 limitations
-------------------
I can't help a chuckle with the statement "to keep this specification simple", I think simplicity got lost somewhere in the process. I probably would have considered breaking the document up in multiple documents.

4. scheduling collections
---------------------------------
can the server only create or also delete the collections?

4.1 scheduling outbox collections
---------------------------------------------
caldav-max-resource-size, not using this seems to invite DoS attacks, perhaps make it a SHOULD to support this and mention in the security considerations the possibility of DoS attacks? (same goes for 4.2)

5.2.2.2 create
------------------
In which cases can scheduling messages be delivered directly to the client? And can't you forbid that?

6 processing incoming scheduling messages
-------------------------------------------------------------
Can you be more specific about WHERE in RFC5546 these rules are specified?

7.1 status codes
----------------------
These are EXAMPLE response codes? Why not normative? And doesn't that give interoperability issues?

7.2.1 day:need-privileges precondition
----------------------------------------------------
How is the user authenticated?

8. Avoiding conflicts when updating scheduling object resources
---------------------------------------------------------------------------------------
First paragraph: reference for ETag and If-Match?

Fourth paragraph: I don't really get the text, a simple example might help.

9.2 schedule status values
------------------------------------
Is there any reasoning behind the delivery status codes? To the uninitiated (me) they seem randomly chosen.

11.1 additional message header fields
----------------------------------------------------
It might make sense to point out that T and F stand for True and False

12.2 caldav:schedule-default-calendar-url property
---------------------------------------------------------------------
What does it mean that a property is protected?

15. Security Considerations
--------------------------------------
You write that servers and clients MUST use TLS. That is not sufficiently strong, you must make sure that server and client mutually authenticate each other. I would at the very least expect some text about server validation [RFC6125]

Also, in the main text there is no mentioning of HTTPS, but only HTTP, I think you need to say also in the main text that you expect a secure channel (unless you don't?)

This document leverages iTIP [RFC5546], however that document specifies an abstract transport protocol, and assumes other documents to implement particular transports. Furthermore it does't contain any normative language for dealing with the threats that are identified:
- 6.1.1 Spoofing the "Organizer"
- 6.1.2 Spoofing the "Attendee"
- 6.1.3 Unauthorized Replacement of the Organizer
- 6.1.4 Eavesdropping
- 6.1.5 Flooding a Calendar
- 6.1.6     Procedural Alarms
- 6.1.7 Unauthorized REFRESH Requests

I would expect in the security considerations mention of these threats and normative language about at least the authentication of the organizer to the attendee and the attendee to the organizer. 

In the examples there is mention of users @example.org and users @example.com, I suspect that that means that multiple calendaring domains can operate in a federated manner, how is the authenticity of a user in another domain validated? Can only "local users" look up free/busy information? If not, how do you make sure that not the whole Internet can lookup for example free/busy information?

15.3 Privacy Considerations

Especially in large deployments spanning many organizations (like Google Calendar) I think Schedule-Reply request header is not going to cut it. I would expect at least some discussion about privacy and free/busy information, information about calendar event traveling over organizational boundaries (or not) etc..