Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10

"Hilarie Orman" <hilarie@purplestreak.com> Wed, 08 September 2010 21:16 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 1C8EC3A69F3; Wed, 8 Sep 2010 14:16:34 -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 cjP5UEBb+D8J; Wed, 8 Sep 2010 14:16:31 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 0FC833A6980; Wed, 8 Sep 2010 14:16:30 -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 1OtS0o-0005ef-Cc; Wed, 08 Sep 2010 15:16:58 -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 1OtS0m-0005Nx-Jl; Wed, 08 Sep 2010 15:16:58 -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 o88LF7md032039; Wed, 8 Sep 2010 15:15:07 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o88LF62w032038; Wed, 8 Sep 2010 15:15:06 -0600
Date: Wed, 8 Sep 2010 15:15:06 -0600
Message-Id: <201009082115.o88LF62w032038@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
In-reply-to: Yourmessage <4C8418DF.6010703@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; sa02 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: Re: [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: Wed, 08 Sep 2010 21:16:34 -0000

Comments inline.

>  From: Alexey Melnikov <alexey.melnikov@isode.com>
>  Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10
>  Date: Sun, 05 Sep 2010 23:25:35 +0100

>  Hi Hilarie,

>  Hilarie Orman wrote:

>  >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.
>  >  
>  >
>  Thank you for your review.

>  >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"
>  >
>  Yes. I think saying "who signed the text/calendar body part ..." would 
>  be even better.

>  >and "the SMTP message sender" be more accurate?
>  >
>  Actually no. In general case SMTP message sender (i.e. the SMTP MAIL 
>  FROM value) has nothing to do with who is sending out the message (value 
>  of the message's Sender: header field). So this text is talking about 
>  the person associated with the Sender header field.

In the text above, you need to say which protocol the "Sender header
field" is associated with.  Your text speaks of e-mail and forwarding,
thus my assumption that your caveat applied to the SMTP sender.  Help out
the reader by being explicit.

>  >  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.
>  >  
>  >
>  I would prefer to do the first change and not do anything about the second.

>  >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,
>  >
>  I think this is the only viable option the way how calendaring and email 
>  is done today.

>  >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.
>  >
>  Delegation doesn't currently work this way and I don't think this is 
>  likely to change. When "sent-by" is used the organizer delegates all 
>  handling (out-of-band or using some kind of authorization) to another 
>  person. The organizer is not involved in creating the event. Think of 
>  this as a case when a boss tells her secretary to organize a meeting. 
>  The boss is not going to create the meeting event, sign it and send it 
>  to the secretary. If the boss does it, there is no reason to use 
>  "sent-by" at all, as the calendar event can be just sent out by the boss.

>  >Or, the receiver could have a list of
>  >trusted <sent-by, organizer> proxies in its local security policy.
>  >
>  This is more likely. For example if the organizer and the receiver are 
>  in the same organization.

>  Or the receiver can phone the organizer and ask if this was truly 
>  authorized (out-of-band verification).

>  >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.
>  >
>  In absence of any other information about organizer authorizing the 
>  "sent-by", I agree.
>  But I think the existing text on this is adequate:

>     It is possible to receive iMIP messages sent by someone working on
>     behalf of another "Calendar User". This is determined by examining
>     the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
>     property.  [iCAL] and [iTIP] provide no mechanism to verify that a
>     "Calendar User" has authorized someone else to work on their behalf.
>     To address this security issue, implementations MUST provide
>     mechanisms for the "Calendar Users" to make that decision before
>     applying changes from someone working on behalf of a "Calendar User".
>     One way to achieve this is to reject iMIP messages sent by users
>     other than the "ORGANIZER" or the "ATTENDEE"s.

>  This covers the case "treat as untrusted".

>     Another way is to
>     prompt the user for confirmation.

This is where I would add the previously recommended text:
"Or, the receiver could have a list of trusted <sent-by, organizer>
proxies in its local security policy."  

>     iMIP based calendaring is frequently deployed within a single ADMD
>     (Administrative Domain) [RFC5598], with boundary filtering employed
>     to restrict email calendaring flows to be inside the ADMD. This can
>     help in minimizing malicious changes to calendaring messages in
>     transit, as well as in making authorization decisions easier.

I'd say the decisions are not "easier" but "less risky".  Also, that
paragraph sounds like a RECOMMENDATION.

Hilarie