draft-ietf-drip-arch-23.txt   draft-ietf-drip-arch-24.txt 
drip S. Card drip S. Card
Internet-Draft A. Wiethuechter Internet-Draft A. Wiethuechter
Intended status: Informational AX Enterprize Intended status: Informational AX Enterprize
Expires: 2 December 2022 R. Moskowitz Expires: 12 December 2022 R. Moskowitz
HTT Consulting HTT Consulting
S. Zhao (Editor) S. Zhao (Editor)
Tencent Tencent
A. Gurtov A. Gurtov
Linköping University Linköping University
31 May 2022 10 June 2022
Drone Remote Identification Protocol (DRIP) Architecture Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-23 draft-ietf-drip-arch-24
Abstract Abstract
This document describes an architecture for protocols and services to This document describes an architecture for protocols and services to
support Unmanned Aircraft System (UAS) Remote Identification (RID) support Unmanned Aircraft System (UAS) Remote Identification (RID)
and tracking, plus UAS RID-related communications. This architecture and tracking, plus UAS RID-related communications. This architecture
adheres to the requirements listed in the DRIP Requirements document adheres to the requirements listed in the DRIP Requirements document
(RFC9153). (RFC9153).
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 December 2022. This Internet-Draft will expire on 12 December 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID)
and Standardization . . . . . . . . . . . . . . . . . . . 3 and Standardization . . . . . . . . . . . . . . . . . . . 3
1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4
1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5
1.3. Overview of USS Interoperability . . . . . . . . . . . . 7 1.3. Overview of USS Interoperability . . . . . . . . . . . . 7
1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 8 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 8
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 10 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 10
2.1. Additional Abbreviations . . . . . . . . . . . . . . . . 10 2.1. Additional Abbreviations . . . . . . . . . . . . . . . . 10
2.2. Additional Definitions . . . . . . . . . . . . . . . . . 11 2.2. Additional Definitions . . . . . . . . . . . . . . . . . 11
3. HHIT as the DRIP Entity Identifier . . . . . . . . . . . . . 11 3. HHIT as the DRIP Entity Identifier . . . . . . . . . . . . . 11
3.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 12 3.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 12
3.2. HHIT as A Trustworthy DRIP Entity Identifier . . . . . . 12 3.2. HHIT as A Trustworthy DRIP Entity Identifier . . . . . . 12
3.3. HHIT for DRIP Identifier Registration and Lookup . . . . 14 3.3. HHIT for DRIP Identifier Registration and Lookup . . . . 14
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. EPP and RDAP as the Private DRIP Identifier 4.2.2. EPP and RDAP as the Private DRIP Identifier
Registry . . . . . . . . . . . . . . . . . . . . . . 16 Registry . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Alternative Private DRIP Registry methods . . . . . . 16 4.2.3. Alternative Private DRIP Registry methods . . . . . . 16
5. DRIP Identifier Trust . . . . . . . . . . . . . . . . . . . . 16 5. DRIP Identifier Trust . . . . . . . . . . . . . . . . . . . . 16
6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 17 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 17
6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 18
6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 18
7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18 7. DRIP Contact . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Post Quantum Computing out of scope . . . . . . . . . . . 20 8.1. Private Key Physical Security . . . . . . . . . . . . . . 20
9. Privacy & Transparency Considerations . . . . . . . . . . . . 20 8.2. Post Quantum Computing Out Of Scope . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.3. Denial Of Service (DOS) Protection Out Of Scope . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 9. Privacy & Transparency Considerations . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic
Management (UTM) . . . . . . . . . . . . . . . . . . . . 24 Management (UTM) . . . . . . . . . . . . . . . . . . . . 25
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 24
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 25 A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 25
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 25 A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 26
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 26
Appendix B. Automatic Dependent Surveillance Broadcast Appendix B. Automatic Dependent Surveillance Broadcast
(ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 26 (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document describes an architecture for protocols and services to This document describes an architecture for protocols and services to
support Unmanned Aircraft System (UAS) Remote Identification (RID) support Unmanned Aircraft System (UAS) Remote Identification (RID)
and tracking, plus RID-related communications. The architecture and tracking, plus RID-related communications. The architecture
takes into account both current (including proposed) regulations and takes into account both current (including proposed) regulations and
non-IETF technical standards. non-IETF technical standards.
skipping to change at page 4, line 35 skipping to change at page 4, line 39
With release 16, the 3GPP completed the UAS RID requirement study With release 16, the 3GPP completed the UAS RID requirement study
[TS-22.825] and proposed a set of use cases in the mobile network [TS-22.825] and proposed a set of use cases in the mobile network
and services that can be offered based on UAS RID. Release 17 and services that can be offered based on UAS RID. Release 17
specification focuses on enhanced UAS service requirements and specification focuses on enhanced UAS service requirements and
provides the protocol and application architecture support that provides the protocol and application architecture support that
will be applicable for both 4G and 5G networks. The study of will be applicable for both 4G and 5G networks. The study of
Further Architecture Enhancement for Uncrewed Aerial Vehicles Further Architecture Enhancement for Uncrewed Aerial Vehicles
(UAV) and Urban Air Mobility (UAM) [FS_AEUA] in release 18 further (UAV) and Urban Air Mobility (UAM) [FS_AEUA] in release 18 further
enhances the communication mechanism between UAS and USS/UTM. The enhances the communication mechanism between UAS and USS/UTM. The
UAS RID discussed in Section 3 may be used as the 3GPP CAA-level DRIP Entity Tag in Section 3 may be used as the 3GPP CAA-level UAS
UAS ID for Remote Identification purposes. ID for Remote Identification purposes.
1.2. Overview of Types of UAS Remote ID 1.2. Overview of Types of UAS Remote ID
This specification introduces two types UAS Remote ID defined in ASTM This specification introduces two types UAS Remote ID defined in ASTM
[F3411]. [F3411].
1.2.1. Broadcast RID 1.2.1. Broadcast RID
[F3411] defines a set of UAS RID messages for direct, one-way, [F3411] defines a set of UAS RID messages for direct, one-way,
broadcast transmissions from the UA over Bluetooth or Wi-Fi. These broadcast transmissions from the UA over Bluetooth or Wi-Fi. These
skipping to change at page 12, line 24 skipping to change at page 12, line 24
A DRIP entity identifier needs to be "Trustworthy" (See DRIP A DRIP entity identifier needs to be "Trustworthy" (See DRIP
Requirement GEN-1, ID-4 and ID-5 in [RFC9153]). This means that Requirement GEN-1, ID-4 and ID-5 in [RFC9153]). This means that
given a sufficient collection of UAS RID messages, an Observer can given a sufficient collection of UAS RID messages, an Observer can
establish that the identifier claimed therein uniquely belongs to the establish that the identifier claimed therein uniquely belongs to the
claimant. To satisfy DRIP requirements and maintain important claimant. To satisfy DRIP requirements and maintain important
security properties, the DRIP identifier should be self-generated by security properties, the DRIP identifier should be self-generated by
the entity it names (e.g., a UAS) and registered (e.g., with a USS, the entity it names (e.g., a UAS) and registered (e.g., with a USS,
see Requirements GEN-3 and ID-2). see Requirements GEN-3 and ID-2).
Broadcast RID, especially its support for Bluetooth 4, imposes severe Broadcast RID, especially its support for Bluetooth 4.x, imposes
constraints. ASTM UAS RID [F3411] allows a UAS ID of types 1, 2 and severe constraints. ASTM UAS RID [F3411] allows a UAS ID of types 1,
3 of 20 bytes; a revision to [F3411], currently in balloting (as of 2 and 3 of 20 bytes; a revision to [F3411], currently in balloting
Oct 2021), adds type 4, Specific Session ID, to be standardized by (as of Oct 2021), adds type 4, Specific Session ID, to be
IETF and other standards development organizations (SDOs) as standardized by IETF and other standards development organizations
extensions to ASTM UAS RID, consumes one of those bytes to index the (SDOs) as extensions to ASTM UAS RID, consumes one of those bytes to
sub-type, leaving only 19 for the identifier (see DRIP Requirement index the sub-type, leaving only 19 for the identifier (see DRIP
ID-1). Requirement ID-1).
Likewise, the maximum ASTM UAS RID [F3411] Authentication Message Likewise, the maximum ASTM UAS RID [F3411] Authentication Message
payload is 201 bytes for most authentication types. A type 5 is also payload is 201 bytes for most authentication types. A type 5 is also
added in this revision for IETF and other SDOs to develop Specific added in this revision for IETF and other SDOs to develop Specific
Authentication Methods as extensions to ASTM UAS RID. One byte out Authentication Methods as extensions to ASTM UAS RID. One byte out
of 201 bytes is consumed to index the sub-type which leaves only 200 of 201 bytes is consumed to index the sub-type which leaves only 200
for DRIP authentication payloads, including one or more DRIP entity for DRIP authentication payloads, including one or more DRIP entity
identifiers and associated authentication data. identifiers and associated authentication data.
3.2. HHIT as A Trustworthy DRIP Entity Identifier 3.2. HHIT as A Trustworthy DRIP Entity Identifier
skipping to change at page 13, line 36 skipping to change at page 13, line 36
use HHITs for their IDs. Such HHITs can facilitate DRIP security use HHITs for their IDs. Such HHITs can facilitate DRIP security
functions such as used with HIP to strongly mutually authenticate and functions such as used with HIP to strongly mutually authenticate and
encrypt communications. encrypt communications.
A self-attestation of a HHIT used as a UAS ID can be done in as A self-attestation of a HHIT used as a UAS ID can be done in as
little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an
explicit encoding technology like ASN.1 or Concise Binary Object explicit encoding technology like ASN.1 or Concise Binary Object
Representation (CBOR [RFC8949]). This attestation consists of only Representation (CBOR [RFC8949]). This attestation consists of only
the HHIT, a timestamp, and the EdDSA signature on them. the HHIT, a timestamp, and the EdDSA signature on them.
Ed25519 [RFC8032] is used as the HHIT signing algorithm as [RFC9153]
GEN-1 and ID-5 can best be met by restricting the HI to 32 bytes. A
larger public key would rule out the offline attestation feature that
fits within the 200-byte Authentication Message maximum length.
Other algorithms that meet this 32 byte constraint can be added as
deemed needed.
A DRIP identifier can be assigned to a UAS as a static HHIT by its A DRIP identifier can be assigned to a UAS as a static HHIT by its
manufacturer, such as a single HI and derived HHIT encoded as a manufacturer, such as a single HI and derived HHIT encoded as a
hardware serial number per [CTA2063A]. Such a static HHIT SHOULD hardware serial number per [CTA2063A]. Such a static HHIT SHOULD
only be used to bind one-time use DRIP identifiers to the unique UA. only be used to bind one-time use DRIP identifiers to the unique UA.
Depending upon implementation, this may leave a HI private key in the Depending upon implementation, this may leave a HI private key in the
possession of the manufacturer (more details in Section 8). possession of the manufacturer (see also Section 8).
In general, Internet access may be needed to validate Attestations or In general, Internet access may be needed to validate Attestations or
Certificates. This may be obviated in the most common cases (e.g., Certificates. This may be obviated in the most common cases (e.g.,
attestation of the UAS ID), even in disconnected environments, by attestation of the UAS ID), even in disconnected environments, by
prepopulating small caches on Observer devices with Registry public prepopulating small caches on Observer devices with Registry public
keys and a chain of Attestations or Certificates (tracing a path keys and a chain of Attestations or Certificates (tracing a path
through the Registry tree). This is assuming all parties on the through the Registry tree). This is assuming all parties on the
trust path also use HHITs for their identities. trust path also use HHITs for their identities.
3.3. HHIT for DRIP Identifier Registration and Lookup 3.3. HHIT for DRIP Identifier Registration and Lookup
skipping to change at page 14, line 40 skipping to change at page 14, line 44
hierarchy within which it is registered and a cryptographic hash of hierarchy within which it is registered and a cryptographic hash of
that information concatenated with the entity's public key, etc. that information concatenated with the entity's public key, etc.
Although hash collisions may occur, the registrar can detect them and Although hash collisions may occur, the registrar can detect them and
reject registration requests rather than issue credentials, e.g., by reject registration requests rather than issue credentials, e.g., by
enforcing a first-claimed, first-attested policy. Pre-image hash enforcing a first-claimed, first-attested policy. Pre-image hash
attacks are also mitigated through this registration process, locking attacks are also mitigated through this registration process, locking
the HHIT to a specific HI the HHIT to a specific HI
4. DRIP Identifier Registration and Registries 4. DRIP Identifier Registration and Registries
DRIP registries hold both public and private UAS information (See DRIP registries [I-D.ietf-drip-registries] hold both public and
PRIV-1 in [RFC9153]) resulting from the DRIP identifier registration private UAS information (See PRIV-1 in [RFC9153]) resulting from the
process. Given these different uses, and to improve scalability, DRIP identifier registration process. Given these different uses,
security, and simplicity of administration, the public and private and to improve scalability, security, and simplicity of
information can be stored in different registries. This section administration, the public and private information can be stored in
introduces the public and private information registries for DRIP different registries. This section introduces the public and private
identifiers. This DRIP Identifier registration process satisfies the information registries for DRIP identifiers. This DRIP Identifier
following DRIP requirements defined in [RFC9153]: GEN-3, GEN-4, ID-2, registration process satisfies the following DRIP requirements
ID-4, ID-6, PRIV-3, PRIV-4, REG-1, REG-2, REG-3 and REG-4. defined in [RFC9153]: GEN-3, GEN-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4,
REG-1, REG-2, REG-3 and REG-4.
4.1. Public Information Registry 4.1. Public Information Registry
4.1.1. Background 4.1.1. Background
The public information registry provides trustable information such The public information registry provides trustable information such
as attestations of UAS RID ownership and registration with the HDA as attestations of UAS RID ownership and registration with the HDA
(Hierarchical HIT Domain Authority). Optionally, pointers to the (Hierarchical HIT Domain Authority). Optionally, pointers to the
registries for the HDA and RAA (Registered Assigning Authority) registries for the HDA and RAA (Registered Assigning Authority)
implicit in the UAS RID can be included (e.g., for HDA and RAA implicit in the UAS RID can be included (e.g., for HDA and RAA
skipping to change at page 18, line 13 skipping to change at page 18, line 18
estimate the locations of the mobile transmitters. estimate the locations of the mobile transmitters.
Further, gateways with additional sensors (e.g., smartphones with Further, gateways with additional sensors (e.g., smartphones with
cameras) can provide independent information on the UA type and size, cameras) can provide independent information on the UA type and size,
confirming or refuting those claims made in the UAS RID messages. confirming or refuting those claims made in the UAS RID messages.
Section 6.1 and Section 6.2 define two additional entities that are Section 6.1 and Section 6.2 define two additional entities that are
required to provide this Crowd Sourced Remote ID (CS-RID). required to provide this Crowd Sourced Remote ID (CS-RID).
This approach satisfies the following DRIP requirements defined in This approach satisfies the following DRIP requirements defined in
[RFC9153]: GEN-5, GEN-11, and REG-1. [RFC9153]: GEN-5, GEN-11, and REG-1. As Broadcase messages are
inherently multicast, GEN-10 is met for local-link multicast to
multiple Finders (how multilateration is possible).
6.1. The CS-RID Finder 6.1. The CS-RID Finder
A CS-RID Finder is the gateway for Broadcast Remote ID Messages into A CS-RID Finder is the gateway for Broadcast Remote ID Messages into
UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID
Finder could implement, integrate, or accept outputs from a Broadcast Finder could implement, integrate, or accept outputs from a Broadcast
RID receiver. However, it should not depend upon a direct interface RID receiver. However, it should not depend upon a direct interface
with a GCS, Net-RID SP, Net-RID DP or Network RID client. It would with a GCS, Net-RID SP, Net-RID DP or Network RID client. It would
present a new interface to a CS-RID SDSP, similar to but readily present a new interface to a CS-RID SDSP, similar to but readily
distinguishable from that between a GCS and a Net-RID SP. distinguishable from that between a GCS and a Net-RID SP.
skipping to change at page 19, line 32 skipping to change at page 19, line 40
connectivity between the parties. One method directly supported by connectivity between the parties. One method directly supported by
the use of HHITs as DRIP entity identifiers is initiation of a HIP the use of HHITs as DRIP entity identifiers is initiation of a HIP
Base Exchange (BEX) and Bound End-to-End Tunnel (BEET). Base Exchange (BEX) and Bound End-to-End Tunnel (BEET).
This approach satisfies DRIP requirement GEN-6 Contact, supports This approach satisfies DRIP requirement GEN-6 Contact, supports
satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5 satisfaction of requirements [RFC9153] GEN-8, GEN-9, PRIV-2, PRIV-5
and REG-3, and is compatible with all other DRIP requirements. and REG-3, and is compatible with all other DRIP requirements.
8. Security Considerations 8. Security Considerations
The size of the public key hash in the HHIT is vulnerable to a
second-image attack. It is well within current server array
technology to compute another key pair that hashes to the same HHIT.
Thus, if a receiver were to check HHIT validity only by verifying
that the received HI and associated information, when hashed in the
ORCHID construction, reproduce the received HHIT, an adversary could
impersonate a validly registered UA. To defend against this, on-line
receivers should verify the received HHIT and received HI with the
USS with which the HHIT purports to be registered. On-line and off-
line receivers can use a chain of received DRIP link attestations
from a root of trust through the RAA and the HDA to the UA, as
described in [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries].
Compromise of a registry private key could do widespread harm. Key
revocation procedures are as yet to be determined. These risks are
in addition to those involving Operator key management practices and
will be addressed as part of the registry process.
8.1. Private Key Physical Security
The security provided by asymmetric cryptographic techniques depends The security provided by asymmetric cryptographic techniques depends
upon protection of the private keys. It may be necessary for the GCS upon protection of the private keys. It may be necessary for the GCS
to have the key pair to register the HHIT to the USS. Thus it may be to have the key pair to register the HHIT to the USS. Thus it may be
the GCS that generates the key pair and delivers it to the UA, making the GCS that generates the key pair and delivers it to the UA, making
the GCS a part of the key security boundary. Leakage of the private the GCS a part of the key security boundary. Leakage of the private
key either from the UA or GCS to the component manufacturer is a key either from the UA or GCS to the component manufacturer is a
valid concern and steps need to be in place to ensure safe keeping of valid concern and steps need to be in place to ensure safe keeping of
the private key. the private key.
The size of the public key hash in the HHIT is also of concern. It Since it is possible for the UAS RID sender of a small harmless UA
is well within current server array technology to compute another key (or the entire UA) to be carried by a larger dangerous UA as a "false
pair that hashes to the same HHIT. Thus an adversary could flag", it is out of scope to deal wtih secure store for the private
impersonate a validly registered UA. This attack would only be key.
exposed when the HI in DRIP authentication message is checked back to
the USS and found not to match.
Finally, the UAS RID sender of a small harmless UA (or the entire UA)
could be carried by a larger dangerous UA as a "false flag."
Compromise of a registry private key could do widespread harm. Key
revocation procedures are as yet to be determined. These risks are
in addition to those involving Operator key management practices.
8.1. Post Quantum Computing out of scope 8.2. Post Quantum Computing Out Of Scope
There has been no effort, at this time, to address post quantum There has been no effort, at this time, to address post quantum
computing cryptography. UAs and Broadcast Remote ID communications computing cryptography. UAs and Broadcast Remote ID communications
are so constrained that current post quantum computing cryptography are so constrained that current post quantum computing cryptography
is not applicable. Plus since a UA may use a unique HHIT for each is not applicable. Plus since a UA may use a unique HHIT for each
operation, the attack window could be limited to the duration of the operation, the attack window could be limited to the duration of the
operation. operation.
Finally, as the HHIT contains the ID for the cryptographic suite used Finally, as the HHIT contains the ID for the cryptographic suite used
in its creation, a future post quantum computing safe algorithm that in its creation, a future post quantum computing safe algorithm that
fits the Remote ID constraints may readily be added. fits the Remote ID constraints may readily be added.
8.3. Denial Of Service (DOS) Protection Out Of Scope
Remote ID services from the UA use a wireless link in a public space.
As such, they are open to many forms of RF jamming. It is trivial
for an attacker to stop any UA messages from reaching a wireless
receiver. Thus it is pointless to attempt to provide relief from DOS
attacks as there is always the ultimate RF jamming attack. Subtle
DOS attacks of message content altering are not practical with the
basic message error correction provided. Finally, this whole
architecture is put forth to make DOS spoofing/replay attacks very
hard.
9. Privacy & Transparency Considerations 9. Privacy & Transparency Considerations
Broadcast RID messages can contain Personally Identifiable Broadcast RID messages can contain Personally Identifiable
Information (PII). A viable architecture for PII protection would be Information (PII). A viable architecture for PII protection would be
symmetric encryption of the PII using a session key known to the UAS symmetric encryption of the PII using a session key known to the UAS
and its USS. Authorized Observers could obtain plaintext in either and its USS. Authorized Observers could obtain plaintext in either
of two ways. An Observer can send the UAS ID and the cyphertext to a of two ways. An Observer can send the UAS ID and the cyphertext to a
server that offers decryption as a service. An Observer can send the server that offers decryption as a service. An Observer can send the
UAS ID only to a server that returns the session key, so that UAS ID only to a server that returns the session key, so that
Observer can directly locally decrypt all cyphertext sent by that UA Observer can directly locally decrypt all cyphertext sent by that UA
skipping to change at page 22, line 13 skipping to change at page 22, line 36
TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip>. TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip>.
[I-D.ietf-drip-auth] [I-D.ietf-drip-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Entity Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Entity
Tag Authentication Formats & Protocols for Broadcast Tag Authentication Formats & Protocols for Broadcast
Remote ID", Work in Progress, Internet-Draft, draft-ietf- Remote ID", Work in Progress, Internet-Draft, draft-ietf-
drip-auth-12, 25 May 2022, drip-auth-12, 25 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-auth- <https://www.ietf.org/archive/id/draft-ietf-drip-auth-
12.txt>. 12.txt>.
[I-D.ietf-drip-registries]
Wiethuechter, A., Card, S., Moskowitz, R., and J. Reid,
"DRIP Entity Tag Registration & Lookup", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-03, 11 May
2022, <https://www.ietf.org/archive/id/draft-ietf-drip-
registries-03.txt>.
[Implementing] [Implementing]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
Commission Implementing Regulation 2019/947 of 24 May 2019 Commission Implementing Regulation 2019/947 of 24 May 2019
on the rules and procedures for the operation of unmanned on the rules and procedures for the operation of unmanned
aircraft", 2019, <https://eur-lex.europa.eu/legal- aircraft", 2019, <https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX%3A32019R0947>. content/EN/TXT/?uri=CELEX%3A32019R0947>.
[Implementing_update] [Implementing_update]
European Union Aviation Safety Agency (EASA), "EU European Union Aviation Safety Agency (EASA), "EU
COMMISSION IMPLEMENTING REGULATION (EU) 2021/664 of 22 COMMISSION IMPLEMENTING REGULATION (EU) 2021/664 of 22
 End of changes. 19 change blocks. 
48 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/