From 28c190defc4b313aabbb6b47fbe7c27ed1ac8fe2 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 15 Mar 2021 18:30:01 -0700 Subject: [PATCH] russ suggested some good stuff, incorporated --- draft-ymbk-sidrops-rpki-has-no-identity.xml | 90 ++++++++++++++------- 1 file changed, 62 insertions(+), 28 deletions(-) diff --git a/draft-ymbk-sidrops-rpki-has-no-identity.xml b/draft-ymbk-sidrops-rpki-has-no-identity.xml index 208d712..b01edb9 100644 --- a/draft-ymbk-sidrops-rpki-has-no-identity.xml +++ b/draft-ymbk-sidrops-rpki-has-no-identity.xml @@ -31,6 +31,20 @@ + + Vigil Security, LLC +
+ + 516 Dranesville Road + Herndon + VA + 20170 + USA + + housley@vigilsec.com +
+ + @@ -61,67 +75,77 @@ The Resource Public Key Infrastructure (RPKI), see , "represents the allocation hierarchy of IP - address space and Autonomous System (AS) numbers." + address space and Autonomous System (AS) numbers." Though since, it + has grown to include other similar resource and routing data. In security terms the phrase "Public Key" implies there are also - private keys, a la . And, as the RPKI has + private keys, a la . 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. + 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. - 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. + 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. 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. + world holder(s) of those INRs. The RPKI provides authorization to + speak for the named IP address blocks and AS numbers.
- The RPKI base document, , Section 2.1 - says explicitly "An important property of this PKI is that - certificates do not attest to the identity of the subject." - - The "Template for a Certification Practice Statement (CPS) for - the Resource PKI (RPKI)" 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. - + The RPKI was designed and specified to sign certificates for use + within the RPKI itself　and to generate Route Origin Authorizations + (ROAs), , 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. + 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. + 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. + 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. + 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. +
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. + 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. 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. + certificates, etc. Hence schemes such as and must go to great @@ -161,7 +185,17 @@ 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. + in loop detection in routing. They have no inherent semantics other + than uniqueness. + + The RPKI base document, , Section 2.1 + says explicitly "An important property of this PKI is that + certificates do not attest to the identity of the subject." + + The "Template for a Certification Practice Statement (CPS) for + the Resource PKI (RPKI)" 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.
@@ -208,7 +242,7 @@ - +