idnits 2.17.1 draft-wiethuechter-tmrid-identity-claims-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Croa is special in that it is similiar to an issued automobile registration. The Operator, once it recieves Croa via a secure channel from the Registry, should store it somewhere safe to be recalled if required. It SHOULD not be public availibe, as it can be classified as Personally Identifiable Information (PII). -- The document date (9 March 2020) is 1481 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) == Missing Reference: 'RFC4398' is mentioned on line 199, but not defined == Missing Reference: 'RFC3498' is mentioned on line 345, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP A. Wiethuechter 3 Internet-Draft S. Card 4 Intended status: Standards Track AX Enterprize 5 Expires: 10 September 2020 R. Moskowitz 6 HTT Consulting 7 9 March 2020 9 TMRID Identity Claims 10 draft-wiethuechter-tmrid-identity-claims-01 12 Abstract 14 This document describes 7 Identity Claims for use in Trustworthy 15 Multipurpose Remote ID. These Identity Claims will be used in 16 various Drone Remote ID Protocols (DRIP). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 10 September 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 53 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 2 54 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Host Identity Claims . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Why the term: Host Identity Claims . . . . . . . . . . . 3 57 3.2. Cxx Form . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2.1. Cxx Claims . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Cxy Form . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3.1. Cxy Claims . . . . . . . . . . . . . . . . . . . . . 7 61 3.4. Claim Registry on Aircraft . . . . . . . . . . . . . . . 7 62 4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. HHIT Delegation . . . . . . . . . . . . . . . . . . . . . 9 64 4.2. Operator . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3. Aircraft . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.4. Registry . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 This document expands on Hierarchical HIT Registries 78 [hhit-registries], defining defining 7 Identity Claims that are 79 created and distributed through the provisioning process of a 80 Unmanned Aircraft in Trustworthy Multipupose Remote ID (TMRID). 82 These claims establish trust for Hierarchical HITs 83 [hierarchical-hit]. They are then used in various Drone Remote ID 84 Protocols to establish the trustworthy claims needed to safely use 85 the data provided. 87 2. Terms and Definitions 89 2.1. Requirements Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 2.2. Definitions 99 HDA (Hierarchical HIT Domain Authority): The 14 bit field 100 identifying the HIT Domain Authority under a RAA. 102 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 104 RAA (Registered Assigning Authority): The 18 bit field identifying 105 the Hierarchical HIT Assigning Authority. 107 3. Host Identity Claims 109 Under TMRID there are a total of 7 Identity Claims created during the 110 provisioning of the UA to enable trustworthiness. This document 111 specifies the Host Identity Claims forms in detail, the individual 112 Host Identity Claims created and their use in TMRID. 114 3.1. Why the term: Host Identity Claims 116 Host Identity Claims are a form of digital certificates, specially 117 crafted for the UAS/USS ecosystem. The term "certificates" has been 118 avoided due to the significant technology and legal baggage around 119 X.509 certificates. 121 X.509 certificates and Public Key Infrastructure invokes more legal 122 and public policy considerations than probably any other electronic 123 communication sector. It emerged as a governmental platform for 124 trusted identity management and was pursued in intergovernmental 125 bodies with links into treaty instruments. 127 Thus there is a common expectation whenever the term "Certificates" 128 are used, and the term "Host Identity Claims" to carefully separate 129 these objects from X.509 objects and to emphasize their role as 130 claims. 132 3.2. Cxx Form 134 Cxx is a self-signed Host Identity Claim on entity 'x' with the 135 following format: 137 0 1 2 3 138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 139 +---------------+---------------+---------------+---------------+ 140 | | 141 | Hierarchical | 142 | Host Identity Tag | 143 | | 144 +---------------+---------------+---------------+---------------+ 145 | | 146 | | 147 | | 148 | Host | 149 | Identity | 150 | | 151 | | 152 | | 153 +---------------+---------------+---------------+---------------+ 154 | Expiration Timestamp | 155 +---------------+---------------+---------------+---------------+ 156 | | 157 | | 158 | | 159 | | 160 | | 161 | | 162 | | 163 | Signature | 164 | | 165 | | 166 | | 167 | | 168 | | 169 | | 170 | | 171 | | 172 +---------------+---------------+---------------+---------------+ 174 This Host Identity Claim form is used to stake an unverified claim 175 onto the specified HI/HHIT pairing, until an expiration time, to be 176 used in TMRID for entity 'x'. All Identity Claims of this form are 177 116 bytes in length. 179 The Expiration Timestamp MUST be current UNIX time, at the time of 180 signing, plus an offset into the future. This offset SHOULD be of 181 significant length (possibly years). 183 3.2.1. Cxx Claims 185 TMRID uses this form to create three self-signed Host Identity 186 Claims, which are then nested into other claims. The three claims 187 created are: 189 Aircraft on Aircraft (Caa) 191 Operator on Operator (Coo) 193 Registry on Registry (Crr) 195 These claims (and keypairs needed to create them) SHOULD be created 196 on the entities that own them. Crr on the Registry, Coo on the 197 Operator device and Caa on the Aircraft itself (if able). 199 These claims could also be stored in DNS under the CERT RR [RFC4398]. 200 The value of doing so is currently unknown. 202 3.3. Cxy Form 204 Cxy is a binding Host Identity Claim with the following format: 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +---------------+---------------+---------------+---------------+ 209 | | 210 . . 211 . Cxx . 212 . . 213 | | 214 +---------------+---------------+---------------+---------------+ 215 | | 216 . . 217 . Cyy . 218 . . 219 | | 220 +---------------+---------------+---------------+---------------+ 221 | Timestamp | 222 +---------------+---------------+---------------+---------------+ 223 | Expiration Timestamp | 224 +---------------+---------------+---------------+---------------+ 225 | | 226 | | 227 | | 228 | | 229 | | 230 | | 231 | | 232 | Signature | 233 | | 234 | | 235 | | 236 | | 237 | | 238 | | 239 | | 240 | | 241 +---------------+---------------+---------------+---------------+ 243 In the Cxy form a binding is asserted between the entities of 'x' and 244 'y'. The self-signed Host Identity Claims of Cxx and Cyy are used in 245 the new claim. The new Identity Claims is signed by the first party 246 (in the example above owner of Cxx) using their keypair. 248 During Host Identity Claim creation Timestamp and Expiration 249 Timestamp MUST be UNIX time (with Expiration Timestamp being created 250 using an offset setting it into the future) and MUST be no later than 251 the Expiration Timestamps found in Cxx and Cyy. 253 3.3.1. Cxy Claims 255 In TMRID two Identity Claims are created in the Cxy way, and third 256 one which is a special nesting of the created Host Identity Claims 257 (but following the Cxy form). These claims are as follows: 259 Registry on Operator (Cro): Using Crr and Coo as Cxx and Cyy 260 respectively, this claims asserts the Registry's Acceptance of the 261 claims in Coo. This MUST be performed on the Registry. It is 304 262 bytes in length. 264 Operator on Aircraft (Coa): Using Coo and Caa (Cxx and Cyy 265 respectively) this claim asserts a binding between an Operator and 266 Aircaft. This MUST be performed on the Operator device. It is 267 304 bytes in length. 269 Registry on Operator on Aircraft (Croa): A special claim created, 270 asserting the transitivity between Registry, Operator and 271 Aircraft. It uses Cro as Cxx and Coa as Cyy. This MUST be 272 performed on the Registry. It is 608 bytes in length. 274 The exact methods of transfering data between the entities are out of 275 scope of this document. It MUST be secure, especially when the 276 Registry sends back Croa. It is RECOMMENED that HIP be used if 277 possible, considering that HHITs are being used already. 279 Croa is special in that it is similiar to an issued automobile 280 registration. The Operator, once it recieves Croa via a secure 281 channel from the Registry, should store it somewhere safe to be 282 recalled if required. It SHOULD not be public availibe, as it can be 283 classified as Personally Identifiable Information (PII). 285 It is possible that Cro and/or Coa are stored in DNS and are public 286 availible as a result. If so, the CERT RR [RFC3498] should be used 287 to store them. It is unknown the value of storing them in DNS gives. 289 3.4. Claim Registry on Aircraft 291 The Registry on Aircraft claim is a special Host Identity Claim 292 defined as follows: 294 0 1 2 3 295 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 296 +---------------+---------------+---------------+---------------+ 297 | | 298 | Hierarchical | 299 | Host Identity Tag | 300 | | 301 +---------------+---------------+---------------+---------------+ 302 | | 303 . . 304 . Caa . 305 . . 306 | | 307 +---------------+---------------+---------------+---------------+ 308 | Expiration Timestamp | 309 +---------------+---------------+---------------+---------------+ 310 | | 311 | | 312 | | 313 | | 314 | | 315 | | 316 | | 317 | Signature | 318 | | 319 | | 320 | | 321 | | 322 | | 323 | | 324 | | 325 | | 326 +---------------+---------------+---------------+---------------+ 328 This Identity Claim uses the HHIT of the Registry and Caa to form a 329 short (200 byte) certificate to be used on the Aircraft in Broadcast 330 Remote ID. 332 During Host Identity Claim creation the Expiration Timestamp MUST be 333 UNIX time (with an offset added to it, setting it into the future) 334 and also MUST be no later than the Expiration Timestamp found in Caa. 336 The Registry HHIT is substitued for Crr to keep the Host Identity 337 Claim within the contraints of Broadcast RID payload size. This 338 optimization does allow for an attacker to attempt a hash collision 339 on the HHIT. This, the authors argue, would be incredible hard as 340 the attacker would need to corrupt DNS to go undetected. That is if 341 a collision on the HHIT is even found in time as it is expected that 342 standard operating procedure for UAS would be to use "one-time" 343 identifiers. 345 Cra could also be stored in DNS using the CERT RR [RFC3498]. If this 346 is of any benefit has not been explored. 348 4. Provisioning 350 This section gives an overview of how an Operator then Aircraft are 351 provisioned under TMRID. 353 First keypairs are generates on the required devices. Due to 354 limitations in hardware and connectivity it is acceptable to generate 355 the Aircraft keypairs and Host Identity Claims on the Operator device 356 and later embed the data into the Aircraft at the end of 357 provisioning. The methods to securely perform the action of handling 358 the data and embedding it into the Aircraft hardware are out of scope 359 for this document. This section of the document assumes that the 360 Operator is acting on behalf of the Aircraft. 362 4.1. HHIT Delegation 364 Under the FAA NPRM, it is expect that IDs for UAS are assigned by the 365 UTM and are generally one-time use. The methods for this however is 366 unspecified leaving two options. 368 The entity generates its own HHIT, discovering and using the RRA 369 and HDA for the target Registry. The method for discovering a 370 Registry's RRA and HDA is out of scope here. This allows for the 371 device to generate an HHIT to send to the Registry to be accepted 372 (thus generating the required Host Identity Claim) or denied. 374 The entity sends to the Registry its HI for it to be hashed and 375 result in the HHIT. The Registry would then either accept 376 (returning the HHIT to the device) or deny this pairing. 378 In either case the Registry must make a decision on if the HI/HHIT 379 pairing is valid. This in its simplest form is checking the current 380 Registry for a collision on the HHIT. 382 Upon accepting a HI/HHIT pair the Registry MUST populate the requried 383 the DNS serving the HDA with the HIP RR and other relevant RR types 384 (such as TXT and CERT). The Registry MUST also generate the 385 appropriate Host Identity Claim for the given operation. 387 If the Registry denied the HI/HHIT pair, because their was a HHIT 388 collision or any other reason, the Registry MUST signal back to the 389 device being provisioned that a new HI needs to be generated. 391 The subsequent sections follow that the device is generating its own 392 HHIT. 394 4.2. Operator 396 +----------+ +---------+ 397 | Registry | ---------> | HDA DNS | 398 +----------+ HIP RR +---------+ 399 ^ | 400 | | 401 | | 402 Coo | | Cro 403 | | 404 | v 405 +----------+ 406 | Operator | 407 +----------+ 409 The Operator generates his HHIT then Coo and sends Coo (along with 410 other relevant information if required) to the desired Registry. 412 The Registry performs Operator registration, by confirming that no 413 HHIT collisions occur. Coo undergoes a signature verification. If 414 everything passes the Registry adds the HIP RR and optionally CERT 415 RRs and TXT RRs into the HDA DNS, generates Cro and transmits it back 416 to the Operator. 418 Upon recieving Cro the Operator is now registered in the Registry and 419 can proceed to provision any Aircraft. Further verification of Cro 420 can be done, if desired. 422 4.3. Aircraft 424 +----------+ +---------+ 425 | Registry | ---------> | HDA DNS | 426 +----------+ HIP RR +---------+ 427 ^ | 428 | | 429 | | 430 Caa, Coa | | Croa, Cra 431 | | 432 | v 433 +----------+ +----------+ 434 | Operator | ---------------------> | Aircraft | 435 +----------+ Aircraft Keypair, +----------+ 436 Aircraft HHIT, 437 Caa, Cra 439 The Operator generates the HHIT for the Aircraft along with Caa and 440 Coa, sending them to the Registry. 442 The Registry confirms that the Operator is valid user and then begins 443 Aircraft registration. The HHIT is checked to see if there is a 444 collision in the current Registry. Caa and Coa undergo a signature 445 check. Once complete and all passes, then the Registry adds the HIP 446 RR (and other RRs) to the HDA DNS. The Registry then generates two 447 Host Identity Claims: Croa and Cra. Both are sent back to the 448 Operator to signal successful completion of Aircraft registration. 450 Upon recieving Croa the Operator stores it for safe keeping. After 451 any additional verification and signature checking Cra, the Aircraft 452 HHIT and the Aircraft keypair and embedded onto the Aircaft. 454 4.4. Registry 456 It should be noted that the Registry can undergo a similar process as 457 Operator/Aircraft to provision them to an RRA (as a Registry is most 458 likely the HDA). This is currently not specified here for berevity 459 of the document. 461 5. IANA Considerations 463 TBD 465 6. Security Considerations 467 A major consideration is the optimization done in Cra to get its 468 length down to 200 bytes. The truncation of Crr down to just its 469 HHIT is one that could be used against the system to act as a false 470 Registry. For this to occur an attacker would need to find a hash 471 collision on that Registry HHIT and then manage to spoof all of DNS 472 being used in the system. 474 The authors believe that the probabilty of such an attack is low when 475 Registry operators are using best practices in security. If such an 476 attack is able to occur (especially in the time frame of "one-time 477 use IDs") then there are more serious issues present in the system. 479 7. Acknowledgments 481 TBD 483 8. References 485 8.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 494 May 2017, . 496 8.2. Informative References 498 [hhit-registries] 499 Moskowitz, R., Card, S., and A. Wiethuechter, 500 "Hierarchical HIT Registries", draft-moskowitz-hip-hhit- 501 registries-01 (work in progress), 17 October 2019, 502 . 505 [hierarchical-hit] 506 Moskowitz, R., Card, S., and A. Wiethuechter, 507 "Hierarchical HITs for HIPv2", draft-moskowitz-hip- 508 hierarchical-hit-04 (work in progress), 3 March 2020, 509 . 512 Authors' Addresses 514 Adam Wiethuechter 515 AX Enterprize 516 4947 Commercial Drive 517 Yorkville, NY 13495 518 United States of America 520 Email: adam.wiethuechter@axenterprize.com 522 Stuart W. Card 523 AX Enterprize 524 4947 Commercial Drive 525 Yorkville, NY 13495 526 United States of America 528 Email: stu.card@axenterprize.com 530 Robert Moskowitz 531 HTT Consulting 532 Oak Park, MI 48237 533 United States of America 535 Email: rgm@labs.htt-consult.com