--- 1/draft-ietf-drip-registries-03.txt 2022-06-24 11:13:11.875831259 -0700 +++ 2/draft-ietf-drip-registries-04.txt 2022-06-24 11:13:11.999834427 -0700 @@ -1,22 +1,22 @@ drip Working Group A. Wiethuechter (Editor) Internet-Draft S. Card Intended status: Standards Track AX Enterprize, LLC -Expires: 12 November 2022 R. Moskowitz +Expires: 26 December 2022 R. Moskowitz HTT Consulting J. Reid RTFM llp - 11 May 2022 + 24 June 2022 DRIP Entity Tag Registration & Lookup - draft-ietf-drip-registries-03 + draft-ietf-drip-registries-04 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 12 November 2022. + This Internet-Draft will expire on 26 December 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. @@ -62,30 +62,30 @@ 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Registered Assigning Authorities . . . . . . . . . . 7 3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7 3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 8 4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 9 4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 10 5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 10 5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 11 - 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 11 + 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 12 6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 12 6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 13 6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 14 6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 15 6.2. Registering a Serial Number . . . . . . . . . . . . . . . 16 6.3. Registering an Operator . . . . . . . . . . . . . . . . . 18 6.4. Registering a Session ID . . . . . . . . . . . . . . . . 19 6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 21 6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 23 6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 24 @@ -106,26 +106,26 @@ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 34 A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 34 - A.1.1. Attestor Identity Information . . . . . . . . . . . . 35 + A.1.1. Attestor Identity Information . . . . . . . . . . . . 36 A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 36 A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 36 A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 36 A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 36 - A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 36 + A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 37 A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 37 A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 38 A.2.3. Concise Attestation (CA-x.y) . . . . . . . . . . . . 39 A.2.4. Mutual Attestation (MA-x.y) . . . . . . . . . . . . . 40 A.2.5. Link Attestation (LA-x.y) . . . . . . . . . . . . . . 41 A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 42 A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 44 A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 44 A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 45 A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 45 @@ -136,24 +136,25 @@ Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 48 B.1. Certificate Policy and Certificate Stores . . . . . . . . 49 B.2. Certificate Management . . . . . . . . . . . . . . . . . 49 B.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 50 B.4. Alternative Certificate Encoding . . . . . . . . . . . . 50 Appendix C. Blockchain-based Registries . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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. + Registries are fundamental to Remote ID (RID). Only very limited + operational 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 expected to vary between, jurisdictions. However this evolves, the essential registry functions, starting with management of identifiers, are expected to remain the same, so are specified herein. While most data to be sent via Broadcast or Network RID is public, much of the extended information in registries will be private. Thus @@ -170,30 +171,30 @@ The intent of the negative and positive access control requirements on registries is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. Mitigation of Denial of Service attacks and refusal to allow database mass scraping would be based on those behaviors, not on identity or role of the party submitting the query per se, but querant identity information might be gathered (by security systems protecting DRIP implementations) on such misbehavior. - Registration under DRIP is vital as the worry of collisions in the - hash portion of the DET. Forgery of the DET is still possible, but - including it as a part of a public registration mitigates a lot of - 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. + Registration under DRIP is vital to manage the inevitable collisions + in the hash portion of the DET. Forgery of the DET is still + possible, but including it as a part of a public registration + mitigates this 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 (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 @@ -284,75 +285,77 @@ 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. 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 + As DETs 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 + An RAA-level registry 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. + An HDA may be an USS, ISP, or any third party that takes on the + business to register the actual UAS entities that need DETs. This + includes, but is not limited to UA, GCS, and Operators. It should + also provide needed UAS services including those required for HIP- + enabled devices (e.g. RVS). - The HDA is an 14-bit field (16,384 HDAs per RAA) of a DET assigned by + The HDA is a 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 + An HDA-level registry 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. Hold RAA value of 1 and HDA values of 1+. 3.1.3.2. Remote ID Registries (RIDR) - Registry that holds the binding between a UAS Session ID (for DRIP - the DET) and the UA Serial Number. The Serial Number MUST have its - access protected to allow only authorized parties to obtain. The - Serial Number SHOULD be encrypted in a way only the authorized party - can decrypt. + An HDA-level registry that holds the binding between a UAS Session ID + (for DRIP the DET) and the UA Serial Number. The Serial Number MUST + have its access protected to allow only authorized parties to obtain. + The Serial Number SHOULD be encrypted in a way only the authorized + party can decrypt. As part of the UTM system they also hold a binding between a UAS ID (Serial Number or Session ID) and an Operational Intent. Hold RAA values of 2+ and HDA values of 1+. 3.2. Key Rollover & Federation During key rollover the entity MUST inform all children and parents of the change - using best standard practices of a key rollover. At @@ -373,82 +376,96 @@ thoroughly studied at this time. 4. DRIP Fully Qualified Domain Names Under DRIP there are a number of FQDN forms used to allow lookups to take place. The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone. The HDA SHOULD provide DNS service for its zone - and provide the HHIT detail response. A secure connection (e.g., DNS - over TLS) to the authoritative zone may be a viable alternative to - DNSSEC. + and provide the DET detail response. + + DNSSEC is strongly recommended (especially for RAA-level zones). + Frequency of updates, size of the zone, and registry policy may + impact its use. 4.1. Serial Number + See Section 4.2 of [drip-rid] for how to encode DETs as Serial + Numbers. + Serial Number: 8653FZ2T7B8RA85D19LX ICAO Mfr Code: 8653 Length Code: F ID: FZ2T7B8RA85D19LX - FQDN: Z2T7B8RA85D19LX.F.8653.mfr.uas.icao.int + FQDN: Z2T7B8RA85D19LX.8653.mfr.uas.icao.int 4.2. DET - The DET reverse lookup can be a standard IPv6 reverse look up, or it - can leverage off the HHIT structure. If we assume a prefix of - 2001:30::/28: + DETs SHOULD be discoverable in DNS via a hash.oga.hda.raa.prefix. + structure under a ICAO managed DNS aviation tree. This document + proposes a .det.uas.icao.int. branch in the current ICAO DNS domain. + This is subject of discussions with ICAO. Thus if we assume a DET + prefix of 2001:30::/28, the following example shows the resultant DNS + entry: DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e ID: a3ad:1952:0ad0:a69e OGA: 5 HDA: 0014 = 20 RAA: 000a = 10 Prefix: 20010030 FQDN: a3ad19520ad0a69e.5.20.10.20010030.det.uas.icao.int When building a DET FQDN the following two things must be done: 1. The RAA and HDA values MUST be converted from hexadecimal to - decimal form + decimal form. 2. The FQDN must be built using the expanded form of the IPv6 - address + address. The prefix is included in the FQDN form to support other potential prefixes being used. 4.3. Reverse DET + + The DET reverse lookup should be a standard IPv6 reverse address in + ip6.arpa. + $ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa. e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR 5. Supported DNS Records DRIP requires a number of resource records, some specific to certain registries to function. 5.1. HIP RR All registries will have their own DET associated with them and their - respective DNS server will hold a HIP RR that is pointed to by their - DET FQDN. + respective DNS server will hold a HIP RR [RFC8005] that is pointed to + by their DET FQDN. MRA and RIDR servers will also have HIP RRs for their registered parties (aircraft and operators). 5.2. CERT RR Most attestations can be placed into DNS. An exception to this is the Attestation Certificate made during Session ID registration. This is as this particular certificate acts similar to a car registration and should be held safe by the operator. + These should be held in CERT RRs [RFC4398]. + 5.3. NS RR Along with their associated "glue" record (A/AAAA) supports the traversal in DNS across the tree. 1. on Root points to specific DET FQDN of IRM 2. .mfr.remoteid.aero on IRM points to specific DET FQDN of MRA @@ -470,24 +487,28 @@ includes data being stored on its children. The best example of this is RIDR would have a SVR RR that points to a database that contains any extra information of a Session ID it has registered. Another example is the MRA has a SVR RR pointing to where the metadata of a UA registered in the MRA can be located. In all cases the server being pointed to MUST be protected using AAA, specifically using RDAP. + ## + 5.6. TLSA RR - This RR is mainly used to support DTLS deployments where the DET is - used in Network RID and the wider UTM system. + This RR [RFC6698] is mainly used to support DTLS deployments where + the DET is used (e.g. Network RID and the wider UTM system). The HI + is encoded using the SubjectPublicKeyInfo selector. DANE [RFC6698] + is for servers, DANCE [dane-clients] is for clients. 6. Registry Operations As a general rule the following processing performed for any registration operation: 1. Verify input Attestations from registering party 2. Check for collision of DET and HI @@ -1395,70 +1416,80 @@ Huque, S., Dukhovni, V., and A. Wilson, "TLS Client Authentication via DANE TLSA records", Work in Progress, Internet-Draft, draft-ietf-dance-client-auth-00, 24 March 2022, . [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-22, 21 March 2022, + draft-ietf-drip-arch-24, 10 June 2022, . + 24.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-09, 30 April 2022, . + Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Entity + Tag Authentication Formats & Protocols for Broadcast + Remote ID", Work in Progress, Internet-Draft, draft-ietf- + drip-auth-14, 21 June 2022, + . [drip-requirements] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) 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, . [drip-secure-nrid-c2] Moskowitz, R., Card, S. W., Wiethuechter, A., and A. Gurtov, "Secure UAS Network RID and C2 Transport", Work in Progress, Internet-Draft, draft-moskowitz-drip-secure- - nrid-c2-06, 5 May 2022, . + nrid-c2-09, 17 June 2022, + . [hhit-registries] Moskowitz, R., Card, S. W., and A. Wiethuechter, "Hierarchical HIT Registries", Work in Progress, Internet- Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 2020, . [NPRM] "Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems", December 2019. + [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name + System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, + . + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . + [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name + System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, + October 2016, . + [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Appendix A. DRIP Attestations & Certificates See [drip-arch] for definitions of claim, assertion, attestation and certificate as used in this document. A.1. Attestation Structure