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

Yaron Sheffer <yaronf@checkpoint.com> Mon, 21 September 2009 06:01 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C491A3A67A5; Sun, 20 Sep 2009 23:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3gRaYcV4ignm; Sun, 20 Sep 2009 23:01:21 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com []) by core3.amsl.com (Postfix) with ESMTP id B022E3A67A4; Sun, 20 Sep 2009 23:01:20 -0700 (PDT)
X-CheckPoint: {4AB7160C-5-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9F91A29C005; Mon, 21 Sep 2009 09:02:20 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com []) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7A18829C002; Mon, 21 Sep 2009 09:02:20 +0300 (IDT)
X-CheckPoint: {4AB7160C-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost []) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8L62JSr026810; Mon, 21 Sep 2009 09:02:20 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([]) by il-ex01.ad.checkpoint.com ([]) with mapi; Mon, 21 Sep 2009 09:02:19 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: secdir <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-calsify-2446bis.all@tools.ietf.org" <draft-ietf-calsify-2446bis.all@tools.ietf.org>
Date: Mon, 21 Sep 2009 09:02:17 +0300
Thread-Topic: SecDir review of draft-ietf-calsify-2446bis-09
Thread-Index: Aco6gRMGhqy0iK79QF6p8HpEuJDpzw==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370ilex01adche_"
MIME-Version: 1.0
Subject: [secdir] SecDir review of draft-ietf-calsify-2446bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 06:01:25 -0000

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


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.


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


- 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