idnits 2.17.00 (12 Aug 2021) /tmp/idnits50166/draft-ietf-sidrops-rpki-has-no-identity-06.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 document date (14 April 2022) is 37 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 (-07) exists of draft-ietf-sidrops-rpki-rsc-06 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: 16 October 2022 Vigil Security 6 14 April 2022 8 The I in RPKI does not stand for Identity 9 draft-ietf-sidrops-rpki-has-no-identity-06 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 'holder' 15 of 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 16 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. The RPKI is for Authorization . . . . . . . . . . . . . . . . 3 60 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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," which are collectively known as 74 Internet Number Resources (INRs). Since initial deployment, the RPKI 75 has grown to include other similar resource and routing data, e.g. 76 Router Keying for BGPsec, [RFC8635]. 78 In security terms, the phrase "Public Key" implies there is also a 79 corresponding private key [RFC5280]. The RPKI provides strong 80 authority to the current holder of INRs; however, some people a have 81 a desire to use RPKI private keys to sign arbitrary documents as the 82 INR 'holder' of those resources with the inappropriate expectation 83 that the signature will be considered an attestation to the 84 authenticity of the document content. But in reality, the RPKI 85 certificate is only an authorization to speak for the explicitly 86 identified INRs; it is explicitly not intended for authentication of 87 the 'holders' of the INRs. This situation is emphasized in 88 Section 2.1 of [RFC6480]. 90 It has been suggested that one could authenticate real-world business 91 transactions with the signatures of INR holders. E.g. Bill's Bait 92 and Sushi could use the private key attesting to that they are the 93 holder of their AS in the RPKI to sign a Letter of Authorization 94 (LOA) for some other party to rack and stack hardware owned by BB&S. 95 Unfortunately, while this may be technically possible, it is neither 96 appropriate nor meaningful. 98 The I in RPKI actually stands for "Infrastructure," as in Resource 99 Public Key Infrastructure, not for "Identity". In fact, the RPKI 100 does not provide any association between INRs and the real world 101 holder(s) of those INRs. The RPKI provides authorization to make 102 assertions only regarding named IP address blocks, AS numbers, etc. 104 In short, avoid the desire to use RPKI certificates for any purpose 105 other than the verification of authorizations associated with the 106 delegation of INRs or attestations related to INRs. Instead, 107 recognize that these authorizations and attestations take place 108 irrespective of the identity of a RPKI private key holder. 110 2. The RPKI is for Authorization 112 The RPKI was designed and specified to sign certificates for use 113 within the RPKI itself and to generate Route Origin Authorizations 114 (ROAs), [RFC6480], for use in routing. Its design intentionally 115 precluded use for attesting to real-world identity as, among other 116 issues, it would expose the Certification Authority (CA) to 117 liability. 119 That the RPKI does not authenticate real-world identity is by design. 120 If it tried to do so, aside from the liability, it would end in a 121 world of complexity with no proof of termination, as X.400 learned. 123 Registries such as the Regional Internet Registries (RIRs) provide 124 INR to real-world identity mapping through WHOIS, [RFC3912], and 125 similar services. They claim to be authoritative, at least for the 126 INRs which they allocate. 128 PKI operations MUST NOT be performed with RPKI certificates other 129 than exactly as described, and for the purposes described, in 130 [RFC6480]. That is, RPKI-based credentials of INRs MUST NOT be used 131 to authenticate real-world documents or transactions without some 132 formal external authentication of the INR and the authority for the 133 actually anonymous INR holder to authenticate the particular document 134 or transaction. 136 I.e., RPKI-based credentials of INRs MUST NOT be used to authenticate 137 real-world documents or transactions without some formal external 138 authentication of the INR and the authority for the actually 139 anonymous INR holder to authenticate the particular document or 140 transaction. 142 Given sufficient external, i.e. non-RPKI, verification of authority, 143 the use of RPKI-based credentials seems superfluous. 145 3. Discussion 147 The RPKI base document, [RFC6480], Section 2.1 says explicitly "An 148 important property of this PKI is that certificates do not attest to 149 the identity of the subject." 151 The Template for a Certification Practice Statement (CPS) for the 152 Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear 153 that "The Subject name in each certificate SHOULD NOT be meaningful;" 154 and goes on to do so at some length. 156 Normally, the INR holder does not hold the private key attesting to 157 their resources; the Certification Authority (CA) does. The INR 158 holder has a real-world business relationship with the CA for which 159 they have likely signed real-world documents. 161 As the INR holder does not have the keying material, they rely on the 162 CA, to which they presumably present credentials, to manipulate their 163 INRs. These credentials may be userid/password (with two factor 164 authentication one hopes), a hardware token, client browser 165 certificates, etc. 167 Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and 168 [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the 169 supposedly relevant keys from the CA. 171 For some particular INR, say Bill's Bait and Sushi's Autonomous 172 System (AS) number, someone out on the net probably has the 173 credentials to the CA account in which BB&S's INRs are registered. 174 That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, 175 or the Government of Elbonia. One simply can not know. 177 In large organizations, INR management is often compartmentalized 178 with no authority over anything beyond dealing with INR registration. 179 The INR manager for Bill's Bait and Sushi is unlikely to be 180 authorized to conduct bank transactions for BB&S, or even to 181 authorize access to BB&S's servers in some colocation facility. 183 Then there is the temporal issue. The holder of that AS may be BB&S 184 today when some document was signed, and could be the Government of 185 Elbonia tomorrow. Or the resource could have been administratively 186 moved from one CA to another, likely requiring a change of keys. If 187 so, how does one determine if the signature on the real-world 188 document is still valid? 190 While Ghostbuster Records [RFC6493] may seem to identify real-world 191 entities, their semantic content is completely arbitrary, and does 192 not attest to holding of any INRs. They are merely clues for 193 operational support contact in case of technical RPKI problems. 195 Usually, before registering INRs, CAs require proof of an INR holding 196 via external documentation and authorities. It is somewhat droll 197 that the CPS Template, [RFC7382], does not mention any diligence the 198 CA must, or even might, conduct to assure the INRs are in fact owned 199 by a registrant. 201 That someone can provide 'proof of possession' of the private key 202 signing over a particular INR should not be taken to imply that they 203 are a valid legal representative of the organization in possession of 204 that INR. They could be just an INR administrative person. 206 Autonomous System Numbers do not identify real-world entities. They 207 are identifiers some network operators 'own' and are only used for 208 loop detection in routing. They have no inherent semantics other 209 than uniqueness. 211 4. Security Considerations 213 Attempts to use RPKI data to authenticate real-world documents or 214 other artifacts requiring identity are invalid and misleading. 216 When a document is signed with the private key associated with an 217 RPKI certificate, the signer is speaking for the INRs, the IP address 218 space and Autonomous System (AS) numbers, in the certificate. This 219 is not an identity; this is an authorization. In schemes such as 220 [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the 221 signed message further narrows this scope of INRs. The INRs in the 222 message are a subset of the INRs in the certificate. If the 223 signature is valid, the message content comes from a party that is 224 authorized to speak for that subset of INRs. 226 Control of INRs for an entity could be used to falsely authorize 227 transactions or documents for which the INR manager has no authority. 229 5. IANA Considerations 231 This document has no IANA Considerations. 233 6. Acknowledgments 235 The authors thank George Michaelson and Job Snijders for lively 236 discussion, Geoff Huston for some more formal text, Ties de Kock for 237 useful suggestions, and last but not least, Biff for the loan of 238 Bill's Bait and Sushi. 240 7. References 242 7.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 250 Housley, R., and W. Polk, "Internet X.509 Public Key 251 Infrastructure Certificate and Certificate Revocation List 252 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 253 . 255 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 256 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 257 February 2012, . 259 [RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a 260 Certification Practice Statement (CPS) for the Resource 261 PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, 262 April 2015, . 264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 266 May 2017, . 268 [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for 269 BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, 270 . 272 7.2. Informative References 274 [I-D.ietf-sidrops-rpki-rsc] 275 Snijders, J., Harrison, T., and B. Maddison, "Resource 276 Public Key Infrastructure (RPKI) object profile for Signed 277 Checklist (RSC)", Work in Progress, Internet-Draft, draft- 278 ietf-sidrops-rpki-rsc-06, 12 February 2022, 279 . 282 [I-D.ietf-sidrops-rpki-rta] 283 Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels, 284 T., and M. Hoffmann, "A profile for Resource Tagged 285 Attestations (RTAs)", Work in Progress, Internet-Draft, 286 draft-ietf-sidrops-rpki-rta-00, 21 January 2021, 287 . 290 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 291 DOI 10.17487/RFC3912, September 2004, 292 . 294 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 295 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 296 February 2012, . 298 Authors' Addresses 300 Randy Bush 301 Arrcus & Internet Initiative Japan 302 5147 Crystal Springs 303 Bainbridge Island, WA 98110 304 United States of America 305 Email: randy@psg.com 307 Russ Housley 308 Vigil Security, LLC 309 516 Dranesville Road 310 Herndon, VA, 20170 311 United States of America 312 Email: housley@vigilsec.com