From: "Bonica, Ron" <ronald.bonica@hpe.com>
To: Eric Biggers <ebiggers=40google.com@dmarc.ietf.org>,
        "tcpm@ietf.org"
	<tcpm@ietf.org>
Thread-Topic: [tcpm] Re: I-D Action: draft-ietf-tcpm-tcp-ao-algs-05.txt
Thread-Index: AQHdGILmUSyriU+OukOKgZ6nFL3227Z3qxAH
Date: Tue, 21 Jul 2026 08:51:02 +0000
Message-ID: 
 <DM4PR84MB2310B85EEE1563CE885C97ADF4C22@DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM>
References: 
 <178249061156.1804370.3766568479863954134@dt-datatracker-f9b87776f-8pmmg>
 <20260720200218.GA341047@google.com>
In-Reply-To: <20260720200218.GA341047@google.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: 
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM4PR84MB2310:EE_|MW4PR84MB2041:EE_
x-ms-office365-filtering-correlation-id: c8e4cc4f-cb42-401a-06a5-08dee70531dd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: 
 BCL:0;ARA:13230040|376014|4022899009|23010399003|1800799024|366016|13003099007|6133799003|18002099003|22082099003|38070700021|56012099006|8096899003|4143699003|3023799007|10067099003;
x-microsoft-antispam-message-info: 
 NilDRludG0Y6Nb/nulsJCmonGyBYKznq4nVhd1Un2mRGEkzXRxCScyE8PDbEzWM05ZIQEn//H90XO8nxfSFiXvuHOU9kIMvjyHhddQoeLaP08Z/NmaiHXN3j8lSS1XBExfJ8UiOvbL50n/D0nI/6ntKOFvJRw4xWf7epblKy+qmG9jAJqIq6vieurMafK2cahAsppcHSoEQq38T3H35EkW3WPZ08yFxx5ftdPnJ0nQOMkmsrr2z2Lne/fMnWgmHf6cx+5CzH+xNOyEy11pSWQWyit4jaa0YV+4IhivcB0E2oS7pdTeqQXgphgwJLlOqkPNs9V+EkV9AV3yiI//8lb+Njrt2WAEJVR85QF1kv6QaQVxUK3lVJe7vMZETA/PU6NB8lo1mulJmT+K0Ax8xMTIEfNVYEMQFbBzvO4LCHElhxrsJ5TM/tNfwi37OJ6QMDceBcwxMBwiFFmvMoGqKgrCB6I9R/w/O8lh6t1hxouGIRNl8WVP7mCSB2zMTuJIKl6MIYAuffFeJCylp4AMfhMQ34L79TqtO4tYZggsoHfUNSKYvERfkDdm7Lk8vWHAV0CGQ0xf++R1b0oWBmjSF5GmvPgu/gshQuQp10z71b0OwAdGSgARyK8pR+xhqp4Pex0mVZdmEX3Q3uXWMtoFyaoO7j6QxUP7+HkTpJQ9I1dWk7lKChEN+9jhbdB6Wra5ZYyw9Kp8xQ4+VW1NDLTCf/NvgwYbpK6O8EKvsTtXSRGHQ=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(4022899009)(23010399003)(1800799024)(366016)(13003099007)(6133799003)(18002099003)(22082099003)(38070700021)(56012099006)(8096899003)(4143699003)(3023799007)(10067099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?BgmRcEdDbQ12UgVl0seubXkxpOmeVOtshslqig4m3UzZq8GFbokq78HLTkL+?=
 =?us-ascii?Q?EqSqEM8CcPDPy6YlO9r2ZGP54Cpe7dFmRzUvqQ3VtG/44ZrwIZ3wl4SpM8kC?=
 =?us-ascii?Q?VEs6K7NHDHB/WamUrIFQQdPcUpLmHPKrKUpuGGjdpxQFFyI3LBwWWYKdu0NS?=
 =?us-ascii?Q?QJdPCBft7LLuurtPxiU2PyLFwn1bQ8T5IrIDPE57bEqOWWQ6GPAQy/tryXBD?=
 =?us-ascii?Q?qluwInyoIKirQcUez6QuKHb3qZNDWOuJA3L8fmdSiGKfcEpFxmGK1AgMB/Ug?=
 =?us-ascii?Q?F8qglVwc719Ht9I8o6meTahibRtA0C2o58wjMhgv2M/aE68qfbsJYnSpvnf8?=
 =?us-ascii?Q?28sknOEac8zfN5gZjrYZxCMoU6qJMEbgSgMWOpD9h5xfPFHRzCnrY43IEZH6?=
 =?us-ascii?Q?dt2OHB1d9RlHkfZcF56jmsVkgdTUbhQvX98uxeKODfcmw+zAkh1fFeOsmZEL?=
 =?us-ascii?Q?0aawJ9jAF09fKMzZLKt7Wh230jPry0D2oa+FwdTx/IX+BroBUzBHBVR2wnFf?=
 =?us-ascii?Q?0hEp2yaPuuH7JOiZVnmpTBkh6cpp3GsdGBszvzyOZzdrBrA0ZYjTzF9TcQ6l?=
 =?us-ascii?Q?WUAI+655fcPMBPNfUjrKWl4spKnvCikSJkQvNqSMJG8G0V4OYowVPbr01gWh?=
 =?us-ascii?Q?5p75wsX+4jNIfNjkd2WLdLF8k27R0q1y8B7uHT9uHK9Z7T60pjf1aqsf9TDv?=
 =?us-ascii?Q?di/dU+i8jg6urLPE2iMEAjEnoAnHcarS8VM/Ew01GcWpc/ZrYzH7LSbzi76M?=
 =?us-ascii?Q?XZZBtUJvdZPCwjbtxi1KxU9wH1BuwUNv+sqOssjVWObcxcvkG7Qcp27e+ET5?=
 =?us-ascii?Q?ybpsH7uBEh3Xr+ULW6SPm624OJauHLuvPsld2vbu9JU+yHZODvHaDPe+H3B8?=
 =?us-ascii?Q?/sJixaeX3p8xpeOH/3hF8OUC7gNTOdklad7PjanLwG7c//gJhE6GFibYFKlk?=
 =?us-ascii?Q?ckRmErLBCT6hbYTjQJEFwa7N2SEJab7au4vrNMe39X6UlJp9lxySWaj1k5jc?=
 =?us-ascii?Q?zXD4k+4YQFc6aLUCHHPfN+fGczpplpycnjIwtTAgUh1b0shuqGTSUeUV+7sa?=
 =?us-ascii?Q?3bFNHK6TZNzDs2/aoY007jUwFzs4nZwC40IDhdwgUxxclbYjOL8gU6+RT4lt?=
 =?us-ascii?Q?sA4oLHVv2v0TzprRaOeZLwfJ24pXoLxdWL7B3ed6LBaKWgMb8lsTk8rtxDNB?=
 =?us-ascii?Q?PNiZG4+BDCackdBAbV5PrTlkimMBfTZCrUv+DFV4EN7HH2TAeD/fOIe9Lnyy?=
 =?us-ascii?Q?KAgFnPhBWItoJbTU1a+6K8Hb5hhLZ3Dcn8PRAjx/MjbMRefFlLg542heRj1u?=
 =?us-ascii?Q?66kW5K9rVOF5P0plHOftlwqbr9YiwB/NanzJGi3TQMyX66jf+qc2yXDNBw1B?=
 =?us-ascii?Q?wUIL9RlNO9H3SUTIrG701pkm9DwtToxXPkckBqkiRPY9rq6Bjo1ECVYKHaeG?=
 =?us-ascii?Q?hOSJQVl4KXE8Ici67hd23iQoV3A/tjwklsZV9D/26VIkT3tOHt17zT30kU7i?=
 =?us-ascii?Q?adlx3PXmjOsvC2QG7GwCwZ/VF7FnCgyvp5+OwObgOG0ls669cJKDrWMLbtwV?=
 =?us-ascii?Q?2d49rrqx8SzESEh1ucIMeHEkYzKk4zOZjXZNwKi3Cqr03bm96zhxYFwSv0rE?=
 =?us-ascii?Q?8EFH2Ou1x041KICkqhbs6V/FvdelX3tLNbuxQkmFe4zQEZ61mf01l7eCtJyg?=
 =?us-ascii?Q?x0BqsMh20mraUqT8hYr7wRNVckbJRZ71ta/2dkkxhFd2yAHi?=
Content-Type: multipart/alternative;
	boundary="_000_DM4PR84MB2310B85EEE1563CE885C97ADF4C22DM4PR84MB2310NAMP_"
MIME-Version: 1.0
X-Exchange-RoutingPolicyChecked: 
 jOB+3NXdFXxhYeslTprDKQv4uxOqIWm+PzcK/GgpF7Omiucj0Y0QbnL5F0kH1L3+s27KfRHk0WTHEs5/2KTZdbog+BEz1srww4Fa9a+7Q7pIEi4DuWwzwZYGbDHVVqbUmEVZpjA7wvh8LEY7vIuFTl9SDLgX1vkMip1T7CAVay2r5LcH7HgUoNOziB1WUpXidognsXyXJHcajgwbrx/pONAaBv6taI49vG97WRHTdE9q+PYunC9JDw/RFN35FmGbwvJST6wrOo8G5MpePXPPPRTwf9k89dfk1lecDjjUwUwSEb50IKXDSF3Kn1Ff0f6tmiS+N9mfHgP+IwPHZ6b6FQ==
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 c8e4cc4f-cb42-401a-06a5-08dee70531dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2026 08:51:03.0045
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 uxdx/0OmejxQClukhnL0wdmXUbePgxWXMapu4szxfM3uy0OKl6Nj7xYumcDl1N+NgrO9e5biEAa9tj2fERt0yQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR84MB2041
X-OriginatorOrg: hpe.com
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIxMDA5MyBTYWx0ZWRfX1ai/tw3AW9CL
 PiIKjQ6hT4SvrnlAu1tdKK6sNMqsfyBoMGR3iCiVGgx5X8XjlcM5647hyBVOpzl/DOioIVzaKnz
 Z9paezlayZKlG9nRnkb0yc2anV5mXtOySpEtAcUgv8NZFyqeYxbzbbkxiaeWsVLSmRtNmTGbx1V
 IyaDGsvQlPKk5NeWgSruTRIUDgWXTy8wEWZm9/ucpqjqNCqSK0vktQ3h6E6bYmjUd/B+piRFUA4
 c/7NWIUdo3USjkSgKUwnIAdikFWTBXpEjDBruCULY3KWX7p/O0HhcQ7cI51jgotmHDXo/GNYRer
 OdYtcTDZYPEn6XZj3cnIoB1ZGp4G6E5foo34DjHYiKdZvWIodmLShrIYbdQODJTpEISrSpst+q7
 dFWj93++Afi3m8Dqu+7fklWNrRVDSd27iFUhKE/rWM16u9Ho7vwcWqFr0y+aNsQG92I7wdUoEJE
 pVY/jbbrXMyLAJJdNaA==
X-Proofpoint-GUID: RPFn7UKfImwuXq5mwOwyQx8EMSK2QLHe
X-Authority-Analysis: v=2.4 cv=eJojSnp1 c=1 sm=1 tr=0 ts=6a5f3306 cx=c_pps
 a=UObrlqRbTUrrdMEdGJ+KZA==:117 a=UObrlqRbTUrrdMEdGJ+KZA==:17
 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19
 a=xqWC_Br6kY4A:10 a=RAioF0-LDSMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=gQcMVamqm3wCPoSYhaRC:22 a=NCWKwCw8Xy9Og0ibBRsL:22 a=VwQbUJbxAAAA:8
 a=48vgC7mUAAAA:8 a=T_UvQZqNDaiwzUC07D0A:9 a=CjuIK1q_8ugA:10 a=O8hF6Hzn-FEA:10
 a=Z1jG49YorJyVr2Te:21 a=frz4AuCg-hUA:10 a=_W_S_7VecoQA:10
X-Proofpoint-Spam-Info: AW1haW4tMjYwNzIxMDA5MyBTYWx0ZWRfX94oCfFOc8eEP
 +r1jFfCvGXRttopEkHc9emxvJ9OoeaGa3sstV6dlVwU2pv0C84ekXGWElhqSuPlZeYcqr+dx5v4
 ESeT/fIRWRWMzHnDvJH1U11L/YBSIuY=
X-Proofpoint-ORIG-GUID: RPFn7UKfImwuXq5mwOwyQx8EMSK2QLHe
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-07-20_06,2026-07-20_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 spamscore=0 bulkscore=0 adultscore=0 malwarescore=0 priorityscore=1501
 lowpriorityscore=0 clxscore=1011 phishscore=0 impostorscore=0 suspectscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607210093
Message-ID-Hash: DMFW46QWWKHZQ5QIZHP4YEAQATP7XFX7
X-Message-ID-Hash: DMFW46QWWKHZQ5QIZHP4YEAQATP7XFX7
X-MailFrom: ronald.bonica@hpe.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-tcpm.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5Btcpm=5D_Re=3A_I-D_Action=3A_draft-ietf-tcpm-tcp-ao-algs-05=2Etx?=
	=?utf-8?q?t?=
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tcpm/EG9q7Eylk2G09nMUNJ_GkYwxGWs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Owner: <mailto:tcpm-owner@ietf.org>
List-Post: <mailto:tcpm@ietf.org>
List-Subscribe: <mailto:tcpm-join@ietf.org>
List-Unsubscribe: <mailto:tcpm-leave@ietf.org>

--_000_DM4PR84MB2310B85EEE1563CE885C97ADF4C22DM4PR84MB2310NAMP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

agree
________________________________
From: Eric Biggers <ebiggers=3D40google.com@dmarc.ietf.org>
Sent: Monday, July 20, 2026 10:02 PM
To: tcpm@ietf.org <tcpm@ietf.org>
Cc: i-d-announce@ietf.org <i-d-announce@ietf.org>
Subject: [tcpm] Re: I-D Action: draft-ietf-tcpm-tcp-ao-algs-05.txt

Hi,

On Fri, Jun 26, 2026 at 09:16:51AM -0700, internet-drafts@ietf.org wrote:
> Internet-Draft draft-ietf-tcpm-tcp-ao-algs-05.txt is now available. It is=
 a
> work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the IE=
TF.
>
>    Title:   Additional Cryptographic Algorithms For Use With TCP-AO
>    Authors: Ron Bonica
>             Tony Li
>    Name:    draft-ietf-tcpm-tcp-ao-algs-05.txt
>    Pages:   26
>    Dates:   2026-06-26
>
> Abstract:
>
>    RFC5926 creates a list of cryptographic algorithms that can be used
>    with TCP-AO.  This document expands that list, adding two Message
>    Authentication Code (MAC) algorithms, HMAC-SHA256-128 and
>    KMAC256-128.  For each MAC algorithm, a corresponding Key Derivation
>    Function (KDF) is also added.
>
>    The MAC algorithms described by this document produce 128-bit (i.e.,
>    16-byte) MACs.  When 16-byte MACs are encoded in TCP-AO, the TCP-AO
>    consumes 20 of the 40 bytes available for TCP options.

I had this reviewed internally as well, and the result is that it
generally looks reasonable.  But there's still a footgun regarding what
is acceptable as a Master_Key.  There's an opportunity to do more to
decrease the chance of misuse.

As a refresher, TCP-AO accepts variable-length ASCII strings as the
Master_Key with no minimum length requirement.  Unfortunately, this
encourages users to input arbitrary passwords, which tend to have low
entropy.  Furthermore, no key stretching is performed, leaving these
passwords vulnerable to brute-forcing.  Some of the problematic language
includes:

  - RFC 5925: "Master_Key - The master_key string"

  - RFC 5926: "The Master_Key is used as the seed for the KDF.  We
    assume that this is a human-readable pre-shared key (PSK); thus, we
    assume it is of variable length.   Master_Keys SHOULD be random, but
    might not be (e.g., badly chosen by the user).  For
    interoperability, the management interface by which the PSK is
    configured MUST accept ASCII strings, and SHOULD also allow for the
    configuration of any arbitrary binary string in hexadecimal form."

  - draft-ietf-tcpm-tcp-ao-algs-05.txt: "This document RECOMMENDS that
    operators use Master_Keys generated by a cryptographic random number
    generator, or similar.  However, it is understood that they may not
    do so."

Though none of these documents explicitly use the word "password," the
lack of a minimum length and the explicit support for human-readable
ASCII strings makes it easily be interpreted as one.

Not surprisingly, here's how it got paraphrased into the documentation
of Linux's TCP-AO implementation (until I fixed it):

  - https://www.kernel.org/doc/html/v7.0/networking/tcp_ao.html :
    "MACs are produced from the content of a TCP segment using a hashing
    function with a password known to both peers."

So when people actually implement this stuff it becomes "password".

Really, the protocol should just take a 256-bit binary key that MUST be
a cryptographic key.  However, since that wasn't done from the
beginning, requiring it just for the new algorithms would be confusing.

Instead, how about:

  - The new algorithms will require that the master key MUST be *at
    least* 256 bits in length.  (This doesn't necessarily mean 256 bits
    of entropy, given that the key could be an ASCII representation of a
    key; however, this is better than no defense at all.)

  - The "Security Considerations" section should be clearer.  For
    example:

    "Master_Keys SHOULD have at least 256 bits of entropy, and they
    SHOULD be generated by a cryptographic random number generator or
    similar. No key stretching is done, and the use of low-entropy
    secrets (such as passwords) is vulnerable to brute-force attacks. If
    an ASCII string is used, it SHOULD be the hex or base64
    representation of a cryptographic key with at least 256 bits of
    entropy, rather than a human-readable password or passphrase."

- Eric

_______________________________________________
tcpm mailing list -- tcpm@ietf.org
To unsubscribe send an email to tcpm-leave@ietf.org

--_000_DM4PR84MB2310B85EEE1563CE885C97ADF4C22DM4PR84MB2310NAMP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
agree</div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Eric Biggers &lt;ebig=
gers=3D40google.com@dmarc.ietf.org&gt;<br>
<b>Sent:</b> Monday, July 20, 2026 10:02 PM<br>
<b>To:</b> tcpm@ietf.org &lt;tcpm@ietf.org&gt;<br>
<b>Cc:</b> i-d-announce@ietf.org &lt;i-d-announce@ietf.org&gt;<br>
<b>Subject:</b> [tcpm] Re: I-D Action: draft-ietf-tcpm-tcp-ao-algs-05.txt</=
font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">Hi,<br>
<br>
On Fri, Jun 26, 2026 at 09:16:51AM -0700, internet-drafts@ietf.org wrote:<b=
r>
&gt; Internet-Draft draft-ietf-tcpm-tcp-ao-algs-05.txt is now available. It=
 is a<br>
&gt; work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the=
 IETF.<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp; Title:&nbsp;&nbsp; Additional Cryptographic Algorith=
ms For Use With TCP-AO<br>
&gt;&nbsp;&nbsp;&nbsp; Authors: Ron Bonica<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Tony Li<br>
&gt;&nbsp;&nbsp;&nbsp; Name:&nbsp;&nbsp;&nbsp; draft-ietf-tcpm-tcp-ao-algs-=
05.txt<br>
&gt;&nbsp;&nbsp;&nbsp; Pages:&nbsp;&nbsp; 26<br>
&gt;&nbsp;&nbsp;&nbsp; Dates:&nbsp;&nbsp; 2026-06-26<br>
&gt; <br>
&gt; Abstract:<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp; RFC5926 creates a list of cryptographic algorithms t=
hat can be used<br>
&gt;&nbsp;&nbsp;&nbsp; with TCP-AO.&nbsp; This document expands that list, =
adding two Message<br>
&gt;&nbsp;&nbsp;&nbsp; Authentication Code (MAC) algorithms, HMAC-SHA256-12=
8 and<br>
&gt;&nbsp;&nbsp;&nbsp; KMAC256-128.&nbsp; For each MAC algorithm, a corresp=
onding Key Derivation<br>
&gt;&nbsp;&nbsp;&nbsp; Function (KDF) is also added.<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp; The MAC algorithms described by this document produc=
e 128-bit (i.e.,<br>
&gt;&nbsp;&nbsp;&nbsp; 16-byte) MACs.&nbsp; When 16-byte MACs are encoded i=
n TCP-AO, the TCP-AO<br>
&gt;&nbsp;&nbsp;&nbsp; consumes 20 of the 40 bytes available for TCP option=
s.<br>
<br>
I had this reviewed internally as well, and the result is that it<br>
generally looks reasonable.&nbsp; But there's still a footgun regarding wha=
t<br>
is acceptable as a Master_Key.&nbsp; There's an opportunity to do more to<b=
r>
decrease the chance of misuse.<br>
<br>
As a refresher, TCP-AO accepts variable-length ASCII strings as the<br>
Master_Key with no minimum length requirement.&nbsp; Unfortunately, this<br=
>
encourages users to input arbitrary passwords, which tend to have low<br>
entropy.&nbsp; Furthermore, no key stretching is performed, leaving these<b=
r>
passwords vulnerable to brute-forcing.&nbsp; Some of the problematic langua=
ge<br>
includes:<br>
<br>
&nbsp; - RFC 5925: &quot;Master_Key - The master_key string&quot;<br>
<br>
&nbsp; - RFC 5926: &quot;The Master_Key is used as the seed for the KDF.&nb=
sp; We<br>
&nbsp;&nbsp;&nbsp; assume that this is a human-readable pre-shared key (PSK=
); thus, we<br>
&nbsp;&nbsp;&nbsp; assume it is of variable length.&nbsp;&nbsp; Master_Keys=
 SHOULD be random, but<br>
&nbsp;&nbsp;&nbsp; might not be (e.g., badly chosen by the user).&nbsp; For=
<br>
&nbsp;&nbsp;&nbsp; interoperability, the management interface by which the =
PSK is<br>
&nbsp;&nbsp;&nbsp; configured MUST accept ASCII strings, and SHOULD also al=
low for the<br>
&nbsp;&nbsp;&nbsp; configuration of any arbitrary binary string in hexadeci=
mal form.&quot;<br>
<br>
&nbsp; - draft-ietf-tcpm-tcp-ao-algs-05.txt: &quot;This document RECOMMENDS=
 that<br>
&nbsp;&nbsp;&nbsp; operators use Master_Keys generated by a cryptographic r=
andom number<br>
&nbsp;&nbsp;&nbsp; generator, or similar.&nbsp; However, it is understood t=
hat they may not<br>
&nbsp;&nbsp;&nbsp; do so.&quot;<br>
<br>
Though none of these documents explicitly use the word &quot;password,&quot=
; the<br>
lack of a minimum length and the explicit support for human-readable<br>
ASCII strings makes it easily be interpreted as one.<br>
<br>
Not surprisingly, here's how it got paraphrased into the documentation<br>
of Linux's TCP-AO implementation (until I fixed it):<br>
<br>
&nbsp; - <a href=3D"https://www.kernel.org/doc/html/v7.0/networking/tcp_ao.=
html">https://www.kernel.org/doc/html/v7.0/networking/tcp_ao.html</a> :<br>
&nbsp;&nbsp;&nbsp; &quot;MACs are produced from the content of a TCP segmen=
t using a hashing<br>
&nbsp;&nbsp;&nbsp; function with a password known to both peers.&quot;<br>
<br>
So when people actually implement this stuff it becomes &quot;password&quot=
;.<br>
<br>
Really, the protocol should just take a 256-bit binary key that MUST be<br>
a cryptographic key.&nbsp; However, since that wasn't done from the<br>
beginning, requiring it just for the new algorithms would be confusing.<br>
<br>
Instead, how about:<br>
<br>
&nbsp; - The new algorithms will require that the master key MUST be *at<br=
>
&nbsp;&nbsp;&nbsp; least* 256 bits in length.&nbsp; (This doesn't necessari=
ly mean 256 bits<br>
&nbsp;&nbsp;&nbsp; of entropy, given that the key could be an ASCII represe=
ntation of a<br>
&nbsp;&nbsp;&nbsp; key; however, this is better than no defense at all.)<br=
>
<br>
&nbsp; - The &quot;Security Considerations&quot; section should be clearer.=
&nbsp; For<br>
&nbsp;&nbsp;&nbsp; example:<br>
<br>
&nbsp;&nbsp;&nbsp; &quot;Master_Keys SHOULD have at least 256 bits of entro=
py, and they<br>
&nbsp;&nbsp;&nbsp; SHOULD be generated by a cryptographic random number gen=
erator or<br>
&nbsp;&nbsp;&nbsp; similar. No key stretching is done, and the use of low-e=
ntropy<br>
&nbsp;&nbsp;&nbsp; secrets (such as passwords) is vulnerable to brute-force=
 attacks. If<br>
&nbsp;&nbsp;&nbsp; an ASCII string is used, it SHOULD be the hex or base64<=
br>
&nbsp;&nbsp;&nbsp; representation of a cryptographic key with at least 256 =
bits of<br>
&nbsp;&nbsp;&nbsp; entropy, rather than a human-readable password or passph=
rase.&quot;<br>
<br>
- Eric<br>
<br>
_______________________________________________<br>
tcpm mailing list -- tcpm@ietf.org<br>
To unsubscribe send an email to tcpm-leave@ietf.org<br>
</div>
</span></font></div>
</body>
</html>

--_000_DM4PR84MB2310B85EEE1563CE885C97ADF4C22DM4PR84MB2310NAMP_--