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

["Hilarie Orman" <[e-mail]>]

Comments inline.

>  From: Alexey Melnikov <[e-mail]>
>  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