idnits 2.17.1 draft-ietf-rescap-proto-main-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 311 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 30, 2000) is 8850 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-hoffman-rescap-proto-format - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RESCAP-FORMAT' ** Downref: Normative reference to an Informational draft: draft-ietf-rescap-req (ref. 'RESCAP-REQUIRE') ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-ietf-rescap-proto-main-00.txt Internet Mail Consortium 3 January 30, 2000 4 Expires in six months 6 The rescap Resolution Protocol 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The rescap protocol is a general client-server resolution protocol that 31 translates resource identifiers to a list of attributes. For instance, 32 a rescap client can ask a rescap server for the attributes of a 33 particular mail user. rescap is very light-weight and acts only as a 34 resolution protocol, not a directory service. This document describes 35 the main features of the protocol. 37 1. Introduction 39 When an Internet client is accessing a resource, it is often valuable 40 for the client to know the attributes of the resource before contacting 41 the resource. For example, a mail user might want to know whether 42 another mail user is able to natively display TIFF files before 43 creating a message with a TIFF file in it. The rescap protocol is a 44 simple, extensible client-server protocol that allows a client to 45 easily find the correct rescap server for a particular resource and 46 find the attributes for that resource. 48 This document specifies: 49 - How to find the rescap server for a particular resource 50 - The recap protocol 51 - Registration of the "rescap" scheme name for URLs 53 A different document, [RESCAP-FORMAT], specifies: 54 - The format for rescap requests and responses 55 - Required rescap items that must be supported 57 The protocol in this document attempts to meet the requirements 58 described in the rescap requirements document [RESCAP-REQUIRE]. It 59 should be noted that rescap is explicitly not to be used as a service- 60 discovery protocol; users that want such a capability should use the 61 Service Location Protocol [SLP]. 63 Future documents may specify the administrative protocol described 64 in [RESCAP-REQUIRE]. 66 This document and others relating to the rescap protocol are being 67 discussed in the recap WG of the IETF on the rescap@cs.utk.edu mailing 68 list. To subscribe, send a message to rescap-request@cs.utk.edu. An 69 archive of the mailing list is available at 70 . 72 1.1 Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [MUSTSHOULD]. 78 2. Finding a rescap Server 80 A rescap client that wants to find the attributes for a particular 81 Internet resource needs to find the rescap server for that resource. 82 The client MUST look up the A record associated with the rescap server 83 for the host name in the resource. When SRV records (described in 84 [SRV]) become widely deployed, the client MAY instead use the SRV 85 protocol to locate the rescap server. 87 To find the A record of the rescap server, the client prepends two 88 special domain names to the host name in the resource. The first name 89 prepended (just to the left of the host name) is "_rescap."; the second 90 name prepended (just to the left of "_rescap." is an underscore followed 91 by the URL scheme name. 93 For example, to find the rescap server that is authoritative for the 94 URI "mailto:someone@example.com", the rescap client would resolve the A 95 record of the name "_mailto._rescap.example.com" and use that value as 96 the location of the rescap server. 98 2.1 Optional use of SRV Records 100 SRV records MAY be used for locating rescap servers. The request sent 101 to the DNS server is somewhat different than is specified in [SRV] 102 because the rescap client must indicate the type of resource that will 103 be resolved by the rescap server. The resource name is given as the URI 104 scheme name, and it appears in the left-most part of the DNS name to be 105 resolved. The URI scheme name has an underscore character (_) prepended 106 to it, just as the service and prototype names do. 108 As described in section 3 of this specification, the rescap protocol 109 runs over both the UDP and TCP protocols, and all compliant servers 110 must run the rescap service on both protocols on the same host. It is 111 inefficient to force the rescap client to look up SRV records for both 112 protocols, and doubling the number of SRV records for the rescap 113 protocol can have an adverse effect on the domain name system. Thus, 114 rescap clients MUST only resolve rescap SRV records for the UDP 115 protocol, and MUST assume that the same host that was resolved for the 116 UDP protocol will support rescap over the TCP protocol as well. rescap 117 clients MUST NOT attempt to resolve rescap SRV records for the TCP 118 protocol. 120 For example, to use SRV records to find the rescap server that is 121 authoritative for the URI "mailto:someone@example.com", the rescap 122 client would resolve the SRV record for the name 123 "_mailto._rescap._udp.example.com". 125 3. Protocol 127 The rescap protocol uses a single request-response model. That is, a 128 rescap client connects to the rescap server, sends a single request, 129 and waits for the response. The server sends a single response and 130 closes the connection. 132 The rescap protocol has two forms: basic and secure. The basic form 133 offers only authentication by IP address, and gives no privacy for the 134 requests or the responses. The secure form offers client and server 135 authentication, and privacy. Conforming rescap servers MUST support 136 the basic form and MAY also support the secure form. 138 Note that many of the main motivations for rescap do not require any 139 security services: the information returned by the rescap server is 140 openly available to anyone. The basic form of rescap works just fine 141 for this situation. If the client needs to authenticate the server, of 142 if the server needs to authenticate the client by something other than 143 the client's IP address (such as for mobile users), or if privacy is 144 needed, the secure form MUST be used. 146 3.1 Basic form 148 The requirement that the rescap protocol be light-weight and fast leads 149 to the conclusion that it should run on UDP instead of TCP because UDP 150 takes less system and network resources for short exchanges. However, 151 UDP has many problems, including that long datagrams may get split up 152 or lost. Thus, to make rescap reliable, basic form rescap servers run 153 on both UDP and TCP. Implementations of basic form rescap SHOULD use 154 UDP checksums to help detect fragmentation. 156 A basic form rescap server MUST run the same service on both the UDP 157 and TCP protocols, and MUST use the same port number for both services. 158 The port number 283 has been reserved by IANA for basic form rescap, 159 and basic form rescap servers SHOULD run on that port number. However, 160 because the client is allowed to find the port number using SRV 161 records, the basic form rescap server can run on any UDP and TCP port. 163 A rescap client using the basic form SHOULD make its initial request to 164 the basic form rescap server using UDP. However, if the rescap client 165 using the basic form expects that the response from the server to be 166 longer than 512 octets (such as if it is asking for an attribute whose 167 value is always longer than 512 octets), the client MAY choose to make 168 the initial connection using TCP. 170 If a client using the basic form sends a UDP request to the server 171 named in an SRV record but does not receive a response, the client 172 SHOULD send the same request using TCP. If a client sends a UDP request 173 to a server and receives an incomplete response, the client MUST send 174 the same request using TCP. This is due to the fact that a later part 175 of a response might modify or negate the meaning of an earlier part of 176 a response. 178 3.2 Secure form 180 The secure form of rescap is quite similar to the basic form, but the 181 connection is made using TCP under TLS [TLS]. The port has been 182 reserved by IANA for secure form rescap, and secure form rescap servers 183 SHOULD run on that port number. However, because the client is allowed 184 to find the port number using SRV records, the secure form rescap 185 server can run on any TCP port. 187 rescap clients and servers MUST support the 188 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The client and 189 the server MUST NOT support any cipher suites that do not contain both 190 encryption and authentication. 192 4. Security Considerations 194 rescap users rely on the DNS for finding a rescap server. Unless the 195 DNS is secure, an attacker can cause a rescap user to get information 196 from the wrong server. 198 Basic form rescap offers no authentication of the client, no 199 authentication of the server, and no privacy of the requests or 200 responses. The secure form gives privacy of the request and the 201 response, and allows the client to authenticate the server and the 202 server to authenticate the client. Note, however, that few TLS 203 implementations use client authentication. The rescap format has 204 features for client authentication in both basic form and secure form. 206 5. References 208 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 209 Levels", RFC 2119. 211 [RESCAP-FORMAT] "The rescap Request and Response Format", 212 draft-hoffman-rescap-proto-format. 214 [RESCAP-REQUIRE] "ResCap Requirements", draft-ietf-rescap-req. 216 [SLP] "Service Location Protocol, Version 2.", RFC 2608, and "Service 217 Templates and Service: Schemes", RFC 2609. 219 [SRV] "A DNS RR for specifying the location of services (DNS SRV)", RFC 220 2052. NOTE: RFC 2052 is being updated by 221 draft-ietf-dnsind-rfc2052bis. The examples in this document are 222 based on the Internet Draft, not on RFC 2052. 224 [TLS] "TLS Protocol", RFC 2246. 226 A. IANA Considerations 228 A.1 Registration for rescap URL Scheme 230 URL scheme name: rescap 232 URL scheme syntax: ://? 233 is either the string "rescap" for basic form or 234 "rescap-secure" for secure form. is exactly as defined 235 in RFC 2396. is the Base64 encoding of a 236 rescap request. 238 For example, to indicate a query to the basic form rescap server 239 on the host "an.example.com" at the default port of 283, the URL 240 would be rescap://an.example.com/SK398cske002CcksleEEx 242 For example, to indicate a query to the secure form rescap server 243 on the host at 10.20.30.40 at port 1234, the URL would be 244 rescap-secure://10.20.30.40:1234/SK398cske002CcksleEEx 246 Character encoding considerations: None. All three parts are expressed 247 in US-ASCII. 249 Intended usage: To identify queries rescap servers. The resolution of a 250 rescap URL will normally cause a query to be sent to the named 251 server. The resolver would decode the Base64 of the third part of 252 the URL and send it to the specified port (or the default port of 253 283 if no port is specified in the URL) using the TCP protocol. 255 Applications and/or protocols which use this URL scheme name: 256 This document describes the rescap protocol. 258 Interoperability considerations: None known. 260 Security considerations: Same as in this document. 262 Relevant publications: This document. 264 Person & email address to contact for further information: 265 Paul Hoffman 267 Author/Change controller: 268 Paul Hoffman 270 A.2 Port reservation 272 IANA has reserved port 283 for basic form rescap. A port has been 273 requested for secure form rescap. 275 B. Acknowledgments 277 Graham Klyne provided suggestions for early versions of the first draft. 279 C. Changes Between Versions of This Document 281 This document began as a single document that included the material 282 in [RESCAP-FORMAT]. It was split into two so that people could think 283 about each part separately. Thus, a great deal has been cut out and 284 moved to the other draft. 286 The biggest change in this document is that the protocol now has two 287 forms: basic and secure. Made many changes based on this. 289 Noted that the mailing list is now for the WG. 291 Updated the references. 293 Updated the URL registration for secure form. 295 D. Author Contact Information 297 Paul Hoffman 298 Internet Mail Consortium 299 127 Segre Place 300 Santa Cruz, CA 95060 USA 301 phoffman@imc.org