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

[Eliot Lear <[e-mail]>]

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