idnits 2.17.1 draft-ietf-sidr-publication-09.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 402 has weird spacing: '...element erro...' == Line 403 has weird spacing: '...element fail...' -- The document date (September 21, 2016) is 2773 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 (~~), 3 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 25, 2017 TowerSec 6 R. Austein 7 Dragon Research Labs 8 September 21, 2016 10 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 11 draft-ietf-sidr-publication-09 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 25, 2017. 38 Copyright Notice 40 Copyright (c) 2016 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. Publication and Withdrawal . . . . . . . . . . . . . . . 4 60 2.3. Listing the repository . . . . . . . . . . . . . . . . . 5 61 2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 6 62 2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1. Query, No Existing Object . . . . . . . . . . 9 66 3.2. Query, Overwriting Existing Object . . . . . . 10 67 3.3. Query . . . . . . . . . . . . . . . . . . . . 10 68 3.4. Reply . . . . . . . . . . . . . . . . . . . . 10 69 3.5. With Optional Elements . . . . . . . . . 10 70 3.6. Without Optional Elements . . . . . . . . 11 71 3.7. Error Handling With Multi-Element Queries . . . . . . . . 11 72 3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11 73 3.7.2. Successful Multi-Element Response . . . . . . . . . . 12 74 3.7.3. Failure Multi-Element Response, First Error Only . . 12 75 3.7.4. Failure Multi-Element Response, All Errors . . . . . 13 76 3.8. Query . . . . . . . . . . . . . . . . . . . . . . 14 77 3.9. Reply . . . . . . . . . . . . . . . . . . . . . . 14 78 4. Operational Considerations . . . . . . . . . . . . . . . . . 14 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 83 7.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 This document assumes a working knowledge of the Resource Public Key 89 Infrastructure (RPKI), which is intended to support improved routing 90 security on the Internet. [RFC6480] 92 In order to make participation in the RPKI easier, it is helpful to 93 have a few consolidated repositories for RPKI objects, thus saving 94 every participant from the cost of maintaining a new service. 95 Similarly, relying parties using the RPKI objects will find it faster 96 and more reliable to retrieve the necessary set from a smaller number 97 of repositories. 99 These consolidated RPKI object repositories will in many cases be 100 outside the administrative scope of the organization issuing a given 101 RPKI object. In some cases, outsourcing operation of the repository 102 will be an explicit goal: some resource holders who strongly wish to 103 control their own RPKI private keys may lack the resources to operate 104 a 24x7 repository, or may simply not wish to do so. 106 The operator of an RPKI publication repository may well be an 107 Internet registry which issues certificates to its customers, but it 108 need not be; conceptually, operation of a an RPKI publication 109 repository is separate from operation of RPKI CA. 111 This document defines an RPKI publication protocol which allows 112 publication either within or across organizational boundaries, and 113 which makes fairly minimal demands on either the CA engine or the 114 publication service. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 "Publication engine" and "publication server" are used 123 interchangeably to refer to the server providing the service 124 described in this document. 126 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 127 refers to a PKI, separate from the RPKI, used to authenticate clients 128 to the publication engine. We use the term "Business PKI" here 129 because an Internet registry might already have a PKI for 130 authenticating its clients and might wish to reuse that PKI for this 131 protocol. There is, however, no requirement to reuse such a PKI. 133 2. Protocol Specification 135 The publication protocol uses XML messages wrapped in signed CMS 136 messages, carried over HTTP transport. 138 The publication protocol uses a simple request/response interaction. 139 The client passes a request to the server, and the server generates a 140 corresponding response. 142 A message exchange commences with the client initiating an HTTP POST 143 with content type of "application/rpki-publication", with the message 144 object as the body. The server's response will similarly be the body 145 of the response with a content type of "application/rpki- 146 publication". 148 The content of the POST and the server's response will be a well- 149 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 150 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 152 2.1. Common XML Message Format 154 The XML schema for this protocol is below in Section 2.6. The basic 155 XML message format looks like this: 157 161 162 164 168 169 171 Common attributes: 173 version: The value of this attribute is the version of this 174 protocol. This document describes version 4. 176 type: The possible values of this attribute are "reply" and "query". 178 A query PDU may be one of three types: , , or 179 . 181 A reply PDU may be one of three types: , , or 182 . 184 The and PDUs include a tag to facilitate bulk 185 operation. 187 2.2. Publication and Withdrawal 189 The publication protocol uses a common message format to request 190 publication of any RPKI object. This format was chosen specifically 191 to allow this protocol to accommodate new types of RPKI objects 192 without needing changes to this protocol. 194 Both the and PDUs have a payload of a tag and 195 a URI. The query also contains the DER object to be 196 published, encoded in Base64. 198 Both the and PDUs also have a "hash" 199 attribute, which carries a hash of an existing object at the 200 specified repository URI. For PDUs, the hash is 201 mandatory, as this operation makes no sense if there is no existing 202 object to withdraw. For PDUs, the hash MUST be present if 203 the publication operation is overwriting an existing object, and MUST 204 be omitted if this publication operation is writing to a new URI 205 where no prior object exists. Presence of an object when no "hash" 206 attribute is specified is an error, as is absence of the "hash" 207 attribute or an incorrect hash value when an object is present. Any 208 such errors MUST be reported using the PDU. 210 The hash algorithm is SHA-256 [SHS], to simplify comparison of 211 publication protocol hashes with RPKI manifest hashes. 213 The intent behind the "hash" attribute is to allow the client and 214 server to detect any disagreements about the effect that a 215 or PDU will have on the repository. 217 Note that every publish and withdraw action requires a new manifest, 218 thus every publish or withdraw action will involve at least two 219 objects. 221 Processing of a query message is handled atomically: either the 222 entire query succeeds or none of it does. When a query message 223 contains multiple PDUs, failure of any PDU may require the server to 224 roll back actions triggered by earlier PDUs. 226 When a query messages containing and/or PDUs 227 succeeds, a single reply is returned. 229 When a query fails, one or more reply PDUs are 230 generated. Typically, only one reply is generated, 231 corresponding to the first query PDU that failed. Servers are 232 permitted to return multiple PDUs. 234 2.3. Listing the repository 236 The operation allows the client to ask the server for a 237 complete listing of objects which the server believes the client has 238 published. This is intended primarily to allow the client to recover 239 upon detecting (probably via use of the "hash" attribute, see 240 Section 2.2) that they have somehow lost synchronization. 242 The query consists of a single PDU. A query must be 243 the only PDU in a query - it may not be combined with any 244 or queries. 246 The reply consists of zero or more PDUs, one per object 247 published in this repository by this client, each PDU conveying the 248 URI and hash of one published object. 250 2.4. Error handling 252 Errors are handled at two levels. 254 Errors that make it impossible to decode a query or encode a response 255 are handled at the HTTP layer. 4xx and 5xx HTTP response codes 256 indicate that something bad happened. 258 In all other cases, errors result in an XML PDU. 259 Like the rest of this protocol, PDUs are CMS-signed 260 XML messages and thus can be archived to provide an audit trail. 262 PDUs only appear in replies, never in queries. 264 The "tag" attribute of the PDU associated with a 265 or PDU MUST be set to the same value as the 266 "tag" attribute in the PDU which generated the error. A client can 267 use the "tag" attribute to determine which PDU caused processing of 268 an update to fail. 270 The error itself is conveyed in the "error_code" attribute. The 271 value of this attribute is a token indicating the specific error that 272 occurred. 274 The body of the element contains two sub-elements: 276 1. An optional text element , which if present, 277 contains a text string with debugging information intended for 278 human consumption. 280 2. An optional element , which, if present, contains a 281 verbatim copy of the query PDU whose failure triggered the 282 PDU. The quoted element must be syntactically 283 valid. 285 See Section 3.7 for examples of a multi-element query and responses. 287 2.5. Error Codes 289 These are the defined error codes as well as some discussion of each. 290 Text similar to these descriptions may be sent in an 291 element to help explain the error encountered. 293 xml_error: Encountered an XML problem. Note that some XML errors 294 may be severe enough to require error reporting at the HTTP layer, 295 instead. Implementations MAY choose to report any or all XML 296 errors at the HTTP layer. 298 permission_failure: Client does not have permission to update this 299 URI. 301 bad_cms_signature: Bad CMS signature. 303 object_already_present: An object is already present at this URI, 304 yet a "hash" attribute was not specified. A "hash" attribute must 305 be specified when overwriting or deleting an object. Perhaps 306 client and server are out of sync? 308 no_object_present: There is no object present at this URI, yet a 309 "hash" attribute was specified. Perhaps client and server are out 310 of sync? 312 no_object_matching_hash The "hash" attribute supplied does not match 313 the "hash" attribute of the object at this URI. Perhaps client 314 and server are out of sync? 316 consistency_problem: Server detected an update that looks like it 317 will cause a consistency problem (e.g. an object was deleted, but 318 the manifest was not updated). Note that a server is not required 319 to make such checks. Indeed, it may be unwise for a server to do 320 so. This error code just provides a way for the server to explain 321 its (in-)action. 323 other_error: A meteor fell on the server. 325 2.6. XML Schema 327 The following is a RelaxNG compact form schema describing the 328 Publication Protocol. 330 # $Id: rpki-publication.rnc 3785 2016-09-21 22:21:58Z sra $ 331 # RelaxNG schema for RPKI publication protocol. 333 default namespace = 334 "http://www.hactrn.net/uris/rpki/publication-spec/" 336 # This is version 4 of the protocol. 338 version = "4" 340 # Top level PDU is either a query or a reply. 342 start |= element msg { 343 attribute version { version }, 344 attribute type { "query" }, 345 query_elt 346 } 348 start |= element msg { 349 attribute version { version }, 350 attribute type { "reply" }, 351 reply_elt 352 } 354 # Tag attributes for bulk operations. 356 tag = attribute tag { xsd:token { maxLength="1024" } } 358 # Base64 encoded DER stuff. 360 base64 = xsd:base64Binary 362 # Publication URIs. 364 uri = attribute uri { xsd:anyURI { maxLength="4096" } } 366 # Digest of an existing object (hexadecimal). 368 hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } } 370 # Error codes. 372 error |= "xml_error" 373 error |= "permission_failure" 374 error |= "bad_cms_signature" 375 error |= "object_already_present" 376 error |= "no_object_present" 377 error |= "no_object_matching_hash" 378 error |= "consistency_problem" 379 error |= "other_error" 381 # and query elements 383 query_elt |= ( 384 element publish { tag, uri, hash?, base64 } | 385 element withdraw { tag, uri, hash } 386 )* 388 # reply 390 reply_elt |= element success { empty } 392 # query and reply 394 query_elt |= element list { empty } 395 reply_elt |= element list { uri, hash }* 397 # reply 399 reply_elt |= element report_error { 400 tag?, 401 attribute error_code { error }, 402 element error_text { xsd:string { maxLength="512000" }}?, 403 element failed_pdu { query_elt }? 404 }* 406 3. Examples 408 Following are examples of various queries and the corresponding 409 replies for the RPKI publication protocol. 411 Note the authors have taken liberties with the Base64, hash, and URI 412 text in these examples in the interest of making the examples fit 413 nicely into RFC text format. 415 3.1. Query, No Existing Object 417 421 424 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 425 426 428 3.2. Query, Overwriting Existing Object 430 434 438 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 439 440 442 3.3. Query 444 448 452 454 3.4. Reply 456 460 461 463 3.5. With Optional Elements 464 468 471 472 Can't delete an object I don't have 473 474 475 479 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 480 481 482 483 485 3.6. Without Optional Elements 487 491 494 496 3.7. Error Handling With Multi-Element Queries 498 3.7.1. Multi-Element Query 499 503 506 SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= 507 508 512 515 SGVsbG8sIG15IG5hbWUgaXMgQ2Fyb2w= 516 517 521 524 SGVsbG8sIG15IG5hbWUgaXMgRXZl 525 526 528 3.7.2. Successful Multi-Element Response 530 534 535 537 3.7.3. Failure Multi-Element Response, First Error Only 538 542 545 546 550 551 552 554 3.7.4. Failure Multi-Element Response, All Errors 556 560 563 564 568 569 570 573 574 577 SGVsbG8sIG15IG5hbWUgaXMgRXZl 578 579 580 581 583 3.8. Query 585 589 590 592 3.9. Reply 594 598 601 604 607 610 612 4. Operational Considerations 614 There are two basic options open to the repository operator as to how 615 the publication tree is laid out. The first option is simple: each 616 publication client is given its own directory one level below the top 617 of the rsync module, and there is no overlap between the publication 618 spaces used by different clients. For example: 620 rsync://example.org/rpki/Alice/ 621 rsync://example.org/rpki/Bob/ 622 rsync://example.org/rpki/Carol/ 624 This has the advantage of being very easy for the publication 625 operator to manage, but has the drawback of making it difficult for 626 relying parties to fetch published objects both safely and as 627 efficiently as possible. 629 Given that the mandatory-to-implement retrieval protocol for relying 630 parties is rsync, a more efficient repository structure would be one 631 which minimized the number of rsync fetches required. One such 632 structure would be one in which the publication directories for 633 subjects were placed underneath the publication directories of their 634 issuers: since the normal synchronization tree walk is top-down, this 635 can significantly reduce the total number of rsync connections 636 required to synchronize. For example: 638 rsync://example.org/rpki/Alice/ 639 rsync://example.org/rpki/Alice/Bob/ 640 rsync://example.org/rpki/Alice/Bob/Carol/ 642 Preliminary measurement suggests that, in the case of large numbers 643 of small publication directories, the time needed to set up and tear 644 down individual rsync connections becomes significant, and that a 645 properly optimized tree structure can reduce synchronization time by 646 an order of magnitude. 648 The more complex tree structure does require careful attention to the 649 "base_uri" attribute values when setting up clients. In the example 650 above, assuming that Alice issues to Bob who in turn issues to Carol, 651 Alice has ceded control of a portion of her publication space to Bob, 652 who has in turn ceded a portion of that to Carol, and the "base_uri" 653 attributes in the setup messages should reflect this. 655 The details of how the repository operator determines that Alice has 656 given Bob permission to nest Bob's publication directory under 657 Alice's is outside the scope of this protocol. 659 5. IANA Considerations 661 IANA is asked to register the application/rpki-publication MIME media 662 type as follows: 664 MIME media type name: application 665 MIME subtype name: rpki-publication 666 Required parameters: None 667 Optional parameters: None 668 Encoding considerations: binary 669 Security considerations: Carries an RPKI Publication Protocol 670 Message, as defined in this document. 671 Interoperability considerations: None 672 Published specification: This document 673 Applications which use this media type: HTTP 674 Additional information: 675 Magic number(s): None 676 File extension(s): 677 Macintosh File Type Code(s): 678 Person & email address to contact for further information: 679 Rob Austein 680 Intended usage: COMMON 681 Author/Change controller: Rob Austein 683 6. Security Considerations 685 The RPKI publication protocol and the data it publishes use entirely 686 separate PKIs for authentication. The published data is 687 authenticated within the RPKI, and this protocol has nothing to do 688 with that authentication, nor does it require that the published 689 objects be valid in the RPKI. The publication protocol uses a 690 separate Business PKI (BPKI) to authenticate its messages. 692 Each RPKI publication protocol message is CMS-signed. Because of 693 that protection at the application layer, this protocol does not 694 require the use of HTTPS or other transport security mechanisms. 696 Although the hashes used in the and PDUs are 697 cryptographic strength, the digest algorithm was selected for 698 convenience in comparing these hashes with the hashes that appear in 699 RPKI manifests. The hashes used in the and 700 PDUs are not particularly security-sensitive, because these PDUs are 701 protected by the CMS signatures. 703 Compromise of a publication server, perhaps through mismanagement of 704 BPKI keys, could lead to a denial-of-service attack on the RPKI. An 705 attacker gaining access to BPKI keys could use this protocol delete 706 (withdraw) RPKI objects, leading to routing changes or failures. 707 Accordingly, as in most PKIs, good key management practices are 708 important. 710 7. References 712 7.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", RFC 2119, BCP 14, March 1997. 717 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 718 RFC 5652, STD 70, September 2009. 720 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 721 Protocol for Provisioning Resource Certificates", 722 RFC 6492, February 2012. 724 [SHS] National Institute of Standards and Technology, "Secure 725 Hash Standard", FIPS PUB 180-4, March 2012, 726 . 729 7.2. Informative References 731 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 732 Secure Internet Routing", RFC 6480, February 2012. 734 Authors' Addresses 736 Samuel Weiler 737 Parsons 739 Email: weiler@tislabs.com 741 Anuja Sonalker 742 TowerSec Automotive Cyber Security 744 Email: asonalker@tower-sec.com 746 Rob Austein 747 Dragon Research Labs 749 Email: sra@hactrn.net