[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, 2 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