Re: [Tm-rid] Proposed WG Charter v2

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

I will have a V4 draft charter out today, addressing all comments received.

On Fri, Jan 10, 2020, 05:01 Eric Vyncke (evyncke) <[e-mail]> wrote:

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