Subject: [secdir] SecDir review of draft-ietf-calsify-2446bis-09

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Sep 2009 09:02:17 +0300

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 document is a refresh of the 1998 iTip, an abstract transport protocol for iCalendar objects. This protocol is then instantiated for specific transports, e.g. RFC 2447, iMip (mail transport).

General

The original RFC 2446 security considerations seem extensive enough, and the proposed mitigations are reasonable. I believe the changes in -bis do not require additional work in this area (but see below).

Reality Check

If basing the entire security of the protocol on S/MIME may have been reasonable in 1998, today this is almost meaningless. S/MIME is too rarely used to protect mail in transit, and I would imagine its use to protect calendaring is even less prevalent.

Security

- In Sec. 6.2, replace "encrypted" by "encrypted and authenticated".
- An attack that is never mentioned is unauthorized creation of events. In many enterprise situations not everyone is authorized to invite the CEO, for example. Similarly, there may be tight control over who is allowed to delegate to whom. This obviously calls for an access control mechanism, something that is never mentioned in the document.

Nits

- 1.4: in table, objecy -> object
- 3.2.5 and 3.4.5: is MUST -> MUST

Email secured by Check Point

Email secured by Check Point

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Sep 2009 12:53:23 +0200

Yaron,

Thank you for taking the time to review draft-ietf-calsify-2446bis-09. 
Cyrus should respond in due course to these comments.  I will note two
things:

1.  iTIP is meant to be implemented on top of a transport, such as mail
or some other means (perhaps carrier pigeon or swallow, or other more
sophisticated DTN).  We cannot assume at this layer that there is an
interactive bidirectional negotiating path.  As such the solution space
here is quite limited.  We would value your additional thoughts on this
subject.

2.  We should separate – even in rfc2447bis – encryption and
authentication.  Since RFC-2447 was released the world HAS changed, and
we should consider new approaches and mitigations to email
authenticaiton, such as DKIM.

Warmest regards,

Eliot

On 9/21/09 8:02 AM, Yaron Sheffer wrote:
>
> 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 document is a refresh of the 1998 iTip, an abstract transport
> protocol for iCalendar objects. This protocol is then instantiated for
> specific transports, e.g. RFC 2447, iMip (mail transport).
>
>  
>
> General
>
>  
>
> The original RFC 2446 security considerations seem extensive enough,
> and the proposed mitigations are reasonable. I believe the changes in
> -bis do not require additional work in this area (but see below).
>
>  
>
> Reality Check
>
>  
>
> If basing the entire security of the protocol on S/MIME may have been
> reasonable in 1998, today this is almost meaningless. S/MIME is too
> rarely used to protect mail in transit, and I would imagine its use to
> protect calendaring is even less prevalent.
>
>  
>
> Security
>
>  
>
> - In Sec. 6.2, replace “encrypted” by “encrypted and authenticated”.
>
> - An attack that is never mentioned is unauthorized creation of
> events. In many enterprise situations not everyone is authorized to
> invite the CEO, for example. Similarly, there may be tight control
> over who is allowed to delegate to whom. This obviously calls for an
> access control mechanism, something that is never mentioned in the
> document.
>
>  
>
> Nits
>
>  
>

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Sep 2009 11:34:58 -0400

Hi Yaron,
Thank you for your review.

> protect calendaring is even less prevalent.

This is a good point. In fact with CalDAV we are doing iTIP scheduling over 
HTTP with SSL and S/MIME is not involved at all. Given Eliot's comment 
about the nature of iTIP (i.e. transport independence) at this point it may 
be best to remove the explicit MUST for S/MIME.

Proposal:

Section 6.2: remove the sentence:

   This may be accomplished using
   public key technology, specifically Security Multiparts for MIME
   [RFC1847] in the iTIP transport binding.

Section 6.2.1: change title to: "Securing iTIP transactions"

Change first sentence to:

   iTIP transport bindings MUST provide a mechanism to enable 
authentication of the
   sender's identity, and privacy and integrity of the data being
   transmitted.

The reference to 1847 would be removed entirely.

> - In Sec. 6.2, replace “encrypted” by “encrypted and

Fixed in my working copy.

> - An attack that is never mentioned is unauthorized creation of events.

> In many enterprise situations not everyone is authorized to invite the
> CEO, for example. Similarly, there may be tight control over who is
> allowed to delegate to whom. This obviously calls for an access control
> mechanism, something that is never mentioned in the document.

Good point. In CalDAV scheduling 
(<http://tools.ietf.org/html/draft-desruisseaux-caldav-sched>) we have in 
fact used WebDAV ACL with a new set of privileges to allow just that. This 
actually goes a little beyond just access control. For example, with iMIP 
(email) there is no way to prevent someone from sending an iMIP message to 
someone else. In that case email filtering needs to be used to enforce 
restrictions. Whilst the specific details of how all that should work 
depends on the transport, something does need to be said in this document. 
Therefore I propose adding the following:

6.2.3 Access Controls and Filtering

    In many environments there could be restrictions on who is allowed to
    scheduled with whom, and who allowed delegates are for particular
    calendar users.

    iTIP transport bindings SHOULD provide mechanisms for implementing
    access controls or filtering to ensure iTIP transactions only take
    place between authorized calendar users. That would include preventing
    one calendar user from scheduling with another, or a calendar user
    delegating to another.

> - 3.2.5 and 3.4.5: is MUST -> MUST

Both fixed in my working copy.

-- 
Cyrus Daboo

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 23 Sep 2009 00:47:07 +0300

Hi Cyrus,

[removing IESG].

Thanks for accepting my review. Please see my remaining responses inline.

Thanks,
	Yaron

> -----Original Message-----
> From: Cyrus Daboo [mailto:[email-masked]]
> Sent: Tuesday, September 22, 2009 18:35
> To: Yaron Sheffer; secdir; [email-masked]; draft-ietf-calsify-
> [email-masked]
> Subject: Re: SecDir review of draft-ietf-calsify-2446bis-09
> 
> Hi Yaron,
[YS] Well in fact, having read the first paragraph of Sec. 15 of CalDAV, I would recommend that you add more depth to your use of SSL. Just saying "Servers and clients MUST use an HTTP connection protected with TLS as defined in [RFC2818] for all scheduling transactions" will not give you the security that you need. Things like how clients are authenticated, and what fields in the calendar objects must match which certificate fields.

> The reference to 1847 would be removed entirely.

[YS] If there are still bindings that do use S/MIME, you might want to have "if S/MIME is used to provide these assurances..." and the rest of the existing subsection.
>     one calendar user from scheduling with another, or a calendar user
[YS] Sounds good.
> Scanned by Check Point Total Security Gateway.