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

tried to merge in russ's changes to the wrong document

Browse source
This commit is contained in:
Randy Bush 2021-03-16 12:49:12 -07:00
parent 13c178b736
commit 866591d607
1 changed files with 47 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -31,15 +31,14 @@
</address> </address>
</author> </author>
<author fullname="Russ Housley" initials="R" surname="Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon</city> <city>Herndon, VA</city>
<region>VA</region>
<code>20170</code> <code>20170</code>
<country>USA</country> <country>US</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
@ -49,11 +48,9 @@
<abstract> <abstract>
<t>There is a false notion that internet number resource in the RPKI <t>There is a false notion that Internet Number Resources (INRs) in
can be associated with the real world identity of the 'owner' of an the RPKI can be associated with the real world identity of the 'owner'
internet number resource, and may therefore be used to authenticate of an INR. This document attempts to put that notion to rest.</t>
real world documents or transactions. This document attempts to put
that notion to rest.</t>
</abstract> </abstract>
@ -82,12 +79,11 @@
<t>In security terms the phrase "Public Key" implies there are also <t>In security terms the phrase "Public Key" implies there are also
private keys, a la <xref target="RFC5280"/>. And, as the RPKI has private keys, a la <xref target="RFC5280"/>. And, as the RPKI has
strong authority over ownership of Internet Number Resources (INRs), strong authority over ownership of Internet Number Resources (INRs),
there is a desire to use these private keys to sign arbitrary there is a desire to use the private keys to sign arbitrary
documents to attest that the 'owner' of those resources has documents to attest that the 'owner' of those resources has attested
authorized or authenticated a real world document or transaction. to the authenticity of those documents. Instead, it is an
Instead, it is an authorization to speak for the named IP address authorization to speak for the named IP address blocks and AS
blocks and AS numbers themselves, not their unidentifiable numbers themselves, not their unidentifiable owners.</t>
owners.</t>
<t>There is a desire is to authenticate real world business <t>There is a desire is to authenticate real world business
transactions with the signatures of INR holders. E.g. for Bill's transactions with the signatures of INR holders. E.g. for Bill's
@ -137,16 +133,16 @@
<section anchor="discuss" title="Discussion"> <section anchor="discuss" title="Discussion">
<t>An INR holder does not actually hold the private key attesting to <t>Normally, the INR holder does not hold the private key attesting
their resources; a CA does. The INR holder has a real world to their resources; the Certification Authority (CA) does. The INR
business relationship with the CA for which they have likely signed holder has a real world business relationship with the CA for which
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, in order the CA, to which they presumably must present credentials, to
to manipulate their INRs. These credentials may be userid/password manipulate their INRs. These credentials may be userid/password
(with two factor authentication one hopes), hardware tokens, client (with two factor authentication one hopes), a hardware token, client
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
@ -156,7 +152,8 @@
System (AS) number, someone out on the net probably has the System (AS) number, someone out on the net probably has the
credentials to the CA account in which BB&amp;S's INRs are 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 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> 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 operations, INR management is often compartmentalized
with no authority over anything beyond dealing with INR with no authority over anything beyond dealing with INR
@ -165,7 +162,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>There is the temporal issue that the owner of an INR may be <t>Then there is the temporal issue. The owner 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
@ -193,18 +190,28 @@
says explicitly "An important property of this PKI is that says explicitly "An important property of this PKI is that
certificates do not attest to the identity of the subject."</t> certificates do not attest to the identity of the subject."</t>
<t>The "Template for a Certification Practice Statement (CPS) for <t>The Template for a Certification Practice Statement (CPS) for the
the Resource PKI (RPKI)" <xref target="RFC7382"/> Section 3.1, Resource PKI (RPKI) <xref target="RFC7382"/> Section 3.1, Naming,
Naming, makes very clear that "The Subject name in each certificate makes very clear that "The Subject name in each certificate SHOULD
SHOULD NOT be meaningful;" and goes on to do so at some length.</t> NOT be meaningful;" and goes on to do so at some length.</t>
</section> </section>
<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 inappropriate and other artifacts requiring identity are invalid and misleading.</t>
dangerous.</t>
<t>When a document is signed with the private key associated with a
RPKI certificate, the signer is speaking for the INRs, the IP
address space and Autonomous System (AS) numbers, in the
certificate. This is not an identity; this is an authorization. In
schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/> and <xref
target="I-D.ietf-sidrops-rpki-rsc"/> the signed message further
narrows this scope of INRs. The INRs in the message are a subset of
the INRs in the certificate. If the signature is valid, the message
content comes from a party that is authorized to speak for that
subset of INRs.</t>
<t>Control of INRs for an entity could be used to falsely authorize <t>Control of INRs for an entity could be used to falsely authorize
transactions or documents for which the INR manager has no transactions or documents for which the INR manager has no