idnits 2.17.1 draft-ietf-rescap-req-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 434 has weird spacing: '...esource to...' -- 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 (June 22, 2002) is 7976 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) == Missing Reference: 'SRV' is mentioned on line 332, but not defined == Missing Reference: 'NAPTR' is mentioned on line 332, but not defined == Missing Reference: 'TLS' is mentioned on line 346, but not defined == Unused Reference: 'RFC2052' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC2168' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC2533' is defined on line 367, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2052 (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2168 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RESCAP J. Beck 3 Internet-Draft Sun Microsystems 4 Expires: December 21, 2002 June 22, 2002 6 ResCap Requirements 7 draft-ietf-rescap-req-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 21, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 A variety of resource identifiers have been widely deployed on the 39 Internet as a means of identifying various resources, services, and 40 destinations. However, a means of attaching a set of attributes or 41 characteristics to a given resource identifier and subsequently 42 assessing those attributes or characteristics has not been specified 43 and deployed. 45 Two tasks are envisioned. The first task will be to define a general 46 resolution protocol that will translate resource identifiers to a 47 list of attributes. The second task will be to define an 48 administrative model and update protocol that can be used to set up 49 and maintain the information the resolution protocol accesses. 51 This document defines the requirements for these two protocols. 53 Table of Contents 55 1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. General requirements . . . . . . . . . . . . . . . . . . . . 3 58 3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Resolution protocol requirements . . . . . . . . . . . . . . 4 60 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2 Reply data . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.3 Granularity . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.4 Expiration . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.5 Referral . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.7 Server location . . . . . . . . . . . . . . . . . . . . . . 6 67 4.8 Preferences . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.9 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.10 Replication and Synchronization . . . . . . . . . . . . . . 6 70 5. Administrative update protocol requirements . . . . . . . . 7 71 5.1 Access control . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.5 Replication and Synchronization . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 80 A. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 B. Revision history . . . . . . . . . . . . . . . . . . . . . . 9 82 B.1 Initial revision (beck-00): April 15, 1999 . . . . . . . . . 9 83 B.2 beck-00 -> beck-01: May 14, 1999 . . . . . . . . . . . . . . 9 84 B.3 beck-01 -> beck-02: June 15, 1999 . . . . . . . . . . . . . 10 85 B.4 beck-02 -> beck-02a: November 23, 1999 . . . . . . . . . . . 10 86 B.5 beck-02a -> beck-03: December 1, 1999 . . . . . . . . . . . 10 87 B.6 beck-03 -> rescap-00: December 9, 1999 . . . . . . . . . . . 10 88 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 90 1. Discussion 92 This draft is being discussed on the ResCap mailing list at 93 . Subscription requests can be sent to (send an email message with the word "subscribe" 95 in the body). More information on the mailing list along with an 96 archive of back messages is available at . 99 2. Introduction 101 An attribute is a named characteristic of a resource identifier with 102 a value that is meaningful in the context in which it is used. An 103 attribute may be requested from a ResCap server. An example of an 104 attribute might be a content type that an email address is capable of 105 receiving. 107 A capability is a named set of one or more attributes that is 108 meaningful in the context in which it is evaluated. A capability may 109 be requested from a ResCap server. An example of a capability would 110 be the complete set of content types that an email address could 111 receive. 113 A particularly important resolution service of the general type 114 described in the Abstract is one which, when given a mail address 115 identifying a particular mail recipient, will return a series of 116 attributes describing the capabilities of that recipient. This 117 differs from a directory service in that no searching or other 118 advanced query operations are involved. Likewise; this is not a 119 discovery protocol. 121 3. General requirements 123 3.1 Security 125 The protocols must include support for authenticated messages between 126 clients and servers. Specifically, it must be possible for a rescap 127 client requesting information to reliably identify the server who is 128 the source of the response. The client should be able to require a 129 server to authenticate itself. The question as to whether the server 130 is authorized to respond with the information requested is outside 131 the scope of the protocols. See the Security Considerations section 132 for more information. 134 Similarly, it must be possible for a rescap server to reliably 135 identify the client who is making the request for information. The 136 server should be able to require the client to authenticate itself. 137 The question as to whether the client is authorized to request the 138 information is outside the scope of the protocols. See the Security 139 Considerations section for more information. 141 Because the principal purpose of the protocols is the dissemination 142 of public information, support for confidentiality services is 143 explicitly not required from the protocols. Nevertheless, specific 144 attributes or capabilities may themselves be encrypted, unbeknownst 145 to the protocol. Also, local security policies may require the use 146 of a secure transport layer that includes confidentiality services. 147 See the Security Considerations section for more information. 149 4. Resolution protocol requirements 151 Throughout the rest of this section, "the protocol" refers to the 152 resolution protocol. 154 4.1 Scalability 156 The protocol must be highly scalable both for number of entries in 157 the database and number of entries per second resolved. 159 Example: Mail services with tens of millions of users could easily 160 expect tens of millions of requests per day for client attribute 161 information. 163 4.2 Reply data 165 The protocol must be able to support attributes and capabilities that 166 are arbitrarily long text or binary values. The protocol should be 167 optimized for the exchange of relatively short length resource 168 identifiers and attribute values. By way of example, the distinction 169 between short and long could be determined by whether or not the 170 request and response fit in an ordinary UDP packet. 172 Servers must either provide the information requested, provide a 173 referral indicating from where the information may be requested, or 174 indicate the information is not available. Servers may forward 175 requests on behalf of clients, but the forward must be transparent to 176 the client. 178 4.3 Granularity 180 A mechanism needs to exist whereby a subset of capabilities for a 181 resource can be fetched. I.e., the protocol request syntax should be 182 able ask for one or more features instead of all of them at once. 183 However, the client also needs to be able to ask for all capabilities 184 known to the server without naming all of them. 186 Example: A client might only want to know the S/MIME capabilities of 187 a recipient, but not care about its media features. 189 4.4 Expiration 191 Some means to indicate the expected lifetime of a capability is 192 required, so that a client application can judge whether, or when, 193 the information should be considered stale. 195 The expectation is that data will be infrequently updated, and that 196 the granularity for time-stamps would be in seconds. 198 The protocol should also support a mechanism for indicating the "last 199 changed date" of a given attribute. 201 Example: The ResCap server may believe that the recipient is only 202 temporarily unable to receive large mail messages. 204 4.5 Referral 206 Some sort of request referral mechanism is needed. In other words, 207 the protocol must support a mechanism whereby a response can indicate 208 "I don't know, but go ask the ResCap server at address X." or "use 209 the following URL to retrieve the ResCap response you requested." 210 That is, the response might be a simple DNS name, or it might be a 211 full ResCap URL. 213 Example: A server might delegate all requests for S/MIME certificate 214 information to a different server that keeps track of that type of 215 information. 217 4.6 Security 219 The protocol must be able to handle authenticated queries. The 220 protocol must also support transmission of signed and/or encrypted 221 responses. The protocol should allow for a ResCap server to hold and 222 return "pre-signed" responses. This would allow it to hold 223 capability information signed by the controller of the resource to 224 which it refers, and also to sign responses off-line to avoid the 225 need to perform signature computations at the time of responding to a 226 query. This may imply a need to apply a signature to just part of a 227 response. 229 Servers may require clients to use authenticated requests. Clients 230 are not required to be able to create authenticated queries. Such 231 clients will not be able to make requests of servers requiring 232 authenticated queries; such servers might regard this as a feature. 234 Clients may require servers to use authenticated responses. Servers 235 must be able to create authenticated responses. 237 Controls on which attributes will be announced should exist. 239 Note that consideration of transport-level security is out of scope 240 here; an appropriate mechanism such as TLS or IPSec should be used 241 instead. 243 Example: A server might give less information to a client that is 244 unauthenticated than to one that is authenticated. Some information 245 from the server may be important enough for the server to want to 246 prevent tampering, or even to prevent snoopers from reading. 248 4.7 Server location 250 DNS resource records should be used to determine a protocol server. 252 Example: The ResCap server that provides responses for resources at 253 "example.com" might itself be running on a host other than 254 "example.com", such as if the administrator of "example.com" has 255 outsourced ResCap services to another company. 257 4.8 Preferences 259 Preferences for a set of capabilities, if needed, are to be a 260 supplied in a schema-specific fashion. 262 Example: A recipient might strongly prefer image/tiff files over 263 image/jpeg because s/he can display image/tiff on his/her system 264 without launching an external application. 266 4.9 Simplicity 268 The protocol should be sufficiently simple that it allows 269 implementation of client and/or server functionality in very small, 270 low cost devices (e.g. telephones, modems, printers, smart-cards, 271 etc.). 273 4.10 Replication and Synchronization 275 We need to define the model for consistency between replicas - e.g. 276 if a client is using one replica for queries and has to fail over to 277 another, what assumptions can the client make about the consistency 278 between the two replicas? 280 We should consider whether to assume strict master-slave as this 281 choice would severely limit scalability of the service. Multi-master 282 seems preferable, but this impacts the protocol as hooks are needed 283 to allow clients to make sense of the data if they need to get it 284 from multiple servers. 286 5. Administrative update protocol requirements 288 Throughout the rest of this section, "the protocol" refers to the 289 administrative update protocol. 291 5.1 Access control 293 Authentication of anyone updating the database is required. 295 Example: Individual mail users should be able to update some or all 296 of the information about them in the database, but such updates must 297 be done with authentication to prevent others from maliciously 298 entering false information. 300 5.2 Inheritance 302 The protocol must support inheritance. Specifically, mechanisms must 303 be provided by which administrators can set default values for 304 members of their administrative domains. 306 If a change is made to a default resource capability value that has 307 previously been inherited by some other resource, then the inheritor 308 should receive the new value. 310 Example: The media features for all addresses at a particular mail 311 server might be the same because the mail server processes all 312 messages at all addresses. 314 5.3 Scalability 316 The protocol must support atomic processing of request messages. 317 This processing does not include updating any replicated sources for 318 the information nor. The client should receive a completion response 319 from the server, but the underlying protocol (if used over UDP) might 320 require the client to retransmit its request at appropriate intervals 321 until it receives such a response. 323 5.4 Security 325 The protocol must include support for authenticated messages. 326 Servers and clients must use authenticated requests and responses to 327 effect changes to attributes or capabilities. 329 5.5 Replication and Synchronization 331 SRV and/or NAPTR resource records may be used to determine a protocol 332 server. [SRV, NAPTR] 334 6. Security Considerations 336 Security issues are discussed in sections 2.1, 3.6, 4.1 and 4.4 of 337 this memo. 339 It is also worth noting that the data which these protocols will be 340 designed to deal with are meant to be public, not private. 342 However, support for authentication should be included in the 343 resolution protocol to permit administrators to restrict the 344 attributes that are returned in response to a request according to a 345 locally specified security policy. The security policy may require 346 the use of a transport security protocol, e.g., TLS [TLS], to provide 347 additional security services not supported by these protocols. 349 7. Acknowledgements 351 The author would like to thank Paul Hoffman, Graham Klyne, Ned Freed, 352 James Galvin and Keith Moore for their assistance. 354 References 356 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 357 location of services (DNS SRV)", RFC 2052, October 1996. 359 [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform 360 Resource Identifiers using the Domain Name System", RFC 361 2168, June 1997. 363 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. 364 and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 365 January 1999. 367 [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", 368 RFC 2533, March 1999. 370 Author's Address 372 John Beck 373 Sun Microsystems 374 901 San Antonio Road M/S U-MPK-17-202 375 Palo Alto, CA 94303-4900 376 US 378 Phone: +1-650-786-8078 379 EMail: john.beck+rescap@sun.com 381 Appendix A. Issues 383 1. Does section 3.6 need further clean-up, particularly the first 384 paragraph? 386 2. Are sections 4.1 and 4.4 redundant? 388 3. Section 3.10 currently lays out no requirements, but asks some 389 questions and raises some issues which need to be addressed in 390 order for the proper requirements to be determined. 392 Appendix B. Revision history 394 B.1 Initial revision (beck-00): April 15, 1999 396 B.2 beck-00 -> beck-01: May 14, 1999 398 o Added note to Abstract about this not being a discovery protocol. 400 o Examples added throughout. 402 o Section 1.2 renamed from "Long replies" to "Reply data", and 403 clarified. 405 o Clarified section 1.4, and added note about support for a "last 406 changed date". 408 o Section 1.6 renamed from "Privacy" to Security, and clarified, 409 largely by absorbing section 2.2 (Privacy). As a result, section 410 2.3 (Inheritance) renumbered to 2.2 . 412 o New section 4 (Acknowledgements) added, and old sections 4 413 (References) and 5 (Author's Address) renumbered to 5 and 6. 415 B.3 beck-01 -> beck-02: June 15, 1999 417 o New section 1.9 (Simplicity) added. 419 B.4 beck-02 -> beck-02a: November 23, 1999 421 o Added notes about infrequent updates and granularity of seconds to 422 section 1.4 (Expiration). 424 o Added note about transport-level security being out of scope to 425 section 1.6 (Security), and did some word-smithing. 427 o Section 1.7 (Server location): specific references to SRV and 428 NAPTR replaced by general reference to DNS. Deleted corresponding 429 references from section 5 (References). Also rewrote example in 430 section 1.7 . 432 o Section 1.8 (Preference) changed to be schema-specific. 434 o Added note about the effect of changing a default resource to 435 section 2.2 (Inheritance). 437 o Added note about public vs. private date to section 3 (Security 438 Considerations). 440 o Added appendix X (Revision history). 442 B.5 beck-02a -> beck-03: December 1, 1999 444 o New section 1 (Introduction) and 2 (General requirements); old 445 sections 1 through 6 renumbered to 3 through 8. 447 o New section 4.3 (Scalability) added. 449 o Section 3.2 (Reply data) rewritten. 451 B.6 beck-03 -> rescap-00: December 9, 1999 453 o ResCap is now a WG, so document name changes. 455 o Added note about authentication to Security Considerations. 457 o Added appendix I for open issues. 459 o Added sections 2.1 and 4.4, and added to 3.6 (all on Security). 461 o Added sections 3.10 and 4.5 (on Replication and Synchronization). 463 Full Copyright Statement 465 Copyright (C) The Internet Society (2002). All Rights Reserved. 467 This document and translations of it may be copied and furnished to 468 others, and derivative works that comment on or otherwise explain it 469 or assist in its implementation may be prepared, copied, published 470 and distributed, in whole or in part, without restriction of any 471 kind, provided that the above copyright notice and this paragraph are 472 included on all such copies and derivative works. However, this 473 document itself may not be modified in any way, such as by removing 474 the copyright notice or references to the Internet Society or other 475 Internet organizations, except as needed for the purpose of 476 developing Internet standards in which case the procedures for 477 copyrights defined in the Internet Standards process must be 478 followed, or as required to translate it into languages other than 479 English. 481 The limited permissions granted above are perpetual and will not be 482 revoked by the Internet Society or its successors or assigns. 484 This document and the information contained herein is provided on an 485 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 486 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 487 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 488 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Acknowledgement 493 Funding for the RFC Editor function is currently provided by the 494 Internet Society.