Skip to main content

The I in RPKI does not stand for Identity
draft-ietf-sidrops-rpki-has-no-identity-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9255.
Authors Randy Bush , Russ Housley
Last updated 2021-09-23 (Latest revision 2021-08-08)
Replaces draft-ymbk-sidrops-rpki-has-no-identity
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 9255 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-sidrops-rpki-has-no-identity-02
Network Working Group                                            R. Bush
Internet-Draft                        Arrcus & Internet Initiative Japan
Intended status: Standards Track                              R. Housley
Expires: 27 March 2022                                    Vigil Security
                                                       23 September 2021

               The I in RPKI does not stand for Identity
               draft-ietf-sidrops-rpki-has-no-identity-02

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 27 March 2022.

Copyright Notice

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

Bush & Housley            Expires 27 March 2022                 [Page 1]
Internet-Draft  The I in RPKI does not stand for Identit  September 2021

   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 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 . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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.  But in reality, it is an authorization to speak for
   the named IP address blocks and AS numbers themselves, not their
   unidentifiable owners.

   It has been suggested that one could authenticate real world business
   transactions with the signatures of INR holders.  E.g.  Bill's Bait
   and Sushi could 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.

Bush & Housley            Expires 27 March 2022                 [Page 2]
Internet-Draft  The I in RPKI does not stand for Identit  September 2021

   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 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 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.

   Note that, if there is sufficient external, i.e. non-RPKI,
   verifcation of authority, then use of RPKI-based credentials seems
   superfluous.

3.  Discussion

   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.

Bush & Housley            Expires 27 March 2022                 [Page 3]
Internet-Draft  The I in RPKI does not stand for Identit  September 2021

   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 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.
   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 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 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.

Bush & Housley            Expires 27 March 2022                 [Page 4]
Internet-Draft  The I in RPKI does not stand for Identit  September 2021

   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 just an INR administrative person.

   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 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
   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, Ties de Kock for useful suggestions, and last but not
   least, Biff for the loan of Bill's Bait and Sushi.

7.  References

7.1.  Normative References

Bush & Housley            Expires 27 March 2022                 [Page 5]
Internet-Draft  The I in RPKI does not stand for Identit  September 2021

   [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>.

7.2.  Informative References

   [I-D.ietf-sidrops-rpki-rsc]
              Snijders, J., Harrison, T., and B. Maddison, "Resource
              Public Key Infrastructure (RPKI) object profile for Signed
              Checklist (RSC)", Work in Progress, Internet-Draft, draft-
              ietf-sidrops-rpki-rsc-05, 11 August 2021,
              <https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
              rsc-05.txt>.

   [I-D.ietf-sidrops-rpki-rta]
              Michaelson, G. 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://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
              rta-00.txt>.

Bush & Housley            Expires 27 March 2022                 [Page 6]
Internet-Draft  The I in RPKI does not stand for Identit  September 2021

   [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>.

Authors' Addresses

   Randy Bush
   Arrcus & Internet Initiative Japan
   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

Bush & Housley            Expires 27 March 2022                 [Page 7]