idnits 2.17.1 draft-ietf-crisp-firs-relay-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([FIRS-CORE], [FIRS-ARCH], [CRISP-REQ]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 194 has weird spacing: '...ference const...' -- 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 (September 5, 2003) is 7531 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) -- Looks like a reference, but probably isn't: '0' on line 133 -- Looks like a reference, but probably isn't: '1' on line 134 -- Possible downref: Non-RFC (?) normative reference: ref. 'CRISP-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIRS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIRS-CORE' ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Gietz 3 Internet-Draft DAASI International GmbH 4 Expires: March 5, 2004 September 5, 2003 6 Relay Bag Search Control for the Federated Internet Registry Service 7 draft-ietf-crisp-firs-relay-00 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 March 5, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes an LDAP search request and response control 39 to allow additional unspecified data to be returned with a referral 40 to the client, which can submit these data to the referred to server 41 in support of the Federated Internet Registry Service (FIRS) 42 described in [FIRS-ARCH] and [FIRS-CORE]. A flexible container 43 called relay bag as required in [CRISP-REQ] is included into this 44 extension to the LDAP search operation. 46 Conventions used in this document 48 Protocol elements are described using ASN.1 [X.680]. The term "BER- 49 encoded" means the element is to be encoded using the Basic Encoding 50 Rules [X.690] under the restrictions detailed in Section 5.1 of 51 [RFC2251]. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Whenever the words "client" and "server" are used in this document, 58 the notion is a FIRS complying client and server respectively. 60 1. Background and Intent of Use 62 The Federated Internet Registry Service (FIRS) described in [FIRS- 63 ARCH] and [FIRS-CORE] is a distributed service for storing, locating 64 and transferring information about the Internet Resources using 65 LDAPv3 [RFC3377]. It is thus an implementation of a Cross Registry 66 Information Service Protocol as specified in the requirements 67 document [CRISP-REQ]. To completly fulfil these requirements, a 68 feature called relay bag has to be supported. 70 A relay bag is a flexible container which may contain unspecified 71 data that a server can give back to a client in addition to a 72 referral. The data are not to be read and understood by the client, 73 but to be forwarded by the client to the referred to server. The 74 data transported in the relay bag are thus server operator-to- 75 operator coordination data, e.g. for auditing or tracking. 77 This document specifies such a relay bag with the means of two LDAP 78 controls extenting the LDAP search operation. 80 2. Relay Bag Search Request and Response Controls 82 Support for the relay bag search request and response controls 83 defined in this section is advertised by the presence of their OID in 84 the supportedControl attribute of a server's root DSE entry, which is 85 specified in [RFC2251], section 3.4. The OID of the request control 86 is "1.3.6.1.4.1.10126.1.15.7.2", the OID of the response control is 87 "1.3.6.1.4.1.10126.1.15.7.3". 89 An LDAP control as specified in [RFC2251], section 4.1.12, is a way 90 to specify extension information for an LDAP operation. Basically an 91 LDAP control consists of a controlType, containing the OID for the 92 control, a boolean field for marking the criticality of the control, 93 and an optional controlValue containing arbitrary data with octet 94 string syntax. 96 The relay bag search request and response controls are only to be 97 used within the search operation, which is specified in [RFC2251], 98 section 4.5. 100 2.1 Relay Bag Search Request Control 102 The relay bag search request control is to be included in the the 103 SearchRequest message as part of the controls field of the 104 LDAPMessage, which is defined in section 4.1.1 of [RFC2251]. It MUST 105 NOT be included in any other request or result message. 107 It has the following controlType: 109 relayBagSearchRequestOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.10126.1.15.7.2 111 The controlValue is a BER-encoded Octet string, which can contain any 112 kind of data: 114 relayBagSearchRequestValue ::== OCTET STRING 116 The criticality may either be set to TRUE or FALSE. 118 2.2 Relay Bag Search Response Control 120 The relay bag search response control is to be included in the the 121 SearchResultReference message as part of the controls field of the 122 LDAPMessage, which defined in section 4.1.1 of [RFC2251]. It MUST 123 NOT be included in any other request or result message. 125 It has the following controlType: 127 relayBagSearchResponseOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.10126.1.15.7.3 129 The controlValue is a BER-encoded Octet string, with the following 130 syntax: 132 relayBagSearchResponseValue ::== SEQUENCE of SEQUENCE { 133 ldapurl [0] LDAPURL, 134 relayBag [1] OCTET STRING 135 } 137 The ldapurl part of the relayBagSearchResponseValue is an LDAP URL, 138 which is specified in [RFC2255] 140 The relayBag part of the relayBagSearchResponseValue is a BER-encoded 141 Octet string, which can contain any kind of data: 143 The criticality MUST be set to TRUE. 145 3. Relay Bag Specific LDAP Result Codes 147 As specified in [RFC3383], section 3.6, it is possible to register 148 new LDAP result codes not specified in [RFC2251]. For the relay bag 149 controls the following LDAP result codes are defined: 151 firsRelayBagUnrecognizedFormat (1050) 152 firsRelayBagUnacceptableData (1051) 153 firsRelayBagTemporarlyRefused (1052) 155 4. Operation Requirements 157 A client MAY evaluate if the server it initially connects to supports 158 this feature, by checking if the controlType Object Identifier of the 159 controls specified in this document (relayBagSearchRequestOID and 160 relayBagSearchResponseOID) are stored in the attribute 161 supportedControl of the root DSE entry, which is specified in 162 [RFC2251], section 3.4. 164 If the server supports this control the Client MUST use it when 165 sending a search request to the server. In the initial server 166 contact the controlValue of the relayBagSearchRequest sent by the 167 client SHOULD be empty. 169 When the server sends back the search response, it MUST include the 170 control identified by the controlType field. The controlValue MAY 171 contain data that at least give the information that the server had 172 referred the client to another server. 174 For each LDAP URL listed in the control value of the 175 SearchResultReference message response the relay bag part of the 176 control value MUST contain some kind of data. The semantics for such 177 information is not defined in this document and is to be specified by 178 the service operators. 180 The semantics MAY include a mechanism to make sure that the data have 181 not been changed, e.g. by digitally signing a hash value of the 182 contents. 184 The semantics MAY also include a mechanism to make sure that only the 185 referred to server can read the contents of the relay bag, e.g. by 186 encrypting the contents with the Public Key of the refered to server, 187 so that only that server can decrypt the contents with its private 188 key. 190 A server may send back referrals without a relay bag, referrals with 191 a relay bag and a combination of both. 193 Referrals without relay bag MUST be submitted via the 194 SearchResultReference construct specified in RFC 2251, section 4.5.2 195 for this purpose. 197 If the server only sends back referrals without relay bags, the 198 controlValue of the SearchResultReference MUST be empty. 200 When the client follows a referral given without a relay bag, it MAY 201 nonetheless use the relay bag request control while contacting the 202 referred to server. In this case the controlValue of the 203 relayBagSearchRequest sent by the client MUST be empty. 205 Referrals with a relay bag MUST be submitted inside the controlValue 206 field as specified above, without redundantly storing the referrals 207 in the SearchResultReference construct. 209 When the client follows a referral given with a relay bag part in the 210 response control value, it MUST use the control and send the data 211 given by the referring server in the respective relay bag part of 212 controlValue field unchanged in the controlValue field of the search 213 request. 215 If only referrals with relay bag are submitted, the server MUST store 216 a dummy-referral in the SearchResultReference construct. The dummy 217 referral, which MUST be ignored by the client, is: 219 ldap:/// 221 If no referrals are submitted at all, the response message of the 222 server is another than SearchResultReference, namely SearchResultDone 223 or SearchResultEntry. In these cases no relay bag control will be 224 included in the response message. 226 If the refered to server does not recognize the format of the Relay 227 Bag included in a search request it MUST respond with the result code 228 firsRelayBagUnrecognizedFormat (1050). This has to be interpreted by 229 the client as permanent failure. 231 If the relay bag included in a search request contains data 232 unacceptable to the refered to server, the server MUST respond with 233 the result code firsRelayBagUnacceptableData (1051). This has to be 234 interpreted by the client as permanent failure. 236 If the relay bag included in a search request contains data that 237 according to the policy of the referred to server indicate that 238 processing should be refused at this time, the refered to server MUST 239 respond with the result code firsRelayBagTemporarlyRefused (1052). 240 This has to be interpreted by the client as transient failure. 242 If the relay bag included in a search request contains data that 243 according to the policy of the refered to server indicate that 244 processing should be refused at any time, the refered to server MAY 245 respond with the result code unwillingToPerform (53). 247 Servers that support the relay bag control MAY decide to only serve 248 clients that support and use this control. If a server wants to thus 249 enforce the control, every search request without this control SHOULD 250 be responded to with the resultCode unwillingToPerform (53). 252 5. Relationship to Other Search Controls 254 The relay bag search control is not intended be used together with 255 any other existing search controls. Nonetheless there should not be 256 a problem to do so. Clients have to be aware though that if using 257 the relay bag control, some referrals may be found in the 258 controlValue instead of the referral list. In cases other than a 259 SearchResultReference, there are no effects in the server response at 260 all caused by the relay bag control. 262 If a new search control is to be used in combination with the relay 263 bag search control the document, describing that new search control 264 has to deal with possible implications not foreseable now. 266 6. Security Considerations 268 The relay bag search control can be used in services to provide data 269 only to clients that have properly authenticated to one server, by 270 passing over the authentication status of the client to the referred 271 to server. 273 To make sure the client has not changed the contents of the relay 274 bag, it is possible to use the PKI feature of digitally signing the 275 contents of the relay bag, e.g. by using X.509 based PKI with 276 certificates as specified in [RFC3280]. 278 To make sure the client cannot understand the contents of the relay 279 bag, which is only meant to be understood by the referred to server, 280 it is possible to use the PKI feature of encrypting the contents of 281 the relay bag with the help of the public key of the referred to 282 server, so that only that server can decrypt the contents. 284 Obviously any usage of this search control is dependant on the 285 services that use it, since this document does not specify and 286 enforce any semantics of the controlValue field. Thus every service, 287 using this control has to be aware of the possible security 288 implications. 290 7. IANA Considerations 292 7.1 Object Identifiers 294 This document uses the OIDs 1.3.6.1.4.1.10126.1.15.7.2 and 295 1.3.6.1.4.1.10126.1.15.7.3 to identify an LDAP protocol element 296 defined herin. This OID was assigned by DAASI International Ltd., 297 under its IANA assigned private enterprise allocation [PRIVATE], for 298 use in this specification. 300 7.2 Protocol Mechanisms 302 Registration of the protocol mechanisms defined in this document is 303 requested in [RFC3383]. 305 Subject: Request for LDAP Protocol Mechanism Registration 307 Object Identifier: 1.3.6.1.4.1.10126.1.15.7.2 309 Description: relay bag search request 311 Person & email address to contact for further information: 312 Peter Gietz 314 Usage: Control 316 Specification: RFCxxxx 318 Author/Change Controller: IESG 320 Comments: none 322 Subject: Request for LDAP Protocol Mechanism Registration 324 Object Identifier: 1.3.6.1.4.1.10126.1.15.7.3 326 Description: relay bag search response 328 Person & email address to contact for further information: 329 Peter Gietz 331 Usage: Control 333 Specification: RFCxxxx 335 Author/Change Controller: IESG 337 Comments: none 339 7.3 LDAP Result Codes 341 Registration of the LDAP result codes defined in this document is 342 requested in [RFC3383]. 344 Subject: Request for LDAP Result Code Registration 346 Result Code Name: firsRelayBagUnrecognizedFormat 348 Result Code Number: 1050 349 Person & email address to contact for further information: 350 Peter Gietz 352 Specification: RFCxxxx 354 Author/Change Controller: IESG 356 Comments: none 358 Subject: Request for LDAP Result Code Registration 360 Result Code Name: firsRelayBagUnacceptableData 362 Result Code Number: 1051 364 Person & email address to contact for further information: 365 Peter Gietz 367 Specification: RFCxxxx 369 Author/Change Controller: IESG 371 Comments: none 373 Subject: Request for LDAP Result Code Registration 375 Result Code Name: firsRelayBagTemporarlyRefused 377 Result Code Number: 1052 379 Person & email address to contact for further information: 380 Peter Gietz 382 Specification: RFCxxxx 384 Author/Change Controller: IESG 386 Comments: none 388 8. Changes from Previous Drafts 389 8.1 Changes in Draft 01 391 o Separated the control into different controls for the request and 392 the response. The response control value now consists of a list 393 of referrals with a relay bag attached to each referral. 395 o introduced FIRS specific LDAP result codes for relay bag handling 396 of the server. 398 o added a number of clarifications in section Section 4 400 o changed section Section 5 to clarify the relations to other search 401 controls. 403 o re-evaluated the MUST, SHOUD and MAY with respect to the 404 requirements specified in [CRISP-REQ], especially with respect to 405 the criticality of the control 407 o added section on IANA considerations 409 o some minor editorial changes 411 9. Acknowledgments 413 This document is the result of discussions taking place in the IETF 414 CRISP WG. The concept of relay bags is derived from that activity. 415 Especially Andrew Newton, Eric A. Hall, Steven Legg, Leslie Daigle 416 and Marc C. Smith gave valuable input. 418 This document has been written in XML according to the DTD specified 419 in RFC2629. xml2rfc has been used to generate an RFC2033 compliant 420 plain text form. The XML source and a HTML version are available on 421 request. 423 10. References 425 10.1 Normative References 427 [CRISP-REQ] Newton, A., "Cross Registry Internet Service Protocol 428 (CRISP) Requirements", May 2003, . 431 [FIRS-ARCH] Hall, E., "The Federated Internet Registry Service: 432 Architecture and Implementation Guide", May 2003, 433 . 435 [FIRS-CORE] Hall, E., "The Federated Internet Registry Service: Core 436 Elements", May 2003, . 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 443 Access Protocol (v3)", RFC 2251, December 1997. 445 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 446 December 1997. 448 [RFC3377] Hodges, J. and RL. Morgan, "Lightweight Directory Access 449 Protocol (v3): Technical Specification", RFC 3377, 450 September 2002. 452 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority 453 (IANA) Considerations for the Lightweight Directory 454 Access Protocol (LDAP)", RFC 3383, September 2002. 456 [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - 457 Specification of Basic Notation", X. 680, 1994. 459 [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, 460 Canonical, and Distinguished Encoding Rules", X. 690, 461 1994. 463 10.2 Non-normative References 465 [PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/ 466 assignements/enterprise-numbers. 468 [RFC3280] Housley, R., Polk, T., Ford, W. and D. Solo, "Internet 469 X.509 Public Key Infrastructure Certificate and CRL 470 Profile", RFC 3280, April 2002. 472 Author's Address 474 Peter Gietz 475 DAASI International GmbH 476 Wilhelmstr. 106 477 Tuebingen 72074 478 DE 480 Phone: +49 7071 29 70336 481 EMail: peter.gietz@daasi.de 482 URI: http://www.daasi.de/ 484 Full Copyright Statement 486 Copyright (C) The Internet Society (2003). All Rights Reserved. 488 This document and translations of it may be copied and furnished to 489 others, and derivative works that comment on or otherwise explain it 490 or assist in its implementation may be prepared, copied, published 491 and distributed, in whole or in part, without restriction of any 492 kind, provided that the above copyright notice and this paragraph are 493 included on all such copies and derivative works. However, this 494 document itself may not be modified in any way, such as by removing 495 the copyright notice or references to the Internet Society or other 496 Internet organizations, except as needed for the purpose of 497 developing Internet standards in which case the procedures for 498 copyrights defined in the Internet Standards process must be 499 followed, or as required to translate it into languages other than 500 English. 502 The limited permissions granted above are perpetual and will not be 503 revoked by the Internet Society or its successors or assigns. 505 This document and the information contained herein is provided on an 506 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 507 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 508 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 509 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 510 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 512 Acknowledgement 514 Funding for the RFC Editor function is currently provided by the 515 Internet Society.