Network Working Group R. Bush Internet-Draft Arrcus & Internet Initiative Japan Intended status: Standards Track R. Housley Expires: November 5, 2021 Vigil Security May 4, 2021 The I in RPKI does not stand for Identity draft-ietf-sidrops-rpki-has-no-identity-00 Abstract There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real world identity of the 'owner' of an INR. This document attempts to put that notion to rest. 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. 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 November 5, 2021. Copyright Notice Copyright (c) 2021 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 Bush & Housley Expires November 5, 2021 [Page 1] Internet-Draft The I in RPKI does not stand for Identity May 2021 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The Resource Public Key Infrastructure (RPKI), see [RFC6480], "represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers." Though since, it has grown to include other similar resource and routing data, e.g. Router Keying for BGPsec, [RFC8635]. In security terms the phrase "Public Key" implies there are also private keys, a la [RFC5280]. And, as the RPKI has strong authority over ownership of Internet Number Resources (INRs), there is a desire to use the private keys to sign arbitrary documents to attest that the 'owner' of those resources has attested to the authenticity of those documents. Instead, it is an authorization to speak for the named IP address blocks and AS numbers themselves, not their unidentifiable owners. There is a desire is to authenticate real world business transactions with the signatures of INR holders. E.g. for Bill's Bait and Sushi to use their AS in the RPKI to sign a Letter of Authorization (LOA) for some other party to rack and stack hardware owned by BB&S. Unfortunately, this is not formally feasible. The I in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not for "Identity". In fact, the RPKI does not provide any association between INRs and the real world Bush & Housley Expires November 5, 2021 [Page 2] Internet-Draft The I in RPKI does not stand for Identity May 2021 holder(s) of those INRs. The RPKI provides authorization to speak for the named IP address blocks and AS numbers. 2. The Bottom Line 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 intentionally precluded use for attesting to real world identity as, among other issues, it would expose the Certification Authority (CA) to liability. That the RPKI does not authenticate real world identity is a feature not a bug. If it tried to do so, aside from the liability, it would end in a world of complexity with no proof of termination, as X.400 learned. Registries such as the Regional Internet Resistries (RIRs) provide INR to real world identity mapping through whois and similar services. They claim to be authoritative, at least for for the INRs which they allocate. RPKI-based credentials of INRs MUST NOT be used to authenticate real world documents or transactions without some formal external authentication of the INR and the authority for the actually anonymous INR holder to authenticate the particular document or transaction. 3. Discussion Normally, the INR holder does not hold the private key attesting to their resources; the Certification Authority (CA) does. The INR holder has a real world business relationship with the CA for which they have likely signed real world documents. As the INR owner does not have the keying material, they rely on the CA, to which they presumably must present credentials, to manipulate their INRs. These credentials may be userid/password (with two factor authentication one hopes), a hardware token, client browser certificates, etc. Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the supposedly relevant keys from the CA. For some particular INR, say Bill's Bait and Sushi's Autonomous System (AS) number, someone out on the net probably has the credentials to the CA account in which BB&S's INRs are registered. Bush & Housley Expires November 5, 2021 [Page 3] Internet-Draft The I in RPKI does not stand for Identity May 2021 That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, or the Government of Elbonia. One simply can not know. In large operations, INR management is often compartmentalized with no authority over anything beyond dealing with 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 is the temporal issue. The owner of that AS may be BB&S today when some document was signed, and could be the Government of Elbonia tomorrow. Or the resource could have been administratively moved from one CA to another, likely requiring a change of keys. If so, how does one determine if the signature on the real world document is still valid? While Ghostbuster Records [RFC6493] may seem to identify real world entities, their semantic content is completely arbitrary, and does not attest to INR ownership. They are merely clues for operational support contact in case of technical RPKI problems. Usually, before registering INRs, CAs require proof of INR ownership via external documentation and authorities. It is somewhat droll that the CPS Template, [RFC7382], does not mention any diligence the CA must, or even might, conduct to assure the INRs are in fact owned by a registrant. Autonomous System Numbers do not identify real world entities. They are identifiers some network operators 'own' and are only used in loop detection in routing. They have no inherent semantics other than uniqueness. The RPKI base document, [RFC6480], Section 2.1 says explicitly "An important property of this PKI is that certificates do not attest to the identity of the subject." The Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear that "The Subject name in each certificate SHOULD NOT be meaningful;" and goes on to do so at some length. 4. Security Considerations Attempts to use RPKI data to authenticate real world documents or other artifacts requiring identity are invalid and misleading. When a document is signed with the private key associated with a RPKI certificate, the signer is speaking for the INRs, the IP address Bush & Housley Expires November 5, 2021 [Page 4] Internet-Draft The I in RPKI does not stand for Identity May 2021 space and Autonomous System (AS) numbers, in the certificate. This is not an identity; this is an authorization. In schemes such as [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the signed message further narrows this scope of INRs. The INRs in the message are a subset of the INRs in the certificate. If the signature is valid, the message content comes from a party that is authorized to speak for that subset of INRs. Control of INRs for an entity could be used to falsely authorize transactions or documents for which the INR manager has no authority. RPKI-based credentials of INRs MUST NOT be used to authenticate real world documents or transactions without some formal external authentication of the INR and the authority for the actually anonymous INR holder to authenticate the particular document or transaction. 5. IANA Considerations This document has no IANA Considerations. 6. Acknowledgments The authors thank George Michaelson and Job Snijders for lively discussion; and last but not least, Biff for the loan of Bill's Bait and Sushi. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . Bush & Housley Expires November 5, 2021 [Page 5] Internet-Draft The I in RPKI does not stand for Identity May 2021 [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, . 7.2. Informative References [I-D.ietf-sidrops-rpki-rsc] Snijders, J., "Resource Public Key Infrastructure (RPKI) object profile for Signed Checklist (RSC)", draft-ietf- sidrops-rpki-rsc-02 (work in progress), March 2021. [I-D.ietf-sidrops-rpki-rta] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., and M. Hoffmann, "A profile for Resource Tagged Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work in progress), January 2021. [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, . Authors' Addresses Randy Bush Arrcus & Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 US Email: randy@psg.com Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 US Email: housley@vigilsec.com Bush & Housley Expires November 5, 2021 [Page 6]