Re: [secdir] SecDir review of draft-ietf-calsify-2446bis-09
Cyrus Daboo <cyrus@daboo.name> Tue, 22 September 2009 15:34 UTC
Return-Path: <cyrus@daboo.name>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F4628C12C; Tue, 22 Sep 2009 08:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuDx3sKnD5iQ; Tue, 22 Sep 2009 08:34:00 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 4088A28C11D; Tue, 22 Sep 2009 08:34:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1003A1FA96D; Tue, 22 Sep 2009 11:35:04 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq+UIDgEYP7m; Tue, 22 Sep 2009 11:35:03 -0400 (EDT)
Received: from caldav.corp.apple.com (caldav.corp.apple.com [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id F3CE01FA965; Tue, 22 Sep 2009 11:35:01 -0400 (EDT)
Date: Tue, 22 Sep 2009 11:34:58 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Yaron Sheffer <yaronf@checkpoint.com>, secdir <secdir@ietf.org>, iesg@ietf.org, draft-ietf-calsify-2446bis.all@tools.ietf.org
Message-ID: <7236D8B61D923C0A53A03F7E@caldav.corp.apple.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size="2923"
X-Mailman-Approved-At: Tue, 22 Sep 2009 10:51:15 -0700
Subject: Re: [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: Tue, 22 Sep 2009 15:34:01 -0000
Hi Yaron, Thank you for your review. --On September 21, 2009 9:02:17 AM +0300 Yaron Sheffer <yaronf@checkpoint.com> wrote: > 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. 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. > Security > > > > - In Sec. 6.2, replace “encrypted” by “encrypted and > authenticated”. 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. > Nits > > > > - 1.4: in table, objecy -> object > > - 3.2.5 and 3.4.5: is MUST -> MUST Both fixed in my working copy. -- Cyrus Daboo
- [secdir] SecDir review of draft-ietf-calsify-2446… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-calsify-… Eliot Lear
- Re: [secdir] SecDir review of draft-ietf-calsify-… Cyrus Daboo
- Re: [secdir] SecDir review of draft-ietf-calsify-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-calsify-… Alexey Melnikov