[saag] Fwd: New Version Notification for draft-moskowitz-ads -b-auth-02.txt

Here is an updated version with more technical content.

I really request review of the TESLA aspects.  Particularly sec 3.3.3.1

this is where I have the various hashing and key MACing functions.

Of course a couple of big points:

The TESLA MAC is 28 bits.  That is all I can really fit into the 
messages.  But the authentication key is only used for ~31 messages 
before moving on to the next key in the hash-chain.

And this ties into PQC concerns.  128-bit key works nice in that it 
works well in the disclosure of 144 bits available in a TESLA maced 
message.  If I drop the MACing, I can go up to a 192-bit key.  A 224-bit 
key is possible if I make this a complete new message (grabbing 51 bits 
from the PPM portion, 196+51), but taking up valuable channel capacity.  
At most there is only 255 bits available if I really push the design; a 
256-bit key is just not possible.

But as the authentication key as from a hash-chain and ONLY used for ~31 
messages (current TESLA interval design, may change), and KMAC is the 
Manditory mac (HMAC optional), is there a real QC risk against the 
128-bit key?

Thank you for any reviews/feedback!

Bob



-------- Forwarded Message --------
Subject: 	New Version Notification for draft-moskowitz-ads-b-auth-02.txt
Date: 	Fri, 14 Aug 2026 10:46:25 -0700
From: 	[email protected]
To: 	Stuart W. Card <[email protected]>, Mikaëla Ngamboé 
<[email protected]>, José M. Fernandez 
<[email protected]>, Adam Wiethuechter 
<[email protected]>, Jose Fernandez 
<[email protected]>, Mikaela Ngamboe 
<[email protected]>, Robert Moskowitz 
<[email protected]>, Stuart Card <[email protected]>



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

Name: draft-moskowitz-ads-b-auth
Revision: 02
Title: ADS-B Authentication
Date: 2026-08-14
Group: Individual Submission
Pages: 46
URL: https://www.ietf.org/archive/id/draft-moskowitz-ads-b-auth-02.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-ads-b-auth/
HTML: https://www.ietf.org/archive/id/draft-moskowitz-ads-b-auth-02.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-02

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

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]