290 lines
12 KiB
XML
290 lines
12 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
|
|
<?rfc comments="yes"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc subcompact="no"?>
|
|
<?rfc inline="yes"?>
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="yes"?>
|
|
<?rfc tocdepth="6"?>
|
|
<?rfc tocindent="yes"?>
|
|
<?rfc tocompact="yes"?>
|
|
|
|
<rfc category="std" consensus="true" submissionType="IETF" docName="draft-ietf-sidrops-rpki-has-no-identity-05" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title>The I in RPKI does not stand for Identity</title>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>Arrcus & Internet Initiative Japan</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>WA</region>
|
|
<code>98110</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author initials="R." surname="Housley" fullname="Russ Housley">
|
|
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
|
|
<address>
|
|
<postal>
|
|
<street>516 Dranesville Road</street>
|
|
<city>Herndon, VA</city>
|
|
<code>20170</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>housley@vigilsec.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>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.</t>
|
|
|
|
</abstract>
|
|
|
|
<note title="Requirements Language">
|
|
|
|
<t>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 <xref target="RFC2119"/> <xref
|
|
target="RFC8174"/> when, and only when, they appear in all capitals,
|
|
as shown here.</t>
|
|
|
|
</note>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<t>The Resource Public Key Infrastructure (RPKI), see <xref
|
|
target="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, <xref
|
|
target="RFC8635"/>.</t>
|
|
|
|
<t>In security terms, the phrase "Public Key" implies there is also
|
|
a corresponding private key <xref target="RFC5280"/>. The RPKI's
|
|
strong authority over ownership of INRs has misled some people
|
|
toward a desire to use RPKI private keys to sign arbitrary documents
|
|
attesting that the INR 'owner' of those resources has attested 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 'owners' of the INRs. This situation is emphasized in Section
|
|
2.1 of <xref target="RFC6480"/>.</t>
|
|
|
|
<t>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 the private key attesting to
|
|
ownership 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.</t>
|
|
|
|
<t>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 named IP address blocks, AS numbers,
|
|
etc.</t>
|
|
|
|
<t>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 a RPKI private key holder.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="bottom" title="The Bottom Line">
|
|
|
|
<t>The RPKI was designed and specified to sign certificates for use
|
|
within the RPKI itself and to generate Route Origin Authorizations
|
|
(ROAs), <xref target="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.</t>
|
|
|
|
<t>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, as X.400
|
|
learned.</t>
|
|
|
|
<t>Registries such as the Regional Internet Registries (RIRs)
|
|
provide INR to real-world identity mapping through WHOIS, <xref
|
|
target="RFC3912"/>, and similar services. They claim to be
|
|
authoritative, at least for the INRs which they allocate.</t>
|
|
|
|
<t>PKI operations MUST NOT be performed with RPKI certificates other
|
|
than exactly as described, and for the purposes described, in <xref
|
|
target="RFC6480"/>.</t>
|
|
|
|
<t>I.e., 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.</t>
|
|
|
|
<t>Given sufficient external, i.e. non-RPKI, verification of
|
|
authority, the use of RPKI-based credentials seems superfluous.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="discuss" title="Discussion">
|
|
|
|
<t>The RPKI base document, <xref target="RFC6480"/>, Section 2.1
|
|
says explicitly "An important property of this PKI is that
|
|
certificates do not attest to the identity of the subject."</t>
|
|
|
|
<t>The Template for a Certification Practice Statement (CPS) for the
|
|
Resource PKI (RPKI) <xref target="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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>Hence schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/>
|
|
and <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to great
|
|
lengths to extract the supposedly relevant keys from the CA.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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?</t>
|
|
|
|
<t>While Ghostbuster Records <xref target="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.</t>
|
|
|
|
<t>Usually, before registering INRs, CAs require proof of INR
|
|
ownership via external documentation and authorities. It is
|
|
somewhat droll that the CPS Template, <xref target="RFC7382"/>, does
|
|
not mention any diligence the CA must, or even might, conduct to
|
|
assure the INRs are in fact owned by a registrant.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
<t>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.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
|
|
<t>Attempts to use RPKI data to authenticate real-world documents or
|
|
other artifacts requiring identity are invalid and misleading.</t>
|
|
|
|
<t>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 Autonomous System (AS) numbers, in the
|
|
certificate. This is not an identity; this is an authorization. In
|
|
schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/> and <xref
|
|
target="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.</t>
|
|
|
|
<t>Control of INRs for an entity could be used to falsely authorize
|
|
transactions or documents for which the INR manager has no
|
|
authority.</t>
|
|
<!--
|
|
<t>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.</t>
|
|
-->
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
|
|
<t>This document has no IANA Considerations.</t>
|
|
|
|
<!--
|
|
<t>Note to RFC Editor: this section may be replaced on publication
|
|
as an RFC.</t>
|
|
-->
|
|
|
|
</section>
|
|
|
|
<section anchor="acks" title="Acknowledgments">
|
|
|
|
<t>The authors thank George Michaelson and Job Snijders for lively
|
|
discussion, Geoff Huston for some more formal text, Ties de Kock for
|
|
useful suggestions, and last but not least, Biff for the loan of
|
|
Bill's Bait and Sushi.</t>
|
|
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<?rfc include="reference.RFC.2119.xml"?>
|
|
<?rfc include="reference.RFC.5280.xml"?>
|
|
<?rfc include="reference.RFC.6480.xml"?>
|
|
<?rfc include="reference.RFC.7382.xml"?>
|
|
<?rfc include="reference.RFC.8174.xml"?>
|
|
<?rfc include="reference.RFC.8635.xml"?>
|
|
</references>
|
|
|
|
<references title="Informative References">
|
|
<?rfc include="reference.RFC.3912.xml"?>
|
|
<?rfc include="reference.RFC.6493.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-rpki-rsc.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?>
|
|
</references>
|
|
|
|
</back>
|
|
</rfc>
|