idnits 2.17.1 draft-ietf-sidr-publication-05.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 249 has weird spacing: '...owed in queri...' -- The document date (February 12, 2014) is 3725 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft SPARTA, Inc. 4 Intended status: Standards Track A. Sonalker 5 Expires: August 16, 2014 Battelle Memorial Institute 6 R. Austein 7 Dragon Research Labs 8 February 12, 2014 10 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) 11 draft-ietf-sidr-publication-05 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 August 16, 2014. 38 Copyright Notice 40 Copyright (c) 2014 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. Error handling . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Query . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Reply . . . . . . . . . . . . . . . . . . . . 8 65 3.3. Query . . . . . . . . . . . . . . . . . . . . 9 66 3.4. Reply . . . . . . . . . . . . . . . . . . . . 9 67 3.5. With Text . . . . . . . . . . . . . . . . 9 68 3.6. Without Text . . . . . . . . . . . . . . 9 69 4. Operational Considerations . . . . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 7.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 This document assumes a working knowledge of the Resource Public Key 80 Infrastructure (RPKI), which is intended to support improved routing 81 security on the Internet. [RFC6480] 83 In order to make participation in the RPKI easier, it is helpful to 84 have a few consolidated repositories for RPKI objects, thus saving 85 every participant from the cost of maintaining a new service. 86 Similarly, relying parties using the RPKI objects will find it faster 87 and more reliable to retrieve the necessary set from a smaller number 88 of repositories. 90 These consolidated RPKI object repositories will in many cases be 91 outside the administrative scope of the organization issuing a given 92 RPKI object. In some cases, outsourcing operation of the repository 93 will be an explicit goal: some resource holders who stringly wish to 94 control their own RPKI private keys may lack the resources to operate 95 a 24x7 repository, or may simply not wish to do so. 97 The operator of an RPKI publication repository may well be an 98 Internet registry which issues certificates to its customers, but it 99 need not be; conceptually, operation of a an RPKI publication 100 repository is separate from operation of RPKI CA. 102 This document defines an RPKI publication protocol which allows 103 publication either within or across organizational boundaries, and 104 which makes fairly minimal demands on either the CA engine or the 105 publication service. 107 1.1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 "Publication engine" and "publication server" are used 114 interchangeably to refer to the server providing the service 115 described in this document. 117 "Business Public Key Infrastructure" ("Business PKI" or "BPKI") 118 refers to a PKI, separate from the RPKI, used to authenticate clients 119 to the publication engine. We use the term "Business PKI" here 120 because an internet registry might already have a PKI for 121 authenticating its clients and might wish to reuse that PKI for this 122 protocol. There is, however, no requirement to reuse such a PKI. 124 2. Protocol Specification 126 The publication protocol uses XML messages wrapped in signed CMS 127 messages, carried over HTTP transport. 129 The publication protocol uses a simple request/response interaction. 130 The client passes a request to the server, and the server generates a 131 corresponding response. 133 A message exchange commences with the client initiating an HTTP POST 134 with content type of "application/rpki-publication", with the message 135 object as the body. The server's response will similarly be the body 136 of the response with a content type of "application/rpki- 137 publication". 139 The content of the POST and the server's response will be a well- 140 formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID = 141 1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492]. 143 2.1. Common XML Message Format 145 The XML schema for this protocol is below in Section 2.4. The basic 146 XML message format looks like this: 148 152 153 155 159 160 162 Common attributes: 164 version: The value of this attribute is the version of this 165 protocol. This document describes version 3. 167 type: The possible values of this attribute are "reply" and "query". 169 A query PDU may be one of two types: publish_query, or 170 withdraw_query. 172 A reply PDU may be one of three types: publish_reply, withdraw_reply, 173 or report_error_reply. 175 Each of these PDUs may include an optional tag to facilitate bulk 176 operation. If a tag is set in a query PDU, the corresponding 177 reply(s) MUST have the tag attribute set to the same value. 179 2.2. Publication and Withdrawal 181 The publication protocol uses a common message format to request 182 publication of any RPKI object. This format was chosen specifically 183 to allow this protocol to accommodate new types of RPKI objects 184 without needing changes to this protocol. 186 Both the and objects have a payload of an 187 optional tag and a URI. The query also contains the DER 188 object to be published, encoded in Base64. 190 Note that every publish and withdraw action requires a new manifest, 191 thus every publish or withdraw action will involve at least two 192 objects. 194 2.3. Error handling 196 Errors are handled at two levels. 198 Since all messages in this protocol are conveyed over HTTP 199 connections, basic errors are indicated via the HTTP response code. 200 4xx and 5xx responses indicate that something bad happened. Errors 201 that make it impossible to decode a query or encode a response are 202 handled in this way. 204 Where possible, errors will result in an XML message 205 which takes the place of the expected protocol response message. 206 messages are CMS-signed XML messages like the rest of 207 this protocol, and thus can be archived to provide an audit trail. 209 messages only appear in replies, never in queries. 210 The message can appear in both the control and 211 publication subprotocols. 213 Like all other messages in this protocol, the message 214 includes a "tag" attribute to assist in matching the error with a 215 particular query when using batching. It is optional to set the tag 216 on queries but, if set on the query, it MUST be set on the reply or 217 error. 219 The error itself is conveyed in the error_code attribute. The value 220 of this attribute is a token indicating the specific error that 221 occurred. 223 The body of the element itself is an optional text 224 string; if present, this is debugging information. 226 2.4. XML Schema 228 The following is a RelaxNG compact form schema describing the 229 Publication Protocol. 231 # $Id: rpki-publication.rnc 2698 2013-12-13 23:33:07Z sra $ 232 # RelaxNG schema for RPKI publication protocol. 234 default namespace = 235 "http://www.hactrn.net/uris/rpki/publication-spec/" 237 # This is version 3 of the protocol. 239 version = "3" 241 # Top level PDU is either a query or a reply. 243 start = element msg { 244 attribute version { version } , 245 ( ( attribute type { "query" }, query_elt* ) | 246 ( attribute type { "reply" }, reply_elt* ) ) 247 } 249 # PDUs allowed in queries and replies. 251 query_elt = publish_query | withdraw_query 252 reply_elt = publish_reply | withdraw_reply | report_error_reply 254 # Tag attributes for bulk operations. 256 tag = attribute tag { xsd:token { maxLength="1024" } } 258 # Base64 encoded DER stuff. 260 base64 = xsd:base64Binary 262 # Publication URIs. 264 uri = attribute uri { xsd:anyURI { maxLength="4096" } } 266 # Handles on remote objects (replaces passing raw SQL IDs). 268 object_handle = xsd:string { 269 maxLength = "255" 270 pattern="[\-_A-Za-z0-9/]*" 271 } 273 # Error codes. 275 error = xsd:token { maxLength="1024" } 277 # element 279 publish_query |= element publish { tag?, uri, base64 } 280 publish_reply |= element publish { tag?, uri } 282 # element 284 withdraw_query |= element withdraw { tag?, uri } 285 withdraw_reply |= element withdraw { tag?, uri } 286 # element 288 report_error_reply = element report_error { 289 tag?, 290 attribute error_code { error }, 291 xsd:string { maxLength="512000" }? 292 } 294 3. Examples 296 Following are examples of various queries and the corresponding 297 replies for the RPKI publication protocol 299 3.1. Query 300 304 306 MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhE 307 RjRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4 308 MDUyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIx 309 OEYwNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZI 310 hvcNAQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6F 311 r/9Xm/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3 312 F5qrKlZ4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQlu 313 ffiNDjzteCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSm 314 UDuZ1HDz1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/ 315 o8qFdC300VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mG 316 aA1jgAxlXWsCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I 317 8M3Ngo9/FzAfBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNV 318 HR8ETjBMMEqgSKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQv 319 UklSLzEvMzBxQUYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEF 320 BQcBAQQ5MDcwNQYIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAv 321 dGVzdGJlZC9XT01CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw 322 DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwEL 323 BIGOMIGLMDQGCCsGAQUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rl 324 c3RiZWQvUklSL1IwLzEvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9z 325 dDo0NDAwL3Rlc3RiZWQvUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56 326 WUtQZnhjLm1uZjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYB 327 BQUHAQcBAf8ELzAtMCsEAgABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMF 328 AsAAAiwDBQDAAAJkMA0GCSqGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv 329 306vmCuXhtu9Lr2mmRw2ZErB8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yATh 330 M81FPNRsU5mM0acIRnAPtxjHvPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFUR 331 azENztppsolHeTpm0cpLItK7mNpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel 332 /SM/UvOArCCOBvf0Gz7kSuupDSZ7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxd 333 x28qIj7ejZkRzNFw/3pi8/XK281h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx 334 0iwPYdLiDbdWFbtTdPcXBauY 335 336 338 3.2. Reply 340 344 346 348 3.3. Query 350 354 356 358 3.4. Reply 360 364 366 368 3.5. With Text 370 374 376 Shampooing with sterno again, are we? 377 378 380 3.6. Without Text 382 386 388 390 4. Operational Considerations 392 There are two basic options open to the repository operator as to how 393 the publication tree is laid out. The first option is simple: each 394 publication client is given its own directory one level below the top 395 of the rcynic module, and there is no overlap between the publication 396 spaces used by different clients. For example: 398 rsync://example.org/rpki/Alice/ 399 rsync://example.org/rpki/Bob/ 400 rsync://example.org/rpki/Carol/ 402 This has the advantage of being very easy for the publication 403 operator to manage, but has the drawback of making it difficult for 404 relying parties to fetch published objects both safely and as 405 efficiently as possible. 407 Given that the mandatory-to-implement retrieval protocol for relying 408 parties is rsync, a more efficient repository structure would be one 409 which minimized the number of rsync fetches required. One such 410 structure would be one in which the publication directories for 411 subjects were placed underneath the publication directories of their 412 issuers: since the normal synchronization tree walk is top-down, this 413 can significantly reduce the total number of rsync connections 414 required to synchronize. For example: 416 rsync://example.org/rpki/Alice/ 417 rsync://example.org/rpki/Alice/Bob/ 418 rsync://example.org/rpki/Alice/Bob/Carol/ 420 Preliminary measurement suggests that, in the case of large numbers 421 of small publication directories, the time needed to set up and tear 422 down individual rsync connections becomes significant, and that a 423 properly optimized tree structure can reduce synchronization time by 424 an order of magnitude. 426 The more complex tree structure does require careful attention to the 427 base_uri attribute values when setting up clients. In the example 428 above, assuming that Alice issues to Bob who in turn issues to Carol, 429 Alice has ceded control of a portion of her publication space to Bob, 430 who has in turn ceded a portion of that to Carol, and the base_uri 431 attributes in the setup messages should reflect this. 433 The details of how the repository operator determines that Alice has 434 given Bob permission to nest Bob's publication directory under 435 Alice's is outside the scope of this protocol. 437 5. IANA Considerations 439 IANA is asked to register the application/rpki-publication MIME media 440 type as follows: 442 MIME media type name: application 443 MIME subtype name: rpki-publication 444 Required parameters: None 445 Optional parameters: None 446 Encoding considerations: binary 447 Security considerations: Carries an RPKI Publication Protocol 448 Message, as defined in this document. 449 Interoperability considerations: None 450 Published specification: This document 451 Applications which use this media type: HTTP 452 Additional information: 453 Magic number(s): None 454 File extension(s): 455 Macintosh File Type Code(s): 456 Person & email address to contact for further information: 457 Rob Austein 458 Intended usage: COMMON 459 Author/Change controller: Rob Austein 461 6. Security Considerations 463 The RPKI publication protocol and the data it publishes use entirely 464 separate PKIs for authentication. The published data is 465 authenticated within the RPKI, and this protocol has nothing to do 466 with that authentication, nor does it require that the published 467 objects be valid in the RPKI. The publication protocol uses a 468 separate Business PKI (BPKI) to authenticate its messages. 470 Each of the RPKI publication protocol messages is CMS-signed. 471 Because of that protection at the application layer, this protocol 472 does not require the use of HTTPS or other transport security 473 mechanisms. 475 Compromise of a publication server, perhaps through mismanagement of 476 BPKI keys, could lead to a denial-of-service attack on the RPKI. An 477 attacker gaining access to BPKI keys could use this protocol delete 478 (withdraw) RPKI objects, leading to routing changes or failures. 479 Accordingly, as in most PKIs, good key management practices are 480 important. 482 7. References 484 7.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", RFC 2119, BCP 14, March 1997. 489 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 490 5652, STD 70, September 2009. 492 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 493 Protocol for Provisioning Resource Certificates", RFC 494 6492, February 2012. 496 7.2. Informative References 498 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 499 Secure Internet Routing", RFC 6480, February 2012. 501 Authors' Addresses 503 Samuel Weiler 504 SPARTA, Inc. 505 7110 Samuel Morse Drive 506 Columbia, Maryland 21046 507 US 509 Email: weiler@tislabs.com 511 Anuja Sonalker 512 Battelle Memorial Institute 514 Email: sonalkera@battelle.org 516 Rob Austein 517 Dragon Research Labs 519 Email: sra@hactrn.net