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

Alexey Melnikov <> Thu, 09 September 2010 08:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3995C3A6A36; Thu, 9 Sep 2010 01:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.362
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y-BnuUe+Phn6; Thu, 9 Sep 2010 01:25:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF02D3A677D; Thu, 9 Sep 2010 01:25:56 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Thu, 9 Sep 2010 09:26:22 +0100
Message-ID: <>
Date: Thu, 09 Sep 2010 09:26:07 +0100
From: Alexey Melnikov <>
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 <>
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Sep 2010 08:25:58 -0000

Hi Hilarie,

Hilarie Orman wrote:

>Comments inline.
>> From: Alexey Melnikov <>
>> 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.