A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services
draft-ietf-enum-calendar-service-04.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 11, 2008.

Abstract

This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.

1.  Introduction

ENUM (E.164 Number Mapping, RFC 3761 (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.) [RFC3761]) is a system that uses DNS (Domain Name Service, RFC 1034 (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [RFC1034]) to translate telephone numbers, such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]), such as 'mailto:user@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources. The ENUM registration here could be used to allow phones for example to check the free/busy status of a user in their address book or propose a meeting with him or her from the user's phone number.

The Guide to Internet Calendaring (Mahoney, B., Babics, G., and A. Taler, “Guide to Internet Calendaring,” June 2002.) [RFC3283] describes the relationship between various internet calendaring specifications like this: "iCalendar (Dawson, F. and Stenerson, D., “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” November 1998.) [RFC2445] is the language used to describe calendar objects. iTIP (Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, “iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries,” November 1998.) [RFC2446] [Transport-Independent Interoperability Protocol] describes a way to use the iCalendar language to do scheduling. iMIP (Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP),” November 1998.) [RFC2447] [Message-Based Interoperability Protocol] describes how to do iTIP scheduling via e-mail."

Recently another standard track protocol for calendar and scheduling access has appeared. CalDAV (Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV),” March 2007.) [RFC4791] (Calendaring Extensions to WebDAV) is a WebDAV (Dusseault, L., “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV),” June 2007.) [RFC4918] (Web-based Distributed Authoring and Versioning) based mechanism for manipulating internet calendars, viewing free/busy lists, and via a planned scheduling extension (Daboo, C. and B. Desruisseaux, “CalDAV Scheduling Extensions to WebDAV,” August 2009.) [I‑D.desruisseaux‑caldav‑sched], could be used for proposing calendar events as well.

The existing 'mailto:' URI scheme (defined in RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]) is already used to address iMIP compatible Calendar Services. Likewise the existing 'http:' and 'https:' URI schemes (defined in RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] and RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818]) are already used to address CalDAV compatible Calendar Services.

This document registers an enumservice for advertising internet calendaring information associated with an E.164 number, using the 'mailto:', 'http:', or 'https:' schemes.

2.  ENUM Service Registration - ical

As defined in RFC 3761 (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.) [RFC3761], the following is a template covering information needed for the registration of the enumservice specified in this document:

Enumservice Name:

"ical"

Enumservice Type:

"ical"

Enumservice Subtypes:

sched

URI scheme(s):

"mailto:", "http:", "https:"

Functional Specification:

This Enumservice indicates that the resource identified is a URI used for scheduling using Internet Calendaring. Supported URI schemes are the 'mailto:' URI for the iMIP (Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP),” November 1998.) [RFC2447] protocol, and 'http:' or 'https:' URIs for a planned scheduling extension (Daboo, C. and B. Desruisseaux, “CalDAV Scheduling Extensions to WebDAV,” August 2009.) [I‑D.desruisseaux‑caldav‑sched] to the CalDAV (Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV),” March 2007.) [RFC4791] protocol.

Security considerations:

See section 3.

Intended usage:

COMMON

Author:

Rohan Mahy (rohan@ekabal.com)

Enumservice Name:

"ical"

Enumservice Type:

"ical"

Enumservice Subtypes:

access

URI scheme(s):

"http:", "https:"

Functional Specification:

This Enumservice indicates that the resource identified is a URI used for Internet Calendaring which is available to access a user's calendar (for example free/busy status). Supported URI schemes are 'http:' or 'https:' URIs for the CalDAV (Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV),” March 2007.) [RFC4791] protocol.

Security considerations:

See section 3.

Intended usage:

COMMON

Author:

Rohan Mahy (rohan@ekabal.com)

3.  Example of Usage

Below is a set of sample resource records for this enumservice.

$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
@ NAPTR 10 100 "u" "E2U+ical:access"
  "!^.*$!http://cal.example.com/home/alice/calendars/!" .

$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa.
@ NAPTR 10 100 "u" "E2U+ical:sched"
  "!^.*$!mailto:alice@example.com!" .

4.  Security Considerations

The Domain Name System (DNS) does not make policy decisions about which records it provides to a DNS resolver. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered open to the public -- which is a cause for some privacy considerations.

Revealing a calendaring URI by itself is unlikely to introduce many privacy concerns, although, depending on the structure of the URI, it might reveal the full name or employer of the target. The use of anonymous URIs mitigates this risk.

As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the answer returned to a query is authentic. An analysis of threats specific to the dependence of ENUM on the DNS is provided in RFC 3761 and a thorough analysis of threats to the DNS itself is covered in RFC 3833 (Atkins, D. and R. Austein, “Threat Analysis of the Domain Name System (DNS),” August 2004.) [RFC3833]. Many of these problems are prevented when the resolver verifies the authenticity of answers to its ENUM queries via DNSSEC (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) [RFC4035] in zones where it is available.

More serious security concerns are associated with potential attacks against an underlying calendaring system (for example, unauthorized modification or viewing). For this reason, iTIP discusses a number of security requirements (detailed in RFC 2446 (Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, “iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries,” November 1998.) [RFC2446]) that call for authentication, integrity and confidentiality properties, and similar measures to prevent such attacks. Any calendaring protocol used in conjunction with a URI scheme currently meets these requirements. The use of CalDAV with the 'https:' scheme makes use of TLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) [RFC4346] (Transport Layer Security) to provide server authentication, confidentiality, and message integrity.

Unlike a traditional telephone number, the resource identified by an calendaring URI is often already guessable and often requires that users provide cryptographic credentials for authentication and authorization before calendar data can be exchanged. Despite the public availability of ENUM records, the use of this information to reveal an unprotected calendaring resource is unlikely in practice.

5.  IANA Considerations

This document requests registration of the "iCal" Enumservice according to the definitions in Section 2 (ENUM Service Registration - ical) of this document and RFC 3761 (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.) [RFC3761].

6.  References

6.1. Normative References

6.2. Informational References

Appendix A.  Acknowlegments

Thanks to Lisa Dusseault and Alexander Mayrhofer for reviewing this document.

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.