From nobody Mon Sep 4 05:23:58 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 EEB27128D0F for ; Mon, 4 Sep 2017 05:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samba.org 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 A_-X3Qr8XalG for ; Mon, 4 Sep 2017 05:23:54 -0700 (PDT) Received: from hr2.samba.org (hr2.samba.org [IPv6:2a01:4f8:192:486::147:1]) (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 76918126DD9 for ; Mon, 4 Sep 2017 05:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samba.org; s=42627210; h=Date:Message-ID:From:Cc:To; bh=ehqnbvRUnq6KrAVkO9O4pHvSERc9TNOqtmUpth2mCYM=; b=sJNHmOjd4eit84wSGUhrEuxSGd O8MMVcX+bbWCRc6Da6XR4tZfgGnax1IQ04mAEo/0FVxHjVHpaNVh2NRL03nZeHWqq+4zEv22Qe72T 7l1VLkEdwmVzMqNKF0mbGEtF8jegnunQB/9I87jjFU2vzgvw695+7/ZmPyVuvoToJoiY=; Received: from [127.0.0.2] (localhost [127.0.0.1]) by hr2.samba.org with esmtpsa (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim) id 1doqPu-0000yc-0o; Mon, 04 Sep 2017 12:23:50 +0000 To: mrex@sap.com Cc: Simo Sorce , Greg Hudson , heimdal-discuss@h5l.org, "krbdev@mit.edu Dev List" , "kitten@ietf.org" , Samba Technical References: <20170830223732.6A91B1A6EC@ld9781.wdf.sap.corp> From: Stefan Metzmacher Openpgp: id=A3D192CE44EF412517BCED646A739B025C6B98D4 Message-ID: <83f2f9d5-eccd-de3b-e22e-7e893a20c2af@samba.org> Date: Mon, 4 Sep 2017 14:23:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170830223732.6A91B1A6EC@ld9781.wdf.sap.corp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ED5qm1PSVXSHbNqgX54L0qWckaQeoHGRX" Archived-At: Subject: Re: [kitten] Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation... 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, 04 Sep 2017 12:23:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ED5qm1PSVXSHbNqgX54L0qWckaQeoHGRX Content-Type: multipart/mixed; boundary="VrC4rTj9PEkXLnbJgpEFaQMd603aJU1Dl"; protected-headers="v1" From: Stefan Metzmacher To: mrex@sap.com Cc: Simo Sorce , Greg Hudson , heimdal-discuss@h5l.org, "krbdev@mit.edu Dev List" , "kitten@ietf.org" , Samba Technical Message-ID: <83f2f9d5-eccd-de3b-e22e-7e893a20c2af@samba.org> Subject: Re: [kitten] Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation... References: <20170830223732.6A91B1A6EC@ld9781.wdf.sap.corp> In-Reply-To: <20170830223732.6A91B1A6EC@ld9781.wdf.sap.corp> --VrC4rTj9PEkXLnbJgpEFaQMd603aJU1Dl Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Martin, I don't think your comments apply to what I'm proposing. See the inline comments below. >> We should enforce a PAC always to be present, as we don't support >> trusted domains with LSA_TRUST_TYPE_MIT anyway. "We" is Samba in here. Services which don't use the PAC at all are not enforced to use it in future. > I haven't really followed the discussion here, but Microsoft PACs are > a royal PITA, wasting huge amounts of network bandwidth, creating > bad latency on authentication, causing spurious authentication failures= > during high-load situations and completely breaking certain rfc4559 > HTTP Negotiate scenarios when users are assigned to lots of groups > in Microsoft AD. Bottlenecks in LSA PAC verifications are extremely > annoying, such as using Outlook&Exchange with 50k+ Users and > at least once an hour an Outlook Password logon prompt pops up because > one of the crazy many rfc4559 Kerberos authentications failed between > Outlook and Exchange. (Hitting cancel on the popup and toggling > offline/online in the Outlook window status bar retries Kerberos > authentication and typically succeeds... The PAC contains two signatures, one that's done with the services long-term key (machine password) and one with the KDCs (krbtgt) long-term key. In Samba we're only rely on krb5_pac_verify(), which is an offline verification that's possible with the same key that's used to decrypt the ticket itself. You're talking about "online" PAC verification that's used to verify KDCs signature by asking a DC. See https://blogs.msdn.microsoft.com/openspecification/2009/04/24/understandi= ng-microsoft-kerberos-pac-validation/ regarding SeTcbPrivilege. The main difference is that code that runs as part of the OS with SeTCBPrivilege only needs the offline verification. And Samba is similar and only requires the offline verification. > Simply disabling PACs on the service account for service tickets > solves all of the hard and annoying problems, by enabling the bit > UF_NO_AUTH_DATA_REQUIRED (0x02000000) in the UserAccountControl > property of the service account. >=20 > Without setting this bit to omit the crazy PACs, common problems with > heavy (mindless) Group membership usage are this: >=20 > https://blogs.technet.microsoft.com/shanecothran/2010/07/16/maxtoken= size-and-kerberos-token-bloat/ >=20 >=20 > Reasons why the myriads of PAC verfications occasionally fail: >=20 > https://blogs.technet.microsoft.com/instan/2011/11/14/the-return-of-= pac-mania-aka-some-reasons-why-pac-verification-can-fail/ >=20 > and btw. huge kerberos tickets can also make rfc4559 fail because of > the excessive size of the HTTP header field to carry the AP_REQ with th= e > kerberos ticket. >=20 > Whenever authorization isn't actually managed through PACs, > i.e. pretty much 100% of the time when the backend is a database > and access through rfc4559 HTTP Negotiate, omitting PACs from Kerberos > tickets comes close to a universal panacea for a huge amount of > "occasional" failures. I'm not sure that it applies to all workloads, but it's quite possible that http is typically different to SMB, LDAP or DCERPC. metze --VrC4rTj9PEkXLnbJgpEFaQMd603aJU1Dl-- --ED5qm1PSVXSHbNqgX54L0qWckaQeoHGRX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJZrUXVAAoJEA219WEoab1WeIsP/1IjO0KXs5TKdBrATwONTqox EeSKoRWJQXXlXGc8YxR9xu4Yn025nve7JgbUvcLV+ovJZtunSzSS2/atfkp72d6G mI3dS2iMbICW15l2st9GLH1R0gdJui/JZh7ksikuwlS+7blIh4hiLc/xVjfTJOmd 9TSZpEDTFJ9kHCII9qGlsR6JO2PKrRaFulqFpc8HUxvkPivqqZhwiBQiqHsiYm++ VaCCo/O4nr9CHe/YjXejTwv5aZBS5HTJw7YRqdCG5HvpuM0yJDh9MPPu9Zd6eNms ytyFOkvWLAlYC3CnBtwBMrhpQBDnX1DBLFlUuKfsaFLb74mnXu91eXJfctPnA5Gr zv1VOm8UFrliylYduKeEOqTJnISKgyVBImvKttQwp4+bB1FNu7BIBYCaMBuPl9yD 777XOKSGvpxOCk28nTObbLjfcmlU/c08lsjfqD5pkAGxBRgDmYl/eBlfzWqjM7sy KGlWycwcP7wnluxa6N8eiy/9T6l+NM4LRYIQRXLlvCb1TlrruMK7zFUvJ2gKviUY /6YpduSaQLz0O5x+5LUZ0h7GMxP/xsHIjfeI8dsyJUlaAXMSB0Drs6U9f+dMoE+5 Re2Y+RgFNAwfIOYh8acJMdB2sgvswJqH1kuFhMl69EErvq5AXMUed8/KddvO7wVQ FMzAY1XZiieSWe1ht3fy =Yk9V -----END PGP SIGNATURE----- --ED5qm1PSVXSHbNqgX54L0qWckaQeoHGRX-- From nobody Mon Sep 4 18:25:30 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 CBB391321A5; Mon, 4 Sep 2017 18:25:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150457472979.28661.15542249793619015627@ietfa.amsl.com> Date: Mon, 04 Sep 2017 18:25:29 -0700 Archived-At: Subject: [kitten] Genart last call review of draft-ietf-kitten-rfc5653bis-05 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, 05 Sep 2017 01:25:30 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-kitten-rfc5653bis-05 Reviewer: Joel Halpern Review Date: 2017-09-04 IETF LC End Date: 2017-09-11 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC. Reviewer note: The reviewer concentrated on the changes from the previous RFC, and did not attempt to review the code. The changes seem clear and understandable. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Tue Sep 5 12:00:17 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 7C19C132E29; Tue, 5 Sep 2017 12:00:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150463800843.29826.6748894127604407016@ietfa.amsl.com> Date: Tue, 05 Sep 2017 12:00:08 -0700 Archived-At: Subject: [kitten] Opsdir last call review of draft-ietf-kitten-rfc5653bis-05 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, 05 Sep 2017 19:00:09 -0000 Reviewer: Joe Clarke Review result: Ready I have been asked to do an LC review of draft-ietf-kitten-rfc5653bis on behalf of the ops directorate (OPS-DIR). This draft is an update to the Java bindings for the Generic Security Service API Version 2. Overall, this document is READY. It clearly articulates the reason for the modifications in the Appendix, and the changes feel straight-forward and make sense in light of the C API capabilities. My one concern is the compatibility of this change relative to the previous RFC5653 bindings. That is, the previous GSSException does not have a getOutputToken method. The sample application in the draft (section 7) calls this new method (and I like the same covers the relevant change in this doc). But what happens if my Java library is the older 5653 version? A NoSuchMethodError will be thrown, which is not ideal. If there is a set of static properties one can check to see if they have the supported version of the library (and thus the GSSException.getOutputToken() method exists), then the example should use those, and that process should be called out in the text. In lieu of that, introspection could be used to determine if the new method exists in the current library before it is used. This is immediately a concern with any API change, but since the appendix mentions this is a compatible change, I wanted to raise the point. From nobody Tue Sep 5 22:42: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 EB8EA126DD9; Tue, 5 Sep 2017 22:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 bhvkugw68yl2; Tue, 5 Sep 2017 22:42:16 -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 4EB8D1241F3; Tue, 5 Sep 2017 22:42:13 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v865gBC2026705 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 05:42:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v865gBLD012245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 05:42:11 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v865gBMb014211; Wed, 6 Sep 2017 05:42:11 GMT Received: from dhcp-tokyo-twvpn-1a-vpnpool-10-191-26-59.vpn.oracle.com (/10.191.26.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Sep 2017 22:42:10 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Weijun Wang In-Reply-To: <150463800843.29826.6748894127604407016@ietfa.amsl.com> Date: Wed, 6 Sep 2017 13:42:28 +0800 Cc: ops-dir@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2D53D28B-DCAD-485C-A8E5-182EA9C13F16@oracle.com> References: <150463800843.29826.6748894127604407016@ietfa.amsl.com> To: Joe Clarke X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [kitten] Opsdir last call review of draft-ietf-kitten-rfc5653bis-05 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, 06 Sep 2017 05:42:18 -0000 Hi Joe When I said it's a compatible change, I meant the behavior is = compatible, so either initSecContext or acceptSecContext still throws an = exception instead of returning KRB-ERROR in a byte array. I know = "compatibility" has lots of different meanings. If this method is called directly (not via refection) it will only = compile with a new JDK. The program will not run with an old JDK because = in Java the class file contains a magic number that increases with each = version. This happens before you can see a NoSuchMethodError. If a developer wants an application or library runnable with an old JDK = release but also like to benefit from the new method when running with a = new release, some kind of reflection (GSSException.class.getMethod) is = needed. In this case the developer will certainly be aware that this = method might not exist and deal with it carefully. I feel hesitated to add reflection calls to all examples since that will = look quite a mess. How about changing the last paragraph of Section 11 = 1) to something like: New JGSS programs should make use of this new method but it is not = mandatory. A program that intends to run with both old and new Java releases can = use reflection to check the availability of this new method and call it = accordingly. Thanks Max >=20 > On Sep 6, 2017, at 3:00 AM, Joe Clarke wrote: >=20 > Reviewer: Joe Clarke > Review result: Ready >=20 > I have been asked to do an LC review of draft-ietf-kitten-rfc5653bis = on behalf > of the ops directorate (OPS-DIR). >=20 > This draft is an update to the Java bindings for the Generic Security = Service > API Version 2. >=20 > Overall, this document is READY. It clearly articulates the reason = for the > modifications in the Appendix, and the changes feel straight-forward = and make > sense in light of the C API capabilities. >=20 > My one concern is the compatibility of this change relative to the = previous > RFC5653 bindings. That is, the previous GSSException does not have a > getOutputToken method. The sample application in the draft (section = 7) calls > this new method (and I like the same covers the relevant change in = this doc).=20 > But what happens if my Java library is the older 5653 version? A > NoSuchMethodError will be thrown, which is not ideal. >=20 > If there is a set of static properties one can check to see if they = have the > supported version of the library (and thus the = GSSException.getOutputToken() > method exists), then the example should use those, and that process = should be > called out in the text. In lieu of that, introspection could be used = to > determine if the new method exists in the current library before it is = used. >=20 > This is immediately a concern with any API change, but since the = appendix > mentions this is a compatible change, I wanted to raise the point. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Wed Sep 6 06:01: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 985B1132F05; Wed, 6 Sep 2017 06:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 SodsuDdSYCe9; Wed, 6 Sep 2017 06:00:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470BC132F09; Wed, 6 Sep 2017 06:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3798; q=dns/txt; s=iport; t=1504702857; x=1505912457; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Bj+fK4swfqrQFwg9M9e/p/xWr7sQc6GvpZhkEDn4QBo=; b=M0pHwYmy7mv+Ytu8HlY+/WSiBCFkHsCEGZCvY7C7RSXrZpZuWSNNHphH tC9HtqUNMexAqpStkxOVsNE3ZlANCbfIsPpsCt2Ww3OQsxt7x4NQons0L dFA5CHscvilFe7efFZ18eQB+oOGW3iBukG/kb5G5H/EHL1+qoztAlojCV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgA68a9Z/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRWDd5pCgXGYOgoYC4RMTwKEPEMUAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBIUsLEAsYAgImAgInMAYNBgIBAYolCBCufYInizkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGgWBDYIdggKBToFjK4J9iAiCYQWgdJRRghOJQYcdiXyLL4E5NiG?= =?us-ascii?q?BDVMkFUmFGByCAyQ2iiUBAQE?= X-IronPort-AV: E=Sophos;i="5.41,484,1498521600"; d="scan'208";a="453593731" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2017 13:00:56 +0000 Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v86D0t72002235; Wed, 6 Sep 2017 13:00:55 GMT To: Weijun Wang Cc: ops-dir@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org References: <150463800843.29826.6748894127604407016@ietfa.amsl.com> <2D53D28B-DCAD-485C-A8E5-182EA9C13F16@oracle.com> From: Joe Clarke Organization: Cisco Message-ID: <54e49125-b10e-b756-19fe-57b78594efe0@cisco.com> Date: Wed, 6 Sep 2017 09:00:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2D53D28B-DCAD-485C-A8E5-182EA9C13F16@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] Opsdir last call review of draft-ietf-kitten-rfc5653bis-05 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, 06 Sep 2017 13:01:01 -0000 On 9/6/17 01:42, Weijun Wang wrote: > Hi Joe > > When I said it's a compatible change, I meant the behavior is compatible, so either initSecContext or acceptSecContext still throws an exception instead of returning KRB-ERROR in a byte array. I know "compatibility" has lots of different meanings. > > If this method is called directly (not via refection) it will only compile with a new JDK. The program will not run with an old JDK because in Java the class file contains a magic number that increases with each version. This happens before you can see a NoSuchMethodError. Yes, compile-time will stop you. But if you distribute an app with someone else's jar... (I know you know this :-) ). > > If a developer wants an application or library runnable with an old JDK release but also like to benefit from the new method when running with a new release, some kind of reflection (GSSException.class.getMethod) is needed. In this case the developer will certainly be aware that this method might not exist and deal with it carefully. > > I feel hesitated to add reflection calls to all examples since that will look quite a mess. How about changing the last paragraph of Section 11 1) to something like: > > New JGSS programs should make use of this new method but it is not mandatory. > A program that intends to run with both old and new Java releases can use > reflection to check the availability of this new method and call it accordingly. I'm good with this. A slight change, though: "A program that intends to run with both old and new GSS Java bindings can use reflection to check the availability of this new method and call it accordingly." You're right that adding reflection to the example would just muddle it. In a perfect world, you'd have the latest jar with the an app written for it. So the example is good. But my experience with Java is that you may not get the jar you expect, and changes like this that are said to be "compatible" can often bite you. Joe > > Thanks > Max > > >> >> On Sep 6, 2017, at 3:00 AM, Joe Clarke wrote: >> >> Reviewer: Joe Clarke >> Review result: Ready >> >> I have been asked to do an LC review of draft-ietf-kitten-rfc5653bis on behalf >> of the ops directorate (OPS-DIR). >> >> This draft is an update to the Java bindings for the Generic Security Service >> API Version 2. >> >> Overall, this document is READY. It clearly articulates the reason for the >> modifications in the Appendix, and the changes feel straight-forward and make >> sense in light of the C API capabilities. >> >> My one concern is the compatibility of this change relative to the previous >> RFC5653 bindings. That is, the previous GSSException does not have a >> getOutputToken method. The sample application in the draft (section 7) calls >> this new method (and I like the same covers the relevant change in this doc). >> But what happens if my Java library is the older 5653 version? A >> NoSuchMethodError will be thrown, which is not ideal. >> >> If there is a set of static properties one can check to see if they have the >> supported version of the library (and thus the GSSException.getOutputToken() >> method exists), then the example should use those, and that process should be >> called out in the text. In lieu of that, introspection could be used to >> determine if the new method exists in the current library before it is used. >> >> This is immediately a concern with any API change, but since the appendix >> mentions this is a compatible change, I wanted to raise the point. >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Sep 6 07:17: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 EF95C132FD6; Wed, 6 Sep 2017 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 MB2uzIKYMxyx; Wed, 6 Sep 2017 07:17:53 -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 89DEB132A0D; Wed, 6 Sep 2017 07:17:41 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v86EHeE5011018 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 14:17:40 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v86EHdS9010771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 14:17:40 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v86EHdt2017992; Wed, 6 Sep 2017 14:17:39 GMT Received: from [192.168.1.101] (/114.250.180.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Sep 2017 07:17:39 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Weijun Wang In-Reply-To: <54e49125-b10e-b756-19fe-57b78594efe0@cisco.com> Date: Wed, 6 Sep 2017 22:17:32 +0800 Cc: ops-dir@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150463800843.29826.6748894127604407016@ietfa.amsl.com> <2D53D28B-DCAD-485C-A8E5-182EA9C13F16@oracle.com> <54e49125-b10e-b756-19fe-57b78594efe0@cisco.com> To: Joe Clarke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [kitten] Opsdir last call review of draft-ietf-kitten-rfc5653bis-05 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, 06 Sep 2017 14:17:54 -0000 Hi Joe > On Sep 6, 2017, at 9:00 PM, Joe Clarke wrote: >=20 > "A program that intends to run with both old and new GSS Java bindings > can use reflection to check the availability of this new method and = call > it accordingly." Accepted. You do not mean to remove the existing "New JGSS programs = should make use of this new method but it is not mandatory" sentence, = right? Is there anything else I need to touch before posting the -06 version of = this ID? > But my experience with Java is that you may not get the jar you = expect, > and changes like this that are said to be "compatible" can often bite = you. Since this is inside Java SE, hopefully the situation is better than a = 3rd party API. Of course, with the new modularized structure introduced = in JDK 9, people might start making JDK images of their own which = contain modules from different releases and different vendors... Thanks Max From nobody Wed Sep 6 07:19:30 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 423B9132FC0; Wed, 6 Sep 2017 07:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1EzwDmFJ6ced; Wed, 6 Sep 2017 07:19:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3F8132FC1; Wed, 6 Sep 2017 07:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1504707566; x=1505917166; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4BcDq4sKkI0C8B7GkODXrOo72dtA6zSGmKGieZXh8RM=; b=jo4qtMqmHddrAU9+gpN0fIDEdtqNEh4qgFIaWtc0tlsecBsPZ8v1quJg yEoHX26VLXGhdu87IrP0kjm20j4PAgo7Z78PHSwQeFD6hPhzHwcQxdPlw s2P4M66uyODSp+LYek5XpHCrMkEXbVIJRqEDlHhtEy+JlxICvTKhJFHIY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAgDpArBZ/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeYN3mkKBTyKYOgqFPgKEPEMUAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CASNWEAsYAgImAgJXBg0GAgEBiiUIrhWCJ4s4AQEBAQEBAQEBAQEBAQEBAQEhg?= =?us-ascii?q?Q2CHYICgU6BYysLgnKICIJhBaB0lFGLVIcdlSuBOTYhgQ1TJBWFYRyCAyQ2iiU?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.41,484,1498521600"; d="scan'208";a="482127587" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2017 14:19:26 +0000 Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v86EJPwd004963; Wed, 6 Sep 2017 14:19:25 GMT To: Weijun Wang Cc: ops-dir@ietf.org, kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-rfc5653bis.all@ietf.org References: <150463800843.29826.6748894127604407016@ietfa.amsl.com> <2D53D28B-DCAD-485C-A8E5-182EA9C13F16@oracle.com> <54e49125-b10e-b756-19fe-57b78594efe0@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: Date: Wed, 6 Sep 2017 10:19:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] Opsdir last call review of draft-ietf-kitten-rfc5653bis-05 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, 06 Sep 2017 14:19:28 -0000 On 9/6/17 10:17, Weijun Wang wrote: > Hi Joe > >> On Sep 6, 2017, at 9:00 PM, Joe Clarke wrote: >> >> "A program that intends to run with both old and new GSS Java bindings >> can use reflection to check the availability of this new method and call >> it accordingly." > > Accepted. You do not mean to remove the existing "New JGSS programs should make use of this new method but it is not mandatory" sentence, right? Correct. I was just changing that last sentence. I intended you to keep the quoted sentence you have above. > > Is there anything else I need to touch before posting the -06 version of this ID? Not from my OPS-DIR review. > >> But my experience with Java is that you may not get the jar you expect, >> and changes like this that are said to be "compatible" can often bite you. > > Since this is inside Java SE, hopefully the situation is better than a 3rd party API. Of course, with the new modularized structure introduced in JDK 9, people might start making JDK images of their own which contain modules from different releases and different vendors... Yes. It was really the "compatible" word that piqued my thinking. Joe > > Thanks > Max > From nobody Thu Sep 7 10:17: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 D2854132992 for ; Thu, 7 Sep 2017 10:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DcdIFubK20Tp for ; Thu, 7 Sep 2017 10:17:02 -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 34BED132962 for ; Thu, 7 Sep 2017 10:17:02 -0700 (PDT) X-AuditID: 12074424-2c5ff70000002172-2e-59b17f0c58a4 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id E4.C8.08562.C0F71B95; Thu, 7 Sep 2017 13:17:00 -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 v87HGxKd007275 for ; Thu, 7 Sep 2017 13:16:59 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [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 v87HGwhc022943 for ; Thu, 7 Sep 2017 13:16:59 -0400 From: Greg Hudson To: kitten@ietf.org Date: Thu, 07 Sep 2017 13:16:58 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUixCmqrMtTvzHSoP2nsMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0dX1gqnggFDFxf9RDYy9/F2MnBwSAiYSbxZ2snUxcnEICSxm klj68DqUc4xR4tXNJYwQTjuTxN1Vu9hBWtgElCXW79/KAmKLCAhL7N76jhnEFhZQlPixYy1Q nIODRUBV4vvOTJAwr4ChxP7pR1ghbEGJkzOfgLUyC0hIHHzxgnkCI/csJKlZSFILGJlWMcqm 5Fbp5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBIUAu4vKDsbuHu9DjAIcjEo8vBbBGyOF WBPLiitzDzFKcjApifIe1wAK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGVrwbK8aYkVlalFuXD pKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvI51QI2CRanpqRVpmTklCGkmDk6Q4TxA w6trQYYXFyTmFmemQ+RPMUpKifM+BEkIgCQySvPgel8xigO9IMwbDZLlAcYzXNcroIFMQANL nm8AGViSiJCSamDcc7p/h5D1fV/Nx5OObPgq15fy+GO0lsbC5n2bF5e+X3jqfdnfWVLmaxIc HXq4/3kmdbHsV9tTuGEPB89n0wa/il+fpSQXhrCeYpwny6NkGXnmUubW/2xBF7+scb+66a3F MYNbsfF93E8MBVr3Ne4VnLdigYB/WXdZ5PoCFYuVNx5snrdpx/wwJZbijERDLeai4kQAoacX kaQCAAA= Archived-At: Subject: [kitten] SPAKE edwards25519 group 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, 07 Sep 2017 17:17:04 -0000 I would like to add a SPAKE group specification using the Edwards 2^255-19 curve used by the ed25519 signature algorithm. I was recently able to implement this group by adapating the SPAKE2 code from BoringSSL. I would like to specify that the new group is the only mandatory-to-implement group, as I believe that it is the easiest to implement in constant time and has the potential to be the most performant choice. (P-256 may be more performant in practice in some situation, as OpenSSL normally uses an optimized assembly implementation of P-256, while the BoringSSL Edwards 25519 SPAKE code is in C. But in my tests they're pretty close even so.) I would like to renumber the groups so that the new group is 1 and the three NIST groups are 2, 3, and 4. As we have not assigned pa-data or key usage code points yet, there should be no interoperability issues with renumbering the groups. I suggest the group name "edwards25519", which is used in RFC 7748. The shorter name "ed25519" could create confusion with the ed25519 signature algorithm. Here is the registry entry (please verify that my RFC 7748 and RFC 8032 references seem correct): * ID Number: 1 * Name: edwards25519 * Specification: [RFC7748] section 4.1 (edwards25519) * Serialization: [RFC8032] section 3.1 * Multiplier Length: 32 * Multiplier Conversion: RFC 8032 section 3.1 * SPAKE M Constant: 5ada7e4bf6ddd9adb6626d32131c6b5c51a1e347a3478f53cfcf441b88eed12e * SPAKE N Constant: 10e3df0ae37d8e7a99b5fe74b44672103dbddcbd06af680d71329a11693bc778 To justify the M and N values (which are the same ones used by BoringSSL), I would like to add an appendix B titled "SPAKE M and N Value Selection" with the text: The M and N constants for the edwards25519 group are the SHA-256 hashes [RFC6234] of "edwards25519 point generation seed (M)" and "edwards25519 point generation seed (N)" respectively. Both hashes decode to valid curve points. (The BoringSSL SPAKE2 code includes a whole bit of Python code in a comment which would iterate the SHA-256 hash until a valid curve point is found. But it turns out both seeds hash to a valid curve point immediately.) Convenience links: https://tools.ietf.org/html/rfc7748 https://tools.ietf.org/html/rfc8032 https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-00 From nobody Mon Sep 11 08:25:37 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 4932B1323F7 for ; Mon, 11 Sep 2017 08:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 a6V8ekNIsY1z for ; Mon, 11 Sep 2017 08:25:33 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 9E6411330C2 for ; Mon, 11 Sep 2017 08:25:32 -0700 (PDT) X-AuditID: 1209190d-f7dff70000001ead-db-59b6aaeba6f9 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 51.E9.07853.BEAA6B95; Mon, 11 Sep 2017 11:25:31 -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 v8BFPUhP013219; Mon, 11 Sep 2017 11:25:30 -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 v8BFPQx7016399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Sep 2017 11:25:29 -0400 Date: Mon, 11 Sep 2017 10:25:26 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20170911152526.GD96685@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.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrft61bZIg2uHlSyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL7ur2wFTyUrVm3uYm9gvCHSxcjJISFgInFu4TvWLkYuDiGB xUwSB86+Y4NwNjJK7Dr0gQXCucokceXQL0aQFhYBVYlpf86ygdhsAioSDd2XmUFsEQFFiWer 5rKA2MwCwhLL10DUCAvoSWzbtokdxOYFWre1oQesXkjAUGLL1pmsEHFBiZMzn0D1aknc+PeS qYuRA8iWllj+jwPE5BQwkpjYBTZRVEBZYt6+VWwTGAVmIWmehaR5FkLzAkbmVYyyKblVurmJ mTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGMEBKcm7g/HfXa9DjAIcjEo8vA292yKFWBPLiitz DzFKcjApifK+O74lUogvKT+lMiOxOCO+qDQntfgQowQHs5IIb8dCoHLelMTKqtSifJiUNAeL kjivuEZjhJBAemJJanZqakFqEUxWhoNDSYL32EqgRsGi1PTUirTMnBKENBMHJ8hwHqDh4SA1 vMUFibnFmekQ+VOMilLivDErgBICIImM0jy4XlDCkMjeX/OKURzoFWHesyDtPMBkA9f9Cmgw E9BgnktbQAaXJCKkpBoYz/5IXP4oonbb9+1rMiyPlpk3rD8x9Zhx68zLmrGH3ogL51sIXdk2 /Q7Ty7luj02eq7qpRfQFel2yjmMVy10QeDr8kYhnku2LZRvmnA/jPuV2ZM71eTVS88rqC9N9 E3tdLJRZn0RNnHyjpFv92osgl8Wbr8Rf/J7b9JHtteKmsMTM5vx/kdq8SizFGYmGWsxFxYkA eGBOu/MCAAA= Archived-At: Subject: Re: [kitten] SPAKE edwards25519 group 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, 11 Sep 2017 15:25:36 -0000 On Thu, Sep 07, 2017 at 01:16:58PM -0400, Greg Hudson wrote: > I would like to add a SPAKE group specification using the Edwards > 2^255-19 curve used by the ed25519 signature algorithm. I was recently > able to implement this group by adapating the SPAKE2 code from > BoringSSL. > > I would like to specify that the new group is the only > mandatory-to-implement group, as I believe that it is the easiest to > implement in constant time and has the potential to be the most > performant choice. (P-256 may be more performant in practice in some > situation, as OpenSSL normally uses an optimized assembly implementation > of P-256, while the BoringSSL Edwards 25519 SPAKE code is in C. But in > my tests they're pretty close even so.) In general I support this proposal. > I would like to renumber the groups so that the new group is 1 and the > three NIST groups are 2, 3, and 4. As we have not assigned pa-data or > key usage code points yet, there should be no interoperability issues > with renumbering the groups. Seems reasonable. > I suggest the group name "edwards25519", which is used in RFC 7748. The > shorter name "ed25519" could create confusion with the ed25519 signature > algorithm. Sure. > Here is the registry entry (please verify that my RFC 7748 and RFC 8032 > references seem correct): > > * ID Number: 1 > * Name: edwards25519 > * Specification: [RFC7748] section 4.1 (edwards25519) Yes, that's the right section for edwards25519, even though the section title is Curve25519. RFC 7748 does have an external reference for ed25519 (and the edwards25519 curve), which is a Springer publication, so the RFC is probably better. > * Serialization: [RFC8032] section 3.1 RFC 8032 seems to refer to bit-string serializations, whereas our group elements are represented as octet strings. RFC 8032 does describe packing bit strings into octet strings in section 2, so perhaps the given reference suffices. > * Multiplier Length: 32 > * Multiplier Conversion: RFC 8032 section 3.1 > * SPAKE M Constant: 5ada7e4bf6ddd9adb6626d32131c6b5c51a1e347a3478f53cfcf441b88eed12e > * SPAKE N Constant: 10e3df0ae37d8e7a99b5fe74b44672103dbddcbd06af680d71329a11693bc778 > > To justify the M and N values (which are the same ones used by > BoringSSL), I would like to add an appendix B titled "SPAKE M and N > Value Selection" with the text: Sure. > The M and N constants for the edwards25519 group are the SHA-256 > hashes [RFC6234] of "edwards25519 point generation seed (M)" and > "edwards25519 point generation seed (N)" respectively. Both hashes > decode to valid curve points. > > (The BoringSSL SPAKE2 code includes a whole bit of Python code in a > comment which would iterate the SHA-256 hash until a valid curve point > is found. But it turns out both seeds hash to a valid curve point > immediately.) > > Convenience links: > > https://tools.ietf.org/html/rfc7748 > https://tools.ietf.org/html/rfc8032 > https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-00 It would be good to hear some additional feedback before pushing an updated version of the document. Does anyone want to speak for or against adding the edwards25519 curve and making it MTI? -Ben From nobody Mon Sep 11 08:34:15 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 561D11330CF for ; Mon, 11 Sep 2017 08:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 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, 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 c1jCPxj-7tlC for ; Mon, 11 Sep 2017 08:34:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F741330CA for ; Mon, 11 Sep 2017 08:34:10 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAE1C1203C; Mon, 11 Sep 2017 15:34:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DAE1C1203C Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=simo@redhat.com Received: from ovpn-116-144.phx2.redhat.com (ovpn-116-144.phx2.redhat.com [10.3.116.144]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5D7375C549; Mon, 11 Sep 2017 15:34:09 +0000 (UTC) Message-ID: <1505144048.10402.12.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , Greg Hudson Cc: kitten@ietf.org Date: Mon, 11 Sep 2017 11:34:08 -0400 In-Reply-To: <20170911152526.GD96685@kduck.kaduk.org> References: <20170911152526.GD96685@kduck.kaduk.org> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 11 Sep 2017 15:34:10 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE edwards25519 group 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, 11 Sep 2017 15:34:12 -0000 On Mon, 2017-09-11 at 10:25 -0500, Benjamin Kaduk wrote: > On Thu, Sep 07, 2017 at 01:16:58PM -0400, Greg Hudson wrote: > > I would like to add a SPAKE group specification using the Edwards > > 2^255-19 curve used by the ed25519 signature algorithm.  I was > > recently > > able to implement this group by adapating the SPAKE2 code from > > BoringSSL. > > > > I would like to specify that the new group is the only > > mandatory-to-implement group, as I believe that it is the easiest > > to > > implement in constant time and has the potential to be the most > > performant choice.  (P-256 may be more performant in practice in > > some > > situation, as OpenSSL normally uses an optimized assembly > > implementation > > of P-256, while the BoringSSL Edwards 25519 SPAKE code is in > > C.  But in > > my tests they're pretty close even so.) > > In general I support this proposal. > > > I would like to renumber the groups so that the new group is 1 and > > the > > three NIST groups are 2, 3, and 4.  As we have not assigned pa-data > > or > > key usage code points yet, there should be no interoperability > > issues > > with renumbering the groups. > > Seems reasonable. > > > I suggest the group name "edwards25519", which is used in RFC > > 7748.  The > > shorter name "ed25519" could create confusion with the ed25519 > > signature > > algorithm. > > Sure. > > > Here is the registry entry (please verify that my RFC 7748 and RFC > > 8032 > > references seem correct): > > > > * ID Number: 1 > > * Name: edwards25519 > > * Specification: [RFC7748] section 4.1 (edwards25519) > > Yes, that's the right section for edwards25519, even though the > section > title is Curve25519.  RFC 7748 does have an external reference for > ed25519 > (and the edwards25519 curve), which is a Springer publication, so the > RFC is probably better. > > > * Serialization: [RFC8032] section 3.1 > > RFC 8032 seems to refer to bit-string serializations, whereas our > group > elements are represented as octet strings.  RFC 8032 does describe > packing > bit strings into octet strings in section 2, so perhaps the given > reference > suffices. > > > * Multiplier Length: 32 > > * Multiplier Conversion: RFC 8032 section 3.1 > > * SPAKE M Constant: > > 5ada7e4bf6ddd9adb6626d32131c6b5c51a1e347a3478f53cfcf441b88eed12e > > * SPAKE N Constant: > > 10e3df0ae37d8e7a99b5fe74b44672103dbddcbd06af680d71329a11693bc778 > > > > To justify the M and N values (which are the same ones used by > > BoringSSL), I would like to add an appendix B titled "SPAKE M and N > > Value Selection" with the text: > > Sure. > > >     The M and N constants for the edwards25519 group are the SHA- > > 256 > >     hashes [RFC6234] of "edwards25519 point generation seed (M)" > > and > >     "edwards25519 point generation seed (N)" respectively.  Both > > hashes > >     decode to valid curve points. > > > > (The BoringSSL SPAKE2 code includes a whole bit of Python code in a > > comment which would iterate the SHA-256 hash until a valid curve > > point > > is found.  But it turns out both seeds hash to a valid curve point > > immediately.) > > > > Convenience links: > > > > https://tools.ietf.org/html/rfc7748 > > https://tools.ietf.org/html/rfc8032 > > https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-00 > > It would be good to hear some additional feedback before pushing an > updated version of the document.  Does anyone want to speak for > or against adding the edwards25519 curve and making it MTI? In favor. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Mon Sep 11 09:01:20 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 68E5613314E for ; Mon, 11 Sep 2017 09:01:13 -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, 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 k9rUVBC8CKZ1 for ; Mon, 11 Sep 2017 09:01:04 -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 A989713314D for ; Mon, 11 Sep 2017 09:01:04 -0700 (PDT) X-AuditID: 1209190e-afbff700000008e4-df-59b6b33fd10c 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.EA.02276.F33B6B95; Mon, 11 Sep 2017 12:01:03 -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 v8BG12Tn032589 for ; Mon, 11 Sep 2017 12:01:03 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [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 v8BG11Wq006405 for ; Mon, 11 Sep 2017 12:01:02 -0400 From: Greg Hudson To: kitten@ietf.org Date: Mon, 11 Sep 2017 12:01:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUixG6nomu/eVukwfu1ChZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuGDDawFswUrNm+ezdTAeJ63i5GTQ0LAROL6n63MILaQwGIm if5Fml2MXED2cUaJHV8Ps0I4HUwSF35PZAepYhNQlli/fysLiC0iICyxe+s7sG5hATWJJ9tv gNksAqoSWw9MY+pi5ODgFTCUOLijFiTMKyAocXLmE7BWZgEJiYMvXjBPYOSehSQ1C0lqASPT KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3UlNJNjKAQ4JTk28E4qcH7EKMAB6MSD29D 77ZIIdbEsuLK3EOMkhxMSqK8745viRTiS8pPqcxILM6ILyrNSS0+xCjBwawkwnt2PVA5b0pi ZVVqUT5MSpqDRUmcV1yjMUJIID2xJDU7NbUgtQgmK8PBoSTBy7MJqFGwKDU9tSItM6cEIc3E wQkynAdo+LGNIMOLCxJzizPTIfKnGCWlxHnlQZoFQBIZpXlwva8YxYFeEOb1BMnyAOMZrusV 0EAmoIE8l7aADCxJREhJNTA2N0/OrvzSoX3+60/u4H23G9fLr3b8NzP81FWv5P+MjUkRCc+z W2qOqrSJOnyf++ey7PRWow9z907WcZoQzMfj+t9/WXPoO/eSn6Xf10Td/X7kIxujwsH9ZR7x jw8LvS/b8DM9ZdbyZdffT+9ukTeL/JpTerOak/NdXqZ1war/ct9XZ05d2eylxFKckWioxVxU nAgAUBR+p6QCAAA= Archived-At: Subject: [kitten] SPAKE and weak checksum types 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, 11 Sep 2017 16:01:13 -0000 Currently the SPAKE draft says, in security considerations: Weak checksums present a risk to the transcript checksum. Any etype with a checksum based on one of the following algorithms MUST NOT be used: * CRC32 * MD4 * MD5 I have several problems with this clause. The implementer doesn't get to choose the transcript checksum type; it is specified as the required checksum type of the initial reply key. To conform to this clause, and implementer must decline to offer SPAKE preauth if the initial reply key uses RC4 or DES. While those enctypes are problematic, I don't think it's ideal for the KDC to throw up its hands and use encrypted timestamp just because the SPAKE transcript checksum would be using MD5 (which is still preimage-resistant as far as we know). Also, this clause focuses on the transcript checksum, which seems like a difficult attack vector as it is merely one component of key derivation, while ignoring other possible weaknesses of the reply key encryption type, such as the integrity tag on the key confirmation or the confidentiality of second-factor data. I propose to replace this clause with the following wording: This mechanism does not upgrade the encryption type of the initial reply key, and relies on that encryption type for confidentiality, integrity, and pseudo-random functions. If the client long-term key uses a weak encryption type, an attacker might be able to subvert the exchange, and the replaced reply key will also be of the same weak encryption type. (During the design of the SPAKE preauth mechanism, I did consider the possibility of upgrading the reply key encryption type, so that the client long-term key is only used as a source of octets for the shared secret input to the SPAKE algorithm. Although that would be a neat benefit for deployments with a lot of legacy DES or RC4 client keys, it would significantly complicate the spec. It would also introduce a risk of a downgrade attack on the initial reply key enctype, e.g. if the KDC could be fooled into thinking that DES is a better choice than AES by altering the request enctype list.) From nobody Mon Sep 11 12:35:32 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 283911331EB for ; Mon, 11 Sep 2017 12:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 B0ET0YzQ1PUr for ; Mon, 11 Sep 2017 12:35:28 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062FC1331F7 for ; Mon, 11 Sep 2017 12:35:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 076E62AB7A; Mon, 11 Sep 2017 19:35:18 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGQNANl2b4UH; Mon, 11 Sep 2017 19:35:17 +0000 (UTC) Received: from [100.73.146.149] (74.sub-70-197-78.myvzw.com [70.197.78.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id D724B2A815; Mon, 11 Sep 2017 19:35:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Henry B Hotz X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Mon, 11 Sep 2017 12:35:12 -0700 Cc: kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg Hudson Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 11 Sep 2017 19:35:30 -0000 IIUC you are concerned with the case that someone will stand up a kdc which w= ill opportunistically use SPAKE, but supports older/weaker stuff. By its nat= ure such a beast will be vulnerable to downgrade attacks and you can't solve= that in SPAKE.=20 That said, I'm OK with your proposed change. It does point the finger in th= e right direction.=20 Personal email. hbhotz@oxy.edu > On Sep 11, 2017, at 9:01 AM, Greg Hudson wrote: >=20 > Currently the SPAKE draft says, in security considerations: >=20 > Weak checksums present a risk to the transcript checksum. Any etype > with a checksum based on one of the following algorithms MUST NOT be > used: >=20 > * CRC32 > * MD4 > * MD5 >=20 > I have several problems with this clause. The implementer doesn't get > to choose the transcript checksum type; it is specified as the required > checksum type of the initial reply key. To conform to this clause, and > implementer must decline to offer SPAKE preauth if the initial reply key > uses RC4 or DES. While those enctypes are problematic, I don't think > it's ideal for the KDC to throw up its hands and use encrypted timestamp > just because the SPAKE transcript checksum would be using MD5 (which is > still preimage-resistant as far as we know). >=20 > Also, this clause focuses on the transcript checksum, which seems like a > difficult attack vector as it is merely one component of key derivation, > while ignoring other possible weaknesses of the reply key encryption > type, such as the integrity tag on the key confirmation or the > confidentiality of second-factor data. >=20 > I propose to replace this clause with the following wording: >=20 > This mechanism does not upgrade the encryption type of the initial > reply key, and relies on that encryption type for confidentiality, > integrity, and pseudo-random functions. If the client long-term key > uses a weak encryption type, an attacker might be able to subvert > the exchange, and the replaced reply key will also be of the same > weak encryption type. >=20 > (During the design of the SPAKE preauth mechanism, I did consider the > possibility of upgrading the reply key encryption type, so that the > client long-term key is only used as a source of octets for the shared > secret input to the SPAKE algorithm. Although that would be a neat > benefit for deployments with a lot of legacy DES or RC4 client keys, it > would significantly complicate the spec. It would also introduce a risk > of a downgrade attack on the initial reply key enctype, e.g. if the KDC > could be fooled into thinking that DES is a better choice than AES by > altering the request enctype list.) >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Sep 11 13:38: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 A0364132F35 for ; Mon, 11 Sep 2017 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ymYUEsoDc2iT for ; Mon, 11 Sep 2017 13:38:43 -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 438F7129A89 for ; Mon, 11 Sep 2017 13:38:43 -0700 (PDT) X-AuditID: 12074425-c57ff70000004927-84-59b6f4511b1a 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id DF.C1.18727.254F6B95; Mon, 11 Sep 2017 16:38:42 -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 v8BKcefH016713; Mon, 11 Sep 2017 16:38:41 -0400 Received: from [18.101.8.201] (VPN-18-101-8-201.MIT.EDU [18.101.8.201]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8BKccjZ029620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Sep 2017 16:38:40 -0400 To: Henry B Hotz References: Cc: kitten@ietf.org From: Greg Hudson Message-ID: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> Date: Mon, 11 Sep 2017 16:38:38 -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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrRv0ZVukwZ0WLouP9xayWBzdvIrF gcljyZKfTB5bm/4yBzBFcdmkpOZklqUW6dslcGV0vfrOUvCCveJb51nmBsaVbF2MnBwSAiYS N49sYu9i5OIQEljMJHH0+2M2CGcjo8TRfXuYIZyjTBIdp5sYQVqEBYwl9vT/YQexRQQUJRpb joONEhJIkvj64h0ziM0sICyxfM1ZsDibgLLE+v1bWUBsXgEriWWLr4DFWQRUJY4vmQpmiwpE SDzs3MUOUSMocXLmE7B6TgFriSunt7BBzNST2HH9FyuELS+x/e0c5gmMArOQtMxCUjYLSdkC RuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuhZ6uZkleqkppZsYQaHK7qK6g3HOX69DjAIcjEo8 vA292yKFWBPLiitzDzFKcjApifK+O74lUogvKT+lMiOxOCO+qDQntfgQowQHs5IIr8hDoHLe lMTKqtSifJiUNAeLkjivuEZjhJBAemJJanZqakFqEUxWhoNDSYI34TNQo2BRanpqRVpmTglC momDE2Q4D9DwiyA1vMUFibnFmekQ+VOMuhw3Hl7/wyTEkpeflyolzssJUiQAUpRRmgc3B5xi UjlOvmIUB3pLmHcqSBUPMD3BTXoFtIQJaAnPpS0gS0oSEVJSDYzudo59f965nfP2nyC4U15u nsY902//P79ui115aH9089MnBWu59m5WqPmy2YpVcb7nl85au4TZeX6MoXq3hB1Srjv7HQ// segPv8m0Xzcflbe0HnFQcC5P3GWZ/UatMP+rzPy6lpnOYoUsbyQrvryvco269Kjhzc68KT9e uklMvTN51zsfUxklluKMREMt5qLiRABSXWEKDAMAAA== Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 11 Sep 2017 20:38:44 -0000 On 09/11/2017 03:35 PM, Henry B Hotz wrote: > IIUC you are concerned with the case that someone will stand up a kdc which will opportunistically use SPAKE, but supports older/weaker stuff. By its nature such a beast will be vulnerable to downgrade attacks and you can't solve that in SPAKE. If the KDC downgrades itself to encrypted timestamp for DES/RC4 keys, only a passive attack is needed, versus an active attack to downgrade to encrypted timestamp. The KDC can't be responsible for preventing downgrades to encrypted timestamp; the client has to refuse it (assuming no FAST or TLS tunneling). If a client allows it but the KDC does not, the AS request will fail, so the attack will at least be visible, but the client has already sent a ciphertext which can be dictionary attacked. It will be much easier to configure a client to refuse encrypted timestamp if it doesn't have to worry about the KDC refusing SPAKE based on what enctypes it has for the client long-term key. From nobody Tue Sep 12 09:46:40 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 71E65132D96 for ; Tue, 12 Sep 2017 09:46:39 -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 sA_yG8gj3Xh6 for ; Tue, 12 Sep 2017 09:46:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B04B132403 for ; Tue, 12 Sep 2017 09:46:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4C7B72682; Tue, 12 Sep 2017 16:46:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C4C7B72682 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rharwood@redhat.com Received: from localhost (ovpn-66-194.rdu2.redhat.com [10.10.66.194]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83E85179C8; Tue, 12 Sep 2017 16:46:37 +0000 (UTC) From: Robbie Harwood To: Greg Hudson , Henry B Hotz Cc: kitten@ietf.org In-Reply-To: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> References: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> Date: Tue, 12 Sep 2017 12:47:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 12 Sep 2017 16:46:38 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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: Tue, 12 Sep 2017 16:46:39 -0000 --=-=-= Content-Type: text/plain Greg Hudson writes: > On 09/11/2017 03:35 PM, Henry B Hotz wrote: > >> IIUC you are concerned with the case that someone will stand up a kdc >> which will opportunistically use SPAKE, but supports older/weaker >> stuff. By its nature such a beast will be vulnerable to downgrade >> attacks and you can't solve that in SPAKE. > > If the KDC downgrades itself to encrypted timestamp for DES/RC4 keys, > only a passive attack is needed, versus an active attack to downgrade > to encrypted timestamp. > > The KDC can't be responsible for preventing downgrades to encrypted > timestamp; the client has to refuse it (assuming no FAST or TLS > tunneling). I think this is the important part for me: we tend to put the responsibility on the client to ensure that it receives an adequate level of protection. > It will be much easier to configure a client to refuse encrypted > timestamp if it doesn't have to worry about the KDC refusing SPAKE > based on what enctypes it has for the client long-term key. Agreed. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlm4D5kACgkQJTL5F2qV pEK9GhAAhtw+1BNfBz2MlbpGxQ3boOa8DPFSVaVnS8E2BMt1XQyciVgM48YA8Ef1 8DQhhFD6fFoB8NCkhuzg2Coi3WuxpFdLtnFFXPTz43TcyLkZGF9SS+g506mGxU1t R3PkUvT8kO+jOkFYaU6olax2V0VqOc0piWjJ7xib8bgJ/3k+JuotCN4XQuTiqt0E Mw4LHolvmdX2qoGTTOas/RRM1d5SrGyhYU45rtZauFIJVzkVVLDcQPkkr3kqm53q jFo3uMO83rYmJ7qBWEyetIZn3dH+29bkW4F0sj9NvoEef5wpUAruCUNZbPJ8D9Em kp3VSRcLHdG8clgMPj+NaGCB1tXY2AXB9ywVrRtCKASANMFt/M8vbdkwbVzmoJqB +5Wvz0WKJVay6oCafpxJh3sGrUUZN1pOznkBP5MsG9sNvZUr7LXibVcJyLXN3nMb PjVStDolRsu/SLBY6pC9AgFc8c+kCsMnNM3nKx4j/NBKF8rlQbAYY3KKIgidj3V7 3XTN3h57IpdVOirlk+uX5+ioP+aCX1f7i9XZbZ4YJsIQSAjSgEdup9uphUr55PeL kn1x2vAMVTdeN6GM6DRbKVG81HJlpTt3Dd73GmxZuqp8nefkzcQ+AG0oDPTtmDhO 6w2+BIlZnvOZhcokw0Z8QNzjIDFPmQnpicmii3z/m96HApU57p8= =0jBP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 12 17:10:11 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 65369132F82 for ; Tue, 12 Sep 2017 17:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 d3bts2g2RXyP for ; Tue, 12 Sep 2017 17:10:09 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE857132707 for ; Tue, 12 Sep 2017 17:10:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id DF96A2B34E for ; Wed, 13 Sep 2017 00:10:07 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YtP32h5zXwq for ; Wed, 13 Sep 2017 00:10:07 +0000 (UTC) Received: from [172.20.167.249] (unknown [12.145.98.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 8E20C2AE62 for ; Wed, 13 Sep 2017 00:10:07 +0000 (UTC) From: "Henry B (Hank) Hotz, CISSP" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> Date: Tue, 12 Sep 2017 17:10:05 -0700 To: "kitten@ietf.org " Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [kitten] Any Interest in a Key Delivery Service? 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, 13 Sep 2017 00:10:10 -0000 I have run into a couple of cases where I wanted the kdc to provide -- = not a service ticket -- but an actual encryption key for some data at = rest. (Specifically an encrypted disk or a database.) There are obvious problems to be addressed, or at least agreed to. But = just generally is it worth talking about or should we leave this space = to the HSM folk? Personal email. hbhotz@oxy.edu From nobody Tue Sep 12 18:31:01 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 777A8132EBF for ; Tue, 12 Sep 2017 18:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=kenh@pobox.com header.d=pobox.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 1eh8ZEx2lqzX for ; Tue, 12 Sep 2017 18:30:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A14132F2E for ; Tue, 12 Sep 2017 18:30:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id BA51F8E633; Tue, 12 Sep 2017 21:30:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:mime-version:content-type:date :message-id; s=sasl; bh=Yb9hXBemXA4KrgXVIiNinIInk94=; b=K8cw7BsM DydxyzZe+lfBOcwtHawewZ1UA7SolPljZTjBnmrvCDmQsYwbBMDiTobseRISGefj kOuEFhRFe8JXyUDvlT9c1eCZ68I3bUIVAbfk16Z/VIjq7+g37aYvFZYhkhOBJztR S43+yw7waMtekZtQLbDHaLOkxXxc2gjT2Tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:mime-version:content-type:date :message-id; q=dns; s=sasl; b=KOHSKbVWssRC88138IFaoAKm16ju6fw7tR uwW/cuuUPE9NzHt8inRZUl4Jqpqz74O09ID4+1RGTy08m3wp7V78egMgTATBEBaG LGzOrokKwG1ZVVl8vfpacKx3b3zaLXw47cxgxOdc+0IHilVm95kSc+e37mn8cptX ZTmyUjCIc= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B1BEE8E632; Tue, 12 Sep 2017 21:30:57 -0400 (EDT) Received: from paradise-falls.internal (unknown [96.255.19.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 1F5738E631; Tue, 12 Sep 2017 21:30:57 -0400 (EDT) From: Ken Hornstein To: "Henry B (Hank) Hotz, CISSP" cc: "kitten@ietf.org " In-Reply-To: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> References: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Sep 2017 21:30:56 -0400 X-Pobox-Relay-ID: 31023D68-9823-11E7-88A8-9D2B0D78B957-90216062!pb-smtp2.pobox.com Message-Id: <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 13 Sep 2017 01:30:59 -0000 >I have run into a couple of cases where I wanted the kdc to provide -- >not a service ticket -- but an actual encryption key for some data at >rest. (Specifically an encrypted disk or a database.) It seems like a lot of people use KMIP for that. I think it would make sense to be able to use Kerberos to authenticate to KMIP, but in my brief interaction with some people who claimed to be KMIP people, they did not understand why I would want that (there is a super brief mention of Kerberos in the protocol document, but if you read it closely clearly they weren't serious about doing Kerberos authentication for real; the protocol would need a lot more specification to be something you could implement). --Ken From nobody Tue Sep 12 22:12:00 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 633411330BF for ; Tue, 12 Sep 2017 22:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 R3y_Z5YfB3-x for ; Tue, 12 Sep 2017 22:11:57 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2290F133059 for ; Tue, 12 Sep 2017 22:11:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 25430C8938; Wed, 13 Sep 2017 05:11:56 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo01-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygBMFkilwjNy; Wed, 13 Sep 2017 05:11:56 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 930EDC08BD; Wed, 13 Sep 2017 05:11:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> Date: Tue, 12 Sep 2017 22:11:50 -0700 Cc: "kitten@ietf.org " Content-Transfer-Encoding: quoted-printable Message-Id: <7BAC4A7B-5585-4CF0-8373-9BD54C3281FD@oxy.edu> References: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> To: Ken Hornstein X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 13 Sep 2017 05:11:59 -0000 > On Sep 12, 2017, at 6:30 PM, Ken Hornstein wrote: >=20 >> I have run into a couple of cases where I wanted the kdc to provide = -- >> not a service ticket -- but an actual encryption key for some data at >> rest. (Specifically an encrypted disk or a database.) >=20 > It seems like a lot of people use KMIP for that. I think it would = make > sense to be able to use Kerberos to authenticate to KMIP, but in my = brief > interaction with some people who claimed to be KMIP people, they did > not understand why I would want that Bashes head against wall. . . > (there is a super brief mention > of Kerberos in the protocol document, but if you read it closely = clearly > they weren't serious about doing Kerberos authentication for real; the > protocol would need a lot more specification to be something you could > implement). >=20 > =E2=80=94Ken OK, so should we produce a spec that tells them how to do it, or would = that just trigger NIH (not invented here)? Personal email. hbhotz@oxy.edu From nobody Wed Sep 13 06:32:00 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 AFFC5133036 for ; Wed, 13 Sep 2017 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=kenh@pobox.com header.d=pobox.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 9l_dTQOKRX66 for ; Wed, 13 Sep 2017 06:31:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C161321A1 for ; Wed, 13 Sep 2017 06:31:56 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 056D5985B5; Wed, 13 Sep 2017 09:31:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:mime-version:content-type:date :message-id; s=sasl; bh=v19n6qMQ+mOQJ1PpFOqScVTqmKY=; b=nywwVjgf PPlB/VJP4KajJCzaalRqxjlNOGHFOIWsN4mHewBCnQKdHLB0B4Ql0cgF3Kh5hWOC dIoThAgsYXvAyLRE4UTxaO8tNNqnlPLeNZFSLoY/qWmSoG/0mnx0vLXIjDA6SUAQ U8uXwhEX/uGdSF0KZXS8MB8Z3KExM/5+q3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:mime-version:content-type:date :message-id; q=dns; s=sasl; b=FFjY1m5jPVVRCfVFvIFIoGJUAuiOl0BoQ9 jVmn5em94gq1qsVnE5fWCR/nuXTquvpXp8tIF94KflCLqKxJ/80F1H6ZUycK8BAp 17lkLrgggjWOznC2Aa8fcJfwN/La2+mAFbAMVh9TVaqF0woDG2ODgzmulU+q1RWk Q7O6R5rrc= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F275C985B4; Wed, 13 Sep 2017 09:31:55 -0400 (EDT) Received: from zoolander.cmf.nrl.navy.mil (unknown [134.207.12.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 67660985B1; Wed, 13 Sep 2017 09:31:55 -0400 (EDT) From: Ken Hornstein To: "Henry B (Hank) Hotz, CISSP" cc: "kitten@ietf.org " In-Reply-To: <7BAC4A7B-5585-4CF0-8373-9BD54C3281FD@oxy.edu> References: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> <7BAC4A7B-5585-4CF0-8373-9BD54C3281FD@oxy.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Sep 2017 09:31:54 -0400 X-Pobox-Relay-ID: E8FE84F8-9887-11E7-9AE3-9D2B0D78B957-90216062!pb-smtp2.pobox.com Message-Id: <20170913133155.F275C985B4@pb-smtp2.pobox.com> Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 13 Sep 2017 13:31:59 -0000 >OK, so should we produce a spec that tells them how to do it, or would >that just trigger NIH (not invented here)? Good question! In my experience the issues are a) lack of specification, and b) getting people to implement the specification. I do think it would be .... not worth the effort to go through the IETF process to produce something for KMIP. You need to work in their space (OASIS). --Ken From nobody Wed Sep 13 09:57: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 812BF1321DF for ; Wed, 13 Sep 2017 09:57:33 -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, 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 QT9m9o5SQ4so for ; Wed, 13 Sep 2017 09:57:32 -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 4E5451321B6 for ; Wed, 13 Sep 2017 09:57:31 -0700 (PDT) X-AuditID: 12074422-875ff7000000295c-6c-59b9637a0b54 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id E0.27.10588.A7369B95; Wed, 13 Sep 2017 12:57:31 -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 v8DGvUkB012295 for ; Wed, 13 Sep 2017 12:57:30 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [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 v8DGvSW9022280 for ; Wed, 13 Sep 2017 12:57:30 -0400 From: Greg Hudson To: kitten@ietf.org Date: Wed, 13 Sep 2017 12:57:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUixG6nrludvDPSYM9mFoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro79TpuArS8X5STdZGhgbWboYOTkkBEwk7m5/DWRzcQgJLGaS WNJwggkkISRwnFHi2EEFCLuDSaJ3aQGIzSagLLF+/1awZhEBYYndW98xg9jCQINaVi1lB7FZ BFQlZuzrYeti5ODgFTCU6P5fDBLmFRCUODnzCVgrs4CExMEXL5gnMHLPQpKahSS1gJFpFaNs Sm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRrD/XZR2ME7853WIUYCDUYmH94Hlzkgh 1sSy4srcQ4ySHExKorx7dYFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHiDooByvCmJlVWpRfkw KWkOFiVxXnGNxgghgfTEktTs1NSC1CKYrAwHh5IE7/4koEbBotT01Iq0zJwShDQTByfIcB6g 4ddAaniLCxJzizPTIfKnGFU5bjy8/odJiCUvPy9VSpx3TSJQkQBIUUZpHtycV4ziQO8I8/KD jOABxjjchFdAw5mAhp85vQNkeEkiQkqqgZGr+9n/phXe+n8XLtY7GrKjytNjKfPkiHkLxE6w rHr7asPu22nSM6/9veTs8vLru61NHzOPHGPP9P2sk+zsYtkf31CjyujT0GOanvGiq9I1UETb +bTlt22BWadM3RtO8bD8+OXy9fDrFeHh2+TFEl1zeqYZGqXopBa8b1dSPGV3cuKER4+9jiux FGckGmoxFxUnAgDep2XZrgIAAA== Archived-At: Subject: [kitten] SPAKE key usage and padata type assignments 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, 13 Sep 2017 16:57:33 -0000 I have assigned the following key usage numbers to SPAKE preauth: 65 KEY_USAGE_SPAKE_TRANSCRIPT 66 KEY_USAGE_SPAKE_FACTOR Those assignments are sufficient to generate test vectors. We also need to assign a padata type. RFC 6113 established an IANA registry for padata types with new registrations subject to expert review. I think it would be reasonable to ask for a padata type registration at this time. Aside from the addition of the edwards25519 group (which would benefit from another non-coauthor +1), I am not aware of any open questions which could lead to non-interoperable changes in the protocol. From nobody Wed Sep 13 18:17:33 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 35940132339 for ; Wed, 13 Sep 2017 18:17:32 -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, 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 Ok0ZuDl35KqM for ; Wed, 13 Sep 2017 18:17:31 -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 05F59132F78 for ; Wed, 13 Sep 2017 18:17:30 -0700 (PDT) X-AuditID: 12074423-b1dff70000006fff-a0-59b9d8a994e3 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 0B.AE.28671.9A8D9B95; Wed, 13 Sep 2017 21:17:30 -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 v8E1HSSN025654; Wed, 13 Sep 2017 21:17:29 -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 v8E1HOdZ016840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 21:17:27 -0400 Date: Wed, 13 Sep 2017 20:17:25 -0500 From: Benjamin Kaduk To: Ken Hornstein Cc: "Henry B (Hank) Hotz, CISSP" , "kitten@ietf.org " Message-ID: <20170914011724.GN96685@kduck.kaduk.org> References: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrLvqxs5Ig9n9zBYf7y1ksehvOs5i cXTzKhYHZo8lS34yeWxt+svscfGScgBzFJdNSmpOZllqkb5dAlfG17d/2Qvuslfs2TuJpYFx ClsXIweHhICJxPfTRl2MXBxCAouZJPYtbGGDcDYySnw4e4oZwrnKJLFi/XaWLkZODhYBVYkr y1pYQWw2ARWJhu7LzCCTRASUJM6ckwAJMwsUSsy62sYEEhYWsJX4OkMWJMwLtOv3r7VMILaQ QLbEuomnWSDighInZz5hgWjVkrjx7yVYK7OAtMTyfxwgYU4Ba4n+nyCLODlEBZQl5u1bxTaB UWAWku5ZSLpnIXQvYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuml5tZopeaUrqJERSy7C7K Oxhf9nkfYhTgYFTi4X1guTNSiDWxrLgy9xCjJAeTkijvXl2gEF9SfkplRmJxRnxRaU5q8SFG CQ5mJRHeU1eAcrwpiZVVqUX5MClpDhYlcV5xjcYIIYH0xJLU7NTUgtQimKwMB4eSBO/F60CN gkWp6akVaZk5JQhpJg5OkOE8QMNPg9TwFhck5hZnpkPkTzHqctx4eP0PkxBLXn5eqpQ478lr QEUCIEUZpXlwc0CpRiJ7f80rRnGgt4R594OM4gGmKbhJr4CWMAEtOXN6B8iSkkSElFQDY7y9 l0Pfp9D1345umsdcyiIp8jP2ebRDJ19A5uamkPZbsRW+b+Z6CW04//Rjz4bNwQ5GMieNq5T0 Vla9cjO3PCfzb8/EsCU92+tOVZT8eOLFxqG0886de4emLdZO2/9TasW618mzxO2CVOfYHdi0 5pTE3RNXz4ZJCl/he3Hu/FrNox/nvbHJ2qrEUpyRaKjFXFScCADLcoF+EAMAAA== Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 14 Sep 2017 01:17:32 -0000 On Tue, Sep 12, 2017 at 09:30:56PM -0400, Ken Hornstein wrote: > >I have run into a couple of cases where I wanted the kdc to provide -- > >not a service ticket -- but an actual encryption key for some data at > >rest. (Specifically an encrypted disk or a database.) > > It seems like a lot of people use KMIP for that. I think it would make > sense to be able to use Kerberos to authenticate to KMIP, but in my brief I don't know much about KMIP, but it does seem like there is not very much that would tie such a service to be part of and/or colocated with a Kerberos KDC. This functionality ought to be providable by a "generic kerberized service", i.e., something running elsewhere than the KDC that authenticates via kerberos. It could require initial tickets (e.g., via kinit -S kmip/hostname) without needing to be the KDC, and there's probably a lot of advantage in decoupling the protocol and implementation of the key-management service and the KDC. -Ben From nobody Wed Sep 13 18:36: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 6B556132F8F for ; Wed, 13 Sep 2017 18:36:33 -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, 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 zct8W1M-wIAB for ; Wed, 13 Sep 2017 18:36:32 -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 197F2132F82 for ; Wed, 13 Sep 2017 18:36:32 -0700 (PDT) X-AuditID: 12074425-cadff70000007029-86-59b9dd1f8281 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 04.A0.28713.F1DD9B95; Wed, 13 Sep 2017 21:36:31 -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 v8E1aTs8025340; Wed, 13 Sep 2017 21:36:30 -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 v8E1aPKo022804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 21:36:28 -0400 Date: Wed, 13 Sep 2017 20:36:25 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: Henry B Hotz , kitten@ietf.org, Robbie Harwood Message-ID: <20170914013625.GO96685@kduck.kaduk.org> References: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5QAgd0e35j3NYeGe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsUixG6nrit/d2ekQVsru8XHewtZLI5uXsVi sbOnidWB2WPJkp9MHlub/jJ7vN93lS2AOYrLJiU1J7MstUjfLoEr4+jJlcwFS4UrtjX2sTcw LhLoYuTgkBAwkTi1Ta+LkYtDSGAxk8SxKZNZIZyNjBJP50xngXCuMklcOvmIsYuRk4NFQFVi 8f8HzCA2m4CKREP3ZTBbREBR4tmquSwgNrNAosSP7t1gcWEBY4k9/X/YQWxekG13N7JDDN3E KNF7eC8rREJQ4uTMJ1DNZRKLD5xmAzmPWUBaYvk/DpAwp4CmxL17D8BuEBVQlpi3bxXbBEaB WUi6ZyHpnoXQDRHWkrjx7yUThrC2xLKFr5khbFuJdevesyxgZF/FKJuSW6Wbm5iZU5yarFuc nJiXl1qka6GXm1mil5pSuokRHBkuqjsY5/z1OsQowMGoxMP7wHJnpBBrYllxZe4hRkkOJiVR 3r26QCG+pPyUyozE4oz4otKc1OJDjCpAux5tWH2BUYolLz8vVUmE99QVoDrelMTKqtSifJgy aQ4WJXFecY3GCCGB9MSS1OzU1ILUIpisDAeHkgTv3NtAjYJFqempFWmZOSUIaSYOzkOMEhw8 QMPPgdTwFhck5hZnpkPkTzEqSonzOt4BSgiAJDJK8+B6QQlNInt/zStGcaC3hHkPgbTzAJMh XPcroMFMQIPPnN4BMrgkESEl1cBoO7F1apWAFsPyqTMjruz8XcsSE9gXw78yWvnt5b50k803 12ouWG2rUiGfIJfefDXR98lx3wk5TH/+2Gr2PtFfffqEkW+zCwPzi/CLZ/4z2LIb6rM6hORd 3varcL3n2bdLWL/qyeQ91ek7EXUxLuP7/Pc9+63Dnq/6K/5WNNnP2Lz62LOq7jwlluKMREMt 5qLiRAB0+k5WQwMAAA== Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 14 Sep 2017 01:36:33 -0000 --5QAgd0e35j3NYeGe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 12, 2017 at 12:47:21PM -0400, Robbie Harwood wrote: > Greg Hudson writes: >=20 > > On 09/11/2017 03:35 PM, Henry B Hotz wrote: > > > >> IIUC you are concerned with the case that someone will stand up a kdc > >> which will opportunistically use SPAKE, but supports older/weaker > >> stuff. By its nature such a beast will be vulnerable to downgrade > >> attacks and you can't solve that in SPAKE. > > > > If the KDC downgrades itself to encrypted timestamp for DES/RC4 keys, > > only a passive attack is needed, versus an active attack to downgrade > > to encrypted timestamp. I must still be foggy from recovering from being sick; could you walk me through the passive attack a bit more slowly (or which scenarios are being compared)? > > The KDC can't be responsible for preventing downgrades to encrypted > > timestamp; the client has to refuse it (assuming no FAST or TLS > > tunneling). >=20 > I think this is the important part for me: we tend to put the > responsibility on the client to ensure that it receives an adequate > level of protection. Yes, this seems like a key point. > > It will be much easier to configure a client to refuse encrypted > > timestamp if it doesn't have to worry about the KDC refusing SPAKE > > based on what enctypes it has for the client long-term key. >=20 > Agreed. Yup; I think you should go ahead and make this change. We can (and are!) work on deprecating weak enctypes independently of new preauth mechanisms. -Ben --5QAgd0e35j3NYeGe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlm53RQACgkQKNmm82Tr dRIDnAwcCn9GdY8X/CHQkvteeVIKLlMSbv1DqQJ3dZ4DGdFzpsazMNAd1Hy/Y9I9 IxFHGZl4AcywTRcZqzr+mjOCNpM8sRwanjjZJI4+hFTiPMdQ/+BvC1RNjz8dKHSS vzHVfk7U2SyZvVO1SmU2g7KHtxrxvfFqNT2sq+DsuKeehUOv0PkCeSfNQYfqHF0B 8fuDukTqwvMe+TeP9hfjtQHKNtUJ4yK2J2d0sxn58/ab1+73E4cGd8JDu6bQVqR1 aSI9p9K8Sk1KXWjnXHtp8RFRdSCw3XFnA+r5eLioPY5K9lTyjmnfckaUxDyHe9lM 3AU6wuAbtEGJe2y84Gj6eXYSLtUsc52aIoWrX+FPvfqMLn+w8TxWCr2FAiRd7GWi cdPdHwLUu7Ufu02xBk58mp7PcgZAISIfcn8135wvaLwO2evJF3KTMREl2KxqdnEI HhGL55Q6jzuqZBLJGp1GmCrZH/b8NkqQxWwh85uh+W9jUw2RopRXoPYZruhrUTqs efWu2Ey+UCtkeg== =s+50 -----END PGP SIGNATURE----- --5QAgd0e35j3NYeGe-- From nobody Wed Sep 13 18:47:50 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 E45B2132F8F for ; Wed, 13 Sep 2017 18:47:49 -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, 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 2aio3GbY58es for ; Wed, 13 Sep 2017 18:47:48 -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 565E71323A3 for ; Wed, 13 Sep 2017 18:47:48 -0700 (PDT) X-AuditID: 1209190e-b1bff700000005aa-1b-59b9dfc34750 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id A1.12.01450.3CFD9B95; Wed, 13 Sep 2017 21:47:47 -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 v8E1lj5C029075; Wed, 13 Sep 2017 21:47:46 -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 v8E1lgkn027089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 21:47:44 -0400 Date: Wed, 13 Sep 2017 20:47:42 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20170914014741.GP96685@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.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrHv4/s5Ig+PfBC2Obl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIXretgLujgr1t7VbmCcx97FyMkhIWAi0fb3NXMXIxeHkMBi JokP95azQjgbGSWmXbzJDFIlJHCVSWLphyAQm0VAVeLq8iVgcTYBFYmG7stgtoiAosSzVXNZ QGxmAWGJ5WvOsoHYwgKOEhOnXATbxgu07daLh6wQMw0ljq+9xwoRF5Q4OfMJVK+WxI1/L5m6 GDmAbGmJ5f84QMKcAkYSxzqWgpWICihLzNu3im0Co8AsJN2zkHTPQuhewMi8ilE2JbdKNzcx M6c4NVm3ODkxLy+1SNdYLzezRC81pXQTIzgcJfl2ME5q8D7EKMDBqMTD+8ByZ6QQa2JZcWXu IUZJDiYlUd69ukAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrynrgDleFMSK6tSi/JhUtIcLEri vOIajRFCAumJJanZqakFqUUwWRkODiUJXj1g3AkJFqWmp1akZeaUIKSZODhBhvMADV94D2R4 cUFibnFmOkT+FKOilDgvO0izAEgiozQPrheULiSy99e8YhQHekWYdxpIOw8w1cB1vwIazAQ0 +MzpHSCDSxIRUlINjIKX5eVTrsqoZwh9XigsdrvqxGHvQ++S5m7bF/h9xf/u2JJcgQcqh6c8 Fw0y9WR9whYn2dB4+JTJuYYTyWGuKfcl+Ro/HN/PdfXqrat7xUKr5JZGvZts5cLn66HkK8y6 zlEk8+6d7RUcN8yY571lmOLNsqVJN1Omfqrq2XiOA3b3GDrEZmkJKbEUZyQaajEXFScCAElD 5wjyAgAA Archived-At: Subject: Re: [kitten] SPAKE key usage and padata type assignments 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, 14 Sep 2017 01:47:50 -0000 On Wed, Sep 13, 2017 at 12:57:28PM -0400, Greg Hudson wrote: > I have assigned the following key usage numbers to SPAKE preauth: > > 65 KEY_USAGE_SPAKE_TRANSCRIPT > 66 KEY_USAGE_SPAKE_FACTOR > > Those assignments are sufficient to generate test vectors. We also need > to assign a padata type. RFC 6113 established an IANA registry for > padata types with new registrations subject to expert review. Subject to expert review, provided that they only authenticate clients authenticate KDCs, and/or establish the reply key, which does appear to be the case here. > I think it would be reasonable to ask for a padata type registration at I concur. Would you like me to make the request with my chair hat? > this time. Aside from the addition of the edwards25519 group (which > would benefit from another non-coauthor +1), I am not aware of any open > questions which could lead to non-interoperable changes in the protocol. Me, neither. And yes, it would be very nice to have another no-coauthor +1. Though my current inclination is that we should go ahead with that change anyway, in the absence of any objections. -Ben From nobody Wed Sep 13 19:02:37 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 3C1441323A3 for ; Wed, 13 Sep 2017 19:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=kenh@pobox.com header.d=pobox.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 lOzSzRQ-SlBl for ; Wed, 13 Sep 2017 19:02:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4311270AB for ; Wed, 13 Sep 2017 19:02:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id CED6FA2792 for ; Wed, 13 Sep 2017 22:02:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:in-reply-to:references:mime-version:content-type:date :message-id; s=sasl; bh=6lAfTIGQSmr50aV+gzqrxj7RU3U=; b=cTdi5/Mw 7bJh4v4PQqJAWIKexbUX3o+emwdDF7JmXb92YWOFIPeZDBGH/Pqw7FUzY9boG7gA OHvfDSaoK8pnURZRT0rXDIJaQ9a48h7IuJZjMyF9mU6k0HITvaiNmcUX9ZlIczKK eMR2uyaKl46CuKRBQWiYfkpkdt+9N0o6iXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :in-reply-to:references:mime-version:content-type:date :message-id; q=dns; s=sasl; b=RpePpznSZaIIuuU0y7o/HH5Rd5v9Ri61Ng 16oRQxuh++lXjzdEHJUAsWwsjo1SdbQFxsiAZWcMLcSlEUSi0AU6XqrJrdRiv4tz lzr+E+PAO5Guml0OYvMFDTT+wa0HfbW3Khm6vbe5nuMqlG5wZ+J5U3bG5xjnEzki l+7kawR90= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id C6D85A2791 for ; Wed, 13 Sep 2017 22:02:32 -0400 (EDT) Received: from paradise-falls.internal (unknown [96.255.19.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 4EDC2A2790 for ; Wed, 13 Sep 2017 22:02:32 -0400 (EDT) From: Ken Hornstein To: In-Reply-To: <20170914011724.GN96685@kduck.kaduk.org> References: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> <20170914011724.GN96685@kduck.kaduk.org> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Sep 2017 22:02:31 -0400 X-Pobox-Relay-ID: C50AA072-98F0-11E7-8D5C-9D2B0D78B957-90216062!pb-smtp2.pobox.com Message-Id: <20170914020232.C6D85A2791@pb-smtp2.pobox.com> Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 14 Sep 2017 02:02:35 -0000 >> >I have run into a couple of cases where I wanted the kdc to provide -- >> >not a service ticket -- but an actual encryption key for some data at >> >rest. (Specifically an encrypted disk or a database.) >> >> It seems like a lot of people use KMIP for that. I think it would make >> sense to be able to use Kerberos to authenticate to KMIP, but in my brief > >I don't know much about KMIP, but it does seem like there is not very >much that would tie such a service to be part of and/or colocated with >a Kerberos KDC. This functionality ought to be providable by a >"generic kerberized service", i.e., something running elsewhere than the >KDC that authenticates via kerberos. Right, that was what I was suggesting. You can find the KMIP specification here: httb:/docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.html If you look at section 2.1.2, they have a BRIEF mention of Kerberos where it talks about the Credential structure. But it's not clear to me at first glance if there is a spot in the protocol for an AP-REP, much less a potentially-unlimited series of round trips that you could get via GSSAPI. I only mentioned KMIP because that is a protocol designed to generate, store, and retrieve keys for use in EXACTLY the situation originally mentioned (it is big in the data at rest world). It might be more fruitful to try to adapt KMIP to your needs rather than shoehorn the KDC into that role. --Ken From nobody Wed Sep 13 21:20:23 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 6FBCE1330AB for ; Wed, 13 Sep 2017 21:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KUZJB4X2jidC for ; Wed, 13 Sep 2017 21:20:21 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 513101320B5 for ; Wed, 13 Sep 2017 21:20:21 -0700 (PDT) X-AuditID: 1209190f-e0bff70000002b7f-a4-59ba038307ec 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 46.61.11135.3830AB95; Thu, 14 Sep 2017 00:20:19 -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 v8E4KIwY012980; Thu, 14 Sep 2017 00:20:18 -0400 Received: from [18.101.8.221] (VPN-18-101-8-221.MIT.EDU [18.101.8.221]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8E4KFxY005343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Sep 2017 00:20:17 -0400 To: Benjamin Kaduk References: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> <20170914013625.GO96685@kduck.kaduk.org> Cc: kitten@ietf.org From: Greg Hudson Message-ID: <898b0135-7c9d-078d-c213-faf90c5c0417@mit.edu> Date: Thu, 14 Sep 2017 00:20:15 -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: <20170914013625.GO96685@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrNvMvCvS4ORXC4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9XEtYwFDzkqvqydwtTA2MXexcjJISFgInFrzgq2LkYuDiGB xUwSpzf9YIFwNjJKvLzxnBHCOcok8ebGdRaQFmEBY4k9/X/A2kUElCQWn22Bar/NKDF/xyWw BLOAsMTyNWfZQGw2AWWJ9fu3gjXzClhJrLg8jxHEZhFQlZj8Yw5YXFQgQuJh5y52iBpBiZMz n4DFOQVMJfYse8IMMVNPYsf1X6wQtrzE9rdzmCcwCsxC0jILSdksJGULGJlXMcqm5Fbp5iZm 5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBAemJP8OxjkN3ocYBTgYlXh4H1jujBRiTSwrrsw9 xCjJwaQkyrtXFyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhDf8DVCONyWxsiq1KB8mJc3BoiTO K67RGCEkkJ5YkpqdmlqQWgSTleHgUJLgncC0K1JIsCg1PbUiLTOnBCHNxMEJMpwHaHgkSA1v cUFibnFmOkT+FKOilDjvE0aghABIIqM0D64XnDhSOe6+YhQHekWY9wRIOw8w6cB1vwIazAQ0 +MzpHSCDSxIRUlINjGZLKsxWv/++KvPPp9hmvqRXf8Q9cpVFxMQf2cxpTrco3ftq9eOl20+U HX6tW7Lr1/Q/UblFClpVoYGRxgcvvsm+ayc3O4on2Ks8KHXF6rm7FqwvuDjVf8Jvz57TYuJu OYrS5s2f/phOm8i/S+tby9mANzMVnYIiq678+JzvGcfx26+N03eWkhJLcUaioRZzUXEiADGg 78X3AgAA Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 14 Sep 2017 04:20:22 -0000 On 09/13/2017 09:36 PM, Benjamin Kaduk wrote: >>>> IIUC you are concerned with the case that someone will stand up a kdc >>>> which will opportunistically use SPAKE, but supports older/weaker >>>> stuff. By its nature such a beast will be vulnerable to downgrade >>>> attacks and you can't solve that in SPAKE. >>> >>> If the KDC downgrades itself to encrypted timestamp for DES/RC4 keys, >>> only a passive attack is needed, versus an active attack to downgrade >>> to encrypted timestamp. > > I must still be foggy from recovering from being sick; could you walk > me through the passive attack a bit more slowly (or which scenarios are > being compared)? The particular scenario I was concerned about here (which should not be an issue since we appear to have agreement on the text change) was: the KDC and the client both permit SPAKE and encrypted timestamp. The KDC decides not to offer SPAKE because the initial reply key is an RC4 key and therefore the transcript checksum would use HMAC-MD5. The passive attacker can simply dictionary attack the ciphertext from the client (or the KDC). From nobody Wed Sep 13 21:20:51 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 E02D51321DE for ; Wed, 13 Sep 2017 21:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 4WamCx_1SVSm for ; Wed, 13 Sep 2017 21:20:50 -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 CC13C1320B5 for ; Wed, 13 Sep 2017 21:20:49 -0700 (PDT) X-AuditID: 12074422-56bff70000001766-bf-59ba03a0e8d5 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 02.C1.05990.0A30AB95; Thu, 14 Sep 2017 00:20:48 -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 v8E4KlRs010245; Thu, 14 Sep 2017 00:20:48 -0400 Received: from [18.101.8.221] (VPN-18-101-8-221.MIT.EDU [18.101.8.221]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8E4Kj15005528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Sep 2017 00:20:46 -0400 To: Benjamin Kaduk References: <20170914014741.GP96685@kduck.kaduk.org> Cc: kitten@ietf.org From: Greg Hudson Message-ID: Date: Thu, 14 Sep 2017 00:20:44 -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: <20170914014741.GP96685@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrbuAeVekwZLNphZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtu0/8wF9xkrpr45xNTAuIqxi5GTQ0LAROL351b2LkYuDiGB xUwSVxq/M4MkhAQ2MkocPpYEkTjKJDHj+jwmkISwgKPExCkX2UFsEQElicVnW9ggGmIk5ixp BathFhCWWL7mLFicTUBZYv3+rSwgNq+AlcSrRW1gNouAqsT8iy/B5ogKREg87NzFDlEjKHFy 5hOwGk4BU4n3/e3sEDP1JHZc/8UKYctLbH87h3kCo8AsJC2zkJTNQlK2gJF5FaNsSm6Vbm5i Zk5xarJucXJiXl5qka6pXm5miV5qSukmRlBQsrso7WCc+M/rEKMAB6MSD+8Dy52RQqyJZcWV uYcYJTmYlER59+oChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwhr8ByvGmJFZWpRblw6SkOViU xHnFNRojhATSE0tSs1NTC1KLYLIyHBxKErxfGHdFCgkWpaanVqRl5pQgpJk4OEGG8wANj2QC quEtLkjMLc5Mh8ifYtTluPHw+h8mIZa8/LxUKXHeJyCDBECKMkrz4OaAk0kqx91XjOJAbwnz doOM4gEmIrhJr4CWMAEtOXN6B8iSkkSElBQwqXRukDr8/tHOqVt4A2Uf+uYeMFWQDTC/9kC9 XWIu3+L6YNPmmgfvxeU2Of0O0+p1Ke5VyP/kcW6zxdseBY/8Bpv/zgonih3n5W78snP1wpl9 k6dwn7DY2zBHW2vtrXXK11oXBO4OS+XYPtM6UbZNj6vEnP/ujVsi/V/KUtz79hhudFKviU9R YinOSDTUYi4qTgQA+bi8rgEDAAA= Archived-At: Subject: Re: [kitten] SPAKE key usage and padata type assignments 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, 14 Sep 2017 04:20:51 -0000 On 09/13/2017 09:47 PM, Benjamin Kaduk wrote: >> I think it would be reasonable to ask for a padata type registration at > > I concur. Would you like me to make the request with my chair hat? Sure, please do so. From nobody Thu Sep 14 06:04:12 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 24779133010 for ; Thu, 14 Sep 2017 06:04:11 -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 MuWdSCz-jdyj for ; Thu, 14 Sep 2017 06:04:09 -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 D835412008A for ; Thu, 14 Sep 2017 06:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=secure-endpoints.com; s=MDaemon; t=1505394221; x=1505999021; 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=93GdJp4FYL/JHRa+k0y0pA eBDBQyoi8/rqm4S0KCaEI=; b=IHkL+A58c1tofYbc+s5bXwj/3A5rencwNGu960 39ctKf0fBCWwarL4aQ7K1YQz4hu21QHzZjxH+wRwtMGdrqnFulqUzCHvpgkXc9Or bTbx4vvBJ+EvkFKfXfbBDrEyboHveNMmpGe+CJG9UthNHaQcRt95wX+u/Sq8ZNQj g6eFU= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Thu, 14 Sep 2017 09:03:41 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Thu, 14 Sep 2017 09:03:40 -0400 Received: from [IPv6:2001:470:1f07:f77:717d:782b:3f80:9600] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v17.5.0rc2) with ESMTPSA id md50001422205.msg; Thu, 14 Sep 2017 09:03:39 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:717d:782b:3f80:9600 X-MDHelo: [IPv6:2001:470:1f07:f77:717d:782b:3f80:9600] X-MDArrival-Date: Thu, 14 Sep 2017 09:03:39 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1430f7b518=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: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> <20170914011724.GN96685@kduck.kaduk.org> <20170914020232.C6D85A2791@pb-smtp2.pobox.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <78b69dc8-c7cc-47af-bbc9-ffb13909927e@secure-endpoints.com> Date: Thu, 14 Sep 2017 09:03:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170914020232.C6D85A2791@pb-smtp2.pobox.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070801020507000904070602" Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 14 Sep 2017 13:04:11 -0000 This is a cryptographically signed message in MIME format. --------------ms070801020507000904070602 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/13/2017 10:02 PM, Ken Hornstein wrote: > Right, that was what I was suggesting. You can find the KMIP specifica= tion > here: >=20 > http:/docs.oasis-open.org/kmip/spec/v1.2/kmip-spec-v1.2.html >=20 > If you look at section 2.1.2, they have a BRIEF mention of Kerberos > where it talks about the Credential structure. But it's not clear to m= e > at first glance if there is a spot in the protocol for an AP-REP, much > less a potentially-unlimited series of round trips that you could get > via GSSAPI. I only mentioned KMIP because that is a protocol designed > to generate, store, and retrieve keys for use in EXACTLY the situation > originally mentioned (it is big in the data at rest world). It might b= e > more fruitful to try to adapt KMIP to your needs rather than shoehorn > the KDC into that role. >=20 > --Ken As far as I can tell, before GSS-API or Kerberos could be used to authenticate to a KMIP service, TLS would need to be updated to support Kerberos authentication. At the moment, KMIP requires TLS 1.2. See http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.ht= ml Alternatively, a new GSS-API protected network protocol could be developed as a front-end to the KMIP store. For example, an RXGK protected RX RPC service would be interesting. Jeffrey Altman --------------ms070801020507000904070602 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDkxNDEzMDMzNlowLwYJKoZI hvcNAQkEMSIEINYBa36nD3NiswnOw3/UOJKaygGnH40hJV9H9qvlnNXlMF0GCSsGAQQBgjcQ BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1 c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAbTT5VTd26c9ewy4ytEox 2dK7qOFXQFcYlyu1xKPRUv1awT82qWasUSh2qT0SkIXSFnPBdJEeBtBDwEMENPnc/t6AdWw1 CUipyPdQSHqR35GvtZhqE9F6gg+3gYDnkq5VcLjNK5TJGJ1jd7VT9GK2i98Fz8LQwQ/cnKFX Zex/z57dNaCFQ/v6TBwUbdeSej49ugAYI1YD7+ZAc3BfkOp0fJ4+0KrP33r+A1xQJAus28tt WvnXnVuelwdq71pN++4tl4L2D1EaPpSpPXX6KV+DMFXfqCvizFlTSmvHk51eyx/cFgCobY3t jxCtkOlMfWo1pXsz+7/1tLrJFjinKiPlzgAAAAAAAA== --------------ms070801020507000904070602-- From nobody Thu Sep 14 08:25: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 D694113295C for ; Thu, 14 Sep 2017 08:25:12 -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, 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 0U-bA5Hv7NUo for ; Thu, 14 Sep 2017 08:25:12 -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 CCC1A13239C for ; Thu, 14 Sep 2017 08:25:11 -0700 (PDT) X-AuditID: 1209190e-b91ff70000006e19-bd-59ba9f56d3e9 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 62.46.28185.65F9AB95; Thu, 14 Sep 2017 11:25:10 -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 v8EFP9ia012333; Thu, 14 Sep 2017 11:25:09 -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 v8EFP5nu032255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Sep 2017 11:25:07 -0400 Date: Thu, 14 Sep 2017 10:25:05 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20170914152505.GR96685@kduck.kaduk.org> References: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> <20170914013625.GO96685@kduck.kaduk.org> <898b0135-7c9d-078d-c213-faf90c5c0417@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <898b0135-7c9d-078d-c213-faf90c5c0417@mit.edu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrRs2f1ekwaODehZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvOc3WwFL9gqVjZ8YWtgXMvaxcjJISFgInHlzzqmLkYuDiGB xUwSvw4/YIFwNjJKbH/xEypzlUmivWkFG0gLi4CqxPvZm1hAbDYBFYmG7svMILaIgKLEs1Vz weLMAsISy9ecBasXFjCW2NP/h72LkYODF2jdol8VEDP7mCRmHXvJCFLDKyAocXLmE6heLYkb /14ygdQzC0hLLP/HAWJyClhLXLpaB1IhKqAsMW/fKrYJjAKzkDTPQtI8C6F5ASPzKkbZlNwq 3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3UlNJNjOCAlOTbwTipwfsQowAHoxIPr8CEXZFCrIll xZW5hxglOZiURHn36u6MFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC6zoRqJw3JbGyKrUoHyYl zcGiJM67LQgoJZCeWJKanZpakFoEk5Xh4FCS4J06DygrWJSanlqRlplTgpBm4uAEGc4DNNwN pIa3uCAxtzgzHSJ/ilGX48bD63+YhFjy8vNSpcR5S0GKBECKMkrz4OaAEolE9v6aV4ziQG8J 83KDVPEAkxDcpFdAS5iAlpw5vQNkSUkiQkqqgXGrjGzfvbOzz9//m7l3440TO7f0Kps75PD2 GH4KTHmy+ezsTOvPhxNvWRfOXd0abyaudfBhVs18ppkSJTw8CedEBeJWbrVdb56w8a3x8pTY qBdxkff9ZnFkbbLIm1sQKqH58Kdd2u1lzTKSyWW7PnTp8Ov/eCPofkX0gnKwg/pnKdNc/gWm 65RYijMSDbWYi4oTAStwR9b/AgAA Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 14 Sep 2017 15:25:13 -0000 On Thu, Sep 14, 2017 at 12:20:15AM -0400, Greg Hudson wrote: > On 09/13/2017 09:36 PM, Benjamin Kaduk wrote: > > > > I must still be foggy from recovering from being sick; could you walk > > me through the passive attack a bit more slowly (or which scenarios are > > being compared)? > > The particular scenario I was concerned about here (which should not be > an issue since we appear to have agreement on the text change) was: the > KDC and the client both permit SPAKE and encrypted timestamp. The KDC > decides not to offer SPAKE because the initial reply key is an RC4 key > and therefore the transcript checksum would use HMAC-MD5. The passive > attacker can simply dictionary attack the ciphertext from the client (or > the KDC). Ah, the passive attack is limited to the case where the weak reply key would be used, got it. Thanks, Ben From nobody Thu Sep 14 09:15: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 E592B132D47 for ; Thu, 14 Sep 2017 09:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=kenh@pobox.com header.d=pobox.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 CEJz9Dl78A4Q for ; Thu, 14 Sep 2017 09:15:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430C1124239 for ; Thu, 14 Sep 2017 09:15:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 8A7EEABE97 for ; Thu, 14 Sep 2017 12:15:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:in-reply-to:references:mime-version:content-type:date :message-id; s=sasl; bh=HkXtUjSbK/AvtjPVlwVTkpIroT0=; b=IkkUJFvy QH2EGd5vqX42ZF8wxu+/oBa/iAohn4SJJEquceb27kd2xJoN/Yh/FOhwWv89supx CSmclBiDIZRqxU2cbKwK5dXiCoANdMCamUdKrObd2unxfmgdALy09OgGA2yryHRA bh3uKEJDoVJMtRuZzItPWr7CWfJt0V4v088= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :in-reply-to:references:mime-version:content-type:date :message-id; q=dns; s=sasl; b=e+64Jk82aS67LxueJ9qtlxl/K0dWhWMQFx NzkGL2+Djw1QVS9WFjBCOKG7hIpVyRUhVfg9e/JC/wc76MzapOeQ51i4PYY69iUf YSTdyE0QyHAgtiZI2KVN0FdoVWha+7C7TmYAOpZhObSiEI/QMF7TvoOG911KrW0m 7PTSOjoSA= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 6E4E3ABE96 for ; Thu, 14 Sep 2017 12:15:06 -0400 (EDT) Received: from zoolander.cmf.nrl.navy.mil (unknown [134.207.12.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 8FF0CABE95 for ; Thu, 14 Sep 2017 12:15:05 -0400 (EDT) From: Ken Hornstein To: kitten@ietf.org In-Reply-To: <78b69dc8-c7cc-47af-bbc9-ffb13909927e@secure-endpoints.com> References: <2FB98F5F-3981-4EFF-8CFF-FF6B5B3D485C@oxy.edu> <20170913013057.B1BEE8E632@pb-smtp2.pobox.com> <20170914011724.GN96685@kduck.kaduk.org> <20170914020232.C6D85A2791@pb-smtp2.pobox.com> <78b69dc8-c7cc-47af-bbc9-ffb13909927e@secure-endpoints.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Sep 2017 12:15:04 -0400 X-Pobox-Relay-ID: DEC7DFD0-9967-11E7-B2AD-9D2B0D78B957-90216062!pb-smtp2.pobox.com Message-Id: <20170914161506.6E4E3ABE96@pb-smtp2.pobox.com> Archived-At: Subject: Re: [kitten] Any Interest in a Key Delivery Service? 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, 14 Sep 2017 16:15:09 -0000 >As far as I can tell, before GSS-API or Kerberos could be used to >authenticate to a KMIP service, TLS would need to be updated to support >Kerberos authentication. At the moment, KMIP requires TLS 1.2. See > > >http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html My reading of the spec is that you would have to create a new profile (my dumb reading is that TLS is required for the "basic" authentication suite, and you'd define your own authentication suite). That's that part that I suspect would be a giant, awful slog through the OASIS standardization process, which would probably one of those fruitless, soul-draining exercises. It might NOT be, but I'm pretty sure it would be an uphill battle. --Ken From nobody Thu Sep 14 17:23:25 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 5C8D6126B7E; Thu, 14 Sep 2017 17:23:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kitten@ietf.org, kitten-chairs@ietf.org, ekr@rtfm.com, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150543500333.2831.10468308167317237805.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 17:23:23 -0700 Archived-At: Subject: [kitten] kitten - Not having a session at IETF 100 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: Fri, 15 Sep 2017 00:23:23 -0000 Benjamin Kaduk, a chair of the kitten working group, indicated that the kitten working group does not plan to hold a session at IETF 100. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Sep 14 17:25:12 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 1BE1E132331 for ; Thu, 14 Sep 2017 17:25:11 -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, 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 I01FlyczLvYw for ; Thu, 14 Sep 2017 17:25:09 -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 ECEAD126B7E for ; Thu, 14 Sep 2017 17:25:08 -0700 (PDT) X-AuditID: 12074425-767ff70000004315-1a-59bb1de36c5c 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id AE.C9.17173.3ED1BB95; Thu, 14 Sep 2017 20:25:07 -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 v8F0P7PW026106 for ; Thu, 14 Sep 2017 20:25:07 -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 v8F0P4gU019265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Sep 2017 20:25:06 -0400 Date: Thu, 14 Sep 2017 19:25:04 -0500 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170915002504.GV96685@kduck.kaduk.org> References: <150543500333.2831.10468308167317237805.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150543500333.2831.10468308167317237805.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6novtYdnekwd/1VhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvP+XpaCFSwVj5d8Ym9gXM/cxcjJISFgInHp3B/WLkYuDiGB xUwSNz/PZgRJCAkcZ5TYuzkLIvGaSeLQg0WsIAkWAVWJvTOusIDYbAIqEg3dl8EmiQgIS+ze +g7MFhYwkzi0+SGYzQu04dfv50xdjBxAg3wlnn8yhAgLSpyc+QRsDLOAlsSNfy/BSpgFpCWW /+MACXMK+Ek0H+sA2yoqoCwxb98qtgmM/LOQdM9C0j0LoXsBI/MqRtmU3Crd3MTMnOLUZN3i 5MS8vNQiXQu93MwSvdSU0k2M4LBzUd3BOOev1yFGAQ5GJR7eHb27IoVYE8uKK3MPMUpyMCmJ 8u7V3RkpxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ3R2B3pBBvSmJlVWpRPkxKmoNFSZx3WxDQ JIH0xJLU7NTUgtQimKwMB4eSBO8NGaBGwaLU9NSKtMycEoQ0EwcnyHAeoOFHQWp4iwsSc4sz 0yHypxh1OW48vP6HSYglLz8vVUqcVxmkSACkKKM0D24OKF1IZO+vecUoDvSWMO87kCoeYKqB m/QKaAkT0JIzp3eALClJREhJNTDGzTa9a3cg+6zswz03Li9fzLzCylLyYvvbUwc2PL15w7Cy duIDhxDlpjfLrx2vv7r1vmOzw+KujWuWJiv570/dtuxCSdMh7v+LLpvPUuu+u91aVst7+92H c+w6Hi9y07E+8ZTjjpzGuc9bEx8aCul7vb3DVZuhmjRB63jm+8NPk0xb5Q7LO7p9VGIpzkg0 1GIuKk4EAM/3baLyAgAA Archived-At: Subject: Re: [kitten] kitten - Not having a session at IETF 100 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, 15 Sep 2017 00:25:11 -0000 On Thu, Sep 14, 2017 at 05:23:23PM -0700, IETF Meeting Session Request Tool wrote: > > > Benjamin Kaduk, a chair of the kitten working group, indicated that the kitten working group does not plan to hold a session at IETF 100. > > This message was generated and sent by the IETF Meeting Session Request Tool. Please let the chairs know if you plan to attend IETF 100 and have topic(s) you would like to discuss with kitten. As noted above, we currently do not have any such topics and do not plan to request a session. Thanks, Ben From nobody Thu Sep 14 21:38:41 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 2E3BB132EDC for ; Thu, 14 Sep 2017 21:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 fxVA-BVZMqXG for ; Thu, 14 Sep 2017 21:38:37 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539F5132ED3 for ; Thu, 14 Sep 2017 21:38:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 411142B0F4; Fri, 15 Sep 2017 04:38:36 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQaaGrQVgdYp; Fri, 15 Sep 2017 04:38:36 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 5E0A62B0F0; Fri, 15 Sep 2017 04:38:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <898b0135-7c9d-078d-c213-faf90c5c0417@mit.edu> Date: Thu, 14 Sep 2017 21:38:28 -0700 Cc: Benjamin Kaduk , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3D9FE776-CE1C-4C82-951A-98E5D8A57511@oxy.edu> References: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> <20170914013625.GO96685@kduck.kaduk.org> <898b0135-7c9d-078d-c213-faf90c5c0417@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 15 Sep 2017 04:38:39 -0000 > On Sep 13, 2017, at 9:20 PM, Greg Hudson wrote: >=20 > On 09/13/2017 09:36 PM, Benjamin Kaduk wrote: >>>>> IIUC you are concerned with the case that someone will stand up a = kdc >>>>> which will opportunistically use SPAKE, but supports older/weaker >>>>> stuff. By its nature such a beast will be vulnerable to downgrade >>>>> attacks and you can't solve that in SPAKE. >>>>=20 >>>> If the KDC downgrades itself to encrypted timestamp for DES/RC4 = keys, >>>> only a passive attack is needed, versus an active attack to = downgrade >>>> to encrypted timestamp. >>=20 >> I must still be foggy from recovering from being sick; could you walk >> me through the passive attack a bit more slowly (or which scenarios = are >> being compared)? >=20 > The particular scenario I was concerned about here (which should not = be > an issue since we appear to have agreement on the text change) was: = the > KDC and the client both permit SPAKE and encrypted timestamp. The KDC > decides not to offer SPAKE because the initial reply key is an RC4 key > and therefore the transcript checksum would use HMAC-MD5. The passive > attacker can simply dictionary attack the ciphertext from the client = (or > the KDC). Wouldn=E2=80=99t the KDC have already sent a preuth-required message = which prohibited that enctype? I thought the list of enctypes was = separate from the list of PA types. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten Personal email. hbhotz@oxy.edu From nobody Thu Sep 14 21:39:57 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 42972132ED3 for ; Thu, 14 Sep 2017 21:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 qCuQgWnOHnGI for ; Thu, 14 Sep 2017 21:39:55 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F851321D5 for ; Thu, 14 Sep 2017 21:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 4DAFBCA603; Fri, 15 Sep 2017 04:39:54 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo01-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3PdSIU01OtD; Fri, 15 Sep 2017 04:39:54 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id C2F81CA5D6; Fri, 15 Sep 2017 04:39:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20170911152526.GD96685@kduck.kaduk.org> Date: Thu, 14 Sep 2017 21:39:48 -0700 Cc: Greg Hudson , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6576FCF6-6262-4C16-B251-834ACB5D306B@oxy.edu> References: <20170911152526.GD96685@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE edwards25519 group 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, 15 Sep 2017 04:39:56 -0000 > On Sep 11, 2017, at 8:25 AM, Benjamin Kaduk wrote: >=20 > It would be good to hear some additional feedback before pushing an > updated version of the document. Does anyone want to speak for > or against adding the edwards25519 curve and making it MTI? I remember thinking we would be adding 25519 real soon when I reviewed = it. Sure go ahead. Personal email. hbhotz@oxy.edu From nobody Fri Sep 15 13:16:01 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 A7BE31341F8; Fri, 15 Sep 2017 13:15:53 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150550655363.4903.14608112142112731562@ietfa.amsl.com> Date: Fri, 15 Sep 2017 13:15:53 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-01.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: Fri, 15 Sep 2017 20:15:54 -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 WG of the IETF. Title : SPAKE Pre-Authentication Authors : Nathaniel McCallum Simo Sorce Robbie Harwood Greg Hudson Filename : draft-ietf-kitten-krb-spake-preauth-01.txt Pages : 30 Date : 2017-09-15 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 second factor authentication without relying on FAST. This is achieved 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-spake-preauth-01 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 Fri Sep 15 17:08: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 C86741321A7 for ; Fri, 15 Sep 2017 17:08:58 -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, 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 twhEGtzTkZJn for ; Fri, 15 Sep 2017 17:08:57 -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 827951200F3 for ; Fri, 15 Sep 2017 17:08:57 -0700 (PDT) X-AuditID: 12074423-b13ff70000000510-dd-59bc6b981eca 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 8C.15.01296.89B6CB95; Fri, 15 Sep 2017 20:08:56 -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 v8G08sHM028155; Fri, 15 Sep 2017 20:08:55 -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 v8G08oA3017893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Sep 2017 20:08:53 -0400 Date: Fri, 15 Sep 2017 19:08:51 -0500 From: Benjamin Kaduk To: "Henry B (Hank) Hotz, CISSP" Cc: Greg Hudson , kitten@ietf.org Message-ID: <20170916000850.GZ96685@kduck.kaduk.org> References: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu> <20170914013625.GO96685@kduck.kaduk.org> <898b0135-7c9d-078d-c213-faf90c5c0417@mit.edu> <3D9FE776-CE1C-4C82-951A-98E5D8A57511@oxy.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3D9FE776-CE1C-4C82-951A-98E5D8A57511@oxy.edu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1p2RvSfSoGs7t8XHewtZLI5uXsXi wOSxZMlPJo+tTX+ZA5iiuGxSUnMyy1KL9O0SuDIu9r5kKVjOUzF32U+mBsZnnF2MHBwSAiYS s+ZLdTFycQgJLGaS6H9/kq2LkRPI2cgo0bWcDyJxlUnizeQzjCAJFgFVibaODcwgNpuAikRD 92UwW0TAUGL6yomsIDazgJHE1rajYIOEBYwl9vT/YQexeYGWHZzZxwoxdD+TxN4br6ESghIn Zz5hgWhWl/gz7xIzyHXMAtISy/9xQITlJZq3zgbbxSlgLbF+5XSwVlEBZYl5+1axTWAUnIVk 0iwkk2YhTJqFZNICRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYQUHN7qK8 g/Fln/chRgEORiUe3obLuyOFWBPLiitzDzFKcjApifJa+e2JFOJLyk+pzEgszogvKs1JLT7E KMHBrCTC25oMlONNSaysSi3Kh0lJc7AoifNuC9oVKSSQnliSmp2aWpBaBJOV4eBQkuA1zgJq FCxKTU+tSMvMKUFIM3FwggznARp+EKSGt7ggMbc4Mx0if4pRUUqcd18mUEIAJJFRmgfXC0o6 Etn7a14xigO9Isx7GqSdB5iw4LpfAQ1mAhp85vQOkMEliQgpqQZGgfZy+Y3nVlxujX/2QlHp 7d43L07PCz9emht+N/XfjZiN4u9OfZhfMqMwZCtX0EOGTXsf1K/1d2VZvuBCrF9PqdcOvf+J 5y4sOXe6+KNKgcX9jKdPrp1xUIg6utnG6fbhli9uCbUqD+JFJaXtthTz6aqWTqq+feKuR/xW +0cKW+7pOv2/LvElUImlOCPRUIu5qDgRAO+O/2IVAwAA Archived-At: Subject: Re: [kitten] SPAKE and weak checksum types 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, 16 Sep 2017 00:08:59 -0000 On Thu, Sep 14, 2017 at 09:38:28PM -0700, Henry B (Hank) Hotz, CISSP wrote: > > > On Sep 13, 2017, at 9:20 PM, Greg Hudson wrote: > > > > The particular scenario I was concerned about here (which should not be > > an issue since we appear to have agreement on the text change) was: the > > KDC and the client both permit SPAKE and encrypted timestamp. The KDC > > decides not to offer SPAKE because the initial reply key is an RC4 key > > and therefore the transcript checksum would use HMAC-MD5. The passive > > attacker can simply dictionary attack the ciphertext from the client (or > > the KDC). > > Wouldn’t the KDC have already sent a preuth-required message which prohibited that enctype? I thought the list of enctypes was separate from the list of PA types. The spake draft requires that, if SPAKE is to be used/offered, a single enctype must be in pa-etype-info2. So the key decision here is at the KDC, a combination of whether to offer SPAKE at all and what enctype(s) to use. But in this scenario, the KDC does not wholesale forbid HMAC-MD5, it was just going to comply with the (old) draft text to forbid SPAKE with MD5. So, if the RC4 key was the initial choice for reply key, that "compliant" KDC could not offer SPAKE and would have to only offer encrypted-timestamp. The client would then actually send the encrypted timestamp, offering the ciphertext in question. On the other hand, if RC4 was not the initial choice for the reply key, then the KDC would offer SPAKE with that other enctype. -Ben From nobody Sat Sep 16 22:24:57 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 39AD5132198 for ; Sat, 16 Sep 2017 22:24:56 -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, 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 6yD64dKI8sI3 for ; Sat, 16 Sep 2017 22:24:55 -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 D52E21243F6 for ; Sat, 16 Sep 2017 22:24:54 -0700 (PDT) X-AuditID: 12074423-8ddff700000028c4-98-59be0725aa27 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id F8.64.10436.5270EB95; Sun, 17 Sep 2017 01:24:53 -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 v8H5Orev007842 for ; Sun, 17 Sep 2017 01:24:53 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [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 v8H5OprY018034 for ; Sun, 17 Sep 2017 01:24:52 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sun, 17 Sep 2017 01:24:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUixG6nrqvKvi/S4OQBbYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY2vrbfaC6YIVu88dY29gbOTrYuTgkBAwkdi+LqmLkYtDSGAx k8ScfSfZIJzjjBLTdhxihXA6mCQu/OgBynBysAkoS6zfv5UFxBYREJbYvfUdM4gtLGAu8eT/ HUaQqSwCqhKHLqaChHkFDCUWvv/MBGELSpyc+QSslVlAQuLgixfMExi5ZyFJzUKSWsDItIpR NiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4BFyUdzC+7PM+xCjAwajEw7uhZG+k EGtiWXFl7iFGSQ4mJVFeK789kUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeOvY9kUK8aYkVlal FuXDpKQ5WJTEebcF7YoUEkhPLEnNTk0tSC2CycpwcChJ8PKCNAoWpaanVqRl5pQgpJk4OEGG 8wANlwUbXlyQmFucmQ6RP8UoKSXO+4kVKCEAksgozYPrfcUoDvSCMK8wSBsPMJ7hul4BDWQC GtiyYw/IwJJEhJRUA2Ni770bVcs2um7IuqtzLe+tuuDemKDCTakHfpsfDV7NOy1144MDzHos tSZFq+KW7rn3I6l/d+TXuH7OYs+znX6CT37ODDP9xlSVaC0lbtknlJgkyLn6zdzj3P9jDOZP nGG6tvzas171i9ZsOtM4tb7zh+iwfn93U5SBK2BSyKT10w5n5NofWqHEUpyRaKjFXFScCAAv EpuApAIAAA== Archived-At: Subject: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 17 Sep 2017 05:24:56 -0000 RFC 3961 says about the checksum profile get_mic operation: "This function is not required to return the same deterministic result for each use; it need only generate a token that the verify_mic routine can check." In practice, only the oldest checksum types (used with single-DES keys) are non-deterministic. The SPAKE preauth transcript checksum is computed independently by the client and KDC using the RFC 3961 checksum operation (iterated several times). In hindsight, this design obviously requires a deterministic checksum operation, so the pieces don't currently fit. I unfortunately only realized this mismatch today when I started doing integration tests using DES keys in a prototype implementation. The potential remedies I can think of fall into these bins: 1. Don't change the SPAKE design. Instead, update RFC 3961 to specify that new checksum types must be deterministic, and specify that SPAKE preauth can't be used with single-DES keys. Aside from the standards-space cost of pushing our problem down into a lower layer, the prohibition against using SPAKE with single-DES keys could make it harder for clients to be configured to refuse encrypted timestamp preauth on a pre-realm basis. That is perhaps not a large cost as Kerberos implementations are moving away from single-DES support anyway. 2. A relatively quick fix: use PRF instead of checksum. (Or PRF+, in which case we have to decide how much length of output we want.) I think PRF has the requisite properties, but I would want to think on it more. 3. We could use a hash (it doesn't need to be keyed) independent of RFC 3961. The hash algorithm could be specified in the group profile, perhaps, but I believe the rejected-optimistic-challenge case poses a difficulty for that design. 4. The most open-ended option is to back up and reconsider the purpose of the transcript checksum, which is to bind at least the public keys into key derivation. The current transcript also binds in group negotiation and the initial factor challenge. I can't immediately think of an alternative design which doesn't require the KDC to store a lot of information in the cookie. From nobody Mon Sep 18 18:59:47 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 543B5132FA7 for ; Mon, 18 Sep 2017 18:59:45 -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, 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 RN-MD7E6U3e8 for ; Mon, 18 Sep 2017 18:59:44 -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 CE2A113243A for ; Mon, 18 Sep 2017 18:59:43 -0700 (PDT) X-AuditID: 12074422-077ff70000001d12-5e-59c07a0ea581 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4D.C3.07442.E0A70C95; Mon, 18 Sep 2017 21:59:42 -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 v8J1xfTE015236; Mon, 18 Sep 2017 21:59:42 -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 v8J1xcIq026957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Sep 2017 21:59:40 -0400 Date: Mon, 18 Sep 2017 20:59:38 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20170919015937.GN96685@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.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrctXdSDS4M40I4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr41D/dpaCf+IVx24vZ29gXCHcxcjJISFgIrHuzh/GLkYuDiGB xUwS8749ZIJwNjJKvGr4wAzhXGWSODinkxmkhUVAVeLBwtuMIDabgIpEQ/dlsLiIgKLEs1Vz WUBsZgFhieVrzrKB2MICLhJnPyxlArF5gdbNabrICmILCRhKXJi9jxUiLihxcuYTqF4tiRv/ XgLVcwDZ0hLL/3GAhDkFjCQu9v0AWysqoCwxb98qtgmMArOQdM9C0j0LoXsBI/MqRtmU3Crd 3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoJBkd1HawTjxn9chRgEORiUeXoFr+yOFWBPL iitzDzFKcjApifKurTgQKcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE1z4GKMebklhZlVqUD5OS 5mBREufdFrQrUkggPbEkNTs1tSC1CCYrw8GhJMH7F2SoYFFqempFWmZOCUKaiYMTZDgP0PAq kBre4oLE3OLMdIj8KUZFKXFe40qghABIIqM0D64XlDIksvfXvGIUB3pFmFcCpIoHmG7gul8B DWYCGtyyYw/I4JJEhJRUA2Oej3SsiEW1598jOoJ2fycGKv+YUeVhw2d0UfAej0GWwDtH2XXT r1qKvp+dwnjg8HzpWY+en2NzbJsZJ/pl4vHw+GcnCyKbYj9I9Egft2DkL1dZc/pnR37UZwd2 H6u7rtefOZjE+l/c43zV5t+fg2n1+w4WBE8M6HmyanWqzyrJz+anXMJzfiixFGckGmoxFxUn AgAoRiAl9AIAAA== Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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: Tue, 19 Sep 2017 01:59:45 -0000 On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote: > RFC 3961 says about the checksum profile get_mic operation: "This > function is not required to return the same deterministic result for > each use; it need only generate a token that the verify_mic routine can > check." In practice, only the oldest checksum types (used with > single-DES keys) are non-deterministic. > > The SPAKE preauth transcript checksum is computed independently by the > client and KDC using the RFC 3961 checksum operation (iterated several > times). In hindsight, this design obviously requires a deterministic > checksum operation, so the pieces don't currently fit. I unfortunately > only realized this mismatch today when I started doing integration tests > using DES keys in a prototype implementation. > > The potential remedies I can think of fall into these bins: > > 1. Don't change the SPAKE design. Instead, update RFC 3961 to specify > that new checksum types must be deterministic, and specify that SPAKE > preauth can't be used with single-DES keys. Aside from the > standards-space cost of pushing our problem down into a lower layer, the > prohibition against using SPAKE with single-DES keys could make it > harder for clients to be configured to refuse encrypted timestamp > preauth on a pre-realm basis. That is perhaps not a large cost as > Kerberos implementations are moving away from single-DES support anyway. > > 2. A relatively quick fix: use PRF instead of checksum. (Or PRF+, in > which case we have to decide how much length of output we want.) I > think PRF has the requisite properties, but I would want to think on it > more. This is probably the most appealing option, provided we can accurately state which properties we need (and they are provided by PRF(+)). > 3. We could use a hash (it doesn't need to be keyed) independent of RFC > 3961. The hash algorithm could be specified in the group profile, > perhaps, but I believe the rejected-optimistic-challenge case poses a > difficulty for that design. The hash algorithm could also be negotiated independently (so that in practice, e.g., sha256 is always used, at least in the initial deployments). For the rejected-optimistic case there is still an issue, but if the KDC only supports O(2) hash algorithms during a hash transition, then the amount of state needed in the cookie is bounded by a number that might be smaller than the number of supported groups (but then again, might not). > 4. The most open-ended option is to back up and reconsider the purpose > of the transcript checksum, which is to bind at least the public keys > into key derivation. The current transcript also binds in group > negotiation and the initial factor challenge. I can't immediately think > of an alternative design which doesn't require the KDC to store a lot of > information in the cookie. I agree that we are likely to end up with something resembling a "transcript hash", even if it does not directly use a hash primitve. -Ben From nobody Tue Sep 19 06:23: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 8CFA4134302 for ; Tue, 19 Sep 2017 06:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 XHnz7806pIqz for ; Tue, 19 Sep 2017 06:23:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 91569134301 for ; Tue, 19 Sep 2017 06:23:17 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8JDNGDX024397 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Sep 2017 13:23:17 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8JDNGqc006532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Sep 2017 13:23:16 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v8JDNFAY014365 for ; Tue, 19 Sep 2017 13:23:16 GMT Received: from [192.168.1.101] (/111.196.138.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Sep 2017 06:23:15 -0700 From: Weijun Wang Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 19 Sep 2017 21:23:08 +0800 Message-Id: To: kitten X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [kitten] MIT krb5 1.15 interop with Windows 2003 R2 SP2 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: Tue, 19 Sep 2017 13:23:23 -0000 Hi All I am trying out MIT krb5 1.15 and using its kinit to login to a Windows = 2003 R2 SP2 AD domain. The command fails with kinit: KDC has no support for encryption type while getting initial = credentials After some more experiments, it seems that whenever I put the = aes256-sha2 etype before rc4-hmac in default_tkt_enctypes, the same = error happens. It is interesting that aes128-sha2 has no such effect. = The latest Heimdal kinit shows the same interop issue. Precisely, the server does not complain with its 1st PREAUTH_REQUIRED = response, and in my 2nd AS-REQ, if I provide a wrong password, the error = is a normal PASSWORD_INCORRECT. Only if I provide the correct password = it returns this error. Seems like it decides to choose etype of 20 but = only realize it's not supported after some time. Is this a known issue? I tried Windows 2008 and Windows 2000 and have = not seen the same error. Thanks Max From nobody Wed Sep 20 08:09:51 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 38B4C134217 for ; Wed, 20 Sep 2017 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 hJ0fV3ZNd_Wo for ; Wed, 20 Sep 2017 08:09:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852A813318C for ; Wed, 20 Sep 2017 08:09:46 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0B7BF2C9746; Wed, 20 Sep 2017 15:09:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0B7BF2C9746 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=simo@redhat.com Received: from ovpn-116-78.phx2.redhat.com (ovpn-116-78.phx2.redhat.com [10.3.116.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9C6AF5C8B7; Wed, 20 Sep 2017 15:09:30 +0000 (UTC) Message-ID: <1505920169.1143.15.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk , Greg Hudson Cc: kitten@ietf.org Date: Wed, 20 Sep 2017 11:09:29 -0400 In-Reply-To: <20170919015937.GN96685@kduck.kaduk.org> References: <20170919015937.GN96685@kduck.kaduk.org> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 20 Sep 2017 15:09:31 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 20 Sep 2017 15:09:49 -0000 On Mon, 2017-09-18 at 20:59 -0500, Benjamin Kaduk wrote: > On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote: > > RFC 3961 says about the checksum profile get_mic operation: "This > > function is not required to return the same deterministic result > > for > > each use; it need only generate a token that the verify_mic routine > > can > > check."  In practice, only the oldest checksum types (used with > > single-DES keys) are non-deterministic. > > > > The SPAKE preauth transcript checksum is computed independently by > > the > > client and KDC using the RFC 3961 checksum operation (iterated > > several > > times).  In hindsight, this design obviously requires a > > deterministic > > checksum operation, so the pieces don't currently fit.  I > > unfortunately > > only realized this mismatch today when I started doing integration > > tests > > using DES keys in a prototype implementation. > > > > The potential remedies I can think of fall into these bins: > > > > 1. Don't change the SPAKE design.  Instead, update RFC 3961 to > > specify > > that new checksum types must be deterministic, and specify that > > SPAKE > > preauth can't be used with single-DES keys.  Aside from the > > standards-space cost of pushing our problem down into a lower > > layer, the > > prohibition against using SPAKE with single-DES keys could make it > > harder for clients to be configured to refuse encrypted timestamp > > preauth on a pre-realm basis.  That is perhaps not a large cost as > > Kerberos implementations are moving away from single-DES support > > anyway. > > > > 2. A relatively quick fix: use PRF instead of checksum.  (Or PRF+, > > in > > which case we have to decide how much length of output we want.)  I > > think PRF has the requisite properties, but I would want to think > > on it > > more. > > This is probably the most appealing option, provided we can > accurately > state which properties we need (and they are provided by PRF(+)). Why is this more appealing than just saying no to DES ? Do we have any concern we may get future enc types that have non- deterministic checksums ? > > 3. We could use a hash (it doesn't need to be keyed) independent of > > RFC > > 3961.  The hash algorithm could be specified in the group profile, > > perhaps, but I believe the rejected-optimistic-challenge case poses > > a > > difficulty for that design. > > The hash algorithm could also be negotiated independently (so that in > practice, e.g., sha256 is always used, at least in the initial > deployments). > For the rejected-optimistic case there is still an issue, but if the > KDC > only supports O(2) hash algorithms during a hash transition, then the > amount of state needed in the cookie is bounded by a number that > might > be smaller than the number of supported groups (but then again, might > not). The nice thing about using the enctypes is that as new ones will come out with new, stronger checksums, we'll get those automatically, without adding a new thing to negotiate ... > > 4. The most open-ended option is to back up and reconsider the > > purpose > > of the transcript checksum, which is to bind at least the public > > keys > > into key derivation.  The current transcript also binds in group > > negotiation and the initial factor challenge.  I can't immediately > > think > > of an alternative design which doesn't require the KDC to store a > > lot of > > information in the cookie. > > I agree that we are likely to end up with something resembling a > "transcript hash", even if it does not directly use a hash primitve. I have to say that between PRF and a separate Hash I would rather use a separate hash. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Wed Sep 20 19:59:16 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 32737132193 for ; Wed, 20 Sep 2017 19:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 tRWRVKym_QCm for ; Wed, 20 Sep 2017 19:59:13 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357FD124B18 for ; Wed, 20 Sep 2017 19:59:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 49BE7210A3; Thu, 21 Sep 2017 02:59:12 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1COPDrKKDuth; Thu, 21 Sep 2017 02:59:12 +0000 (UTC) Received: from [10.178.253.119] (unknown [204.89.11.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 6E1A3210A2; Thu, 21 Sep 2017 02:59:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Wed, 20 Sep 2017 18:14:31 -0700 Cc: kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg Hudson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 21 Sep 2017 02:59:15 -0000 Seems like a lesser of evils question. I don=E2=80=99t like backing up = at this late stage, so I favor 1,2 over 3,4. No strong preference = between 1 and 2, just don=E2=80=99t want to let single-DES drive the = future. If we=E2=80=99re sure we=E2=80=99ll never want non-deterministic = checksums, then go with 1. > On Sep 16, 2017, at 10:24 PM, Greg Hudson wrote: >=20 > RFC 3961 says about the checksum profile get_mic operation: "This > function is not required to return the same deterministic result for > each use; it need only generate a token that the verify_mic routine = can > check." In practice, only the oldest checksum types (used with > single-DES keys) are non-deterministic. >=20 > The SPAKE preauth transcript checksum is computed independently by the > client and KDC using the RFC 3961 checksum operation (iterated several > times). In hindsight, this design obviously requires a deterministic > checksum operation, so the pieces don't currently fit. I = unfortunately > only realized this mismatch today when I started doing integration = tests > using DES keys in a prototype implementation. >=20 > The potential remedies I can think of fall into these bins: >=20 > 1. Don't change the SPAKE design. Instead, update RFC 3961 to specify > that new checksum types must be deterministic, and specify that SPAKE > preauth can't be used with single-DES keys. Aside from the > standards-space cost of pushing our problem down into a lower layer, = the > prohibition against using SPAKE with single-DES keys could make it > harder for clients to be configured to refuse encrypted timestamp > preauth on a pre-realm basis. That is perhaps not a large cost as > Kerberos implementations are moving away from single-DES support = anyway. >=20 > 2. A relatively quick fix: use PRF instead of checksum. (Or PRF+, in > which case we have to decide how much length of output we want.) I > think PRF has the requisite properties, but I would want to think on = it > more. >=20 > 3. We could use a hash (it doesn't need to be keyed) independent of = RFC > 3961. The hash algorithm could be specified in the group profile, > perhaps, but I believe the rejected-optimistic-challenge case poses a > difficulty for that design. >=20 > 4. The most open-ended option is to back up and reconsider the purpose > of the transcript checksum, which is to bind at least the public keys > into key derivation. The current transcript also binds in group > negotiation and the initial factor challenge. I can't immediately = think > of an alternative design which doesn't require the KDC to store a lot = of > information in the cookie. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten Personal email. hbhotz@oxy.edu From nobody Sat Sep 23 12:05:36 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 310E313295C for ; Sat, 23 Sep 2017 12:05:35 -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, 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 P6mfr00C2CKC for ; Sat, 23 Sep 2017 12:05:33 -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 9AF2613214D for ; Sat, 23 Sep 2017 12:05:33 -0700 (PDT) X-AuditID: 1209190c-343ff70000006f84-90-59c6b07c9bba 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 92.41.28548.C70B6C95; Sat, 23 Sep 2017 15:05:32 -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 v8NJ5Vhd019979; Sat, 23 Sep 2017 15:05:31 -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 v8NJ5Rce028828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Sep 2017 15:05:30 -0400 Date: Sat, 23 Sep 2017 14:05:27 -0500 From: Benjamin Kaduk To: Simo Sorce Cc: Greg Hudson , kitten@ietf.org Message-ID: <20170923190527.GU96685@kduck.kaduk.org> References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1505920169.1143.15.camel@redhat.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixG6noluz4VikQU+bvMXRzatYLH7MXcTq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGX0TJnHWDBTpeLj/XVMDYzLZboYOTkkBEwk Xmy7ztzFyMUhJLCYSeLXnw5GCGcjo8SJXb1QmatMEq8X3WQCaWERUJVYN2MZI4jNJqAi0dB9 mRnEFhFQkFjQf4cFxGYWMJLY2naUDcQWFnCROPthKVgvL9C6h/O3sYLYQgItjBKf/qtAxAUl Ts58AtWrI7Fz6x2gXg4gW1pi+T8OiLC8RPPW2WCrOIHGT9t8BewEUQFliXn7VrFNYBSchWTS LCSTZiFMmoVk0gJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBYc0pybOD 8cwbr0OMAhyMSjy8ExyPRgqxJpYVV+YeYpTkYFIS5V235likEF9SfkplRmJxRnxRaU5q8SFG CQ5mJRHefw1AOd6UxMqq1KJ8mJQ0B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCV6v9UCN gkWp6akVaZk5JQhpJg5OkOE8QMO7QGp4iwsSc4sz0yHypxiNOTbdvPuHiWPD9wd/mIRY8vLz UqXEeblASgVASjNK8+CmgVKTRPb+mleM4kDPCfOuBKniAaY1uHmvgFYxAa0qX30EZFVJIkJK qoHR8/fXQx5bNOfM1GG4dOf/LM0paT+feZgu/pp7Zq+BYOtpqf3505If3fhZHD15ttul4GWH Zy7R3H5NNVDxyMfH4o73bFJ6blneOSR931bTkHHHmwV1pW/EL192+Pl+v8HxPAnnPx6rjqem HrhqnFzE8vvwU1+LKaev8V9vV7l4+5K4qVZhJffJUiWW4oxEQy3mouJEAO257m8oAwAA Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 23 Sep 2017 19:05:35 -0000 On Wed, Sep 20, 2017 at 11:09:29AM -0400, Simo Sorce wrote: > On Mon, 2017-09-18 at 20:59 -0500, Benjamin Kaduk wrote: > > On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote: > > > > > > The potential remedies I can think of fall into these bins: > > > > > > 1. Don't change the SPAKE design.Instead, update RFC 3961 to > > > specify > > > that new checksum types must be deterministic, and specify that > > > SPAKE > > > preauth can't be used with single-DES keys.Aside from the > > > standards-space cost of pushing our problem down into a lower > > > layer, the > > > prohibition against using SPAKE with single-DES keys could make it > > > harder for clients to be configured to refuse encrypted timestamp > > > preauth on a pre-realm basis.That is perhaps not a large cost as > > > Kerberos implementations are moving away from single-DES support > > > anyway. > > > > > > 2. A relatively quick fix: use PRF instead of checksum.(Or PRF+, > > > in > > > which case we have to decide how much length of output we want.)I > > > think PRF has the requisite properties, but I would want to think > > > on it > > > more. > > > > This is probably the most appealing option, provided we can > > accurately > > state which properties we need (and they are provided by PRF(+)). > > Why is this more appealing than just saying no to DES ? > Do we have any concern we may get future enc types that have non- > deterministic checksums ? There's two aspects that push me this way: first, from a standards process point of view, now we have to also Update a core protocol spec and hope that people remember to check our new document whenver they try to make a new enctype/checksum type. While it's unlikely that a hyptoehtical future document would actually get through the full process with such an error, it does add to the burden on future work in this space. The second concern relates to implementations, in that there will need to be some sort of logic to handle the interaction of single-DES and SPAKE preauth. If we were in a place where implementations were actively removing the code for single-DES support, I would not see this as an issue, but my understanding is that we're still several years (at least!) away from completely removing the code (as opposed to just not using it by default). Even though we know that no one ought to be using the two things together, our code still has to come up with something to do in that case, and if we get the logic wrong things could break badly. > > > 3. We could use a hash (it doesn't need to be keyed) independent of > > > RFC > > > 3961.The hash algorithm could be specified in the group profile, > > > perhaps, but I believe the rejected-optimistic-challenge case poses > > > a > > > difficulty for that design. > > > > The hash algorithm could also be negotiated independently (so that in > > practice, e.g., sha256 is always used, at least in the initial > > deployments). > > For the rejected-optimistic case there is still an issue, but if the > > KDC > > only supports O(2) hash algorithms during a hash transition, then the > > amount of state needed in the cookie is bounded by a number that > > might > > be smaller than the number of supported groups (but then again, might > > not). > > The nice thing about using the enctypes is that as new ones will come > out with new, stronger checksums, we'll get those automatically, > without adding a new thing to negotiate ... That is a good point, about the required checksum being matched in perceived strength, and that holding as an invariant in the future. > > > 4. The most open-ended option is to back up and reconsider the > > > purpose > > > of the transcript checksum, which is to bind at least the public > > > keys > > > into key derivation.The current transcript also binds in group > > > negotiation and the initial factor challenge.I can't immediately > > > think > > > of an alternative design which doesn't require the KDC to store a > > > lot of > > > information in the cookie. > > > > I agree that we are likely to end up with something resembling a > > "transcript hash", even if it does not directly use a hash primitve. > > I have to say that between PRF and a separate Hash I would rather use a > separate hash. Hmm, so no we have a split on 2 vs. 3, unless we can somehow make 1 more appetizing. Do we have the collective will to make single-DES actually go away entirely and force any continued users to either run custom solutions or stay on old software? -Ben From nobody Mon Sep 25 10:03:16 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 63BCB1344F0 for ; Mon, 25 Sep 2017 10:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 jEuyvwFamQwj for ; Mon, 25 Sep 2017 10:03:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4A91344E6 for ; Mon, 25 Sep 2017 10:03:13 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0E90C5D689; Mon, 25 Sep 2017 17:03:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0E90C5D689 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=simo@redhat.com Received: from ovpn-117-8.phx2.redhat.com (ovpn-117-8.phx2.redhat.com [10.3.117.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B020778212; Mon, 25 Sep 2017 17:03:12 +0000 (UTC) Message-ID: <1506358991.3211.1.camel@redhat.com> From: Simo Sorce To: Benjamin Kaduk Cc: kitten@ietf.org Date: Mon, 25 Sep 2017 13:03:11 -0400 In-Reply-To: <20170923190527.GU96685@kduck.kaduk.org> References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 25 Sep 2017 17:03:13 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 25 Sep 2017 17:03:15 -0000 On Sat, 2017-09-23 at 14:05 -0500, Benjamin Kaduk wrote: > On Wed, Sep 20, 2017 at 11:09:29AM -0400, Simo Sorce wrote: > > On Mon, 2017-09-18 at 20:59 -0500, Benjamin Kaduk wrote: > > > On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote: > > > > > > > > The potential remedies I can think of fall into these bins: > > > > > > > > 1. Don't change the SPAKE design.  Instead, update RFC 3961 to > > > > specify > > > > that new checksum types must be deterministic, and specify that > > > > SPAKE > > > > preauth can't be used with single-DES keys.  Aside from the > > > > standards-space cost of pushing our problem down into a lower > > > > layer, the > > > > prohibition against using SPAKE with single-DES keys could make > > > > it > > > > harder for clients to be configured to refuse encrypted > > > > timestamp > > > > preauth on a pre-realm basis.  That is perhaps not a large cost > > > > as > > > > Kerberos implementations are moving away from single-DES > > > > support > > > > anyway. > > > > > > > > 2. A relatively quick fix: use PRF instead of checksum.  (Or > > > > PRF+, > > > > in > > > > which case we have to decide how much length of output we > > > > want.)  I > > > > think PRF has the requisite properties, but I would want to > > > > think > > > > on it > > > > more. > > > > > > This is probably the most appealing option, provided we can > > > accurately > > > state which properties we need (and they are provided by PRF(+)). > > > > Why is this more appealing than just saying no to DES ? > > Do we have any concern we may get future enc types that have non- > > deterministic checksums ? > > There's two aspects that push me this way: first, from a standards process > point of view, now we have to also Update a core protocol spec and hope > that people remember to check our new document whenver they try to make > a new enctype/checksum type.  While it's unlikely that a hyptoehtical > future document would actually get through the full process with such an > error, it does add to the burden on future work in this space.  The second > concern relates to implementations, in that there will need to be some sort > of logic to handle the interaction of single-DES and SPAKE preauth.  If > we were in a place where implementations were actively removing the code > for single-DES support, I would not see this as an issue, but my understanding > is that we're still several years (at least!) away from completely removing > the code (as opposed to just not using it by default).  Even though we > know that no one ought to be using the two things together, our code still > has to come up with something to do in that case, and if we get the logic > wrong things could break badly. Why not simply state in the spake document that single-DES MUST NOT be supported ? > > > > 3. We could use a hash (it doesn't need to be keyed) > > > > independent of > > > > RFC > > > > 3961.  The hash algorithm could be specified in the group > > > > profile, > > > > perhaps, but I believe the rejected-optimistic-challenge case > > > > poses > > > > a > > > > difficulty for that design. > > > > > > The hash algorithm could also be negotiated independently (so > > > that in > > > practice, e.g., sha256 is always used, at least in the initial > > > deployments). > > > For the rejected-optimistic case there is still an issue, but if > > > the > > > KDC > > > only supports O(2) hash algorithms during a hash transition, then > > > the > > > amount of state needed in the cookie is bounded by a number that > > > might > > > be smaller than the number of supported groups (but then again, > > > might > > > not). > > > > The nice thing about using the enctypes is that as new ones will > > come > > out with new, stronger checksums, we'll get those automatically, > > without adding a new thing to negotiate ... > > That is a good point, about the required checksum being matched in > perceived strength, and that holding as an invariant in the future. > > > > > 4. The most open-ended option is to back up and reconsider the > > > > purpose > > > > of the transcript checksum, which is to bind at least the > > > > public > > > > keys > > > > into key derivation.  The current transcript also binds in > > > > group > > > > negotiation and the initial factor challenge.  I can't > > > > immediately > > > > think > > > > of an alternative design which doesn't require the KDC to store > > > > a > > > > lot of > > > > information in the cookie. > > > > > > I agree that we are likely to end up with something resembling a > > > "transcript hash", even if it does not directly use a hash > > > primitve. > > > > I have to say that between PRF and a separate Hash I would rather > > use a > > separate hash. > > Hmm, so no we have a split on 2 vs. 3, unless we can somehow make 1 > more > appetizing.  Do we have the collective will to make single-DES > actually > go away entirely and force any continued users to either run custom > solutions > or stay on old software? I say that if you are on old software you have bigger problems to deal with than not being able to use SPAKE, and having SPAKE actively disallow a knowingly broken enctype is not a bad thing at all. It gives you one more lever to get off of DES. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Mon Sep 25 19:26:02 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 1ADA0134641 for ; Mon, 25 Sep 2017 19:26:00 -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, 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 aKJOJg6clOOz for ; Mon, 25 Sep 2017 19:25:56 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 BB7FA13463C for ; Mon, 25 Sep 2017 19:25:56 -0700 (PDT) X-AuditID: 1209190f-207ff70000007ae5-fd-59c9bab34efd 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id A6.49.31461.3BAB9C95; Mon, 25 Sep 2017 22:25:55 -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 v8Q2PsPS005966; Mon, 25 Sep 2017 22:25:54 -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 v8Q2Pouv006718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Sep 2017 22:25:53 -0400 Date: Mon, 25 Sep 2017 21:25:51 -0500 From: Benjamin Kaduk To: Simo Sorce Cc: kitten@ietf.org Message-ID: <20170926022550.GZ96685@kduck.kaduk.org> References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1506358991.3211.1.camel@redhat.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1t2862Skwb0zihZHN69isfgxdxGr A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJXxdMcfxoI/EhV7m+UaGK8JdzFyckgImEhM XLyZrYuRi0NIYDGTxI2fe1ggnI2MEkdm7YVyrjJJbFnygw2khUVAVWL/2V8sIDabgIpEQ/dl ZhBbREBBYkH/HbA4s4CwxPI1Z8HqhQVcJM5+WMoEYvMCrbu5YjkzxNBrjBIt7y9CJQQlTs58 AtWsI7Fz6x2gZg4gW1pi+T8OiLC8RPPW2WC7OAUMJZYs+sEKYosKKEvM27eKbQKj4Cwkk2Yh mTQLYdIsJJMWMLKsYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECA5rSf4djHMa vA8xCnAwKvHwNjCdjBRiTSwrrsw9xCjJwaQkynszESjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJ hPf6dqAcb0piZVVqUT5MSpqDRUmcd1vQrkghgfTEktTs1NSC1CKYrAwHh5IE7/adQI2CRanp qRVpmTklCGkmDk6Q4TxAwxt2gAwvLkjMLc5Mh8ifYlSUEufdBNIsAJLIKM2D6wWlHYns/TWv GMWBXhHmPQtSxQNMWXDdr4AGMwEN7p16AmRwSSJCSqqBkbfuy4ENadkTUthFIs4vfHbr4c0/ m+s1nMPXCKx/qLdQnsVWdu/9q7umC7c9Zm8K+FogIVy2lmEh25ubNoJdCyZsdjwWsEhY4fWq k9Wbg2aocKnlBHP+aUuQFRQzTa1KP71H5dR3gSkiyxamiIbPuz4153QIB/PUOZJtzzVrcp2e MLWysd38rMRSnJFoqMVcVJwIACM4sTQWAwAA Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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: Tue, 26 Sep 2017 02:26:00 -0000 On Mon, Sep 25, 2017 at 01:03:11PM -0400, Simo Sorce wrote: > On Sat, 2017-09-23 at 14:05 -0500, Benjamin Kaduk wrote: > > On Wed, Sep 20, 2017 at 11:09:29AM -0400, Simo Sorce wrote: > > > > There's two aspects that push me this way: first, from a standards process > > point of view, now we have to also Update a core protocol spec and hope > > that people remember to check our new document whenver they try to make > > a new enctype/checksum type.While it's unlikely that a hyptoehtical > > future document would actually get through the full process with such an > > error, it does add to the burden on future work in this space.The second > > concern relates to implementations, in that there will need to be some sort > > of logic to handle the interaction of single-DES and SPAKE preauth.If > > we were in a place where implementations were actively removing the code > > for single-DES support, I would not see this as an issue, but my understanding > > is that we're still several years (at least!) away from completely removing > > the code (as opposed to just not using it by default).Even though we > > know that no one ought to be using the two things together, our code still > > has to come up with something to do in that case, and if we get the logic > > wrong things could break badly. > > Why not simply state in the spake document that single-DES MUST NOT be > supported ? The potential reason to not do that that I have in mind is roughly that "it makes things easy for us now but could make things harder for us/others further down the line". But perhaps it is not actually that hard, given that DES will be used less and less. > > > > Hmm, so no we have a split on 2 vs. 3, unless we can somehow make 1 > > more > > appetizing.Do we have the collective will to make single-DES > > actually > > go away entirely and force any continued users to either run custom > > solutions > > or stay on old software? > > I say that if you are on old software you have bigger problems to deal > with than not being able to use SPAKE, and having SPAKE actively > disallow a knowingly broken enctype is not a bad thing at all. It gives > you one more lever to get off of DES. Another lever to get of DES is, on the face of it, good. On the other hand, we just removed the text preventing SPAKE from using a knowingly broken hash algorithm (MD5), which is not quite the same situation but bears some similarities. And over in the TLS WG trying to use TLS 1.3 as a lever to force adoption of RSA-PSS signatures is not going terribly well, so I don't know how much weight to give to the argument of having another lever to get rid of ${bad-thing}. That said, Greg noted on IRC that if we do have a "no DES and SPAKE together" requirement, the KDC knows the initial reply key and can do the right thing fairly easiliy, including rejecting optimistic attempts from (broken) clients. So, I'm starting to come around to the camp of "prevent SPAKE with 1DES, and require all future mandatory checksum types to be deterministic". (Possibly all future checksum types entirely, but that may be too aggressive.) -Ben From nobody Mon Sep 25 22:04: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 9B7F6120720 for ; Mon, 25 Sep 2017 22:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 9jsxHRp39uRC for ; Mon, 25 Sep 2017 22:04:29 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29541344A5 for ; Mon, 25 Sep 2017 22:04:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id C7FABCAA88; Tue, 26 Sep 2017 05:04:22 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo01-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBkdCvSneYkd; Tue, 26 Sep 2017 05:04:22 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 93A25CAA87; Tue, 26 Sep 2017 05:04:17 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20170926022550.GZ96685@kduck.kaduk.org> Date: Mon, 25 Sep 2017 22:04:15 -0700 Cc: Simo Sorce , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> <20170926022550.GZ96685@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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: Tue, 26 Sep 2017 05:04:31 -0000 > On Sep 25, 2017, at 7:25 PM, Benjamin Kaduk wrote: >=20 > That said, Greg noted on IRC that if we do have a "no DES and SPAKE > together" requirement, the KDC knows the initial reply key and can > do the right thing fairly easiliy, including rejecting optimistic > attempts from (broken) clients. So, I'm starting to come around to > the camp of "prevent SPAKE with 1DES, and require all future mandatory > checksum types to be deterministic". (Possibly all future checksum > types entirely, but that may be too aggressive.) Do we really have that many single-des deployments to worry about = anymore? Everything I know of, including AFS and AD/Windows, has better = alternatives available and just waiting to be turned on. Surely nobody = is still using JGSS in Java 1.4. Personal email. hbhotz@oxy.edu From nobody Tue Sep 26 08:24:40 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 46F9713309D for ; Tue, 26 Sep 2017 08:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 CFXC7oPN1is0 for ; Tue, 26 Sep 2017 08:24:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD13C134213 for ; Tue, 26 Sep 2017 08:24:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60E713B728; Tue, 26 Sep 2017 15:24:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 60E713B728 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rharwood@redhat.com Received: from localhost (ovpn-66-196.rdu2.redhat.com [10.10.66.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 371EB71C4A; Tue, 26 Sep 2017 15:24:34 +0000 (UTC) From: Robbie Harwood To: "Henry B \(Hank\) Hotz\, CISSP" , Benjamin Kaduk Cc: kitten@ietf.org, Simo Sorce In-Reply-To: References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> <20170926022550.GZ96685@kduck.kaduk.org> Date: Tue, 26 Sep 2017 11:25:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 26 Sep 2017 15:24:37 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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: Tue, 26 Sep 2017 15:24:39 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable "Henry B (Hank) Hotz, CISSP" writes: >> On Sep 25, 2017, at 7:25 PM, Benjamin Kaduk wrote: >>=20 >> That said, Greg noted on IRC that if we do have a "no DES and SPAKE >> together" requirement, the KDC knows the initial reply key and can >> do the right thing fairly easiliy, including rejecting optimistic >> attempts from (broken) clients. So, I'm starting to come around to >> the camp of "prevent SPAKE with 1DES, and require all future mandatory >> checksum types to be deterministic". (Possibly all future checksum >> types entirely, but that may be too aggressive.) > > Do we really have that many single-des deployments to worry about > anymore? Everything I know of, including AFS and AD/Windows, has > better alternatives available and just waiting to be turned on. Surely > nobody is still using JGSS in Java 1.4. I don't think we can really know until we start pulling support for it, rather than just having it off by default. Our model makes it easy to deploy a KDC in a "compatibility" mode (which I suspect a lot of sites do) and then worry less about what clients are running around. Thanks, =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlnKcWgACgkQJTL5F2qV pELtqw/+PmjbhKMHDkJt/Z3nRLfTonAH4CHCOubymXPSp3gBxVESX7kHf7FOSf6V GwXF29gLisCyaYgYnmHfyR76KAtdJyGQAUU9TyE+BPZvM2tq5nX2OaZyEF3m8EYD 0iUQJYXFXnQg3qJU8rC5dnqkOPDpfAQ1ZmTFQRDRtYpjGaRr7VlyVhljyn9PTeRe fjwjf8clkxB6oeE/At6EBp+K/8XydqGRr4dgePrMRG3kNk4IGu7lTBn1TlW41IZt ToNz4dFKODJ1f9f0fr/KJecPgj2sMd9t9zDUzfbllf+yMjxfJ+D87kZMGOmiYZmL dcMqiXAJ/e9K0GKQiiRXNsoq7J/IMJpPaP3yKbLaqIGok3WE2n01U5lNnXICd6Ux I7l6eMQwF2khaLbF9RShd3P8oLBokBht7T7SnYRKWvRu206rUHklFjbs7gDZCBbM ieyjvBREUd87fGD7lrLh/Aw7fk5OeZF4fq9ohj/y3byo7KZGFveMPFjyvChvpK5L Xd/WORyLfjhyJ6pfm1KQskYdQvuC965E7F+JN9c8nnRV111fGasmRsWky2M6AbFx nXzOL3n6Gz1ZH/DtG2fTcrW1pnd5gXuWkSduqp4jb+py7OeBhj1IealEMjXqQQm+ RbcoiOcrGw+RwuDxGnneA5kPj+YU8gRXwSidiBlphToxcUOqY1Y= =AqOJ -----END PGP SIGNATURE----- --=-=-=-- From brw@brandenwilliams.com Tue Sep 26 09:05:43 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 093431326F6 for ; Tue, 26 Sep 2017 09:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brandenwilliams.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 x-TXVqMPfnPn for ; Tue, 26 Sep 2017 09:05:41 -0700 (PDT) Received: from mail.kickinit.net (altair.brw.net [64.129.152.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3AA132E24 for ; Tue, 26 Sep 2017 09:05:41 -0700 (PDT) Received: from [10.69.70.5] (unknown [47.185.156.197]) (Authenticated sender: brw) by mail.kickinit.net (Postfix) with ESMTPSA id 9B86E361054 for ; Tue, 26 Sep 2017 11:05:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=brandenwilliams.com; s=201709; t=1506441940; bh=InTy+yDamKs8uH6k2Fb/THlAiv72z5jr5dIKyluDdIE=; h=Date:Subject:From:To:From; b=bcG2MaOlVnboJB/y+p1mA4yLvhjLJQfEvi83dTTTriSq2juD9jaq9z+VUMAWb6JMk hSHkXOLiVIvtG1SpLzyr2mandll0JlW3ofjKibskAn4SG7I6W9FhP9iq2KctEDpzsy hgSc7RCO9tC3RO+jhsKxkdaYunm39gTIknc8uyJAmJH1E+sknnh60zjlzDdb6BUora VFGMq9CGwLVhYZmdJQ3vStKZq1p66x15laCN4tJFnAZ4+XZehzyCojydTJRyP3j22+ +36HkDHmuvfluAQiSp5DeQAqWavJ5Ynrp/0k4B6G6Y7+ZCAAZ3L6UqKL7pkL2NOGFb RZmo2boDUmBzw== User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 26 Sep 2017 11:05:40 -0500 From: Branden Williams To: Message-ID: <6671C116-6813-4D0E-A8B1-4D93EB8D2E7A@brandenwilliams.com> Thread-Topic: New Draft: Open Password Automation Recipe (OPAR) Protocol Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3589268740_1180382055" Archived-At: Subject: [kitten] New Draft: Open Password Automation Recipe (OPAR) Protocol 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: Tue, 26 Sep 2017 16:06:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3589268740_1180382055 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Good day! =20 I=E2=80=99m happy to announce my first I-D submission here: https://tools.ietf.or= g/html/draft-bwilliams-kitten-opar-00=20 =20 Problem Description: There is no standard way for a Password Manager (1Password, LastPass, etc.)= to understand what constitutes a compliant password on a site to site basis= . Often times, the format that it suggests does not comply with the website=E2= =80=99s password policy (wrong special characters, wrong length, wrong count of = upper v. lower v. numbers). The attached proposal attempts to solve this by = allowing website owners to embed their password policy programmatically into= a JSON object that a password manager can read to automatically suggest a s= trong and compliant password. This would promote usability of password manag= ers as well as improve the user experience. (Note: I do not work for any com= pany that creates a password manager.) =20 Success: Publication of this doc as a Proposed Standard. This would allow website ow= ners to programmatically describe compliant passwords so password managers c= an suggest, transmit, and store the maximum strength compliant password poss= ible for the website. Ideally, all developers that build password managers c= ould implement the standard to improve their user experience. This could pot= entially also improve user experience for those with ADA (or non-US equivale= nt) requirements. =20 Discussion: Please discuss here on kitten@ietf.org! As this is my first submission, I a= m open to any and all comments. =20 Regards, =20 Branden R. Williams, DBA, CISSP, CISM brw@brandenwilliams.com Phone: +1 (214) 727-8227 =20 http://www.brandenwilliams.com/ --B_3589268740_1180382055 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Good day!

 

I=E2=80=99m happy to announce my first I-D submission here: https://tools.ietf.= org/html/draft-bwilliams-kitten-opar-00

 

Problem Description:

There is no standa= rd way for a Password Manager (1Password, LastPass, etc.) to understand what= constitutes a compliant password on a site to site basis. Often times, the = format that it suggests does not comply with the website=E2=80=99s password policy= (wrong special characters, wrong length, wrong count of upper v. lower v. n= umbers). The attached proposal attempts to solve this by allowing website ow= ners to embed their password policy programmatically into a JSON object that= a password manager can read to automatically suggest a strong and compliant= password. This would promote usability of password managers as well as impr= ove the user experience. (Note: I do not work for any company that creates a= password manager.)

 

Success:

Publication of this doc as a Proposed Standard. This wo= uld allow website owners to programmatically describe compliant passwords so= password managers can suggest, transmit, and store the maximum strength com= pliant password possible for the website. Ideally, all developers that build= password managers could implement the standard to improve their user experi= ence. This could potentially also improve user experience for those with ADA= (or non-US equivalent) requirements.

 

Discussion:

Please discuss here on kitten@ietf.org! As this is my first submission, I= am open to any and all comments.

 

= Regards,

 

Branden R. Williams, DBA, CISSP, CISM

brw@br= andenwilliams.com

Phone: +1 (214) 727-8227

 

http://www.brandenwilliams.com/

--B_3589268740_1180382055-- From nobody Tue Sep 26 09:28:26 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 E6BB21342DD for ; Tue, 26 Sep 2017 09:28:24 -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, 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 ajLmb5H6jMxJ for ; Tue, 26 Sep 2017 09:28:23 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 84A351330B3 for ; Tue, 26 Sep 2017 09:28:23 -0700 (PDT) X-AuditID: 1209190d-95fff70000003123-f8-59ca80264b41 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 79.C7.12579.6208AC95; Tue, 26 Sep 2017 12:28:22 -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 v8QGSLoc005467 for ; Tue, 26 Sep 2017 12:28:22 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [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 v8QGSKHZ019937 for ; Tue, 26 Sep 2017 12:28:21 -0400 From: Greg Hudson To: kitten@ietf.org Date: Tue, 26 Sep 2017 12:28:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUixCmqravWcCrS4MtfOYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+nuv0wFx8Uq7p46ytjAOEeoi5GDQ0LARGLS/+AuRi4OIYHF TBLbPnxkhHCOM0p0Pb/DCuF0MEncPfOEuYuRk4NNQFli/f6tLCC2iICwxO6t78DiwgK2Eve/ /GcFmcoioCpxbYEdSJhXwFBi6ud/jBC2oMTJmU/AWpkFJCQOvnjBPIGRexaS1CwkqQWMTKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCQ0CSdwfjv7tehxgFOBiVeHgZQk5F CrEmlhVX5h5ilORgUhLlVZQDCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhTawFyvGmJFZWpRbl w6SkOViUxHm3Be2KFBJITyxJzU5NLUgtgsnKcHAoSfDW1gM1ChalpqdWpGXmlCCkmTg4QYbz AA1nAanhLS5IzC3OTIfIn2KUlBLn/VMHlBAASWSU5sH1vmIUB3pBmPcJSJYHGM9wXa+ABjIB DeydegJkYEkiQkqqgbFQKCHgxQTDgGe2/HmBJ44tv676eVHvLnfBiED2ZzuW/ZRUvirlUV7F sYtvq6Rs+q85/hINolZeiodUdk48pri95tfd7Xrv66/yK10L3KOe+3Wr6KydjT1GclrJV051 aD+/skNy8TG5pxuNU7wnrJHgsJZh2OLLFxSx5eIRje2pzzhNE9eu2aHEUpyRaKjFXFScCACk 9HdapAIAAA== Archived-At: Subject: [kitten] Updating RFC 3961 to require deterministic checksums 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: Tue, 26 Sep 2017 16:28:25 -0000 (I'm starting a new thread to emphasize what we're talking about doing, for anyone who is interested in the cryptographic framework but perhaps not as much in a specific new preauth mechanism.) It looks like consensus on the SPAKE transcript checksum issue is tending towards updating RFC 3961 to require deterministic checkums for future mandatory-to-implement checksum types. I propose the following wording changes to the SPAKE draft: 1. Add a new section titled "Update to Checksum Specifications" just before the "SPAKE Pre-Authentication Message Protocol" section. It reads: [RFC3961] section 4 specifies the Kerberos checksum algorithm profile. It does not require checksums to be deterministic. In practice, DES-based checksum types (deprecated by [RFC6649]) use a random confounder; all other current checksum types are deterministic. Future checksum types required by an encryption type MUST be deterministic. All future checksum types SHOULD be deterministic. This mechanism requires a deterministic checksum type for the transcript checksum. Therefore, a KDC MUST NOT offer this mechanism if the initial reply key is of type des-cbc-crc, des-cbc-md4, or des- cbc-md5. 2. Flesh out the description of the second optimization to describe fallback to other preauth mechs with the following diff. This case already needed specifying because the KDC may not support any of the client's groups, but it is also relevant to the case of a KDC refusing SPAKE due to a single-DES initial reply key. Second, clients MAY skip the first pass and send an AS-REQ with a - PA-SPAKE PA-DATA element using the support choice. The KDC MUST - include a PA-ETYPE-INFO2 value within the METHOD-DATA of the + PA-SPAKE PA-DATA element using the support choice. If the KDC accepts + the support message and generates a challenge, it MUST include a + PA-ETYPE-INFO2 value within the METHOD-DATA of the KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may - not otherwise be able to compute the initial reply key. KDCs MUST - support this optimization. + not otherwise be able to compute the initial reply key. If the KDC + cannot continue with SPAKE (either because initial reply key type is + incompatible with SPAKE or because it does not support any of the + client's groups) but can offer other pre-authentication mechanisms, it + MUST respond with a KDC_ERR_PREAUTH_FAILED error containing + METHOD-DATA. A client supporting this optimization MUST continue after + a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113] section 2. + KDCs MUST support this optimization. 3. For proper bookkeeping, add "Updates: RFC 3961" to the header, add RFC 6649 as a non-normative reference, and add KDC_ERR_PREAUTH_FAILED as one of the terms specified in RFC 6113. From nobody Wed Sep 27 19:15:45 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 3436213525D for ; Wed, 27 Sep 2017 19:15:43 -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, 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 b3ZY4vo9tQUj for ; Wed, 27 Sep 2017 19:15:41 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 9C61C135259 for ; Wed, 27 Sep 2017 19:15:41 -0700 (PDT) X-AuditID: 1209190d-17fff70000005ec5-1b-59cc5b4c8970 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 85.8D.24261.C4B5CC95; Wed, 27 Sep 2017 22:15:40 -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 v8S2FdWm004987; Wed, 27 Sep 2017 22:15:39 -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 v8S2FZjB008208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Sep 2017 22:15:38 -0400 Date: Wed, 27 Sep 2017 21:15:35 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20170928021534.GE96685@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.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrOsTfSbSYGWTjMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fr4UZaCd5IVNxvb2BsYz4h0MXJySAiYSOz5eYuxi5GLQ0hg MZPE8iNfGUESQgIbGSWOPeaFSFxlkuj78IkZJMEioCrRsr2dHcRmE1CRaOi+DBYXEVCUeLZq LguIzSwgLLF8zVk2EFtYwEtiY+ssJhCbF2jbjs132SAWGErsfXCfDSIuKHFy5hOoXi2JG/9e AtVzANnSEsv/cYCEOQWMJLqWbAcbIyqgLDFv3yq2CYwCs5B0z0LSPQuhewEj8ypG2ZTcKt3c xMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzggJTk3cH4767XIUYBDkYlHt4LC05HCrEmlhVX 5h5ilORgUhLlXeJ+JlKILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO95ZqAcb0piZVVqUT5MSpqD RUmcd1vQrkghgfTEktTs1NSC1CKYrAwHh5IE788IoEbBotT01Iq0zJwShDQTByfIcB6Q4SA1 vMUFibnFmekQ+VOMilLivJpRQAkBkERGaR5cLyhhSGTvr3nFKA70ijDv9kigKh5gsoHrfgU0 mAlocO/UEyCDSxIRUlINjGslk7Zlvn/gYp0U+/nL9jP6tTcE5r4UW99Zt3rR/xevD+TpnWRY tkj3Y46BfH6d2lKDhpDwIvne1Wul+a/l3spc+s96skCRzPGf9q0qJ9t1mC76fNjzkmWnV8lB 004+7+33T53hfM24xXdOx3RrMaa1eXfPrAvTjLsy/0zY+zqhC8c5zWW4OZRYijMSDbWYi4oT Abhe0zzzAgAA Archived-At: Subject: Re: [kitten] Updating RFC 3961 to require deterministic checksums 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, 28 Sep 2017 02:15:43 -0000 On Tue, Sep 26, 2017 at 12:28:20PM -0400, Greg Hudson wrote: > (I'm starting a new thread to emphasize what we're talking about doing, > for anyone who is interested in the cryptographic framework but perhaps > not as much in a specific new preauth mechanism.) > > It looks like consensus on the SPAKE transcript checksum issue is > tending towards updating RFC 3961 to require deterministic checkums for > future mandatory-to-implement checksum types. I propose the following > wording changes to the SPAKE draft: > > 1. Add a new section titled "Update to Checksum Specifications" just > before the "SPAKE Pre-Authentication Message Protocol" section. It > reads: > > [RFC3961] section 4 specifies the Kerberos checksum algorithm > profile. It does not require checksums to be deterministic. In > practice, DES-based checksum types (deprecated by [RFC6649]) use a > random confounder; all other current checksum types are > deterministic. > > Future checksum types required by an encryption type MUST be > deterministic. All future checksum types SHOULD be deterministic. > > This mechanism requires a deterministic checksum type for the > transcript checksum. Therefore, a KDC MUST NOT offer this mechanism > if the initial reply key is of type des-cbc-crc, des-cbc-md4, or des- > cbc-md5. > > 2. Flesh out the description of the second optimization to describe > fallback to other preauth mechs with the following diff. This case > already needed specifying because the KDC may not support any of the > client's groups, but it is also relevant to the case of a KDC refusing > SPAKE due to a single-DES initial reply key. > > Second, clients MAY skip the first pass and send an AS-REQ with a > - PA-SPAKE PA-DATA element using the support choice. The KDC MUST > - include a PA-ETYPE-INFO2 value within the METHOD-DATA of the > + PA-SPAKE PA-DATA element using the support choice. If the KDC accepts > + the support message and generates a challenge, it MUST include a > + PA-ETYPE-INFO2 value within the METHOD-DATA of the > KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may > - not otherwise be able to compute the initial reply key. KDCs MUST > - support this optimization. > + not otherwise be able to compute the initial reply key. If the KDC > + cannot continue with SPAKE (either because initial reply key type is > + incompatible with SPAKE or because it does not support any of the > + client's groups) but can offer other pre-authentication mechanisms, it > + MUST respond with a KDC_ERR_PREAUTH_FAILED error containing > + METHOD-DATA. A client supporting this optimization MUST continue after > + a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113] section 2. > + KDCs MUST support this optimization. > > 3. For proper bookkeeping, add "Updates: RFC 3961" to the header, add > RFC 6649 as a non-normative reference, and add KDC_ERR_PREAUTH_FAILED as > one of the terms specified in RFC 6113. This looks good to me. I think we also will need a 4. Include instructions in the IANA considerations section to update the registration policy for the checksum type registry that notes the additional constraint on checksum behavior. -Ben From nobody Wed Sep 27 19:21:45 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 0BCC1135269 for ; Wed, 27 Sep 2017 19:21:37 -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, 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 y_V3QDY6C9LS for ; Wed, 27 Sep 2017 19:21:35 -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 26EBB135267 for ; Wed, 27 Sep 2017 19:21:34 -0700 (PDT) X-AuditID: 1209190e-1d3ff7000000497a-5a-59cc5cad7a1d 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 6C.7F.18810.DAC5CC95; Wed, 27 Sep 2017 22:21:33 -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 v8S2LWKZ006171; Wed, 27 Sep 2017 22:21:32 -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 v8S2LSX3010007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Sep 2017 22:21:30 -0400 Date: Wed, 27 Sep 2017 21:21:28 -0500 From: Benjamin Kaduk To: "Henry B (Hank) Hotz, CISSP" Cc: Simo Sorce , kitten@ietf.org Message-ID: <20170928022127.GF96685@kduck.kaduk.org> References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> <20170926022550.GZ96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT110bcybSYM88TouP9xayWBzdvIrF 4sfcRawOzB5Llvxk8tja9JfZ4/2+q2wBzFFcNimpOZllqUX6dglcGefam5gKznFVzJ37hamB 8SRHFyMnh4SAicSe/8/Zuhi5OIQEFjNJXPxwigXC2cgoseXRFUYI5yqTxOe7E5hBWlgEVCWm X5jGCGKzCahINHRfBouLCBhKTF85kRXEZgayp+zdyAZiCwu4SJz9sJQJxOYFWreksZ8dYugm Jom71xcxQyQEJU7OfMIC0awlcePfS6AGDiBbWmL5P7BTOQWsJV48fge2V1RAWWLevlVsExgF ZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxhBwcspybeD cVKD9yFGAQ5GJR7eCwtORwqxJpYVV+YeYpTkYFIS5V3ifiZSiC8pP6UyI7E4I76oNCe1+BCj BAezkgjveWagHG9KYmVValE+TEqag0VJnHdb0K5IIYH0xJLU7NTUgtQimKwMB4eSBO+daKBG waLU9NSKtMycEoQ0EwcnyHAeoOGsMSDDiwsSc4sz0yHypxh1OR7duPuHSYglLz8vVUqc9z/I IAGQoozSPLg5oKQjkb2/5hWjONBbwrxFIFU8wIQFN+kV0BImoCW9U0+ALClJREhJNTDaCYj5 qSvkTEvm++i6bvkO21+TJ0+bttU/fNGpO4yTorxTd9+wUfXnS3ybUTD1jaLL5u16fjnupzVi ZWQfLq3J4EjdwLA6TbPnvtqzpdp7v8rH7qj3SL7b/DXbev2Bswn5y9csnL5gtYryMh7zO/sl jLLX/Ger3PEwtTp1/bH+WBWp73Fb42SVWIozEg21mIuKEwEZgac/FQMAAA== Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 28 Sep 2017 02:21:37 -0000 On Mon, Sep 25, 2017 at 10:04:15PM -0700, Henry B (Hank) Hotz, CISSP wrote: > > > On Sep 25, 2017, at 7:25 PM, Benjamin Kaduk wrote: > > > > That said, Greg noted on IRC that if we do have a "no DES and SPAKE > > together" requirement, the KDC knows the initial reply key and can > > do the right thing fairly easiliy, including rejecting optimistic > > attempts from (broken) clients. So, I'm starting to come around to > > the camp of "prevent SPAKE with 1DES, and require all future mandatory > > checksum types to be deterministic". (Possibly all future checksum > > types entirely, but that may be too aggressive.) > > Do we really have that many single-des deployments to worry about anymore? Everything I know of, including AFS and AD/Windows, has better alternatives available and just waiting to be turned on. Surely nobody is still using JGSS in Java 1.4. As I understand it, there is not much (any?) modern software that strictly requires single-DES, but there are also many sites where the effort to upgrade has not been expended. Even in ATHENA.MIT.EDU, we have cross-realm keys that are actively used (albeit not for terribly critical functionality) that remain single-DES because of the logistical challenges involved in getting both KDC administrators in contact and with a trusted channel. -Ben From nobody Fri Sep 29 02:08:21 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 78203126B6E for ; Fri, 29 Sep 2017 02:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 PXXkQumkyQwK for ; Fri, 29 Sep 2017 02:08:17 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (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 4D977124239 for ; Fri, 29 Sep 2017 02:08:17 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id q124so2048454wmb.0 for ; Fri, 29 Sep 2017 02:08:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version; bh=sMfILGwuC+l5qhxrZKecrxHGjL9w03RlkS5wgB2TM3o=; b=RiyLioZo3ljRbujchfHHIcNSlErMkMfof17/8FkDTRPWbMTlXJBN/gDe3V4BYrcLUZ g8HzfiRx6itCSeGKTW9Z60pP7dYTrK0kWkZfSQrZ4yIDYf8QumyUmq3GC65T54knRZpb hgjFU2lL82zrccDNobdeYix8cMAUKlbJQ/xYlG5aWyTc7FyR7efwCFPDHM2+1ynJ+aG7 xtkr5AHjZxtgP6xfnsD+SwiOjDfcBlZwBn2BXT//0OzfD1meD5eWjwiUK57pA3X6aF4Y prJStYmnAo77Ejb89pBRS+AcySLKL/hmm62IzKz/gl+ItIso/968TRj38MwtrnAUpnqe af9g== X-Gm-Message-State: AHPjjUiRWq56Umy2igdFuxrzAOsxnJ0dyk4qDE5pNHDjWssr+yowM5N1 z8onpGkFVcmQ7YWuCN245Ypxn/r8 X-Google-Smtp-Source: AOwi7QCvsqHn+A6xZNmEo/hjBEf0iUatkLmoNb2YNwQDKdkFNAKG15M3zk1a1gbVeWlNwc5H3X8GGg== X-Received: by 10.80.151.206 with SMTP id f14mr8876034edb.27.1506676095287; Fri, 29 Sep 2017 02:08:15 -0700 (PDT) Received: from ?IPv6:2001:a62:11f3:ee01:54eb:8b20:9338:80c? ([2001:a62:11f3:ee01:54eb:8b20:9338:80c]) by smtp.googlemail.com with ESMTPSA id j6sm681716edj.58.2017.09.29.02.08.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 02:08:13 -0700 (PDT) To: kitten@ietf.org Cc: XMPP Standards , Christoph Egger , Peter Saint-Andre From: Florian Schmaus Message-ID: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> Date: Fri, 29 Sep 2017 11:08:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1wPL8f8arTj9MASOoMHS9uwkbkOjPX2i7" Archived-At: Subject: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) 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, 29 Sep 2017 09:08:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1wPL8f8arTj9MASOoMHS9uwkbkOjPX2i7 Content-Type: multipart/mixed; boundary="eLeep0rsvSQBWhCLNPAllqJ0NOeLJD53v"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Cc: XMPP Standards , Christoph Egger , Peter Saint-Andre Message-ID: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> Subject: The Hashed-Token SASL Mechanism (SASL-HT) --eLeep0rsvSQBWhCLNPAllqJ0NOeLJD53v Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I would like to note the existence of draft-schmaus-kitten-sasl-ht-01: https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-01 Fast, ideally instant, session reattachment becomes increasingly important, partly because of the rising share of mobile sessions. A while ago I started thinking about a new approach for quick XMPP session reattachment. Currently in XMPP a session obtains a (non-sensitive) token which, after authentication via SASL, it can use to resume an existing session (XEP-0198). However, this does lead to a number of round-trips during session setup, many of which we can elide by combining the authentication and resumption steps. Thus we initially authenticate an XMPP session using a strong mechanism like SCRAM, but at resumption-time we want a single round trip mechanism. The basic idea of such a mechanism is that the client requests a short-lived, exclusively ephemeral token after being authenticated, which can be used to authenticate the resumption in an efficient manner. Members of the XSF community pointed out that that it eventually makes sense to split the work into a number of distinct portions so that other application protocols can re-use and benefit from it: 1) An extensible SASL profile, replacing the existing SASL profile specified in RFC 6120, being developed within the XSF as XEP-0388 [1] (although we might well move this to IETF once it fits our needs). 2) An extension to this profile to support the framework of XEP-0198 session resumption (XEP-ISR-SALS2, [2]). 3) A new SASL mechanism suitable for the purpose (HT-*, as specified in draft-schmaus-kitten-sasl-ht-01). The SASL HT-* mechanism outlined is attempting to provide a reasonably secure authentication based around a token obtained over the application protocol, in a single round-trip. This single-round-trip is a key requirement. The proposal uses a single-use token as a shared secret, provides channel binding and mutual authentication. Because neither the XSF nor the authors of the Internet Draft do claim to have the expertise required to adequately review and otherwise develop a SASL mechanism it has been submitted as an Internet Draft by an individual. The XSF does AFAIK not operate a formal liaison process with the IETF in general; instead we will simply encourage interested individuals to participate here instead. In particular, the XSF will neither participate, nor attempt to control, as an organisation. Many of the participants within the XSF are also IETF participants, so we'll play nicely. Your feedback is highly appreciated. Thanks Florian 1: https://xmpp.org/extensions/xep-0388.html 2: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html --eLeep0rsvSQBWhCLNPAllqJ0NOeLJD53v-- --1wPL8f8arTj9MASOoMHS9uwkbkOjPX2i7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAlnODXtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFIRuQf/TnGPbA+XdoAWMJairPcNLt390jmPwTfw QXpXNXN1FUVFvSwTSCbEFMuxMHf499gac2VlN0vxlb2Jgqr2C/BCVRvbdgcEaboU SUPJGyqRdrR73opA80gNjDRKSUNVCDkXUQxVz5kW/tng47A+URlSo+/DIP3QoY6B RpMZV99Oiev72TdAFV59DFqpNLkBdndo3Xw9j6zV7rK+1hfvAg8fqnslAcSsoGwT 0pZ72GupRMU13gKIlbZV5eDO4BKaVK7QLI5YYizdB0LsaZNLXSKxXUCeiJbba8Is aIhdKPMQbIReXYVK7ygAWUmfoQq6O/dozH9IffWrFs/mcZcEefu2Hw== =wpr1 -----END PGP SIGNATURE----- --1wPL8f8arTj9MASOoMHS9uwkbkOjPX2i7-- From nobody Fri Sep 29 14:42: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 D1D7B1342D3 for ; Fri, 29 Sep 2017 14:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DSC_xldyws2R for ; Fri, 29 Sep 2017 14:42:14 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 A6AB813247A for ; Fri, 29 Sep 2017 14:42:14 -0700 (PDT) X-AuditID: 1209190f-62fff7000000662c-ef-59cebe35440a 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id E5.AA.26156.53EBEC95; Fri, 29 Sep 2017 17:42:13 -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 v8TLgCJZ017671; Fri, 29 Sep 2017 17:42:12 -0400 Received: from [18.101.8.111] (VPN-18-101-8-111.MIT.EDU [18.101.8.111]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8TLg9p5015009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Sep 2017 17:42:11 -0400 To: Benjamin Kaduk References: <20170928021534.GE96685@kduck.kaduk.org> Cc: kitten@ietf.org From: Greg Hudson Message-ID: <045c369b-491d-07b5-1615-d238e5efde51@mit.edu> Date: Fri, 29 Sep 2017 17:42:09 -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: <20170928021534.GE96685@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrGu671ykwZv/0hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuvPiywF7awVq68+ZWlgnMDSxcjJISFgInFhw1SmLkYuDiGB xUwSu6dOYoRwNjJKzHg7nRnCOcokcexXNyNIi7CAl8TG1llMILaIgJLE4rMtbCC2kECMxM1j v8DGMgsISyxfcxYsziagLLF+/1awOK+AlcSMX0+YQWwWAVWJ01uWsoLYogIREg87d7FD1AhK nJz5BKyeU8BUYs/ap+wQM/Ukdlz/xQphy0tsfzuHeQKjwCwkLbOQlM1CUraAkXkVo2xKbpVu bmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGcFhK8u9gnNPgfYhRgINRiYe3weNcpBBrYllx Ze4hRkkOJiVR3hW7gEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeDeuBcrxpiRWVqUW5cOkpDlY lMR5twXtihQSSE8sSc1OTS1ILYLJynBwKEnw2u4FahQsSk1PrUjLzClBSDNxcIIM5wEaLrQH ZHhxQWJucWY6RP4Uoy7HjYfX/zAJseTl56VKifPeBCkSACnKKM2DmwNOJ6kc+a8YxYHeEua1 AFnHA0xFcJNeAS1hAloyeeIZkCUliQgpqQZG+W1Wc/0m1r/hOHD53A4eR72zu8sMVWudPsnM XW3blOZ8zyufw+tZ7+YteRs5brjuuPi7cragRNba4uas+QyejDI37VhPXOqYc/ncyXOKZg2H fr/e+zl+1Se3RQ+lv5mearqa5/MyaN9xzoMLvna/X2nRz+KXllbA4rrhw8FX3ZlljUe90zvr lViKMxINtZiLihMBPJRKggIDAAA= Archived-At: Subject: Re: [kitten] Updating RFC 3961 to require deterministic checksums 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, 29 Sep 2017 21:42:16 -0000 On 09/27/2017 10:15 PM, Benjamin Kaduk wrote: > 4. Include instructions in the IANA considerations section to update the > registration policy for the checksum type registry that notes the additional > constraint on checksum behavior. Proposed wording (at the beginning of the IANA considerations section): The notes for the "Kerberos Checksum Type Numbers" registry should be updated with the following addition: "If the checksum algorithm is non-deterministic, see [this document] Section 4". (where "Section 4" is an xref to the new "Update to Checksum Specifications" section from my previous message in this thread.) From nobody Sat Sep 30 02:05:36 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 6C3B51326F6 for ; Sat, 30 Sep 2017 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 a0DnE2dyU2Vp for ; Sat, 30 Sep 2017 02:05:34 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2D21326ED for ; Sat, 30 Sep 2017 02:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id D32AA2BC35; Sat, 30 Sep 2017 09:05:31 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGEXOg-5gGa9; Sat, 30 Sep 2017 09:05:31 +0000 (UTC) Received: from macbook-air-2.lan (66-215-86-135.dhcp.psdn.ca.charter.com [66.215.86.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id B04642BBF7; Sat, 30 Sep 2017 09:05:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20170928022127.GF96685@kduck.kaduk.org> Date: Sat, 30 Sep 2017 02:05:25 -0700 Cc: Simo Sorce , kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8CDF104A-0D83-4B46-9016-E8ECA6F581D3@oxy.edu> References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> <20170926022550.GZ96685@kduck.kaduk.org> <20170928022127.GF96685@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 30 Sep 2017 09:05:35 -0000 > On Sep 27, 2017, at 7:21 PM, Benjamin Kaduk wrote: >=20 > On Mon, Sep 25, 2017 at 10:04:15PM -0700, Henry B (Hank) Hotz, CISSP = wrote: >>=20 >>> On Sep 25, 2017, at 7:25 PM, Benjamin Kaduk wrote: >>>=20 >>> That said, Greg noted on IRC that if we do have a "no DES and SPAKE >>> together" requirement, the KDC knows the initial reply key and can >>> do the right thing fairly easiliy, including rejecting optimistic >>> attempts from (broken) clients. So, I'm starting to come around to >>> the camp of "prevent SPAKE with 1DES, and require all future = mandatory >>> checksum types to be deterministic". (Possibly all future checksum >>> types entirely, but that may be too aggressive.) >>=20 >> Do we really have that many single-des deployments to worry about = anymore? Everything I know of, including AFS and AD/Windows, has better = alternatives available and just waiting to be turned on. Surely nobody = is still using JGSS in Java 1.4. >=20 > As I understand it, there is not much (any?) modern software that = strictly > requires single-DES, but there are also many sites where the effort to > upgrade has not been expended. Even in ATHENA.MIT.EDU, we have = cross-realm > keys that are actively used (albeit not for terribly critical = functionality) > that remain single-DES because of the logistical challenges involved = in > getting both KDC administrators in contact and with a trusted channel. >=20 > -Ben I know that kind of thing can be much harder than it seems it should. = OTOH, do you think that difficulty (as a specific example) should = prevent us from stipulating "no 1des with SPAKE=E2=80=9D? Personal email. hbhotz@oxy.edu From nobody Sat Sep 30 10:12:12 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 55C76134290 for ; Sat, 30 Sep 2017 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 cWXfNVlhTAHG for ; Sat, 30 Sep 2017 10:12:09 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 37237133226 for ; Sat, 30 Sep 2017 10:12:09 -0700 (PDT) X-AuditID: 1209190f-d9dff700000026d9-73-59cfd0671949 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id DC.07.09945.760DFC95; Sat, 30 Sep 2017 13:12:08 -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 v8UHC7Nl028138; Sat, 30 Sep 2017 13:12:07 -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 v8UHC4Bd018948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Sep 2017 13:12:06 -0400 Date: Sat, 30 Sep 2017 12:12:04 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20170930171203.GR96685@kduck.kaduk.org> References: <20170928021534.GE96685@kduck.kaduk.org> <045c369b-491d-07b5-1615-d238e5efde51@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <045c369b-491d-07b5-1615-d238e5efde51@mit.edu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrptx4XykQetRNoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9qbnWwFf1kr3s0/wtzA+Iili5GTQ0LARGLF61lANheHkMBi Jomrvz+zQjgbGSXmNz+Hylxlkvi6fR9bFyMHB4uAqsTECRUg3WwCKhIN3ZeZQWwRAUWJZ6vm gk1lFhCWWL7mLBuILSzgJbGxdRYTiM0LtO3K892MEDN7GSW6/75ih0gISpyc+QSqWUvixr+X TCC7mAWkJZb/4wAJcwpYS3S2toHNFBVQlpi3bxXbBEaBWUi6ZyHpnoXQvYCReRWjbEpulW5u YmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZQSHJK8u9gnNPgfYhRgINRiYe3weNcpBBrYllx Ze4hRkkOJiVR3sbT5yOF+JLyUyozEosz4otKc1KLDzFKcDArifDWngDK8aYkVlalFuXDpKQ5 WJTEebcF7YoUEkhPLEnNTk0tSC2CycpwcChJ8CqfB2oULEpNT61Iy8wpQUgzcXCCDOcBGu4I UsNbXJCYW5yZDpE/xajLcePh9T9MQix5+XmpUuK89iBFAiBFGaV5cHNAqUQie3/NK0ZxoLeE eTNAqniAaQhu0iugJUxASyZPPAOypCQRISXVwBgnYLnnqdZ+nciS/1M2lNzhtUqO3n6T58Pf xX4+L9mLQmtX7/+YNmVGb8uTMMU1k1+6NP+LifTcLmufJaCpVFz2aZeHd5a5v4C03X+hlRUp 96f0TZj9q3mf/9sIjZUlH4W+5opv15H9lfOOM2QRw8wW09I9s8xXPXbt7fz3Y9fuiRfYr4o9 Y1RiKc5INNRiLipOBAAPs2zAAAMAAA== Archived-At: Subject: Re: [kitten] Updating RFC 3961 to require deterministic checksums 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, 30 Sep 2017 17:12:10 -0000 On Fri, Sep 29, 2017 at 05:42:09PM -0400, Greg Hudson wrote: > On 09/27/2017 10:15 PM, Benjamin Kaduk wrote: > > 4. Include instructions in the IANA considerations section to update the > > registration policy for the checksum type registry that notes the additional > > constraint on checksum behavior. > > Proposed wording (at the beginning of the IANA considerations section): > > The notes for the "Kerberos Checksum Type Numbers" registry should be > updated with the following addition: "If the checksum algorithm is > non-deterministic, see [this document] Section 4". > > (where "Section 4" is an xref to the new "Update to Checksum > Specifications" section from my previous message in this thread.) Sounds good to me. -Ben From nobody Sat Sep 30 12:02: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 28E3C132125 for ; Sat, 30 Sep 2017 12:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 mZLlJSA0JcGB for ; Sat, 30 Sep 2017 12:02:15 -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 E4213126BF3 for ; Sat, 30 Sep 2017 12:02:14 -0700 (PDT) X-AuditID: 1209190e-0f3ff70000001974-ab-59cfea35d815 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 80.71.06516.53AEFC95; Sat, 30 Sep 2017 15:02:13 -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 v8UJ2Cip031340; Sat, 30 Sep 2017 15:02:13 -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 v8UJ29Kj015529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Sep 2017 15:02:11 -0400 Date: Sat, 30 Sep 2017 14:02:09 -0500 From: Benjamin Kaduk To: "Henry B (Hank) Hotz, CISSP" Cc: Simo Sorce , kitten@ietf.org Message-ID: <20170930190208.GS96685@kduck.kaduk.org> References: <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com> <20170923190527.GU96685@kduck.kaduk.org> <1506358991.3211.1.camel@redhat.com> <20170926022550.GZ96685@kduck.kaduk.org> <20170928022127.GF96685@kduck.kaduk.org> <8CDF104A-0D83-4B46-9016-E8ECA6F581D3@oxy.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8CDF104A-0D83-4B46-9016-E8ECA6F581D3@oxy.edu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixCmqrWv66nykwaIP5hYf7y1ksTi6eRWL xY+5i1gdmD2WLPnJ5LG16S+zx/t9V9kCmKO4bFJSczLLUov07RK4Mja9nMRYsI+9YnpHF1sD 4y/WLkZODgkBE4m3b78wdTFycQgJLGaSmLF2MhuEs5FRomf2dEYI5yqTxJv/DWAtLAKqEv83 f2AGsdkEVCQaui+D2SIChhLTV04Eq2EGsqfs3cgGYgsLuEic/bAUaAUHBy/Qur83ayBm9jFL bGjvAuvlFRCUODnzCQtEr7rEn3mXmEHqmQWkJZb/44AIy0s0b50NFuYUsJa4vtcSJCwqoCwx b98qtgmMgrOQDJqFZNAshEGzkAxawMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81 pXQTIzjQJfl2ME5q8D7EKMDBqMTDu+D2+Ugh1sSy4srcQ4ySHExKorzcz4FCfEn5KZUZicUZ 8UWlOanFhxglOJiVRHgnPAHK8aYkVlalFuXDpKQ5WJTEebcF7YoUEkhPLEnNTk0tSC2Cycpw cChJ8Jq/BGoULEpNT61Iy8wpQUgzcXCCDOcBGq4IUsNbXJCYW5yZDpE/xWjMcePh9T9MHI9u 3P3DJMSSl5+XKiXOqwJSKgBSmlGaBzcNlKwksvfXvGIUB3pOmFcKpIoHmOjg5r0CWsUEtGry xDMgq0oSEVJSDYzOz2N/xVr53E8JfD/9rYbJLL6tFXz2/513JMmuyDNb03Nr/ccCDXbpNq3V szX3/+T54h8w1ePtYXaNGUwuEcFSG284XvFcZXIso/SJ4UuBQO4VYssOv+mVic17f/6jn2xZ z6rt09z5+BMrQyckVxak7ky48WDSxb2PglxeHhBN+vRiily1V7ESS3FGoqEWc1FxIgAB4AAv MQMAAA== Archived-At: Subject: Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums 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, 30 Sep 2017 19:02:16 -0000 On Sat, Sep 30, 2017 at 02:05:25AM -0700, Henry B (Hank) Hotz, CISSP wrote: > > > On Sep 27, 2017, at 7:21 PM, Benjamin Kaduk wrote: > > > > As I understand it, there is not much (any?) modern software that strictly > > requires single-DES, but there are also many sites where the effort to > > upgrade has not been expended. Even in ATHENA.MIT.EDU, we have cross-realm > > keys that are actively used (albeit not for terribly critical functionality) > > that remain single-DES because of the logistical challenges involved in > > getting both KDC administrators in contact and with a trusted channel. > > > > -Ben > > I know that kind of thing can be much harder than it seems it should. OTOH, do you think that difficulty (as a specific example) should prevent us from stipulating "no 1des with SPAKE”? No, I don't think examples of that sort should prevent us from placing that restriction on SPAKE usage. -Ben