258 lines
9.8 KiB
XML
258 lines
9.8 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" docName="draft-ymbk-sidrops-rpki-has-no-identity-00" 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 fullname="Russ Housley" initials="R" surname="Housley">
|
||
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
|
||
<address>
|
||
<postal>
|
||
<street>516 Dranesville Road</street>
|
||
<city>Herndon</city>
|
||
<region>VA</region>
|
||
<code>20170</code>
|
||
<country>USA</country>
|
||
</postal>
|
||
<email>housley@vigilsec.com</email>
|
||
</address>
|
||
</author>
|
||
|
||
<date />
|
||
|
||
<abstract>
|
||
|
||
<t>There is a false notion that internet number resource in the RPKI
|
||
can be associated with the real world identity of the 'owner' of an
|
||
internet number resource, and may therefore be used to authenticate
|
||
real world documents or transactions. 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." Though since, it
|
||
has grown to include other similar resource and routing data.</t>
|
||
|
||
<t>In security terms the phrase "Public Key" implies there are also
|
||
private keys, a la <xref target="RFC5280"/>. And, as the RPKI has
|
||
strong authority over ownership of Internet Number Resources (INRs),
|
||
there is a desire to use these private keys to sign arbitrary
|
||
documents to attest that the 'owner' of those resources has
|
||
authorized or authenticated a real world document or transaction.
|
||
Instead, it is an authorization to speak for the named IP address
|
||
blocks and AS numbers themselves, not their unidentifiable
|
||
owners.</t>
|
||
|
||
<t>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.</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
|
||
speak for the named IP address blocks and AS numbers.</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. It's 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 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.</t>
|
||
|
||
<t>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.</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>
|
||
|
||
<!--
|
||
<t>If there is sufficient external, i.e. non-RPKI, verifcation of
|
||
authority, then use of RPKI-based credentials seems superfluous.</t>
|
||
-->
|
||
</section>
|
||
|
||
<section anchor="discuss" title="Discussion">
|
||
|
||
<t>An INR holder does not actually hold the private key attesting to
|
||
their resources; a 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 must present credentials, in order
|
||
to manipulate their INRs. These credentials may be userid/password
|
||
(with two factor authentication one hopes), hardware tokens, client
|
||
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 Autonompus
|
||
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, or the Government of Elbonia. One simply can not know.</t>
|
||
|
||
<t>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.</t>
|
||
|
||
<t>There is the temporal issue that the owner of an INR 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>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.</t>
|
||
|
||
<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>
|
||
|
||
</section>
|
||
|
||
<section anchor="security" title="Security Considerations">
|
||
|
||
<t>Attempts to use RPKI data to authenticate real world documents or
|
||
other artifacts requiring identity are inappropriate and
|
||
dangerous.</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; 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"?>
|
||
<?rfc include="reference.RFC.5280"?>
|
||
<?rfc include="reference.RFC.6480"?>
|
||
<?rfc include="reference.RFC.7382"?>
|
||
<?rfc include="reference.RFC.8174"?>
|
||
</references>
|
||
|
||
<references title="Informative References">
|
||
<?rfc include="reference.RFC.6493"?>
|
||
<?rfc include="reference.I-D.ietf-sidrops-rpki-rsc"?>
|
||
<?rfc include="reference.I-D.ietf-sidrops-rpki-rta"?>
|
||
</references>
|
||
|
||
</back>
|
||
</rfc>
|