DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-10
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Adam Wiethuechter , Jim Reid | ||
| Last updated | 2023-06-13 (Latest revision 2023-03-28) | ||
| Replaces | draft-wiethuechter-drip-registries | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Early review
(of
-19)
by Ron Bonica
On the right track
DNSDIR Early review
(of
-18)
by David Blacka
On the right track
DNSDIR Early review
(of
-09)
by Tim Wicinski
On the right track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-drip-registries-10
drip Working Group A. Wiethuechter
Internet-Draft AX Enterprize, LLC
Intended status: Informational J. Reid
Expires: 15 December 2023 RTFM llp
13 June 2023
DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-10
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 are through 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 15 December 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wiethuechter & Reid Expires 15 December 2023 [Page 1]
Internet-Draft DETIM Architecture June 2023
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. Abstract Process and Reasoning . . . . . . . . . . . . . . . 4
2.1. Supported Scenarios . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Required Terminology . . . . . . . . . . . . . . . . . . 6
3.2. Additional Definitions . . . . . . . . . . . . . . . . . 6
4. DIME Roles . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Apex . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Registered Assigning Authority (RAA) . . . . . . . . . . 8
4.2.1. ISO 3166-1 Numeric Nations (INN) . . . . . . . . . . 9
4.2.2. Manufacturer Code Authority (MCA) . . . . . . . . . . 9
4.3. Hierarchial HIT Domain Authority (HDA) . . . . . . . . . 10
4.3.1. Manufacturer Unmanned Aircraft Authority (MAA) . . . 10
4.3.2. Session ID Authority (SIDA) . . . . . . . . . . . . . 10
4.4. Role Abbreviation in DETs . . . . . . . . . . . . . . . . 11
4.5. Text Conventions . . . . . . . . . . . . . . . . . . . . 11
5. DIME Architecture . . . . . . . . . . . . . . . . . . . . . . 11
5.1. DRIP Provisioning Agent (DPA) . . . . . . . . . . . . . . 12
5.2. Registry . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Name Server (NS) . . . . . . . . . . . . . . . . . . . . 13
5.4. DRIP Information Agent (DIA) . . . . . . . . . . . . . . 13
5.5. Registration Data Directory Service (RDDS) . . . . . . . 14
6. Registration/Provisioning Process . . . . . . . . . . . . . . 14
6.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Type 1 . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.2. Type 2 . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.3. Type 3 . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.4. Type 4 . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Operator . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Session ID . . . . . . . . . . . . . . . . . . . . . . . 20
6.3.1. UA Based . . . . . . . . . . . . . . . . . . . . . . 21
6.3.2. UAS Based . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Child DIME . . . . . . . . . . . . . . . . . . . . . . . 22
7. Differentiated Access Process . . . . . . . . . . . . . . . . 23
8. DRIP in the Domain Name System . . . . . . . . . . . . . . . 24
8.1. DRIP Entity Tags . . . . . . . . . . . . . . . . . . . . 25
8.1.1. DET Resource Record . . . . . . . . . . . . . . . . . 25
Wiethuechter & Reid Expires 15 December 2023 [Page 2]
Internet-Draft DETIM Architecture June 2023
8.2. Serial Numbers & Other UAS ID Types . . . . . . . . . . . 26
9. Endorsements . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Endorsement Structure . . . . . . . . . . . . . . . . . . 27
9.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1.2. Evidence . . . . . . . . . . . . . . . . . . . . . . 28
9.1.3. Identity . . . . . . . . . . . . . . . . . . . . . . 28
9.1.4. Signature . . . . . . . . . . . . . . . . . . . . . . 28
10. X.509 Certificates . . . . . . . . . . . . . . . . . . . . . 28
10.1. Certificate Policy and Certificate Stores . . . . . . . 28
10.2. Certificate Management . . . . . . . . . . . . . . . . . 29
10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 30
10.4. Alternative Certificate Encoding . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.1. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 30
11.1.1. Aircraft Information Registry . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12.1. Key Rollover & Federation . . . . . . . . . . . . . . . 31
12.2. DET Generation . . . . . . . . . . . . . . . . . . . . . 32
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. DRIP Fully Qualified Domain Names . . . . . . . . . 35
A.1. DRIP Entity Tag . . . . . . . . . . . . . . . . . . . . . 35
A.2. UAS Serial Number . . . . . . . . . . . . . . . . . . . . 35
Appendix B. DRIP Endorsements for UAS . . . . . . . . . . . . . 36
B.1. Generic Endorsement . . . . . . . . . . . . . . . . . . . 36
B.2. Self Endorsement . . . . . . . . . . . . . . . . . . . . 36
B.3. Broadcast Endorsement . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote
ID (RID). Only very limited operational information can be
Broadcast, 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 [drip-arch]).
While it is expected that DRIP Identity Management Entity (DIME)
functions will be integrated with UAS Service Suppliers (USS)
(Appendix A.2 of [drip-arch]), who will provide DIME-like functions
is not yet determined in most, and is expected to vary between,
jurisdictions. However this evolves, the essential DIME-like
functions (including the management of identifiers (such as the DRIP
Entity Tag (DET))) are expected to remain the same, so are specified
herein.
Wiethuechter & Reid Expires 15 December 2023 [Page 3]
Internet-Draft DETIM Architecture June 2023
While most data to be sent via Broadcast RID (Section 1.2.1 of
[drip-arch]) or Network RID (Section 1.2.2 of [drip-arch]) is public,
much of the extended information in registries will be private. As
discussed in Section 7 of [drip-arch], Authentication, Attestation,
Authorization, Access Control, Accounting, Attribution, and Audit
(AAA) for registries 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 should be human readable to facilitate analysis and
discussion, and machine readable to enable automated enforcement,
using a language amenable to both (e.g., eXtensible Access Control
Markup Language (XACML)).
The intent of the access control requirements on registries is to
ensure that no member of the public would be hindered from accessing
public information, while only duly authorized parties would be
enabled to access private information. Mitigation of Denial of
Service (DoS) attacks and refusal to allow database mass scraping
would be based on those behavior, not on identity or role of the
party submitting the query per se, but querant identity information
might be gathered (by security systems protecting DRIP
implementations) on such misbehavior.
Registration under DRIP is vital to manage the inevitable collisions
in the hash portion of the DET (Section 9.5 of [RFC9374]). Forgery
of a DET is still possible, but including it as a part of a public
registration mitigates this risk.
This document creates the DET registration and discovery ecosystem.
This includes all components in the ecosystem (e.g., 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. Abstract Process and Reasoning
In DRIP each entity (DIME, Operator, UA, etc.) is expected to
generate a DET [RFC9374] on the local device their key is expected to
be used. These are registered with a Public Information Registry
(e.g. DNS) within the hierarchy along with whatever data is required
by the cognizant CAA and the DIME. Any Personally Identifiable
Information (PII) is stored in a Private Information Registry
protected through industry practice AAA or stronger. In response,
Wiethuechter & Reid Expires 15 December 2023 [Page 4]
Internet-Draft DETIM Architecture June 2023
the entity will obtain an endorsement from the DIME proving such
registration.
Manufacturers that wish to participate in DRIP should not only
support DRIP as a Session ID type for their aircraft but could also
generate a DET then encode it as a Serial Number (Section 4.2 of
[RFC9374]). This would allow aircraft under CAA mandates to fly only
ID Type 1 (Serial Number) could still use DRIP and most of its
benefits. Even if DRIP is not supported for Serial Numbers by a
Manufacturer it is hoped that they would still run a DIME to store
their Serial Numbers and allow look ups for generic model
information. This look up could be especially helpful in UTM for
Situational Awareness when an aircraft flying with a Serial Number is
detected and allow for an aircraft profile to be displayed.
Operators are registered with a number of registries or their
regional RAA. This acts as a verification check when a user performs
other registration operations; such as provisioning an aircraft with
a new Session ID. It is an open question if an Operator registers to
their CAA (the RAA's direct HDA) or multiple USS's (HDA's). PII of
the Operator would vary based on the CAA they are under and the DIME.
Finally, aircraft that support using a DET would provision per flight
to a USS, proposing a DET to the DIME to generate a binding between
the aircraft (Session ID, Serial Number, and Operational Intent),
operator and DIME. The aircraft then follows [drip-auth] to meet
various requirements from [RFC9153] during a flight.
2.1. Supported Scenarios
1. UA using manufacturer generated Serial Number for UAS ID. No
additional information provided.
2. UA using manufacturer generated Serial Number for UAS ID.
Manufacturer using a DIME. Manufacturer MUST provided pointer to
additional information via DNS (even if null).
3. UA using manufacturer generated Serial Number which is mapped to
a DET by manufacturer for UAS ID. UA using manufacturer
generated DET for Authentication. Manufacturer using a DIME.
DIME MUST place public DET information into DNS (i.e. HI). DIME
MUST provide mapping of Serial Number to DET in DNS.
Manufacturer MUST provide pointer to additional information via
DNS (even if null).
4. UA using manufacturer generated DRIP enhanced Serial Number for
UAS ID. UA using manufacturer generated DET for Authentication.
Manufacturer using a DIME. DIME MUST place public information
Wiethuechter & Reid Expires 15 December 2023 [Page 5]
Internet-Draft DETIM Architecture June 2023
into DNS (i.e. HI) - either directly or as a mapping to a DET.
DIME MUST provide pointer to additional information via DNS (even
if null).
5. UA using manufacturer generated Serial Number for UAS ID. UA
using user generated DET for Authentication. User uses DIME with
capability to publically map Serial Number to a DET (via a USS).
DIME MUST place public DET information into DNS (i.e. HI). DIME
MUST provide mapping of Serial Number to DET in DNS. DIME MUST
provide pointer to additional information via DNS (even if null).
6. UA provisioned with DET (i.e. Session ID) with a DIME (via a
USS) for UAS ID and Authentication. DIME MUST place public DET
information into DNS (i.e. HI). DIME MUST NOT (unless required)
provide mapping of DET to Serial Number in DNS. USS MUST provide
pointer to additional information via DNS (even if null).
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
[drip-arch], while others (RAA, HDA, etc.) are from [RFC9374].
4. DIME Roles
[drip-arch] 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 and can be classified to serve a number of different
roles, which are detailed in the following subsections. The general
hierarchy of these roles are illustrated in Figure 1.
Wiethuechter & Reid Expires 15 December 2023 [Page 6]
Internet-Draft DETIM Architecture June 2023
+----------+
| Apex |
+-o------o-+
| |
******************|******|*****************************
| |
+-----o-+ +-o-----+
RAAs | IAM | | RAA o------.
+---o---+ +---o---+ '
| | |
****************|**********|**********|****************
| | |
+---o---+ +---o---+ +---o---+
HDAs | MAA | | SIDA | | HDA |
+-------+ +-------+ +-------+
Figure 1: DIME Roles and Hierarchy
4.1. Apex
The Apex is a special DIME role that holds the values of RAA=0-3 and
HDA=0. It serves as the branch point from the larger DNS system in
which DETs are defined. The Apex the IPv6 prefix portion of the DET
associated with it (2001:30/28) which is assigned by IANA from the
special IPv6 address space for ORCHIDs.
The Apex manages all delegations and allocations of the DET's RAA to
various parties. Allocations of RAAs SHOULD be done in contigous
groups of 4.
Wiethuechter & Reid Expires 15 December 2023 [Page 7]
Internet-Draft DETIM Architecture June 2023
+===================+=================+=============================+
| RAA Decimal Range | RAA Hex Range | Status |
+===================+=================+=============================+
| 0 - 3 | 0x0000 - | Apex |
| | 0x0003 | |
+-------------------+-----------------+-----------------------------+
| 1 - 3999 | 0x0001 - | ISO 3166-1 Countries |
| | 0x0F9F | (Section 4.2.1) |
+-------------------+-----------------+-----------------------------+
| 4000 - 4095 | 0x0FA0 - | Manufacturer Code |
| | 0x0FFF | Authorities (Section 4.2.2) |
+-------------------+-----------------+-----------------------------+
| 4096 - 16384 | 0x1000 - | Reserved |
| | 0x3FFF | |
+-------------------+-----------------+-----------------------------+
| 16376 - 16384 | 0x3FF8 - | DRIP WG Experimental Use |
| | 0x3FFF | |
+-------------------+-----------------+-----------------------------+
Table 1
RAA values of 0 (0x0000) to 3 (0x0003) are reserved to the Apex
exclusively.
The Experimental range of 16376 (0x3FF8) to 16384 (0x3FFF) is
allocated to the DRIP working group itself. 16381 to 16383 are setup
by DRIP experts to act as RAAs for potentional HDA users to test
against. 16384 is setup to be an RAA to act as a MCA Section 4.2.2
for UAS manufacturers to test their HDAs against and have their
Manufacturer Code properly managed. The rest of the range (16376 to
16380) are reserved to be allocate by the DRIP experts to buisnesses
that wish to test being an RAA.
4.2. Registered Assigning Authority (RAA)
RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field,
i.e. 16,384 RAAs, of an DET). An RAA is a business or organization
that manages a DIME of HDAs (Section 4.3). Most are contemplated to
be Civil Aviation Authorities (CAA), 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.
Wiethuechter & Reid Expires 15 December 2023 [Page 8]
Internet-Draft DETIM Architecture June 2023
An RAA must provide a set of services to allocate HDAs to
organizations. It must have a public policy on what is necessary to
obtain an HDA. It must maintain a DNS zone minimally for discovering
HID RVS servers. All RAA's have a single reserved HDA value: 0
(0x0000) for itself to support various functions or services. Other
HDA values can be allocated or reserved per RAA policy.
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.
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 contigous values 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 as "user assigned code elements" without specific claimaint
predefined in the RAA space. Withdrawn and other special codes also
do not have predetermined claimants.
How a CAA handles their 4 allocations are out of scope of this
document. Control of these values are expected to be claimed by
their respective owner. Protection against fraudulent claims of one
of these values is out of scope for this document.
4.2.2. Manufacturer Code Authority (MCA)
An RAA-level DIME that hands out HDA values to participating
Manufacturer's that hold an Manufacturer Code used in [CTA2063A] that
is issued by ICAO.
To manage the large Manufacturer Code space (34 character set; 4
characters; 1,336,336 possible codes) a range of RAA values are set
aside for the use case. These are the RAA values of 4000 (0x0FA0) up
to 4095 (0x0FFF). This allows a single HDA for each Manufacturer
Code.
See Section 4.3.1 for the HDA allocation of Manufacturer Codes under
these RAAs.
Wiethuechter & Reid Expires 15 December 2023 [Page 9]
Internet-Draft DETIM Architecture June 2023
Note: the upper RAAs in the range (4083 to 4095) are not used but
are left reserved in this space for future action if requried.
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 the actual entities that need DETs. This
includes, but is not limited to UA, GCS, UAS Operators and
infrastucture (such as Supplemental Data Service Providers). It
should also provide needed UAS services including those required for
HIP-enabled devices (e.g. RVS).
The HDA is a 14-bit field (16,384 HDAs per RAA) of a DET assigned by
an RAA. An HDA should maintain a set of RVS servers for UAS clients
that may use HIP. How this is done and scales to the potentially
millions of customers are outside the scope of this document. This
service should be discoverable through the DNS zone maintained by the
HDA's RAA.
An RAA may assign a block of values to an individual organization.
This is completely up to the individual RAA's published policy for
delegation. Such policy is out of scope.
4.3.1. Manufacturer Unmanned Aircraft Authority (MAA)
An HDA-level DIME run by a manufacturer of UAS systems that
participate in Remote ID. Stores UAS Serial Numbers under a specific
Manufacturer Code (assigned to the manufacturer by ICAO). The
specific RAA (out of MCA space) and HDA use the following derivation:
mfr_int = radix34(mfr_code)
hid = (4000 << 14) + mfr_int
raa = hid >> 14
hda = hid & 0x3FF
The Manufacturer Code radix character set is defined in [CTA2063A]
with the values being set as integers from 0 to 33. Standard base
conversion is used to convert from the base 34 character set to base
10.
A DET can be encoded into a Serial Number (see [RFC9374],
Section 4.2) and this DIME would hold a mapping from the Serial
Number to the DET and its artifacts.
4.3.2. Session ID Authority (SIDA)
Author Note: this subsection could be rolled into the main HDA
section removing the somewhat unnecessary abstraction.
Wiethuechter & Reid Expires 15 December 2023 [Page 10]
Internet-Draft DETIM Architecture June 2023
An HDA-level DIME that holds the binding between a UAS Session ID
(for DRIP the DET) and the UA Serial Number. The Serial Number MUST
have its access protected to allow only authorized parties to obtain.
The Serial Number SHOULD be encrypted in a way only the authorized
party can decrypt.
As part of the UTM system they also hold a binding between a UAS ID
(Serial Number or Session ID) and an Operational Intent. They may
either be a direct logical part of a UAS Service Supplier (USS) or be
a UTM wide service to USS's.
4.4. Role Abbreviation in DETs
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 in length. Spaces MUST NOT be used and be replaced
with either underscores (_) or dashes (-).
For RAAs allocated in the CAA range, the abbreviation MUST be set to
the ISO 3166-1 country code (either Alpha-2 or Alpha-3).
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.
4.5. 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.
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. For example:
* The Name Server component could be handled by a well-established
DNS registrar/registry with the DRIP Provisioning Agent (DPA)
(Section 5.1) interfacing to them
Wiethuechter & Reid Expires 15 December 2023 [Page 11]
Internet-Draft DETIM Architecture June 2023
- Either the DPA or the Registry/Name Server interfaces to the
DRIP Information Agent (DIA)
* The DPA, Registry, and Name Server may all be co-located in one
implementation with an interface to a DIA offered by another
organization from any one of the co-located components
+--------------------+
| Registering Client |
+---------o----------+
|
**********|******************************************************
* | DRIP Identity Management Entity *
* | *
* +------o-------+ +-------------+ +--------------+ *
* | DRIP | | | | | *
* | Provisioning o------o | | | *
* | Agent | | | | | *
* +-------o------+ | | | | *
* | | | | | *
* | | DRIP | | Registration | *
* +-------o--+ | Information o------o Data | *
* | Registry o----------o Agent | | Directory | *
* +-------o--+ | | | Service | *
* | | | | | *
* | | | | | *
* +-------o-----+ | | | | *
* | Name Server | | | | | *
* +------o------+ +-----o-------+ +------o-------+ *
* | | | *
* | | | *
**********|********************|*********************|***********
| | |
| +-------o-------+ |
'------------o Lookup Client o-------------'
+---------------+
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 delegate (internally or
externally) various items to other components in the DIME.
A standard interface MUST be provided for clients to access. An
HTTPS based interface is RECOMMENDED. This interface specification
is out of scope for this document.
Wiethuechter & Reid Expires 15 December 2023 [Page 12]
Internet-Draft DETIM Architecture June 2023
There MUST be an interface from the DPA to a Registry (Section 5.2)
component which handles the DNS specific requirements of the DIME as
defined by the Registry. There MAY also be interface from the DPA to
a DRIP Information Agent (Section 5.4) as defined by the DIA.
5.2. Registry
The Registry component handles all the required DNS based
requirements of the DIME to function for DRIP. This includes the
registration and maintenance of various DNS Resource Records.
A standardized interface MUST be implemented for interactions with
the DPA (Section 5.1). This interface MAY be over HTTPS using JSON/
CBOR encoding or MAY use the Extensional Provisioning Protocol (EPP)
[RFC5730]. The detailed specification of either of these interfaces
is out of scope for this document.
There MAY be interface from the Registry to a DRIP Information Agent
(Section 5.4) as defined by the DIA.
5.3. Name Server (NS)
The interface of the Name Server to any component (nominally the
Registry) in a DIME is out of scope as typically they are
implementation specific.
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.4. DRIP Information Agent (DIA)
The DIA is the main component handling requests for information from
entities outside of the DIME. Typically this is when an Observer
looks up a Session ID from an UA and gets pointed to the DIA to
obtain information not available publicly (i.e. via DNS).
The information contained in the DIA is generally more oriented
around the Operator of a given UAS and is thus classified as
Personally Identifiable Information (PII). To protect the privacy of
an Operator of the UAS this information is not publicly accessible
and is only available behind policy driven differentiated access
mechanisms (see Section 7).
Wiethuechter & Reid Expires 15 December 2023 [Page 13]
Internet-Draft DETIM Architecture June 2023
For DRIP, the Registration Data Access Protocol (RDAP) ([RFC7480],
[RFC9082] and [RFC9083]) is the selected protocol to provide policy
driven differentiated access for queries of information from clients.
There MUST be a standardized interface for the DPA or Registry to
add, update or delete information into the DIA. Specific details for
these interfaces are out of scope for this document.
An interface defined by the Registration Data Directory Service
(RDDS) (Section 5.5) is also required as specified by the RDDS.
5.5. Registration Data Directory Service (RDDS)
This is the primary information database for the DIA. An interface
MUST be provided to the DIA but its specification is out of scope for
this document.
6. Registration/Provisioning Process
The general process for a registering party is as follows:
1. Verify input Endorsement(s) from registering party
2. Check 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)
In the following subsections an abbreviated form of Section 5 using
co-located components is used to describe the flow of information.
The data elements being transmitted between entities is marked
accordingly in each figure for the specific examples.
6.1. Serial Number
There are four ways a Serial Number is supported by DRIP:
1. As a clear-text string with additional information
(Section 6.1.1)
2. As a clear-text string mapped to a DET "post" generation by the
*manufacturer* (for use in authentication) and additional
information (Section 6.1.2)
Wiethuechter & Reid Expires 15 December 2023 [Page 14]
Internet-Draft DETIM Architecture June 2023
3. As a clear-text string mapped to a DET "post" generation by the
*user (via an HDA)* (for use in authentication) and additional
information (Section 6.1.3)
4. As an encoding of an HI and associated DET by the *manufacturer*
(for use in authentication) with additional information
(Section 6.1.4)
Note: additional information here refers to any subset of keys
defined in Section 11.1.1.
6.1.1. Type 1
This is where a UA is provisioned with a Serial Number by the
manufacturer. The Serial Number is just text string, defined by
[CTA2063A]. The manufacturer runs an MAA and uses the mechanisms of
this document to provide additional information.
+-------------------+
| Unmanned Aircraft |
+--o---o------------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: MAA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Serial Number,
UA Information
(b) Success Code
(c) NAPTR RR
(d) UA Information
Figure 3: Example DIME:MAA with Serial Number Registration
Wiethuechter & Reid Expires 15 December 2023 [Page 15]
Internet-Draft DETIM Architecture June 2023
6.1.2. Type 2
This is where a UAS is provisioned with a Serial Number and DET by
the manufacturer enabling their devices to use [drip-auth] and
provide additional information. A public mapping of the Serial
Number to DET and all public artifacts MUST be provided by the
manufacturer. This document RECOMMENDS the manufacturer use an MAA
for this task.
+-------------------+
| Unmanned Aircraft |
+--o---o------------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: MAA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Serial Number,
UA Information,
Self-Endorsement: UA
(b) Success Code,
Broadcast Endorsement: MAA on UA
(c) HIP RR,
CERT RRs,
NAPTR RR,
"Link" RR
(d) UA Information
Figure 4: Example DIME:MAA with Serial Number + DET Registration
Wiethuechter & Reid Expires 15 December 2023 [Page 16]
Internet-Draft DETIM Architecture June 2023
6.1.3. Type 3
This is where a UAS has a Serial Number (from the manufacturer) and
the user (via a DIME) has a mechanism to generate and map a DET to
the Serial Number after production. This can provide dynamic signing
keys for DRIP Authentication Messages via [drip-auth] for UAS that
MUST fly only using Serial Numbers. Registration SHOULD be allowed
to any relevant DIME that supports it. A public mapping of the DET
to the Serial Number SHOULD be provided.
+-------------------+
| Unmanned Aircraft |
+--o---o------------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Serial Number,
UA Information,
Self-Endorsement: UA
(b) Success Code,
Broadcast Endorsement: DIME on UA
(c) HIP RR,
CERT RRs,
NAPTR RR,
"Link" RR
(d) UA Information
Figure 5: Example DIME with Serial Number + DET Registration
Wiethuechter & Reid Expires 15 December 2023 [Page 17]
Internet-Draft DETIM Architecture June 2023
6.1.4. Type 4
This is where a UAS manufacturer chooses to use the Serial Number
scheme defined in [RFC9374] to create Serial Numbers, their
associated DETs for [drip-auth] and provide additional information.
This document RECOMMENDEDS that the manufacturer "locks" the device
from changing its authentication method so identifiers in both the
Basic ID Message and Authentication Message do not de-sync. The
manufacturer MUST use an MAA for this task, with the mapping between
their Manufacturer Code and the upper portion of the DET publicly
available.
+-------------------+
| Unmanned Aircraft |
+--o---o------------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: MAA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Serial Number,
UA Information,
Self-Endorsement: UA
(b) Success Code,
Broadcast Endorsement: MAA on UA
(c) HIP RR,
CERT RRs,
NAPTR RR,
"Link" RR
(d) UA Information
Figure 6: Example DIME:MAA with DRIP Serial Number Registration
Wiethuechter & Reid Expires 15 December 2023 [Page 18]
Internet-Draft DETIM Architecture June 2023
6.2. Operator
Provided either by USS or CAA run HDAs. Regulation might require
interaction between them. An Operator can request that certain
information normally generated and provisioned into DNS be omitted
due to privacy concerns.
+----------+
| Operator |
+--o---o---+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME:HDA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Operator Information,
Operator Self-Endorsement
(b) Success Code,
Generic Endorsement: HDA on Operator
(c) HIP RR,
CERT RRs
(d) Operator Information
Note: (c) MAY be requested by the Operator to be omitted due to PII concerns.
Figure 7: Example DIME:HDA with Operator (DET) Registration
The definition of Operator Information is out of scope of this
document and left to local regulations (both in its format and
contents).
Wiethuechter & Reid Expires 15 December 2023 [Page 19]
Internet-Draft DETIM Architecture June 2023
6.3. Session ID
Session IDs are generally handled by HDAs, specifically SIDAs. In
Figure 8 the UAS comprises of an unmanned aircraft and a Ground
Control Station (GCS). Both parties are involved in the registration
process.
+---------+
| UAS |
+--o---o--+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: SIDA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Mutual Endorsement: SIDA on GCS,
Generic Endorsement: GCS on UA,
Session ID Information
(b) Success Code,
Broadcast Endorsement: SIDA on UA,
Generic Endorsement: SIDA on UAS
(c) HIP RR,
TLSA, RR,
CERT RRs
(d) Session ID Information
Figure 8: Example DIME:SIDA with Session ID (DET) Registration
Through mechanisms not specified in this document the Operator should
have methods (via the GCS) to instruct the unmanned aircraft onboard
systems to generate a keypair, DET and Self-Endorsement: UA. The
Self-Endorsement: UA is extracted by the Operator onto the GCS.
Wiethuechter & Reid Expires 15 December 2023 [Page 20]
Internet-Draft DETIM Architecture June 2023
The GCS is already pre-provisioned and registered to the DIME with
its own keypair, DET, Self-Endorsement: GCS and Generic Endorsement:
SIDA on GCS. The GCS creates a new Generic Endorsement: GCS on UA
and also creates Mutual Endorsement: SIDA on GCS. These new
endorsements along with Session ID Information are sent to the DIME
via a secure channel.
The GCS injects the Broadcast Endorsement: SIDA on UA securely into
the unmanned aircraft. Endorsement: SIDA on GCS is securely stored
by the GCS.
Note: in Figure 8 the Session ID Information is expected to
contain the Serial Number along with other PII specific
information (such as UTM data) related to the Session ID.
Session ID Information is defined as the current model:
sessionid_info = {
serial: tstr .size 20,
session_id: tstr,
operational_intent: tstr,
intent_src: tstr,
operator_id: tstr,
* tstr: any
}
Future standards or implementations MAY add other keys to this list
(for local features and/or local regulation).
6.3.1. UA Based
There may be some unmanned aircraft that have their own Internet
connectivity allowing them to register a Session ID themselves
without outside help from other devices such as a GCS. When such a
system is in use its imperative that the Operator has some method to
create the Generic Endorsement: Operator on UA to send to the DIME.
The process and methods to perform this are out of scope for this
document but MUST be done in a secure fashion.
6.3.2. UAS Based
Most unmanned aircraft will not have their own Internet connectivity
but will have a connection to a GCS. Typically a GCS is an
application on a user device (such as smartphone) that allow the user
to fly their aircraft. For the Session ID registration the DIME MUST
be provided with an Generic Endorsement: GCS on UA which implies
there is some mechanism extracting and inserting information from the
unmanned aircraft to the GCS. These methods MUST be secure but are
Wiethuechter & Reid Expires 15 December 2023 [Page 21]
Internet-Draft DETIM Architecture June 2023
out of scope for this document.
With this system it is also possible to have the GCS generate the DET
based Session ID and insert it securely into the unmanned aircraft
after registration is done. This is NOT RECOMMENDED as this
invalidates the objective of the asymmetric cryptography in the
underlying DET as the private key MAY get in the possession of
another entity other than the unmanned aircraft. See Section 12.2
for more details.
6.4. Child DIME
Handled by the Apex and RAA's. This is an endpoint that handles
dynamic registration (or key roll-over) of lower-level DIMEs (RAAs to
Apex and HDAs to RAAs) in the hierarchy.
+---------------+
| DIME: HDA |
+--o---o--------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: RAA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Self-Endorsement: HDA,
HDA Information or
Generic Endorsement: old HDA, new HDA
(b) Success Code,
Broadcast Endorsement: RAA on HDA
(c) HIP RR,
CERT RRs
(d) HDA Information
Wiethuechter & Reid Expires 15 December 2023 [Page 22]
Internet-Draft DETIM Architecture June 2023
Figure 9: Example DIME:RAA with DIME:HDA Registration
It should be noted that this endpoint DOES NOT hand out dynamically
RAA/HDA values to systems that hit the endpoint. This is done out-
of-band through processes specified by local regulations and
performed by cognizant authorities. The endpoint MUST NOT accept
queries it is not previously informed of being expected via
mechanisms not defined in this document.
It is OPTIONAL to implement this endpoint. This MAY be used to
handle lower-level DIME key roll-over.
7. Differentiated Access Process
Per [drip-arch] all information classified as public 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. [drip-arch] 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.
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).
Wiethuechter & Reid Expires 15 December 2023 [Page 23]
Internet-Draft DETIM Architecture June 2023
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 [drip-arch] all information classified as public is stored in the
DNS to satisfy REG-1 from [RFC9153].
Author Note: this section needs a little rework due to the
ISO-3166 delegation that we do, thus taking ICAO somewhat out of
the loop.
The apex for domain names MUST be under the administrative control of
ICAO, the international treaty organization providing the critical
coordination platform for civil aviation. ICAO SHOULD be responsible
for the operation of the DNS-related infrastructure for these domain
name apexes. It MAY chose to run that infrastructure directly or
outsource it to competent third parties or some combination of the
two. ICAO 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.
ICAO SHOULD delegate domains beneath these apexes to national civil
aviation authorities. This ensures DRIP complies with national law
and regulation since these are matters of national sovereignty. The
HHIT has a designated field, the RAA, for this exact purpose and
SHOULD be used instead of a ISO-3166 entries: ie a two- or three-
letter or a three digit country code.
Wiethuechter & Reid Expires 15 December 2023 [Page 24]
Internet-Draft DETIM Architecture June 2023
Each national aviation authority SHOULD be responsible for the
operation of the DNS-related infrastructure for their delegated
subdomains. As with the domain apexes overseen by ICAO, each
national aviation authority MAY chose to run that infrastructure
directly or outsource it to competent third parties or some
combination of the two. National aviation authorities 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. These are
National Matters where national law/regulation prevail. National
policy and reguations will define how long DNS data are stored or
archived.
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.
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 ICAO. In addition to the DNS
infrastructure for 3.0.0.1.0.0.2.ip6.arpa, ICAO 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 on a
country by country basis, using the 14-bit RAA space as a framework.
ICAO SHOULD allocate blocks to each National Aviation Authority 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 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 an DET RRtype and not a PTR RRtype.
8.1.1. DET Resource Record
Wiethuechter & Reid Expires 15 December 2023 [Page 25]
Internet-Draft DETIM Architecture June 2023
Author Note: This section is very much a WIP, comments are
welcome.
<domain> DET IN ( OGAID DET HI RVS RAA HDA URI Endorsement )
OGAID = Integer value of OGA ID -- taken from HIP RR
DET = Base16 DET -- taken from HIP RR
HI = Base64 Host Identity -- taken from HIP RR
RVS = List of Rendevous Server addresses -- taken from HIP RR
RAA = RAA Abbreviation
HDA = HDA Abbreviation
URI = URI to assocaited DIA
Endorsement = Broadcast Endorsements in CBOR encoding
8.2. Serial Numbers & Other UAS ID Types
Author Note: There MUST be an entry point in DNS for the lookup of
UAS Serial Numbers. This section is very much a shot in the dark.
This document specifies the creation and delegation to ICAO of the
subdomain uas.icao.arpa. To enable lookup of Serial Numbers a
subdomains of sn.uas.icao.arpa is maintained. All entries under
sn.uas.icao.arpa are to follow the convention found in Appendix A.2.
This is to enable a singular lookup point for Serial Numbers for UAS.
Note that other subdomains under uas.icao.arpa can be made to support
other identifiers in UAS. The creation and use of other such other
subdomains are out of scope for this document. The further use and
creation of items under icao.arpa is the authority of ICAO (which has
been delegated control).
DETs MUST not have a subdomain in uas.icao.arpa (such as
det.uas.icao.arpa) as they fit within the predefined ip6.arpa as they
are IPv6 addresses.
9. Endorsements
DRIP Endorsements are defined in a CDDL [RFC8610] structure
(Figure 10) that can be encoded to CBOR, JSON or have their CDDL keys
removed and be sent as a binary blob. When the latter is used very
specific forms are defined with naming conventions to know the data
fields and their lengths for parsing and constrained envirornments.
CBOR is the preferred encoding format.
Wiethuechter & Reid Expires 15 December 2023 [Page 26]
Internet-Draft DETIM Architecture June 2023
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.
Appendix B specifies specific Endorsement structures for the UAS RID
use-case.
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. Specific use-cases SHOULD add new keys for each
section (if required) and define the valid keys and encoding forms
for their use-case.
9.1. Endorsement Structure
endorsement = {
; TODO: add tag for self-describing type or leave up to cbor?
scope: {
vnb: number,
vna: number,
* tstr => any
},
evidence: bstr,
endorser: {
identity: {
hhit: bstr .size 16, ? hi: bstr // * tstr => any
},
signature: {
sig: bstr,
* tstr => any
}
}
}
Figure 10: Endorsement CDDL
9.1.1. Scope
The scope section is more formally "the 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.
Wiethuechter & Reid Expires 15 December 2023 [Page 27]
Internet-Draft DETIM Architecture June 2023
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.
9.1.2. Evidence
The evidence section contain a byte string of evidence. Specific
content of evidence (such as subfields, length and ordering) is
defined in specific Endorsement structures.
9.1.3. Identity
The identity section is 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). Other keys, for
different identifiers, can be provided and MUST be defined in their
specific Endorsement.
The length of the hi can be determined when using hhit by decoding
the provided IPv6 address. The prefix will inform of the ORCHID
construction being used, which informs the locations of the OGA ID in
the address. The OGA ID will then inform the user of the key
algorithm selected which has the key length defined.
9.1.4. Signature
The signature section contain the signature data for the Endorsement.
The signature itself MUST be provided under the sig key. Other forms
or data elements could also be present in the signature section if
specified in a specific Endorsement. Signatures MUST be generated
using the preceding sections in their binary forms (i.e. as a
bytestring with no keys).
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 covered in this document will also have certificates to
create and manage the necessary PKI structure.
Wiethuechter & Reid Expires 15 December 2023 [Page 28]
Internet-Draft DETIM Architecture June 2023
Any Certificate Authority (CA) supporting DRIP entities SHOULD adhere
to the ICAO's International Aviation Trust Framework (IATF)
Certificate Policy [ICAO-IATF-CP-draft]. The CA(s) supporting this
CP MUST either be a part of the IATF Bridge PKI or part of the IATF
CA Trust List.
EEs may use their X.509 certificates, rather than their rawPublicKey
(i.e. HI) in authentication protocols (as not all may support
rawPublicKey identities). Some EE HI may not be 'worth' supporting
the overhead of X.509. 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
not AfterDate will 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.
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. 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 MUST be available via RDAP. LDAP/OCSP access for other
UTM and ICAO uses SHOULD also be provided.
10.2. Certificate Management
(mostly TBD still)
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.
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.
Details of this are left out, as there are a number of approaches and
further research and experience will be needed.
Wiethuechter & Reid Expires 15 December 2023 [Page 29]
Internet-Draft DETIM Architecture June 2023
10.3. Examples
TBD
10.4. Alternative Certificate Encoding
(CBOR encoded certs here. TBD)
11. IANA Considerations
11.1. IANA DRIP Registry
11.1.1. Aircraft Information Registry
This document requests a new registry for aircraft information fields
under the DRIP registry group (https://www.iana.org/assignments/drip/
drip.xhtml).
Aircraft Information Fields: list of acceptable keys to be used in
UA Information during a UA registration to a DIME. Future
additions to this registry are to be made through First Come First
Served (Section 4.4 of [RFC8126]). The following values are
defined:
+======================+=======+========================+
| Key Name | Type | Description |
+======================+=======+========================+
| length | float | length, in millimeters |
+----------------------+-------+------------------------+
| width | float | width, in millimeters |
+----------------------+-------+------------------------+
| height | float | height, in millimeters |
+----------------------+-------+------------------------+
| constructionMaterial | tstr | materials, comma |
| | | separated if multiple |
+----------------------+-------+------------------------+
| color | tstr | colors, comma |
| | | separated if multiple |
+----------------------+-------+------------------------+
| serial | tstr | ANSI CTA 2063-A Serial |
| | | Number |
+----------------------+-------+------------------------+
| manufacturer | tstr | manufacturer name |
+----------------------+-------+------------------------+
| make | tstr | aircraft make |
+----------------------+-------+------------------------+
| model | tstr | aircraft model |
+----------------------+-------+------------------------+
Wiethuechter & Reid Expires 15 December 2023 [Page 30]
Internet-Draft DETIM Architecture June 2023
| dryWeight | float | weight of aircraft |
| | | with no payloads |
+----------------------+-------+------------------------+
| numRotors | int | Number of rotators |
+----------------------+-------+------------------------+
| propLength | float | Length of props, in |
| | | centimeters |
+----------------------+-------+------------------------+
| numBatteries | int | |
+----------------------+-------+------------------------+
| batteryCapacity | float | in milliampere hours |
+----------------------+-------+------------------------+
| batteryWeight | float | in kilograms |
+----------------------+-------+------------------------+
| batteryVoltage | float | in volts |
+----------------------+-------+------------------------+
| batteryChemistry | tstr | |
+----------------------+-------+------------------------+
| maxTakeOffWeight | float | in kilograms |
+----------------------+-------+------------------------+
| maxPayloadWeight | float | in kilograms |
+----------------------+-------+------------------------+
| maxFlightTime | float | in minutes |
+----------------------+-------+------------------------+
| minOperatingTemp | float | in Celsius |
+----------------------+-------+------------------------+
| maxOperatingTemp | float | in Celsius |
+----------------------+-------+------------------------+
| ipRating | tstr | standard IP rating |
+----------------------+-------+------------------------+
| engineType | tstr | |
+----------------------+-------+------------------------+
| fuelType | tstr | |
+----------------------+-------+------------------------+
| fuelCapacity | float | in liters |
+----------------------+-------+------------------------+
| previousSerial | tstr | legacy serial |
| | | number(s) |
+----------------------+-------+------------------------+
Table 2
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.
Wiethuechter & Reid Expires 15 December 2023 [Page 31]
Internet-Draft DETIM Architecture June 2023
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. An endpoint
such as in Section 6.4 is a possible place to have these functions.
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.
Under the FAA [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.
Wiethuechter & Reid Expires 15 December 2023 [Page 32]
Internet-Draft DETIM Architecture June 2023
13. 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.
14. References
14.1. Normative References
[drip-arch]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-31, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
arch-31>.
[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>.
14.2. Informative References
Wiethuechter & Reid Expires 15 December 2023 [Page 33]
Internet-Draft DETIM Architecture June 2023
[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-02, 12 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dance-
client-auth-02>.
[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-30, 27 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
auth-30>.
[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-12, 26 March 2023,
<https://datatracker.ietf.org/doc/html/draft-moskowitz-
drip-secure-nrid-c2-12>.
[NPRM] "Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", December 2019.
[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>.
[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>.
Wiethuechter & Reid Expires 15 December 2023 [Page 34]
Internet-Draft DETIM Architecture June 2023
[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>.
[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>.
[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>.
[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. DRIP Fully Qualified Domain Names
A.1. DRIP Entity Tag
{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: .det.uas.icao.arpa.
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.det.uas.icao.arpa.
A.2. UAS Serial Number
{id}.{length}.{manufacturer-code}.{apex}.
Wiethuechter & Reid Expires 15 December 2023 [Page 35]
Internet-Draft DETIM Architecture June 2023
Apex: .sn.uas.icao.arpa.
Serial: MFR0ADR1P1SC00L
Manufacturer Code: MFR0
Length: A
ID: DR1P1SC00L
FQDN: dr1p1sc00l.a.mfr0.sn.uas.icao.arpa.
Appendix B. DRIP Endorsements for UAS
B.1. Generic Endorsement
generic_endorsement = {
scope: {
vnb: number,
vna: number
},
evidence: bstr,
endorser: {
identity: {
hhit: bstr .size 16
},
signature: {
sig: bstr
}
}
}
Figure 11: Generic Endorsement CDDL
evidence is a binary string with specified contents (in format and
ordering) by specific use-cases. As an example this format is used
by [drip-auth] to support Authentication over F3411 constrained
links. evidence data is defined by [drip-auth] for DRIP Wrapper,
Manifest and Frame formats.
B.2. Self Endorsement
Wiethuechter & Reid Expires 15 December 2023 [Page 36]
Internet-Draft DETIM Architecture June 2023
self_endorsement = {
scope: {
vnb: number,
vna: number
},
evidence: bstr,
endorser: {
identity: {
hhit: bstr .size 16
},
signature: {
sig: bstr
}
}
}
Figure 12: Self Endorsement CDDL
Used during registration process as an input. evidence is filled with
the corresponding HI of the hhit.
Wiethuechter & Reid Expires 15 December 2023 [Page 37]
Internet-Draft DETIM Architecture June 2023
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 13: Self Endorsement Binary
TODO
Figure 14: Self Endorsement CBOR
B.3. Broadcast Endorsement
Wiethuechter & Reid Expires 15 December 2023 [Page 38]
Internet-Draft DETIM Architecture June 2023
broadcast_endorsement = {
scope: {
vnb: number,
vna: number
},
evidence: bstr,
endorser: {
identity: {
hhit: bstr .size 16
},
signature: {
sig: bstr
}
}
}
Figure 15: Broadcast Endorsement CDDL
Defined by [drip-auth] in a binary format to support Authentication
over F3411 constrained links. Used in the DRIP Link format. A
required output of registration to a DIME at any level. evidence is a
binary string of the concatination of a child entities (e.g. a UA)
HHIT and its associated HI. hhit is of the parent entity (e.g. a
DIME).
Wiethuechter & Reid Expires 15 December 2023 [Page 39]
Internet-Draft DETIM Architecture June 2023
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 16: Broadcast Endorsement Binary
TODO
Wiethuechter & Reid Expires 15 December 2023 [Page 40]
Internet-Draft DETIM Architecture June 2023
Figure 17: Broadcast Endorsement CBOR
Authors' Addresses
Adam Wiethuechter
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 15 December 2023 [Page 41]