IETF RESCAP WG G. Klyne, MIMEsweeper Group Internet draft 9 January 2002 Expires: July 2002 RESCAP Scenarios Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society 2002. All Rights Reserved. Abstract This memo explores some scenarios for the resource capabaility discovery protocol (RESCAP). It is intended to provide some grounding in specific use-cases for decisions about RESCAP goals and design. Klyne Internet draft [Page 1] RESCAP Scenarios 9 January 200 Table of contents 1. Introduction.............................................3 1.1 Structure of this document ...........................3 1.2 Document terminology and conventions .................3 1.3 Discussion of this document ..........................3 2. General issues...........................................4 3. Scenarios................................................5 3.1 Mail user agent capability discovery .................5 3.2 Resource metadata access .............................6 3.3 Resource replica locations ...........................7 3.4 Alternative or associated URLs .......................7 3.5 Capabilities at a telephone number ...................8 3.6 Public key distribution ..............................8 3.7 Recognized certification authorities .................9 3.8 Internet fax capabilities ............................9 3.9 VPIM voice messagiong capabilities ...................10 3.10 IPP printer capabilities ............................11 3.11 Presence protocol supplementary information .........11 4. Resource capability data.................................12 4.1 Media feature expression .............................12 4.2 Security options .....................................12 4.2.1 S/MIME capabilities..............................12 4.2.2 OpenPGP..........................................13 4.2.3 Channel security.................................13 4.2.4 Network security.................................13 4.2.5 X.509 certification authority....................13 4.3 MIME handling options ................................13 4.4 General capabilities and preferences .................14 4.5 Resource location information ........................14 5. RESCAP security threats..................................15 5.1 Unauthorized access or disclosure ....................15 5.2 Response spoofing ....................................15 5.3 Traffic analysis .....................................15 5.4 Data mining (privacy) ................................15 5.5 Firewall configuration disclosure ....................15 5.6 Denial of service ....................................15 6. Security considerations..................................15 6.1 Authentication .......................................15 7. Acknowledgements.........................................15 8. References...............................................16 8. Author's address.........................................17 Appendix A: Amendment history...............................17 Full copyright statement....................................17 Klyne Internet draft [Page 2] RESCAP Scenarios 9 January 200 1. Introduction This memo explores some scenarios for the resource capabaility discovery protocol (RESCAP). It is intended to provide some grounding in specific use-cases for decisions about RESCAP goals and design. 1.1 Structure of this document Section 2 makes some general comments about expected RESCAP usage and deployment. Section 3 describes a number of usage scenarios that motivate the design of RESCAP. In each case, the expected resource data and perceived security threats are listed. Section 4 describes in greater detail the resource capability data elements that are noted in one of more of the scenarios. Section 5 describes in greater detail the security threats that are noted in one of more of the scenarios. 1.2 Document terminology and conventions RESCAP refers to the "Ressource Capability Discovery Protocol" that is being designed by the RESCAP working group. NOTE: Comments like this provide additional nonessential information about the rationale for parts of this document. [[[Editorial comments and questions about outstanding issues are provided in triple brackets like this. These working comments should be resolved and removed prior to final publication.]]] 1.3 Discussion of this document Discussion of this document should take place on the Resource Capability Protocol (RESCAP) mailing list. Please send comments regarding this document to: To subscribe to this list, send a message to "" containing the command "subscribe rescap" in the message body. Klyne Internet draft [Page 3] RESCAP Scenarios 9 January 200 To see what has gone on before you subscribed, please see the mailing list archive at: ftp://cs.utk.edu/pub/rescap 2. General issues The RESCAP working group charter sets out the motivation and goals for the RESCAP protocol: A variety of resource identifiers have been widely deployed on the Internet as a means of identifying various resources, services, and destinations. However, a means of attaching a set of attributes or characteristics to a given resource identifier and subsequently assessing those attributes or characteristics has not been specified and deployed. A particularly important resolution service of this general type is one which, when given a mail address identifying a particular mail recipient, will return a series of attributes describing the capabilities of that recipient. This differs from a directory service in that no searching or other advanced query operations are involved. RESCAP consists of two protocol parts: o a general resolution protocol that will translate resource identifiers to a list of attributes. o an administrative model and update protocol that can be used to set up and maintain the information the resolution protocol accesses. The service resulting from the combination of these two protocols must meet the following goals: (0) The resolution protocol must be highly scalable, as the intent is to deploy it very widely. (1) Resolution protocol and server overhead must be very low, as some applications will make very heavy use of it. (2) Identifiers input to the resolution service are to be formatted as Uniform Resource Identifiers (URIs) containing one or more DNS domains. Note that mail addresses can be presented as mailto: URIs to meet this requirement. Klyne Internet draft [Page 4] RESCAP Scenarios 9 January 200 (3) Facilities to support inheritance within the attribute store will be essential, as the number of identifiers may be very large. Specifically, mechanisms are required for administrators to set default values for members of their administrative domains. (4) Existing protocols will be profiled for use as part of this service whenever possible rather than developing new protocols. In particular: (a) The DNS must be used as the first step in the resolution service. As the URIs under consideration here contain a DNS domain name, this provides for effective delegation of resolution activities. (b) Existing DNS record types such as SRV and NAPTR will be used if feasible, to ease deployment. (c) An existing administrative model and maintenance protocol will be used if feasible. Possible candidates for this include ACAP and LDAPv3. The protocol and security model by which a user can update his or her own attributes must be covered. The means to register and extend the set of attributes must be specified. 3. Scenarios This section summarizes some intended uses for the RESCAP protocol. Resource metadata and security threats are simply listed here, with more extensive descrptions provided in the following sections. 3.1 Mail user agent capability discovery It can be very useful for a mail sender to have some knowledge of a receiver's user agent before a message is sent. This kind of information is difficult to discover by any other means, and mail users are often forced to resort to ad-hoc out-of-band means to learn how to best prepare a message for a given recipient. Type of resource: o a mailbox, identified by a 'mailto:' URL [1, 2]. Type of metadata: o Media feature expression o Security options Klyne Internet draft [Page 5] RESCAP Scenarios 9 January 200 o MIME handling options o General capabilities and preferences Security threats: o Unauthorized access or disclosure o Response spoofing o Data mining 3.2 Resource metadata access Web and other data resources may have associated metadata (URCs?). A combination of DNS and RESCAP protocols might be used to access this resource metadata. HTTP might be used instead of RESCAP, but the RESCAP goals suggest two possible advantages over HTTP: lightweight access for small items of information that are accessed frequently, and the RESCAP administrative model suggests a possibility for easier administration of metadata for metadata about a family of related resources. Following this line, RESCAP may find a role in efficient URN resolution (using DNS NAPTR and related records [22] to locate a suitable RESCAP server). Type of resource: o Web and ftp data o [[[Others?]]] Type of metadata: o Resource URLs o Media feature expressions [[[List other kinds of metadata returned]]] Security threats: o Unauthorized access o Response spoofing o Firewall configuration disclosure Klyne Internet draft [Page 6] RESCAP Scenarios 9 January 200 3.3 Resource replica locations Popular web and FTP resources are often replicated on different servers for fault tolerance and load sharing. Given a URL for one copy of a resource, RESCAP might be used to find another copy. [[[NOTE: DNS NAPTR, etc., might be better used for this purpose]]] Type of resource: o Anything with a URL or URI. Type of metadata: o Resource location information Security threats: o Unauthorized access o Response spoofing o Firewall configuration disclosure 3.4 Alternative or associated URLs A network resource may have associated or alternative URLs. For example, to access the resource using a different protocol, to access different versions of a resource or to access associated information about a resource. Type of resource: o Anything with a URL or URI. Type of metadata: o Resource location information Security threats: o Unauthorized access o Response spoofing o Firewall configuration disclosure Klyne Internet draft [Page 7] RESCAP Scenarios 9 January 200 3.5 Capabilities at a telephone number Convergence between the Internet and telephone networks is leading to resources and endpoints accessed from the Internet being identified by telephone numbers. A simple telephone number does little to indicate the kinds of service available at that endpoint, or the protocols that may be used to access the facilities provided. In some cases, communication with an endpoint identified by a telephone number may take place entirely over the Internet, in which case it is necessay to know which Internet protocols should be employed (e.g. H.323, SIP, Internet fax, VPIM, etc.). Type of resource: o Communication service endpoints tradtionally associated with the telephone network: voice, voice messaging, fax, etc. Type of metadata: o Media feature expression o Security options o MIME handling options o General capabilities and preferences o [[[Access billing information???]]] Security threats: o Unauthorized access or disclosure o Response spoofing o Data mining o Traffic analysis 3.6 Public key distribution To conduct secure communications with a given endpoint, a suitable public key for that endpoint may be needed. RESCAP could be one useful way to publish public key information. Type of resource: o Any communication endpoint Klyne Internet draft [Page 8] RESCAP Scenarios 9 January 200 Type of metadata: o Security options Security threats: o The usual issues associated with public key distribution. 3.7 Recognized certification authorities In the absence of an X.509 style global root for authorizing public keys, one of the challenges to securing communication with public key cryptography is to find a certification authority (CA) that is directly or indirectly trusted by both parties. Having each party publish details of the CAs that it recognizes may help in establishing a chain of trust between the communicating parties. Type of resource: o Any communication endpoint Type of metadata: o X.509 Certification Authorities [[[What is PGP equivalent?]]] Security threats: o The usual issues associated with public key distribution. o Exposure of potentially weak security 3.8 Internet fax capabilities Internet fax uses e-mail protocols to emulate a fax-like service within the Internet e-mail environment. One problem with this is that the endpoint identification and capability exchange associated with traditional facsimile is not provided by the e-mail protocols. RESCAP may provide an alternatuve way to access such information, particularly with respect to receiver capabilities. Even if the proposed content negotiation framework is deployed, using RESCAP to obtain capability information cam optimize the process by reducing the number of occasions on which additional message round trips will be needed. Klyne Internet draft [Page 9] RESCAP Scenarios 9 January 200 Type of resource: o a mailbox, identified by a 'mailto:' URL [1, 2]. Type of metadata: o Level of Internet fax support (e.g. "simple", "extended", "full", "none"). o Media feature expression o Security options o MIME handling options o General capabilities and preferences Security threats: o Unauthorized access or disclosure o Response spoofing o Data mining 3.9 VPIM voice messagiong capabilities VPIM uses e-mail protocols to transfer voice messages within the Internet e-mail environment. RESCAP may provide a way to access vital information about VPIM receiver caabilities. Type of resource: o a mailbox, identified by a 'mailto:' URL [1, 2]. Type of metadata: o Level of VPIM support (e.g. "V2", "IVM", support for message privacy options such as "do not forward"). o Media feature expression (especially for indicating supported audio codecs). o Security options o MIME handling options o General capabilities and preferences Klyne Internet draft [Page 10] RESCAP Scenarios 9 January 200 Security threats: o Unauthorized access or disclosure o Response spoofing o Data mining 3.10 IPP printer capabilities IPP uses a protocol modeled on HTTP to transfer print images for remote printing, and to control the print process. Although IPP allows printer capabilities to be interrogated, RESCAP might be used as a more efficient way to find such information, particularly in a phase of printer discovery. Type of resource: o IPP printer, identified by an 'ipp:' URL (String) Type of metadata: o IPP capability informaton o Other resource metadata Security threats: o Unauthorized access o Response spoofing o Firewall configuration disclosure 3.11 Presence protocol supplementary information There has been much discussion both within and outside the IMPP working group about the use of a presence protocol to distribute capability information. A problem is that it cxan be difficult to know how far it is reasonable to go in adding supplementary information to what should be a very lightweight indication of "available/not-available" presence informaton. One way to address this problem is to restrict the presence information to genuine dynamic status information, and to use RESCAP to access any (less dynamic) supplementary information about a contact point described by presence information. Klyne Internet draft [Page 11] RESCAP Scenarios 9 January 200 Type of resource: o Presence information contact address -- as a URL. Type of metadata: o General preference and capability information (esp. vCard) o Media feature expression Security threats: o Unauthorized access o Response spoofing o Firewall configuration disclosure o Data mining 4. Resource capability data Try to draw line between a capability resolution service and a content deivery service. 4.1 Media feature expression 4.2 Security options 4.2.1 S/MIME capabilities S/MIME related capabilities [3,4,5, and associated documents]. o S/MIME signature types that can be verified (list of strings; e.g. "id-dsa", "rsaEncryption"). o S/MIME public signing key certificates (list of arbitrary binary values). o S/MIME public encrypting key certificates (list of arbitrary binary values). o S/MIME public key-certificaton key certificates - used by agents acting in a certifying authority (CA) role (list of arbitrary binary values). o Resonds to requests for S/MIME signed receipts? (Boolean). o Recognizes and interprets S/MIME security labels? (Boolean). Klyne Internet draft [Page 12] RESCAP Scenarios 9 January 200 o Acts as an S/MIME secure mailing list? (Boolean). o Handles signed 'SigningCertificate' attribute? (Boolean). 4.2.2 OpenPGP OpenPGP related capabilities [6, and associated documents]. o OpenPGP signature types that can be verified (list of strings; e.g. "DSA", "RSA"). o OpenPGP public signing key certificates (list of arbitrary binary values). o OpenPGP public encrypting key certificates (list of arbitrary binary values). o OpenPGP public key-certificaton key certificates (list of arbitrary binary values). 4.2.3 Channel security [[[Details of keys, etc., applicable to channel security mechanisms, such as TLS]]] 4.2.4 Network security [[[Details of keys, etc., applicable to channel netwrk mechanisms, such as IPSEC]]] 4.2.5 X.509 certification authority o List of X.509 certification authorities directly trusted by a party (List of strings containing X.509 distinguished names). 4.3 MIME handling options The attributes in this section describe MIME handling capabilities [7,8]. o Plain text only - MIME not recognized (Boolean). o Supports MIME header extensions [9] (Boolean). o Supports MIME parameter extensions [10] (Boolean). o Character sets [11] displayed (String, containing CONNEG media feature expression [12], containg character set feature tags [13] in simple disjunctive form). Klyne Internet draft [Page 13] RESCAP Scenarios 9 January 200 o Preferred languages [14] (String, containing CONNEG media feature expression [12], containg language feature tags [13] in simple disjunctive form). o Display line length in characters (Integer). o Can handle MHTML [15]? (Boolean). o Can handle Content-MD5 [16]? (Boolean). o Can handle mailing list URLs? (Boolean). o Can recognize and respond to MDN requests [18]? (Boolean) o Can act as an iCalendar and iMIP agent [19]? (Boolean) 4.4 General capabilities and preferences This section lists some general capabilities that may be significant to a message sender. Unsolicited bulk e-mail preferences. (List of pairs of strings, each of which is a policy name and an associated value). Mailing list information. (String containing a list of RFC 822 headers [20]). vCard information [21]. (String containing information in vCard format.) Associated e-mail addresses. (List of pairs of strings; each pair is an e-mail address and description of that address, such as "home", "work", etc.). 4.5 Resource location information Resource location(s) can be described using a URL or a list of URLs: o Single location: URL (String) o Multiple locations: list of URLs (List of strings). Klyne Internet draft [Page 14] RESCAP Scenarios 9 January 200 5. RESCAP security threats In considering security for RESCAP, note that the general presumtpion is that the information being provided is public. But completely unrestricted access may be inappropriate because that would create an exposure to privacy invasion through data mining activities. Also, there may be requirements to disclose some information only within a closed community. [[[The rest of this section has yet to be fleshed out]]] 5.1 Unauthorized access or disclosure Access controls 5.2 Response spoofing 5.3 Traffic analysis 5.4 Data mining (privacy) 5.5 Firewall configuration disclosure 5.6 Denial of service 6. Security considerations [[[Additional points?]]] 6.1 Authentication Note that there are a number of diferent authentication cases to be considered: o Server to client o Client to server o Request to server o Response to client 7. Acknowledgements The initial list of scenarios was largely culled from an informal meeting of RESCAP working group participants, and from Paul Hoffman's RESCAP profile for mail user agents. Klyne Internet draft [Page 15] RESCAP Scenarios 9 January 200 8. References [[[Full citations to be supplied]]] [1] RFC 821, "Simple Mail Transfer Protocol" [2] "mailto: URL" [3] SMIME-MSG [4] SMIME-CERT [5] SMIME-ESS [6] OpenPGP [7] RFC 2045, MIME [8] RFC 2046, MIME [9] RFC 2047, MIME extensions [10] MIME parameter extensions [11] Charset registry [12] RFC 2533, Media feature expressions [13] CONNEG charset/language tags [14] Language code registry [15] MHTML [16] Content-MD5 [17] Mailing list URLs [18] RFC 2298, MDNs [19] iCalendar/iMIP [20] Mailing list headers [21] vCard format [22] RFC 2168, URN resolution and DNS NAPTR record Klyne Internet draft [Page 16] RESCAP Scenarios 9 January 200 [xx] "xxx" xxx, yyy Internet draft: Work in progress, xxx yyyy 8. Author's address Graham Klyne, MIMEsweeper Group, 1310 Waterside, Arlington Business Park Theale Reading, RG7 4SA United Kingdom. Telephone: +44 118 930 1300 Facsimile: +44 118 930 1301 E-mail: GK-ResCap@ninebynine.org Appendix A: Amendment history 00a 30-Mar-2000 Memo initially created. 01a 09-Jan-2002 Reissued to Internet-drafts, without significant change. TODO 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. Klyne Internet draft [Page 17] RESCAP Scenarios 9 January 200 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. Klyne Internet draft [Page 18]