idnits 2.17.1 draft-ietf-rescap-proto-main-01.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 338 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 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 (August 8, 2000) is 8661 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: 8 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-01.txt Internet Mail Consortium 3 August 8, 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 52 A different document, [RESCAP-FORMAT], specifies: 53 - The format for rescap requests and responses 54 - Required rescap items that must be supported 56 The protocol in this document attempts to meet the requirements 57 described in the rescap requirements document [RESCAP-REQUIRE]. It 58 should be noted that rescap is explicitly not to be used as a service- 59 discovery protocol; users that want such a capability should use the 60 Service Location Protocol [SLP]. 62 Future documents may specify the administrative protocol described 63 in [RESCAP-REQUIRE]. 65 This document and others relating to the rescap protocol are being 66 discussed in the recap WG of the IETF on the rescap@cs.utk.edu mailing 67 list. To subscribe, send a message to rescap-request@cs.utk.edu. An 68 archive of the mailing list is available at 69 . 71 1.1 Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [MUSTSHOULD]. 77 2. Protocol 79 The rescap protocol uses a single request-response model. That is, a 80 rescap client connects to the rescap server, sends a single request, 81 and waits for the response. The server sends a single response and 82 closes the connection. 84 The rescap protocol has two forms: basic and secure. The basic form 85 offers only authentication by IP address, and gives no privacy for the 86 requests or the responses. The secure form offers client and server 87 authentication, and privacy. Conforming rescap servers MUST support 88 the basic form and MAY also support the secure form. 90 Note that many of the main motivations for rescap do not require any 91 security services: the information returned by the rescap server is 92 openly available to anyone. The basic form of rescap works just fine 93 for this situation. If the client needs to authenticate the server, or 94 if the server needs to authenticate the client by something other than 95 the client's IP address (such as for mobile users), or if privacy is 96 needed, the secure form MUST be used. 98 2.1 Basic form 100 The requirement that the rescap protocol be light-weight and fast leads 101 to the conclusion that it should run on UDP instead of TCP because UDP 102 takes less system and network resources for short exchanges. However, 103 UDP has many problems, including that long datagrams may get split up or 104 lost. Thus, to make rescap reliable, basic form rescap servers run on 105 both UDP and TCP. Implementations of basic form rescap SHOULD use UDP 106 checksums to help detect fragmentation. 108 A basic form rescap server MUST run the same service on both the UDP and 109 TCP protocols. The port number 283 has been reserved by IANA for basic 110 form rescap, and basic form rescap servers SHOULD run on that port 111 number. However, because the client MUST find the port number using SRV 112 records, the basic form rescap server can run on any UDP and TCP port. 114 A rescap client using the basic form SHOULD make its initial request to 115 the basic form rescap server using UDP. However, if the rescap client 116 using the basic form expects that the response from the server to be 117 longer than 512 octets (such as if it is asking for an attribute whose 118 value is always longer than 512 octets), the client MAY choose to make 119 the initial connection using TCP. 121 If a client using the basic form sends a UDP request to the server named 122 in an SRV record but does not receive a response, the client SHOULD send 123 the same request using TCP. If a client sends a UDP request to a server 124 and receives an incomplete response, the client MUST send the same 125 request using TCP. This is due to the fact that a later part of a 126 response might modify or negate the meaning of an earlier part of a 127 response. 129 2.2 Secure form 131 The secure form of rescap is quite similar to the basic form, but the 132 connection MUST be made using TCP under TLS [TLS]. No port has been 133 reserved by IANA for secure form rescap, so secure form rescap servers 134 MAY run on any port number. Because the client MUST find the port number 135 using SRV records, the secure form rescap server can run on any UDP and 136 TCP port. 138 Secure form rescap clients and servers MUST support the 139 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLS. The client and 140 the server MUST NOT support any cipher suites that do not contain both 141 encryption and authentication. 143 3. Finding a rescap Server 145 SRV records [SRV] MUST be used for locating rescap servers. The request 146 sent to the DNS server is somewhat different than is specified in [SRV] 147 because the rescap client must indicate the type of resource that will 148 be resolved by the rescap server. The resource name is given as the URI 149 scheme name, and it appears in the left-most part of the DNS name to be 150 resolved. The URI scheme name has an underscore character (_) prepended 151 to it, just as the service and prototype names do. 153 As described in section 2 of this specification, the basic form of the 154 rescap protocol runs over both the UDP and TCP protocols, and all 155 compliant basic form servers MUST run the rescap service on both 156 protocols on the same host (secure form servers only run 157 on TCP). It is inefficient to force the rescap client 158 to look up SRV records for both protocols, and doubling the number of 159 SRV records for the rescap protocol can have an adverse effect on the 160 domain name system. Thus, rescap clients MUST only resolve rescap SRV 161 records for the TCP protocol, and MUST assume that the same host that 162 was resolved for the TCP protocol will support rescap over the UDP 163 protocol as well. rescap clients MUST NOT attempt to resolve 164 rescap SRV records for the UDP protocol. 166 The two forms of rescap have different service names for the SRV 167 records. The basic form has the service name "rescap-basic" and the 168 secure form has the service name "rescap-secure". 170 For example, to find the basic server that is authoritative for the URI 171 "mailto:someone@example.com", the rescap client would resolve the SRV 172 record for the name: 174 _mailto._rescap-basic._tcp.example.com 176 To find the secure server that is authoritative for the URI 177 "mailto:someone@example.com", the rescap client would resolve the SRV 178 record for the name: 180 _mailto._rescap-secure._tcp.example.com 182 4. Security Considerations 184 rescap users rely on the DNS for finding a rescap server. Unless the 185 DNS is secure, an attacker can cause a rescap user to get information 186 from the wrong server. 188 Basic form rescap offers no authentication of the client, no 189 authentication of the server, and no privacy of the requests or 190 responses. The secure form gives privacy of the request and the 191 response, and allows the client to authenticate the server and the 192 server to authenticate the client. Note, however, that few TLS 193 implementations use client authentication. The rescap format has 194 features for client authentication in both basic form and secure form. 196 5. References 198 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 199 Levels", RFC 2119. 201 [RESCAP-FORMAT] "The rescap Request and Response Format", 202 draft-hoffman-rescap-proto-format. 204 [RESCAP-REQUIRE] "ResCap Requirements", draft-ietf-rescap-req. 206 [SLP] "Service Location Protocol, Version 2.", RFC 2608, and "Service 207 Templates and Service: Schemes", RFC 2609. 209 [SRV] "A DNS RR for specifying the location of services (DNS SRV)", RFC 210 2782. 212 [TLS] "TLS Protocol", RFC 2246. 214 A. IANA Considerations 216 A.1 Registration for rescap-basic URL Scheme 218 URL scheme name: rescap-basic 220 URL scheme syntax: rescap-basic://? 222 is exactly as defined in RFC 2396. 223 is the Base64 encoding of a rescap request. 225 For example, to indicate a query to the basic form rescap server on 226 the host "an.example.com" at the default port of 283, the URL would 227 be rescap://an.example.com/SK398cske002CcksleEEx 229 Character encoding considerations: None. All three parts are expressed 230 in US-ASCII. 232 Intended usage: To identify redirected queries to rescap servers. The 233 resolution of a rescap URL will cause a query to be sent to the 234 named server. The resolver would decode the Base64 of the third 235 part of the URL and send it to the specified port (or the default 236 port of 283 if no port is specified in the URL) using the TCP 237 protocol. It is *not* expected that recap-basic URLs will be 238 entered manually by users or be given by anything other than a 239 referring rescap server. 241 Applications and/or protocols which use this URL scheme name: 242 This document describes the rescap protocol. 244 Interoperability considerations: None known. 246 Security considerations: Same as in this document. 248 Relevant publications: This document. 250 Person & email address to contact for further information: 251 Paul Hoffman 253 Author/Change controller: 254 Paul Hoffman 256 A.2 Registration for rescap-secure URL Scheme 258 URL scheme name: rescap-secure 260 URL scheme syntax: rescap-secure://? 262 is exactly as defined in RFC 2396. Note that, because 263 there is no default port for secure form server, the port number 264 MUST be included in the . is the 265 Base64 encoding of a rescap request. 267 For example, to indicate a query to the form rescap server on the 268 host at 10.20.30.40 at port 1234, the URL would be 269 rescap-secure://10.20.30.40:1234/SK398cske002CcksleEEx 271 Character encoding considerations: None. All three parts are expressed 272 in US-ASCII. 274 Intended usage: To identify redirected queries to rescap servers. The 275 resolution of a rescap URL will cause a query to be sent to the 276 named server. The resolver would decode the Base64 of the third 277 part of the URL and send it to the specified port (or the default 278 port of 283 if no port is specified in the URL) using the TCP 279 protocol. It is *not* expected that recap-basic URLs will be 280 entered manually by users or be given by anything other than a 281 referring rescap server. 283 Applications and/or protocols which use this URL scheme name: 284 This document describes the rescap protocol. 286 Interoperability considerations: None known. 288 Security considerations: Same as in this document. 290 Relevant publications: This document. 292 Person & email address to contact for further information: 293 Paul Hoffman 295 Author/Change controller: 296 Paul Hoffman 298 A.3 Port reservation 300 IANA has reserved port 283 for basic form rescap. A port has been 301 requested for secure form rescap. 303 B. Acknowledgments 305 Graham Klyne provided suggestions for early versions of the first draft. 307 C. Changes Between the -00 and -01 Versions of This Document 309 Reversed the order of sections 2 and 3 because the new document needs to 310 describe the basic and secure forms before describing how to find them. 312 Made SRV records mandatory and dropped the previous kludge. 314 Made using the port number from the SRV record mandatory. 316 Changed the SRV lookup to use TCP to reduce confusion between the basic 317 and secure forms. 319 Updated the reference for SRV records. 321 Significantly updated the URL registration. 323 D. Author Contact Information 325 Paul Hoffman 326 Internet Mail Consortium 327 127 Segre Place 328 Santa Cruz, CA 95060 USA 329 phoffman@imc.org