Subject: Re: [secdir] review of draft-desruisseaux-caldav-sched-10

From: Cyrus Daboo <[email-masked]>
Date: Tue, 06 Mar 2012 16:04:18 -0500

Hi Klaas,
Thank you very much for our review. FYI, following some other comments we 
have received, we have undertaken some significant editorial-only changes 
to this draft to, in particular, clarify and simplify introductory and 
descriptive elements. As such, several of your issues have been addressed 
(or eliminated) in our working copy.

--On March 3, 2012 5:05:08 PM +0100 Klaas Wierenga <[email-masked]> wrote:

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

That bulleted list has been eliminated as it was added as justification for 
a change of approach made earlier during the lifecycle of this draft and is 
no longer relevant.

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

So the SCHEDULE-AGENT parameter defined in this spec defaults to having the 
server do scheduling operations (sending, processing etc). However, there 
may be times when the client really needs to be able to do it itself. In 
particular, if there are attendees in an event who are not hosted on the 
CalDAV server, then the server might not be able to deliver any message to 
those attendees. In such a case a client might want to take over scheduling 
for those attendees (send iMIP - email - messages instead). In that 
situation it is important that all clients know this is going on, hence the 
need for SCHEDULE-AGENT=CLIENT. In other cases it might be known that the 
attendee has been informed of the meeting in an "out-of-band" manner and 
there is no need for actual iCalendar-based scheduling - that defines the 
need for SCHEDULE-AGENT=NONE. Having these different modes of operation 
does mean more complexity, but they are driven by important requirements.

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

That has been rewritten and that particularly humorous statement is now 
gone :-)

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

Well the only case where the server might delete them is if the user were 
"downgraded" and had scheduling capability totally removed. That is 
probably an unlikely scenario, and in any event, can be accomplished by 
simply setting scheduling ACLs for the user to deny scheduling. So at this 
point I would rather leave it as-is and not mention that servers can delete.

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

I have added a new section to Security considerations:

    11.1 Preventing Denial of Service Attacks

    Servers MUST ensure that clients cannot consume excessive server
    resources by carrying out "large" scheduling operations. In particular,
    servers SHOULD enforce CALDAV:max-resource-size, CALDAV:max-instances
    and CALDAV:max-attendees-per-instance pre-conditions as applicable for
    scheduling Inbox and Outbox collections.

Does that address your concern?

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

This again reflects the possibility of scheduling with users not hosted on 
the CalDAV server. In this case an attendee receives a scheduling message 
via iMIP (email) from an organizer not on the server. They may want to 
store the event on their CalDAV server so they can view it on all their 
devices. I have added an "e.g." into that sentence to help clarify:

   However, in some cases a scheduling message can get
   delivered directly to the client (e.g., via email [RFC6047])

Hopefully, that will clarify what is meant.

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

Well it is really all of Section 2 and 3 of RFC5546 - which is pretty much 
the whole specification. I don't think it is possible to be more specific 
than that without having a long list of sub-sections.

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

Well WebDAV and HTTP have traditionally allowed response codes to varying 
depending on what a server might want to do. e.g., in some cases a server 
might want to return a body on a successful PUT, in which case a 200 would 
be returned instead of a 204. Now, the WebDAV base spec (RFC4918) uses the 
term "common status codes" rather than "example status codes" so I will 
change our draft to use that same terminology. I have now adopted the 
RFC4918 text as follows:

    The list below summarizes the most common status codes used for this
    method. However, clients should be prepared to handle other 2/3/4/5xx
    series status codes as well.

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

As per requirements of WebDAV, WebDAV ACL and CalDAV - namely HTTP 
authentication. This is covered in Section 13 of RFC3744.

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

This section has been significantly reduced in size and the 4th paragraph 
is pretty much gone. I have made sure the term ETag is qualified by "HTTP".

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

Servers might send scheduling messages synchronously or asynchronously with 
respect to the HTTP request. i.e., for synchronous, all scheduling messages 
to attendees will have been sent and delivered by the time the response is 
sent back to the client. Whereas, for asynchronous, the server might queue 
up messages to attendees and process those after sending the HTTP response 
to the client. Since we do not wish to dictate the nature of a server's 
implementation in this regard, we have provided sufficient detail in the 
scheduling status values to accomodate both modes of operation, and to also 
cover the case where the server might be sending scheduling messages 
without any guarantee of an acknowledgement (code 1.1). Now strictly 
speaking we did state in the introduction that we do not cover the case of 
scheduling with "external" users, but for completeness we felt it important 
to include the 1.1 code, as many existing implementations do in fact have 
an "email gateway" feature that does allow sending of iMIP messages - but 
that is not directly in scope for this specification.

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

Done.

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

That is standard WebDAV terminology. See second paragraph of Section 15 of 
RFC4918.

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

I have added the following to the end of the first paragraph of Section 11:

    Clients MUST use the procedures detailed in Section 6 of [RFC6125] to
    verify the authenticity of the server.  Servers MUST make use of HTTP
    authentication [RFC2617] to verify the authenticity of the calendar
    user for whom the client is sending requests.

Would that suffice?

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

The requirements for CalDAV (RFC4791) does require TLS. Since there has 
been push-back from others about the length of the spec and unnecessary 
repetition, I am tempted to not add an additional statement about TLS 
support in the main body of the spec, but rather leave that to the security 
section.

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

So these threats are covered by the existing requirements in the security 
section. To make that more obvious, I have added a new sub-section titled 
"Mitigation of iTIP Threats" that lists each of the iTIP threats and a 
reference to parts of our specification that deal with those threats.

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

Unfortunately, because we are limited to "example.ZZZ" domains, it is 
sometimes confusing in examples where one wants to illustrate the use of 
different domains, as the only way to do that is by varying the TLD part. 
In this case the goal is to indicate that example.com users are locally 
hosted on the server, whereas users in other example.org domains are not. 
example.net is meant to illustrate an alternative calendar user address 
that is also valid for calendar users on the server. I have added the 
following paragraph to the examples section to clarify this:

   The server is assumed to be hosted in the "example.com" domain, and
   users whose email address is at the "example.com" domain are assumed
   to be hosted by the server.  In addition, the email addresses in the
   "example.net" domain are also valid email addresses for calendar
   users hosted by the server.  Calendar users with an email address at
   the "example.org" domain are assumed to not be hosted by the server.

In terms of who can do what, the scheduling privileges basically control 
that and the fact that the Security section always refers to 
"authenticated" users - i.e., users "known" to the server. So "external" 
users are never allowed to access the system to deliver scheduling messages 
direct to the server or request freebusy of hosted users.

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

I have added a new paragraph to the privacy section to try and address this:

   This specification only defines how calendar users on the same server
   are able to schedule with each other - unauthenticated users have no
   way to carry out scheduling operations.  Access control privileges
   (as per Section 6) can control which of those users can schedule with
   others.  Calendar users not wishing to expose their calendar
   information to other users can do so by denying privileges to
   specific users, or all users, for all scheduling operations, or
   perhaps only freebusy.

Is that sufficient?

-- 
Cyrus Daboo

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 08 Mar 2012 12:11:42 +0100

On 3/6/12 10:04 PM, Cyrus Daboo wrote:

Hi Cyrus,

> Thank you very much for our review. FYI, following some other
> comments

you're welcome

> we have received, we have undertaken some significant
> editorial-only changes to this draft to, in particular, clarify and
> simplify introductory and descriptive elements. As such, several of
> your issues have been addressed (or eliminated) in our working
> copy.
> 
>> 1.2 approach ------------------ bullet 1 and 2 together seem to
>> form 1 problem, bullet 1 is just stating a fact.
> 
> That bulleted list has been eliminated as it was added as
> justification for a change of approach made earlier during the
> lifecycle of this draft and is no longer relevant.

ack

> 
>> 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.
> 
> So the SCHEDULE-AGENT parameter defined in this spec defaults to
> having the server do scheduling operations (sending, processing
> etc). However, there may be times when the client really needs to
> be able to do it itself. In particular, if there are attendees in
> an event who are not hosted on the CalDAV server, then the server
> might not be able to deliver any message to those attendees. In
> such a case a client might want to take over scheduling for those
> attendees (send iMIP - email - messages instead). In that situation
> it is important that all clients know this is going on, hence the
> need for SCHEDULE-AGENT=CLIENT. In other cases it might be known
> that the attendee has been informed of the meeting in an
> "out-of-band" manner and there is no need for actual 
> iCalendar-based scheduling - that defines the need for 
> SCHEDULE-AGENT=NONE. Having these different modes of operation does
> mean more complexity, but they are driven by important
> requirements.

ok, fair enough, this shows my lack of understanding of the specifics

> 
>> 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.
> 
> That has been rewritten and that particularly humorous statement is
> now gone :-)

;-)

> 
>> 4. scheduling collections --------------------------------- can
>> the server only create or also delete the collections?
> 
> Well the only case where the server might delete them is if the
> user were "downgraded" and had scheduling capability totally
> removed. That is probably an unlikely scenario, and in any event,
> can be accomplished by simply setting scheduling ACLs for the user
> to deny scheduling. So at this point I would rather leave it as-is
> and not mention that servers can delete.

ok, it is just that I believe I will not be the only one wondering
about delete.

>> 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)
> 
> resources by carrying out "large" scheduling operations. In
> particular, servers SHOULD enforce CALDAV:max-resource-size,
> CALDAV:max-instances and CALDAV:max-attendees-per-instance
> pre-conditions as applicable for scheduling Inbox and Outbox
> collections.
> 

yes, thank you!

> 
>> 5.2.2.2 create ------------------ In which cases can scheduling
>> messages be delivered directly to the client? And can't you
>> forbid that?
> 
> This again reflects the possibility of scheduling with users not
> hosted on the CalDAV server. In this case an attendee receives a
> scheduling message via iMIP (email) from an organizer not on the
> server. They may want to store the event on their CalDAV server so
> they can view it on all their devices. I have added an "e.g." into
> that sentence to help clarify:
> 
> However, in some cases a scheduling message can get delivered
> directly to the client (e.g., via email [RFC6047])
> 

yes it does

>> ------------------------------------------------------------- Can
>> you be more specific about WHERE in RFC5546 these rules are 
>> specified?
> 
> Well it is really all of Section 2 and 3 of RFC5546 - which is
> pretty much the whole specification. I don't think it is possible
> to be more specific than that without having a long list of
> sub-sections.

perhaps just say "in sections 2 and 3 of RFC5546"? but no big deal

> 
>> 7.1 status codes ---------------------- These are EXAMPLE
>> response codes? Why not normative? And doesn't that give
>> interoperability issues?
> 
> Well WebDAV and HTTP have traditionally allowed response codes to 
> varying depending on what a server might want to do. e.g., in some
> cases a server might want to return a body on a successful PUT, in
> which case a 200 would be returned instead of a 204. Now, the
> WebDAV base spec (RFC4918) uses the term "common status codes"
> rather than "example status codes" so I will change our draft to
> use that same terminology. I have now adopted the RFC4918 text as
> follows:
> 
> The list below summarizes the most common status codes used for
> this method. However, clients should be prepared to handle other
> 2/3/4/5xx series status codes as well.

ack

>> ---------------------------------------------------- How is the
>> user authenticated?
> 

ok

>> 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.
> 
> This section has been significantly reduced in size and the 4th 
> paragraph is pretty much gone. I have made sure the term ETag is 
> qualified by "HTTP".

ok

> 
>> 9.2 schedule status values ------------------------------------ 
> Servers might send scheduling messages synchronously or
> asynchronously with respect to the HTTP request. i.e., for
> synchronous, all scheduling messages to attendees will have been
> sent and delivered by the time the response is sent back to the
> client. Whereas, for asynchronous, the server might queue up
> messages to attendees and process those after sending the HTTP
> response to the client. Since we do not wish to dictate the nature
> of a server's implementation in this regard, we have provided 
> sufficient detail in the scheduling status values to accomodate
> both modes of operation, and to also cover the case where the
> server might be sending scheduling messages without any guarantee
> of an acknowledgement (code 1.1). Now strictly speaking we did
> state in the introduction that we do not cover the case of
> scheduling with "external" users, but for completeness we felt it
> important to include the 1.1 code, as many existing implementations
> do in fact have an "email gateway" feature that does allow sending
> of iMIP messages - but that is not directly in scope for this
> specification.

sorry, I formulated poorly, I was just refering to the fact that the
numbering didn't go 1,2,3,4.... so I was wondering about the
significance of the chosen numbers

>> ---------------------------------------------------- It might
>> make sense to point out that T and F stand for True and False
> 
> Done.

ok

> 
> That is standard WebDAV terminology. See second paragraph of
> Section 15 of RFC4918.

ok

>> -------------------------------------- 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]
> 
> Clients MUST use the procedures detailed in Section 6 of [RFC6125]
> to verify the authenticity of the server.  Servers MUST make use of
> HTTP authentication [RFC2617] to verify the authenticity of the
> calendar user for whom the client is sending requests.
> 
> Would that suffice?

for me it does, but having gone through this discussion myself for
draft-ietf-sasl-saml myself the IESG might have some additional
comments ;-)

> 
>> 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?)
> 
> The requirements for CalDAV (RFC4791) does require TLS. Since there
> has been push-back from others about the length of the spec and
> unnecessary repetition, I am tempted to not add an additional
> statement about TLS support in the main body of the spec, but
> rather leave that to the security section.

ok, I can live with that

> 
>> 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.
> 
> So these threats are covered by the existing requirements in the 
> security section. To make that more obvious, I have added a new 
> sub-section titled "Mitigation of iTIP Threats" that lists each of
> the iTIP threats and a reference to parts of our specification that
> deal with those threats.

perfect

>> @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?
> 
> Unfortunately, because we are limited to "example.ZZZ" domains, it
> is sometimes confusing in examples where one wants to illustrate
> the use of different domains, as the only way to do that is by
> varying the TLD part. In this case the goal is to indicate that
> example.com users are locally hosted on the server, whereas users
> in other example.org domains are not. example.net is meant to
> illustrate an alternative calendar user address that is also valid
> for calendar users on the server. I have added the following
> paragraph to the examples section to clarify this:
> 
> The server is assumed to be hosted in the "example.com" domain,
> and users whose email address is at the "example.com" domain are
> assumed to be hosted by the server.  In addition, the email
> addresses in the "example.net" domain are also valid email
> addresses for calendar users hosted by the server.  Calendar users
> with an email address at the "example.org" domain are assumed to
> not be hosted by the server.

ok, that clarifies at least for me a lot.

> 
> In terms of who can do what, the scheduling privileges basically
> control that and the fact that the Security section always refers
> to "authenticated" users - i.e., users "known" to the server. So
> "external" users are never allowed to access the system to deliver
> scheduling messages direct to the server or request freebusy of
> hosted users.

yes, with the previous item that makes sense

>> 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..
> 
> This specification only defines how calendar users on the same
> server are able to schedule with each other - unauthenticated users
> have no way to carry out scheduling operations.  Access control
> privileges (as per Section 6) can control which of those users can
> schedule with others.  Calendar users not wishing to expose their
> calendar information to other users can do so by denying privileges
> to specific users, or all users, for all scheduling operations, or 
> perhaps only freebusy.
> 
> Is that sufficient?
> 

yes

Thank you!

Klaas