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