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.