idnits 2.17.1 draft-ietf-crisp-iris-beep-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 24, 2003) is 7461 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) == Unused Reference: '19' is defined on line 439, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (ref. '6') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3205 (ref. '7') (Obsoleted by RFC 9205) == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-core-01 -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2818 (ref. '11') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2396 (ref. '12') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2234 (ref. '13') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-06) exists of draft-ietf-crisp-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-crisp-requirements (ref. '15') ** Obsolete normative reference: RFC 2459 (ref. '16') (Obsoleted by RFC 3280) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 ** Obsolete normative reference: RFC 3023 (ref. '18') (Obsoleted by RFC 7303) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: April 23, 2004 October 24, 2003 6 IRIS - Using the Internet Registry Information Service (IRIS) over 7 the Blocks Extensible Exchange Protocol (BEEP) 8 draft-ietf-crisp-iris-beep-04 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 23, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document specifies how to use the Blocks Extensible Exchange 40 Protocol (BEEP) as the application transport substrate for the 41 Internet Registry Information Service (IRIS). 43 Table of Contents 45 1. Introduction and Motivations . . . . . . . . . . . . . . . . . 3 46 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 47 3. BEEP Profile Identification . . . . . . . . . . . . . . . . . 5 48 4. IRIS Message Packages . . . . . . . . . . . . . . . . . . . . 6 49 5. IRIS Message Patterns . . . . . . . . . . . . . . . . . . . . 7 50 5.1 Registry Dependent Patterns . . . . . . . . . . . . . . . . . 7 51 5.2 Default Pattern . . . . . . . . . . . . . . . . . . . . . . . 7 52 6. Server Authentication Methods . . . . . . . . . . . . . . . . 8 53 6.1 Registry Dependent Methods . . . . . . . . . . . . . . . . . . 8 54 6.2 Default Authentication Method . . . . . . . . . . . . . . . . 8 55 7. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 9 56 7.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 7.2 Application Protocol Label . . . . . . . . . . . . . . . . . . 9 58 7.3 BEEP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 8. Registrations . . . . . . . . . . . . . . . . . . . . . . . . 10 60 8.1 BEEP Profile Registration . . . . . . . . . . . . . . . . . . 10 61 8.2 URI Scheme Registration . . . . . . . . . . . . . . . . . . . 10 62 8.3 Well-known TCP Port Registration . . . . . . . . . . . . . . . 10 63 8.4 NAPSTR Registration . . . . . . . . . . . . . . . . . . . . . 11 64 9. Registry Definition Checklist . . . . . . . . . . . . . . . . 12 65 10. Internationalization Considerations . . . . . . . . . . . . . 13 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 70 Intellectual Property and Copyright Statements . . . . . . . . 18 72 1. Introduction and Motivations 74 The proposal in this document describes the IRIS [9] application 75 transport binding using BEEP [2]. Requirements for IRIS and the 76 specification in this document are outlined in CRISP [15]. 78 The choice of BEEP as the transport substrate is primarily driven by 79 the need to re-use an existing, well-understood protocol with all the 80 necessary features to support the requirements. This gives 81 implementers a wealth of toolkits and debugging gear for use in 82 constructing both servers and clients and allows operators to apply 83 existing experience in issues of deployment. It is also felt that 84 the construction of a simple application transport for the specific 85 purpose of IRIS would yield a similar, though likely smaller and 86 probably less complete, standard after taking into consideration such 87 matters as framing, authentication, etc. 89 Precedents for using other transport mechanisms in layered 90 applications do not seem to fit with the design goals of IRIS. HTTP 91 [6] offers many features employed for use by similar applications. 92 However, it is not the intention of IRIS to be put to such uses as 93 by-passing fire-walls, co-mingling URI schemes, or any other such 94 methods which might lead to confusion between IRIS and traditional 95 World Wide Webb applications. Beyond adhering to the guidelines 96 spelled out in RFC3205 [7], the use of HTTP also offers many other 97 challenges that quickly erode its appeal. For example, the 98 appropriate use of TLS [5] with HTTP is defined by RFC2817 [4], but 99 the common use as described in RFC2818 [11] is usually the only 100 method in most implementations. 102 Finally, the straight use of TCP such as that specified by EPP-TCP 103 [10] does not offer the client negotiation characteristics needed by 104 a referral application where a single client, in the act of 105 processing a query, may traverse multiple servers operating with 106 different parameters. 108 2. Document Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119 [8]. 114 3. BEEP Profile Identification 116 The BEEP profile identifier for IRIS is a URI composed of the IRIS 117 schema URN, followed by a slash, followed by an IRIS registry type 118 (which is a URN). 120 Since the IRIS schema URN is compliant with XML_URN [17], it may be 121 abbreviated according to the rules of IRIS. To simplify matters, it 122 MUST be abbreviated in the use of this profile identifier. 124 The registry type URN maybe abbreviated according to the rules of 125 IRIS (see [9]). To simplify matters, it MUST be abbreviated in the 126 use of this profile identifier. 128 The following is an example of an IRIS profile identifier for BEEP. 129 It identifies the version of IRIS to match that specified by 130 "urn:iana:params:xml:ns:iris1" with a registry type URN of 131 "urn:iana:params:xml:ns:dreg1". 133 http://iana.org/beep/transient/crisp/iris1/dreg1 135 The full ABNF [13] with certain values included from IRIS [9] 136 follows. 138 profile = profile-uri "/" iris-urn "/" registry-urn 139 profile-uri = "http://iana.org/beep/transient/crisp/" 140 iris-urn = // as specified by IRIS 141 registry-urn = // as specified by IRIS 143 This URI is used in the "profile" element in BEEP during channel 144 creation. According to the rules of BEEP, multiple "profile" 145 elements may be offered thus allowing for a negotiation of the 146 version of IRIS to be used for every registry type being served. 148 Once this profile is accepted and the channel is created, the state 149 of the channel is considered ready to exchange IRIS messages. 151 4. IRIS Message Packages 153 The BEEP profile for IRIS transmits XML [1] containing the requests 154 and responses for IRIS registries. These XML instances MUST be 155 encoded as UTF-8 [14] using the media-type of "application/xml" 156 according to RFC3023 [18]. A registry type MAY define other message 157 packages that are not IRIS XML instances (e.g. binary images 158 referenced by an IRIS response). 160 5. IRIS Message Patterns 162 5.1 Registry Dependent Patterns 164 Because each registry type is defined by a separate BEEP profile, 165 each registry type MAY define a separate message pattern. These 166 patterns MUST be within the allowable scope of BEEP [2]. If a 167 registry type does not explicitly define a message pattern, the 168 default pattern is used (see Section 5.2 170 However, each registry type MUST be capable of supporting the default 171 pattern (Section 5.2) for use with the query in IRIS. 173 5.2 Default Pattern 175 The default BEEP profile for IRIS only has a one-to-one request/ 176 response message pattern. This exchange involves sending an IRIS XML 177 instance, which results in a response of an IRIS XML instance. 179 The request is sent by the client using an "MSG" message containing a 180 valid IRIS XML instance. The server responds with an "RPY" message 181 containing a valid IRIS XML instance. The "ERR" message is used for 182 sending fault codes. The list of allowable fault codes is listed in 183 BEEP [2]. 185 6. Server Authentication Methods 187 6.1 Registry Dependent Methods 189 When using the TLS [5] tuning profile in BEEP, it is possible to 190 verify the authenticity of the server. However, a convention is 191 needed to conduct this authentication. This convention dictates the 192 name of the authority used by a client to ask for authentication 193 credentials so that the server knows which set of credentials to pass 194 back. Because this is dependent on the authority component of the 195 URI, each registry type must define a server authentication method. 197 If a registry type does not explicitly define a server authentication 198 method, the default method is used (see Section 6.2. 200 6.2 Default Authentication Method 202 The default server authentication method is as follows: 204 1. When connecting to a server, the client MUST present the name of 205 the authority to the server using the BEEP [2] serverName 206 mechanism. For instance, if the URI "iris:com/dreg/domain/ 207 example.com" is being resolved, the client would use the 208 serverName="com" attribute during the BEEP session instantiation. 210 2. During TLS negotiation, the server presents to the client a 211 certificate for the authority given in serverName. This 212 certificate MUST be an X509 [16] certificate. This certificate 213 MUST contain the authority in either the subjectDN or the 214 subjectAltName extension of type dNSName. 216 3. The certificate MUST cryptographically verify according to the 217 procedures of TLS. 219 4. The client then checks the content of the subjectDN or dNSName. 220 Matching for both the types is case insensitive. A wildcard 221 character ('*') MAY be used as the left-most component of the 222 name. If more than one dNSName is present, a match on any one is 223 acceptable. 225 7. IRIS Transport Mapping Definitions 227 This section lists the definitions required by IRIS [9] for transport 228 mappings. 230 7.1 URI Scheme 232 The URI scheme name specific to BEEP over IRIS MUST be "iris.beep". 234 7.2 Application Protocol Label 236 The application protocol label MUST be "iris.beep". 238 7.3 BEEP Mapping 240 The mapping of IRIS in this document is specific to RFC 3080 [2]. 241 This mapping MUST use TCP as specified by RFC 3081 [3]. 243 8. Registrations 245 8.1 BEEP Profile Registration 247 Profile Identification: http://iana.org/beep/transient/crisp/iris/0.2 249 Messages exchanged during Channel Creation: none 251 Messages starting one-to-one exchanges: IRIS XML instance 253 Messages in positive replies: IRIS XML instance 255 Messages in negative replies: none 257 Messages in one-to-many exchanges: none 259 Message Syntax: IRIS XML instances as defined by IRIS [9]. 261 Message Semantics: request/response exchanges as defined by IRIS [9]. 263 Contact Information: Andrew Newton 265 8.2 URI Scheme Registration 267 URL scheme name: iris.beep 269 URL scheme syntax: defined in Section 7.1 and [9]. 271 Character encoding considerations: as defined in RFC2396 [12]. 273 Intended usage: identifies an IRIS entity made available using the 274 BEEP profile for IRIS 276 Applications using this scheme: defined in IRIS [9]. 278 Interoperability considerations: n/a 280 Security Considerations: defined in Section 12. 282 Relevant Publications: BEEP [2] and IRIS [9]. 284 Contact Information: Andrew Newton 286 Author/Change controller: the IESG 288 8.3 Well-known TCP Port Registration 290 Protocol Number: TCP 291 Message Formats, Types, Opcodes, and Sequences: defined in Section 3, 292 Section 4, and Section 5. 294 Functions: defined in IRIS [9]. 296 Use of Broadcast/Multicast: none 298 Proposed Name: IRIS over BEEP 300 Short name: iris.beep 302 Contact Information: Andrew Newton 304 8.4 NAPSTR Registration 306 Application Protocol Label: iris.beep 308 Intended usage: identifies an IRIS server using BEEP 310 Interoperability considerations: n/a 312 Security Considerations: defined in Section 12. 314 Relevant Publications: BEEP [2] and IRIS [9]. 316 Contact Information: Andrew Newton 318 Author/Change controller: the IESG 320 9. Registry Definition Checklist 322 Specifications of registry types MUST include the following explicit 323 definitions: 325 o message pattern - A definition of the message pattern for use with 326 BEEP or a declaration to use the default message pattern in 327 Section 5.2. 329 o server authentication method - A definition of the method to use 330 for server authentication with TLS or a declaration to use the 331 default server authentication method in Section 6.2. 333 10. Internationalization Considerations 335 IRIS XML instances using this transport MUST use UTF-8. See Section 336 5. 338 11. IANA Considerations 340 Registrations with the IANA are described in Section 8. 342 12. Security Considerations 344 Implementers should be fully aware of the security considerations 345 given by IRIS [9], BEEP [2], and TLS [5]. With respect to server 346 authentication with the use of TLS, see . 348 Clients SHOULD be prepared to use the following BEEP tuning profiles: 350 o http://iana.org/beep/SASL/DIGEST-MD5 - for user authentication 351 without the need of session encryption. 353 o http://iana.org/beep/SASL/OTP - for user authentication without 354 the need of session encryption. 356 o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 357 cipher - for encryption. 359 o http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 360 cipher with client-side certificates - for encryption and user 361 authentication. 363 Anonymous client access should be considered in one of two methods: 365 1. When no authentication tuning profile has been used. 367 2. Using the SASL anonymous profile: http://iana.org/beep/SASL/ 368 ANONYMOUS 370 IRIS contains a referral mechanism as a standard course of operation. 371 However, care should be taken that user authentication mechanisms do 372 not hand user credentials to untrusted servers. Therefore, clients 373 SHOULD NOT use the http://iana.org/beep/SASL/PLAIN tuning profile. 375 References 377 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 378 1.0", W3C XML, February 1998, . 381 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 382 3080, March 2001. 384 [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 385 2001. 387 [4] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 388 RFC 2817, May 2000. 390 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 391 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 392 1999. 394 [6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 395 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 396 HTTP/1.1", RFC 2616, June 1999. 398 [7] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 399 3205, February 2002. 401 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 402 Levels", RFC 2119, BCP 14, March 1997. 404 [9] Newton, A., "Internet Registry Information Service", 405 draft-ietf-crisp-iris-core-01 (work in progress), November 406 2002. 408 [10] Hollenbeck, S., "EPP TCP Transport", Internet Draft, a work 409 in-progress., January 2002. 411 [11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 413 [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 414 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 415 1998. 417 [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax 418 Specifications: ABNF", RFC 2234, November 1997. 420 [14] The Unicode Consortium, "The Unicode Standard, Version 2.0", 421 ISBN 0-201-48345-9 ISBN 0-201-48345-9, January 1988, . 424 [15] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 425 Requirements", draft-ietf-crisp-requirements-02 (work in 426 progress), October 2002. 428 [16] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 429 Public Key Infrastructure Certificate and CRL Profile", RFC 430 2459, January 1999. 432 [17] Mealling, M., "The IETF XML Registry", 433 draft-mealling-iana-xmlns-registry-04 (work in progress), July 434 2002. 436 [18] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 437 3023, January 2001. 439 [19] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 440 specifying the location of services (DNS SRV)", RFC 2782, 441 February 2000. 443 Author's Address 445 Andrew L. Newton 446 VeriSign, Inc. 447 21345 Ridgetop Circle 448 Sterling, VA 20166 449 USA 451 Phone: +1 703 948 3382 452 EMail: anewton@verisignlabs.com; anewton@ecotroph.net 453 URI: http://www.verisignlabs.com/ 455 Intellectual Property Statement 457 The IETF takes no position regarding the validity or scope of any 458 intellectual property or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; neither does it represent that it 462 has made any effort to identify any such rights. Information on the 463 IETF's procedures with respect to rights in standards-track and 464 standards-related documentation can be found in BCP-11. Copies of 465 claims of rights made available for publication and any assurances of 466 licenses to be made available, or the result of an attempt made to 467 obtain a general license or permission for the use of such 468 proprietary rights by implementors or users of this specification can 469 be obtained from the IETF Secretariat. 471 The IETF invites any interested party to bring to its attention any 472 copyrights, patents or patent applications, or other proprietary 473 rights which may cover technology that may be required to practice 474 this standard. Please address the information to the IETF Executive 475 Director. 477 Full Copyright Statement 479 Copyright (C) The Internet Society (2003). All Rights Reserved. 481 This document and translations of it may be copied and furnished to 482 others, and derivative works that comment on or otherwise explain it 483 or assist in its implementation may be prepared, copied, published 484 and distributed, in whole or in part, without restriction of any 485 kind, provided that the above copyright notice and this paragraph are 486 included on all such copies and derivative works. However, this 487 document itself may not be modified in any way, such as by removing 488 the copyright notice or references to the Internet Society or other 489 Internet organizations, except as needed for the purpose of 490 developing Internet standards in which case the procedures for 491 copyrights defined in the Internet Standards process must be 492 followed, or as required to translate it into languages other than 493 English. 495 The limited permissions granted above are perpetual and will not be 496 revoked by the Internet Society or its successors or assignees. 498 This document and the information contained herein is provided on an 499 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 500 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 501 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 502 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 503 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 505 Acknowledgement 507 Funding for the RFC Editor function is currently provided by the 508 Internet Society.