diff --git a/draft-ymbk-sidrops-rpki-has-no-identity.xml b/draft-ymbk-sidrops-rpki-has-no-identity.xml new file mode 100644 index 0000000..c12240d --- /dev/null +++ b/draft-ymbk-sidrops-rpki-has-no-identity.xml @@ -0,0 +1,205 @@ + + + + + + + + + + + + + + + + + + The I in RPKI does not stand for Identity + + + Arrcus & Internet Initiative Japan +
+ + 5147 Crystal Springs + Bainbridge Island + WA + 98110 + US + + randy@psg.com +
+ + + + + + + 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. + + + + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 when, + and only when, they appear in all capitals, as shown here. + + + + + + + +
+ + The Resource Public Key Infrastructure (RPKI), see , "represents the allocation hierarchy of IP + address space and Autonomous System (AS) numbers." + + In security terms the phrase "Public Key" implies there are also + 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. + + 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 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. + +
+ +
+ + 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. + + 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. + +
+ +
+ + 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. + + As the INR owner does not have the keying material, they rely on + 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), hardware tokens, client + browser certificates, etc. + + Hence schemes such as + and must go to great + lengths to extract the supposedly [not really] relevant keys from + the CA. + + For some particular INR, say Bill's Bait and Sushi's AS number, + someone out on the net probably has the credentials to the CA + account in which BB&S's INRs are registered. That could be the + owner of BB&S, Roberto's Taco Stand, or the Government of + Elbonia. One simply can not know. + + In large operations, INR management is often compartmentalized + with no authority over anything beyond dealing with INR + registration. The INR manager for Bill's Bait and Sushi is unlikely + to be authorized to conduct bank transactions for BB&S, or even + to authorize access to BB&S's servers in some colocation + facility. + + There is also a temporal issue. The owner of an AS may be + BB&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 + change of keys. If so, how to determine if the signature on the + real world document still valid? + + While Ghostbuster Records may seem to + identify real world entities, their semantic content is completely + arbitrary, and does not attest to INR ownership. They are merely + clues for operational support contact in case of technical RPKI + problems. + + Usually, before registering INRs, CAs require proof of INR + ownership via external documentation and authorities. It is + somewhat droll that the CPS template, , does + not mention any diligence the CA must, or even should, conduct to + assure the INRs are in fact owned by a registrant. + +
+ +
+ + Attempts to use RPKI data to authenticate real world documents or + other artifacts requiring identity are invalid and misleading. + + The control of INRs for an entity could be used to falsely + authorize transactions or documents for which the INR manager has no + authority. + + RPKI-based keying from INRs MUST NOT be used to authenticate real + world documents or transactions without some external authentication + of the INR and the authority for the actually anonymous INR holder + to authenticate the particular document or transaction. + +
+ +
+ + This document has no IANA Considerations. + + + +
+ +
+ + The authors thank George Michaelson and Job Snijders for lively + discussion. + +
+ + + + + + + + + + + + + + + + + + + + +