From nobody Tue Jun 6 12:31:14 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8328126C25; Tue, 6 Jun 2017 12:31:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149677747276.3887.5092728511899292089@ietfa.amsl.com> Date: Tue, 06 Jun 2017 12:31:12 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:31:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : SPAKE Pre-Authentication Authors : Nathaniel McCallum Simo Sorce Robbie Harwood Greg Hudson Filename : draft-ietf-kitten-krb-spake-preauth-00.txt Pages : 22 Date : 2017-06-06 Abstract: This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of secure second factor authentication without relying on FAST. This is achived using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-00 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 15 21:07:34 2017 Return-Path: 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 20FEF126DCA for ; Thu, 15 Jun 2017 21:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rsCIZMhgiMpQ for ; Thu, 15 Jun 2017 21:07:31 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 E5BCA1200F3 for ; Thu, 15 Jun 2017 21:07:30 -0700 (PDT) X-AuditID: 1209190c-257ff700000025d9-65-594359818ef0 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 11.01.09689.18953495; Fri, 16 Jun 2017 00:07:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5G47Sf2012738 for ; Fri, 16 Jun 2017 00:07:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5G47Pl7013337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Jun 2017 00:07:27 -0400 Date: Thu, 15 Jun 2017 23:07:25 -0500 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170616040724.GO39245@kduck.kaduk.org> References: <149758570844.11259.2151834891785499164@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149758570844.11259.2151834891785499164@ietfa.amsl.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUixCmqrdsY6RxpsHahicXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0XWsk62gU6Li1NQp7A2Mf4S6GDk5JARMJM49eM3UxcjFISSw mEni+85j7BDOcUaJtv8HoTKvmSR+/pnADtLCIqAq8ar3GiOIzSagItHQfZkZxBYREJbYvfUd mC0sECJxp/EFaxcjBwcv0Iq195RAwkICzhK33v4CG8MrIChxcuYTFhCbWUBL4sa/l0wg5cwC 0hLL/3GAhDkFXCTaz59hArFFBZQl/h6+xzKBkX8Wku5ZSLpnIXQvYGRexSibklulm5uYmVOc mqxbnJyYl5dapGuol5tZopeaUrqJERx4kjw7GM+88TrEKMDBqMTDq9DgFCnEmlhWXJl7iFGS g0lJlJdfDijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPdzsHOkEG9KYmVValE+TEqag0VJnFdC ozFCSCA9sSQ1OzW1ILUIJivDwaEkwdseAdQoWJSanlqRlplTgpBm4uAEGc4DNHyHK8jw4oLE 3OLMdIj8KUZFKXHezHCghABIIqM0D64XlBgksvfXvGIUB3pFmHc2yAoeYFKB634FNJgJaHDQ BQeQwSWJCCmpBsZTd4XzbBZEZP3/Y6f7MUN3b5Di1AVfvv3QKnp+8aaL/Mp/VferNRzq5R9f cLgsf/zq0zCn/TFXjRW3Mlnefpy17LHn9+cbvxYrpttUPDzWcD893WrX3cv+K6Pqe1+VL9pv 17j0taBm1O4d57ZpqkoeiFn/fbkuW+hnptsGEXLdgYfnnQ982OOnxFKckWioxVxUnAgAivKw GOcCAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 04:07:33 -0000 Hi everyone, 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.) Thanks, Ben On Thu, Jun 15, 2017 at 09:01:48PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. > > Title : Deprecate 3DES and RC4 in Kerberos > Authors : Benjamin Kaduk > Michiko Short > Filename : draft-ietf-curdle-des-des-des-die-die-die-03.txt > Pages : 9 > Date : 2017-06-15 > > Abstract: > The 3DES and RC4 encryption types are steadily weakening in > cryptographic strength, and the deprecation process should be begun > for their use in Kerberos. Accordingly, RFC 4757 is moved to > Obsolete status, as none of the encryption types it specifies should > be used, and RFC 3961 is updated to note the deprecation of the > triple-DES encryption types. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-03 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-die-die-die-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des-des-des-die-die-die-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Jun 16 06:47:04 2017 Return-Path: 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 389EB12943F for ; Fri, 16 Jun 2017 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 vD8X-fEN1s1A for ; Fri, 16 Jun 2017 06:47:01 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0806212741D for ; Fri, 16 Jun 2017 06:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1497620797; x=1498225597; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=Y2r9iIElW4WDilonmjyr6/ F6Na/TXag1YNekWk3S1uc=; b=ko8RcFTMrFAuHEvw0uvpKuCcYgsTPVRF3Sx/wf bbQBzKSDQGNwwWB77ZvDGo3zdB/216bmUfsCzbs/cbpZaK8uKxx0MckYLksSQjsV uBsxQs2Bmc+jdEeHwUoLh+YRssyz1wgLD+m9SbWLxSrhlYoJhrndA/kx3kEem0jX xyT84= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 16 Jun 2017 09:46:37 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 16 Jun 2017 09:46:36 -0400 Received: from [IPv6:2001:470:1f07:f77:7174:9244:a061:80d1] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v17.0.2) with ESMTPSA id md50001368541.msg; Fri, 16 Jun 2017 09:46:35 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:7174:9244:a061:80d1 X-MDHelo: [IPv6:2001:470:1f07:f77:7174:9244:a061:80d1] X-MDArrival-Date: Fri, 16 Jun 2017 09:46:35 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=13401aadbb=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-CAV-Result: clean To: kitten@ietf.org References: <149758570844.11259.2151834891785499164@ietfa.amsl.com> <20170616040724.GO39245@kduck.kaduk.org> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <91ab7cab-53cc-3a8b-e936-2664ebac17b5@secure-endpoints.com> Date: Fri, 16 Jun 2017 09:46:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170616040724.GO39245@kduck.kaduk.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010702000803050401020400" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:47:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010702000803050401020400 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I will confirm the Heimdal dates. AES was added to Heimdal's source tree on Jul 23 13:00:42 2003 and support for the krb5 AES OIDs were added on Apr 26 21:08:01 2004. The 0.7 release is the first tagged release to include the AES OIDs. The tag was applied on Jun 16 16:23:19 2005. Jeffrey Altman On 6/16/2017 12:07 AM, Benjamin Kaduk wrote: > Hi everyone, >=20 > As far as I know, this version is ready to be sent to the IESG for > approval. >=20 > The -03 adds this text (including known typo): >=20 > Fortuntately, modern (i.e., supported) Kerberos implementations > support a secure alternative to RC4, in the form of AES. Windows ha= s > supported AES since 2007-2008 with the release of Windows Vista and > Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supporte= d > 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. >=20 > 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.) >=20 > Thanks, >=20 > Ben >=20 >=20 >=20 > On Thu, Jun 15, 2017 at 09:01:48PM -0700, internet-drafts@ietf.org wrot= e: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the CURves, Deprecating and a Little more= Encryption of the IETF. >> >> Title : Deprecate 3DES and RC4 in Kerberos >> Authors : Benjamin Kaduk >> Michiko Short >> Filename : draft-ietf-curdle-des-des-des-die-die-die-03.txt >> Pages : 9 >> Date : 2017-06-15 >> >> Abstract: >> The 3DES and RC4 encryption types are steadily weakening in >> cryptographic strength, and the deprecation process should be begun= >> for their use in Kerberos. Accordingly, RFC 4757 is moved to >> Obsolete status, as none of the encryption types it specifies shoul= d >> be used, and RFC 3961 is updated to note the deprecation of the >> triple-DES encryption types. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die= -die/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-= 03 >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-des-des-des-di= e-die-die-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-des-des-des-die-= die-die-03 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --------------ms010702000803050401020400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJswggYCMIIE6qADAgECAhBAAVgjEN7WFoCIXylZ1uvSMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMjQxOFoXDTE3MTEwMjAzMjQxOFowgZYxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMTAwLgYKCZImiZPyLGQBARMgN0YwMDAwMDEw MDAwMDE1ODIzMTBERUE3MDAwMDA3QjQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDPaPDUdwWkzLcNsJjjlDs5lo4ySDKmCgzQsuDt+VY3wP0IZBbu8f/LM3zWCH7zVRJ/XuY5 qN44jFEXwj5fGY71Esm5pKv5sUpys6Q3c6BKXiHv/IUusI3qTJ46QBEAiHu2lxB75UnIYgm+ ZbKmcAR48Z1Sl/Ku86e9GPuts9R51SeHW1pjq89LAi6C0ERuAUIK0rVZGDmKWtRNs9EykXzk mU2Z1ZLuPL0jIggFPeT8TyH6TH/XvapbC+7rHJrzuBY4NDqLgqDJUf0JidL9JeK9+IxxPCab EbVmOf5sBgO5mg92l4+f+Q4xefZcI4C7RPFdRTRWsQs7Z3DpE28BDbjDAgMBAAGjggKlMIIC oTAOBgNVHQ8BAf8EBAMCBaAwgYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDov L2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFs aWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgw FoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASwGA1UdIASCASMwggEfMIIB GwYLYIZIAYb5LwAGCwEwggEKMEoGCCsGAQUFBwIBFj5odHRwczovL3NlY3VyZS5pZGVudHJ1 c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDCBuwYIKwYBBQUHAgIw ga4agatUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29y ZGFuY2Ugd2l0aCAKSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91 bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5 L3RzL2luZGV4Lmh0bWwwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3ZhbGlkYXRpb24uaWRl bnRydXN0LmNvbS9jcmwvdHJ1c3RpZGNhYTEyLmNybDAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB0GA1UdDgQWBBSP11Voh/Sg9hmecftn2BV5ZQd9OTAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAC9cnqRj+ViE efFsiYNMUC8tZf6PXcWDecOR5Pdv/Vd/O6y10mYyilPrcd0sJux1idTZIOzHAsh36BfBdNSt BFAuBZD66L649U3XqBnh9nbuzmCwNc3tWjOaY/Xe7R90lqrXaW0Dw0U++zwmNyCO2CRgBdrU 8cTqFpOtpe/gCAMhjajrUfb+m8Vcd5R0RVIvdljblqv2t9IXQIHwWSm8E7v302z7yW4o4iPH kegez5vq37ICikQjkkVyAJr0wtirJyQuFzMgpoWVpm0CKBiMwJPki2kiHlNiMHBr2ch4fC+H SjbMg4OzTZJCz1xhKvpyRDOM8JRb2BNSU8JjmrxZgFIwggaRMIIEeaADAgECAhEA+d5Wf8lN DHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUw MjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYy maAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ 00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGV TtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQO ORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEA AaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJj aWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24u aWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU 7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggET MIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVu dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhp cyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdp dGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0 cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4 Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv bS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0G CSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3w Wzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp /7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq 0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIw pigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2h e8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQ epmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUg YOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAg prpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7Vu EP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEB ME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDYxNjEzNDYzMlowLwYJKoZI hvcNAQkEMSIEIEbBq+3S75yY1t1mPyYxBO2Npx1Tv/F157wJGSjAUGDPMF0GCSsGAQQBgjcQ BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1 c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEATYD9UBlyw/3lDTgTQuib rJfDvo7eanVWNJvJZ5uu1lOJjkqt5LxLvHmmtlLrMJ2gv08iePBOXzyeJlVRjlJhcXQoI34R xqK5xM/5XuMaEZpcWpjCFEu+fCxMk5oScBpT9Iu52s6FGfLFx99FlGDfsfXqZVMLWWypBDMQ zslQAoRqgWb3zsUQ101g+dVT6anpjvsbNiemOxbgSp12oArIF+6+iclLO6oVoVwzXszPFhIf rcK6LYRH/97+347p5irq66apDmVh3nYFVMQCg7xpSOQk5+FR9TnvcG4qYTwo9WfkVbpHqFQz cT21GXrM3DVAGGpqxF596BuSeb9Vift5VAAAAAAAAA== --------------ms010702000803050401020400-- From nobody Fri Jun 16 22:28:59 2017 Return-Path: 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 AFB141318F3 for ; Fri, 16 Jun 2017 22:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZeR7KAEY_ljw for ; Fri, 16 Jun 2017 22:28:55 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 7F90A1318E9 for ; Fri, 16 Jun 2017 22:28:55 -0700 (PDT) X-AuditID: 12074425-69dff70000001ce3-9f-5944be14b625 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 29.87.07395.41EB4495; Sat, 17 Jun 2017 01:28:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5H5Sq9l019276 for ; Sat, 17 Jun 2017 01:28:52 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5H5SmP0030834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Jun 2017 01:28:51 -0400 Date: Sat, 17 Jun 2017 00:28:48 -0500 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170617052847.GT39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixCmqrCu6zyXS4MxDRYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/rVzawFV0Urfp5tY29gPC/YxcjJISFgIrH51WbGLkYuDiGB xUwSK8/thnKOM0rc/XgMynnNJHG1qY0FpIVFQFWifcJHZhCbTUBFoqH7MpgtIiAssXvrOzBb WCBD4sGbf4wgNi/QirOLP0LZghInZz4Bm8MsoCVx499Lpi5GDiBbWmL5Pw6QsKiAssTfw/dY JjDyzkLSMQtJxyyEjgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzGCQond RXUH45y/XocYBTgYlXh4GW47RwqxJpYVV+YeYpTkYFIS5c0Jd4kU4kvKT6nMSCzOiC8qzUkt PsQowcGsJMKbkQmU401JrKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeDfv AWoULEpNT61Iy8wpQUgzcXCCDOcBGs68AWR4cUFibnFmOkT+FKOilDjvu91ACQGQREZpHlwv KNYlsvfXvGIUB3pFmHcCyAoeYJqA634FNJgJaHDQBQeQwSWJCCmpBsblnvVzZ7yNXyry3KUt JiRPQe7qp8kBNQdaYqKU9qcoTdtw2H5K7/mcd99DxN88YeLLlX2wP/rIxFVmmW8N7Os+Xbsv L5XuaKIQ7fbTr9buG7NI750/7H5Jgc6r2S1uW9Tl+ysduCU1588+s3exxaxWn01+s2hwKb6W 6n6VM4d3Z37wm4cr5JRYijMSDbWYi4oTAYmKO9jQAgAA Archived-At: Subject: [kitten] [daniel.migault@ericsson.com: [Curdle] WGLC 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 05:28:58 -0000 For those not following the curdle list... ----- Forwarded message from Daniel Migault ----- Date: Fri, 16 Jun 2017 09:18:33 -0400 From: Daniel Migault To: curdle Subject: [Curdle] WGLC draft-ietf-curdle-des-des-des-die-die-die-03.txt Hi, This email starts a WGLC for draft-ietf-curdle-des-des-des-die-die-die. Please review the document and raise your concerns by June 30. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ Yours, Rich and Daniel ---------- Forwarded message ---------- From: Date: Fri, Jun 16, 2017 at 12:01 AM Subject: [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt To: i-d-announce@ietf.org Cc: curdle@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Deprecate 3DES and RC4 in Kerberos Authors : Benjamin Kaduk Michiko Short Filename : draft-ietf-curdle-des-des-des-die-die-die-03.txt Pages : 9 Date : 2017-06-15 Abstract: The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos. Accordingly, RFC 4757 is moved to Obsolete status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-des-des-des-die-die-die-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle- des-des-des-die-die-die-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-des- des-des-die-die-die-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ----- End forwarded message ----- From nobody Fri Jun 16 22:30:49 2017 Return-Path: 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 A5D791318E9 for ; Fri, 16 Jun 2017 22:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 lr-A2eimwvwY for ; Fri, 16 Jun 2017 22:30:47 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 663671287A3 for ; Fri, 16 Jun 2017 22:30:47 -0700 (PDT) X-AuditID: 12074424-00fff700000007c8-c2-5944be85b5b4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 67.B7.01992.58EB4495; Sat, 17 Jun 2017 01:30:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v5H5UhRn028279; Sat, 17 Jun 2017 01:30:44 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5H5UdIA031208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jun 2017 01:30:42 -0400 Date: Sat, 17 Jun 2017 00:30:39 -0500 From: Benjamin Kaduk To: Jeffrey Altman Cc: kitten@ietf.org Message-ID: <20170617053039.GU39245@kduck.kaduk.org> References: <149758570844.11259.2151834891785499164@ietfa.amsl.com> <20170616040724.GO39245@kduck.kaduk.org> <91ab7cab-53cc-3a8b-e936-2664ebac17b5@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91ab7cab-53cc-3a8b-e936-2664ebac17b5@secure-endpoints.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrtu2zyXSoG2ftMWflZPYLI5uXsXi wOSxZMlPJo+TfedZA5iiuGxSUnMyy1KL9O0SuDK2/XzLVtDEXPHq+gH2BsaVTF2MnBwSAiYS i/bdYu5i5OIQEljMJLGnbwUbhLORUaJt4QmozFUmiZmLrjODtLAIqEp8u3eTHcRmE1CRaOi+ DBYXETCUaPt/kxXEZhYQlli+5iwbiC0sECtx6sd3FhCbF2jd3sO3oYauYZTY9uoKE0RCUOLk zCcsEM1aEjf+vQSKcwDZ0hLL/3GAhDkFPCTu7fsAtktUQFni7+F7LBMYBWYh6Z6FpHsWQvcC RuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6uZkleqkppZsYwYHqorKDsbvH+xCjAAejEg8v w23nSCHWxLLiytxDjJIcTEqivDnhLpFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgzMoFyvCmJ lVWpRfkwKWkOFiVxXnGNxgghgfTEktTs1NSC1CKYrAwHh5IErywwIoUEi1LTUyvSMnNKENJM HJwgw3mAhjNvABleXJCYW5yZDpE/xajL0fRhyxcmIZa8/LxUKXHe5r1ARQIgRRmleXBzQAlG Int/zStGcaC3hHkn7AGq4gEmJ7hJr4CWMAEtCbrgALKkJBEhJdXAuKdt2eHj6x8GGzZ8fbXg 2Ylv04NNVO5W/lM54CV8tclJufCDctvbV6+MLggF/nTo43Ho87VxKUirFxbL+s3BUnxotUz8 4g38PxRZJLRilr/8/ih30nSDzMbDjoYbbE61z2aZnlW9P1KCSWb/Ah8FUcc3kwyMbT4cFBCy El/JWKy6ec714/9dlViKMxINtZiLihMBRYirQQsDAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 05:30:49 -0000 On Fri, Jun 16, 2017 at 09:46:32AM -0400, Jeffrey Altman wrote: > I will confirm the Heimdal dates. > > AES was added to Heimdal's source tree on Jul 23 13:00:42 2003 and > support for the krb5 AES OIDs were added on Apr 26 21:08:01 2004. The > 0.7 release is the first tagged release to include the AES OIDs. The > tag was applied on Jun 16 16:23:19 2005. Thanks! -Ben From nobody Sat Jun 17 11:23:55 2017 Return-Path: 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 480A6129B55 for ; Sat, 17 Jun 2017 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 42FBhbLHcl9x for ; Sat, 17 Jun 2017 11:23:52 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDFB129B5B for ; Sat, 17 Jun 2017 11:23:51 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 63so29540651ywr.0 for ; Sat, 17 Jun 2017 11:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oVktMNtSZZceqbYGJI+Uimj9GwQLWRhTITigd/j6rac=; b=bFpI/yrMvKK9SerrzMkHLdjQLxOFE9of0xY6/TU1z6CC3FSlVY8K4+IGA5bbxVOxpf cPsGyTXjCL0tD7zj8S5WxmpJy0KgIyw630RoEZsPkKy+4rZkfXJHdVH8Twu2ng9pzwFK vNLhNCvCWYFtCGVI4DksJW/FRJcEbWnkwqfmuTa4HIUg2kMLNNiBOwg6K05Ch+vyMsQw KHqjdNUZxNbtfD2ZWqYYO9qFKdjSMSVPSXrWixrbWL/fej7I+WogFgtcX6bBhEb44LXI 9NKj3ki6jIwtA/YGZiOLeQYgnBdM6qawjY496Z+pLSYuDHkUtAFbeUrp5M+WGc2kLvsv gGag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oVktMNtSZZceqbYGJI+Uimj9GwQLWRhTITigd/j6rac=; b=t22bRNxR1k3fhD8BdjkJCVXvVFv9EJZTEVTU60pAf4FlBqos6b2GDc+XDyLfo00k5N i6VreSgpJ3HTFL1mDu7tj8CyxQEgwKa18iubuCjVzVT5PUgtESOOtT0srbqSKQKbIL43 kmQbZOuNtIIBkfxuD4T0sFNrGLfCeVT9HuD9cq19tFbGEv+E2TTaZ/S6SJ2A/Rz+kU/f uNbHMaN64U4p4HL4JzWuzPfZvuM6q4shwY3vHhmgzPSjYyx2qKVbLv342AwN/QYGUabd kNY2Q6dzXfCXuzTREUsB1EuomYNp9rrKGh7lLuAgJe4sfCdFQhK4alRe6gDQEu21W3LN 1+tw== X-Gm-Message-State: AKS2vOySel0w1GbvUFUnxSxIWK2BXFeocMpagoEHDf18YzhmeRbLbbFX VyJYhc4U6x9oaLQRTwJLtNNytZHEdo70Xwg= X-Received: by 10.129.68.10 with SMTP id r10mr12644818ywa.85.1497723830974; Sat, 17 Jun 2017 11:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 17 Jun 2017 11:23:10 -0700 (PDT) From: Eric Rescorla Date: Sat, 17 Jun 2017 11:23:10 -0700 Message-ID: To: kitten Content-Type: multipart/alternative; boundary="f403045eb768ead0ec05522c00e1" Archived-At: Subject: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 18:23:54 -0000 --f403045eb768ead0ec05522c00e1 Content-Type: text/plain; charset="UTF-8" This document seems generally sound. There are some things about this API that confused/surprised me and seem perhaps unwise, but given that this is a bis, I will mostly confine my review to mostly calling them out and asking you to make sure I understand and that the document is clear. OVERALL 1. What is a fatal error? The document describes exceptions as indicating "fatal errors". What does this mean for the state of the context. For instance, if I receive an exception from initSecContext(), does that mean that it is no longer possible to initiate it? Your example code seems to treat them as fatal for the context. What happens if I try to use a context after such an event? 2. How do I enforce properties for received messages? I see that I can request services for context initialization (requestConf), and that I can check whether a given message was encrypted (getPrivacy) but it's not clear to me if this causes the API to enforce these rules for tokens that I receive. Is that possible or do I just need to check? 3. Are the request* flags() hard limits? E.g., if I do requestMutualAuth() do I get it or fail? 4. It's a little unusual to have a structure where you keep calling initSecContext or acceptContext() repeatedly. In most APIs you would do like "setRole(Server)" or "setRoleClient(), and then "Handshake(). DETAIL S 6.1.16. Can addProviderAtFront() be used to add new providers which the API would not normally use at all? S 6.4.9. Successful completion of this call does not guarantee that wrap will be able to protect a message of the computed length, since this ability may depend on the availability of system resources at the time that wrap is called. However, if the implementation itself imposes an upper limit on the length of messages that may be processed by wrap, the implementation should not return a value that is greater than this length. This should seems pretty weak. This isn't a hard limit? S 6.4.10. Instance of MessageProp that is used by the application to set the desired QOP and privacy state. Set the desired QOP to 0 to request the default QOP. Upon return from this method, this object will contain the actual privacy state that was applied to the message by the underlying mechanism. Just to be clear: if you ask for a specific QOP you always get it (or failure). This checking thing is only if you use 0? It would also be helpful to point out that QOP is mech-specific as noted in RFC 2743. S 6.4.21. What does requestInteg() mean? As far as I can tell the only thing you can do with a context is wrap() or getMIC(), both of which involve integrity. So what happens if you set it false? S 6.5.7. Does "privacy" here mean "confidentiality"? Can you clarify. EDITORIAL S 3.3. Please do not use the phrase "cryptographic checksum", I recognize that the terminology in this document is idiosyncratic because of age, but this isn't really a modern term. Typically we would now use "authentication tag" or "integrity tag" S 4.12.3. So an exception is thrown for an invalid token? S 5.3. gss_release_cred() is just eager, right? In any case the data will be cleaned up on GC? In any case you should make this clear. S 6.1.15. I wouldn't say you are "creating a previously exported context". You are either importing it or creating a new context from a previously exported one. S 6.2.1. // export and re-import the name byte[] exportName = mechName.export(); // create a new name object from the exported buffer GSSName newName = mgr.createName(exportName, GSSName.NT_EXPORT_NAME); This comment structure is confusing, because the first is just the export. I would change that. S 6.2.6. It's a bit unclear to me under what circumstances you can compare GSS names. I see you can do .equals() and export/memcmp, but can you compare strings? Perhaps after you canonicalize them? S 6.3.9. Does "union over all mechanisms" mean that if mechanism A supports INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT" S 6.4.X The presentation order here is weird because you show initSecContext() in the 6.4.1. example but then define it in 6.4.3 and then show another example that's reduced in 6.4.4. Perhaps you can consolidate these? -Ekr --f403045eb768ead0ec05522c00e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This document seems generally sound. There are some t= hings about this
API that confused/surprised me and seem perh= aps unwise, but given that
this is a bis, I will mostly confine m= y review to mostly calling them
out and asking you to make sure I= understand and that the document is
clear.

<= div>OVERALL
1. What is a fatal error?
The document desc= ribes exceptions as indicating "fatal errors".
What doe= s this mean for the state of the context. For instance,
if I rece= ive an exception from initSecContext(), does that mean
that it is= no longer possible to initiate it? Your example code
seems to tr= eat them as fatal for the context. What happens
if I try to use a= context after such an event?


2. Ho= w do I enforce properties for received messages?
I see that I can= request services for context initialization
(requestConf), and t= hat I can check whether a given message
was encrypted (getPrivacy= ) but it's not clear to me if this
causes the API to enforce = these rules for tokens that I
receive. Is that possible or do I j= ust need to check?

3. Are the request* flags() har= d limits? E.g., if I do
requestMutualAuth() do I get it or fail?<= /div>


4. It's a little unusual to hav= e a structure where you keep
calling initSecContext or acceptCont= ext() repeatedly. In
most APIs you would do like "setRole(Se= rver)" or
"setRoleClient(), and then "Handshake().=



DETAIL
S = 6.1.16.
Can addProviderAtFront() be used to add new providers whi= ch
the API would not normally use at all?

S 6.4.9.
=C2=A0 =C2=A0Successful completion of this call does n= ot guarantee that wrap will
=C2=A0 =C2=A0be able to protect a mes= sage of the computed length, since this
=C2=A0 =C2=A0ability may = depend on the availability of system resources at the
=C2=A0 =C2= =A0time that wrap is called.=C2=A0 However, if the implementation itself
=C2=A0 =C2=A0imposes an upper limit on the length of messages that = may be
=C2=A0 =C2=A0processed by wrap, the implementation should = not return a value that
=C2=A0 =C2=A0is greater than this length.=

This should seems pretty weak. This isn't a h= ard limit?

S 6.4.10.
=C2=A0 =C2=A0Instan= ce of MessageProp that is used by the
=C2=A0 =C2=A0application to= set the desired QOP and privacy
=C2=A0 =C2=A0state.=C2=A0 Set th= e desired QOP to 0 to request the
=C2=A0 =C2=A0default QOP.=C2=A0= Upon return from this method, this
=C2=A0 =C2=A0object will cont= ain the actual privacy state that
=C2=A0 =C2=A0was applied to the= message by the underlying
=C2=A0 =C2=A0mechanism.

=
Just to be clear: if you ask for a specific QOP you always get i= t
(or failure). This checking thing is only if you use 0?

It would also be helpful to point out that QOP is mech-sp= ecific
as noted in RFC 2743.


<= div>
S 6.4.21.
What does requestInteg() mean? As fa= r as I can tell the only thing
you can do with a context is wrap(= ) or getMIC(), both of which involve
integrity. So what happens i= f you set it false?

S 6.5.7.
Does "= privacy" here mean "confidentiality"? Can you clarify.
=


EDITORIAL
S 3.3.
Ple= ase do not use the phrase "cryptographic checksum", I recognize
that the terminology in this document is idiosyncratic because of<= /div>
age, but this isn't really a modern term. Typically
we would now use "authentication tag" or "integrity tag&quo= t;

S 4.12.3.
So an exception is thrown f= or an invalid token?


S 5.3.
gss_release_cred() is just eager, right? In any case the data will
=
be cleaned up on GC? In any case you should make this clear.

S 6.1.15.
I wouldn't say you are "creati= ng a previously exported context". You
are either importing = it or creating a new context from a previously
exported one.

S 6.2.1.

=C2=A0 =C2=A0// expo= rt and re-import the name
=C2=A0 =C2=A0byte[] exportName =3D mech= Name.export();

=C2=A0 =C2=A0// create a new name o= bject from the exported buffer
=C2=A0 =C2=A0GSSName newName =3D m= gr.createName(exportName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GSSName.NT_EXPORT_NAME);
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
This comment structure is confusing, because the first is jus= t
the export. I would change that.


<= /div>
S 6.2.6.
It's a bit unclear to me under what circum= stances you can compare GSS
names. I see you can do .equals() and= export/memcmp, but can you
compare strings? Perhaps after you ca= nonicalize them?


S 6.3.9.
Does "union over all mechanisms" mean that if mechanism A suppor= ts
INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCE= PT"

S 6.4.X
The presentation order = here is weird because you show initSecContext()
in the 6.4.1. exa= mple but then define it in 6.4.3 and then show
another example th= at's reduced in 6.4.4. Perhaps you can consolidate
these?

-Ekr

--f403045eb768ead0ec05522c00e1-- From nobody Sun Jun 18 20:42:09 2017 Return-Path: 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 6825D1272E1; Sun, 18 Jun 2017 20:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 BZ1BhTmLKwHp; Sun, 18 Jun 2017 20:42:06 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 E9B1E1275C5; Sun, 18 Jun 2017 20:42:00 -0700 (PDT) X-AuditID: 12074423-dbdff70000004d74-ba-5947480631eb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E9.97.19828.60847495; Sun, 18 Jun 2017 23:41:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5J3fudk013314; Sun, 18 Jun 2017 23:41:57 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5J3fqsM025386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Jun 2017 23:41:55 -0400 Date: Sun, 18 Jun 2017 22:41:52 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: kitten , draft-ietf-kitten-rfc5653bis@ietf.org Message-ID: <20170619034152.GZ39245@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrMvu4R5p8G+CosX3k0dZLFa8Psdu cXTzKhYHZo8lS34yeUx+3MYcwBTFZZOSmpNZllqkb5fAlbHp3h72ggvBFYuW7GdsYNzs1MXI ySEhYCLx59Vy1i5GLg4hgcVMEjMWPmaBcDYySnx+MZEZwrnKJDH9YCeQw8HBIqAqsWBHHkg3 m4CKREP3ZWYQW0RAQeLXnxMsIDazgLPE14l/mEBsYQEHie3LVoPV8AJtOzTrFFhcSCBA4vuZ dawQcUGJkzOfQPVqSdz495IJZBWzgLTE8n8cIGFOgUCJB6cvgo0RFVCW+Hv4HssERoFZSLpn IemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRlC4srso72B82ed9 iFGAg1GJh7fiuVukEGtiWXFl7iFGSQ4mJVHe16bukUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eIX0gHK8KYmVValF+TApaQ4WJXFecY3GCCGB9MSS1OzU1ILUIpisDAeHkgSvrjtQo2BRanpq RVpmTglCmomDE2Q4D9BwU0uQ4cUFibnFmekQ+VOMilLivKdcgRICIImM0jy4XlA6kcjeX/OK URzoFWHeoyBVPMBUBNf9CmgwE9Bg5jMuIINLEhFSUg2MYkuCeTdJ6/JvZn0esOdC+LzJ3rbf 7vT1Pgw4vmfZlopP0k+kZn2dntMbkvmu8vw5iTs7y34vPCed5vhu/rF4nnq1DwdjkyQl1A4l 8rOd4DsdPFuh2nzHjfPSi/gz3psv8AyrN+LI5Vh36PH1nWmTD2ySucR7mTNlMusU5lL5nhPa n/Jq1+5+psRSnJFoqMVcVJwIAJZULpQCAwAA Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 03:42:08 -0000 Hi Ekr, [authors: some questions remain, inline] On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote: > This document seems generally sound. There are some things about this > API that confused/surprised me and seem perhaps unwise, but given that > this is a bis, I will mostly confine my review to mostly calling them > out and asking you to make sure I understand and that the document is > clear. There are some bits of the GSSAPI that are strange, surprising, and confusing, yes ... I hear rumors that there are ideas for a GSSAPIv3 floating around, though nothing concrete yet. > OVERALL > 1. What is a fatal error? Fatal errors are specified as a specific list of GSS-API major status codes in RFC 2743, table 1 (things like GSS_S_BAD_MIC, GSS_S_FAILURE, GSS_S_UNAUTHORIZED, etc.), as opposed to informatory status codes like GSS_S_COMPLETE, GSS_S_CONTINUE_NEEDED, GSS_S_DUPLICATE_TOKEN (which is, confusingly, a fatal error during context establishment), etc. > The document describes exceptions as indicating "fatal errors". > What does this mean for the state of the context. For instance, > if I receive an exception from initSecContext(), does that mean > that it is no longer possible to initiate it? Your example code > seems to treat them as fatal for the context. What happens > if I try to use a context after such an event? I think this is also something specified at the GSS level, though RFC 2743 is unfortunately obscure about it. In the context-negotiating routines (GSS_Init_sec_context() and GSS_Accept_sec_context()), successful return codes are GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED, and other return codes (at the abstract GSS level) abort the context negotiation. This is buried in the descriptions for those two functions, though hopefully I made it a bit more clear in RFC 7546. (Once a context is established, then more robust error handling is available and a context can remain useful after a given message-handling function returns an error/throws an exception.) The Java bindings handle the GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED distinction differently than the C bindings do (with init/acceptSecContext returning the token to send to the peer, if any, and an isEstablished() function to query whether the local side is complete), but any other GSS-level result from the context-establishment functions is a GSS-level error, which presents as a java exception. Subsequent calls on the failed context are expected to also throw exceptions (something like the abstract GSS API GSS_S_NO_CONTEXT). > > 2. How do I enforce properties for received messages? > I see that I can request services for context initialization > (requestConf), and that I can check whether a given message > was encrypted (getPrivacy) but it's not clear to me if this > causes the API to enforce these rules for tokens that I > receive. Is that possible or do I just need to check? I think you just need to check. The GSSAPI is in general a request-and-check sort of affair, and even when confidentiality protection is enabled on a given context, a given message could be wrapped without confidentility protection. In the abstract API, GSS_Unwrap() has an explicit conf_state output value; the msgProp stuff is essentially specific to the Java bindings. > 3. Are the request* flags() hard limits? E.g., if I do > requestMutualAuth() do I get it or fail? They are not hard limits; this is just how the GSS-API works. You request things but have to check whether you got them. > > 4. It's a little unusual to have a structure where you keep > calling initSecContext or acceptContext() repeatedly. In > most APIs you would do like "setRole(Server)" or > "setRoleClient(), and then "Handshake(). Yes. The designs floating around for a GSSAPIv3 would most likely have such a common Handshake() API, but for v2 (and v1) we are stuck with separtae Init and Accept roles. > > > DETAIL Now we get into areas about which I am less certain; I'll loop in the authors alias to get a confirmation/correction. > S 6.1.16. > Can addProviderAtFront() be used to add new providers which > the API would not normally use at all? It seems likely. In the C bindings we generally have mechanisms globally enabled, and site-local customizations go in /etc/gss/mechs.d . > S 6.4.9. > Successful completion of this call does not guarantee that wrap will > be able to protect a message of the computed length, since this > ability may depend on the availability of system resources at the > time that wrap is called. However, if the implementation itself > imposes an upper limit on the length of messages that may be > processed by wrap, the implementation should not return a value that > is greater than this length. > > This should seems pretty weak. This isn't a hard limit? This is telling you what the ciphertext expansion is, but in reverse -- you put in the ciphertext size and receive back a plaintext input length that would produce that much ciphertext. > S 6.4.10. > Instance of MessageProp that is used by the > application to set the desired QOP and privacy > state. Set the desired QOP to 0 to request the > default QOP. Upon return from this method, this > object will contain the actual privacy state that > was applied to the message by the underlying > mechanism. > > Just to be clear: if you ask for a specific QOP you always get it > (or failure). This checking thing is only if you use 0? I believe so. GSS QOPs are for practical purposes deprecated and everyone uses 0. > It would also be helpful to point out that QOP is mech-specific > as noted in RFC 2743. Sure. (Maybe also that their use is disrecommended or something like that.) > > > S 6.4.21. > What does requestInteg() mean? As far as I can tell the only thing > you can do with a context is wrap() or getMIC(), both of which involve > integrity. So what happens if you set it false? If you set it to false, then some (hypothetical?) mechanism that only provides authentication could be used to establish a security context. There are also some other GSS functions like GSS_Pseudo_random() (RFC 4401) that could potentially be used on a security context that does not require per-message protections, though I don't know of Java bindings for that one, at least. Authentication-only is a valid workflow even just limited to this self-contained spec, using the security context negotiation to establish a context, query the peer's name with getSrcName(), and make authorization decisions based on that name. One might imagine someone trying to shoehorn OAuth2 into a GSS mechanism using something like that. > S 6.5.7. > Does "privacy" here mean "confidentiality"? Can you clarify. That's the only interpretation I can come up with that makes sense, but let's check with the authors. > > EDITORIAL > S 3.3. > Please do not use the phrase "cryptographic checksum", I recognize > that the terminology in this document is idiosyncratic because of > age, but this isn't really a modern term. Typically > we would now use "authentication tag" or "integrity tag" > > S 4.12.3. > So an exception is thrown for an invalid token? I think so. > > S 5.3. > gss_release_cred() is just eager, right? In any case the data will > be cleaned up on GC? In any case you should make this clear. I think so, though there is an implicit recommendation to destroy sensitive crypto material immediately after use. > S 6.1.15. > I wouldn't say you are "creating a previously exported context". You > are either importing it or creating a new context from a previously > exported one. "importing" would be more consistent with the language used by the C bindings. > S 6.2.1. > > // export and re-import the name > byte[] exportName = mechName.export(); > > // create a new name object from the exported buffer > GSSName newName = mgr.createName(exportName, > GSSName.NT_EXPORT_NAME); > > This comment structure is confusing, because the first is just > the export. I would change that. > > > S 6.2.6. > It's a bit unclear to me under what circumstances you can compare GSS > names. I see you can do .equals() and export/memcmp, but can you > compare strings? Perhaps after you canonicalize them? You have stumbled upon one of the worst warts on the GSS-API ;) It is confusing no matter whether you look at the abstract spec or language bindings. When you first create a name you end up with a generic "internal name", and certain operations can cause that to be transformed into a "mechanism name" that contains additional mechanism-specific information. The offically recommended way to compare GSS names is to GSS_Export_name() and use memcmp(), noting that you must GSS_Canonicalize_name() between GSS_Import_name() and GSS_Export_name(). >From RFC 2743: Note that the results obtained by using GSS_Compare_name() will in general be different from those obtained by invoking GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the exported names. The first series of operations determines whether two (unauthenticated) names identify the same principal; the second whether a particular mechanism would authenticate them as the same principal. These two operations will in general give the same results only for MNs. Sadly, lots of applications use GSS_Display_name() and strcmp(), which is something of a security vulnerability waiting to happen. I'm not entirely sure that I've answered your question, though. > > S 6.3.9. > Does "union over all mechanisms" mean that if mechanism A supports > INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT" Yes. Again quoting RFC 2743: GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for "cred_usage" if both of the following conditions hold: (1) there exists in the credential an element which allows context initiation using some mechanism (2) there exists in the credential an element which allows context acceptance using some mechanism (allowably, but not necessarily, one of the same mechanism(s) qualifying for (1)). > S 6.4.X > The presentation order here is weird because you show initSecContext() > in the 6.4.1. example but then define it in 6.4.3 and then show > another example that's reduced in 6.4.4. Perhaps you can consolidate > these? I'll leave that for the authors. -Ben From nobody Mon Jun 19 00:52:56 2017 Return-Path: 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 4220E129404; Mon, 19 Jun 2017 00:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 mEczIeraeGrX; Mon, 19 Jun 2017 00:52:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 1C45B128D3E; Mon, 19 Jun 2017 00:52:52 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5J7qo9S030833 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jun 2017 07:52:51 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5J7qod1025390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jun 2017 07:52:50 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5J7qnhC008677; Mon, 19 Jun 2017 07:52:49 GMT Received: from [10.191.8.143] (/10.191.8.143) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Jun 2017 00:52:48 -0700 To: Benjamin Kaduk , Eric Rescorla Cc: kitten , draft-ietf-kitten-rfc5653bis@ietf.org References: <20170619034152.GZ39245@kduck.kaduk.org> From: Weijun Wang Message-ID: <1101e365-22f9-f850-cfce-f1fa2a626422@oracle.com> Date: Mon, 19 Jun 2017 15:52:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170619034152.GZ39245@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 07:52:54 -0000 Hi Ekr, Thanks for the review. Below I keep questions that I can answer. For other general GSS-API questions, I could not answer better than Ben. Thanks a lot, Ben. On 06/19/2017 11:41 AM, Benjamin Kaduk wrote: > On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote: > >> S 6.1.16. >> Can addProviderAtFront() be used to add new providers which >> the API would not normally use at all? > > It seems likely. In the C bindings we generally have mechanisms > globally enabled, and site-local customizations go in > /etc/gss/mechs.d . Yes. A Java security provider advertises what service(s) it provides (for GSS-API, GssApiMechanism). If someone adds a provider that does not contains this service, it will be ignored. > >> S 6.5.7. >> Does "privacy" here mean "confidentiality"? Can you clarify. > > That's the only interpretation I can come up with that makes sense, > but let's check with the authors. Yes. > >> >> EDITORIAL >> S 3.3. >> Please do not use the phrase "cryptographic checksum", I recognize >> that the terminology in this document is idiosyncratic because of >> age, but this isn't really a modern term. Typically >> we would now use "authentication tag" or "integrity tag" We can use "integrity tag". >> >> S 4.12.3. >> So an exception is thrown for an invalid token? > > I think so. Correct, if the input token is not well-formed or was not correctly signed/encrypted by the peer, an exception will be thrown. > >> >> S 5.3. >> gss_release_cred() is just eager, right? In any case the data will >> be cleaned up on GC? In any case you should make this clear. > > I think so, though there is an implicit recommendation to destroy > sensitive crypto material immediately after use. Well... Java has a mechanism to provide a callback method called finalize() and hope GC will call it, and Oracle's SunNativeGSS provider (as a bridge to a native GSS-API lib) does provide one to release the native cred handle explicitly. That said, everyone is saying finalize() is unreliable and it usage is already deprecated. Even if finalize() is reliable, whether it should dispose the cred is not documented and up to the implementation. > >> S 6.1.15. >> I wouldn't say you are "creating a previously exported context". You >> are either importing it or creating a new context from a previously >> exported one. > > "importing" would be more consistent with the language used by the C > bindings. Yes. > >> S 6.2.1. >> >> // export and re-import the name >> byte[] exportName = mechName.export(); >> >> // create a new name object from the exported buffer >> GSSName newName = mgr.createName(exportName, >> GSSName.NT_EXPORT_NAME); >> >> This comment structure is confusing, because the first is just >> the export. I would change that. Correct. >> >> >> S 6.2.6. >> It's a bit unclear to me under what circumstances you can compare GSS >> names. I see you can do .equals() and export/memcmp, but can you >> compare strings? Perhaps after you canonicalize them? > > You have stumbled upon one of the worst warts on the GSS-API ;) > > It is confusing no matter whether you look at the abstract spec or > language bindings. When you first create a name you end up with a > generic "internal name", and certain operations can cause that to be > transformed into a "mechanism name" that contains additional > mechanism-specific information. The offically recommended way to > compare GSS names is to GSS_Export_name() and use memcmp(), noting > that you must GSS_Canonicalize_name() between GSS_Import_name() and > GSS_Export_name(). > >>From RFC 2743: > > Note that the results obtained by using GSS_Compare_name() will in > general be different from those obtained by invoking > GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the > exported names. The first series of operations determines whether > two (unauthenticated) names identify the same principal; the second > whether a particular mechanism would authenticate them as the same > principal. These two operations will in general give the same > results only for MNs. > > Sadly, lots of applications use GSS_Display_name() and strcmp(), > which is something of a security vulnerability waiting to happen. > > I'm not entirely sure that I've answered your question, though. Oracle's Java implementation looks like this: 1. If they are both canonicalized, compare the canonicalized mech element inside. 2. If only one is canonicalized, try to canonicalize the other one using this one's mechanism, and compare the result. 3. Otherwise, canonicalize both to Kerberos 5 and compare the result. By comparing 2 canonicalized mech elements, I mean comparing the type and the string or byte array name, which is equivalent to comparing the exported form. >> >> S 6.3.9. >> Does "union over all mechanisms" mean that if mechanism A supports >> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT" > > Yes. > > Again quoting RFC 2743: > > GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for > "cred_usage" if both of the following conditions hold: > > (1) there exists in the credential an element which allows context > initiation using some mechanism > > (2) there exists in the credential an element which allows context > acceptance using some mechanism (allowably, but not necessarily, > one of the same mechanism(s) qualifying for (1)). Same as in Java. > > >> S 6.4.X >> The presentation order here is weird because you show initSecContext() >> in the 6.4.1. example but then define it in 6.4.3 and then show >> another example that's reduced in 6.4.4. Perhaps you can consolidate >> these? > > I'll leave that for the authors. Yes, it's confused. Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() and acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in GSSContext (here, from the initiator's perspective). For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples shown here are only of the most common usage and can be read again in S 7. Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level deeper to become 6.4.3.1 etc and/or rename the title to "initSecContext Example code" etc. Or maybe the order looks weird because every class has an example as the first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about what this class is about. If this is the major reason, we can move these examples (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section. But then we will also need to indent/rename 6.1.17 and 6.1.19 to avoid two "Example code" in a row. Thanks, Weijun > > -Ben > From nobody Mon Jun 19 09:47:35 2017 Return-Path: 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 6A346131607 for ; Mon, 19 Jun 2017 09:47:34 -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 8S_zW2SPEUq1 for ; Mon, 19 Jun 2017 09:47:31 -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 1BC7D1315A4 for ; Mon, 19 Jun 2017 09:43:33 -0700 (PDT) Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (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 3wrxcg1J8qz1Hld; Mon, 19 Jun 2017 18:43:31 +0200 (CEST) X-purgate-ID: 152705::1497890611-00000816-582C79F0/0/0 X-purgate-size: 2950 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 mail08.wdf.sap.corp (Postfix) with ESMTP id 3wrxcg0W17z2xvD; Mon, 19 Jun 2017 18:43:31 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 0CB221A6BE; Mon, 19 Jun 2017 18:43:31 +0200 (CEST) In-Reply-To: <20170616040724.GO39245@kduck.kaduk.org> To: Benjamin Kaduk Date: Mon, 19 Jun 2017 18:43:31 +0200 (CEST) CC: 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: <20170619164331.0CB221A6BE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:47:34 -0000 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: 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). 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? 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). Kerberos with RC4 enctypes seemed to always have worked instantly after upgrading Windows domains, but AES enctypes seem to have never worked. Does anyone know about the exact details, and why RC4-enctypes seem to work so much better in Windows? (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 From nobody Tue Jun 20 20:46:25 2017 Return-Path: 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 8563D126C0F for ; Tue, 20 Jun 2017 20:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2SfPTtcN6Vm3 for ; Tue, 20 Jun 2017 20:46:22 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 EF0E01204DA for ; Tue, 20 Jun 2017 20:46:21 -0700 (PDT) X-AuditID: 12074423-645ff70000003130-70-5949ec0c1416 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 24.DE.12592.C0CE9495; Tue, 20 Jun 2017 23:46:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5L3kJMe018949; Tue, 20 Jun 2017 23:46:20 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5L3kFTc031577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2017 23:46:18 -0400 Date: Tue, 20 Jun 2017 22:46:15 -0500 From: Benjamin Kaduk To: Martin Rex Cc: kitten@ietf.org Message-ID: <20170621034615.GH39245@kduck.kaduk.org> References: <20170616040724.GO39245@kduck.kaduk.org> <20170619164331.0CB221A6BE@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619164331.0CB221A6BE@ld9781.wdf.sap.corp> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrcvzxjPSYOdhPYujm1exWPT+3sHs wOSxZMlPJo8pn7cyBjBFcdmkpOZklqUW6dslcGU8/faWpWCLaMWUzxdZGhinCXYxcnJICJhI nP17j6WLkYtDSGAxk8TeVWfZIJyNjBIrO6+xQjhXmSQmzbzFBNLCIqAqsfDhYVYQm01ARaKh +zIziC0iICsx7dobRhCbWUBYYvkakEmcHMICsRKnfnxnAbF5gda9WbsOLC4kkCbx/2wzG0Rc UOLkzCcsEL1aEjf+vQTaxQFkS0ss/8cBEuYUsJH4+/sXWLmogLLE38P3WCYwCsxC0j0LSfcs hO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxgsKU3UV5B+PLPu9DjAIc jEo8vBHKnpFCrIllxZW5hxglOZiURHn9bwKF+JLyUyozEosz4otKc1KLDzFKcDArifDKxQHl eFMSK6tSi/JhUtIcLErivOIajRFCAumJJanZqakFqUUwWRkODiUJXubXQI2CRanpqRVpmTkl CGkmDk6Q4TxAw8PngAwvLkjMLc5Mh8ifYlSUEuetfQWUEABJZJTmwfWC0ohE9v6aV4ziQK8I 874CqeIBpiC47ldAg5mABr844gEyuCQRISXVwMg+dfbyIxybxeJkQg4u4RFmFr6UHyklNXVx RF9izvfAXdN4t0jqiEw4wqDt+0IlZf96u6gqhhzV95PkCww+mohmlp0837t9k1od/5s69RUm 3aqvpzL/rf6Sdjm38Ud1WqUm3/dWCTEV8YDQfb3h58WFVPVDtnxiaLr2l7dD702I47PtC3Wy lFiKMxINtZiLihMB1NYpyP4CAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 03:46:23 -0000 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. > 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). Such an assumption is plausible. > 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? I don't know. > 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). Such a property is a natural consequence of a design that stores only the string2key'd keys and not the original passwords. (I think I heard vague rumors that very old AD DCs did in fact store actual user passwords, but cannot substantiate such rumors.) > > Kerberos with RC4 enctypes seemed to always have worked instantly after > upgrading Windows domains, but AES enctypes seem to have never worked. I suspect that what is going on is that RC4 always existed and is always supported, but AES was added later and so had backwards compatibility requirements that involved not breaking existing deployments, so you had to explicitly opt-in all parties to the exchange. It's hard to know for sure when the risk of breaking things has gone away and it's safe to enable the new feature by default. > > Does anyone know about the exact details, and why RC4-enctypes seem > to work so much better in Windows? > > (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). Your guesses seem reasonable to me, but I'm also just guessing, myself. -Ben From nobody Wed Jun 21 02:49:42 2017 Return-Path: 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 ; 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 ; 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 ; 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 Date: Wed, 21 Jun 2017 11:49:35 +0200 (CEST) CC: Martin Rex , 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 (Martin Rex) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Wed Jun 21 10:46:10 2017 Return-Path: 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 2B11F126CF6; Wed, 21 Jun 2017 10:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Eg02z1t07UG8; Wed, 21 Jun 2017 10:46:06 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 302CC128656; Wed, 21 Jun 2017 10:46:05 -0700 (PDT) X-AuditID: 12074425-7d5ff70000003ab1-32-594ab0db6c46 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A6.92.15025.BD0BA495; Wed, 21 Jun 2017 13:46:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5LHk2is023738; Wed, 21 Jun 2017 13:46:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5LHjw4h012961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2017 13:46:01 -0400 Date: Wed, 21 Jun 2017 12:45:58 -0500 From: Benjamin Kaduk To: Martin Rex Cc: kitten@ietf.org, curdle@ietf.org Message-ID: <20170621174558.GK39245@kduck.kaduk.org> References: <20170621034615.GH39245@kduck.kaduk.org> <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHtng1ekwY5vjBZbF85itji6eRWL Re/vHcwOzB5Llvxk8pjyeStjAFMUl01Kak5mWWqRvl0CV8a6Y5+YC66IVCz+c4m9gfGQQBcj J4eEgInEor/vGbsYuTiEBBYzSUzbs44RJCEksJFRYtEVLojEVSaJVW0r2UASLAKqEjNXPmIH sdkEVCQaui8zg9giArIS0669AWtmBopvetrECmILC8RKnPrxnaWLkYODF2hb20owU0ggTeL/ ZbAbeAUEJU7OfMIC0aklcePfSyaQEmYBaYnl/zhAwpwCNhI7fn5jArFFBZQl/h6+xzKBUWAW ku5ZSLpnIXQvYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERSq7C6qOxjn /PU6xCjAwajEw2tR5xUpxJpYVlyZe4hRkoNJSZS3YxlQiC8pP6UyI7E4I76oNCe1+BCjBAez kgjvnXVAOd6UxMqq1KJ8mJQ0B4uSOK+4RmOEkEB6YklqdmpqQWoRTFaGg0NJgtd5PVCjYFFq empFWmZOCUKaiYMTZDgP0HCdNSDDiwsSc4sz0yHypxgVpcR5X4FsFQBJZJTmwfWCUolE9v6a V4ziQK8I82oAE4sQDzANwXW/AhrMBDT4xREPkMEliQgpqQZGua2hVU3v+85Vtze6fJy0NuXe qiU+P4sW5X/+LZHMuiDu7ZVVTdm8TNnXAlqf1Ni9eirLvPsDz+vbZkvEpv110zX8cFhf2PmN wbxVt9rSnD0j7EJzP7utnWvhdv7PpLXTM7Zkym0OkWeMeju/2uFcrJf63DUH/Y/YbHTb2Cfs yHTE7UPlc9Z3SizFGYmGWsxFxYkAaYfDZwADAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:46:08 -0000 Adding curdle@ for discussion of potential content changes to the draft... On Wed, Jun 21, 2017 at 11:49:35AM +0200, Martin Rex wrote: > 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) It sounds like you are asking for the addition of some text along the lines of: Software support is only a bare minimum requirement for deprecating RC4 enctypes; there may be additional logistical considerations involved such as provisioning AES keys for all principals and updating software configuration to enable AES and disable deprecated encryption types. Is that something you are asking for? Thanks, Ben > 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 From nobody Wed Jun 21 12:39:07 2017 Return-Path: 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 C54DF1241FC for ; Wed, 21 Jun 2017 12:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 5uBSdaXceLAd for ; Wed, 21 Jun 2017 12:39:05 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B88129415 for ; Wed, 21 Jun 2017 12:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1498073922; x=1498678722; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=EutfDKLijbA71MVk2jRWYU wXArnZCv+guRJje3U/QYk=; b=Rltd6TNpT4nFjoSu00aMEesRC5M64vmsr9AlYN 0zg/r4ZGQhUejLgXU8EYwq/RmbYgGVi3YP8T7TUCzPkqtThfRp0husVIk65jMm0/ ZZnOo7CE+M2mYfVXmZ5xQot89Pf9Jr6FCWt7234EGOowJ5QkXXfZ34Aik9UpiBv5 /Qjkw= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Wed, 21 Jun 2017 15:38:42 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Wed, 21 Jun 2017 15:38:42 -0400 Received: from [IPv6:2001:470:1f07:f77:7174:9244:a061:80d1] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v17.0.2) with ESMTPSA id md50001371673.msg; Wed, 21 Jun 2017 15:38:40 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:7174:9244:a061:80d1 X-MDHelo: [IPv6:2001:470:1f07:f77:7174:9244:a061:80d1] X-MDArrival-Date: Wed, 21 Jun 2017 15:38:40 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=13456c59c6=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-CAV-Result: clean To: kitten@ietf.org, curdle@ietf.org References: <20170621034615.GH39245@kduck.kaduk.org> <20170621094935.AF6161A6BF@ld9781.wdf.sap.corp> <20170621174558.GK39245@kduck.kaduk.org> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: Date: Wed, 21 Jun 2017 15:38:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170621174558.GK39245@kduck.kaduk.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040206090204090807030301" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:39:07 -0000 This is a cryptographically signed message in MIME format. --------------ms040206090204090807030301 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/21/2017 1:45 PM, Benjamin Kaduk wrote: > It sounds like you are asking for the addition of some text along > the lines of: >=20 > Software support is only a bare minimum requirement for deprecating > RC4 enctypes; there may be additional logistical considerations > involved such as provisioning AES keys for all principals and > updating software configuration to enable AES and disable deprecated > encryption types. >=20 > Is that something you are asking for? >=20 > Thanks, In my opinion, such text is inappropriate for an RFC. The deprecation of the encryption type is a protocol action. The RFC is not guidance for system administrators. Such guidance should come from the protocol implementations. As such I believe the addition of text similar to the above is unnecessary for publication. Jeffrey Altman --------------ms040206090204090807030301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJswggYCMIIE6qADAgECAhBAAVgjEN7WFoCIXylZ1uvSMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMjQxOFoXDTE3MTEwMjAzMjQxOFowgZYxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMTAwLgYKCZImiZPyLGQBARMgN0YwMDAwMDEw MDAwMDE1ODIzMTBERUE3MDAwMDA3QjQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDPaPDUdwWkzLcNsJjjlDs5lo4ySDKmCgzQsuDt+VY3wP0IZBbu8f/LM3zWCH7zVRJ/XuY5 qN44jFEXwj5fGY71Esm5pKv5sUpys6Q3c6BKXiHv/IUusI3qTJ46QBEAiHu2lxB75UnIYgm+ ZbKmcAR48Z1Sl/Ku86e9GPuts9R51SeHW1pjq89LAi6C0ERuAUIK0rVZGDmKWtRNs9EykXzk mU2Z1ZLuPL0jIggFPeT8TyH6TH/XvapbC+7rHJrzuBY4NDqLgqDJUf0JidL9JeK9+IxxPCab EbVmOf5sBgO5mg92l4+f+Q4xefZcI4C7RPFdRTRWsQs7Z3DpE28BDbjDAgMBAAGjggKlMIIC oTAOBgNVHQ8BAf8EBAMCBaAwgYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDov L2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFs aWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgw FoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASwGA1UdIASCASMwggEfMIIB GwYLYIZIAYb5LwAGCwEwggEKMEoGCCsGAQUFBwIBFj5odHRwczovL3NlY3VyZS5pZGVudHJ1 c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDCBuwYIKwYBBQUHAgIw ga4agatUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29y ZGFuY2Ugd2l0aCAKSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91 bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5 L3RzL2luZGV4Lmh0bWwwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3ZhbGlkYXRpb24uaWRl bnRydXN0LmNvbS9jcmwvdHJ1c3RpZGNhYTEyLmNybDAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB0GA1UdDgQWBBSP11Voh/Sg9hmecftn2BV5ZQd9OTAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAC9cnqRj+ViE efFsiYNMUC8tZf6PXcWDecOR5Pdv/Vd/O6y10mYyilPrcd0sJux1idTZIOzHAsh36BfBdNSt BFAuBZD66L649U3XqBnh9nbuzmCwNc3tWjOaY/Xe7R90lqrXaW0Dw0U++zwmNyCO2CRgBdrU 8cTqFpOtpe/gCAMhjajrUfb+m8Vcd5R0RVIvdljblqv2t9IXQIHwWSm8E7v302z7yW4o4iPH kegez5vq37ICikQjkkVyAJr0wtirJyQuFzMgpoWVpm0CKBiMwJPki2kiHlNiMHBr2ch4fC+H SjbMg4OzTZJCz1xhKvpyRDOM8JRb2BNSU8JjmrxZgFIwggaRMIIEeaADAgECAhEA+d5Wf8lN DHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUw MjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYy maAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ 00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGV TtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQO ORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEA AaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJj aWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24u aWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU 7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggET MIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVu dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhp cyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdp dGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0 cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4 Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv bS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0G CSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3w Wzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp /7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq 0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIw pigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2h e8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQ epmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUg YOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAg prpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7Vu EP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEB ME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDYyMTE5MzgzN1owLwYJKoZI hvcNAQkEMSIEIEsb8ekdJXn7gDhyE5lUoN/iAd3Fq3pC19Ar36fIlKRUMF0GCSsGAQQBgjcQ BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1 c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAWd0Fsv22CvqVuLmz67Qw sY92GEwzAuJ3BZa9Y5MoRRO32LBwcDbYGRqEa7ce805KxN6uGQVlBDxU1Q5xTtcv2SGp3bBl mrDreVkKSHtbp4ELkFxByq0ooaO2v/PUam3o0vcQ48lIk8fl2VuW9SKY7NTbVJVpcMoVDMzC v4KY3b1cxTeHzL3aOxC8ARDeLDkftmiX6wErZh7JX6nfbDvFD2LCpuJBHK1m5s6aJPks7stm Mvhqgyp+U143BJToco3RkW0JB5MrTg0UOLvCJNLN+cmmoCf26i63Ac3aGoTaXo4nO51gLlWu JG1FAF7Iz95InUF8CcAdkmT1anvrEwvKdAAAAAAAAA== --------------ms040206090204090807030301-- From nobody Wed Jun 21 13:31:52 2017 Return-Path: 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 ; 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 ; 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 ; 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 To: "mrex@sap.com" , Benjamin Kaduk CC: "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: 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:31:51 -0000 inline -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, June 19, 2017 9:44 AM To: Benjamin Kaduk Cc: kitten@ietf.org Subject: Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-di= e-die-die-03.txt Benjamin Kaduk wrote: >=20 > As far as I know, this version is ready to be sent to the IESG for=20 > approval. >=20 > The -03 adds this text (including known typo): >=20 > 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. >=20 > It would be good to get independent confirmation of those=20 > dates/release numbers; the windows ones I took from Michiko's email=20 > and the Heimdal one from Chaskiel's mail. (I did the MIT research=20 > 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 Kerb= eros and the RC4-enctype: [Michiko Short] Not sure this is only a MS issue.=20 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 l= evel 2008 or higher (rather than domain functional level 2003). [Michiko Short] correct. This is why we had a matrix published with the AE= S 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 th= at Vista announcement.=20 Can Active Directory store AES enctype longterm secrets of service accounts= (for 2-token Kerberos authentication) when the domain controllers are Wind= ows 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 i= t knows. When we shipped the GP to configure etype support we had to fix th= e DC logic to create all keys it knew vs supported to avoid the problem tha= t 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 t= he DC which is not understood by one or move DCs.=20 If not, is it documented anywhere that _after_ upgrading a windows domain t= o 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, o= therwise only RC4-enctypes and NTLM-authentication will work for that servi= ce account (unless storing passwords with reversible encryption has been en= abled 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.=20 Kerberos with RC4 enctypes seemed to always have worked instantly after upg= rading Windows domains, but AES enctypes seem to have never worked. [Michiko Short] RC4 is supported by every version of Windows so it will wor= k as it is the default. AES came later and unfortunately requires a lot of = manual work.=20 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.=20 (I'm not a real Kerberos user myself, but I've worked on a number of suppo= rt 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 From nobody Thu Jun 22 10:36:17 2017 Return-Path: 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 6F84B129B0E for ; Thu, 22 Jun 2017 10:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Mfk9W3qCaeBr for ; Thu, 22 Jun 2017 10:36:15 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93FD1270AC for ; Thu, 22 Jun 2017 10:36:14 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id 63so8720295ywr.0 for ; Thu, 22 Jun 2017 10:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=M6fVVx/G21IFzTmSSjP11fxJCc/tzqxfSHijMT1W+9Y=; b=vG0dwDOI0Ch1fq+UvICCHhK4SFA0GqanLLjbiKBu0h3XkrvpPOvA8vo5c75/wNVI1Q x1lUpc3pRY8sSs1Xw+wL7kxsrwvlSa2817i7pv+wMBVcDgOj3FF8ezSEr5IMHMLvtrEk IV2g1u3rLWS9FCDTV5CuuKrSBBzWAZhGLk6umLbFln8T9tQn1rkuoGcoNOm0ywM9z58J 0jbfQWV8dxh/08TimAG2lMjbD7lZUTNXZC+JM7Eaz35kX9XUU7Rlkzm5uhZI5qGdXi/O aeTDAiPWHZ5NkBjWQIh0jbwX3ECUOnmfnbyk5C4VGVYt0t1hqxG8jOUyFBraDEggNirm /m5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M6fVVx/G21IFzTmSSjP11fxJCc/tzqxfSHijMT1W+9Y=; b=SuxPozZw7vaDFRIi2yUNYCs1tNuVvILAcRz8T8h1v53HReV4Dj++LZmLPicQ9LKzPf QcyDrpBvpYd37Odrdj5LO+JWQz6uPmh9B0Pua1yMeq5Fwt98Mme1nAUNjGF8EORUdoF8 35p5hWvKHq9kyhsBHDMxXmg3i7J8bTSY/DHc9+ZSzOrpPKh5Sg7oBcdEIwBY8jX6xjts OL2k3xYzQDg5VB1p5bQQ1mjZhPWmbADpWCxhTeZUT3KAbOWNxoDY1Ba5ZQBTZCy0oFna 2MkfGe47938UhUHZW66Ar5XZievpnJwYZXKQtIsVCDHk/WVD0ZIuOWY1r/LtYdwEH4Ul t1+w== X-Gm-Message-State: AKS2vOzC9KZ8av4OOJluQ+I0YOC1OUrOyriLZxa5dwI5ko+h4uUpDJ8y FdRFNIx0kdVHVpdamMJlALco5aKK8+Da07vQHg== X-Received: by 10.129.43.68 with SMTP id r65mr2695833ywr.24.1498152973645; Thu, 22 Jun 2017 10:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 22 Jun 2017 10:35:33 -0700 (PDT) From: Eric Rescorla Date: Thu, 22 Jun 2017 10:35:33 -0700 Message-ID: To: kitten , Kathleen Moriarty Content-Type: multipart/alternative; boundary="001a1141e798d06b0805528feb30" Archived-At: Subject: [kitten] Chair volunteers X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:36:16 -0000 --001a1141e798d06b0805528feb30 Content-Type: text/plain; charset="UTF-8" Hi folks, Matt Miller has expressed a desire to resign as chair. If you're interested in co-chairing, please e-mail Kathleen and myself. Thanks to Matt for his service and thanks in advance to the volunteers. Thanks, -Ekr --001a1141e798d06b0805528feb30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Matt Miller h= as expressed a desire to resign as chair. If you're interested
in co-chairing, please e-mail Kathleen and myself.

Thanks to Matt for his service and thanks in advance to the volunteers.<= /div>

Thanks,
-Ekr

<= /div> --001a1141e798d06b0805528feb30-- From nobody Fri Jun 23 05:03:59 2017 Return-Path: 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 3E222128DF3; Fri, 23 Jun 2017 05:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 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, RCVD_IN_SORBS_SPAM=0.5, 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 jUGokK51kq4Q; Fri, 23 Jun 2017 05:03:44 -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 DA7FB12EAB4; Fri, 23 Jun 2017 05:03:43 -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 3wvHCy0vkVz1JNd; Fri, 23 Jun 2017 14:03:42 +0200 (CEST) X-purgate-ID: 152705::1498219422-00000861-5EF00B1F/0/0 X-purgate-size: 2879 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 3wvHCx616HzGp0x; Fri, 23 Jun 2017 14:03:41 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C93721A6BE; Fri, 23 Jun 2017 14:03:41 +0200 (CEST) In-Reply-To: <20170621174558.GK39245@kduck.kaduk.org> To: Benjamin Kaduk Date: Fri, 23 Jun 2017 14:03:41 +0200 (CEST) CC: Martin Rex , kitten@ietf.org, curdle@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: <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 12:03:46 -0000 Benjamin Kaduk wrote: > Adding curdle@ for discussion of potential content changes to the > draft... > > On Wed, Jun 21, 2017 at 11:49:35AM +0200, Martin Rex wrote: >> >> 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) > > > It sounds like you are asking for the addition of some text along > the lines of: > > Software support is only a bare minimum requirement for deprecating > RC4 enctypes; there may be additional logistical considerations > involved such as provisioning AES keys for all principals and > updating software configuration to enable AES and disable deprecated > encryption types. > > Is that something you are asking for? Yes, thank your. This sounds good to me. I consider it even more helpful than the reference to particular versions of particular OpenSource Kerberos implementations, because this is a characteristic that is sort-of implied by how kerberos-enctypes keys are created (derived by string2key) and probably affect all implementations of Kerberos, yet it is non-obvious to consumers of the technology. There is a substantial difference between cipher suites in TLS, where key length, strength and algorithm for the symmetric crypto is mostly irrelevant to the (PKI) credentials, and where using new TLS cipher suites and deprecating old TLS cipher suites does not have a rekeying requirement. I do believe that it is very appropriate to provide such kind of a guidance in an RFC, so that it this recommendation for deprecation becomes more comprehensible and the trade-offs clearer to mere consumers of the Kerberos technology, readers that aren't Kerberos protocol experts and senior Kerberos implementers. When making admins sufficiently aware of predictable interop-problems, we may actually see more administrative deprecation of weak Kerberos enctypes than leaving them in the dark, and it helps reducing the amount of stumped users, helpdesks and admins. -Martin From nobody Sat Jun 24 07:38:59 2017 Return-Path: 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 25BC9126CC7 for ; Sat, 24 Jun 2017 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 YwmFQzmhDw3m for ; Sat, 24 Jun 2017 07:38:57 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 62966124D68 for ; Sat, 24 Jun 2017 07:38:57 -0700 (PDT) X-AuditID: 1209190c-0ddff70000001227-e4-594e797e045a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.FF.04647.E797E495; Sat, 24 Jun 2017 10:38:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v5OEcsWk000396 for ; Sat, 24 Jun 2017 10:38:54 -0400 Received: from localhost ([10.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5OEcrVQ012124 for ; Sat, 24 Jun 2017 10:38:53 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sat, 24 Jun 2017 10:38:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUixG6noltf6RdpsOGOmMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfd2I1PBX72Kk7vOMTUwHlTtYuTkkBAwkbi5ZhJLFyMXh5DA YiaJpRfOMEM4xxkltl09zgZSJSTwhVFiybMMEJtNQFli/f6tLCC2iICwxO6t75hBbGEBK4l3 m44wgdgsAqoSq7ZvB4vzChhKzH+2nBHCFpQ4OfMJWC+zgITEwRcvmCcwcs9CkpqFJLWAkWkV o2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZGUBBwSvLsYDzzxusQowAHoxIPb4a3 b6QQa2JZcWXuIUZJDiYlUd7YMz6RQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4ecL9IoV4UxIr q1KL8mFS0hwsSuK8EhqNEUIC6YklqdmpqQWpRTBZGQ4OJQle4QqgRsGi1PTUirTMnBKENBMH J8hwHqDhkmDDiwsSc4sz0yHypxhVORqmb/3CJMSSl5+XKiXOOwVkkABIUUZpHtycV4ziQO8I 8yaBZHmAkQ434RXQcCag4TPW+IAML0lESEk1MCa6sHs0NhZuj8r7tZqdLT1vvq60aPDX1lPV b9OPsBWf1Hy6NTT40maV4B0dJ/guRz2Zrm8f6buCm1XgurKt+Bb94OO+/SZ/61lcJmmsF36a tLLoj5Hu03cyDzLveIl/OdNjvV95583/nn+jp31nmy3/LWmC4POZHlknDe1DDgv5vaot9bf8 osRSnJFoqMVcVJwIAAHFxKyxAgAA Archived-At: Subject: [kitten] Review of draft-ietf-kitten-channel-bound-flag-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 14:38:59 -0000 Here are my semantic concerns: Section 1: * Paragraph 2 discusses taking advantage of implementation behavior to deploy channel bindings on initiators first, then acceptors. A naive reader might conclude that this is sufficient, because an acceptor can be configured to not provide channel bindings if it does not wish to require all initiators to provide them as well. It would be helpful to explain that the value obtained by providing channel bindings on the acceptor without enforcing them, which is that participating initiators gain protection against MITM attacks. * Paragraph 4 should either be omitted or made more specific. It's interesting to me that SSPI implements these semantics (all of them or just the existence of a channel-bound ret flag?), but that should be stated directly or just skipped. Section 1.1: * "[RFC2743] seems to indicate that mechanisms must ignore channel bindings when one party provided none." What part of RFC 2743? How does this statement square with "This facility is meant to be all-or-nothing" in the introduction? * The remainder of this paragraph seems redundant with the top material in section 1. Sections 1.2-1.4: these sections are kind of informal and may not all be of interest to implementors. I think it's worth saying that gss_create_sec_context() is expected to lead to simpler stepper functions in the future, but the rest can probably go. Section 2.2: * The term "understood" is a little unclear, and aside from the new channel-bound flag, it's unclear how a mechanism should process the absence of an understood flag. Out of band, Nico has said that he doesn't expect the mechanism to pare down its set of ret_flags based on ret_flags_understood (e.g. it should not omit the mutual-auth flag if the application doesn't include it in ret_flags_understood). So the mechanism should only consult ret_flags_understood when it really needs to know, such as with the new channel-bound flag. The draft should make that clear. * The new gss_set_context_flags() call allows us to specify req_flags to gss_accept_sec_context(), which is an intentional addition. However, we have no immediate use for it, and the draft doesn't make it clear whether an existing mechanism should do anything with existing req_flags on the acceptor. Section 2.2.1: * Naming the parameter "ret_flags" rather than "ret_flags_understood" in the C bindings appears to create some confusion as to what should be done with the flags. Section 2.4 and 2.5: * For background, the overall purpose of this draft is to make channel bindings fit the GSS-API model where the caller asks for things and then checks whether it actually got them. On the initiator it is awkward to achieve this goal, since the krb5 mech does not have channel binding confirmation and other existing mechanisms may not have it either. Thus the draft specifies new mechanism attributes to express whether a mechanism has channel binding confirmation, and a request flag to filter SPNEGO mechanisms according to whether they can confirm channel bindings. Nico has a plan to extend the krb5 mech's mutual-auth response to confirm channel bindings, likely using GSS_C_CB_CONFIRM_FLAG (2048) in the 8003 checksum flags value as a negotiation bit. * GSS_C_MA_CBINDING_MAY_CONFIRM does not really express where the krb5 mech will wind up after the mutual auth response is extended, as channel bindings will only be confirmed if the initiator requests mutual auth, and possibly only if the mechanism choose an RFC 4121 enctype. * The specification of req_cb_confirmation_flag is wishy-washy as to whether it allows SPNEGO to choose a mechanism that might only possibly be able to confirm channel bindings. I'm not sure that this request flag will ever wind up being useful to callers. * "the pseudo-mechanism MUST NOT negotiate any mechanisms that lack the GSS_C_MA_CBINDING_CONFIRM or GSS_C_MA_CBINDING_MAY_CONFIRM mechanism attributes" reads to me as "mechanisms must have both attributes to qualify", but from context I think it is supposed to mean "mechanisms must have one of the two attributes to qualify". Section 2.6: * Here we specify the behavior of gss_delete_sec_context on an empty context. We should also specify the behavior an the application tries to use an empty context with gss_inquire_sec_context(), gss_wrap(), etc.. Per discussion with Nico, doing so should result in GSS_S_NO_CONTEXT, just as if the application supplied GSS_C_NO_CONTEXT to those functions. Section 3: * The third requirement says that init_sec_context SHOULD be lax about the acceptor not providing channel bindings, but notes that "It is possible that not all security mechanism protocols can implement this requirement easily." In contrast, the fourth requirement says that init_sec_context MUST be lax if the caller understands ret_channel_bound_flag. The fourth requirement doesn't seem to square with the proviso on the third. If a mechanism can conform to the fourth requirement, then it seems like it can also conform to the third requirement. And here are a few copy-editing notes: Abstract: * "This document addresses both, the..." should not have the comma. Section 2.2: * undestands -> understands * "individual elements -one-per-flag- instead" -> "individual elements--one per flag--instead" Section 3: * There are multiple instances of "Whenever [something] shall have [done something]", which doesn't look right to me. Omitting the word "shall", and sometimes changing "have" to "has", makes them look better. * "Whenever both, the initiator..." should not have the comma. * "This is a restatement... restated for the reader's convenience" should either omit "a restatement of" or the final clause. From nobody Sun Jun 25 10:00:14 2017 Return-Path: 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 E7A671273B1 for ; Sun, 25 Jun 2017 10:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 hHuu287fLPl4 for ; Sun, 25 Jun 2017 10:00:10 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 B323B1201F2 for ; Sun, 25 Jun 2017 10:00:10 -0700 (PDT) X-AuditID: 1209190e-3a3ff7000000676b-45-594fec19279f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.B6.26475.91CEF495; Sun, 25 Jun 2017 13:00:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5PH079n003508; Sun, 25 Jun 2017 13:00:08 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5PH03lr021977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jun 2017 13:00:06 -0400 Date: Sun, 25 Jun 2017 12:00:04 -0500 From: Benjamin Kaduk To: Greg Hudson , nico@cryptonector.com Cc: kitten@ietf.org Message-ID: <20170625170003.GB17840@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrSv5xj/S4OgrLYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4dHciS8FDo4rND2YyNzC+Ue9i5OSQEDCR WNjYwtzFyMUhJLCYSeLqqYNQzkZGiV0zz0E5V5kkOjbMYuti5OBgEVCVaJlZCtLNJqAi0dB9 mRkkLCJgIfF4giFImFlAWGL5mrNg1cIC7hLz+hJBwrxAu+7/3s0MYgsJGEq8vXeNCSIuKHFy 5hMWiFYtiRv/XjKBtDILSEss/8cBEuYUMJL4dK2XFcQWFVCW+Hv4HssERoFZSLpnIemehdC9 gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRnCASvLtYJzU4H2IUYCDUYmH N2CtX6QQa2JZcWXuIUZJDiYlUd5Gf/9IIb6k/JTKjMTijPii0pzU4kOMEhzMSiK87c+Bcrwp iZVVqUX5MClpDhYlcV5xjcYIIYH0xJLU7NTUgtQimKwMB4eSBO+W10CNgkWp6akVaZk5JQhp Jg5OkOE8QMMzHoIMLy5IzC3OTIfIn2LU5WiYvvULkxBLXn5eqpQ4736QQQIgRRmleXBzQIlF Int/zStGcaC3hHn/vQSq4gEmJbhJr4CWMAEtmbHGB2RJSSJCSqqBMfFqoFdc5bHJX9+9aONr aP3/M+L72sDTPlfuONx9G6V/0Ff2wwq3XVo8/QKLH1V/u7Ve/JtWZ5fPQn3eV7bLma78yfqk 07pY7JPwftMFkflX2Vw/xL3s3nhz0ovyCo/0VT7Pt51OPZhelM0UcoOZkefv5SOKxhPjtesf ybp4pR0LSS9aEXlWQomlOCPRUIu5qDgRAP2sRYQHAwAA Archived-At: Subject: Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 17:00:13 -0000 Thanks for the review, Greg. Nico, will you be able to prepare a document update? (one note inline) On Sat, Jun 24, 2017 at 10:38:53AM -0400, Greg Hudson wrote: > Here are my semantic concerns: > > Section 1: > > * Paragraph 2 discusses taking advantage of implementation behavior to > deploy channel bindings on initiators first, then acceptors. A > naive reader might conclude that this is sufficient, because an > acceptor can be configured to not provide channel bindings if it > does not wish to require all initiators to provide them as well. It > would be helpful to explain that the value obtained by providing > channel bindings on the acceptor without enforcing them, which is > that participating initiators gain protection against MITM attacks. > > * Paragraph 4 should either be omitted or made more specific. It's > interesting to me that SSPI implements these semantics (all of them > or just the existence of a channel-bound ret flag?), but that should > be stated directly or just skipped. > > Section 1.1: > > * "[RFC2743] seems to indicate that mechanisms must ignore channel > bindings when one party provided none." What part of RFC 2743? How > does this statement square with "This facility is meant to be > all-or-nothing" in the introduction? > > * The remainder of this paragraph seems redundant with the top material > in section 1. > > Sections 1.2-1.4: these sections are kind of informal and may not all > be of interest to implementors. I think it's worth saying that > gss_create_sec_context() is expected to lead to simpler stepper > functions in the future, but the rest can probably go. > > Section 2.2: > > * The term "understood" is a little unclear, and aside from the new > channel-bound flag, it's unclear how a mechanism should process the > absence of an understood flag. Out of band, Nico has said that he > doesn't expect the mechanism to pare down its set of ret_flags based > on ret_flags_understood (e.g. it should not omit the mutual-auth > flag if the application doesn't include it in ret_flags_understood). > So the mechanism should only consult ret_flags_understood when it > really needs to know, such as with the new channel-bound flag. The > draft should make that clear. > > * The new gss_set_context_flags() call allows us to specify req_flags > to gss_accept_sec_context(), which is an intentional addition. > However, we have no immediate use for it, and the draft doesn't make > it clear whether an existing mechanism should do anything with > existing req_flags on the acceptor. > > Section 2.2.1: > > * Naming the parameter "ret_flags" rather than "ret_flags_understood" > in the C bindings appears to create some confusion as to what should > be done with the flags. > > Section 2.4 and 2.5: > > * For background, the overall purpose of this draft is to make channel > bindings fit the GSS-API model where the caller asks for things and > then checks whether it actually got them. On the initiator it is > awkward to achieve this goal, since the krb5 mech does not have > channel binding confirmation and other existing mechanisms may not > have it either. Thus the draft specifies new mechanism attributes > to express whether a mechanism has channel binding confirmation, and > a request flag to filter SPNEGO mechanisms according to whether they > can confirm channel bindings. Nico has a plan to extend the krb5 > mech's mutual-auth response to confirm channel bindings, likely > using GSS_C_CB_CONFIRM_FLAG (2048) in the 8003 checksum flags value > as a negotiation bit. > > * GSS_C_MA_CBINDING_MAY_CONFIRM does not really express where the krb5 > mech will wind up after the mutual auth response is extended, as > channel bindings will only be confirmed if the initiator requests > mutual auth, and possibly only if the mechanism choose an RFC 4121 > enctype. > > * The specification of req_cb_confirmation_flag is wishy-washy as to > whether it allows SPNEGO to choose a mechanism that might only > possibly be able to confirm channel bindings. I'm not sure that > this request flag will ever wind up being useful to callers. > > * "the pseudo-mechanism MUST NOT negotiate any mechanisms that lack > the GSS_C_MA_CBINDING_CONFIRM or GSS_C_MA_CBINDING_MAY_CONFIRM > mechanism attributes" reads to me as "mechanisms must have both > attributes to qualify", but from context I think it is supposed to > mean "mechanisms must have one of the two attributes to qualify". I agree that's the apparent intent. -Ben > Section 2.6: > > * Here we specify the behavior of gss_delete_sec_context on an empty > context. We should also specify the behavior an the application > tries to use an empty context with gss_inquire_sec_context(), > gss_wrap(), etc.. Per discussion with Nico, doing so should result > in GSS_S_NO_CONTEXT, just as if the application supplied > GSS_C_NO_CONTEXT to those functions. > > Section 3: > > * The third requirement says that init_sec_context SHOULD be lax about > the acceptor not providing channel bindings, but notes that "It is > possible that not all security mechanism protocols can implement > this requirement easily." In contrast, the fourth requirement says > that init_sec_context MUST be lax if the caller understands > ret_channel_bound_flag. The fourth requirement doesn't seem to > square with the proviso on the third. If a mechanism can conform to > the fourth requirement, then it seems like it can also conform to > the third requirement. > > And here are a few copy-editing notes: > > Abstract: > > * "This document addresses both, the..." should not have the comma. > > Section 2.2: > > * undestands -> understands > > * "individual elements -one-per-flag- instead" -> > "individual elements--one per flag--instead" > > Section 3: > > * There are multiple instances of "Whenever [something] shall have > [done something]", which doesn't look right to me. Omitting the > word "shall", and sometimes changing "have" to "has", makes them > look better. > > * "Whenever both, the initiator..." should not have the comma. > > * "This is a restatement... restated for the reader's convenience" > should either omit "a restatement of" or the final clause. From nobody Sun Jun 25 19:11:46 2017 Return-Path: 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 F37B3127873; Sun, 25 Jun 2017 19:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 NuXnhJtSQDQm; Sun, 25 Jun 2017 19:11:43 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 40BA1128D3E; Sun, 25 Jun 2017 19:11:43 -0700 (PDT) X-AuditID: 12074422-975ff70000003ff1-a2-59506d5d30a2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E5.F4.16369.D5D60595; Sun, 25 Jun 2017 22:11:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5Q2Be6M031932; Sun, 25 Jun 2017 22:11:40 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5Q2BZja020527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Jun 2017 22:11:39 -0400 Date: Sun, 25 Jun 2017 21:11:35 -0500 From: Benjamin Kaduk To: Martin Rex , jaltman@secure-endpoints.com Cc: kitten@ietf.org, curdle@ietf.org Message-ID: <20170626021135.GF17840@kduck.kaduk.org> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrBubGxBp8GiijcXWhbOYLf6snMRm cXTzKhaL3t87mB1YPJYs+cnkMeXzVkaPk33nWQOYo7hsUlJzMstSi/TtErgy/n9rYiy4I1Xx r/EpYwPjIdEuRk4OCQETiTmLf7F3MXJxCAksZpLoW9wO5WxklHjwbDMLhHOVSWLzlkksIC0s AqoSU5f/BrPZBFQkGrovM4PYIgLWEtuXrWUDsZmB4pueNrGC2MICsRKnfnwHq+cFWnfn/W0w W0ggTeL6+x/MEHFBiZMzn7BA9GpJ3Pj3kqmLkQPIlpZY/o8DJMwpYCOxbOIrsPGiAsoSfw/f Y5nAKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECApi dhelHYwT/3kdYhTgYFTi4c2wDIgUYk0sK67MPcQoycGkJMrb6O8fKcSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmENyMRqJw3JbGyKrUoHyYlzcGiJM4rrtEYISSQnliSmp2aWpBaBJOV4eBQkuDl ywFqFCxKTU+tSMvMKUFIM3FwggznARpu7AYyvLggMbc4Mx0if4pRUUqcd3k2UEIAJJFRmgfX C0oyEtn7a14xigO9IsxrDLKCB5ig4LpfAQ1mAho8Y40PyOCSRISUVANjfmvAuWXcvHL39U66 rfRWFfhT9nRve+PXpdpGBT8XM823n6vDMD199/3F57bPS5Ry0Lk+dStnMJvHt5/tCXePbZxc XLXi8ZmotQqRd34cNcip0FlSG3ZZysDbj6P28QaD/ppdzSG9sSd95Nk7hHim255nLVeIN3Nq Mu66/1Bnytxf11+c7mRTYinOSDTUYi4qTgQAaH0zUg0DAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 02:11:45 -0000 Hi Martin, On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote: > Benjamin Kaduk wrote: > > > > It sounds like you are asking for the addition of some text along > > the lines of: > > > > Software support is only a bare minimum requirement for deprecating > > RC4 enctypes; there may be additional logistical considerations > > involved such as provisioning AES keys for all principals and > > updating software configuration to enable AES and disable deprecated > > encryption types. > > > > Is that something you are asking for? > > Yes, thank your. This sounds good to me. I consider it even more > helpful than the reference to particular versions of particular > OpenSource Kerberos implementations, because this is a characteristic > that is sort-of implied by how kerberos-enctypes keys are created > (derived by string2key) and probably affect all implementations of > Kerberos, yet it is non-obvious to consumers of the technology. Thank you for clarifying your comment into a request. > > There is a substantial difference between cipher suites in TLS, where > key length, strength and algorithm for the symmetric crypto is mostly > irrelevant to the (PKI) credentials, and where using new TLS cipher suites > and deprecating old TLS cipher suites does not have a rekeying requirement. To some extent this is inherent in Kerberos's use of symmetric crypto for authentication, as opposed to TLS which uses asymmetric crypto for authentication and switches to symmetric crypto for efficiency for bulk data transfer. (Jeffrey Altman wrote:) % In my opinion, such text is inappropriate for an RFC. The deprecation % of the encryption type is a protocol action. The RFC is not guidance % for system administrators. Such guidance should come from the protocol % implementations. % % As such I believe the addition of text similar to the above is % unnecessary for publication. > > I do believe that it is very appropriate to provide such kind of a > guidance in an RFC, so that it this recommendation for deprecation > becomes more comprehensible and the trade-offs clearer to mere consumers > of the Kerberos technology, readers that aren't Kerberos protocol experts > and senior Kerberos implementers. In general I tend to hew more to Jeffrey's track that protocol specifications should limit themseles to protocol-level work. I could see some grounds for an exception here, though, in that the deployment difficulties are inherent to any Kerberos deployment that follows best practice of not storing user passwords (only derived keys). Given Jeffrey's reasoning, I do not think my above "proposed text" (to get clarification from Martin) should be used as-is; if we do want to provide the clarification that Martin wants, I would want to rephrase things somewhat. But, it still seems unclear where the WG consensus lies on the question of including any guidance at all, here. Can others please weigh in? > When making admins sufficiently aware of predictable interop-problems, > we may actually see more administrative deprecation of weak Kerberos > enctypes than leaving them in the dark, and it helps reducing the amount > of stumped users, helpdesks and admins. Admins are more likely to read software-provided documentation than protocol specs; this argument seems speculative to me. -Ben From nobody Mon Jun 26 09:02:31 2017 Return-Path: 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 65C3A129B38 for ; Mon, 26 Jun 2017 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 s3HaU_8gluDp for ; Mon, 26 Jun 2017 09:02:28 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 4694612EA58 for ; Mon, 26 Jun 2017 09:02:27 -0700 (PDT) X-AuditID: 12074422-c37ff70000002104-5e-59513002e938 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E6.21.08452.20031595; Mon, 26 Jun 2017 12:02:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5QG29Sn006044 for ; Mon, 26 Jun 2017 12:02:10 -0400 Received: from [18.101.8.159] (vpn-18-101-8-159.mit.edu [18.101.8.159]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5QG270E023638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Jun 2017 12:02:09 -0400 To: kitten@ietf.org References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org> From: Greg Hudson Message-ID: <6a5c9a4d-9be0-6a4d-3ee8-675c3430cc09@mit.edu> Date: Mon, 26 Jun 2017 12:02:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170626021135.GF17840@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrCtoEBhp8PSNgcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMef4W7aCBawVE++eY2lgnMrSxcjJISFgInHtyFogm4tDSGAx k0Tn3X5mCOc4o8SU5YtZIZzbTBJ3Z35iAmkRFoiVOPXjO1i7iICwxO6t76A6JjJKHP79gBkk wSagLLF+/1awIl4BK4mG69vBmlkEVCVWfvsHZosKREg87NzFDlEjKHFy5hOwek4BU4mHR46x gdjMAnoSO67/YoWw5SW2v53DPIGRfxaSlllIymYhKVvAyLyKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11QvN7NELzWldBMjKADZXZR2ME7853WIUYCDUYmH9wdTYKQQa2JZcWXuIUZJDiYlUV6O JwGRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4g7mBynlTEiurUovyYVLSHCxK4rziGo0RQgLp iSWp2ampBalFMFkZDg4lCV4zPaBGwaLU9NSKtMycEoQ0EwcnyHAeoOFdmiDDiwsSc4sz0yHy pxh1OZo+bPnCJMSSl5+XKiXOG60LVCQAUpRRmgc3B5w4Ujnmv2IUB3pLmPc/yDoeYNKBm/QK aAkT0BKWeQEgS0oSEVJSDYzNeU8rV/f3Pz7EG9vT/fKit/wX3fXfPx4X+5G8P6jnS6XEvj8G N74v5V2o0ifs33HC7/OBc2xSuzt2LYtnfcm8xDT24tVdP1s8jSfarto9Z/W51NxEA9PqLy92 yOyZvkah7MU2jvB335emin31Sona6Sp3riUgcJ6FtGc/V+ZfA74ns/wPuj5UYinOSDTUYi4q TgQAh2cf7fcCAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 16:02:29 -0000 On 06/25/2017 10:11 PM, Benjamin Kaduk wrote: >>> [...] there may be additional logistical considerations >>> involved such as provisioning AES keys [...] > (Jeffrey Altman wrote:) > % In my opinion, such text is inappropriate for an RFC. The deprecation > % of the encryption type is a protocol action. The RFC is not guidance > % for system administrators. Ben wrote: > Can others please weigh in? I don't think we need guidance for system administrators in this document, and we don't appear to have any such guidance in RFC 6649. I am okay with including such guidance in an appendix, but I don't believe it is a requirement for publication. From nobody Mon Jun 26 10:37:19 2017 Return-Path: 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 28BDF12EAF6 for ; Mon, 26 Jun 2017 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Wf2-f-eNDVQw for ; Mon, 26 Jun 2017 10:37:14 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D0912896F for ; Mon, 26 Jun 2017 10:37:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id z62so4790355ioi.3 for ; Mon, 26 Jun 2017 10:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Bo8Rd7H9y5MiQnSBEfBxjudIfqm/Jwnv1F0j+S+xv7E=; b=rWX+dnWTmPUSh7bV9TRmKkYtnLlzou5mrYD3yUnkdP3g2JsNgDHqAoAlPwXoA9Epmg 4WLkkJ8jU7An5SEqT13+OvpvCY8UrJVZts+BSvhhhlBc4vDAHOe60l8AYpiOfW3Vyvo0 LCehh8FBSFsGPbLOT8O0a+cPpE8F0svyTX+sHGGR0qdOzaL1fbxOpaPbbOIzvdOpH5jX 2JliNfpwx+CbQZMCC0GxyodYLXky1Fvdbo4miSS+Tam7IOnIZ+QgB7AWU2awu7HQrrdR akVkOrNyQGD73ve5bVbqhd0Ng3Kdq0QaK48TxpfUdl0A4SU9EPR8NRCgvtQD60nylMz/ BbvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Bo8Rd7H9y5MiQnSBEfBxjudIfqm/Jwnv1F0j+S+xv7E=; b=VfJBWijl0PXtGl5v5q4i4l0h/dMqFUHCH3znE0rPiK49/U9KgCsg3YsGGdGlrxgPIx 9V8CJz33FQRnywzduMsVaeYkNjY1xRxJg+J3d8yKfDSzo/GFj964Ul5jcUUfrYl6dvfl sOCNzzwiDEe37OQW//YBOMGZJZ3wFbI6hzUJ+u79b3P8XAKHSREwS33hcoYUqIkAY/iJ wBNY5deF/weY0HyNqp0b4zjhY9Za+RnOezTFyIkjsTrg5Re4y5Ea/1bpsqanlfZ2/8I3 f4Wg1bRNJhBjgfBMaXc+MJENbWylJguoEFoBovFFZYhcpZ279fyd1FCcP8ysSsD5n4i1 joLg== X-Gm-Message-State: AKS2vOzerYyArqBaig6IFwQd/y+TPI2kSL/Coszq3XbSSOb1J/UqVGyd 55wMMdwt+Oqrx4pBWtFqoZkEBlEMHA== X-Received: by 10.107.9.137 with SMTP id 9mr1814635ioj.131.1498498633073; Mon, 26 Jun 2017 10:37:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.16.7 with HTTP; Mon, 26 Jun 2017 10:37:12 -0700 (PDT) In-Reply-To: <6a5c9a4d-9be0-6a4d-3ee8-675c3430cc09@mit.edu> References: <20170621174558.GK39245@kduck.kaduk.org> <20170623120341.C93721A6BE@ld9781.wdf.sap.corp> <20170626021135.GF17840@kduck.kaduk.org> <6a5c9a4d-9be0-6a4d-3ee8-675c3430cc09@mit.edu> From: Michael Jenkins Date: Mon, 26 Jun 2017 13:37:12 -0400 Message-ID: To: kitten@ietf.org Content-Type: multipart/alternative; boundary="001a113f8f14b8ea230552e06671" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:37:18 -0000 --001a113f8f14b8ea230552e06671 Content-Type: text/plain; charset="UTF-8" Hi all, I would agree that guidance for system administrators need not appear in a document like this, and I don't see any in RFC 6649. On the other hand, most of the justification for deprecating both RC4 and 3DES /is/ about system administration. The NTLM discussion is about deployment upgrade, and the cross-realm discussion is about architecture. Neither have anything to do with the weakness of the algorithms, and both are problems that could arise with any transition. Seems that you should either remove what's not cryptographic or a direct problem that the algorithm/enc-type causes for the security of the protocol (not deployment of the protocol) ala RFC 6649, or acknowledge that your discussion has crossed over into deployment-land and at least put in a disclaimer that what you've written is merely justification for the deprecation, and not an assessment that the deprecation can be implemented with no breakage. On Mon, Jun 26, 2017 at 12:02 PM, Greg Hudson wrote: > On 06/25/2017 10:11 PM, Benjamin Kaduk wrote: > >>> [...] there may be additional logistical considerations > >>> involved such as provisioning AES keys [...] > > > (Jeffrey Altman wrote:) > > % In my opinion, such text is inappropriate for an RFC. The deprecation > > % of the encryption type is a protocol action. The RFC is not guidance > > % for system administrators. > > Ben wrote: > > Can others please weigh in? > > I don't think we need guidance for system administrators in this > document, and we don't appear to have any such guidance in RFC 6649. I > am okay with including such guidance in an appendix, but I don't believe > it is a requirement for publication. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- Mike Jenkins mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk m.jenkins.364706@gmail.com - to read everywhere 443-634-3951 --001a113f8f14b8ea230552e06671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I would agree that gui= dance for system administrators need not appear in a document like this, an= d I don't see any in RFC 6649.

On the other hand, most of = the justification for deprecating both RC4 and 3DES /is/ about system admin= istration. The NTLM discussion is about deployment upgrade, and the cross-r= ealm discussion is about architecture. Neither have anything to do with the= weakness of the algorithms, and both are problems that could arise with an= y transition.

Seems that you should either remove what's n= ot cryptographic or a direct problem that the algorithm/enc-type causes for= the security of the protocol (not deployment of the protocol) ala RFC 6649= , or acknowledge that your discussion has crossed over into deployment-land= and at least put in a disclaimer that what you've written is merely ju= stification for the deprecation, and not an assessment that the deprecation= can be implemented with no breakage.
<= br>
On Mon, Jun 26, 2017 at 12:02 PM, Greg Hudson= <ghudson@mit.edu> wrote:
On= 06/25/2017 10:11 PM, Benjamin Kaduk wrote:
>>>=C2=A0 =C2=A0[...] there may be additional logistical considera= tions
>>>=C2=A0 =C2=A0involved such as provisioning AES keys [...]

> (Jeffrey Altman wrote:)
> % In my opinion, such text is inappropriate for an RFC.=C2=A0 The depr= ecation
> % of the encryption type is a protocol action.=C2=A0 The RFC is not gu= idance
> % for system administrators.

Ben wrote:
> Can others please weigh in?

I don't think we need guidance for system administrators in this=
document, and we don't appear to have any such guidance in RFC 6649.=C2= =A0 I
am okay with including such guidance in an appendix, but I don't believ= e
it is a requirement for publication.

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten



--
Mike Jenkins
mjjenki@tycho.ncsc.mil - if you want me to re= ad it only at my desk
m.jenkins.364706@gmail.com - to read everywhere
= 443-634-3951
--001a113f8f14b8ea230552e06671--