From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5028.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc5028.txt (limited to 'doc/rfc/rfc5028.txt') diff --git a/doc/rfc/rfc5028.txt b/doc/rfc/rfc5028.txt new file mode 100644 index 0000000..addf9d5 --- /dev/null +++ b/doc/rfc/rfc5028.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group R. Mahy +Request for Comments: 5028 Plantronics +Category: Standards Track October 2007 + + + A Telephone Number Mapping (ENUM) Service Registration for + Instant Messaging (IM) Services + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document registers a Telephone Number Mapping (ENUM) service for + Instant Messaging (IM). Specifically, this document focuses on + provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. + +1. Introduction + + ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS + (Domain Name Service, RFC 1034 [2]) to translate telephone numbers, + such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC + 3986 [3]), such as 'im: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. + + Instant Messaging (IM) is a service defined in RFC 2778 [6] that + allows users to send and receive typically short, often textual + messages in near real-time. The IETF has defined a generic URI used + to identify an IM service for a particular resource: the 'im:' URI + scheme (defined in RFC 3861 [4]). RFC 3861 [4] also defines rules + for discovering service running specific protocols, such as SIP (the + Session Initiation Protocol, RFC 3261 [8]) and XMPP (the eXtensible + Messaging and Presence Protocol, RFC 3921 [9]) from a specific 'im:' + URI. + + RFC 3953 [10] already defines an enumservice for presence services, + which returns 'pres:' URIs (also defined in RFC 3861 [4]). This + document registers an enumservice for advertising IM information + associated with an E.164 number. + + + + + + +Mahy Standards Track [Page 1] + +RFC 5028 IM Enumservice October 2007 + + +2. ENUM Service Registration - im + + As defined in RFC 3761 [1], the following is a template covering + information needed for the registration of the enumservice specified + in this document: + + Enumservice Name: + "im" + Enumservice Type: + "im" + Enumservice Subtypes: + N/A + URI scheme(s): + "im:" + Functional Specification: + This Enumservice indicates that the resource identified is an + 'im:' URI. The 'im:' URI scheme does not identify any particular + protocol that will be used to handle instant messaging receipt or + delivery, rather the mechanism in RFC 3861 [4] is used to discover + whether an IM protocol supported by the party querying ENUM is + also supported by the target resource. + Security considerations: + See section 3. + Intended usage: + COMMON + Author: + Rohan Mahy (rohan@ekabal.com) + +3. 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 an 'im:' 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 [11]. + Many of these problems are prevented when the resolver verifies the + + + +Mahy Standards Track [Page 2] + +RFC 5028 IM Enumservice October 2007 + + + authenticity of answers to its ENUM queries via DNSSEC [5] in zones + where it is available. + + More serious security concerns are associated with potential attacks + against an underlying Instant Messaging system (for example, message + forgery and tampering). For this reason, IM protocols have a number + of security requirements (detailed in RFC 2779 [7]) that call for + authentication, integrity and confidentiality properties, and similar + measures to prevent such attacks. Any instant messaging protocol + used in conjunction with the 'im:' URI scheme is required to meet + these requirements. + + Unlike a traditional telephone number, the resource identified by an + 'im:' URI may require that callers provide cryptographic credentials + for authentication and authorization before instant messages are + exchanged. In concert with instant messaging protocols, ENUM can + actually provide far greater protection from unwanted callers than + does the existing PSTN, despite the public availability of ENUM + records. + +4. IANA Considerations + + This document requests registration of the "im" Enumservice according + to the definitions in this document and RFC 3761 [1]. + +5. References + +5.1. Normative References + + [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource + Identifiers (URI) Dynamic Delegation Discovery System (DDDS) + Application (ENUM)", RFC 3761, April 2004. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, + January 2005. + + [4] Peterson, J., "Address Resolution for Instant Messaging and + Presence", RFC 3861, August 2004. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + + + + +Mahy Standards Track [Page 3] + +RFC 5028 IM Enumservice October 2007 + + +5.2. Informative References + + [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence + and Instant Messaging", RFC 2778, February 2000. + + [7] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant + Messaging / Presence Protocol Requirements", RFC 2779, February + 2000. + + [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [9] Saint-Andre, P., Ed., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", RFC 3921, + October 2004. + + [10] Peterson, J., "Telephone Number Mapping (ENUM) Service + Registration for Presence Services", RFC 3953, January 2005. + + [11] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + +Author's Address + + Rohan Mahy + Plantronics + + EMail: rohan@ekabal.com + + + + + + + + + + + + + + + + + + + + + + +Mahy Standards Track [Page 4] + +RFC 5028 IM Enumservice October 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + + + + + + + + + + + +Mahy Standards Track [Page 5] + -- cgit v1.2.3