idnits 2.17.1 draft-ietf-sidrops-rpki-has-no-identity-07.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 (19 April 2022) is 710 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) == Unused Reference: 'I-D.ietf-sidrops-aspa-profile' is defined on line 268, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6480 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-profile-07 == Outdated reference: A later version (-11) exists of draft-ietf-sidrops-rpki-rsc-06 Summary: 1 error (**), 0 flaws (~~), 4 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: 21 October 2022 Vigil Security 6 19 April 2022 8 The I in RPKI does not stand for Identity 9 draft-ietf-sidrops-rpki-has-no-identity-07 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 specifies that RPKI does not associate to 16 the INR holder. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 [RFC2119] [RFC8174] when, and only when, they appear in all 24 capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 21 October 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. The RPKI is for Authorization . . . . . . . . . . . . . . . . 3 61 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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," which are collectively known as 75 Internet Number Resources (INRs). Since initial deployment, the RPKI 76 has grown to include other similar resource and routing data, e.g. 77 Router Keying for BGPsec, [RFC8635]. 79 In security terms, the phrase "Public Key" implies there is also a 80 corresponding private key [RFC5280]. The RPKI provides strong 81 authority to the current holder of INRs; however, some people a have 82 a desire to use RPKI private keys to sign arbitrary documents as the 83 INR 'holder' of those resources with the inappropriate expectation 84 that the signature will be considered an attestation to the 85 authenticity of the document content. But in reality, the RPKI 86 certificate is only an authorization to speak for the explicitly 87 identified INRs; it is explicitly not intended for authentication of 88 the 'holders' of the INRs. This situation is emphasized in 89 Section 2.1 of [RFC6480]. 91 It has been suggested that one could authenticate real-world business 92 transactions with the signatures of INR holders. E.g. Bill's Bait 93 and Sushi (BB&S) could use the private key attesting to that they are 94 the holder of their AS in the RPKI to sign a Letter of Authorization 95 (LOA) for some other party to rack and stack hardware owned by BB&S. 96 Unfortunately, while this may be technically possible, it is neither 97 appropriate nor meaningful. 99 The I in RPKI actually stands for "Infrastructure," as in Resource 100 Public Key Infrastructure, not for "Identity". In fact, the RPKI 101 does not provide any association between INRs and the real world 102 holder(s) of those INRs. The RPKI provides authorization to make 103 assertions only regarding Internet Number Resources, such as IP 104 prefixes or AS numbers, and data such as ASPA 105 [I-D.ietf-sidrops-aspa-profile]records. 107 In short, avoid the desire to use RPKI certificates for any purpose 108 other than the verification of authorizations associated with the 109 delegation of INRs or attestations related to INRs. Instead, 110 recognize that these authorizations and attestations take place 111 irrespective of the identity of a RPKI private key holder. 113 2. The RPKI is for Authorization 115 The RPKI was designed and specified to sign certificates for use 116 within the RPKI itself and to generate Route Origin Authorizations 117 (ROAs), [RFC6480], for use in routing. Its design intentionally 118 precluded use for attesting to real-world identity as, among other 119 issues, it would expose the Certification Authority (CA) to 120 liability. 122 That the RPKI does not authenticate real-world identity is by design. 123 If it tried to do so, aside from the liability, it would end in a 124 world of complexity with no proof of termination. 126 Registries such as the Regional Internet Registries (RIRs) provide 127 INR to real-world identity mapping through WHOIS, [RFC3912], and 128 similar services. They claim to be authoritative, at least for the 129 INRs which they allocate. 131 That is, RPKI-based credentials of INRs MUST NOT be used to 132 authenticate real-world documents or transactions. That might be 133 done with some formal external authentication of authority allowing 134 an otherwise anonymous INR holder to authenticate the particular 135 document or transaction. Given such external, i.e. non-RPKI, 136 verification of authority, the use of RPKI-based credentials adds no 137 authenticity. 139 3. Discussion 141 The RPKI base document, [RFC6480], Section 2.1 says explicitly "An 142 important property of this PKI is that certificates do not attest to 143 the identity of the subject." 145 The Template for a Certification Practice Statement (CPS) for the 146 Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear 147 that "The Subject name in each certificate SHOULD NOT be meaningful;" 148 and goes on to do so at some length. 150 Normally, the INR holder does not hold the private key attesting to 151 their resources; the Certification Authority (CA) does. The INR 152 holder has a real-world business relationship with the CA for which 153 they have likely signed real-world documents. 155 As the INR holder does not have the keying material, they rely on the 156 CA, to which they presumably present credentials, to manipulate their 157 INRs. These credentials may be userid/password (with two factor 158 authentication one hopes), a hardware token, client browser 159 certificates, etc. 161 Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and 162 [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the 163 supposedly relevant keys from the CA. 165 For some particular INR, say Bill's Bait and Sushi's Autonomous 166 System (AS) number, someone out on the net probably has the 167 credentials to the CA account in which BB&S's INRs are registered. 168 That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, 169 or the Government of Elbonia. One simply can not know. 171 In large organizations, INR management is often compartmentalized 172 with no authority over anything beyond dealing with INR registration. 173 The INR manager for Bill's Bait and Sushi is unlikely to be 174 authorized to conduct bank transactions for BB&S, or even to 175 authorize access to BB&S's servers in some colocation facility. 177 Then there is the temporal issue. The holder of that AS may be BB&S 178 today when some document was signed, and could be the Government of 179 Elbonia tomorrow. Or the resource could have been administratively 180 moved from one CA to another, likely requiring a change of keys. If 181 so, how does one determine if the signature on the real-world 182 document is still valid? 183 While Ghostbuster Records [RFC6493] may seem to identify real-world 184 entities, their semantic content is completely arbitrary, and does 185 not attest to holding of any INRs. They are merely clues for 186 operational support contact in case of technical RPKI problems. 188 Usually, before registering INRs, CAs require proof of an INR holding 189 via external documentation and authorities. It is somewhat droll 190 that the CPS Template, [RFC7382], does not mention any diligence the 191 CA must, or even might, conduct to assure the INRs are in fact owned 192 by a registrant. 194 That someone can provide 'proof of possession' of the private key 195 signing over a particular INR should not be taken to imply that they 196 are a valid legal representative of the organization in possession of 197 that INR. They could be just an INR administrative person. 199 Autonomous System Numbers do not identify real-world entities. They 200 are identifiers some network operators 'own' and are only used for 201 loop detection in routing. They have no inherent semantics other 202 than uniqueness. 204 4. Security Considerations 206 Attempts to use RPKI data to authenticate real-world documents or 207 other artifacts requiring identity, while possibly cryptographically 208 valid within the RPKI, are misleading as to any authenticity. 210 When a document is signed with the private key associated with an 211 RPKI certificate, the signer is speaking for the INRs, the IP address 212 space and Autonomous System (AS) numbers, in the certificate. This 213 is not an identity; this is an authorization. In schemes such as 214 [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the 215 signed message further narrows this scope of INRs. The INRs in the 216 message are a subset of the INRs in the certificate. If the 217 signature is valid, the message content comes from a party that is 218 authorized to speak for that subset of INRs. 220 Control of INRs for an entity could be used to falsely authorize 221 transactions or documents for which the INR manager has no authority. 223 5. IANA Considerations 225 This document has no IANA Considerations. 227 6. Acknowledgments 229 The authors thank George Michaelson and Job Snijders for lively 230 discussion, Geoff Huston for some more formal text, Ties de Kock for 231 useful suggestions, many directorate and IESG reviewers, and last but 232 not least, Biff for the loan of Bill's Bait and Sushi. 234 7. References 236 7.1. Normative References 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 244 Housley, R., and W. Polk, "Internet X.509 Public Key 245 Infrastructure Certificate and Certificate Revocation List 246 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 247 . 249 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 250 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 251 February 2012, . 253 [RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a 254 Certification Practice Statement (CPS) for the Resource 255 PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, 256 April 2015, . 258 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 259 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 260 May 2017, . 262 [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for 263 BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, 264 . 266 7.2. Informative References 268 [I-D.ietf-sidrops-aspa-profile] 269 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 270 and R. Housley, "A Profile for Autonomous System Provider 271 Authorization", Work in Progress, Internet-Draft, draft- 272 ietf-sidrops-aspa-profile-07, 31 January 2022, 273 . 276 [I-D.ietf-sidrops-rpki-rsc] 277 Snijders, J., Harrison, T., and B. Maddison, "Resource 278 Public Key Infrastructure (RPKI) object profile for Signed 279 Checklist (RSC)", Work in Progress, Internet-Draft, draft- 280 ietf-sidrops-rpki-rsc-06, 12 February 2022, 281 . 284 [I-D.ietf-sidrops-rpki-rta] 285 Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels, 286 T., and M. Hoffmann, "A profile for Resource Tagged 287 Attestations (RTAs)", Work in Progress, Internet-Draft, 288 draft-ietf-sidrops-rpki-rta-00, 21 January 2021, 289 . 292 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 293 DOI 10.17487/RFC3912, September 2004, 294 . 296 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 297 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 298 February 2012, . 300 Authors' Addresses 302 Randy Bush 303 Arrcus & Internet Initiative Japan 304 5147 Crystal Springs 305 Bainbridge Island, WA 98110 306 United States of America 307 Email: randy@psg.com 309 Russ Housley 310 Vigil Security, LLC 311 516 Dranesville Road 312 Herndon, VA, 20170 313 United States of America 314 Email: housley@vigilsec.com