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

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..