diff --git a/draft-ietf-sidrops-rpki-has-no-identity.xml b/draft-ietf-sidrops-rpki-has-no-identity.xml new file mode 100644 index 0000000..0768935 --- /dev/null +++ b/draft-ietf-sidrops-rpki-has-no-identity.xml @@ -0,0 +1,268 @@ + + + + + + + + + + + + + + + + + + The I in RPKI does not stand for Identity + + + Arrcus & Internet Initiative Japan +
+ + 5147 Crystal Springs + Bainbridge Island + WA + 98110 + US + + randy@psg.com +
+ + + + Vigil Security, LLC +
+ + 516 Dranesville Road + Herndon, VA + 20170 + US + + housley@vigilsec.com +
+ + + + + + + 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. + + + + + + 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." Though since, it + has grown to include other similar resource and routing data, e.g. + Router Keying for BGPsec, . + + 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 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. + + 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. The RPKI provides authorization to + speak for the named IP address blocks and AS numbers. + +
+ +
+ + 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. Its 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, 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. + + +
+ +
+ + 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. + + 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), a hardware token, client + browser certificates, etc. + + Hence schemes such as + and must go to great + lengths to extract the supposedly relevant keys from the CA. + + For some particular INR, say Bill's Bait and Sushi's Autonomous + System (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, an IT vendor, 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. + + Then there is the temporal issue. The owner of that 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 does one determine if the signature on + the real world document is 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 might, conduct to + assure the INRs are in fact owned by a registrant. + + 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. 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. + +
+ +
+ + Attempts to use RPKI data to authenticate real world documents or + other artifacts requiring identity are invalid and misleading. + + 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 and 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. + + 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 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. + +
+ +
+ + This document has no IANA Considerations. + + + +
+ +
+ + The authors thank George Michaelson and Job Snijders for lively + discussion; and last but not least, Biff for the loan of Bill's Bait + and Sushi. + +
+ + + + + + + + + + + + + + + + + + + + + +