rfc9575v2.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 | |||
May 2024 | May 2024 | |||
DRIP Entity Tag Authentication Formats and Protocols for Broadcast | DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast | |||
Remote Identification | Remote Identification (RID) | |||
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 | |||
UAS, even by Observers lacking Internet access. This document | UAS, even by Observers lacking Internet access. This document | |||
defines DRIP message types and formats to be sent in Broadcast RID | defines DRIP message types and formats to be sent in Broadcast RID | |||
Authentication Messages to verify that attached and recently detached | Authentication Messages to verify that attached and recently detached | |||
skipping to change at line 68 ¶ | skipping to change at line 68 ¶ | |||
2. Terminology | 2. Terminology | |||
2.1. Required Terminology | 2.1. Required Terminology | |||
2.2. Definitions | 2.2. Definitions | |||
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. SAM Data Format | |||
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 | |||
skipping to change at line 182 ¶ | skipping to change at line 182 ¶ | |||
Administration (FAA) [FAA-14CFR], which is missing from [F3411] over | Administration (FAA) [FAA-14CFR], which is missing from [F3411] over | |||
Legacy Transports (Bluetooth 4.x). | Legacy Transports (Bluetooth 4.x). | |||
These DRIP enhancements to ASTM's specification for RID and tracking | These DRIP enhancements to ASTM's specification for RID and tracking | |||
[F3411] further support the important use case of Observers who may | [F3411] further support the important use case of Observers who may | |||
be offline at the time of observation. | be offline at the time of observation. | |||
Section 7 summarizes the DRIP requirements [RFC9153] addressed | Section 7 summarizes the DRIP requirements [RFC9153] addressed | |||
herein. | herein. | |||
Note: The Endorsement (used in Section 4.2) that proves that a DET is | ||||
registered MUST come from its immediate parent in the registration | ||||
hierarchy, e.g., a DRIP Identity Management Entity (DIME) [DRIP-REG]. | ||||
In the definitive hierarchy, the parent of the UA is its HHIT Domain | ||||
Authority (HDA), the parent of an HDA is its Registered Assigning | ||||
Authority (RAA), etc. It is also assumed that all DRIP-aware | ||||
entities use a DET as their identifier during interactions with other | ||||
DRIP-aware entities. | ||||
2. Terminology | 2. Terminology | |||
2.1. Required Terminology | 2.1. Required Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
skipping to change at line 221 ¶ | skipping to change at line 212 ¶ | |||
802.11 Beacons with the vendor-specific information element as | 802.11 Beacons with the vendor-specific information element as | |||
specified in [F3411]. Must use ASTM Message Pack (Message Type | specified in [F3411]. Must use ASTM Message Pack (Message Type | |||
0xF). | 0xF). | |||
Legacy Transports: Use of broadcast frames (Bluetooth 4.x) as | Legacy Transports: Use of broadcast frames (Bluetooth 4.x) as | |||
specified in [F3411]. | specified in [F3411]. | |||
Manifest: An immutable list of items being transported (in this | Manifest: An immutable list of items being transported (in this | |||
specific case over wireless communication). | specific case over wireless communication). | |||
Note: For the remainder of this document, Broadcast Endorsement: | ||||
Parent, Child will be abbreviated as BE: Parent, Child. For example, | ||||
Broadcast Endorsement: RAA, HDA will be abbreviated as BE: RAA, HDA. | ||||
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 | |||
skipping to change at line 303 ¶ | skipping to change at line 298 ¶ | |||
trust assessment (Section 6.4.2). | trust assessment (Section 6.4.2). | |||
3.1.2.1. DIME Endorsements of Subordinate DETs | 3.1.2.1. DIME Endorsements of Subordinate DETs | |||
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: | ||||
Parent, Child will be abbreviated as BE: Parent, Child. For example, | ||||
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 sign and send data that is unique and unpredictable but | UA MUST sign and send data that is unique and unpredictable but | |||
easily validated by the Observer. The data can be an ASTM Message | easily validated by the Observer. The data can be an ASTM Message | |||
that fulfills the requirements to be unpredictable but easily | that fulfills the requirements to be unpredictable but easily | |||
validated. An Observer receives this UA-signed Evidence from DRIP- | validated. An Observer receives this UA-signed Evidence from 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 | |||
skipping to change at line 329 ¶ | skipping to change at line 320 ¶ | |||
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 | |||
than the Legacy Transport size but is limited for use only on | | larger than the Legacy Transport size but is limited for use | |||
Extended Transports where it can be supported. | | only on 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_. | Type is encoded in every Authentication Page in the _Page Header_. | |||
The SAM Type is defined as a field in the _Authentication Payload_ | The SAM Type is defined as a field in the _Authentication Payload_ | |||
(see Section 3.2.3.1). | (see Section 3.2.3). | |||
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 | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 1: Standard ASTM Authentication Message Page | Figure 1: Standard ASTM Authentication Message Page | |||
Page Header: (1 octet) | _Page Header_: (1 octet) | |||
Authentication Type (4 bits) and Page Number (4 bits) | Authentication Type (4 bits) and Page Number (4 bits) | |||
Authentication Payload: (23 octets per page) | _Authentication Payload_: (23 octets per page) | |||
Authentication Payload, including headers. Null padded. See | Authentication Payload, including headers. Null padded. See | |||
Section 3.2.2. | Section 3.2.2. | |||
The Authentication Message is structured as a set of pages per | The Authentication Message is structured as a set of pages per | |||
Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15) | Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15) | |||
that can be sent for a single Authentication Message, with each page | that can be sent for a single Authentication Message, with each page | |||
carrying a maximum 23-octet Authentication Payload. See | carrying a maximum 23-octet _Authentication Payload_. See | |||
Section 3.2.4 for more details. Over Legacy Transports, these | Section 3.2.4 for more details. Over Legacy Transports, these | |||
messages are "fragmented", with each page sent in a separate Legacy | messages are "fragmented", with each page sent in a separate Legacy | |||
Transport frame. | Transport frame. | |||
Either as a single Authentication Message or a set of fragmented | Either as a single Authentication Message or a set of fragmented | |||
Authentication Message Pages, the structure is further wrapped by | Authentication Message Pages, the structure is further wrapped by | |||
outer ASTM framing and the specific link framing. | outer ASTM framing and the specific link framing. | |||
3.2.2. Authentication Payload Field | 3.2.2. Authentication Payload Field | |||
Figure 2 is the source data view of the data fields found in the | Figure 2 is the source data view of the data fields found in the | |||
Authentication Message as defined by [F3411]. This data is placed | Authentication Message as defined by [F3411]. This data is placed | |||
into the Authentication Payload shown in Figure 1, which spans | into the _Authentication Payload_ shown in Figure 1, which spans | |||
multiple Authentication Pages. | multiple _Authentication Pages_. | |||
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 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Authentication Headers | | | Authentication Headers | | |||
| +---------------+---------------+ | | +---------------+---------------+ | |||
| | | | | | | | |||
+---------------+---------------+ | | +---------------+---------------+ | | |||
. . | . . | |||
. Authentication Data / Signature . | . Authentication Data / Signature . | |||
skipping to change at line 411 ¶ | skipping to change at line 402 ¶ | |||
| ADL | | | | ADL | | | |||
+---------------+ | | +---------------+ | | |||
. . | . . | |||
. Additional Data . | . Additional Data . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 2: ASTM Authentication Message Fields | Figure 2: ASTM Authentication Message Fields | |||
Authentication Headers: (6 octets) | _Authentication Headers_: (6 octets) | |||
As defined in [F3411]. | As defined in [F3411]. | |||
Authentication Data / Signature: (0 to 255 octets) | _Authentication Data / Signature_: (0 to 255 octets) | |||
Opaque authentication data. The length of this payload is known | Opaque authentication data. The length of this payload is known | |||
through a field in the Authentication Headers (defined in | through a field in the _Authentication Headers_ (defined in | |||
[F3411]). | [F3411]). | |||
Additional Data Length (ADL): (1 octet - unsigned) | _Additional Data Length (ADL)_: (1 octet - unsigned) | |||
Length in octets of Additional Data. The value of ADL is | Length in octets of _Additional Data_. The value of _ADL_ is | |||
calculated as the minimum of 361 - Authentication Data / Signature | calculated as the minimum of 361 - Authentication Data / Signature | |||
Length and 255. Only present with Additional Data. | Length and 255. Only present with _Additional Data_. | |||
Additional Data: (ADL octets) | _Additional Data:_ (_ADL_ octets) | |||
Data that follows the Authentication Data / Signature but is not | Data that follows the _Authentication Data / Signature_ but is not | |||
considered part of the Authentication Data, and thus is not | considered part of the _Authentication Data_, and thus is not | |||
covered by a signature. For DRIP, this field is used to carry | covered by a signature. For DRIP, this field is used to carry | |||
Forward Error Correction (FEC) generated by transmitters and | Forward Error Correction (FEC) generated by transmitters and | |||
parsed by receivers as defined in Section 5. | parsed by receivers as defined in Section 5. | |||
3.2.3. Specific Authentication Method (SAM) | 3.2.3. SAM Data Format | |||
3.2.3.1. SAM Data Format | ||||
Figure 3 is the general format to hold authentication data when using | Figure 3 is the general format to hold authentication data when using | |||
SAM and is placed inside the Authentication Data / Signature field in | SAM and is placed inside the _Authentication Data / Signature_ field | |||
Figure 2. | in Figure 2. | |||
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 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| SAM Type | | | | SAM Type | | | |||
+---------------+ | | +---------------+ | | |||
. . | . . | |||
. SAM Authentication Data . | . SAM Authentication Data . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 3: SAM Data Format | Figure 3: SAM Data Format | |||
SAM Type: (1 octet) | _SAM Type_: (1 octet) | |||
The following SAM Types are allocated to DRIP: | The following SAM Types are allocated to DRIP: | |||
+==========+=============================+ | +==========+=============================+ | |||
| SAM Type | Description | | | SAM Type | Description | | |||
+==========+=============================+ | +==========+=============================+ | |||
| 0x01 | DRIP Link (Section 4.2) | | | 0x01 | DRIP Link (Section 4.2) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
| 0x02 | DRIP Wrapper (Section 4.3) | | | 0x02 | DRIP Wrapper (Section 4.3) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
| 0x03 | DRIP Manifest (Section 4.4) | | | 0x03 | DRIP Manifest (Section 4.4) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
| 0x04 | DRIP Frame (Section 4.5) | | | 0x04 | DRIP Frame (Section 4.5) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
Table 1: DRIP SAM Types | Table 1: DRIP SAM Types | |||
Note: ASTM International is the owner of these code points as they | | Note: ASTM International is the owner of these code points as | |||
are defined in [F3411]. In accordance with Annex 5 of [F3411], the | | they are defined in [F3411]. In accordance with Annex 5 of | |||
International Civil Aviation Organization (ICAO) has been selected by | | [F3411], the International Civil Aviation Organization (ICAO) | |||
ASTM as the registrar to manage allocations of these code points. | | has been selected by ASTM as the registrar to manage | |||
The list is available at [ASTM-Remote-ID]. | | allocations of these code points. The list is available at | |||
| [ASTM-Remote-ID]. | ||||
SAM Authentication Data: (0 to 200 octets) | _SAM Authentication Data_: (0 to 200 octets) | |||
Contains opaque authentication data formatted as defined by the | Contains opaque authentication data formatted as defined by the | |||
preceding SAM Type. | preceding SAM Type. | |||
3.2.4. ASTM Broadcast RID Constraints | 3.2.4. ASTM Broadcast RID Constraints | |||
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 uses (display, report, etc.) the latest data regardless of the | SHOULD use (display, report, etc.) the latest data regardless of the | |||
transport over which that data was received. | 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. As [F3411] message formats are | support larger payloads per frame. As [F3411] message formats are | |||
the same for all media, and their framing was designed to fit within | the same for all media, and their framing was designed to fit within | |||
these legacy constraints, Extended Transports cannot send larger | these legacy constraints, Extended Transports cannot send larger | |||
messages; instead, the Message Pack format encapsulates multiple | messages; instead, the Message Pack format encapsulates multiple | |||
messages (each of which fits within these legacy constraints). | messages (each of which fits within these legacy constraints). | |||
skipping to change at line 532 ¶ | skipping to change at line 522 ¶ | |||
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. | |||
As such, DRIP transmitters are REQUIRED to adhere to the following | As such, DRIP transmitters are REQUIRED to adhere to the following | |||
when using the Authentication Message: | when using the Authentication Message: | |||
1. Authentication Data / Signature data MUST fit in the first 9 | 1. _Authentication Data / Signature_ data MUST fit in the first 9 | |||
pages (Page Numbers 0 through 8). | pages (Page Numbers 0 through 8). | |||
2. The Length field in the Authentication Headers (which encodes the | 2. The _Length_ field in the _Authentication Headers_ (which encodes | |||
length in octets of Authentication Data / Signature only) MUST | the length in octets of _Authentication Data / Signature_ only) | |||
NOT exceed the value of 201. This includes the SAM Type but | MUST NOT exceed the value of 201. This includes the SAM Type but | |||
excludes Additional Data. | excludes _Additional Data_. | |||
3.2.4.3. Timestamps | 3.2.4.3. Timestamps | |||
In ASTM [F3411], timestamps are a Unix-style timestamp with an epoch | In ASTM [F3411], timestamps are a Unix-style timestamp with an epoch | |||
of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for | of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for | |||
Authentication to keep a common time format in Broadcast payloads. | Authentication to keep a common time format in Broadcast payloads. | |||
Under DRIP, there are two timestamps defined: Valid Not Before (VNB) | Under DRIP, there are two timestamps defined: Valid Not Before (VNB) | |||
and Valid Not After (VNA). | and Valid Not After (VNA). | |||
skipping to change at line 560 ¶ | skipping to change at line 550 ¶ | |||
Timestamp denoting the recommended time at which to start trusting | Timestamp denoting the recommended time at which to start trusting | |||
data. MUST follow the format defined in [F3411] as described | data. MUST follow the format defined in [F3411] as described | |||
above. MUST be set no earlier than the time the signature (across | above. MUST be set no earlier than the time the signature (across | |||
a given structure) is generated. | a given structure) is generated. | |||
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 offset (relative to VNB) to avoid replay attacks. | |||
future (relative to VNB) to avoid replay attacks. The exact | The exact offset is not defined in this document. Best practice | |||
offset is not defined in this document. Best practice for | for identifying an acceptable offset should be used and should | |||
identifying an acceptable offset should be used and should take | take into consideration the UA environment, propagation | |||
into consideration the UA environment, propagation characteristics | characteristics of the messages being sent, and clock differences | |||
of the messages being sent, and clock differences between the UA | between the UA and Observers. For UA signatures in scenarios | |||
and Observers. For UA signatures in scenarios typical as of 2024, | typical as of 2024, a reasonable offset would be to set VNA | |||
a reasonable offset would be to set VNA approximately 2 minutes | approximately 2 minutes after VNB; see Appendix B for examples | |||
after VNB; see Appendix B for examples that may aid in tuning this | that may aid in tuning this value. | |||
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 FEC Section 5 MUST be used. | for example Legacy Transports, then FEC (per 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 | |||
flight to sign over information elements using the private key | during 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 | |||
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 635 ¶ | skipping to change at line 624 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
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 field MUST be 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 a DET [RFC9374] currently being used by the UA for | This is a DET [RFC9374] currently being used by the UA for | |||
authentication; it is assumed to be a Specific Session ID (a type | 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). | of UAS ID typically also used by the UA in the Basic ID Message). | |||
UA Signature: (64 octets) | _UA Signature_: (64 octets) | |||
Signature over the concatenation of preceding fields (VNB, VNA, | Signature over the concatenation of preceding fields (_VNB_, | |||
Evidence, and UA DET) using the keypair of the UA DET. The | _VNA_, _Evidence_, and _UA DET_) using the keypair of the UA DET. | |||
signature algorithm is specified by the Hierarchical Host Identity | The signature algorithm is specified by the Hierarchical Host | |||
Tags (HHIT) Suite ID of the DET. | Identity 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 | |||
This SAM Type is used to transmit Broadcast Endorsements. For | This SAM Type (Figure 5) is used to transmit Broadcast Endorsements. | |||
example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link | For example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link | |||
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. | |||
skipping to change at line 731 ¶ | skipping to change at line 720 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 5: Broadcast Endorsement / DRIP Link | Figure 5: Broadcast Endorsement / DRIP Link | |||
VNB Timestamp by Parent: (4 octets) | _VNB Timestamp by Parent_: (4 octets) | |||
See Section 3.2.4.3. Set by Parent Entity. | See Section 3.2.4.3. Set by Parent Entity. | |||
VNA Timestamp by Parent: (4 octets) | _VNA Timestamp by Parent_: (4 octets) | |||
See Section 3.2.4.3. Set by Parent Entity. | See Section 3.2.4.3. Set by Parent Entity. | |||
DET of Child: (16 octets) | _DET of Child_: (16 octets) | |||
DRIP Entity Tag of Child Entity. | DRIP Entity Tag of Child Entity. | |||
HI of Child: (32 octets) | _HI of Child_: (32 octets) | |||
Host Identity of Child Entity. | Host Identity of Child Entity. | |||
DET of Parent: (16 octets) | _DET of Parent_: (16 octets) | |||
DRIP Entity Tag of Parent Entity in DIME Hierarchy. | DRIP Entity Tag of Parent Entity in DIME Hierarchy. | |||
Signature by Parent: (64 octets) | _Signature by Parent_: (64 octets) | |||
Signature over concatenation of preceding fields (VNB, VNA, DET of | Signature over concatenation of preceding fields (_VNB_, _VNA_, | |||
Child, HI of Child, and DET of Parent) using the keypair of the | _DET of Child_, _HI of Child_, and _DET of Parent_) using the | |||
Parent DET. | keypair of the Parent DET. | |||
This DRIP Authentication Message is used in conjunction with other | This DRIP Authentication Message is used in conjunction with other | |||
DRIP SAM Types (such as the Manifest or the Wrapper) that contain | DRIP SAM Types (such as the Manifest or the Wrapper) that contain | |||
data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that | data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that | |||
is guaranteed to be unique, unpredictable, and easily cross-checked | is guaranteed to be unique, unpredictable, and easily cross-checked | |||
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). | |||
Note: The Endorsement that proves a DET is registered MUST come from | ||||
its immediate parent in the registration hierarchy, e.g., a DRIP | ||||
Identity Management Entity (DIME) [DRIP-REG]. In the definitive | ||||
hierarchy, the parent of the UA is its HHIT Domain Authority (HDA), | ||||
the parent of an HDA is its Registered Assigning Authority (RAA), | ||||
etc. It is also assumed that all DRIP-aware entities use a DET as | ||||
their identifier during interactions with other DRIP-aware entities. | ||||
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 field of the UA-Signed Evidence Structure (Section 4.1) | The _Evidence_ field of the _UA-Signed Evidence Structure_ | |||
is populated with up to four ASTM Messages [F3411] in a contiguous | (Section 4.1) is populated with up to four ASTM Messages [F3411] in a | |||
octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 | contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, | |||
are allowed and must be in Message Type order as defined by [F3411]. | 0x4, and 0x5 are allowed and must be in Message Type order as defined | |||
These messages MUST include the Message Type and Protocol Version | by [F3411]. These messages MUST include the Message Type and | |||
octet and MUST NOT include the Message Counter octet (thus are fixed | Protocol Version octet and MUST NOT include the Message Counter octet | |||
at 25 octets in length). | (thus are fixed 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 | |||
Timestamp by UA and the UA DET as shown in Figure 6. | _VNA 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 { | |||
return DECODE_FAILURE; | return DECODE_FAILURE; | |||
} | } | |||
wrappedCount = wrapperLength / 25; | wrappedCount = wrapperLength / 25; | |||
if (wrappedCount == 0) { | if (wrappedCount == 0) { | |||
// DECODE_SUCCESS; treat as DRIP Wrapper over extended transport | // DECODE_SUCCESS; treat as DRIP Wrapper over extended transport | |||
} | } | |||
else if (wrappedCount > 4) { | else if (wrappedCount > 4) { | |||
return DECODE_FAILURE; | return DECODE_FAILURE; | |||
} else { | } else { | |||
// DECODE_SUCCESS; treat as standard DRIP Wrapper | // DECODE_SUCCESS; treat as standard DRIP Wrapper | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
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 850 ¶ | skipping to change at line 847 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
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 field 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 892 ¶ | skipping to change at line 889 ¶ | |||
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 field of the UA-Signed Evidence Structure (Section 4.1) | The _Evidence_ field of the _UA-Signed Evidence Structure_ | |||
is populated with 8-octet hashes of [F3411] Broadcast RID messages | (Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast | |||
(up to 11) and three special hashes (Section 4.4.2). All of these | RID messages (up to 11) and three special hashes (Section 4.4.2). | |||
hashes MUST be concatenated to form a contiguous octet sequence in | All of these hashes MUST be concatenated to form a contiguous octet | |||
the Evidence field. It is RECOMMENDED that the maximum number of | sequence in the _Evidence_ field. It is RECOMMENDED that the maximum | |||
ASTM Message Hashes used be 10 (see Appendix B.1.1.2). | number of 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 | |||
HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen | (BE: HDA, UA) Hash_ MUST always come before the _ASTM Message Hashes_ | |||
in Figure 8. | as seen 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. | |||
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 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
skipping to change at line 930 ¶ | skipping to change at line 927 ¶ | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | | | | | |||
. . | . . | |||
. ASTM Message Hashes . | . ASTM Message Hashes . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 8: DRIP Manifest Evidence Structure | Figure 8: DRIP Manifest Evidence Structure | |||
Previous Manifest Hash: (8 octets) | _Previous Manifest Hash_: (8 octets) | |||
Hash of the previously sent Manifest Message. | Hash of the previously sent Manifest Message. | |||
Current Manifest Hash: (8 octets) | _Current Manifest Hash_: (8 octets) | |||
Hash of the current Manifest Message. | Hash of the current Manifest Message. | |||
DRIP Link (BE: HDA, UA): (8 octets) | _DRIP Link (BE: HDA, UA)_: (8 octets) | |||
Hash of the DRIP Link Authentication Message carrying BE: HDA, UA | Hash of the DRIP Link Authentication Message carrying BE: HDA, UA | |||
(see Section 4.2). | (see Section 4.2). | |||
ASTM Message Hash: (8 octets) | _ASTM Message Hash_: (8 octets) | |||
Hash of a single full ASTM Message using hash operations described | Hash of a single full ASTM Message using hash operations described | |||
in Section 4.4.3. | in Section 4.4.3. | |||
4.4.1. Hash Count and Format Validation | 4.4.1. Hash Count and Format Validation | |||
When decoding a DRIP Manifest on a receiver, a calculation of the | When decoding a DRIP Manifest on a receiver, a calculation of the | |||
number of hashes and a validation can be performed by using the | number of hashes and a validation can be performed by using the | |||
number of octets between the UA DET and the VNB Timestamp by UA | number of octets between the _UA DET_ and the _VNB Timestamp by UA_ | |||
(defined as manifestLength) such as shown in Figure 9. | (defined as manifestLength) such as shown in Figure 9. | |||
<CODE BEGINS> | <CODE BEGINS> | |||
if (manifestLength MOD 8) != 0 { | if (manifestLength MOD 8) != 0 { | |||
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 | |||
The following three special hashes are included in all Manifests: | The following three special hashes are included in all Manifests: | |||
* the Previous Manifest Hash links to the previous Manifest. | * the _Previous Manifest Hash_ links to the previous Manifest. | |||
* the Current Manifest Hash is of the Manifest in which it appears. | * 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 | * the _DRIP Link (BE: HDA, UA) Hash_ ties the endorsed UA key to the | |||
Manifest chain. | Manifest chain. | |||
The Previous and Current hashes act as a ledger of provenance for the | 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 | Manifest chain, which should be traced back if the Observer and UA | |||
were within Broadcast RID wireless range of each other for an | were within Broadcast RID wireless range of each other for an | |||
extended period of time. | 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 | |||
The hash algorithm used for the Manifest is the same hash algorithm | The hash algorithm used for the Manifest is the same hash algorithm | |||
used in creation of the DET [RFC9374] that is signing the Manifest. | used in creation of the DET [RFC9374] that is signing the Manifest. | |||
This is encoded as part of the DET using the HHIT Suite ID. | This is encoded as part of the DET using the HHIT Suite ID. | |||
DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as | DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as | |||
follows: | follows: | |||
cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash") | cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash") | |||
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 | |||
from the previous Manifest. For the first built Manifest, this value | known from the previous Manifest. For the first built Manifest, this | |||
is filled with a random nonce. The Current Manifest Hash is null | value is filled with a random nonce. The _Current Manifest Hash_ is | |||
filled while ASTM Messages are hashed and fill the ASTM Message | null filled while ASTM Messages are hashed and fill the _ASTM Message | |||
Hashes field. 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 | |||
Hash (null filled), and ASTM Message Hashes. This hash value | Manifest Hash_ (null filled), and _ASTM Message Hashes_. This hash | |||
replaces the null-filled Current Manifest Hash and becomes the | value replaces the null-filled _Current Manifest Hash_ and becomes | |||
Previous Manifest Hash for the next Manifest. | the _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 | |||
with the 24 octets of message data. The hash MUST NOT include the | with the 24 octets of message data. The hash MUST NOT include the | |||
Message Counter octet. | Message Counter octet. | |||
For paged ASTM Messages (currently only Authentication Messages), all | For paged ASTM Messages (currently only Authentication Messages), all | |||
skipping to change at line 1037 ¶ | skipping to change at line 1035 ¶ | |||
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 use of the UA-Signed Evidence | This SAM Type is defined to enable use of the _UA-Signed Evidence | |||
Structure (Section 4.1) in the future beyond the previously defined | Structure_ (Section 4.1) in the future beyond the previously defined | |||
formats (Wrapper and Manifest) by the inclusion of a single octet to | formats (Wrapper and Manifest) by the inclusion of a single octet to | |||
signal the format of Evidence 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 (2024), there are no | for a _Frame Type_. At the time of publication (2024), there are no | |||
defined Frame Types; only an Experimental range has been defined. | 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 | |||
parse the content in Frame Evidence Data. | known, 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) | |||
As shown in Figure 10, the Frame Type takes the first octet, which | As shown in Figure 10, the _Frame Type_ takes the first octet, | |||
leaves 111 octets available for Frame Evidence Data. See | which leaves 111 octets available for _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 1094 ¶ | skipping to change at line 1092 ¶ | |||
all page data of an Authentication Message. This allows the | all page data of an Authentication Message. This allows the | |||
correction of a single erased page in an Authentication Message. If | correction of a single erased page in an Authentication Message. If | |||
more than a single page is missing, then handling of an incomplete | more than a single page is missing, then handling of an incomplete | |||
Authentication Message is determined by higher layers. | Authentication Message is determined by higher layers. | |||
Other FEC schemes, to protect more than a single page of an | Other FEC schemes, to protect more than a single page of an | |||
Authentication Message or multiple [F3411] Messages, are left for | Authentication Message or multiple [F3411] Messages, are left for | |||
future standardization if operational experience proves it necessary | future standardization if operational experience proves it necessary | |||
and/or practical. | and/or practical. | |||
The data added during FEC is not included in the Authentication Data | The data added during FEC is not included in the _Authentication Data | |||
/ Signature, but instead in the Additional Data field of Figure 2. | / Signature_, but instead in the _Additional Data_ field of Figure 2. | |||
This may cause the Authentication Message to exceed 9 pages, up to a | This may cause the Authentication Message to exceed 9 pages, up to a | |||
maximum of 16 pages. | maximum of 16 pages. | |||
5.1. Encoding | 5.1. Encoding | |||
When encoding, two things are REQUIRED: | When encoding, two things are REQUIRED: | |||
1. The FEC data MUST start on a new Authentication Page. To do | 1. The FEC data MUST start on a new Authentication Page. To do | |||
this, the results of parity encoding MUST be placed in the | this, the results of parity encoding MUST be placed in the | |||
Additional Data field of Figure 2 with null padding before it to | _Additional Data_ field of Figure 2 with null padding before it | |||
line up with the next page. The Additional Data Length field | to line up with the next page. The _Additional Data Length_ | |||
MUST be set to number of padding octets + number of parity | field MUST be set to number of padding octets + number of parity | |||
octets. | octets. | |||
2. The Last Page Index field (in Page 0) MUST be incremented from | 2. The _Last Page Index_ field (in Page 0) MUST be incremented from | |||
what it would have been without FEC by the number of pages | what it would have been without FEC by the number of pages | |||
required for the Additional Data Length field, null padding, and | required for the _Additional Data Length_ field, null padding, | |||
FEC. | and FEC. | |||
To generate the parity, a simple XOR operation using the previous | To generate the parity, a simple XOR operation using the previous | |||
parity page and current page is used. Only the 23-octet | parity page and current page is used. Only the 23-octet | |||
Authentication Payload field of Figure 1 is used in the XOR | _Authentication Payload_ field of Figure 1 is used in the XOR | |||
operations. For Page 0, a 23-octet null pad is used for the previous | operations. For Page 0, a 23-octet null pad is used for the previous | |||
parity page. | parity page. | |||
Figure 11 shows an example of the last two pages (out of N) of an | Figure 11 shows an example of the last two pages (out of N) of an | |||
Authentication Message using DRIP Single Page FEC. The Additional | Authentication Message using DRIP Single Page FEC. The _Additional | |||
Data Length is set to 33, as there are always 23 octets of FEC data | Data Length_ is set to 33, as there are always 23 octets of FEC data | |||
and there are 10 octets of padding in this example to line it up into | and there are 10 octets of padding in this example to line it up into | |||
Page N. | Page N. | |||
Page N-1: | Page N-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 Data / Signature | | | Authentication Data / Signature | | |||
skipping to change at line 1160 ¶ | skipping to change at line 1158 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 11: Example Single Page FEC Encoding | Figure 11: Example Single Page FEC Encoding | |||
5.2. Decoding | 5.2. Decoding | |||
Frame decoding is independent of the transmit media. However, the | Frame decoding is independent of the transmit media. However, the | |||
decoding process can determine from the first Authentication page | decoding process can determine from the first Authentication Page | |||
that there may be a Bluetooth 4.x FEC page at the end. The decoding | that there may be a Bluetooth 4.x FEC page at the end. The decoding | |||
process MUST test for the presence of FEC and apply it as follows. | process MUST test for the presence of FEC and apply it as follows. | |||
To determine if FEC has been used, a check of the Last Page Index is | To determine if FEC has been used, a check of the _Last Page Index_ | |||
performed. In general, if the Last Page Index field is one greater | is performed. In general, if the _Last Page Index_ field is one | |||
than that necessary to hold Length octets of Authentication Data, | greater than that necessary to hold _Length_ octets of Authentication | |||
then FEC has been used. Note that if Length octets are exhausted | Data, then FEC has been used. Note that if _Length_ octets are | |||
exactly at the end of an Authentication Page, the Additional Data | exhausted exactly at the end of an Authentication Page, the | |||
Length field will occupy the first octet of the following page. The | _Additional Data Length_ field will occupy the first octet of the | |||
remainder of this page will be null padded under DRIP to align the | following page. The remainder of this page will be null padded under | |||
FEC to its own page. In this case, the Last Page Index will have | DRIP to align the FEC to its own page. In this case, the _Last Page | |||
been incremented once for initializing the Additional Data Length | Index_ will have been incremented once for initializing the | |||
field and once for the FEC page, for a total of two additional pages, | _Additional Data Length_ field and once for the FEC page, for a total | |||
as in the last row of Table 5. | of two additional pages, as in the last row of Table 5. | |||
To decode FEC in DRIP, a rolling XOR is used on each Authentication | To decode FEC in DRIP, a rolling XOR is used on each _Authentication | |||
Page received in the current Authentication Message. A Message | Page_ received in the current Authentication Message. A Message | |||
Counter, outside of the ASTM Message but specified in [F3411], is | Counter, outside of the ASTM Message but specified in [F3411], is | |||
used to signal a different Authentication Message and to correlate | used to signal a different Authentication Message and to correlate | |||
pages to messages. This Message Counter is only a single octet in | pages to messages. This Message Counter is only a single octet in | |||
length, so it will roll over (to 0x00) after reaching its maximum | length, so it will roll over (to 0x00) after reaching its maximum | |||
value (0xFF). If only a single page is missing in the Authentication | value (0xFF). If only a single page is missing in the Authentication | |||
Message the resulting parity octets should be the data of the erased | Message the resulting parity octets should be the data of the erased | |||
page. | page. | |||
Authentication Page 0 contains various important fields, only located | Authentication Page 0 contains various important fields, only located | |||
on that page, that help decode the full ASTM Authentication Message. | on that page, that help decode the full ASTM Authentication Message. | |||
If Page 0 has been reconstructed, the Last Page Index and Length | If Page 0 has been reconstructed, the _Last Page Index_ and _Length_ | |||
fields MUST be validated by DRIP. The pseudocode in Figure 12 can be | fields MUST be validated by DRIP. The pseudocode in Figure 12 can be | |||
used for both checks. | used for both checks. | |||
<CODE BEGINS> | <CODE BEGINS> | |||
function decode_check(auth_pages[], decoded_lpi, decoded_length) { | function decode_check(auth_pages[], decoded_lpi, decoded_length) { | |||
// check decoded_lpi does not exceed maximum value | // check decoded_lpi does not exceed maximum value | |||
if (decoded_lpi >= 16) { | if (decoded_lpi >= 16) { | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
skipping to change at line 1222 ¶ | skipping to change at line 1220 ¶ | |||
} | } | |||
// 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 | // use the presumed ADL to calculate a presumed | |||
//Last Page Index (LPI, a field defined in <xref target="F3411"/>) | //Last Page Index (LPI, a field defined in [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> | |||
Figure 12: Pseudocode for Decode Checks | Figure 12: Pseudocode for Decode Checks | |||
5.3. FEC Limitations | 5.3. FEC Limitations | |||
The worst-case scenario is when the Authentication Data / Signature | The worst-case scenario is when the _Authentication Data / Signature_ | |||
ends perfectly on a page boundary (Page N-1). This means the | ends perfectly on a page boundary (Page N-1). This means the | |||
Additional Data Length would start the next page (Page N) and have 22 | _Additional Data Length_ would start the next page (Page N) and have | |||
octets worth of null padding to align the FEC to begin at the start | 22 octets worth of null padding to align the FEC to begin at the | |||
of the next page (Page N+1). In this scenario, an entire page (Page | start of the next page (Page N+1). In this scenario, an entire page | |||
N) is being wasted just to carry the Additional Data Length. | (Page N) is being wasted just to carry the _Additional Data Length_. | |||
6. Requirements and Recommendations | 6. Requirements and Recommendations | |||
6.1. Legacy Transports | 6.1. Legacy Transports | |||
Under DRIP, the goal is to bring reliable receipt of the paged | Under DRIP, the goal is to bring reliable receipt of the paged | |||
Authentication Message using Legacy Transports. FEC (Section 5) MUST | Authentication Message using Legacy Transports. FEC (Section 5) MUST | |||
be used, per mandated RID rules (for example, the US FAA RID Rules | be used, per mandated RID rules (for example, the US FAA RID Rules | |||
[FAA-14CFR]), when using Legacy Transports (such as Bluetooth 4.x). | [FAA-14CFR]), when using Legacy Transports (such as Bluetooth 4.x). | |||
skipping to change at line 1501 ¶ | skipping to change at line 1499 ¶ | |||
Successful signature verification, using that public key, of a | Successful signature verification, using that public key, of a | |||
Wrapper (Section 4.3) or Manifest (Section 4.4) message, | Wrapper (Section 4.3) or Manifest (Section 4.4) message, | |||
authenticating content that is nonce-like, provides trust that the | authenticating content that is nonce-like, provides trust that the | |||
sender actually possesses the corresponding private key. | sender actually possesses the corresponding private key. | |||
The term "nonce-like" describes data that is unique, changes | The term "nonce-like" describes data that is unique, changes | |||
frequently, is not accurately predictable long in advance, and is | frequently, is not accurately predictable long in advance, and is | |||
easily validated (i.e., can be checked quickly at low computational | easily validated (i.e., can be checked quickly at low computational | |||
cost using readily available data) by the Observer. A Location/ | cost using readily available data) by the Observer. A Location/ | |||
Vector Message is an obvious choice. This is described in | Vector Message is an obvious choice. This is described in | |||
Section 6.3 (requirement 4) and Section 3.1.2.2. The Location/Vector | Section 3.1.2.2 and Section 6.3 (requirement 4). The Location/Vector | |||
Message [F3411] reporting precise UA position and velocity at a | Message [F3411] reporting precise UA position and velocity at a | |||
precise and very recent time is to be checked by the Observer against | 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 | visual observations of the UA within RF. Thus, Visual Line of Sight | |||
is typically the recommended form of this data. For specification of | is typically the recommended form of this data. For specification of | |||
the foregoing, see Sections 3.1.2 and 6.4.2. | 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., | |||
skipping to change at line 1574 ¶ | skipping to change at line 1572 ¶ | |||
frames* (manifest frame count + base frame count). | frames* (manifest frame count + base frame count). | |||
9.3. VNA Timestamp Offsets for DRIP Authentication Formats | 9.3. VNA Timestamp Offsets for DRIP Authentication Formats | |||
Note the discussion of VNA Timestamp offsets here is in the context | Note the discussion of VNA Timestamp offsets here is in the context | |||
of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and | of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and | |||
DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), these offsets | DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), these offsets | |||
are set by the DIME and have their own set of considerations in | are set by the DIME and have their own set of considerations in | |||
[DRIP-REG]. | [DRIP-REG]. | |||
The offset of the VNA Timestamp by UA is one that needs careful | The offset of the _VNA Timestamp by UA_ is one that needs careful | |||
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 | |||
skipping to change at line 1687 ¶ | skipping to change at line 1685 ¶ | |||
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 briefly describes each state and recommends an | Table 4 briefly describes each state and recommends an associated | |||
associated color. | color. | |||
+==============+========+===================================+ | +==============+========+===================================+ | |||
| State | Color | Details | | | State | Color | Details | | |||
+==============+========+===================================+ | +==============+========+===================================+ | |||
| None | Black | No Authentication has been or is | | | None | Black | No Authentication has been or is | | |||
| | | being received (as yet) | | | | | being received (as yet) | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Partial | Gray | Authentication being received but | | | Partial | Gray | Authentication being received but | | |||
| | | missing pages | | | | | missing pages | | |||
+--------------+--------+-----------------------------------+ | +--------------+--------+-----------------------------------+ | |||
skipping to change at line 1733 ¶ | skipping to change at line 1731 ¶ | |||
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 authentication information has not yet been | The default state where authentication information has not yet been | |||
received and is not currently being 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 | |||
skipping to change at line 1808 ¶ | skipping to change at line 1806 ¶ | |||
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 all jurisdictions known to the authors of this document as of its | |||
every second are: Basic ID (0x0), Location/Vector (0x1), and System | publication (2024), at least the following ASTM Messages are required | |||
(0x4). Typical implementations will most likely send at a higher | to be transmitted at least once per second: | |||
rate (2x sets per cycle) resulting in 6 frames sent per cycle. | ||||
Transmitting this set of messages more than once a second is not | ||||
discouraged, but awareness is needed to avoid congesting the RF | ||||
spectrum, causing further issues. | ||||
Informational Note: In Europe, transmission of the Operator ID | * Basic ID (0x1) | |||
Message (0x5) is also required. In Japan, transmission of two Basic | ||||
IDs (0x0), a Location/Vector (0x1), and an Authentication (0x2) are | * Location (0x2) | |||
required. Self ID (0x3) transmission is optional but can carry | ||||
Emergency Status information. | * System (0x4) | |||
Europe also requires: | ||||
* Operator ID Message (0x5) | ||||
Japan requires not one but two Basic ID messages: | ||||
* one carrying a manufacturer assigned serial number | ||||
* one carrying a CAA assigned registration number | ||||
Japan also requires: | ||||
* Authentication (0x2) using their own unique scheme | ||||
In all jurisdictions, one further message is optional, but highly | ||||
recommended for carriage of additional information on the nature of | ||||
the emergency if the Emergency value is sent in the Operational | ||||
Status field of the Location/Vector Message: | ||||
* Self ID (0x3) | ||||
To improve the likelihood of successful timely receipt of regulator | ||||
required RID data elements, most implementations send at a higher | ||||
rate, whether by repeating the same messages in the same one second | ||||
interval, or updating message content and sending messages more | ||||
frequently than once per second. Excessive sending rate, however, | ||||
could congest the RF spectrum, leading to collisions and counter- | ||||
intuitively actually reducing the likelihood of timely receipt of RID | ||||
data. | ||||
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) | |||
wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1 | wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1 | |||
<CODE ENDS> | <CODE ENDS> | |||
skipping to change at line 1899 ¶ | skipping to change at line 1923 ¶ | |||
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 field of the UA-Signed Evidence Structure making its total | _Evidence_ field of the _UA-Signed Evidence Structure_ making its | |||
size 200 octets. This fits on exactly 9 Authentication Pages ((201 - | total size 200 octets. This fits on exactly 9 Authentication Pages | |||
17) / 23 == 8), so when the ADL is added, it is placed on the next | ((201 - 17) / 23 == 8), so when the ADL is added, it is placed on the | |||
page (Page 10). Per rule 1 in Section 5.1, this means that all of | next page (Page 10). Per rule 1 in Section 5.1, this means that all | |||
Page 10 is null padded (expect the ADL octet) and FEC data fills Page | of Page 10 is null padded (expect the ADL octet) and FEC data fills | |||
11, resulting in a plus-two page count when FEC is applied. | Page 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 (Figure 13) is focused on showing that 100% of ASTM | |||
authenticated over Legacy Transports with up to 125% overhead in | Messages can be authenticated over Legacy Transports with up to 125% | |||
Authentication Pages. Extended Transports are not shown in this | overhead in Authentication Pages. Extended Transports are not shown | |||
example, because, for those, Authentication with DRIP is achieved | in this example, because, for those, Authentication with DRIP is | |||
using Extended Wrapper (Section 4.3.2). Two ASTM Message Packs are | achieved using Extended Wrapper (Section 4.3.2). Two ASTM Message | |||
sent in a given cycle: one containing up to four ASTM Messages and an | Packs are sent in a given cycle: one containing up to four ASTM | |||
Extended Wrapper (authenticating the pack), and one containing a Link | Messages and an Extended Wrapper (authenticating the pack), and one | |||
message with a Broadcast Endorsement and up to two other ASTM | containing a Link message with a Broadcast Endorsement and up to two | |||
Messages. | 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 2069 ¶ | skipping to change at line 2093 ¶ | |||
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. | |||
End of changes. 98 change blocks. | ||||
208 lines changed or deleted | 232 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |