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

[Klaas Wierenga <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
> 
> --On March 3, 2012 5:05:08 PM +0100 Klaas Wierenga
> <[e-mail]> 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.

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.

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

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])
> 
> Hopefully, that will clarify what is meant.

yes it does

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

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

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

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

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


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

ok

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

ok

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

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

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

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

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

yes

Thank you!

Klaas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9Yk+4ACgkQH2Wy/p4XeFIp2ACfTcBrL62BU1AnqdEkdEDOu9NT
ycwAnRSE0gJRLd7ArU4Qum3vTSrrREza
=0h0R
-----END PGP SIGNATURE-----