RFC 9255

The 'I' in RPKI Does Not Stand for Identity

📅 published June 2022, from ietf

The 'I' in RPKI Does Not Stand for Identity 🦋

Okay bestie, here's the tea ☕ This is RFC 9255, a Standards Track doc from the IETF (Internet Engineering Task Force), published June 2022 🌸. The authors are R. Bush (Arrcus & IIJ Research) and R. Housley (Vigil Security) 🎀. It's ISSN 2070-1721, and the header doesn't list anything it obsoletes or updates ✨.

Abstract ✨

Okay so there's this super common myth 🙈 that Internet Number Resources (INRs) in the RPKI can be linked to the real-world identity of the 'holder' of an INR. This doc says nope: RPKI does not associate to the INR holder 💅.

Status of This Memo 📜

This is an Internet Standards Track document, no cap 🔥.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check Section 2 of RFC 7841 💜.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9255 🦋.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 💅.

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
2.  The RPKI is for Authorization
3.  Discussion
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌈

Okay, so the Resource Public Key Infrastructure (RPKI), see [RFC6480], is the thing that "represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers," which together are called Internet Number Resources (INRs) 🍓. Since it first rolled out, the RPKI has grown to cover other similar resource and routing data too, e.g., Router Keying for BGPsec [RFC8635] ✨.

Security-wise, the word "Public Key" implies there's also a matching private key [RFC5280] 🔐. The RPKI gives strong authority to whoever currently holds the INRs 👑. But some people want to use RPKI private keys to sign arbitrary documents as the INR 'holder' of those resources, expecting that the signature will count as an attestation to the authenticity of the document content 🙈. That expectation is inappropriate. The RPKI certificate is only an authorization to speak for the explicitly identified INRs. It is explicitly not meant for authenticating the 'holders' of the INRs 💅. Section 2.1 of [RFC6480] really emphasizes this situation.

Here's a spicy example 🌶️. Someone suggested you could authenticate real-world business deals with the signatures of INR holders. Say Bill's Bait and Sushi (BB&S) used the private key that proves they hold their AS in the RPKI to sign a Letter of Authorization (LOA) letting some other party rack and stack hardware owned by BB&S. Unfortunately, even if that's technically possible, it's neither appropriate nor meaningful 😭.

The 'I' in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not "Identity" 🎀. In fact, the RPKI doesn't provide any association between INRs and the real-world holder(s) of those INRs. The RPKI provides authorization to make assertions only about Internet Number Resources, like IP prefixes or AS numbers, plus data such as Autonomous System Provider Authorization (ASPA) records [ASPA-PROFILE] ✨.

Bottom line: avoid the urge to use RPKI certificates for anything other than verifying authorizations tied to the delegation of INRs, or attestations related to INRs 🫶. Instead, remember that these authorizations and attestations happen no matter who the RPKI private key holder is 🦋.

1.1. Requirements Language 💜

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📜.

2. The RPKI is for Authorization 💖

The RPKI was designed and specified to sign certificates for use within the RPKI itself, and to generate Route Origin Authorizations (ROAs) [RFC6480] for use in routing 🛣️. Its design deliberately ruled out attesting to real-world identity because, among other issues, that would expose the Certification Authority (CA) to liability 😬.

And honestly? The RPKI not authenticating real-world identity is by design 💅. If it tried to, then besides the liability, it would end up in a world of complexity with no proof of termination 💀.

Registries like the Regional Internet Registries (RIRs) do map INRs to real-world identity through WHOIS [RFC3912] and similar services 🧚. They claim to be authoritative, at least for the INRs they allocate 👑.

So, RPKI-based credentials of INRs MUST NOT be used to authenticate real-world documents or transactions 🚫. That might be done with some formal external authentication of authority, which lets an otherwise anonymous INR holder authenticate the particular document or transaction. With that kind of external, i.e. non-RPKI, verification of authority, using RPKI-based credentials adds no authenticity 🙃.

3. Discussion 🎀

Section 2.1 of the RPKI base document [RFC6480] says it outright: "An important property of this PKI is that certificates do not attest to the identity of the subject." 💅

Section 3.1 of "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)" [RFC7382] says the Subject name in each certificate SHOULD NOT be meaningful, and then explains this at some length 🤓.

Normally, the INR holder doesn't hold the private key that attests to their resources. The CA does 🏦. The INR holder has a real-world business relationship with the CA, and they've likely signed real-world documents for it 📜.

Since the INR holder doesn't have the keying material, they rely on the CA to manipulate their INRs. They presumably present credentials to the CA to do that. These could be a user ID and password (with two-factor authentication, one hopes 🙏), a hardware token, client browser certificates, etc. 🔑

So schemes like Resource Tagged Attestations [RPKI-RTA] and Signed Checklists [RPKI-RSC] must go to great lengths to extract the supposedly relevant keys from the CA 😩.

Take Bill's Bait and Sushi's Autonomous System (AS) number. Someone out on the net probably has the credentials to the CA account where BB&S's INRs are registered 👀. That could be the owner of BB&S, Randy's Taco Stand, an IT vendor, or the Government of Elbonia. One simply can not know 🤷.

In large organizations, INR management is often compartmentalized, with no authority over anything beyond INR registration 🏢. The INR manager for Bill's Bait and Sushi is unlikely to be authorized to conduct bank transactions for BB&S, or even to authorize access to BB&S's servers in some colocation facility 💀.

Then there's the timing issue ⏳. The holder of that AS may be BB&S today when some document gets signed, and the Government of Elbonia tomorrow. Or the resource could have been administratively moved from one CA to another, which likely requires a change of keys. If so, how does anyone figure out whether the signature on the real-world document is still valid? 🤔

Ghostbuster Records [RFC6493] may seem to identify real-world entities, but their semantic content is completely arbitrary and doesn't attest to holding any INRs 🙅. They're just clues for operational support contacts when there are technical RPKI problems 📞.

Usually, before registering INRs, CAs require proof of an INR holding through external documentation and authorities 📑. It's kind of wild that the CPS Template [RFC7382] doesn't mention any diligence the CA must, or even might, do to make sure the INRs are actually owned by a registrant 😭.

Also, someone who can provide 'proof of possession' of the private key signing over a particular INR shouldn't be taken to be a valid legal representative of the organization that holds that INR. They could just be in an INR administrative role and not be a formal representative of the organization 🙈.

Last but not least, Autonomous System Numbers don't identify real-world entities 🚫. They're identifiers that some network operators 'own', and they're only used for loop detection in routing. They have no inherent semantics other than uniqueness ✨.

6.1. Normative References 📚

okay so these are the must-read docs the spec leans on, bestie 💅 every one of these is load-bearing, so if you skip one you're missing context 🫶

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[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, May 2008,
           <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,
           February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC7382]  Kent, S., Kong, D., and K. Seo, "Template for a
           Certification Practice Statement (CPS) for the Resource
           PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382,
           April 2015, <https://www.rfc-editor.org/info/rfc7382>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8635]  Bush, R., Turner, S., and K. Patel, "Router Keying for
           BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019,
           <https://www.rfc-editor.org/info/rfc8635>.

6.2. Informative References 🌸

these ones are the extra reading, the "ooh tell me more" section ✨ not required to get the core idea, but they're so worth a peek 👀

[ASPA-PROFILE]
           Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J.,
           and R. Housley, "A Profile for Autonomous System Provider
           Authorization", Work in Progress, Internet-Draft, draft-
           ietf-sidrops-aspa-profile-07, 31 January 2022,
           <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
           aspa-profile-07>.

[RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
           DOI 10.17487/RFC3912, September 2004,
           <https://www.rfc-editor.org/info/rfc3912>.

[RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
           Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
           February 2012, <https://www.rfc-editor.org/info/rfc6493>.

[RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "A profile
           for Resource Public Key Infrastructure (RPKI) Signed
           Checklists (RSC)", Work in Progress, Internet-Draft,
           draft-ietf-sidrops-rpki-rsc-08, 26 May 2022,
           <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
           rpki-rsc-08>.

[RPKI-RTA] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,
           and M. Hoffmann, "A profile for Resource Tagged
           Attestations (RTAs)", Work in Progress, Internet-Draft,
           draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
           <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
           rpki-rta-00>.

Acknowledgments 🫶

the authors wanna give a huge shoutout to George Michaelson and Job Snijders for the lively discussions 🗣️✨ Geoff Huston for the more formal text 🎀 Ties de Kock for the useful suggestions 💡 and the many directorate and IESG reviewers 👑 and last but definitely not least, Biff, for lending Bill's Bait and Sushi 🍣💀

Authors' Addresses 💌

Randy Bush
Arrcus & Internet Initiative Japan Research
5147 Crystal Springs
Bainbridge Island, WA 98110
United States of America
Email: randy@psg.com


Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
United States of America
Email: housley@vigilsec.com
📦 where this page comes from