[secdir] review of draft-desruisseaux-caldav-sched-10

Klaas Wierenga <klaas@cisco.com> Sat, 03 March 2012 16:05 UTC

Return-Path: <klaas@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CD96321F86AD; Sat, 3 Mar 2012 08:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.222
X-Spam-Status: No, score=-9.222 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UHAAZbnKsATq; Sat, 3 Mar 2012 08:05:11 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7A26921F867D; Sat, 3 Mar 2012 08:05:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=5406; q=dns/txt; s=iport; t=1330790711; x=1332000311; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=hsLlmoseo6ZL+DG0NNCx6CJAlN5sZR69XRnTwe8oQfw=; b=aazt9Roip5rIOOs85+aCGwVa2HQBVPTIfpbDrgQWDI2J4zU/ThScIziG cVB/+Q4pfQUdDfBqAFaxdlxRLW4AG21f7p1eMuq91rqwb4KcykeEghaE3 hUmfCCmkTDz6LTdABUOSY2FtpBXJ4RsdQHTI8Xl6bTUud7+m5LS3BhZtA w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAOU/Uk+tJXHB/2dsb2JhbABDtD+BB4IWASeBfQE0h2WaTQGeFI96YwSVPoUzil+CZIFVFw
X-IronPort-AV: E=Sophos;i="4.73,526,1325462400"; d="scan'208";a="63537150"
Received: from rcdn-core2-6.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP; 03 Mar 2012 16:05:11 +0000
Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com []) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q23G5952011712; Sat, 3 Mar 2012 16:05:10 GMT
From: Klaas Wierenga <klaas@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 3 Mar 2012 17:05:08 +0100
Message-Id: <A6C32292-1E9D-44E1-A0F3-680B8379F018@cisco.com>
To: draft-desruisseaux-caldav-sched.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [secdir] review of draft-desruisseaux-caldav-sched-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Mar 2012 16:05:13 -0000


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.




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