[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
- [rfc4082-update] Fwd: New Version Notification fo… Robert Moskowitz