< draft-ietf-drip-auth-07.txt		draft-ietf-drip-auth-08.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: 21 October 2022 R. Moskowitz		Expires: 28 October 2022 R. Moskowitz
	HTT Consulting		HTT Consulting
	19 April 2022		26 April 2022
	DRIP Authentication Formats & Protocols for Broadcast Remote ID		DRIP Authentication Formats & Protocols for Broadcast Remote ID
	draft-ietf-drip-auth-07		draft-ietf-drip-auth-08
	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 21 October 2022.		This Internet-Draft will expire on 28 October 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 26 ¶		skipping to change at page 2, line 26 ¶
	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.2. Reasoning for IETF DRIP Authentication . . . . . . . . . 4
	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. DRIP 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
	4.3. FEC Limitations . . . . . . . . . . . . . . . . . . . . . 13		4.3. FEC Limitations . . . . . . . . . . . . . . . . . . . . . 13
	5. Broadcast Attestation Structure . . . . . . . . . . . . . . . 13		5. Broadcast Attestation Structure . . . . . . . . . . . . . . . 13
	6. DRIP Authentication Formats . . . . . . . . . . . . . . . . . 15		6. DRIP Authentication Formats . . . . . . . . . . . . . . . . . 15
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	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
	this document.		this document.
	3.3. ASTM Authentication Message		3.3. ASTM Authentication Message
	The ASTM Authentication Message (Message Type 0x2) is a unique		The ASTM Authentication Message (Message Type 0x2) is a unique
	message in the Broadcast [F3411] standard as it is the only one that		message in the Broadcast [F3411] standard as it is the only one that
	is paged.		is larger than the Bluetooth 4 frame size. To address this, it is
			defined as a set of "pages" that each fits into a single Bluetooth 4
			broadcast frame. For other media these pages are still used but all
			in a single frame.
	3.3.1. Authentication Page		3.3.1. Authentication Page
	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 | |
	+---------------+ |		+---------------+ |
	| |		| |
	| |		| |
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 38 ¶
	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 TCP or UDP packet. For		A single Authentication Page is akin to a UDP packet. For
	Authentication Pages the structure is further wrapped by outer ASTM		Authentication Pages the structure is further wrapped by outer ASTM
	framing and the specific link framing (Bluetooth or Wi-Fi).		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 |
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	Figure 2 is the abstract view of the data fields found in the		Figure 2 is the abstract 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 Figure 1's Authentication Payload, spanning multiple pages.		into Figure 1's Authentication Payload, spanning multiple pages.
	When Additional Data is being sent, a single unsigned byte		When Additional Data is being sent, a single unsigned byte
	(Additional Data Length) directly follows the Authentication Data /		(Additional Data Length) directly follows the Authentication Data /
	Signature and has the length, in bytes, of the following Additional		Signature and has the length, in bytes, of the following Additional
	Data. For DRIP, this field is used to carry Forward Error Correction		Data. For DRIP, this field is used to carry Forward Error Correction
	as defined in Section 4.		as defined in Section 4.
	3.3.2. DRIP Constraints		3.3.2. ASTM Constraints
	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 of the most		data being sent is REQUIRED to fit within the page limit of the most
	constrained existing transport can support. Under Broadcast RID the		constrained existing transport can support. Under Broadcast RID the
	transport that can hold the least amount of authentication data is		transport that can hold the least amount of authentication data is
	Bluetooth 5 and Wi-Fi BEACON at 9-pages.		Bluetooth 5 and Wi-Fi BEACON 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 a 9-pages (Page		1. Authentication Data / Signature data MUST fit in a 9 pages (Page
	Numbers 0 through 8).		Numbers 0 through 8).
	2. The Length field in the Authentication Headers (which denotes the		2. The Length field in the Authentication Headers (which denotes the
	length in bytes of Authentication Data / Signature only) MUST NOT		length in bytes of Authentication Data / Signature only) MUST NOT
	exceed the value of 201.		exceed the value of 201.
	4. Forward Error Correction		4. Forward Error Correction
	For Broadcast RID, Forward Error Correction (FEC) is provided by the		For Broadcast RID, Forward Error Correction (FEC) is provided by the
	lower layers in Extended Transports (Bluetooth 5.X, Wi-Fi NaN, and		lower layers in Extended Transports (Bluetooth 5.X, Wi-Fi NaN, and
	skipping to change at page 19, line 48 ¶		skipping to change at page 19, line 48 ¶
	. .		. .
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Broadcast Attestation: (136-bytes)		Broadcast Attestation: (136-bytes)
	HDA over UA. Generated by a DRIP Registry during Session ID		HDA over UA. Generated by a DRIP Registry during Session ID
	registration.		registration.
	Figure 8: DRIP Link		Figure 8: DRIP Link
	This DRIP format MUST be used in conjunction with the DRIP Manifest		This DRIP format MUST be used in conjunction with another DRIP SAM
	with the hash of the DRIP Link message and other dynamic data (such		Type (such as Manifest or Wrapper) that contains data that is
	as the Location Message (Message Type 0x2)).		guaranteed to be unique and easily cross checked by the receiving
			device. A good candidate for this is using the DRIP Wrapper to
			encapsulate a Location Message (Message Type 0x2).
	6.3.2.1. Link Limitations		6.3.2.1. Link Limitations
	See Section 10.2 for details on why this structure is not dynamically		See Section 10.2 for details on why this structure is not dynamically
	signed.		signed.
	6.3.3. DRIP Wrapper		6.3.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. It MUST use the Broadcast Attestation		Broadcast RID messages. It MUST use the Broadcast Attestation
	skipping to change at page 33, line 13 ¶		skipping to change at page 33, line 13 ¶
	<https://www.rfc-editor.org/info/rfc9153>.		<https://www.rfc-editor.org/info/rfc9153>.
	[drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.		[drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
	Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,		Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,
	draft-ietf-drip-uas-rid-01, 9 September 2020,		draft-ietf-drip-uas-rid-01, 9 September 2020,
	<https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-		<https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
	01.txt>.		01.txt>.
	Appendix A. Authentication State Diagrams & Color Scheme		Appendix A. Authentication State Diagrams & Color Scheme
	ASTM Authentication has really only 3 states: None, Invalid or Valid.		ASTM Authentication has only 3 states: None, Invalid or Valid. This
	This is because under ASTM the idea is that Authentication is done by		is because under ASTM the idea is that Authentication is done by an
	an external service hosted somewhere on the Internet so it is assumed		external service hosted somewhere on the Internet so it is assumed
	you will always get some sort of answer back. With DRIP this		you will always get some sort of answer back. With DRIP this
	classification becomes more complex with the support of "offline"		classification becomes more complex with the support of "offline"
	scenarios where the receiver does not have Internet connectivity.		scenarios where the receiver does not have Internet connectivity.
	With the use of asymmetric keys this means the public key (PK) must		With the use of asymmetric keys this means the public key (PK) must
	somehow be obtained - [drip-registries] gets more into detail how		somehow be obtained - [drip-registries] gets more into detail how
	these keys are stored on DNS and one reason for DRIP Authentication		these keys are stored on DNS and one reason for DRIP Authentication
	is to send PK's over Broadcast RID.		is to send PK's over Broadcast RID.
	There are two keys of interest: the PK of the UA and the PK of the		There are two keys of interest: the PK of the UA and the PK of the
	HDA (or Registry). This document gives a clear way to send the PK of		HDA (or Registry). This document gives a clear way to send the PK of
End of changes. 11 change blocks.
	15 lines changed or deleted		20 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/