idnits 2.17.1 draft-ietf-sidr-rpki-oob-setup-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 -- The document date (February 22, 2017) is 2613 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) == Outdated reference: A later version (-08) exists of draft-ietf-sidr-delta-protocol-07 == Outdated reference: A later version (-12) exists of draft-ietf-sidr-publication-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'RelaxNG' ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 Internet-Draft Dragon Research Labs 4 Intended status: Standards Track February 22, 2017 5 Expires: August 26, 2017 7 An Out-Of-Band Setup Protocol For RPKI Production Services 8 draft-ietf-sidr-rpki-oob-setup-09 10 Abstract 12 This note describes a simple out-of-band protocol to ease setup of 13 the RPKI provisioning and publication protocols between two parties. 14 The protocol is encoded in a small number of XML messages, which can 15 be passed back and forth by any mutually agreeable means which 16 provides acceptable data integrity and authentication. 18 This setup protocol is not part of the provisioning or publication 19 protocol, rather, it is intended to simplify configuration of these 20 protocols by setting up relationships and exchanging keying material 21 used to authenticate those relationships. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 26, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 3 60 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Common Protocol Elements . . . . . . . . . . . . . . . . 6 63 5.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6 64 5.2.1. . . . . . . . . . . . . . . . . . . 7 65 5.2.2. . . . . . . . . . . . . . . . . . 7 66 5.2.3. . . . . . . . . . . . . . . . . 9 67 5.2.4. . . . . . . . . . . . . . . . 11 68 5.3. . . . . . . . . . . . . . . . . . . . . 12 69 5.4. . . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 76 10.2. Informative References . . . . . . . . . . . . . . . . . 20 77 Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 20 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 This note describes a small XML-based out-of-band protocol used to 83 set up relationships between parents and children in the RPKI 84 provisioning protocol ([RFC6492]) and between publishers and 85 repositories in the RPKI publication protocol 86 ([I-D.ietf-sidr-publication]). 88 The basic function of this protocol is public key exchange, in the 89 form of self-signed X.509 certificates, but workshop experience has 90 demonstrated that it's simpler for the user if we also bundle the 91 other configuration information needed to bring up a new player into 92 the messages used in the key exchange. 94 The underlying transport for this protocol is deliberately 95 unspecified. It might be a USB stick, a web interface secured with 96 conventional HTTPS, PGP-signed email, a T-shirt printed with a QR 97 code, or a carrier pigeon. 99 Since much of the purpose of this protocol is key exchange, 100 authentication and integrity of the key exchange MUST be ensured via 101 external means. Typically such means will tie directly to a new or 102 existing business relationship 104 2. History 106 The protocol described in this document grew out of a series of 107 workshops held starting in 2010, at which it became clear that manual 108 configuration of keying material and service URLs was both error 109 prone and unnecessarily confusing. The basic mechanism and semantics 110 have been essentially unchanged since the earliest versions of the 111 protocol, but there were several workshop-driven syntax changes and 112 simplifications before the protocol made its way into the IETF, and a 113 few more simplifications and minor extensions have occurred since 114 that time. 116 3. Overview of the BPKI 118 Several protocols related to RPKI provisioning use signed CMS 119 messages ([RFC5652]) to authenticate the underlying XML-based 120 protocols. Verification of these CMS messages requires X.509 121 certificates. The PKI that holds these certificates is distinct from 122 the RPKI, and contains no RFC 3779 resources. We refer to this as 123 the "Business PKI" (BPKI), to distinguish it from the RPKI. The "B" 124 is a hint that the certificate relationships in the BPKI are likely 125 to follow and become part of existing contractual relationships 126 between the issuers and subjects of this PKI. 128 The RPKI provisioning protocol does not dictate a particular 129 structure for the BPKI, beyond the basic requirement that it be 130 possible for one party to sign and the other party to verify the CMS 131 messages. This allows a certain amount of flexibility to allow an 132 Internet registry to reuse an existing PKI as the BPKI if that makes 133 sense in their context. 135 In order to keep this protocol simple, we adopt a somewhat 136 constrained model of the BPKI. The first two operations in this 137 protocol are an exchange of public keys between child and parent for 138 use in the provisioning protocol, the latter two operations in this 139 protocol are an exchange of public keys between publisher and 140 repository for use in the publication protocol. In each of these 141 operations, the sending party includes its public key, in the form of 142 a self-signed X.509 CA certificate. The private keys corresponding 143 to the exchanged certificates are not used to sign CMS messages 144 directly; instead, the exchanged CA certificates are the issuers of 145 the BPKI end-entity (EE) certificates which will be included in the 146 CMS messages and can be used, along with the exchanged certificates, 147 to verify the CMS messages. 149 Details of how to tie the exchanged certificates into an 150 implementation's local BPKI are left to the implementation, but the 151 recommended approach is to cross-certify the received public key and 152 subject name under one's own BPKI, using a Basic Constraints 153 extension with cA = TRUE, pathLenConstraint = 0, indicating that the 154 cross-certified certificate is a CA certificate which is allowed to 155 issue EE certificates but is not allowed to issue CA certificates. 156 See section 4.2.1.9 of [RFC5280] for more information about the Basic 157 Constraints extension. 159 For example, suppose that Alice and Bob each have their own self- 160 signed BPKI certificates: 162 Issuer: CN = Alice CA 163 Subject: CN = Alice CA 164 Public Key: [Alice CA Public Key] 165 BasicConstraints: cA = TRUE 167 Issuer: CN = Bob CA 168 Subject: CN = Bob CA 169 Public Key: [Bob CA Public Key] 170 BasicConstraints: cA = TRUE 172 Alice sends Bob her self-signed BPKI certificate, and Bob cross- 173 certifies its public key and subject name under Bob's own self-signed 174 BPKI certificate: 176 Issuer: CN = Bob CA 177 Subject: CN = Alice CA 178 Public Key: [Alice CA Public Key] 179 BasicConstraints: cA = TRUE, pathLenConstraint = 0 181 Later, when Bob receives a CMS message from Alice, Bob can verify 182 this message via a trust chain back to Bob's own trust anchor: 184 Issuer: CN = Alice CA 185 Subject: CN = Alice EE 186 Public Key: [Alice EE Public Key] 188 A complete description of the certificates allowed here is beyond the 189 scope of this document, as it is determined primarily by what is 190 acceptable to the several other protocols for which this protocol is 191 handling setup. Furthermore, we expect the requirements to change 192 over time to track changes in cryptographic algorithms, required key 193 length, and so forth. Finally, since this protocol is restricted to 194 setting up pairwise relationships, all that's really required is that 195 the two parties involved in a particular conversation agree on what 196 constitutes an acceptable certificate. 198 All of that said, in practice, the certificates currently exchanged 199 by this protocol at the time this document was written are what a 200 reader familiar with the technology would probably expect: RSA keys 201 with lengths in the 2048-4096 bit range, SHA-2 digests, and a few 202 common X.509v3 extensions (principally Basic Constraints, Authority 203 Key Identifier, and Subject Key Identifier). Since the most likely 204 usage is a cross-certification operation in which the recipient 205 simply extracts the Subject Name and public key after checking the 206 self-signature and discards the rest of the incoming certificate, the 207 practical value of esoteric X.509v3 extensions is somewhat limited. 209 4. Terminology 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 All of the protocols configured by this setup protocol have their own 216 terminology for their actors, but in the context of this protocol 217 that terminology becomes somewhat confusing. All of the players in 218 this setup protocol issue certificates, are the subjects of other 219 certificates, operate servers, and, in most cases, act as clients for 220 one protocol or another. Therefore, this note uses its own terms for 221 the actors in this protocol. 223 Child: An entity acting in the client ("subject") role of the 224 provisioning protocol defined in [RFC6492]. 226 Parent: An entity acting in the server ("issuer") role of the 227 provisioning protocol defined in [RFC6492]. 229 Publisher: An entity acting in the client role of the publication 230 protocol defined in [I-D.ietf-sidr-publication]. 232 Repository: An entity acting in the server role of the publication 233 protocol defined in [I-D.ietf-sidr-publication]. 235 Note that a given entity might act in more than one of these roles; 236 for example, in one of the simplest cases, the child is the same 237 entity as the publisher, while the parent is the same entity as the 238 repository. 240 5. Protocol Elements 242 Each message in the protocol is a distinct XML element in the 243 "http://www.hactrn.net/uris/rpki/rpki-setup/" XML namespace. 245 The outermost XML element of each message contains a version 246 attribute. This document describes version 1 of the protocol. 248 Appendix A is a [RelaxNG] schema for this protocol. The schema is 249 normative: in the event of a disagreement between the schema and the 250 following textual description, the schema is authoritative. 252 Since "1" is currently the only value allowed for the version 253 attribute in the schema, an incorrect protocol version can be 254 detected either by checking the version attribute directly or as a 255 schema validation error. 257 5.1. Common Protocol Elements 259 Most messages contain, among other things, a self-signed BPKI X.509 260 certificate. These certificates are represented as XML elements 261 whose text value is the Base64 text ([RFC4648] section 4, with line 262 breaks within the Base64 text permitted but not required) encoding 263 the DER representation of the X.509 certificate. 265 A number of attributes contain "handles". A handle in this protocol 266 is a text string in the US-ASCII character set consisting of letters, 267 digits, and the special characters "/", "-", and "_". This protocol 268 places no special semantics on the structure of these handles, 269 although implementations might. Handles are protocol elements, not 270 necessarily meaningful to humans, thus the simplicity of a restricted 271 character set makes more sense than the complex rules which would be 272 needed for internationalized text. 274 Most messages allow an optional "tag" attribute. This is an opaque 275 cookie supplied by the client in a particular exchange and echoed by 276 the server; the intent is to simplify the process of matching a 277 response received by the client with an outstanding request. 279 5.2. Protocol Messages 281 The core of this protocol consists of four message types, 282 representing the basic request and response semantics needed to 283 configure a RPKI engine to talk to its parent and its repository via 284 the provisioning and publication protocols, respectively. 286 5.2.1. 288 The message is an initial setup request from a 289 provisioning protocol child to its provisioning protocol parent. 291 Fields in the message: 293 version: The version attribute specifies the protocol version. This 294 note describes protocol version 1. 296 tag: The child MAY include a "tag" attribute in the request message. 298 child_handle: The child_handle attribute is what the child calls 299 itself. This is just a hint from the child to the parent, the 300 parent need not honor it. 302 child_bpki_ta: The element is the child's BPKI 303 identity, a self-signed X.509 BPKI certificate, encoded in Base64. 305 This CA certificate will be the issuer of the BPKI EE certificates 306 corresponding to private keys that the child will use when sending 307 provisioning protocol messages to the parent. 309 --------------------------------------------------------------------- 310 314 315 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 316 317 318 --------------------------------------------------------------------- 320 5.2.2. 322 The message is a response from a provisioning 323 protocol parent to a provisioning protocol child that had previously 324 sent a message. 326 Fields in the message: 328 version: The version attribute specifies the protocol version. This 329 note describes protocol version 1. 331 tag: If the message included a "tag" attribute, the 332 parent MUST include an identical "tag" attribute in the 333 message; if the request did not include a tag 334 attribute, the response MUST NOT include a tag attribute either. 336 service_uri: The service_uri attribute contains an HTTP or HTTPS URL 337 ([RFC7230]) that the child should contact for up-down ([RFC6492]) 338 service. 340 child_handle: The child_handle attribute is the parent's name for 341 the child. This MAY match the child_handle from the 342 message. If they do not match, the parent wins, 343 because the parent gets to dictate the names in the provisioning 344 protocol. This value is the sender field in provisioning protocol 345 request messages and the recipient field in provisioning protocol 346 response messages. 348 parent_handle: The parent_handle attribute is the parent's name for 349 itself. This value is the recipient field in provisioning 350 protocol request messages and the sender field in provisioning 351 protocol response messages. 353 parent_bpki_ta: The element is the parent's BPKI 354 identity, a self-signed X.509 BPKI certificate. 356 This certificate is the issuer of the BPKI EE certificates 357 corresponding to private keys that the parent will use to sign 358 provisioning protocol messages to the child. 360 offer: If an element is present, the parent is offering 361 publication service to the child. The element, if 362 present, is empty. 364 referral: If elements are present, they suggest third- 365 party publication services which the child might use, and contain: 367 referrer: A referrer attribute, containing the handle by which 368 the publication repository knows the parent, 370 contact_uri: An optional contact_uri attribute that the child may 371 be able to follow for more information, and 373 Authorization token: The text of the element is the 374 Base64 encoding of a signed authorization token granting the 375 child the right to use a portion of the parent's namespace at 376 the publication repository in question. See Section 5.3 for 377 details on the authorization token. 379 A parent is unlikely to need to send both and 380 elements, but strictly speaking they are not mutually exclusive, so a 381 parent which really needs to express that it both offers repository 382 service to its child and is also willing to refer its child to one or 383 more other repository servers can do so. 385 --------------------------------------------------------------------- 386 392 393 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 394 395 396 397 --------------------------------------------------------------------- 399 --------------------------------------------------------------------- 400 406 407 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 408 409 411 R28sIGxlbW1pbmdzLCBnbyE= 412 413 414 --------------------------------------------------------------------- 416 5.2.3. 418 The message is a setup request from a publisher 419 to a repository. Generally this will not take place until after the 420 publisher has set up the provisioning protocol via a 421 / exchange: in particular, the sub- 422 element here requires an token provided by the 423 provisioning protocol exchange. 425 Fields in the message: 427 version: The version attribute specifies the protocol version. This 428 note describes protocol version 1. 430 tag: The publisher MAY include a "tag" attribute in the request 431 message. 433 publisher_handle: The publisher_handle attribute is the publisher's 434 name for itself. This is just a hint, the repository need not 435 honor it. 437 publisher_bpki_ta: The element is the 438 publisher's BPKI identity, a self-signed X.509 BPKI certificate. 439 This certificate is the issuer of the BPKI EE certificates 440 corresponding to private keys that the publisher will use to sign 441 publication protocol messages to the repository. 443 referral: If a element is present, it contains: 445 referrer: A referrer attribute containing the publication handle 446 of the referring parent, and 448 Authorization token: The text of the element is the 449 Base64 encoding of a signed authorization token granting the 450 publisher the right to use a portion of its parent's namespace 451 at this repository. See Section 5.3 for details on the 452 authorization token. 454 These fields are copies of values that a parent provided to the 455 child in the message (see Section 5.2.2). The 456 referrer attribute is present to aid lookup of the corresponding 457 certificate by the repository. Note that the repository operator 458 makes the final decision on whether to grant publication service 459 to the prospective publisher. The element just 460 conveys a parent's grant of permission to use a portion of that 461 parent's namespace. 463 --------------------------------------------------------------------- 464 469 470 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 471 472 473 --------------------------------------------------------------------- 475 5.2.4. 477 The message is a repository's response to a 478 publisher which has previously sent a message. 480 Fields in the message: 482 version: The version attribute specifies the protocol version. This 483 note describes protocol version 1. 485 tag: If the message included a "tag" attribute, 486 the repository MUST include an identical "tag" attribute in the 487 message; if the request did not include a 488 tag attribute, the response MUST NOT include a tag attribute 489 either. 491 service_uri: The service_uri attribute contains an HTTP or HTTPS URL 492 ([RFC7230]) that the publisher should contact for publication 493 service ([I-D.ietf-sidr-publication]). 495 publisher_handle: The publisher_handle attribute is the repository's 496 name for the publisher. This may or may not match the 497 publisher_handle attribute in the publisher's 498 message. 500 sia_base: The sia_base attribute is the rsync:// URI for the base of 501 the publication space allocated to the publisher. 503 rrdp_notification_uri: The optional rrdp_notification_uri attribute 504 is the URI for the RRDP notification file covering the publication 505 space allocated to the publisher ([I-D.ietf-sidr-delta-protocol]). 507 repository_bpki_ta: The element is the 508 repository's BPKI identity, a self-signed X.509 BPKI certificate. 510 --------------------------------------------------------------------- 511 519 520 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 521 522 523 --------------------------------------------------------------------- 525 5.3. 527 The element is a separate message which is signed 528 with CMS, then included as the Base64 content of elements 529 in other messages. 531 The eContentType for the signed CMS message is id-ct-xml ([RFC6492]). 533 Fields in the element: 535 version: The version attribute specifies the protocol version. This 536 note describes protocol version 1. 538 authorized_sia_base: The value of the authorized_sia_base attribute 539 is the rsync:// URI of the base of the namespace which the 540 referrer is delegating. 542 BPKI TA: The text of the element is the identity of 543 the entity to whom the referrer is delegating the portion of the 544 namespace named in the authorized_sia_base attribute, represented 545 as a Base64-encoded self-signed X.509 BPKI certificate. 547 --------------------------------------------------------------------- 548 552 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 553 554 --------------------------------------------------------------------- 556 5.4. 558 The element is an optional message which can be used in 559 response to any of the core protocol messages described in 560 Section 5.2. 562 Whether an element is an appropriate way to signal errors 563 back to the sender of a protocol message depends on details of the 564 implementation which are outside this specification. For example, if 565 this protocol is embedded in a web portal interface which is designed 566 to let a human being upload and download these messages via upload 567 and download forms, a human-readable error message may be more 568 appropriate. On the other hand, a portal intended to be driven by a 569 robotic client might well want to use an message to signal 570 errors. Similar arguments apply to non-web encapsulations (email, 571 USB stick, ...); the primary factor is likely to be whether the 572 implementation expects the error to be handled by a human being or by 573 a program. 575 Fields in the message: 577 version: The version attribute specifies the protocol version. This 578 note describes protocol version 1. 580 reason: The reason attribute contains a code indicating what was 581 wrong with the message. This version of the protocol defines the 582 following codes: 584 syntax-error: Receiver could not parse the offending message. 586 authentication-failure: Receiver could not authenticate the 587 offending message. 589 refused: Receiver refused to perform the requested action. 591 Offending message: The element contains a verbatim copy of 592 the message to which this error applies. 594 --------------------------------------------------------------------- 595 599 603 604 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 605 606 607 608 --------------------------------------------------------------------- 610 6. Protocol Walk-Through 612 This section walks through a few simple examples of the protocol in 613 use, and stars our old friends, Alice, Bob, and Carol. In this 614 example, Alice is the root of a RPKI tree, Bob wants to get address 615 and ASN resources from Alice, and Carol wants to get some of those 616 resources in turn from Bob. Alice offers publication service, which 617 is used by all three. 619 Alice, Bob, and Carol each generate his or her own self-signed BPKI 620 certificate. 622 Bob constructs a message and sends it to Alice: 624 --------------------------------------------------------------------- 625 629 630 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 631 632 633 --------------------------------------------------------------------- 635 o Bob's preferred handle is "Bob", so Bob uses that when setting 636 child_handle. 638 o is Bob's self-signed BPKI certificate. 640 Alice replies with a message, but Alice already 641 has 41 other children named Bob, so she calls this one "Bob-42". 643 Alice's provisioning protocol server happens to use a RESTful URL 644 scheme so that it can find the expected validation context for the 645 provisioning protocol CMS message just by looking at the URL, so the 646 service URL she provides to Bob includes both her name and Bob's. 647 Alice offers publication service, so she offers to let Bob use it; 648 Alice doesn't have to do this, she could just omit this and leave Bob 649 to find publication service on his own, but Alice is trying to be 650 helpful to her customer Bob. Bob doesn't have to accept Alice's 651 offer, but may choose to do so. 653 --------------------------------------------------------------------- 654 660 661 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 662 663 664 665 --------------------------------------------------------------------- 667 o is Alice's own self-signed BPKI certificate. 669 Bob receives Alice's and extracts the fields Bob's 670 RPKI engine will need to know about (child_handle, parent_handle, 671 service_uri, and ). Bob also sees the repository 672 offer, decides to take Alice up on this offer, and constructs a 673 message accordingly: 675 --------------------------------------------------------------------- 676 681 682 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 683 684 685 --------------------------------------------------------------------- 687 Alice receives Bob's request to use Alice's publication service, 688 decides to honor the offer she made, and sends back a 689 message in response. Alice recognizes Bob as 690 one of her own children, because she's already seen Bob's self-signed 691 BPKI certificate, so she allocates publication space to Bob under her 692 own publication space, so that relying parties who rsync her products 693 will pick up Bob's products automatically without needing an 694 additional fetch operation. 696 --------------------------------------------------------------------- 697 705 706 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 707 708 709 --------------------------------------------------------------------- 711 Bob should now have everything he needs to talk to Alice both for 712 provisioning and for publication. 714 A more interesting case is Bob's child, Carol. Carol wants to get 715 her resources from Bob, and, like Bob, does not particularly want to 716 operate a publication service. Bob doesn't have a publication 717 service of his own to offer, but he can refer Carol to Alice, along 718 with his permission for Carol to use a portion of the namespace that 719 Alice gave him. 721 Carol's to Bob looks very similar to Bob's earlier 722 request to Alice: 724 --------------------------------------------------------------------- 725 729 730 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 731 732 733 --------------------------------------------------------------------- 735 Bob's to Carol also looks a lot like Alice's 736 response to Bob, except that Bob includes a element 737 instead of an element. Carol is an only child, so Bob 738 leaves her name alone: 740 --------------------------------------------------------------------- 741 747 748 R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI= 749 750 752 R28sIGxlbW1pbmdzLCBnbyE= 753 754 755 --------------------------------------------------------------------- 757 Bob's response includes a element with a referrer 758 attribute of "Alice/Bob-42", since that's Bob's name to Alice's 759 repository. The Base64-encoded authorization token is an 760 element in a CMS message that can be verified 761 against Bob's self-signed BPKI certificate, using a BPKI EE 762 certificate included in the CMS wrapper. The text 763 is Carol's self-signed BPKI certificate; Bob's signature over this 764 element indicates Bob's permission for Carol to use the indicated 765 portion of Bob's publication space. 767 --------------------------------------------------------------------- 768 772 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 773 774 --------------------------------------------------------------------- 776 Carol, not wanting to have to run a publication service, presents 777 Bob's referral to Alice in the hope that Alice will let Carol use 778 Alice's publication service. So Carol constructs a 779 message including the referral information 780 received from Bob, and sends it all to Alice: 782 --------------------------------------------------------------------- 783 788 789 SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu 790 791 793 R28sIGxlbW1pbmdzLCBnbyE= 794 795 796 --------------------------------------------------------------------- 798 Alice sees the signed authorization token Bob gave to Carol, checks 799 its signature, and unpacks it. When the signature proves valid and 800 the contained BPKI TA matches Carol's, Alice knows that Bob is 801 willing to let Carol use a portion of Bob's namespace. Given this, 802 Alice is willing to provide publication service to Carol in the 803 subtree allocated by Bob for this purpose, so Alice sends back a 804 : 806 --------------------------------------------------------------------- 807 814 815 WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU 816 817 818 --------------------------------------------------------------------- 820 Once Carol receives this response, Carol should be good to go. 822 In theory the publication referral mechanism can extend indefinitely 823 (for example, Carol can refer her child Dave to Alice for publication 824 service and it should all work). In practice, this has not yet been 825 implemented, much less tested. In order to keep the protocol 826 relatively simple, we've deliberately ignored perverse cases such as 827 Bob being willing to refer Carol to Alice but not wanting Carol to be 828 allowed to refer Dave to Alice. 830 Any RPKI operator is free to run their own publication service should 831 they feel a need to do so, and a child need not accept any particular 832 or . In general, having a smaller number of 833 larger publication repositories is probably good for overall system 834 performance, because it will tend to reduce the number of distinct 835 repositories from which each relying party will need to fetch, but 836 the decision on where to publish is up to individual RPKI CA 837 operators and out of scope for this protocol. 839 7. IANA Considerations 841 This document makes no request of IANA. 843 8. Security Considerations 845 As stated in Section 1, the basic function of this protocol is an 846 exchange of public keys to be used as BPKI trust anchors. Integrity 847 and authentication of these exchanges MUST be ensured via external 848 mechanisms deliberately left unspecified in this protocol. 850 9. Acknowledgements 852 The author would like to thank: Byron Ellacott, George Michaelson, 853 Leif Johansson, Matsuzaki Yoshinobu, Michael Elkins, Randy Bush, 854 Seiichi Kawamura, Tim Bruijnzeels, and anybody else who helped along 855 the way but whose name the author has temporarily forgotten. 857 10. References 859 10.1. Normative References 861 [I-D.ietf-sidr-delta-protocol] 862 Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 863 "RPKI Repository Delta Protocol", draft-ietf-sidr-delta- 864 protocol-07 (work in progress), February 2017. 866 [I-D.ietf-sidr-publication] 867 Weiler, S., Sonalker, A., and R. Austein, "A Publication 868 Protocol for the Resource Public Key Infrastructure 869 (RPKI)", draft-ietf-sidr-publication-11 (work in 870 progress), February 2017. 872 [RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November 873 2002, . 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", RFC 2119, BCP 14, March 1997. 879 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 880 Encodings", RFC 4648, October 2006. 882 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A 883 Protocol for Provisioning Resource Certificates", 884 RFC 6492, February 2012. 886 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 887 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 888 2014. 890 10.2. Informative References 892 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 893 Housley, R., and W. Polk, "Internet X.509 Public Key 894 Infrastructure Certificate and Certificate Revocation List 895 (CRL) Profile", RFC 5280, May 2008. 897 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 898 RFC 5652, STD 70, September 2009. 900 Appendix A. RelaxNG Schema 902 Here is a [RelaxNG] schema describing the protocol elements. 904 This schema is normative: in the event of a disagreement between this 905 schema and the document text above, this schema is authoritative. 907 default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/" 909 version = "1" 911 base64 = xsd:base64Binary { maxLength="512000" } 912 handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" } 913 uri = xsd:anyURI { maxLength="4096" } 914 any = element * { attribute * { text }*, ( any | text )* } 915 tag = xsd:token { maxLength="1024" } 917 authorization_token = base64 918 bpki_ta = base64 920 start |= element child_request { 921 attribute version { version }, 922 attribute child_handle { handle }, 923 attribute tag { tag }?, 924 element child_bpki_ta { bpki_ta } 925 } 926 start |= element parent_response { 927 attribute version { version }, 928 attribute service_uri { uri }, 929 attribute child_handle { handle }, 930 attribute parent_handle { handle }, 931 attribute tag { tag }?, 932 element parent_bpki_ta { bpki_ta }, 933 element offer { empty }?, 934 element referral { 935 attribute referrer { handle }, 936 attribute contact_uri { uri }?, 937 authorization_token 938 }* 939 } 941 start |= element publisher_request { 942 attribute version { version }, 943 attribute publisher_handle { handle }, 944 attribute tag { tag }?, 945 element publisher_bpki_ta { bpki_ta }, 946 element referral { 947 attribute referrer { handle }, 948 authorization_token 949 }* 950 } 952 start |= element repository_response { 953 attribute version { version }, 954 attribute service_uri { uri }, 955 attribute publisher_handle { handle }, 956 attribute sia_base { uri }, 957 attribute rrdp_notification_uri { uri }?, 958 attribute tag { tag }?, 959 element repository_bpki_ta { bpki_ta } 960 } 962 start |= element authorization { 963 attribute version { version }, 964 attribute authorized_sia_base { uri }, 965 bpki_ta 966 } 968 start |= element error { 969 attribute version { version }, 970 attribute reason { 971 "syntax-error" | 972 "authentication-failure" | 973 "refused" 975 }, 976 any? 977 } 979 Author's Address 981 Rob Austein 982 Dragon Research Labs 984 Email: sra@hactrn.net