--- 1/draft-ietf-drip-registries-01.txt 2022-04-30 12:13:11.602380117 -0700 +++ 2/draft-ietf-drip-registries-02.txt 2022-04-30 12:13:11.722383137 -0700 @@ -1,22 +1,22 @@ -drip Working Group A. Wiethuechter +drip Working Group A. Wiethuechter (Editor) Internet-Draft S. Card Intended status: Standards Track AX Enterprize, LLC -Expires: 8 September 2022 R. Moskowitz +Expires: 1 November 2022 R. Moskowitz HTT Consulting J. Reid RTFM llp - 7 March 2022 + 30 April 2022 - DRIP Registries - draft-ietf-drip-registries-01 + DRIP Entity Tag Registration & Lookup + draft-ietf-drip-registries-02 Abstract This document creates the DRIP DET registration and discovery ecosystem. This includes all components in the ecosystem (e.g., RAA, HDA, UA, GCS, USS). The registration process will use the Extensible Provisioning Protocol (EPP) and other protocols. The discovery process will leverage DNS and DNSSEC and related technology. The DETs can be registered with as their "raw public keys" or in X.509 certificates. @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 8 September 2022. + This Internet-Draft will expire on 1 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. @@ -58,34 +58,34 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Abstract Process & Reasoning . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Required Terminology . . . . . . . . . . . . . . . . . . 5 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Registered Assigning Authorities . . . . . . . . . . 6 3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7 - 3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 7 + 3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 8 4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 8 4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 9 5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 9 5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 10 - 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 10 + 5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 11 6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 11 6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 12 6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 13 6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 14 6.2. Registering a Serial Number . . . . . . . . . . . . . . . 15 6.3. Registering an Operator . . . . . . . . . . . . . . . . . 17 6.4. Registering a Session ID . . . . . . . . . . . . . . . . 18 6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 20 6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 22 6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 23 @@ -99,24 +99,25 @@ 7.3. EPP Transform Commands . . . . . . . . . . . . . . . . . 24 7.3.1. EPP Command . . . . . . . . . . . . . . . . 24 7.3.2. EPP Command . . . . . . . . . . . . . . . . 28 7.3.3. EPP Command . . . . . . . . . . . . . . . . . 30 7.3.4. EPP Command . . . . . . . . . . . . . . . 30 7.3.5. EPP Command . . . . . . . . . . . . . . . . 30 8. RDAP Definitions . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 30 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 12.2. Informative References . . . . . . . . . . . . . . . . . 31 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 13.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 33 A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 33 A.1.1. Attestor Identity Information . . . . . . . . . . . . 34 A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 34 A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 34 A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 35 A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 35 A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 35 A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 35 A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 36 @@ -126,21 +127,22 @@ A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 40 A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 42 A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 42 A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 43 A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 43 A.3.4. Mutual Certificate (MC-z.x.y) . . . . . . . . . . . . 44 A.4. Abbreviations & File Naming Conventions . . . . . . . . . 45 A.4.1. In Text Abbreviation . . . . . . . . . . . . . . . . 46 A.4.2. File Naming . . . . . . . . . . . . . . . . . . . . . 46 Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 + Appendix C. Blockchain-based Registries . . . . . . . . . . . . 47 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction Registries are fundamental to RID. Only very limited information can be Broadcast, but extended information is sometimes needed. The most essential element of information sent is the UAS ID itself, the unique key for lookup of extended information in registries. While it is expected that registry functions will be integrated with USS, who will provide them is not yet determined in most, and is @@ -177,34 +179,34 @@ the risk. This document creates the DRIP DET registration and discovery ecosystem. This includes all components in the ecosystem (e.g., RAA, HDA, UA, GCS, USS). The registration process will use the Extensible Provisioning Protocol (EPP) and other protocols. The discovery process will leverage DNS and DNSSEC and related technology. The DETs can be registered with as their "raw public keys" or in X.509 certificates. 1.1. Abstract Process & Reasoning - In DRIP each entity (registries, operators and aircraft) is expected - to generate a full DRIP Entity ID [drip-rid] on the local device - their key is expected to be used. These are registered with a Public + In DRIP each entity (registry, operator and aircraft) is expected to + generate a full DRIP Entity ID [drip-rid] on the local device their + key is expected to be used. These are registered with a Public Information Registry within the hierarchy along with whatever data is required by the cognizant CAA and the registry. Any PII is stored in a Private Information Registry protected through industry practice AAA or better. In response, the entity will obtain an attestation or certificate from the registry proving such registration. Manufacturers that wish to participate in DRIP should not only support DRIP as a Session ID type for their aircraft but also generate a DET then encode it as a Serial Number. This would allow aircraft under CAA mandates to fly only ID Type 1 (Serial Number) - could still use DRIP and all its benefits. Even if DRIP is not + could still use DRIP and most of its benefits. Even if DRIP is not supported for Serial Numbers by a Manufacturer it is hoped that they would still run a registry to store their Serial Numbers and allow look ups for generic model information. This look up could be especially helpful in UTM for Situational Awareness when an aircraft flying with a Serial Number is detected and allow for an aircraft profile to be displayed. Operators are registered with a number of registries or their regional RAA. This acts as a verification check when a user performs other registration operations; such as provisioning an aircraft with @@ -266,38 +268,68 @@ Figure 1: Registry Hierarchy 3.1.1. Root This is a special registry holding the RAA value of 0 and HDA value of 0. It delegates out RAA values only to registries that wish to act as an RAA. 3.1.2. Registered Assigning Authorities - RAA's are the upper hierarchy in DRIP. Most are contemplated to be - Civil Aviation Authorities (CAAs) that then delegate HDAs to manage - their NAS. This is does not preclude other entities to operate an - RAA if the Root server allows it. + RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field + (16,384 RAAs) of a DET). An RAA is a business or organization that + manages a registry of HDAs (Section 3.1.3). Most are contemplated to + be Civil Aviation Authorities (CAA), such as the Federal Aviation + Authority (FAA), that then delegate HDAs to manage their NAS. This + is does not preclude other entities to operate an RAA if the Root + server allows it. - All RAA's use an HDA value of 0 and have their RAA value delegated to - them by the Root. + The ICAO registration process will be available from ICAO. Once ICAO + accepts an RAA, it will assign a number and create a zone delegation + under the uas.icao.int. DNS zone for the RAA. + + As HHITs may be used in many different domains, RAA should be + allocated in blocks with consideration on the likely size of a + particular usage. Alternatively, different prefixes can be used to + separate different domains of use of HHITs. + + An RAA must provide a set of services to allocate HDAs to + organizations. It must have a public policy on what is necessary to + obtain an HDA. It must maintain a DNS zone minimally for discovering + HID RVS servers. All RAA's use an HDA value of 0 and have their RAA + value delegated to them by the Root. 3.1.2.1. ICAO Registry of Manufacturer's (IRM) A special RAA that hands out HDA values to participating Manufacturer's that hold an ICAO Manufacturer Code used in ANSI CTA2063-A Serial Numbers. It is holds the RAA value of 1 and HDA value of 0. 3.1.3. Hierarchial HIT Domain Authorities + An HDA may be an ISP or any third party that takes on the business to + provide RVS and other needed services such as those required for HIP- + enabled devices. + + The HDA is an 14-bit field (16,384 HDAs per RAA) of a DET assigned by + an RAA. An HDA should maintain a set of RVS servers for UAS clients + that may use HIP. How this is done and scales to the potentially + millions of customers are outside the scope of this document. This + service should be discoverable through the DNS zone maintained by the + HDA's RAA. + + An RAA may assign a block of values to an individual organization. + This is completely up to the individual RAA's published policy for + delegation. Such policy is out of scope. + 3.1.3.1. Manufacturer's Registry of Aircraft (MRA) A registry (HDA) run by a manufacturer of UAS systems that participate in Remote ID. Stores UAS Serial Numbers under a specific ICAO Manufacturer Code (assigned to the manufacturer by ICAO). A DET can be encoded into a Serial Number (see [drip-rid]) and this registry would hold a mapping from the Serial Number to the DET and its artifacts. @@ -1339,67 +1371,67 @@ Upon accepting a HI/DET pair the registry MUST populate the required the DNS serving the HDA with the HIP RR and other relevant RR types (such as TXT and CERT). The registry MUST also generate the appropriate attestations/certificates for the given operation. If the registry denied the HI/DET pair, because there was a DET collision or any other reason, the registry MUST signal back to the device being provisioned that a new HI needs to be generated. -11. Contributors +11. Acknowledgements * Scott Hollenbeck for his guidance with EPP/RDAP +12. Contributors + * Andrei Gurtov for his insights as a pilot -12. References +13. References -12.1. Normative References +13.1. Normative References [F3411-19] "Standard Specification for Remote ID and Tracking", February 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . -12.2. Informative References +13.2. Informative References [drip-arch] Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", Work in Progress, Internet-Draft, - draft-ietf-drip-arch-20, 28 January 2022, + draft-ietf-drip-arch-22, 21 March 2022, . + 22.txt>. [drip-auth] Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Authentication Formats & Protocols for Broadcast Remote ID", Work in Progress, Internet-Draft, draft-ietf-drip- - auth-04, 20 December 2021, - . + auth-09, 30 April 2022, . [drip-requirements] - Card, S. W., Wiethuechter, A., Moskowitz, R., and A. + Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) - Requirements and Terminology", Work in Progress, Internet- - Draft, draft-ietf-drip-reqs-18, 8 September 2021, - . + Requirements and Terminology", RFC 9153, + DOI 10.17487/RFC9153, February 2022, + . [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A. Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, draft-ietf-drip-uas-rid-01, 9 September 2020, . [hhit-registries] Moskowitz, R., Card, S. W., and A. Wiethuechter, "Hierarchical HIT Registries", Work in Progress, Internet- @@ -2041,22 +2073,95 @@ Some examples of file names: * sa-79d8a404d48f2ef9.cert * a-120b8f25b198c1e1_79d8a404d48f2ef9.cert * ac-aac6b00abba268b7_120b8f25b198c1e1_79d8a404d48f2ef9.cert Appendix B. X.509 Certificates +Appendix C. Blockchain-based Registries + + The implementation of the registries and Network Remote + Identification (Network RID; identify a UA through the network) in + DRIP is yet to be determined. Blockchain, being synonymous with + ledger, is a technology that could naturally fulfil the role of a + registry, while simultaneously offering its benefits such as + auditability, persistency and decentralization. We suggest that + blockchain is an ample candidate to be used as registry within DRIP. + We also show that it can be used to effectively leverage Network RID + in certain scenarios. Thus 1) We propose a novel drone ID + architecture based on Hyperledger Iroha and describe its proof-of- + concept implementation with DRIP. 2) Its performance and scalability + is empirically evaluated. 3) We perform an informal security analysis + of the system against various types of attacks [Secure Drone + Identification with Hyperledger Iroha + (https://doi.org/10.1145/3479243.3487305)]. + + Figure 1: Architecture using blockchain as registry for DRIP + + The proposed architecture is presented in Fig. 1. It consists of the + usual actors in a UAS network, along with the blockchain registry + based on Hyperledger Iroha. Key components: o Authorized users + (administrators) can register new UAs to the network, and store with + them any relevant data such as public keys and certificates. + + Drones can either send location updates directly to the blockchain, + given that they are connected to the Internet, or send location + updates to their connected Ground Control Station (GCS) that forwards + it on behalf of the drones. o Observers can receive drone messages + either through bluetooth and WiFi broadcasts from drones, or by + polling the blockchain. They can also fetch the public key + associated with a drone in order to validate its messages. o The + blockchain network and its nodes are an entirely separate entity, no + other actor participates in the consensus of new blocks. + + Actors within DRIP (except observers) will be registered as accounts + on the blockchain network. Each of these accounts will have their + DRIP identities, certificates and public keys stored and available so + that they can be validated and used for validation by any account on + the blockchain. Note that DRIP crypto key-pairs are separate from + the blockchain crypto key-pairs. DRIP key-pairs are used to sign, + verify and validate DRIP identities and messages, while the + blockchain key-pairs are used to sign, verify and validate + transactions on the blockchain. + + The DRIP requirements for a registry are the following: (1) REG-1: + Public lookup (2) REG-2: Private lookup (3) REG-3: Provisioning (of + static/dynamic data of UAs) (4) REG-4: AAA Policy + + REG-1 & REG-2. In Hyperledger Iroha, accounts are created on + domains. The same account name can be used for multiple domains, and + these are seen as separate accounts on Iroha. PII for an account can + therefore be stored on a separate account (with the same account + name) existing on a separate domain, that only allows certain + accounts to view its account details. Accordingly, a registry using + Iroha would need at least two domains associated with it for any + given account, one for public lookup and one for private lookup. + + REG-3 & REG-4. The details for an account are set with a key/value + pair. Key/value pairs can not be removed once they are set, values + can only be modified through the corresponding key. Furthermore, the + account that sets a key/value pair is included in the account details + as a key/value pair itself, meaning one account can not modify + details set by another account. See Listing 1 for clarification. + Notice that both accounts have set the same key but contain different + values. This sort of implementation supports both non-repudiation, + but also trust in the sense that a drone (assuming the drone is not + compromised) can always trust its own data, and does not have to + interpret data coming from other accounts. Similarly, other accounts + accessing another account's data can trust that it is set by the + corresponding account (e.g. fetching gps data). Authors' Addresses + Adam Wiethuechter AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Stuart Card AX Enterprize, LLC 4947 Commercial Drive