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

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 2 Sep 2010 17:39:10 -0600

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.

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"
and "the SMTP message sender" be more accurate?  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.

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, 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.  Or, the receiver could have a list of
trusted <sent-by, organizer> proxies in its local security policy.
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.

Hilarie

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 05 Sep 2010 23:25:35 +0100

Hi Hilarie,

>WG chairs should treat these comments just like any other review
Thank you for your review.

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

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

>same as receiving an unsigned event, and "sent-by" is as irrelevant as
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

---

From: "Hilarie Orman" <[email-masked]>
Date: Wed, 8 Sep 2010 15:15:06 -0600

Comments inline.

>  From: Alexey Melnikov <[email-masked]>
>  Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10
>  Date: Sun, 05 Sep 2010 23:25:35 +0100

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

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

>     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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Sep 2010 09:26:07 +0100

Hi Hilarie,

>> Date: Sun, 05 Sep 2010 23:25:35 +0100
 [...]

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

>proxies in its local security policy."  
Ok, I will add. Thanks.

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