idnits 2.17.1 draft-ietf-sidr-publication-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 365 has weird spacing: '...owed in queri...' == Line 416 has weird spacing: '...element erro...' == Line 417 has weird spacing: '...element fail...' -- The document date (September 25, 2015) is 3136 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft Parsons 4 Intended status: Standards Track A. Sonalker 5 Expires: March 28, 2016 Battelle Memorial Institute 6 R. Austein 7 Dragon Research Labs 8 September 25, 2015 10 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 11 draft-ietf-sidr-publication-07 13 Abstract 15 This document defines a protocol for publishing Resource Public Key 16 Infrastructure (RPKI) objects. Even though the RPKI will have many 17 participants issuing certificates and creating other objects, it is 18 operationally useful to consolidate the publication of those objects. 19 This document provides the protocol for doing so. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 28, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 58 2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4 59 2.2. General Operation . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Publication and Withdrawal . . . . . . . . . . . . . . . 5 61 2.4. Listing the repository . . . . . . . . . . . . . . . . . 5 62 2.5. Error handling . . . . . . . . . . . . . . . . . . . . . 6 63 2.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Query, No Existing Object . . . . . . . . . . 10 67 3.2. Query, Overwriting Existing Object . . . . . . 10 68 3.3. Reply . . . . . . . . . . . . . . . . . . . . 10 69 3.4. Query . . . . . . . . . . . . . . . . . . . . 10 70 3.5. Reply . . . . . . . . . . . . . . . . . . . . 11 71 3.6. With Optional Elements . . . . . . . . . 11 72 3.7. Without Optional Elements . . . . . . . . 11 73 3.8. Error Handling With Multi-Element Queries . . . . . . . . 11 74 3.8.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11 75 3.8.2. Successful Multi-Element Response . . . . . . . . . . 12 76 3.8.3. Failure Multi-Element Response . . . . . . . . . . . 13 77 4. Operational Considerations . . . . . . . . . . . . . . . . . 14 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 7.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 This document assumes a working knowledge of the Resource Public Key 88 Infrastructure (RPKI), which is intended to support improved routing 89 security on the Internet. [RFC6480] 91 In order to make participation in the RPKI easier, it is helpful to 92 have a few consolidated repositories for RPKI objects, thus saving 93 every participant from the cost of maintaining a new service. 94 Similarly, relying parties using the RPKI objects will find it faster 95 and more reliable to retrieve the necessary set from a smaller number 96 of repositories. 98 These consolidated RPKI object repositories will in many cases be 99 outside the administrative scope of the organization issuing a given 100 RPKI object. In some cases, outsourcing operation of the repository 101 will be an explicit goal: some resource holders who strongly wish to 102 control their own RPKI private keys may lack the resources to operate 103 a 24x7 repository, or may simply not wish to do so. 105 The operator of an RPKI publication repository may well be an 106 Internet registry which issues certificates to its customers, but it 107 need not be; conceptually, operation of a an RPKI publication 108 repository is separate from operation of RPKI CA. 110 This document defines an RPKI publication protocol which allows 111 publication either within or across organizational boundaries, and 112 which makes fairly minimal demands on either the CA engine or the 113 publication service. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 "Publication engine" and "publication server" are used 122 interchangeably to refer to the server providing the service 123 described in this document. 125 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 126 refers to a PKI, separate from the RPKI, used to authenticate clients 127 to the publication engine. We use the term "Business PKI" here 128 because an internet registry might already have a PKI for 129 authenticating its clients and might wish to reuse that PKI for this 130 protocol. There is, however, no requirement to reuse such a PKI. 132 2. Protocol Specification 134 The publication protocol uses XML messages wrapped in signed CMS 135 messages, carried over HTTP transport. 137 The publication protocol uses a simple request/response interaction. 138 The client passes a request to the server, and the server generates a 139 corresponding response. 141 A message exchange commences with the client initiating an HTTP POST 142 with content type of "application/rpki-publication", with the message 143 object as the body. The server's response will similarly be the body 144 of the response with a content type of "application/rpki- 145 publication". 147 The content of the POST and the server's response will be a well- 148 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 149 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 151 2.1. Common XML Message Format 153 The XML schema for this protocol is below in Section 2.7. The basic 154 XML message format looks like this: 156 160 161 163 167 168 170 Common attributes: 172 version: The value of this attribute is the version of this 173 protocol. This document describes version 3. 175 type: The possible values of this attribute are "reply" and "query". 177 A query PDU may be one of three types: , , or 178 . 180 A reply PDU may be one of four types: , , 181 , or . 183 Each of these PDUs may include an optional tag to facilitate bulk 184 operation. If a tag is set in a query PDU, the corresponding 185 reply(s) or error(s) MUST have the tag attribute set to the same 186 value. 188 2.2. General Operation 190 Processing of a query message is handled atomically: either the 191 entire query succeeds or none of it does. When a query message 192 contains multiple PDUs, failure of any PDU may require the server to 193 roll back actions triggered by earlier PDUs. 195 2.3. Publication and Withdrawal 197 The publication protocol uses a common message format to request 198 publication of any RPKI object. This format was chosen specifically 199 to allow this protocol to accommodate new types of RPKI objects 200 without needing changes to this protocol. 202 Both the and PDUs have a payload of an 203 optional tag and a URI. The query also contains the DER 204 object to be published, encoded in Base64. 206 Both the and PDUs also have a "hash" 207 attribute, which carries a hash of an existing object at the 208 specified repository URI. For PDUs, the hash is 209 mandatory, as this operation makes no sense if there is no existing 210 object to withdraw. For PDUs, the hash MUST be present if 211 the publication operation is overwriting an existing object, and MUST 212 be omitted if this publication operation is writing to a new URI 213 where no prior object exists. Presence of an object when no hash 214 attribute is specified is an error, as is absence of the hash 215 attribute or an incorrect hash value when an object is present. Any 216 such errors MUST be reported using the PDU. 218 The hash algorithm is SHA-256 [SHS], to simplify comparison of 219 publication protocol hashes with RPKI manifest hashes. 221 The intent behind the hash attribute is to allow the client and 222 server to detect any disagreements about the effect that a 223 or PDU will have on the repository. 225 Note that every publish and withdraw action requires a new manifest, 226 thus every publish or withdraw action will involve at least two 227 objects. 229 2.4. Listing the repository 231 The operation allows the client to ask the server for a 232 complete listing of objects which the server believes the client has 233 published. This is intended primarily to allow the client to recover 234 upon detecting (probably via use of the "hash" attribute, see 235 Section 2.3) that they have somehow lost synchronization. 237 The query consists of a single PDU. 239 The reply consists of zero or more PDUs, one per object 240 published in this repository by this client, each PDU conveying the 241 URI and hash of one published object. 243 2.5. Error handling 245 Errors are handled at two levels. 247 Errors that make it impossible to decode a query or encode a response 248 are handled at the HTTP layer. 4xx and 5xx HTTP response codes 249 indicate that something bad happened. 251 In all other cases, errors result in an XML PDU which 252 takes the place of the expected protocol response PDU. Like the rest 253 of this protocol, PDUs are CMS-signed XML messages 254 and thus can be archived to provide an audit trail. 256 PDUs only appear in replies, never in queries. 258 Like all other reply PDUs, if a "tag" attribute was set on the query 259 that generated the error, the PDU MUST have its tag 260 attribute set to the same value. 262 The error itself is conveyed in the error_code attribute. The value 263 of this attribute is a token indicating the specific error that 264 occurred. 266 The body of the element contains two sub-elements: 268 1. An optional text element , which if present, 269 contains a text string with debugging information intended for 270 human consumption. 272 2. An optional element , which, if present, contains a 273 verbatim copy of the query PDU whose failure triggered the 274 PDU. The quoted element must be syntactically 275 valid. 277 The position of a element in a reply corresponds to 278 the point in processing the query message where the error occurred. 279 In the simple case of a query message containing only a single 280 element, the element will be the only element in the 281 reply. If, however, the query message contains more than one 282 element, the element may be preceeded by normal 283 responses indicating operations that would have succeeded. 285 There are several ways that a client can match up elements in a 286 response message with the corresponding elements in the query 287 message: 289 o For a one-element query, this is trivial. 291 o For multi-element queries, the simplest way of matching resposes 292 uses the optional tag attribute. The protocol requires tags from 293 query elements to be copied into reply elements, so simply giving 294 each query element a unique tag will suffice. 296 o If for some reason the client implementation is not able or 297 willing to use unique tags within a multi-element query message, 298 the client can still match queries to responses by counting 299 elements in the reply message. This approach is not recommended. 301 See Section 3.8 for examples of a multi-element query and responses. 303 2.6. Error Codes 305 These are the defined error codes as well as some discussion of each. 306 Text similar to these descriptions may be sent in an 307 element to help explain the error encountered. 309 permission_failure: Client does not have permission to update this 310 URI. 312 bad_cms_signature: Bad CMS signature. 314 object_already_present: An object is already present at this URI, 315 yet a hash attribute was not specified. A hash attribute must be 316 specified when overwriting or deleting an object. Perhaps client 317 and server are out of sync? 319 no_object_present: There is no object present at this URI, yet a 320 hash attribute was specified. Perhaps client and server are out 321 of sync? 323 no_object_matching_hash The hash attribute supplied does not match 324 the hash attribute of the object at this URI. Perhaps client and 325 server are out of sync? 327 consistency_problem: Server detected an update that looks like it 328 will cause a consistency problem (e.g. an object was deleted, but 329 the manifest was not updated). Note that a server is not required 330 to make such checks. Indeed, it may be unwise for a server to do 331 so. This error code just provides a way for the server to explain 332 its (in-)action. 334 other_error: A meteor fell on the server. 336 2.7. XML Schema 338 The following is a RelaxNG compact form schema describing the 339 Publication Protocol. 341 # $Id: rpki-publication.rnc 3407 2015-09-25 21:05:28Z sra $ 342 # RelaxNG schema for RPKI publication protocol. 344 default namespace = 345 "http://www.hactrn.net/uris/rpki/publication-spec/" 347 # This is version 3 of the protocol. 349 version = "3" 351 # Top level PDU is either a query or a reply. 353 start |= element msg { 354 attribute version { version }, 355 attribute type { "query" }, 356 query_elt* 357 } 359 start |= element msg { 360 attribute version { version }, 361 attribute type { "reply" }, 362 reply_elt* 363 } 365 # PDUs allowed in queries and replies. 367 query_elt = publish_query | withdraw_query | list_query 368 reply_elt = publish_reply | withdraw_reply | list_reply | error_reply 370 # Tag attributes for bulk operations. 372 tag = attribute tag { xsd:token { maxLength="1024" } } 374 # Base64 encoded DER stuff. 376 base64 = xsd:base64Binary 378 # Publication URIs. 380 uri = attribute uri { xsd:anyURI { maxLength="4096" } } 382 # Digest of an existing object (hexadecimal). 384 hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } } 386 # Error codes. 388 error |= "permission_failure" 389 error |= "bad_cms_signature" 390 error |= "object_already_present" 391 error |= "no_object_present" 392 error |= "no_object_matching_hash" 393 error |= "consistency_problem" 394 error |= "other_error" 396 # element 398 publish_query = element publish { tag?, uri, hash?, base64 } 399 publish_reply = element publish { tag?, uri } 401 # element 403 withdraw_query = element withdraw { tag?, uri, hash } 404 withdraw_reply = element withdraw { tag?, uri } 406 # element 408 list_query = element list { tag? } 409 list_reply = element list { tag?, uri, hash } 411 # element 413 error_reply = element report_error { 414 tag?, 415 attribute error_code { error }, 416 element error_text { xsd:string { maxLength="512000" }}?, 417 element failed_pdu { query_elt }? 418 } 420 3. Examples 422 Following are examples of various queries and the corresponding 423 replies for the RPKI publication protocol. 425 Note the authors have taken liberties with the Base64, hash, and URI 426 text in these examples in the interest of making the examples fit 427 nicely into RFC text format. 429 3.1. Query, No Existing Object 431 435 437 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u 438 439 441 3.2. Query, Overwriting Existing Object 443 447 450 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u 451 452 454 3.3. Reply 456 460 462 464 3.4. Query 466 470 473 475 3.5. Reply 477 481 483 485 3.6. With Optional Elements 487 491 493 494 Can't delete an object I don't have 495 496 497 500 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u 501 502 503 504 506 3.7. Without Optional Elements 508 512 514 516 3.8. Error Handling With Multi-Element Queries 518 3.8.1. Multi-Element Query 519 523 526 QWxpY2U= 527 528 532 535 Q2Fyb2w= 536 537 538 542 545 RXZl 546 547 549 3.8.2. Successful Multi-Element Response 550 554 557 560 563 566 569 572 575 578 581 583 3.8.3. Failure Multi-Element Response 584 588 591 594 597 600 603 606 609 612 613 617 618 619 621 4. Operational Considerations 623 There are two basic options open to the repository operator as to how 624 the publication tree is laid out. The first option is simple: each 625 publication client is given its own directory one level below the top 626 of the rsync module, and there is no overlap between the publication 627 spaces used by different clients. For example: 629 rsync://example.org/rpki/Alice/ 630 rsync://example.org/rpki/Bob/ 631 rsync://example.org/rpki/Carol/ 632 This has the advantage of being very easy for the publication 633 operator to manage, but has the drawback of making it difficult for 634 relying parties to fetch published objects both safely and as 635 efficiently as possible. 637 Given that the mandatory-to-implement retrieval protocol for relying 638 parties is rsync, a more efficient repository structure would be one 639 which minimized the number of rsync fetches required. One such 640 structure would be one in which the publication directories for 641 subjects were placed underneath the publication directories of their 642 issuers: since the normal synchronization tree walk is top-down, this 643 can significantly reduce the total number of rsync connections 644 required to synchronize. For example: 646 rsync://example.org/rpki/Alice/ 647 rsync://example.org/rpki/Alice/Bob/ 648 rsync://example.org/rpki/Alice/Bob/Carol/ 650 Preliminary measurement suggests that, in the case of large numbers 651 of small publication directories, the time needed to set up and tear 652 down individual rsync connections becomes significant, and that a 653 properly optimized tree structure can reduce synchronization time by 654 an order of magnitude. 656 The more complex tree structure does require careful attention to the 657 base_uri attribute values when setting up clients. In the example 658 above, assuming that Alice issues to Bob who in turn issues to Carol, 659 Alice has ceded control of a portion of her publication space to Bob, 660 who has in turn ceded a portion of that to Carol, and the base_uri 661 attributes in the setup messages should reflect this. 663 The details of how the repository operator determines that Alice has 664 given Bob permission to nest Bob's publication directory under 665 Alice's is outside the scope of this protocol. 667 5. IANA Considerations 669 IANA is asked to register the application/rpki-publication MIME media 670 type as follows: 672 MIME media type name: application 673 MIME subtype name: rpki-publication 674 Required parameters: None 675 Optional parameters: None 676 Encoding considerations: binary 677 Security considerations: Carries an RPKI Publication Protocol 678 Message, as defined in this document. 679 Interoperability considerations: None 680 Published specification: This document 681 Applications which use this media type: HTTP 682 Additional information: 683 Magic number(s): None 684 File extension(s): 685 Macintosh File Type Code(s): 686 Person & email address to contact for further information: 687 Rob Austein 688 Intended usage: COMMON 689 Author/Change controller: Rob Austein 691 6. Security Considerations 693 The RPKI publication protocol and the data it publishes use entirely 694 separate PKIs for authentication. The published data is 695 authenticated within the RPKI, and this protocol has nothing to do 696 with that authentication, nor does it require that the published 697 objects be valid in the RPKI. The publication protocol uses a 698 separate Business PKI (BPKI) to authenticate its messages. 700 Each RPKI publication protocol message is CMS-signed. Because of 701 that protection at the application layer, this protocol does not 702 require the use of HTTPS or other transport security mechanisms. 704 Although the hashes used in the and PDUs are 705 cryptographic strength, the digest algorithm was selected for 706 convenience in comparing these hashes with the hashes that appear in 707 RPKI manifests. The hashes used in the and 708 PDUs are not particularly security-sensitive, because these PDUs are 709 protected by the CMS signatures. 711 Compromise of a publication server, perhaps through mismanagement of 712 BPKI keys, could lead to a denial-of-service attack on the RPKI. An 713 attacker gaining access to BPKI keys could use this protocol delete 714 (withdraw) RPKI objects, leading to routing changes or failures. 715 Accordingly, as in most PKIs, good key management practices are 716 important. 718 7. References 720 7.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", RFC 2119, BCP 14, March 1997. 725 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 726 5652, STD 70, September 2009. 728 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 729 Protocol for Provisioning Resource Certificates", RFC 730 6492, February 2012. 732 [SHS] National Institute of Standards and Technology, "Secure 733 Hash Standard", FIPS PUB 180-4, March 2012, 734 . 737 7.2. Informative References 739 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 740 Secure Internet Routing", RFC 6480, February 2012. 742 Authors' Addresses 744 Samuel Weiler 745 Parsons 747 Email: weiler@tislabs.com 749 Anuja Sonalker 750 Battelle Memorial Institute 752 Email: sonalkera@battelle.org 754 Rob Austein 755 Dragon Research Labs 757 Email: sra@hactrn.net