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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 09 September 2010 08:25 UTC

Return-Path: <alexey.melnikov@isode.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 3995C3A6A36; Thu, 9 Sep 2010 01:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.362
X-Spam-Level:
X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Y-BnuUe+Phn6; Thu, 9 Sep 2010 01:25:57 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EF02D3A677D; Thu, 9 Sep 2010 01:25:56 -0700 (PDT)
Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TIiaLQBIEC4V@rufus.isode.com>; Thu, 9 Sep 2010 09:26:22 +0100
Message-ID: <4C889A1F.5010208@isode.com>
Date: Thu, 09 Sep 2010 09:26:07 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Hilarie Orman <hilarie@purplestreak.com>
References: <201009082115.o88LF62w032038@fermat.rhmr.com>
In-Reply-To: <201009082115.o88LF62w032038@fermat.rhmr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
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, 09 Sep 2010 08:25:58 -0000

Hi Hilarie,

Hilarie Orman wrote:

>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:
>>
 [...]

>> >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.
>
This is fairly obvious for somebody who knows details of how email 
works, but I can see this being confusing.

Would adding a reference [RFC5322] (email message format) help here?

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

>> >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."  
>
Ok, I will add. Thanks.

>>    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".
>
Ok, will change.

>Also, that paragraph sounds like a RECOMMENDATION.
>
It is, but, IMHO, not using normative language in this case is just fine.