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>
</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>
<address>
<postal>
<street>516 Dranesville Road</street>
<city>Herndon</city>
<region>VA</region>
<city>Herndon, VA</city>
<code>20170</code>
<country>USA</country>
<country>US</country>
</postal>
<email>housley@vigilsec.com</email>
</address>
@ -49,11 +48,9 @@
<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, and may therefore be used to authenticate
real world documents or transactions. This document attempts to put
that notion to rest.</t>
<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'
of an INR. This document attempts to put that notion to rest.</t>
</abstract>
@ -82,12 +79,11 @@
<t>In security terms the phrase "Public Key" implies there are also
private keys, a la <xref target="RFC5280"/>. And, as the RPKI has
strong authority over ownership of Internet Number Resources (INRs),
there is a desire to use these private keys to sign arbitrary
documents to attest that the 'owner' of those resources has
authorized or authenticated a real world document or transaction.
Instead, it is an authorization to speak for the named IP address
blocks and AS numbers themselves, not their unidentifiable
owners.</t>
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
authorization to speak for the named IP address blocks and AS
numbers themselves, not their unidentifiable owners.</t>
<t>There is a desire is to authenticate real world business
transactions with the signatures of INR holders. E.g. for Bill's
@ -137,16 +133,16 @@
<section anchor="discuss" title="Discussion">
<t>An INR holder does not actually hold the private key attesting to
their resources; a 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>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, in order
to manipulate their INRs. These credentials may be userid/password
(with two factor authentication one hopes), hardware tokens, client
certificates, etc.</t>
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
@ -156,7 +152,8 @@
System (AS) number, someone out on the net probably has the
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
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
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
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
Government of Elbonia tomorrow. Or the resource could have been
administratively moved from one CA to another, likely requiring a
@ -193,18 +190,28 @@
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>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">
<t>Attempts to use RPKI data to authenticate real world documents or
other artifacts requiring identity are inappropriate and
dangerous.</t>
other artifacts requiring identity are invalid and misleading.</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
transactions or documents for which the INR manager has no