Internet-Draft RPKI Manifest Number Handling October 2024
Harrison, et al. Expires 11 April 2025 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-ietf-sidrops-manifest-numbers-02
Updates:
RFC9286 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Harrison
APNIC
G. Michaelson
APNIC
J. Snijders
Fastly

RPKI Manifest Number Handling

Abstract

The Resource Public Key Infrastructure (RPKI) makes use of signed objects called manifests. A manifest lists each file that a publisher intends to include within an RPKI repository, and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest. However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value. This document specifies publisher and RP behaviour for this scenario.

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 https://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 11 April 2025.

Table of Contents

1. Introduction

The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of signed objects [RFC6488] called manifests [RFC9286]. A manifest lists each file that a publisher intends to include within an RPKI repository [RFC6481], and can be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which the publisher must increment whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly-retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously-validated manifest (see Section 4.2.1 of [RFC9286]).

However, the manifestNumber field is 20 octets in length (i.e. not unbounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value (2^159-1), which means that a publisher can no longer make use of a given CA certificate when that value is reached. (For the purposes of [RFC9286], a "CA" is represented by a CA certificate with a stable location and a stable private key. Reissuing a CA certificate with changed resources or a changed expiry date does not change the identity of the CA such that the stored manifestNumber for the CA is reset, for example.)

While it is practically impossible for a publisher to reach the largest possible value under normal operating conditions (it would require that the publisher issue one manifest per second for 23,171,956,451,847,141,650,870 quintillion years), there is a chance that it could be reached due to bugs in the issuance or publication systems or incorrect/inadvertent use of those systems. For example:

These scenarios might also arise in combination and be more severe as a result: for example, a large manifest number increment bug in conjunction with a manifest reissuance loop problem.

For a subordinate CA, the risk of repository invalidation due to this problem can be addressed by the publisher simply using the key rollover process ([RFC6489]) to get a new CA certificate. RPs will treat this new certificate as though it represents a distinct CA, and the manifestNumber can be reset at that point.

However, this option is not available for RPKI Trust Anchors (TAs). If a TA publishes a manifest with the largest-possible manifestNumber value, then it is not possible to make use of the TA after that point, because the certificate location (stored in the associated Trust Anchor Locator (TAL) [RFC8630]) and its private key cannot be changed. Issuing a new TA and distributing the associated TAL to clients would involve a large amount of work for TA operators and RPs, and there would be a limited degree of RPKI protection by way of that TA for the time between the issuance of the problematic manifest and the installation of the new TAL for a given client.

In order to avoid these problems, this document defines how publishers and RPs can handle this scenario in order to facilitate ongoing use of an affected repository.

1.1. Requirements Language

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 [RFC2119] [RFC8174].

2. Manifest Number Handling

For a given CA, an RP MUST NOT reject a new manifest issued by that CA on the basis of it not having a higher manifestNumber than a previously-validated manifest if the new manifest has a different filename from that of the previously-validated manifest. In other words, an RP MUST reset its stored manifestNumber for a given CA if the CA changes the filename of its manifest.

With this behaviour, it is possible for a CA to be configured such that any time it issues a new manifest, it uses a new filename for that manifest. If a CA were configured in this way, the manifestNumber validation set out in Section 4.2.1 of [RFC9286] would have no purpose. To avoid this outcome, CAs SHOULD NOT use new filenames for manifests except in situations where it is necessary to ensure the ongoing validity of the CA or its repository. Similarly, RP software SHOULD alert its operators when a manifest filename changes for a given CA.

To avoid certain forms of replay attack, the RP MUST verify that the URI in the accessLocation in one of the id-ad-signedObject accessMethods in the manifest's Subject Information Access (SIA) extension exactly matches the URI presented in the RPKI Repository Delta Protocol (RRDP) [RFC8182] "publish" element or the path presented by remote rsync servers.

Section 2.2 of [RFC6481] contains non-normative guidance for the naming of manifest files in repositories. While a CA that supports the behaviour described in this section cannot preserve the exact filename suggested by that text (per Section 2.1 of [RFC4387]), the CA SHOULD still ensure that the filename is a value derived from the public key of the CA, per the more general guidance in that section.

A CA specifies its manifest URI by way of an SIA entry with an accessMethod of id-ad-rpkiManifest ([RFC6487]). For the purposes of this document, the manifest filename is the final segment of the path of the accessLocation URI from that SIA entry.

Section 4.8.8.1 of [RFC6487] states that a CA may include in its certificate multiple id-ad-rpkiManifest SIA entries. For comparisons, the RP may use the filename from any one of the id-ad-rpkiManifest SIA entries in the previously-validated CA certificate. If that filename does not appear in any of the id-ad-rpkiManifest SIA entries in the CA certificate that is currently being validated, then the manifest filename has changed, for the purposes of this section. The corollary of this behaviour is that a CA that includes multiple id-ad-rpkiManifest SIA entries in its certificate and wants to rely on the behaviour defined in this document MUST ensure that none of the manifest filenames in the previous CA certificate appear in the newly-issued CA certificate.

Note that the approach set out in this section is different from that described in Section 3.2.1 of [RFC8488].

3. General Repository Handling

The previous section contains a specific update for the handling of manifest numbers, in order to address one potential permanent invalidity scenario. RPs that encounter other permanent invalidity scenarios SHOULD also consider how those can be addressed such that the scenario does not require the relevant CA or TA to perform a key rollover operation. For example, in the event that an RP recognises that a permanent invalidity scenario has occurred, the RP could alert the operator and provide an option to the operator to stop relying on cached data for the affected repository, so that the CA can rectify the problem.

4. Operational Considerations

CA software may opt to support the manifest number reset functionality in various ways. For example, it could change the manifest filename when the manifestNumber reaches a certain threshold, or it could alert the operator in this scenario and request confirmation that the filename should be changed.

5. IANA Considerations

This document has no actions for IANA.

6. Implementation status

This section is to be removed before publishing as an RFC.

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

7. Acknowledgements

The authors would like to thank Theo Buehler, Ben Maddison, Rob Austein, Tim Bruijnzeels, and Russ Housley for their review and feedback on this document.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4387]
Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, , <https://www.rfc-editor.org/info/rfc4387>.
[RFC6487]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, , <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488]
Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, , <https://www.rfc-editor.org/info/rfc6488>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8182]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, , <https://www.rfc-editor.org/info/rfc8182>.
[RFC9286]
Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, , <https://www.rfc-editor.org/info/rfc9286>.

8.2. Informative References

[I-D.ietf-sidrops-rpki-crl-numbers]
Snijders, J., Maddison, B., and T. Buehler, "Relying Party Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-crl-numbers-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-crl-numbers-00>.
[RFC1982]
Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, , <https://www.rfc-editor.org/info/rfc1982>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC6480]
Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <https://www.rfc-editor.org/info/rfc6480>.
[RFC6481]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, , <https://www.rfc-editor.org/info/rfc6481>.
[RFC6489]
Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, , <https://www.rfc-editor.org/info/rfc6489>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC8488]
Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation", RFC 8488, DOI 10.17487/RFC8488, , <https://www.rfc-editor.org/info/rfc8488>.
[RFC8630]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, , <https://www.rfc-editor.org/info/rfc8630>.
[rpki-client]
OpenBSD Project, "rpki-client", , <https://www.rpki-client.org/>.

Appendix A. Serial Number Arithmetic

Serial number arithmetic [RFC1982] is an approach that has been used in the DNS context (among others) to permit the indefinite use of a finite number space. At least in theory, it would be possible to use a similar approach with the manifestNumber field as well.

However, unlike the corresponding DNS context with Start of Authority (SOA) resource records, an RPKI CA does not have visibility into or control over RPKI RPs generally. This means that it is not possible to select an updated manifestNumber value or to manage the relevant state transitions so as to guarantee that all RPs will have valid state at the end of the process. The approach proposed in Section 2 does not have this problem.

Appendix B. Manifest thisUpdate

The thisUpdate field in the manifest object is of type GeneralizedTime, defined in Section 4.1.2.5.2 of [RFC5280]. This type has a maximum value of 99991231235959Z (i.e. 31 December 9999 23:59:59 GMT). Section 4.2.1 of [RFC9286] requires that "[e]ach RP MUST verify that this field value is greater (more recent) than the most recent manifest it has validated", so it would appear to be subject to the same problem as for manifest numbers. However, during validation, if the RP detects that the current time is not between the manifest thisUpdate and nextUpdate values, the RP must treat the fetch as a failed fetch. Therefore, the RP will not cache a manifest with a current date far in the future, and the CA can rectify the problem here by reissuing the relevant manifest with the correct date.

Appendix C. Certificate Revocation List Numbers

Certificate Revocation Lists (CRLs) [RFC5280] are published by RPKI CAs so that RPs can determine the set of certificates that has been revoked by the CA. CRLs contain a cRLNumber field, which is similar to the manifestNumber field in manifests. In particular, cRLNumber values are limited to 20 octets in length, and the resource certificate profile for RPKI [RFC6487] states that "[w]here two or more CRLs are issued by the same CA, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by this CA". As a result, this field raises repository invalidity issues similar to those from the manifest number. These problems are being addressed by way of [I-D.ietf-sidrops-rpki-crl-numbers].

Appendix D. Walkthrough of the rpki-client implementation

This section describes the [rpki-client] implementation with regard to handling manifest numbers. The process is composed of multiple stages:

  1. Fetching the manifests and acquiring referenced files
  2. Preprocessing of the manifests
  3. Selecting the first candidate manifest
  4. Matching file names and hashes
  5. Optionally selecting the second candidate manifest

D.1. Stage: Fetching the Manifests and Acquiring Referenced Files

The RP follows rpkiNotify or caRepository pointers in the SubjectInfoAccess extension of valid CA certificates to queue up synchronization tasks.

At the end of this stage the RP has zero, one, or two manifests for a given caRepository. Depending on the validation status, the RP stores files into two locations: DIR_VALID or DIR_TEMP. DIR_VALID contains objects which were found to be valid (current, not revoked, not expired) during the previous validation run, the DIR_TEMP location contains files retrieved via RRDP or rsync which have not yet been validated, or were rejected by the validation process.

If the remote publication point is unreachable on both RRDP and rsync, no purported "new" manifest file will be stored in DIR_TEMP. It is possible that the DIR_VALID location contains a locally cached version of the object from a previous validation run.

D.2. Stage: preprocessing of the manifests

Constructing the path and filename based on the rpkiManifest of the CA certificate, the RP attempts to open what purportedly are two version of the same .mft file in DIR_TEMP and DIR_VALID, respectively.

For brevity's sake, the version in DIR_TEMP is associated with a data structure named mft1, the version in DIR_VALID is associated with a data structure named mft2.

Assuming two files exist in the DIR_TEMP and DIR_VALID locations, both files are run through a series of checks. If any check fails, that file will be considered ineligible.

  1. Can the file be opened?
  2. Can the content of the file be decoded as DER?
  3. Can the DER-content be parsed as CMS ContentInfo?
  4. Is the CMS self-signage correct?
  5. Can exactly one CMS SignerInfo be extracted?
  6. Is the ContentInfo of the right version?
  7. Is the SignerInfo of the right version?
  8. Does the SignerInfo have the correct signed attributes?
  9. Does the SignerInfo have the correct digest and signature algorithms?
  10. Does the ContentInfo have the right type of embedded content?
  11. Does the eContentType match the Content-Type?
  12. Does the CMS contain zero CRLs?
  13. Can exactly one X.509 cert be extracted from the SignerInfo?
  14. Can the notBefore field be extracted from the X.509 cert?
  15. Can the notAfter field be extracted from the X.509 cert?
  16. Does the X.509 cert's SKI match the SignerInfo's SignerIdentifier?
  17. Can the AIA be extracted from the X.509 EE?
  18. Can the AKI be extracted from the X.509 EE?
  19. Can the SIA be extracted from the X.509 EE?
  20. Does the SIA Signed Object pathname match the pathname presented by the publication point?
  21. Can the SKI be extracted from the X.509 EE?
  22. Are the X509 EE's RFC 3779 extensions set to inherit?
  23. Can the eContent be parsed according to the ASN.1 formal syntax?
  24. Is the Manifest eContent of the right version?
  25. Can the manifestNumber be extracted?
  26. Is the CMS signing-time before the Manifest nextUpdate time?
  27. Is 'now' not before the Manifest thisUpdate?
  28. Is 'now' not after the Manifest nextUpdate?
  29. Is the Manifest nextUpdate not before the Manifest thisUpdate?
  30. Does a valid certification path from a TA to this EE cert exist?

Through the above checks, the mft1 and mft2 data structures are populated, or marked ineligible.

D.3. Stage: selecting the first candidate manifest

Assuming both mft1 and mft2 successfully passed through stage 2 (Appendix D.2), a comparison can be made between mft1 and mft2 to select the candidate mft for the next stage.

The RP checks whether the locally cached version mft2 (from DIR_VALID) is older in the sense that was issued earlier than mft1 (from DIR_TEMP) by comparing the Manifest thisUpdate timestamp, and has a smaller manifestNumber. If both conditions are true, the RP will select mft1 as candidate for stage stage 4 (Appendix D.4).

If there was some kind of issue with mft1(such as it being older than or has the same thisUpdate as mft2, or it having a manifestNumber which is lower than or equal to mft2), the RP proceeds with stage 5 (Appendix D.5).

D.4. Stage: matching file names and hashes for mft1

The RP will now verify the hash value of each file listed in manifest mft1 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 a failed fetch occurred and the RP proceeds to stage 5 (Appendix D.5).

If all the files and hashes matched, mft1 and its associated files are moved from DIR_TEMP to DIR_VALID. The manifest handling procedure now ends.

D.5. Optional Stage: matching file names and hashes for mft2

This stage is only reached if there was an issue with mft1.

The RP will now verify the hash value of each file listed in manifest mft2 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 caRepository is busted.

Authors' Addresses

Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
George G. Michaelson
Asia-Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Job Snijders
Fastly
Amsterdam
Netherlands