Network Working Group B. Campbell Internet-Draft dynamicsoft Expires: October 31, 2002 May 2, 2002 Requirements for Binding Published Data to SIP Services draft-campbell-pub-bind-reqs-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 31, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract A growing number of SIP based services depend on the idea that clients may publish service-related information to network elements. This information may then affect further processing of the service. Examples of such services include presence and CPL. Multiple protocols may exists for the actual publication of such data. But regardless of the protocol, a client must know where to send it. This document describes requirements for a mechanism to inform clients where and how to publish service related information. Campbell Expires October 31, 2002 [Page 1] Internet-Draft Service Data Binding Requirements May 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope of This Document . . . . . . . . . . . . . . . . . . . . 3 3. Publication Mechanism Assumptions . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Publication URI . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Publication Mechanism . . . . . . . . . . . . . . . . . . . . 4 4.3 Address of Record . . . . . . . . . . . . . . . . . . . . . . 4 4.4 Enumeration of Services . . . . . . . . . . . . . . . . . . . 4 4.5 Lifetime of Publication URIs . . . . . . . . . . . . . . . . . 5 4.6 Communication of Publication URIs . . . . . . . . . . . . . . 5 4.7 Separate publication points . . . . . . . . . . . . . . . . . 5 4.8 Publication URIs that are not easily guessable . . . . . . . . 5 4.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 Campbell Expires October 31, 2002 [Page 2] Internet-Draft Service Data Binding Requirements May 2002 1. Introduction A growing number of SIP [1] related services depend on client publication of some form of service data to network elements. This data is then either distributed as part of the service, or affect the processing of the service in some way. Examples include SIMPLE [3], where a client may publish a presence document to a remote Presence Agent which distributes the document to presence watchers. Another example is the Call Processing Language [2], where users may publish CPL scripts to SIP registrars. The actual mechanisms for such publications are somewhat controversial. There is general agreement in the SIP and SIPPING working groups that the SIP REGISTER method is not adequate to the task. To a lesser degree, there has been agreement that the publication mechanism should not be SIP at all. There is, however, no consensus as to what the publication mechanism should be, or that a single mechanism makes sense in all situations. Regardless of the publication mechanism or mechanisms chosen, clients will require a way to determine where to send such service data, and to bind that data to a particular service element or resource. This is essentially a matter of client configuration, and could conceivably handled through provisioning; however such a provisioning effort would likely become prohibitively complex for large installations. 2. Scope of This Document This document discusses requirements for a service data binding mechanism. It does not propose a mechanism for realizing those requirements. It does not attempt to address requirements or mechanism for the actual publication of service data. We make only a few very basic assumptions about such mechanisms. 3. Publication Mechanism Assumptions We assume any service data publication mechanism or mechanisms will use a URI based addressing scheme. It is possible that the mechanism will not use URIs natively in its internal addressing scheme, but it will be possible to express such addresses in terms of URIs externally to the mechanism. For example, FTP does not natively use URIs, but there exists an FTP URI scheme that can be used to express the combination of an FTP server and a location in its file system. We assume that more than one publication mechanism will exist, and Campbell Expires October 31, 2002 [Page 3] Internet-Draft Service Data Binding Requirements May 2002 that a single service may actually use multiple mechanisms. We assume the existence of mechanisms which directly push service data to the publication points, as well as mechanisms where a client tells a service a URI where it can find the service data. (It is interesting to notice that indirect publication is also a type of binding operation and may have requirements similar to those in this document.) 4. Requirements This section describes the requirements that are known at the time of this draft. Requirement discussion is still underway in the SIPPING working group. This document attempts to capture the requirements discussed so far. 4.1 Publication URI The binding mechanism MUST allow a client to discover or infer a URI, or set of URIs, to which data may be published for a particular service. The mechanism MUST allow for any URI scheme, and MUST NOT make assumptions about how a specific publication mechanism interprets URIs. 4.2 Publication Mechanism The binding mechanism MUST allow a client to discover or infer the mechanism, or set of mechanisms, to use to publish data to a particular publication URI. 4.3 Address of Record The binding mechanism MUST allow clients to determine binding information based only on knowledge of an AoR. A client MAY allow provisioning of individual service publication bindings for an AoR. The binding mechanism MUST allow for multiple data-driven services for a single AoL, and MUST allow the client to distinguish one such service from another for publication purposes. (For example, the AoR "sip:alice@example.com" may have both presence and CPL services associated with it. A client must be able to avoid sending CPL to the presence service, or a presence document to the CPL services.) 4.4 Enumeration of Services The binding mechanism SHOULD offer a way for a client to determine a list of all services for a given AoR for which it can publish data. Campbell Expires October 31, 2002 [Page 4] Internet-Draft Service Data Binding Requirements May 2002 4.5 Lifetime of Publication URIs The binding mechanism MUST allow a service element to manage the lifetime of a publication URI. It MUST allow long-lived publication URIs. It MAY also allow very short-lived publication URIs; for example, the URI may be single-use only. 4.6 Communication of Publication URIs The binding mechanism MUST allow a service provider to communicate publication URIs to a client, directly or through a third party. For example the client might directly query a service element, or query a directory service. The mechanism MAY also provide a method for a client to infer publication URIs from an AoR without directly contacting the service elements, for example by using an algorithmic transformation, schema mapping, or the DNS. 4.7 Separate publication points The mechanism MUST NOT require all publication URIs for a given AoR to share the same host, address, or even domain. The mechanism MUST NOT require the publication point for a data-driven service to be colocated with the network element(s) that provide the service itself. 4.8 Publication URIs that are not easily guessable The binding mechanism SHOULD allow the use of publication URIs that are not easily guessable. 4.9 Security The binding mechanism MUST allow a client to authenticate the source of a publication URI. The mechanism MAY allow a publication URI provider to authenticate clients. The mechanism MUST allow a client to ensure that publication URIs have not been tampered with. 5. Security Considerations We make the working assumption that service publication bindings are somewhat public knowledge. This document does not contain strong requirements for confidential transmission of bindings. On the contrary, algorithmic transformations, DNS approaches, etc. could cause such bindings to be completely public. The service data to be published may, on the other hand, be very sensitive. Security of published data is in general an aspect of the publication method, and is out of scope for this document. But it is Campbell Expires October 31, 2002 [Page 5] Internet-Draft Service Data Binding Requirements May 2002 very important that a client can determine that a publication binding comes from a known source, and has not been tampered with. Otherwise, it would be possible for an attacker to provide a false binding, and trick a client into publishing potentially sensitive data to an unauthorized party. 6. Acknowledgements Robert Sparks, Adam Roach, Sean Olson, Henning Schulzrinne, Jonathan Rosenburg, and James Undery all contributed substantially to the discussion about this subject. References [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), February 2002. [2] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000. [3] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for Presence", draft-ietf-simple-presence-06 (work in progress), April 2002. Author's Address Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: bcampbell@dynamicsoft.com Campbell Expires October 31, 2002 [Page 6] Internet-Draft Service Data Binding Requirements May 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Campbell Expires October 31, 2002 [Page 7]