rfc9575v4.txt | rfc9575.txt | |||
---|---|---|---|---|
skipping to change at line 285 ¶ | skipping to change at line 285 ¶ | |||
as having any relevance to the observed UA because replay attacks are | as having any relevance to the observed UA because replay attacks are | |||
trivial. | trivial. | |||
After an Observer has gathered such a complete key trust chain (from | After an Observer has gathered such a complete key trust chain (from | |||
pre-configured cache entries, Broadcast Endorsements received over | pre-configured cache entries, Broadcast Endorsements received over | |||
the air and/or DNS lookups) and verified all of its links, that | the air and/or DNS lookups) and verified all of its links, that | |||
device can trust that the claimed DET and corresponding public key | device can trust that the claimed DET and corresponding public key | |||
are properly registered, but the UA has not yet been proven to | are properly registered, but the UA has not yet been proven to | |||
possess the corresponding private key. | possess the corresponding private key. | |||
It is necessary for the UA to prove possession by dynamically signing | Second is for the UA to prove possession by dynamically signing data | |||
data that is unique and unpredictable but easily verified by the | that is unique and unpredictable but easily verified by the Observer | |||
Observer (Section 3.1.2.2). Verification of this signed data MUST be | (Section 3.1.2.2). Verification of this signed data MUST be | |||
performed by the Observer as part of the received UAS RID information | performed by the Observer as part of the received UAS RID information | |||
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. | |||
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). The Observer | |||
MUST verify the signature (cryptographically) and validate the signed | ||||
content (via non-cryptographic means). | ||||
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 | |||
skipping to change at line 487 ¶ | skipping to change at line 489 ¶ | |||
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 use (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 986 ¶ | skipping to change at line 988 ¶ | |||
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. At least once per | |||
session (of a given Observer processing messages nominally from a | ||||
given UA), the Observer MUST process that message as specified 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: | |||
skipping to change at line 1306 ¶ | skipping to change at line 1311 ¶ | |||
3. MUST: send DRIP Link (Section 4.2) using the BE: HDA, UA | 3. MUST: send DRIP Link (Section 4.2) using the BE: HDA, UA | |||
(satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least | (satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least | |||
once per minute. | once per minute. | |||
4. MUST: send any other DRIP Authentication Format (non-DRIP Link) | 4. MUST: send any other DRIP Authentication Format (non-DRIP Link) | |||
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. | An Observer MUST verify the signature (cryptographically) on each of | |||
the 4 messages immediately above and validate the signed content (via | ||||
non-cryptographic means) of the 4th message immediately above. | ||||
These transmission, receiver verification, and Observer validation | ||||
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 | |||
skipping to change at line 1373 ¶ | skipping to change at line 1383 ¶ | |||
A chain of DRIP Links provides trust in a key. A message, signed by | A chain of DRIP Links provides trust in a key. A message, signed by | |||
that key, containing data that changes rapidly and is not predictable | that key, containing data that changes rapidly and is not predictable | |||
far in advance (relative to typical operational flight times) but | far in advance (relative to typical operational flight times) but | |||
that can be validated by Observers, provides trust that some agent | that can be validated by Observers, provides trust that some agent | |||
with access to that data also possesses that key. If the validation | with access to that data also possesses that key. If the validation | |||
involves correlating physical world observations of the UA with | involves correlating physical world observations of the UA with | |||
claims in that data, then the probability is high that the observed | claims in that data, then the probability is high that the observed | |||
UA is (or is collaborating with or observed in real time by) the | UA is (or is collaborating with or observed in real time by) the | |||
agent with the key. | agent with the key. | |||
After signature verification of any DRIP Authentication Message | At least once per session, after signature verification of any DRIP | |||
containing UAS RID information elements (e.g., DRIP Wrapper | Authentication Message containing UAS RID information elements (e.g., | |||
Section 4.3) the Observer MUST use other sources of information to | DRIP Wrapper, Section 4.3), the Observer MUST use other sources of | |||
correlate against and perform validation. An example of another | information to correlate against and perform validation. An example | |||
source of information is a visual confirmation of the UA position. | of another 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 | |||
after such a rejection are out of scope for this document. | after such a rejection are out of scope for this document. | |||
7. Summary of Addressed DRIP Requirements | 7. Summary of Addressed DRIP Requirements | |||
The following requirements as defined in [RFC9153] are addressed in | The following requirements as defined in [RFC9153] are addressed in | |||
this document: | this document: | |||
skipping to change at line 1498 ¶ | skipping to change at line 1509 ¶ | |||
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 Broadcast RID messages and from | |||
Broadcast RID. A complete chain of Link messages (Section 4.2) from | sources other than Broadcast RID. A complete chain of Link messages | |||
an Endorsement root of trust to the claimed sender must be collected | (Section 4.2) from an Endorsement root of trust to the claimed sender | |||
and verified by the Observer device to provide trust in a key. | must be collected and verified by the Observer device to provide | |||
Successful signature verification, using that public key, of a | trust in a key. Successful signature verification, using that public | |||
Wrapper (Section 4.3) or Manifest (Section 4.4) message, | key, of a 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 (see below), provides trust | |||
sender actually possesses the corresponding private key. | that the 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 3.1.2.2 and Section 6.3 (requirement 4). The Location/Vector | Section 3.1.2.2 and Section 6.3 (requirement 4). A 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 can be checked by the Observer against | |||
visual observations of the UA within RF. Thus, Visual Line of Sight | visual observations of UA within both RF and 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. | For normative specification of the foregoing, see Sections 3.1.2 and | |||
6.4.2. As non-normative clarification, the requirements are | ||||
satisfied as follows: | ||||
The public key corresponding to a given DET (i.e., the key attested | ||||
in the DRIP Link (BE: HDA, UA) that is the last link in the relevant | ||||
chain of DRIP Links) is used by an Observer's receiver to try to | ||||
authenticate some signed message. | ||||
If the signature check passes, | ||||
AND the message was a Wrapper or Manifest, | ||||
AND the wrapped or manifested message contained content that was | ||||
nonce-like, | ||||
AND the Observer validated that content by non-cryptographic means | ||||
(e.g., if the wrapped or manifested message was a Location/Vector | ||||
Message and the UA was visually observed to be in approximately | ||||
the claimed location at the reported time), | ||||
ONLY THEN can the Observer trust that the currently observed sending | ||||
UA actually possesses the corresponding private key (and thus owns | ||||
the corresponding DET). | ||||
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 | |||
skipping to change at line 1651 ¶ | skipping to change at line 1685 ¶ | |||
10.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-16, 31 May | |||
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2024, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
drip-registries-15>. | drip-registries-16>. | |||
[FAA-14CFR] | [FAA-14CFR] | |||
Federal Aviation Administration (FAA), "Remote | Federal Aviation Administration (FAA), "Remote | |||
Identification of Unmanned Aircraft", January 2021, | Identification of Unmanned Aircraft", January 2021, | |||
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/ | <https://www.govinfo.gov/content/pkg/FR-2021-01-15/ | |||
pdf/2020-28948.pdf>. | pdf/2020-28948.pdf>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
End of changes. 11 change blocks. | ||||
27 lines changed or deleted | 61 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |