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

[Alexey Melnikov <[e-mail]>]

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.

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

   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.

Please let me know if you think that some other text needs to be added, or that the quoted text needs to be modified.


Regards,
Alexey