idnits 2.17.1
draft-barnes-sidr-tao-00.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 13, 2014) is 3725 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)
-- Looks like a reference, but probably isn't: '0' on line 439
-- Looks like a reference, but probably isn't: '1' on line 440
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Secure Inter-Domain Routing E. Barnes
3 Internet-Draft BBN Technologies
4 Intended status: Standards Track February 13, 2014
5 Expires: August 17, 2014
7 Resource Public Key Infrastructure (RPKI) Resource Transfer Protocol and
8 Transfer Authorization Object (TAO)
9 draft-barnes-sidr-tao-00
11 Abstract
13 This document defines an extension to the rpki-updown protocol to
14 provide support for transferring Internet Number Resources from one
15 INR holder to another. Such transfers take place external to the
16 RPKI, using procedures defined within and between RIRs. This
17 protocol facilitates automation of the maintenance of RPKI data in
18 the context of INR transfers. The protocol supports asynchronous
19 transfers of live or unused INRs within an RIR or between RIRs. The
20 scope of this protocol is limited to the transfer of Internet Number
21 Resources within the Resource Public Key Infrastructure. In support
22 of this protocol, this document also defines a new signed object type
23 for the RPKI repository system, the Transfer Authorization Object
24 (TAO).
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on August 17, 2014.
43 Copyright Notice
45 Copyright (c) 2014 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 3. Protocol Specifications . . . . . . . . . . . . . . . . . . . 4
64 3.1. INR Source Path . . . . . . . . . . . . . . . . . . . . . 5
65 3.2. INR Recipient Path . . . . . . . . . . . . . . . . . . . 7
66 3.3. Swing Point . . . . . . . . . . . . . . . . . . . . . . . 8
67 3.4. Transfer Authorization Object . . . . . . . . . . . . . . 9
68 3.4.1. TAO Type . . . . . . . . . . . . . . . . . . . . . . 9
69 3.4.2. TAO Validation . . . . . . . . . . . . . . . . . . . 9
70 3.5. ASN.1 Specification of the TAO . . . . . . . . . . . . . 10
71 3.5.1. transferFromSKI . . . . . . . . . . . . . . . . . . . 10
72 3.5.2. transferToSKI . . . . . . . . . . . . . . . . . . . . 10
73 3.5.3. ipAddrBlocks . . . . . . . . . . . . . . . . . . . . 10
74 3.5.4. asIdentifiers . . . . . . . . . . . . . . . . . . . . 10
75 3.5.5. liveXfer . . . . . . . . . . . . . . . . . . . . . . 10
76 3.5.6. overlapPeriod . . . . . . . . . . . . . . . . . . . . 11
77 3.6. Common Message Format . . . . . . . . . . . . . . . . . . 11
78 3.7. End Entity Certificate Constraint . . . . . . . . . . . . 11
79 3.8. INR Transfer . . . . . . . . . . . . . . . . . . . . . . 11
80 3.8.1. Transfer . . . . . . . . . . . . . . . . . . . . . . 11
81 3.8.2. Request-Not-Performed Response . . . . . . . . . . . 13
82 3.8.3. Timeout Response . . . . . . . . . . . . . . . . . . 13
83 3.8.4. Overlap Failure Response . . . . . . . . . . . . . . 13
84 3.9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13
85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
89 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
90 7.2. Informative References . . . . . . . . . . . . . . . . . 17
92 1. Introduction
94 This document defines an extension to the rpki-updown protocol,
95 defined in [RFC6492], to provide support for transferring Internet
96 Number Resources from one INR holder to another. The protocol
97 supports asynchronous transfers of live or unused INRs. The scope of
98 the protocol is limited to the transfer of Internet Number Resource
99 within the Resource Public Key Infrastructure, defined in [RFC6480].
100 In support of this protocol, this document also defines a new signed
101 object type, the Transfer Authorization Object (TAO), which makes use
102 of the signed object format defined in [RFC6488].
104 Many of the messages in this protocol are identical to those in
105 [RFC6488], and the result of the protocol, updated certificates
106 published in the RPKI repository system [RFC6481], is the same for
107 both protocols. To initiate a transfer, an INR holder, or source,
108 creates a TAO and publishes it in its publication point. The TAO is
109 a declaration of the proposed transfer, signed by the transfer
110 source. The source communicates the location of the TAO to the INR
111 recipient. Both entities then pursue the transfer independently,
112 recursively requesting the transfer from their parents until the
113 lowest common ancestor, the swing point is reached. The swing point
114 acts as the ultimate arbiter of the transfer, although any
115 Certification Authority (CA) involved in the transfer is able to deny
116 the transfer. The protocol assumes that the source of the transfer,
117 and the recipient have gained preliminary approval for the transfer,
118 out-of-band (OOB), prior to publishing the TAO and initiating the
119 protocol.
121 1.1. Terminology
123 Terms used in this document are:
125 "Internet Number Resource" (or "resource" or "INR") used in the
126 context of this document to refer to Autonomous System (AS)
127 numbers and IP version 4 or IP version 6 addresses.
129 "swing point" the lowest common ancestor (Certification Authority)
130 of both the INR source and the INR recipient in the RPKI
131 hierarchy. It is assumed that the swing point is neither the
132 source nor the recipient.
134 "source" (or "INR source") the INR holder that initiates the
135 transfer
137 "recipient" (or "INR recipient") the INR holder that is the
138 destination of the transfer
140 "live" a live INR is a resource that is currently in use
142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
144 document are to be interpreted as described in BCP 14, [RFC2119].
146 2. Scope
148 This Resource Public Key Infrastructure (RPKI) INR transfer protocol
149 defines a basic set of interactions that allows:
151 o an INR holder to initiate the transfer of Internet Number
152 Resources,
154 o the INR source and INR recipient to pursue the transfer
155 asynchronously,
157 o and each Certification Authority (CA) along the path between the
158 source and recipient (including the swing point) to validate and
159 approve, or deny, any such transfer.
161 The resource allocation database and INR transfer policies of each CA
162 along the path are authoritative when determining whether the
163 resources in question may be transferred.
165 This protocol specification does not encompass:
167 o the specification of interactions with the each CA's resource
168 allocation database, nor the specification of a protocol to manage
169 the publication repository.
171 o transfers where the source or recipient is also the swing point.
172 Both situations are already handled by rpki-updown as explained in
173 Section 3.3.
175 3. Protocol Specifications
177 The INR source MUST initiate the transfer by creating and publishing
178 the Transfer Authorization Object (TAO, see Section 3.4) at its
179 publication point [RFC6481]. The URL of the TAO SHOULD be
180 communicated to the transfer recipient, e.g., via email. Once the
181 TAO is published, and the recipient has received the URL of the TAO,
182 two separate processes begin: the first from the INR source to the
183 swing point, the second from the transfer recipient to the swing
184 point. These two processes proceed independently and recursively.
185 The following steps occur between each parent and child along the
186 specified paths in the hierarchy.
188 In both cases, when a CA receives an updated certificate from its
189 immediate parent, it MUST promptly update the certificate for the
190 child involved in the transfer. This certificate is published in its
191 publication point and sent to the child using a transfer_response
192 message (Section 3.8.1.2. If this CA is the INR source or INR
193 recipient, no updates are necessary since receipt of the updated
194 certificate indicates that the parent has updated the end point of
195 the transfer. Similarly, when a CA receives an error message from a
196 parent, the CA MUST forward the message code to its immediate child
197 along the path towards the INR source or INR recipient.
199 Both the INR source and the INR recipient MUST NOT rekey during a
200 transfer; their SKIs are captured in the TAO and the validity of the
201 TAO requires the SKIs not change during the process. A new key would
202 invalidate the TAO and require restarting the transfer process. To
203 avoid this problem, the source SHOULD NOT initiate a transfer that is
204 expected to take longer than the notAfter date in its, or the
205 recipient's, CA certificate. The source should contact (OOB) the
206 CA's along the path to receive an estimate of the time required to
207 complete a transfer, to aid in making this determination.
209 The process described below is used for transferring either live or
210 unused INRs. The process is identical for both types of transfers
211 except where otherwise specified.
213 3.1. INR Source Path
215 The source MUST NOT request a transfer of any INRs that are delegated
216 to one of the source's children (i.e., appear in a CA certificate
217 issued by the source). This requirement avoids one way that a TAO
218 that is valid at the beginning of a transfer could become invalid
219 before the end of the transfer. In particular, in the instance where
220 the source of this transfer is the swing point in another transfer,
221 this prevents the swing point from transferring INRs to a different
222 recipient than specified in the first transfer.
224 Along the path from the INR source to the swing point, with the INR
225 source as the initial "child", the following messages MUST be
226 transmitted in the specified order.
228 1. The child sends a transfer_request (Section 3.8.1.1) to its
229 parent.
231 2. The parent confirms the validity of the transfer_request,
232 responding with an error code 1203 for invalid requests. An
233 invalid request cancels the transfer. A transfer_request is
234 valid if all of the following are true:
236 * The attached TAO is valid. See Section 3.4.2 for TAO
237 validation steps.
239 * The TAO in the request is identical to the TAO published in
240 the source's publication point.
242 * The transfer is allowed by the transfer policy of the CA
244 3. The parent replies with a transfer_response (Section 3.8.1.2).
245 For transfers of unused INRs, the transfer_response contains an
246 updated certificate, which MUST have the same INRs as the
247 certificate it replaces, minus the INRs specified in the TAO.
248 For live transfers, the transfer_response contains an error code
249 1104 response, indicating that the transfer is valid and being
250 pursued asynchronously.
252 4. The parent determines if it (the parent) is the swing point. See
253 Section 3.3 for this procedure. If it is not the swing point,
254 the parent repeats this process from step 1, acting as the child.
255 If the parent is not the swing point but is a self-signed CA, an
256 error code 1401 MUST be returned.
258 If, after an excessive wait, a child does not receive a response from
259 its parent, the child SHOULD return error 1402 indicating a timeout.
260 This error declares cancellation of the transfer request by the
261 child, and MUST be propagated up AND down the path. This informs any
262 parents waiting further up the path that the child is no longer
263 waiting for an updated certificate, and indicates that the parent
264 MUST time out as well. Ultimately, what constitutes an excessive
265 wait is determined by each CA. However, it is RECOMMENDED that each
266 CA not time out a transfer prior to the notAfter value in the TAO.
268 For live transfers, the source waits until the notAfter value in the
269 TAO expires. If the recipient has successfully received the INRs at
270 that point, the source MUST use the following process to relinquish
271 control of the transferred INRs:
273 1. The child sends a transfer_request (Section 3.8.1.1) to the
274 parent.
276 2. The parent confirms that the transfer_request matches a previous
277 transfer_request, with the exception that the notAfter MUST be in
278 the past. The parent responds with an error code 1203 for
279 invalid requests. A transfer_request is valid if all of the
280 following are true:
282 * The attached TAO is valid, with the exception of the notAfter
283 value which MUST be in the past. See Section 3.4.2 for TAO
284 validation steps.
286 * The TAO in the request MUST be identical to the TAO published
287 in the source's publication point.
289 3. The parent replies with a transfer_response (Section 3.8.1.2).
290 This response MUST include an updated certificate which MUST have
291 the same INRs as the certificate it replaces, minus the INRs
292 specified in the TAO.
294 4. The parent determines if it (the parent) is the swing point. See
295 Section 3.3 for this procedure. If it is not the swing point,
296 the parent repeats this process from step 1, acting as the child.
297 If the parent is not the swing point but is a self-signed CA, an
298 error code 1401 MUST be returned.
300 3.2. INR Recipient Path
302 A recipient will have multiple parents within the RPKI if it has
303 received INR allocations from multiple sources. In such cases, the
304 recipient MUST select the parent via which the resources will be
305 received. The means by which a recipient makes this decision are
306 outside the scope of this protocol. (INR transfers require OOB
307 coordination among the affected organizations. This coordination is
308 expected to provide the recipient with a basis for selecting a parent
309 for the transfer.)
311 Along the path from the transfer recipient to the swing point, with
312 the INR recipient as the initial "child", the following messages MUST
313 be transmitted in the order specified below.
315 1. The child sends a transfer_request, Section 3.8.1.1, to the
316 parent.
318 2. The parent confirms the validity of the transfer_request,
319 responding with an error code 1203 for invalid requests. A
320 transfer_request is valid only if all of the following are true:
322 * The attached TAO is valid. See Section 3.4.2 for TAO
323 validation steps.
325 * The TAO in the request is identical to the TAO published in
326 the source's publication point.
328 * The transfer is allowed by the transfer policy of the CA
330 3. The parent determines if it (the parent) is the swing point. See
331 Section 3.3 for this procedure.
333 4. If it is not the swing point, the parent replies with a
334 transfer_response containing an error code. If the parent is a
335 self-signed CA and it is not the swing point, an error code 1401
336 MUST be returned. If the parent is not a self-signed CA, an
337 error code 1104 response MUST be returned, indicating that the
338 transfer is valid and being pursued asynchronously. The parent
339 then repeats this process from step 1, acting as the child.
341 If, after an excessive wait, a child does not receive a response from
342 its parent, the child SHOULD return error 1402 indicating a timeout.
343 This error declares cancellation of the transfer request by the
344 child, and MUST be propagated up AND down the path by each parent.
345 See the previous section for a discussion of what constitutes
346 "excessive".
348 During live transfers, CAs in the recipient path have an additional
349 responsibility after receiving an updated certificate. The
350 overlapPeriod field of the TAO MUST be less than that number of
351 seconds from the current time to the notAfter value of the TAO. If
352 this test fails, this CA MUST forward an error code 1403 up and down
353 the path, ending the transfer. This minimizes the likelihood that
354 the source and recipient do not have an adequate overlap in ownership
355 of the INRs in question during a live transfer.
357 3.3. Swing Point
359 A CA determines that it is the swing point by verifying that both the
360 INR source and the INR recipient SKIs, as defined in the TAO, are
361 below the CA in the hierarchy. Because this determination is
362 performed for both paths, starting at the source and the recipient,
363 this will uniquely determine the swing point. This document does not
364 cover the case where the swing point is the source or the recipient.
365 If the swing point is the recipient, the INRs are being relinquished
366 and returned to that organization. If the swing point is the source,
367 the INRs are being assigned. This procedure is already accommodated
368 by use of the up/down protocol. Because the RPKI hierarchy is
369 intended to have a unique root, there should always exist a swing
370 point.
372 The swing point MUST behave as follows:
374 1. Confirm that it is the swing point.
376 2. Confirm the validity and uniqueness of the Subject Key
377 Identifiers (SKI) of the CAs (source and recipient)in the TAO.
379 3. Confirm that it controls the INRs to be transferred.
381 4. Wait to receive both transfer_requests, one from the path to the
382 source and one from the path to the recipient.
384 5. Create an updated certificate for the CA on the path from the
385 swing point to the transfer recipient. Publish this certificate
386 in the swing point's publication point and send the updated
387 certificate to the child CA using a transfer_response message.
388 This updated certificate MUST have the same INRs as the
389 certificate it replaces, plus the INRs specified in the TAO.
390 (The swing point MUST still control the INRs being transferred,
391 but this is a side effect of its normal certificate issuance
392 process.)
394 Should a swing point receive an error code 1403 message from the CA
395 in the recipient path, the swing point must forward the error code to
396 the CA on the source path, indicating a cancellation of the transfer.
398 3.4. Transfer Authorization Object
400 The TAO is encapsulated in a CMS object as defined in [RFC6492]
401 Section 3.1.
403 3.4.1. TAO Type
405 TAO OID TBD
407 3.4.2. TAO Validation
409 The TAO must be validated by each participant in the process. The
410 creator of the TAO MUST validate the TAO after creation. All CAs
411 that receive a Transfer Request MUST perform the following actions:
413 1. Determine that the TAO is valid as defined by the steps in
414 [RFC6488] Section 3.
416 2. Verify that either the transferFromSKI or the transferToSKI (or
417 both) correspond to CAs that are descendants of this CA
419 Note: This requires that the transfer recipient hold some
420 address space and thus hold a valid CA Certificate before this
421 process is initiated.
423 3. Verify that the transferFromSKI and the transferToSKI SKIs are
424 valid, corresponding to the SKI extension of a CA within the
425 RPKI, and unique, such that only one CA has an SKI extension that
426 matches each of these values. (This check SHOULD be performed
427 using the RPKI data acquired by the participant in its role as a
428 relying party [RFC6480].)
430 4. The parent of the source checks that the source holds the INRs in
431 question. Each CA above that checks that the INRs are held by
432 the CA that made the request.
434 3.5. ASN.1 Specification of the TAO
436 TransferAuthorization ::= SEQUENCE {
437 transferFromSKI OCTET STRING,
438 transferToSKI OCTET STRING,
439 ipAddrBlocks [0] IPAddrBlocks OPTIONAL,
440 asIdentifiers [1] ASIdentifiers OPTIONAL,
441 liveXfer BOOLEAN DEFAULT FALSE,
442 overlapPeriod INTEGER OPTIONAL
443 }
445 Either ipAddrBlocks or asIdentifiers, or both, MUST be included.
447 3.5.1. transferFromSKI
449 The transferFromSKI MUST be equal to the SKI of the CA that holds the
450 resources.
452 3.5.2. transferToSKI
454 The transferToSKI MUST be equal to the SKI in a valid CA within the
455 RPKI.
457 3.5.3. ipAddrBlocks
459 IPAddrBlocks is specified in [RFC3779] Section 2. If the
460 ipAddrBlocks attribute is included, it MUST NOT be empty and it MUST
461 NOT have any resources marked as inherit.
463 3.5.4. asIdentifiers
465 ASIdentifiers is specified in [RFC3779] Section 3. If the
466 asIdentifiers attribute is included, it MUST NOT be empty and the
467 inherit flag MUST NOT be TRUE.
469 3.5.5. liveXfer
471 This flag is set TRUE only for a transfer of live resources.
473 3.5.6. overlapPeriod
475 overlapPeriod is the minimum number of seconds which the source and
476 recipient MUST both hold the INRs. This field MUST hold a non-zero
477 number for live transfers. The value MUST be omitted for transfers
478 of unused space. Thus this field is present only if liveXfer is
479 TRUE.
481 3.6. Common Message Format
483 This document defines version 2 of the Common Message Format for the
484 up/down protocol. Version 1 is defined in [RFC6492]. The format in
485 version 2 is identical to version 1, but with several added
486 attributes, defined in Section 3.8, and one additional constraint
487 defined in Section 3.7. The checks specified in [RFC6492]
488 Section 3.2 still apply and MUST be applied.
490 3.7. End Entity Certificate Constraint
492 This section corresponds to Section 3.1.1.4 in [RFC6492]. The End
493 Entity (EE) certificate that is required here MUST have its resources
494 marked as inherit. This convention is imposed to ensure that this
495 certificate remains valid during the life of the TAO before, during,
496 and after the transfer takes place.
498 3.8. INR Transfer
500 3.8.1. Transfer
502 This query is used for all requests and responses made during a
503 transfer. This includes messages between the initial sender and its
504 parent, the receiver and its parent, and between each intermediate CA
505 and its parent.
507 3.8.1.1. Request
509 The value of the message "type" element for this request is:
511 type="transfer_request"
513 ----------------------
515 Payload:
517
519 [tao]
520
521 tao_url: value is the pointer to the location where the INR source
522 has published the TAO.
524 [tao] value is the Base64 encoding of the DER-encoded TAO. After
525 decoding, this object MUST be identical to the object published by
526 the source in its publication point.
528 3.8.1.2. Response
530 The value of the message "type" element for this response is:
532 type="transfer_response"
534 --------------------
536 Payload:
538
546
550 [certificate]
551
552 [issuer's certificate]
553
555 In the case where the transfer is for live resources, not all
556 responses will contain a certificate. For the CAs in the path with
557 the INR source, an updated certificate, with the transferred INR
558 removed, will be available once the transfer is complete and the INR
559 source is prepared to relinquish control of the INRs. In contrast,
560 the CAs along the path to the transfer recipient each receive a new
561 certificate after the swing point receives and approves the messages
562 from both the source and the recipient.
564 tao_url is identical to the tao_url in the request. The definition
565 of all other attributes can be found in [RFC6492] Section 3.3.2.
567 3.8.2. Request-Not-Performed Response
569 This response is an extension of [RFC6492] Section 3.6. In addition
570 to the error codes defined there, Error Code 1401 is used when a
571 self-signed CA determines that it is not an ancestor of both the
572 source and the recipient. This indicates a failure of the automated
573 transfer and a manual transfer must take place.
575 3.8.3. Timeout Response
577 This response is an extension of [RFC6492] Section 3.6. In addition
578 to the error codes defined there, Error Code 1402 is used when a CA
579 determines that it has waited an excessive duration for a response
580 from its parent. This indicates a failure of the transfer.
582 3.8.4. Overlap Failure Response
584 This response is an extension of [RFC6492] Section 3.6. In addition
585 to the error codes defined there, Error Code 1403 is used when a CA
586 in the recipient path determines that the overlapPeriod value is less
587 than the number of seconds between the current time and the notAfter
588 value in the TAO. This indicates a failure of the transfer.
590 3.9. XML Schema
592 The following is a RELAX NG compact form schema [ISO.19757-2.2003]
593 describing version 2 of this protocol.
595 Note: As discussed in [W3C.REC-xml-names-20091208], "the namespace
596 name, to serve its intended purpose, SHOULD have the
597 characteristics of uniqueness and persistence. It is not a goal
598 that it be directly usable for retrieval of a schema (if any
599 exists)".
601 default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
603 grammar {
604 resource_set_as = xsd:string { maxLength="512000"
605 pattern="[\-,0-9]*" }
606 resource_set_ip4 = xsd:string { maxLength="512000"
607 pattern="[\-,/.0-9]*" }
608 resource_set_ip6 = xsd:string { maxLength="512000"
609 pattern="[\-,/:0-9a-fA-F]*" }
611 class_name = xsd:token { minLength="1" maxLength="1024" }
612 ski = xsd:token { minLength="27" maxLength="1024" }
613 label = xsd:token { minLength="1" maxLength="1024" }
614 cert_url = xsd:string { minLength="10" maxLength="4096" }
615 base64_binary = xsd:base64Binary { minLength="4"
616 maxLength="512000" }
617 tao_url = xsd:string { minLength="10" maxLength="4096" }
619 start = element message {
620 attribute version { xsd:positiveInteger {
621 maxInclusive="1" } },
622 attribute sender { label },
623 attribute recipient { label },
624 payload
625 }
627 payload |= attribute type { "list" }, list_request
628 payload |= attribute type { "list_response"}, list_response
629 payload |= attribute type { "issue" }, issue_request
630 payload |= attribute type { "issue_response"}, issue_response
631 payload |= attribute type { "revoke" }, revoke_request
632 payload |= attribute type { "revoke_response"}, revoke_response
633 payload |= attribute type { "error_response"}, error_response
634 payload |= attribute type { "transfer_response"},
635 transfer_response
637 list_request = empty
638 list_response = class*
640 class = element class {
641 attribute class_name { class_name },
642 attribute cert_url { cert_url },
643 attribute resource_set_as { resource_set_as },
644 attribute resource_set_ipv4 { resource_set_ip4 },
645 attribute resource_set_ipv6 { resource_set_ip6 },
646 attribute resource_set_notafter { xsd:dateTime },
647 attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
648 pattern="rsync://.+"} }?,
649 element certificate {
650 attribute cert_url { cert_url },
651 attribute req_resource_set_as { resource_set_as }?,
652 attribute req_resource_set_ipv4 { resource_set_ip4 }?,
653 attribute req_resource_set_ipv6 { resource_set_ip6 }?,
654 base64_binary
655 }*,
656 element issuer { base64_binary }
657 }
659 issue_request = element request {
660 attribute class_name { class_name },
661 attribute req_resource_set_as { resource_set_as }?,
662 attribute req_resource_set_ipv4 { resource_set_ip4 }?,
663 attribute req_resource_set_ipv6 { resource_set_ip6 }?,
664 base64_binary
665 }
666 issue_response = class
668 revoke_request = revocation
669 revoke_response = revocation
671 revocation = element key {
672 attribute class_name { class_name },
673 attribute ski { ski }
674 }
676 error_response =
677 element status { xsd:positiveInteger { maxInclusive="9999" } },
678 element description { attribute xml:lang { xsd:language },
679 xsd:string { maxLength="1024" } }*
680 }
682 transfer_request = element request {
683 attribute tao_url { tao_url },
684 element tao { base64_binary }
685 }
687 transfer_response = element response {
688 attribute tao_url { tao_url },
689 attribute cert_url { cert_url },
690 attribute resource_set_as { resource_set_as },
691 attribute resource_set_ipv4 { resource_set_ip4 },
692 attribute resource_set_ipv6 { resource_set_ip6 },
693 attribute resource_set_notafter { xsd:dateTime },
694 attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
695 pattern="rsync://.+"} }?,
696 element certificate {
697 attribute cert_url { cert_url },
698 attribute req_resource_set_as { resource_set_as }?,
699 attribute req_resource_set_ipv4 { resource_set_ip4 }?,
700 attribute req_resource_set_ipv6 { resource_set_ip6 }?,
701 base64_binary
702 }*,
703 element issuer { base64_binary }
704 }
706 4. Security Considerations
708 The checks described at each stage are designed to ensure that these
709 four security goals are met:
711 o the TAO was generated by the indicated INR source, that source
712 holds the INRs being transferred, and the TAO has not been
713 modified by another party
715 o the transfer recipient is the intended recipient of the resources
716 as per the INR source
718 o each CA that processes a transfer request either holds the
719 resources being transferred, or it is on the path between the
720 swing point and the transfer recipient
722 o each CA along the path approved the transfer (or has rejected it)
724 Up/down protocol messages contain a time-based anti-reply feature, so
725 replays of these signed messages can be detected. If a request
726 message is redirected, a CA receiving it will detect and reject this
727 because the request will not be from one of its children. A
728 redirected response message also will be detected because the
729 response will not be from the child's immediate parent. Because all
730 messages (both requests and responses) are contained within a CMS
731 object, the sender of a message is validated through signature
732 verification.
734 For live transfers, the source initiates the relinquishment of the
735 INRs that were transferred. If they fail to initiate the
736 relinquishment in a timely manner, the recipient may choose to
737 contact any or all of the source's ancestors (up to the swing point)
738 to pursue a forced relinquishment of resources. Any legal or
739 contractual processes used are outside the scope of this document.
741 5. IANA Considerations
743 An OID is requested for the TAO object defined above.
745 6. Acknowledgements
747 The author would like to acknowledge the valued contribution of Steve
748 Kent for providing a top level description of the TAO protocol, David
749 Mandelberg for his contributions to the security of the protocol, and
750 the authors of the rpki-updown protocol ([RFC6492]) Geoff Huston,
751 Robert Loomans, Byron Ellacott, and Rob Austein.
753 7. References
755 7.1. Normative References
757 [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
758 Protocol for Provisioning Resource Certificates", RFC
759 6492, February 2012.
761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
762 Requirement Levels", BCP 14, RFC 2119, March 1997.
764 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
765 Addresses and AS Identifiers", RFC 3779, June 2004.
767 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
768 Resource Certificate Repository Structure", RFC 6481,
769 February 2012.
771 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
772 Template for the Resource Public Key Infrastructure
773 (RPKI)", RFC 6488, February 2012.
775 7.2. Informative References
777 [W3C.REC-xml-names-20091208]
778 Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
779 Thompson, "Namespaces in XML 1.0 (Third Edition)", World
780 Wide Web Consortium Recommendation REC-xml-names-20091208,
781 December 2009,
782 .
784 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
785 Secure Internet Routing", RFC 6480, February 2012.
787 [ISO.19757-2.2003]
788 International Organization for Standardization,
789 "Information technology -- Document Schema Definition
790 Language (DSDL) -- Part 2: Regular-grammar-based
791 validation -- RELAX NG", ISO International Standard
792 19757-2, December 2003.
794 Author's Address
795 Edric Barnes
796 BBN Technologies
797 10 Moulton St
798 Cambridge, MA
799 US
801 EMail: ebarnes@bbn.com