idnits 2.17.1 draft-ietf-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 (May 4, 2021) is 1087 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-02 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: November 5, 2021 Vigil Security 6 May 4, 2021 8 The I in RPKI does not stand for Identity 9 draft-ietf-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 November 5, 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, e.g. Router Keying 76 for BGPsec, [RFC8635]. 78 In security terms the phrase "Public Key" implies there are also 79 private keys, a la [RFC5280]. And, as the RPKI has strong authority 80 over ownership of Internet Number Resources (INRs), there is a desire 81 to use the private keys to sign arbitrary documents to attest that 82 the 'owner' of those resources has attested to the authenticity of 83 those documents. Instead, it is an authorization to speak for the 84 named IP address blocks and AS numbers themselves, not their 85 unidentifiable owners. 87 There is a desire is to authenticate real world business transactions 88 with the signatures of INR holders. E.g. for Bill's Bait and Sushi 89 to use their AS in the RPKI to sign a Letter of Authorization (LOA) 90 for some other party to rack and stack hardware owned by BB&S. 91 Unfortunately, this is not formally feasible. 93 The I in RPKI actually stands for "Infrastructure," as in Resource 94 Public Key Infrastructure, not for "Identity". In fact, the RPKI 95 does not provide any association between INRs and the real world 96 holder(s) of those INRs. The RPKI provides authorization to speak 97 for the named IP address blocks and AS numbers. 99 2. The Bottom Line 101 The RPKI was designed and specified to sign certificates for use 102 within the RPKI itself and to generate Route Origin Authorizations 103 (ROAs), [RFC6480], for use in routing. Its design intentionally 104 precluded use for attesting to real world identity as, among other 105 issues, it would expose the Certification Authority (CA) to 106 liability. 108 That the RPKI does not authenticate real world identity is a feature 109 not a bug. If it tried to do so, aside from the liability, it would 110 end in a world of complexity with no proof of termination, as X.400 111 learned. 113 Registries such as the Regional Internet Resistries (RIRs) provide 114 INR to real world identity mapping through whois and similar 115 services. They claim to be authoritative, at least for for the INRs 116 which they allocate. 118 RPKI-based credentials of INRs MUST NOT be used to authenticate real 119 world documents or transactions without some formal external 120 authentication of the INR and the authority for the actually 121 anonymous INR holder to authenticate the particular document or 122 transaction. 124 3. Discussion 126 Normally, the INR holder does not hold the private key attesting to 127 their resources; the Certification Authority (CA) does. The INR 128 holder has a real world business relationship with the CA for which 129 they have likely signed real world documents. 131 As the INR owner does not have the keying material, they rely on the 132 CA, to which they presumably must present credentials, to manipulate 133 their INRs. These credentials may be userid/password (with two 134 factor authentication one hopes), a hardware token, client browser 135 certificates, etc. 137 Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and 138 [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the 139 supposedly relevant keys from the CA. 141 For some particular INR, say Bill's Bait and Sushi's Autonomous 142 System (AS) number, someone out on the net probably has the 143 credentials to the CA account in which BB&S's INRs are registered. 145 That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, 146 or the Government of Elbonia. One simply can not know. 148 In large operations, INR management is often compartmentalized with 149 no authority over anything beyond dealing with INR registration. The 150 INR manager for Bill's Bait and Sushi is unlikely to be authorized to 151 conduct bank transactions for BB&S, or even to authorize access to 152 BB&S's servers in some colocation facility. 154 Then there is the temporal issue. The owner of that AS may be BB&S 155 today when some document was signed, and could be the Government of 156 Elbonia tomorrow. Or the resource could have been administratively 157 moved from one CA to another, likely requiring a change of keys. If 158 so, how does one determine if the signature on the real world 159 document is still valid? 161 While Ghostbuster Records [RFC6493] may seem to identify real world 162 entities, their semantic content is completely arbitrary, and does 163 not attest to INR ownership. They are merely clues for operational 164 support contact in case of technical RPKI problems. 166 Usually, before registering INRs, CAs require proof of INR ownership 167 via external documentation and authorities. It is somewhat droll 168 that the CPS Template, [RFC7382], does not mention any diligence the 169 CA must, or even might, conduct to assure the INRs are in fact owned 170 by a registrant. 172 Autonomous System Numbers do not identify real world entities. They 173 are identifiers some network operators 'own' and are only used in 174 loop detection in routing. They have no inherent semantics other 175 than uniqueness. 177 The RPKI base document, [RFC6480], Section 2.1 says explicitly "An 178 important property of this PKI is that certificates do not attest to 179 the identity of the subject." 181 The Template for a Certification Practice Statement (CPS) for the 182 Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear 183 that "The Subject name in each certificate SHOULD NOT be meaningful;" 184 and goes on to do so at some length. 186 4. Security Considerations 188 Attempts to use RPKI data to authenticate real world documents or 189 other artifacts requiring identity are invalid and misleading. 191 When a document is signed with the private key associated with a RPKI 192 certificate, the signer is speaking for the INRs, the IP address 193 space and Autonomous System (AS) numbers, in the certificate. This 194 is not an identity; this is an authorization. In schemes such as 195 [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the 196 signed message further narrows this scope of INRs. The INRs in the 197 message are a subset of the INRs in the certificate. If the 198 signature is valid, the message content comes from a party that is 199 authorized to speak for that subset of INRs. 201 Control of INRs for an entity could be used to falsely authorize 202 transactions or documents for which the INR manager has no authority. 204 RPKI-based credentials of INRs MUST NOT be used to authenticate real 205 world documents or transactions without some formal external 206 authentication of the INR and the authority for the actually 207 anonymous INR holder to authenticate the particular document or 208 transaction. 210 5. IANA Considerations 212 This document has no IANA Considerations. 214 6. Acknowledgments 216 The authors thank George Michaelson and Job Snijders for lively 217 discussion; and last but not least, Biff for the loan of Bill's Bait 218 and Sushi. 220 7. References 222 7.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 230 Housley, R., and W. Polk, "Internet X.509 Public Key 231 Infrastructure Certificate and Certificate Revocation List 232 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 233 . 235 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 236 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 237 February 2012, . 239 [RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a 240 Certification Practice Statement (CPS) for the Resource 241 PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, 242 April 2015, . 244 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 245 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 246 May 2017, . 248 [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for 249 BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, 250 . 252 7.2. Informative References 254 [I-D.ietf-sidrops-rpki-rsc] 255 Snijders, J., "Resource Public Key Infrastructure (RPKI) 256 object profile for Signed Checklist (RSC)", draft-ietf- 257 sidrops-rpki-rsc-02 (work in progress), March 2021. 259 [I-D.ietf-sidrops-rpki-rta] 260 Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., 261 and M. Hoffmann, "A profile for Resource Tagged 262 Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work 263 in progress), January 2021. 265 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 266 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 267 February 2012, . 269 Authors' Addresses 271 Randy Bush 272 Arrcus & Internet Initiative Japan 273 5147 Crystal Springs 274 Bainbridge Island, WA 98110 275 US 277 Email: randy@psg.com 279 Russ Housley 280 Vigil Security, LLC 281 516 Dranesville Road 282 Herndon, VA 20170 283 US 285 Email: housley@vigilsec.com