doc: Add RFC documents

1 files changed, 317 insertions, 0 deletions

diff --git a/doc/rfc/rfc9255.txt b/doc/rfc/rfc9255.txt
new file mode 100644
index 0000000..d63a2cd
--- /dev/null
+++ b/doc/rfc/rfc9255.txt
@@ -0,0 +1,317 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           R. Bush
+Request for Comments: 9255                         Arrcus & IIJ Research
+Category: Standards Track                                     R. Housley
+ISSN: 2070-1721                                           Vigil Security
+                                                               June 2022
+
+
+              The 'I' in RPKI Does Not Stand for Identity
+
+Abstract
+
+   There is a false notion that Internet Number Resources (INRs) in the
+   RPKI can be associated with the real-world identity of the 'holder'
+   of an INR.  This document specifies that RPKI does not associate to
+   the INR holder.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9255.
+
+Copyright Notice
+
+   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) 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 Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without 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
+
+   The Resource Public Key Infrastructure (RPKI), see [RFC6480],
+   "represents the allocation hierarchy of IP address space and
+   Autonomous System (AS) numbers," which are collectively known as
+   Internet Number Resources (INRs).  Since initial deployment, the RPKI
+   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 is also a
+   corresponding private key [RFC5280].  The RPKI provides strong
+   authority to the current holder of INRs; however, some people have a
+   desire to use RPKI private keys to sign arbitrary documents as the
+   INR 'holder' of those resources with the inappropriate expectation
+   that the signature will be considered an attestation to the
+   authenticity of the document content.  But, in reality, the RPKI
+   certificate is only an authorization to speak for the explicitly
+   identified INRs; it is explicitly not intended for authentication of
+   the 'holders' of the INRs.  This situation is emphasized in
+   Section 2.1 of [RFC6480].
+
+   It has been suggested that one could authenticate real-world business
+   transactions with the signatures of INR holders.  For example, Bill's
+   Bait and Sushi (BB&S) could use the private key attesting to that
+   they are the holder of 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, while this may be technically
+   possible, it is neither appropriate nor meaningful.
+
+   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
+   holder(s) of those INRs.  The RPKI provides authorization to make
+   assertions only regarding Internet Number Resources, such as IP
+   prefixes or AS numbers, and data such as Autonomous System Provider
+   Authorization (ASPA) records [ASPA-PROFILE].
+
+   In short, avoid the desire to use RPKI certificates for any purpose
+   other than the verification of authorizations associated with the
+   delegation of INRs or attestations related to INRs.  Instead,
+   recognize that these authorizations and attestations take place
+   irrespective of the identity of an RPKI private key holder.
+
+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 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 by design.
+   If it tried to do so, aside from the liability, it would end in a
+   world of complexity with no proof of termination.
+
+   Registries such as the Regional Internet Registries (RIRs) provide
+   INR to real-world identity mapping through WHOIS [RFC3912] and
+   similar services.  They claim to be authoritative, at least for the
+   INRs that they allocate.
+
+   That is, 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 allowing
+   an otherwise anonymous INR holder to authenticate the particular
+   document or transaction.  Given such external, i.e. non-RPKI,
+   verification of authority, the use of RPKI-based credentials adds no
+   authenticity.
+
+3.  Discussion
+
+   Section 2.1 of the RPKI base document [RFC6480] says explicitly "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] states that the Subject name
+   in each certificate SHOULD NOT be meaningful and goes on to explain
+   this at some length.
+
+   Normally, the INR holder does not hold the private key attesting to
+   their resources; the 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 holder does not have the keying material, they rely on the
+   CA, to which they presumably present credentials, to manipulate their
+   INRs.  These credentials may be user ID and password (with two-factor
+   authentication one hopes), a hardware token, client browser
+   certificates, etc.
+
+   Hence schemes such as Resource Tagged Attestations [RPKI-RTA] and
+   Signed Checklists [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.
+   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 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 holder 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 holding of any INRs.  They are merely clues for operational
+   support contact in case of technical RPKI problems.
+
+   Usually, before registering INRs, CAs require proof of an INR holding
+   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.
+
+   That someone can provide 'proof of possession' of the private key
+   signing over a particular INR should not be taken to imply that they
+   are a valid legal representative of the organization in possession of
+   that INR.  They could be in an INR administrative role, and not be a
+   formal representative of the organization.
+
+   Autonomous System Numbers do not identify real-world entities.  They
+   are identifiers some network operators 'own' and are only used for
+   loop detection in routing.  They have no inherent semantics other
+   than uniqueness.
+
+4.  Security Considerations
+
+   Attempts to use RPKI data to authenticate real-world documents or
+   other artifacts requiring identity, while possibly cryptographically
+   valid within the RPKI, are misleading as to any authenticity.
+
+   When a document is signed with the private key associated with an
+   RPKI certificate, the signer is speaking for the INRs (the IP address
+   space and AS numbers) in the certificate.  This is not an identity;
+   this is an authorization.  In schemes such as Resource Tagged
+   Attestations [RPKI-RTA] and Signed Checklists [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.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  References
+
+6.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,
+              <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
+
+   [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 thank George Michaelson and Job Snijders for lively
+   discussion, Geoff Huston for some more formal text, Ties de Kock for
+   useful suggestions, many directorate and IESG reviewers, and last but
+   not least, Biff for the loan of 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