idnits 2.17.1 draft-wiethuechter-tmrid-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 (9 March 2020) is 1507 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 200, but not defined == Missing Reference: 'RFC3498' is mentioned on line 346, 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-00 12 Abstract 14 This document describes 7 Identity Claims for use for Trusted 15 Multipurpose RemoteIDs. These Identity Claims will be used in 16 various Drone RemoteID 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 . . . . . . . . . . . . . . . . . 11 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 Registry Provisioning process. 81 These claims establish trust for Hierarchical HITs 82 [hierarchical-hit]. They are then used in various Drone RemoteID 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 TM-RID there are a total of 7 Identity Claims created during 109 the provisioning of the UA to enable trustworthiness. This section 110 specifies the Host Identity Claims forms in detail, the individual 111 Host Identity Claims created and their use in TM-RID. 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 TM-RID for entity 'x'. All Host Identity Claims of this form 176 are 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 TM-RID uses this form to create three self-signed Host Identity 185 Claims, which are then nested into other Host Identity Claims. The 186 three Host Identity Claims created are: 188 Aircraft on Aircraft (Caa) 190 Operator on Operator (Coo) 192 Registry on Registry (Crr) 194 These Host Identity Claims (and keypairs needed to create them) 195 SHOULD be created on the entities that own them. Crr on the 196 Registry, Coo on the Operator device and Caa on the Aircraft itself 197 (if able). 199 These Host Identity Claims could also be stored in DNS under the CERT 200 RR [RFC4398]. 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 certificate. The new Host Identity Claims is signed by the 246 first party (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 TM-RID two Host Identity Claims are created in the Cxy way, and 256 third one which is a special nesting of the created Host Identity 257 Claims (but following the Cxy form). These Host Identity Claims are 258 as follows: 260 Registry on Operator (Cro): Using Crr and Coo as Cxx and Cyy 261 respectively, this Host Identity Claims asserts the Registry's 262 Acceptance of the claims in Coo. This MUST be performed on the 263 Registry. It is 304 bytes in length. 265 Operator on Aircraft (Coa): Using Coo and Caa (Cxx and Cyy 266 respectively) this Host Identity Claim asserts a binding between 267 an Operator and Aircaft. This MUST be performed on the Operator 268 device. It is 304 bytes in length. 270 Registry on Operator on Aircraft (Croa): A special claim created, 271 asserting the transitivity between Registry, Operator and 272 Aircraft. It uses Cro as Cxx and Coa as Cyy. This MUST be 273 performed on the Registry. It is 608 bytes in length. 275 The exact methods of transfering data between the entities are out of 276 scope of this document. It MUST be secure, especially when the 277 Registry sends back Croa. It is RECOMMENED that HIP be used if 278 possible, considering that HHITs are being used already. 280 Croa is special in that it is similiar to an issued automobile 281 registration.The Operator, once it recieves Croa via a secure channel 282 from the Registry, should store it somewhere safe to be recalled if 283 required. It SHOULD not be public availibe, as it can be classified 284 as Personally Identifiable Information (PII). 286 It is possible that Cro and/or Coa are stored in DNS and are public 287 availible as a result. If so, the CERT RR [RFC3498] should be used 288 to store them. It is unknown the value of storing them in DNS gives. 290 3.4. Claim Registry on Aircraft 292 The Registry on Aircraft claim is a special Host Identity Claim 293 defined as follows: 295 0 1 2 3 296 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 297 +---------------+---------------+---------------+---------------+ 298 | | 299 | Hierarchical | 300 | Host Identity Tag | 301 | | 302 +---------------+---------------+---------------+---------------+ 303 | | 304 . . 305 . Caa . 306 . . 307 | | 308 +---------------+---------------+---------------+---------------+ 309 | Expiration Timestamp | 310 +---------------+---------------+---------------+---------------+ 311 | | 312 | | 313 | | 314 | | 315 | | 316 | | 317 | | 318 | Signature | 319 | | 320 | | 321 | | 322 | | 323 | | 324 | | 325 | | 326 | | 327 +---------------+---------------+---------------+---------------+ 329 This Host Identity Claim uses the HHIT of the Registry and Caa to 330 form a short (200 byte) certificate to be used on the Aircraft in 331 Broadcast Remote ID. 333 During Host Identity Claim creation the Expiration Timestamp MUST be 334 UNIX time (with an offset added to it, setting it into the future) 335 and also MUST be no later than the Expiration Timestamp found in Caa. 337 The Registry HHIT is substitued for Crr to keep the Host Identity 338 Claim within the contraints of Broadcast RID payload size. This 339 optomization does allow for an attacker to attempt a hash collision 340 on the HHIT. This, the authors argue, would be incredible hard as 341 the attacker would need to corrupt DNS to go undetected. That is if 342 a collision on the HHIT is even found in time as it is expected that 343 standard operating procedure for UAS would be to use "one-time" 344 identifiers. 346 Cra could also be stored in DNS using the CERT RR [RFC3498]. If this 347 is of any benefit has not been explored. 349 4. Provisioning 351 This section gives an overview of how an Operator then Aircraft are 352 provisioned under TM-RID. 354 First keypairs are generates on the required devices. Due to 355 limitations in hardware and connectivity it is acceptable to generate 356 the Aircraft keypairs and Host Identity Claims on the Operator device 357 and later embed the data into the Aircraft at the end of 358 provisioning. The methods to securely perform the action of handling 359 the data and embedding it into the Aircraft hardware are out of scope 360 for this document. This section of the document assumes that the 361 Operator is acting on behalf of the Aircraft. 363 4.1. HHIT Delegation 365 Under the FAA NPRM, it is expect that IDs for UAS are assigned by the 366 UTM and are generally one-time use. The methods for this however is 367 unspecified leaving two options. 369 The entity generates its own HHIT, discovering and using the RRA 370 and HDA for the target Registry. The method for discovering a 371 Registry's RRA and HDA is out of scope here. This allows for the 372 device to generate an HHIT to send to the Registry to be accepted 373 (thus generating the required Host Identity Claim) or denied. 375 The entity sends to the Registry its HI for it to be hashed and 376 result in the HHIT. The Registry would then either accept 377 (returning the HHIT to the device) or deny this pairing. 379 In either case the Registry must make a decision on if the HI/HHIT 380 pairing is valid. This in its simplest form is checking the current 381 Registry for a collision on the HHIT. 383 Upon accepting a HI/HHIT pair the Registry MUST populate the requried 384 the DNS serving the HDA with the HIP RR and other relevant RR types 385 (such as TXT and CERT). The Registry MUST also generate the 386 appropriate Host Identity Claim for the given operation. 388 If the Registry denied the HI/HHIT pair, because their was a HHIT 389 collision or any other reason, the Registry MUST signal back to the 390 device being provisioned that a new HI needs to be generated. 392 The subsequent sections follow that the device is generating its own 393 HHIT. 395 4.2. Operator 397 +----------+ +---------+ 398 | Registry | ---------> | HDA DNS | 399 +----------+ HIP RR +---------+ 400 ^ | 401 | | 402 | | 403 Coo | | Cro 404 | | 405 | v 406 +----------+ 407 | Operator | 408 +----------+ 410 The Operator generates his HHIT then Coo and sends Coo (along with 411 other relevant information if required) to the desired Registry. 413 The Registry performs Operator registration, by confirming that no 414 HHIT collisions occur. Coo undergoes a signature verification. If 415 everything passes the Registry adds the HIP RR and optionally CERT 416 RRs and TXT RRs into the HDA DNS, generates Cro and transmits it back 417 to the Operator. 419 Upon recieving Cro the Operator is now registered in the Registry and 420 can proceed to provision any Aircraft. Further verification of Cro 421 can be done, if desired. 423 4.3. Aircraft 425 +----------+ +---------+ 426 | Registry | ---------> | HDA DNS | 427 +----------+ HIP RR +---------+ 428 ^ | 429 | | 430 | | 431 Caa, Coa | | Croa, Cra 432 | | 433 | v 434 +----------+ +----------+ 435 | Operator | ---------------------> | Aircraft | 436 +----------+ Aircraft Keypair, +----------+ 437 Aircraft HHIT, 438 Caa, Cra 440 The Operator generates the HHIT for the Aircraft along with Caa and 441 Coa, sending them to the Registry. 443 The Registry confirms that the Operator is valid user and then begins 444 Aircraft registration. The HHIT is checked to see if there is a 445 collision in the current Registry. Caa and Coa undergo a signature 446 check. Once complete and all passes, then the Registry adds the HIP 447 RR (and other RRs) to the HDA DNS. The Registry then generates two 448 Host Identity Claims: Croa and Cra. Both are sent back to the 449 Operator to signal successful completion of Aircraft registration. 451 Upon recieving Croa the Operator stores it for safe keeping. After 452 any additional verification and signature checking Cra, the Aircraft 453 HHIT and the Aircraft keypair and embedded onto the Aircaft. 455 4.4. Registry 457 It should be noted that the Registry can undergo a similar process as 458 Operator/Aircraft to provision them to an RRA (as a Registry is most 459 likely the HDA). This is currently not specified here for berevity 460 of the document. 462 5. IANA Considerations 464 TBD 466 6. Security Considerations 468 TBD 470 7. Acknowledgments 472 TBD 474 8. References 476 8.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 485 May 2017, . 487 8.2. Informative References 489 [hhit-registries] 490 Moskowitz, R., Card, S., and A. Wiethuechter, 491 "Hierarchical HIT Registries", Work in Progress, Internet- 492 Draft, draft-moskowitz-hip-hhit-registries-01, 17 October 493 2019, . 496 [hierarchical-hit] 497 Moskowitz, R., Card, S., and A. Wiethuechter, 498 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 499 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 500 2020, . 503 Authors' Addresses 505 Adam Wiethuechter 506 AX Enterprize 507 4947 Commercial Drive 508 Yorkville, NY 13495 509 United States of America 511 Email: adam.wiethuechter@axenterprize.com 513 Stuart W. Card 514 AX Enterprize 515 4947 Commercial Drive 516 Yorkville, NY 13495 517 United States of America 519 Email: stu.card@axenterprize.com 521 Robert Moskowitz 522 HTT Consulting 523 Oak Park, MI 48237 524 United States of America 526 Email: rgm@labs.htt-consult.com