[rfc4082-update] Fwd: New Version Notification for draft-moskowitz-ads-b-auth-03.txt

[Robert Moskowitz <[e-mail]>]

Thank you to those that commented to me.

I pulled ASCON and complexity of supporting TESLA keys other than 128 bits.

Timestamp is still a bit of an issue.  It is 1s accuracy which means 
that there can be 7 messages with the same timestamp, coming out of 
order.  I don't know yet if I can afford the 4 bits to address this.  I 
think I have it managed.

I don't know if my hashing and keyed MACing functions are adequate. Got 
to think more on them, and welcome all comments.

I locked down the formats for the Signed TESLA key and Identity Token.  
Both are really too big for sending in-band, as discussed. It will take 
me getting this in front of ICAO (relatively easy) ad RTCA (still needs 
some finessing) for how else (other channels) to handle these.

Anyway, review/comments are welcomed!

I don't THINK I have any changes/addtions before I get more feedback.

Bob

Locked down

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-moskowitz-ads-b-auth-03.txt
Date: 	Fri, 21 Aug 2026 08:45:49 -0700
From: 	[e-mail]
To: 	Stuart W. Card <[e-mail]>, Mikaëla Ngamboé 
<[e-mail]>, José M. Fernandez 
<[e-mail]>, Adam Wiethuechter 
<[e-mail]>, Jose Fernandez 
<[e-mail]>, Mikaela Ngamboe 
<[e-mail]>, Robert Moskowitz 
<[e-mail]>, Stuart Card <[e-mail]>



A new version of Internet-Draft draft-moskowitz-ads-b-auth-03.txt has been
successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-ads-b-auth
Revision: 03
Title: ADS-B Authentication
Date: 2026-08-21
Group: Individual Submission
Pages: 46
URL: https://www.ietf.org/archive/id/draft-moskowitz-ads-b-auth-03.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-ads-b-auth/
HTML: https://www.ietf.org/archive/id/draft-moskowitz-ads-b-auth-03.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ads-b-auth
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-moskowitz-ads-b-auth-03

Abstract:

Automatic Dependent Surveillance – Broadcast (ADS-B) is a
surveillance technology mandated in many airspaces. It is now widely
deployed but suffers from a lack of security and privacy. From a
security point of view, it is relatively easy to spoof ADS-B messages
with readily available hardware and software. From a privacy point
of view, every ADS-B message contains the aircraft's assigned 24-bit
ICAO address, a unique identifier that can be cross-referenced with
external databases (e.g. aircraft registries) to reveal the owner,
and can be used to track when and where a specific aircraft has
flown. In addition, the main transmission medium used for ADS-B, the
1090 MHz frequency, on which messages are broadcast using the
Extended Squitter (1090ES) format, is approaching saturation in some
parts of the world due to the volume of ADS-B and other protocol
messages, resulting in packet loss in certain areas.

This paper presents the IETF TESLA protocol along with X.509
certificates issued by ICAO member states for each aircraft to
authenticate all ADS-B messaging. It leverages the 8PSK phase
overlay (PO) scheme proposed in the Minimum Operational Performance
Standards (MOPS) for ADS-B (RTCA [DO-260C]), which enables 1090ES
ADS-B transmissions to convey three times more information, to
support the transmission of the extra security information required
by the authentication scheme. By doing so, the impact of
authentication on channel usage is negligible. Beyond message
authentication, this scheme protocol has two important additional
benefits: 1) the possibility to implement a Flight Authorization
scheme, allowing ATC and intercepting aircraft to not only
authenticate an aircraft but to verify that it is authorizes to
conduct that flight and 2) a privacy-preserving methodology that
assigns random 24-bit identifiers to designated aircraft while still
enabling blind authentication of their ADS-B transmissions.



The IETF Secretariat