OpenBSD Journal

rpki-client 9.1 released

Contributed by rueda on from the key route announcement dept.

Sebastian Benoit (benno@) announced the release of version 9.1 of rpki-client, the essential component for routing security.

See the full announcement for further details.

Here are some key excerpts from the release announcement:

This release includes the following changes to the previous release:

- Impose same-origin policy for RRDP

  This addresses an oversight in the original RRDP specification
  (RFC8182) which allowed any publication server to cause load on
  another server by tricking RPs into making cross-origin requests.
  Imposing a same-origin policy in RRDP client/server communication
  isolates resources such as Delta and Snapshot files from different
  Repository Servers, reducing possible attack vectors.
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rrdp-same-origin

- Introduce tiebreaking for trust anchors

  Instead of always using newly-retrieved trust anchors, compare a
  fetched TA with one stored in the cache. Later notBefore and earlier
  notAfter are used to identify a trust anchor certificate as newer.
  This prevents certain forms of replay attack.
  https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-ta-tiebreaker

- Fix internal identification of CA resource certificates

  The rpki-client utility tracks CA certificates across privilege
  separation boundaries. The original design was to use the subject key
  identifier, which is problematic because the SKI is not guaranteed to
  be globally unique. On the one hand, operators could choose to reuse
  their keys for multiple CAs and on the other hand, publishing a CA
  cert in the RPKI requires no proof of possession: anyone can publish
  CA certificates with any public key they please.

- Verify self-signage for trust anchors

  In other PKIs, trust anchors come from a trusted source and contain
  little to no important information apart from the public key. Therefore,
  libcrypto's chain verifier does not check their signatures by default
  because this "doesn't add any security and just wastes time". None of
  this is true in the RPKI and therefore trust anchors need an extra
  verification step.

- Introduce a check for filenames as presented by publication points

  Filenames presented by publication points are unsigned data, they must
  match the location in the signed object's EE certificate SIA extension
  which is signed data. This prevents some forms of replay attack.
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-manifest-numbers

- Improved compliance with RFCs 6487 and 8209 for certificates and CRLs

  The issuer field of certificates and CRLs is checked to comply with
  section 4.4 of RFC 6487. Various aspects of URIs provided in SIA, AIA
  and CRL distribution points were improved. Criticality of key usage is
  now enforced and the extension is inspected for all certificate types.

- Presence of CMS signing-time is now enforced and presence of
  CMS binary-signing-time is disallowed, per RFC 9589.
  https://www.rfc-editor.org/rfc/rfc9589.html

- Lowered the maximum acceptable manifest number to 2^159 - 1, per
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-manifest-numbers

- Limit number of validated ASPAs per customer ASID, per
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile

- Ignore the CRL Number extension in CRLs, per
  https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-crl-numbers

- Various minor bug fixes and improvements in logging and error reporting

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]