idnits 2.17.1 draft-ietf-rescap-rc-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (28 February 2002) is 8093 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1491, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2915 (ref. '2') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2570 (ref. '6') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2251 (ref. '7') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2222 (ref. '9') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2168 (ref. '11') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-08 ** Obsolete normative reference: RFC 1831 (ref. '13') (Obsoleted by RFC 5531) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet-Draft University of Tennessee 3 Expires: 28 August 2002 28 February 2002 5 The Resource Catalog 7 draft-ietf-rescap-rc-01.txt 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Comments regarding this internet-draft should be sent to the mailing 28 list of the IETF rescap working group. Refer to the IETF web site at 29 http://www.ietf.org/ for current contact information for IETF working 30 groups. Please include the document identifier 31 "draft-moore-rescap-rc-01.txt" in any comments regarding this document. 33 Abstract 35 This memo describes version 3 of the Resource Catalog. The Resource 36 Catalog (RC) is a service for storing and obtaining metadata that 37 describes network-accessible resources. This service is primarily 38 intended for use by clients prior to accessing, or attempting to access, 39 a particular resource. The RC service may thus be used (for example) to 40 inform a client as to which of a variety of features are supported by 41 the resource, or which methods may be used to access the resource, or 42 which of a small set of locations may be used to access the resource. 44 1. Introduction 46 This memo describes version 3 of the Resource Catalog. The Resource 47 Catalog is a service for storing and obtaining metadata that describes 48 network-accessible resources. This service is primarily intended for 49 use by clients prior to accessing, or attempting to access, a particular 50 resource. The RC service may thus be used (for example) to inform a 51 client as to which of a variety of features are supported by the 52 resource, or which methods may be used to access the resource, or which 53 of a small set of locations may be used to access the resource. 55 A 'network-accessible resource' is potentially any resource which is 56 accessible on the network and which has a distinguished name (probably a 57 URI) by which the metadata can be queried. Such resources could 58 potentially include downloadable files, web pages, electronic mailboxes 59 (including voice and fax mailboxes), instant messaging mailboxes, real- 60 time text, voice, and/or video conferencing terminals, hosts, routers, 61 etc. 'Metadata' are represented as name-value pairs, each of which 62 describes some aspect of the resource. 64 NB: The above examples of resources are intended only as illustration 65 of the flexibility of this approach. It is not expected that RC would, 66 if adopted, be used in all of these contexts (or for that matter, in any 67 particular context.) Each application or service using RC as a 68 component would need to have an explicit definition for the metadata and 69 specific use of RC within that application or service, prior to 70 deployment of code. 72 Earlier versions of the Resource Catalog were designed for use in 73 research projects dealing with replicating network-accessible content 74 and distributed software repositories. This version of the Resource 75 Catalog builds on experience with those earlier efforts, and is intended 76 to be suitable for standardization and widespread deployment. 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [1]. 82 2. Design Goals and Implications 84 Given the overall intended purpose of the service as described above 85 (and in the charter of the rescap working group) RC version 3 was 86 designed with several specific goals in mind. These are reflected in 87 the protocol design as follows: 89 2.1. Federation 91 Ideally, the owner of a resource being described should be able to 92 control the metadata used to describe that resource within RC. Such 93 control would be hampered if RC were a centralized service; this would 94 also impact RC's scalability. It is therefore desirable for the owner 95 to be able to control both the cost and the quality of the RC service 96 which describes his/her/its resources. 98 The RC service is therefore federated according to resource name; it is 99 assumed that the network addresses of the servers that provide 100 authoritative metadata describing a particular named resource are 101 somehow obtainable from that name. RC uses NAPTR [2] and SRV [3] 102 records to locate the RC servers for URIs which contain embedded DNS 103 names. Similar mechanisms would need to be defined for other kinds of 104 resource names (as for instance the URN working group is defining 105 resolution mechanisms for URNs, and the ENUM working group is currently 106 defining a means of finding metadata associated with telephone numbers). 108 This approach further allows the maintainer of a DNS zone to specify the 109 locations of RC services for resource names for which the SRV records 110 are located in that zone; thus, the RC servers corresponding to a 111 particular resource name can be provided locally, outsourced, or some of 112 each. This further implies that "RC service provider" and "resource 113 owner" are different roles, and that the capability to manipulate 114 resource attributes must therefore be delegated to the resource owner 115 through a standard interface. 117 The need to be able to outsource RC services also implies that an RC 118 query must self-contained, i.e. that no part of the question being asked 119 is implicit in the choice of a server to which the question is being 120 presented. 122 It is of course likely that the owner of a resource does not control all 123 of the DNS zones which are traversed in the process of finding the RC 124 servers for a resource name. And while it is hoped that DNS names will 125 continue to be easily obtainable and inexpensive, some kinds of resource 126 names (such as URNs) inevitably lessen owner control of the resource 127 name in order to obtain increased stability of those names. For this 128 reason, and because the RC service provider may be independent of the 129 resource owner, RC provides the capability for resource owners to 130 digitally sign any of the metadata associated with a resource. 132 2.2. Fast response to client queries 134 As RC is intended for use prior to accessing a resource, RC queries will 135 tend to increase the overall time required to access that resource. It 136 is therefore essential that RC provide fast response. This implies that 137 server operations should be cheap in terms of CPU cycles. It further 138 implies (in the case of low bandwidth links) that payloads and protocol 139 overhead are small and (in the case of long delay links) that 140 unnecessary round-trips are avoided. 142 To this end, RC queries are designed to run over UDP and to require a 143 single UDP datagram in each direction. Servers MAY also support TCP as 144 a transport. RC is also optimized for small payloads, and it attempts 145 to impose minimal protocol overhead. RC also provides a number of 146 features designed to minimize the transmission of unnecessary response 147 data, including the ability to query several named attributes in a 148 single transaction, and the ability to specify whether signatures (and 149 which types of signatures) should be returned with the response. 151 2.3. Scalability to large numbers of reading clients 153 If RC is used to provide essential metadata for heavily-used resources 154 it potentially imposes a barrier to access of those resources. The 155 scalability of access to those resources would thus be limited by the 156 scalability of RC. It is therefore necessary that RC be scalable to 157 handle large numbers of reading clients. RC attempts to achieve this 158 by being implementable with minimal server overhead, and by allowing RC 159 queries to be distributed over several replicated RC servers, with a 160 well-defined model for consistency between servers. 162 2.4. Ease of implementation 164 In order to allow for quick deployment, the RC protocol is designed to 165 be simple and easy to implement, and for simple implementations to 166 perform acceptably on modern CPUs with moderate workloads. However it 167 is naturally expected that high performance implementations will be more 168 complex and more difficult to implement. 170 2.5. Security 172 RC is designed with consideration of the following security threats: 174 - Attempts by unauthorized parties to write metadata to servers. 176 RC servers require writers (and optionally readers) to authenticate 177 themselves via secure means; such requests will not be processed 178 unless the authentication credentials can be verified. 180 - Attempts to obtain authentication credentials via the network, via 181 active or passive attacks. 183 The RC protocol allows for multiple authentication methods in order 184 to accommodate the needs of different environments, and to 185 accommodate additional authentication methods which might be 186 defined in the future. 188 - Attempts to replay a previously successful write request for the 189 purpose of modifying metadata in unauthorized ways. 191 Requests to update metadata include a serial number which must 192 always be larger than the serial number of the previous request to 193 update the metadata for that resource. This serial number is 194 authenticated and checked for integrity along with the rest of the 195 request. Attempts to replay write requests can therefore be 196 detected, and unauthorized changes to the metadata avoided. 198 - Attempts to add, delete, or alter data in a response 200 RC allows (but does not require) writers to cryptographically sign 201 metadata that are stored in a server. Reading clients may (but are 202 not required to) request such signatures, attempt to verify them, 203 and determine whether the party signing the metadata is authorized 204 to make such assertions about the resource. However such 205 signatures are opaque to RC servers; the RC protocol does not 206 attempt to verify signatures that are stored with a resource. 208 When TLS [4] is used, the integrity protection provided by TLS will 209 allow a client to detect responses altered in transit. However 210 there is no requirement that TLS be used; furthermore, the protocol 211 setup and server CPU overhead associated with TLS serve as 212 disincentives to use of TLS. 214 - Removal of signatures from responses 216 When TLS is used, the integrity protection provided by TLS will 217 allow a client to detect responses altered in transit. However 218 there is no requirement that TLS be used and there are 219 disincentives to use TLS. 221 NOTE: The protocol described in this document, could, with a very 222 small modification, allow clients to request server-provided 223 signatures on responses. Such signatures would not authenticate 224 the response as coming from an authoritative source, but would 225 serve to thwart this and other attacks that alter responses. If 226 used frequently, such a facility would greatly increase server 227 load, but probably no worse than if TLS were used frequently. On 228 the other hand, to be effective this would also require that the 229 client have a secure means of knowing that a server signature on 230 the response should be expected, and a means of verifying that 231 signature. 233 RC does not attempt to ameliorate the following threats: 235 - Attempts to direct clients to send queries to unauthorized servers 237 Even if unauthorized servers contain data which are signed by 238 authoritative sources, the data provided by unauthorized servers 239 may be stale or obsolete. 241 When DNS SRV and address records are used to direct queries to RC 242 servers, DNSSEC may be useful in authenticating such records to 243 clients. 245 NOTE: TLS server certificates could be used by the client to 246 determine whether the server can authentically claim to operate on 247 behalf of a particular DNS name. However, authority to operate on 248 behalf of a DNS name does not necessarily imply authority to supply 249 information about a resource name, particularly when the server 250 operator may not be authoritative to make assertions about a 251 particular resource, even if the server is the correct one to 252 consult for information about that resource. (e.g. the RC service 253 might be outsourced) 255 - Repudiation of unsigned assertions 257 - Alteration of unsigned responses 259 - Threats which require physical access to server hardware 261 - Attempts to interfere with service by interfering with the 262 transmission of requests or responses over the network 264 - Attempts to interfere with service by flooding the server with 265 requests 267 2.6. Provision for proxies 269 Due to the large number of environments which separate local users from 270 the public Internet with firewalls, and the anticipated use of this 271 protocol to describe public Internet resources, it is essential that RC 272 be usable through intermediaries. 274 2.7. Flexibility 276 RC is intended as a framework which can be used by a wide variety of 277 applications and services, to store information about many different 278 kinds of resources. The protocol therefore needs to be flexible enough 279 to accommodate different applications' needs regarding (for instance) 280 metadata size, rates of change, and security. 282 The feature-set included in RCv3 was selected based on observations from 283 other information query protocols which have been in use for many years, 284 as well as experience with earlier versions of RC. 286 DNS Though the resemblance may not be obvious, in many ways RC is 287 heavily influenced by DNS [5]. Like DNS, RC is federated, handles 288 multiple query types, and provides the ability to return 289 "additional information" in response to a query. In addition, both 290 RC and DNS provide signatures and the capability to support 291 multiple signature types. RC and DNS have similar models for 292 replication, with the RC replication granularity being that of a 293 resource name and the DNS replication granularity being that of a 294 zone. 296 However, RC attempts to generalize a number of DNS features. In 297 particular, RC servers have no knowledge of the characteristics of 298 attribute names (corresponding to DNS resource record types and 299 query types). RC servers determine whether to perform "additional 300 information" lookups based on explicit instructions in the query, 301 rather than based on knowledge of the attribute name. Neither do 302 RC servers have knowledge of signature types; signatures are opaque 303 to the servers. Server processing of signatures in RC is limited to 304 storing signatures that are supplied by writers and returning 305 signatures to readers who ask for them. Finally, RC decouples the 306 notion of "server ownership" from "resource name ownership" - the 307 owner of the server is not inherently considered an authoritative 308 source of information about any particular resource. 310 SNMP In some ways the service provided by RC is similar to that of an 311 SNMP [6] agent. In particular, RC borrows from SNMP the capability 312 to query aggregates of individually addressable resource 313 attributes, where the aggregates are based on the structure of the 314 names. However whereas SNMP uses ASN.1 object-identifiers (OIDs) 315 for attribute names, RC uses human-readable ASCII strings. RC also 316 separates resource names from attribute names rather than combining 317 the two into a single name. Finally, RC lacks an analog to SNMP's 318 trap mechanism, RC's information model is simpler than SNMP's SMI, 319 and RC uses a simple presentation layer and RPC mechanism in 320 contrast to SNMP's ASN.1 PDUs. 322 LDAP RC is heavily influenced by LDAP [7] in that RC avoids many of the 323 design choices in LDAP which impose a barrier to the use of LDAP in 324 applications for which RC is designed. In particular, 326 - RC allows the use of UDP to avoid the delay and bandwidth 327 consumption associated with TCP connection setup 329 - RC uses a simpler data model than ASN.1, and a simpler 330 presentation encoding than BER, for ease of implementation and 331 improved processing efficiency 333 - RC provides lookup by resource name, but not searching of 334 contents, for server efficiency and scalability 336 - RC provides the ability to query for and return "additional 337 information" based on results of the initial query, thus 338 avoiding multiple round-trips 340 - RC has support for caching of data returned from queries 342 - RC defines a model for consistency between replicas which is 343 usable by applications 345 3. Data Model 347 3.1 Format of resource descriptions 349 RC models the description of a resource (its "metadata") as a set of 350 (name, value) pairs called assertions. Each assertion consists of: 352 - an attribute name, which is a human-readable character string; 354 - a value, which is often human-readable, but can potentially be any 355 sequence of octets; 357 - an optional time-to-live; and 359 - an optional expiration-date. 361 The time-to-live is some number of seconds from the present time during 362 which the assertion is expected to remain valid. The expiration-date is 363 an absolute time at which the assertion will no longer be valid. Both 364 time-to-live and expiration-date may be supplied, in which case both 365 limitations to the validity of the assertion apply. This allows an 366 assertion to expire "gracefully" at a particular time without the server 367 having to explicitly decrease times-to-live as the expiration time 368 approaches; it also allows the expiration time to meaningful in a signed 369 assertion. 371 3.1 Caching 373 Intermediaries (e.g. proxies) MAY cache assertions and return cached 374 assertions in response to queries for specific resource_names during the 375 expected lifetime of the assertions. However, all cached assertions 376 about a resource_name which are returned in a query response MUST have 377 been obtained from the same version of the description of that resource. 378 Intermediaries MUST NOT return cached responses to wildcard queries 379 unless those responses were returned from an earlier wildcard query of 380 greater or equal scope (i.e. a shorter prefix of the resource name) than 381 the current query. 383 3.2 Consistency between replicas 385 RC services for a particular portion of URI-space MAY be replicated so 386 that queries, updates, or other operations within that portion of URI- 387 space can be issued to any of the replicas. A standard mechanism for 388 replication between servers is not yet defined, but individual 389 implementations MAY define their own mechanisms for doing so. 391 When the description of a resource is replicated between RC servers, the 392 servers MUST maintain the appearance of a linear change history for the 393 entire resource description across all of the servers. In other words, 394 it is not acceptable for separate changes to be made to different 395 replicas of the resource description. Servers MAY impose requirements 396 on writers in order to facilitate this (e.g. they may require that all 397 updates be sent to a single master server). 399 Replicated RC servers SHOULD make reasonable efforts to be synchronized 400 with one another. 402 3.3 Permission model 404 RC is intended for the dissemination of public information. It is 405 possible for servers to refuse to answer queries sent by non- 406 authenticated parties or to specific parties who authenticate 407 themselves, and it is possible for servers to omit information from the 408 responses of queries sent by unauthorized parties. Until the effect of 409 such restrictions on caching is understood, servers SHOULD NOT restrict 410 the ability of parties to query information. 412 RC servers which support the Update operation MUST be able to prevent 413 unauthorized parties from updating information about a particular 414 resource; however, the granularity with which this is done is not 415 currently defined. Servers MAY restrict the ability to update 416 particular resource names, as well as particular attribute names. 417 However, perhaps unfortunately, the currently defined status reporting 418 mechanism provides little information about why an update attempt 419 failed. 421 4. Protocol 423 The protocol is defined in terms of RPC operations. Each operation is 424 defined in terms of an request structure, result structure, and side- 425 effects that take place when a valid request is received. The 426 structures are defined using the example abstract syntax from the Binary 427 Low-Overhead Block (BLOB) protocol (see [8], Appendix B), and BLOB is 428 used as a presentation format. 430 The first scalar integer of each request is used as a request_type. This 431 allows different types of requests to be distinguished from one another. 432 The first string of each request is a request_id which is used to 433 associate responses with requests. 435 The first scalar string of each response is the request_id from the 436 request. The first scalar integer of each response is the status of the 437 request. 439 4.1 Protocol Evolution and Version Negotiation 441 For most purposes, RC is designed to be used in a stateless manner, 442 without the need for an explicit "connection setup". Explicit 443 negotiation of the RC protocol version or features between client and 444 server would increase the time required to perform RC operations. To 445 the extent feasible, new versions of RC should continue to support 446 request_types from previous versions of the protocol. If it is 447 important to make clients aware of new server features, it might be 448 preferable to advertise such information to clients via SRV or NAPTR DNS 449 records rather than to force the client to negotiate a protocol version 450 on each interaction with an RC server. 452 However, the request_type field of each request can be considered to 453 contain an implicit version number. If it becomes necessary for future 454 versions of RC to deprecate existing request_types, servers can return a 455 RC_PROTO_MISMATCH response to any unsupported request_type. This 456 response contains both protocol version information and a list of 457 supported request_types. 459 Request_type 0 is reserved and can be used by a client to force an 460 Unsupported Request response to be returned. 462 4.1.1 Unsupported request response structure 464 The Unsupported Request response structure is as follows: 466 BEGIN unsupported_request_response 467 string request_id 468 int status 469 int protocol_version 470 int<> supported_requests 471 END 473 This structure is returned in response to any request with an unsup- 474 ported request_type. 476 request_id 477 This is the request_id from the request. 479 status 480 This will normally be RC_UNSUPP_REQUEST. 482 protocol_version 483 This is the highest version of the RC protocol supported by the 484 server. This document describes version 3. 486 supported_requests 487 This is an array of integers indicating the range of request_types 488 supported. The integers are in pairs indicating higher and lower 489 bounds of a range of supported request_types. For instance, an 490 integer array [ 1 4 6 6 10 12 ] would indicate that request_types 491 1-4 inclusive, 6, and 10-12 inclusive were the only ones supported. 493 Note on caching of supported request_types: In principle servers 494 can be up- or downgraded at any time and with no notice. It is 495 therefore not safe for a client to assume that the set of 496 request_types supported by a server will remain constant. Clients 497 MUST therefore be prepared to handle a RC_UNSUPP_REQUEST in 498 response to any request which is not required by this specifica- 499 tion. For a client which can utilize additional request_types if 500 they are supported by the server, a cached list of request_types 501 may prove to be a useful performance optimization. In order to 502 allow clients to discover new server request_types in a timely 503 fashion, clients which can utilize additional request_types (beyond 504 those which are required of servers) SHOULD discard cached 505 request_types after a suitable interval, say a few hours. 507 4.2 Operations 509 The following operations are defined: 511 4.2.1 Query operation 513 The Query operation returns information describing the named resource. 515 4.2.1.1 Query request structure 517 The Query request structure is defined as follows: 519 BEGIN query_request 520 int request_type # QUERY=1 521 string request_id 522 string resource_name 523 string<> attribute_names 524 int<> attribute_flags 525 # QUERY_RECURSE = 01 526 # WANT_SIGNATURES = 02 527 int<> signature_types 528 END 530 The meanings of the individual fields are outlined below. 532 request_type 533 A request_type of 1 indicates a Query request. 535 request_id 536 The request_id is used to associate the response with the request. 537 This is a string which is chosen to be unique for the client's IP 538 address and port pair, for any amount of time during which any 539 request from that host and port pair is likely to be pending or 540 during which a response may be traveling through the network. It is 541 RECOMMENDED that request_ids not be reused within at least an hour. 543 The contents of the request_id are otherwise undefined; client 544 implementations MAY generate them however they wish. (however see 545 the Security Considerations section). 547 resource_name 548 The name of the resource for which information is being requested; 549 for instance, a URI. This field MUST be present. 551 attribute_names, attribute_flags 552 These fields are parallel arrays. attribute_names specifies the 553 names of the attributes which are being requested for the resource, 554 while attribute_flags specifies optional query features desired for 555 each attribute_name. attribute_flags[i] thus specifies the 556 optional query features for attribute_names[i]. These two arrays 557 MUST have the same number of elements, and servers MUST return an 558 RC_DATA_FMT error in response to a Query operation for which the 559 number of elements in these two arrays is different. 561 Currently defined attribute_flags are as follows: 563 - The QUERY_RECURSE bit controls searching for additional 564 information; see section 4.2.1.6 below. 566 - The WANT_SIGNATURES bit requests signatures for this 567 attribute; see section 4.2.1.7 for a discussion of signatures. 569 These flag bits can be ORed together to request both features. 571 Note: as hinted in section 2.5, a WANT_SERVER_SIGNATURE bit could 572 be added here to request that the server sign the response. This 573 would provide some protection against attacks that modify the 574 response but would not by itself guarantee that the response came 575 from an authoritative party. 577 An attribute_name that ends in "*" is a wildcard; see section 578 4.2.1.8. 580 signature_types 581 The list of signature_types which are understood by the caller. 582 Values for individual signature_types are to be defined. 584 4.2.1.2 Query result structure 586 The Query result structure is as follows: 588 BEGIN query_response 589 string request_id 590 struct<> answers 591 END 593 request_id 594 This is the request_id from the Query structure, used to associate 595 the response with the request. 597 answers 598 The list of answers. Each answer contains the results of the query 599 for a particular resource_name. The first answer is the one for 600 the resource_name which was explicitly part of the Query structure. 601 Any additional answers are the result of additional queries 602 requested via the QUERY_RECURSE flag. 604 4.2.1.3 Answer structure 606 Each Answer is formatted as a blob using the following structure: 608 BEGIN answer 609 string resource_name 610 int query_status 611 int version_hi 612 int version_lo 613 struct<> assertions 614 struct<> signatures 615 END 617 Within an answer are the following fields: 619 resource_name 620 The resource_name for which the following assertions are made. 622 query_status 623 A code describing the result of the attempt to query this 624 resource_name. See section 3.5. 626 version_hi, version_lo 627 An 8-byte version number (treated as a single 8-byte integer, but 628 represented for the purpose of presentation as two 4-byte integers) 629 for the resource information. The version number increases (not 630 necessarily by 1) each time the resource is modified. 632 assertions 633 This is an array of blobs, each of which contains information about 634 the named resource. The structure of an assertion is defined 635 below. 637 signatures 638 This is an array of blobs, each of which contains a signature over 639 some set of assertions. The structure of signatures is defined 640 below. 642 4.2.1.4 Assertion structure 644 An assertion has the following structure: 646 BEGIN assertion 647 string name 648 string value 649 int ttl 650 int expire_date_lo 651 int expire_date_hi 652 int flags 653 END 655 name This is the name of the attribute. 657 value 658 This is the value associated with the attribute name. 660 ttl, expire_date_* 661 The ttl and expire_date describe the lifetime during which the 662 information is expected to be valid (and during which it may be 663 cached by intermediaries). 665 The ttl field is the number of seconds during which the assertion 666 is expected to be valid; if the ttl field is 0x7fffffff (2**31 - 1) 667 then no TTL is assumed. 669 The expire_date_* fields contain an absolute expiration date. 670 expire_date_hi contains the day of expiration, expressed as the 671 number of whole days (60*60*24 second periods) since Jan 1, 1970 672 UTC. expire_date_lo contains the number of seconds within the day 673 following the number of days in expire_date_hi. Any leap days 674 which have occurred or will occur prior to the expiration date are 675 included in expire_date_hi. Any leap seconds which have occurred or 676 will occur prior to the expiration date are included in 677 expire_date_lo. Note that expire_date_lo can therefore be greater 678 than 86400 seconds. However most applications will not need that 679 degree of precision, and most applications cannot count on having 680 their clocks synchronized to that degree of precision. An 681 application supplying expiration dates to RC MAY fail to consider 682 leap seconds in its calculations if the loss of precision is not 683 considered significant for that application. If expire_date_hi and 684 expire_date_lo are both zero, no expiration date is assumed. 686 flags 687 These are single-bit characteristics of the attribute. They are for 688 future use. 690 4.2.1.5 Signature structure 692 Signatures which can be used to verify authenticity and integrity of the 693 assertions. Each signature is a blob formatted according to the 694 following structure: 696 BEGIN signature 697 int<> component_list 698 int algorithm 699 struct bits 700 END 702 component_list 703 This is an ordered list of the indices, relative to the start of 704 the assertions array from the answer, of the assertions that are 705 signed by this signature. The first assertion of the answer is 706 always index 0, even even if the implementation language uses one- 707 based arrays. 709 Note that the contents of the assertions are signed, and the 710 indices are NOT signed. The indices have no significance outside 711 of a particular Answer to a Query. 713 algorithm 714 This is an integer which specifies both the method for translating 715 a resource_name, version_hi, version_lo, and an ordered list of 716 assertions into a single linear octet string, and the digital 717 signature algorithm used to create and verify the signature. 719 bits This is the actual signature, formatted according to the algorithm 720 defined by the signature algorithm. 722 A signature is verified by concatenating the names and values of the 723 assertions in a manner specified by the signature algorithm, and then 724 verifying the result of that concatenation against the bits field, again 725 according to the manner specified by the signature algorithm. NOTE: ttl 726 fields of assertions are NOT considered in signature calculations. 728 4.2.1.6 Recursive Processing 730 If the QUERY_RECURSE bit of attribute_flags[i] is set, it signifies that 731 if any attribute_values matching attribute_names[i] are found, they are 732 to be interpreted as resource_names, and additional queries (using the 733 same set of attribute_names and attribute_flags as the original query) 734 are performed for those resource names. The server may decline to 735 service such "additional information" requests for any reason, including 736 for example that the server does not have authoritative information for 737 the resource name, or the query is being made by UDP and the result does 738 not fit within a reasonable UDP packet size, or processing of the 739 additional query would likely cause the caller's retransmission timer to 740 expire. 742 It is possible that an attribute_value of some answer will contain a 743 resource_name for which results have already been obtained while 744 processing this request (either because the resource_name was explicitly 745 listed in the query or because it appeared in the result of a field for 746 which QUERY_RECURSE was set). Servers MUST NOT return multiple sets of 747 answers for the same resource_name in the response to a single Query 748 operation. 750 4.2.1.7 Signature Processing 752 When any of the attributes in a Query operation has an attribute_flags 753 field with the WANT_SIGNATURES bit set, the server will return, along 754 with the attribute information, any signatures which cover the attribute 755 and which are included in the list of signature_types that the client 756 understands. If those signatures include other attributes which are not 757 requested, those attributes are also included in the response. Thus a 758 response may include more attributes than requested. 760 If the list of signature_types is empty but WANT_SIGNATURES is set for 761 any attribute, the server will return all available signatures for that 762 attribute. 764 A server MAY omit signatures (and the attributes needed to verify those 765 signatures) if including them would make the result too large for 766 transmission over UDP; however, inclusion of signatures takes precedence 767 over QUERY_RECURSE processing. 769 4.2.1.8 Wildcard attribute names 771 For the purposes of a query, an attribute_name ending in the character 772 '*' (ASCII 2A hex) causes information to be returned for each of the 773 attribute_names in the resource which begin with the portion of the 774 attribute_name prior to the '*'. The character '*' MUST NOT appear in 775 an attribute_name parameter of a Query operation except as the last 776 character. Issuing a query for an attribute_name of "*" causes all 777 attributes to be returned. 779 4.2.2 Update operation 781 Note: the rescap charter states that the update protocol is part of the 782 "second task" of the group's activity which has not yet begun. A sample 783 update protocol is included here only for the purpose of illustrating 784 how Query and Update might work together. This part of the 785 specification is therefore, for the time being, incomplete. 787 The Update operation may be used to add attributes, change the values 788 associated with attributes, or delete attributes from the set of 789 attributes associated with a URI. The Update protocol may also be used 790 to add or delete signatures to sets of attributes. Servers SHOULD 791 support the Update protocol, but MAY provide alternate means to perform 792 these operations than via the Update protocol. 794 4.2.2.1 Update request structure 796 The Update request structure is as follows: 798 BEGIN update_request 799 int request_type # UPDATE = 2 800 string request_id 801 int version_hi 802 int version_lo 803 string resource_name 804 int flags 805 # UPDATE_CREATE_NEW = 01 806 # UPDATE_VERSION_MATCH = 02 807 # UPDATE_CLOBBER_SIGS = 04 808 struct<> assertions 809 struct<> signatures 810 END 812 request_type 813 For an Update operation, the request_type is 2. 815 request_id 816 This is used to associate the response with the request. See the 817 definition of request_id for the Query operation. 819 version_hi, version_lo 820 These is the version number which the client expects corresponds to 821 the server's current version number for that resource. If the 822 UPDATE_VERSION_MATCH flag is set, this version number is compared 823 with the server's version number. Otherwise, version_hi and 824 version_lo are ignored. 826 The server will increase the version number (as represented by 827 version_hi and version_lo), with each successful Update operation, 828 by a small positive integer, using addition modulo 2**64. The 829 amount added to the version number need not be a constant, but MUST 830 be sufficiently small that no version number will be reused (due to 831 wrap-around) within ten years. 833 Clients MUST NOT use UPDATE_VERSION_MATCH to update portions of a 834 resource's metadata if the version of the record they have 835 previously obtained is more than than a year old or is of uncertain 836 age. In such cases it is necessary to first perform a Query 837 operation and compare the actual data (not merely the version 838 fields) to determine whether the data has been changed. 840 resource_name 841 The resource name for which attributes will be updated. 843 update_flags 844 If the UPDATE_CREATE_NEW flag is set, and no record for 845 resource_name exists, this requests that a new record be created. 847 If the UPDATE_VERSION_MATCH flag is set, the update fails with 848 status VERSION_MISMATCH unless the version_hi and version_lo field 849 of the Update request match the version_hi and version_lo fields of 850 the existing record. A nonexistent record (before it is created) 851 is treated as if version_hi and version_lo were set to zero. 853 If the UPDATE_CLOBBER_SIGS flag is not set, and the update would 854 modify some attributes covered by a signature without modifying all 855 of those attributes, the operation fails with status 856 WOULD_CLOBBER_SIGS. Setting the UPDATE_CLOBBER_SIGS flag causes 857 the signature to be deleted if the update would otherwise be 858 successful. 860 assertions 861 This is the list of assertions about resource_name to be added to, 862 changed, or deleted, formatted according to the "assertions" 863 structure defined above. The assertions are updated as follows: 865 - If there is no assertion matching the attribute_name, the 866 assertion from the Update request is added 868 - If there is already an assertion matching the attribute_name, 869 the assertion from the Update request replaces the previous 870 one from that principal. however, if the ttl field in the 871 Update request is 0, the previous assertion is deleted. 873 - If the attribute_name ends in '*', the Update operation 874 applies to all attributes beginning with the prefix of the 875 attribute_name. However, this can only be used to delete old 876 assertions (by setting ttl=0) or to update their ttls (by set- 877 ting ttl to something other than 0) and expiration dates (by 878 setting these to something other than 0). Thus it is possible 879 to update the ttl and/or expiration date of all assertions 880 associated with a resource_name in a single Update operation. 882 signatures 883 The signatures included in the update. Each of the components of 884 the signature (in component_list) is an index into the assertions 885 array. Signatures can only be provide for assertions included in 886 the Update operation; if it is needed to sign assertions that are 887 already included in the record, they must first be obtained using a 888 Query option and then the signatures supplied using an Update 889 operation (probably with the MATCH_VERSION option set). 891 4.2.2.2 Update response structure 893 The Update response structure is as follows: 895 BEGIN update_response 896 string request_id 897 int status 898 END 900 The update response is a single status code. The entire Update 901 operation either succeeds or fails atomically. Keeping this structure 902 simple makes it easier to handle retransmitted Update requests without 903 performing multiple Updates - the server only has to remember the status 904 of the most recently transmitted request, for that resource_name, from 905 any party authorized to Update that resource. 907 4.2.3 One-Shot Authenticate operation 909 The One-Shot Authenticate operation is used to authenticate another 910 request via a lightweight mechanism. It is intended for use with 911 requests (such as Update) which require authentication, when the 912 enclosing transport does not provide sufficient authentication. 913 However, it MAY be used over any transport, including bare TCP or UDP. 915 The One-Shot Authenticate operation only authenticates a single 916 operation; it DOES NOT establish authentication for subsequent 917 operations between those parties. 919 4.2.3.1 One-Shot Authenticate request structure 921 The Authenticate request structure is as follows: 923 BEGIN one_shot_authenticate_request 924 int request_type # ONE_SHOT_AUTHENTICATE = 3 925 string request_id 926 string authentication_type 927 struct authentication_credentials 928 int serial_number_hi 929 int serial_number_lo 930 struct inner_request 931 END 933 request_type 934 For One-Shot Authenticate, the request number is 3. 936 request_id 937 See request_id as described for the Query operation. 939 authentication_type 940 The type of one-shot authentication used. These are to be 941 determined. Possible authentication types would include digital 942 signature formats based on public key cryptography and keyed-hash 943 functions using shared secrets. 945 authentication_credentials 946 This is an opaque data structure, specific to authentication_type, 947 which is intended to assure the server of the client's identity and 948 to provide integrity protection for the serial_number and the 949 inner_request. 951 serial_number_hi, serial_number_lo 952 This is a serial number, represented as two 4-byte integers. It is 953 used to thwart replay attacks. Each request from a particular 954 principal must have a greater serial number than the previous one. 955 If a serial number is repeated, and the request is otherwise valid, 956 the request will be processed in such a manner as to neither alter 957 information on the server nor to return potentially sensitive 958 information in the result. However, for an Update request sent 959 over UDP, it is appropriate to return the status of the previous 960 operation, in case the duplicate request was caused by a legitimate 961 retransmission. 963 4.2.3.2 One-Shot Authenticate response structure 965 The One-Shot Authenticate response structure is as follows: 967 BEGIN one_shot_authenticate_response 968 string request_id 969 int status 970 struct inner_response 971 END 973 request_id 974 See request_id as described for the Query operation. 976 status 977 A code giving the result of the One-Shot Authenticate operation, 978 not that of the inner request. If the status code for the One-Shot 979 Authenticate operation indicates failure, the inner_response field 980 will be zero length. If the status code for the One-Shot 981 Authenticate operation indicates success, the inner_response field 982 will have a status code indicating the status of the authenticated 983 request. 985 inner_response 986 This is a BLOB-encoded field containing the server's response to 987 the authenticated request, if the authentication was successful. 989 4.2.4 SASL Authenticate operation 991 The SASL Authenticate operation is used to authenticate the connection 992 using SASL [9] mechanisms. Unlike the One-Shot Authenticate operation, 993 the SASL Authenticate operation establishes authentication credentials 994 for subsequent operations over the same TCP or TLS connection; and 995 unlike the One-Shot Authenticate operation, the SASL Authenticate 996 operation does NOT provide integrity protection for subsequent requests 997 or responses. The SASL Authenticate operation MUST NOT be supported 998 over UDP. 1000 4.2.4.1 SASL Authenticate request structure 1002 The SASL Authenticate request structure is as follows: 1004 BEGIN sasl_authenticate_request 1005 int request_type # SASL_AUTHENTICATE = 5 1006 string request_id 1007 string mechanism 1008 int client_state 1009 string response 1010 END 1012 request_type 1013 For SASL Authenticate, the request type is 5. 1015 request_id 1016 See request_id as described for the Query operation. Each SASL 1017 Authenticate request gets a new request_id, even if the request is 1018 to respond to a challenge resulting from a previous SASL 1019 Authenticate request. 1021 mechanism 1022 An ASCII string giving the registered name of the SASL mechanism. 1024 client_state 1025 An integer giving the type of SASL request: 1027 0. Initial SASL Request. This state code is used to indicate an 1028 initial SASL request. In this case the client_response field 1029 MAY be used to indicate the first SASL authentication message 1030 for SASL methods where the client is the first party to send 1031 authentication data. 1033 1. Response to SASL Challenge. This state code is used when the 1034 client wishes to respond to a challenge that was issued by the 1035 server in the immediately previous SASL Authenticate Response 1036 message. 1038 2. Abort SASL Request. This state code is used when the client 1039 wishes to abandon an attempt to authenticate using SASL, or 1040 when the client wishes to revoke SASL authentication that is 1041 currently in effect. (note that the server MAY be unable to 1042 accept a subsequent SASL authentication on the same TCP 1043 connection). 1045 response 1046 An octet string giving the client's response to a challenge (if 1047 state == 1), or the client's initial response (if state == 0) for 1048 SASL methods which are defined to have the client be the first 1049 party to send authentication data. 1051 4.2.4.2 SASL Authenticate response structure 1053 The SASL Authenticate response structure is as follows: 1055 BEGIN sasl_authenticate_response 1056 string request_id 1057 int status 1058 int server_state 1059 string challenge 1060 END 1062 request_id 1063 The request_id of the request. 1065 status 1066 The status code resulting from the attempted operation: 1068 RC_SUCCESS 1069 Authentication completed successfully. server_state will be 1070 set to 2. 1072 RC_AUTH_UNSUPP 1073 Authentication failed because the SASL mechanism requested by 1074 the client is not supported by the server. server_state will 1075 be set to 0. 1077 RC_AUTH_REQUIRES_ENCRYPTION 1078 Authentication failed because the client attempted to use a 1079 SASL mechanism that requires strong encryption, without having 1080 strong encryption in place. server_state will be set to 0. 1082 RC_AUTH_CHALLENGE 1083 Authentication requires a response to a challenge issued by 1084 the server. server_state will be set to 1. 1086 RC_TEMPORARY_FAILURE 1087 Authentication failed for temporary reasons. server_state 1088 will be set to 0. 1090 other code 1091 Authentication failed. server_state will be set to either 0 1092 or 3. 1094 server_state 1095 One of the following: 1097 0. No SASL authentication is in effect or in progress. 1099 1. SASL authentication is in progress; a response to a challenge 1100 is expected. 1102 2. SASL authentication is in effect. 1104 3. No SASL authentication is in effect or in progress, but the 1105 server is unable to accept further SASL authentication 1106 requests during this session. The client must close the cur- 1107 rent TCP or TLS connection and reopen a new connection to the 1108 server before a SASL authentication can be successful. 1110 4.2.4.3 SASL Profile 1112 The following profile is specified per [9]: 1114 1. The SASL service name is {TBA IANA, presumably "rc"}. 1116 2. The command to initiate the protocol exchange is the SASL 1117 Authenticate request with a client_state value of 0. 1119 3. The authentication protocol exchange is carried out by having 1120 the client issue a series of SASL Authenticate requests. The 1121 first request (the one used to initiate the exchange) has a 1122 client_state value of 0. The server issues a response to each 1123 request. Depending on the value of the server_state field of 1124 the response, the client may need to issue additional SASL 1125 Authenticate requests in order to supply responses to server 1126 challenges. This repeats until the server either signals a 1127 success status code (with server_state set to 2) or a failure 1128 status code (with server_state set to 0). The challenges and 1129 responses are supplied in appropriate fields of the SASL 1130 Authenticate response and request structures, respectively, 1131 and are NOT encoded except for the BLOB encapsulation speci- 1132 fied by the RC protocol. 1134 4. The negotiated security layer takes effect immediately follow- 1135 ing the client's transmission of a SASL Authenticate Request 1136 structure, and the server's transmission of a SASL Authenti- 1137 cate Response structure for which (status = RC_SUCCESS) AND 1138 (server_state = 2). Once the client has sent a SASL Authenti- 1139 cate Request, the client MUST NOT transmit additional requests 1140 other than SASL Authenticate over that connection until the 1141 server has returned a SASL Authenticate response for which 1142 server_state is not equal to 1. A SASL Authenticate request 1143 with a client_state of 2 may be used to abort a SASL exchange 1144 and cause the server to reset its server_state to 0. 1146 5. The authorization identity that is passed to the server is 1147 used by the server, along with other configuration and permis- 1148 sions information, to determine whether the client is autho- 1149 rized to perform a particular operation. For now, the method 1150 by which the server makes such a determination is undefined by 1151 the RC protocol. 1153 4.2.4.4 Notes on use of SASL 1155 Due to implementation constraints, some servers may be unable to accept 1156 more than one SASL authentication per TCP or TLS connection, even if the 1157 original authentication is revoked. 1159 Attempts to use SASL mechanisms which transmit shared secrets (e.g. 1160 passwords) MUST be rejected by the server unless there is an established 1161 TLS connection using a ciphersuite which provides encryption with an 1162 effective key strength (for the symmetric encryption key) of at least 1163 112 bits. 1165 4.3 Transport 1167 4.3.1 Use over TCP and UDP 1169 An RC server listens for requests on UDP port {TBD-IANA}. When used 1170 over UDP, each request or response is entirely contained within a single 1171 UDP datagram. The response is sent to the same address and port number 1172 that appeared in the IP header of the request. The request or response 1173 datagrams MAY be fragmented into multiple IP packets; so support for 1174 reassembly is required. The maximum possible request or response is 1175 constrained by the maximum UDP datagram size. Clients SHOULD NOT use 1176 UDP for a request when the response is expected to contain a large 1177 amount of data. Servers SHOULD have code to limit the amount of 1178 additional information returned in a UDP response to some reasonable 1179 figure. Servers MUST detect when a response would be too large (either 1180 larger than the maximum UDP datagram size or larger than some smaller 1181 administrative limit) and return an appropriate error indication. 1183 UDP clients MUST implement a retransmission timer to keep from swamping 1184 the network - details are to be determined. 1186 An RC server that supports TCP listens for requests on port {TBD-IANA}. 1187 The responses are returned over the same connection. Multiple requests 1188 and responses may be sent over a single TCP connection. The requests 1189 and responses are self-delimiting, each beginning with a 4-octet integer 1190 length field (in network byte order). Multiple requests MAY be issued 1191 before reading a response, but this introduces the possibility of 1192 deadlock. A client that issues multiple requests MUST be able to read 1193 responses to earlier requests concurrently while issuing requests. When 1194 multiple outstanding requests are issued over a single TCP connection, 1195 servers MAY service them out of order, so long as no request is 1196 significantly delayed. Servers MAY place a limit on the number of 1197 outstanding requests from a single source, in which case they MUST 1198 respond to requests in excess of that limit with a {TBD} error. 1200 NB: the above needs work. Since a response may be of arbitrary size, a 1201 server might be unable to return "too many outstanding requests" because 1202 a large response is blocking the return channel. 1204 4.3.2 Use over TLS 1206 Clients and servers MAY support TLS. TLS is layered on top of TCP, and 1207 an RC server which supports TLS uses the same port for RC-over-TLS-over- 1208 TCP as for RC-over-TCP. A client wishing to use TLS to communicate with 1209 a server first opens up a TCP connection to that server, and then issues 1210 a StartTLS request. 1212 4.3.2.1 StartTLS request structure 1214 A StartTLS request structure is defined as follows: 1216 BEGIN starttls_request 1217 int request_type # STARTTLS = 4 1218 string request_id 1219 END 1221 4.3.2.2 StartTLS response structure 1223 The StartTLS response structure is: 1225 BEGIN starttls_response 1226 string request_id 1227 int status 1228 END 1230 Servers which support TLS MUST support ciphersuite {TBD}. The 1231 appropriate use of TLS server certificates by clients, and the use of 1232 TLS client certificates by servers, is yet to be defined. 1234 4.4 Mapping from URIs to RC server locations 1236 The specifics of this are currently undefined, but are intended to be 1237 similar to the procedures defined in [11], [2], and [12], and consistent 1238 with any standards developed in this area. 1240 4.5 Operation Through Proxies 1242 RC clients MAY make queries via a proxy. Such proxies MAY cache 1243 successful results (up until their ttls and or expiration dates expire) 1244 and return them in response to subsequent Queries. Unsuccessful results 1245 MUST NOT be cached. Proxies MAY supply their own request_id fields of 1246 requests passed to servers, in order to better facilitate demultiplexing 1247 and routing of the responses to their clients, so long as they also 1248 modify the request_id fields of responses returned to the clients to 1249 match the request_id fields used by those clients. 1251 4.6 Status Codes 1253 RC_SUCCESS (0) 1254 successful operation 1256 RC_NO_SUCH_NAME (1) 1257 operation failed; no record for this resource_name was found on 1258 this server 1260 RC_NOT_AUTHORITATIVE (2) 1261 operation succeeded, but the answer returned is not authoritative 1263 RC_RESULT_MISSING_SIGS (3) 1264 operation succeeded, but signatures could not be included in the 1265 response due to space limitations 1267 RC_VERSION_MISMATCH (4) 1268 operation failed because VERSION_MATCH was set in the request but 1269 the version numbers did not match. (Note: This MUST NOT be used to 1270 signal a mismatch between versions of the RC protocol.) 1272 RC_TEMPORARY_FAILURE (5) 1273 operation failed due to unspecified temporary conditions 1275 RC_WOULD_CLOBBER_SIGS (6) 1276 operation failed because the Update would result in invalidation of 1277 existing signatures, and the DONT_CLOBBER_SIGS flag was set 1279 RC_KEY_SYNTAX (7) 1280 operation failed; the syntax of the resource name was not valid 1282 RC_CRED_VRFY (8) 1283 operation failed, could not verify credentials 1285 RC_CRED_REVOKED (9) 1286 operation failed, credentials have been revoked or have expired 1288 RC_NOPERM (10) 1289 client does not have permission to perform the operation 1291 RC_DATA_FMT (11) 1292 the request was not in the proper format or could not be parsed 1294 RC_REFUSED (12) 1295 query refused 1297 RC_AUTH_INSUFF (13) 1298 The authentication method chosen by the client is not sufficiently 1299 secure for this operation; the actual operation was not attempted. 1301 RC_AUTH_UNSUPP (14) 1302 The authentication method chosen by the client is not supported by 1303 the server. 1305 RC_UNSUPP_REQUEST(15) 1306 The request_type is not supported by this server, either because it 1307 is deprecated or because it is not yet defined. 1309 RC_AUTH_CHALLENGE (16) 1310 This is a response to a SASL Authenticate request, indicating that 1311 a response to a challenge is necessary before authentication can be 1312 completed. 1314 RC_AUTH_REQUIRES_ENCRYPTION (17) 1315 The authentication failed because the client attempted to use an 1316 authentication method that requires strong encryption, without hav- 1317 ing strong encryption in place. 1319 5. Conventions for attribute names 1321 Attribute names are human-meaningful ASCII strings consisting of 1322 printable characters. They are chosen in such a way that wildcard 1323 queries are useful. Related attributes are grouped together by having a 1324 common prefix. Thus for example a set of attributes related to 1325 electronic mail might be grouped together with the prefix "rc:email.", 1326 and queries for "rc:email.*" might be issued to obtain all such 1327 attributes. 1329 RC is designed to be mostly agnostic about the format of attribute 1330 names. Some existing data models use Uniform Resource Identifiers as 1331 attribute names. This seems unwise - not only do URIs tend to be more 1332 verbose than necessary, but their use as attribute names seems likely to 1333 encourage inappropriate semantic association between the URI components 1334 (prefix/protocol, domain name, etc) and the attribute named by the URI. 1336 However, for the sake of consistency with existing practice, URIs MAY be 1337 used as attribute names in RC - subject only to the requirement that RC 1338 performs exact (octet-by-octet) comparison of attribute names. URIs 1339 used as attribute names in RC MUST be canonicalized so that the URI 1340 always has a consistent representation. The algorithm by which this 1341 canonicalization is done is not defined by the RC protocol; it MUST be 1342 specified by the higher-level protocol. 1344 It is intended that a registry of attribute names be maintained by IANA 1345 in order to discourage conflicting uses of the same names. Assignment 1346 of registry names is via the IETF Consensus process or with IESG 1347 approval. Prefixes MAY be delegated to other parties via the IETF 1348 Consensus process. 1350 The prefix "rc:" is reserved for attributes used by RC itself. The 1351 prefix ":x:" is reserved for ad hoc user extensions. 1353 5.1. Inheritance of attributes 1355 The rescap charter specifies a requirement that it must be possible to 1356 inherit attributes. In RC this is accomplished as follows: the 1357 attribute_name "rc:defaults" is defined. The value associated with this 1358 name should be a URI. If an attribute named "rc:defaults" exists for a 1359 particular resource_name, the default attributes for that resource_name 1360 may be obtained by issuing a query for the same attribute_names to the 1361 URI associated with "rc:defaults". 1363 The defaults may thus easily be obtained by including the attribute_name 1364 "rc:defaults" in the set of attributes requested, and by setting the 1365 QUERY_RECURSE flag for that attribute_name. Multiple levels of defaults 1366 are possible, and each resource_name can have its own set of defaults. 1367 (However, clients MUST take pains to detect circular references in 1368 rc:defaults; any rc:defaults value which matches to either the 1369 request_uri or a previous rc:defaults value obtained during the same 1370 query, MUST be ignored.) 1372 6. IANA Considerations 1374 - A new TCP port and a new UDP port are needed 1375 - A registry of attribute_names, and procedures for assigning and 1376 delegating attribute naming prefixes, are needed. 1378 - A registry of signature algorithms, and a procedure for registering 1379 new signature algorithms identifiers, are needed. 1381 - A service name (presumably "rc") for use with SASL (and therefore 1382 GSSAPI) needs to be defined. 1384 7. Security Considerations 1386 Many security considerations are discussed in section 2.5. Here are 1387 some others. 1389 7.1 Privacy issues regarding choice of request_ids 1391 Since request_ids need to be unique, it is tempting to define them in 1392 terms of some other convenient globally-unique number such as a GUID, 1393 network interface hardware address, (non-private) IP address, etc. This 1394 may result in inadvertent disclosure of information about usage patterns 1395 to unauthorized parties. Request-ids SHOULD be chosen in such a way as 1396 to minimize the potential for disclosure of information which could be 1397 associated with a particular person or host. The fact that similar 1398 information could be disclosed by other means does not lessen the burden 1399 for RC client implementations to minimize their own potential for 1400 disclosure through the request_id field. 1402 Similarly, RC proxies that multiplex several clients' requests over the 1403 same TCP stream may need to map between clients' request_ids and their 1404 own request_ids for proxied requests, in order to ensure that each 1405 request_id transmitted over a TCP stream is unique. Such proxies SHOULD 1406 avoid disclosing identifying information about clients via the 1407 request_id field. 1409 8. Differences from RC version 2 1411 Just to provide some background, this section details major differences 1412 between RCv2 and RCv3: 1414 - RCv2 had typed attributes; RCv3 makes all attributes octet-strings. 1416 - RCv2 used ONC XDR and RPC [13]; RCv3 uses the BLOB encoding and 1417 defines its own RPC mechanism. For a variety of reasons, most 1418 having little to do with protocol quality, RCv2's use of ONC RPC 1419 was the single most frequently cited objection to that protocol. 1420 However the mechanism intended for use with RCv3 is easier to 1421 implement and more efficient to process than XDR. 1423 - RCv2 maintained separate records for attributes of resources (like 1424 RCv3's assertions) and locations of resources, allowing the caller 1425 to choose the closest of several locations for that resource. The 1426 latter also included cached DNS A records in order to speed up 1427 accesses to the resource. RCv3 does not have this separation. 1429 - RCv2 supported the principle of multiple 'asserters' for 1430 information about a resource. it kept track of who made each 1431 assertion, and if different asserters made conflicting assertions, 1432 it would return all of the assertions. RCv3 assumes that a small 1433 number of trusted parties will be allowed to make assertions about 1434 any particular resource, and that these parties will cooperate to 1435 the degree necessary to avoid making conflicting assertions about a 1436 resource. The QUERY_RECURSE feature of RCv3 is intended to provide 1437 similar functionality in a more general fashion. 1439 - RCv2 supported the notion of redirects - the ability to redirect 1440 queries for portions of URI-space - at the protocol level; this is 1441 omitted in RCv3 because they were too much trouble to use. 1442 Redirects could be implemented in RCv3 by making them ordinary 1443 attributes and by using the QUERY_RECURSE bit in queries for that 1444 attribute name. 1446 9. Acknowledgements 1448 The author wishes to thank Graham Klyne for extensive comments on an 1449 earlier version of this document. 1451 10. Author's Address 1453 Keith Moore 1454 University of Tennessee, Knoxville 1455 1122 Volunteer Blvd, Suite 203 1456 Knoxville TN, 37996-3450 1457 USA 1458 email: moore@cs.utk.edu 1460 11. References 1462 [1] Bradner, S. Key words for use in RFCs to Indicate Requirement 1463 Levels. RFC 2119, March 1997. 1465 [2] Mealling, M., Daniel, R. The Naming Authority Pointer (NAPTR) DNS 1466 Resource Record. RFC 2915, September 2000. 1468 [3] Gulbrandsen, A., Vixie, P., Esibow, L. A DNS RR for specifying the 1469 location of services (DNS SRV). RFC 2782, February 2000. 1471 [4] Dierks, T., Allen, C. The TLS Protocol Version 1.0. RFC 2246, 1472 January 1999. 1474 [5] Mockapetris, P.V. Domain names - implementation and specification. 1475 RFC 1035, November 1987. 1477 [6] Case, J. Mundy, R., Partain, D., Stewart, B. Introduction to 1478 Version 3 of the Internet-standard Network Management Framework. 1479 RFC 2570, April 1999. 1481 [7] Wahl, M., Howes, T., Kille, S. Lightweight Directory Access 1482 Protocol (v3). RFC 2251, December 1997. 1484 [8] Moore, K. The Binary Low-Overhead Block Presentation Protocol. 1485 Internet-Draft draft-ietf-rescap-blob-01.txt, March 1, 2002, work 1486 in progress. 1488 [9] Myers, J. Simple Authentication and Security Layer (SASL). RFC 1489 2222, October 1997. 1491 [10] Linn, J. Generic Security Service Application Program Interface 1492 Version 2, Update 1. RFC 2743, January 2000. 1494 [11] Daniel, R., Mealling, M. Resolution of Uniform Resource 1495 Identifiers using the Domain Name System. RFC 2168, June 1997. 1497 [12] Mealling, M. A DDDS Database Using the Domain Name System. 1498 Internet-Draft draft-ietf-urn-dns-ddds-database-08.txt, February 1499 2002. work in progress. 1501 [13] Srinivasan, R. RPC: Remote Procedure Call Protocol Specification 1502 Version 2. RFC 1831, August 1995. 1504 Appendix A. Substantive changes since version -00 1506 - section 2.5: removed what was essentially a duplicate description 1507 of the 'alteration of data' threat; also added some text explaining 1508 limitations of server-provided signatures. 1510 - section 3.1: explain why it's useful to have both a TTL and an 1511 expiration date. 1513 - section 4.1 et seq: renumber request types so that the "reserved" 1514 request is 0. 1516 - section 4.1.1: change example of supported_requests array to illus- 1517 trate a range consisting of a single request number. also added a 1518 note about caching of supported request information. 1520 - various: updated section references to reflect current reality. 1522 - section 4.2.1.5: clarify that a signature may be computed over 1523 resource_name and version_* in addition to the list of assertions. 1525 - section 4.2.2.1: eliminate duplicate version_* fields in 1526 update_request. also state explicitly how the server updates ver- 1527 sion_* fields on completion of successful requests, and limitations 1528 on using UPDATE_VERSION_MATCH due to wrap-around of version_ 1529 fields. 1531 - section 4.2.3: rename Authenticate operation to One-Shot Authenti- 1532 cate; add new SASL Authenticate operation. The former is designed 1533 for use with UDP; the latter, with TCP or TLS. 1535 - section 4.3: remove text stating requirements for support of TCP 1536 and UDP; this needs re-thinking. 1538 - section 4.4: forbid caching of negative responses by proxies. 1540 - section 4.5: added new status codes 1542 - section 5.1: clarify handling of circular references to 1543 "rc:defaults". 1545 Appendix B. Open issues 1547 - There is no model for access control. This can probably be 1548 deferred. 1550 - A mandatory-to-implement TLS ciphersuite for servers supporting 1551 StartTLS operation needs to be chosen. 1553 - Authentication methods for One-Shot authentication need to be 1554 defined. 1556 - At least one signature algorithm needs to be defined. 1558 - Characteristics of UDP request retransmission timer need to be 1559 defined. (borrow from SIP?) 1561 - Conformance requrements for clients and servers regarding TCP and 1562 UDP, TLS, and authentication mechanisms, need to be defined. 1564 - Rules for caches/proxies regarding use of authentication need to be 1565 defined.