draft-ietf-calsify-rfc2447bis-04.txt   draft-ietf-calsify-rfc2447bis-05.txt 
INTERNET-DRAFT A. Melnikov INTERNET-DRAFT A. Melnikov
Document: draft-ietf-calsify-rfc2447bis-04.txt Editor Document: draft-ietf-calsify-rfc2447bis-05.txt Editor
Intended status: Standard Track May 12, 2008 Intended status: Standard Track June 9, 2008
Expires: November 2008 Expires: December 2008
iCalendar Message-Based Interoperability Protocol iCalendar Message-Based Interoperability Protocol
(iMIP) (iMIP)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
"multipart/mixed" MIME entity. This will allow each of the iCalendar "multipart/mixed" MIME entity. This will allow each of the iCalendar
objects to be encapsulated within their own "text/calendar" MIME objects to be encapsulated within their own "text/calendar" MIME
entity. 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 [RFC-2046] is US-ASCII. Thus a "charset" "text/*" MIME entity according to [RFC-2046] is US-ASCII. Thus a
parameter MUST be present if the iCalendar object contains characters "charset" parameter MUST be present if the iCalendar object contains
that are not part of the US-ASCII character set. [RFC-2046] discusses characters that can't be represented in US-ASCII character set.
the selection of an appropriate "charset" value. [RFC-2046] discusses the selection of an appropriate "charset" value.
The optional "component" parameter defines the iCalendar component The optional "component" parameter defines the iCalendar component
type contained within the iCalendar object. type contained within the iCalendar object.
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
skipping to change at page 8, line 14 skipping to change at page 8, line 14
process "text/calendar" body parts enclosed within "multipart/*". process "text/calendar" body parts enclosed within "multipart/*".
Note that a "multipart/mixed" MIME message can include multiple Note that a "multipart/mixed" MIME message can include multiple
"text/calendar" components. The receiving UA MUST be able to process "text/calendar" components. The receiving UA MUST be able to process
all of them. all of them.
2.5 Content-Transfer-Encoding 2.5 Content-Transfer-Encoding
Unless iMIP message is transported over 8-bit clean transport (such Unless iMIP message is transported over 8-bit clean transport (such
as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or
base64 [RFC-2045] MUST be used for iCalendar objects containing any base64 [RFC-2045] MUST be used for iCalendar objects containing any
characters that are not part of the US-ASCII character set. characters that can't be represented in the US-ASCII character set.
For example:
<<Add examples of 8bit and quoted-printable>> From: user1@example.com To: user2@example.com Subject: Phone
Conference Mime-Version: 1.0 Date: Wed, 07 May 2008 21:30:25 +0400
Message-ID: <4821E731.5040506@laptop1.example.com> Content-Type:
text/calendar; method=REQUEST; charset=UTF-8 Content-Transfer-
Encoding: quoted-printable
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST
VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:user1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
DTSTAMP:20080507T170000Z DTSTART:20080701T160000Z
DTEND:20080701T163000Z SUMMARY:Phone call to discuss your last visit
DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=
=B2=D0=BE=D0=BB=D0=B5=D0=BD
=D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0=BE=D0=
=B9? UID:calsvr.example.com-8739701987387998 SEQUENCE:0
STATUS:TENTATIVE END:VEVENT END:VCALENDAR
2.6 Content-Disposition 2.6 Content-Disposition
Implementations MAY include a "Content-Disposition" header field to Implementations MAY include a "Content-Disposition" header field to
define a file name for an iCalendar object. However, the handling of define a file name for an iCalendar object. However, the handling of
a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on
the extension specified in the "Content-Disposition", as different the extension specified in the "Content-Disposition", as different
email malware is known to trick User Agents into misinterpreting email malware is known to trick User Agents into misinterpreting
content of messages by specifying a file extension in the Content- content of messages by specifying a file extension in the Content-
Disposition header field that doesn't correspond to the value of Disposition header field that doesn't correspond to the value of
Content-Type header field. Content-Type header field.
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]. Two spoofing threats are identified: iTIP are detailed in [iTIP]. In particular two spoofing threats are
Spoofing the "Organizer", and Spoofing an "Attendee". To address identified in [iTIP]: Spoofing the "Organizer", and Spoofing an
these threats, the originator of an iCalendar object must be "Attendee". To address these threats, the originator of an iCalendar
authenticated by a recipient. Once authenticated, a determination can object must be authenticated by a recipient. Once authenticated, a
be made as to whether or not the originator is authorized to perform determination can be made as to whether or not the originator is
the requested operation. Compliant applications MUST support signing authorized to perform the requested operation. Compliant applications
and encrypting text/calendar attachments using a mechanism based on MUST support signing and encrypting text/calendar body parts using a
Security Multiparts for MIME [RFC-1847] to facilitate the mechanism based on Security Multiparts for MIME [RFC-1847] to
authentication the originator of the iCalendar object. facilitate the authentication of the originator of the iCalendar
Implementations MAY provide a means for users to disable signing and object. The steps for processing a signed iMIP message are described
encrypting. The steps are described below: below:
1. The iCalendar object MUST be signed by the "Organizer" sending an 1. The iCalendar object MUST be signed by the "Organizer" sending an
update or the "Attendee" sending a reply. update/initial request or the "Attendee" sending a reply. <<Or the
person sending on their behalf? Clearly if somebody else is sending
the invitation, she can't sign using the key belonging to the
organizer>>
2. Using the security mechanism compliant with [RFC-1847], determine 2. Using the security mechanism compliant with [RFC-1847], determine
who signed the iCalendar object. This is the "signer". Note that the who signed the iCalendar object. This is the "signer". Note that the
signer is not necessarily the person sending an e-mail message since signer is not necessarily the person sending an e-mail message since
an e-mail message can be forwarded. an e-mail message can be forwarded.
3. Correlate the signer to an "ATTENDEE" property in the iCalendar 3. Correlate the signer to either an "ATTENDEE" property or to the
object. If the signer cannot be correlated to an "ATTENDEE" property, "ORGANIZER" property in the iCalendar object, based on the method and
ignore the message. the calendar component specified in the iCalendar object, as defined
in Section 3 of [iTIP]. If the signer cannot be correlated to an
"ATTENDEE"/"ORGANIZER" property (or is not authorized to act on her
behalf), ignore the message.
4. Determine whether or not the "ATTENDEE" is authorized to perform 4. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized
the operation as defined by [iTIP]. If the conditions are not met, to perform the operation as defined by [iTIP]. If the conditions are
ignore the message. not met, ignore the message.
5. If all the above conditions are met, the message can be processed. 5. If all the above conditions are met, the message can be processed.
To address the confidentiality security threats, signed iMIP messages [RFC-1847] signing also protects against malicious changes in
SHOULD be encrypted by a mechanism based on Security Multiparts for transit.
MIME [RFC-1847].
If calendar confidentiality is required by the sender, signed iMIP
messages SHOULD be encrypted by a mechanism based on Security
Multiparts for MIME [RFC-1847].
Once a signed and/or encrypted iMIP message is received and
successfully verified (as detailed above) by a CUA, the CUA SHOULD
remember whether the sender of the message is using signing and/or
encrypting. If an unsigned iMIP message is received from the same
sender later on, the receiving CUA SHOULD warn the user about a
possible man-in-the-middle attack and SHOULD ignore the message,
unless explicitly overriden by the user. <<Should it also try to
notify the other end?>>
Implementations MAY provide means for users to disable signing and
encrypting.
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
other than the "ORGANIZER" or the "ATTENDEE"s.
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.
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.
skipping to change at page 21, line 25 skipping to change at page 22, line 25
the calendar object is known to be transferred over 8-bit clean the calendar object is known to be transferred over 8-bit clean
transport. transport.
Clarified that file extension specified in the Content-Disposition Clarified that file extension specified in the Content-Disposition
header field is not to be used to override the Content-Type MIME header field is not to be used to override the Content-Type MIME
type. type.
Disallow use of "multiple/alternative" for slightly different Disallow use of "multiple/alternative" for slightly different
representations of the same calendar. representations of the same calendar.
Fixed examples with ATTENDEE property to use CUTYPE= instead of TYPE= Fixed examples with ATTENDEE property to use "CUTYPE=" instead of
"TYPE=".
Various editorial changes to the Security Considerations section.
<<TBD>> <<TBD>>
 End of changes. 11 change blocks. 
31 lines changed or deleted 74 lines changed or added

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