Internet Draft Paul Hoffman draft-ietf-rescap-proto-main-01.txt Internet Mail Consortium August 8, 2000 Expires in six months The rescap Resolution Protocol 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. Abstract The rescap protocol is a general client-server resolution protocol that translates resource identifiers to a list of attributes. For instance, a rescap client can ask a rescap server for the attributes of a particular mail user. rescap is very light-weight and acts only as a resolution protocol, not a directory service. This document describes the main features of the protocol. 1. Introduction When an Internet client is accessing a resource, it is often valuable for the client to know the attributes of the resource before contacting the resource. For example, a mail user might want to know whether another mail user is able to natively display TIFF files before creating a message with a TIFF file in it. The rescap protocol is a simple, extensible client-server protocol that allows a client to easily find the correct rescap server for a particular resource and find the attributes for that resource. This document specifies: - How to find the rescap server for a particular resource - The recap protocol A different document, [RESCAP-FORMAT], specifies: - The format for rescap requests and responses - Required rescap items that must be supported The protocol in this document attempts to meet the requirements described in the rescap requirements document [RESCAP-REQUIRE]. It should be noted that rescap is explicitly not to be used as a service- discovery protocol; users that want such a capability should use the Service Location Protocol [SLP]. Future documents may specify the administrative protocol described in [RESCAP-REQUIRE]. This document and others relating to the rescap protocol are being discussed in the recap WG of the IETF on the rescap@cs.utk.edu mailing list. To subscribe, send a message to rescap-request@cs.utk.edu. An archive of the mailing list is available at . 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD]. 2. Protocol The rescap protocol uses a single request-response model. That is, a rescap client connects to the rescap server, sends a single request, and waits for the response. The server sends a single response and closes the connection. The rescap protocol has two forms: basic and secure. The basic form offers only authentication by IP address, and gives no privacy for the requests or the responses. The secure form offers client and server authentication, and privacy. Conforming rescap servers MUST support the basic form and MAY also support the secure form. Note that many of the main motivations for rescap do not require any security services: the information returned by the rescap server is openly available to anyone. The basic form of rescap works just fine for this situation. If the client needs to authenticate the server, or if the server needs to authenticate the client by something other than the client's IP address (such as for mobile users), or if privacy is needed, the secure form MUST be used. 2.1 Basic form The requirement that the rescap protocol be light-weight and fast leads to the conclusion that it should run on UDP instead of TCP because UDP takes less system and network resources for short exchanges. However, UDP has many problems, including that long datagrams may get split up or lost. Thus, to make rescap reliable, basic form rescap servers run on both UDP and TCP. Implementations of basic form rescap SHOULD use UDP checksums to help detect fragmentation. A basic form rescap server MUST run the same service on both the UDP and TCP protocols. The port number 283 has been reserved by IANA for basic form rescap, and basic form rescap servers SHOULD run on that port number. However, because the client MUST find the port number using SRV records, the basic form rescap server can run on any UDP and TCP port. A rescap client using the basic form SHOULD make its initial request to the basic form rescap server using UDP. However, if the rescap client using the basic form expects that the response from the server to be longer than 512 octets (such as if it is asking for an attribute whose value is always longer than 512 octets), the client MAY choose to make the initial connection using TCP. If a client using the basic form sends a UDP request to the server named in an SRV record but does not receive a response, the client SHOULD send the same request using TCP. If a client sends a UDP request to a server and receives an incomplete response, the client MUST send the same request using TCP. This is due to the fact that a later part of a response might modify or negate the meaning of an earlier part of a response. 2.2 Secure form The secure form of rescap is quite similar to the basic form, but the connection MUST be made using TCP under TLS [TLS]. No port has been reserved by IANA for secure form rescap, so secure form rescap servers MAY run on any port number. Because the client MUST find the port number using SRV records, the secure form rescap server can run on any UDP and TCP port. Secure form rescap clients and servers MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The client and the server MUST NOT support any cipher suites that do not contain both encryption and authentication. 3. Finding a rescap Server SRV records [SRV] MUST be used for locating rescap servers. The request sent to the DNS server is somewhat different than is specified in [SRV] because the rescap client must indicate the type of resource that will be resolved by the rescap server. The resource name is given as the URI scheme name, and it appears in the left-most part of the DNS name to be resolved. The URI scheme name has an underscore character (_) prepended to it, just as the service and prototype names do. As described in section 2 of this specification, the basic form of the rescap protocol runs over both the UDP and TCP protocols, and all compliant basic form servers MUST run the rescap service on both protocols on the same host (secure form servers only run on TCP). It is inefficient to force the rescap client to look up SRV records for both protocols, and doubling the number of SRV records for the rescap protocol can have an adverse effect on the domain name system. Thus, rescap clients MUST only resolve rescap SRV records for the TCP protocol, and MUST assume that the same host that was resolved for the TCP protocol will support rescap over the UDP protocol as well. rescap clients MUST NOT attempt to resolve rescap SRV records for the UDP protocol. The two forms of rescap have different service names for the SRV records. The basic form has the service name "rescap-basic" and the secure form has the service name "rescap-secure". For example, to find the basic server that is authoritative for the URI "mailto:someone@example.com", the rescap client would resolve the SRV record for the name: _mailto._rescap-basic._tcp.example.com To find the secure server that is authoritative for the URI "mailto:someone@example.com", the rescap client would resolve the SRV record for the name: _mailto._rescap-secure._tcp.example.com 4. Security Considerations rescap users rely on the DNS for finding a rescap server. Unless the DNS is secure, an attacker can cause a rescap user to get information from the wrong server. Basic form rescap offers no authentication of the client, no authentication of the server, and no privacy of the requests or responses. The secure form gives privacy of the request and the response, and allows the client to authenticate the server and the server to authenticate the client. Note, however, that few TLS implementations use client authentication. The rescap format has features for client authentication in both basic form and secure form. 5. References [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RESCAP-FORMAT] "The rescap Request and Response Format", draft-hoffman-rescap-proto-format. [RESCAP-REQUIRE] "ResCap Requirements", draft-ietf-rescap-req. [SLP] "Service Location Protocol, Version 2.", RFC 2608, and "Service Templates and Service: Schemes", RFC 2609. [SRV] "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782. [TLS] "TLS Protocol", RFC 2246. A. IANA Considerations A.1 Registration for rescap-basic URL Scheme URL scheme name: rescap-basic URL scheme syntax: rescap-basic://? is exactly as defined in RFC 2396. is the Base64 encoding of a rescap request. For example, to indicate a query to the basic form rescap server on the host "an.example.com" at the default port of 283, the URL would be rescap://an.example.com/SK398cske002CcksleEEx Character encoding considerations: None. All three parts are expressed in US-ASCII. Intended usage: To identify redirected queries to rescap servers. The resolution of a rescap URL will cause a query to be sent to the named server. The resolver would decode the Base64 of the third part of the URL and send it to the specified port (or the default port of 283 if no port is specified in the URL) using the TCP protocol. It is *not* expected that recap-basic URLs will be entered manually by users or be given by anything other than a referring rescap server. Applications and/or protocols which use this URL scheme name: This document describes the rescap protocol. Interoperability considerations: None known. Security considerations: Same as in this document. Relevant publications: This document. Person & email address to contact for further information: Paul Hoffman Author/Change controller: Paul Hoffman A.2 Registration for rescap-secure URL Scheme URL scheme name: rescap-secure URL scheme syntax: rescap-secure://? is exactly as defined in RFC 2396. Note that, because there is no default port for secure form server, the port number MUST be included in the . is the Base64 encoding of a rescap request. For example, to indicate a query to the form rescap server on the host at 10.20.30.40 at port 1234, the URL would be rescap-secure://10.20.30.40:1234/SK398cske002CcksleEEx Character encoding considerations: None. All three parts are expressed in US-ASCII. Intended usage: To identify redirected queries to rescap servers. The resolution of a rescap URL will cause a query to be sent to the named server. The resolver would decode the Base64 of the third part of the URL and send it to the specified port (or the default port of 283 if no port is specified in the URL) using the TCP protocol. It is *not* expected that recap-basic URLs will be entered manually by users or be given by anything other than a referring rescap server. Applications and/or protocols which use this URL scheme name: This document describes the rescap protocol. Interoperability considerations: None known. Security considerations: Same as in this document. Relevant publications: This document. Person & email address to contact for further information: Paul Hoffman Author/Change controller: Paul Hoffman A.3 Port reservation IANA has reserved port 283 for basic form rescap. A port has been requested for secure form rescap. B. Acknowledgments Graham Klyne provided suggestions for early versions of the first draft. C. Changes Between the -00 and -01 Versions of This Document Reversed the order of sections 2 and 3 because the new document needs to describe the basic and secure forms before describing how to find them. Made SRV records mandatory and dropped the previous kludge. Made using the port number from the SRV record mandatory. Changed the SRV lookup to use TCP to reduce confusion between the basic and secure forms. Updated the reference for SRV records. Significantly updated the URL registration. D. Author Contact Information Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA phoffman@imc.org