rfc9575v1acks.txt | rfc9575.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) A. Wiethuechter, Ed. | Internet Engineering Task Force (IETF) A. Wiethuechter, Ed. | |||
Request for Comments: 9575 S. Card | Request for Comments: 9575 S. Card | |||
Category: Standards Track AX Enterprize, LLC | Category: Standards Track AX Enterprize, LLC | |||
ISSN: 2070-1721 R. Moskowitz | ISSN: 2070-1721 R. Moskowitz | |||
HTT Consulting | HTT Consulting | |||
April 2024 | May 2024 | |||
DRIP Entity Tag Authentication Formats and Protocols for Broadcast | DRIP Entity Tag Authentication Formats and Protocols for Broadcast | |||
Remote Identification | Remote Identification | |||
Abstract | Abstract | |||
The Drone Remote Identification Protocol (DRIP), plus trust policies | The Drone Remote Identification Protocol (DRIP), plus trust policies | |||
and periodic access to registries, augments Unmanned Aircraft System | and periodic access to registries, augments Unmanned Aircraft System | |||
(UAS) Remote Identification (RID), enabling local real-time | (UAS) Remote Identification (RID), enabling local real-time | |||
assessment of trustworthiness of received RID messages and observed | assessment of trustworthiness of received RID messages and observed | |||
skipping to change at line 71 ¶ | skipping to change at line 71 ¶ | |||
3. UAS RID Authentication Background and Procedures | 3. UAS RID Authentication Background and Procedures | |||
3.1. DRIP Authentication Protocol Description | 3.1. DRIP Authentication Protocol Description | |||
3.1.1. Usage of DNS | 3.1.1. Usage of DNS | |||
3.1.2. Providing UAS RID Trust | 3.1.2. Providing UAS RID Trust | |||
3.2. ASTM Authentication Message Framing | 3.2. ASTM Authentication Message Framing | |||
3.2.1. Authentication Page | 3.2.1. Authentication Page | |||
3.2.2. Authentication Payload Field | 3.2.2. Authentication Payload Field | |||
3.2.3. Specific Authentication Method (SAM) | 3.2.3. Specific Authentication Method (SAM) | |||
3.2.4. ASTM Broadcast RID Constraints | 3.2.4. ASTM Broadcast RID Constraints | |||
4. DRIP Authentication Formats | 4. DRIP Authentication Formats | |||
4.1. UA Signed Evidence Structure | 4.1. UA-Signed Evidence Structure | |||
4.2. DRIP Link | 4.2. DRIP Link | |||
4.3. DRIP Wrapper | 4.3. DRIP Wrapper | |||
4.3.1. Wrapped Count and Format Validation | 4.3.1. Wrapped Count and Format Validation | |||
4.3.2. Wrapper over Extended Transports | 4.3.2. Wrapper over Extended Transports | |||
4.3.3. Wrapper Limitations | 4.3.3. Wrapper Limitations | |||
4.4. DRIP Manifest | 4.4. DRIP Manifest | |||
4.4.1. Hash Count and Format Validation | 4.4.1. Hash Count and Format Validation | |||
4.4.2. Manifest Ledger Hashes | 4.4.2. Manifest Ledger Hashes | |||
4.4.3. Hash Algorithms and Operation | 4.4.3. Hash Algorithms and Operation | |||
4.5. DRIP Frame | 4.5. DRIP Frame | |||
skipping to change at line 101 ¶ | skipping to change at line 101 ¶ | |||
6.4.1. DRIP Wrapper | 6.4.1. DRIP Wrapper | |||
6.4.2. UAS RID Trust Assessment | 6.4.2. UAS RID Trust Assessment | |||
7. Summary of Addressed DRIP Requirements | 7. Summary of Addressed DRIP Requirements | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. IANA DRIP Registry | 8.1. IANA DRIP Registry | |||
9. Security Considerations | 9. Security Considerations | |||
9.1. Replay Attacks | 9.1. Replay Attacks | |||
9.2. Wrapper vs Manifest | 9.2. Wrapper vs Manifest | |||
9.3. VNA Timestamp Offsets for DRIP Authentication Formats | 9.3. VNA Timestamp Offsets for DRIP Authentication Formats | |||
9.4. DNS Security in DRIP | 9.4. DNS Security in DRIP | |||
10. Acknowledgments | 10. References | |||
11. References | 10.1. Normative References | |||
11.1. Normative References | 10.2. Informative References | |||
11.2. Informative References | ||||
Appendix A. Authentication States | Appendix A. Authentication States | |||
A.1. None: Black | A.1. None: Black | |||
A.2. Partial: Gray | A.2. Partial: Gray | |||
A.3. Unsupported: Brown | A.3. Unsupported: Brown | |||
A.4. Unverifiable: Yellow | A.4. Unverifiable: Yellow | |||
A.5. Verified: Green | A.5. Verified: Green | |||
A.6. Trusted: Blue | A.6. Trusted: Blue | |||
A.7. Questionable: Orange | A.7. Questionable: Orange | |||
A.8. Unverified: Red | A.8. Unverified: Red | |||
A.9. Conflicting: Purple | A.9. Conflicting: Purple | |||
Appendix B. Operational Recommendation Analysis | Appendix B. Operational Recommendation Analysis | |||
B.1. Page Counts vs Frame Counts | B.1. Page Counts vs Frame Counts | |||
B.1.1. Special Cases | B.1.1. Special Cases | |||
B.2. Full Authentication Example | B.2. Full Authentication Example | |||
B.2.1. Raw Example | B.2.1. Raw Example | |||
Acknowledgments | ||||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
The initial regulations (e.g., [FAA-14CFR]) and standards (e.g., | The initial regulations (e.g., [FAA-14CFR]) and standards (e.g., | |||
[F3411]) for Unmanned Aircraft Systems (UAS) Remote Identification | [F3411]) for Unmanned Aircraft Systems (UAS) Remote Identification | |||
(RID) and tracking do not address trust. However, this is a | (RID) and tracking do not address trust. However, this is a | |||
requirement that needs to be addressed for various different parties | requirement that needs to be addressed for various different parties | |||
that have a stake in the safe operation of National Airspace Systems | that have a stake in the safe operation of National Airspace Systems | |||
(NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how | (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how | |||
skipping to change at line 231 ¶ | skipping to change at line 231 ¶ | |||
3. UAS RID Authentication Background and Procedures | 3. UAS RID Authentication Background and Procedures | |||
3.1. DRIP Authentication Protocol Description | 3.1. DRIP Authentication Protocol Description | |||
[F3411] defines Authentication Message framing only. It does not | [F3411] defines Authentication Message framing only. It does not | |||
define authentication formats or methods. It explicitly anticipates | define authentication formats or methods. It explicitly anticipates | |||
several signature options but does not fully define those. Annex A1 | several signature options but does not fully define those. Annex A1 | |||
of [F3411] defines a Broadcast Authentication Verifier Service, which | of [F3411] defines a Broadcast Authentication Verifier Service, which | |||
has a heavy reliance on Observer real-time connectivity to the | has a heavy reliance on Observer real-time connectivity to the | |||
Internet. Fortunately, [F3411] also allows third-party standard | Internet. Fortunately, [F3411] also allows third-party standard | |||
Authentication Types using the Type 5 Specific Authentication Method | Authentication Types using the Type 0x5 Specific Authentication | |||
(SAM), several of which DRIP defines herein. | Method (SAM), several of which DRIP defines herein. | |||
The standardization of specific formats to support the DRIP | The standardization of specific formats to support the DRIP | |||
requirements in UAS RID for trustworthy communications over Broadcast | requirements in UAS RID for trustworthy communications over Broadcast | |||
RID is an important part of the chain of trust for a UAS ID. Per | RID is an important part of the chain of trust for a UAS ID. Per | |||
Section 5 of [RFC9434], Authentication formats are needed to relay | Section 5 of [RFC9434], Authentication formats are needed to relay | |||
information for Observers to determine trust. No existing formats | information for Observers to determine trust. No existing formats | |||
(defined in [F3411] or other organizations leveraging this feature) | (defined in [F3411] or other organizations leveraging this feature) | |||
provide functionality to satisfy this goal, resulting in the work | provide functionality to satisfy this goal, resulting in the work | |||
reflected in this document. | reflected in this document. | |||
skipping to change at line 307 ¶ | skipping to change at line 307 ¶ | |||
Observers receive DRIP Link Authentication Messages (Section 4.2) | Observers receive DRIP Link Authentication Messages (Section 4.2) | |||
containing Broadcast Endorsements by DIMEs of child DET | containing Broadcast Endorsements by DIMEs of child DET | |||
registrations. A series of these Endorsements confirms a path | registrations. A series of these Endorsements confirms a path | |||
through the hierarchy, defined in [DRIP-REG], from the DET Prefix | through the hierarchy, defined in [DRIP-REG], from the DET Prefix | |||
Owner all the way to an individual UA DET registration. | Owner all the way to an individual UA DET registration. | |||
Note: For the remainder of this document, Broadcast Endorsement: | Note: For the remainder of this document, Broadcast Endorsement: | |||
Parent, Child will be abbreviated as BE: Parent, Child. For example, | Parent, Child will be abbreviated as BE: Parent, Child. For example, | |||
Broadcast Endorsement: RAA, HDA will be abbreviated as BE: RAA, HDA. | Broadcast Endorsement: RAA, HDA will be abbreviated as BE: RAA, HDA. | |||
3.1.2.2. UA Signed Evidence | 3.1.2.2. UA-Signed Evidence | |||
To prove possession of the private key associated with the DET, the | To prove possession of the private key associated with the DET, the | |||
UA MUST send data that is unique and unpredictable but easily | UA MUST sign and send data that is unique and unpredictable but | |||
validated by the Observer, that is signed over. The data can be an | easily validated by the Observer. The data can be an ASTM Message | |||
ASTM Message that fulfills the requirements to be unpredictable but | that fulfills the requirements to be unpredictable but easily | |||
easily validated. An Observer receives this UA signed Evidence from | validated. An Observer receives this UA-signed Evidence from DRIP- | |||
DRIP-based Authentication Messages (Sections 4.3 or 4.4). | based Authentication Messages (Sections 4.3 or 4.4). | |||
Whether the content is true is a separate question that DRIP cannot | Whether the content is true is a separate question that DRIP cannot | |||
address, but validation performed using observable and/or out-of-band | address, but validation performed using observable and/or out-of-band | |||
data (Section 6) is possible and encouraged. | data (Section 6) is possible and encouraged. | |||
3.2. ASTM Authentication Message Framing | 3.2. ASTM Authentication Message Framing | |||
The Authentication Message (Message Type 0x2) is unique in the ASTM | The Authentication Message (Message Type 0x2) is unique in the ASTM | |||
[F3411] Broadcast standard, as it is the only message that can be | [F3411] Broadcast standard, as it is the only message that can be | |||
larger than the Legacy Transport size. To address this limitation | larger than the Legacy Transport size. To address this limitation | |||
around transport size, it is defined as a set of "pages", each of | around transport size, it is defined as a set of "pages", each of | |||
which fits into a single Legacy Transport frame. For Extended | which fits into a single Legacy Transport frame. For Extended | |||
Transports, pages are still used but they are all in a single frame. | Transports, pages are still used but they are all in a single frame. | |||
Informational Note: Message Pack (Message Type 0xF) is also larger | Informational Note: Message Pack (Message Type 0xF) is also larger | |||
than the Legacy Transport size but is limited for use only on | than the Legacy Transport size but is limited for use only on | |||
Extended Transports where is can be supported. | Extended Transports where it can be supported. | |||
The following subsections are a brief overview of the Authentication | The following subsections are a brief overview of the Authentication | |||
Message format defined in [F3411] for better context on how DRIP | Message format defined in [F3411] for better context on how DRIP | |||
Authentication fills and uses various fields already defined by ASTM | Authentication fills and uses various fields already defined by ASTM | |||
[F3411]. | [F3411]. | |||
3.2.1. Authentication Page | 3.2.1. Authentication Page | |||
This document leverages Authentication Type 0x5 (Specific | This document leverages Authentication Type 0x5 (Specific | |||
Authentication Method (SAM)) as the principal authentication | Authentication Method (SAM)) as the principal authentication | |||
container, defining a set of SAM Types in Section 4. Authentication | container, defining a set of SAM Types in Section 4. Authentication | |||
Type is encoded in every Authentication Page in the Page Header. The | Type is encoded in every Authentication Page in the _Page Header_. | |||
SAM Type is defined as a field in the Authentication Payload (see | The SAM Type is defined as a field in the _Authentication Payload_ | |||
Section 3.2.3.1). | (see Section 3.2.3.1). | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Page Header | | | | Page Header | | | |||
+---------------+ | | +---------------+ | | |||
| | | | | | |||
| | | | | | |||
| Authentication Payload | | | Authentication Payload | | |||
| | | | | | |||
skipping to change at line 496 ¶ | skipping to change at line 496 ¶ | |||
3.2.4.1. Wireless Frame Constraints | 3.2.4.1. Wireless Frame Constraints | |||
A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi | A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi | |||
NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and | NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and | |||
other Civil Aviation Authorities (CAA) mandate transmitting | other Civil Aviation Authorities (CAA) mandate transmitting | |||
simultaneously over both 4.x and 5.x. The same application-layer | simultaneously over both 4.x and 5.x. The same application-layer | |||
information defined in [F3411] MUST be transmitted over all the | information defined in [F3411] MUST be transmitted over all the | |||
physical-layer interfaces performing RID, because Observer transports | physical-layer interfaces performing RID, because Observer transports | |||
may be limited. If an Observer can support multiple transports, it | may be limited. If an Observer can support multiple transports, it | |||
should be assumed to use the latest data regardless of the transport | SHOULD uses (display, report, etc.) the latest data regardless of the | |||
received over. | transport over which that data was received. | |||
Bluetooth 4.x presents a payload-size challenge in that it can only | Bluetooth 4.x presents a payload-size challenge in that it can only | |||
transmit 25 octets of payload per frame, while other transports can | transmit 25 octets of payload per frame, while other transports can | |||
support larger payloads per frame. However, the [F3411] message | support larger payloads per frame. As [F3411] message formats are | |||
framing dictated by Bluetooth 4.x constraints is inherited by [F3411] | the same for all media, and their framing was designed to fit within | |||
over other media. | these legacy constraints, Extended Transports cannot send larger | |||
messages; instead, the Message Pack format encapsulates multiple | ||||
messages (each of which fits within these legacy constraints). | ||||
It should be noted that Extended Transports by definition have Error | By definition Extended Transports provide FEC, but Legacy Transports | |||
Correction built in, unlike Legacy Transports. For Authentication | lack FEC. Thus over Legacy Transports, paged Authentication Messages | |||
Messages, this means that over Legacy Transport pages may not | may suffer the loss of one or more pages. This would result in | |||
received by Observers resulting in incomplete messages during | delivery to the Observer application of incomplete (typically | |||
operation, although the use of DRIP FEC (Section 5) reduces its | unusable) messages, so DRIP FEC (Section 5) is specified to enable | |||
likelihood. Authentication Messages sent using Extended Transports | recovery of a single lost page and thereby reduce the likelihood of | |||
do not suffer this issue, as the full message (all pages) is sent | receiving incompletely reconstructable Authentication Messages. | |||
using a single Message Pack. Furthermore, the use of one-way RF | Authentication Messages sent using Extended Transports do not suffer | |||
broadcasts prohibits the use of any congestion-control or loss- | this issue, as the full message (all pages) is sent using a single | |||
recovery schemes that require ACKs or NACKs. | Message Pack. Furthermore, the use of one-way RF broadcasts | |||
prohibits the use of any congestion-control or loss-recovery schemes | ||||
that require ACKs or NACKs. | ||||
3.2.4.2. Paged Authentication Message Constraints | 3.2.4.2. Paged Authentication Message Constraints | |||
To keep consistent formatting across the different transports (Legacy | To keep consistent formatting across the different transports (Legacy | |||
and Extended) and their independent restrictions, the authentication | and Extended) and their independent restrictions, the authentication | |||
data being sent is REQUIRED to fit within the page limit that the | data being sent is REQUIRED to fit within the page limit that the | |||
most constrained existing transport can support. Under Broadcast | most constrained existing transport can support. Under Broadcast | |||
RID, the Extended Transport that can hold the least amount of | RID, the Extended Transport that can hold the least amount of | |||
authentication data is Bluetooth 5.x at 9 pages. | authentication data is Bluetooth 5.x at 9 pages. | |||
skipping to change at line 562 ¶ | skipping to change at line 566 ¶ | |||
Valid Not After (VNA) Timestamp: (4 octets) | Valid Not After (VNA) Timestamp: (4 octets) | |||
Timestamp denoting the recommended time at which to stop trusting | Timestamp denoting the recommended time at which to stop trusting | |||
data. MUST follow the format defined in [F3411] as described | data. MUST follow the format defined in [F3411] as described | |||
above. Has an additional offset to push a short time into the | above. Has an additional offset to push a short time into the | |||
future (relative to VNB) to avoid replay attacks. The exact | future (relative to VNB) to avoid replay attacks. The exact | |||
offset is not defined in this document. Best practice for | offset is not defined in this document. Best practice for | |||
identifying an acceptable offset should be used and should take | identifying an acceptable offset should be used and should take | |||
into consideration the UA environment, propagation characteristics | into consideration the UA environment, propagation characteristics | |||
of the messages being sent, and clock differences between the UA | of the messages being sent, and clock differences between the UA | |||
and Observers. A reasonable time would be to set VNA 2 minutes | and Observers. For UA signatures in scenarios typical as of 2024, | |||
after VNB. | a reasonable offset would be to set VNA approximately 2 minutes | |||
after VNB; see Appendix B for examples that may aid in tuning this | ||||
value. | ||||
4. DRIP Authentication Formats | 4. DRIP Authentication Formats | |||
All formats defined in this section are contained in the | All formats defined in this section are contained in the | |||
Authentication Data / Signature field in Figure 2 and use the | Authentication Data / Signature field in Figure 2 and use the | |||
Specific Authentication Method (SAM, Authentication Type 0x5). The | Specific Authentication Method (SAM, Authentication Type 0x5). The | |||
first octet of the Authentication Data / Signature of Figure 2 is | first octet of the Authentication Data / Signature of Figure 2 is | |||
used to multiplex among these various formats. | used to multiplex among these various formats. | |||
When sending data over a medium that does not have underlying FEC, | When sending data over a medium that does not have underlying FEC, | |||
for example Legacy Transports, then Section 5 MUST be used. | for example Legacy Transports, then FEC Section 5 MUST be used. | |||
Examples of Link, Wrapper, and Manifest are shown as part of an | Examples of Link, Wrapper, and Manifest are shown as part of an | |||
operational schedule in Appendix B.2.1. | operational schedule in Appendix B.2.1. | |||
4.1. UA Signed Evidence Structure | 4.1. UA-Signed Evidence Structure | |||
The UA Signed Evidence Structure (Figure 4) is used by the UA during | The UA-Signed Evidence Structure (Figure 4) is used by the UA during | |||
flight to sign over information elements using the private key | flight to sign over information elements using the private key | |||
associated with the current UA DET. It is encapsulated by the SAM | associated with the current UA DET. It is encapsulated by the SAM | |||
Authentication Data field of Figure 3. | Authentication Data field of Figure 3. | |||
This structure is used by the DRIP Wrapper (Section 4.3), Manifest | This structure is used by the DRIP Wrapper (Section 4.3), Manifest | |||
Section 4.4), and Frame (Section 4.5). DRIP Link (Section 4.2) MUST | Section 4.4), and Frame (Section 4.5). DRIP Link (Section 4.2) MUST | |||
NOT use it, as it will not fit in the ASTM Authentication Message | NOT use it, as it will not fit in the ASTM Authentication Message | |||
with its intended content (i.e., a Broadcast Endorsement). | with its intended content (i.e., a Broadcast Endorsement). | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at line 627 ¶ | skipping to change at line 633 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 4: Endorsement Structure for UA Signed Evidence | Figure 4: Endorsement Structure for UA-Signed Evidence | |||
Valid Not Before (VNB) Timestamp by UA: (4 octets) | Valid Not Before (VNB) Timestamp by UA: (4 octets) | |||
See Section 3.2.4.3. Set by the UA. | See Section 3.2.4.3. Set by the UA. | |||
Valid Not After (VNA) Timestamp by UA: (4 octets) | Valid Not After (VNA) Timestamp by UA: (4 octets) | |||
See Section 3.2.4.3. Set by the UA. | See Section 3.2.4.3. Set by the UA. | |||
Evidence: (0 to 112 octets) | Evidence: (0 to 112 octets) | |||
The evidence section MUST filled in with data in the form of an | The Evidence field MUST be filled in with data in the form of an | |||
opaque object specified in the DRIP Wrapper (Section 4.3), | opaque object specified in the DRIP Wrapper (Section 4.3), | |||
Manifest (Section 4.4), or Frame (Section 4.5). | Manifest (Section 4.4), or Frame (Section 4.5). | |||
UA DRIP Entity Tag: (16 octets) | UA DRIP Entity Tag: (16 octets) | |||
This is the current DET [RFC9374] being used by the UA assumed to | This is a DET [RFC9374] currently being used by the UA for | |||
be a Specific Session ID (a type of UAS ID). | authentication; it is assumed to be a Specific Session ID (a type | |||
of UAS ID typically also used by the UA in the Basic ID Message). | ||||
UA Signature: (64 octets) | UA Signature: (64 octets) | |||
Signature over concatenation of preceding fields (VNB, VNA, | Signature over the concatenation of preceding fields (VNB, VNA, | |||
Evidence, and UA DET) using the keypair of the UA DET. The | Evidence, and UA DET) using the keypair of the UA DET. The | |||
signature algorithm is specified by the Hierarchical Host Identity | signature algorithm is specified by the Hierarchical Host Identity | |||
Tags (HHIT) Suite ID of the DET. | Tags (HHIT) Suite ID of the DET. | |||
When using this structure, the UA is minimally self-endorsing its | When using this structure, the UA is minimally self-endorsing its | |||
DET. The HI of the UA DET can be looked up by mechanisms described | DET. The HI of the UA DET can be looked up by mechanisms described | |||
in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see | in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see | |||
Sections 4.2 and 6.3). | Sections 4.2 and 6.3). | |||
4.2. DRIP Link | 4.2. DRIP Link | |||
skipping to change at line 674 ¶ | skipping to change at line 681 ¶ | |||
message. | message. | |||
DRIP Link is important as its contents are used to provide trust in | DRIP Link is important as its contents are used to provide trust in | |||
the DET/HI pair that the UA is currently broadcasting. This message | the DET/HI pair that the UA is currently broadcasting. This message | |||
does not require Internet connectivity to perform signature | does not require Internet connectivity to perform signature | |||
verification of the contents when the DIME DET/HI is in the | verification of the contents when the DIME DET/HI is in the | |||
Observer's cache. It also provides the UA HI, when it is filled with | Observer's cache. It also provides the UA HI, when it is filled with | |||
a BE: HDA, UA, so that connectivity is not required when performing | a BE: HDA, UA, so that connectivity is not required when performing | |||
signature verification of other DRIP Authentication Messages. | signature verification of other DRIP Authentication Messages. | |||
Various Broadcast Endorsements are sent during operation to ensure | Various Broadcast Endorsements are sent during each UAS flight | |||
that the full Broadcast Endorsement chain is available offline. See | operation to ensure that the full Broadcast Endorsement chain is | |||
Section 6.3 for further details. | available offline. See Section 6.3 for further details. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNB Timestamp by Parent | | | VNB Timestamp by Parent | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNA Timestamp by Parent | | | VNA Timestamp by Parent | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | | | | | |||
| DET | | | DET | | |||
skipping to change at line 764 ¶ | skipping to change at line 771 ¶ | |||
by the receiving device. | by the receiving device. | |||
A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement | A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement | |||
chain MUST be included in each DRIP Manifest (Section 4.4). | chain MUST be included in each DRIP Manifest (Section 4.4). | |||
4.3. DRIP Wrapper | 4.3. DRIP Wrapper | |||
This SAM Type is used to wrap and sign over a list of other [F3411] | This SAM Type is used to wrap and sign over a list of other [F3411] | |||
Broadcast RID messages. | Broadcast RID messages. | |||
The evidence section of the UA Signed Evidence Structure | The Evidence field of the UA-Signed Evidence Structure (Section 4.1) | |||
(Section 4.1) is populated with up to four ASTM Messages [F3411] in a | is populated with up to four ASTM Messages [F3411] in a contiguous | |||
contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, | octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 | |||
0x4, and 0x5 are allowed and must be in Message Type order as defined | are allowed and must be in Message Type order as defined by [F3411]. | |||
by [F3411]. These messages MUST include the Message Type and | These messages MUST include the Message Type and Protocol Version | |||
Protocol Version octet and MUST NOT include the Message Counter octet | octet and MUST NOT include the Message Counter octet (thus are fixed | |||
(thus are fixed at 25 octets in length). | at 25 octets in length). | |||
4.3.1. Wrapped Count and Format Validation | 4.3.1. Wrapped Count and Format Validation | |||
When decoding a DRIP Wrapper on a receiver, a calculation of the | When decoding a DRIP Wrapper on a receiver, a calculation of the | |||
number of messages wrapped and a validation MUST be performed by | number of messages wrapped and a validation MUST be performed by | |||
using the number of octets (defined as wrapperLength) between the VNA | using the number of octets (defined as wrapperLength) between the VNA | |||
Timestamp by UA and the UA DET as shown in Figure 6. | Timestamp by UA and the UA DET as shown in Figure 6. | |||
<CODE BEGINS> | <CODE BEGINS> | |||
if (wrapperLength MOD 25) != 0 { | if (wrapperLength MOD 25) != 0 { | |||
skipping to change at line 803 ¶ | skipping to change at line 810 ¶ | |||
Figure 6: Pseudocode for Wrapper Validation and Number of | Figure 6: Pseudocode for Wrapper Validation and Number of | |||
Messages calculation | Messages calculation | |||
4.3.2. Wrapper over Extended Transports | 4.3.2. Wrapper over Extended Transports | |||
When using Extended Transports, an optimization to DRIP Wrapper can | When using Extended Transports, an optimization to DRIP Wrapper can | |||
be made to sign over co-located data in an ASTM Message Pack (Message | be made to sign over co-located data in an ASTM Message Pack (Message | |||
Type 0xF). | Type 0xF). | |||
To perform this optimization, the UA Signed Evidence Structure is | To perform this optimization, the UA-Signed Evidence Structure is | |||
filled with the ASTM Messages to be in the ASTM Message Pack, the | filled with the ASTM Messages to be in the ASTM Message Pack, the | |||
signature is generated, and then the evidence field is cleared, | signature is generated, and then the Evidence field is cleared, | |||
leaving the encoded form shown in Figure 7. | leaving the encoded form shown in Figure 7. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNB Timestamp by UA | | | VNB Timestamp by UA | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNA Timestamp by UA | | | VNA Timestamp by UA | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | | | | | |||
skipping to change at line 843 ¶ | skipping to change at line 850 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 7: DRIP Wrapper over Extended Transports | Figure 7: DRIP Wrapper over Extended Transports | |||
To verify the signature, the receiver MUST concatenate all the | To verify the signature, the receiver MUST concatenate all the | |||
messages in the Message Pack (excluding the Authentication Message | messages in the Message Pack (excluding the Authentication Message | |||
found in the same Message Pack) in ASTM Message Type order and set | found in the same Message Pack) in ASTM Message Type order and set | |||
the evidence section of the UA Signed Evidence Structure before | the Evidence field of the UA-Signed Evidence Structure before | |||
performing signature verification. | performing signature verification. | |||
The functionality of a Wrapper in this form is equivalent to Message | The functionality of a Wrapper in this form is equivalent to Message | |||
Set Signature (Authentication Type 0x3) when running over Extended | Set Signature (Authentication Type 0x3) when running over Extended | |||
Transports. The Wrapper provides the same format but over both | Transports. The Wrapper provides the same format but over both | |||
Extended and Legacy Transports, which allows the transports to be | Extended and Legacy Transports, which allows the transports to be | |||
similar. Message Set Signature also implies using the ASTM validator | similar. Message Set Signature also implies using the ASTM validator | |||
system architecture, which depends on Internet connectivity for | system architecture, which depends on Internet connectivity for | |||
verification that the receiver may not have at the time an | verification that the receiver may not have at the time an | |||
Authentication Message is received. This is something the Wrapper, | Authentication Message is received. This is something the Wrapper, | |||
skipping to change at line 885 ¶ | skipping to change at line 892 ¶ | |||
Wrapper (Section 4.3.3) and greatly reduce overhead. | Wrapper (Section 4.3.3) and greatly reduce overhead. | |||
Observers MUST hash all received ASTM Messages and cross-check them | Observers MUST hash all received ASTM Messages and cross-check them | |||
against hashes in received Manifests. | against hashes in received Manifests. | |||
Judicious use of a Manifest enables an entire Broadcast RID message | Judicious use of a Manifest enables an entire Broadcast RID message | |||
stream to be strongly authenticated with less than 100% overhead | stream to be strongly authenticated with less than 100% overhead | |||
relative to a completely unauthenticated message stream (see | relative to a completely unauthenticated message stream (see | |||
Section 6.3 and Appendix B). | Section 6.3 and Appendix B). | |||
The evidence section of the UA Signed Evidence Structure | The Evidence field of the UA-Signed Evidence Structure (Section 4.1) | |||
(Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast | is populated with 8-octet hashes of [F3411] Broadcast RID messages | |||
RID messages (up to 11) and three special hashes (Section 4.4.2). | (up to 11) and three special hashes (Section 4.4.2). All of these | |||
All of these hashes MUST be concatenated to form a contiguous octet | hashes MUST be concatenated to form a contiguous octet sequence in | |||
sequence in the evidence section. It is RECOMMENDED that the maximum | the Evidence field. It is RECOMMENDED that the maximum number of | |||
number of ASTM Message Hashes used be 10 (see Appendix B.1.1.2). | ASTM Message Hashes used be 10 (see Appendix B.1.1.2). | |||
The Previous Manifest Hash, Current Manifest Hash, and DRIP Link (BE: | The Previous Manifest Hash, Current Manifest Hash, and DRIP Link (BE: | |||
HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen | HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen | |||
in Figure 8. | in Figure 8. | |||
An Observer MUST use the Manifest to verify each ASTM Message hashed | An Observer MUST use the Manifest to verify each ASTM Message hashed | |||
therein that it has previously received. It can do this without | therein that it has previously received. It can do this without | |||
having received them all. A Manifest SHOULD typically encompass a | having received them all. A Manifest SHOULD typically encompass a | |||
single transmission cycle of messages being sent; see Section 6.4 and | single transmission cycle of messages being sent; see Section 6.4 and | |||
Appendix B. | Appendix B. | |||
skipping to change at line 960 ¶ | skipping to change at line 967 ¶ | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
hashCount = (manifestLength / 8) - 3; | hashCount = (manifestLength / 8) - 3; | |||
<CODE ENDS> | <CODE ENDS> | |||
Figure 9: Pseudocode for Manifest Sanity Check and Number of | Figure 9: Pseudocode for Manifest Sanity Check and Number of | |||
Hashes Calculation | Hashes Calculation | |||
4.4.2. Manifest Ledger Hashes | 4.4.2. Manifest Ledger Hashes | |||
Three special hashes are included in all Manifests. The Previous | The following three special hashes are included in all Manifests: | |||
Manifest Hash, links to the previous Manifest, and the Current | ||||
Manifest Hash is of the Manifest in which it appears. These two | * the Previous Manifest Hash links to the previous Manifest. | |||
hashes act as a ledger of provenance to the Manifest that could be | ||||
traced back if the Observer was present for extended periods of time. | * the Current Manifest Hash is of the Manifest in which it appears. | |||
* the DRIP Link (BE: HDA, UA) Hash ties the endorsed UA key to the | ||||
Manifest chain. | ||||
The Previous and Current hashes act as a ledger of provenance for the | ||||
Manifest chain, which should be traced back if the Observer and UA | ||||
were within Broadcast RID wireless range of each other for an | ||||
extended period of time. | ||||
The DRIP Link (BE: HDA, UA) is included so there is a direct | The DRIP Link (BE: HDA, UA) is included so there is a direct | |||
signature by the UA over the Broadcast Endorsement (see Section 4.2). | signature by the UA over the Broadcast Endorsement (see Section 4.2). | |||
Typical operation would expect that the list of ASTM Message Hashes | Typical operation would expect that the list of ASTM Message Hashes | |||
contain nonce-like data. To enforce a binding between the BE: HDA, | contain nonce-like data. To enforce a binding between the BE: HDA, | |||
UA and avoid trivial replay attack vectors (see Section 9.1), at | UA and avoid trivial replay attack vectors (see Section 9.1), at | |||
least one ASTM Message Hash MUST be from an [F3411] message that | least one ASTM Message Hash MUST be from an [F3411] message that | |||
satisfies the fourth requirement in Section 6.3. | satisfies the fourth requirement in Section 6.3. | |||
4.4.3. Hash Algorithms and Operation | 4.4.3. Hash Algorithms and Operation | |||
skipping to change at line 995 ¶ | skipping to change at line 1010 ¶ | |||
For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/ | For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/ | |||
cSHAKE128) [RFC9374], use the construct appropriate for the | cSHAKE128) [RFC9374], use the construct appropriate for the | |||
associated hash. For example, the hash for "2" (ECDSA/SHA-384) is | associated hash. For example, the hash for "2" (ECDSA/SHA-384) is | |||
computed as follows: | computed as follows: | |||
Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 ) | Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 ) | |||
When building the list of hashes, the Previous Manifest Hash is known | When building the list of hashes, the Previous Manifest Hash is known | |||
from the previous Manifest. For the first built Manifest, this value | from the previous Manifest. For the first built Manifest, this value | |||
is filled with a random nonce. The Current Manifest Hash is null | is filled with a random nonce. The Current Manifest Hash is null | |||
filled while ASTM Messages are hashed and fill the ASTM Messaged | filled while ASTM Messages are hashed and fill the ASTM Message | |||
Hashes section. When all messages are hashed, the Current Manifest | Hashes field. When all messages are hashed, the Current Manifest | |||
Hash is computed over the Previous Manifest Hash, Current Manifest | Hash is computed over the Previous Manifest Hash, Current Manifest | |||
Hash (null filled), and ASTM Message Hashes. This hash value | Hash (null filled), and ASTM Message Hashes. This hash value | |||
replaces the null-filled Current Manifest Hash and becomes the | replaces the null-filled Current Manifest Hash and becomes the | |||
Previous Manifest Hash for the next Manifest. | Previous Manifest Hash for the next Manifest. | |||
4.4.3.1. Legacy Transport Hashing | 4.4.3.1. Legacy Transport Hashing | |||
Under this transport, DRIP hashes the full ASTM Message being sent | Under this transport, DRIP hashes the full ASTM Message being sent | |||
over the Bluetooth Advertising frame. This is the 25-octet object | over the Bluetooth Advertising frame. This is the 25-octet object | |||
that starts with the Message Type and Protocol Version octet along | that starts with the Message Type and Protocol Version octet along | |||
skipping to change at line 1022 ¶ | skipping to change at line 1037 ¶ | |||
hashed as one object. | hashed as one object. | |||
4.4.3.2. Extended Transport Hashing | 4.4.3.2. Extended Transport Hashing | |||
Under this transport, DRIP hashes the full ASTM Message Pack (Message | Under this transport, DRIP hashes the full ASTM Message Pack (Message | |||
Type 0xF) regardless of its content. The hash MUST NOT include the | Type 0xF) regardless of its content. The hash MUST NOT include the | |||
Message Counter octet. | Message Counter octet. | |||
4.5. DRIP Frame | 4.5. DRIP Frame | |||
This SAM Type is defined to enable the use of Section 4.1 in the | This SAM Type is defined to enable use of the UA-Signed Evidence | |||
future beyond the previously defined formats (Wrapper and Manifest) | Structure (Section 4.1) in the future beyond the previously defined | |||
by the inclusion of a single octet to signal the format of evidence | formats (Wrapper and Manifest) by the inclusion of a single octet to | |||
data (up to 111 octets). | signal the format of Evidence data (up to 111 octets). | |||
The content format of Frame Evidence Data is not defined in this | The content format of Frame Evidence Data is not defined in this | |||
document. Other specifications MUST define the contents and register | document. Other specifications MUST define the contents and register | |||
for a Frame Type. At the time of publication, there are no defined | for a Frame Type. At the time of publication (2024), there are no | |||
Frame Types other than an Experimental range. | defined Frame Types; only an Experimental range has been defined. | |||
Observers MUST check the signature of the structure (Section 4.1) per | Observers MUST check the signature of the structure (Section 4.1) per | |||
Section 3.1.2.2 and MAY, if the specification of Frame Type is known, | Section 3.1.2.2 and MAY, if the specification of Frame Type is known, | |||
parse the content in Frame Evidence Data. | parse the content in Frame Evidence Data. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Frame Type | | | | Frame Type | | | |||
+---------------+ . | +---------------+ . | |||
. Frame Evidence Data . | . Frame Evidence Data . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 10: DRIP Frame | Figure 10: DRIP Frame | |||
Frame Type: (1 octet) | Frame Type: (1 octet) | |||
Byte to subtype for future different DRIP Frame formats. It takes | As shown in Figure 10, the Frame Type takes the first octet, which | |||
the first octet in Figure 10, leaving 111 octets available for | leaves 111 octets available for Frame Evidence Data. See | |||
Frame Evidence Data. See Section 8.1 for Frame Type allocations. | Section 8.1 for Frame Type allocations. | |||
5. Forward Error Correction | 5. Forward Error Correction | |||
For Broadcast RID, FEC is provided by the lower layers in Extended | For Broadcast RID, FEC is provided by the lower layers in Extended | |||
Transports. The Bluetooth 4.x Legacy Transport does not support FEC, | Transports. The Bluetooth 4.x Legacy Transport does not support FEC, | |||
so the following application-level scheme is used with DRIP | so the following application-level scheme is used with DRIP | |||
Authentication to add some FEC. When sending data over a medium that | Authentication to add some FEC. When sending data over a medium that | |||
does not have underlying FEC, for example Bluetooth 4.x, this section | does not have underlying FEC, for example Bluetooth 4.x, this section | |||
MUST be used. | MUST be used. | |||
skipping to change at line 1206 ¶ | skipping to change at line 1221 ¶ | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
// check that byte directly after last auth byte is null | // check that byte directly after last auth byte is null | |||
if (auth_data[last_auth_byte + 1] equals null) { | if (auth_data[last_auth_byte + 1] equals null) { | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
// we set our presumed Additional Data Length (ADL) | // we set our presumed Additional Data Length (ADL) | |||
presumed_adl = auth_data[last_auth_byte + 1] | presumed_adl = auth_data[last_auth_byte + 1] | |||
// use the presumed ADL to calculate a presumed LPI | // use the presumed ADL to calculate a presumed | |||
//Last Page Index (LPI, a field defined in <xref target="F3411"/>) | ||||
presumed_lpi = (presumed_adl + decoded_length - 17) / 23 | presumed_lpi = (presumed_adl + decoded_length - 17) / 23 | |||
// check that presumed LPI and decoded LPI match | // check that presumed LPI and decoded LPI match | |||
if (presumed_lpi not equal decoded_lpi) { | if (presumed_lpi not equal decoded_lpi) { | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
return DECODE_SUCCESS | return DECODE_SUCCESS | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
skipping to change at line 1284 ¶ | skipping to change at line 1300 ¶ | |||
where the UA is dynamically signing data that is guaranteed to be | where the UA is dynamically signing data that is guaranteed to be | |||
unique, unpredictable, and easily cross checked by the receiving | unique, unpredictable, and easily cross checked by the receiving | |||
device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5 | device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5 | |||
seconds. | seconds. | |||
These four transmission requirements collectively satisfy GEN-3. | These four transmission requirements collectively satisfy GEN-3. | |||
6.4. Operational | 6.4. Operational | |||
UAS operation may impact the frequency of sending DRIP Authentication | UAS operation may impact the frequency of sending DRIP Authentication | |||
messages. When a UA dwells at an approximate location, and the | Messages. When a UA dwells at an approximate location, and the | |||
channel is heavily used by other devices, less frequent message | channel is heavily used by other devices, less frequent message | |||
authentication may be effective (to minimize RF packet collisions) | authentication may be effective (to minimize RF packet collisions) | |||
for an Observer. Contrast this with a UA transiting an area, where | for an Observer. Contrast this with a UA transiting an area, where | |||
authenticated messages SHOULD be sufficiently frequent for an | authenticated messages SHOULD be sufficiently frequent for an | |||
Observer to have a high probability of receiving an adequate number | Observer to have a high probability of receiving an adequate number | |||
for validation during the transit. | for validation during the transit. | |||
A RECOMMENDED operational configuration (in alignment with | A RECOMMENDED operational configuration (in alignment with | |||
Section 6.3) with rationale can be found in Appendix B. It consists | Section 6.3) with rationale can be found in Appendix B. It | |||
of the following recommendations for every second: | recommends the following once per second: | |||
* Under Legacy Transport: | * Under Legacy Transport: | |||
- Two sets of those ASTM Messages required by a CAA in its | - Two sets of those ASTM Messages required by a CAA in its | |||
jurisdiction (example: Basic ID, Location and System) and one | jurisdiction (example: Basic ID, Location/Vector, and System) | |||
set of other ASTM Messages (example: Self ID, Operator ID) | and one set of other ASTM Messages (example: Self ID, Operator | |||
ID) | ||||
- An FEC-protected DRIP Manifest enabling authentication of those | - An FEC-protected DRIP Manifest enabling authentication of those | |||
ASTM Messages sent | ASTM Messages sent | |||
- A single page of an FEC-protected DRIP Link | - A single page of an FEC-protected DRIP Link | |||
* Under Extended Transport: | * Under Extended Transport: | |||
- A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper | - A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper | |||
(per Section 4.3.2) | (per Section 4.3.2) | |||
skipping to change at line 1323 ¶ | skipping to change at line 1340 ¶ | |||
6.4.1. DRIP Wrapper | 6.4.1. DRIP Wrapper | |||
If DRIP Wrappers are sent, they MUST be sent in addition to any | If DRIP Wrappers are sent, they MUST be sent in addition to any | |||
required ASTM Messages in a given jurisdiction. An implementation | required ASTM Messages in a given jurisdiction. An implementation | |||
MUST NOT send DRIP Wrappers in place of any required ASTM Messages it | MUST NOT send DRIP Wrappers in place of any required ASTM Messages it | |||
may encapsulate. Thus, messages within a Wrapper are sent twice: | may encapsulate. Thus, messages within a Wrapper are sent twice: | |||
once in the clear and once authenticated within the Wrapper. | once in the clear and once authenticated within the Wrapper. | |||
The DRIP Wrapper has a specific use case for DRIP-aware Observers. | The DRIP Wrapper has a specific use case for DRIP-aware Observers. | |||
For an Observer plotting Location Messages (Message Type 0x2) on a | For an Observer plotting Location/Vector Messages (Message Type 0x2) | |||
map, display of an embedded Location Message in a DRIP Wrapper can be | on a map, display of an embedded Location/Vector Message in a DRIP | |||
marked differently (e.g., via color) to signify trust in the Location | Wrapper can be marked differently (e.g., via color) to signify trust | |||
data. | in the Location/Vector data. | |||
6.4.2. UAS RID Trust Assessment | 6.4.2. UAS RID Trust Assessment | |||
As described in Section 3.1.2, the Observer MUST perform validation | As described in Section 3.1.2, the Observer MUST perform validation | |||
of the data being received in Broadcast RID. This is because trust | of the data being received in Broadcast RID. This is because trust | |||
in a key is different from trust that an observed UA possesses that | in a key is different from trust that an observed UA possesses that | |||
key. | key. | |||
A chain of DRIP Links provides trust in a key. A message containing | A chain of DRIP Links provides trust in a key. A message, signed by | |||
rapidly changing, not predictable far in advance (relative to typical | that key, containing data that changes rapidly and is not predictable | |||
operational flight times) that can be validated by Observers, signed | far in advance (relative to typical operational flight times) but | |||
by that key, provides trust that some agent with access to that data | that can be validated by Observers, provides trust that some agent | |||
also possesses that key. If the validation involves correlating | with access to that data also possesses that key. If the validation | |||
physical world observations of the UA with claims in that data, then | involves correlating physical world observations of the UA with | |||
the probability is high that the observed UA is (or is collaborating | claims in that data, then the probability is high that the observed | |||
with or observed in real time by) the agent with the key. | UA is (or is collaborating with or observed in real time by) the | |||
agent with the key. | ||||
After signature verification of any DRIP Authentication Message | After signature verification of any DRIP Authentication Message | |||
containing UAS RID information elements (e.g., DRIP Wrapper | containing UAS RID information elements (e.g., DRIP Wrapper | |||
Section 4.3) the Observer MUST use other sources of information to | Section 4.3) the Observer MUST use other sources of information to | |||
correlate against and perform validation. An example of another | correlate against and perform validation. An example of another | |||
source of information is a visual confirmation of the UA position. | source of information is a visual confirmation of the UA position. | |||
When correlation of these different data streams does not match in | When correlation of these different data streams does not match in | |||
acceptable thresholds, the data MUST be rejected as if the signature | acceptable thresholds, the data MUST be rejected as if the signature | |||
failed to validate. Acceptable threshold limits and what happens | failed to validate. Acceptable threshold limits and what happens | |||
skipping to change at line 1392 ¶ | skipping to change at line 1410 ¶ | |||
8.1. IANA DRIP Registry | 8.1. IANA DRIP Registry | |||
IANA has created the "DRIP SAM Types" and "DRIP Frame Types" | IANA has created the "DRIP SAM Types" and "DRIP Frame Types" | |||
registries within the "Drone Remote ID Protocol" registry group | registries within the "Drone Remote ID Protocol" registry group | |||
(https://www.iana.org/assignments/drip). | (https://www.iana.org/assignments/drip). | |||
DRIP SAM Types: | DRIP SAM Types: | |||
This registry is a mirror for SAM Types containing the subset of | This registry is a mirror for SAM Types containing the subset of | |||
allocations used by DRIP Authentication Messages. Future | allocations used by DRIP Authentication Messages. Future | |||
additions MUST be done through ASTM's designated registrar, which | additions MUST be done through ASTM's designated registrar, which | |||
is ICAO [ASTM-Remote-ID] at the time of publication of this RFC. | is ICAO [ASTM-Remote-ID] at the time of publication of this RFC | |||
Additions for DRIP will be coordinated by IANA and the ASTM | (2024). The registration procedure for DRIP (only) SAM Types is | |||
designated registrar before final publication as Standards Track | Standards Action [RFC8126]. Requests for new DRIP SAM Type | |||
RFCs. The following values have been allocated to the IETF: | registrations will be coordinated by IANA and the ASTM-designated | |||
registrar of all SAM Types before being documented in Standards | ||||
Track RFCs. The following values have been allocated to the IETF: | ||||
+==========+===========+=======================================+ | +==========+===========+=======================================+ | |||
| SAM Type | Name | Description | | | SAM Type | Name | Description | | |||
+==========+===========+=======================================+ | +==========+===========+=======================================+ | |||
| 0x01 | DRIP Link | Format to hold Broadcast Endorsements | | | 0x01 | DRIP Link | Format to hold Broadcast Endorsements | | |||
+----------+-----------+---------------------------------------+ | +----------+-----------+---------------------------------------+ | |||
| 0x02 | DRIP | Authenticate full ASTM Messages | | | 0x02 | DRIP | Authenticate full ASTM Messages | | |||
| | Wrapper | | | | | Wrapper | | | |||
+----------+-----------+---------------------------------------+ | +----------+-----------+---------------------------------------+ | |||
| 0x03 | DRIP | Authenticate hashes of ASTM Messages | | | 0x03 | DRIP | Authenticate hashes of ASTM Messages | | |||
skipping to change at line 1458 ¶ | skipping to change at line 1478 ¶ | |||
28 days can be brought to the IESG's attention for resolution. | 28 days can be brought to the IESG's attention for resolution. | |||
9. Security Considerations | 9. Security Considerations | |||
9.1. Replay Attacks | 9.1. Replay Attacks | |||
[F3411] (regardless of transport) lacks replay protection, as it more | [F3411] (regardless of transport) lacks replay protection, as it more | |||
fundamentally lacks fully specified authentication. An attacker can | fundamentally lacks fully specified authentication. An attacker can | |||
spoof the UA sender MAC address and UAS ID, replaying (with or | spoof the UA sender MAC address and UAS ID, replaying (with or | |||
without modification) previous genuine messages, and/or crafting | without modification) previous genuine messages, and/or crafting | |||
entirely new messages. Using DRIP in [F3411] Authentication message | entirely new messages. Using DRIP in [F3411] Authentication Message | |||
framing enables verification that messages were signed with | framing enables verification that messages were signed with | |||
registered keys, but when naively used may be vulnerable to replay | registered keys, but when naively used may be vulnerable to replay | |||
attacks. Technologies such as Single Emitter Identification can | attacks. Technologies such as Single Emitter Identification can | |||
detect such attacks, but they are not readily available and can be | detect such attacks, but they are not readily available and can be | |||
prohibitively expensive, especially for typical Observer devices such | prohibitively expensive, especially for typical Observer devices such | |||
as smartphones. | as smartphones. | |||
Replay attack detection using DRIP requires Observer devices to | Replay attack detection using DRIP requires Observer devices to | |||
combine information from multiple messages and sources other than | combine information from multiple messages and sources other than | |||
Broadcast RID. A complete chain of Link messages (Section 4.2) from | Broadcast RID. A complete chain of Link messages (Section 4.2) from | |||
an Endorsement root of trust to the claimed sender must be collected | an Endorsement root of trust to the claimed sender must be collected | |||
and verified by the Observer device to provide trust in a key. | and verified by the Observer device to provide trust in a key. | |||
Successful signature verification, using that key, of a Wrapper | Successful signature verification, using that public key, of a | |||
(Section 4.3) or Manifest (Section 4.4) message, authenticating | Wrapper (Section 4.3) or Manifest (Section 4.4) message, | |||
content that is nonce-like, provides trust that the sender actually | authenticating content that is nonce-like, provides trust that the | |||
possesses that key. | sender actually possesses the corresponding private key. | |||
The term "nonce-like" means the that data is unique, not accurately | The term "nonce-like" describes data that is unique, changes | |||
predictable long in advance, and readily validated by the Observer. | frequently, is not accurately predictable long in advance, and is | |||
This is described in Section 6.3 (requirement 4) and Section 3.1.2.2. | easily validated (i.e., can be checked quickly at low computational | |||
The Location message [F3411] reporting precise UA position and | cost using readily available data) by the Observer. A Location/ | |||
velocity at a precise and very recent time is to be checked by the | Vector Message is an obvious choice. This is described in | |||
Observer against visual observations of the UA within RF. Thus, | Section 6.3 (requirement 4) and Section 3.1.2.2. The Location/Vector | |||
Visual Line of Sight is typically the recommended form of this data. | Message [F3411] reporting precise UA position and velocity at a | |||
For specification of the foregoing, see Sections 3.1.2 and 6.4.2. | precise and very recent time is to be checked by the Observer against | |||
visual observations of the UA within RF. Thus, Visual Line of Sight | ||||
is typically the recommended form of this data. For specification of | ||||
the foregoing, see Sections 3.1.2 and 6.4.2. | ||||
Messages that pass signature verification with trusted keys could | Messages that pass signature verification with trusted keys could | |||
still be replays if they contain only static information (e.g., | still be replays if they contain only static information (e.g., | |||
Broadcast Endorsements (Section 4.2), [F3411] Basic ID or [F3411] | Broadcast Endorsements (Section 4.2), [F3411] Basic ID or [F3411] | |||
Operator ID), or information that cannot be readily validated (e.g., | Operator ID), or information that cannot be readily validated (e.g., | |||
[F3411] Self-ID). Replay of Link messages is harmless (unless sent | [F3411] Self-ID). Replay of Link messages is harmless (unless sent | |||
so frequently as to cause RF data link congestion) and indeed can | so frequently as to cause RF data link congestion) and indeed can | |||
increase the likelihood of an Observer device collecting an entire | increase the likelihood of an Observer device collecting an entire | |||
trust chain in a short time window. Replay of other messages | trust chain in a short time window. Replay of other messages | |||
([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a | ([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a | |||
vulnerability, unless they are combined with messages containing | vulnerability, unless they are combined with messages containing | |||
nonce-like data ([F3411] Location or [F3411] System) in a Wrapper or | nonce-like data ([F3411] Location/Vector or [F3411] System) in a | |||
Manifest. For specification of this last requirement, see | Wrapper or Manifest. For specification of this last requirement, see | |||
Section 4.4.2. | Section 4.4.2. | |||
9.2. Wrapper vs Manifest | 9.2. Wrapper vs Manifest | |||
Implementations have a choice of using Wrapper (Section 4.3), | Implementations have a choice of using Wrapper (Section 4.3), | |||
Manifest (Section 4.4), or a combination to satisfy the fourth | Manifest (Section 4.4), or a combination to satisfy the fourth | |||
requirement in Section 6.3. | requirement in Section 6.3. | |||
Wrapper is an attached signature of the full content of one or more | Wrapper is an attached signature on the full content of one or more | |||
[F3411] messages, providing strong authentication. However, the size | [F3411] messages, providing strong authentication. Wrapper is an | |||
attached signature of the full content of one or more [F3411] | ||||
messages, providing strong authentication. However, the size | ||||
limitation means it cannot support such signatures over other | limitation means it cannot support such signatures over other | |||
Authentication Messages; thus, it cannot provide a direct binding to | Authentication Messages; thus, it cannot provide a direct binding to | |||
any part of the trust chain (Sections 3.1.2 and 6.4.2). | any part of the trust chain (Sections 3.1.2 and 6.4.2). | |||
Manifest explicitly provides the binding of the last link in the | Manifest explicitly provides the binding of the last link in the | |||
trust chain (with the inclusion of the hash of the Link containing | trust chain (with the inclusion of the hash of the Link containing | |||
BE: HDA, UA). The use of hashes and their length also allows for a | BE: HDA, UA). The use of hashes and their length also allows for a | |||
larger number (11 vs 4) of [F3411] messages to be authenticated, | larger number (11 vs 4) of [F3411] messages to be authenticated, | |||
making it more efficient compared to the Wrapper. However, the | making it more efficient compared to the Wrapper. However, the | |||
detached signature requires additional Observer overhead in storing | detached signature requires additional Observer overhead in storing | |||
and comparing hashes of received messages (some of which may not be | and comparing hashes of received messages (some of which may not be | |||
received) with those in a Manifest. | received) with those in a Manifest. | |||
Appendix B contains a breakdown of frame counts and an example of a | Appendix B contains a breakdown of frame counts and an example of a | |||
schedule using both Manifest and Wrapper. Typical operation may see | schedule using both Manifest and Wrapper. Typical operation may see | |||
(as an example) 2x Basic ID, 2x Location, 2x System, 1x Operator ID | (as an example) 2x Basic ID, 2x Location/Vector, 2x System, 1x | |||
and 1x Self ID broadcast per second to comply with jurisdiction | Operator ID and 1x Self ID broadcast per second to comply with | |||
mandates. Each of these messages is a single frame in size. A Link | jurisdiction mandates. Each of these messages is a single frame in | |||
message is 8 frames long (including FEC). This is a base frame count | size. A Link message is 8 frames long (including FEC). This is a | |||
of *16 frames*. | base frame count of *16 frames*. | |||
When Wrapper is used, up to four of the previous messages (except the | When Wrapper is used, up to four of the previous messages (except the | |||
Link) can be authenticated. For this comparison, we will sign all | Link) can be authenticated. For this comparison, we will sign all | |||
the messages we can in two Wrappers. This results in _20 frames_ | the messages we can in two Wrappers. This results in _20 frames_ | |||
(with FEC). Due to size constraints, the Link message is left | (with FEC). Due to size constraints, the Link message is left | |||
unauthenticated. The total frame count using Wrappers is *36 frames* | unauthenticated. The total frame count using Wrappers is *36 frames* | |||
(wrapper frame count + base frame count). | (wrapper frame count + base frame count). | |||
When Manifest is used, up to 10 previous messages can be | When Manifest is used, up to 10 previous messages can be | |||
authenticated. For this example, all messages (8) are hashed | authenticated. For this example, all messages (8) are hashed | |||
skipping to change at line 1560 ¶ | skipping to change at line 1585 ¶ | |||
consideration for any implementation. The offset should be shorter | consideration for any implementation. The offset should be shorter | |||
than any given flight duration (typically less than an hour) but be | than any given flight duration (typically less than an hour) but be | |||
long enough to be received and processed by Observers (larger than a | long enough to be received and processed by Observers (larger than a | |||
few seconds). It is recommended that 3-5 minutes should be | few seconds). It is recommended that 3-5 minutes should be | |||
sufficient to serve this purpose in any scenario, but it is not | sufficient to serve this purpose in any scenario, but it is not | |||
limited by design. | limited by design. | |||
9.4. DNS Security in DRIP | 9.4. DNS Security in DRIP | |||
As stated in Section 3.1 specification of particular DNS security | As stated in Section 3.1 specification of particular DNS security | |||
options, transports, etc. is outside the scope of this document. | options, transports, etc. is outside the scope of this document. The | |||
[DRIP-REG] is the main specification for DNS operations in DRIP and | main specification for DNS operations in DRIP [DRIP-REG] will specify | |||
as such will specify DRIP usage of best common practices for security | applicable best common security practices (e.g., from [RFC9364]). | |||
(such as [RFC9364]). | ||||
11. References | 10. References | |||
11.1. Normative References | 10.1. Normative References | |||
[F3411] ASTM International, "Standard Specification for Remote ID | [F3411] ASTM International, "Standard Specification for Remote ID | |||
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July | and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July | |||
2022, <https://www.astm.org/f3411-22a.html>. | 2022, <https://www.astm.org/f3411-22a.html>. | |||
[NIST.SP.800-185] | [NIST.SP.800-185] | |||
Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived | Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived | |||
Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST | Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST | |||
Special Publication 800-185, DOI 10.6028/NIST.SP.800-185, | Special Publication 800-185, DOI 10.6028/NIST.SP.800-185, | |||
December 2016, | December 2016, | |||
skipping to change at line 1606 ¶ | skipping to change at line 1630 ¶ | |||
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, | [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, | |||
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote | "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote | |||
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, | ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, | |||
<https://www.rfc-editor.org/info/rfc9374>. | <https://www.rfc-editor.org/info/rfc9374>. | |||
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., | [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., | |||
and A. Gurtov, "Drone Remote Identification Protocol | and A. Gurtov, "Drone Remote Identification Protocol | |||
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July | (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July | |||
2023, <https://www.rfc-editor.org/info/rfc9434>. | 2023, <https://www.rfc-editor.org/info/rfc9434>. | |||
11.2. Informative References | 10.2. Informative References | |||
[ASTM-Remote-ID] | [ASTM-Remote-ID] | |||
International Civil Aviation Organization (ICAO), "Remote | International Civil Aviation Organization (ICAO), "Remote | |||
ID Number Registration", December 2023, | ID Number Registration", December 2023, | |||
<https://www.icao.int/airnavigation/IATF/Pages/ASTM- | <https://www.icao.int/airnavigation/IATF/Pages/ASTM- | |||
Remote-ID.aspx>. | Remote-ID.aspx>. | |||
[DRIP-REG] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) | [DRIP-REG] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) | |||
Identity Management Architecture", Work in Progress, | Identity Management Architecture", Work in Progress, | |||
Internet-Draft, draft-ietf-drip-registries-15, 1 April | Internet-Draft, draft-ietf-drip-registries-15, 1 April | |||
skipping to change at line 1645 ¶ | skipping to change at line 1669 ¶ | |||
Appendix A. Authentication States | Appendix A. Authentication States | |||
ASTM Authentication has only three states: None, Invalid, and Valid. | ASTM Authentication has only three states: None, Invalid, and Valid. | |||
This is because, under ASTM, the authentication is done by an | This is because, under ASTM, the authentication is done by an | |||
external service hosted somewhere on the Internet so it is assumed an | external service hosted somewhere on the Internet so it is assumed an | |||
authoritative response will always be returned. This classification | authoritative response will always be returned. This classification | |||
becomes more complex in DRIP with the support of "offline" scenarios | becomes more complex in DRIP with the support of "offline" scenarios | |||
where an Observer does not have Internet connectivity. With the use | where an Observer does not have Internet connectivity. With the use | |||
of asymmetric cryptography, this means that the public key (PK) must | of asymmetric cryptography, this means that the public key (PK) must | |||
somehow be obtained. [DRIP-REG] provides more detail on how these | somehow be obtained. [DRIP-REG] provides more detail on how these | |||
keys are stored on the DNS and how DRIP Authentication messages can | keys are stored on the DNS and how DRIP Authentication Messages can | |||
be used to send PK's over Broadcast RID. | be used to send PK's over Broadcast RID. | |||
There are a few keys of interest: the PK of the UA and the PKs of | There are a few keys of interest: the PK of the UA and the PKs of | |||
relevant DIMEs. This document describes how to send the PK of the UA | relevant DIMEs. This document describes how to send the PK of the UA | |||
over the Broadcast RID messages. The keys of DIMEs are sent over | over the Broadcast RID messages. The keys of DIMEs are sent over | |||
Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3) | Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3) | |||
but MAY be sent at a far lower rate due to potential operational | but MAY be sent at a far lower rate due to potential operational | |||
constraints (such as saturation of limited bandwidth). As such, | constraints (such as saturation of limited bandwidth). As such, | |||
there are scenarios where part of the key-chain may be unavailable at | there are scenarios where part of the key-chain may be unavailable at | |||
the moment a full Authentication Message is received and processed. | the moment a full Authentication Message is received and processed. | |||
The intent of this informative appendix is to recommend a way to | The intent of this informative appendix is to recommend a way to | |||
classify these various states and convey it to the user through | classify these various states and convey it to the user through | |||
colors and state names/text. These states can apply to either a | colors and state names/text. These states can apply to either a | |||
single authentication message, a DET (and its associated public key), | single Authentication Message, a DET (and its associated public key), | |||
and/or a sender. | and/or a sender. | |||
The table below lays out the recommended colors to associate with | The table below briefly describes each state and recommends an | |||
state and a brief description of each. | associated color. | |||
+==============+========+===================================+ | +==============+========+===================================+ | |||
| State | Color | Details | | | State | Color | Details | | |||
+==============+========+===================================+ | +==============+========+===================================+ | |||
| None | Black | No Authentication being received | | | None | Black | No Authentication has been or is | | |||
| | | (as yet) | | | | | being received (as yet) | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Partial | Gray | Authentication being received but | | | Partial | Gray | Authentication being received but | | |||
| | | missing pages | | | | | missing pages | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Unsupported | Brown | Authentication Type / SAM Type of | | | Unsupported | Brown | Authentication Type / SAM Type of | | |||
| | | received message not supported | | | | | received message not supported | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Unverifiable | Yellow | Data needed for signature | | | Unverifiable | Yellow | Data needed for signature | | |||
| | | verification is missing | | | | | verification is missing | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
skipping to change at line 1704 ¶ | skipping to change at line 1728 ¶ | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Conflicting | Purple | Evidence of both Trusted and | | | Conflicting | Purple | Evidence of both Trusted and | | |||
| | | Unverified for the same claimed | | | | | Unverified for the same claimed | | |||
| | | sender | | | | | sender | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
Table 4: Authentication State Names, Colors, and Descriptions | Table 4: Authentication State Names, Colors, and Descriptions | |||
A.1. None: Black | A.1. None: Black | |||
The default state where no authentication information has been | The default state where authentication information has not yet been | |||
received. | received and is not currently being received. | |||
A.2. Partial: Gray | A.2. Partial: Gray | |||
A pending state where authentication pages are being received, but a | A pending state where authentication pages are being received, but a | |||
full authentication message has yet to be compiled. | full Authentication Message has yet to be compiled. | |||
A.3. Unsupported: Brown | A.3. Unsupported: Brown | |||
A state wherein authentication data is being or has been received but | A state wherein authentication data is being or has been received but | |||
cannot be used, as the Authentication Type or SAM Type is not | cannot be used, as the Authentication Type or SAM Type is not | |||
supported by the Observer. | supported by the Observer. | |||
A.4. Unverifiable: Yellow | A.4. Unverifiable: Yellow | |||
A pending state where a full authentication message has been received | A pending state where a full Authentication Message has been received | |||
but other information, such as public keys to verify signatures, is | but other information, such as public keys to verify signatures, is | |||
missing. | missing. | |||
A.5. Verified: Green | A.5. Verified: Green | |||
A state where all authentication messages that have been received | A state where all Authentication Messages that have been received | |||
from that claimed sender up to that point pass signature verification | from that claimed sender up to that point pass signature verification | |||
and the requirement of Section 6.4.2 has been met. | and the requirement of Section 6.4.2 has been met. | |||
A.6. Trusted: Blue | A.6. Trusted: Blue | |||
A state where all authentication messages that have been received | A state where all Authentication Messages that have been received | |||
from that claimed sender up to that point have passed signature | from that claimed sender up to that point have passed signature | |||
verification, the requirement of Section 6.4.2 has been met, and the | verification, the requirement of Section 6.4.2 has been met, and the | |||
public key of the sending UA has been marked as trusted. | public key of the sending UA has been marked as trusted. | |||
The sending UA key will have been marked as trusted if the relevant | The sending UA key will have been marked as trusted if the relevant | |||
DIMEs only register DETs (of subordinate DIMEs, UAS operators, and | DIMEs only register DETs (of subordinate DIMEs, UAS operators, and | |||
UA) that have been vetted as per their published registration | UA) that have been vetted as per their published registration | |||
policies, and those DIMEs have been marked, by the owner (individual | policies, and those DIMEs have been marked, by the owner (individual | |||
or organizational) of the Observer, as per that owner's policy, as | or organizational) of the Observer, as per that owner's policy, as | |||
trusted to register DETs only for trusted parties. | trusted to register DETs only for trusted parties. | |||
A.7. Questionable: Orange | A.7. Questionable: Orange | |||
A state where there is a mix of authentication messages received that | A state where there is a mix of Authentication Messages received that | |||
are Verified (Appendix A.5) and Unverified (Appendix A.8). | are Verified (Appendix A.5) and Unverified (Appendix A.8). | |||
State transitions from Verified to Questionable if a subsequent | State transitions from Verified to Questionable if a subsequent | |||
message fails verification, so it would have otherwise been marked | message fails verification, so it would have otherwise been marked | |||
Unverified. State transitions from Unverified to Questionable if a | Unverified. State transitions from Unverified to Questionable if a | |||
subsequent message passes verification or validation, so it would | subsequent message passes verification or validation, so it would | |||
otherwise have been marked Verified. It may transition from either | otherwise have been marked Verified. It may transition from either | |||
of those states upon mixed results on the requirement of | of those states upon mixed results on the requirement of | |||
Section 6.4.2. | Section 6.4.2. | |||
A.8. Unverified: Red | A.8. Unverified: Red | |||
A state where all authentication messages that have been received | A state where all Authentication Messages that have been received | |||
from that claimed sender up to that point failed signature | from that claimed sender up to that point failed signature | |||
verification or the requirement of Section 6.4.2. | verification or the requirement of Section 6.4.2. | |||
A.9. Conflicting: Purple | A.9. Conflicting: Purple | |||
A state where there is a mix of authentication messages received that | A state where there is a mix of Authentication Messages received that | |||
are Trusted (Appendix A.6) and Unverified (Appendix A.8) and the | are Trusted (Appendix A.6) and Unverified (Appendix A.8) and the | |||
public key of the aircraft is marked as trusted. | public key of the aircraft is marked as trusted. | |||
State transitions from Trusted to Conflicting if a subsequent message | State transitions from Trusted to Conflicting if a subsequent message | |||
fails verification, so it would have otherwise been marked | fails verification, so it would have otherwise been marked | |||
Unverified. State transitions from Unverified to Conflicting if a | Unverified. State transitions from Unverified to Conflicting if a | |||
subsequent message passes verification or validation and policy | subsequent message passes verification or validation and policy | |||
checks, so it would otherwise have been marked Trusted. It may | checks, so it would otherwise have been marked Trusted. It may | |||
transition from either of those states upon mixed results on the | transition from either of those states upon mixed results on the | |||
requirement of Section 6.4.2. | requirement of Section 6.4.2. | |||
Appendix B. Operational Recommendation Analysis | Appendix B. Operational Recommendation Analysis | |||
The recommendations in Section 6.4 may seem heavy-handed and | The recommendations in Section 6.4 may seem heavy-handed and | |||
specific. This informative appendix lays out the math and | specific. This informative appendix lays out the math and | |||
assumptions made that resulted in those recommendations and provides | assumptions made that resulted in those recommendations and provides | |||
an example. | an example. | |||
In many jurisdictions, the required ASTM Messages to be transmitted | In many jurisdictions, the required ASTM Messages to be transmitted | |||
every second are: Basic ID (0x1), Location (0x2), and System (0x4). | every second are: Basic ID (0x0), Location/Vector (0x1), and System | |||
Typical implementations will most likely send at a higher rate (2x | (0x4). Typical implementations will most likely send at a higher | |||
sets per cycle) resulting in 6 frames sent per cycle. Transmitting | rate (2x sets per cycle) resulting in 6 frames sent per cycle. | |||
this set of messages more than once a second is not discouraged, but | Transmitting this set of messages more than once a second is not | |||
awareness is needed to avoid congesting the RF spectrum, causing | discouraged, but awareness is needed to avoid congesting the RF | |||
further issues. | spectrum, causing further issues. | |||
Informational Note: In Europe, the Operator ID Message (0x5) is also | Informational Note: In Europe, the Operator ID Message (0x5) is also | |||
required. In Japan, two Basic ID (0x0), Location (0x1), and | required. In Japan, two Basic ID (0x0), Location/Vector (0x1), and | |||
Authentication (0x2) are required. Self ID (0x3) is optional but can | Authentication (0x2) are required. Self ID (0x3) is optional but can | |||
carry Emergency Status information. | carry Emergency Status information. | |||
B.1. Page Counts vs Frame Counts | B.1. Page Counts vs Frame Counts | |||
There are two formulas to determine the number of Authentication | There are two formulas to determine the number of Authentication | |||
Pages required. The following formula is for Wrapper: | Pages required. The following formula is for Wrapper: | |||
<CODE BEGINS> | <CODE BEGINS> | |||
wrapper_struct_size = 89 + (25 * num_astm_messages) | wrapper_struct_size = 89 + (25 * num_astm_messages) | |||
skipping to change at line 1874 ¶ | skipping to change at line 1898 ¶ | |||
five slots; thus it can authenticate up to four ASTM Messages co- | five slots; thus it can authenticate up to four ASTM Messages co- | |||
located in the same Message Pack. | located in the same Message Pack. | |||
B.1.1.2. Eleven ASTM Messages | B.1.1.2. Eleven ASTM Messages | |||
Eleven ASTM Messages (see Table 5) is where a Manifest with FEC | Eleven ASTM Messages (see Table 5) is where a Manifest with FEC | |||
invokes the situation mentioned in Section 5.3. | invokes the situation mentioned in Section 5.3. | |||
Eleven is the maximum number of ASTM Message Hashes that can be | Eleven is the maximum number of ASTM Message Hashes that can be | |||
supported resulting in 14 total hashes. This completely fills the | supported resulting in 14 total hashes. This completely fills the | |||
evidence section of the structure making its total size 200 octets. | Evidence field of the UA-Signed Evidence Structure making its total | |||
This fits on exactly 9 Authentication Pages ((201 - 17) / 23 == 8), | size 200 octets. This fits on exactly 9 Authentication Pages ((201 - | |||
so when the ADL is added, it is placed on the next page (Page 10). | 17) / 23 == 8), so when the ADL is added, it is placed on the next | |||
Per rule 1 in Section 5.1, this means that all of Page 10 is null | page (Page 10). Per rule 1 in Section 5.1, this means that all of | |||
padded (expect the ADL octet) and FEC data fills Page 11, resulting | Page 10 is null padded (expect the ADL octet) and FEC data fills Page | |||
in a plus-two page count when FEC is applied. | 11, resulting in a plus-two page count when FEC is applied. | |||
This drives the recommendation is Section 4.4 to only use up to 10 | This drives the recommendation is Section 4.4 to only use up to 10 | |||
ASTM Message Hashes, not 11. | ASTM Message Hashes, not 11. | |||
B.2. Full Authentication Example | B.2. Full Authentication Example | |||
This example is focused on showing that 100% of ASTM Messages can be | This example is focused on showing that 100% of ASTM Messages can be | |||
authenticated over Legacy Transports with up to 125% overhead in | authenticated over Legacy Transports with up to 125% overhead in | |||
Authentication Pages. Extended Transport is not shown as | Authentication Pages. Extended Transports are not shown in this | |||
Authentication with DRIP in that case is covered using Extended | example, because, for those, Authentication with DRIP is achieved | |||
Wrapper (Section 4.3.2). Two ASTM Message Packs are sent in a given | using Extended Wrapper (Section 4.3.2). Two ASTM Message Packs are | |||
cycle: one containing up to four ASTM Messages and an Extended | sent in a given cycle: one containing up to four ASTM Messages and an | |||
Wrapper (authenticating the pack), and one containing a Link message | Extended Wrapper (authenticating the pack), and one containing a Link | |||
with a Broadcast Endorsement and up to two other ASTM Messages. | message with a Broadcast Endorsement and up to two other ASTM | |||
Messages. | ||||
This example transmit scheme covers and meets every known regulatory | This example transmit scheme covers and meets every known regulatory | |||
case enabling manufacturers to use the same firmware worldwide. | case enabling manufacturers to use the same firmware worldwide. | |||
+------------------------------------------------------+ | +------------------------------------------------------+ | |||
| Frame Slots | | | Frame Slots | | |||
| 00 - 04 | 05 - 07 | 08 - 16 | 17 | | | 00 - 04 | 05 - 07 | 08 - 16 | 17 | | |||
+-------------------+---------------+---------+--------+ | +-------------------+---------------+---------+--------+ | |||
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] | | | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] | | |||
+-------------------+---------------+---------+--------+ | +-------------------+---------------+---------+--------+ | |||
skipping to change at line 1940 ¶ | skipping to change at line 1965 ¶ | |||
M[y,z] = DRIP Manifest Authentication Message (0x2) | M[y,z] = DRIP Manifest Authentication Message (0x2) | |||
y = Start Page | y = Start Page | |||
z = End Page | z = End Page | |||
# = Empty Frame Slot | # = Empty Frame Slot | |||
* = Message in DRIP Manifest Authentication Message | * = Message in DRIP Manifest Authentication Message | |||
Figure 13: Example of a Fully Authenticated Legacy Transport | Figure 13: Example of a Fully Authenticated Legacy Transport | |||
Transmit Schedule | Transmit Schedule | |||
Every common required message (Basic ID, Location, and System) is | Every common required message (Basic ID, Location/Vector, and System) | |||
sent twice along with Operator ID and Self ID in a single second. | is sent twice along with Operator ID and Self ID in a single second. | |||
The Manifest is over all messages (8) in slots 00 - 04 and 05 - 07. | The Manifest is over all messages (8) in slots 00 - 04 and 05 - 07. | |||
In two seconds, either a Link or Wrapper are sent. The content and | In two seconds, either a Link or Wrapper is sent. The content and | |||
order of Links and Wrappers runs as follows: | order of Links and Wrappers runs as follows: | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: Apex on RAA | Link: Apex on RAA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Wrapper: Location (0x1), System (0x4) | Wrapper: Location/Vector (0x1), System (0x4) | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: Apex on RAA | Link: Apex on RAA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Wrapper: Location (0x1), System (0x4) | Wrapper: Location/Vector (0x1), System (0x4) | |||
Link: IANA on UAS RID Apex | Link: IANA on UAS RID Apex | |||
With perfect receipt of all messages, all messages (up to that point | After perfect receipt of all messages for a period of 8 seconds, all | |||
then all in future) are authenticated within 8 seconds using the | messages sent during that period have been authenticated using the | |||
Manifest. Within 136 seconds, the entire Broadcast Endorsement chain | Manifest (except for the Authentication Messages themselves). Within | |||
is received and can be validated; interspersed with four messages | 136 seconds, the entire Broadcast Endorsement chain is received and | |||
directly signed over via Wrapper. | can be validated. Interspersed in this schedule are 4 messages sent | |||
not only in their basic [F3411] form, but also in DRIP Wrapper | ||||
messages, together with their attached signatures, to defend against | ||||
the possibility of attack against the detached signatures provided by | ||||
the Manifest messages. | ||||
B.2.1. Raw Example | B.2.1. Raw Example | |||
Assuming the following DET and HI: | Assuming the following DET and HI: | |||
2001:3f:fe00:105:a29b:3ff4:2226:c04e | 2001:3f:fe00:105:a29b:3ff4:2226:c04e | |||
b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813 | b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813 | |||
The following ASTM Messages are to be sent in a single second: | The following ASTM Messages are to be sent in a single second: | |||
skipping to change at line 2024 ¶ | skipping to change at line 2053 ¶ | |||
225008b110ea510903e0dd7c6560115e670000000000000000 | 225008b110ea510903e0dd7c6560115e670000000000000000 | |||
2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01 | 2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01 | |||
22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928 | 22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928 | |||
22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3 | 22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3 | |||
2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4 | 2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4 | |||
22552226c04efb729846e7d110903797066fd96f49a77c5a48 | 22552226c04efb729846e7d110903797066fd96f49a77c5a48 | |||
2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2 | 2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2 | |||
22579ed2dce2769120da83edbcdc0858dd1e357755e7860317 | 22579ed2dce2769120da83edbcdc0858dd1e357755e7860317 | |||
2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83 | 2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83 | |||
10. Acknowledgments | Acknowledgments | |||
The authors acknowledge the following individuals: | ||||
* Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize, | * Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize, | |||
LLC for early prototyping to find holes in earlier drafts of this | LLC for early prototyping to find holes in earlier drafts of this | |||
specification | specification. | |||
* Carsten Bormann for the simple approach of using bit-column-wise | * Carsten Bormann for the simple approach of using bit-column-wise | |||
parity for erasure (dropped frame) FEC | parity for erasure (dropped frame) FEC. | |||
* Soren Friis for pointing out that Wi-Fi implementations would not | * Soren Friis for pointing out that Wi-Fi implementations would not | |||
always give access to the MAC Address, as was originally used in | always give access to the MAC Address, as was originally used in | |||
calculation of the hashes for DRIP Manifest. Also, for confirming | calculation of the hashes for DRIP Manifest. Also, for confirming | |||
that Message Packs (0xF) can only carry up to 9 ASTM frames worth | that Message Packs (0xF) can only carry up to 9 ASTM frames worth | |||
of data (9 Authentication pages) | of data (9 Authentication pages) | |||
* Gabriel Cox (chair of the working group that produced [F3411]) for | * Gabriel Cox (chair of the working group that produced [F3411]) for | |||
reviewing the specification for the SAM Type request as the ASTM | reviewing the specification for the SAM Type request as the ASTM | |||
Designated Expert | Designated Expert. | |||
* Mohamed Boucadair (Document Shepherd) for his many patches and | * Mohamed Boucadair (Document Shepherd) for his many patches and | |||
comments | comments. | |||
* Eric Vyncke (DRIP AD) for his guidance regarding the document's | * Eric Vyncke (DRIP AD) for his guidance regarding the document's | |||
path to publication | path to publication. | |||
* Thanks to the following reviewers: | The authors also thank the following reviewers: | |||
- Rick Salz (secdir) | * Rick Salz (secdir) | |||
- Matt Joras (genart) | * Matt Joras (genart) | |||
- Di Ma (dnsdir) | * Di Ma (dnsdir) | |||
- Gorry Fairhurst (tsvart) | * Gorry Fairhurst (tsvart) | |||
- Carlos Bernardos (intdir) | * Carlos Bernardos (intdir) | |||
- Behcet Sarikaya (iotdir) | * Behcet Sarikaya (iotdir) | |||
- Martin Duke (IESG) | * Martin Duke (IESG) | |||
- Roman Danyliw (IESG) | * Roman Danyliw (IESG) | |||
- Murray Kucherawy (IESG) | * Murray Kucherawy (IESG) | |||
- Erik Kline (IESG) | * Erik Kline (IESG) | |||
- Warren Kumari (IESG) | * Warren Kumari (IESG) | |||
- Paul Wouters (IESG) | * Paul Wouters (IESG) | |||
Authors' Addresses | Authors' Addresses | |||
Adam Wiethuechter (editor) | Adam Wiethuechter (editor) | |||
AX Enterprize, LLC | AX Enterprize, LLC | |||
4947 Commercial Drive | 4947 Commercial Drive | |||
Yorkville, NY 13495 | Yorkville, NY 13495 | |||
United States of America | United States of America | |||
Email: adam.wiethuechter@axenterprize.com | Email: adam.wiethuechter@axenterprize.com | |||
End of changes. 88 change blocks. | ||||
192 lines changed or deleted | 223 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |