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

Michiko Short <michikos@microsoft.com> Wed, 21 June 2017 20:31 UTC

Return-Path: <michikos@microsoft.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 969AC12949B for <kitten@ietfa.amsl.com>; Wed, 21 Jun 2017 13:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 v7c8OAI6kfji for <kitten@ietfa.amsl.com>; Wed, 21 Jun 2017 13:31:49 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3195129449 for <kitten@ietf.org>; Wed, 21 Jun 2017 13:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eJC3hEwJqdTW4dgpywVHEuhUev55WioH1gBy+PZZiLA=; b=Ra3DE49py6KrfTK8q+ZnEYk5cUQycrOM0nOAvR9F/PNdVxFMyh7CSJ07F0BjMtymjRp07m5jO2Q7HIWFl3BGRhXNS3CRF5bz1k21wslIpc5q2on2LEupVZxWlxjiNMONUdnr/d0KDuRE1RVQsBjEbFp+WOz9GwjY4OSLXAFctwM=
Received: from CY4PR21MB0165.namprd21.prod.outlook.com (10.173.192.147) by CY4PR21MB0152.namprd21.prod.outlook.com (10.173.189.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Wed, 21 Jun 2017 20:31:40 +0000
Received: from CY4PR21MB0165.namprd21.prod.outlook.com ([10.173.192.147]) by CY4PR21MB0165.namprd21.prod.outlook.com ([10.173.192.147]) with mapi id 15.01.1220.003; Wed, 21 Jun 2017 20:31:40 +0000
From: Michiko Short <michikos@microsoft.com>
To: "mrex@sap.com" <mrex@sap.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: "kitten@ietf.org" <kitten@ietf.org>
Thread-Topic: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt
Thread-Index: AQHS6S5ERbEDNBZGKUWvYaqTFCHYCKIvxCTg
Date: Wed, 21 Jun 2017 20:31:40 +0000
Message-ID: <CY4PR21MB0165053FBFE8C351377E6784D0DA0@CY4PR21MB0165.namprd21.prod.outlook.com>
References: <20170616040724.GO39245@kduck.kaduk.org> <20170619164331.0CB221A6BE@ld9781.wdf.sap.corp>
In-Reply-To: <20170619164331.0CB221A6BE@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sap.com; dkim=none (message not signed) header.d=none;sap.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:6::1be]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0152; 7:3jCb7viTBoKZ3dLwjwdZ6yG0DVT+f/YmxmN85X8euQxH/ljYTqHK9kIL75fG9ZGu4RnEcScEJesT8Ymy4yukfcfMvHFsw75Z7gN+fClZuut04MudUnavvhHK+RdrKcUa44h+fMTHLzUWcu1agsM434V2MKUVLdpWbB9fXijQNdU/l+jZqIbFG4MUFNV87fLwBOYT6cUqVkBLzebdrpO9ktwHMV/vfe6DUjwEdaJ+ImHfcRtp/AUZqc6gNIIUT30RbGeMNUWfuO2GZIfj5LxvQ5JXcaJsqZsHP1Y4Ubf3nMxEcfm2e4AAoclsgTIiDTa1wGN4NQV5QTuoJOIUcvm6tZR7DMFbu2gMk1uaRRNhZ+YdXqXSBojvW3rpafaJa3T40NY9mZe6genpzvhE9aPezQSyUqn37K5tp34JCmNcGVtFyfoH90ai9hNL4c5mR92i1LRaCxt1yHLab2XINpg+UGmiGAc4InXMsUrMMOeXDCeVjFkthHPiCVJ+ZmJ9QqJQcloTupaCzXBtnvV0ek8adq/1zENNRRiSdlsSux0rITNG7ImJL0tyIudzJX74Jlt0FX4SEWyHf2Mzyvx9qq+vO3g523/k139OcoKjwt+Draag0o5oBS4FkxjuPqeoENuURyecg9i3XPWXk3P9aRolAtT+Zm0kyWHcJNWZgJWpoa3ed44ZlFN24ckFyCcEEzg+DaTsjoOb1Ipoqft13OYJsdzaAGKSIhbYsDYfuPxZKhB+3JVoAlMnFrRcZLRTl15LfkeYGRH09uab7X25XSU7DHEfZmBGoIpBaen9vpp0bQ/6b8Aa6bsFQe8LZNwYzJkO
x-ms-office365-filtering-correlation-id: 6c3cf5b9-fb2d-4ecb-525f-08d4b8e485d4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:CY4PR21MB0152;
x-ms-traffictypediagnostic: CY4PR21MB0152:
x-microsoft-antispam-prvs: <CY4PR21MB01523A3D853DB02E75E5A574D0DA0@CY4PR21MB0152.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(55761251573089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0152; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0152;
x-forefront-prvs: 0345CFD558
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39860400002)(377454003)(24454002)(13464003)(230783001)(5660300001)(14454004)(53936002)(122556002)(77096006)(8656002)(9686003)(55016002)(6246003)(7736002)(478600001)(38730400002)(10090500001)(2171002)(7696004)(86362001)(5005710100001)(2501003)(76176999)(54356999)(8676002)(189998001)(305945005)(53546010)(6436002)(50986999)(81166006)(2900100001)(74316002)(8936002)(25786009)(33656002)(551544002)(4326008)(6506006)(102836003)(2950100002)(2906002)(3280700002)(3660700001)(10290500003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0152; H:CY4PR21MB0165.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 20:31:40.1259 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0152
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/FPzAobQmoo-sRZsY2VDF59jZQs8>
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 20:31:51 -0000

inline

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com] 
Sent: Monday, June 19, 2017 9:44 AM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: kitten@ietf.org
Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt

Benjamin Kaduk wrote:
> 
> As far as I know, this version is ready to be sent to the IESG for 
> approval.
> 
> The -03 adds this text (including known typo):
> 
>    Fortuntately, modern (i.e., supported) Kerberos implementations
>    support a secure alternative to RC4, in the form of AES.  Windows has
>    supported AES since 2007-2008 with the release of Windows Vista and
>    Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supported
>    AES (including the GSSAPI mechanism) since 2004 with the release of
>    version 1.3.2; Heimdal [HEIMDAL] has fully supported AES since 2005
>    with the release of version 0.7.  Though there may still be issues
>    running ten-year-old unsupported software in mixed environments with
>    new software, issues of that sort seem unlikely to be unique to
>    Kerberos, and the aministrators of such environments are expected to
>    be capable of devising workarounds.
> 
> It would be good to get independent confirmation of those 
> dates/release numbers; the windows ones I took from Michiko's email 
> and the Heimdal one from Chaskiel's mail.  (I did the MIT research 
> myself, and picked 1.3.2 to include the GSSAPI mechanism instead of
> 1.3 which had the bare enctype.)


I have always been wondering about the following issue about Microsoft Kerberos and the RC4-enctype:
[Michiko Short] Not sure this is only a MS issue. 

To be able to use AES enctypes with Microsoft Kerberos, not only the client, the server and the domain controllers must be using Vista or higher, but I assume that *also* Active Directory must be running a Domain functional level 2008 or higher (rather than domain functional level 2003).
[Michiko Short]  correct. This is why we had a matrix published with the AES announcement since Kerberos uses encryption for multiple things and thus DFL is one of the things that must be understood. I probably should revise that table and add to our docs for clarity, but I believe there have been a couple of blogs in the AskDS and protocol licensee space released since that Vista announcement. 

Can Active Directory store AES enctype longterm secrets of service accounts (for 2-token Kerberos authentication) when the domain controllers are Windows 2008, 2008R2 or maybe even 2012R2, but domain functional level is still at Windows 2003?
[Michiko Short] The problem with mixed modes domains (which I would assume applies to MIT & Heimdal as well) is that the DC can only create the keys it knows. When we shipped the GP to configure etype support we had to fix the DC logic to create all keys it knew vs supported to avoid the problem that when you flip the config on a DC then everything needs to change password. It is also why AES support becomes DFL. You cannot have a key used with the DC which is not understood by one or move DCs. 

If not, is it documented anywhere that _after_ upgrading a windows domain to functional level 2008+, and _before_ being able to use AES enctypes with serice accounts, it will be necessary to _manually_ _administratively_ set a new password (or the same password) for each and every service account, otherwise only RC4-enctypes and NTLM-authentication will work for that service account (unless storing passwords with reversible encryption has been enabled for a service account, I assume).
[Michiko Short] Actually it is more subtle than that. But I agree, when we evangelize RC4 deprecation in AD, we create better documentation. 

Kerberos with RC4 enctypes seemed to always have worked instantly after upgrading Windows domains, but AES enctypes seem to have never worked.
[Michiko Short] RC4 is supported by every version of Windows so it will work as it is the default. AES came later and unfortunately requires a lot of manual work. 

Does anyone know about the exact details, and why RC4-enctypes seem to work so much better in Windows?
[Michiko Short] Every version of Windows supports it and was the default in the design. 

(I'm not a real Kerberos user myself, but I've worked on a number of  support calls, and for some customers, administratively setting a  new password seemed to fix some of the Kerberos authentication issues,  and I am mainly guessing at potential issues here).


-Martin