Updated TMRID BOF Charter

Robert Moskowitz <[email protected]> Fri, 25 Oct 2019 12:02:29 -0400
Newsgroups gmane.ietf.hipsec,gmane.ietf.hip
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============7945026889433887548==
Content-Type: multipart/alternative;
 boundary="------------49C2906F7170DC076BCC511C"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------49C2906F7170DC076BCC511C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I have updated the TMRID BOF Charter at:

https://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Here it is.  Comments/corrections/additions welcomed:


Governmental agencies worldwide, including the United States Federal 
Aviation Administration (FAA), are embarking on rule making processes to 
define Remote Identification (RID) requirements for Unmanned Aircraft 
Systems (UAS). ASTM International (formerly the American Society for 
Testing and Materials) F38 Committee Work Item WK65041, “Standard 
Specification for UAS Remote ID and Tracking”, addresses such 
anticipated requirements. Broadcast RID defines a set of messages for 
UAS to send one-way over Bluetooth or IEEE 802.11. Network RID defines 
how the same information (and potentially more) can be made available 
via the Internet. The ASTM draft does not address how to ensure or at 
least assess trustworthiness of information communicated via RID.


The Host Identity Protocol (HIP) Host Identity Tag (HIT) is ideally, in 
fact uniquely, suited to work within this RID effort. For each Unmanned 
Aircraft (UA), a HIT can consolidate the 4-tuple of (UA ID, UA physical 
location, UA onboard host ID, UA onboard host logical location [IP 
address list]) to a 3-tuple (HIT, UA physical location, UA onboard host 
logical location) and thereby provide significant benefits. More 
importantly, 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 can also 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.


HIP would benefit from the following updates to be used effectively in 
this environment.


- Hierarchical HITs (HHIT) enabling scalable and trustable UA 
registration and information retrieval: HHIT was part of the original 
design of HIP, but was dropped for lack of a clear use case. RID 
messages containing HHITs will enable use of DNS to access information 
about the UAS.


- expanded HIP Registration for HHITs: This registration process will 
provide proof of authenticity and prevent duplicate HHITs from 
occurring. Further, these Registries will provide the UAS DNS 
information and other services (including support of RVS for Network RID 
and related applications).


- new cryptographic algorithms: Extremely compact keys and signatures 
(such as are enabled by EdDSA and Keccak functions) are needed to meet 
the severely constrained UAS environment.


Additionally, tm-rid will offer 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 the 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.


Further work will emerge as experience is gained in using HIP for UAS 
RID. For example, some UAS Traffic Management (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 goal is to complete these updates to HIP and publish the TMRID RFCs 
by the end of 2020.



--------------49C2906F7170DC076BCC511C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-text-html" lang="x-unicode"> I have updated the
      TMRID BOF Charter at:<br>
      <br>
      <a class="moz-txt-link-freetext"
        href="https://trac.tools.ietf.org/bof/trac/wiki/WikiStart">https://trac.tools.ietf.org/bof/trac/wiki/WikiStart</a><br>
      <br>
      Here it is.  Comments/corrections/additions welcomed:<br>
      <br>
      <br>
      <p style="margin-bottom: 0in; line-height: 100%">Governmental
        agencies worldwide, including the United States Federal Aviation
        Administration (FAA), are embarking on rule making processes to
        define Remote Identification (RID) requirements for Unmanned
        Aircraft Systems (UAS). ASTM International (formerly the
        American Society for Testing and Materials) F38 Committee Work
        Item WK65041, “Standard Specification for UAS Remote ID and
        Tracking”, addresses such anticipated requirements. Broadcast
        RID defines a set of messages for UAS to send one-way over
        Bluetooth or IEEE 802.11. Network RID defines how the same
        information (and potentially more) can be made available via the
        Internet. The ASTM draft does not address how to ensure or at
        least assess trustworthiness of information communicated via
        RID.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%"><a
          name="__DdeLink__338_3467620224"></a> The Host Identity
        Protocol (HIP) Host Identity Tag (HIT) is ideally, in fact
        uniquely, suited to work within this RID effort. For each
        Unmanned Aircraft (UA), a HIT can consolidate the 4-tuple of (UA
        ID, UA physical location, UA onboard host ID, UA onboard host
        logical location [IP address list]) to a 3-tuple (HIT, UA
        physical location, UA onboard host logical location) and thereby
        provide significant benefits. More importantly, 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.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">HITs can also
        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.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">HIP would benefit
        from the following updates to be used effectively in this
        environment.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">- Hierarchical
        HITs (HHIT) enabling scalable and trustable UA registration and
        information retrieval: HHIT was part of the original design of
        HIP, but was dropped for lack of a clear use case. RID messages
        containing HHITs will enable use of DNS to access information
        about the UAS.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">- expanded HIP
        Registration for HHITs: This registration process will provide
        proof of authenticity and prevent duplicate HHITs from
        occurring. Further, these Registries will provide the UAS DNS
        information and other services (including support of RVS for
        Network RID and related applications).</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">- new
        cryptographic algorithms: Extremely compact keys and signatures
        (such as are enabled by EdDSA and Keccak functions) are needed
        to meet the severely constrained UAS environment.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%"><a name="_GoBack"></a>
        Additionally, tm-rid will offer 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 the 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. </p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">Further work will
        emerge as experience is gained in using HIP for UAS RID. For
        example, some UAS Traffic Management (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.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
      <p style="margin-bottom: 0in; line-height: 100%">The goal is to
        complete these updates to HIP and publish the TMRID RFCs by the
        end of 2020.</p>
      <p style="margin-bottom: 0in; line-height: 100%"><br>
      </p>
    </div>
  </body>
</html>

--------------49C2906F7170DC076BCC511C--


--===============7945026889433887548==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec

--===============7945026889433887548==--