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