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

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 04 August 2026 21:40 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: rfc4082-update@mail2.ietf.org
Delivered-To: rfc4082-update@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5183C123B306E; Tue, 4 Aug 2026 14:40:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785879657; bh=x9i1v4RdYrHmfCrkOSmkHst4LZtNqBp4FbQTLn1+IpQ=; h=Date:To:From:Subject; b=r+GHkHTG7pXIckcnvLdO35hhysjQnYxNFpx8GEEZDGW8r46PK/6i7wveYNGUE7r6p UyKlzvf54s5U2WQArWZv6ydteBtOWh6dX1A3eNFru/lTA3yvJ2vjdR2EIomBy83vI6 4M0VI2U3r2WuPXJBwYrofj+SQpoh2DlBJIIEufwg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=htt-consult.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2LEtRie25A0; Tue, 4 Aug 2026 14:40:56 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [23.123.122.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 20392123B3063; Tue, 4 Aug 2026 14:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=htt-consult.com; s=mail; t=1785879646; bh=x9i1v4RdYrHmfCrkOSmkHst4LZtNqBp4FbQTLn1+IpQ=; h=Date:To:From:Subject:From; b=RiNhhLnvqyV/XOJGdzInO31gQvjM6zfUGx+qb/lP6wLlImo/FyYtECGEClOcU0Bdr A6YXUYsBjpjxoZBiJcZg6zz/cvcwlm/c+NBrmLNRu0I9ovqHrVB4YB7+b6DqGGn40x xxIXk+yH09y6WYvIp2VuqkxYRodcUipEf70NZ7FaEJqYVtkNcIa/UtrpT359aFX+SZ HFqOtv3eJ8UX1t+O0pRV3O+RnGd20mXN3fNOVX7buQCrQJljDpsYtYVVNrWQfuVdng eajy4sW6cf/bYmwWSQ0kfSA0cXUmYJTuZajtsGYQQCJvCQFufPLNXhVdN5RHK8oE3N emetm2mSzBqNA==
Received: from authenticated-user (klovia.htt-consult.com [23.123.122.149]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by klovia.htt-consult.com (Postfix) with ESMTPSA id EF3CF4A02E6; Tue, 4 Aug 2026 17:40:45 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------Xr8I0SigbYRUvAcHbNjcNyHI"
Message-ID: <8f8c8e33-498f-439b-b21d-33a224862eb9@htt-consult.com>
Date: Tue, 04 Aug 2026 17:40:33 -0400
MIME-Version: 1.0
To: IETF SAAG <saag@ietf.org>, rfc4082-update@ietf.org
Content-Language: en-US
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID-Hash: 3SIGRVMO4HIK3G3E5EFVHE3B5BDFZUOJ
X-Message-ID-Hash: 3SIGRVMO4HIK3G3E5EFVHE3B5BDFZUOJ
X-MailFrom: rgm-sec@htt-consult.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [rfc4082-update] Fwd: New Version Notification for draft-moskowitz-ads-b-auth-01.txt
List-Id: "Discussions for updating TESLA (Timed Efficient Stream Loss-Tolerant Authentication), RFC 4082." <rfc4082-update.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc4082-update/NMRqbxZTAlOlTgfZ_OJq4MNa3AM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc4082-update>
List-Help: <mailto:rfc4082-update-request@ietf.org?subject=help>
List-Owner: <mailto:rfc4082-update-owner@ietf.org>
List-Post: <mailto:rfc4082-update@ietf.org>
List-Subscribe: <mailto:rfc4082-update-join@ietf.org>
List-Unsubscribe: <mailto:rfc4082-update-leave@ietf.org>

During the SAAG session, in the chat, I mentioned the challenges I am 
having with my ADS-B Authentication work.  Particularly conveying 
digital certificates in some shape or form over the 1090ES channel even 
with the added bits from the Phase Overlay.

Forget about PQC, EdDSA25519 hurts.

I said in the chat, that I would soon be pushing out a draft of my 
ADS-Auth protocol for review/comments.  In particular there are aspects 
of use of TESLA that I need review.  But here it is.  The current 
protocol to authenticate ADS-B.

I welcome review.  The cert part is minimal in the ID, as the ID is 
about the 1090ES channel messages.  Not about the needed PKI or how PQC 
makes things really really hard.

Comments on SAAG or the rfc4082-update list are invited.  This design is 
now quite close to 4082, unlike what GNSS SBAS is doing. But that list 
might be the best place for discussions.  Or anywhere else people think 
to take it.

Oh, one last thing.  RTCA basically "owns" ADS-B in their DO-260 MOPS.  
It is behind their paywall.  Even I don't, yet, have a copy. My 
co-authors of the ID do have it and have kept the design consistant to 
the current DO-260C.  We will be taking this protocol to RTCA for the 
work on 260D (just starting up).  RTCA really does not (IMO) have the 
needed depth for a proper security review of this protocol.  Thus the 
public design, at this state, of what the protocol needs to be.  There 
will be similar IDs for parts of the PKI and perhaps how to send certs 
over some other channel because as you will see, 1090ES really cannot 
hack it.

Enough of my thought meanderings for the evening.  See you on lists 
tomorrow!

Bob






-------- Forwarded Message --------
Subject: 	New Version Notification for draft-moskowitz-ads-b-auth-01.txt
Date: 	Thu, 30 Jul 2026 13:22:09 -0700
From: 	internet-drafts@ietf.org
To: 	Stuart W. Card <stu.card@axenterprize.com>, Mikaëla Ngamboé 
<mikaela-stephanie-2.ngamboe-mvogo@polymtl.ca>, José M. Fernandez 
<jose.fernandez@bastionnage.ca>, Adam Wiethuechter 
<adam.wiethuechter@axenterprize.com>, Jose Fernandez 
<jose.fernandez@bastionnage.ca>, Mikaela Ngamboe 
<mikaela-stephanie-2.ngamboe-mvogo@polymtl.ca>, Robert Moskowitz 
<rgm@labs.htt-consult.com>, Stuart Card <stu.card@axenterprize.com>



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

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

Abstract:

The Automatic Dependent Surveillance – Broadcast (ADS-B) is a
surveillance technology mandated in many airspaces. It is now widely
deployed but suffers a lack of security and privacy. From a security
point of view, it is relatively easy to spoof the ADS-B messages.
With the appropriate readily available hardware and software. From a
privacy point of view, all the messages contain the aircraft’s
assigned 24-bit ICAO address, which makes it easy to link to data
about the aircraft, in particular to know when a particular aircraft
has flown and where to. In addition, the main transmission medium
utilized for ADS-B, i.e. the 1090 MHz frequency used by Extended
Squitter (1090ES), is approaching saturation in some parts of the
world with ADS-B and other protocol messages, resulting in packet
loss in certain areas [RF_Usage].

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 methodology for adequately protecting
the privacy by assigning rotating 24-bit identifiers to designated
aircraft, while maintaining the possibility to (blindly) authenticate
their ADS-B transmissions.



The IETF Secretariat