DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-15
| Document | Type | Active Internet-Draft (drip WG) | |
|---|---|---|---|
| Authors | Adam Wiethuechter , Jim Reid | ||
| Last updated | 2024-04-01 | ||
| Replaces | draft-wiethuechter-drip-registries | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
DNSDIR Early review
(of
-09)
by Tim Wicinski
On the Right Track
|
||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | Daniel Migault | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | daniel.migault@ericsson.com |
draft-ietf-drip-registries-15
drip Working Group A. Wiethuechter, Ed.
Internet-Draft AX Enterprize, LLC
Intended status: Standards Track J. Reid
Expires: 3 October 2024 RTFM llp
1 April 2024
DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-15
Abstract
This document describes the high level architecture for the
registration and discovery of DRIP Entity Tags (DETs) using DNS.
Discovery of DETs and their artifacts is performed via DRIP specific
DNS structures and standard DNS methods. A general overview of the
interfaces required between involved components is described in this
document with future supporting documents giving technical
specifications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 3 October 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wiethuechter & Reid Expires 3 October 2024 [Page 1]
Internet-Draft DETIM Architecture April 2024
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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Concept . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Required Terminology . . . . . . . . . . . . . . . . . . 5
3.2. Additional Definitions . . . . . . . . . . . . . . . . . 5
3.3. Text Conventions . . . . . . . . . . . . . . . . . . . . 6
4. DIME Roles . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Apex . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. DRIP Apex for UAS RID . . . . . . . . . . . . . . . . 7
4.2. Registered Assigning Authority (RAA) . . . . . . . . . . 7
4.2.1. ISO 3166-1 Numeric Nations (INN) . . . . . . . . . . 8
4.2.2. Experimental . . . . . . . . . . . . . . . . . . . . 8
4.3. Hierarchial HIT Domain Authority (HDA) . . . . . . . . . 8
5. DIME Architecture . . . . . . . . . . . . . . . . . . . . . . 9
5.1. DRIP Provisioning Agent (DPA) . . . . . . . . . . . . . . 10
5.2. Registry & Name Server (NS) . . . . . . . . . . . . . . . 11
5.3. DRIP Information Agent (DIA) & Registration Data Directory
Service (RDDS) . . . . . . . . . . . . . . . . . . . . . 11
6. DET Registration Process . . . . . . . . . . . . . . . . . . 12
6.1. DET Registration Data Model . . . . . . . . . . . . . . . 13
6.1.1. UAS ID Handling . . . . . . . . . . . . . . . . . . . 14
6.1.2. Self Endorsement . . . . . . . . . . . . . . . . . . 15
6.1.3. Service Tuple . . . . . . . . . . . . . . . . . . . . 15
6.2. DET Authentication . . . . . . . . . . . . . . . . . . . 16
6.3. DET Session ID . . . . . . . . . . . . . . . . . . . . . 16
6.4. DET Session ID & Authentication . . . . . . . . . . . . . 16
7. Differentiated Access Process . . . . . . . . . . . . . . . . 16
8. DRIP in the Domain Name System . . . . . . . . . . . . . . . 17
8.1. DRIP Entity Tags . . . . . . . . . . . . . . . . . . . . 18
9. Endorsements . . . . . . . . . . . . . . . . . . . . . . . . 19
10. X.509 Certificates . . . . . . . . . . . . . . . . . . . . . 20
10.1. Certificate Policy and Certificate Stores . . . . . . . 20
10.2. Certificate Management . . . . . . . . . . . . . . . . . 22
10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 22
10.4. Alternative Certificate Encoding . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. Management of DRIP Apex . . . . . . . . . . . . . . . . 23
Wiethuechter & Reid Expires 3 October 2024 [Page 2]
Internet-Draft DETIM Architecture April 2024
11.2. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 23
11.2.1. DRIP RAA Allocations . . . . . . . . . . . . . . . . 23
11.2.2. Endorsement Types . . . . . . . . . . . . . . . . . 24
11.2.3. HHIT Type . . . . . . . . . . . . . . . . . . . . . 25
11.2.4. HHIT Status . . . . . . . . . . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12.1. Key Rollover & Federation . . . . . . . . . . . . . . . 27
12.2. DET Generation . . . . . . . . . . . . . . . . . . . . . 27
13. Public Key Exposure . . . . . . . . . . . . . . . . . . . . . 28
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
15.1. Normative References . . . . . . . . . . . . . . . . . . 29
15.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. HHIT Resource Record . . . . . . . . . . . . . . . . 32
Appendix B. HID Abbreviation Recommendation . . . . . . . . . . 33
Appendix C. DETs as Fully Qualified Domain Names . . . . . . . . 33
Appendix D. DRIP Endorsements for UAS . . . . . . . . . . . . . 34
D.1. Self Endorsement . . . . . . . . . . . . . . . . . . . . 34
D.2. Broadcast Endorsement . . . . . . . . . . . . . . . . . . 35
D.3. Wrapper Endorsement . . . . . . . . . . . . . . . . . . . 38
D.4. Manifest Endorsement . . . . . . . . . . . . . . . . . . 38
D.5. Frame Endorsement . . . . . . . . . . . . . . . . . . . . 38
Appendix E. DNS Examples . . . . . . . . . . . . . . . . . . . . 39
E.1. Operator . . . . . . . . . . . . . . . . . . . . . . . . 39
E.2. Session ID . . . . . . . . . . . . . . . . . . . . . . . 39
E.3. Child DIME . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote
ID (RID). Only very limited operational information can be sent via
Broadcast RID, but extended information is sometimes needed. The
most essential element of information is the UAS ID, the unique key
for lookup of extended information in relevant registries (see
Figure 4 of [RFC9434]).
Such extended information is retrieved from the UAS ID via the use of
a DRIP Entity Tag (DET) [RFC9374] which is managed by the DRIP
Identity Management Entity (DIME). In this document we assume the
DIME belongs to the UAS Service Suppliers (USS) (Appendix A.2 of
[RFC9434]) but a DIME can be independent or handled by another entity
as well.
While most data to be sent via Broadcast RID (Section 1.2.1 of
[RFC9434]) or Network RID (Section 1.2.2 of [RFC9434]) is public,
much of the extended information will be private. As discussed in
Section 7 of [RFC9434], Authentication, Attestation, Authorization,
Wiethuechter & Reid Expires 3 October 2024 [Page 3]
Internet-Draft DETIM Architecture April 2024
Access Control, Accounting, Attribution, and Audit (typically known
as AAA) is essential, not just to ensure that access is granted only
to strongly authenticated, duly authorized parties, but also to
support subsequent attribution of any leaks, audit of who accessed
information when and for what purpose. As specific AAA requirements
will vary by jurisdictional regulation, provider choices, customer
demand, etc., they are left to specification in policies which are
out of scope for this document.
The intent of the access control requirements 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.
Registration is necessary to guarantee the uniqueness of the DET and
thus to ensure the extended information is bound to the UAS ID.
This document creates the DRIP registration and discovery
architecture focusing on the DET for UAS at its surrounding
ecosystem. Clients in the architecture that can use a DET include
Unmanned Aircraft (UA), Registered Assigning Authority (RAA),
Hierarchical HIT Domain Authority (HDA), Ground Control Station
(GCS), and USS.
This document uses the Concise Data Definition Language (CDDL)
[RFC8610] for describing the registration data.
2. General Concept
DETs when generated are only "proposed" and MUST be registered within
the hierarchy to become legitimate. DIME's are the points in the
hierarchy that enforce requirements on registration and information
access. This document standardizes the basic interactions and
methods for registration and lookup to support interoperability based
around DETs. Other identifiers and their methods are out of scope
for this document.
This document selects the Domain Name System (DNS) as the Public
Information Registry for both storing and retrieving public
information, such as the public key of DETs and pointers to Private
Information Registries. Personally Identifiable Information (PII) is
stored in Private Information Registries and MUST be protected
through AAA.
For UAS, a DIME can provide the following congruent registration and
lookup services:
1. personal information (e.g. for pilots and operators)
Wiethuechter & Reid Expires 3 October 2024 [Page 4]
Internet-Draft DETIM Architecture April 2024
2. UAS Serial Number and aircraft physical characteristics
3. DETs as a Key ID for UAS RID Authentication ([drip-auth])
4. DETs as a pseudo-anonymous UAS Specific Session ID (UAS ID Type
4)
5. binding of UAS ID to UTM Operational Intent
A DIME's services are determined by their intended role (Section 4)
and policies (both internally and from cognizant authorities). For
example, services 1 and 2 can be restricted to non-public access
controlled lookups with mandatory registration and 5 to publicly
available but access controlled lookups.
For this document only services 3 and 4, as they directly relate to
DETs, are detailed. Services 1 and 5 will be talked about
conceptually while service 2 is out of scope.
Requirements on the elements of information in registration and
lookup (beyond the scope basic interoperability) is out of scope for
this document. It is left to cognizant authorities to determine
these details along with policy for access. For the UAS use-case
this is Civil Aviation Authorities (CAAs).
3. Terminology
3.1. Required 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3.2. Additional Definitions
This document makes use of the terms (PII, USS, etc.) defined in
[RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434],
while others (RAA, HDA, etc.) are from [RFC9374].
Wiethuechter & Reid Expires 3 October 2024 [Page 5]
Internet-Draft DETIM Architecture April 2024
3.3. Text Conventions
When talking about a DIME in documents it should be referred to as
the role it is serving. For example a CAA level DIME running
services both as an RAA (its primary role in the hierarchy) and as an
HDA (optionally) would be be referred to "RAA" when performing its
RAA duties and "HDA" when performing its HDA duties. The rest of the
document will follow this convention unless verbosity or clarity is
needed.
4. DIME Roles
[RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and
further specifies an instance of them used for UAS RID called DETs.
As a review, HHITs are comprised of four major components: a Prefix,
a Hierarchy ID (HID), a HHIT Suite ID (fixed 8-bits) and an ORCHID
Hash. DETs use a 28-bit prefix and 64-bit hash leaving 28-bits for
the HID. For UAS RID this HID is further divided into two fields:
RAA and HDA, each 14-bits in length. Figure 1 shows this breakdown.
+-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28-bits) | (28-bits) | (8-bits) | (64-bits) |
+-------------+--------------+---------------+-------------+
/ \
/ \
/ \-----------------------------\
/ \
/ \
+--------------------------------+-----------------------+
| Registered Assigning Authority | HHIT Domain Authority |
| (14-bits) | (14-bits) |
+--------------------------------+-----------------------+
Figure 1: DRIP Entity Tag Breakdown
[RFC9434] defines the DRIP Identity Management Entity (DIME) as an
entity that vets Claims and/or Evidence from a registrant and
delivers, to successful registrations, Endorsements and/or
Certificates in response. The DIME encompasses various logical
components (Section 5) and can be classified to serve a number of
different roles, mapped to levels in the hierarchy, which are
detailed in the following subsections.
Wiethuechter & Reid Expires 3 October 2024 [Page 6]
Internet-Draft DETIM Architecture April 2024
4.1. Apex
The Apex is the owner of the IPv6 prefix portion of the DET
associated with it which is assigned by IANA from the special IPv6
address space for ORCHIDs. It serves as the branch point from the
larger DNS system in which DETs are defined. The Apex manages all
delegations and allocations of RAAs to various parties. The Apex
MUST reserve an allocation for itself that it MAY use.
4.1.1. DRIP Apex for UAS RID
For UAS RID the Apex manages the IPv6 prefix of 2001:30/28.
Allocations of RAAs in this prefix SHOULD be done in contiguous
groups of 4. This is to support the nibble reversing of the DET to
be placed in DNS (Section 8.1). See Section 11.1 for the RAA
allocations.
Values 0 (0x0000) through 3 (0x0003) MUST be reserved for the UAS RID
Apex and SHOULD be used to endorse RAA delegations in Endorsements
(Section 9). While the individual Apexes can be designated for
different purposes they share the same pool of RAAs to be allocated.
Such operation would require policy by the administrator of the Apex
to avoid simultaneous allocation and is out of scope for this
document.
4.2. Registered Assigning Authority (RAA)
An RAA is a business or organization that runs a DIME to register
HDAs (Section 4.3). Most are contemplated to be CAAs (using
Section 4.2.1), such as the Federal Aviation Authority (FAA), that
then delegate HDAs to manage their National Air Space (NAS). This is
does not preclude other entities to operate an RAA if the Apex allows
it.
An RAA:
* MUST provide a set of services to allocate HDAs to organizations
* MUST have a public policy on what is necessary to obtain an HDA
* SHOULD maintain a DNS zone minimally for discovering HIP RVS
servers
All RAA's MUST have a single reserved HDA value: 0 (0x0000) for
itself to support various functions or services. Other HDA values
SHOULD be allocated or reserved per RAA policy.
Wiethuechter & Reid Expires 3 October 2024 [Page 7]
Internet-Draft DETIM Architecture April 2024
4.2.1. ISO 3166-1 Numeric Nations (INN)
The RAA range of 4 (0x0004) to 3999 (0x0F9F) are reserved for CAAs
using the ISO 3166-1 Numeric Nation Code. The RAA can be derived
from the ISO 3166-1 numeric code by multiplying the value by 4 (i.e.
raa_code = iso_code * 4). Four contiguous values (raa_code + 0,
raa_code + 1, raa_code + 2 and raa_code + 3) are used in a single
allocation. The inverse (RAA to ISO) works out as: iso_code =
floor(raa_code / 4).
As an example the United States has an ISO 3166-1 Numeric Code of
840. This derives the following RAAs: 3360, 3361, 3362 and 3363.
It should be noted that the range of codes from 900 to 999 are
defined (by ISO 3166-1) as "user assigned code elements" and do not
have specific claimants predefined in the RAA space. Withdrawn and
other special codes also do not have predetermined claimants.
How a CAA handles their allocated values are out of scope of this
document. Control of these values are expected to be claimed by
their respective owner. How a claim is vetted and validated is out
of scope of this document. Protection against fraudulent claims of
one of these values is out of scope for this document.
Informational Note: A single entity may control more than one NAS
(for example LU and BE being covered by Skeyes.be) and would
manage two allocation spaces. How this is claimed and handled is
out of scope for this document.
4.2.2. Experimental
The RAA range of 16376 (0x3FF8) to 16383 (0x3FFF), eight (8) RAAs, is
allocated to the DRIP working group itself as an experimental range.
RAA 16376 is already "in use" with driptesting.org. The rest of the
range (16377 to 16383) are reserved to be allocated by the DRIP
experts to agencies or organizations that wish to test for a period
of time.
4.3. Hierarchial HIT Domain Authority (HDA)
An HDA may be an USS, ISP, or any third party that takes on the
business to register client entities that need DETs. This includes,
but is not limited to UA, GCS, UAS Operators and UAS/UTM
infrastructure (such as Supplemental Data Service Providers). It
SHOULD also provide needed UAS services including those required for
HIP-enabled devices (e.g. RVS).
For UAS RID, HDAs can provide any of the following services:
Wiethuechter & Reid Expires 3 October 2024 [Page 8]
Internet-Draft DETIM Architecture April 2024
* registration and public lookup of DETs as a Key ID for
Authentication as defined in [drip-auth]
* registration and access controlled lookup of DETs as a pseudo-
anonymous UAS Session ID
* registration of UAS ID and UTM Operational Intent to bind them
together (if allowed by cognizant authority)
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 MUST
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 for this document.
5. DIME Architecture
The DIME, in any of its roles (Section 4), is comprised of a number
of logical components that are depicted in Figure 2. Any of these
components could be delegated to other entities as a service both co-
located or remote.
Interfaces with a specific transport requirement (such as HTTPS) are
labeled accordingly. Interfaces not labeled can be implementation
specific or proprietary due to co-location of components. For
example the interface between the DPA and Registry/Name Server, when
delegated, might be Extensional Provisioning Protocol (EPP) [RFC5730]
(due to Registry/Name Server requirements) while implementations co-
locating these components might use an internal code library. These
non-labeled interfaces are out of scope for this document.
Wiethuechter & Reid Expires 3 October 2024 [Page 9]
Internet-Draft DETIM Architecture April 2024
+--------------------+
| Registering Client |
+---------o----------+
|
| HTTPS
|
**********|*********************************************************
* | DRIP Identity Management Entity (DIME) *
* | *
* +------o-------+ +-------------+ +--------------+ *
* | DRIP | | | | | *
* | Provisioning o---------o | | | *
* | Agent (DPA) | | | | | *
* +-------o------+ | | | | *
* | | | | | *
* | | DRIP | | Registration | *
* | | Information o------o Data | *
* | | Agent (DIA) | | Directory | *
* | | | | Service | *
* +-------o----------+ | | | (RDDS) | *
* | Registry | | | | | *
* | / | | | | | *
* | Name Server (NS) | | | | | *
* +------o-----------+ +-----o-------+ +--------------+ *
* | | *
* | | *
**********|***********************|*********************************
| |
| TCP/UDP | RDAP
| |
| +-------o-------+
'---------------o Lookup Client |
+---------------+
Figure 2: DIME Logical Components
5.1. DRIP Provisioning Agent (DPA)
The DPA performs the important task of vetting information coming
from clients wishing to register and then delegates (internally or
externally) various items to other components in the DIME. This is
the primary component that handles all DRIP related cryptographic
operations for incoming registrations to the DIME.
The DPA:
* MUST have a publicly accessible and discoverable HTTPS interface
for clients to register through
Wiethuechter & Reid Expires 3 October 2024 [Page 10]
Internet-Draft DETIM Architecture April 2024
* MUST use a provided interface from a DRIP Information Agent
(Section 5.3)
* MUST use a provided interface from a Registry/Name Server
(Section 5.2)
Specific details of the public HTTPS interface (such as
advertisement) is out of scope for this document.
5.2. Registry & Name Server (NS)
The Registry & Name Server component handles all the required DNS
based requirements of the DIME to function. This includes the
registration and maintenance of various DNS Resource Records used in
public lookups.
The Registry:
* MUST provide an interface (for example EPP) for management of DNS
functions
* MUST provide a standard DNS query interface
The detailed specification of either interface is out of scope for
this document.
The Registry is the component that interfaces the DIME into the DNS
hierarchy and thus operation SHOULD follow best common practices,
specifically in security (such as running DNSSEC) as appropriate.
Specific instruction for operating a Registry & Name Server is out of
scope for this document. However the following references are
presented as pointers to material that might be useful: TODO: add
list of useful RFCs?
Author Note: This may be very important here as we should not
preclude a USS from running his own Name Server but they are not
DNS experts and will need guidance or at least pointers to it to
not mess it up. Such as SOA and NS formats to allow delegation if
acting as an RAA.
5.3. DRIP Information Agent (DIA) & Registration Data Directory Service
(RDDS)
The DIA is the main component handling information ingress (via
registration) and egress (via lookup) of the RDDS.
The DIA:
Wiethuechter & Reid Expires 3 October 2024 [Page 11]
Internet-Draft DETIM Architecture April 2024
* MUST have an access controlled interface for add/delete/update of
information that MAY be publicly available
- this interface definition is out of scope for this document
* MUST have an access controlled interface to query for information
that MAY be publicly available
- if this interface is publicly available it MUST use
Registration Data Access Protocol (RDAP) ([RFC7480], [RFC9082]
and [RFC9083])
- if this interface is not publicly available its specification
is out of scope for this document
Certain information stored within the RDDS, due to policy, may be
considered PII and MUST be protected from access using AAA (for
example using XACML). See Section 7 for more information.
The interface between a DIA and an RDDS is out of scope for this
document.
6. DET Registration Process
The general process for a registering DET is as follows:
1. Verify inputs (such as Endorsement(s)) from registering client
2. DPA checks for collision of DET and HI
3. Populate Registry/Name Server with resource record(s)
4. Populate RDDS via DIA with PII and other info
5. Generate and return Endorsement(s)
Generically a DET can be used as an identifier for any client in UTM
and SHOULD be registered to a DIME. For example a CAA may choose to
use DETs for its Operators. A data model (such as what is specified
in Section 6.1) would be required to define all the information for
registration for a given classification of client.
Such specification beyond using DETs as a Session ID and/or Key ID
(Section 6.2, Section 6.3 and Section 6.4) is out of scope for this
document.
Wiethuechter & Reid Expires 3 October 2024 [Page 12]
Internet-Draft DETIM Architecture April 2024
In the following subsections an abbreviated form of Figure 2 seen
below in Figure 3 uses co-located components to describe the flow of
information. Each section gives specific example details for the
components, interfaces and data elements. Each section has an
associated appendix (Appendix E) containing DNS examples.
+----------+
| Client |
+--o---o---+
| ^
(1,2) | | (5)
| |
*******|***|*****************************
* | | DIME *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA (2) o--------->o | *
* +----o----+ (4) | | *
* | | | *
* | (3) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
Figure 3: Example Registration Process
6.1. DET Registration Data Model
The following is the general data model for DET registration data to
be sent to the DPA from a client. This model is defined for and used
by Section 6.2, Section 6.3 and Section 6.4.
Wiethuechter & Reid Expires 3 October 2024 [Page 13]
Internet-Draft DETIM Architecture April 2024
det_registration_info = {
serial_number: tstr .size 20, ; ANSI CTA2063-A UAS Serial Number
uas_id: bstr .size 20, ; UAS ID per ASTM F3411-22a Basic ID Message
uas_id_type: 0..15, ; UAS ID Type per ASTM F3411-22a
? key_id: bstr,
? self_endorsement: bstr .size 120,
? utm_binding,
* tstr => any
}
utm_binding = (
utm_id: bstr .size 16, ; Operational Intent (UUIDv4)
utm_source: tstr ; URI to USS with Operational Intent
)
UAS ID Type and UAS ID: defined per ASTM [F3411]. See Section 6.1.1
for handling specific instructions during registration.
UAS Serial Number: defined per [CTA2063A]. Other UAS Serial Number
formats (considered legacy) are out of scope for this document.
UTM Assigned ID: also known as an Operational Intent, defined per
ADD-UTM-REF and ASTM [F3411] as a UUIDv4.
Self Endorsement: defined per Section 9 and Appendix D.1. See
Section 6.1.2 for handling specific instructions during
registration.
It is RECOMMENDED that the information above is signed over in some
way to ensure integrity of the registration data. A recommended way
to do this is with a JWT[RFC7519] or CWT [RFC8392] using the clients
key.
Other data elements MAY be added to this model. A DIME MUST have a
public API detailing additional elements expected for their
implementations. These elements and reference is out of scope for
this document.
6.1.1. UAS ID Handling
The uas_id_type field MUST be set to same UAS ID Type in the ASTM
[F3411] Basic ID Message to ensure proper decoding of the uas_id
field.
Wiethuechter & Reid Expires 3 October 2024 [Page 14]
Internet-Draft DETIM Architecture April 2024
The uas_id field MUST be set with the octets found in the ASTM
[F3411] Basic ID Message UAS ID field. By using identical contents
of the Basic ID Message the Specific Session ID Type octet (the first
octet in the UAS ID when using UAS ID Type is 0x4) is preserved.
When a DET is used a Session ID, the value of this first octet MUST
be 0x01.
6.1.2. Self Endorsement
The self_endorsement is included when a DET is used either as a
Session ID (in uas_id) or for Authentication (in key_id).
The value is verified by the DPA and its contents used to generate a
Broadcast Endorsement for use in [drip-auth] and put into DNS.
6.1.3. Service Tuple
Five critical pieces of information are required to provide the
services listed in Section 2 that make a tuple. These are: UAS ID,
UAS ID Type, UAS Serial Number, Key ID and UTM Assigned ID. The UAS
ID, UAS ID Type and UAS Serial Number fields are mandatory and MUST
NOT be null for entry as defined .
This tuple encodes the services that the specific registration is
being used. A few examples can be seen in the table below.
+================+==========+========+============+=====+==========+
| Service | UAS ID | UAS ID | UAS Serial | Key | UTM |
| | | Type | Number | ID | Assigned |
| | | | | | ID |
+================+==========+========+============+=====+==========+
| DET | TEST3ABC | 0x1 | TEST3ABC | DET | - |
| Authentication | | | | | |
+----------------+----------+--------+------------+-----+----------+
| DET Session ID | 0x01 + | 0x4 | TEST3ABC | - | - |
| | DET | | | | |
+----------------+----------+--------+------------+-----+----------+
| DET Session ID | 0x01 + | 0x4 | TEST3ABC | DET | - |
| + | DET | | | | |
| Authentication | | | | | |
+----------------+----------+--------+------------+-----+----------+
Table 1
As this document focuses on DETs exclusively the use of the Key ID
using other cryptographic identifiers and how to distinguish between
them (such as how UAS ID and UAS ID Type is used) is out of scope of
this document.
Wiethuechter & Reid Expires 3 October 2024 [Page 15]
Internet-Draft DETIM Architecture April 2024
6.2. DET Authentication
For Authentication use of a DET, registration requires the following
additional data elements: key_id, self_endorsement. Section 6.1.2
MUST be followed.
6.3. DET Session ID
For the registration of a DET as a Session ID the client is typically
the UAS. The mechanisms of how the UAS generates a DET are out of
scope for this document.
For Session ID use of a DET, registration requires the following
additional data elements: self_endorsement. Both Section 6.1.1 and
Section 6.1.2 MUST be followed.
Optionally a binding between a DET and a UTM Session ID can be made
by providing the information of the UTM side using utm_id and
utm_source. The support of this is based on CAA policy and is out of
scope for this document.
6.4. DET Session ID & Authentication
For Session ID & Authentication use of a DET, registration requires
the following additional data elements: key_id, self_endorsement.
Both Section 6.1.1 and Section 6.1.2 MUST be followed.
7. Differentiated Access Process
Per [RFC9434] all information classified as private is stored in a
datastore protected using some form of differentiated access (i.e.
AAA) to satisfy REG-2 from [RFC9153].
Differentiated access, as a process, is a requirement for DIMEs as
defined in [RFC9153] by the combination of PRIV-1, PRIV-3, PRIV-4,
REG-2 and REG-4. [RFC9434] further elaborates on the concept by
citing RDAP (from [RFC7480], [RFC9082] and [RFC9083]) as a potential
means of fulfilling this requirement.
Typically the cognizant authority is the primary querant of private
information from a DIME if a Session ID is reported (the case of the
owner of the private information is ignored for the moment). This
capability MAY be delegated to other parties at the authorities
discretion (be it to a single user or many), thus requiring a
flexible system to delegate, determine and revoke querent access
rights for information. XACML MAY be a good technology choice for
this flexibility.
Wiethuechter & Reid Expires 3 October 2024 [Page 16]
Internet-Draft DETIM Architecture April 2024
It is noted by the authors that as this system scales the problem
becomes a, well known and tricky, key management problem. While
recommendations for key management are useful they are not
necessarily in scope for this document as best common practices
around key management should already be mandated and enforced by the
cognizant authorities in their existing systems. This document
instead focuses on finding a balance for generic wide-spread
interoperability between DIMEs with authorities and their existing
systems in a Differentiated Access Process (DAP).
A system where cognizant authorities would require individual
credentials to each HDA is not scalable, nor practical. Any change
in policy would require the authority to interact with every single
HDA (active or inactive) to grant or revoke access; this would be
tedious and prone to mistakes. A single credential for a given
authority is also strongly NOT RECOMMENDED due to the security
concerns it would entail if it leaked.
A zero-trust model would be the most appropriate for a DAP; being
highly flexible and robust. Most authorities however use "oracle"
based systems with specific user credentials and the oracle knowing
the access rights for a given user. This would require the DAP the
have some standard mechanism to locate and query a given oracle for
information on the querent to determine if access is granted.
DRIP has no intention to develop a new "art" of key management,
instead hoping to leverage existing systems and be flexible enough to
adapt as new ones become popular.
8. DRIP in the Domain Name System
Per [RFC9434] all information classified as public is stored in the
DNS to satisfy REG-1 from [RFC9153].
DIMEs MUST be responsible for the operation of the DNS-related
infrastructure for domain names under DRIP. It MAY chose to run that
infrastructure directly or outsource it to competent third parties or
some combination of the two.
DIMEs SHOULD specify the technical and administrative criteria for
the provision of these services: contractual terms (if any),
reporting, uptime, SLAs (if any), DNS query handling capacity,
response times, incident handling, complaints, law enforcement
interaction and so on. National policy and regulations will define
how long DNS data are stored or archived. These are all National
Matters where national law/regulation prevail ensuring DRIP complies
with national law and regulation since these are matters of national
sovereignty.
Wiethuechter & Reid Expires 3 October 2024 [Page 17]
Internet-Draft DETIM Architecture April 2024
DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher
zones). When a DIME decides to use DNSSEC they SHOULD define a
framework for cryptographic algorithms and key management [RFC6841].
This may be influenced by frequency of updates, size of the zone, and
policies.
Static UAS specific information that is publicly available MAY also
be stored in DNS but is out of scope for this document.
Author Note: proposal for a UAS RR that is a CBOR map of static
UAS data elements (UAS ID, UAS Type, Self Description, etc.)
For DRIP, IANA has agreed to act as the Apex at least initially (see
Section 11.1 for more details). The delegation of civil aviation
authorities to RAAs is already done per Section 4.2.1 using their ISO
3166-1 Numeric Codes. Since these are public, any entity can stand
up an RAA with that value. The Apex SHOULD be the root of trust in a
Endorsement or certificate chain that provides validation of any of
these specific RAAs, in the ISO RAA range, thus protecting against
bad actors standing up fraudulent RAAs.
8.1. DRIP Entity Tags
The REQUIRED mechanism is to place any information into ip6.arpa when
using a DET. Since the DET is an IPv6 address it can be nibble-
reversed and used in the zone, per standard conventions.
The prefix 2001:30/28 is registered with IANA [RFC9374] and
3.0.0.1.0.0.2.ip6.arpa - the corresponding reverse domain - SHOULD be
under the administrative control of the Apex. In addition to the DNS
infrastructure for 3.0.0.1.0.0.2.ip6.arpa, the Apex SHOULD be
responsible for the allocation of IPv6 addresses in this prefix. An
addressing plan will need to be developed.
Distribution of HHIT (IPv6 address) blocks SHOULD be done using the
14-bit RAA space as a framework. The Apex SHOULD allocate blocks to
each entity who can then assign them to HDAs in accordance with local
law and policy. All HDAs MUST have an IPv6 address in 2001:30/28. A
discrete zone SHOULD be delegated for each HDA. These MUST contain
an HHIT resource record (Appendix A) for itself.
Reverse lookups of these IPv6 addresses will translate the address
into a domain name in the manner defined in [RFC1886]. However,
these lookups will query for, depending on what is required: HIP,
HHIT, TLSA, URI, or PTR RRTypes.
Wiethuechter & Reid Expires 3 October 2024 [Page 18]
Internet-Draft DETIM Architecture April 2024
9. Endorsements
DRIP Endorsements are defined in a CDDL [RFC8610] structure
(Figure 4) that can be encoded to CBOR, JSON or as a binary blob by
concatenating values. CBOR is the preferred encoding format.
The CDDL was derived from the more specific structure developed for
[drip-auth]. As such the structures found in [drip-auth], such as
the UA Signed Evidence and the contents of DRIP Link (known as a
Broadcast Endorsement), are a subset of the below definition in a
strict binary form.
Note: this section uses the term HHIT instead of DET as the
Endorsements are designed to be generic and re-useable for other
HHIT use-cases.
endorsement = 6.xxx(e-data: array)
e-data = [e-type, scope, ? $$evidence, $$endorser, $$signature]
e-type = uint .size(2)
scope = (vnb: time, vna: time, ? $$scope-ext)
$$endorser //= (hhit,)
$$endorser //= (hhit, eddsa25519-hi,)
$$endorser //= (eddsa25519-hi,)
hhit = #6.54(bstr .size(16))
eddsa25519-hi = bstr .size(32)
$$signature = (eddsa25519-sig,)
eddsa25519-sig = bstr .size(64)
Figure 4: Endorsement CDDL
Endorsement Type: a 16-bit value used to hint at the content of the
$$evidence group. Four special values (1 through 4) map to the
SAM Type of the Authentication framing in [drip-auth], allowing
the 16-bit value to be excluded from the Endorsement structure.
See Section 11.2.2 for more details.
Scope & Scope Extensions: The scope section is more formally "the
Wiethuechter & Reid Expires 3 October 2024 [Page 19]
Internet-Draft DETIM Architecture April 2024
scope of validity of the endorsement". The scope can come in
various forms but MUST always have a "valid not before" (vnb) and
"valid not after" (vna) timestamps. Other forms of the scope
could for example be a 4-dimensional volume definition. This
could be in raw latitude, longitude, altitude pairs or may be a
URI pointing to scope information. Additional scope fields are
out of scope for this document and should be defined for specific
Endorsement structures if they are desired using the $$scope-ext
socket group.
Evidence: socket group containing a set claims. The content and
order of claims is specified explicitly for each e-type.
Endorser: socket group where the main identity information of the
signer of the Endorsement is found. The identity can take many
forms such as a handle to the identity (e.g. an HHIT), or can
include more explicit data such as the public key (e.g. an HI).
The content and ordering is specified explicitly for each e-type.
Signature: socket group containing the signature data for the
Endorsement. The content and ordering is specified explicitly for
each e-type. Signatures MUST be generated using the preceding
sections (except for e-type) in their binary forms (i.e. as a
concatenated bytestring of values) rather than their CBOR
encoding.
Appendix D specifies Endorsement structures for the UAS RID use-case.
10. X.509 Certificates
10.1. Certificate Policy and Certificate Stores
X.509 certificates are optional for the DRIP entities covered in this
document. DRIP endpoint entities (EE) (i.e., UA, GCS, and Operators)
may benefit from having X.509 certificates. Most of these
certificates will be for their DET and some will be for other UAS
identities. To provide for these certificates, some of the other
entities (e.g. USS) covered in this document will also have
certificates to create and manage the necessary PKI structure.
Wiethuechter & Reid Expires 3 October 2024 [Page 20]
Internet-Draft DETIM Architecture April 2024
Three certificate profiles are defined, with examples, and explained
in [drip-dki]. Each has a specific role to play and an EE may have
its DET enrolled in all of them. There is a 'Lite' profile that
would work well enough on constrained communication links for those
instances where various issues push the use of X.509. There is a
'Basic; profile that is more in line with [RFC5280] recommendations,
but is still small enough for many constrained environments. Finally
there is a profile to directly add DET support into the civil/general
aviation certificates as discussed below.
A Certificate Authority (CA) supporting DRIP entities MAY adhere to
the ICAO's Aviation Common Certificate Policy (ACCP). The CA(s)
supporting this CP MUST either be a part of the ACCP cross-
certification or part of the ACCP CA Trust List. It is possible that
future versions of the ACCP will directly support the DRIP Basic
profile.
Authors Note: ACCP is ICAO Doc 10169 Aviation Common Certificate
Policy (ACCP). I can't get a url for that, but so far these is no
changes from v 0.93 of the old IATF CP; changes are in the works
then will be posted, so continue to reference IATF CP
EEs may use their X.509 certificates, rather than their rawPublicKey
(i.e. HI) in authentication protocols (as not all may support
rawPublicKey identities). Short lived DETs like those used for a
single operation or even for a day's operations may not benefit from
X.509. Creating then almost immediately revoking these certificates
is a considerable burden on all parts of the system. Even using a
short notAfter date will not completely mitigate the burden of
managing these certificates. That said, many EEs will benefit to
offset the effort. It may also be a regulator requirement to have
these certificates. Finally, certificates can provide the context of
use for a DET (via policy constraint OIDs).
Typically an HDA either does or does not issue a certificate for all
its DETs. An RAA may specifically have some HDAs for DETs that do
not want/need certificates and other HDAs for DETs that do need them.
These types of HDAs could be managed by a single entity thus
providing both environments for its customers.
It is recommended that DRIP X.509 certificates be stored as DNS TLSA
Resource Records, using the DET as the lookup key. This not only
generally improves certificate lookups, but also enables use of DANE
[RFC6698] for the various servers in the UTM and particularly DIME
environment and DANCE [dane-clients] for EEs (e.g.
[drip-secure-nrid-c2]). All DRIP certificates MAY alternatively be
available via RDAP. LDAP/OCSP access for other UTM and ICAO uses
SHOULD also be provided.
Wiethuechter & Reid Expires 3 October 2024 [Page 21]
Internet-Draft DETIM Architecture April 2024
10.2. Certificate Management
PKIX standard X.509 issuance practices should be used. The
certificate request SHOULD be included in the DET registration
request. A successful DET registration then MUST include certificate
creation, store, and return to the DET registrant. It is possible
that the DET registration is actually an X.509 registration. For
example, PKIX CSR may be directly used and the DET registration and
Endorsement creation are a addition to this process. Further ACME
may be directly extendable to provide the DET registration.
Note that CSRs do not include the certificate validityDate; adding
that is done by the CA. If in the registration process, the EE is
the source of notBefore and notAfter dates, they need to be sent
along with the CSR.
Certificate revocation will parallel DET revocation. TLSA RR MUST be
deleted from DNS and RDAP, LDAP, and OCSP return revoked responses.
CRLs SHOULD be maintained per the CP.
10.3. Examples
For full examples of X.509 Certificates and the process to use them
see [drip-dki].
10.4. Alternative Certificate Encoding
The CBOR Encoded X.509 Certificates (C509 Certificates) [cbor-cert]
provides a standards-based approach to reduce the size of X.509
certificates both on-the-wire and in storage. The PKI-Lite RAA
certificate example in Appendix B.2 is 331 bytes. The matching C509
certificate is 183 bytes. This sort of difference may have
significant impact both on UAS storage requirements and over-the-air
transmission impact.
C509 provides two approaches for encoding X.509:
1. An invertible CBOR re-encoding of DER encoded X.509 certificates
[RFC5280], which can be reversed to obtain the original DER
encoded X.509 certificate.
2. Natively signed C509 certificates, where the signature is
calculated over the CBOR encoding instead of over the DER
encoding as in 1. This removes the need for ASN.1 and DER
parsing and the associated complexity but they are not backwards
compatible with implementations requiring DER encoded X.509.
Wiethuechter & Reid Expires 3 October 2024 [Page 22]
Internet-Draft DETIM Architecture April 2024
The invertible CBOR encoding may be sufficient for most needs. The
CBOR objects clearly indicate which approach was used, so that the
receiver can properly process the C509 object. For interoperability
in DRIP, it is recommended that invertible CBOR encoding be used.
Using the invertible CBOR encoding is achieved through in-line
libraries that convert in the desired direction. Since it is not
expected that DNS protocols to implement this conversion, the HHIT RR
SHOULD contain the normal X.509 DER encoding. The CBOR encoding MAY
be used, but operational experience will be needed to see if there
are measurable gains in doing so.
11. IANA Considerations
11.1. Management of DRIP Apex
A discussion between the authors of this document, DRIP AD and IANA
was held during IETF 118. Those present were:
* Eric Vyncke (AD of DRIP WG)
* Bob Moskowitz
* Jim Ried (Author of this RFC)
* Adam Wiethuechter (Editor of this RFC)
* Kim Davies (IANA)
IANA agreed that they would be willing to manage the Apex for DRIP
until the desired Apex manager, International Civil Aviation
Organization (ICAO), is ready. This is expected to be in the next 5
years due to ICAO process. The hand-over to ICAO is TBD at that time
but various options are available.
Further discussion of the SLA required to RAAs by IANA is and other
requirements to IANA are TBD.
11.2. IANA DRIP Registry
11.2.1. DRIP RAA Allocations
This document requests a new registry for RAA Allocations under the
DRIP registry group (https://www.iana.org/assignments/drip/
drip.xhtml).
RAA Allocations: a 14-bit value that is allocated in groups of 4.
Wiethuechter & Reid Expires 3 October 2024 [Page 23]
Internet-Draft DETIM Architecture April 2024
Future additions to this registry are to be made through Expert
Review (Section 4.5 of [RFC8126]). The following values/ranges
are defined:
+==============+===========+=====================+=================+
| RAA Value(s) | Status | Allocation | Reference |
+==============+===========+=====================+=================+
| 0 - 3 | Allocated | UAS RID (DRIP) Apex | This RFC |
| | | | (Section 4.1.1) |
+--------------+-----------+---------------------+-----------------+
| 4 - 3999 | Allocated | ISO 3166-1 | This RFC |
| | | Countries | (Section 4.2.1) |
+--------------+-----------+---------------------+-----------------+
| 4000 - 16375 | Reserved | N/A | N/A |
+--------------+-----------+---------------------+-----------------+
| 16375 - | Allocated | DRIP WG | This RFC |
| 16383 | | (Experimental Use) | (Section 4.2.2) |
+--------------+-----------+---------------------+-----------------+
Table 2
The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found
as a CSV file here: TODO.
11.2.2. Endorsement Types
This document requests a new registry for Endorsement Type under the
DRIP registry group (https://www.iana.org/assignments/drip/
drip.xhtml).
Endorsement Type: A 16-bit value to provide hinting of the contents
of other sections of an Endorsement. Future additions to this
registry are to be made through Specification Required
(Section 4.3 of [RFC8126]) for values 0x0000 to 0xEFFF and First
Come First Served (Section 4.4 of [RFC8126]) for the values 0xF000
to 0xFFFF. The following values are defined:
Wiethuechter & Reid Expires 3 October 2024 [Page 24]
Internet-Draft DETIM Architecture April 2024
+=======+=======================+=========================+
| Value | Endorsement Type | Reference |
+=======+=======================+=========================+
| 0 | Self-Endorsement | This RFC (Appendix D.1) |
+-------+-----------------------+-------------------------+
| 1 | Broadcast Endorsement | This RFC (Appendix D.2) |
+-------+-----------------------+-------------------------+
| 2 | Wrapper | This RFC (Appendix D.3) |
+-------+-----------------------+-------------------------+
| 3 | Manifest | This RFC (Appendix D.4) |
+-------+-----------------------+-------------------------+
| 4 | Frame | This RFC (Appendix D.5) |
+-------+-----------------------+-------------------------+
Table 3
To register an e-type the following MUST be provided in CDDL for
review:
* Additions to scope group using $$scope-ext
* Specific group contents of $$evidence
* Specific group contents of $$endorser
* Specific group contents of $$signature
11.2.3. HHIT Type
This document requests a new registry for HHIT Type under the DRIP
registry group (https://www.iana.org/assignments/drip/drip.xhtml).
HHIT Type: numeric, 16-bit, field of the HHIT RR to encode the HHIT
Type. Future additions to this registry are to be made through
Expert Review (Section 4.5 of [RFC8126]). The following values
are defined:
+=========+============================================+============+
| Value | Type | Reference |
+=========+============================================+============+
| 0 | Not Defined | This RFC |
+---------+--------------------------------------------+------------+
| 1 | DRIP Identity Management Entity (DIME) | This RFC |
+---------+--------------------------------------------+------------+
| 2 | Apex | This RFC |
+---------+--------------------------------------------+------------+
| 3 | Registered Assigning Authority (RAA) | This RFC |
+---------+--------------------------------------------+------------+
Wiethuechter & Reid Expires 3 October 2024 [Page 25]
Internet-Draft DETIM Architecture April 2024
| 4 | HHIT Domain Authority (HDA) | This RFC |
+---------+--------------------------------------------+------------+
| 5 | DIME Provisioning Agent (DPA) | This RFC |
+---------+--------------------------------------------+------------+
| 6 | DIME Information Agent (DIA) | This RFC |
+---------+--------------------------------------------+------------+
| 7 | Name Server (NS) | This RFC |
+---------+--------------------------------------------+------------+
| 8 | Registration Data Directory Service (RDDS) | This RFC |
+---------+--------------------------------------------+------------+
| 9 | ISO 3166-1 Numeric Nation (INN) | This RFC |
+---------+--------------------------------------------+------------+
| 10 - | Reserved | |
| 15 | | |
+---------+--------------------------------------------+------------+
| 16 | Endpoint Entity (EE) | [drip-dki] |
+---------+--------------------------------------------+------------+
| 17 | Issuer CA | [drip-dki] |
+---------+--------------------------------------------+------------+
| 18 | Authentication CA | [drip-dki] |
+---------+--------------------------------------------+------------+
| 19 | Uncrewed Aircraft (UA) | This RFC |
+---------+--------------------------------------------+------------+
| 20 | Ground Control Station (GCS) | This RFC |
+---------+--------------------------------------------+------------+
| 21 | Uncrewed Aerial System (UAS) | This RFC |
+---------+--------------------------------------------+------------+
| 22 | Remote Identification (RID) Module | This RFC |
+---------+--------------------------------------------+------------+
| 23 | Pilot | This RFC |
+---------+--------------------------------------------+------------+
| 24 | Operator | This RFC |
+---------+--------------------------------------------+------------+
| 25 | Discovery & Synchronization Service (DSS) | This RFC |
+---------+--------------------------------------------+------------+
| 26 | UAS Service Supplier (USS) | This RFC |
+---------+--------------------------------------------+------------+
| 27 | Network RID Service Provider (SP) | This RFC |
+---------+--------------------------------------------+------------+
| 28 | Network RID Display Provider (DP) | This RFC |
+---------+--------------------------------------------+------------+
| 29 | Supplemental Data Service Provider (SDSP) | This RFC |
+---------+--------------------------------------------+------------+
| 30 - | Reserved | |
| 65535 | | |
+---------+--------------------------------------------+------------+
Table 4
Wiethuechter & Reid Expires 3 October 2024 [Page 26]
Internet-Draft DETIM Architecture April 2024
11.2.4. HHIT Status
This document requests a new registry for HHIT Status under the DRIP
registry group (https://www.iana.org/assignments/drip/drip.xhtml).
HHIT Status: numeric, 8 bit, field of the HHIT RR to encode the HHIT
Status. Future additions to this registry are to be made through
Expert Review (Section 4.5 of [RFC8126]). The following values
are defined:
+=======+============+===============================+===========+
| Value | Status | Description | Reference |
+=======+============+===============================+===========+
| 0 | Inactive | Default when accepted by DIME | This RFC |
+-------+------------+-------------------------------+-----------+
| 1 | Active | Set when in use | This RFC |
+-------+------------+-------------------------------+-----------+
| 2 | Expired | Set when past VNA | This RFC |
+-------+------------+-------------------------------+-----------+
| 3 | Deprecated | Set when no longer in use | This RFC |
| | | (but not expired) | |
+-------+------------+-------------------------------+-----------+
Table 5
12. Security Considerations
12.1. Key Rollover & Federation
During key rollover the DIME MUST inform all children and parents of
the change - using best standard practices of a key rollover.
A DET has a natural ability for a single DIME to hold different
cryptographic identities under the same HID values. This is due to
the lower 64-bits of the DET being a hash of the public key and the
HID of the DET being generated. As such during key rollover, only
the lower 64-bits would change and a check for a collision would be
required.
This attribute could also allow for a single DIME to be "federated"
across multiple DETs sharing the same HID value. This method of
deployment has not been thoroughly studied at this time.
12.2. DET Generation
Author Note: is this section valid anymore? Perhaps we hard
specify that devices ONLY generate on their own hardware instead
of "out-sourcing" as this section implies.
Wiethuechter & Reid Expires 3 October 2024 [Page 27]
Internet-Draft DETIM Architecture April 2024
Under the FAA [FAA-RID-NPRM], it is expecting that IDs for UAS are
assigned by the UTM and are generally one-time use. The methods for
this however are unspecified leaving two options.
Option 1:
The entity generates its own DET, discovering and using the RAA
and HDA for the target DIME. The method for discovering a DIME's
RAA and HDA is out of scope here. This allows for the device to
generate an DET to send to the DIME to be accepted (thus
generating the required Self-Endorsement) or denied.
Option 2:
The entity sends to the DIME its HI for it to be hashed and result
in the DET. The DIME would then either accept (returning the DET
to the device) or deny this pairing.
Keypairs are expected to be generated on the device hardware it will
be used on. Due to hardware limitations and connectivity it is
acceptable, though not recommended, under DRIP to generate keypairs
for the Aircraft on Operator devices and later securely inject them
into the Aircraft. The methods to securely inject and store keypair
information in a "secure element" of the Aircraft is out of scope of
this document.
13. Public Key Exposure
DETs are built upon asymmetric keypairs. As such the public key must
be revealed to enable clients to perform signature verifications.
While unlikely the forging of a corresponding private key is possible
if given enough time (and computational power). As such it is
RECOMMENDED that the public key for any DET not be exposed in DNS
(using the HIP RR) until it is required.
Optimally this requires the UAS somehow signal the DIME that a flight
using a Specific Session ID is underway or complete. It may also be
facilitated under UTM if the USS (which may or may not be a DIME)
signals when a given operation using a Session ID goes active.
Wiethuechter & Reid Expires 3 October 2024 [Page 28]
Internet-Draft DETIM Architecture April 2024
14. Contributors
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT
Consulting, LLC) for their early work on the DRIP registries concept.
Their early contributions laid the foundations for the content and
processes of this architecture and document. Bob Moskowitz is also
instrumental in the PKIX work defined in this document with his
parallel work in ICAO.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9153] 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,
<https://www.rfc-editor.org/info/rfc9153>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
2023, <https://www.rfc-editor.org/info/rfc9434>.
15.2. Informative References
Wiethuechter & Reid Expires 3 October 2024 [Page 29]
Internet-Draft DETIM Architecture April 2024
[cbor-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-09, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-09>.
[CTA2063A] "ANSI/CTA 2063-A Small Unmanned Aerial Systems Numbers",
September 2019, <https://shop.cta.tech/products/small-
unmanned-aerial-systems-serial-numbers>.
[dane-clients]
Huque, S. and V. Dukhovni, "TLS Client Authentication via
DANE TLSA records", Work in Progress, Internet-Draft,
draft-ietf-dance-client-auth-05, 13 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dance-
client-auth-05>.
[drip-auth]
Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP
Entity Tag Authentication Formats & Protocols for
Broadcast Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-auth-49, 21 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
auth-49>.
[drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
moskowitz-drip-dki-09, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-moskowitz-
drip-dki-09>.
[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-14, 16 March 2024,
<https://datatracker.ietf.org/doc/html/draft-moskowitz-
drip-secure-nrid-c2-14>.
[F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
2022, <https://www.astm.org/f3411-22a.html>.
[FAA-RID-NPRM]
"Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", December 2019.
Wiethuechter & Reid Expires 3 October 2024 [Page 30]
Internet-Draft DETIM Architecture April 2024
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, DOI 10.17487/RFC1886, December 1995,
<https://www.rfc-editor.org/info/rfc1886>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[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, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<https://www.rfc-editor.org/info/rfc6841>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
Wiethuechter & Reid Expires 3 October 2024 [Page 31]
Internet-Draft DETIM Architecture April 2024
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
Appendix A. HHIT Resource Record
This appendix is normative.
The HHIT Resource Record is a metadata record for various bits of
HHIT specific information that isn't available in the pre-existing
HIP RR Type. It is encoded as a CBOR array.
rr = 6.xxx(rr_data: array)
rr_data= [hhit, type, status, abbreviation, endorsements]
hhit = #6.54(bstr .size(16))
type = uint .size(2)
status = uint .size(1)
abbreviation = tstr .size(15)
endorsements = [1* endorsement] ; MUST be in e-type order
Figure 5: Resource Record Wire CDDL
<domain> HHIT IN ( HHIT TYPE STATUS ABBREV [Endorsement(s)] )
Figure 6: Resource Record Text CDDL
Type: This field is two octets with values defined in
Section 11.2.3. It is envisioned that there may be many types of
HHITs in use. In some cases it may be helpful to understand the
HHITs role in the ecosystem like described in [drip-dki].
Status: This field is a single byte with values defined in
Section 11.2.4. A HHIT can go through various states during its
life-cycle in the ecosystem. It is helpful for a querant to
understand the current status as a further requirement for
verification.
Abbreviation: This field is meant to provide an abbreviation to the
HID structure for display devices. The specific contents of this
field are not defined here, but a recommendation/example can be
found in Appendix B.
Endorsements: This field is a list of CBOR encoded Endorsements in
e-type order. It MUST included at least one Broadcast Endorsement
(Appendix D.2). A special case for the Apex is that the Broadcast
Endorsement is filled with its own DET and HI as evidence (i.e. a
self-signed Broadcast Endorsement).
Wiethuechter & Reid Expires 3 October 2024 [Page 32]
Internet-Draft DETIM Architecture April 2024
Appendix B. HID Abbreviation Recommendation
This appendix is informative.
On receiver devices a DET can be translated to a more human readable
form such as: {RAA Abbreviation} {HDA Abbreviation} {Last 4
Characters of DET Hash}. An example of this would be US FAA FE23.
To support this DIMEs are recommended to have an abbreviation that
could be used for this form. These abbreviations should be a maximum
of six characters (for each section) in length. Spaces should not be
used and be replaced with either underscores (_) or dashes (-).
The concatenation of {RAA Abbreviation} and {HDA Abbreviation} with a
space between them can be what fills in the HID field of the HHIT RR
in Appendix A.
For RAAs allocated in the ISO range Section 4.2.1, the RAA
abbreviation should be set to the ISO 3166-1 country code (either
Alpha-2 or Alpha-3). A common abbreviation for an RAAs four
allocated RAA values are out of scope. Other documents such as
[drip-dki] may have more specific recommendations or requirements.
If a DIME does not have an abbreviation or it can not be looked up
then the receiver must use the uppercase 4-character hexadecimal
encoding of the field it is missing when using this form.
Appendix C. DETs as Fully Qualified Domain Names
This appendix is informative.
{hash}.{oga_id}.{hda}.{raa}.{prefix}.{apex}.
When building a DET FQDN it MUST must be built using the exploded
(all padding present) form of the IPv6 address.
Apex: .example.com
DET: 2001:0030:0280:1405:c465:1542:a33f:dc26
ID: c4651542a33fdc26
OGA: 05
HID: 0028014
HDA: 0014
RAA: 000a
Prefix: 2001003
FQDN: c4651542a33fdc26.05.0014.000a.2001003.example.com
Wiethuechter & Reid Expires 3 October 2024 [Page 33]
Internet-Draft DETIM Architecture April 2024
Appendix D. DRIP Endorsements for UAS
This appendix is normative.
D.1. Self Endorsement
; e-type=0, Self Endorsement
$$evidence //= (eddsa25519-hi,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
Figure 7: Self Endorsement CDDL
Used during registration process as an input. $$evidence contains the
HI of the endorser. $$endorser contains the HHIT of the endorser.
$$signature contains the EdDSA25519 signature.
Wiethuechter & Reid Expires 3 October 2024 [Page 34]
Internet-Draft DETIM Architecture April 2024
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| VNB |
+---------------+---------------+---------------+---------------+
| VNA |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| HI |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| |
| HHIT |
| |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 8: Self Endorsement Binary
TODO
Figure 9: Self Endorsement CBOR
D.2. Broadcast Endorsement
Wiethuechter & Reid Expires 3 October 2024 [Page 35]
Internet-Draft DETIM Architecture April 2024
; e-type=1, SAM Type=1, Broadcast Endorsement
$$evidence //= (hhit, eddsa25519-hi,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
Figure 10: Broadcast Endorsement CDDL
Defined by [drip-auth] in a binary format to support Authentication
over ASTM [F3411] constrained links. Used in the DRIP Link format.
A required output of registration to a DIME at any level.
$$evidence are the child entities (e.g. a UA) DET/HHIT and its
associated HI. $$endorser contains the HHIT of the parent entity
(e.g. DIME) as the endorser. $$signature contains the EdDSA25519
signature.
Note that the Endorsement Type (e-type) field is the same value as
the SAM Type allocated to DRIP (i.e. the value 1). As such for DRIP
Authentication the e-type field is not encoded into the binary form
and is instead handled by the SAM Type of the Authentication framing.
Wiethuechter & Reid Expires 3 October 2024 [Page 36]
Internet-Draft DETIM Architecture April 2024
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| VNB |
+---------------+---------------+---------------+---------------+
| VNA |
+---------------+---------------+---------------+---------------+
| |
| HHIT of |
| Child |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| HI of |
| Child |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| |
| HHIT of |
| Parent |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 11: Broadcast Endorsement Binary
TODO
Wiethuechter & Reid Expires 3 October 2024 [Page 37]
Internet-Draft DETIM Architecture April 2024
Figure 12: Broadcast Endorsement CBOR
D.3. Wrapper Endorsement
; e-type=2, SAM Type=2, Wrapper Endorsement
$$evidence //= (*4 astm-message,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
astm-message = bstr .size(25)
Figure 13: Wrapper Endorsement CDDL
TODO
Figure 14: Wrapper Endorsement CBOR
TODO
Figure 15: Wrapper Endorsement Binary
D.4. Manifest Endorsement
; e-type=3, SAM Type=3, Manifest Endorsement
$$evidence //= (3*11 manifest-hash,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
manifest-hash = bstr .size(8)
Figure 16: Manifest Endorsement CDDL
TODO
Figure 17: Manifest Endorsement CBOR
TODO
Figure 18: Manifest Endorsement Binary
D.5. Frame Endorsement
; e-type=4, SAM Type=4, Frame Endorsement
$$evidence //= (frame-type, frame-data,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
frame-type = uint .size(1)
frame-data = bstr .size(1..111)
Figure 19: Frame Endorsement CDDL
Wiethuechter & Reid Expires 3 October 2024 [Page 38]
Internet-Draft DETIM Architecture April 2024
TODO
Figure 20: Frame Endorsement CBOR
TODO
Figure 21: Frame Endorsement Binary
Appendix E. DNS Examples
This appendix is informative.
E.1. Operator
@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN DET
( 2001003fff800005ba8af5252a35030e 0 1 "TEST DRIP" "" ... )
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN HIP
( 5 2001003fff800005ba8af5252a35030e ... )
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN URI
( https://example.com/operator/* )
E.2. Session ID
@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN DET
( 2001003fff800005b6ce935b616306d4 0 1 "TEST DRIP" "" ... )
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN HIP
( 5 2001003fff800005b6ce935b616306d4 ... )
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN URI
( https://example.com/session/* )
E.3. Child DIME
RAA:
@ORIGIN 8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
0.0.0 IN NS 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
HDA:
@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN DET
( 2001003fff8000054e486394a60bb669 0 1 "TEST DRIP" "" ... )
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN HIP
( 5 2001003fff8000054e486394a60bb669 ... )
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN URI
( https://example.com/dime/* )
Wiethuechter & Reid Expires 3 October 2024 [Page 39]
Internet-Draft DETIM Architecture April 2024
Authors' Addresses
Adam Wiethuechter (editor)
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Email: jim@rfc1035.com
Wiethuechter & Reid Expires 3 October 2024 [Page 40]