randy/draft-rpki-has-no-identity
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

still rough but starting to feel good about it

Browse source
This commit is contained in:
Randy Bush 2021-03-14 19:07:49 -07:00
parent 71b1781494
commit 6e54483c41
1 changed files with 205 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

205
draft-ymbk-sidrops-rpki-has-no-identity.xml Normal file
View file

@ -0,0 +1,205 @@
<?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 &amp; 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>
<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."</t>
<t>In security terms the phrase "Public Key" implies there are also
private keys, a la <xref target="RFC2459"/>. 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.</t>
<t>The 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&amp;S.
Unfortunately, this is not 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.</t>
</section>
<section anchor="bottom" title="The Bottom Line">
<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>That the RPKI does not authenticate real world identity is a
feature not a bug. If it tried to do so, it would end in a world of
complexity with no proof of termination, as X.400 learned.</t>
</section>
<section anchor="discuss" title="Discussion">
<t>An INR holder does not actually hold the private key attesting to
their resources; a 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 must present credentials, to
manipulate their INRs. These credentials may be userid/password
(with two factor authentication one hopes), hardware tokens, 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 [not really] relevant keys from
the CA.</t>
<t>For some particular INR, say Bill's Bait and Sushi's AS number,
someone out on the net probably has the credentials to the CA
account in which BB&amp;S's INRs are registered. That could be the
owner of BB&amp;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&amp;S, or even
to authorize access to BB&amp;S's servers in some colocation
facility.</t>
<t>There is also a temporal issue. The owner of an AS may be
BB&amp;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 to determine if the signature on the
real world document 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 should, conduct to
assure the INRs are in fact owned by a registrant.</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>The 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 keying from INRs MUST NOT be used to authenticate real
world documents or transactions without some 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2459"?>
<?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>