Re: [kitten] RFC8636 paChecksum Agility

Greg Hudson <ghudson@mit.edu> Fri, 05 February 2021 00:46 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A893A1A11; Thu, 4 Feb 2021 16:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CCAIyrnDHf7; Thu, 4 Feb 2021 16:46:30 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22763A196C; Thu, 4 Feb 2021 16:46:27 -0800 (PST)
Received: from [18.28.9.250] ([18.28.9.250]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1150kPhN005818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Feb 2021 19:46:25 -0500
To: Andrew Wiley <anwiley=40microsoft.com@dmarc.ietf.org>, "kitten@ietf.org" <kitten@ietf.org>
References: <MWHPR21MB0174E9837FA1A08F0472F072A0B39@MWHPR21MB0174.namprd21.prod.outlook.com>
From: Greg Hudson <ghudson@mit.edu>
Autocrypt: addr=ghudson@mit.edu; keydata= mDMEXqnt4RYJKwYBBAHaRw8BAQdAzXfl3g5JJqlqM42fUUk/heS/9HBlRsg+nxe2STu4Su+0 HUdyZWcgSHVkc29uIDxnaHVkc29uQG1pdC5lZHU+iJYEExYIAD4WIQS7YOmQRa0ieO6SH+BO swnsPlpb8QUCXqnt4QIbAwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBOswns Plpb8aqtAP42pvOVq1EMSxNC1700RRyc1vhn0oHwcvQvh9KFjeLrbwEAnhQDwJsF3jJEsUhm 3pYkGXbUNFmTeAmKpSWxNa1tvgW4OAReqe3hEgorBgEEAZdVAQUBAQdAAaEKW1gflS0YVNfR azqT484BHfoNGd6HC5sidhGX5AUDAQgHiH4EGBYIACYWIQS7YOmQRa0ieO6SH+BOswnsPlpb 8QUCXqnt4QIbDAUJCWYBgAAKCRBOswnsPlpb8bFNAP40xH2VSjRL9fJ6AwFLH9kC2nLMIbf9 SaqB5KymlBlKtAD+NFHB1W68lmQGqlNglGxobCmVvlP7/kgNlfzfETgs+Aw=
Message-ID: <0e893d69-0240-6f83-1545-b8119e69fa19@mit.edu>
Date: Thu, 04 Feb 2021 19:46:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <MWHPR21MB0174E9837FA1A08F0472F072A0B39@MWHPR21MB0174.namprd21.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/tHTLbXkG7yuQZPaJZZnzJU6TOxo>
Subject: Re: [kitten] RFC8636 paChecksum Agility
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2021 00:46:32 -0000

On 2/4/21 6:28 PM, Andrew Wiley wrote:
> Section 3 describes how the SHA-1 checksum in paChecksum binds the preauthentication data to the request body and that in DH key agreement, the KDF supplements it. However, the KDF does not bind the preauthentication data to the request body – it only binds the response to the full request including preauthentication data.

This is stated in the security considerations:

   The paChecksum field, which binds the client pre-authentication data
   to the Kerberos request body, remains fixed at SHA-1.  If an attacker
   substitutes a different request body using an attack against SHA-1 (a
   second preimage attack is likely required as the attacker does not
   control any part of the legitimate request body), the KDC will not
   detect the substitution.  Instead, if a new KDF is negotiated, the
   client will detect the substitution by failing to decrypt the reply.

This choice of binding the reply key rather than the request padata
appears to date all the way back to the first draft in 2006 by Love and
Larry.  I can't find a working group archive going back that far, so I
don't know what their reasoning was.