Re: [Tm-rid] Proposed WG Charter v2

["Card, Stu" <[e-mail]>]

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]> wrote:

> I will try wordsmithing this week.
>
> On Mon, Dec 2, 2019, 09:04 Michael Richardson <[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]> 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]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>> --
>> Tm-rid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tm-rid
>>
>