Subject: [Drip] I-D Action: draft-ietf-drip-auth-02.txt

From: [email-masked]
Date: Thu, 21 Oct 2021 17:30:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.

        Title           : DRIP Authentication Formats for Broadcast RID
        Authors         : Adam Wiethuechter
                          Stuart Card
                          Robert Moskowitz
	Filename        : draft-ietf-drip-auth-02.txt
	Pages           : 41
	Date            : 2021-10-21

Abstract:
   This document describes how to include trust into the ASTM Remote ID
   specification defined in ASTM F3411-19 under a Broadcast Remote ID
   (RID) scenario.  It defines a few different message schemes (based on
   the Authentication Message) that can be used to assure past messages
   sent by a UA and also act as an assurance for UA trustworthiness in
   the absence of Internet connectivity at the receiving node.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-auth/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-auth-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-auth-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Adam Wiethuechter <[email-masked]>
Date: Fri, 22 Oct 2021 00:51:53 +0000

All,

auth-formats-02 is one that has been sitting on my drive for a while mainly due to a sit and wait situation with the ASTM standard it directly references and extends. Since F3411-v1.1 need to perform a reballot this gave time to refine some items on that end, resulting in a cleaner extension than previous iterations of this draft.

Section 3.2 has had a major revisioning, becoming more abstract to help clearly define a new field added to the Authentication Message on the F3411 side, Additional Data. In response to this abstract a new section has been spawned in the Appendix which contains examples of Authentication Messages.

Section 4 in general, has also been cleaned up to now fit the new Section 3.2. Mainly an introductory paragraph in Section 4 was added and in Section 4.4.1 the references to FEC were removed and pulled into Appendix D. Section 4 (and Section 5) directly cite Appendix D and when it is to be applied. Section 4.4 is very text heavy which concerns me - we may want to consider our options for figures here that help give a better understanding to the text.

Section 5.3 was reworded and made more explicit as to what recommendations satisfy the requirements (as stated in -drip-reqs). An odd set of text pertaining to the cost/benefits of Wrappers or Manifests now has its own subsection.

Appendix B was modified and expanded, but the formats stayed the same (I hope these are the final ones but that's up for debate). I question if these belong here, the -uas-rid draft or -registries. B.11 is very text heavy and is probably supposed to be part of -registries (which I will do regardless and refresh -registries).

Appendix C and D may need to be pulled in the main document. I'm considering between Section 3 and 4. One caveat is that I will switch the ordering to be FEC first, then the Broadcast Attestation Structure.

Appendix D need some love. Mainly the only real content is for single page FEC but now with the Additional Data we can do multiple page FEC easily. I'm considering Reed Solomon here but want to get some input on what options we have and if we even specify it here. I am thinking we may need to do some multiplexing for multipage FEC or just FEC in general - unsure how this would pan out however.

Questions, comments, and concerns welcome as always.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Tm-rid <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, October 21, 2021 8:30 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Drip] I-D Action: draft-ietf-drip-auth-02.txt

Abstract:

--
Tm-rid mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 22 Oct 2021 14:42:59 -0400

First a title change:

DRIP Authentication Formats for Broadcast Remote ID

Full name before TLA:

sent by an unmanned aircraft (UA) and also act as an assurance for UA 
trustworthiness in

Unmanned Aircraft Systems (UAS) are usually in a volatile environment 
when it comes

The ASTM standard [F3411-19] focuses on two ways of communicating to
    a UAS for Remote ID (RID): Broadcast and Network.

This document will focus on adding trust to Broadcast RID (B-RID) in the

    Aircraft:  In this document whenever the word Aircraft is used it is
       referring to an Unmanned Aircraft (UA) not a Manned Aircraft.

I have a problem here.  How many readers really understand the ICAO 
definition?

Manned Aircraft means pilot-in-command on board
Unmanned Aircraft means NO pilot-in-command on board

So a UPS cargo plane is manned (at least those in service today!).
An air-taxi, autonomous or remotely controlled, is unmanned.

Now how to say this shortly in a definition....  :)

these are style nits, but once you define a TLA (or an FLA), just use it:

    The current standard for RID does not, in any meaningful

Or in this case, just the full Formal Name (note that Formal Names have 
all words starting in caps)

    The current standard for Remote ID does not, in any meaningful

    The ASTM Authentication Message (Msg Type 0x2) is a unique message 
in the Broadcast
    F3411 standard as it is the only one that is paged.

Next:

    Figure 1 is an abstracted view of a single Authentication Page used
    in an Authentication Message.  There is a max of 16 pages (indexed 0
    to 15 in the first byte; "Auth.  Header") that can be sent for a
    single Authentication Message, with each page carrying a max 23-byte
    "Authentication Payload".

Although 16 pages are 'allowed', I believe there is a practical limit of 
9 pages?  Whatever it is, it needs be be included here, so the reader 
has this practical limit in mind.  Perhaps a "see Sec 4 for actual max 
pages details".

Well, actually that is for BT4.  Would it be 10 over BT5 or WiFi in a 
Message Pack?

In Fig 2:

Message from ASTM [F3411-19] Standard.

And with using [F3411-19], you are actually using a future F3411-21.  So 
just drop the -19 in all references, other than in the actual reference 
section.

In 4.1 you use:

    The existing ASTM [F3411-19] Authentication Type 0x1 can be used to
    send a fresh Self-Attestation of the UA over 7 pages.

But have not defined Authentication Type.  Is this a part of ASTM 
Authentication Headers?  Show where it is in the message.  Also have a 
table of defined values before your use in 4.1

In Fig 3, 4, & 5 you need to detail the fields and their sizes.

Fig 3:

HHIT 16 bytes
HI  32 Bytes
Trust Timestamp 4 bytes
Signing Timestamp 4 bytes
UA Sig 64 bytes

Total 120?  I would recommend a Trust time interval of 2 bytes in sec or 
10s of sec.

Fig 4:

Same general layout.  Here the Trust Timestamp almost makes sense to be 
time, as for how long depends on policy.  It could be years.

4.4.  Specific Method

    For ASTM Specific Method (Authentication Type 0x5) a special Specific

Again, where does this appear.  What is ASTM Specfic Method?

              SAM Type                     | Value
              -----------------------------+-------
              DRIP Frame                   | 1
              DRIP Wrapper                 | 2
              DRIP Manifest                | 3m
              DRIP Link                    | 4

Is that m after the 3 a typo?

=======

I am stopping here for today.  So I am posting the items I have come up 
to so far.

Bob

---

From: Adam Wiethuechter <[email-masked]>
Date: Sat, 23 Oct 2021 07:18:49 +0000

Bob,

Comments inline.

--------
73,
Adam T. Wiethuechter

________________________________
From: Tm-rid <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Sent: Friday, October 22, 2021 2:42 PM
To: [email-masked] <[email-masked]>
Subject: [Drip] Comments on draft-ietf-drip-auth-02.txt

First a title change:

Full name before TLA:

<atw>
All noted and fixed in my working copy of -03
</atw>

<atw>
Ignored as I do not use this TLA anywhere in the document and have no intention of doing so.
</atw>

<atw>
This was done originally as I started using Aircraft instead of UA in places. I don't remember why - I think it was spurred by a comment from Med? Perhaps the fix here is to remove any mentions of Aircraft and replace with UA or Unmanned Aircraft?
If you have words to suggest please suggest them.
</atw>

<atw>
Noted. Please be on the lookout for any I miss.
</atw>

<atw>
Added your parenthetical note.
</atw>

Next:

<atw>
Close. 16-pages are allowed on BT4. BT5 is constrained to a max of 9-pages.
You are corrent there is a practical limit - but the ASTM standard makes no mention of this anywhere that I saw. It is something we are all aware of. I already address this in Section 4 preamble but maybe it is better to move it here.
</atw>

In Fig 2:

<atw>
Went a changed to say F3411 for the reference. Now the confusion is gone.
</atw>

In 4.1 you use:

<atw>
I have a restructuring of section 3 that should address this.
However I am being very careful what I do here. I can not verbatim take the Authentication defintion out of F3411 - copyright issues.
So no matter what I must abstract stuff away. AuthType was defined in Section 3; but as part of Figure 1.
Lets see how my new Section 3 works once I get it out
</atw>

<atw>
Noted. These are really just SelfAttestations (except 5, he is special) already defined in -registries, I may just point to there and avoid having the figures here.
I suspect that -registries also has this issue though which will need to be fixed.
</atw>

Fig 3:

HHIT 16 bytes
HI  32 Bytes
Trust Timestamp 4 bytes

<atw>
In hindsight I should be very explicit here and state this is the Broadcast Attestation Structure filled in specifically with UA HHIT, UA HI. Then the timestamp offset discussions in Section 8.3 and C.3 comes into play.
This relates back to my comments made earlier this evening in my DET review to you.
We could play with modifiying the Broadcast Attestation Structure to have a 2-byte offset timestamp (and maybe a 2-byte timestamp?) (as there it can make sense) but to change all the Attestations to 2-byte timestamps offsets would be....awful IMHO.
</atw>

Fig 4:

<atw>
Correct - hence why ALL SelfAttestation's have a 4-byte timestamp. This one is just the SelfAttestation for the Operator and not the Aircraft. I was expecting the aircraft to make a SelfAttestation with current time and trust times with broadcasting over air in mind. Note this is technically a different SelfAttestation than the one generated by the aircraft for registration (with the expiration timestamp being far far in the future).
</atw>

4.4.  Specific Method

<atw>
This is an oversight and is covered with my latest WIP changes. Good catch.
</atw>

              SAM Type                     | Value

<atw>
m is a tpyo ;-)
</atw>

=======

<atw>
Sounds good, I have a lot of these, other than the controversial ones, already in a WIP version.
I'll let you finish your review here and then post the next one with changes time permitting.
I will send you an advanced copy unicast if you desire it - just let me know.
</atw>

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 25 Oct 2021 11:17:05 -0400

OK.  I got through 4.4.1.  continuing...

Somehow, SAM description should be a part of fig 2.  All of the 
'controls' that we inherit from ASTM should be in one place.  Even 
though some, like SAM are the result of our getting them included in 
f3411-2x

4.4.1.2

Note that 'should' is appropriately lower case.  And I am keeping with 
drip-rid B.2 being mandatory to include.  It may still need some tweeting.

4.4.2

I just can't wrap my mind around this text.  Maybe because I am not a 
programmer; but I think it is because you are too close to the 
solution.  Been there, done that myself.

are you saying that the Attestation Structure fits into the DRIP 
Authentication Data of fig 6 and where does the Wrapper fit?

I THINK you are trying to say:

For SAM Type of DRIP Wrapper, the DRIP Authentication Data follows the 
following DRIP Wrapper format.

then have a figure of that format, how it is divided over of multiple 25 
byte pieces.

I am just generally confused in this section on how it looks.

4.4.3

I have similar struggles following this section as 4.4.2.

4.4.3.1

2nd sentence:

A HHIT using cSHAKE128 [NIST.SP.800-185] computes the hash as follows:

Note, DRIP-RID is specifying cSHAKE128, but leaves over for expansion to 
other OGAs.

4.4.3.3.

If the UA does not stay in RF range the Observer will not obtain many
(if not all) of the messages in the
    manifest.  Without the original messages received no verification can
    be done.  Examples of such scenarios include delivery or survey UA

And is even that right?

If one of the chain is lost, can this 'hole' be skipped?

4.4.4

Totally don't get this.  Need to understand what this is for and THEN 
what the format is.

Perhaps that is part of the key.  Rearrange this section so you first 
cover the different types of authentication.  Why they are there, and 
THEN what the bytes in the packets are.

With that I need to stop and get back to making changes to drip-rid to 
get the next version out.

I will re-review, and get through the whole draft when you push out 
drip-auth-03 later today!  ;)

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 27 Oct 2021 08:26:24 -0400

Adam,

Had a idea to further convey to the reader what is happening with drip-auth.

You need a section of actual message captures.  It will be 'easy' to fit 
one BT4 frame per line.  So how do you indicate which frames together 
make one multi-page message?

The messages are shown in full content in hex.  Perhaps some of the 
content 'translated'; definitely the message type.

So the example:

A delivery UA traveling along a main thoroughfare at a sedate 30MPH 
(44fps).  Or specify in Metric.  :)
It is in RF range for 100'? 1000'? (30M? 300M?)
That is 4.5s or 45.5s
How many messages received based on recommended transmit rate thus how 
many lines of captured messages in the appendix.  Or only show for a 
portion of the visible transmission.

Or make the example more interesting.  Still a delivery UA, but the 
Observer is at the corner of a major intersection and the UA is coming 
down one thoroughfare and makes a right turn and continues down, out of 
range down the other.

This gives multiple advantages:

The document reader gets a 'feel' for the flow of what UA activity 
messages occur and how they are authenticated.  This along with the 
frequency (or lack there of) of 'Identity' information in the form of 
self-attestation, and offline attestation (in the new form we worked out 
yesterday).

Developers of Observer apps and RID-crowd-sourcing apps (yeah!) would 
have test data.

You could also store the actual message capture file(s) on the github 
with a reference to their location.  Thus have more examples like a 
survey UA running a grid.

I might expect that you have running code right now, and weather 
permitting you can get out on the runway and collect the messages...

Bob