Reviewer: Pascal Thubert Review result: Ready with Nits https://www.ietf.org/id/draft-ietf-drip-rid-26.txt DRIP R. Moskowitz Internet-Draft HTT Consulting Updates: 7401, 7343 (if approved) S. Card Intended status: Standards Track A. Wiethuechter Expires: 14 November 2022 AX Enterprize, LLC A. Gurtov Linköping University 13 May 2022 DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) draft-ietf-drip-rid-26 Abstract This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). This document updates RFC7401 and RFC7343. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs self-attest to the included explicit hierarchy that provides registry (via, e.g., DNS, EPP) discovery for 3rd-party identifier attestation. 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 14 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Moskowitz, et al. Expires 14 November 2022 [Page 1] Internet-Draft DRIP Entity Tag (DET) May 2022 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 1.1. HHIT Statistical Uniqueness different from UUID or X.509 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 6 3.1. HHIT Prefix for RID Purposes . . . . . . . . . . . . . . 7 3.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. HDA custom HIT Suite IDs . . . . . . . . . . . . . . 8 3.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 8 3.3.1. The Registered Assigning Authority (RAA) . . . . . . 8 3.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 9 3.4. Edward-Curve Digital Signature Algorithm for HHITs . . . 9 3.4.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 11 3.5. ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . . 11 3.5.1. Adding Additional Information to the ORCHID . . . . . 12 3.5.2. ORCHID Encoding . . . . . . . . . . . . . . . . . . . 13 3.5.3. ORCHID Decoding . . . . . . . . . . . . . . . . . . . 15 3.5.4. Decoding ORCHIDs for HIPv2 . . . . . . . . . . . . . 15 4. Hierarchical HITs as DRIP Entity Tags . . . . . . . . . . . . 15 4.1. Nontransferablity of DETs . . . . . . . . . . . . . . . . 16 4.2. Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . . 16 4.3. Remote ID DET as one Class of Hierarchical HITs . . . . . 17 4.4. Hierarchy in ORCHID Generation . . . . . . . . . . . . . 17 4.5. DRIP Entity Tag (DET) Registry . . . . . . . . . . . . . 18 4.6. Remote ID Authentication using DETs . . . . . . . . . . . 18 5. DRIP Entity Tags (DETs) in DNS . . . . . . . . . . . . . . . 18 6. Other UTM Uses of HHITs Beyond DET . . . . . . . . . . . . . 20 7. Summary of Addressed DRIP Requirements . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8.1. New Well-Known IPv6 prefix for DETs . . . . . . . . . . . 20 8.2. New IANA DRIP Registry . . . . . . . . . . . . . . . . . 21 8.3. IANA CGA Registry Update . . . . . . . . . . . . . . . . 22 8.4. IANA HIP Registry Updates . . . . . . . . . . . . . . . . 22 Moskowitz, et al. Expires 14 November 2022 [Page 2] Internet-Draft DRIP Entity Tag (DET) May 2022 8.5. IANA IPSECKEY Registry Update . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.1. DET Trust in ASTM messaging . . . . . . . . . . . . . . . 25 9.2. DET Revocation . . . . . . . . . . . . . . . . . . . . . 25 9.3. Privacy Considerations . . . . . . . . . . . . . . . . . 26 9.4. Collision Risks with DETs . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 31 Appendix B. The 14/14 HID split . . . . . . . . . . . . . . . . 31 Appendix C. Calculating Collision Probabilities . . . . . . . . 33 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 > 1. Introduction > DRIP Requirements [RFC9153] describe an Unmanned Aircraft System Maybe expand DRIP on first use? > asserting IPv6 addresses and thereby a trustable identifier for use > as the UAS Remote ID. Architecturally speaking, people hate using IPv6 addresses as ID. I foresee discussions about address renewal, device replacement (same address?), and privacy. We'll see further down the draft but I expect that a dedicated section on why this is desirable (and OK) so we do not get endless pushback at IESG. https://www.rfc-editor.org/rfc/rfc9153.html#name-identifier does not seem to enforce that IP is used. Also, interesting to figure if the model is portable to vitually anything, e.g., in IoT. > Hierarchical HITs provide self-attestation of the HHIT registry. A > HHIT can only be in a single registry within a registry system (e.g., > EPP and DNS). Could we imagine a distributed ledger? > HHITs are statistically unique through the cryptographic hash feature > of second-preimage resistance. Good thing that the HHITs are Hierarchical as opposed to only Statistical ;) > The cryptographically-bound addition > of the hierarchy and a HHIT registration process [drip-registries] > provide complete, global HHIT uniqueness. Coudl issues arise when the global registry is unreachable when the ID is formed? Is the HHIT "tentative" till then? > 2. Terms and Definitions A forward ref to fig 1 woudl help with all the bit fields. > Keccak (KECCAK Message Authentication Code): I guess the expansion in () is a CC from the next definition. > 3. The Hierarchical Host Identity Tag (HHIT) > * ORCHID hash (96 - prefix length - 8 for HHIT Suite ID, e.g., 64) > See Section 3.5 for more details. If P is 28 bits then the hash is 60, which is less than CGA; also this fails to align to the usual /64, though whether that's important is debatable. Is there a reason to allow P to reach 28 as opposed to 24? Will it be harder to allocate? > 3.1. HHIT Prefix for RID Purposes > Initially, for DET use, one 28-bit prefix should be assigned out of > the IANA IPv6 Special Purpose Address Block ([RFC6890]). Same as above, are we reducing the security properties by having a /28? 3.2. HHIT Suite IDs > The following HHIT Suite IDs are defined: > > HHIT Suite Value > RESERVED 0 > RSA,DSA/SHA-256 1 [RFC7401] > ECDSA/SHA-384 2 [RFC7401] > ECDSA_LOW/SHA-1 3 [RFC7401] > EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED) > I checked the IANA section. It's there though - missing references - duplicating other efforts for similar registries e.g., https://www.rfc-editor.org/rfc/rfc8928.html#name-crypto-type-subregistry Could you reuse that registry and extend it for the new suite IDs / hash / KMAC? Adding Keccak capabilities to the previous RFCs is a win/win. > 3.5.2. ORCHID Encoding > The cSHAKE function call for this update is: > cSHAKE128(Input, L, "", Context ID) Is there a way to add a "salt" so that the node may generate more than one ID for privacy? > 4.1. Nontransferablity of DETs > A HI and its HHIT SHOULD NOT be transferable between UA or even > between replacement electronics Pro: This answers one question above. Con: this bars very interesting IoT use cases I have in mind for spare parts and sensory devices. e.g., ISA100.11a uses IPv6 addresses as IDs and would benefit from this. Is the non-transferability a requirement? Could you reword as to say that when it is a requirement then the keys must be safeguarded in the store but leave it open for other scenarios? > 4.3. Remote ID DET as one Class of Hierarchical HITs > UAS Remote ID DET may be one of a number of uses of HHITs. However, > it is out of the scope of the document to elaborate on other uses of > HHITs. As such these follow-on uses need to be considered in > allocating the RAAs (Section 3.3.1) or HHIT prefix assignments > (Section 8). This answers another of my questions, but then please limit your MUST to the supported use case of DETs not for HHITs in general, to my point right above. > 6. Other UTM Uses of HHITs Beyond DET > Please expand UTM (and add to terminology?) 8.2. New IANA DRIP Registry > Hierarchical HIT (HHIT) Suite ID: > HHIT Suite Value You probably want an additional column with ref to the algorithms, or maybe reuse either the format or registry of RFC 8928, more below. > 8.4. IANA HIP Registry Updates > EdDSA Curve Label: Any way to use / extend https://www.rfc-editor.org/rfc/rfc8928.html#name-crypto-type-subregistry ? > 9. Security Considerations > The 64-bit hash in HHITs presents a real risk of second pre-image > cryptographic hash attack Section 9.4. This partially addresses another of my earlier questions. > However, with today's computing power, producing 2^64 EdDSA keypairs > and then generating the corresponding HHIT is economically feasible. That would be 2^60, unless I miss something? and then maybe there'd be a way to variate other fileds of the hash with the same key. Then there's the post Quantum thingy. I guess it's safe to say that this model is not post-Q resilent right? > The Registry service [drip-registries], through its HHIT > uniqueness enforcement, provides against forced or accidental HHIT > hash collisions. When it's reachable. When it's not, there can be both impersonation and DOS attacks based on the false ID. > 9.3. Privacy Considerations > There is no expectation of privacy for DETs; it is not part of the > privacy normative requirements listed in, Section 4.3.1, of > [RFC9153]. This addresses another of my initial questions. > DETs are broadcast in the clear over the open air via > Bluetooth and Wi-Fi. So L2 security when present still protects the ID but not MAC, correct? > 9.4. Collision Risks with DETs > The 64-bit hash size does have an increased risk of collisions over > the 96-bit hash size used for the other HIT Suites. Is that true also for voluntary collisions (brute force) ? > 10.2. Informative References unmanned-aerial-systems-serial-numbers>. > [drip-architecture] Shouldn't be normative? > [drip-authentication] Same, and then for registries? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
