Last Call Review of draft-ietf-calsify-rfc2447bis-
review-ietf-calsify-rfc2447bis-secdir-lc-orman-2010-09-05-00

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