< draft-ietf-drip-auth-08.txt		draft-ietf-drip-auth-09.txt >
	DRIP Working Group A. Wiethuechter (Editor)		DRIP Working Group A. Wiethuechter (Editor)
	Internet-Draft S. Card		Internet-Draft S. Card
	Intended status: Standards Track AX Enterprize, LLC		Intended status: Standards Track AX Enterprize, LLC
	Expires: 28 October 2022 R. Moskowitz		Expires: 1 November 2022 R. Moskowitz
	HTT Consulting		HTT Consulting
	26 April 2022		30 April 2022
	DRIP Authentication Formats & Protocols for Broadcast Remote ID		DRIP Authentication Formats & Protocols for Broadcast Remote ID
	draft-ietf-drip-auth-08		draft-ietf-drip-auth-09
	Abstract		Abstract
	This document describes how to include trust into the ASTM Remote ID		This document describes how to include trust into the ASTM Remote ID
	specification defined in ASTM F3411 under Broadcast Remote ID (RID).		specification defined in ASTM F3411 under Broadcast Remote ID (RID).
	It defines a few message schemes (sent within the Authentication		It defines a few message schemes (sent within the Authentication
	Message) that can be used to authenticate past messages sent by a		Message) that can be used to authenticate past messages sent by a
	unmanned aircraft (UA) and provide proof of UA trustworthiness even		unmanned aircraft (UA) and provide proof of UA trustworthiness even
	in the absence of Internet connectivity at the receiving node.		in the absence of Internet connectivity at the receiving node.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 28 October 2022.		This Internet-Draft will expire on 1 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. DRIP Requirements Addressed . . . . . . . . . . . . . . . 3		1.1. DRIP Requirements Addressed . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Required Terminology . . . . . . . . . . . . . . . . . . 4		2.1. Required Terminology . . . . . . . . . . . . . . . . . . 4
	2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Problem Space and Focus . . . . . . . . . . . . . . . . . 4		3.1. Problem Space and Focus . . . . . . . . . . . . . . . . . 4
	3.2. Reasoning for IETF DRIP Authentication . . . . . . . . . 4		3.1.1. Broadcast RID RF Options . . . . . . . . . . . . . . 4
			3.2. Reasoning for IETF DRIP Authentication . . . . . . . . . 5
	3.3. ASTM Authentication Message . . . . . . . . . . . . . . . 5		3.3. ASTM Authentication Message . . . . . . . . . . . . . . . 5
	3.3.1. Authentication Page . . . . . . . . . . . . . . . . . 5		3.3.1. Authentication Page . . . . . . . . . . . . . . . . . 5
	3.3.2. ASTM Constraints . . . . . . . . . . . . . . . . . . 8		3.3.2. ASTM Constraints . . . . . . . . . . . . . . . . . . 8
	4. Forward Error Correction . . . . . . . . . . . . . . . . . . 8		4. Forward Error Correction . . . . . . . . . . . . . . . . . . 8
	4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 8		4.1.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 8
	4.1.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 9		4.1.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 9
	4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 12		4.2.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 12
	4.2.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 12		4.2.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 44 ¶
	3. Background		3. Background
	3.1. Problem Space and Focus		3.1. Problem Space and Focus
	The current standard for Remote ID does not, in any meaningful		The current standard for Remote ID does not, in any meaningful
	capacity, address the concerns of trust in the UA space with		capacity, address the concerns of trust in the UA space with
	communication in the Broadcast RID environment. This is a		communication in the Broadcast RID environment. This is a
	requirement that will need to be addressed eventually for various		requirement that will need to be addressed eventually for various
	different parties that have a stake in the UA industry.		different parties that have a stake in the UA industry.
			3.1.1. Broadcast RID RF Options
			A UA has the option of broadcasting using Bluetooth (4 and 5) or Wi-
			Fi (BEACON or NAN), see Section 7. With Bluetooth, FAA and other CAA
			mandate transmitting simultaneously over both 4 and 5. With Wi-Fi,
			use of BEACON is recommended. Wi-Fi NAN is another option, depending
			on CAA.
			Bluetooth 4 presents a payload size challenge in that it can only
			transmit 25 bytes of payload where the others all can support 252
			byte payloads.
	3.2. Reasoning for IETF DRIP Authentication		3.2. Reasoning for IETF DRIP Authentication
	The ASTM Authentication Message has provisions in [F3411] to allow		The ASTM Authentication Message has provisions in [F3411] to allow
	for other organizations to standardize additional Authentication		for other organizations to standardize additional Authentication
	formats beyond those explicitly in [F3411]. The standardization of		formats beyond those explicitly in [F3411]. The standardization of
	specific formats to support the DRIP requirements in UAS RID for		specific formats to support the DRIP requirements in UAS RID for
	trustworthy communications over Broadcast RID is an important part of		trustworthy communications over Broadcast RID is an important part of
	the chain of trust for a UAS ID. No existing formats (defined in		the chain of trust for a UAS ID. No existing formats (defined in
	[F3411] or other organizations leveraging this feature) provide the		[F3411] or other organizations leveraging this feature) provide the
	functionality to satisfy this goal resulting in the work reflected in		functionality to satisfy this goal resulting in the work reflected in
	skipping to change at page 5, line 38 ¶		skipping to change at page 6, line 5 ¶
	Page Header: (1 byte)		Page Header: (1 byte)
	Authentication Type (4 bits)		Authentication Type (4 bits)
	Page Number (4 bits)		Page Number (4 bits)
	Authentication Payload: (23 bytes per page)		Authentication Payload: (23 bytes per page)
	Authentication Payload, including headers. Null padded.		Authentication Payload, including headers. Null padded.
	Figure 1: Standard ASTM Authentication Message Page		Figure 1: Standard ASTM Authentication Message Page
	A single Authentication Page is akin to a UDP packet. For		A single Authentication Message is akin to a UDP packet. The
	Authentication Pages the structure is further wrapped by outer ASTM		Authentication Message is structured as a set of up to 16 pages.
	framing and the specific link framing (Bluetooth or Wi-Fi).		Over Bluetooth 4, these pages are "fragmented" into separate
			Bluetooth 4 broadcast frames.
			Either as a single Authentication Message or a set of fragmented
			Authentication Message Pages the structure(s) is further wrapped by
			outer ASTM framing and the specific link framing (Bluetooth or Wi-
			Fi).
	3.3.1.1. Authentication Type		3.3.1.1. Authentication Type
	[F3411] has the following subset of Authentication Type's defined and		[F3411] has the following subset of Authentication Type's defined and
	that can be used in the Page Header:		that can be used in the Page Header:
	+=====================+================================+		+=====================+================================+
	| Authentication Type | Description |		| Authentication Type | Description |
	+=====================+================================+		+=====================+================================+
	| 0x2 | Operator ID Signature |		| 0x2 | Operator ID Signature |
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 41 ¶
	3.3.1.1.1. Specific Authentication Method (SAM)		3.3.1.1.1. Specific Authentication Method (SAM)
	This document leverages Authentication Type 0x5, Specific		This document leverages Authentication Type 0x5, Specific
	Authentication Method (SAM), defining a set of SAM Types in		Authentication Method (SAM), defining a set of SAM Types in
	Section 6.3. Other Authentication Types are also used in DRIP and		Section 6.3. Other Authentication Types are also used in DRIP and
	their use is defined in Section 6.		their use is defined in Section 6.
	3.3.1.2. Page Number		3.3.1.2. Page Number
	There is a technical maximum of 16-pages (indexed 0 to 15 in the Page		There is a technical maximum of 16 pages (indexed 0 to 15 in the Page
	Header) that can be sent for a single Authentication Message, with		Header) that can be sent for a single Authentication Message, with
	each page carrying a max 23-byte Authentication Payload. See		each page carrying a max 23-byte Authentication Payload. See
	Section 3.3.2 for more details.		Section 3.3.2 for more details.
	3.3.1.3. Authentication Payload Field		3.3.1.3. Authentication Payload Field
	The following is shown in its complete format.		The following is shown in its complete format.
	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
End of changes. 8 change blocks.
	9 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/