]> AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

Internet drip Working Group Internet-Draft This document standardizes usage of Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) as identifiers to enable trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems (UAS) in Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). DETs can serve as Session IDs for privacy, Authentication Key IDs for accountability, and encryption key IDs for confidentiality.

Introduction

Purpose This document provides to stakeholders in a National Airspace System (NAS), such as a Civil Aviation Authority (CAA) and its consituients, a point of entry into a set of relevant standards. These standards provide guidance to enable trustworthy Air Domain Awareness (ADA) primarily via cooperative techologies. Such technologies can include, but are not limited to, Unmanned Aircraft Systems (UAS) Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). This document specifies an interopable manner of achieving the stated objectives in an international context. A CAA MAY override any technical specification in this document but MUST, if claiming compliance with this document, provide the reason and an alternative specification satisfying the same objective.

Background provides comprehensive background on the UAS RID use-case and the UTM/AAM context. Trustworthiness revolves around identification and authentication. defines the Drone Remote Identification Protocol (DRIP) Entity Tag (DET), a trustable identifier backed by asymmetic cryptography. standardizes authentication of DETs and associated information using strong cryptography suited for constrained mobile wireless links (typical of Broadcast RID). Broadcast and Network RID are defined by ASTM which designates the International Civil Aviation Organization (ICAO) to maintain codepoints for Specific Session ID Types and Specific Authentication Methods (SAMs) . ICAO includes DETs as a Specific Session ID Type and lists the four DRIP SAMs. defines a method for a registrant (typically a UAS Operator or UAS) to propose their inclusion into the identifier heirarchy. The registry system, made up of DRIP Identity Management Entities (DIMEs), ensures uniqueness within the heirarchy, endorses inclusion through X.509 certificates, and provides access to public and private information associated with a DET registration. Public information is served using the Domain Name System (DNS) and is specified in . Private information is served using the Registration Data Access Protocol (RDAP, TODO: ref) and protected through policy based differentiated access . This document specifies the fundamental registration processes and interactions surrounding the Private Information Registry function defined in the DRIP Architecture ().

Scope This document assumes that participanting entities are in compliance with relevant existing UAS standards such as ASTM , and TODO-REF: ICAO-TFP. This document governs use of a DET in the following cases:

• An entity that uses a Session ID (some participating entities, e.g. HDAs, may not need Session IDs), MUST use a DET for that Session ID.
• An entity that participates in DRIP protocol interactions (even if not needing a Session ID), MUST use a DET for the DRIP public key ID in those interactions.
• An entity that requires a strongly cryptographically verifiable IP compatible identifier, MAY use a DET for any other legal purpose.
• An entity SHOULD NOT use a DET as a locator in physical or logical space (e.g. as a globally routable IPv6 address outside of an overlay network), as deconflation is intended, see .

The archetypal case is a UAS for which the DET serves as both the UAS ID (first case above) and the Authentication Key ID (second case).

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Additional Definitions This document makes use of terms (PII, USS, etc.) defined in , and . For convenience of the reader, some of the major definitions are restated here.

DRIP Identity Management Entity (DIME):

Originally defined in and expanded technically in . An entity providing registrar and registry services specifically for DETs.

Interactions & Responsibilities This section outlines the various players in the ecosystem. For each, it outlines relevant motivations for using DRIP, as well as the interactions and responsibilities they have in doing so.

UAS Observers An Observer has many motivations for detecting Broadcast RID. Regardless of their motivation the authenticity of the data presented is important for them to make decisions on their next actions. This is accomplished by the use of Authentication of the Broadcast RID, something DRIP provides. Observers also may need additional information, beyond what is sent over Broadcast RID. While the use of a Session ID provides a level of privacy, the use of DRIP allows this privacy while also enabling authorized queries for additional data. An Observer device is expected to be able to process Broadcast RID messages per in accordance with CAA regulations (such as ) as follows: In order to satisfy CAA regulatory requirements as per corresponding Means of Compliance (e.g. for the US) something something MUST comply with applicable portions of and process as per the following messages:

1. The UAS ID SHOULD be displayed either in the style of an IPv6 address per or as described in for the following ASTM Message Types:
   • Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag).
2. is RECOMMENDED for visualization of the trustworthiness assessment. Observer devices MUST follow the requirements of for the following ASTM Message Types:
   • Authentication Messages (Message Type 0x2), Authentication Type 0x5 (Specific Authentication Method (SAM)), SAM Types 0x01 (DRIP Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest) and optionally 0x04 (DRIP Frame).

Registrants Typically UAS Operators. UAS Operators may want to protect the privacy of their details (such as Operator Location) and their reputation. Reputation can be gained or lost with observation and reports of behavior backed by Authentication. They MAY decide for which identification purposes they will use DETs. This choice may be constrained by the jurisdiction's RID regulations.

• Author: move to Definitions: whether to use DRIP for an Authentication Key ID only, Single Use Session ID only, or both. The last of these is the natural approach providing the greatest benefits and thus the primary focus of this document.

UAS Manufacturers Manufacturers typically wish to maintain good reputation of their brands and are often driven by market forces. Such forces include requirements and preferences of both UAS Observers and Operators. To satisfy CAA requirements, a UA MUST transmit whatever messages are needed to carry at least the minimal elements of information required by the regulator. In the US, under the current FAA RID rule, these are Basic ID, Location/Vector, and System as specified in . If the content of these messages is to be trusted, the UA MUST also sign those messages, using the DRIP Wrapper and/or DRIP Manifest methods, as described in .

• Author: add reference to US RID rule

The UAS MUST provide mechanisms and interfaces to enable DET support for UAS Operator selected purposes. For DRIP this requires at minimum the UAS Operator to be able to select DRIP options and start the process of generating and registering a DET with a selected HDA.

HDA Operators A registry function including Hierarchical Host Identity Tag (HHIT) Domain Authority (HDA) is required to support Session IDs that can be used by CAAs and other lawfully authorized parties to look up essential safety and security information associated with UAS and their Operators. In the UTM context, it is expected that the HDA function will be provided by each UAS Service Supplier (USS). This can be in-house or out-sourced to a service bureau more specialized in cryptographically verifiable identifiers usable to access data and systems on networks. Outside the UTM context, each Operator must still obtain this function from some provider. The HDA function also can support other services related to Session IDs. The DRIP Entity Tag (DET) can act as a Session ID and/or Authentication Key ID, thus HDA functionality in this document assumes both are being provided to registrants (see for more details). The use of Authentication is mandated in some (e.g. Japan) but not all regions. Each DET is tied to a longer term identifier by its HDA. Typically this identifier is expected to be the UAS Serial Number, however a CAA MAY choose another long term identifier of significance to them. The binding between these two identifiers is typically considered private. An HDA Operator must fullfil the requirements of their jurisdiction. They must also satisfy the desires of UAS Operators. The HDA MUST provide, upon successful registration of a DET, the four Broadcast Endorsement objects for use in as defined by . These are:

• Broadcast Endorsement: RAA:A on RAA:A
• Broadcast Endorsement: RAA:A on HDA:A
• Broadcast Endorsement: HDA:A on HDA:I
• Broadcast Endorsement: HDA:I on Registrant

The HDA must also place certain essential information into the Internet Domain Name System (DNS) and maintain that information as operations are activated, completed, etc. All the information to be placed into the DNS is public as it is either needed to make the DET based systems work or because it is a high-availability replica of information transmitted in clear-text via Broadcast RID. The DNS records also MUST point to the private registry in which additional information, required by the HDA/USS itself or the CAA, must be placed and maintained, for query by authorized parties only.

RAA Operators RAAs in this document are scoped to be operated by a State. Each State is allocated four RAAs, and may decide on their usage. Each RAA MUST register HDAs within its scope. Each RAA MUST provide both widely supported "long form" X.509 certificates and DRIP-specific "short form" endorsements of its HDAs. The RAA MAY provide services to HDAs for verification of data pertaining to UAS Operators. For example an HDA registering a UAS Session ID may query the RAA to verify a previously RAA-registered UAS Serial Number. The RAA Operator MUST obtain valid DNS delegation. See for more details.

Requirements for DIME Operation The requirements below apply to both RAA and HDA Operators with a focus on how HDA Operators provide registration and related services for their clients (i.e. UAS Operators and their UAS).

Query A DIME has two query interfaces it MUST support. One interface is used for public information query and another (identified and using data found via public queries) is for private information.

Public Information Registries The information found in these registries has been designated as (explicitly or implicitly) public by cognizant authority and/or the information owner. Such information includes public cryptographic keys needed for authentication in , static Broadcast RID data and trustworthy pointers to additional information. These registries are Authoritative Name Servers of DNS. See for operational requirements, query mechanism and response models.

Private Information Registries The information found in these registries is considered Personally Identifiable Information (PII) and/or is stored for potential future audit of registration. Private information queries MUST follow . This specifies the use of Registration Data Access Protocol (RDAP) data models and query formats as the primary query mechanisms. The specific access control policies are to be defined by the CAA. A CAA MAY require additional query mechanisms for their jurisdiction. The eXtensible Access Control Markup Language (XACML) MUST be used. The policies to be enforced by XACML MUST be provided by the CAA and are out of scope for this document.

Registration There are several registration functions essential to achieving the purposes to which this document is directed. Likewise there are several viable technical approaches to performing these functions. The only approaches fully specified in are the Constrained Application Protocol (CoAP) and/or Concise Binary Object Representation (CBOR) Web Tokens (CWT) . DRIP does NOT provide protection against incorrect (e.g. fraudulent) data entered during registration or asserted subsequently. DRIP does protect against alteration (intentional or unintentional) of data subsequent to its assertion by the cryptographic signer. The signer might be the proximate sender (e.g. UA transmitting Broadcast RID) or might be an attestor far away and long ago (e.g. root Certificate Authority). It is the duty of the operator of each DIME, or the party on whose behalf the DIME is being operated, to validate the registration data. The RAA (e.g. CAA) SHOULD provide services to obtain this goal. The APIs and access controls for such services are a matter of national policy and are out of scope for this document.

Compliance Testing It is the responsability of each node in the tree that a child node passes functional interop testing prior to issuing a certificate for the child node.

• Author: This section is a work in progress.

All interfaces MUST be tested on valid and invalid data (such as being malformed). When policy is required on an interface all defined permutations of the policy MUST be tested. The policy engine MUST be evoked to validate proper decisions and actions are being made. All data returned from an interface MUST be tested to check that it conforms with specifications. There is a range in the RAA space allocated for experimentation and testing purposes. These can be delegated to parties, for a limited period of time at the behest of the RAA Designated Expert, to test DIME interoperability (e.g. HDA to RAA interactions) in any of the below subsections. The IANA Considerations section of contains more information on how these delegations are to be handled. provides a set of forms to be filled out and submitted as part of a CAA compliance process for using DRIP.

System Interface Test Diagram o | | A | | B | | o<---(2)----o | | | | | +-----+ +-----+ ]]>

Registration Interface A, B pairs: (registrant, HDA), (HDA, RAA) 1: Ensure that CoAP endpoints on B can be accessed according to B's policy by A. Ensure that the endpoints conform to the normative requirements of Test that B interface properly handles valid and malformed data. Test that B securely generates proper artifacts and stores them. 2: Ensure that the CoAP interactions for (1) properly returns data to A from B. This data MUST include the Broadcast Endorsements, X.509s and any other data elements required.

Public Query Interface A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA') 1: Ensure that B has a properly configured and publicly accessible Authoritative Name Server for its delegated ip6.arpa domain. 2: Ensure that B returns the valid RRTypes defined in to A based on an ip6.arpa query via standard DNS methods (i.e. using UDP on port 53). Ensure that the HHIT RRType contains the correct Certificate with an URI.

Private Query Interface A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA') 1: Ensure that the provide URI from the public query interface points to a valid URI. Ensure that the endpoint on B has proper AAA mechanisms as defined in this document and enforces the proper policy options. 2: Ensure that the B endpoint securely returns the data expected according to policy (matrix of authorized, valid request, unauthorized and invalid request) to A.

IANA Considerations This document requires no new or modified actions by IANA. It does depend on actions IANA has already undertaken to perform in support of DRIP . It also informs other parties of interactions they must have with IANA to achieve the intended purposes of this document; e.g. Nation states MUST request IANA delegation of the DNS zone under ip6.arpa. corresponding to their allocated RAA values.

Security Considerations The considerations discussed in , , , and apply. DIMEs use and provide various methods to protect data as described below under seven categories: Attestation, Authentication, Authorization, Access Control, Attribution, Accounting and Audit. DRIP refers to these categories collectively as AAA. All data, handled under DRIP, MUST be protected by AAA. All private data MUST also be protected by strong encryption where permitted by law. These requirements apply to data at rest and in transit in all phases of the process, i.e. registration and query. Attestation may be mandated by CAAs for devices (such as UA). Remote ATtestation ProcedureS (RATS) is recommended for DRIP. The specific attestation mechanisms in a given jurisdiction are out of scope for this document.

Privacy & Transparency Considerations The considerations discussed in apply.

DETs as Session ID and Authentication Key ID The properties of a DET allow it to be used as a Session ID and/or an Authentication Key ID. There may be scenarios in which Session IDs are desired for privacy but Authentication is not; although this may reduce transparency and security, a DET MAY be used exclusively as a Session ID in such. There are scenarios in which Authentication is desired but Session IDs are not (e.g. where a CAA does not allow Session IDs); a DET MAY be used exclusively as an Authentication Key ID in such. In the scenario expected to be most common, both Session IDs and Authentication are desired; the same DET SHOULD be used as both the Session ID and Authentication Key ID in such. Consequences and operational impact of using different DETs for the Session ID and Authentication Key ID are unknown and not covered in this document.

Selective Encryption Selective encryption may be allowed in some circumstances. An HHIT may be used in a private lookup to access decryption key material or obtain decryption as a service. Selective encryption of UAS RID using DRIP is only allowed when the DET to be used as the Session ID is issued by an HDA associated with a USS and that DET is associated with the corresponding Operational Intent in UTM. This enables the encryption of selected data elements in Broadcast RID to provide a layer of privacy for operators (e.g. their position) without compromising transparency to entities (e.g. public safety / law enforcement personnel) that need to know. Selective encryption typically requires network connectivity of the Observer to perform the private query to obtain the decryption service or key material. CAAs should consider the expected Observer environment and prohibit encryption wherever and whenever Observers cannot reasonably be expected to have connectivity. For example selective encryption, per CAA regulations, MAY be allowed in dense wireless IP connectivity areas (e.g. urban) but prohibited in poor wirelessly covered areas (e.g. rural). The issue of Observer network connectivity MAY be mitigated with the use of a shared decryption key used by multiple Session IDs under a given USS/HDA over a period of time, that is preloaded onto the Observer device before connectivity is lost. For example Observers MAY query USS/HDAs for flight volumes in which they are interested to preload their decryption key(s) for the Operational Intents/Session IDs that day.

References Normative References AX Enterprize, LLC RTFM llp This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. AX Enterprize, LLC This document specifies a registration interaction model and interfaces for DRIP Entity Tags to a DRIP Identity Management Entity using the Constrained Application Protocol and CBOR Web Tokens. AX Enterprize, LLC This document defines an RDAP profile and extension data model for UAS registration. It also gives recommendations for AAA mechanisms. HTT Consulting AX Enterprize, LLC The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement. This document updates RFCs 7401 and 7343. This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153). The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The Security Considerations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. ASTM International ASTM International ASTM International International Civil Aviation Organization

HID Abbreviation The DET MAY be abbreviated. This is useful for display application with limited screen real-estate as the display of the entire 128-bit (32-character in hexadecimal) IPv6 address can be costly. Abbreviations SHOULD follow the following format rules.

Hierarchy Level:

Each hierarchy level (RAA/HDA) is represented by a maximum of four alphanumeric characters. This abbreviation SHOULD NOT be a single character in length, for obvious reasons of not being very useful. The decimal representation does fit into the 4 character restriction but is NOT RECOMMENDED. The RECOMMENDED abbreviation for the RAA level is to use the ISO3166-1 Alpha 2 code for nations. This abbreviation MAY be found in DNS under a HHIT RRType of the entity or its parents. If there is no abbreviation hint display devices SHOULD use a fixed size four character hexadecimal representation of the value. It is RECOMMENDED that display applications specify a default RAA value, and only display the RAA abbreviation explicitly when it does not match the default.

Entity Hash:

The entity is represented by a fixed size four character hexadecimal string using the last four characters of the DET. If a collision (within the same HID space) on display occurs, the four characters SHOULD shift to the left by one hexadecimal character until the collision is resolved. This window MUST stay within the last sixteen hexadecimal characters of the DET. The : character found in an IPv6 address string is ignored.

Delimiter:

Each section is delimited by a single character. This can be any whitespace character (except newline and tab) or any non-alphanumeric character (period, comma, semicolon, etc.). It is RECOMMENDED that the delimiter is consistent between components. The RECOMMENDED delimiter is the space character.

For example a DET with the values of RAA 16383 and HDA 1 without any abbreviation hint from DNS is represented by the string 3FFF 0001 xxxx with xxxx representing a entity hash. If an abbreviation for the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then the DET can be represented with the string of DRIP01 TEST xxxx. For an example of the entity hash, let's assume there are two DETs with the following hashes in the same HID: 0000:1111:2222:3333 and 0000:2222:1111:3333. At first both DETs are represented with the same abbreviation: RAA HDA 3333. One of these DETs is selected by the display application to shift the display hash one character to avoid the collision resulting in the following two abbreviations: RAA HDA 3333 and RAA HDA 1333.

Compliance Submission Forms TODO