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

-01 published

Browse source
This commit is contained in:
Randy Bush 2021-08-08 13:38:35 -07:00
parent 8a743d75b7
commit 8c6d0f4e5f
1 changed files with 36 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

72
draft-ietf-sidrops-rpki-has-no-identity.xml
View file

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ietf-sidrops-rpki-has-no-identity-00" ipr="trust200902">
<rfc category="std" consensus="true" docName="draft-ietf-sidrops-rpki-has-no-identity-01" ipr="trust200902">
<front>
@ -82,15 +82,15 @@
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. Instead, it is an
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.</t>
<t>There is a desire 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 formally
<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 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 formally
feasible.</t>
<t>The I in RPKI actually stands for "Infrastructure," as in
@ -126,24 +126,33 @@
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>
<t>Note that, 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>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 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>
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
@ -156,7 +165,7 @@
Stand, an IT vendor, or the Government of Elbonia. One simply can
not know.</t>
<t>In large operations, INR management is often compartmentalized
<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&amp;S, or even
@ -184,18 +193,9 @@
<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
for 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">
@ -250,18 +250,18 @@
<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"?>
<?rfc include="reference.RFC.8635"?>
<?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.6493"?>
<?rfc include="reference.I-D.ietf-sidrops-rpki-rsc"?>
<?rfc include="reference.I-D.ietf-sidrops-rpki-rta"?>
<?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>