[secdir] Security review of draft-ietf-calsify-rfc2447bis-10
"Hilarie Orman" <hilarie@purplestreak.com> Thu, 02 September 2010 23:39 UTC
Return-Path: <hilarie@purplestreak.com>
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 B19D93A677C; Thu, 2 Sep 2010 16:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5U4B+isninfT; Thu, 2 Sep 2010 16:39:29 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 6AAA83A65A6; Thu, 2 Sep 2010 16:39:29 -0700 (PDT)
Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1OrJNt-0007hG-Jy; Thu, 02 Sep 2010 17:39:57 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1OrJNr-0007iu-Aw; Thu, 02 Sep 2010 17:39:57 -0600
Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o82NdBEX027379; Thu, 2 Sep 2010 17:39:11 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o82NdAic027378; Thu, 2 Sep 2010 17:39:10 -0600
Date: Thu, 02 Sep 2010 17:39:10 -0600
Message-Id: <201009022339.o82NdAic027378@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: Hilarie Orman <hilarie@purplestreak.com>
To: Alexey.Melnikov@isode.com
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;Alexey.Melnikov@isode.com
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com)
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Thu, 02 Sep 2010 23:39:32 -0000
Security review of draft-ietf-calsify-rfc2447bis-10 Do not be alarmed. 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 review comments. The document describes the "iCalendar Message-Based Interoperability Protocol (iMIP)", a protocol for transmitting calendar events over SMTP. The security considerations are tied to authenticating the entity with the role of "Organizer" or "Attendee". The authentication relies on MIME security for attaching signatures and public key certificates. The SMTP sender is not relevant to the authentication. I'm slightly puzzled by the first step listed in "Security Considerations" about the steps needed to perform authentication. 1. Using the security mechanism compliant with [RFC-1847], determine who signed the email message containing the iCalendar object. This is the "signer". Note that the signer is not necessarily the person sending an e-mail message since an e-mail message can be forwarded. The confusion stems from the phrases "who signed the email message" and "the person sending". Would "who signed the MIME calendar part" and "the SMTP message sender" be more accurate? I think that MIME allows each part to have a different signer, and I think the protocol anticipates having MIME parts separated from the original SMTP message and forwarded in a different SMTP message. If that's the case, the rephrasing would make sense to me. There is an obvious slippery slope in the iCal "sent-by" parameter. It conflicts with the "organizer". The receiver is left with a dilemna: to authenticate wrt to the "sent-by" entity, or to insist on a signature by the "organizer". It seems to me that the "organizer" could have signed the event (including the "sent-by" parameter) in advance and given the MIME parts to the sender, so there is no need to trust the "sent-by" entity. Or, the receiver could have a list of trusted <sent-by, organizer> proxies in its local security policy. But, in general, I think that an event signed by an unknown or untrusted party should be given no special considertion --- it is the same as receiving an unsigned event, and "sent-by" is as irrelevant as the SMTP sender. Hilarie
- [secdir] Security review of draft-ietf-calsify-rf… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-calsif… Alexey Melnikov
- Re: [secdir] Security review of draft-ietf-calsif… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-calsif… Alexey Melnikov