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.
- [kitten] RFC8636 paChecksum Agility Andrew Wiley
- Re: [kitten] RFC8636 paChecksum Agility Greg Hudson