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

more ownership

Browse source
This commit is contained in:
Randy Bush 2022-04-14 15:30:25 -07:00
parent 547178358d
commit 1ad4817e10
1 changed files with 26 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -49,7 +49,7 @@
<abstract> <abstract>
<t>There is a false notion that Internet Number Resources (INRs) in <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' the RPKI can be associated with the real-world identity of the 'holder'
of an INR. This document attempts to put that notion to rest.</t> of an INR. This document attempts to put that notion to rest.</t>
</abstract> </abstract>
@ -80,23 +80,24 @@
target="RFC8635"/>.</t> target="RFC8635"/>.</t>
<t>In security terms, the phrase "Public Key" implies there is also <t>In security terms, the phrase "Public Key" implies there is also
a corresponding private key <xref target="RFC5280"/>. The RPKI's a corresponding private key <xref target="RFC5280"/>. The RPKI
strong authority over ownership of INRs has misled some people provides strong authority to the current holder of INRs; however,
toward a desire to use RPKI private keys to sign arbitrary documents some people a have a desire to use RPKI private keys to sign
attesting that the INR 'owner' of those resources has attested to arbitrary documents as the INR 'holder' of those resources with the
the authenticity of the document content. But in reality, the RPKI inappropriate expectation that the signature will be considered an
certificate is only an authorization to speak for the explicitly attestation to the authenticity of the document content. But in
identified INRs; it is explicitly not intended for authentication of reality, the RPKI certificate is only an authorization to speak for
the 'owners' of the INRs. This situation is emphasized in Section the explicitly identified INRs; it is explicitly not intended for
2.1 of <xref target="RFC6480"/>.</t> authentication of the 'holders' 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 <t>It has been suggested that one could authenticate real-world
business transactions with the signatures of INR holders. E.g. business transactions with the signatures of INR holders. E.g.
Bill's Bait and Sushi could use the private key attesting to Bill's Bait and Sushi could use the private key attesting to that
ownership of their AS in the RPKI to sign a Letter of Authorization they are the holder of their AS in the RPKI to sign a Letter of
(LOA) for some other party to rack and stack hardware owned by Authorization (LOA) for some other party to rack and stack hardware
BB&amp;S. Unfortunately, while this may be technically possible, it owned by BB&amp;S. Unfortunately, while this may be technically
is neither appropriate nor meaningful.</t> possible, it is neither appropriate nor meaningful.</t>
<t>The I in RPKI actually stands for "Infrastructure," as in <t>The I in RPKI actually stands for "Infrastructure," as in
Resource Public Key Infrastructure, not for "Identity". In fact, Resource Public Key Infrastructure, not for "Identity". In fact,
@ -167,7 +168,7 @@
holder has a real-world business relationship with the CA for which holder has a real-world business relationship with the CA for which
they have likely signed real-world documents.</t> they have likely signed real-world documents.</t>
<t>As the INR owner does not have the keying material, they rely on <t>As the INR holder does not have the keying material, they rely on
the CA, to which they presumably present credentials, to manipulate the CA, to which they presumably present credentials, to manipulate
their INRs. These credentials may be userid/password (with two their INRs. These credentials may be userid/password (with two
factor authentication one hopes), a hardware token, client browser factor authentication one hopes), a hardware token, client browser
@ -191,7 +192,7 @@
to authorize access to BB&amp;S's servers in some colocation to authorize access to BB&amp;S's servers in some colocation
facility.</t> facility.</t>
<t>Then there is the temporal issue. The owner of that AS may be <t>Then there is the temporal issue. The holder of that AS may be
BB&amp;S today when some document was signed, and could be the BB&amp;S today when some document was signed, and could be the
Government of Elbonia tomorrow. Or the resource could have been Government of Elbonia tomorrow. Or the resource could have been
administratively moved from one CA to another, likely requiring a administratively moved from one CA to another, likely requiring a
@ -200,15 +201,15 @@
<t>While Ghostbuster Records <xref target="RFC6493"/> may seem to <t>While Ghostbuster Records <xref target="RFC6493"/> may seem to
identify real-world entities, their semantic content is completely identify real-world entities, their semantic content is completely
arbitrary, and does not attest to INR ownership. They are merely arbitrary, and does not attest to holding of any INRs. They are
clues for operational support contact in case of technical RPKI merely clues for operational support contact in case of technical
problems.</t> RPKI problems.</t>
<t>Usually, before registering INRs, CAs require proof of INR <t>Usually, before registering INRs, CAs require proof of an INR
ownership via external documentation and authorities. It is holding via external documentation and authorities. It is somewhat
somewhat droll that the CPS Template, <xref target="RFC7382"/>, does droll that the CPS Template, <xref target="RFC7382"/>, does not
not mention any diligence the CA must, or even might, conduct to mention any diligence the CA must, or even might, conduct to assure
assure the INRs are in fact owned by a registrant.</t> the INRs are in fact owned by a registrant.</t>
<t>That someone can provide 'proof of possession' of the private key <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 signing over a particular INR should not be taken to imply that they