Last Call Review of draft-ietf-calsify-2446bis-
review-ietf-calsify-2446bis-secdir-lc-sheffer-2009-09-25-00

Request Review of draft-ietf-calsify-2446bis
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-22
Requested 2009-09-03
Authors Cyrus Daboo
Draft last updated 2009-09-25
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-calsify-2446bis-secdir-lc-sheffer-2009-09-25
Review completed: 2009-09-25

Review
review-ietf-calsify-2446bis-secdir-lc-sheffer-2009-09-25






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