Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt

mrex@sap.com (Martin Rex) Wed, 21 June 2017 09:49 UTC

Return-Path: <mrex@sap.com>
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 DD5B1131CE8 for <kitten@ietfa.amsl.com>; Wed, 21 Jun 2017 02:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WSdrBsZl638U for <kitten@ietfa.amsl.com>; Wed, 21 Jun 2017 02:49:38 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9C1131CF2 for <kitten@ietf.org>; Wed, 21 Jun 2017 02:49:37 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3wt0L76Jl0z1HQS; Wed, 21 Jun 2017 11:49:35 +0200 (CEST)
X-purgate-ID: 152705::1498038575-00000816-1B32DBB4/0/0
X-purgate-size: 1985
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3wt0L75T36zGnsh; Wed, 21 Jun 2017 11:49:35 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AF6161A6BF; Wed, 21 Jun 2017 11:49:35 +0200 (CEST)
In-Reply-To: <20170621034615.GH39245@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@mit.edu>
Date: Wed, 21 Jun 2017 11:49:35 +0200
CC: Martin Rex <mrex@sap.com>, kitten@ietf.org
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/oHEZsidYRUCUXkAzt6TcyA0sGss>
Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 21 Jun 2017 09:49:41 -0000

Benjamin Kaduk wrote:
> On Mon, Jun 19, 2017 at 06:43:31PM +0200, Martin Rex wrote:
>> 
>> I have always been wondering about the following issue about
>> Microsoft Kerberos and the RC4-enctype:
> 
> Just to note explicitly: I am listed in the To: line of this message
> but am definitely not the right person to answer the questions here.
 
Partially true, it would be good to get some light shed on that
issue from *all* Kerberos implementors (not just Microsoft).

The new paragraph that you quoted as having been added to the I-D
currently _only_ talks about support for Kerberos AES enctypes in code.
The new text fails to mention the issue of availability of longterm secrets
in the Kerberos KDC database that are properly encoded for AES enctypes
--as a prerequisite of actually _using_ AES enctypes.

It's not just about availability of sufficiently recent code,
but also a necessity for re-keying all accounts in the Kerberos KDC database
_after_ sufficiently recend code has been deployed.  And it may not be
the deployment of new code on the KDC alone, there may be additonal
administrative changes necessary on the KDC to acutally enable use of
AES enctypes (e.g. changing the domain functional level in Active Directory)

The necessity for rekeying as a prerequisite of using new entypes is
AFAIK caused by salting string2key differently in all Kerberos enctypes
(except for RC4-HMAC) and storing only the resulting outputs, and this
seems to apply to most, if not all Kerberos implementations, I believe.

While many users in "managed" environments have traditionally been
pestered to change their user passwords on a regular basis, the same
might not be true for service accounts, which typically have plaintext
passwords configured in the registry on Windows Servers, or file-based
keytabs for traditional MIT Kerberos, and may not be subject to the
same regular re-keying as end user accounts in typical installations.


-Martin