idnits 2.17.1 draft-ietf-sidrops-rpki-has-no-identity-01.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 (8 August 2021) is 992 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-04 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: 9 February 2022 Vigil Security 6 8 August 2021 8 The I in RPKI does not stand for Identity 9 draft-ietf-sidrops-rpki-has-no-identity-01 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 9 February 2022. 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 7.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The Resource Public Key Infrastructure (RPKI), see [RFC6480], 72 "represents the allocation hierarchy of IP address space and 73 Autonomous System (AS) numbers." Though since, it has grown to 74 include other similar resource and routing data, e.g. Router Keying 75 for BGPsec, [RFC8635]. 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. But in reality, it is an authorization to speak for 83 the named IP address blocks and AS numbers themselves, not their 84 unidentifiable owners. 86 It has been suggested that one could authenticate real world business 87 transactions with the signatures of INR holders. E.g. Bill's Bait 88 and Sushi could use their AS in the RPKI to sign a Letter of 89 Authorization (LOA) for some other party to rack and stack hardware 90 owned by BB&S. 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. Its 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 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 Note that, if there is sufficient external, i.e. non-RPKI, 124 verifcation of authority, then use of RPKI-based credentials seems 125 superfluous. 127 3. Discussion 129 The RPKI base document, [RFC6480], Section 2.1 says explicitly "An 130 important property of this PKI is that certificates do not attest to 131 the identity of the subject." 133 The Template for a Certification Practice Statement (CPS) for the 134 Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear 135 that "The Subject name in each certificate SHOULD NOT be meaningful;" 136 and goes on to do so at some length. 138 Normally, the INR holder does not hold the private key attesting to 139 their resources; the Certification Authority (CA) does. The INR 140 holder has a real world business relationship with the CA for which 141 they have likely signed real world documents. 143 As the INR owner does not have the keying material, they rely on the 144 CA, to which they presumably present credentials, to manipulate their 145 INRs. These credentials may be userid/password (with two factor 146 authentication one hopes), a hardware token, client browser 147 certificates, etc. 149 Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and 150 [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the 151 supposedly relevant keys from the CA. 153 For some particular INR, say Bill's Bait and Sushi's Autonomous 154 System (AS) number, someone out on the net probably has the 155 credentials to the CA account in which BB&S's INRs are registered. 156 That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, 157 or the Government of Elbonia. One simply can not know. 159 In large organizations, INR management is often compartmentalized 160 with no authority over anything beyond dealing with INR registration. 161 The INR manager for Bill's Bait and Sushi is unlikely to be 162 authorized to conduct bank transactions for BB&S, or even to 163 authorize access to BB&S's servers in some colocation facility. 165 Then there is the temporal issue. The owner of that AS may be BB&S 166 today when some document was signed, and could be the Government of 167 Elbonia tomorrow. Or the resource could have been administratively 168 moved from one CA to another, likely requiring a change of keys. If 169 so, how does one determine if the signature on the real world 170 document is still valid? 172 While Ghostbuster Records [RFC6493] may seem to identify real world 173 entities, their semantic content is completely arbitrary, and does 174 not attest to INR ownership. They are merely clues for operational 175 support contact in case of technical RPKI problems. 177 Usually, before registering INRs, CAs require proof of INR ownership 178 via external documentation and authorities. It is somewhat droll 179 that the CPS Template, [RFC7382], does not mention any diligence the 180 CA must, or even might, conduct to assure the INRs are in fact owned 181 by a registrant. 183 Autonomous System Numbers do not identify real world entities. They 184 are identifiers some network operators 'own' and are only used for 185 loop detection in routing. They have no inherent semantics other 186 than uniqueness. 188 4. Security Considerations 190 Attempts to use RPKI data to authenticate real world documents or 191 other artifacts requiring identity are invalid and misleading. 193 When a document is signed with the private key associated with a RPKI 194 certificate, the signer is speaking for the INRs, the IP address 195 space and Autonomous System (AS) numbers, in the certificate. This 196 is not an identity; this is an authorization. In schemes such as 197 [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the 198 signed message further narrows this scope of INRs. The INRs in the 199 message are a subset of the INRs in the certificate. If the 200 signature is valid, the message content comes from a party that is 201 authorized to speak for that subset of INRs. 203 Control of INRs for an entity could be used to falsely authorize 204 transactions or documents for which the INR manager has no authority. 206 RPKI-based credentials of INRs MUST NOT be used to authenticate real 207 world documents or transactions without some formal external 208 authentication of the INR and the authority for the actually 209 anonymous INR holder to authenticate the particular document or 210 transaction. 212 5. IANA Considerations 214 This document has no IANA Considerations. 216 6. Acknowledgments 218 The authors thank George Michaelson and Job Snijders for lively 219 discussion; and last but not least, Biff for the loan of Bill's Bait 220 and Sushi. 222 7. References 224 7.1. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 232 Housley, R., and W. Polk, "Internet X.509 Public Key 233 Infrastructure Certificate and Certificate Revocation List 234 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 235 . 237 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 238 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 239 February 2012, . 241 [RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a 242 Certification Practice Statement (CPS) for the Resource 243 PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, 244 April 2015, . 246 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 247 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 248 May 2017, . 250 [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for 251 BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, 252 . 254 7.2. Informative References 256 [I-D.ietf-sidrops-rpki-rsc] 257 Snijders, J., Harrison, T., and B. Maddison, "Resource 258 Public Key Infrastructure (RPKI) object profile for Signed 259 Checklist (RSC)", Work in Progress, Internet-Draft, draft- 260 ietf-sidrops-rpki-rsc-04, 31 May 2021, 261 . 264 [I-D.ietf-sidrops-rpki-rta] 265 Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels, 266 T., and M. Hoffmann, "A profile for Resource Tagged 267 Attestations (RTAs)", Work in Progress, Internet-Draft, 268 draft-ietf-sidrops-rpki-rta-00, 21 January 2021, 269 . 272 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 273 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 274 February 2012, . 276 Authors' Addresses 277 Randy Bush 278 Arrcus & Internet Initiative Japan 279 5147 Crystal Springs 280 Bainbridge Island, WA 98110 281 United States of America 283 Email: randy@psg.com 285 Russ Housley 286 Vigil Security, LLC 287 516 Dranesville Road 288 Herndon, VA, 20170 289 United States of America 291 Email: housley@vigilsec.com