From d8e3b6d1d56e47699551510328df95a2c5a7a9d4 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 11 Aug 2020 12:36:41 -0700 Subject: [PATCH] wg adoption, so -00 --- draft-ietf-sidrops-6486bis.xml | 974 +++++++++++++++++++++++++++++++++ 1 file changed, 974 insertions(+) create mode 100644 draft-ietf-sidrops-6486bis.xml diff --git a/draft-ietf-sidrops-6486bis.xml b/draft-ietf-sidrops-6486bis.xml new file mode 100644 index 0000000..32fa2ed --- /dev/null +++ b/draft-ietf-sidrops-6486bis.xml @@ -0,0 +1,974 @@ + + + + + + + + + + + + + + + + + Manifests for the Resource Public Key Infrastructure (RPKI) + + + Arrcus, Inc. +
+ sra@hactrn.net +
+ + + + APNIC +
+ + 6 Cordelia St + South Brisbane + QLD 4101 + Australia + + gih@apnic.net +
+ + + + Independent +
+ kkent@alum.mit.edu +
+ + + + New College Florida +
+ + 5800 Bay Shore Rd. + Sarasota, FL + 34243 + USA + + mlepinski@ncf.edu +
+ + + + + + + + This document defines a "manifest" for use in the Resource Public + Key Infrastructure (RPKI). A manifest is a signed object (file) + that contains a listing of all the signed objects (files) in the + repository publication point (directory) associated with an + authority responsible for publishing in the repository. For each + certificate, Certificate Revocation List (CRL), or other type of + signed objects issued by the authority that are published at this + repository publication point, the manifest contains both the name + of the file containing the object and a hash of the file content. + Manifests are intended to enable a relying party (RP) to detect + certain forms of attacks against a repository. Specifically, if + an RP checks a manifest's contents against the signed objects + retrieved from a repository publication point, then the RP can + detect "stale" (valid) data and deletion of signed objects. + + + + + + + + +
+ + + The Resource Public Key Infrastructure (RPKI) makes use of a distributed repository system + to make available a variety of objects + needed by relying parties (RPs). Because all of the objects + stored in the repository system are digitally signed by the + entities that created them, attacks that modify these published + objects are detectable by RPs. However, digital signatures + provide no protection against attacks that substitute "stale" + versions of signed objects (i.e., objects that were valid and have + not expired, but have since been superseded) or attacks that + remove an object that should be present in the repository. To + assist in the detection of such attacks, the RPKI repository + system can make use of a signed object called a "manifest". + + + + A manifest is a signed object that enumerates all the signed + objects (files) in the repository publication point (directory) + that are associated with an authority responsible for publishing + at that publication point. Each manifest contains both the name + of the file containing the object and a hash of the file content, + for every signed object issued by an authority that is published + at the authority's repository publication point. A manifest is + intended to allow an RP to detect unauthorized object removal or + the substitution of stale versions of objects at a publication + point. A manifest also is intended to allow an RP to detect + similar outcomes that may result from a man-in-the-middle attack + on the retrieval of objects from the repository. Manifests are + intended to be used in Certification Authority (CA) publication + points in repositories (directories containing files that are + subordinate certificates and Certificate Revocation Lists (CRLs) + issued by this CA and other signed objects that are verified by + end-entity (EE) certificates issued by this CA). + + + + Manifests are modeled on CRLs, as the issues involved in detecting + stale manifests and potential attacks using manifest replays, + etc., are similar to those for CRLs. The syntax of the manifest + payload differs from CRLs, since RPKI repositories contain objects + not covered by CRLs, e.g., digitally signed objects, such as Route + Origination Authorizations (ROAs). + + +
+ + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", + "MAY", and "OPTIONAL" in this document are to be interpreted as + described in BCP 14 when, and only when, they appear in all + capitals, as shown here. + + +
+ +
+ +
+ + + A manifest associated with a CA's repository publication point + contains a list of: + + + + + + + the set of (non-expired, non-revoked) certificates issued and + published by this CA, + + + + the most recent CRL issued by this CA, and + + + + all published signed objects that are verifiable using EE + certificates issued by this CA. + + + + + + + + Every RPKI signed object includes, in the Cryptographic Message + Syntax (CMS) wrapper of the object, the + EE certificate used to verify it . Thus, + there is no requirement to separately publish that EE certificate + at the CA's repository publication point. + + + + Where multiple CA instances share a common publication point, as + can occur when an entity performs a key-rollover operation , the repository publication point will contain + multiple manifests. In this case, each manifest describes only + the collection of published products of its associated CA + instance. + + +
+ +
+ + + A CA's manifest is verified using an EE certificate. The + SubjectInfoAccess (SIA) field of this EE certificate contains the + access method OID of id-ad-signedObject. + + + + The CA MAY choose to sign only one manifest with each generated + private key, and generate a new key pair for each new version of + the manifest. This form of use of the associated EE certificate + is termed a "one-time-use" EE certificate. + + + + Alternatively, the CA MAY elect to use the same private key to + sign a sequence of manifests. Because only a single manifest + (issued under a single CA instance) is current at any point in + time, the associated EE certificate is used to verify only a + single object at a time. As long as the sequence of objects + verified by this EE certificate are published using the same file + name, then this sequential, multiple use of the EE certificate is + also valid. This form of use of an EE certificate is termed a + "sequential-use" EE certificate. + + +
+ +
+ + + A manifest is an RPKI signed object, as specified in . The RPKI signed object template requires + specification of the following data elements in the context of the + manifest structure. + + +
+ + + The eContentType for a manifest is defined as id-ct-rpkiManifest + and has the numerical value of 1.2.840.113549.1.9.16.1.26. + + +
+ + + +
+
+ +
+ + + The content of a manifest is ASN.1 encoded using the + Distinguished Encoding Rules (DER) . The + content of a manifest is defined as follows: + + +
+ + + +
+ +
+ + + The manifestNumber, thisUpdate, and nextUpdate fields are + modeled after the corresponding fields in X.509 CRLs (see + ). Analogous to CRLs, a manifest is + nominally current until the time specified in nextUpdate or + until a manifest is issued with a greater manifest number, + whichever comes first. + + + + If a "one-time-use" EE certificate is employed to verify a + manifest, the EE certificate MUST have a validity period that + coincides with the interval from thisUpdate to nextUpdate, to + prevent needless growth of the CA's CRL. + + + + If a "sequential-use" EE certificate is employed to verify a + manifest, the EE certificate's validity period needs to be no + shorter than the nextUpdate time of the current manifest. + The extended validity time raises the possibility of a + substitution attack using a stale manifest, as described in + . + + + + The data elements of the manifest structure are defined as + follows: + + + + + + + The version number of this version of the manifest + specification MUST be 0. + + + + This field is an integer that is incremented each time a + new manifest is issued for a given publication point. + This field allows an RP to detect gaps in a sequence of + published manifests. + + As the manifest is modeled on the CRL specification, the + ManifestNumber is analogous to the CRLNumber, and the + guidance in for CRLNumber values + is appropriate as to the range of number values that can + be used for the manifestNumber. Manifest numbers can be + expected to contain long integers. Manifest verifiers + MUST be able to handle number values up to 20 octets. + Conforming manifest issuers MUST NOT use number values + longer than 20 octets. + + + + This field contains the time when the manifest was + created. This field has the same format constraints as + specified in for the CRL field of + the same name. + + + + + This field contains the time at which the next scheduled + manifest will be issued. The value of nextUpdate MUST be + later than the value of thisUpdate. The specification of + the GeneralizedTime value is the same as required for the + thisUpdate field. + + If the authority alters any of the items that it has + published in the repository publication point, then the + authority MUST issue a new manifest before the nextUpdate + time. If a manifest encompasses a CRL, the nextUpdate + field of the manifest MUST match that of the CRL's + nextUpdate field, as the manifest will be re-issued when a + new CRL is published. If a "one-time-use" EE certificate + is used to verify the manifest, then when a new manifest + is issued before the time specified in nextUpdate of the + current manifest, the CA MUST also issue a new CRL that + includes the EE certificate corresponding to the old + manifest. + + + + This field contains the OID of the hash algorithm used to + hash the files that the authority has placed into the + repository. The hash algorithm used MUST conform to the + RPKI Algorithms and Key Size Profile specification . + + + + + This field is a sequence of FileAndHash objects. There is + one FileAndHash entry for each currently valid signed + object that has been published by the authority (at this + publication point). Each FileAndHash is an ordered pair + consisting of the name of the file in the repository + publication point (directory) that contains the object in + question and a hash of the file's contents. + + + + +
+
+ +
+ + + The mandatory content-type attribute MUST have its attrValues + field set to the same OID as eContentType. This OID is + id-ct-rpkiManifest and has the numerical value of + 1.2.840.113549.1.9.16.1.26. + + +
+ +
+ + + To determine whether a manifest is valid, the RP MUST perform + the following checks in addition to those specified in : + + + + + + + The eContentType in the EncapsulatedContentInfo is + id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). + + + + The version of the rpkiManifest is 0. + + + + In the rpkiManifest, thisUpdate precedes nextUpdate. + + + + + + + + If the above procedure indicates that the manifest is invalid, + then the manifest MUST be discarded and treated as though no + manifest were present. + + +
+ +
+ + +
+ +
+ + + For a CA publication point in the RPKI repository system, a CA + MUST perform the following steps to generate a manifest: + + + + + + + If no key pair exists, or if using a "one-time-use" EE + certificate with a new key pair, generate a key pair. + + + + If using a "one-time-use" EE certificate, or if a key pair + was generated in step 1, or if using a "sequential-use" EE + certificate that will expire before the intended nextUpdate + time of this manifest, issue an EE certificate for this key + pair. This EE certificate MUST have + an SIA extension access description field with an + accessMethod OID value of id-ad-signedobject, where the + associated accessLocation references the publication point + of the manifest as an object URL. + + This EE certificate MUST describe its Internet Number + Resources (INRs) using the "inherit" attribute, rather than + explicit description of a resource set (see ). + + In the case of a "one-time-use" EE certificate, the validity + times of the EE certificate MUST exactly match the + thisUpdate and nextUpdate times of the manifest. + + In the case of a "sequential-use" EE certificate, the + validity times of the EE certificate MUST encompass the time + interval from thisUpdate to nextUpdate. + + + + The EE certificate MUST NOT be published in the authority's + repository publication point. + + + + Construct the manifest content. The + manifest content is described in . The manifest's fileList includes the + file name and hash pair for each object issued by this CA + that has been published at this repository publication point + (directory). The collection of objects to be included in + the manifest includes all certificates issued by this CA + that are published at the CA's repository publication point, + the most recent CRL issued by the CA, and all objects + verified by EE certificates that were issued by this CA that + are published at this repository publication point. + + Note that the manifest does not include a self reference + (i.e., its own file name and hash), since it would be + impossible to compute the hash of the manifest itself prior + to it being signed. + + + + Encapsulate the manifest content using the CMS SignedData + content type (as specified ), sign + the manifest using the private key corresponding to the + subject key contained in the EE certificate, and publish the + manifest in the repository system publication point that is + described by the manifest. + + + + In the case of a key pair that is to be used only once, in + conjunction with a "one-time-use" EE certificate, the + private key associated with this key pair MUST now be + destroyed. + + + + + +
+ +
+ + + A new manifest MUST be issued and published on or before the + nextUpdate time. + + + + An authority MUST issue a new manifest in conjunction with the + finalization of changes made to objects in the publication + point. An authority MAY perform a number of object operations + on a publication repository within the scope of a repository + change before issuing a single manifest that covers all the + operations within the scope of this change. Repository + operators SHOULD implement some form of repository update + procedure that mitigates, to the extent possible, the risk that + RPs that are performing retrieval operations on the repository + are exposed to inconsistent, transient, intermediate states + during updates to the repository publication point (directory) + and the associated manifest. + + + + Since the manifest object URL is included in the SIA of issued + certificates, a new manifest MUST NOT invalidate the manifest + object URL of previously issued certificates. This implies that + the manifest's publication name in the repository, in the form + of an object URL, is unchanged across manifest generation + cycles. + + + + When a CA entity is performing a key rollover, the entity MAY + choose to have two CA instances simultaneously publishing into + the same repository publication point. In this case, there will + be one manifest associated with each active CA instance that is + publishing into the common repository publication point + (directory). + + +
+ +
+ +
+ + + Each RP must determine which signed objects it will use for + validating assertions about INRs and their use (e.g., which ROAs + to use in the construction of route filters). As noted earlier, + manifests are designed to allow an RP to detect manipulation of + repository data, errors by a CA or repository manager, and/or + active attacks on the communication channel between an RP and a + repository. Unless all of the files enumerated in a manifest can + be obtained by an RP during a fetch operation, the fetch is + considered to have failed and the RP MUST retry the fetch later. + + + + suggests (but does not mandate) that the + RPKI model employ fetches that are incremental, e.g., an RP + transfers files from a publication point only if they are + new/changed since the previous, successful, fetch represented in + the RP's local cache. This document avoids language that relies on + details of the underlying file transfer mechanism employed by an + RP and a publication point to effect this operation. Thus the term + "fetch" refers to an operation that attempts to acquire the full + set of files at a publication point, consistent with the + id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see + below). + + + + If a fetch fails, it is assumed that a subsequent fetch will + resolve problems encountered during the fetch. Until such time as + a successful fetch is executed, an RP SHOULD use cached data from + a previous, successful fetch. This response is intended to prevent + an RP from misinterpreting data associated with a publication + point, and thus possibly treating invalid routes as valid, or vice + versa. + + + + The processing described below is designed to cause all RPs with + access to the same local cache and RPKI repository data to achieve + the same results with regard to validation of RPKI data. However, + in operation, different RPs will access repositories at different + times, and some RPs may experience local cache failures, so there + is no guarantee that all RPs will achieve the same results with + regard to validation of RPKI data. + + + + Note that there is a "chicken and egg" relationship between the + manifest and the CRL for a given CA instance. If the EE + certificate for the current manifest is revoked, i.e., it appears + in the current CRL, then the CA or publication point manager has + made a serious error. In this case the fetch has failed; proceed + to . Similarly, if the CRL is not listed + on a valid, current manifest, acquired during a fetch, the fetch + has failed; proceed to , because the CRL + is considered missing. + + + + Note that if a CA and its associated publication point are + operating properly, there will always be exactly one manifest and + one associated CRL at the publication point identified in the CA's + SIA (see below). + + +
+ + + For a given publication point, an RP MUST perform a series of + tests to determine which signed object files at the publication + point are acceptable. The tests described below ( to ) are to + be performed using the manifest identified by the + id-ad-rpkiManifest URI extracted from a CA certificate's + SIA. All of the files referenced by the manifest MUST be be + located at the publication point specified by the + id-ad-caRepository URI from the (same) CA certificate's SIA. The + manifest and the files it references MUST reside at the same + publication point. If an RP encounters any files that appear on + a manifest but do not reside at the same publication point as + the manifest the RP MUST treat the fetch as failed, and a + warning MUST be issued (see below). + + + + A manifest SHOULD contain exactly one CRL (.crl) file and it + MUST be at the location specified in the CRLDP in the manifest's + EE certificate. If more than one .crl file appears in the + manifest, the fetch has failed and the RP MUST proceed to ; otherwise proceed to . + + + + Note that, during CA key rollover , + signed objects for two or more different CA instances will + appear at the same publication point. Manifest processing is to + be performed separately for each CA instance, guided by the SIA + id-ad-rpkiManifest URI in each CA certificate. + +
+ +
+ + + The RP MUST fetch the manifest identified by the SIA + id-ad-rpkiManifest URI in the CA certificate. If an RP cannot + retrieve a manifest using this URI, or if the manifest is not + valid (), an RP MUST treat this as a + failed fetch and, proceed to ; + otherwise proceed to . + +
+ +
+ + + The RP MUST check that the current time (translated to UTC) is + between thisUpdate and nextUpdate. If the current time lies + within this interval, proceed to . If + the current time is earlier than thisUpdate, the CA has made an + error; this is a failed fetch and the RP MUST proceed to . If the current time is later than + nextUpdate, then the manifest is stale; this is a failed fetch + and RP MUST proceed to ; otherwise + proceed to . + +
+ +
+ + + The RP MUST acquire all of the files enumerated in the manifest + (fileList) from the publication point. This includes the CRL, + each object containing an EE certificate issued by the CA, and + any subordinate CA and EE certificates. If there are files + listed in the manifest that cannot be retrieved from the + publication point, or if they fail the validity tests specified + in , the fetch has failed and the RP + MUST proceed to ; otherwise, proceed to + . + +
+ +
+ + + The RP MUST verify that the hash value of each file listed in + the manifest matches the value obtained by hashing the file + acquired from the publication point. If the computed hash value + of a file listed on the manifest does not match the hash value + contained in the manifest, then the fetch has failed and the RP + MUST proceed to ; otherwise proceed to + . + +
+ +
+ + + If a current manifest contains entries for objects that are not + within the scope of the manifest (), + the fetch has failed and the RP SHOULD proceed to ; otherwise the fetch is deemed successful + and the RP will process the fetched objects. + +
+ +
+ + + If an RP does not acquire a current valid manifest, or does not + acquire current valid instances of all of the objects enumerated + in a current valid manifest as a result of a fetch, then + processing of the signed objects associated with the CA instance + has failed for this fetch cycle. The RP MUST issue a warning + indicating the reason(s) for termination of processing with + regard to this CA instance. It is RECOMMENDED that a human + operator be notified of this warning. + + + + Termination of processing means that the RP SHOULD continue to + use cached versions of the objects associated with this CA + instance, until such time as they become stale or they can be + replaced by objects from a successful fetch. This implies that + the RP MUST not try to acquire and validate subordinate signed + objects, e.g., subordinate CA certificates, until the next + interval when the RP is scheduled to fetch and process data for + this CA instance. + +
+ +
+ +
+ + + The RPKI publication system model requires that every publication + point be associated with one or more CAs, and be non-empty. Upon + creation of the publication point associated with a CA, the CA + MUST create and publish a manifest as well as a CRL. A CA's + manifest will always contain at least one entry, namely, the CRL + issued by the CA upon repository creation . + + + + Every published signed object in the RPKI + is published in the repository publication point of the CA that + issued the EE certificate, and is listed in the manifest + associated with that CA certificate. + + +
+ +
+ + + Manifests provide an additional level of protection for RPKI RPs. + Manifests can assist an RP to determine if a repository object has + been deleted, occluded, or otherwise removed from view, or if a + publication of a newer version of an object has been suppressed + (and an older version of the object has been substituted). + + + + Manifests cannot repair the effects of such forms of corruption of + repository retrieval operations. However, a manifest enables an + RP to determine if a locally maintained copy of a repository is a + complete and up-to-date copy, even when the repository retrieval + operation is conducted over an insecure channel. In cases where + the manifest and the retrieved repository contents differ, the + manifest can assist in determining which repository objects form + the difference set in terms of missing, extraneous, or superseded + objects. + + + + The signing structure of a manifest and the use of the nextUpdate + value allows an RP to determine if the manifest itself is the + subject of attempted alteration. The requirement for every + repository publication point to contain at least one manifest + allows an RP to determine if the manifest itself has been occluded + from view. Such attacks against the manifest are detectable + within the time frame of the regular schedule of manifest updates. + Forms of replay attack within finer-grained time frames are not + necessarily detectable by the manifest structure. + + +
+ +
+ + + As created and populated the registries + "RPKI Signed Object" and three-letter filename extensions for + "RPKI Repository Name Schemes," no new action is requested of the + IANA. + + + + +
+ +
+ + + The authors would like to acknowledge the contributions from + George Michelson and Randy Bush in the preparation of the manifest + specification. Additionally, the authors would like to thank Mark + Reynolds and Christopher Small for assistance in clarifying + manifest validation and RP behavior. The authors also wish to + thank Job Snijders, Oleg Muravskiy, and Sean Turner for their + helpful review of this document. + + +
+ + + + + + + + + + + + + + + + ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER) + + International International Telephone and Telegraph Consultative Committee + + + + + + + + + + + + + + + +
+ +
+ + + +
+
+ + + +