iCalendar Transport-Independent Interoperability Protocol (iTIP)
RFC 5546
| Document | Type |
RFC
- Proposed Standard
(December 2009)
Errata
Updated by RFC 6638
Obsoletes RFC 2446
Updates RFC 5545
|
|
|---|---|---|---|
| Author | Cyrus Daboo | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Lisa M. Dusseault | |
| Send notices to | (None) |
RFC 5546
quot;VTODO", or "VJOURNAL" calendar component and republish it or redistribute updates to the "Attendees". An iCalendar object that maliciously changes or cancels an existing "VEVENT", "VTODO", or "VJOURNAL" calendar component may be constructed by someone other than the "Organizer" and republished or sent to the "Attendees". 6.1.2. Spoofing the Attendee In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component (or someone working on the "Attendee's" behalf) is the only person authorized to update any parameter associated with their "ATTENDEE" Daboo Standards Track [Page 124] RFC 5546 iTIP December 2009 property and send it to the "Organizer". An iCalendar object that maliciously changes the "ATTENDEE" parameters may be constructed by someone other than the real "Attendee" and sent to the "Organizer". 6.1.3. Unauthorized Replacement of the Organizer There will be circumstances when "Attendees" of an event or to-do decide, using out-of-band mechanisms, that the "Organizer" must be replaced. When the new "Organizer" sends out the updated "VEVENT" or "VTODO", the "Attendee's" CUA will detect that the "Organizer" has been changed, but it has no way of knowing whether or not the change was mutually agreed upon. 6.1.4. Eavesdropping and Data Integrity The iCalendar object is constructed with human-readable clear text. Any information contained in an iCalendar object may be read and/or changed by unauthorized persons while the object is in transit. 6.1.5. Flooding a Calendar Implementations could provide a means to automatically incorporate "REQUEST" methods into a calendar. This presents the opportunity for a calendar to be flooded with requests, which effectively blocks all the calendar's free time. 6.1.6. Unauthorized REFRESH Requests It is possible for an "Organizer" to receive a "REFRESH" request from someone who is not an "Attendee" of an event or to-do. Only "Attendees" of an event or to-do are authorized to receive replies to "REFRESH" requests. Replying to such requests to anyone who is not an "Attendee" may be a security problem. 6.2. Recommendations For an application where the information is sensitive or critical and the network is subject to a high probability of attack, iTIP transactions SHOULD be encrypted and authenticated. This helps mitigate the threats of spoofing, eavesdropping, and malicious changes in transit. 6.2.1. Securing iTIP transactions iTIP transport bindings MUST provide a mechanism to enable authentication of the sender's identity as well as privacy and integrity of the data being transmitted. This allows the receiver of a signed iCalendar object to verify the identity of the sender. This Daboo Standards Track [Page 125] RFC 5546 iTIP December 2009 sender may then be correlated to an "ATTENDEE" property in the iCalendar object. If the correlation is made and the sender is authorized to make the requested change or update, then the operation may proceed. It also allows the message to be encrypted to prevent unauthorized reading of the message contents in transit. iTIP transport binding documents describe this process in detail. 6.2.2. Implementation Controls The threat of unauthorized replacement of the "Organizer" SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that make "Calendar Users" aware of such "Organizer" changes and allowing them to decide whether or not the request should be honored. The threat of flooding a calendar SHOULD be mitigated by a calendar system that uses this protocol by providing controls that may be used to limit the acceptable sources for iTIP transactions, and perhaps the size of messages and volume of traffic, by source. The threat of unauthorized "REFRESH" requests SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that allow "Calendar Users" to decide whether or not the request should be honored. An implementation MAY decide to maintain, for audit or historical purposes, "Calendar Users" who were part of an "Attendee" list and who were subsequently uninvited. Similar controls or alerts should be provided when a "REFRESH" request is received from these "Calendar Users" as well. 6.2.3. Access Controls and Filtering In many environments, there could be restrictions on who is allowed to schedule with whom and who the allowed delegates are for particular "Calendar Users". iTIP transport bindings SHOULD provide mechanisms for implementing access controls or filtering to ensure iTIP transactions only take place between authorized "Calendar Users". That would include preventing one "Calendar User" from scheduling with another or one "Calendar User" delegating to another. 6.3. Privacy Issues The "Organizer" might want to keep "Attendees" from knowing which other "Attendees" are participating in an event or to-do. The "Organizer" has the choice of sending single iTIP messages with a full list of "Attendees" or sending iTIP messages to each "Attendee" with only that "Attendee" listed. Daboo Standards Track [Page 126] RFC 5546 iTIP December 2009 7. IANA Considerations 7.1. Registration Template for REQUEST-STATUS Values This specification updates [RFC5545] by adding a "REQUEST-STATUS" value registry to the iCalendar Elements registry. A "REQUEST-STATUS" value is defined by completing the following template. Status Code: Hierarchical, numeric return status code, following the rules defined in Section 3.8.8.3 of [RFC5545]. Status Description: Textual status description. A short but clear description of the error. Status Exception Data: Textual exception data. A short but clear description of what might appear in this field. Description: Describe the underlying cause for this status code value. 7.2. Additions to iCalendar METHOD Registry This document defines the following values for the iCalendar "METHOD" property, using the values template from Section 8.2.6 of [RFC5545]. These should be added to the Methods Registry defined in Section 8.3.12 of [RFC5545]: 7.2.1. METHOD:PUBLISH Value: PUBLISH Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.2. METHOD:REQUEST Value: REQUEST Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. Daboo Standards Track [Page 127] RFC 5546 iTIP December 2009 7.2.3. METHOD:REPLY Value: REPLY Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.4. METHOD:ADD Value: ADD Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.5. METHOD:CANCEL Value: CANCEL Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.6. METHOD:REFRESH Value: REFRESH Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.7. METHOD:COUNTER Value: COUNTER Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Daboo Standards Track [Page 128] RFC 5546 iTIP December 2009 Examples: See this RFC. 7.2.8. METHOD:DECLINECOUNTER Value: DECLINECOUNTER Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.3. REQUEST-STATUS Value Registry New "REQUEST-STATUS" values can be registered using the process described in Section 8.2.1 of [RFC5545]. The following table is to be used to initialize the "REQUEST-STATUS" value registry. Daboo Standards Track [Page 129] RFC 5546 iTIP December 2009 +-------------+---------+--------------------------+ | Status Code | Status | Reference | +-------------+---------+--------------------------+ | 2.0 | Current | RFC 5546, Section 3.6.1 | | 2.1 | Current | RFC 5546, Section 3.6.2 | | 2.2 | Current | RFC 5546, Section 3.6.3 | | 2.3 | Current | RFC 5546, Section 3.6.4 | | 2.4 | Current | RFC 5546, Section 3.6.5 | | 2.5 | Current | RFC 5546, Section 3.6.6 | | 2.6 | Current | RFC 5546, Section 3.6.7 | | 2.7 | Current | RFC 5546, Section 3.6.8 | | 2.8 | Current | RFC 5546, Section 3.6.9 | | 2.9 | Current | RFC 5546, Section 3.6.10 | | 2.10 | Current | RFC 5546, Section 3.6.11 | | 2.11 | Current | RFC 5546, Section 3.6.12 | | 3.0 | Current | RFC 5546, Section 3.6.13 | | 3.1 | Current | RFC 5546, Section 3.6.14 | | 3.2 | Current | RFC 5546, Section 3.6.15 | | 3.3 | Current | RFC 5546, Section 3.6.16 | | 3.4 | Current | RFC 5546, Section 3.6.17 | | 3.5 | Current | RFC 5546, Section 3.6.18 | | 3.6 | Current | RFC 5546, Section 3.6.19 | | 3.7 | Current | RFC 5546, Section 3.6.20 | | 3.8 | Current | RFC 5546, Section 3.6.21 | | 3.9 | Current | RFC 5546, Section 3.6.22 | | 3.10 | Current | RFC 5546, Section 3.6.23 | | 3.11 | Current | RFC 5546, Section 3.6.24 | | 3.12 | Current | RFC 5546, Section 3.6.25 | | 3.13 | Current | RFC 5546, Section 3.6.26 | | 3.14 | Current | RFC 5546, Section 3.6.27 | | 4.0 | Current | RFC 5546, Section 3.6.28 | | 5.0 | Current | RFC 5546, Section 3.6.29 | | 5.1 | Current | RFC 5546, Section 3.6.30 | | 5.2 | Current | RFC 5546, Section 3.6.31 | | 5.3 | Current | RFC 5546, Section 3.6.32 | +-------------+---------+--------------------------+ 8. Acknowledgments This is an update to the original iTIP document authored by S. Silverberg, S. Mansour, F. Dawson, and R. Hopson. This revision is the product of the Calsify IETF Working Group, and several participants have made important contributions to this specification, including Oliver Block, Bernard Desruisseaux, Mike Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg II, Robert Ransdell, and Caleb Richardson. Daboo Standards Track [Page 130] RFC 5546 iTIP December 2009 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. 9.2. Informative References [iMIP] Melnikov, A., Ed., "iCalendar Message-Based Interoperability Protocol (iMIP)", Work in Progress, October 2009. Daboo Standards Track [Page 131] RFC 5546 iTIP December 2009 Appendix A. Differences from RFC 2446 A.1. Changed Restrictions This specification now defines an allowed combination of "REQUEST- STATUS" codes when multiple iCalendar components are included in an iTIP message. This specification now restricts "RECURRENCE-ID" to only a single occurrence in any one iCalendar component in an iTIP message, as required by [RFC5545]. Changed the "RECURRENCE-ID" entry in the component restriction table to "0 or 1" from "0+", to fall in line with [RFC5545]. Changed the "FREEBUSY" entry in the "VFREEBUSY", "PUBLISH", and "REPLY" restriction tables to "0+" from "1+", to fall in line with [RFC5545]. Changed the "FREEBUSY" description in the "VFREEBUSY" and "REPLY" restriction tables to indicate that different "FBTYPE" ranges MUST NOT overlap. Changed the "TZNAME" entry in the "VTIMEZONE" restriction table to "0+" from "0 or 1", to fall in line with [RFC5545]. Changed the "COMMENT" entry in the component restriction tables to "0+" from "0 or 1", to fall in line with [RFC5545]. Added the "ATTENDEE" entry in the "VALARM" restriction table to match the email alarm type in [RFC5545]. Changed the "CATEGORIES" entry in the component restriction tables to "0+" from "0 or 1", to fall in line with [RFC5545]. Changed the "RESOURCES" entry in the component restriction tables to "0+" from "0 or 1", to fall in line with [RFC5545]. Changed the "CONTACT" entry in the "VFREEBUSY" restriction table to "0 or 1" from "0+", to fall in line with [RFC5545]. Changed the "UID" entry in the "VFREEBUSY" and "PUBLISH" restriction tables to "1" from "0", to fall in line with [RFC5545]. Added the "COMPLETED" entry in the "VTODO" restriction tables to fall in line with [RFC5545]. Daboo Standards Track [Page 132] RFC 5546 iTIP December 2009 Added the "REQUEST-STATUS" entry in the "VJOURNAL" restriction tables to fall in line with [RFC5545]. A.2. Deprecated Features The "EXRULE" property was removed in [RFC5545] and references to that have been removed in this document too. The "PROCEDURE" value for the "ACTION" property was removed in [RFC5545] and references to that have been removed in this document too. The "THISANDPRIOR" option for the "RANGE" parameter was removed in [RFC5545] and references to that have been removed in this document too. Author's Address Cyrus Daboo (editor) Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/ Daboo Standards Track [Page 133]