draft-ietf-calsify-rfc2447bis-10.txt   draft-ietf-calsify-rfc2447bis-11.txt 
INTERNET-DRAFT A. Melnikov INTERNET-DRAFT A. Melnikov
Document: draft-ietf-calsify-rfc2447bis-10.txt Editor Document: draft-ietf-calsify-rfc2447bis-11.txt Editor
Intended status: Standard Track July 27, 2010 Intended status: Standard Track September 10, 2010
Expires: January 2011 Expires: March 2011
iCalendar Message-Based Interoperability Protocol iCalendar Message-Based Interoperability Protocol
(iMIP) (iMIP)
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
skipping to change at page 5, line 32 skipping to change at page 5, line 32
The [RFC-5322] "Reply-To" header field typically contains the email The [RFC-5322] "Reply-To" header field typically contains the email
address of the originator of the scheduling message. However, this address of the originator of the scheduling message. However, this
cannot be guaranteed because the sender of the iMIP message might not cannot be guaranteed because the sender of the iMIP message might not
be the originator of the scheduling message and the sender's Mail be the originator of the scheduling message and the sender's Mail
User Agent (MUA) might not enforce iMIP semantics by translating the User Agent (MUA) might not enforce iMIP semantics by translating the
originator's address into the "Reply-To" email header field. originator's address into the "Reply-To" email header field.
2.1 MIME Media Type 2.1 MIME Media Type
A MIME entity containing content information formatted according to A MIME entity containing content information formatted according to
this document will be referenced as a "text/calendar" content type. this document will be referenced as a "text/calendar" content type
It is assumed that this content type will be transported through a [iCAL]. It is assumed that this content type will be transported
MIME electronic mail transport. through a MIME electronic mail transport.
2.2 Security 2.2 Security
This section addresses several aspects of security including This section addresses several aspects of security including
authentication, authorization and confidentiality. Authentication and authentication, authorization and confidentiality. Authentication and
confidentiality can be achieved using [RFC-1847] that specifies the confidentiality can be achieved using S/MIME [RFC-5750][RFC-5751],
Security Multiparts for MIME. This framework defines new content which uses Security Multiparts framework for MIME [RFC-1847].
types and subtypes of multipart: signed and encrypted. Each contains
two body parts: one for the protected data and another for the
control information necessary to remove the protection.
2.2.1 Authorization 2.2.1 Authorization
In [iTIP] messages, only the "Organizer" is authorized to modify or In [iTIP] messages, only the "Organizer" is authorized to modify or
cancel calendar entries she organizes. That is, spoof@xyz.example.net cancel calendar entries she organizes. That is, spoof@xyz.example.net
is not allowed to modify or cancel a meeting that was organized by is not allowed to modify or cancel a meeting that was organized by
a@example.com. Furthermore, only the respondent has the authorization a@example.com. Furthermore, only the respondent has the authorization
to indicate their status to the "Organizer". That is, the "Organizer" to indicate their status to the "Organizer". That is, the "Organizer"
must ignore an [iTIP] message from spoof@xyz.example.net that MUST ignore an [iTIP] message from spoof@xyz.example.net that
declines a meeting invitation for b@example.com. declines a meeting invitation for b@example.com.
Implementations of iMIP SHOULD verify the authenticity of the creator Implementations of iMIP SHOULD verify the authenticity of the creator
of an iCalendar object before taking any action. Methods for doing of an iCalendar object before taking any action. Methods for doing
this are presented later in this document. this are presented later in this document.
[RFC-1847] Message flow in iTIP supports someone working on behalf of [RFC-1847] Message flow in iTIP supports someone working on behalf of
a "Calendar User" through use of the "sent-by" parameter that is a "Calendar User" through use of the "sent-by" parameter that is
associated with the "ATTENDEE" and "ORGANIZER" properties. However, associated with the "ATTENDEE" and "ORGANIZER" properties. However,
there is no mechanism to verify whether or not a "Calendar User" has there is no mechanism to verify whether or not a "Calendar User" has
authorized someone to work on their behalf. It is left to authorized someone to work on their behalf. It is left to
implementations to provide mechanisms for the "Calendar Users" to implementations to provide mechanisms for the "Calendar Users" to
make that decision. make that decision.
2.2.2 Authentication 2.2.2 Authentication
Authentication can be performed using an implementation of [RFC-1847] Authentication MUST be performed using S/MIME [RFC-5750][RFC-5751].
"multipart/signed" that supports public/private key certificates.
Authentication is possible only on messages that have been signed. Authentication is possible only on messages that have been signed.
Authenticating an unsigned message may not be reliable. Unauthenticated messages (i.e., unsigned messages) may not be
trusted.
2.2.3 Confidentiality 2.2.3 Confidentiality
To ensure confidentiality using iMIP implementations should utilize To ensure confidentiality using iMIP implementations SHOULD utilize
encryption compliant with [RFC-1847]. The protocol does not restrict encryption specified in S/MIME [RFC-5750][RFC-5751]. iMIP does not
a "Calendar User Agent" (CUA) from forwarding iCalendar objects to restrict a "Calendar User Agent" (CUA) from forwarding iCalendar
other users or agents. objects to other users or agents.
2.3 Email Addresses 2.3 Email Addresses
The calendar address specified within the "ORGANIZER" and "ATTENDEE" The calendar address specified within the "ORGANIZER" and "ATTENDEE"
properties in an iCalendar object send using iMIP MUST be a proper properties in an iCalendar object send using iMIP MUST be a proper
"mailto:" [MAILTO] URI specification for the corresponding "mailto:" [MAILTO] URI specification for the corresponding
"Organizer" or "Attendee" of the "VEVENT" or "VTODO". "Organizer" or "Attendee" of the "VEVENT" or "VTODO".
Because [iTIP] does not preclude "Attendees" from forwarding Because [iTIP] does not preclude "Attendees" from forwarding
"VEVENTS" or "VTODOS" to others, the [RFC-5322] "Sender" value may "VEVENTS" or "VTODOS" to others, the [RFC-5322] "Sender" value may
not equal that of the "Organizer". Additionally, the "Organizer" or not equal that of the "Organizer". Additionally, the "Organizer" or
"Attendee" cannot be reliably inferred by the [RFC-5322] "Sender" or "Attendee" cannot be reliably inferred by the [RFC-5322] "Sender" or
"Reply-to" values of an iMIP message. The relevant address MUST be "Reply-to" header field values of an iMIP message. The relevant
ascertained by opening the "text/calendar" MIME body part and address MUST be ascertained by opening the "text/calendar" MIME body
examining the "ATTENDEE" and "ORGANIZER" properties. part and examining the "ATTENDEE" and "ORGANIZER" properties.
2.4 Content-Type Header Field 2.4 Content-Type Header Field
A MIME body part containing content information that conforms to this A MIME body part containing content information that conforms to this
document MUST have an [RFC-2045] "Content-Type" value of document MUST have an [RFC-2045] "Content-Type" value of
"text/calendar". The [RFC-2045] "Content-Type" header field MUST also "text/calendar". The [RFC-2045] "Content-Type" header field MUST also
include the type MIME parameter "method". The value MUST be the same include the type MIME parameter "method". The value MUST be the same
(ignoring case) as the value of the "METHOD" property within the (ignoring case) as the value of the "METHOD" property within the
iCalendar object. iCalendar object.
Note 1: A MIME message containing multiple iCalendar objects with Note 1: A MIME message containing multiple iCalendar objects with
different method values MUST be further encapsulated with a different method values MUST be further encapsulated with a
"multipart/mixed" MIME entity. This will allow each of the iCalendar "multipart/mixed" MIME entity [RFC-2046]. This will allow each of the
objects to be encapsulated within their own "text/calendar" MIME iCalendar objects to be encapsulated within their own "text/calendar"
entity. MIME entity.
Note 2: A MIME body part of "text/calendar" "Content-Type" that lacks Note 2: A MIME body part of "text/calendar" "Content-Type" that lacks
the "method" parameter is not considered to be an iMIP body part and the "method" parameter is not considered to be an iMIP body part and
thus is not subject to the requirements specified in this document. thus is not subject to the requirements specified in this document.
Note that according to [iCAL] the default character set for iCalendar Note that according to [iCAL] the default character set for iCalendar
objects is UTF-8 [UTF-8]. However the default character set for a objects is UTF-8 [UTF-8]. However the default character set for a
"text/*" MIME entity according to [RFC-2046] is US-ASCII. Thus a "text/*" MIME entity according to [RFC-2046] is US-ASCII. Thus a
"charset" MIME parameter MUST be present if the iCalendar object "charset" MIME parameter MUST be present if the iCalendar object
contains characters that can't be represented in US-ASCII character contains characters that can't be represented in US-ASCII character
skipping to change at page 7, line 39 skipping to change at page 7, line 36
The following is an example of this header field with a value that The following is an example of this header field with a value that
indicates an event message. indicates an event message.
Content-Type: text/calendar; method=request; charset=UTF-8; Content-Type: text/calendar; method=request; charset=UTF-8;
component=vevent component=vevent
The "text/calendar" content type allows for the scheduling message The "text/calendar" content type allows for the scheduling message
type to be included in a MIME message with other content information type to be included in a MIME message with other content information
(i.e., "multipart/mixed") or included in a MIME message with a clear- (i.e., "multipart/mixed") or included in a MIME message with a clear-
text, human-readable form of the scheduling message (i.e., text, human-readable form of the scheduling message (i.e.,
"multipart/alternative"). "multipart/alternative" [RFC-2046]).
In order to permit the information in the scheduling message to be In order to permit the information in the scheduling message to be
understood by MIME user agents (UA) that do not support the understood by MIME user agents (UA) that do not support the
"text/calendar" content type, scheduling messages SHOULD be sent with "text/calendar" content type, scheduling messages SHOULD be sent with
an alternative, human-readable form of the information. an alternative, human-readable form of the information.
Note that "multipart/alternative" MUST NOT be used to represent two Note that "multipart/alternative" MUST NOT be used to represent two
slightly different iCalendar objects, for example two VEVENT with slightly different iCalendar objects, for example two VEVENT with
alternative starting times. alternative starting times.
skipping to change at page 10, line 15 skipping to change at page 10, line 15
3 Security Considerations 3 Security Considerations
The security threats that applications must address when implementing The security threats that applications must address when implementing
iTIP are detailed in [iTIP]. In particular two spoofing threats are iTIP are detailed in [iTIP]. In particular two spoofing threats are
identified in [iTIP]: Spoofing the "Organizer", and Spoofing an identified in [iTIP]: Spoofing the "Organizer", and Spoofing an
"Attendee". To address these threats, the originator of an iCalendar "Attendee". To address these threats, the originator of an iCalendar
object must be authenticated by a recipient. Once authenticated, a object must be authenticated by a recipient. Once authenticated, a
determination can be made as to whether or not the originator is determination can be made as to whether or not the originator is
authorized to perform the requested operation. Compliant applications authorized to perform the requested operation. Compliant applications
MUST support signing and encrypting text/calendar body parts using a MUST support signing and encrypting text/calendar body parts using a
mechanism based on Security Multiparts for MIME [RFC-1847] to mechanism based on S/MIME [RFC-5750][RFC-5751] in order to facilitate
facilitate the authentication of the originator of the iCalendar the authentication of the originator of the iCalendar object (see
object. The steps for processing a signed iMIP message are described Section 2.2.2 and 2.2.3). The steps for processing a signed iMIP
below: message are described below:
1. Using the security mechanism compliant with [RFC-1847], determine 1. Using S/MIME, determine who signed the text/calendar body part
who signed the email message containing the iCalendar object. This is containing the iCalendar object. This is the "signer". (Note that
the "signer". Note that the signer is not necessarily the person the email address of the signer MUST be specified in the rfc822Name
sending an e-mail message since an e-mail message can be forwarded. field of the subject alternative name extension of the signer
certificate, as specified in [RFC-5280], Section 4.1.2.6.) Note that
the signer is not necessarily the person sending an e-mail message
since an e-mail message can be forwarded.
2. Correlate the signer to either an "ATTENDEE" property or to the 2. Correlate the signer to either an "ATTENDEE" property or to the
"ORGANIZER" property in the iCalendar object, based on the method and "ORGANIZER" property in the iCalendar object, based on the method and
the calendar component specified in the iCalendar object, as defined the calendar component specified in the iCalendar object, as defined
in Section 1.4 of [iTIP]. If the signer cannot be correlated to an in Section 1.4 of [iTIP]. If the signer cannot be correlated to an
"ATTENDEE"/"ORGANIZER" property, then actively warn the user "ATTENDEE"/"ORGANIZER" property, then actively warn the user
controlling the calendar user agent that the iCalendar object is controlling the calendar user agent that the iCalendar object is
untrusted and encourage the user to ignore the message, but give untrusted and encourage the user to ignore the message, but give
advanced users the option to (a) view the certificate of the signer advanced users the option to (a) view the certificate of the signer
and the entire certificate chain (if any) in order to help decide if and the entire certificate chain (if any) in order to help decide if
the signer should be trusted to send the message, and then (b) allow the signer should be trusted to send the message, and then (b) allow
CUA to accept and process the iCalendar object. CUA to accept and process the iCalendar object.
3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized 3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized
to perform the operation as defined by [iTIP]. If the conditions are to perform the operation as defined by [iTIP]. If the conditions are
not met, ignore the message. not met, ignore the message.
4. If all the above conditions are met, the message can be processed. 4. If all the above conditions are met, the message can be processed.
[RFC-1847] signing also protects against malicious changes in S/MIME signing also protects against malicious changes in transit.
transit.
If calendar confidentiality is required by the sender, signed iMIP If calendar confidentiality is required by the sender, signed iMIP
messages SHOULD be encrypted by a mechanism based on Security messages SHOULD be encrypted by a mechanism based on S/MIME
Multiparts for MIME [RFC-1847]. [RFC-5750][RFC-5751]. If iMIP is used within a single ADMD
(Administrative Domain) [RFC5598], SMTP STARTTLS [SMTP-TLS] (together
with STARTTLS in IMAP/POP [IMAP-POP-TLS]) MAY alternatively be used
to provide calendar confidentiality.
Once a signed and/or encrypted iMIP message is received and Once a signed and/or encrypted iMIP message is received and
successfully verified (as detailed above) by a CUA, the CUA SHOULD successfully verified (as detailed above) by a CUA, the CUA SHOULD
remember whether the sender of the message is using signing and/or remember whether the sender of the message is using signing and/or
encrypting. If an unsigned iMIP message is received from the same encrypting. If an unsigned iMIP message is received from the same
sender later on, the receiving CUA SHOULD warn the receiving user sender later on, the receiving CUA SHOULD warn the receiving user
about a possible man-in-the-middle attack and SHOULD ignore the about a possible man-in-the-middle attack and SHOULD ignore the
message, unless explicitly overridden by the user. message, unless explicitly overridden by the user.
Implementations MAY provide means for users to disable signing and Implementations MAY provide means for users to disable signing and
skipping to change at page 11, line 21 skipping to change at page 11, line 26
It is possible to receive iMIP messages sent by someone working on It is possible to receive iMIP messages sent by someone working on
behalf of another "Calendar User". This is determined by examining behalf of another "Calendar User". This is determined by examining
the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
property. [iCAL] and [iTIP] provide no mechanism to verify that a property. [iCAL] and [iTIP] provide no mechanism to verify that a
"Calendar User" has authorized someone else to work on their behalf. "Calendar User" has authorized someone else to work on their behalf.
To address this security issue, implementations MUST provide To address this security issue, implementations MUST provide
mechanisms for the "Calendar Users" to make that decision before mechanisms for the "Calendar Users" to make that decision before
applying changes from someone working on behalf of a "Calendar User". applying changes from someone working on behalf of a "Calendar User".
One way to achieve this is to reject iMIP messages sent by users One way to achieve this is to reject iMIP messages sent by users
other than the "ORGANIZER" or the "ATTENDEE"s. Another way is to other than the "ORGANIZER" or the "ATTENDEE"s. Alternatively, the
prompt the user for confirmation. receiver could have a list of trusted <sent-by, organizer> proxies in
its local security policy. And yet another way is to prompt the user
for confirmation.
iMIP based calendaring is frequently deployed within a single ADMD iMIP based calendaring is frequently deployed within a single ADMD,
(Administrative Domain) [RFC5598], with boundary filtering employed with boundary filtering employed to restrict email calendaring flows
to restrict email calendaring flows to be inside the ADMD. This can to be inside the ADMD. This can help in minimizing malicious changes
help in minimizing malicious changes to calendaring messages in to calendaring messages in transit, as well as in making
transit, as well as in making authorization decisions easier. authorization decisions less risky.
A security consideration associated with use of Content-Disposition A security consideration associated with use of Content-Disposition
header field is described in section 2.6. header field is described in section 2.6.
Use of S/MIME makes Security Considerations discussed in
[RFC-5750][RFC-5751] relevant to this document. For additional
Security Considerations regarding certificate and CRL verification
please see [RFC-5280].
4 Examples 4 Examples
4.1 Single Component With An ATTACH Property 4.1 Single Component With An ATTACH Property
This minimal message shows how an iCalendar object references an This minimal message shows how an iCalendar object references an
attachment. The attachment is accessible via its URL. attachment. The attachment is accessible via its URL.
From: sman@netscape.example.com From: sman@netscape.example.com
To: stevesil@microsoft.example.com To: stevesil@microsoft.example.com
Subject: Phone Conference Subject: Phone Conference
skipping to change at page 19, line 47 skipping to change at page 19, line 47
[RFC-2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC-2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[IMAP-POP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
2595, June 1999.
[RFC-5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750,
January 2010.
[RFC-5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC
5751, January 2010.
[RFC-5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 5280,
May 2008.
7.2 Informative References 7.2 Informative References
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
July 1994. July 1994.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
[RFC-3282] Alvestrand, H., "Content Language Headers", RFC 3282, May [RFC-3282] Alvestrand, H., "Content Language Headers", RFC 3282, May
skipping to change at page 22, line 36 skipping to change at page 22, line 36
Clarified handling of the "method" MIME parameter of the "Content- Clarified handling of the "method" MIME parameter of the "Content-
Type" header field. Type" header field.
Clarified that in an iMIP message an ORGANIZER/ATTENDEE property Clarified that in an iMIP message an ORGANIZER/ATTENDEE property
contains a mailto: URI. contains a mailto: URI.
Fixed examples with ATTENDEE property to use "CUTYPE=" instead of Fixed examples with ATTENDEE property to use "CUTYPE=" instead of
"TYPE=". "TYPE=".
Clarified that message integrity/confidentiality should be achieved
using S/MIME.
Additional examples. Additional examples.
Improved Security Considerations section. Improved Security Considerations section.
Multiple editorial changes to different sections of the document. Multiple editorial changes to different sections of the document.
Appendix B. Acknowledgements Appendix B. Acknowledgements
<<RFC Editor: feel free to move this section elsewhere.>> <<RFC Editor: feel free to move this section elsewhere.>>
 End of changes. 19 change blocks. 
45 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/