russ suggested some good stuff, incorporated
This commit is contained in:
parent
386d1df403
commit
28c190defc
1 changed files with 62 additions and 28 deletions
|
|
@ -31,6 +31,20 @@
|
|||
</address>
|
||||
</author>
|
||||
|
||||
<author fullname="Russ Housley" initials="R" surname="Housley">
|
||||
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
|
||||
<address>
|
||||
<postal>
|
||||
<street>516 Dranesville Road</street>
|
||||
<city>Herndon</city>
|
||||
<region>VA</region>
|
||||
<code>20170</code>
|
||||
<country>USA</country>
|
||||
</postal>
|
||||
<email>housley@vigilsec.com</email>
|
||||
</address>
|
||||
</author>
|
||||
|
||||
<date />
|
||||
|
||||
<abstract>
|
||||
|
|
@ -61,67 +75,77 @@
|
|||
|
||||
<t>The Resource Public Key Infrastructure (RPKI), see <xref
|
||||
target="RFC6480"/>, "represents the allocation hierarchy of IP
|
||||
address space and Autonomous System (AS) numbers."</t>
|
||||
address space and Autonomous System (AS) numbers." Though since, it
|
||||
has grown to include other similar resource and routing data.</t>
|
||||
|
||||
<t>In security terms the phrase "Public Key" implies there are also
|
||||
private keys, a la <xref target="RFC2459"/>. 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),
|
||||
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.</t>
|
||||
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>
|
||||
|
||||
<t>The desire is 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&S.
|
||||
Unfortunately, this is not formally feasible.</t>
|
||||
<t>There is a desire is 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&S. Unfortunately, this is not formally
|
||||
feasible.</t>
|
||||
|
||||
<t>The I in RPKI actually stands for "Infrastructure," as in
|
||||
Resource Public Key Infrastructure, not for "Identity". In fact,
|
||||
the RPKI does not provide any association between INRs and the real
|
||||
world holder(s) of those INRs.</t>
|
||||
world holder(s) of those INRs. The RPKI provides authorization to
|
||||
speak for the named IP address blocks and AS numbers.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="bottom" title="The Bottom Line">
|
||||
|
||||
<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>The RPKI was designed and specified to sign certificates for use
|
||||
within the RPKI itself and to generate Route Origin Authorizations
|
||||
(ROAs), <xref target="RFC6480"/>, for use in routing. It's design
|
||||
intentionally precluded use for attesting to real world identity as,
|
||||
among other issues, it would expose the Certification Authority (CA)
|
||||
to liability.</t>
|
||||
|
||||
<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
|
||||
complexity with no proof of termination, as X.400 learned.</t>
|
||||
feature not a bug. If it tried to do so, aside from the liability,
|
||||
it would end in a world of complexity with no proof of termination,
|
||||
as X.400 learned.</t>
|
||||
|
||||
<t>Registries such as the Regional Internet Resistries (RIRs)
|
||||
provide INR to real world identity mapping through whois and similar
|
||||
services. They claim to be authoritative, at least for for the INRs
|
||||
which they allocate.</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 anchor="discuss" title="Discussion">
|
||||
|
||||
<t>An INR holder does not actually hold the private key attesting to
|
||||
their resources; a 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>
|
||||
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>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
|
||||
browser certificates, etc.</t>
|
||||
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
|
||||
|
|
@ -161,7 +185,17 @@
|
|||
|
||||
<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.</t>
|
||||
in 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>
|
||||
|
||||
|
|
@ -208,7 +242,7 @@
|
|||
|
||||
<references title="Normative References">
|
||||
<?rfc include="reference.RFC.2119"?>
|
||||
<?rfc include="reference.RFC.2459"?>
|
||||
<?rfc include="reference.RFC.5280"?>
|
||||
<?rfc include="reference.RFC.6480"?>
|
||||
<?rfc include="reference.RFC.7382"?>
|
||||
<?rfc include="reference.RFC.8174"?>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue