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

cite 6480

Browse source
This commit is contained in:
Randy Bush 2021-03-15 03:34:43 -07:00
parent 6e54483c41
commit 626b90b855
1 changed files with 42 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -75,7 +75,7 @@
with the signatures of INR holders. E.g. for Bill's Bait and Sushi 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) 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. for some other party to rack and stack hardware owned by BB&S.
Unfortunately, this is not feasible.</t> Unfortunately, this is not formally feasible.</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,
@ -86,15 +86,28 @@
<section anchor="bottom" title="The Bottom Line"> <section anchor="bottom" title="The Bottom Line">
<t>The Template for a Certification Practice Statement (CPS) for the <t>The RPKI base document, <xref target="RFC6480"/>, Section 2.1
Resource PKI (RPKI) <xref target="RFC7382"/> Section 3.1, Naming, says explicitly "An important property of this PKI is that
makes very clear that "The Subject name in each certificate SHOULD certificates do not attest to the identity of the subject."</t>
NOT be meaningful;" and goes on to do so at some length.</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>That the RPKI does not authenticate real world identity is a <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 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> complexity with no proof of termination, as X.400 learned.</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>
<section anchor="discuss" title="Discussion"> <section anchor="discuss" title="Discussion">
@ -105,21 +118,20 @@
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 owner does not have the keying material, they rely on
the CA, to which they presumably must present credentials, to the CA, to which they presumably must present credentials, in order
manipulate their INRs. These credentials may be userid/password to manipulate their INRs. These credentials may be userid/password
(with two factor authentication one hopes), hardware tokens, client (with two factor authentication one hopes), hardware tokens, client
browser certificates, etc.</t> browser certificates, etc.</t>
<t>Hence schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/> <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 and <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to great
lengths to extract the supposedly [not really] relevant keys from lengths to extract the supposedly relevant keys from the CA.</t>
the CA.</t>
<t>For some particular INR, say Bill's Bait and Sushi's AS number, <t>For some particular INR, say Bill's Bait and Sushi's Autonompus
someone out on the net probably has the credentials to the CA System (AS) number, someone out on the net probably has the
account in which BB&amp;S's INRs are registered. That could be the credentials to the CA account in which BB&amp;S's INRs are
owner of BB&amp;S, Roberto's Taco Stand, or the Government of registered. That could be the owner of BB&amp;S, Roberto's Taco
Elbonia. One simply can not know.</t> Stand, or the Government of Elbonia. One simply can not know.</t>
<t>In large operations, INR management is often compartmentalized <t>In large operations, INR management is often compartmentalized
with no authority over anything beyond dealing with INR with no authority over anything beyond dealing with INR
@ -128,12 +140,12 @@
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>There is also a temporal issue. The owner of an AS may be <t>There is the temporal issue that the owner of an INR 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
change of keys. If so, how to determine if the signature on the change of keys. If so, how does one determine if the signature on
real world document still valid?</t> the real world document is still valid?</t>
<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
@ -143,8 +155,8 @@
<t>Usually, before registering INRs, CAs require proof of INR <t>Usually, before registering INRs, CAs require proof of INR
ownership via external documentation and authorities. It is ownership via external documentation and authorities. It is
somewhat droll that the CPS template, <xref target="RFC7382"/>, does somewhat droll that the CPS Template, <xref target="RFC7382"/>, does
not mention any diligence the CA must, or even should, conduct to not mention any diligence the CA must, or even might, conduct to
assure the INRs are in fact owned by a registrant.</t> assure the INRs are in fact owned by a registrant.</t>
</section> </section>
@ -152,16 +164,18 @@
<section anchor="security" title="Security Considerations"> <section anchor="security" title="Security Considerations">
<t>Attempts to use RPKI data to authenticate real world documents or <t>Attempts to use RPKI data to authenticate real world documents or
other artifacts requiring identity are invalid and misleading.</t> other artifacts requiring identity are inappropriate and
dangerous.</t>
<t>The control of INRs for an entity could be used to falsely <t>Control of INRs for an entity could be used to falsely authorize
authorize transactions or documents for which the INR manager has no transactions or documents for which the INR manager has no
authority.</t> authority.</t>
<t>RPKI-based keying from INRs MUST NOT be used to authenticate real <t>RPKI-based credentials of INRs MUST NOT be used to authenticate
world documents or transactions without some external authentication real world documents or transactions without some formal external
of the INR and the authority for the actually anonymous INR holder authentication of the INR and the authority for the actually
to authenticate the particular document or transaction.</t> anonymous INR holder to authenticate the particular document or
transaction.</t>
</section> </section>
@ -179,7 +193,8 @@
<section anchor="acks" title="Acknowledgments"> <section anchor="acks" title="Acknowledgments">
<t>The authors thank George Michaelson and Job Snijders for lively <t>The authors thank George Michaelson and Job Snijders for lively
discussion.</t> discussion; and last but not least, Biff for the loan of Bill's Bait
and Sushi.</t>
</section> </section>