This section describes the DRIP architectural approach to meeting the basic requirements of a DRIP entity identifier within the external technical standard ASTM [F3411-22a
] and regulatory constraints. It justifies and explains the use of Hierarchical Host Identity Tags (HHITs) [RFC 9374
] as self-asserting IPv6 addresses suitable as a UAS ID type and, more generally, as trustworthy multipurpose remote identifiers.
Self-asserting in this usage means that, given the Host Identity (HI), the HHIT Overlay Routable Cryptographic Hash IDentifier (ORCHID) construction (see Section 3.5
of RFC 9374
), and a signature of the DIME on the HHIT and HI, the HHIT can be verified by the receiver as a trusted UAS ID. The explicit registration hierarchy within the HHIT provides registration discovery (managed by a DIME) to either yield the HI for third-party (seeking UAS ID endorsement) validation or prove that the HHIT and HI have been registered uniquely.
A DRIP entity identifier needs to be "Trustworthy" (see DRIP requirements GEN-1, ID-4, and ID-5 in [RFC 9153
]). This means that given a sufficient collection of UAS RID messages, an Observer can establish that the identifier claimed therein uniquely belongs to the claimant. To satisfy DRIP requirements and maintain important 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; see DRIP requirements GEN-3 and ID-2).
However, Broadcast RID, especially its support for Bluetooth 4, imposes severe constraints. A previous revision of the ASTM UAS RID, [F3411-19
], allowed a UAS ID of types (1, 2, and 3), each of 20 bytes. [F3411-22a
] adds type 4, Specific Session ID, for other Standards Development Organizations (SDOs) to extend ASTM UAS RID. Type 4 uses one byte to index the Specific Session ID subtype, leaving 19 bytes (see ID-1 of DRIP Requirements [RFC 9153
]). As described in Section 3
of RFC 9153
, ASTM has allocated Specific Session ID subtype 1 to IETF DRIP.
The maximum ASTM UAS RID Authentication Message payload is 201 bytes each for Authentication Types 1, 2, 3, and 4. [F3411-22a
] adds Authentication Type 5 for other SDOs (including the IETF) to extend ASTM UAS RID with Specific Authentication Methods (SAMs). With Type 5, one of the 201 bytes is consumed to index the SAM Type, leaving only 200 bytes for DRIP authentication payloads, including one or more DRIP entity identifiers and associated authentication data.
The only (known to the authors at the time of writing) existing types of IP-address-compatible identifiers cryptographically derived from the public keys of the identified entities are Cryptographically Generated Addresses (CGAs) [RFC 3972
] and Host Identity Tags (HITs) [RFC 7401
]. CGAs and HITs lack registration/retrieval capability. To provide this, each HHIT embeds plaintext information designating the hierarchy within which it is registered, a cryptographic hash of that information concatenated with the entity's public key, etc. Although hash collisions may occur, the DIME can detect them and reject registration requests rather than issue credentials, e.g., by enforcing a First Come First Served policy [RFC 8126
]. Preimage hash attacks are also mitigated through this registration process, locking the HHIT to a specific HI.
A Remote UAS ID that can be trustworthy for use in Broadcast RID can be built from an asymmetric key pair. In this method, the UAS ID is cryptographically derived directly from the public key. The proof of UAS ID ownership (verifiable endorsement versus mere claim) is guaranteed by signing this cryptographic UAS ID with the associated private key. The association between the UAS ID and the private key is ensured by cryptographically binding the public key with the UAS ID; more specifically, the UAS ID results from the hash of the public key. The public key is designated as the HI, while the UAS ID is designated as the HIT.
By construction, the HIT is statistically unique through the mandatory use of cryptographic hash functions with second-preimage resistance. The cryptographically bound addition of the hierarchy and a HHIT registration process provide complete, global HHIT uniqueness. This registration forces the attacker to generate the same public key rather than a public key that generates the same HHIT. This is in contrast to general IDs (e.g., a Universally Unique Identifier (UUID) or device serial number) as the subject in an X.509 certificate.
A UA equipped for Broadcast RID MUST
be provisioned not only with its HHIT but also with the HI public key from which the HHIT was derived and the corresponding private key to enable message signature.
A UAS equipped for DRIP-enhanced Network RID MUST
be provisioned likewise; the private key resides only in the ultimate source of Network RID messages. If the GCS is the source of the Network RID messages, the GCS MUST
hold the private key. If the UA is the source of the Network RID messages and they are being relayed by the GCS, the UA MUST
hold the private key, just as a UA that directly connects to the network rather than through its GCS.
Each Observer device functioning with Internet connectivity MAY
be provisioned either with public keys of the DRIP identifier root registries or certificates for subordinate registries; each Observer device that needs to operate without Internet connectivity at any time MUST
be so provisioned.
HHITs can also be used throughout the USS/UTM system. Operators and Private Information Registries, as well as other UTM entities, can use HHITs for their IDs. Such HHITs can facilitate DRIP security functions, such as those used with HIP, to strongly mutually authenticate and encrypt communications.
A self-endorsement of a HHIT used as a UAS ID can be done in as little as 88 bytes when Ed25519 [RFC 8032
] is used by only including the 16-byte HHIT, two 4-byte timestamps, and the 64-byte Ed25519 signature.
Ed25519 [RFC 8032
] is used as the HHIT mandatory-to-implement signing algorithm, as GEN-1 and ID-5 [RFC 9153
] can best be met by restricting the HI to 32 bytes. A larger public key would rule out the offline endorsement 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 manufacturer, such as a single HI and derived HHIT encoded as a hardware serial number, per [CTA2063A
]. Such a static HHIT SHOULD
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 possession of the manufacturer (see also Section 9
In general, Internet access may be needed to validate Endorsements or Certificates. This may be obviated in the most common cases (e.g., endorsement of the UAS ID), even in disconnected environments, by prepopulating small caches on Observer devices with DIME public keys and a chain of Endorsements or Certificates (tracing a path through the DIME tree). This is assuming all parties on the trust path also use HHITs for their identities.
UAS RID needs a deterministic lookup mechanism that rapidly provides actionable information about the identified UA. Given the size constraints imposed by the Bluetooth 4 broadcast media, the UAS ID itself needs to be a non-spoofable inquiry input into the lookup.
A DRIP registration process based on the explicit hierarchy within a HHIT provides manageable uniqueness of the HI for the HHIT. The hierarchy is defined in [RFC 9374
] and consists of 2 levels: an RAA and then an HDA. The registration within this hierarchy is the defense against a cryptographic hash second-preimage attack on the HHIT (e.g., multiple HIs yielding the same HHIT; see Requirement ID-3 in [RFC 9153
]). The First Come First Served registration policy is adequate.
A lookup of the HHIT into the DIME provides the registered HI for HHIT proof of ownership and deterministic access to any other needed actionable information based on inquiry access authority (more details in Section 4.2