Subject: [Drip] UA and GSC IDevID requirements

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Aug 2020 23:56:56 -0400

okay, many of you will have guessed I watched the IETF108 meeting recording
and commented on a number of things.

The private-key exfiltration discussion was interesting, trumped, I think by
Stu's comment that the bigger (weaponised) UAs probably can carry the toy UA
inside it.  I was thinking just now, it probably could even have the toy UA
operating normally, with the bigger UA having some tether sensor so that
as the toy UA moves, the bigger one moves in the same direction without
actually being carried.
That would mean that the entire toy UA+GSC could be completely stock.

No amount of PUFs will help that.  PUFs, btw, are:
  https://en.wikipedia.org/wiki/Physical_unclonable_function
and while there are quite a number of proponents of PUFs and they are very
attractive in many ways (being almost free being one of them), there are many
doubts about them.  Rather than saying yes/no, I suggest that they are just
one part of a multivariable evaluation of the security of the root of trust involved.
(In attestation speak: "root of trust" <= more or less private key.
"trust anchor" <=  public key )

As was mentioned in the IETF108 session, pretty much every single M-class (or
A-class!) CPU you might find in an UA is capable of the crypto, and likely is
available with some secure-enclave way to store a private key in a almost
impossible to extrafiltrate way.  We can do attestations and the like, and
IETF WGs like RATS are standardizing this.  Carrying those attestatons
from the UA over BT would be hard, but carrying them through the control
channel to the GSC and out to the network would be easy.

In any case, what we want are not attestations from the UAS itself, but
attestations from other observers.  This is a whole problem in itself.

I am trying to start work on:
   A Toxonomy of operational security of manufacturer
   installed keys and anchors

currently known as:
   draft-richardson-secdispatch-idevid-considerations-02
but getting a new name soon.

I believe that some entity, probably an association of Hierarchical HIT Domain Authorities
will need to write a document like draft-richardson-anima-masa-considerations
to provide some guidance on how the manufacturers should manage the PKI for
the IDevID certificates that go into the UAS.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 14 Aug 2020 08:20:47 -0400

> attestations from other observers.  This is a whole problem in itself.

Different classes of Observers and many already have their Identities 
(US police in a PKI that uses TRUSTMARK; this will have bearing on RDAP).

But look at both:

draft-moskowitz-drip-crowd-sourced-rid
draft-moskowitz-drip-secure-nrid-c2

For other Identity pieces (and potential other uses of HHITs).

> the IDevID certificates that go into the UAS.

ICAO IATF TRON and DIWG are probably moving in this direction.  For 
manned aircraft, the serial number is a plate on the airframe and the 
owner of the airframe registers this with appropriate CAA (and we WON'T 
get into the rat hole about leasing companies vs airlines and regional 
policies that were in the last TRON call and emails!) The manufacturer 
has no direct involvement.  I have pointed out this won't scale well 
with UAS/UAM/... and I gave 3 approaches, one of which is IDevID (I 
wonder why, as I was there at 802.1 in the first discussions).

Oh, this plate is suppose to be non-removable.  Except when you make 
major airframe/wing changes and you have to change it.  One call 
participate recalls when he had to do this...  :)

I think it will come down to a debate in DIWG/TRON is the Identity that 
of the airframe or some computing guts (and what happens when said 
computing guts are gutted {e.g. DJL airframes with different brains used 
by US Gov}).  Fun.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Aug 2020 19:17:31 -0400

> Different classes of Observers and many already have their Identities (US
    > police in a PKI that uses TRUSTMARK; this will have bearing on RDAP).

    > draft-moskowitz-drip-secure-nrid-c2

I started reading them yesterday, ran into too many TLAs I didn't know, and
realized I should finish reading the other documents.

I have now read crowd-sourced-rid.
I would sure like to have an example of an SDSP, particularly in the
introduction of this document.  Who would operate such a thing?
What's their business model?  I think that's pretty important, because it
would determine what kind of things they would want to do, and what things
they would find too expensive.

The mention of the Finder's public key and ECIES in the introduction suggests
that the forwarding of the B-RID messages might be done in an unconnected
fashion (UDP, no three-way TCP handshake, or TLS setup).

Finders clearly need to disclose their location to the SDSP.
There is therefore a tension between the SDSP knowing that the Finders are
real, and the SDSP knowing way too much about the location of the Finders.

You may find https://datatracker.ietf.org/doc/rfc7416/ to have a set of
terminology which might be useful.  RPL is subject to a variety of attacks
that can be made without breaking the crypto, that basically involve various
kinds of repeaters, the point being to change where (physically) a device
appears to be.

}   When 3 or more Finders are reporting to an SDSP on a specific UA, the
}   SDSP is in a unique position to perform multilateration on these
}   messages and compute the Finder's view of the UA location to compare
}   with the UA Location/Vector messages.  This check against the UA's
}   location claims is both a validation on the UA's reliability as well
}   as the trustworthiness of the Finders.  Other than providing data to
}   allow for multilateration, this SDSP feature is out of scope of this
}   document.

Sorry, which "SDSP feature" are you speaking off?
NETSP/NETDP term is inconsistent with reqs document.
SDSP is just a terrible term.

}   provides only Network RID.  The FAA has dropped their previous
}   position on allowing for only Broadcast RID.  We can guess as to
}   their reasons; they are not spelled out in the NPRM.  It may be that
}   just B-RID does not meet the FAA's statutory UA tracking
}   responsibility.

-> We can only guess?
   Are you guessing here?
   You need to connect "Broadcast RID" with "B-RID" more often, or use only one.

Wish you would use "C&C" rather than "C2"
I don't think that a small device mounted on a UA that provided B-RID,
over BT4/BT5, is an "IoT"... It's just a device. No Internet or IP involved.

Section 4: having the Finder register to the SDSP seems a bit unreasonable.
        I think that for Finders that are other GCS, that they should
        register to their manufacturer.  I think you'll need federation.

I think that four methods to authenticate is probably a bad idea.
TLS or HIPv2 in my opinion.  Using raw ECIES seems too much.
Also maybe, OSCORE/CoAP over HIPv2?

}4.2.  Managing Finders
}
}   Finder density will vary over time and space.  For example, sidewalks
}   outside an urban train station can be packed with pedestrians at rush
}   hour, either coming or going to their commute trains.  An SDSP may
}   want to proactively limit the number of active Finders in such
}   situations.

It seems like the SDSP should simply thank every Finder, and then ask them to
report again after they have moved at least X meters or Y seconds.
First, being told not to report indicates that there are other Finders.
Being asked to report, tells the Finder how many other Finders are around.
One should assume the Finders are collaborating with some UA that wishes to
provide false data about it's location.

At this point, it jumps into CDDL, and I found that very jarring, and
I really didn't get much from it.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Aug 2020 19:22:00 -0400

> ICAO IATF TRON and DIWG are probably moving in this direction.  For manned
    > aircraft, the serial number is a plate on the airframe and the owner of the
    > airframe registers this with appropriate CAA (and we WON'T get into the rat
    > hole about leasing companies vs airlines and regional policies that were in
    > the last TRON call and emails!) The manufacturer has no direct involvement. 
    > I have pointed out this won't scale well with UAS/UAM/... and I gave 3
    > approaches, one of which is IDevID (I wonder why, as I was there at 802.1 in
    > the first discussions).

okay, that's fine, and with a manned aircraft, I don't see IDevID management as being particularly
expensive or relevant.

    > I think it will come down to a debate in DIWG/TRON is the Identity that of
    > the airframe or some computing guts (and what happens when said computing
    > guts are gutted {e.g. DJL airframes with different brains used by US Gov}). 

okay, but the thing is that this IDevID has to be get into the assembly line of the devices being sold at Walmart.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Aug 2020 19:39:17 -0400

So, again, I don't like "C2", I'd rather C&C.

I don't like "USS".. as it winds up in "USS Network Secure Provider"
(along with the USS Enterprise, you see)
So that's Unmapped Aircraft System Service Supplier Network Secure Provider.
Does that make any sense?  Not to me.
I understand that maybe it comes from an FAA UTM document?

What's the business model for these things?

I think that sections 3 and 4 need to reworked.
I think things should start with:
   Command and Control (C2) connection is between the UA and GCS.

and then explain the various ways in which this can be accomplished,
introducing the various NETSP,etc. along the way.

I find the document is way to nebulous.
It seems like the document should establish the required security and
multihop/rendezvous and multihoming requirements.
The requirements should indicate how rendezvous will be used.
Those that do not require a rendezvous (STUN), i.e. that use IPv6, would be
preferred for latency reasons.

Establish the basis for trust (who sets it it up, how many parties are involved).
Then, somewhere near the end, establish how to do with DTLS in a section,
and how to do it with HIPv2 in another section.  Maybe even in two documents.

I didn't quite figure out what the USS is in this C2 model.
I understood that the Operator files a Mission (Operation?) with the USS.
Does the GCS need to get something from the UA to attest that it is
authoritative for the UA?

confused.

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 16 Aug 2020 20:15:35 -0400

> So, again, I don't like "C2", I'd rather C&C.

C2 is the accepted industry term.  We really can't come up with our own.

> (along with the USS Enterprise, you see)

Talk to the FAA and Candian and EU aviation people.  They all pretty 
much agree on the term.  We have to work in their TLA field.

But Canada does not like UAS; they Remote Piloted Aircraft (RPA).

> I understand that maybe it comes from an FAA UTM document?

https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf

> What's the business model for these things?

Much is still unknown.  Stu is active in the study group on this.

> authoritative for the UA?

That is ok.  It needs work, but how much of point to appropriate info.

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 16 Aug 2020 20:54:45 -0400

> C2 is the accepted industry term.  We really can't come up with our own.

Oh, there is a 'C3' term, but right now I can't remember what the 3rd 
'C' is...

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 16 Aug 2020 21:48:14 -0400

> https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf 

Another important document to get aviation Unmanned Aircraft terms and TLAs:

https://www.icao.int/Meetings/UAS/Documents/Circular%20328_en.pdf

You Canadians can call this work RPAS, rather than UAS...  :)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Aug 2020 17:07:24 -0400

> C2 is the accepted industry term.  We really can't come up with our own.

In that industry, yes :-)

    >> So that's Unmanned Aircraft System Service Supplier Network Secure Provider.

    > https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf

can we mark which terms are imported (and from where)?
I think that this will help reviewers make better peace with the difficult terminological choices.

    > Much is still unknown.  Stu is active in the study group on this.

okay.  While we think that we don't do business models, we *do* risk and
threat analysis, and if an entity has a financial disincentive to do
something well, then it won't get done.

    > You Canadians can call this work RPAS, rather than UAS...  :)

I'm sure it translates to francais in some way that neither of us understand.
   https://www.youtube.com/watch?v=xrLghyJ_uQA

---

From: "Stuart W. Card" <[email-masked]>
Date: Sun, 23 Aug 2020 14:55:29 -0400

Weather information. Paid subscription service. Why that would be part
of the UTM network, vs external, I don't know, but it is the standard
cited example in the UTM world.

On 8/16/2020 7:17 PM, Michael Richardson wrote:
> ...
> What's their business model? ...

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495