Re: [Tm-rid] Proposed WG Charter v2

["Eric Vyncke (evyncke)" <[e-mail]>]

Stu, Adam, Bob and other,

The clock is starting to click towards IETF-107 and it takes several weeks to create a WG. In short, it becomes really important that the TM-RID community rally around a draft charter that can be reviewed by the IESG as a first step. IMHO, the v2 will have difficulties to go through the evaluation if my comments below are not taken into account.

Regards

-éric

From: Eric Vyncke <[e-mail]>
Date: Friday, 3 January 2020 at 17:34
To: "Card, Stu" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: ryoung <[e-mail]>
Subject: Re: [Tm-rid] Proposed WG Charter v2

Happy New Year all

Stu, exactly one month ;-)

This TM-RID community needs to work more and faster around this chartering. A liaison statement from FAA or other CAA or ICAO or ASTM (not exclusive) on this work could also help a lot.

About the charter itself, it is difficult to parse as there are many acronyms + their expansion. Unsure how to solve this issue though (except like this trick[1]).

The charter flow does not follow the usual one. E.g., it would benefit a lot of clearly identifying the work items (or at least clearly the WG scope). Having milestones (i.e. dates) is also helpful for chartering a WG, milestones are outside of the charter itself but can be enumerated, for now, as bullets after the charter.

Citing the existing Internet drafts is also typical in a charter.

To be direct, I am afraid that statement like “HIP HIT is uniquely ideally suited to serving as an UAS ID Type” will NOT attract consensus in a charter. I would suggest to have a work item to check the adequacy of HIP to the problem statement than trying to defend this assumption in the charter itself.

Please continue this good work and let’s try to have more interactivity around this topic

-eric

[1] I believe that footnotes can be added to charters ;-)

From: Tm-rid <[e-mail]> on behalf of "Card, Stu" <[e-mail]>
Date: Thursday, 2 January 2020 at 23:01
To: "[e-mail]" <[e-mail]>
Cc: ryoung <[e-mail]>
Subject: Re: [Tm-rid] Proposed WG Charter v2

Week turned into month but here's my attempt. All please review and comment.

Trustworthy Multipurpose Remote Identification (TM-RID) Proposed WG Charter v3

Civil Aviation Authorities (CAAs) worldwide (e.g. United States Federal Aviation Administration, FAA), have initiated rule making for Unmanned Aircraft Systems (UAS) Remote Identification (RID).  CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry consensus technical standards as acceptable means of compliance. One key standard here is ASTM International F38 Committee Work Item WK65041, “Standard Specification for UAS Remote ID and Tracking”.  ASTM Network RID defines a set of information for UAS to make available globally indirectly via the Internet. ASTM Broadcast RID defines a set of messages for Unmanned Aircraft (UA) to send locally directly one-way over Bluetooth or IEEE 802.11. WK65041 addresses neither how to ensure trustworthiness of RID information nor how to make it instantly useful.

TM-RID’s goal is to make RID immediately actionable, in both Internet and local-only connected scenarios, especially emergencies, in severely constrained UAS environments, balancing legitimate (e.g. public safety) authorities’ Need To Know trustworthy information with UAS operators’ privacy. To accomplish this, TM-RID will liaise with ASTM, CTA, ICAO, RTCA, et al and complement their standards with IETF work to meet this urgent need. An Applicability Statement RFC for UAS RID, showing how to use IETF standardized technologies for this purpose, will be a central work product. Other Technical Specification RFCs will address enhancements of specific supporting protocols. Prototypes using the contemplated technical approach have already been successfully flown.

The Host Identity Protocol (HIP) Host Identity Tag (HIT) is uniquely ideally suited to serving as an UAS ID Type. A  HIT, an Overlay Routable Cryptographic Hash Identifier (ORCHID), is derived from and compactly (as an IPv6 address) represents a Host Identity (HI), a [self-generated] public key. HITs can verifiably identify all entities in the UAS Traffic Management (UTM) ecosystem: UA, Ground Control Stations (GCS), observer devices, registries, etc. TM-RID will specify how to leverage HITs –

- Provide strong RID authentication by using the HI in public key operations to:
= prove ownership of the claimed ID (HIT);
= authenticate other claims made via RID (e.g. location) as signed by the owner of that ID; and
= provide observers [w/o Internet connectivity] locally verifiable proof that ID is in a known registry.

- Use DNS to enable observers to use a received HIT to look up minimal public ID information.

- Use access controlled RDAP to enable authorized observers to look up more extensive private information (including operator Personally Identifiable Information, PII) needed for legitimate (e.g. public safety or security) purposes from an Internet domain name (Whois) or similar registry.

This provides stronger privacy than other FAA Notice of Proposed Rulemaking (NPRM) / ASTM standard UAS ID Types, while providing greater assurance of authenticity to authorized observers, but necessitates several HIP enhancements –

- Hierarchical HIT (HHIT): Enable scalable and trustable UA registration and information retrieval (e.g. with DNS and RDAP) by adding optional structure to the (currently flat) HIT/ORCHID space.

- registration extensions:  Prevent registration of duplicate HHITs, populate registries with IDs and associated data, update DNS, support Rendez-Vous Servers (RVS) and provide proof of authenticity.

- proxies: Enable any party observing an UA to contact a RVS or other intermediary that will either deny or facilitate secure communications with the party controlling the UA, while maintaining the privacy of the latter’s identity, location and other information to all but authorized parties, per policy.

- multicast: To securely and efficiently communicate with a group, multicast to their ephemeral (and likely multiple per host) IP addresses, starting from individual and/or group HITs.

- new cryptographic algorithms: Extremely compact keys and signatures (such as are enabled by EdDSA and Keccak functions) are needed for severely constrained [UAS] environments.

TM-RID potentially could be applied to verifiably identify other types of registered things reported to be in specified physical locations, but the urgent motivation and clear initial focus is UAS. TM-RID enhancements to HIP will be generic: of these, only HHITs with their associated registration procedures and compact crypto are vital to support UAS RID; HIP proxies and HIP multicast are stretch goals. Some UTM concepts envision using OAuth for GCS and personnel; HIP as an OAuth method also will be investigated. The Applicability Statement and the Technical Specifications initially essential for UAS RID will be published within one year of the 2019 DEC 31 FAA NPRM.


On Mon, Dec 2, 2019 at 12:31 PM Card, Stu <[e-mail]<mailto:[e-mail]>> wrote:
I will try wordsmithing this week.

On Mon, Dec 2, 2019, 09:04 Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

I am enthusiatic about this work, although I don't anticipate being able to
be more than a bystandard on this.

Robert Moskowitz <[e-mail]<mailto:[e-mail]>> wrote:
    > TM-RID will build upon the Host Identity Tag (HIT) from the Host Identity
    > Protocol (HIP) as an RID and augment it and supporting HIP and other IETF
    > technologies to add trustworthiness to the ASTM messaging suite.

I think that this sentence needs editing.  Too many ".. and"

    > The goal is
    > to provide trustworthiness both in an Internet connected environment and
    > emergency, unconnected situations within the highly constrained environment
    > of UAS.

I think that a reference for the nature of the constrained environment might
be in order.

    > The Host Identity Tag (HIT) is ideally, in fact uniquely, suited to work
    > within this RID effort.  The Host Identity (HI) behind the HIT can be used to
    > sign Broadcast Authentication Messages, thus proving ownership of the RID
    > (HIT) and signed messages.  HITs provide significantly superior privacy
    > compared to other allowed RID types while providing greater assurance to
    > authorized observers that they are accessing the proper PII for the UA.

This wanders into solution space, and I think it would be better to omit this.

    > TM-RID will create specifications for HIP-augmented ASTM RID messages..
    > Initially this will consist of additional RID Authentication Messages that
    > use the HI in public key signing operations: to prove UAS ownership of a
    > Hierarchical HIT (HHIT); to authenticate other claims made via RID, such as
    > position and velocity, as having been made by the owner of that HHIT; and to
    > provide observers lacking current Internet connectivity with locally
    > verifiable UAS proof-of-registration objects.

removing some of the solutions, leaving the requirements:

TM-RID will create specifications to prove UAS ownership of a
Hierarchical HIT (HHIT); providing a framework to authenticate other claims, such as
position and velocity, as having been made by the owner of that HHIT; and to
provide observers lacking current Internet connectivity with locally
verifiable UAS proof-of-registration objects.

I would have written this as numbered points.

    > For this, HIP would be amended to be used effectively in this environment:

I think you could put a period instead of : and omit the next three paragraphs.

    > HHITs are envisioned to identify all components in the UAS/UTM (UAS Traffic
    > Management) environment: UA, Command Consoles, Observer devices, and
    > Registries.  This will entail further work as experience is gained in using
    > HIP for UAS RID.  For example, some (UTM) systems envision using OAuth for
    > Ground Control Systems (GCS) and authorized safety personnel.  HIP as an
    > OAuth method may help in merging HIP into these systems.

    > The workgroup will need to liaison with the various SDOs working in the UAS
    > regulation space.

Please if you could list those SDOs?
Do we need to do liason agreements with them?  I would be happier if that was
part of the plan.

How will we engage with implementers?  I.e. how are we going to get running-code?



--
Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-



--
Tm-rid mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tm-rid