]> AX Enterprize, LLC

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

Internet drip Working Group Internet-Draft This document is intended for Civil Aviation Authorities (CAAs) as a Means of Compliance (MOC) for using Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS) Remote ID (RID) identifiers. This enables Session IDs, Authentication Key IDs for accountability, and encryption key IDs for confidentiality.

Introduction

Purpose This document is written to reference other documents, thus acting as an introduction for Civil Aviation Authorities (CAAs) and their Operators attempting to comply within a given jurisdiction. A CAA MAY override any requirement in this document, but MUST provide the reason and an alternative for their operators to implement. This document offers technical options, with recommendations of defaults for international interoperability.

Background 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 Unmanned Aerial System (UAS) Traffic Management (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.

Scope Any entity involved in UAS Broadcast RID as per this document:

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

The archetypal case is a UAS for which the DET serves as both the UAS ID (e.g. in the ASTM Basic ID Message as a Type 4, Subtype 1 Specific Session ID) and the Authentication Key ID. DRIP builds upon existing UAS RID standards (ASTM ) and baseline Means of Compliance (ASTM ). This document acts as a further Means of Compliance for DETs to be used as Session IDs and/or Authentication Key IDs. This document is intended to be internationally applicable but at the time of first writing the authors have only confirmed compatibility with ASTM (and thus US FAA rules).

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. TODO: find good accurate definitions of these terms & order them

UAS RID identifier:

a term used in this document to encompass the use of a DET to be used as any combination of the following: UAS Specific Session ID, Authentication Key ID and Encryption Key ID.

DRIP Identity Management Entity (DIME):

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

Attestation:

i.e. secure boot of a device

Authentication:

of the individual (essential)

Authorization:

the admin action of defining roles and what access is permitted for them & the subsequent reference to these roles in policy based determination to grant or deny specific access requests

Access Control:

i.e. zero trust. Fine grained near real time access control

Attribution:

every action needs to attributable to who took it

Accounting:

resource use MUST be tracked

Audit:

look back at any of the above after the fact

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 messages compliant with and Broadcast RID including:

1. Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag). The UAS ID SHOULD be displayed either in the style of an IPv6 address per or as described in .
2. 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). The details of these SAM Types are described in . Observer devices MUST follow the requirements of Section 6.4.2 of . Appendix A of is RECOMMENDED for visualization of the trustworthiness assessment.

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 UAS RID identifier 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 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 . These are:

• Broadcast Endorsement: RAA:A on RAA:I
• Broadcast Endorsement: RAA:I 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 public (explicitly or implicitly) 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.

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.

Cross Cutting 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. The definitions of the seven categories are provided in . 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 by DRIP. The specific attestation mechanisms in a given jurisdiction are out of scope for this document.

Authentication:

SHOULD be provided by DIMEs for entities participating in Broadcast RID and if provided MUST follow .

Authorization:

TODO

Access Control:

MUST be enforced by the DIME to access data from . 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.

Attribution:

TODO

Accounting:

TODO

Audit:

TODO

Compliance Testing

• 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.

DETs as a Locator TODO

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.

Selective Encryption The DET, in its capacity as a Session ID, already acts as a query key for various data elements (both public and private). Selective encryption MAY be allowed when using a Session ID to allow authorized parties to obtain decryption as a service (under UTM, from the USS under which the observed UA is flying) or access decryption key material (under UTM or not, from the HDA) via a private lookup. 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 urban areas but prohibited in rural areas. The issue of Observer network connectivity MAY be mitigated with the use of a shared key, for encryption/decryption, used by multiple Session IDs in a given HDA over a period of time, that is preloaded onto the Observer before connectivity is lost. For example Observers MAY query HDAs for flight volumes in which they are interested to preload their decryption key(s) for the registrations that day.

References Normative References AX Enterprize, LLC RTFM llp This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata. 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. 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. 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

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