rfc9575v5.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		June 2024
	DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast		DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast
	Remote Identification (RID)		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
	skipping to change at line 212 ¶		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).
			Observation Session: The period of time during which a given
			Observer's receiver is processing (even if only intermittently) a
			series of UAS RID messages, at least some of which use DRIP
			extensions to [F3411], all nominally from the same UA executing a
			single flight operation.
	Note: For the remainder of this document, _Broadcast Endorsement:		Note: For the remainder of this document, _Broadcast Endorsement:
	Parent, Child_ will be abbreviated as _BE: Parent, Child_. For		Parent, Child_ will be abbreviated as _BE: Parent, Child_. For
	example, _Broadcast Endorsement: RAA, HDA_ will be abbreviated as		example, _Broadcast Endorsement: RAA, HDA_ will be abbreviated as
	_BE: RAA, HDA_.		_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
	skipping to change at line 307 ¶		skipping to change at line 313 ¶
	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). The Observer		based Authentication Messages (Sections 4.3 or 4.4). The Observer
	MUST verify the signature (cryptographically) and validate the signed		must verify the signature (cryptographically, as specified in
	content (via non-cryptographic means).		Section 3.1.1) and validate the signed content (via non-cryptographic
			means, as specified in Section 6.3).
	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 989 ¶		skipping to change at line 996 ¶
	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. At least once per		satisfies the fourth requirement in Section 6.3. At least once per
	session (of a given Observer processing messages nominally from a		Observation Session, the Observer must process that message as
	given UA), the Observer MUST process that message as specified in		specified in Section 6.3.
	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 1292 ¶		skipping to change at line 1298 ¶
	Message Packs are sent only over Extended Transports that provide		Message Packs are sent only over Extended Transports that provide
	FEC. Thus, the DRIP decoders will never be presented with a Message		FEC. Thus, the DRIP decoders will never be presented with a Message
	Pack from which a constituent Authentication Page has been dropped;		Pack from which a constituent Authentication Page has been dropped;
	DRIP FEC could never provide benefit to a Message Pack, only consume		DRIP FEC could never provide benefit to a Message Pack, only consume
	its precious payload space. Therefore, DRIP FEC (Section 5) MUST NOT		its precious payload space. Therefore, DRIP FEC (Section 5) MUST NOT
	be used in Message Packs.		be used in Message Packs.
	6.3. Authentication		6.3. Authentication
	To fulfill the requirements in [RFC9153], a UA:		To fulfill the requirements in [RFC9153], a UA MUST:
	1. MUST: send DRIP Link (Section 4.2) using the _BE: Apex, RAA_		1. send DRIP Link (Section 4.2) using the _BE: Apex, RAA_ (partially
	(partially satisfying GEN-3); at least once per 5 minutes. Apex		satisfying GEN-3); at least once per 5 minutes. Apex in this
	in this context is the DET prefix owner.		context is the DET prefix owner.
	2. MUST: send DRIP Link (Section 4.2) using the BE: RAA, HDA		2. send DRIP Link (Section 4.2) using the BE: RAA, HDA (partially
	(partially satisfying GEN-3); at least once per 5 minutes.		satisfying GEN-3); at least once per 5 minutes.
	3. MUST: send DRIP Link (Section 4.2) using the BE: HDA, UA		3. send DRIP Link (Section 4.2) using the BE: HDA, UA (satisfying
	(satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least		ID-5, GEN-1 and partially satisfying GEN-3); at least once per
	once per minute.		minute.
	4. MUST: send any other DRIP Authentication Format (non-DRIP Link)		4. send any other DRIP Authentication Format (non-DRIP Link) where
	where the UA is dynamically signing data that is guaranteed to be		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.
	An Observer MUST verify the signature (cryptographically) on each of		An Observer's receiver must verify the signature (cryptographically,
	the 4 messages immediately above and validate the signed content (via		as specified in Section 3.1.1) on each of the 4 messages sent in the
	non-cryptographic means) of the 4th message immediately above.		operations specified immediately above and the Observer MUST validate
			the signed content (via non-cryptographic means) of the 4th message
			sent in the last operation immediately above (the non-DRIP Link
			message).
	These transmission, receiver verification, and Observer validation		These transmission, receiver verification, and Observer validation
	requirements collectively satisfy GEN-3.		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)
	skipping to change at line 1383 ¶		skipping to change at line 1392 ¶
	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.
	At least once per session, after signature verification of any DRIP		At least once per Observation session, after signature verification
	Authentication Message containing UAS RID information elements (e.g.,		of any DRIP Authentication Message containing UAS RID information
	DRIP Wrapper, Section 4.3), the Observer MUST use other sources of		elements (e.g., DRIP Wrapper, Section 4.3), the Observer must use
	information to correlate against and perform validation. An example		other sources of information to correlate against and perform
	of another source of information is a visual confirmation of the UA		validation (as specified in Section 6.3). An example of another
	position.		source of information is a visual confirmation of the UA position.
	When correlation of these different data streams does not match in		When correlation of these different data streams does not match in
	acceptable thresholds, the data MUST be rejected as if the signature		acceptable thresholds, the data MUST be rejected as if the signature
	failed to validate. Acceptable threshold limits and what happens		failed to validate. Acceptable threshold limits and what happens
	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 1539 ¶		skipping to change at line 1548 ¶
	6.4.2. As non-normative clarification, the requirements are		6.4.2. As non-normative clarification, the requirements are
	satisfied as follows:		satisfied as follows:
	The public key corresponding to a given DET (i.e., the key attested		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		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		chain of DRIP Links) is used by an Observer's receiver to try to
	authenticate some signed message.		authenticate some signed message.
	If the signature check passes,		If the signature check passes,
	AND the message was a Wrapper or Manifest,		_and_ the message was a Wrapper or Manifest,
	AND the wrapped or manifested message contained content that was		_and_ the wrapped or manifested message contained content that was
	nonce-like,		nonce-like,
	AND the Observer validated that content by non-cryptographic means		_and_ the Observer validated that content by non-cryptographic
	(e.g., if the wrapped or manifested message was a Location/Vector		means (e.g., if the wrapped or manifested message was a Location/
	Message and the UA was visually observed to be in approximately		Vector Message and the UA was visually observed to be in
	the claimed location at the reported time),		approximately the claimed location at the reported time),
	ONLY THEN can the Observer trust that the currently observed sending		_only then_ can the Observer trust that the currently observed
	UA actually possesses the corresponding private key (and thus owns		sending UA actually possesses the corresponding private key (and thus
	the corresponding DET).		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
	vulnerability, unless they are combined with messages containing		vulnerability, unless they are combined with messages containing
	nonce-like data ([F3411] Location/Vector or [F3411] System) in a		nonce-like data ([F3411] Location/Vector or [F3411] System) in a
	Wrapper or Manifest. For specification of this last requirement, see		Wrapper or Manifest. For specification of this last requirement, see
	Section 4.4.2.		Section 4.4.2.
End of changes. 16 change blocks.
	36 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48.