idnits 2.17.1 draft-ymbk-sidrops-rpki-has-no-identity-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 16, 2021) is 1136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6480 == Outdated reference: A later version (-11) exists of draft-ietf-sidrops-rpki-rsc-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus & Internet Initiative Japan 4 Intended status: Standards Track R. Housley 5 Expires: September 17, 2021 Vigil Security 6 March 16, 2021 8 The I in RPKI does not stand for Identity 9 draft-ymbk-sidrops-rpki-has-no-identity-00 11 Abstract 13 There is a false notion that Internet Number Resources (INRs) in the 14 RPKI can be associated with the real world identity of the 'owner' of 15 an INR. This document attempts to put that notion to rest. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 21 "OPTIONAL" in this document are to be interpreted as described in BCP 22 14 [RFC2119] [RFC8174] when, and only when, they appear in all 23 capitals, as shown here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 17, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 7.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 The Resource Public Key Infrastructure (RPKI), see [RFC6480], 73 "represents the allocation hierarchy of IP address space and 74 Autonomous System (AS) numbers." Though since, it has grown to 75 include other similar resource and routing data. 77 In security terms the phrase "Public Key" implies there are also 78 private keys, a la [RFC5280]. And, as the RPKI has strong authority 79 over ownership of Internet Number Resources (INRs), there is a desire 80 to use the private keys to sign arbitrary documents to attest that 81 the 'owner' of those resources has attested to the authenticity of 82 those documents. Instead, it is an authorization to speak for the 83 named IP address blocks and AS numbers themselves, not their 84 unidentifiable owners. 86 There is a desire is to authenticate real world business transactions 87 with the signatures of INR holders. E.g. for Bill's Bait and Sushi 88 to use their AS in the RPKI to sign a Letter of Authorization (LOA) 89 for some other party to rack and stack hardware owned by BB&S. 90 Unfortunately, this is not formally feasible. 92 The I in RPKI actually stands for "Infrastructure," as in Resource 93 Public Key Infrastructure, not for "Identity". In fact, the RPKI 94 does not provide any association between INRs and the real world 95 holder(s) of those INRs. The RPKI provides authorization to speak 96 for the named IP address blocks and AS numbers. 98 2. The Bottom Line 100 The RPKI was designed and specified to sign certificates for use 101 within the RPKI itself and to generate Route Origin Authorizations 102 (ROAs), [RFC6480], for use in routing. It's design intentionally 103 precluded use for attesting to real world identity as, among other 104 issues, it would expose the Certification Authority (CA) to 105 liability. 107 That the RPKI does not authenticate real world identity is a feature 108 not a bug. If it tried to do so, aside from the liability, it would 109 end in a world of complexity with no proof of termination, as X.400 110 learned. 112 Registries such as the Regional Internet Resistries (RIRs) provide 113 INR to real world identity mapping through whois and similar 114 services. They claim to be authoritative, at least for for the INRs 115 which they allocate. 117 RPKI-based credentials of INRs MUST NOT be used to authenticate real 118 world documents or transactions without some formal external 119 authentication of the INR and the authority for the actually 120 anonymous INR holder to authenticate the particular document or 121 transaction. 123 3. Discussion 125 Normally, the INR holder does not hold the private key attesting to 126 their resources; the Certification Authority (CA) does. The INR 127 holder has a real world business relationship with the CA for which 128 they have likely signed real world documents. 130 As the INR owner does not have the keying material, they rely on the 131 CA, to which they presumably must present credentials, to manipulate 132 their INRs. These credentials may be userid/password (with two 133 factor authentication one hopes), a hardware token, client browser 134 certificates, etc. 136 Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and 137 [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the 138 supposedly relevant keys from the CA. 140 For some particular INR, say Bill's Bait and Sushi's Autonompus 141 System (AS) number, someone out on the net probably has the 142 credentials to the CA account in which BB&S's INRs are registered. 143 That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, 144 or the Government of Elbonia. One simply can not know. 146 In large operations, INR management is often compartmentalized with 147 no authority over anything beyond dealing with INR registration. The 148 INR manager for Bill's Bait and Sushi is unlikely to be authorized to 149 conduct bank transactions for BB&S, or even to authorize access to 150 BB&S's servers in some colocation facility. 152 Then there is the temporal issue. The owner of that AS may be BB&S 153 today when some document was signed, and could be the Government of 154 Elbonia tomorrow. Or the resource could have been administratively 155 moved from one CA to another, likely requiring a change of keys. If 156 so, how does one determine if the signature on the real world 157 document is still valid? 159 While Ghostbuster Records [RFC6493] may seem to identify real world 160 entities, their semantic content is completely arbitrary, and does 161 not attest to INR ownership. They are merely clues for operational 162 support contact in case of technical RPKI problems. 164 Usually, before registering INRs, CAs require proof of INR ownership 165 via external documentation and authorities. It is somewhat droll 166 that the CPS Template, [RFC7382], does not mention any diligence the 167 CA must, or even might, conduct to assure the INRs are in fact owned 168 by a registrant. 170 Autonomous System Numbers do not identify real world entities. They 171 are identifiers some network operators 'own' and are only used in 172 loop detection in routing. They have no inherent semantics other 173 than uniqueness. 175 The RPKI base document, [RFC6480], Section 2.1 says explicitly "An 176 important property of this PKI is that certificates do not attest to 177 the identity of the subject." 179 The Template for a Certification Practice Statement (CPS) for the 180 Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear 181 that "The Subject name in each certificate SHOULD NOT be meaningful;" 182 and goes on to do so at some length. 184 4. Security Considerations 186 Attempts to use RPKI data to authenticate real world documents or 187 other artifacts requiring identity are invalid and misleading. 189 When a document is signed with the private key associated with a RPKI 190 certificate, the signer is speaking for the INRs, the IP address 191 space and Autonomous System (AS) numbers, in the certificate. This 192 is not an identity; this is an authorization. In schemes such as 193 [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the 194 signed message further narrows this scope of INRs. The INRs in the 195 message are a subset of the INRs in the certificate. If the 196 signature is valid, the message content comes from a party that is 197 authorized to speak for that subset of INRs. 199 Control of INRs for an entity could be used to falsely authorize 200 transactions or documents for which the INR manager has no authority. 202 RPKI-based credentials of INRs MUST NOT be used to authenticate real 203 world documents or transactions without some formal external 204 authentication of the INR and the authority for the actually 205 anonymous INR holder to authenticate the particular document or 206 transaction. 208 5. IANA Considerations 210 This document has no IANA Considerations. 212 6. Acknowledgments 214 The authors thank George Michaelson and Job Snijders for lively 215 discussion; and last but not least, Biff for the loan of Bill's Bait 216 and Sushi. 218 7. References 220 7.1. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 228 Housley, R., and W. Polk, "Internet X.509 Public Key 229 Infrastructure Certificate and Certificate Revocation List 230 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 231 . 233 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 234 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 235 February 2012, . 237 [RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a 238 Certification Practice Statement (CPS) for the Resource 239 PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, 240 April 2015, . 242 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 243 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 244 May 2017, . 246 7.2. Informative References 248 [I-D.ietf-sidrops-rpki-rsc] 249 Snijders, J., "Resource Public Key Infrastructure (RPKI) 250 object profile for Signed Checklist (RSC)", draft-ietf- 251 sidrops-rpki-rsc-01 (work in progress), March 2021. 253 [I-D.ietf-sidrops-rpki-rta] 254 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 255 and M. Hoffmann, "A profile for Resource Tagged 256 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 257 in progress), January 2021. 259 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 260 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 261 February 2012, . 263 Authors' Addresses 265 Randy Bush 266 Arrcus & Internet Initiative Japan 267 5147 Crystal Springs 268 Bainbridge Island, WA 98110 269 US 271 Email: randy@psg.com 273 Russ Housley 274 Vigil Security, LLC 275 516 Dranesville Road 276 Herndon, VA 20170 277 US 279 Email: housley@vigilsec.com