Internet DRAFT - draft-barnes-sidr-tao

draft-barnes-sidr-tao







Secure Inter-Domain Routing                                    E. Barnes
Internet-Draft                                          BBN Technologies
Intended status: Standards Track                       February 13, 2014
Expires: August 17, 2014


Resource Public Key Infrastructure (RPKI) Resource Transfer Protocol and
                  Transfer Authorization Object (TAO)
                        draft-barnes-sidr-tao-00

Abstract

   This document defines an extension to the rpki-updown protocol to
   provide support for transferring Internet Number Resources from one
   INR holder to another.  Such transfers take place external to the
   RPKI, using procedures defined within and between RIRs.  This
   protocol facilitates automation of the maintenance of RPKI data in
   the context of INR transfers.  The protocol supports asynchronous
   transfers of live or unused INRs within an RIR or between RIRs.  The
   scope of this protocol is limited to the transfer of Internet Number
   Resources within the Resource Public Key Infrastructure.  In support
   of this protocol, this document also defines a new signed object type
   for the RPKI repository system, the Transfer Authorization Object
   (TAO).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 17, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Barnes                   Expires August 17, 2014                [Page 1]

Internet-Draft        Transfer Authorization Object        February 2014


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Specifications . . . . . . . . . . . . . . . . . . .   4
     3.1.  INR Source Path . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  INR Recipient Path  . . . . . . . . . . . . . . . . . . .   7
     3.3.  Swing Point . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Transfer Authorization Object . . . . . . . . . . . . . .   9
       3.4.1.  TAO Type  . . . . . . . . . . . . . . . . . . . . . .   9
       3.4.2.  TAO Validation  . . . . . . . . . . . . . . . . . . .   9
     3.5.  ASN.1 Specification of the TAO  . . . . . . . . . . . . .  10
       3.5.1.  transferFromSKI . . . . . . . . . . . . . . . . . . .  10
       3.5.2.  transferToSKI . . . . . . . . . . . . . . . . . . . .  10
       3.5.3.  ipAddrBlocks  . . . . . . . . . . . . . . . . . . . .  10
       3.5.4.  asIdentifiers . . . . . . . . . . . . . . . . . . . .  10
       3.5.5.  liveXfer  . . . . . . . . . . . . . . . . . . . . . .  10
       3.5.6.  overlapPeriod . . . . . . . . . . . . . . . . . . . .  11
     3.6.  Common Message Format . . . . . . . . . . . . . . . . . .  11
     3.7.  End Entity Certificate Constraint . . . . . . . . . . . .  11
     3.8.  INR Transfer  . . . . . . . . . . . . . . . . . . . . . .  11
       3.8.1.  Transfer  . . . . . . . . . . . . . . . . . . . . . .  11
       3.8.2.  Request-Not-Performed Response  . . . . . . . . . . .  13
       3.8.3.  Timeout Response  . . . . . . . . . . . . . . . . . .  13
       3.8.4.  Overlap Failure Response  . . . . . . . . . . . . . .  13
     3.9.  XML Schema  . . . . . . . . . . . . . . . . . . . . . . .  13
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  17








Barnes                   Expires August 17, 2014                [Page 2]

Internet-Draft        Transfer Authorization Object        February 2014


1.  Introduction

   This document defines an extension to the rpki-updown protocol,
   defined in [RFC6492], to provide support for transferring Internet
   Number Resources from one INR holder to another.  The protocol
   supports asynchronous transfers of live or unused INRs.  The scope of
   the protocol is limited to the transfer of Internet Number Resource
   within the Resource Public Key Infrastructure, defined in [RFC6480].
   In support of this protocol, this document also defines a new signed
   object type, the Transfer Authorization Object (TAO), which makes use
   of the signed object format defined in [RFC6488].

   Many of the messages in this protocol are identical to those in
   [RFC6488], and the result of the protocol, updated certificates
   published in the RPKI repository system [RFC6481], is the same for
   both protocols.  To initiate a transfer, an INR holder, or source,
   creates a TAO and publishes it in its publication point.  The TAO is
   a declaration of the proposed transfer, signed by the transfer
   source.  The source communicates the location of the TAO to the INR
   recipient.  Both entities then pursue the transfer independently,
   recursively requesting the transfer from their parents until the
   lowest common ancestor, the swing point is reached.  The swing point
   acts as the ultimate arbiter of the transfer, although any
   Certification Authority (CA) involved in the transfer is able to deny
   the transfer.  The protocol assumes that the source of the transfer,
   and the recipient have gained preliminary approval for the transfer,
   out-of-band (OOB), prior to publishing the TAO and initiating the
   protocol.

1.1.  Terminology

   Terms used in this document are:

   "Internet Number Resource"  (or "resource" or "INR") used in the
      context of this document to refer to Autonomous System (AS)
      numbers and IP version 4 or IP version 6 addresses.

   "swing point"  the lowest common ancestor (Certification Authority)
      of both the INR source and the INR recipient in the RPKI
      hierarchy.  It is assumed that the swing point is neither the
      source nor the recipient.

   "source"  (or "INR source") the INR holder that initiates the
      transfer

   "recipient"  (or "INR recipient") the INR holder that is the
      destination of the transfer




Barnes                   Expires August 17, 2014                [Page 3]

Internet-Draft        Transfer Authorization Object        February 2014


   "live"  a live INR is a resource that is currently in use

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119].

2.  Scope

   This Resource Public Key Infrastructure (RPKI) INR transfer protocol
   defines a basic set of interactions that allows:

   o  an INR holder to initiate the transfer of Internet Number
      Resources,

   o  the INR source and INR recipient to pursue the transfer
      asynchronously,

   o  and each Certification Authority (CA) along the path between the
      source and recipient (including the swing point) to validate and
      approve, or deny, any such transfer.

   The resource allocation database and INR transfer policies of each CA
   along the path are authoritative when determining whether the
   resources in question may be transferred.

   This protocol specification does not encompass:

   o  the specification of interactions with the each CA's resource
      allocation database, nor the specification of a protocol to manage
      the publication repository.

   o  transfers where the source or recipient is also the swing point.
      Both situations are already handled by rpki-updown as explained in
      Section 3.3.

3.  Protocol Specifications

   The INR source MUST initiate the transfer by creating and publishing
   the Transfer Authorization Object (TAO, see Section 3.4) at its
   publication point [RFC6481].  The URL of the TAO SHOULD be
   communicated to the transfer recipient, e.g., via email.  Once the
   TAO is published, and the recipient has received the URL of the TAO,
   two separate processes begin: the first from the INR source to the
   swing point, the second from the transfer recipient to the swing
   point.  These two processes proceed independently and recursively.
   The following steps occur between each parent and child along the
   specified paths in the hierarchy.




Barnes                   Expires August 17, 2014                [Page 4]

Internet-Draft        Transfer Authorization Object        February 2014


   In both cases, when a CA receives an updated certificate from its
   immediate parent, it MUST promptly update the certificate for the
   child involved in the transfer.  This certificate is published in its
   publication point and sent to the child using a transfer_response
   message (Section 3.8.1.2.  If this CA is the INR source or INR
   recipient, no updates are necessary since receipt of the updated
   certificate indicates that the parent has updated the end point of
   the transfer.  Similarly, when a CA receives an error message from a
   parent, the CA MUST forward the message code to its immediate child
   along the path towards the INR source or INR recipient.

   Both the INR source and the INR recipient MUST NOT rekey during a
   transfer; their SKIs are captured in the TAO and the validity of the
   TAO requires the SKIs not change during the process.  A new key would
   invalidate the TAO and require restarting the transfer process.  To
   avoid this problem, the source SHOULD NOT initiate a transfer that is
   expected to take longer than the notAfter date in its, or the
   recipient's, CA certificate.  The source should contact (OOB) the
   CA's along the path to receive an estimate of the time required to
   complete a transfer, to aid in making this determination.

   The process described below is used for transferring either live or
   unused INRs.  The process is identical for both types of transfers
   except where otherwise specified.

3.1.  INR Source Path

   The source MUST NOT request a transfer of any INRs that are delegated
   to one of the source's children (i.e., appear in a CA certificate
   issued by the source).  This requirement avoids one way that a TAO
   that is valid at the beginning of a transfer could become invalid
   before the end of the transfer.  In particular, in the instance where
   the source of this transfer is the swing point in another transfer,
   this prevents the swing point from transferring INRs to a different
   recipient than specified in the first transfer.

   Along the path from the INR source to the swing point, with the INR
   source as the initial "child", the following messages MUST be
   transmitted in the specified order.

   1.  The child sends a transfer_request (Section 3.8.1.1) to its
       parent.

   2.  The parent confirms the validity of the transfer_request,
       responding with an error code 1203 for invalid requests.  An
       invalid request cancels the transfer.  A transfer_request is
       valid if all of the following are true:




Barnes                   Expires August 17, 2014                [Page 5]

Internet-Draft        Transfer Authorization Object        February 2014


       *  The attached TAO is valid.  See Section 3.4.2 for TAO
          validation steps.

       *  The TAO in the request is identical to the TAO published in
          the source's publication point.

       *  The transfer is allowed by the transfer policy of the CA

   3.  The parent replies with a transfer_response (Section 3.8.1.2).
       For transfers of unused INRs, the transfer_response contains an
       updated certificate, which MUST have the same INRs as the
       certificate it replaces, minus the INRs specified in the TAO.
       For live transfers, the transfer_response contains an error code
       1104 response, indicating that the transfer is valid and being
       pursued asynchronously.

   4.  The parent determines if it (the parent) is the swing point.  See
       Section 3.3 for this procedure.  If it is not the swing point,
       the parent repeats this process from step 1, acting as the child.
       If the parent is not the swing point but is a self-signed CA, an
       error code 1401 MUST be returned.

   If, after an excessive wait, a child does not receive a response from
   its parent, the child SHOULD return error 1402 indicating a timeout.
   This error declares cancellation of the transfer request by the
   child, and MUST be propagated up AND down the path.  This informs any
   parents waiting further up the path that the child is no longer
   waiting for an updated certificate, and indicates that the parent
   MUST time out as well.  Ultimately, what constitutes an excessive
   wait is determined by each CA.  However, it is RECOMMENDED that each
   CA not time out a transfer prior to the notAfter value in the TAO.

   For live transfers, the source waits until the notAfter value in the
   TAO expires.  If the recipient has successfully received the INRs at
   that point, the source MUST use the following process to relinquish
   control of the transferred INRs:

   1.  The child sends a transfer_request (Section 3.8.1.1) to the
       parent.

   2.  The parent confirms that the transfer_request matches a previous
       transfer_request, with the exception that the notAfter MUST be in
       the past.  The parent responds with an error code 1203 for
       invalid requests.  A transfer_request is valid if all of the
       following are true:






Barnes                   Expires August 17, 2014                [Page 6]

Internet-Draft        Transfer Authorization Object        February 2014


       *  The attached TAO is valid, with the exception of the notAfter
          value which MUST be in the past.  See Section 3.4.2 for TAO
          validation steps.

       *  The TAO in the request MUST be identical to the TAO published
          in the source's publication point.

   3.  The parent replies with a transfer_response (Section 3.8.1.2).
       This response MUST include an updated certificate which MUST have
       the same INRs as the certificate it replaces, minus the INRs
       specified in the TAO.

   4.  The parent determines if it (the parent) is the swing point.  See
       Section 3.3 for this procedure.  If it is not the swing point,
       the parent repeats this process from step 1, acting as the child.
       If the parent is not the swing point but is a self-signed CA, an
       error code 1401 MUST be returned.

3.2.  INR Recipient Path

   A recipient will have multiple parents within the RPKI if it has
   received INR allocations from multiple sources.  In such cases, the
   recipient MUST select the parent via which the resources will be
   received.  The means by which a recipient makes this decision are
   outside the scope of this protocol.  (INR transfers require OOB
   coordination among the affected organizations.  This coordination is
   expected to provide the recipient with a basis for selecting a parent
   for the transfer.)

   Along the path from the transfer recipient to the swing point, with
   the INR recipient as the initial "child", the following messages MUST
   be transmitted in the order specified below.

   1.  The child sends a transfer_request, Section 3.8.1.1, to the
       parent.

   2.  The parent confirms the validity of the transfer_request,
       responding with an error code 1203 for invalid requests.  A
       transfer_request is valid only if all of the following are true:

       *  The attached TAO is valid.  See Section 3.4.2 for TAO
          validation steps.

       *  The TAO in the request is identical to the TAO published in
          the source's publication point.

       *  The transfer is allowed by the transfer policy of the CA




Barnes                   Expires August 17, 2014                [Page 7]

Internet-Draft        Transfer Authorization Object        February 2014


   3.  The parent determines if it (the parent) is the swing point.  See
       Section 3.3 for this procedure.

   4.  If it is not the swing point, the parent replies with a
       transfer_response containing an error code.  If the parent is a
       self-signed CA and it is not the swing point, an error code 1401
       MUST be returned.  If the parent is not a self-signed CA, an
       error code 1104 response MUST be returned, indicating that the
       transfer is valid and being pursued asynchronously.  The parent
       then repeats this process from step 1, acting as the child.

   If, after an excessive wait, a child does not receive a response from
   its parent, the child SHOULD return error 1402 indicating a timeout.
   This error declares cancellation of the transfer request by the
   child, and MUST be propagated up AND down the path by each parent.
   See the previous section for a discussion of what constitutes
   "excessive".

   During live transfers, CAs in the recipient path have an additional
   responsibility after receiving an updated certificate.  The
   overlapPeriod field of the TAO MUST be less than that number of
   seconds from the current time to the notAfter value of the TAO.  If
   this test fails, this CA MUST forward an error code 1403 up and down
   the path, ending the transfer.  This minimizes the likelihood that
   the source and recipient do not have an adequate overlap in ownership
   of the INRs in question during a live transfer.

3.3.  Swing Point

   A CA determines that it is the swing point by verifying that both the
   INR source and the INR recipient SKIs, as defined in the TAO, are
   below the CA in the hierarchy.  Because this determination is
   performed for both paths, starting at the source and the recipient,
   this will uniquely determine the swing point.  This document does not
   cover the case where the swing point is the source or the recipient.
   If the swing point is the recipient, the INRs are being relinquished
   and returned to that organization.  If the swing point is the source,
   the INRs are being assigned.  This procedure is already accommodated
   by use of the up/down protocol.  Because the RPKI hierarchy is
   intended to have a unique root, there should always exist a swing
   point.

   The swing point MUST behave as follows:

   1.  Confirm that it is the swing point.

   2.  Confirm the validity and uniqueness of the Subject Key
       Identifiers (SKI) of the CAs (source and recipient)in the TAO.



Barnes                   Expires August 17, 2014                [Page 8]

Internet-Draft        Transfer Authorization Object        February 2014


   3.  Confirm that it controls the INRs to be transferred.

   4.  Wait to receive both transfer_requests, one from the path to the
       source and one from the path to the recipient.

   5.  Create an updated certificate for the CA on the path from the
       swing point to the transfer recipient.  Publish this certificate
       in the swing point's publication point and send the updated
       certificate to the child CA using a transfer_response message.
       This updated certificate MUST have the same INRs as the
       certificate it replaces, plus the INRs specified in the TAO.
       (The swing point MUST still control the INRs being transferred,
       but this is a side effect of its normal certificate issuance
       process.)

   Should a swing point receive an error code 1403 message from the CA
   in the recipient path, the swing point must forward the error code to
   the CA on the source path, indicating a cancellation of the transfer.

3.4.  Transfer Authorization Object

   The TAO is encapsulated in a CMS object as defined in [RFC6492]
   Section 3.1.

3.4.1.  TAO Type

   TAO OID TBD

3.4.2.  TAO Validation

   The TAO must be validated by each participant in the process.  The
   creator of the TAO MUST validate the TAO after creation.  All CAs
   that receive a Transfer Request MUST perform the following actions:

   1.  Determine that the TAO is valid as defined by the steps in
       [RFC6488] Section 3.

   2.  Verify that either the transferFromSKI or the transferToSKI (or
       both) correspond to CAs that are descendants of this CA

          Note: This requires that the transfer recipient hold some
          address space and thus hold a valid CA Certificate before this
          process is initiated.

   3.  Verify that the transferFromSKI and the transferToSKI SKIs are
       valid, corresponding to the SKI extension of a CA within the
       RPKI, and unique, such that only one CA has an SKI extension that
       matches each of these values.  (This check SHOULD be performed



Barnes                   Expires August 17, 2014                [Page 9]

Internet-Draft        Transfer Authorization Object        February 2014


       using the RPKI data acquired by the participant in its role as a
       relying party [RFC6480].)

   4.  The parent of the source checks that the source holds the INRs in
       question.  Each CA above that checks that the INRs are held by
       the CA that made the request.

3.5.  ASN.1 Specification of the TAO

    TransferAuthorization ::= SEQUENCE {
      transferFromSKI OCTET STRING,
      transferToSKI OCTET STRING,
      ipAddrBlocks [0] IPAddrBlocks OPTIONAL,
      asIdentifiers [1] ASIdentifiers OPTIONAL,
      liveXfer BOOLEAN DEFAULT FALSE,
      overlapPeriod INTEGER OPTIONAL
   }

   Either ipAddrBlocks or asIdentifiers, or both, MUST be included.

3.5.1.  transferFromSKI

   The transferFromSKI MUST be equal to the SKI of the CA that holds the
   resources.

3.5.2.  transferToSKI

   The transferToSKI MUST be equal to the SKI in a valid CA within the
   RPKI.

3.5.3.  ipAddrBlocks

   IPAddrBlocks is specified in [RFC3779] Section 2.  If the
   ipAddrBlocks attribute is included, it MUST NOT be empty and it MUST
   NOT have any resources marked as inherit.

3.5.4.  asIdentifiers

   ASIdentifiers is specified in [RFC3779] Section 3.  If the
   asIdentifiers attribute is included, it MUST NOT be empty and the
   inherit flag MUST NOT be TRUE.

3.5.5.  liveXfer

   This flag is set TRUE only for a transfer of live resources.






Barnes                   Expires August 17, 2014               [Page 10]

Internet-Draft        Transfer Authorization Object        February 2014


3.5.6.  overlapPeriod

   overlapPeriod is the minimum number of seconds which the source and
   recipient MUST both hold the INRs.  This field MUST hold a non-zero
   number for live transfers.  The value MUST be omitted for transfers
   of unused space.  Thus this field is present only if liveXfer is
   TRUE.

3.6.  Common Message Format

   This document defines version 2 of the Common Message Format for the
   up/down protocol.  Version 1 is defined in [RFC6492].  The format in
   version 2 is identical to version 1, but with several added
   attributes, defined in Section 3.8, and one additional constraint
   defined in Section 3.7.  The checks specified in [RFC6492]
   Section 3.2 still apply and MUST be applied.

3.7.  End Entity Certificate Constraint

   This section corresponds to Section 3.1.1.4 in [RFC6492].  The End
   Entity (EE) certificate that is required here MUST have its resources
   marked as inherit.  This convention is imposed to ensure that this
   certificate remains valid during the life of the TAO before, during,
   and after the transfer takes place.

3.8.  INR Transfer

3.8.1.  Transfer

   This query is used for all requests and responses made during a
   transfer.  This includes messages between the initial sender and its
   parent, the receiver and its parent, and between each intermediate CA
   and its parent.

3.8.1.1.  Request

   The value of the message "type" element for this request is:

      type="transfer_request"

   ----------------------

   Payload:

    <request
   tao_url="url">
   [tao]
   </request>



Barnes                   Expires August 17, 2014               [Page 11]

Internet-Draft        Transfer Authorization Object        February 2014


   tao_url:  value is the pointer to the location where the INR source
      has published the TAO.

   [tao]  value is the Base64 encoding of the DER-encoded TAO.  After
      decoding, this object MUST be identical to the object published by
      the source in its publication point.

3.8.1.2.  Response

   The value of the message "type" element for this response is:

      type="transfer_response"

   --------------------

   Payload:

   <class
   tao_url="url"
   cert_url="url"
   resource_set_as="as resource set"
   resource_set_ipv4="ipv4 resource set"
   resource_set_ipv6="ipv6 resource set"
   resource_set_notafter="datetime"
   suggested_sia_head="[directory uri]">
   <certificate cert_url="url"
   req_resource_set_as="as resource set"
   req_resource_set_ipv4="ipv4 resource set"
   req_resource_set_ipv6="ipv6 resource set" >
   [certificate]
   </certificate>
   <issuer>[issuer's certificate]</issuer>
   </class>

   In the case where the transfer is for live resources, not all
   responses will contain a certificate.  For the CAs in the path with
   the INR source, an updated certificate, with the transferred INR
   removed, will be available once the transfer is complete and the INR
   source is prepared to relinquish control of the INRs.  In contrast,
   the CAs along the path to the transfer recipient each receive a new
   certificate after the swing point receives and approves the messages
   from both the source and the recipient.

   tao_url is identical to the tao_url in the request.  The definition
   of all other attributes can be found in [RFC6492] Section 3.3.2.






Barnes                   Expires August 17, 2014               [Page 12]

Internet-Draft        Transfer Authorization Object        February 2014


3.8.2.  Request-Not-Performed Response

   This response is an extension of [RFC6492] Section 3.6.  In addition
   to the error codes defined there, Error Code 1401 is used when a
   self-signed CA determines that it is not an ancestor of both the
   source and the recipient.  This indicates a failure of the automated
   transfer and a manual transfer must take place.

3.8.3.  Timeout Response

   This response is an extension of [RFC6492] Section 3.6.  In addition
   to the error codes defined there, Error Code 1402 is used when a CA
   determines that it has waited an excessive duration for a response
   from its parent.  This indicates a failure of the transfer.

3.8.4.  Overlap Failure Response

   This response is an extension of [RFC6492] Section 3.6.  In addition
   to the error codes defined there, Error Code 1403 is used when a CA
   in the recipient path determines that the overlapPeriod value is less
   than the number of seconds between the current time and the notAfter
   value in the TAO.  This indicates a failure of the transfer.

3.9.  XML Schema

   The following is a RELAX NG compact form schema [ISO.19757-2.2003]
   describing version 2 of this protocol.

      Note: As discussed in [W3C.REC-xml-names-20091208], "the namespace
      name, to serve its intended purpose, SHOULD have the
      characteristics of uniqueness and persistence.  It is not a goal
      that it be directly usable for retrieval of a schema (if any
      exists)".

   default namespace = "http://www.apnic.net/specs/rescerts/up-down/"

   grammar {
      resource_set_as = xsd:string {  maxLength="512000"
                                      pattern="[\-,0-9]*" }
      resource_set_ip4 = xsd:string { maxLength="512000"
                                      pattern="[\-,/.0-9]*" }
      resource_set_ip6 = xsd:string { maxLength="512000"
                                      pattern="[\-,/:0-9a-fA-F]*" }


      class_name = xsd:token { minLength="1" maxLength="1024" }
      ski = xsd:token { minLength="27" maxLength="1024" }
      label = xsd:token { minLength="1" maxLength="1024" }



Barnes                   Expires August 17, 2014               [Page 13]

Internet-Draft        Transfer Authorization Object        February 2014


      cert_url = xsd:string { minLength="10" maxLength="4096" }
      base64_binary = xsd:base64Binary { minLength="4"
                                         maxLength="512000" }
      tao_url = xsd:string { minLength="10" maxLength="4096" }

      start = element message {
         attribute version { xsd:positiveInteger {
                                              maxInclusive="1" } },
         attribute sender { label },
         attribute recipient { label },
         payload
      }

      payload |= attribute type { "list" }, list_request
      payload |= attribute type { "list_response"}, list_response
      payload |= attribute type { "issue" }, issue_request
      payload |= attribute type { "issue_response"}, issue_response
      payload |= attribute type { "revoke" }, revoke_request
      payload |= attribute type { "revoke_response"}, revoke_response
      payload |= attribute type { "error_response"}, error_response
      payload |= attribute type { "transfer_response"},
                                   transfer_response

      list_request = empty
      list_response = class*

      class = element class {
        attribute class_name { class_name },
        attribute cert_url { cert_url },
        attribute resource_set_as { resource_set_as },
        attribute resource_set_ipv4 { resource_set_ip4 },
        attribute resource_set_ipv6 { resource_set_ip6 },
        attribute resource_set_notafter { xsd:dateTime },
        attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
                                              pattern="rsync://.+"} }?,
        element certificate {
          attribute cert_url { cert_url },
          attribute req_resource_set_as { resource_set_as }?,
          attribute req_resource_set_ipv4 { resource_set_ip4 }?,
          attribute req_resource_set_ipv6 { resource_set_ip6 }?,
          base64_binary
        }*,
        element issuer { base64_binary }
      }

      issue_request = element request {
        attribute class_name { class_name },
        attribute req_resource_set_as { resource_set_as }?,



Barnes                   Expires August 17, 2014               [Page 14]

Internet-Draft        Transfer Authorization Object        February 2014


        attribute req_resource_set_ipv4 { resource_set_ip4 }?,
        attribute req_resource_set_ipv6 { resource_set_ip6 }?,
        base64_binary
      }
      issue_response = class

      revoke_request = revocation
      revoke_response = revocation

      revocation = element key {
         attribute class_name { class_name },
         attribute ski { ski }
      }

      error_response =
        element status { xsd:positiveInteger { maxInclusive="9999" } },
        element description { attribute xml:lang { xsd:language },
                                  xsd:string { maxLength="1024" } }*
      }

      transfer_request = element request {
        attribute tao_url { tao_url },
        element tao { base64_binary }
      }

      transfer_response = element response {
         attribute tao_url { tao_url },
         attribute cert_url { cert_url },
         attribute resource_set_as { resource_set_as },
         attribute resource_set_ipv4 { resource_set_ip4 },
         attribute resource_set_ipv6 { resource_set_ip6 },
         attribute resource_set_notafter { xsd:dateTime },
         attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
                                               pattern="rsync://.+"} }?,
         element certificate {
            attribute cert_url { cert_url },
            attribute req_resource_set_as { resource_set_as }?,
            attribute req_resource_set_ipv4 { resource_set_ip4 }?,
            attribute req_resource_set_ipv6 { resource_set_ip6 }?,
            base64_binary
         }*,
         element issuer { base64_binary }
      }








Barnes                   Expires August 17, 2014               [Page 15]

Internet-Draft        Transfer Authorization Object        February 2014


4.  Security Considerations

   The checks described at each stage are designed to ensure that these
   four security goals are met:

   o  the TAO was generated by the indicated INR source, that source
      holds the INRs being transferred, and the TAO has not been
      modified by another party

   o  the transfer recipient is the intended recipient of the resources
      as per the INR source

   o  each CA that processes a transfer request either holds the
      resources being transferred, or it is on the path between the
      swing point and the transfer recipient

   o  each CA along the path approved the transfer (or has rejected it)

   Up/down protocol messages contain a time-based anti-reply feature, so
   replays of these signed messages can be detected.  If a request
   message is redirected, a CA receiving it will detect and reject this
   because the request will not be from one of its children.  A
   redirected response message also will be detected because the
   response will not be from the child's immediate parent.  Because all
   messages (both requests and responses) are contained within a CMS
   object, the sender of a message is validated through signature
   verification.

   For live transfers, the source initiates the relinquishment of the
   INRs that were transferred.  If they fail to initiate the
   relinquishment in a timely manner, the recipient may choose to
   contact any or all of the source's ancestors (up to the swing point)
   to pursue a forced relinquishment of resources.  Any legal or
   contractual processes used are outside the scope of this document.

5.  IANA Considerations

   An OID is requested for the TAO object defined above.

6.  Acknowledgements

   The author would like to acknowledge the valued contribution of Steve
   Kent for providing a top level description of the TAO protocol, David
   Mandelberg for his contributions to the security of the protocol, and
   the authors of the rpki-updown protocol ([RFC6492]) Geoff Huston,
   Robert Loomans, Byron Ellacott, and Rob Austein.





Barnes                   Expires August 17, 2014               [Page 16]

Internet-Draft        Transfer Authorization Object        February 2014


7.  References

7.1.  Normative References

   [RFC6492]  Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
              Protocol for Provisioning Resource Certificates", RFC
              6492, February 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              February 2012.

   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure
              (RPKI)", RFC 6488, February 2012.

7.2.  Informative References

   [W3C.REC-xml-names-20091208]
              Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
              Thompson, "Namespaces in XML 1.0 (Third Edition)", World
              Wide Web Consortium Recommendation REC-xml-names-20091208,
              December 2009,
              <http://www.w3.org/TR/2009/REC-xml-names-20091208>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, February 2012.

   [ISO.19757-2.2003]
              International Organization for Standardization,
              "Information technology -- Document Schema Definition
              Language (DSDL) -- Part 2: Regular-grammar-based
              validation -- RELAX NG", ISO International Standard
              19757-2, December 2003.

Author's Address









Barnes                   Expires August 17, 2014               [Page 17]

Internet-Draft        Transfer Authorization Object        February 2014


   Edric Barnes
   BBN Technologies
   10 Moulton St
   Cambridge, MA
   US

   EMail: ebarnes@bbn.com












































Barnes                   Expires August 17, 2014               [Page 18]