Delete 'draft-ymbk-rpki-has-no-identity.xml'
This commit is contained in:
parent
866591d607
commit
35ed924efd
1 changed files with 0 additions and 183 deletions
|
|
@ -1,183 +0,0 @@
|
||||||
<?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-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>
|
|
||||||
|
|
||||||
<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. 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 the private keys to sign arbitrary
|
|
||||||
documents to attest that the 'owner' of those resources has attested
|
|
||||||
to the authenticity of those documents.</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&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>Normally, the INR holder does not hold the private key attesting
|
|
||||||
to their resources; the Certification Authority (CA) does.</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), 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 [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 it is 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>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 kets. If so, is the signature still valid?</t>
|
|
||||||
|
|
||||||
<t>Beware that, while Ghostbuster Records <xref target="RFC6493"/>
|
|
||||||
may seem to identify a real world entity, in fact their semantic
|
|
||||||
content is completely arbitrary, and does not attest to INR
|
|
||||||
ownership. They are merely a clue for operational support contact
|
|
||||||
in case of technical RPKI problems.</t>
|
|
||||||
|
|
||||||
<t>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>
|
|
||||||
|
|
||||||
</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>
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue