From nobody Sun Feb 1 09:38:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11811A1A50 for ; Sun, 1 Feb 2015 09:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lBdJlbI9aGvE for ; Sun, 1 Feb 2015 09:38:04 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006D51A1A45 for ; Sun, 1 Feb 2015 09:38:03 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-ff-54ce647ad6c3 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 AF.FF.03354.A746EC45; Sun, 1 Feb 2015 12:38:02 -0500 (EST) 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 t11Hbulc028065; Sun, 1 Feb 2015 12:37:57 -0500 Received: from [18.101.8.94] (vpn-18-101-8-94.mit.edu [18.101.8.94]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t11Hbsga017627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 1 Feb 2015 12:37:56 -0500 Message-ID: <54CE6472.9050408@mit.edu> Date: Sun, 01 Feb 2015 12:37:54 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: <20150123003504.3896.40306.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrVuVci7EYPMvNYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/+es6wFTZwVf9r2MTcwLmXvYuTkkBAwkXiwYxYbhC0mceHe eiCbi0NIYDGTxOu1L9ghnA2MEq33DrJAOAeYJDZM6QZr5xVQk5h3pZERxGYRUJV4dnEuE4jN JqAssX7/VqAGDg5RgTCJ882MEOWCEidnPmEBsUUEjCXu/rwBZgsLeEt0HroO1iokUCbRvqOB FcTmFHCSePnpIFicWUBPYsf1X6wQtrxE89bZzBMYBWYhGTsLSdksJGULGJlXMcqm5Fbp5iZm 5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBAUlu4vqDsYJh5QOMQpwMCrx8C64fDZEiDWxrLgy 9xCjJAeTkijvwv1AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8eepAOd6UxMqq1KJ8mJQ0B4uS OO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd7M5HMhQoJFqempFWmZOSUIaSYOTpDhPEDDF4HU 8BYXJOYWZ6ZD5E8xKkqJ87aAJARAEhmleXC9sKTxilEc6BVhXk6QKh5gwoHrfgU0mAlo8LJJ Z0AGlyQipKQaGJO0vKb/lH3l+3hjUOI927W35lh+9mvK2vrUSUfy1lLuBxZX9tacNf970C9m /TKOU96nLSKunBWp2nw98eCj1MYcx/1fJfk22fode58+QaN/f8XO9nzdtJ5TC9IjrkYud13L 4tchWfWLbyH7inUdU+R4rjRsfhnAv72loeSipC37hXO5e1zsviuxFGckGmoxFxUnAgAoQuTw 9QIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 17:38:05 -0000 I have some questions, mostly related to PA-AS-FRESHNESS-REQUEST: 1. Is this padata type needed at all? The only benefit I can see is that KDCs can omit PA-AS-FRESHNESS from the PREAUTH_REQUIRED hint list if the client doesn't support it, but that benefit vanishes as more clients support the new feature. 2. If it is needed, does it need to have a different padata type value from PA-AS-FRESHNESS? 3. The draft defines "PA-AS-FRESHNESS-REQUEST ::= NULL". Is the intent that the client will use a padata-value of 05 00 (an ASN.1 NULL value encoded in DER)? An empty padata-value would be more traditional and more compact. 4. The draft defines "PA-AS-FRESHNESS ::= OCTET STRING". Is it desirable to wrap the freshness token in a DER OCTET STRING tag, or could we just transmit the value directly within the padata-value? Of course the value still needs to have type OCTET STRING within the PKAuthenticator. 5. It looks like this mechanism is general enough to be used by other preauthentication mechanisms in the future, if they have similar requirements. Perhaps the RFC should explicitly call out that possibility. From nobody Sun Feb 1 13:49:30 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1E1A1AD3 for ; Sun, 1 Feb 2015 13:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DBusILonZSZX for ; Sun, 1 Feb 2015 13:49:25 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D371A1AC1 for ; Sun, 1 Feb 2015 13:49:24 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-39-54ce9f63275c 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 2B.5E.03354.36F9EC45; Sun, 1 Feb 2015 16:49:23 -0500 (EST) 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 t11LnH79016354; Sun, 1 Feb 2015 16:49:18 -0500 Received: from [18.101.8.94] (vpn-18-101-8-94.mit.edu [18.101.8.94]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t11LnF6f021481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 1 Feb 2015 16:49:17 -0500 Message-ID: <54CE9F5B.9070808@mit.edu> Date: Sun, 01 Feb 2015 16:49:15 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrZs8/1yIwfr3xhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRl/DSdaCNu6Kh7svsTYwTuPsYuTkkBAwkdi65gEThC0mceHe erYuRi4OIYHFTBIT7zxghXA2MEpcnrOeCcI5wCSx+tdhsBZeATWJ3mdfWEBsFgFVib3fT7CC 2GwCyhLr928FinNwiAqESZxvZoQoF5Q4OfMJWLmIgLHE3Z83WEBmCgvMZJToPNMMNlNIwFFi 2qVt7CA2p4CTRN+zRjYQm1lAT2LH9V+sELa8RPPW2cwTGAVmIZk7C0nZLCRlCxiZVzHKpuRW 6eYmZuYUpybrFicn5uWlFuma6OVmluilppRuYgSHpST/DsZvB5UOMQpwMCrx8P64ejZEiDWx rLgy9xCjJAeTkijvwv1AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8m+vOhQjxpiRWVqUW5cOk pDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwes8DahQsSk1PrUjLzClBSDNxcIIM5wEa HgBSw1tckJhbnJkOkT/FqCglzssPkhAASWSU5sH1wtLGK0ZxoFeEeRVBqniAKQeu+xXQYCag wcsmnQEZXJKIkJJqYDSLKcrr3TNpsuVu16hi+c6L9XOeLFd7+eD19+esRaWmJZd3zVvW0nV6 3p+YGIvUgyuqlfWVv064ld7F9yZjilJsiOThHv5M7+qEvMWVs5IE/hvFXGK4omq7anqbrKz7 hADP2pXK0x0WxMlUii8x7nDXf2uxWFAsxu7DZ5nHiv27Wz2V2l/cVWIpzkg01GIuKk4EANxQ 1yr2AgAA Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 21:49:27 -0000 On 01/20/2015 06:02 PM, Benjamin Kaduk wrote: > http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 I reviewed this and did not find any problems with it. > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 My only substantive note is that the InputStream/OutputStream forms of initSecContext/acceptSecContext could, perhaps, already write tokens to the outStream parameter before throwing an exception, instead of communicating them in the exception. If this issue has already been discussed, please ignore this remark. If not, I suspect it might be easier on callers (but perhaps harder on implementations) just to require that callers flush or otherwise handle content in the output stream after an exception. I do not have a strong interest in how this turns out, though. Some text was removed from the copyright notice about containing pre-2008 material. If this was intentional, please ignore this remark. In several places the draft uses the new text "to inform the reason for the error," which is not correct English. I suggest "to communicate the reason for the error." The section 5.2 table contains the pre-existing typo "Covert" for "Convert". I noticed because the table was reformatted; it may or may not be worth correcting. > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 I found a typo: "optionSHOULD" for "option SHOULD." From nobody Sun Feb 1 19:03:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430A1A9244 for ; Sun, 1 Feb 2015 19:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zymKDQlhli02 for ; Sun, 1 Feb 2015 19:03:16 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C711A9174 for ; Sun, 1 Feb 2015 19:03:16 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1233ErU007049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Feb 2015 03:03:15 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1233E8D006464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 03:03:14 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t1233DAd020278; Mon, 2 Feb 2015 03:03:13 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 01 Feb 2015 19:03:13 -0800 Message-ID: <54CEE8E5.5080701@oracle.com> Date: Mon, 02 Feb 2015 11:03:01 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Greg Hudson , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> In-Reply-To: <54CE9F5B.9070808@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 03:03:17 -0000 On 2/2/2015 5:49, Greg Hudson wrote: > On 01/20/2015 06:02 PM, Benjamin Kaduk wrote: >> http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 > > I reviewed this and did not find any problems with it. > >> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 > > My only substantive note is that the InputStream/OutputStream forms of > initSecContext/acceptSecContext could, perhaps, already write tokens to > the outStream parameter before throwing an exception, instead of > communicating them in the exception. If this issue has already been > discussed, please ignore this remark. If not, I suspect it might be > easier on callers (but perhaps harder on implementations) just to > require that callers flush or otherwise handle content in the output > stream after an exception. I do not have a strong interest in how this > turns out, though. The main reason I preferred the current design is to be consistent with the byte array forms of the methods, which gives the caller the chance to determine whether the error token should be sent or not. > > Some text was removed from the copyright notice about containing > pre-2008 material. If this was intentional, please ignore this remark. The whole Copyright Notice section is automatically generated by xml2rfc. I thought that paragraph is a standard part of every old RFC and the new format should override it. If not, I'll add it back (I'll have to figure out where to add it in the XML file). > > In several places the draft uses the new text "to inform the reason for > the error," which is not correct English. I suggest "to communicate the > reason for the error." OK. > > The section 5.2 table contains the pre-existing typo "Covert" for > "Convert". I noticed because the table was reformatted; it may or may > not be worth correcting. I've correct it. Thanks Weijun > >> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 > > I found a typo: "optionSHOULD" for "option SHOULD." > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Mon Feb 2 08:28:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94B11A8714 for ; Mon, 2 Feb 2015 08:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 beEiH8NxcHCL for ; Mon, 2 Feb 2015 08:28:42 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C571A1A7009 for ; Mon, 2 Feb 2015 08:28:40 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-b8-54cfa5b6a4cb 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 97.C8.03354.6B5AFC45; Mon, 2 Feb 2015 11:28:38 -0500 (EST) 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 t12GScmj009192; Mon, 2 Feb 2015 11:28:38 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t12GSamW007314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Feb 2015 11:28:37 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t12GSaFN015726; Mon, 2 Feb 2015 11:28:36 -0500 (EST) Date: Mon, 2 Feb 2015 11:28:35 -0500 (EST) From: Benjamin Kaduk To: Weijun Wang In-Reply-To: <54CEE8E5.5080701@oracle.com> Message-ID: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrbtt6fkQg93/zCyObl7FYvF16QZm ByaPJUt+Mnl8fHqLJYApissmJTUnsyy1SN8ugStj3uPvzAUdHBVXZ31lbWA8ztbFyMkhIWAi 0X7jLiuELSZx4d56sLiQwGImiROHyiHsDYwSLVsDIeyDTBK/JiZB2PUSZw6vYwexWQS0JE7M 3M0CYrMJqEjMfLMRbI6IgIZEw4MmZhCbWUBYYv25GUA2F4ewwExGic4zzUwgCU6g5nN3TjN2 MXJw8Ao4SrRcMIeYXyWx/G0H2ExRAR2J1fungNm8AoISJ2c+YYGYqSWxfPo2lgmMgrOQpGYh SS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRHKSS/DsYvx1UOsQowMGo xMM74eO5ECHWxLLiytxDjJIcTEqivOsXnQ8R4kvKT6nMSCzOiC8qzUktPsQowcGsJMLrNw0o x5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwft8CVCjYFFqempFWmZO CUKaiYMTZDgP0PB7IDW8xQWJucWZ6RD5U4y6HJdeHprJJMSSl5+XKiXO+xSkSACkKKM0D24O LLm8YhQHekuYVxiYaoR4gIkJbtIroCVMQEuWTToDsqQkESEl1cA4sS+vnu3m3g+ax02Wf3c/ 4z81mf3dO49Zd7aHqCmV3FZfYdWf93xDrn+93SOOzrtbDLuyyhbMerBe3fvVbe2tL3VLJFRM ZLWn/9un8/+aq77t57pzkoy+DRvlcy45rd0qOPdpg83La1MF7VhVc436NhUe2vFhzrNV//h/ MXec2M19wuxPyMqTSizFGYmGWsxFxYkAnwJfrwkDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:28:43 -0000 On Sun, 1 Feb 2015, Weijun Wang wrote: > > > On 2/2/2015 5:49, Greg Hudson wrote: > > On 01/20/2015 06:02 PM, Benjamin Kaduk wrote: > > > > > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 > > > > > > Some text was removed from the copyright notice about containing > > pre-2008 material. If this was intentional, please ignore this remark. > > The whole Copyright Notice section is automatically generated by xml2rfc. I > thought that paragraph is a standard part of every old RFC and the new format > should override it. If not, I'll add it back (I'll have to figure out where to > add it in the XML file). I believe this is the 'ipr' attribute of the tag at the beginning of the document, per https://tools.ietf.org/html/rfc2629#section-2.2.7.1 -- unfortunately, that RFC does not document all the possible values listed in the DTD, and the DTD itself (http://www.w3.org/2008/xmlsec/Drafts/algorithms-rfc/rfc2629.dtd ?) doesn't offer much guidance about what each value does. -Ben From nobody Mon Feb 2 09:28:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9411A877A for ; Mon, 2 Feb 2015 09:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 BL9QTz7Oj55D for ; Mon, 2 Feb 2015 09:28:44 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31181A8777 for ; Mon, 2 Feb 2015 09:28:43 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id q108so48420553qgd.0 for ; Mon, 02 Feb 2015 09:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9W0BCNGpei0MlvaPvXd+qbx9wsXpLETOh8bTqkzTYbs=; b=Ix7yZrQaQ+OoCuck9S00Fib29h61ySIn9/4Ze27my2qJZqYQftUJTiWG9gL7ZP2L9+ NRXOy3SN60Rl4tn4m1k1rNiY/yw/1yoTHAD/FsztBGgpbeqHAJpCkCP1wUMtyrEmLR1+ 3bVCx1cGt/EmiHGnm/wO29hF7R2bQveEeBem49I2JwfPIyvt9JKMAghPUCUGB3DelbAk HDcd7D0yVL8Gf8KvJLHS3Dfh6jg+CNlRNP7+/0mjCnc+QHY41iHNRUcjiwY2V5rNsZ1L LCwM6w5/gIlt/xaKerC4+fxNvqOn6F+jB9GfOJ0YvTdccplrDdem2rafjVgqEjnY+9dp JoRQ== MIME-Version: 1.0 X-Received: by 10.140.48.67 with SMTP id n61mr40291160qga.82.1422898122858; Mon, 02 Feb 2015 09:28:42 -0800 (PST) Received: by 10.229.39.131 with HTTP; Mon, 2 Feb 2015 09:28:42 -0800 (PST) In-Reply-To: <20140930141040.271b6205@willson.usersys.redhat.com> References: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> <20140930141040.271b6205@willson.usersys.redhat.com> Date: Mon, 2 Feb 2015 12:28:42 -0500 Message-ID: From: Michael Jenkins To: Simo Sorce Content-Type: multipart/alternative; boundary=001a113519c42a249e050e1e4997 Archived-At: Cc: kitten@ietf.org, "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:28:46 -0000 --001a113519c42a249e050e1e4997 Content-Type: text/plain; charset=UTF-8 Simo, As I understand it (I inherited this draft from Kelley Burgin), the answer is essentially because this work was submitted as a precursor to a "Using Kerberos in a Suite B compliant manner" draft (which will be submitted as an independent informational draft). [For the discussion of why this draft is a kitten work item, you'd have to look at the archive.] As such, the encryption and hash algorithm sizes are determined by the Suite B requirements. That said, the Suite B requirements were tuned to match what seemed to becoming commonly available at the time, particularly in terms of accelerated AES. So, for instance, SHA-384 is matched to AES-256, because AES-256 had a hardware accelerated implementation. Once this pair was selected as a Suite B level of security, it seemed reasonable to simply use them as much as possible (and, for example, truncate the hash results) than to require lots of other sizes as well. [Again, as this was inherited work, I'm working from received lore.] *That* said, there's nothing particularly Suite B about this (the enc-type) draft, or needn't be, so I'd rather put the above seminal explanation in the document than say "because Suite B". I propose that the following paragraph be added to the Security Considerations section (8) to address the entire document, rather than to litter the document with in-place explanations: 8.2 Algorithm dimensions Although there is nothing in this document that constrains its application, it has been written to be consistent with common implementations of AES and SHA-2. The encryption and hash algorithm sizes have been chosen to create a consistent level of protection, with consideration to implementation efficiencies. So, for instance, SHA-384, which would normally be matched to AES-192, is instead matched to AES-256 to leverage the fact that there are efficient hardware implementations of AES-256. Would this suffice? If so, I'll generate an -06 version and upload it in time for Dallas. Mike Jenkins NSA mjjenki@tycho.ncsc.mil / m.jenkins.364706@gmail.com official email / read-everywhere email - feel free to include both On Tue, Sep 30, 2014 at 2:10 PM, Simo Sorce wrote: > On Tue, 23 Sep 2014 05:25:46 -0700 > internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Common Authentication > > Technology Next Generation Working Group of the IETF. > > > > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > > Authors : Michael J. Jenkins > > Michael A. Peck > > Kelley W. Burgin > > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-05.txt > > Hi while reading this otherwise very nice specification two questions > kept popping in my mind. > > Why SHA-512 is not being used ? > Why AES-192 is not being used and SHA-384 is paired with AES-256 > instead ? > Why are you using a hash twice the size of the bit strength required, > and chop it off, isn't HMAC supposedly not affected by birthday > attacks ? > > I can guess at the rationale of some of these choices (some of it was > discussed in IETF meetings/lists), but it would be nice to have a > section that explains the choice or even just a reference to some other > document that does. > > Regards, > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- Mike Jenkins mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk m.jenkins.364706@gmail.com - to read everywhere else 443-634-3951 --001a113519c42a249e050e1e4997 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simo,

As I understand it (I inherit= ed this draft from Kelley Burgin), the answer is essentially because this w= ork was submitted as a precursor to a "Using Kerberos in a Suite B com= pliant manner" draft (which will be submitted as an independent inform= ational draft). [For the discussion of why this draft is a kitten work item= , you'd have to look at the archive.] As such, the encryption and hash = algorithm sizes are determined by the Suite B requirements.

That sai= d, the Suite B requirements were tuned to match what seemed to becoming com= monly available at the time, particularly in terms of accelerated AES. So, = for instance, SHA-384 is matched to AES-256, because AES-256 had a hardware= accelerated implementation. Once this pair was selected as a Suite B level= of security, it seemed reasonable to simply use them as much as possible (= and, for example, truncate the hash results) than to require lots of other = sizes as well. [Again, as this was inherited work, I'm working from rec= eived lore.]

*That* said, there's nothing particularly Sui= te B about this (the enc-type) draft, or needn't be, so I'd rather = put the above seminal explanation in the document than say "because Su= ite B". I propose that the following paragraph be added to the Securit= y Considerations section (8) to address the entire document, rather than to= litter the document with in-place explanations:

8.2=C2=A0= =C2=A0=C2=A0 Algorithm dimensions

Although there is nothing in this= =20 document that=20 constrains its application, it has been written to be consistent with=20 common implementations of AES and SHA-2. The=C2=A0 encryption and hash=20 algorithm sizes have been chosen to create a consistent level of=20 protection, with consideration to implementation efficiencies. So, for=20 instance, SHA-384, which would normally be matched to AES-192, is=20 instead matched to AES-256 to leverage the fact that there are efficient hardware=20 implementations of AES-256.

Would this suffice? If so, I&= #39;ll generate an -06 version and upload it in time for Dallas.

Mik= e Jenkins
NSA
official email / read= -everywhere email - feel free to include both

On Tue, Sep 30, 2014 at 2= :10 PM, Simo Sorce <simo@redhat.com> wrote:
On Tue, 23 Sep 2014 05:25:46 -0700
internet-drafts@ietf.org wr= ote:

>
> 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 Working Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: AES Encryption with HMAC-SHA2 for Kerberos 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Michael J. Jenkins
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Michael A. Peck
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Kelley W. Burgin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-kitten-aes-cts-hmac-sha2-05.txt

Hi while reading this otherwise very nice specification two question= s
kept popping in my mind.

Why SHA-512 is not being used ?
Why AES-192 is not being used and SHA-384 is paired with AES-256
instead ?
Why are you using a hash twice the size of the bit strength required,
and chop it off, isn't HMAC supposedly not affected by birthday
attacks ?

I can guess at the rationale of some of these choices (some of it was
discussed in IETF meetings/lists), but it would be nice to have a
section that explains the choice or even just a reference to some other
document that does.

Regards,
Simo.

--
Simo Sorce * Red Hat, Inc * New York

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



--
Mike Jenkins
mjjenki@tycho.ncsc.mil - if= you want me to read it only at my desk
m.jenkins.364706@gmail.com - to r= ead everywhere else
443-634-3951
--001a113519c42a249e050e1e4997-- From nobody Mon Feb 2 17:52:06 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B9B1A1A68 for ; Mon, 2 Feb 2015 17:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 B1dEUMROrBHF for ; Mon, 2 Feb 2015 17:52:04 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F255C1A1A4C for ; Mon, 2 Feb 2015 17:52:03 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t131q2mS006866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Feb 2015 01:52:03 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t131q1gB013446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2015 01:52:02 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t131q0tp008058; Tue, 3 Feb 2015 01:52:01 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Feb 2015 17:52:00 -0800 Message-ID: <54D029B3.3050003@oracle.com> Date: Tue, 03 Feb 2015 09:51:47 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 01:52:05 -0000 But the xml2rfc tool claims No boilerplate text available for ipr: 'full2026'. Acceptable values are: trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902, trust200811, noModificationTrust200811, noDerivativesTrust200811 I decide to choose "pre5378Trust200902". The output text is almost identical to that of RFC 5653, but adding these lines which I think is harmless Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Thanks Max On 2/3/2015 0:28, Benjamin Kaduk wrote: > I believe this is the 'ipr' attribute of the tag at the beginning of > the document, perhttps://tools.ietf.org/html/rfc2629#section-2.2.7.1 -- > unfortunately, that RFC does not document all the possible values listed > in the DTD, and the DTD itself > (http://www.w3.org/2008/xmlsec/Drafts/algorithms-rfc/rfc2629.dtd ?) > doesn't offer much guidance about what each value does. From nobody Tue Feb 3 10:35:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329AF1A1BF5 for ; Tue, 3 Feb 2015 10:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SZ-x14UqOoFa for ; Tue, 3 Feb 2015 10:35:48 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33401A1ADF for ; Tue, 3 Feb 2015 10:35:47 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-34-54d1150250fc 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 51.9E.03365.20511D45; Tue, 3 Feb 2015 13:35:46 -0500 (EST) 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 t13IZjQp023382; Tue, 3 Feb 2015 13:35:45 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t13IZgs2011430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 13:35:44 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t13IZg7M003520; Tue, 3 Feb 2015 13:35:42 -0500 (EST) Date: Tue, 3 Feb 2015 13:35:41 -0500 (EST) From: Benjamin Kaduk To: Michael Jenkins In-Reply-To: Message-ID: References: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> <20140930141040.271b6205@willson.usersys.redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrMskejHE4OQyBYujm1exWCz7dpXN YuP7U4wWP+YuYnVg8dg56y67x5IlP5k83u+7yuaxtfkfYwBLFJdNSmpOZllqkb5dAlfGzrcn 2AqucVXcOdfH1MB4jKOLkYNDQsBE4tCh/C5GTiBTTOLCvfVsILaQwGImiY5Nhl2MXED2BkaJ 3WunskMkDjJJnF8EZddLNPxvYgeZwyKgJfHzdQRImE1ARWLmm41gc0QEDCQWTVoHZjML5Eo8 65vODFIuLOAn8eFvJkiYUyBQ4sPJqawgNq+Ao0THnutsEGt3M0ocW3yFBSQhKqAjsXr/FBaI IkGJkzOfsEDM1JJYPn0bywRGwVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdfL zSzRS00p3cQICmV2F5UdjM2HlA4xCnAwKvHwOihdCBFiTSwrrsw9xCjJwaQkypshfDFEiC8p P6UyI7E4I76oNCe1+BCjBAezkgjvnt9A5bwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NT C1KLYLIyHBxKErxOIEMFi1LTUyvSMnNKENJMHJwgw3mAhj8CqeEtLkjMLc5Mh8ifYlSUEudd C5IQAElklObB9cJSzStGcaBXhHm1RYCqeIBpCq77FdBgJqDBshdBri4uSURISTUwhu74siVM 1qFq3/WvjvsuFyfOazpdUjcjcI0lg+8Gtm/mvtsVPs578GJdv3K577Zrvd3Xirl+77a+8fLu 4o7tJ6sT12/x0VM72Lh12tyOviaN1eqmlWwyizIuumWVXuL73Hv839zpy69Y71iUWvVM18Dc TOvm+vWn3kStiPqd4iL57M6EMuvFGkosxRmJhlrMRcWJAM059BkQAwAA Archived-At: Cc: kitten@ietf.org, "mjjenki@tycho.ncsc.mil" , Simo Sorce Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 18:35:50 -0000 On Mon, 2 Feb 2015, Michael Jenkins wrote: > the document than say "because Suite B". I propose that the following > paragraph be added to the Security Considerations section (8) to address > the entire document, rather than to litter the document with in-place > explanations: > > 8.2 Algorithm dimensions > > Although there is nothing in this document that constrains its application, It's not entirely clear what "constraints its application" is intended to mean here; I would prefer an alternate phrasing. > it has been written to be consistent with common implementations of AES and > SHA-2. The encryption and hash algorithm sizes have been chosen to create > a consistent level of protection, with consideration to implementation > efficiencies. So, for instance, SHA-384, which would normally be matched to > AES-192, is instead matched to AES-256 to leverage the fact that there are > efficient hardware implementations of AES-256. I wonder if there is a way to say that the combination of SHA-384 and AES-256 as used in this document "only has 192 bits of security" (to the extent that the concept of bits of security can even be defined). > Would this suffice? If so, I'll generate an -06 version and upload it in > time for Dallas. That would be fine for me, but let's give Simo some time to reply as well. -Ben From nobody Tue Feb 3 19:04:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13FB1A1BBD for ; Tue, 3 Feb 2015 19:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 3MzcV5cc1YM6 for ; Tue, 3 Feb 2015 19:04:23 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A1B1A1BA9 for ; Tue, 3 Feb 2015 19:04:22 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id s11so38803864qcv.2 for ; Tue, 03 Feb 2015 19:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fJcO8WHIGylVMhTNv6B4xCJolp2lVgUB2tSQ3IZgJWk=; b=KvNcGgMAaobvo7WAHexfH5FL0GzygFc7bdprPmdJx5DYGSog+zaTlPCad5kdmWhGgr 5lR9s2WcNDC+P9hdAagpabc76B6kIhJg9/A4j2Vx+aXzmprWtQ1Hn6xdusc085bcZr+I 0aLuGZIX6wzeHR4/s1GFUYhRkDVGUPGTRVU/cOPsvm9W3F2WrSKPKhzK1LSz079Qux7p qfg2Xp6Qs9ZgZbPbYw71BPbOW1v/ozM8tZ2LEaWML7tBLy99eKg6/WFETKbCWTFETZlB C5w0pj9wTTQg79SZOrsk0AMWRIKfmAqvla4LS5Y6C9qlSf+wHQxku6+Eq4eJ/oieFUjj WT6g== MIME-Version: 1.0 X-Received: by 10.224.96.130 with SMTP id h2mr59493560qan.85.1423019061972; Tue, 03 Feb 2015 19:04:21 -0800 (PST) Received: by 10.229.177.133 with HTTP; Tue, 3 Feb 2015 19:04:21 -0800 (PST) In-Reply-To: References: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> <20140930141040.271b6205@willson.usersys.redhat.com> Date: Tue, 3 Feb 2015 22:04:21 -0500 Message-ID: From: Michael Jenkins To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11c34fa6b295d8050e3a7179 Archived-At: Cc: kitten@ietf.org, "mjjenki@tycho.ncsc.mil" , Simo Sorce Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 03:04:25 -0000 --001a11c34fa6b295d8050e3a7179 Content-Type: text/plain; charset=UTF-8 The "constrains its application" made more sense in the original (unposted) version of this paragraph that explicitly mentioned Suite B, before I convinced myself that it was unnecessary (that it can be left for the informational Suite B document). While I don't think you'd have to be running a Suite B complaint installation for this document to be useful, it is fair to say that the choices of hash and encryption sizes are constraints. I would prefer to eliminate the initial clause than try to rewrite it. So, the paragraph would start with, "This document has been written to be consistent..." As to the 192 bits of security, again this made more sense originally when I had text about the Suite B 192-bit level of security. Perhaps a final sentence, "Note that, as indicated by the enc-type name "aes256-cts-hmac-sha384-192", the use of SHA-384 and AES-256 with a 192-bit key provides only a 192-bit level of security." [There's a NIST special pub under development (says their 2012 Annual Report) that talks about what-you-get-from-what-you-used, but I'm not sure when it might be available.] The resulting paragraph would read: This document has been written to be consistent with common implementations of AES and SHA-2. The encryption and hash algorithm sizes have been chosen to create a consistent level of protection, with consideration to implementation efficiencies. So, for instance, SHA-384, which would normally be matched to AES-192, is instead matched to AES-256 to leverage the fact that there are efficient hardware implementations of AES-256. Note that, as indicated by the enc-type name "aes256-cts-hmac-sha384-192", the use of SHA-384 and AES-256 with a 192-bit key provides only a 192-bit level of security. On Tue, Feb 3, 2015 at 1:35 PM, Benjamin Kaduk wrote: > On Mon, 2 Feb 2015, Michael Jenkins wrote: > > > the document than say "because Suite B". I propose that the following > > paragraph be added to the Security Considerations section (8) to address > > the entire document, rather than to litter the document with in-place > > explanations: > > > > 8.2 Algorithm dimensions > > > > Although there is nothing in this document that constrains its > application, > > It's not entirely clear what "constraints its application" is intended to > mean here; I would prefer an alternate phrasing. > > > it has been written to be consistent with common implementations of AES > and > > SHA-2. The encryption and hash algorithm sizes have been chosen to > create > > a consistent level of protection, with consideration to implementation > > efficiencies. So, for instance, SHA-384, which would normally be matched > to > > AES-192, is instead matched to AES-256 to leverage the fact that there > are > > efficient hardware implementations of AES-256. > > I wonder if there is a way to say that the combination of SHA-384 and > AES-256 as used in this document "only has 192 bits of security" (to the > extent that the concept of bits of security can even be defined). > > > Would this suffice? If so, I'll generate an -06 version and upload it in > > time for Dallas. > > That would be fine for me, but let's give Simo some time to reply as well. > > -Ben > -- Mike Jenkins mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk m.jenkins.364706@gmail.com - to read everywhere else 443-634-3951 --001a11c34fa6b295d8050e3a7179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The "constrains its application" made more sense= in the original (unposted) version of this paragraph that explicitly menti= oned Suite B, before I convinced myself that it was unnecessary (that it ca= n be left for the informational Suite B document). While I don't think = you'd have to be running a Suite B complaint installation for this docu= ment to be useful, it is fair to say that the choices of hash and encryptio= n sizes are constraints. I would prefer to eliminate the initial clause tha= n try to rewrite it. So, the paragraph would start with, "This documen= t has been written to be consistent..."

As to the 1= 92 bits of security, again this made more sense originally when I had text = about the Suite B 192-bit level of security. Perhaps a final sentence, &quo= t;Note that, as indicated by the enc-type name "aes256-cts-hmac-sha384= -192", the use of SHA-384 and AES-256 with a 192-bit key provides only= a 192-bit level of security." [There's a NIST special pub under d= evelopment (says their 2012 Annual Report) that talks about what-you-get-fr= om-what-you-used, but I'm not sure when it might be available.]

The resulting paragraph would read:

This document has been written to be consistent with common implementati= ons of AES and SHA-2. The =C2=A0encryption and hash algorithm sizes have be= en chosen to create a consistent level of protection, with consideration to= implementation efficiencies. So, for instance, SHA-384, which would normal= ly be matched to AES-192, is instead matched to AES-256 to leverage the fac= t that there are efficient hardware implementations of AES-256.=C2=A0Note t= hat, as indicated by the enc-type name "aes256-cts-hmac-sha384-192&quo= t;, the use of SHA-384 and=C2=A0AES-256 with a 192-bit key provides only a = 192-bit level of security.

<= br>
On Tue, Feb 3, 2015 at 1:35 PM, Benjamin Kadu= k <= kaduk@mit.edu> wrote:
On= Mon, 2 Feb 2015, Michael Jenkins wrote:

> the document than say "because Suite B". I propose that the = following
> paragraph be added to the Security Considerations section (8) to addre= ss
> the entire document, rather than to litter the document with in-place<= br> > explanations:
>
> 8.2=C2=A0 =C2=A0 Algorithm dimensions
>
> Although there is nothing in this document that constrains its applica= tion,

It's not entirely clear what "constraints its application&q= uot; is intended to
mean here; I would prefer an alternate phrasing.

> it has been written to be consistent with common implementations of AE= S and
> SHA-2. The=C2=A0 encryption and hash algorithm sizes have been chosen = to create
> a consistent level of protection, with consideration to implementation=
> efficiencies. So, for instance, SHA-384, which would normally be match= ed to
> AES-192, is instead matched to AES-256 to leverage the fact that there= are
> efficient hardware implementations of AES-256.

I wonder if there is a way to say that the combination of SHA-384 an= d
AES-256 as used in this document "only has 192 bits of security" = (to the
extent that the concept of bits of security can even be defined).

> Would this suffice? If so, I'll generate an -06 version and upload= it in
> time for Dallas.

That would be fine for me, but let's give Simo some time to repl= y as well.

-Ben



--
Mike Jenkins
mjjenki@tycho.ncsc.mil - if= you want me to read it only at my desk
m.jenkins.364706@gmail.com - to r= ead everywhere else
443-634-3951
--001a11c34fa6b295d8050e3a7179-- From nobody Tue Feb 3 21:15:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A671A1BE4 for ; Tue, 3 Feb 2015 21:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mHthqyeZi7sw for ; Tue, 3 Feb 2015 21:15:14 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44821A1AB2 for ; Tue, 3 Feb 2015 21:15:11 -0800 (PST) X-AuditID: 12074423-f797b6d000000cfe-18-54d1aade28f5 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 42.63.03326.EDAA1D45; Wed, 4 Feb 2015 00:15:10 -0500 (EST) 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 t145F9NN002624 for ; Wed, 4 Feb 2015 00:15:10 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t145F83L010402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Feb 2015 00:15:09 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t145F7f5025192; Wed, 4 Feb 2015 00:15:07 -0500 (EST) Date: Wed, 4 Feb 2015 00:15:07 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixG6nrntv1cUQg8NLVCyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLt9dxgLZgpWzLl9i62BcSJfFyMnh4SAicSzO3PZIWwxiQv3 1rN1MXJxCAksZpJoPHaFCcI5xiix8eVbKOc6k8Tjay/ZQFqEBOolzn/YzAJiswhoSdw/egbM ZhNQkZj5ZiNYjYiAsMTure+YQZqFBWYySnSeaQaaxMHBKeAk8awrCqSGV8BRomNaEyPEzHKJ nVd+s4LYogI6Eqv3T2GBqBGUODnzCZjNDLRr+fRtLBMYBWYhSc1CklrAyLSKUTYlt0o3NzEz pzg1Wbc4OTEvL7VI10wvN7NELzWldBMjOPxclHcw/jmodIhRgINRiYdXIP9iiBBrYllxZe4h RkkOJiVR3r4FQCG+pPyUyozE4oz4otKc1OJDjBIczEoivIvnAeV4UxIrq1KL8mFS0hwsSuK8 m37whQgJpCeWpGanphakFsFkZTg4lCR4WYFxJiRYlJqeWpGWmVOCkGbi4AQZzgM0/N5KkOHF BYm5xZnpEPlTjIpS4rz9IAkBkERGaR5cLyw9vGIUB3pFmHcbSBUPMLXAdb8CGswENFj24gWQ wSWJCCmpBsZb5VedIgplm02zs7a1zm4+Yqd9o0Vu2yE//5n6bIGxjc/2Gv/uLbLntz42+b0p U+ufX9fn/C2SXJw9PXLBtmyVBD1PD86KvRs+zl2X07zy/6JDJ+e/Sp9ZravA/5Vv1/epc27+ 29ZTuTFTP+zUX9a2c/EPeJp4p7T+XDpx5pcYZpt361pN395TYinOSDTUYi4qTgQA87KyAOoC AAA= Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:15:16 -0000 Just a reminder: two weeks remain in this WGLC period. -Ben On Thu, 29 Jan 2015, Benjamin Kaduk wrote: > Just under three weeks remain in this WGLC period. > > -Ben > > On Tue, 20 Jan 2015, Benjamin Kaduk wrote: > > > This message begins the Working Group Last Call (WGLC) for the following > > three documents: "A Pseudo-Random Function (PRF) for the Kerberos V > > Generic Security Service Application Program Interface (GSS-API) > > Mechanism" , "Generic Security Service > > API Version 2: Java Bindings Update" , > > and "Anonymity Support for Kerberos" . > > Because there are three documents under review, and the whole body of the > > documents are up for re-review (not just the updates), the WGLC is > > extended to four weeks, so the WGLC will end on Tuesday February 17th, > > 2015. The drafts are available at: > > > > http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 > > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 > > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 > > > > Please review these documents and send comments to the Working Group > > mailing list kitten@ietf.org or the co-chairs > > before the end of the WGLC. Any and all > > comments on the document(s) are sought in order to assess the strength of > > consensus. Even if you have read and commented on this or earlier > > versions of the draft, please feel free to comment again. This is > > particularly important if you found issues with the previous version. > > > > As a reminder, comments can be anything from "this looks fine" to "this is > > a horrible idea"; they can include suggestions for minor editorial > > corrections to significant editorial changes. > > > > > > - Your Kitten Chairs > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Tue Feb 3 23:48:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD921A6F2D for ; Tue, 3 Feb 2015 23:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 u89qp7jY5Sch for ; Tue, 3 Feb 2015 23:48:06 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA941A6F2B for ; Tue, 3 Feb 2015 23:48:05 -0800 (PST) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t147m2c8001747; Wed, 4 Feb 2015 02:48:02 -0500 Date: Wed, 4 Feb 2015 02:48:02 -0500 (EST) From: Simo Sorce To: Michael Jenkins Message-ID: <1218923415.6402079.1423036082480.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> <20140930141040.271b6205@willson.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF35 (Linux)/8.0.6_GA_5922) Thread-Topic: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt Thread-Index: Pb9YKLXVN3Tbk41bq78YWXsfmFslmQ== Archived-At: Cc: kitten@ietf.org, mjjenki@tycho.ncsc.mil, Simo Sorce Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 07:48:08 -0000 ----- Original Message ----- > From: "Michael Jenkins" > To: "Benjamin Kaduk" > Cc: "Simo Sorce" , kitten@ietf.org, mjjenki@tycho.ncsc.mil > Sent: Tuesday, February 3, 2015 10:04:21 PM > Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt > > The "constrains its application" made more sense in the original (unposted) > version of this paragraph that explicitly mentioned Suite B, before I > convinced myself that it was unnecessary (that it can be left for the > informational Suite B document). While I don't think you'd have to be > running a Suite B complaint installation for this document to be useful, it > is fair to say that the choices of hash and encryption sizes are > constraints. I would prefer to eliminate the initial clause than try to > rewrite it. So, the paragraph would start with, "This document has been > written to be consistent..." > > As to the 192 bits of security, again this made more sense originally when > I had text about the Suite B 192-bit level of security. Perhaps a final > sentence, "Note that, as indicated by the enc-type name > "aes256-cts-hmac-sha384-192", the use of SHA-384 and AES-256 with a 192-bit > key provides only a 192-bit level of security." [There's a NIST special pub > under development (says their 2012 Annual Report) that talks about > what-you-get-from-what-you-used, but I'm not sure when it might be > available.] > > The resulting paragraph would read: > > This document has been written to be consistent with common implementations > of AES and SHA-2. The encryption and hash algorithm sizes have been chosen > to create a consistent level of protection, with consideration to > implementation efficiencies. So, for instance, SHA-384, which would > normally be matched to AES-192, is instead matched to AES-256 to leverage > the fact that there are efficient hardware implementations of AES-256. Note > that, as indicated by the enc-type name "aes256-cts-hmac-sha384-192", the > use of SHA-384 and AES-256 with a 192-bit key provides only a 192-bit level > of security. Michael, thank you for the explanation. I think this wording (and this archived discussion), is sufficient to clear most of my questions and gives enough hints to understand the logic behind these choices. Regards, Simo. > On Tue, Feb 3, 2015 at 1:35 PM, Benjamin Kaduk wrote: > > > On Mon, 2 Feb 2015, Michael Jenkins wrote: > > > > > the document than say "because Suite B". I propose that the following > > > paragraph be added to the Security Considerations section (8) to address > > > the entire document, rather than to litter the document with in-place > > > explanations: > > > > > > 8.2 Algorithm dimensions > > > > > > Although there is nothing in this document that constrains its > > application, > > > > It's not entirely clear what "constraints its application" is intended to > > mean here; I would prefer an alternate phrasing. > > > > > it has been written to be consistent with common implementations of AES > > and > > > SHA-2. The encryption and hash algorithm sizes have been chosen to > > create > > > a consistent level of protection, with consideration to implementation > > > efficiencies. So, for instance, SHA-384, which would normally be matched > > to > > > AES-192, is instead matched to AES-256 to leverage the fact that there > > are > > > efficient hardware implementations of AES-256. > > > > I wonder if there is a way to say that the combination of SHA-384 and > > AES-256 as used in this document "only has 192 bits of security" (to the > > extent that the concept of bits of security can even be defined). > > > > > Would this suffice? If so, I'll generate an -06 version and upload it in > > > time for Dallas. > > > > That would be fine for me, but let's give Simo some time to reply as well. > > > > -Ben > > > > > > -- > Mike Jenkins > mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk > m.jenkins.364706@gmail.com - to read everywhere else > 443-634-3951 > From nobody Wed Feb 4 21:15:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B507A1A01AE for ; Wed, 4 Feb 2015 21:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 h03PJZGXa4N1 for ; Wed, 4 Feb 2015 21:14:59 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB85D1A020D for ; Wed, 4 Feb 2015 21:14:57 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-62-54d2fc50aca6 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 E1.33.03326.05CF2D45; Thu, 5 Feb 2015 00:14:56 -0500 (EST) 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 t155Etjr026045; Thu, 5 Feb 2015 00:14:56 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t155ErSs013192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Feb 2015 00:14:55 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t155Er5k025299; Thu, 5 Feb 2015 00:14:53 -0500 (EST) Date: Thu, 5 Feb 2015 00:14:53 -0500 (EST) From: Benjamin Kaduk To: Weijun Wang In-Reply-To: <54D029B3.3050003@oracle.com> Message-ID: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D029B3.3050003@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrRvw51KIwaef4hZHN69isfi6dAOz A5PHkiU/mTw+Pr3FEsAUxWWTkpqTWZZapG+XwJVx7/Qb1oJH7BVfZ39kbmCcx9bFyMkhIWAi se33FWYIW0ziwr31QHEuDiGBxUwS65+sZAFJCAlsYJS4csECInGQSWLquVOsEIl6ib1b/oEV sQhoSTyZ9BdsKpuAisTMNxvBbBEBDYmGB01gG5gFhCXWn5vBDDJIWGAmo0TnmWamLkZ2Dk6g 5o8WICW8Ag4SKyc8Y4fYdY5R4m7nfrA5ogI6Eqv3T2GBKBKUODnzCQvETC2J5dO3sUxgFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2M4ECV5N3B+O6g0iFG AQ5GJR7eB7svhQixJpYVV+YeYpTkYFIS5d38AyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhNf3 LVCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCd88voEbBotT01Iq0 zJwShDQTByfIcB6g4b9AaniLCxJzizPTIfKnGHU5FrTvn8kkxJKXn5cqJc77FKRIAKQoozQP bg4swbxiFAd6S5hX8zdQFQ8wOcFNegW0hAloiezFCyBLShIRUlINjEsX3V+39eZWFcGNYfKL NrOEfjXTFX95ZoKP1743J9nuyt6dcsnp4pID99elhL5qi/IpvOk4+Xhzm4bPIyE9r1lHM3e8 thAyS1GUZJom4i252yQtwHBlv/mk45f4P+efONxsJHLwyTdOkQlPVVb/+bPq3BaHWZy59o2z D/pynVZaEp/afPV5sLwSS3FGoqEWc1FxIgDZlHNYCwMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:15:05 -0000 On Mon, 2 Feb 2015, Weijun Wang wrote: > But the xml2rfc tool claims > > No boilerplate text available for ipr: 'full2026'. Acceptable values are: > trust200902, noModificationTrust200902, noDerivativesTrust200902, > pre5378Trust200902, trust200811, noModificationTrust200811, > noDerivativesTrust200811 The standalone tool for local use, or http://xml2rfc.ietf.org/ ? I think that at least at one point, they had slightly different behavior. > I decide to choose "pre5378Trust200902". The output text is almost identical > to that of RFC 5653, but adding these lines which I think is harmless > > Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. That may be good enough; we can call out the difference in the shepherd report and/or RFC Editor note if needed. -Ben From nobody Wed Feb 4 21:17:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4571A1A38 for ; Wed, 4 Feb 2015 21:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Vm5gTShqIIgD for ; Wed, 4 Feb 2015 21:17:19 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF331A01AE for ; Wed, 4 Feb 2015 21:17:18 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t155HH1f000837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 05:17:18 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t155HG7W022766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Feb 2015 05:17:17 GMT Received: from ubhmt112.oracle.com (ubhmt112.oracle.com [156.151.24.17]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t155HGIA026527; Thu, 5 Feb 2015 05:17:16 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Feb 2015 21:17:16 -0800 Message-ID: <54D2FCD5.6060404@oracle.com> Date: Thu, 05 Feb 2015 13:17:09 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Greg Hudson , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> In-Reply-To: <54CEE8E5.5080701@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:17:20 -0000 Hi Greg On 2/2/2015 11:03, Weijun Wang wrote: >>> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 >> >> My only substantive note is that the InputStream/OutputStream forms of >> initSecContext/acceptSecContext could, perhaps, already write tokens to >> the outStream parameter before throwing an exception, instead of >> communicating them in the exception. If this issue has already been >> discussed, please ignore this remark. If not, I suspect it might be >> easier on callers (but perhaps harder on implementations) just to >> require that callers flush or otherwise handle content in the output >> stream after an exception. I do not have a strong interest in how this >> turns out, though. > > The main reason I preferred the current design is to be consistent with > the byte array forms of the methods, which gives the caller the chance > to determine whether the error token should be sent or not. Are you OK with this reason? Thanks Weijun From nobody Wed Feb 4 21:35:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03B11A01D6 for ; Wed, 4 Feb 2015 21:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 smkLXiELxFFx for ; Wed, 4 Feb 2015 21:35:50 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9321A0072 for ; Wed, 4 Feb 2015 21:35:50 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t155ZnkR016614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 05:35:49 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t155ZmTN007247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 05:35:49 GMT Received: from ubhmt106.oracle.com (ubhmt106.oracle.com [156.151.24.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t155ZmfZ007619; Thu, 5 Feb 2015 05:35:48 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Feb 2015 21:35:47 -0800 Message-ID: <54D30130.6040707@oracle.com> Date: Thu, 05 Feb 2015 13:35:44 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D029B3.3050003@oracle.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:35:52 -0000 On 2/5/2015 13:14, Benjamin Kaduk wrote: > On Mon, 2 Feb 2015, Weijun Wang wrote: > >> But the xml2rfc tool claims >> >> No boilerplate text available for ipr: 'full2026'. Acceptable values are: >> trust200902, noModificationTrust200902, noDerivativesTrust200902, >> pre5378Trust200902, trust200811, noModificationTrust200811, >> noDerivativesTrust200811 > > The standalone tool for local use, or http://xml2rfc.ietf.org/ ? I think > that at least at one point, they had slightly different behavior. Local, but the web tool also shows the same error. In fact, there is a box on the web page explaining several ipr values (4 flavors of trust200902) and "pre5378Trust200902" seems to be the correct one since the initial RFC for JGSS-API (RFC 2478) was submitted in June 2000. > >> I decide to choose "pre5378Trust200902". The output text is almost identical >> to that of RFC 5653, but adding these lines which I think is harmless >> >> Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. > > That may be good enough; we can call out the difference in the shepherd > report and/or RFC Editor note if needed. I am waiting for feedback from Greg, and after that I'll post -02 draft. Thanks Weijun > > -Ben > From nobody Wed Feb 4 23:17:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8B51A1A5B for ; Wed, 4 Feb 2015 23:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JZTRQX_ObeRh for ; Wed, 4 Feb 2015 23:17:43 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58FA1A039B for ; Wed, 4 Feb 2015 23:17:42 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-5b-54d319154043 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 0E.61.03354.51913D45; Thu, 5 Feb 2015 02:17:41 -0500 (EST) 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 t157HZGk012923; Thu, 5 Feb 2015 02:17:35 -0500 Received: from [18.101.8.241] (vpn-18-101-8-241.mit.edu [18.101.8.241]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t157HXHx009194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Feb 2015 02:17:34 -0500 Message-ID: <54D3190D.8080003@mit.edu> Date: Thu, 05 Feb 2015 02:17:33 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Weijun Wang , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> In-Reply-To: <54D2FCD5.6060404@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrisqeTnEYM12YYujm1exWHxduoHZ gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mp4enEma8FGzorPa90bGC+wdzFyckgImEjM /LSdEcIWk7hwbz1bFyMXh5DAYiaJXQ+msEA4GxglWv7fYIVwDjNJrDm7nhWkhVdATWL6ij4W EJtFQFXiVtN2MJtNQFli/f6tQDYHh6hAmMT5ZkaIckGJkzOfgJWICCRJtDUvYQKZKSwwk1Gi 80wzE8SCGYwSmz/sAbuPU0BLou3kCbBuZgE9iR3Xf7FC2PIS29/OYZ7AKDALyeBZSMpmISlb wMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIzhUXVR3ME44pHSIUYCDUYmH 12LfpRAh1sSy4srcQ4ySHExKoryxvJdDhPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwanIA5XhT EiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHgnigM1ChalpqdWpGXmlCCk mTg4QYbzAA2fDVLDW1yQmFucmQ6RP8WoKCXO2wWSEABJZJTmwfXCUskrRnGgV4R5V4JU8QDT EFz3K6DBTECDZS9eABlckoiQkmpgjL3X05n8nK18XtkPsQNHxNjbVLkeews+3vg+52TUiU2L l0r/czXhjYuoNW/ZmlnqEa5X6HHon/+a9yHlgpOn7RTYpql27G7S8nXrojpvHdC/NrWde2f6 0xvPn7zea6Bpn7GsQzRH7dvVmB/sooeWXTv+43mVrsKKpctWbPPabT5HfjVj6g+7NCWW4oxE Qy3mouJEAHvyQ6YAAwAA Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 07:17:46 -0000 On 02/05/2015 12:17 AM, Weijun Wang wrote: > On 2/2/2015 11:03, Weijun Wang wrote: >>>> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 >>> >>> My only substantive note is that the InputStream/OutputStream forms of >>> initSecContext/acceptSecContext could, perhaps, already write tokens to >>> the outStream parameter before throwing an exception, instead of >>> communicating them in the exception. If this issue has already been >>> discussed, please ignore this remark. If not, I suspect it might be >>> easier on callers (but perhaps harder on implementations) just to >>> require that callers flush or otherwise handle content in the output >>> stream after an exception. I do not have a strong interest in how this >>> turns out, though. >> >> The main reason I preferred the current design is to be consistent with >> the byte array forms of the methods, which gives the caller the chance >> to determine whether the error token should be sent or not. > > Are you OK with this reason? As I said, I don't have a strong opinion either way, but I'm not sure why it would be important or useful to give the caller a chance to decline to send an error token. From nobody Wed Feb 4 23:46:41 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DF11A017C for ; Wed, 4 Feb 2015 23:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LvQBvo3SCI7y for ; Wed, 4 Feb 2015 23:46:38 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEAB1A0130 for ; Wed, 4 Feb 2015 23:46:38 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t157ka12007186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 07:46:37 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t157kaZo012160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Feb 2015 07:46:36 GMT Received: from ubhmt116.oracle.com (ubhmt116.oracle.com [156.151.24.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t157kZ73008454; Thu, 5 Feb 2015 07:46:35 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Feb 2015 23:46:35 -0800 Message-ID: <54D31FD0.9030508@oracle.com> Date: Thu, 05 Feb 2015 15:46:24 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Greg Hudson , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> In-Reply-To: <54D3190D.8080003@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 07:46:40 -0000 On 2/5/2015 15:17, Greg Hudson wrote: > On 02/05/2015 12:17 AM, Weijun Wang wrote: >> On 2/2/2015 11:03, Weijun Wang wrote: >>>>> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 >>>> >>> The main reason I preferred the current design is to be consistent with >>> the byte array forms of the methods, which gives the caller the chance >>> to determine whether the error token should be sent or not. >> >> Are you OK with this reason? > > As I said, I don't have a strong opinion either way, but I'm not sure > why it would be important or useful to give the caller a chance to > decline to send an error token. The current implementation does not send the error token (This is not precisely specified although the doc does mention that a token generated by initSecContext/acceptSecContext is meant to be consumed by acceptSecContext/initSecContext by the peer). Either a caller does not want to send the token at all, or one should have already written extra code to generate that token and send it. If we now silently send the token, it will be a big behavior change and a surprise for everyone. Thanks Weijun From nobody Thu Feb 5 06:55:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD691A88E3 for ; Thu, 5 Feb 2015 06:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eUnQU-WTiooz for ; Thu, 5 Feb 2015 06:55:08 -0800 (PST) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567131A8834 for ; Thu, 5 Feb 2015 06:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423148099; bh=duNo1FczHkfuPPi3qGqINhIh3N3jlyG+jLQXMTl6Sx8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=bKD3l0KOEe/Kxan85D+gKeF00iu0iCIFjJwh5LVUCuw58r1AN+F+dRJeDpKK2tKHP56v30QdO0JgxOTw8jlG52PmVwEAz/FpYES5zlBA/Tvepc43OD4hHEToBOWklQl35FdlIA0wNM8tkAUW8Sb05zrII2rxrKJvdMq0KjtGwhyEAqMUNsN4Gd5KoC9Eju6KsPufLnXagDuJWZVs4Svmz/ssZfNxrIqYaXR1Y9QqmPTH/bKfgVcTQhKL/OIMJsHJ9HYK84ReSsw7BGYeUBMD7xzDppj8JFfAr55iRn0X/DL2nrGcxW6NYEhv0NtfLdouWfOfYkMelA7Km2Ysl9Ygsw== Received: from [98.139.215.140] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 14:54:59 -0000 Received: from [98.139.212.234] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 14:54:59 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 14:54:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 503874.68391.bm@omp1043.mail.bf1.yahoo.com X-YMail-OSG: erXMloMVM1kf6Dn.KCkleGhPHnS1VTB18skU6c46Z0W.Rc4Kx0FqKlT9zwKteST XrdGaE2moExGacVI_tthqeEAx87P2eaZLSMr.FhVoqUCdCZ0T381b.HymgC2NJ690luCoXnJyNpQ 7gNgWwtP4hDz9se7v.i9t8D5_2mJw5HEFvxtIxF3RbOcMCtI_IPnwZuZhqS_cowWWufsTeac3xIZ eKW9QA5XmSz8Dg_J8_nTHCMpG3S8vhDyRPJ4mP6Tan.wtjB_8Q8QYc1tcSn9nIZFfmME4F0FmbZc 17yplR2dKipHNxN7kRdS9nZ._WK1xo8_.6QWqA8HtOv_d7lqH4t4HT4VSLRC9fSjDt6EhTTNrb6w 6FIA0zZQMmp4xeGi6d1y_pDX9qpF_iumbD75rPn2XNmv7qo961Yp49dsvcwZwA_HttQDP1x2mLwx _CDCvKzAmjP65xCfXFnA9Az0gERBhKfWcAQFEEcD6M65mM1SwIMY4U.qH4uVKVzQEcfv.DOKsyIy s9xZwsaB3 Received: by 66.196.80.150; Thu, 05 Feb 2015 14:54:59 +0000 Date: Thu, 5 Feb 2015 14:54:58 +0000 (UTC) From: Bill Mills To: Weijun Wang , Benjamin Kaduk Message-ID: <172631459.249465.1423148098718.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <54D30130.6040707@oracle.com> References: <54D30130.6040707@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_249464_575878802.1423148098715" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 14:55:09 -0000 ------=_Part_249464_575878802.1423148098715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The standalone tool can product results that the more aggressive parser in = the submission checked won't accept. =C2=A0I use that for local work but al= ways submite the XML to the online tool for final production of the plainte= xt draft.=20 On Wednesday, February 4, 2015 9:35 PM, Weijun Wang wrote: =20 =20 On 2/5/2015 13:14, Benjamin Kaduk wrote: > On Mon, 2 Feb 2015, Weijun Wang wrote: > >> But the xml2rfc tool claims >> >>=C2=A0 =C2=A0 No boilerplate text available for ipr: 'full2026'.=C2=A0 Ac= ceptable values are: >> trust200902, noModificationTrust200902, noDerivativesTrust200902, >> pre5378Trust200902, trust200811, noModificationTrust200811, >> noDerivativesTrust200811 > > The standalone tool for local use, or http://xml2rfc.ietf.org/ ?=C2=A0 I = think > that at least at one point, they had slightly different behavior. Local, but the web tool also shows the same error. In fact, there is a=20 box on the web page explaining several ipr values (4 flavors of=20 trust200902) and "pre5378Trust200902" seems to be the correct one since=20 the initial RFC for JGSS-API (RFC 2478) was submitted in June 2000. > >> I decide to choose "pre5378Trust200902". The output text is almost ident= ical >> to that of RFC 5653, but adding these lines which I think is harmless >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Code Components extracted from this document = must >>=C2=A0 =C2=A0 include Simplified BSD License text as described in Section= 4.e of >>=C2=A0 =C2=A0 the Trust Legal Provisions and are provided without warrant= y as >>=C2=A0 =C2=A0 described in the Simplified BSD License. > > That may be good enough; we can call out the difference in the shepherd > report and/or RFC Editor note if needed. I am waiting for feedback from Greg, and after that I'll post -02 draft. Thanks Weijun > > -Ben > _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_249464_575878802.1423148098715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The standalone tool can product result= s that the more aggressive parser in the submission checked won't accept. &= nbsp;I use that for local work but always submite the XML to the online too= l for final production of the plaintext draft.


On Wednesday, February 4, 2015 9:35 PM, Weijun Wang <weijun.wang@orac= le.com> wrote:




On 2/5/2015 13:14, Benjamin Kaduk = wrote:
> On Mon, 2 Feb 2015, Weijun Wang wrote:
>
>> But the xml2rfc tool claims
>>
>>    No boilerp= late text available for ipr: 'full2026'.  Acceptable values are:
>> trust200902, noModificationTrust200902, noDerivatives= Trust200902,
>> pre5378Trust200902, trust200811, no= ModificationTrust200811,
>> noDerivativesTrust20081= 1
>
> The standalone tool for loc= al use, or http://xml2rfc.ietf.org/ ?  I think
> t= hat at least at one point, they had slightly different behavior.

Local, but the web tool also shows the same er= ror. In fact, there is a
box on the web page explaining = several ipr values (4 flavors of
trust200902) and "pre53= 78Trust200902" seems to be the correct one since
the ini= tial RFC for JGSS-API (RFC 2478) was submitted in June 2000.

>
>> I decide to choose "= pre5378Trust200902". The output text is almost identical
= >> to that of RFC 5653, but adding these lines which I think is harml= ess
>>
>>    &nbs= p;   Code Components extracted from this document must
>>    include Simplified BSD License text as described= in Section 4.e of
>>    the Trust Legal= Provisions and are provided without warranty as
>>=     described in the Simplified BSD License.
&= gt;
> That may be good enough; we can call out the dif= ference in the shepherd
> report and/or RFC Editor not= e if needed.

I am waiting for feedback= from Greg, and after that I'll post -02 draft.

Thanks

Weijun

>
&= gt; -Ben
>

______= _________________________________________
Kitten mailing = list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


------=_Part_249464_575878802.1423148098715-- From nobody Thu Feb 5 08:07:21 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110261A884C for ; Thu, 5 Feb 2015 08:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Bvo4NSGeWQbM for ; Thu, 5 Feb 2015 08:07:10 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8C91A88DC for ; Thu, 5 Feb 2015 08:07:09 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-26-54d3952b7acc 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 9B.E1.03762.C2593D45; Thu, 5 Feb 2015 11:07:08 -0500 (EST) 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 t15G71FC028039; Thu, 5 Feb 2015 11:07:02 -0500 Received: from [18.101.8.163] (vpn-18-101-8-163.mit.edu [18.101.8.163]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t15G6xIr032308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Feb 2015 11:07:01 -0500 Message-ID: <54D39523.5070700@mit.edu> Date: Thu, 05 Feb 2015 11:06:59 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Weijun Wang , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> In-Reply-To: <54D31FD0.9030508@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6noqsz9XKIwYduNoujm1exWHxduoHZ gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mp4+VSnYIlAxelrSxgbGNt4uxg5OSQETCSO rf7NCGGLSVy4t56ti5GLQ0hgMZPEuQXLmCCcDYwSK1d/hMocZpKYN/cCkMPBwSugJvFlkTZI N4uAqsS1jv9gk9gElCXW79/KAlIiKhAmcb4ZLMwrIChxcuYTFhBbRCBJoq15Cdh8YYGZjBKd Z5qhll1klHix9AIrSBWngJZE479nbCA2s4CexI7rv1ghbHmJ5q2zmScwCsxCMngWkrJZSMoW MDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECApUTkmeHYxvDiodYhTgYFTi 4X2w+1KIEGtiWXFl7iFGSQ4mJVFen8mXQ4T4kvJTKjMSizPii0pzUosPMUpwMCuJ8N5pBsrx piRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwKk4BahQsSk1PrUjLzClB SDNxcIIM5wEaPgGkhre4IDG3ODMdIn+KUVFKnDcOJCEAksgozYPrhSWSV4ziQK8I83qDVPEA kxBc9yugwUxAg2UvXgAZXJKIkJJqYAwQbtdojS9hVU/c9rg6v3zO2tCIT5n7pulslrmqu89q yvIvnB/OxveUfl589wPXul9e6TNL8stWfnjL8vhx77bgIOWUxp3Ll8zmNCyaVpzeO2k/q3D3 K6OuwHrOHY7h1XdOFH2+y/qA+2fIrqLpk/lmXGzS+rrsX6NE6R2l6d8WWDz7psXtK6vEUpyR aKjFXFScCACFM3C5/wIAAA== Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:07:12 -0000 On 02/05/2015 02:46 AM, Weijun Wang wrote: >> As I said, I don't have a strong opinion either way, but I'm not sure >> why it would be important or useful to give the caller a chance to >> decline to send an error token. > > The current implementation does not send the error token (This is not > precisely specified although the doc does mention that a token generated > by initSecContext/acceptSecContext is meant to be consumed by > acceptSecContext/initSecContext by the peer). Either a caller does not > want to send the token at all, or one should have already written extra > code to generate that token and send it. Error tokens are usually consumed by accept/init on the peer. The exception is if the peer is already in the GSS_S_COMPLETE state, in which case it needs to be consumed by gss_process_context_token. I don't think it's legitimate for a GSS application to decide to discard a token simply because it came with an error return. If the application knows that the other peer is in GSS_S_COMPLETE state and the protocol has no way of framing a context token to a peer in that state, then it has no choice to discard the token. But absent that specific knowledge, the token should always be sent. > If we now silently send the token, it will be a big behavior change and > a surprise for everyone. As an implementor I certainly understand wanting to be conservative about surprising applications. I don't know how likely it is that Java applications would break if tokens started showing up in the output stream when init/accept raises an error. On the flip side, making the caller explicitly retrieve the token is likely to result in a lot of applications which don't bother. That's unavoidable for the byte array methods, but not for the stream methods. (As an aside, I believe the Python bindings plan to solve this by raising an exception for the GSS_S_CONTINUE case as well as for errors, so an application needs code to extract a token from an exception in order to work for anything more than a single hop.) From nobody Thu Feb 5 15:54:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5D31A8882 for ; Thu, 5 Feb 2015 15:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 Qiv_i_BSCOBO for ; Thu, 5 Feb 2015 15:54:21 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE78F1A8876 for ; Thu, 5 Feb 2015 15:54:20 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 775362AC16; Fri, 6 Feb 2015 00:54:18 +0100 (CET) X-purgate-ID: 152705::1423180458-00003099-7F44DBAC/0/0 X-purgate-size: 3180 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 441D8431BD; Fri, 6 Feb 2015 00:54:18 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3C2BD1B15B; Fri, 6 Feb 2015 00:54:18 +0100 (CET) In-Reply-To: <54D39523.5070700@mit.edu> To: Greg Hudson Date: Fri, 6 Feb 2015 00:54:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150205235418.3C2BD1B15B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:54:25 -0000 Greg Hudson wrote: > On 02/05/2015 02:46 AM, Weijun Wang wrote: >>> As I said, I don't have a strong opinion either way, but I'm not sure >>> why it would be important or useful to give the caller a chance to >>> decline to send an error token. >> >> The current implementation does not send the error token (This is not >> precisely specified although the doc does mention that a token generated >> by initSecContext/acceptSecContext is meant to be consumed by >> acceptSecContext/initSecContext by the peer). Either a caller does not >> want to send the token at all, or one should have already written extra >> code to generate that token and send it. > > Error tokens are usually consumed by accept/init on the peer. The > exception is if the peer is already in the GSS_S_COMPLETE state, in > which case it needs to be consumed by gss_process_context_token. > > I don't think it's legitimate for a GSS application to decide to discard > a token simply because it came with an error return. If the application > knows that the other peer is in GSS_S_COMPLETE state and the protocol > has no way of framing a context token to a peer in that state, then it > has no choice to discard the token. But absent that specific knowledge, > the token should always be sent. I'm sorry to disagree, but I believe that the opposite applies. GSS-API does *NOT* define a wire protocol, only a wire token format. It is *ENTIRELY* up to the application to decide about whether and how to embed and send GSS-API tokens .. or not. It is perfectly OK for an application to discard a context level token from a gssapi mechanism that is returned along with a fatal major_status from the context iterator call -- *unless* the specific application wire protocol explicitly requires a different behaviour[*]. Since it requires additional application protocol complexity and additional application code (calling of gss_process_context_token) to process "unexpected" context token in an application protocol, it is *MUCH* easier to unconditionally discard context level tokens from a context iterator call that accompany a fatal major_status code. A "portable" application caller does not know whether such a token will be "unexpected" for the peer, so conveying such a token without knowing whether the peer will be capable of dealing gracefully with it is somewhat "risky". My application code will never convey context error tokens, I will not contemplating ever conveying error tokens, and I've NEVER had a situation where this decision was detrimental during the past 19 years where we've been using GSS-API to protect our application's communication for our proprietary communication protocols. -Martin [*] SSL&TLS define a wire protocol and specify certain behaviour in addition to protocol PDUs. Microsoft implemented SSL&TLS with a GSS-API style interface: The Microsoft SChannel SSP, and the application caller "Microsoft IIS" unfortunately follows the proprietary apps protocol approach and discards error tokens, rather than sending fatal TLS alerts to the peer, as the TLS protocol _requires_ it. From nobody Thu Feb 5 16:04:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6BC1A006F for ; Thu, 5 Feb 2015 16:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vRq_37gii0-Y for ; Thu, 5 Feb 2015 16:04:22 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D161A700B for ; Thu, 5 Feb 2015 16:04:22 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1604Llo027761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2015 00:04:21 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t1604KD6012204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2015 00:04:21 GMT Received: from ubhmt110.oracle.com (ubhmt110.oracle.com [156.151.24.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1604KJ2000452; Fri, 6 Feb 2015 00:04:20 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Feb 2015 16:04:20 -0800 Message-ID: <54D404FE.8010009@oracle.com> Date: Fri, 06 Feb 2015 08:04:14 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Greg Hudson , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> In-Reply-To: <54D39523.5070700@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:04:30 -0000 On 2/6/2015 0:06, Greg Hudson wrote: > On 02/05/2015 02:46 AM, Weijun Wang wrote: >>> As I said, I don't have a strong opinion either way, but I'm not sure >>> why it would be important or useful to give the caller a chance to >>> decline to send an error token. >> >> The current implementation does not send the error token (This is not >> precisely specified although the doc does mention that a token generated >> by initSecContext/acceptSecContext is meant to be consumed by >> acceptSecContext/initSecContext by the peer). Either a caller does not >> want to send the token at all, or one should have already written extra >> code to generate that token and send it. > > Error tokens are usually consumed by accept/init on the peer. I was wrong about that. > > I don't think it's legitimate for a GSS application to decide to discard > a token simply because it came with an error return. If the application > knows that the other peer is in GSS_S_COMPLETE state and the protocol > has no way of framing a context token to a peer in that state, then it > has no choice to discard the token. But absent that specific knowledge, > the token should always be sent. > >> If we now silently send the token, it will be a big behavior change and >> a surprise for everyone. > > As an implementor I certainly understand wanting to be conservative > about surprising applications. I don't know how likely it is that Java > applications would break if tokens started showing up in the output > stream when init/accept raises an error. It should not break. The peer might have been a non-Java app and is already sending that token. One problem is that if the app "have already written extra code to generate that token and send it", now it will send it twice. > > On the flip side, making the caller explicitly retrieve the token is > likely to result in a lot of applications which don't bother. That's > unavoidable for the byte array methods, but not for the stream methods. Stream methods are not used by many. So most people would have to rewrite their apps to make use of this feature. Thanks Max > > (As an aside, I believe the Python bindings plan to solve this by > raising an exception for the GSS_S_CONTINUE case as well as for errors, > so an application needs code to extract a token from an exception in > order to work for anything more than a single hop.) > From nobody Thu Feb 5 16:40:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C781A0029 for ; Thu, 5 Feb 2015 16:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mOiAfpzSh2Od for ; Thu, 5 Feb 2015 16:40:20 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D911A0067 for ; Thu, 5 Feb 2015 16:40:19 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-a1-54d40d728314 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 16.DD.03354.27D04D45; Thu, 5 Feb 2015 19:40:18 -0500 (EST) 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 t160eCOp001692; Thu, 5 Feb 2015 19:40:12 -0500 Received: from [18.101.8.163] (vpn-18-101-8-163.mit.edu [18.101.8.163]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t160eAZn008823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Feb 2015 19:40:11 -0500 Message-ID: <54D40D6A.7010704@mit.edu> Date: Thu, 05 Feb 2015 19:40:10 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Weijun Wang , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> In-Reply-To: <54D404FE.8010009@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrVvEeyXEYM47Loujm1exWHxduoHZ gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4MrYf+QNc8E81orLd+ewNzD2snQxcnJICJhI HPm2E8oWk7hwbz1bFyMXh5DAYiaJGydXs0M4Gxgl5s2bzAzhHGaS2Db9MhNIC6+AmsS15luM XYwcHCwCqhI31wSAhNkElCXW79/KAhIWFQiTON/MCFEtKHFy5hOwZSICSRJtzUuYQEYKC8xk lOg808wEMb+LSWLV/+tsIFWcAloS3/f8BLOZBfQkdlz/xQphy0tsfzuHeQKjwCwkg2chKZuF pGwBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M4FCV5N/B+O2g0iFGAQ5G JR7eB7svhQixJpYVV+YeYpTkYFIS5d3PeSVEiC8pP6UyI7E4I76oNCe1+BCjBAezkggvw9/L IUK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8XdxAQwWLUtNTK9Iy c0oQ0kwcnCDDeYCGXwKp4S0uSMwtzkyHyJ9i1OVY0L5/JpMQS15+XqqUOO9WkCIBkKKM0jy4 ObAU84pRHOgtYV41HqAqHmB6gpv0CmgJE9AS2YsXQJaUJCKkpBoYrRdFc3gG10z599JK1X7m fP4nefcfH7T7+4n7oXNJ4/uUFJnJUft25tQeTMysb77kfWzl2ZdCnHwPb6rvvvCukDPiGIOg 5olXKYH/BSfPac3w3eqRKMf/8XRU27yzxxzbblxf9LnU5PPf2VP9D04/mSpzmXF+xr2gDX7y zhcf/VwWIhH8+Uh2uRJLcUaioRZzUXEiAB8QT04MAwAA Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:40:23 -0000 On 02/05/2015 07:04 PM, Weijun Wang wrote: > One problem is that if the app "have already written extra code to > generate that token and send it", now it will send it twice. How would an app generate its own GSSAPI error token? Surely it would have to have intimate knowledge of the mech in order to do so. > Stream methods are not used by many. So most people would have to > rewrite their apps to make use of this feature. Fair enough. If, considering all of the arguments given thus far, you still feel that it's better for the stream methods to be consistent with the byte methods, I don't have any strong objection to keeping it the way it is. From nobody Thu Feb 5 16:51:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859F21A0027 for ; Thu, 5 Feb 2015 16:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WQGxwlxGNFES for ; Thu, 5 Feb 2015 16:51:35 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E8C1A0029 for ; Thu, 5 Feb 2015 16:51:35 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t160pY68003344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2015 00:51:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t160pX9d029088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2015 00:51:34 GMT Received: from ubhmt102.oracle.com (ubhmt102.oracle.com [156.151.24.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t160pX9N029085; Fri, 6 Feb 2015 00:51:33 GMT Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Feb 2015 16:51:33 -0800 Message-ID: <54D4100E.7070200@oracle.com> Date: Fri, 06 Feb 2015 08:51:26 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Greg Hudson , Benjamin Kaduk , kitten@ietf.org References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> In-Reply-To: <54D40D6A.7010704@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:51:38 -0000 On 2/6/2015 8:40, Greg Hudson wrote: > On 02/05/2015 07:04 PM, Weijun Wang wrote: >> One problem is that if the app "have already written extra code to >> generate that token and send it", now it will send it twice. > > How would an app generate its own GSSAPI error token? Surely it would > have to have intimate knowledge of the mech in order to do so. I don't know if there exists an app doing that. Still possible. Maybe I am just looking for reasons to persuade myself. :-) > >> Stream methods are not used by many. So most people would have to >> rewrite their apps to make use of this feature. > > Fair enough. > > If, considering all of the arguments given thus far, you still feel that > it's better for the stream methods to be consistent with the byte > methods, I don't have any strong objection to keeping it the way it is. That's still my position. I just don't want to introduce a behavior change. Thanks for all the advices. I'll prepare a -02 draft including other changes you suggested. --Weijun From nobody Thu Feb 5 20:19:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8071A0366 for ; Thu, 5 Feb 2015 20:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iWDw7oOgUNwL for ; Thu, 5 Feb 2015 20:19:22 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E961A028A for ; Thu, 5 Feb 2015 20:19:19 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-9a-54d440c679d2 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 99.97.03326.6C044D45; Thu, 5 Feb 2015 23:19:18 -0500 (EST) 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 t164JHwW028278; Thu, 5 Feb 2015 23:19:18 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t164JEKP007330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Feb 2015 23:19:16 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t164JDUC001355; Thu, 5 Feb 2015 23:19:13 -0500 (EST) Date: Thu, 5 Feb 2015 23:19:12 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20150205235418.3C2BD1B15B@ld9781.wdf.sap.corp> Message-ID: References: <20150205235418.3C2BD1B15B@ld9781.wdf.sap.corp> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1j3mcCXE4MZzJYujm1exWPT+3sFs 8XXpBmYHZo8lS34yeXx8eovFY8rnrYwBzFFcNimpOZllqUX6dglcGU/XbmMrWMBSsfvuScYG xvXMXYwcHBICJhJbLgh0MXICmWISF+6tZwOxhQQWM0nc3xwDYW9glOhfqtjFyAVkH2SSWHN4 GiNEol7iw5Or7CA2i4CWxOfVa8HibAIqEjPfbAQbJCIgKzHt2huwOLNAosSjVdPZQAYJC8xk lOg808wEkuAUsJG4dOY1K4jNK+Ag0X9iBTvEAmuJE/sWgtWICuhIrN4/hQWiRlDi5MwnLBBD tSSWT9/GMoFRcBaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzGC Q1eSbwfj14NKhxgFOBiVeHgTeK+ECLEmlhVX5h5ilORgUhLlFVADCvEl5adUZiQWZ8QXleak Fh9ilOBgVhLhZfh7OUSINyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC N9QeaKhgUWp6akVaZk4JQpqJgxNkOA/Q8B0gNbzFBYm5xZnpEPlTjLocC9r3z2QSYsnLz0uV EuetAikSACnKKM2DmwNLOa8YxYHeEubdC1LFA0xXcJNeAS1hAloie/ECyJKSRISUVANjwTFm X5UFujEq1ydyimdcMFe+cnJvSFSThlPms00dMXEtBb5Cj94apkw9XswhU+Ac2r5Y096z7NDs q7yx9r3nFk+YOWOHDJvWQdOOJY13fs76X3InXKfq3xyPe5YbdPSNZ+j38n279Ot7aa2M6DvP 8JnSzuo5DB//XPjxZ1nrDp47E1OXqP5QYinOSDTUYi4qTgQAuHT83xQDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 04:19:26 -0000 On Thu, 5 Feb 2015, Martin Rex wrote: > > GSS-API does *NOT* define a wire protocol, only a wire token format. > It is *ENTIRELY* up to the application to decide about whether and how > to embed and send GSS-API tokens .. or not. > > It is perfectly OK for an application to discard a context level token > from a gssapi mechanism that is returned along with a fatal major_status > from the context iterator call -- *unless* the specific application wire > protocol explicitly requires a different behaviour[*]. Exactly. -Ben From nobody Thu Feb 5 23:21:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC71A1A2F; Thu, 5 Feb 2015 23:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Oeoptpbj1azg; Thu, 5 Feb 2015 23:21:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEA71A0066; Thu, 5 Feb 2015 23:21:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206072110.32177.54979.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 23:21:10 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 07:21:12 -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 Working Group of the IETF. Title : Generic Security Service API Version 2: Java Bindings Update Authors : Mayank D. Upadhyay Seema Malkani Wang Weijun Filename : draft-ietf-kitten-rfc5653bis-02.txt Pages : 102 Date : 2015-02-05 Abstract: The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc5653bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 5 23:30:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5667F1A1A3D for ; Thu, 5 Feb 2015 23:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RkQ5Lw5emnYz for ; Thu, 5 Feb 2015 23:29:47 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9391A1A6D for ; Thu, 5 Feb 2015 23:29:12 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t167TB9r014178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2015 07:29:12 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t167T9LE012415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2015 07:29:10 GMT Received: from ubhmt114.oracle.com (ubhmt114.oracle.com [156.151.24.19]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t167T8CO029340; Fri, 6 Feb 2015 07:29:08 GMT Received: from [192.168.10.106] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Feb 2015 23:29:08 -0800 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=windows-1252 From: Wang Weijun In-Reply-To: <54D30130.6040707@oracle.com> Date: Fri, 6 Feb 2015 15:28:45 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D029B3.3050003@oracle.com> <54D30130.6040707@oracle.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 07:29:52 -0000 http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-02 posted. Major = diff is the pre-2008 paragraph in copyright notice. Others are a new = date, 4 s/inform/communicate/ and one typo. Thanks Weijun > On Feb 5, 2015, at 13:35, Weijun Wang wrote: >=20 > I am waiting for feedback from Greg, and after that I'll post -02 = draft. From nobody Fri Feb 6 15:13:29 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7402D1A1ABB for ; Fri, 6 Feb 2015 15:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HY9uvkVszTsG for ; Fri, 6 Feb 2015 15:13:25 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFCF1A0673 for ; Fri, 6 Feb 2015 15:13:24 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-13-54d54a93c323 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 3F.75.03326.39A45D45; Fri, 6 Feb 2015 18:13:23 -0500 (EST) 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 t16NDMqN016911; Fri, 6 Feb 2015 18:13:22 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t16NDKZo026296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Feb 2015 18:13:21 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t16NDKd3023336; Fri, 6 Feb 2015 18:13:20 -0500 (EST) Date: Fri, 6 Feb 2015 18:13:19 -0500 (EST) From: Benjamin Kaduk To: Weijun Wang In-Reply-To: <54D4100E.7070200@oracle.com> Message-ID: References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrDvZ62qIQU+/qsXRzatYLL4u3cDs wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGUcbrvNVtBqX3Hm90+mBsaXRl2MnBwSAiYS j5oes0PYYhIX7q1n62Lk4hASWMwkcXDhGihnA6PE7bOnoJyDTBI9V48wg7QICdRL3H/bywpi swhoSTydfh0sziagIjHzzUY2EFtEQEOi4UETUJyDg1nASOLCrwwQU1hAX+LaYnmQCk6gzlPv rzGChHkFHCTuT5OG2HSUSWLCtTtgE0UFdCRW75/CAmLzCghKnJz5BMxmBupdPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdbLzSzRS00p3cQIDlNJvh2MXw8qHWIU 4GBU4uFN4L0SIsSaWFZcmXuIUZKDSUmUV8f8aogQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd6e pUDlvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvByeQEMFi1LTUyvS MnNKENJMHJwgw3mAhveB1PAWFyTmFmemQ+RPMSpKifOGgiQEQBIZpXlwvbA08opRHOgVYd4e kCoeYAqC634FNJgJaPBisKuLSxIRUlINjKzqbheOKE3nzTotFXZwtdxJ7cdfFgh/2dERe89O 8pv28oNVbEdk/trw2tcH/O3usfK+fCNe10rlyomlVxjtdzoe28Wi/2JmbOuu9BzJhiaLhS3d N5SZ3W6qSucxL5pUWb3iprbWp9Srqy4dXZ91zdu0L8HnGfu6LOYZU1R8Jc3sb/5+vJAhQIml OCPRUIu5qDgRANiIc3T+AgAA Archived-At: Cc: kitten@ietf.org Subject: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 23:13:28 -0000 (was Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00) [changing subject line to avoid complicating the threading if there are discussions for the other two documents] On Thu, 5 Feb 2015, Weijun Wang wrote: > > > On 2/6/2015 8:40, Greg Hudson wrote: > > On 02/05/2015 07:04 PM, Weijun Wang wrote: > > > One problem is that if the app "have already written extra code to > > > generate that token and send it", now it will send it twice. > > > > How would an app generate its own GSSAPI error token? Surely it would > > have to have intimate knowledge of the mech in order to do so. > > I don't know if there exists an app doing that. Still possible. Maybe I am > just looking for reasons to persuade myself. :-) > > > > > > Stream methods are not used by many. So most people would have to > > > rewrite their apps to make use of this feature. > > > > Fair enough. > > > > If, considering all of the arguments given thus far, you still feel that > > it's better for the stream methods to be consistent with the byte > > methods, I don't have any strong objection to keeping it the way it is. > > That's still my position. I just don't want to introduce a behavior change. I got a chance to read more closely more of the bulk of the document. (That is, read the whole text, not just the diff, though I skipped some uninteresting API descriptions.) First, I should note that the Java bindings explicitly do not implement GSS_Process_context_token. This does not directly affect any of the reasoning about whether the application protocol can transmit post-completion error tokens or the peer's ability to process them, since the peer is not necessarily written in Java. I have some serious concerns about the stream-based routines in general, though. Section 6.4.5 (and 6.4.9) contain the text: The GSS-API authentication tokens contain a definitive start and end. This method will attempt to read one of these tokens per invocation, and may block on the stream if only part of the token is available. This is simply not true. Only the initial context token is required to use the ASN.1-like framing; subsequent context tokens are known to be from a particular mechanism, and that mechanism can specify a token format which does not contain framing information. It happens that the Kerberos and SPKM mechanisms mentioned in the introduction do use self-describing token formats, but a generic mechanism is not bound to do so. As described in section 2 of https://tools.ietf.org/html/draft-ietf-kitten-gss-loop-04 , the application protocol using the GSS-API must specify how to frame and identify context negotation tokens. Similarly, the format of wrap tokens is mechanism specific, and is not required to include framing information. The discussion in 6.4.15 and 6.4.17 do not seem to include explicit claims that the wrap tokens are self-describing, but the use of stream interfaces does tend to imply that wrap() and unwrap() could be used to filter a data stream from an application for encryption on the wire. Because neither the context nor per-message tokens are required to be self-describing, a generic GSS-API-using application protocol must specify its own token framing, and the only safe way to use the stream forms of these routines is to read the entire token from the network using the application's framing, then construct a single-use stream for a single GSS call, discarding the stream afterwards. (It might be possible for an application to limit itself to a specific mechanism which is known to use token framing, but that completely loses the "Generic" part of "GSS-API".) Since this essentially involves generating byte-array tokens everywhere and generating single-use streams from them, it makes me wonder what utility the stream forms of these routines provide. That is, it seems they could be removed from the specification, since they only increase the programmer effort required, when used correctly. However, I have no experience writing GSS-API-using software in Java, so perhaps I am missing something about how and why the stream forms might be preferred in some cases. Finally, I believe I can say a bit more about keeping the transmission of error tokens under the application's control even when streams are used. It seems that the intended workflow in section 7.4.5 of RFC 5653 is that the initSecContext implementation will generate an output token and place it into the OutputStream buffer; the application would then explicitly call flush() on the stream to trigger the token transmission. The expectation would be that the stream provides complete buffering for each token, so that each flush() or GSS call would transmit or consume exactly one token on the stream. Given the above commentary about non-framed tokens, though, I don't see how this could work reliably. In any case, even in this model where the GSS implementation places bytes in the stream to be flush()ed by the application, sections 7.4.5 and 7.4.9 of RFC 5653 are still ambiguous about whether the implementation places bytes in the stream before throwing an exception. A given implementation could either place the token in the stream or not do so, and still be compliant with what RFC 5653 specifies. Since we are now discovering the issue, we should take advantage of the opportunity to resolve the ambiguity, but are obligated to do so in a backwards-compatible way. It seems that erring on the side of not sending error tokens is mroe backwards-compatible than erring on the side of sending duplicate error tokens (though I have not given a great deal of thought to it), so that would be my current preference. That is, I think Weijun is justified in his position of using an exception for error tokens in the stream case. A few other notes from my reading that probably do not affect the actual specified behavior: Comparing the descriptions of the initSecContext flavors in 6.4.3 and 6.4.5, it seems that the byte-array version's description in 6.4.3 started out as a copy of the stream-based description in 6.4.5 and was not fully updated for the byte-array case. That is, it refers to "[t]his is equivalent to the stream-based method except that the token buffers are handled as byte arrays instead of using stream objects.", but the stream version has not been introduced yet, so this is a forward reference that is not marked as such. It also has the text that "Typically, the application would do so by calling the flush() method on an OutputStream that encapsulates the connection between the two peers.", which does not seem quite appropriate for a routine dealing in byte arrays. The phrase "informational purpose" appears in three places in the new text, but should be "informational purposes" with a trailing 's'. RFC 5653 had a notice about the use of RFC 2119 keywords that is removed in the current draft, which seems correct as I do not see any capitalized RFC 2119 keywords in my reading. I wonder how that notice slipped into RFC 5653.... Section 6.8 of the -02 adds "For example, when an initSecContext call fails due to a fatal error, the mechanism may define an error token [...]" I wonder if "generate" might be better than "define". In 6.8.2, I think that the text about the outputToken where "When provided, the array will be cloned to protect against subsequent modifications" could be more clear that the GSS implementation will make a copy of the outputToken which was provided as input to the GSSException constructor (as opposed to the copy being made at some later time). In particular, the word "clone" is a bit unusual to use here. The unchanged text from RFC 5653 could also benefit from a general copyediting pass, but I do not think I am prepared to perform one during the WGLC period. -Ben From nobody Mon Feb 9 14:00:36 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316751A894C for ; Mon, 9 Feb 2015 13:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gZ3AQ1iXFlmT for ; Mon, 9 Feb 2015 13:19:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166271A8900 for ; Mon, 9 Feb 2015 13:19:01 -0800 (PST) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.1.81.12; Mon, 9 Feb 2015 21:18:38 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.132]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.132]) with mapi id 15.01.0081.018; Mon, 9 Feb 2015 21:18:38 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: I-D Action: draft-ietf-kitten-pkinit-freshness-00.txt Thread-Index: AdBBi+Xf81L9FbgETLycsD7GvbRawA== Date: Mon, 9 Feb 2015 21:18:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB210; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB210; x-forefront-prvs: 04825EA361 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(77156002)(54356999)(86362001)(19580405001)(19580395003)(87936001)(230783001)(50986999)(2501002)(450100001)(62966003)(92566002)(46102003)(107886001)(2900100001)(2351001)(15975445007)(102836002)(40100003)(110136001)(561944003)(33656002)(2656002)(76576001)(74316001)(99286002)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2015 21:18:38.1349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB210 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:19:17 -0000 1. Is this padata type needed at all? =20 My understanding (confirmed by Sam) is that RFC 4120 extensibility guidelin= es require that the KDC ensure the clients understand the response. I am op= en to discussion. 2. If it is needed, does it need to have a different padata type value from= PA-AS-FRESHNESS? I am open to the idea. We can have a single padata-type (PA-AS-FRESHNESS) t= hen specify in requests, the padata-value shall be empty and in responses, = the padata-value contains the actual freshness token. What do others think? 3. The draft defines "PA-AS-FRESHNESS-REQUEST ::=3D NULL". Is the intent t= hat the client will use a padata-value of 05 00 (an ASN.1 NULL value encode= d in DER)? An empty padata-value would be more traditional and more compac= t. Our proposal was ASN.1 NULL object (tag 5). An empty octet string for padat= a-value works, too. 4. The draft defines "PA-AS-FRESHNESS ::=3D OCTET STRING". Is it desirable= to wrap the freshness token in a DER OCTET STRING tag, or could we just tr= ansmit the value directly within the padata-value? Of course the value sti= ll needs to have type OCTET STRING within the PKAuthenticator. If we skip the OCTET STRING definition then we need to specify that the pad= ata-value directly is the freshness octet string (i.e., no wrapping in the = padata-value OCTET STRING). The PKAuthenticator needs to specify that the f= reshnessToken component is an OCTET STRING and with a comment that the valu= e shall be as received in padata-value (basically just a copy of the whole = DER-encoded padata-value value). The advantage though (besides being short= er) is that we could now simply claim that the padata-value directly carrie= s a freshness token, when non-empty. Is that what you were thinking? 5. It looks like this mechanism is general enough to be used by other preau= thentication mechanisms in the future, if they have similar requirements. = Perhaps the RFC should explicitly call out that possibility. I thought that as well which is why I pulled the PK out of the naming so th= at future extensions could use the token and it would not look odd.=20 -----Original Message----- ---------------------------------------------------------------------- Message: 1 Date: Sun, 01 Feb 2015 12:37:54 -0500 From: Greg Hudson To: Benjamin Kaduk , kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-00.txt Message-ID: <54CE6472.9050408@mit.edu> Content-Type: text/plain; charset=3Dwindows-1252 I have some questions, mostly related to PA-AS-FRESHNESS-REQUEST: 1. Is this padata type needed at all? The only benefit I can see is that K= DCs can omit PA-AS-FRESHNESS from the PREAUTH_REQUIRED hint list if the cli= ent doesn't support it, but that benefit vanishes as more clients support t= he new feature. 2. If it is needed, does it need to have a different padata type value from= PA-AS-FRESHNESS? 3. The draft defines "PA-AS-FRESHNESS-REQUEST ::=3D NULL". Is the intent t= hat the client will use a padata-value of 05 00 (an ASN.1 NULL value encode= d in DER)? An empty padata-value would be more traditional and more compac= t. 4. The draft defines "PA-AS-FRESHNESS ::=3D OCTET STRING". Is it desirable= to wrap the freshness token in a DER OCTET STRING tag, or could we just tr= ansmit the value directly within the padata-value? Of course the value sti= ll needs to have type OCTET STRING within the PKAuthenticator. 5. It looks like this mechanism is general enough to be used by other preau= thentication mechanisms in the future, if they have similar requirements. = Perhaps the RFC should explicitly call out that possibility. ------------------------------ Subject: Digest Footer _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------------------------------ End of Kitten Digest, Vol 123, Issue 1 ************************************** From nobody Mon Feb 9 14:10:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574941A883B for ; Mon, 9 Feb 2015 13:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tDVi6ws-UNyW for ; Mon, 9 Feb 2015 13:33:25 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85701A1A48 for ; Mon, 9 Feb 2015 13:33:24 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-10-54d927a3e05b 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 36.9F.08135.3A729D45; Mon, 9 Feb 2015 16:33:23 -0500 (EST) 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 t19LXMBr028377; Mon, 9 Feb 2015 16:33:23 -0500 Received: from [18.101.9.202] (vpn-18-101-9-202.mit.edu [18.101.9.202]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t19LXK6p003613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2015 16:33:22 -0500 Message-ID: <54D9279B.9020209@mit.edu> Date: Mon, 09 Feb 2015 16:33:15 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michiko Short , "kitten@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nortY/WaIwfQWJYujm1exWPzr5nNg 8liy5CeTR+uOv+wBTFFcNimpOZllqUX6dglcGb2b3rMVfOCrOND3na2BcR5PFyMnh4SAicSu iYtZIGwxiQv31rN1MXJxCAksZpL4tnAqM4SzgVFi0cpnjBDOYSaJH/tbWUFaeAXUJJb2nQCz WQRUJa48mAdmswkoS6zfvxVsrKhAmMT3zTuYIeoFJU7OfAIU5+AQEYiQmNsaCxIWFvCW6Dx0 nQnEFhKIkrh+4z7YGE6BaImN96aAjWEW0JPYcf0XK4QtL9G8dTbzBEaBWUimzkJSNgtJ2QJG 5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxhBYcopybuD8d1BpUOMAhyMSjy8 FR+vhwixJpYVV+YeYpTkYFIS5f0ifzNEiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvjzM3QoR4 UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4F6sBDRUsSk1PrUjLzClB SDNxcIIM5wEarg1Sw1tckJhbnJkOkT/FqCglzjsFJCEAksgozYPrhaWRV4ziQK8I88aAVPEA UxBc9yugwUxAgwsKQK4uLklESEk1MC7+IapkcqXlQn/n99+qrv+SY29PY0plnWEeWPxl9Zvq 5roFDc7f3vQp3P4+o+jWi523FB4LMO8rVnq6/4RR3oukvsz3x69oPn/jdpn75dKlRl2XtOJ7 7BdYTzzq2qXxMtq1z7BIe3PMoZpF9V2a4h8iWv1ykp7+nKS5v6hux8FfanPmPLm1e74SS3FG oqEWc1FxIgB2fqGP/gIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:33:27 -0000 On 02/09/2015 04:18 PM, Michiko Short wrote: > 1. Is this padata type needed at all? > > My understanding (confirmed by Sam) is that RFC 4120 extensibility guidelines require that the KDC ensure the clients understand the response. I am open to discussion. Surely clients must ignore unknown preauth types in a preauth-required error. Otherwise all new preauth methods (including specified ones such as PKINIT and OTP) would have required an indication of client support in the request. > 4. The draft defines "PA-AS-FRESHNESS ::= OCTET STRING". Is it desirable to wrap the freshness token in a DER OCTET STRING tag, or could we just transmit the value directly within the padata-value? Of course the value still needs to have type OCTET STRING within the PKAuthenticator. > > If we skip the OCTET STRING definition then we need to specify that the padata-value directly is the freshness octet string (i.e., no wrapping in the padata-value OCTET STRING). The PKAuthenticator needs to specify that the freshnessToken component is an OCTET STRING and with a comment that the value shall be as received in padata-value (basically just a copy of the whole DER-encoded padata-value value). The advantage though (besides being shorter) is that we could now simply claim that the padata-value directly carries a freshness token, when non-empty. Is that what you were thinking? Yes. In addition to making the preauth-required error slightly shorter, this change eliminates an implementation step and an exceptional case in the client code required to implement the feature. If we make this change and the PA-AS-FRESHNESS token sent by the KDC is empty, I don't think the client should treat that as an exceptional case; it should include an empty OCTET STRING value in the freshnessToken field of the PKAuthenticator, like it would for any other PA-AS-FRESHNESS padata-value. From nobody Mon Feb 9 14:52:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0183D1A8A13 for ; Mon, 9 Feb 2015 14:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JYNmO9txMC0f for ; Mon, 9 Feb 2015 14:35:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737BC1A1A30 for ; Mon, 9 Feb 2015 14:35:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6189CBEE9 for ; Mon, 9 Feb 2015 22:36:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvElrOOdZg_M for ; Mon, 9 Feb 2015 22:36:01 +0000 (GMT) Received: from [172.16.29.43] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A7D6BE9C for ; Mon, 9 Feb 2015 22:36:00 +0000 (GMT) Message-ID: <54D9362D.2060707@cs.tcd.ie> Date: Mon, 09 Feb 2015 22:35:25 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20150126143402.29738.32769.idtracker@ietfa.amsl.com> In-Reply-To: <20150126143402.29738.32769.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150126143402.29738.32769.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] Fwd: Last Call: (Structure of the GSS Negotiation Loop) to Informational RFC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 22:35:36 -0000 Folks, IETF LC for this has ended with no comment that I can see. I'll put this on the next IESG telechat (Feb 19) unless someone tells me to wait. Thanks, S. -------- Forwarded Message -------- Subject: Last Call: (Structure of the GSS Negotiation Loop) to Informational RFC Date: Mon, 26 Jan 2015 06:34:02 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: kitten@ietf.org The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'Structure of the GSS Negotiation Loop' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 10 02:41:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF901A012D for ; Tue, 10 Feb 2015 02:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aQ2p_VY59Wyz for ; Tue, 10 Feb 2015 02:41:05 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC361A00FE for ; Tue, 10 Feb 2015 02:41:05 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1AAf3pI018998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Feb 2015 10:41:04 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1AAf2XK020819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 10:41:03 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t1AAf2gP008987; Tue, 10 Feb 2015 10:41:02 GMT Received: from [192.168.10.106] (/114.250.155.87) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Feb 2015 02:40:57 -0800 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Wang Weijun In-Reply-To: Date: Tue, 10 Feb 2015 18:40:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <85E13C1B-F11F-4D61-96D3-A7ECFF5A1BFC@oracle.com> References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2070.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 10:41:07 -0000 Hi Ben > On Feb 7, 2015, at 07:13, Benjamin Kaduk wrote: >=20 > The unchanged text from RFC 5653 could also benefit from a general > copyediting pass, but I do not think I am prepared to perform one = during > the WGLC period. I will spend some time talking with my colleagues on your opinions on = stream-based methods. If we want to make any change on them, that will = be much bigger than the current new GSSException method. I don't want to = waste an RFC number if we have to modify the document again soon. Thanks Weijun From nobody Tue Feb 10 04:58:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20751A0231; Tue, 10 Feb 2015 04:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 IW89Id4JTd-5; Tue, 10 Feb 2015 04:58:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5FA1A019B; Tue, 10 Feb 2015 04:58:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210125851.17919.42918.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 04:58:51 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 12:58:53 -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 Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-06.txt Pages : 16 Date : 2015-02-09 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-06 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 Tue Feb 10 13:16:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582851A6FEF for ; Tue, 10 Feb 2015 13:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hZ06t5EdiPuc for ; Tue, 10 Feb 2015 13:16:40 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89CE1A6FCF for ; Tue, 10 Feb 2015 13:16:34 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-28-54da75304cae 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 A3.87.21729.0357AD45; Tue, 10 Feb 2015 16:16:32 -0500 (EST) 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 t1ALGVVO011069 for ; Tue, 10 Feb 2015 16:16:32 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1ALGUtY017439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Feb 2015 16:16:31 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1ALGTOO014090; Tue, 10 Feb 2015 16:16:29 -0500 (EST) Date: Tue, 10 Feb 2015 16:16:29 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUixG6nrmtQeivE4PQsYYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/2p58wFd/krtjVOZmpg7OLtYuTkkBAwkbi4YC47hC0mceHe erYuRi4OIYHFTBKvvt5hhHCOM0rcu/qXGcK5wSSx7/oXqLIGRomu5umMIP0sAtoSE+b+YQWx 2QRUJGa+2cgGYosICEvs3voOrFtYYAWjxKbz58GKOAWcJPqeNYIV8Qo4SLTcmgoWFxJwlJh2 aRvYUaICOhKr909hgagRlDg58wmYzSygJbF8+jaWCYwCs5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRroZebWaKXmlK6iREcgi6qOxgnHFI6xCjAwajEw1uQeDNEiDWxrLgy9xCj JAeTkigva+atECG+pPyUyozE4oz4otKc1OJDjBIczEoivP7xQDnelMTKqtSifJiUNAeLkjjv ph98IUIC6YklqdmpqQWpRTBZGQ4OJQnedcVAjYJFqempFWmZOSUIaSYOTpDhPEDDu0BqeIsL EnOLM9Mh8qcYFaXEeReDJARAEhmleXC9sBTxilEc6BVh3qcgVTzA9ALX/QpoMBPQ4IKCGyCD SxIRUlINjBPDJi5/veHTvR0HPGsllJ1XlEySDDfMPZkckXmOwUFfyZmD8b6mwByPuNN7nPxm 7HubalHNpGx1Zfdnf+Zl3E8nhbTf7e93TH98X1Tf31XBxnVeWZE48/8vk25zvH73Nti3hk/8 1cnOlboBv4RFpf5u/uF90zazxe3939vNx8yOtgWucI8zV2Ipzkg01GIuKk4EAIiyfxzsAgAA Archived-At: Subject: Re: [kitten] last week of WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 21:16:45 -0000 Reminder: only one week remains in these WGLCs. I believe we have not seen any comments on 6112bis yet; please consider commenting on it (and the other documents) if you have not already done so. -Ben On Tue, 20 Jan 2015, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) for the following > three documents: "A Pseudo-Random Function (PRF) for the Kerberos V > Generic Security Service Application Program Interface (GSS-API) > Mechanism" , "Generic Security Service > API Version 2: Java Bindings Update" , > and "Anonymity Support for Kerberos" . > Because there are three documents under review, and the whole body of the > documents are up for re-review (not just the updates), the WGLC is > extended to four weeks, so the WGLC will end on Tuesday February 17th, > 2015. The drafts are available at: > > http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 > > Please review these documents and send comments to the Working Group > mailing list kitten@ietf.org or the co-chairs > before the end of the WGLC. Any and all > comments on the document(s) are sought in order to assess the strength of > consensus. Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again. This is > particularly important if you found issues with the previous version. > > As a reminder, comments can be anything from "this looks fine" to "this is > a horrible idea"; they can include suggestions for minor editorial > corrections to significant editorial changes. > > > - Your Kitten Chairs > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Tue Feb 10 20:02:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8E91A00F5 for ; Tue, 10 Feb 2015 19:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3UGOgprXXTbP for ; Tue, 10 Feb 2015 19:54:20 -0800 (PST) Received: from amersmtp2.software.dell.com (amersmtp2.software.dell.com [12.106.87.227]) (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 98FA01A1B7E for ; Tue, 10 Feb 2015 19:54:18 -0800 (PST) Received: from amersmtp2.software.dell.com (127.0.0.1) id hrb96o0171sd for ; Tue, 10 Feb 2015 19:54:17 -0800 (envelope-from ) Received: from ALVHTXW01.prod.quest.corp ([10.1.135.17]) by amersmtp2.software.dell.com (SonicWALL 8.0.7.2831) with ESMTPS (version=TLSv1 cipher=AES128-SHA bits=128/128) id 201502110354170206853; Tue, 10 Feb 2015 19:54:17 -0800 Received: from ALVMBXW02.prod.quest.corp ([fe80::b862:2ecd:1237:d875]) by ALVHTXW01.prod.quest.corp ([::1]) with mapi id 14.03.0224.002; Tue, 10 Feb 2015 19:54:17 -0800 From: Thomas Maslen To: "kitten@ietf.org" Thread-Topic: [kitten] draft-ietf-kitten-rfc5653bis-02 review Thread-Index: AQHQRZiqtINAbwvb/kCw227JtWH+lA== Date: Wed, 11 Feb 2015 03:54:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 8.0.7.2831 X-Mlf-UniqueId: o201502110354170206853 Archived-At: X-Mailman-Approved-At: Tue, 10 Feb 2015 20:02:41 -0800 Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 03:54:23 -0000 On 10 Feb 2015 18:40:25 +0800, Wang Weijun wrote= =0A= (in response to one of Ben's review comments):=0A= > [...]=0A= > I will spend some time talking with my colleagues on your opinions on str= eam-based methods.=0A= =0A= For whatever it's worth...=0A= =0A= I agree with most of what Ben wrote in his review, particularly the long-st= anding text he flagged in RFC 2853 / 5653 / rfc5653bis which seems to assum= e that all tokens -- not just initial tokens -- received by GSSContext.init= SecContext() and GSSContext.acceptSecContext() use the mechanism-independen= t token format.=0A= =0A= However, I don't agree with this comment in the review:=0A= =0A= >> [...]=0A= >> Since this essentially involves generating byte-array tokens everywhere= =0A= >> and generating single-use streams from them, it makes me wonder what=0A= >> utility the stream forms of these routines provide.=0A= =0A= I believe that the "Since this essentially involves generating byte-array t= okens everywhere" premise isn't really true, and I believe that the stream-= based methods are definitely useful and don't need to be revisited.=0A= =0A= (Aside: now that I have read the sample code in RFC 2853 et seq for the st= ream-based methods, I see what led Ben to believe that this essentially inv= olves generating byte-array tokens everywhere, but I believe that's just a = problem with the usefulness of the sample code, not a problem with the usef= ulness of the stream-based methods).=0A= =0A= To me the stream-based methods are the fundamental form, whereas the byte-a= rray methods are just convenience methods: they provide a convenient but l= ess efficient alternative, and it wouldn't have been a tragedy if RFC 2853 = had omitted the byte-array methods and included only the stream-based metho= ds.=0A= =0A= Since I regard the byte-array methods as just convenience methods, I think = that it's nice if they can provide all the same functionality as the stream= -based methods but it definitely isn't a requirement -- to me it's OK if th= e byte-array methods don't support some more arcane cases.=0A= =0A= Given that, my reaction to the rfc5653bis drafts is similar (I think) to Gr= eg Hudson's comment on 1 Feb 2015: the stream-based methods already kinda = sorta provide a way to do this -- write the error token to the OutputStream= , then throw the GSSException. For me it's fine that only the stream-based= methods support this and the byte-array methods don't, but I understand th= at others may differ, including of course Weijun.=0A= =0A= w.r.t. the main change in the rfc5653bis drafts (i.e. adding the getOutputT= oken() method to GSSException), ideally I would like to see some tweaks:=0A= =0A= (1) In the updated example code for the stream-based methods, the "sendToke= n(new ByteArrayOutputStream(outTok));" code in the catch-block is bogus (an= d also won't compile), right?=0A= =0A= (2) [Perhaps someone already mentioned this one, maybe Greg?] The stream-b= ased methods now have two ways that they could convey an error token: eith= er write it to the OutputStream or return it in the GSSException (but not b= oth, I trust). I didn't notice any text that specifies (a) what the JGSS i= mplementation is required to do (and not do) w.r.t. this, and (b) what the = calling code should / shouldn't expect, but perhaps I overlooked it. Would= the rule be "If the implementation is generating an error token, it must n= ever write any bytes to the OutputStream, and must always return the token = in the GSSException", or something else?=0A= =0A= (3) GSSException is used throughout the JGSS API:=0A= =0A= http://docs.oracle.com/javase/7/docs/api/org/ietf/jgss/class-use/GS= SException.html=0A= =0A= but I assume that the only places where GSSException.getOutputToken() can b= e non-null (and calling code should handle it) are after the two initSecCon= text() methods and the two acceptSecContext() methods -- right? That's mor= e or less implicit in the current draft, but could the section 6.8 intro an= d / or section 6.8.7 be a bit more explicit that getOutputToke() is only pe= rtinent to initSecContext() and acceptSecContext() ?=0A= =0A= ... but none of them are anywhere close to being "over my dead body" issues= .=0A= =0A= Overall, given a choice between RFC 5653 and the current rfc5653bis drafts,= my 0.02 would be just to keep RFC 5653 as-is, but again that's just a mild= preference.=0A= From nobody Wed Feb 11 08:34:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579F21A8972 for ; Wed, 11 Feb 2015 08:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IxuNOtZFejAM for ; Wed, 11 Feb 2015 08:34:19 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC541A1A04 for ; Wed, 11 Feb 2015 08:33:27 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-31-54db8456dbda 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 A1.D4.21729.6548BD45; Wed, 11 Feb 2015 11:33:26 -0500 (EST) 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 t1BGXP2B003090; Wed, 11 Feb 2015 11:33:26 -0500 Received: from [18.101.8.241] (vpn-18-101-8-241.mit.edu [18.101.8.241]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1BGXNAE005719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Feb 2015 11:33:25 -0500 Message-ID: <54DB8453.4060607@mit.edu> Date: Wed, 11 Feb 2015 11:33:23 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Thomas Maslen , "kitten@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nohvWcjvEYN9aTYujm1exWLxubGJy YPJYsuQnk0ffMZcApigum5TUnMyy1CJ9uwSujFvzJrIWXOStaNpq0sC4mLuLkZNDQsBEYteu m8wQtpjEhXvr2boYuTiEBBYzSbQv/gzlbGSUOHN9LROEc4RJYtaCdWwgLbwCahKf571mBLFZ BFQlXi29CGazCShLrN+/lQXEFhUIk/i+eQczRL2gxMmZT8DiIgKJEnfOLGMCsYUFbCRWfJjE DmILCQRIPHnZCzaHUyBQYsrO+2A2s4CexI7rv1ghbHmJ5q2zmScwCsxCMnYWkrJZSMoWMDKv YpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3ECA5TF9UdjBMOKR1iFOBgVOLh9dh6 K0SINbGsuDL3EKMkB5OSKO+vptshQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4+bOAcrwpiZVV qUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErwKzUCNgkWp6akVaZk5JQhpJg5O kOE8QMPBaniLCxJzizPTIfKnGBWlxHkVQRICIImM0jy4XlgaecUoDvSKMK8jSBUPMAXBdb8C GswENLig4AbI4JJEhJRUA+OGR4IGV9fy8Gz6cXpPmMrBv3wH972tlGGbcXcnZ05w08m+xpzp ++4yWX5yudsY/OXf1UThVcadN3ccWFjkJeclWnj2eZ+2vUPiiiW2Nsc+CLkZsBQKXNBOOsCe ZMrX1fU+dHXazBdOh9Y/k5lz8VsU99UP4RdYmJwftVX9t5U/Pn31/HrRoxuUWIozEg21mIuK EwEnF7pH/gIAAA== Archived-At: Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 16:34:21 -0000 On 02/10/2015 10:54 PM, Thomas Maslen wrote: > I agree with most of what Ben wrote in his review, particularly the long-standing text he flagged in RFC 2853 / 5653 / rfc5653bis which seems to assume that all tokens -- not just initial tokens -- received by GSSContext.initSecContext() and GSSContext.acceptSecContext() use the mechanism-independent token format. [...] > I believe that the "Since this essentially involves generating byte-array tokens everywhere" premise isn't really true, and I believe that the stream-based methods are definitely useful and don't need to be revisited. [...] > To me the stream-based methods are the fundamental form, whereas the byte-array methods are just convenience methods: they provide a convenient but less efficient alternative, and it wouldn't have been a tragedy if RFC 2853 had omitted the byte-array methods and included only the stream-based methods. I am having trouble reconciling these statements. The issue with token framing is not just an issue with the wording in the RFC; it calls into question the whole mode of operation. An implementation of init/accept_sec_context cannot know how much data to read from the input stream in order to read a token, since GSS tokens do not necessarily have self-describing lengths. The only way this can really work is if the application cooperates by creating a single-use input stream which ends at the end of the token. Similarly, output tokens must be externally framed by the protocol. An application cannot simply provide its outgoing network buffer to init/accept_sec_context; it must package up the data written to the output stream and frame it. In effect, the output stream must be transformed into a byte array. From nobody Wed Feb 11 10:36:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B61A1A5B for ; Wed, 11 Feb 2015 10:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Gzoi58HbePR9 for ; Wed, 11 Feb 2015 10:36:02 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06AB1A1A83 for ; Wed, 11 Feb 2015 10:36:01 -0800 (PST) X-AuditID: 1209190c-f79696d000005933-a4-54dba1102e95 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.33.22835.011ABD45; Wed, 11 Feb 2015 13:36:00 -0500 (EST) 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 t1BIZxj7006858 for ; Wed, 11 Feb 2015 13:36:00 -0500 Received: from localhost (equal-rites.mit.edu [18.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 t1BIZwEL022277 for ; Wed, 11 Feb 2015 13:35:59 -0500 From: Greg Hudson To: kitten@ietf.org Date: Wed, 11 Feb 2015 13:35:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixG6nriuw8HaIwbnNChZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpyvT9gLVmpW/Lz4j62BcY9iFyMnh4SAicSs9TNZIGwxiQv3 1rN1MXJxCAksZpI4NGMzI4RznFHi9qd/7BBOB5PE3zPXWEFa2ASUJdbv3wrWLiIgLLF76ztm EFtYwEBib8d7MJtFQFXizKJ/YPW8AoYSPR07GSFsQYmTM5+A9TILSEgcfPGCeQIjzywkqVlI UgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIEhQenJM8OxjcHlQ4xCnAw KvHwemy9FSLEmlhWXJl7iFGSg0lJlHf9tNshQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4K2YB 5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHh3zAdqFCxKTU+tSMvM KUFIM3FwggznARpuuwBkeHFBYm5xZjpE/hSjopQ47wmQZgGQREZpHlwvLH5fMYoDvSLMewCk igcY+3Ddr4AGMwENnjgDbHBJIkJKqoHRQN6/9gK71In9c7TnrAqXuSulO+d2bnvj6tz8maud 5bIZVsaqBk85suywTqxYKntw/8Zc781sD7jsc6pZrvtenHAu+CRb2f2XVdz/dJzmJn7aJTZF ++3H90L5O+2Zjjx4WWZSfjLimpFv364FO/7xH49JObPwwP0FYsEmaXasD1el3RJcvslXiaU4 I9FQi7moOBEApu5JKLoCAAA= Archived-At: Subject: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 18:36:04 -0000 Nathaniel McCallum has been working on a Kerberos PAKE preauth mechanism (https://github.com/npmccallum/krb5-pake) which also supports a second factor value. Although there are many variables to how this mechanism could wind up working, we know that the exchange will end with the client sending a key confirmation and encrypted second factor (perhaps in addition to a client public value), and the KDC either issuing a ticket or an error. If the KDC implementation is careful enough about operating in constant time, the client doesn't find out whether it was wrong about the key or the second factor value. If the PAKE mechanism only requires two hops (as in SPAKE2), then we could theoretically fit the whole exchange into the same number of round trips as traditional encrypted timestamp: C: unauthenticated AS-REQ K: PREAUTH_REQUIRED (KDC public value in hint) C: AS-REQ (client public value, key confirmation, second factor) K: ticket or error Naively putting a KDC public value into a hint list isn't a great strategy for a preauth mech. Even with a modern group like Curve25519 the public value will take non-negligible time to compute and non-negligible space to transport. If there were many preauth mechs making this choice, the hint list would become large and expensive to produce. Also, if there is any kind of sub-negotiation within the preauth mech (curve choice, PAKE algorithm choice, etc.), this approach doesn't work. I think there are basically three options: 1. Add a third round trip. The exchange could look like this: C: unauthenticated AS-REQ K: PREAUTH_REQUIRED (empty hint) C: AS-REQ (client sub-negotiation parameters) K: MORE_PREAUTH_DATA_REQUIRED (KDC parameter choice, KDC public value) C: AS-REQ (client public value, key confirmation, second factor) K: ticket or error Other variations are possible--the KDC hint list could contain sub-negotiation parameters to be interpreted by the client, and the second client AS-REQ could contain a client public value for three-hop PAKE mechanisms. The point is that the KDC doesn't put much work or data into its hint list, and receives sub-negotiation parameters before it generates a public value. This approach fits solidly within the confines of RFC 6113 and (at least with an empty KDC hint) postpones almost all of the cost of the mech until after it is agreed upon by the client and KDC. The only real disadvantage is the extra latency of a third round trip. 2. Use pseudo-enctypes: C: unauthenticated AS-REQ (pseudo-enctypes in etype field) K: PREAUTH_REQUIRED (KDC public value in hint) C: AS-REQ (client public value, key confirmation, second factor) K: ticket or error Each pseudo-enctype indicates client support for the preauth mech and particular sub-negotiation parameters. Because the KDC knows the client supports the mech, it can suppress other preauth mechs in the hint list and generate a public value known to be compatible with the client's capabilities. There is some half-hearted precedent for this idea. RFC 4556 specifies some PKINIT pseudo-enctypes to indicate CMS algorithm support, but then immediately deprecates the practice and recommends the use of OIDs instead. Pseudo-enctypes are compact, and there is already support for them in the MIT krb5 client preauth framework because of PKINIT. However, this approach requires that every sub-negotiation parameter value be registered within the IANA Kerberos enctype registry; one can't use OIDs to name curves, for instance. And some people find it inelegant to use the enctype number space for purposes other than actual RFC 3961 encryption types. 3. Use client preauth hints: C: unauthenticate AS-REQ (padata containing sub-negotiation params) K: PREAUTH_REQUIRED (KDC public value in hint) C: AS-REQ (client public value, key confirmation, second factor) K: ticket or error In this strategy, the client includes an unsolicited padata value in its initial request which indicates support for the mechanism and contains sub-negotiation parameters. RFC 6113 does not currently envision this kind of client hint as part of preauth negotiation, so we would have to extend it. Clients would have to retry without hints if an older KDC rejects the unauthenticated AS-REQ with PREAUTH_FAILED; this is already required for clients implementing RFC 6806 FAST negotiation. The client hint value will inevitably be larger than a few pseudo-enctypes would be, especially if the sub-negotiation parameters could include multiple OID values. If several preauth mechanisms come into the world using non-trivial client hints, initial AS-REQs could grow larger than we might like. Otherwise, this approach has similar properties as option 2, but without requiring any abuse of the enctype number space. --- As I write this, I am leaning towards option 1. My only reservation is that I would like this mechanism to eventually displace encrypted timestamp in the Kerberos ecosystem, and it might be a shame to make essentially all password-based initial Kerberos authentications take three round trips. What are other people's thoughts? From nobody Wed Feb 11 11:01:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BB01A1B19 for ; Wed, 11 Feb 2015 11:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 poYmfUQokkef for ; Wed, 11 Feb 2015 11:01:14 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 2DFE11A0383 for ; Wed, 11 Feb 2015 11:01:14 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1BJ1DCb006493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Feb 2015 14:01:13 -0500 Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1BJ1CjJ019357; Wed, 11 Feb 2015 14:01:12 -0500 Message-ID: <1423681272.5770.5.camel@willson.usersys.redhat.com> From: Simo Sorce To: Greg Hudson Date: Wed, 11 Feb 2015 14:01:12 -0500 In-Reply-To: References: Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:01:16 -0000 On Wed, 2015-02-11 at 13:35 -0500, Greg Hudson wrote: > Nathaniel McCallum has been working on a Kerberos PAKE preauth mechanism > (https://github.com/npmccallum/krb5-pake) which also supports a second > factor value. Although there are many variables to how this mechanism > could wind up working, we know that the exchange will end with the > client sending a key confirmation and encrypted second factor (perhaps > in addition to a client public value), and the KDC either issuing a > ticket or an error. If the KDC implementation is careful enough about > operating in constant time, the client doesn't find out whether it was > wrong about the key or the second factor value. > > If the PAKE mechanism only requires two hops (as in SPAKE2), then we > could theoretically fit the whole exchange into the same number of round > trips as traditional encrypted timestamp: > > C: unauthenticated AS-REQ > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Naively putting a KDC public value into a hint list isn't a great > strategy for a preauth mech. Even with a modern group like Curve25519 > the public value will take non-negligible time to compute and > non-negligible space to transport. If there were many preauth mechs > making this choice, the hint list would become large and expensive to > produce. Also, if there is any kind of sub-negotiation within the > preauth mech (curve choice, PAKE algorithm choice, etc.), this approach > doesn't work. > > I think there are basically three options: > > 1. Add a third round trip. The exchange could look like this: > > C: unauthenticated AS-REQ > K: PREAUTH_REQUIRED (empty hint) > C: AS-REQ (client sub-negotiation parameters) > K: MORE_PREAUTH_DATA_REQUIRED (KDC parameter choice, KDC public value) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Other variations are possible--the KDC hint list could contain > sub-negotiation parameters to be interpreted by the client, and the > second client AS-REQ could contain a client public value for three-hop > PAKE mechanisms. The point is that the KDC doesn't put much work or > data into its hint list, and receives sub-negotiation parameters before > it generates a public value. > > This approach fits solidly within the confines of RFC 6113 and (at least > with an empty KDC hint) postpones almost all of the cost of the mech > until after it is agreed upon by the client and KDC. The only real > disadvantage is the extra latency of a third round trip. > > 2. Use pseudo-enctypes: > > C: unauthenticated AS-REQ (pseudo-enctypes in etype field) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Each pseudo-enctype indicates client support for the preauth mech and > particular sub-negotiation parameters. Because the KDC knows the client > supports the mech, it can suppress other preauth mechs in the hint list > and generate a public value known to be compatible with the client's > capabilities. > > There is some half-hearted precedent for this idea. RFC 4556 specifies > some PKINIT pseudo-enctypes to indicate CMS algorithm support, but then > immediately deprecates the practice and recommends the use of OIDs > instead. > > Pseudo-enctypes are compact, and there is already support for them in > the MIT krb5 client preauth framework because of PKINIT. However, this > approach requires that every sub-negotiation parameter value be > registered within the IANA Kerberos enctype registry; one can't use OIDs > to name curves, for instance. And some people find it inelegant to use > the enctype number space for purposes other than actual RFC 3961 > encryption types. > > 3. Use client preauth hints: > > C: unauthenticate AS-REQ (padata containing sub-negotiation params) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > In this strategy, the client includes an unsolicited padata value in its > initial request which indicates support for the mechanism and contains > sub-negotiation parameters. RFC 6113 does not currently envision this > kind of client hint as part of preauth negotiation, so we would have to > extend it. Clients would have to retry without hints if an older KDC > rejects the unauthenticated AS-REQ with PREAUTH_FAILED; this is already > required for clients implementing RFC 6806 FAST negotiation. > > The client hint value will inevitably be larger than a few > pseudo-enctypes would be, especially if the sub-negotiation parameters > could include multiple OID values. If several preauth mechanisms come > into the world using non-trivial client hints, initial AS-REQs could > grow larger than we might like. Otherwise, this approach has similar > properties as option 2, but without requiring any abuse of the enctype > number space. > > --- > > As I write this, I am leaning towards option 1. My only reservation is > that I would like this mechanism to eventually displace encrypted > timestamp in the Kerberos ecosystem, and it might be a shame to make > essentially all password-based initial Kerberos authentications take > three round trips. What are other people's thoughts? I strongly prefer 3. Clients can easily limit the amount of data they will send so I am not concerned that the AS_REQ will grow too much. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Feb 11 11:34:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC7F1A8ABF for ; Wed, 11 Feb 2015 11:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YFS-NCwe0x1v for ; Wed, 11 Feb 2015 11:34:08 -0800 (PST) Received: from amersmtp2.software.dell.com (amersmtp2.software.dell.com [12.106.87.227]) (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 0764D1A1A13 for ; Wed, 11 Feb 2015 11:34:07 -0800 (PST) Received: from amersmtp2.software.dell.com (127.0.0.1) id hrenb00171s3 for ; Wed, 11 Feb 2015 11:34:07 -0800 (envelope-from ) Received: from ALVHTXW02.prod.quest.corp ([10.1.135.18]) by amersmtp2.software.dell.com (SonicWALL 8.0.7.2831) with ESMTPS (version=TLSv1 cipher=AES128-SHA bits=128/128) id 201502111934070239357; Wed, 11 Feb 2015 11:34:07 -0800 Received: from ALVMBXW02.prod.quest.corp ([fe80::b862:2ecd:1237:d875]) by ALVHTXW02.prod.quest.corp ([::1]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 11:34:06 -0800 From: Thomas Maslen To: Greg Hudson , "kitten@ietf.org" Thread-Topic: [kitten] draft-ietf-kitten-rfc5653bis-02 review Thread-Index: AQHQRZiqtINAbwvb/kCw227JtWH+lJzsK9KA//+g7yU= Date: Wed, 11 Feb 2015 19:34:06 +0000 Message-ID: References: , <54DB8453.4060607@mit.edu> In-Reply-To: <54DB8453.4060607@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 8.0.7.2831 X-Mlf-UniqueId: o201502111934070239357 Archived-At: Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:34:11 -0000 On 11 Feb 2015 11:33:23 -0500, Greg Hudson wrote:=0A= > [...]=0A= > I am having trouble reconciling these statements.=0A= > =0A= > The issue with token framing is not just an issue with the wording in=0A= > the RFC; it calls into question the whole mode of operation. An=0A= > implementation of init/accept_sec_context cannot know how much data to=0A= > read from the input stream in order to read a token, since GSS tokens do= =0A= > not necessarily have self-describing lengths. The only way this can=0A= > really work is if the application cooperates by creating a single-use=0A= > input stream which ends at the end of the token.=0A= =0A= Yes but no:=0A= =0A= I agree that the application must create a single-use input stream which en= ds at the end of the token.=0A= =0A= But you can do that without having to read and buffer the token.=0A= =0A= It's easy enough to write a new subclass (I may as well call it BoundedInpu= tStream) that takes an underlying InputStream and a length count, and produ= ces an InputStream which lets you read that number of octets but no more (u= nless you go around it and get to the underlying InputStream).=0A= =0A= This is a pretty normal sort of thing to do in Java, and it's normal enough= that even JDK 1.0 had a convenience class -- http://docs.oracle.com/javase= /7/docs/api/java/io/FilterInputStream.html -- that acts as a helpful base c= lass for this sort of thing. (The standard subclasses of FilterInputStream= are mostly designed to munge the sequence of octets in the stream, not to = virtualize end-of-stream, but the general approach is similar).=0A= =0A= =0A= > Similarly, output tokens must be externally framed by the protocol. An= =0A= > application cannot simply provide its outgoing network buffer to=0A= > init/accept_sec_context; it must package up the data written to the=0A= > output stream and frame it. In effect, the output stream must be=0A= > transformed into a byte array.=0A= =0A= I agree that the argument is weaker for output tokens, because the majority= of application protocols that convey GSS tokens probably use simple framin= g where the token is preceded by a length count for the entire token -- so = yeah, in that case you're pretty much stuck with buffering the token in ord= er to determine its length, so you may as well have used the byte array ins= tead. Hypothetically an application protocol could use a chunked encoding,= e.g. ASN.1 indefinite-length or HTTP/1.1 chunking, and then you could writ= e a subclass of java.io.FilterOutputStream that only had to buffer up to so= me chunk size, not the whole token... but likely all non-hypothetical prot= ocols that use GSS tokens just use the simple whole-token length count?=0A= From nobody Wed Feb 11 13:19:35 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7381A1BDC for ; Wed, 11 Feb 2015 13:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 panMW0w0M_ew for ; Wed, 11 Feb 2015 13:19:30 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 626A61A1BF8 for ; Wed, 11 Feb 2015 13:19:29 -0800 (PST) X-AuditID: 12074422-f79d16d0000024cf-7d-54dbc7600945 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 4D.4E.09423.067CBD45; Wed, 11 Feb 2015 16:19:28 -0500 (EST) 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 t1BLJRGW031895 for ; Wed, 11 Feb 2015 16:19:28 -0500 Received: from localhost (equal-rites.mit.edu [18.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 t1BLJRiI021777 for ; Wed, 11 Feb 2015 16:19:27 -0500 From: Greg Hudson To: kitten@ietf.org Date: Wed, 11 Feb 2015 16:19:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6nrptw/HaIwe/TqhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvc1i5kLzvNV3Lp3iamB8Tl3FyMnh4SAicS1P9+YIGwxiQv3 1rN1MXJxCAksZpLo/PWLHcI5zijR8ayLFcLpYJLYPvU3K0gLm4CyxPr9W1lAbBEBYYndW98x g9jCAuYSq28fArNZBFQlFqw7DzSWg4NXwFBi6foQkDCvgKDEyZlPwFqZBSQkDr54wTyBkWcW ktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgoPDRWkH48+DSocY BTgYlXh4PbbeChFiTSwrrsw9xCjJwaQkyht59HaIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe xm1AOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCV6LY0CNgkWp6akV aZk5JQhpJg5OkOE8QMPLQGp4iwsSc4sz0yHypxgVpcR5ZUASAiCJjNI8uF5Y9L5iFAd6RZi3 E6SKBxj5cN2vgAYzAQ2eOANscEkiQkqqgbHealvpC+Vv53YzXry6/u0bRT0O3dBrvGwb1KR/ PU3cJGM1qXeO7xsjpfrG7z56e76U3q428Q4+8OzX3b8vrkw7v2tLOL/Krsn//QSyuTdf3neo 6Nfbv7rKLuaXe2fqFH7dezCM772w65wrkxrvHPr63Yn7c8xnhtpPzEXKOY/OKRo8nOX98sMi JZbijERDLeai4kQAF3zMA7kCAAA= Archived-At: Subject: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 21:19:34 -0000 draft-ietf-kitten-cammac is in the RFC editor queue, so I assume it's too late to make any non-trivial corrections, but we noticed an issue with the security considerations section when going over cross-realm scenarios. When we decided to make kdc-verifier optional, we provided guidance to KDC implementors to avoid attacks where services can forge CAMMAC data and get KDCs to put kdc-verifiers on them. So we wrote: The KDC MUST NOT create a new CAMMAC from an existing one unless the existing CAMMAC has a valid kdc-verifier, with two exceptions: 1. [Local TGTs under certain assumptions about realm KDCs] 2. [Ticket modification requests, but the KDC] MUST NOT place a kdc-verifier in the new CAMMAC. We missed a third case. If the header ticket is an incoming cross-realm TGT, any CAMMACs in that ticket can only be verified with the svc-verifier; the kdc-verifier, if present, will be signed with the foreign realm's local TGS key. (Section 4 makes it clear that the kdc-verifier always uses the local TGS key and the svc-veriifer uses the cross TGS key for cross-realm TGTs.) Nevertheless, the KDC may choose to filter and propagate CAMMAC-signed authdata originating from the foreign realm. For example, a KDC might choose to propagate authentication indicators, perhaps translating them into local realm indicator conventions, since only the foreign realm can know how the client originally authenticated. If the local KDC is propagating authdata originating from the foreign realm, it must place a local realm kdc-verifier on the CAMMAC it produces if the issued ticket might be used in an S4U2Proxy request. I suspect we will have to submit an errata for this, amending "two exceptions" to "three exceptions" and adding a third exception to cover the case of incoming cross-realm requests. From nobody Wed Feb 11 17:25:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731361A89A6; Wed, 11 Feb 2015 17:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iIJ_cTIY1P-r; Wed, 11 Feb 2015 17:24:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E30D1A8994; Wed, 11 Feb 2015 17:24:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40652BF07; Thu, 12 Feb 2015 01:25:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCgbQgAljB-Z; Thu, 12 Feb 2015 01:25:07 +0000 (GMT) Received: from [172.16.29.97] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 634D6BEEE; Thu, 12 Feb 2015 01:25:06 +0000 (GMT) Message-ID: <54DC00D0.2050900@cs.tcd.ie> Date: Thu, 12 Feb 2015 01:24:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "saag@ietf.org" , "kitten@ietf.org" , "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "kitten@ietf.org" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:24:47 -0000 Hiya, I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's needed for some work in http-auth but doesn't quite fit with any current WG. I plan to start an IETF LC for that shortly, but please do let me know if there are any issues. This was previously discussed on the kitten WG list, so (with the WG chairs' permission) I'd ask that you send any comments there if you've any before I start the IETF LC. (Reply-to is set to the kitten WG list.) Thanks, S. [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 From nobody Thu Feb 12 10:47:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885761A1AA4 for ; Thu, 12 Feb 2015 10:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7palQYzui0jT for ; Thu, 12 Feb 2015 10:47:16 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6A61A1B0B for ; Thu, 12 Feb 2015 10:47:16 -0800 (PST) X-AuditID: 1209190c-f79696d000005933-a6-54dcf5320646 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CA.4B.22835.335FCD45; Thu, 12 Feb 2015 13:47:15 -0500 (EST) 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 t1CIlEEA020101; Thu, 12 Feb 2015 13:47:14 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1CIlCvN020053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Feb 2015 13:47:13 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1CIlCgC027951; Thu, 12 Feb 2015 13:47:12 -0500 (EST) Date: Thu, 12 Feb 2015 13:47:12 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrWv89U6IwZQZLBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRnNDN0vBDeGKzua7LA2Mj/i7GDk5JARMJK7uPs4KYYtJXLi3 nq2LkYtDSGAxk8SGI/dZIJyNjBK7Gp4zQTiHmCQmzdsM5TQwSjzobmUH6WcR0Jb4sOQWI4jN JqAiMfPNRjYQW0RAUeL3yrdgcWYBYYn152Ywg9jCAi4SBx68AItzChhJrN0/FczmFXCQePP3 A1iNkIChxOV398HiogI6Eqv3T2GBqBGUODnzCQvETC2J5dO3sUxgFJyFJDULSWoBI9MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2M4MCU5NnB+Oag0iFGAQ5GJR7eAOM7IUKs iWXFlbmHGCU5mJREeTk+A4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8Kp/BMrxpiRWVqUW5cOk pDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwvgYZKliUmp5akZaZU4KQZuLgBBnOAzRc 6QvI8OKCxNzizHSI/ClGRSlx3rcgzQIgiYzSPLheWOJ4xSgO9Iow7zWQKh5g0oHrfgU0mAlo 8MQZt0EGlyQipKQaGNndzOf8ejN575KcUM7q7U+mfPuulLS65Jv690U58vMfNL+fMo1Jd9+s /Lj3P9W7WF9OD3rdLBdd0D6z/XaGFB9PTIzHjilV6mvCjRN+Mu3fyLGZ5ZnXxYuva9PkH2S9 v+0a3OB5677fsjZ+k8c/H2u3OtR97VmxL7l/MsOivdsvyaZ1L7l1vFKJpTgj0VCLuag4EQCV Gq5X9wIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 18:47:25 -0000 On Wed, 11 Feb 2015, Greg Hudson wrote: > draft-ietf-kitten-cammac is in the RFC editor queue, so I assume it's > too late to make any non-trivial corrections, but we noticed an issue > with the security considerations section when going over cross-realm > scenarios. It appears to not be too late. % The document draft-ietf-kitten-cammac-01 has changed from RFC-EDITOR % state to IESG state. We thought you'd like to know. You can also follow % your document's state at % . For % definitions of state names, please see: % . But, we should decide what new text we wish to insert. > When we decided to make kdc-verifier optional, we provided guidance to > KDC implementors to avoid attacks where services can forge CAMMAC data > and get KDCs to put kdc-verifiers on them. So we wrote: > > The KDC MUST NOT create a new CAMMAC from an existing one unless the > existing CAMMAC has a valid kdc-verifier, with two exceptions: > > 1. [Local TGTs under certain assumptions about realm KDCs] > > 2. [Ticket modification requests, but the KDC] MUST NOT place a > kdc-verifier in the new CAMMAC. > > We missed a third case. If the header ticket is an incoming cross-realm > TGT, any CAMMACs in that ticket can only be verified with the > svc-verifier; the kdc-verifier, if present, will be signed with the > foreign realm's local TGS key. (Section 4 makes it clear that the > kdc-verifier always uses the local TGS key and the svc-veriifer uses the > cross TGS key for cross-realm TGTs.) Nevertheless, the KDC may choose > to filter and propagate CAMMAC-signed authdata originating from the > foreign realm. For example, a KDC might choose to propagate > authentication indicators, perhaps translating them into local realm > indicator conventions, since only the foreign realm can know how the > client originally authenticated. If the local KDC is propagating > authdata originating from the foreign realm, it must place a local realm > kdc-verifier on the CAMMAC it produces if the issued ticket might be > used in an S4U2Proxy request. > > I suspect we will have to submit an errata for this, amending "two > exceptions" to "three exceptions" and adding a third exception to cover > the case of incoming cross-realm requests. Do you want to come up with a concrete proposal for new text? I agree that the change is needed. -Ben From nobody Thu Feb 12 12:34:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269DC1A1EB7 for ; Thu, 12 Feb 2015 12:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KhxmIOZNEOnX for ; Thu, 12 Feb 2015 12:34:09 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915221A6F3F for ; Thu, 12 Feb 2015 12:34:03 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-ee-54dd0e3ab7fd 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 E0.8F.21729.A3E0DD45; Thu, 12 Feb 2015 15:34:02 -0500 (EST) 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 t1CKY19p019025; Thu, 12 Feb 2015 15:34:02 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1CKXxl8016287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Feb 2015 15:34:01 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1CKXxT9012983; Thu, 12 Feb 2015 15:33:59 -0500 (EST) Date: Thu, 12 Feb 2015 15:33:59 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixG6nrmvFdzfEYOFBaYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr492/40wFJ/kqpsz9ytTAuJG7i5GTQ0LARKJv8l9mCFtM4sK9 9WxdjFwcQgKLmSRublzMDOFsZJS4tnA1E4RziEni49VZrBBOA6PE1a8HWUD6WQS0JWasf8EK YrMJqEjMfLORDcQWEVCU+L3yLSOIzSwgLLH+3AywfcICthKTb38HszkFjCSmTzrMBGLzCjhI PG6ZwA5iCwkYSnT++g7WKyqgI7F6/xQWiBpBiZMzn7BAzNSSWD59G8sERsFZSFKzkKQWMDKt YpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3ECA5MF9UdjBMOKR1iFOBgVOLhDTC+ EyLEmlhWXJl7iFGSg0lJlPcI190QIb6k/JTKjMTijPii0pzU4kOMEhzMSiK86h+BynlTEiur UovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHg5eYGGChalpqdWpGXmlCCkmTg4 QYbzAA23BanhLS5IzC3OTIfIn2JUlBLnZQBJCIAkMkrz4HphieMVozjQK8K87iBVPMCkA9f9 CmgwE9DgiTNugwwuSURISTUwdsd27LvO5bdQvu/hzcykb4a9m06d3OT8KbumKjusR9bIKDRu ggb3BwcW02Vyhf+fJrQs3ycj8D3q6Yl9e2XLmVQjN2d1PMiYErTFZn7pkdzesCnH13UcmM72 rymq7QG3rFNQ6VJl7/Am80JZ30NVrQIMZxeVf3/jxP3nhfw6xcy3zx3kLJyUWIozEg21mIuK EwE5+HEB9wIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 20:34:12 -0000 On Wed, 11 Feb 2015, Greg Hudson wrote: > 1. Add a third round trip. The exchange could look like this: > > C: unauthenticated AS-REQ > K: PREAUTH_REQUIRED (empty hint) > C: AS-REQ (client sub-negotiation parameters) > K: MORE_PREAUTH_DATA_REQUIRED (KDC parameter choice, KDC public value) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > 2. Use pseudo-enctypes: > > C: unauthenticated AS-REQ (pseudo-enctypes in etype field) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > 3. Use client preauth hints: > > C: unauthenticate AS-REQ (padata containing sub-negotiation params) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > --- > > As I write this, I am leaning towards option 1. My only reservation is > that I would like this mechanism to eventually displace encrypted > timestamp in the Kerberos ecosystem, and it might be a shame to make > essentially all password-based initial Kerberos authentications take > three round trips. What are other people's thoughts? I agree that (1) is the cleanest in terms of fitting into the existing structures. But, practical considerations of reducing the round-trip count may end up causing us to go with (3), which is also fairly elegant but has the wart of needing to update RFC 6113. I generally like to avoid changing existing specs that had a lot of thought go into them, but perhaps this is a minor enough change that it would be acceptable. Do you want to write a little bit about the existing pa-hint and how this new usage would differ from the current standardized usage? -Ben From nobody Thu Feb 12 13:21:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD011A1A39 for ; Thu, 12 Feb 2015 13:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 j5RlJ20pQ-OS for ; Thu, 12 Feb 2015 13:21:26 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644671A1A12 for ; Thu, 12 Feb 2015 13:21:26 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-1b-54dd1955283f 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.F6.08135.5591DD45; Thu, 12 Feb 2015 16:21:25 -0500 (EST) 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 t1CLLJJm026248; Thu, 12 Feb 2015 16:21:19 -0500 Received: from [18.101.8.113] (vpn-18-101-8-113.mit.edu [18.101.8.113]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1CLLHiQ003065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Feb 2015 16:21:19 -0500 Message-ID: <54DD194D.2010201@mit.edu> Date: Thu, 12 Feb 2015 16:21:17 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrhsqeTfE4Ms0IYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/HwP5aCRs6KxUffsjcwrmXvYuTkkBAwkVjStIEFwhaTuHBv PRuILSSwmEliY1diFyMXkL2RUWL1gR5WCOcIk0TLtGZWkCpeATWJP9PfgtksAqoS929PB+tm E1CWWL9/K9hUUYEwie+bdzBD1AtKnJz5BCwuIqAksfhsC1g9s4CwxIXte8HmCAu4SBx48IIR 4oo0iRe3P4NdyingKNG97DtUvZ7Ejuu/WCFseYnmrbOZJzAKzkKyYhaSsllIyhYwMq9ilE3J rdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIClZOSd4djO8OKh1iFOBgVOLhDTC+EyLE mlhWXJl7iFGSg0lJlLed726IEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe9Y9A5bwpiZVVqUX5 MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxGEkBDBYtS01Mr0jJzShDSTBycIMN5 gIa/Fgeq4S0uSMwtzkyHyJ9iVJQS5/0HkhAASWSU5sH1wpLJK0ZxoFeEeXNAVvAAExFc9yug wUxAgyfOuA0yuCQRISXVwOjr8HGL3/aumo02cd2zzlWzelx31+MXu5R/UXd7//2KxXIH7jfs WLIw2z3Kyfrbu2ebX7Aalm9d7xgVZJlX8vfjb/O0qsktpveDjFZemXFyr95v/R1GE7x9LFPs dU2S59tK/o55aVl7VHXq1y0PfNdpbY998VWyTVC0Z8qT0p1uqWf7QhSqopRYijMSDbWYi4oT Aa1394ABAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 21:21:29 -0000 On 02/12/2015 01:47 PM, Benjamin Kaduk wrote: > Do you want to come up with a concrete proposal for new text? Sure. In section 8 (Security Considerations), replace "two exceptions" with "three exceptions," and add a third item to the list: --- 3. If the ticket server principal is a cross-realm TGS from a different realm, the CAMMAC's kdc-verifier cannot be validated because the checksum was made using the other realm's local TGS key. If the CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely assumed to have originated from the other realm. The KDC SHOULD NOT blindly copy CAMMAC elements originating from another realm, but MAY choose to filter, transform, and propagate elements according to policy rules, and MAY place a kdc-verifier in the new CAMMAC containing the resulting authorization data elements. --- I use MUST NOT instead of SHOULD NOT because a KDC might be in a subsidiary relationship to a higher-security realm. By "cross-realm TGS from a different realm," I mean an incoming cross-realm krbtgt principal like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell that out. From nobody Thu Feb 12 14:39:20 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5AB1A1A31 for ; Thu, 12 Feb 2015 14:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rGUFLesD4M0q for ; Thu, 12 Feb 2015 14:39:16 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D331A1A0B for ; Thu, 12 Feb 2015 14:39:15 -0800 (PST) X-AuditID: 1209190e-f79bb6d0000030e8-98-54dd2b922854 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 42.07.12520.29B2DD45; Thu, 12 Feb 2015 17:39:14 -0500 (EST) 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 t1CMdEP6027653; Thu, 12 Feb 2015 17:39:14 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1CMdCKx002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Feb 2015 17:39:13 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1CMd9HC029657; Thu, 12 Feb 2015 17:39:09 -0500 (EST) Date: Thu, 12 Feb 2015 17:39:09 -0500 (EST) From: Benjamin Kaduk To: Thomas Maslen In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrDtJ+26IwZntRhZHN69isXjd2MTk wOSxZMlPJo++Yy4BTFFcNimpOZllqUX6dglcGYeXLmUueGVQ0bNrDVsD40n1LkZODgkBE4lp SycwQ9hiEhfurWfrYuTiEBJYzCRx+fQ2VpCEkMBGRomX56MhEoeYJB6e/cgCkWhglPh1QAPE ZhHQlji2+gMjiM0moCIx881GNhBbRMBY4tPS5WA2s4C6xLczb8BqhAVsJFZ8mMQOYnMKBEpM 2XkfLM4r4CCxcPseJoj5ARJPXvaCxUUFdCRW75/CAlEjKHFy5hMWiJlaEsunb2OZwCg4C0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrGermZJXqpKaWbGMFhKsm3g/HrQaVDjAIc jEo8vCtM74QIsSaWFVfmHmKU5GBSEuVt57sbIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV/0j UDlvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgSvvhbQUMGi1PTUirTM nBKENBMHJ8hwHqDhJSA1vMUFibnFmekQ+VOMilLivKtBEgIgiYzSPLheWBp5xSgO9Iow73mQ Kh5gCoLrfgU0mAlo8MQZt0EGlyQipKQaGGU5fyqfEHJqLv8T//320w0hFwMa3jKwLHGObDQo Wbz1UMHRogPzLh21DTdqXKuV/2Pu/peibYl86md8oy0U3tzc5mewwfKX3Iejj3okvrcZsvUy Mjp6Mfk+efU8c8k2xm7nDbKFct+/mU/au7Rs9sUJAT8W9bk87vEtP6hY1MHYcr7O9Lk+kxJL cUaioRZzUXEiAIuOkPD+AgAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:39:19 -0000 On Tue, 10 Feb 2015, Thomas Maslen wrote: > On 10 Feb 2015 18:40:25 +0800, Wang Weijun wrote > (in response to one of Ben's review comments): > > However, I don't agree with this comment in the review: > > >> [...] > >> Since this essentially involves generating byte-array tokens everywhere > >> and generating single-use streams from them, it makes me wonder what > >> utility the stream forms of these routines provide. > > I believe that the "Since this essentially involves generating > byte-array tokens everywhere" premise isn't really true, and I believe > that the stream-based methods are definitely useful and don't need to be > revisited. My statement was intentionally strong and intended to spark discussion :) It may well be that they should remain, but I do think that what we are doing right now in revisiting whether they have utility, is a discussion worth having. > (Aside: now that I have read the sample code in RFC 2853 et seq for the > stream-based methods, I see what led Ben to believe that this > essentially involves generating byte-array tokens everywhere, but I > believe that's just a problem with the usefulness of the sample code, > not a problem with the usefulness of the stream-based methods). This seems like a fine opportunity to improve the sample code, since we are doing the bis document. (ter, really, I guess...) > To me the stream-based methods are the fundamental form, whereas the > byte-array methods are just convenience methods: they provide a > convenient but less efficient alternative, and it wouldn't have been a > tragedy if RFC 2853 had omitted the byte-array methods and included only > the stream-based methods. > > Since I regard the byte-array methods as just convenience methods, I > think that it's nice if they can provide all the same functionality as > the stream-based methods but it definitely isn't a requirement -- to me > it's OK if the byte-array methods don't support some more arcane cases. I think that your sentiment is too strong to be supportable. While there is a strong sequencing requirement for context-level tokens (the negotiation loop proceeds in lockstep), and so a stream-based method would definitely be workaboe there, the per-message operations do not have that ordering requirement. I think it would be an unreasonable burden on an application to expect it to supply input streams to the per-message GSS operations which are guaranteed to only supply a single token. Even though it is possible to do, it requires a lot of effort to do correctly. Regarding whether either the byte-array or stream methods are just "convenience methods" around the other, I believe that since both are listed in the RFC, both must be considered as first-class methods that provide all the functionality of the underlying abstract GSS-API (RFC 2743) operations. I would not find it reasonable to provide reduced functionality in a standardized function like this. (Some implmentation could provide its own extension that has reduced functionality, of course, and that would be fine.) > Given that, my reaction to the rfc5653bis drafts is similar (I think) to > Greg Hudson's comment on 1 Feb 2015: the stream-based methods already > kinda sorta provide a way to do this -- write the error token to the > OutputStream, then throw the GSSException. For me it's fine that only > the stream-based methods support this and the byte-array methods don't, > but I understand that others may differ, including of course Weijun. My ideological preference would be consistency between the flavors, but I would accept a solution that explicitly spelled out that the stream-based methods handled error tokens in one way and the byte-array methods handled error tokens in a different way. The reason that I am arguing for the exception to carry the error token in the stream method is that it seems the best way to clearly spell out how to generate error tokens in the way which is most likely to be backwards-compatible. Having the implementation automatically insert the error token into the stream seems like it introduces a risk of duplicating the token (albeit a very small one), and I don't see that risk if the exception carries the token. > w.r.t. the main change in the rfc5653bis drafts (i.e. adding the > getOutputToken() method to GSSException), ideally I would like to see > some tweaks: > > (1) In the updated example code for the stream-based methods, the > "sendToken(new ByteArrayOutputStream(outTok));" code in the catch-block > is bogus (and also won't compile), right? > > (2) [Perhaps someone already mentioned this one, maybe Greg?] The > stream-based methods now have two ways that they could convey an error > token: either write it to the OutputStream or return it in the > GSSException (but not both, I trust). I didn't notice any text that Greg did mention this, yes. > specifies (a) what the JGSS implementation is required to do (and not > do) w.r.t. this, and (b) what the calling code should / shouldn't > expect, but perhaps I overlooked it. Would the rule be "If the > implementation is generating an error token, it must never write any > bytes to the OutputStream, and must always return the token in the > GSSException", or something else? I think the document would benefit from some more explicit text about what the implementation is expected to do, yes. > (3) GSSException is used throughout the JGSS API: > > http://docs.oracle.com/javase/7/docs/api/org/ietf/jgss/class-use/GSSException.html > > but I assume that the only places where GSSException.getOutputToken() > can be non-null (and calling code should handle it) are after the two > initSecContext() methods and the two acceptSecContext() methods -- > right? That's more or less implicit in the current draft, but could the > section 6.8 intro and / or section 6.8.7 be a bit more explicit that > getOutputToke() is only pertinent to initSecContext() and > acceptSecContext() ? I agree that the text should be more explicit about this, yes. Thank you for the review; these are definitely useful comments. -Ben From nobody Thu Feb 12 15:13:40 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C061A1B03 for ; Thu, 12 Feb 2015 15:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JCBWIZQIfoNL for ; Thu, 12 Feb 2015 15:13:36 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70281A0368 for ; Thu, 12 Feb 2015 15:13:34 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-eb-54dd339d44e9 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 26.A2.30099.D933DD45; Thu, 12 Feb 2015 18:13:33 -0500 (EST) 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 t1CNDRH3031309; Thu, 12 Feb 2015 18:13:27 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1CNDPQQ013826; Thu, 12 Feb 2015 18:13:26 -0500 From: Tom Yu To: Greg Hudson References: <54DD194D.2010201@mit.edu> Date: Thu, 12 Feb 2015 18:13:25 -0500 In-Reply-To: <54DD194D.2010201@mit.edu> (Greg Hudson's message of "Thu, 12 Feb 2015 16:21:17 -0500") Message-ID: Lines: 94 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUixCmqrDvX+G6IwYrjWhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxubps9kL3qpWNOxRaWCcJNfFyMkhIWAicX3TKWYIW0ziwr31 bCC2kMBiJon38/kg7I2MEmtml3YxcgHZbxglWrftBStiE5CWOH55FxOILSKgKPFs1VyWLkYO DmYBU4l/P6xAwsICLhIHHrxghJjTyijx41EuSAmLgKrE5lMuIGFOgTSJVStegk3kFdCVOLTt EdhEHgFOiZm9z1kh4oISJ2c+YQGxmQW0JG78e8k0gVFgFpLULCSpBYxMqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3RN9HIzS/RSU0o3MYKDTpJ/B+O3g0qHGAU4GJV4eAOM74QIsSaWFVfmHmKU 5GBSEuVt57sbIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV/0jUDlvSmJlVWpRPkxKmoNFSZx3 0w++ECGB9MSS1OzU1ILUIpisDAeHkgRvjBHQUMGi1PTUirTMnBKENBMHJ8hwHqDh5SA1vMUF ibnFmekQ+VOMilLivJEgCQGQREZpHlwvLCm8YhQHekWYNwqkigeYUOC6XwENZgIaPHHGbZDB JYkIKakGRpHvEseu+ej+mSVxdbbyNfWDHoHNfJWPp+/wr7DcWLO57l4w/4a3jrsVizhyQ3nW 9+g0tlekT2FtuVNzNu1nlaXdVb+dR3dM0zz8aqaOQ9PMkqi4W+ZCe35f9F590OruwljJs9eF VeTUTZaoHo/m6VVo2BQy9eCfE3P8zRemcmYvbZt07VTfFCWW4oxEQy3mouJEAALk22DlAgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 23:13:39 -0000 Greg Hudson writes: > On 02/12/2015 01:47 PM, Benjamin Kaduk wrote: >> Do you want to come up with a concrete proposal for new text? > > Sure. In section 8 (Security Considerations), replace "two exceptions" > with "three exceptions," and add a third item to the list: > > --- > 3. If the ticket server principal is a cross-realm TGS from a different > realm, the CAMMAC's kdc-verifier cannot be validated because the > checksum was made using the other realm's local TGS key. If the > CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely > assumed to have originated from the other realm. The KDC SHOULD NOT > blindly copy CAMMAC elements originating from another realm, but MAY > choose to filter, transform, and propagate elements according to policy > rules, and MAY place a kdc-verifier in the new CAMMAC containing the > resulting authorization data elements. > --- > > I use MUST NOT instead of SHOULD NOT because a KDC might be in a > subsidiary relationship to a higher-security realm. By "cross-realm TGS > from a different realm," I mean an incoming cross-realm krbtgt principal > like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell > that out. This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy" in your suggested text. Which did you intend? I would like to try to reason about this from a data origin authentication standpoint. This might help us come up with more clear and generally applicable wording. On the other hand, if we want to minimize textual changes, reasoning about this might help us avoid missing edge cases when we make the more minimal changes. The kdc-verifier provides data origin authentication that the CAMMAC contents originated from the KDC itself (or another KDC serving the same local realm). If the KDC successfully validates the kdc-verifier, it can copy the CAMMAC contents knowing that either it or another KDC in the realm originated the contents. There is also the local TGT special case. In the other cases, where it can only validate the svc-verifier, it must apply some policy about the provenance of the contents of the CAMMAC to decide whether to copy the contents verbatim, filter, or transform them. This includes both the non-S4U2Proxy service tickets and the cross-realm TGTs. Exception (1) in the document is for the case where the ticket-encrypting key is a key that only other KDCs in the local realm know, and therefore provides the same properties of data origin authentication that the kdc-verifier would. Exception (2) is different, because the KDC has no assurance that the CAMMAC contents originated from it or another KDC serving the same local realm. In this case, the KDC makes a policy decision that the only consumers of the possibly forged CAMMAC contents that it copies into a new CAMMAC are consumers that would not suffer adverse effects from such a forgery. In the cross-realm case, the local realm KDC can only validate the svc-verifier (because the only remote realm KDC can validate the kdc-verifier). The local realm KDC makes a policy decision about how to filter, transform, etc. the original CAMMAC contents to a new CAMMAC. I guess this is a roundabout way of suggesting text that includes: The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new CAMMAC when it cannot validate the original CAMMAC as authentically originating from itself or another KDC in its local realm. In such a situation, the KDC MAY choose to filter, transform, or propagate elements from the original CAMMAC to a new CAMMAC according to policy rules, and MAY place a kdc-verifier in the new CAMMAC containing the resulting authorization data elements. The two individually sufficient conditions for a KDC validating a CAMMAC as authentically originating from itself or another KDC in its local realm are: 1. The KDC successfully validates the kdc-verifier of the CAMMAC; or 2. The CAMMAC lacks a kdc-verifier, but the encryption key for its surrounding ticket is one known exclusively by the local realm KDCs (e.g., when the ticket is a local TGT), and all KDCs serving the realm are configured to filter out CAMMAC authorization data submitted by clients. Then we would somehow modify existing explanatory text about the specific use cases, e.g.: 1. omission of kdc-verifier to make TGTs, etc., smaller -- safe to make verbatim copies if the local realm KDCs are configured properly 2. omission of kdc-verifier when the only consumers of the CAMMAC are the original service principal of the ticket (no S4U2Proxy privileges) -- apply policy rules 3. incoming cross-realm TGTs -- apply policy rules From nobody Thu Feb 12 20:38:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053011A0086 for ; Thu, 12 Feb 2015 20:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8DQVqbi_J0tk for ; Thu, 12 Feb 2015 20:38:36 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079971A0081 for ; Thu, 12 Feb 2015 20:38:35 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-4b-54dd7fca5cd8 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 C5.5A.08135.ACF7DD45; Thu, 12 Feb 2015 23:38:34 -0500 (EST) 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 t1D4cSe4027155; Thu, 12 Feb 2015 23:38:29 -0500 Received: from [18.101.8.113] (vpn-18-101-8-113.mit.edu [18.101.8.113]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1D4cQdg007538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Feb 2015 23:38:28 -0500 Message-ID: <54DD7FC2.10104@mit.edu> Date: Thu, 12 Feb 2015 23:38:26 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tom Yu References: <54DD194D.2010201@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrHuq/m6Iwav9+hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq7+LawFD9kqpt1cwtLAuI61i5GTQ0LARGLihw4oW0ziwr31 bF2MXBxCAouZJHb1NYAlhAQ2MkosXZYKYR9hknhwTQHE5hVQkThx8zgLiM0ioCpx6N5PMJtN QFli/f6tYLaoQJjE9807mCHqBSVOznwCFhcRkJT4tmkqI4jNLGAscalnPdguYQEXiQMPXjBC 7FrMKHG6PRPE5hTQk+ifuJcJol5PYsf1X6wQtrzE9rdzmCcwCs5CsmIWkrJZSMoWMDKvYpRN ya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECA5VSd4djO8OKh1iFOBgVOLhfeF3N0SI NbGsuDL3EKMkB5OSKO/eOKAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4tdkA53pTEyqrUonyY lDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJ3pd1QI2CRanpqRVpmTklCGkmDk6Q4TxA w3+B1PAWFyTmFmemQ+RPMepyLGjfP5NJiCUvPy9VSpz3HEiRAEhRRmke3BxYinnFKA70ljCv GTDhCPEA0xPcpFdAS5iAlkyccRtkSUkiQkqqgXG5uXlm7enrX9YvlucRPX82tzekk32V6gal 8G9r9qo4s7/OUdnRZXWv03YGi9f2a3FmjG/rTDKEFF+tv+Sn6WGxZ5Pts8cnFVbnTnrgL/ty //YmyQN7J6ZWrV/butqd5cD/fpXudz9bP0+tYnFXvRzaszfaOZmlyfju9Rgev8K+kxtc/qyY 8V2JpTgj0VCLuag4EQAL9gw7DAMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 04:38:38 -0000 On 02/12/2015 06:13 PM, Tom Yu wrote: >> I use MUST NOT instead of SHOULD NOT because[...] > > This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy" > in your suggested text. Which did you intend? Sorry, editing error. I meant to say "I use SHOULD NOT instead of MUST NOT because...". > I would like to try to reason about this from a data origin > authentication standpoint. Your reasoning about data origin authentication matches my reasoning about the ways a KDC can safely process an incoming CAMMAC. > I guess this is a roundabout way of suggesting text that includes: I have no objection to this presentation and can review the full alternative section 8 text if you want to write it. I don't know if rewriting this much text would necessitate another working group or IETF last call; that might be a consideration. From nobody Fri Feb 13 07:37:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A508A1A8742 for ; Fri, 13 Feb 2015 07:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Ux6ncZTNPQvm for ; Fri, 13 Feb 2015 07:37:07 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (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 8AE1A1A874A for ; Fri, 13 Feb 2015 07:37:04 -0800 (PST) Received: by iebtr6 with SMTP id tr6so9767324ieb.10 for ; Fri, 13 Feb 2015 07:37:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9749Hhr9+4l6z887q+S7yTmao0lhOvoTPnLkBp6QYrM=; b=ZdjweslOSdtDzTlWTGAeSDRRZRxU16ebUvHzI5pHLY19hFwQ0/p1Zt4hQmj2PsYktQ SOAKkgwpoJZUsbNBG0StUyQOFhGQ4R94lglSZHIdPrdON3jSjExYjrqanOq8hFhUspOg b0Wb1a4c7EXmUTB1iOKhGTct98GS8qbPgIiUYSu73ZfGf3oYTvbXh8RJ1wQfasXKnPDp m7yf3lGm/5YYyGRolyeT7+qNmjRAoSpvSvGXlZjsCK/SCfhYeMPId1sIzBEWs+du1o1Y fn3gzwEMOd4qWHOlXa41pRhHxOueNYlB1A8zQhBDAuy5JF17oDX6HOWUs29AHiTTqC5P YGrQ== X-Gm-Message-State: ALoCoQnWDHlwT6GwajStk+OxEeLWHNUIupzcthsdDgjLy918UmKJ/C21E6UhZpYretta/5w5OrjR X-Received: by 10.107.134.160 with SMTP id q32mr12674994ioi.70.1423841822913; Fri, 13 Feb 2015 07:37:02 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j5sm4614069iod.31.2015.02.13.07.37.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 07:37:02 -0800 (PST) Message-ID: <54DE1A1C.6020908@andyet.net> Date: Fri, 13 Feb 2015 08:37:00 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> In-Reply-To: <54DC00D0.2050900@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 15:37:08 -0000 On 2/11/15 6:24 PM, Stephen Farrell wrote: > > Hiya, > > I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's > needed for some work in http-auth but doesn't quite fit with any > current WG. I plan to start an IETF LC for that shortly, but please > do let me know if there are any issues. > > This was previously discussed on the kitten WG list, so (with > the WG chairs' permission) I'd ask that you send any comments > there if you've any before I start the IETF LC. (Reply-to is > set to the kitten WG list.) This is a helpful document. Herewith a few comments. §2 For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers SHOULD announce a hash iteration-count of at least 4096. Because (per RFC 5082) it is mandatory for the server to announce a hash iteration-count, I'm wondering if that could be better expressed as: For the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms, the hash iteration-count announced by a server SHOULD be at least 4096. §3 It might be helpful here (or in the introduction) to describe why we need these mechanisms, i.e., presumably they might have stronger security properties or greater predicted longevity than the SCRAM mechanisms based on SHA-1. Nits: §1 mechanism are defined -> mechanisms are defined §4 I doubt that we need RFC 2119 language in the form. Peter From nobody Fri Feb 13 10:17:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB311A005F for ; Fri, 13 Feb 2015 10:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 g2oFP_J3mYCQ for ; Fri, 13 Feb 2015 10:16:56 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025BB1A00BD for ; Fri, 13 Feb 2015 10:16:55 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-16-54de3f9658ef 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 3D.36.21729.69F3ED45; Fri, 13 Feb 2015 13:16:54 -0500 (EST) 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 t1DIGslu028230 for ; Fri, 13 Feb 2015 13:16:54 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1DIGq3f027155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Feb 2015 13:16:53 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1DIGp11027091; Fri, 13 Feb 2015 13:16:51 -0500 (EST) Date: Fri, 13 Feb 2015 13:16:51 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <54CE9F5B.9070808@mit.edu> Message-ID: References: <54CE9F5B.9070808@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrTvN/l6IwfNvJhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxutFPxkLzvJWrH3+grmB8TlXFyMnh4SAicSWnQdYIGwxiQv3 1rN1MXJxCAksZpJY9e0HM4RznFGi989CVgjnBpPE0de72SGcBkaJyyuXsIP0swhoS3xYOJMZ xGYTUJGY+WYjG4gtIiAssXvrO7BRwgIzGSU6zzQzgSQ4BdQlpt/YCbScg4NXwEFi+dU4kLCQ QIzE/vNzwGaKCuhIrN4/Bew+XgFBiZMzn4DZzAJaEsunb2OZwCgwC0lqFpLUAkamVYyyKblV urmJmTnFqcm6xcmJeXmpRboWermZJXqpKaWbGEEByO6iuoNxwiGlQ4wCHIxKPLwTfO6GCLEm lhVX5h5ilORgUhLlfW95L0SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO9CLaAcb0piZVVqUT5M SpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr7wdUKNgUWp6akVaZk4JQpqJgxNkOA/Q 8CSQGt7igsTc4sx0iPwpRkUpcV4DkIQASCKjNA+uF5YgXjGKA70izOsPUsUDTC5w3a+ABjMB DZ444zbI4JJEhJRUA6Nj4Ypnagy3GGbM/p7EnvSjfJ3z4nD9921ZR79nPJIq2vZbZbeOkuyM +CV9R165z5AqKNrZLP3/foKIkQA36w9jc5aTP0+lmF6qXCw2rVySe+X+62ZCmyY/O7q80czU zEQvWeB3Y9jkpJW3GGq26RW/CSkMOSS5dLVcUI1gh9LxVvsSdd05tUosxRmJhlrMRcWJAOCn Ln7rAgAA Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:16:59 -0000 On Sun, 1 Feb 2015, Greg Hudson wrote: > On 01/20/2015 06:02 PM, Benjamin Kaduk wrote: > > http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 > > I reviewed this and did not find any problems with it. I also did not find any substantive issues with it. Some non-substantive issues are noted below. The reference for the Kerberos V GSS-API mechanism in section 1.1 seems to have changed from RFC 4121 to RFC 1964; is this a correct change? The RFC 2119 language conventions statement has been moved later in the document, after at least the first occurrence of "MUST". It would be nice to have the RFC 2119 text before the first use of its keywords. The original RFC 4402 security considerations include: [...] if an application can be tricked into providing very large input octet strings and requesting very long output octet strings, then that may constitute a denial of service attack on the application; therefore, applications SHOULD place appropriate limits on the size of any input octet strings received from their peers without integrity protection. It is not clear to me that integrity protection is sufficient to alleviate the denial of service attack, since verifying the message integrity may itself consume a substantial amount of resources. In the added text, % This document obsoletes RFC 4402 and reclassifies that document as % historic. RFC 4402 starts the PRF+ counter at 1, however a number % implementations starts the counter at 0. As a result, the original it should be "a number of implementations start" (add "of" and remove 's' from "starts") to be grammatical. Thanks again to Greg for supplying the test vectors. -Ben From nobody Fri Feb 13 11:33:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7CF1A0117 for ; Fri, 13 Feb 2015 11:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5y7N42H7hlts for ; Fri, 13 Feb 2015 11:32:55 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E8C1A0115 for ; Fri, 13 Feb 2015 11:32:54 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 6615ed45.0.4180537.00-2168.11530877.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 13 Feb 2015 19:32:55 +0000 (UTC) X-MXL-Hash: 54de51677357e5bd-732ec525ac66ca837b759504fc4dd78469159800 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DJWQhL005299 for ; Fri, 13 Feb 2015 14:32:53 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DIq6gK008818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 13 Feb 2015 13:52:07 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Fri, 13 Feb 2015 18:51:57 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DIpvXc031553 for ; Fri, 13 Feb 2015 13:51:57 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1DIpqfJ031337 for ; Fri, 13 Feb 2015 13:51:52 -0500 Received: from txcdtl01ks8671.itservices.sbc.com (txcdtl01ks8671.itservices.sbc.com?[135.110.240.237](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150213185150gw1000cebme>; Fri, 13 Feb 2015 18:51:51 +0000 X-Originating-IP: [135.110.240.237] Message-ID: <54DE47C6.4060609@att.com> Date: Fri, 13 Feb 2015 13:51:50 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54DE1A1C.6020908@andyet.net> In-Reply-To: <54DE1A1C.6020908@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=boL78jmi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mJp9S24oyUUA:10 a=UZBibCCZedwA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=AwGr7gOs] X-AnalysisOut: [GDYIhd7fnNoA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 19:32:57 -0000 Thanks Peter! More below. On 2/13/15 10:37 AM, Peter Saint-Andre - &yet wrote: > On 2/11/15 6:24 PM, Stephen Farrell wrote: >> >> Hiya, >> >> I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's >> needed for some work in http-auth but doesn't quite fit with any >> current WG. I plan to start an IETF LC for that shortly, but please >> do let me know if there are any issues. >> >> This was previously discussed on the kitten WG list, so (with >> the WG chairs' permission) I'd ask that you send any comments >> there if you've any before I start the IETF LC. (Reply-to is >> set to the kitten WG list.) > > This is a helpful document. Herewith a few comments. > > §2 > > For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers > SHOULD announce a hash iteration-count of at least 4096. > > Because (per RFC 5082) it is mandatory for the server to announce a > hash iteration-count, I'm wondering if that could be better expressed as: > > For the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms, the > hash iteration-count announced by a server SHOULD be at least 4096. ok > §3 > > It might be helpful here (or in the introduction) to describe why we > need these mechanisms, i.e., presumably they might have stronger > security properties or greater predicted longevity than the SCRAM > mechanisms based on SHA-1. I'll add the following to the introduction (gladly re-using your suggest words): SHA-256 has stronger security properties than SHA-1, and it is expected that SCRAM mechanisms based on it will have greater predicted longevity than the SCRAM mechanisms based on SHA-1. I don't think it's necessary to mention that the HTTP SCRAM document will probably reference it. Seem okay? > Nits: > > §1 > > mechanism are defined -> mechanisms are defined ack > §4 > > I doubt that we need RFC 2119 language in the form. While I might agree, that text is copied directly from RFC 5802. I don't feel strongly enough about the use of mustard there to worry about it. Tony From nobody Fri Feb 13 12:10:32 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A541A0118 for ; Fri, 13 Feb 2015 12:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 zcsgPZ2sehZL for ; Fri, 13 Feb 2015 12:10:17 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (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 3CD341A0270 for ; Fri, 13 Feb 2015 12:10:05 -0800 (PST) Received: by iecar1 with SMTP id ar1so22161482iec.11 for ; Fri, 13 Feb 2015 12:10:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3iuP85OcLIjcBbDQ6u/YdZCFuLaWKN6Qb9if4Gb5V2U=; b=beg0kXsOLXYelb3glxfDqUNaYuF2m6X5rdvcGiT2AYitl005krGd7pGwBO9WuKpdg4 UbGOkgMcMdQD/mX5UqthDO8ErQbuNqW5gNHZ8ZxZX4xrXB9UGwrkrh/nLfaiejypQE3L 6hpgx1z1Wfr3CcJYu++LNVPAICskgtIp8CBBNubaauWLDd7r7LiocgaO08OOMTva5+Zz ShUxd9fb6QjKf3VH+dW0I1+rfDjJLw+ppZUvrgyW5KmuuKMjo/4Y4eAyqt3ZchgSK1d/ t41s3qc1iQlGz2bWBRUalDaXTeJTai8tpU1NTPo+WqbkvlCGjLJxcYw45swIz1rwWFYx 0brQ== X-Gm-Message-State: ALoCoQmBe4XpBVFA3QA1llh8if11DddIaMqRi5H7MBT2AVq1mrHZBZ+N6Y/MJt2q5UxRyT1G52rq X-Received: by 10.43.66.9 with SMTP id xo9mr16483650icb.67.1423858204723; Fri, 13 Feb 2015 12:10:04 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id k12sm5015910iok.35.2015.02.13.12.10.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 12:10:04 -0800 (PST) Message-ID: <54DE5A0F.6090703@andyet.net> Date: Fri, 13 Feb 2015 13:09:51 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tony Hansen , "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54DE1A1C.6020908@andyet.net> <54DE47C6.4060609@att.com> In-Reply-To: <54DE47C6.4060609@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 20:10:23 -0000 Hi Tony, that all looks good! On 2/13/15 11:51 AM, Tony Hansen wrote: > Thanks Peter! > > More below. > > On 2/13/15 10:37 AM, Peter Saint-Andre - &yet wrote: >> On 2/11/15 6:24 PM, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's >>> needed for some work in http-auth but doesn't quite fit with any >>> current WG. I plan to start an IETF LC for that shortly, but please >>> do let me know if there are any issues. >>> >>> This was previously discussed on the kitten WG list, so (with >>> the WG chairs' permission) I'd ask that you send any comments >>> there if you've any before I start the IETF LC. (Reply-to is >>> set to the kitten WG list.) >> >> This is a helpful document. Herewith a few comments. >> >> §2 >> >> For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers >> SHOULD announce a hash iteration-count of at least 4096. >> >> Because (per RFC 5082) it is mandatory for the server to announce a >> hash iteration-count, I'm wondering if that could be better expressed as: >> >> For the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms, the >> hash iteration-count announced by a server SHOULD be at least 4096. > > ok > >> §3 >> >> It might be helpful here (or in the introduction) to describe why we >> need these mechanisms, i.e., presumably they might have stronger >> security properties or greater predicted longevity than the SCRAM >> mechanisms based on SHA-1. > > I'll add the following to the introduction (gladly re-using your suggest > words): > > SHA-256 has stronger security properties than SHA-1, and it is > expected that SCRAM > mechanisms based on it will have greater predicted longevity than > the SCRAM > mechanisms based on SHA-1. > > I don't think it's necessary to mention that the HTTP SCRAM document > will probably reference it. > > Seem okay? > >> Nits: >> >> §1 >> >> mechanism are defined -> mechanisms are defined > > ack > >> §4 >> >> I doubt that we need RFC 2119 language in the form. > > While I might agree, that text is copied directly from RFC 5802. I don't > feel strongly enough about the use of mustard there to worry about it. > > Tony From nobody Sat Feb 14 17:23:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BDD1A0126 for ; Sat, 14 Feb 2015 17:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cEM7yjuTZSfe for ; Sat, 14 Feb 2015 17:22:58 -0800 (PST) Received: from amersmtp2.software.dell.com (amersmtp2.software.dell.com [12.106.87.227]) (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 747951A00FE for ; Sat, 14 Feb 2015 17:22:57 -0800 (PST) Received: from amersmtp2.software.dell.com (127.0.0.1) id hrvqf40171sv for ; Sat, 14 Feb 2015 17:22:56 -0800 (envelope-from ) Received: from ALVHTXW02.prod.quest.corp ([10.1.135.18]) by amersmtp2.software.dell.com (SonicWALL 8.0.7.2831) with ESMTPS (version=TLSv1 cipher=AES128-SHA bits=128/128) id 201502150122560292199; Sat, 14 Feb 2015 17:22:56 -0800 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW02.prod.quest.corp ([::1]) with mapi id 14.03.0224.002; Sat, 14 Feb 2015 17:22:56 -0800 From: Thomas Maslen To: Benjamin Kaduk Thread-Topic: [kitten] draft-ietf-kitten-rfc5653bis-02 review Thread-Index: AQHQRZiqtINAbwvb/kCw227JtWH+lJzuJFmAgAKbcDI= Date: Sun, 15 Feb 2015 01:22:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 8.0.7.2831 X-Mlf-UniqueId: o201502150122560292199 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 01:23:01 -0000 On Thu, 12 Feb 2015, Benjamin Kaduk wrote:=0A= > [...]=0A= > While there is a strong sequencing requirement for context-level tokens= =0A= > (the negotiation loop proceeds in lockstep), and so a stream-based method= =0A= > would definitely be workaboe there, the per-message operations do not hav= e=0A= > that ordering requirement. I think it would be an unreasonable burden on= =0A= > an application to expect it to supply input streams to the per-message=0A= > GSS operations which are guaranteed to only supply a single token. Even= =0A= > though it is possible to do, it requires a lot of effort to do correctly.= =0A= =0A= Quite possibly I'm missing something obvious or just haven't thought this t= hrough, but:=0A= =0A= Even in really complex scenarios, e.g. running with requestSequenceDet(fals= e) + concurrent / unordered delivery of application messages from the peer = (e.g. using UDP or a separate TCP connection for each) + multiple threads o= perating concurrently to receive these application messages and present the= ir per-message tokens to the GSSContext instance, I believe that it's as ea= sy (or as difficult) to use the stream-based methods as it is to use the by= te-array methods.=0A= =0A= Possibly relevant: note that the spec (2853, 5653, 5653bis) doesn't promis= e anything about concurrency w.r.t. the methods of a GSSContext instance (n= or about anything else in the API, for that matter) -- in particular, the J= ava keyword "synchronized" doesn't appear anywhere. [Yes, it might be a go= od thing if this were more explicit in the spec, whereas at present it's ve= ry very implicit; by contrast, GSSContext's Javadoc in the JDK=0A= =0A= http://docs.oracle.com/javase/1.5.0/docs/api/org/ietf/jgss/GSSContext.h= tml=0A= =0A= comes right out and says "Also note that none of the methods in this interf= ace are synchronized. Therefore, it is not advisable to share a GSSContext = among several threads unless some application level synchronization is in p= lace"].=0A= =0A= The byte-array methods may intuitively seem to be kinda sorta "more atomic"= than the stream-based methods, but they aren't; if you're using multiple = threads to feed per-message tokens to a GSSContext instance then you're res= ponsible for serializing the calls, regardless of whether you're using the = byte-array methods or the stream-based methods.=0A= =0A= =0A= [Skipping...]=0A= =0A= > My ideological preference would be consistency between the flavors, but I= =0A= > would accept a solution that explicitly spelled out that the stream-based= =0A= > methods handled error tokens in one way and the byte-array methods handle= d=0A= > error tokens in a different way. The reason that I am arguing for the=0A= > exception to carry the error token in the stream method is that it seems= =0A= > the best way to clearly spell out how to generate error tokens in the way= =0A= > which is most likely to be backwards-compatible. Having the=0A= > implementation automatically insert the error token into the stream seems= =0A= > like it introduces a risk of duplicating the token (albeit a very small= =0A= > one), and I don't see that risk if the exception carries the token.=0A= =0A= I agree; if, per the rfc5653bis drafts, GSSException is extended to carry = the error token, then I think it's reasonable (and probably a good idea) to= say that the implementation should always convey the error token in the GS= SException, never in the OutputStream.=0A= =0A= [One caveat, but it's probably not worth worrying about because this may be= strictly hypothetical: if there are any cases where an existing JGSS impl= ementation has already been using the OutputStream to convey an error token= (because that was the only approach that was available in 2853 or 5653) an= d real application code has been making use of this, then we might be outla= wing something that has worked up until now... but my guess is that this i= s only a hypothetical concern].=0A= From nobody Sun Feb 15 18:00:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E407B1A1AC7 for ; Sun, 15 Feb 2015 18:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 weOTKhxmCY8M for ; Sun, 15 Feb 2015 18:00:37 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 994101A008A for ; Sun, 15 Feb 2015 18:00:37 -0800 (PST) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id EB3DC2005D828; Sun, 15 Feb 2015 18:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Cc/AUQTPPkySx1 mMd5efHoeGeSk=; b=ByAp5818N2buCZb+Drxa6n2DV6/mM8rtMacQOYeKLssLHT 9nApl+yMnQzj63ipQfJZlyylg0F55EIsFdd2giijpCjQo6mRH2fWQgJG1YtjdrDp agxrYF42m5t+15QIXyrQTUMfXckn4gjLjfP2T8NmBvqVVhNI2Fe3L+wfBzp1o= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id A11622005D81C; Sun, 15 Feb 2015 18:00:36 -0800 (PST) Date: Sun, 15 Feb 2015 20:00:36 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150216020035.GA5246@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 02:00:40 -0000 FYI, these are useful links for reviewing these I-Ds: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-kitten-rfc4402bis-00.txt http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-kitten-rfc5653bis-02.txt&url1=rfc5653.txt http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-kitten-rfc6112bis-00.txt From nobody Sun Feb 15 20:10:35 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8546B1A8732 for ; Sun, 15 Feb 2015 20:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 tcwFnYB5iORC for ; Sun, 15 Feb 2015 20:10:30 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 299171A19E4 for ; Sun, 15 Feb 2015 20:10:30 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id D5E752005693E; Sun, 15 Feb 2015 20:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nt4kWzlZtGU60P NCsyPtQmC9+Q4=; b=BREtFZgKmVFTDcMq3FFzMMJBDKhB/aghkQJx/7EcESz628 FPULBkrBmFlGIZWKCW8B2WADuujJLQZqxoP8vT6nAzl4+rylkn99W9gvwq4/n+Zz xLKhIkrtQljv8gcsRZhyCBUdF0mfuPQACmqtvVkMi43+zs4KtGzuRfuU5B3Iw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 84C2A20060013; Sun, 15 Feb 2015 20:10:29 -0800 (PST) Date: Sun, 15 Feb 2015 22:10:28 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150216041027.GB5246@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 04:10:33 -0000 Please forgive me for being so late with these reviews. On Tue, Jan 20, 2015 at 06:02:24PM -0500, Benjamin Kaduk wrote: > http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 FWIW, my only comment as to rfc4402bis is that rfc4402 wasn't "my" RFC, just an Internet RFC that I authored. Not sure if that's even a nit. > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 I've not reviewed the entirety of this document, just the docs from RFC5653 to rfc5653bis-02. Comments: My one comment on the changes is that having GSSException() constructors that take major and minor status code numbers seems... like a bad idea, particularly as to minor status codes. HOWEVER, since some implementations may use an all-Java GSSException class even with a JNI bindings for the rest of the API (or for specific mechanism providers), it seems like a good idea for that purpose. I don't think this is worth mentioning in the I-D; this is really just a comment for the mailing list archive. > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 Ditto here, I'm only reviewing the changes, not the entire I-D. Although I have one comment as to the original RFC: - Should we take this opportunity to define an AD to carry the PKINIT client cert and its validation cert chain (and trust anchor)? Regarding the change in section 4.2, the only reason for not reducing the MUST further to MAY is probably interoperability with TGSes that implemented the "MUST return a KRB-ERROR..." text that is being deleted. This seems to merit a mention, something like: If the ticket in the PA-TGS-REQ of the TGS request is an anonymous one, the client SHOULD set the anonymous KDC option in the request for interoperability with TGSes that insist on it. The TGS SHOULD ignore the presence/absence of the anonymous KDC option in the request when the the ticket in the request is an anonymous ticket. (Do we need to be more careful about defining "anonymous ticket"? Clearly this refers to tickets whose cname is anonymous, but in the user-to-user case the sname of the second ticket could be anonymous, and when we add post-dating, one could even have a TGS-REQ where the ticket has an anonymous sname. Such a request is bound to fail, and makes no sense anyways! This is just a twisted case just to demonstrate that it's the cname of a ticket that determines whether its an anonymous one or not. Just a curiosity.) Nico -- From nobody Sun Feb 15 20:21:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A5C1A8739 for ; Sun, 15 Feb 2015 20:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 f82VZA0e0b56 for ; Sun, 15 Feb 2015 20:21:09 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 20ECC1A8738 for ; Sun, 15 Feb 2015 20:21:09 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 036052004EE8B; Sun, 15 Feb 2015 20:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LXfoPi0EoZqOKD fkzXPUjPXpbyo=; b=MQOWqDhGjxPrdYCMoWxMJvqbt8D7QOFvxqYmxXZgkCZIR2 FaD2yxVmxQGH/pOdxVmS9JULs1HEcpvYQpfuPG1QE3nQ4Si5P4Z5KKarz9aAfwrX ARnh+/V42O/aupJnwPVtDvJAcNen3nm0JOsmPUmHL4udX1F1JGPJR6gn59mzg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 99FC22004EE8A; Sun, 15 Feb 2015 20:21:08 -0800 (PST) Date: Sun, 15 Feb 2015 22:21:08 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150216042107.GC5246@localhost> References: <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 04:21:10 -0000 On Fri, Feb 06, 2015 at 06:13:19PM -0500, Benjamin Kaduk wrote: > First, I should note that the Java bindings explicitly do not implement > GSS_Process_context_token. This does not directly affect any of the > [...] Perhaps not, but a Java equivalent for GSS_Process_context_token would be nice to have. > I have some serious concerns about the stream-based routines in general, > though. Section 6.4.5 (and 6.4.9) contain the text: > > The GSS-API authentication tokens contain a definitive start and end. > This method will attempt to read one of these tokens per invocation, > and may block on the stream if only part of the token is available. > > This is simply not true. Only the initial context token is required to > use the ASN.1-like framing; subsequent context tokens are known to be from > [...] I *think* what's happening here is that the streams in question are synthetic ones containing *only* the GSS tokens. Therefore there should be no framing issue. It's just a different way to represent a token. The use of streams can be helpful in some applications, I'm sure, and though an adaptor class would work just as well, these methods should result in less application code. That said, the use of streams strikes me as dangerous: in the presence of a self-framing mechanism, an application that passes in streams corresponding to the application protocol streams... would function correctly, whereas it would fail to work with non-self-framing mechanisms. (The GSI mechanism that uses TLS is a self-framing mechanism. When the application writes the tokens without further framing the result is TLS on the wire, even though a GSS interface is used!) > Finally, I believe I can say a bit more about keeping the transmission of > error tokens under the application's control even when streams are used. The above applies here as well. Nico -- From nobody Sun Feb 15 20:24:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EF1A8739 for ; Sun, 15 Feb 2015 20:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 qCfddoJFdBPl for ; Sun, 15 Feb 2015 20:24:57 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9C1A8734 for ; Sun, 15 Feb 2015 20:24:57 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 58CE82005E612; Sun, 15 Feb 2015 20:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+xxnujWf5SbPMT i6fdbjSKBx1M4=; b=sa6HbmONGYfL6wukMHtC6bt5iAUbPnJxGzacmIBLcy0taF NrvtuA4G8MRUI3EcKsvDWIxpy6plbz6fEVJh5TriyTRv9/kemmklCDGt4/CYi9MA 8yplrRiH0MvaU9+GlNo1+wzKRymEpjFzHfSiofo+fhG2x8EXe2fN3uQd0Nqqo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 1612D2005E607; Sun, 15 Feb 2015 20:24:57 -0800 (PST) Date: Sun, 15 Feb 2015 22:24:56 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150216042456.GD5246@localhost> References: <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com> <54D39523.5070700@mit.edu> <54D404FE.8010009@oracle.com> <54D40D6A.7010704@mit.edu> <54D4100E.7070200@oracle.com> <20150216042107.GC5246@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150216042107.GC5246@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 04:24:58 -0000 On Sun, Feb 15, 2015 at 10:21:08PM -0600, Nico Williams wrote: > That said, the use of streams strikes me as dangerous: in the presence > of a self-framing mechanism, an application that passes in streams > corresponding to the application protocol streams... would function > correctly, whereas it would fail to work with non-self-framing > mechanisms. > > (The GSI mechanism that uses TLS is a self-framing mechanism. When the > application writes the tokens without further framing the result is TLS > on the wire, even though a GSS interface is used!) That is, I am in favor of deprecating the methods dealing with streams, or at the very least adding text describing the framing issue and recommending (lower-case?) the use of memory-based, one-token-only streams. On the other hand, I do want to add a mechanism attribute for indicating that a mechanism's tokens are self-framed... Nico -- From nobody Mon Feb 16 01:48:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8107A1A879F; Mon, 16 Feb 2015 01:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 uKJvqLYjLIzI; Mon, 16 Feb 2015 01:48:43 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 F2EBC1A1A94; Mon, 16 Feb 2015 01:48:42 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1G9mQlW002499 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 10:48:27 +0100 From: Simon Josefsson To: Stephen Farrell References: <54DC00D0.2050900@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150216:saag@ietf.org::Jc2JG4WsjrZNwtiw:BHUR X-Hashcash: 1:22:150216:stephen.farrell@cs.tcd.ie::YPH3Px1gxiJuxrcN:5ofE X-Hashcash: 1:22:150216:kitten@ietf.org::ZDkkZ4ZLrYOkxmVC:NKIr X-Hashcash: 1:22:150216:http-auth@ietf.org::JYW4JhqrwSxgt6go:wIal Date: Mon, 16 Feb 2015 10:48:25 +0100 In-Reply-To: <54DC00D0.2050900@cs.tcd.ie> (Stephen Farrell's message of "Thu, 12 Feb 2015 01:24:32 +0000") Message-ID: <87r3tqqj9y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 09:48:44 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > Hiya, > > I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's > needed for some work in http-auth but doesn't quite fit with any > current WG. I plan to start an IETF LC for that shortly, but please > do let me know if there are any issues. Since SCRAM was published, we have learned that the tls-unique channel binding is insecure -- it would be nice if we could combine the SHA256 update with another default channel binding type to resolve that problem. In my view, the problem with SCRAM today isn't primarily its use of SHA1 but it's broken channel binding. A suggested (not even mandated) pbkdf iteration count of at least 4096 is unchanged since RFC 5802 -- I'd really like to see that be significantly higher. Back in 2000 an iteration count of 1000 was recommended as the minimum. Surely computational power has increased more than a factor of four since then. /Simon > This was previously discussed on the kitten WG list, so (with > the WG chairs' permission) I'd ask that you send any comments > there if you've any before I start the IETF LC. (Reply-to is > set to the kitten WG list.) > > Thanks, > S. > > [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU4bzpAAoJEIYLf7sy+BGdLJMH/2UVm1Cq+WobKXz4gg4SSPnq mm+Bv1cihrz5FF52mQwKyyjMS1Ww3ZqEl0WPr4aBnBYrV5MM2CR5M9DpO4Bpz1YA sGKFULzk6Y+h246VipIKpw370CTUST/hsB0gMf5fzvnlwPfHEttU1zyL/Ct+2l5/ nRnq93aok7q4BySTaZZn4ZsLzY3Y1cssu5+GrUiSZGnkMILpRpjj1P2hJMyY9A0u d7AQiBomHJZgNf5LJz/epkA7psp0cTW5qdxOqOOV9K4WCamlK3Jwf48qfJdDotJF dOjDuHOno0sCwQyloURg928VuYY7IyW+M093I0A5WcQM009nQtDdBAzIKFp0Te0= =aPqw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 16 02:55:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A791A0158; Mon, 16 Feb 2015 02:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 Z5iCQbaaK3W7; Mon, 16 Feb 2015 02:55:17 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 057FC1A87C6; Mon, 16 Feb 2015 02:55:16 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1GAsxsR009139 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 11:55:00 +0100 Date: Mon, 16 Feb 2015 11:54:57 +0100 From: Simon Josefsson To: Martin Thomson Message-ID: <20150216115457.3c16fdbf@latte.josefsson.org> In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Cj_a0vmV/eSiOCEMBWO5yhM"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:55:18 -0000 --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Mon, 16 Feb 2015 21:15:40 +1100 skrev Re: [saag] AD sponsoring draft-hansen-scram-sha256: > On 16 February 2015 at 20:48, Simon Josefsson > wrote: > > Since SCRAM was published, we have learned that the tls-unique > > channel binding is insecure -- it would be nice if we could combine > > the SHA256 update with another default channel binding type to > > resolve that problem. In my view, the problem with SCRAM today > > isn't primarily its use of SHA1 but it's broken channel binding. >=20 >=20 > We have a solution for that: > https://tools.ietf.org/html/draft-ietf-tls-session-hash Then SCRAM-SHA256 should normatively references that and require that it is implemented for secure use of SCRAM with channel bindings. There are drawbacks with that approach: it is not widely implemented, not published as an RFC that updates earlier TLS versions, and difficult for SCRAM implementers to validate (usually the TLS stack is opaque to the SCRAM implementer). I could live with that though, as a way of pushing the current security problem down from the IETF protocol layer into the implementation layer. Alternatively, use a new channel binding type that use the extended master secret derivation as described by the document above. I could update draft-josefsson-sasl-tls-cb to describe this approach. /Simon --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU4cyCAAoJEIYLf7sy+BGdc9EH/i0+0+gTBOFj5xqU9u8A3JpA exIv/q/HCpm6c4r9PjM9PA6DdqRPr9+bFl/o9h4UPsDw4Fwjny9WetPCUvzf4WFN eCnRQBzwyWVOoyjQftoWiDVFUVI7wJsEgOY1ynyB/br3uoOHtFueLSa9KIOur8aG +mtyBa8067RedRmMV3nRIQCZ/+x8Ui9A0Bwa0gHJ0QlRG7ZzxMP9cIzRvAMaLkrW dBMS3GQ38eTcOFt4lZYUhMPpa2ei7CtKNb6MNLmm1VtzwDhNt9X2V/gUwoFY/U7H krWO1dozYPta14qRrDsY1+wyWxxlWCYaxdaZRGcSC0XTxoW+9WPizXxWVrtKgrs= =85Yc -----END PGP SIGNATURE----- --Sig_/Cj_a0vmV/eSiOCEMBWO5yhM-- From nobody Mon Feb 16 03:10:35 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BE91A876E; Mon, 16 Feb 2015 03:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MQuxtGz1mgH9; Mon, 16 Feb 2015 03:10:13 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3044A1A8794; Mon, 16 Feb 2015 03:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424085006; d=isode.com; s=selector; i=@isode.com; bh=H2M622mg5Pj/fBD/ED7nkJsBaHoEU2Zj4EztCeOSPKg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=JFgBTqFpbCCBnUuEJcTlTPsZdm2TS6HzzndlOjyFEgAQ+wH5Z2OOo0kk2N2ggjd6jvNnk3 iEgrUiq1Irg5jhoeqlMJn3L5v70exejMcE3ZCuR6eyR4BF5rOmncLCuzuMvtoF9/0kLv+l CUnJQB/qKRnvprZ+AxJWPEuiyfA7AEs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Feb 2015 11:10:06 +0000 Message-ID: <54E1D009.2050408@isode.com> Date: Mon, 16 Feb 2015 11:10:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Simon Josefsson , Stephen Farrell References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> In-Reply-To: <87r3tqqj9y.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:10:22 -0000 Hi Simon, On 16/02/2015 09:48, Simon Josefsson wrote: [snip] > A suggested (not even mandated) pbkdf iteration count of at least 4096 > is unchanged since RFC 5802 -- I'd really like to see that be > significantly higher. Back in 2000 an iteration count of 1000 was > recommended as the minimum. Surely computational power has increased > more than a factor of four since then. I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number. From nobody Mon Feb 16 03:21:41 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E91A8825 for ; Mon, 16 Feb 2015 03:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 cLyHyyqZ1lG5 for ; Mon, 16 Feb 2015 03:21:36 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FA61A882A for ; Mon, 16 Feb 2015 03:21:34 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wo20so41161740obc.7 for ; Mon, 16 Feb 2015 03:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wgyXFE5xwyGIhKJiS4fp1H4E3c6EICG4Fgz5lzKMPAw=; b=JjR9sU3mxf3nYJQhDweL0DazRsbcWKsnw0pvph2t8LxRdA7WCfMk9kw+3JMz+gIxZa mE8/usiyrpoR4+fc9uMxMgvQdg2TS8BU8SBoD2OmDp+/prmgoOUva3tNjPpTHoejHFPL Q2OfGOg/UpYQ2wt8/vD2Zi/CE8zevNQUHLT3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wgyXFE5xwyGIhKJiS4fp1H4E3c6EICG4Fgz5lzKMPAw=; b=ZMGjqTVMYRUmbSoU4RR3OjO7wDmXSdgNwWGVAxr/04YlelZPV0ZSw7LHZrCncDA4V3 Vs6QWRYPZE+k0NnduTXl5TssmzKiBjKHL9extacVhp79n/8rT7hMpFCj80Kd3PSeI3y+ wHm4CDrT8YDdZ2LKz/dazNivczizyip+N6CaGxyJ8wieyLVwnkLolj6YhNTxC3WtxTEL +EGtiDOdgqQsmA+W8Ud3YnpjTm/4faucTwEpBuaf8XGyLC6key77IPKa/lbh6Qfl1j5G Cjnu8md6OR9Q+c5zbDgaO7+dhKHlogR427cU6HNRMLoUJ/jcL23pYIUw+kjq0pQOMCTs q+0w== X-Gm-Message-State: ALoCoQn54mDhMLR+Ve0EiyTw+m1xSeghdbIqD4MIYij5x5Y9SuEE/ucSBua7cTGspgI3fmdF0iWC MIME-Version: 1.0 X-Received: by 10.202.52.215 with SMTP id b206mr14131825oia.31.1424085693831; Mon, 16 Feb 2015 03:21:33 -0800 (PST) Received: by 10.60.77.71 with HTTP; Mon, 16 Feb 2015 03:21:33 -0800 (PST) Received: by 10.60.77.71 with HTTP; Mon, 16 Feb 2015 03:21:33 -0800 (PST) In-Reply-To: <54E1D009.2050408@isode.com> References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> Date: Mon, 16 Feb 2015 11:21:33 +0000 Message-ID: From: Dave Cridland To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a113cd412e936aa050f32c9c1 Archived-At: Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:21:38 -0000 --001a113cd412e936aa050f32c9c1 Content-Type: text/plain; charset=UTF-8 On 16 Feb 2015 11:10, "Alexey Melnikov" wrote: > > Hi Simon, > > On 16/02/2015 09:48, Simon Josefsson wrote: > [snip] > >> A suggested (not even mandated) pbkdf iteration count of at least 4096 >> is unchanged since RFC 5802 -- I'd really like to see that be >> significantly higher. Back in 2000 an iteration count of 1000 was >> recommended as the minimum. Surely computational power has increased >> more than a factor of four since then. > > I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number. > Worth asking in the XSF, there's likely to be implementation experience from the Android client devs there. However, clients need only do the iterations once, if the salt is stable, at least in principle. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --001a113cd412e936aa050f32c9c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Feb 2015 11:10, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:
>
> Hi Simon,
>
> On 16/02/2015 09:48, Simon Josefsson wrote:
> =C2=A0[snip]
>
>> A suggested (not even mandated) pbkdf iteration count of at least = 4096
>> is unchanged since RFC 5802 -- I'd really like to see that be<= br> >> significantly higher.=C2=A0 Back in 2000 an iteration count of 100= 0 was
>> recommended as the minimum.=C2=A0 Surely computational power has i= ncreased
>> more than a factor of four since then.
>
> I've heard complains from developers that 4096 with SHA-1 is too h= igh for current Android phones. It would be good to get more information on= performance before changing the number.
>

Worth asking in the XSF, there's likely to be implementa= tion experience from the Android client devs there.

However, clients need only do the iterations once, if the sa= lt is stable, at least in principle.

>
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.i= etf.org/mailman/listinfo/kitten

--001a113cd412e936aa050f32c9c1-- From nobody Mon Feb 16 03:23:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7051A8824; Mon, 16 Feb 2015 03:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 cGA1zhoDn4xb; Mon, 16 Feb 2015 03:23:06 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 70AF61A8834; Mon, 16 Feb 2015 03:23:05 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:2999:8dd0:70ed:36a2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1GBMsio012070 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Feb 2015 12:22:55 +0100 From: Simon Josefsson To: Alexey Melnikov References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150216:kitten@ietf.org::EWdwoo552beHa/0b:WT X-Hashcash: 1:22:150216:http-auth@ietf.org::F8s7r/08HLa4mUxC:29gH X-Hashcash: 1:22:150216:saag@ietf.org::uPGbsf7wXCavTt7U:3dcZ X-Hashcash: 1:22:150216:alexey.melnikov@isode.com::/LkbAKUNDiSHfRjc:2A1c X-Hashcash: 1:22:150216:stephen.farrell@cs.tcd.ie::swRGKVSRaHsx72yf:Bmtq Date: Mon, 16 Feb 2015 12:22:53 +0100 In-Reply-To: <54E1D009.2050408@isode.com> (Alexey Melnikov's message of "Mon, 16 Feb 2015 11:10:01 +0000") Message-ID: <87iof2qewi.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:23:07 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov writes: > Hi Simon, > > On 16/02/2015 09:48, Simon Josefsson wrote: > [snip] >> A suggested (not even mandated) pbkdf iteration count of at least 4096 >> is unchanged since RFC 5802 -- I'd really like to see that be >> significantly higher. Back in 2000 an iteration count of 1000 was >> recommended as the minimum. Surely computational power has increased >> more than a factor of four since then. > I've heard complains from developers that 4096 with SHA-1 is too high > for current Android phones. It would be good to get more information > on performance before changing the number. You will always hear complaints from developers that security features adds computational and other resource costs. When that happens, I prefer asking myself whether the threat model motivates the cost or not. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU4dMNAAoJEIYLf7sy+BGdIAEH+wQRkqNucW+OSk7yZc6dRTyZ 6xHI/xsD8Vg1PjQ12ED7ixYlgEdpcuFOtUt+tPy9hqgDVQcs/Uojmk8HAIcCLhee Z7n3WQnnbBXIGaKYzZeBZWu6dcmBAiQU+S3bldYXoKGrYoH67l1qhInidqgO4hgs dedmZcFj6RxFnFt3vpO4MZvEy2iQKpQJ+179spNhbMDKa0obgofdwhcWKcOkz5GI G3IUHocYVjJZmrPJp2D5jlsh9y59VoV0sWH5/jP++qgyC81r9bj42fIkl/oQbjBz OrPQAOI9j8ZE4mRMjs37tFO//l4N8l+ixyDpAhWRfYN6NPcPgPD9bgoWfMc2bDo= =kxUe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 16 07:48:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C281A887F; Mon, 16 Feb 2015 02:15:44 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 j5g2BK_dJm4i; Mon, 16 Feb 2015 02:15:42 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 ACD631A87A9; Mon, 16 Feb 2015 02:15:41 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so40571463obc.1; Mon, 16 Feb 2015 02:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vo+4Lhm2eqkgleBGICOexNOG5aGtpXcl63DV5Rvgeic=; b=eK95kgCRWN4PB30Ggwu9iN+2jHD2scpX8zRn/zdMpy8YXPFhClF/Zeczc8/3EjVqW/ jbuKwYpy9nuqGlB6UB179onkTCJdEYSbRTc/8NxVKR2Bq5+2sYVGsbT94n2AL1q1f+k8 uZAvw8gDtH0qK5hvjSVXdEZjYQ7kalfsdxjw9dDZhF8MA1A+1dBKiH42RgjO0yZ8alMW b+PD3reDG28r9KKWApi1VWH4qORPOmEHJAy0/1yy3g6UcQb3HVrpS7G0nYMxl4VP4PYj 9um7bIySXjgExeillaoP/VbJOeSPJ2arBuVeV42pYgCSsMNLrdoPxe+13kUr7BwykFa3 WhFw== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr13992334oib.94.1424081740941; Mon, 16 Feb 2015 02:15:40 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 16 Feb 2015 02:15:40 -0800 (PST) In-Reply-To: <87r3tqqj9y.fsf@latte.josefsson.org> References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> Date: Mon, 16 Feb 2015 21:15:40 +1100 Message-ID: From: Martin Thomson To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Mon, 16 Feb 2015 07:48:21 -0800 Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 10:15:44 -0000 On 16 February 2015 at 20:48, Simon Josefsson wrote: > Since SCRAM was published, we have learned that the tls-unique channel > binding is insecure -- it would be nice if we could combine the SHA256 > update with another default channel binding type to resolve that > problem. In my view, the problem with SCRAM today isn't primarily its > use of SHA1 but it's broken channel binding. We have a solution for that: https://tools.ietf.org/html/draft-ietf-tls-session-hash From nobody Mon Feb 16 20:12:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F791A8703 for ; Mon, 16 Feb 2015 20:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Up1VlIEbZXKu for ; Mon, 16 Feb 2015 20:12:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9466F1A8701 for ; Mon, 16 Feb 2015 20:12:30 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1H4CTxR030202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Feb 2015 04:12:29 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1H4CSs7024908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Feb 2015 04:12:29 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1H4CS7n026824 for ; Tue, 17 Feb 2015 04:12:28 GMT Received: from [10.159.84.144] (/10.159.84.144) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Feb 2015 20:12:28 -0800 Message-ID: <54E2BFE4.4000003@oracle.com> Date: Mon, 16 Feb 2015 21:13:24 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20150125 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <54CE9F5B.9070808@mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Subject: Re: [kitten] draft-ietf-kitten-rfc4402bis-00 (was: Re: WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 04:12:32 -0000 Thanks for your review, comments in-line... On 02/13/15 11:16 AM, Benjamin Kaduk wrote: > On Sun, 1 Feb 2015, Greg Hudson wrote: > >> On 01/20/2015 06:02 PM, Benjamin Kaduk wrote: >>> http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 >> I reviewed this and did not find any problems with it. > I also did not find any substantive issues with it. Some non-substantive > issues are noted below. > > > The reference for the Kerberos V GSS-API mechanism in section 1.1 seems to > have changed from RFC 4121 to RFC 1964; is this a correct change? Good catch. The XML source obtained referenced this back when it was a draft. I've updated accordingly. > > The RFC 2119 language conventions statement has been moved later in the > document, after at least the first occurrence of "MUST". It would be nice > to have the RFC 2119 text before the first use of its keywords. Yes, this is awkward. I've updated accordingly. > The original RFC 4402 security considerations include: > > [...] if an > application can be tricked into providing very large input octet > strings and requesting very long output octet strings, then that may > constitute a denial of service attack on the application; therefore, > applications SHOULD place appropriate limits on the size of any input > octet strings received from their peers without integrity protection. > > It is not clear to me that integrity protection is sufficient to alleviate > the denial of service attack, since verifying the message integrity may > itself consume a substantial amount of resources. I interpret this statement differently: If integrity protection is not enforced then an attacker can construct an arbitrarily long string. > In the added text, > > % This document obsoletes RFC 4402 and reclassifies that document as > % historic. RFC 4402 starts the PRF+ counter at 1, however a number > % implementations starts the counter at 0. As a result, the original > > it should be "a number of implementations start" (add "of" and remove 's' > from "starts") to be grammatical. > > > Thanks again to Greg for supplying the test vectors. ...and also to Nico who verified the vectors in Heimdal. Eventual shepherd should take note... Shawn. -- From nobody Tue Feb 17 08:14:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B865F1A8904 for ; Tue, 17 Feb 2015 08:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IJBtLr1FnKfp for ; Tue, 17 Feb 2015 08:14:52 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 3E4801A8AB3 for ; Tue, 17 Feb 2015 08:14:46 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1HGEiGd006026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 17 Feb 2015 11:14:45 -0500 Received: from vpn-50-159.rdu2.redhat.com (vpn-50-159.rdu2.redhat.com [10.10.50.159]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1HGEcw5012734 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Feb 2015 11:14:42 -0500 Message-ID: <1424189675.2645.23.camel@redhat.com> From: Nathaniel McCallum To: Greg Hudson Date: Tue, 17 Feb 2015 11:14:35 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:14:57 -0000 On Wed, 2015-02-11 at 13:35 -0500, Greg Hudson wrote: > Nathaniel McCallum has been working on a Kerberos PAKE preauth > mechanism (https://github.com/npmccallum/krb5-pake) which also > supports a second factor value. Although there are many variables > to how this mechanism could wind up working, we know that the > exchange will end with the client sending a key confirmation and > encrypted second factor (perhaps in addition to a client public > value), and the KDC either issuing a ticket or an error. If the KDC > implementation is careful enough about operating in constant time, > the client doesn't find out whether it was wrong about the key or > the second factor value. > > If the PAKE mechanism only requires two hops (as in SPAKE2), then we > could theoretically fit the whole exchange into the same number of > round trips as traditional encrypted timestamp: > > C: unauthenticated AS-REQ > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Naively putting a KDC public value into a hint list isn't a great > strategy for a preauth mech. Even with a modern group like > Curve25519 the public value will take non-negligible time to compute > and non-negligible space to transport. If there were many preauth > mechs making this choice, the hint list would become large and > expensive to produce. Also, if there is any kind of sub-negotiation > within the preauth mech (curve choice, PAKE algorithm choice, etc.), > this approach doesn't work. > > I think there are basically three options: > > 1. Add a third round trip. The exchange could look like this: > > C: unauthenticated AS-REQ > K: PREAUTH_REQUIRED (empty hint) > C: AS-REQ (client sub-negotiation parameters) > K: MORE_PREAUTH_DATA_REQUIRED (KDC parameter choice, KDC public > value) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Other variations are possible--the KDC hint list could contain sub- > negotiation parameters to be interpreted by the client, and the > second client AS-REQ could contain a client public value for three- > hop PAKE mechanisms. The point is that the KDC doesn't put much > work or data into its hint list, and receives sub-negotiation > parameters before it generates a public value. > > This approach fits solidly within the confines of RFC 6113 and (at > least with an empty KDC hint) postpones almost all of the cost of > the mech until after it is agreed upon by the client and KDC. The > only real disadvantage is the extra latency of a third round trip. > > 2. Use pseudo-enctypes: > > C: unauthenticated AS-REQ (pseudo-enctypes in etype field) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Each pseudo-enctype indicates client support for the preauth mech > and particular sub-negotiation parameters. Because the KDC knows > the client supports the mech, it can suppress other preauth mechs in > the hint list and generate a public value known to be compatible > with the client's capabilities. > > There is some half-hearted precedent for this idea. RFC 4556 > specifies some PKINIT pseudo-enctypes to indicate CMS algorithm > support, but then immediately deprecates the practice and recommends > the use of OIDs instead. > > Pseudo-enctypes are compact, and there is already support for them > in the MIT krb5 client preauth framework because of PKINIT. > However, this approach requires that every sub-negotiation parameter > value be registered within the IANA Kerberos enctype registry; one > can't use OIDs to name curves, for instance. And some people find > it inelegant to use the enctype number space for purposes other than > actual RFC 3961 encryption types. > > 3. Use client preauth hints: > > C: unauthenticate AS-REQ (padata containing sub-negotiation > params) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > In this strategy, the client includes an unsolicited padata value in > its initial request which indicates support for the mechanism and > contains sub-negotiation parameters. RFC 6113 does not currently > envision this kind of client hint as part of preauth negotiation, so > we would have to extend it. Clients would have to retry without > hints if an older KDC rejects the unauthenticated AS-REQ with > PREAUTH_FAILED; this is already required for clients implementing > RFC 6806 FAST negotiation. > > The client hint value will inevitably be larger than a few pseudo- > enctypes would be, especially if the sub-negotiation parameters > could include multiple OID values. If several preauth mechanisms > come into the world using non-trivial client hints, initial AS-REQs > could grow larger than we might like. Otherwise, this approach has > similar properties as option 2, but without requiring any abuse of > the enctype number space. > > --- > > As I write this, I am leaning towards option 1. My only reservation > is that I would like this mechanism to eventually displace encrypted > timestamp in the Kerberos ecosystem, and it might be a shame to make > essentially all password-based initial Kerberos authentications take > three round trips. What are other people's thoughts? I see 1 and 3 as the only good options. Having to register group parameters instead of using OIDs is a deal-breaker in my book. 1 and 3 are also compatible workflows. In 3, the first AS-REQ is exactly the same padata as the second AS-REQ in 1. That is to say, 3 is an optimization of 1 where the first round-trip of 1, which includes no meaningful data, is simply not used. Put another way, 3 is just 1 with optimistic preauth. So a KDC can actually implement both 1 and 3 simultaneously. If the KDC does not receive the padata in the first step (option 3), it generates the empty hint (option 1). Otherwise, 1 and 3 are identical. Only one thing differs: PREAUTH_REQUIRED or MORE_PREAUTH_DATA_REQUIRED. Can we just always use the latter error? The problem, as Greg rightly notes, is that a client cannot know if the KDC supports the PAKE preauth mech and will have to handle PREAUTH_FAILED properly. After thinking about this (and implementing it), I think the best way forward is 1 with 3 as an optional optimization. The KDC should always support both 1 and 3; adding support for (optional) 3 should be trivial. Clients should choose whether or not to support 3 based on complexity of implementation; 3 can always be added later as an optimization. Nathaniel From nobody Tue Feb 17 09:28:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98D81A1B5C for ; Tue, 17 Feb 2015 09:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 xxjiVdDMUjz1 for ; Tue, 17 Feb 2015 09:27:53 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 89A771A1B51 for ; Tue, 17 Feb 2015 09:27:53 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 37351360075; Tue, 17 Feb 2015 09:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=7QmPKojYhaSzOH VonUjAWNp9ChQ=; b=mTQnQ1kyESUG7pw5VBQiWscQo7CVgH8iPWUGjrIvtzglJC I+s1vNCAPU/qiT8UcwpevqEf7VggE88t1OLq7WPBH15FjWh1Q7tioYE7ITOkIFM/ +tzQq8W2BN/uCt4Alz8FuNYQTGjhmU/oX1FazhSZ16WHFNxUOlkinT18kdsik= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id E31B2360059; Tue, 17 Feb 2015 09:27:52 -0800 (PST) Date: Tue, 17 Feb 2015 11:27:52 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20150217172751.GG5246@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:27:55 -0000 On Wed, Feb 11, 2015 at 01:35:58PM -0500, Greg Hudson wrote: > If the PAKE mechanism only requires two hops (as in SPAKE2), then we > could theoretically fit the whole exchange into the same number of round > trips as traditional encrypted timestamp: > > C: unauthenticated AS-REQ > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Naively putting a KDC public value into a hint list isn't a great > strategy for a preauth mech. Even with a modern group like Curve25519 > the public value will take non-negligible time to compute and > non-negligible space to transport. If there were many preauth mechs > making this choice, the hint list would become large and expensive to > produce. Also, if there is any kind of sub-negotiation within the > preauth mech (curve choice, PAKE algorithm choice, etc.), this approach > doesn't work. Agreed. (For some two-round-trip PAKEs the amount of work to do on the first go could be negligible, but nonetheless, the remaining points apply.) > I think there are basically three options: > > 1. Add a third round trip. The exchange could look like this: This has the advantage of having a return routability check built-in so that the AS doesn't spend too many resources computing public values for a client that isn't there to complete the exchange. At a minimum, an over-worked AS should have an option to force the additional round-trip. > 2. Use pseudo-enctypes: > > C: unauthenticated AS-REQ (pseudo-enctypes in etype field) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > Each pseudo-enctype indicates client support for the preauth mech and > particular sub-negotiation parameters. Because the KDC knows the client > supports the mech, it can suppress other preauth mechs in the hint list > and generate a public value known to be compatible with the client's > capabilities. > > There is some half-hearted precedent for this idea. RFC 4556 specifies > some PKINIT pseudo-enctypes to indicate CMS algorithm support, but then > immediately deprecates the practice and recommends the use of OIDs > instead. Not just that, but this approach has been used to extend other protocols (e.g., TLS). > Pseudo-enctypes are compact, and there is already support for them in > the MIT krb5 client preauth framework because of PKINIT. However, this > approach requires that every sub-negotiation parameter value be > registered within the IANA Kerberos enctype registry; one can't use OIDs > to name curves, for instance. And some people find it inelegant to use > the enctype number space for purposes other than actual RFC 3961 > encryption types. I don't mind this too much. A problem with (2) is that if we ever need more than "which PAKEs does the client support" hints, then (2) will be insufficient. Or perhaps we'll have a bit of a cartesian explosion (PAKEs x curves). Or perhaps we'll end up with many pseudo-enctypes for hinting (one set for PAKEs, another for curves, ...). > 3. Use client preauth hints: > > C: unauthenticate AS-REQ (padata containing sub-negotiation params) > K: PREAUTH_REQUIRED (KDC public value in hint) > C: AS-REQ (client public value, key confirmation, second factor) > K: ticket or error > > In this strategy, the client includes an unsolicited padata value in its > initial request which indicates support for the mechanism and contains > sub-negotiation parameters. RFC 6113 does not currently envision this > kind of client hint as part of preauth negotiation, so we would have to > extend it. Clients would have to retry without hints if an older KDC > rejects the unauthenticated AS-REQ with PREAUTH_FAILED; this is already > required for clients implementing RFC 6806 FAST negotiation. I don't mind this either. It is decidedly more elegant. The 1-round-trip penalty when talking to older KDCs will vanish when those are upgraded. > The client hint value will inevitably be larger than a few > pseudo-enctypes would be, especially if the sub-negotiation parameters I don't think this need be inevitable. See comment above about cartesian explosions in (2). > could include multiple OID values. If several preauth mechanisms come If we use OIDs for PAKEs and curves, then yeah, the hints in (3) could get large! :) (This is a bad joke about space inefficiency of OIDs.) We've talked about using relative OIDs, but the problem with those (or integers, bits in a bit string, ...) is that they really force use to have a registry. > into the world using non-trivial client hints, initial AS-REQs could > grow larger than we might like. Otherwise, this approach has similar > properties as option 2, but without requiring any abuse of the enctype > number space. If the only things the client has to send a priori were a set of PAKEs and a set of curves, then the hints can be fairly space efficient. If we need a cartesian explosion (e.g., if some PAKEs are not orthogonal to the choice of curve) then hints have to get large in the long run anyways. > --- > > As I write this, I am leaning towards option 1. My only reservation is > that I would like this mechanism to eventually displace encrypted > timestamp in the Kerberos ecosystem, and it might be a shame to make > essentially all password-based initial Kerberos authentications take > three round trips. What are other people's thoughts? Why not (3)? It too will cost 3 round trips _at first_, but will eventually improve to 2 round trips as KDCs are upgraded. Seems like a win to me. I don't mind (2) much either, but on the whole I prefer (3), mostly because it will allow us to make registration optional (if we use OIDs) and because it will allow the hint data structure to evolve in ways that pseudo-enctypes simply can't. Nico -- From nobody Tue Feb 17 09:30:20 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F309D1A88BA for ; Tue, 17 Feb 2015 09:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 KE5QucLFZQ_c for ; Tue, 17 Feb 2015 09:30:18 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E5C3C1A8832 for ; Tue, 17 Feb 2015 09:30:18 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id A0F6C2004EE08; Tue, 17 Feb 2015 09:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=p/UfDyLb2j8Ve/ mybExhFUYYvGE=; b=KOAS3sQ1IUitAwLGKi7UybffYohZ4CuwI3CJaWl0ll3X2b 6Y0iMT0a9yy8INzqIFV77yXZLyq0XC/4Z6t9UzueDh2wUoBZ6XgandZ2vMgakwG0 K6UFWczkem3kbdG4+T6dJ6ms72rqQW9ZCF8eu7xtj1DGvsePe+uFIXCLQ+o1w= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 3AC652005D82D; Tue, 17 Feb 2015 09:30:18 -0800 (PST) Date: Tue, 17 Feb 2015 11:30:17 -0600 From: Nico Williams To: Simo Sorce Message-ID: <20150217173017.GH5246@localhost> References: <1423681272.5770.5.camel@willson.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1423681272.5770.5.camel@willson.usersys.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:30:20 -0000 On Wed, Feb 11, 2015 at 02:01:12PM -0500, Simo Sorce wrote: > I strongly prefer 3. > Clients can easily limit the amount of data they will send so I am not > concerned that the AS_REQ will grow too much. Ah, because they can always try multiple times, but with (1) each additional attempt costs an additional round-trip, thus making any trade-off of request size to round trip count seem much less worthwhile. Nico -- From nobody Tue Feb 17 09:37:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956331A8F3E for ; Tue, 17 Feb 2015 09:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 7G7lqMGvb3jQ for ; Tue, 17 Feb 2015 09:37:14 -0800 (PST) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBFF1A893A for ; Tue, 17 Feb 2015 09:37:14 -0800 (PST) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 7D2602005E807; Tue, 17 Feb 2015 09:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0SrjakXsddEUma VxkQzF1RRGf60=; b=MHHGn/Q4QSet+AJQ8aFzPWUMHyluOGNWcevjb5/LEMPLpk oTU69QytXRTpr0mqEMppjHt4hOdZjJnYgm+uwFKW8pyPbt/AMNGrJOCl0t3X4CxU bEBTS6KL/ohsZrtTluDJeLTq1LnxrvzPekhGRMVz1laUaoCwczf+iKs7cwioE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id 2038B2005E801; Tue, 17 Feb 2015 09:37:14 -0800 (PST) Date: Tue, 17 Feb 2015 11:37:13 -0600 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150217173713.GI5246@localhost> References: <1424189675.2645.23.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424189675.2645.23.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:37:15 -0000 On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum wrote: > I see 1 and 3 as the only good options. Having to register group > parameters instead of using OIDs is a deal-breaker in my book. I also prefer not to have to add registration of groups. I'm not sure that I want to have any support for negotiable group parameters though, if that's what you meant. I'd rather have well-known curves (groups) suitable for discrete codepoint assignments regardless of whether we have/need a registry. However, a single popular use case for negotiable groups will make (2) utterly inapplicable, and that's the best case for not considering (2), IMO. On the whole I prefer (3). I agree that it's an optimization that could come later though. But it's also an optimization that clients could implement immediately (with the fallback penalty); it's only the AS where more work is needed. Nico -- From nobody Tue Feb 17 09:58:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7957D1A896A for ; Tue, 17 Feb 2015 09:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ed3cZ4rW7R50 for ; Tue, 17 Feb 2015 09:58:22 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 A1B811A1EE8 for ; Tue, 17 Feb 2015 09:58:22 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1HHwLTQ019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 17 Feb 2015 12:58:21 -0500 Received: from vpn-50-159.rdu2.redhat.com (vpn-50-159.rdu2.redhat.com [10.10.50.159]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1HHwJZT020961 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Feb 2015 12:58:20 -0500 Message-ID: <1424195899.2645.36.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Tue, 17 Feb 2015 12:58:19 -0500 In-Reply-To: <20150217173713.GI5246@localhost> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:58:24 -0000 On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum wrote: > > I see 1 and 3 as the only good options. Having to register group > > parameters instead of using OIDs is a deal-breaker in my book. > > I also prefer not to have to add registration of groups. I'm not > sure that I want to have any support for negotiable group parameters > though, if that's what you meant. I'd rather have well-known curves > (groups) suitable for discrete codepoint assignments regardless of > whether we have/need a registry. That was not what I meant. I meant parameters of the exchange. Current parameters are: * PAKE method (currently: SPAKE and JPAKE; needs registration) * Group (currently: only standardized elliptic curve groups) * Hash (currently: MD5, SHA1, SHA2-*) Currently, I advertise these as: PAKEInfo ::= SEQUENCE { ptypes SEQUENCE (SIZE(1..MAX)) OF Int32, supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport, ... } PAKESupport ::= SEQUENCE { etype Int32, groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, ... } The drawback to this approach is that groups or hashes supported by multiple enctypes get listed multiple times. However, this also captures that some groups/hashes are only usable for some enctypes. Generally this relates to key size and protects large keys from being generated by small curves. I'm open to alternatives. > However, a single popular use case for negotiable groups will make > (2) utterly inapplicable, and that's the best case for not > considering (2), IMO. +1 > On the whole I prefer (3). I agree that it's an optimization that > could come later though. But it's also an optimization that clients > could implement immediately (with the fallback penalty); it's only > the AS where more work is needed. Having implemented it, the AS side is easy. The client is harder. That is at least the case on the MIT codebase. I suspect it is true of all implementations. Nathaniel From nobody Tue Feb 17 10:30:53 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583D1A1B51; Tue, 17 Feb 2015 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 3Y21PTB_x7oL; Tue, 17 Feb 2015 10:30:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE121A1F01; Tue, 17 Feb 2015 10:30:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217183049.25985.6083.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 10:30:49 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:30:50 -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 Working Group of the IETF. Title : Authentication Indicator in Kerberos Tickets Authors : Anupam Jain Nathan Kinder Nathaniel McCallum Filename : draft-ietf-kitten-krb-auth-indicator-00.txt Pages : 5 Date : 2015-02-17 Abstract: This document proposes an extension in the Kerberos protocol [RFC4120]. It defines a new Authorization Data Type AD- AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in the service tickets so that the application services can use it as an input into policy decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 11:58:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004AA1A884E for ; Tue, 17 Feb 2015 11:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 vFmbO5dSyr1o for ; Tue, 17 Feb 2015 11:58:20 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4C1A1AFA for ; Tue, 17 Feb 2015 11:58:20 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 63AA62004F4DE; Tue, 17 Feb 2015 11:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Bc3OZ7Vef793AW TTZR/RS/zsTE0=; b=vw9aTFdJaQQ3qtPxgG1d8M1pZQyHK8RgEHY0kyWziJFCcR U0eRly/Qf5DZPGRMzu8LkOcn5gFdytzFn+R6xl20PYHgEaoiQppO1BzYFiYAmmvJ v2fG5lW3CVVdvqWGiz5w04Q6jI2b/QB6tiUZL6FfjPGzRM/6htAgsMMh9SCu0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 0951A2004F4CA; Tue, 17 Feb 2015 11:58:19 -0800 (PST) Date: Tue, 17 Feb 2015 13:58:19 -0600 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150217195815.GJ5246@localhost> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424195899.2645.36.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 19:58:22 -0000 On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum wrote: > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum wrote: > > > I see 1 and 3 as the only good options. Having to register group > > > parameters instead of using OIDs is a deal-breaker in my book. > > > > I also prefer not to have to add registration of groups. I'm not > > sure that I want to have any support for negotiable group parameters > > though, if that's what you meant. I'd rather have well-known curves > > (groups) suitable for discrete codepoint assignments regardless of > > whether we have/need a registry. > > That was not what I meant. I meant parameters of the exchange. Current > parameters are: > * PAKE method (currently: SPAKE and JPAKE; needs registration) > * Group (currently: only standardized elliptic curve groups) > * Hash (currently: MD5, SHA1, SHA2-*) [I covered that elsewhere.] Assuming these are all orthogonal (they should be), then pseudo-enctypes work, but need a registry. OIDs are much better (though larger) because we can then outsource the registry to CFRG and friends. > Currently, I advertise these as: > > PAKEInfo ::= SEQUENCE { > ptypes SEQUENCE (SIZE(1..MAX)) OF Int32, > supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport, > ... > } > > PAKESupport ::= SEQUENCE { > etype Int32, > groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > ... > } Why is etype not a sequence? > The drawback to this approach is that groups or hashes supported by > multiple enctypes get listed multiple times. However, this also > captures that some groups/hashes are only usable for some enctypes. If all of these are orthogonal (they should be) then we should just send sequences (sets, really, but ASN.1 SEQUENCEs) of enctypes, PAKEs, groups (curves; we're not likely to bother with non-EC DH, right?), and hash functions (and/or KDF??). > Generally this relates to key size and protects large keys from being > generated by small curves. I don't see why that should be a problem. It should be possible to generate a key for AES-256 from a 128-bit shared secret. That's one reason for PRFs/KDFs: so we can resolve such impedance mismatches. > > On the whole I prefer (3). I agree that it's an optimization that > > could come later though. But it's also an optimization that clients > > could implement immediately (with the fallback penalty); it's only > > the AS where more work is needed. > > Having implemented it, the AS side is easy. The client is harder. That > is at least the case on the MIT codebase. I suspect it is true of all > implementations. Interesting. All the better. Let's go with (3), with the optimization being optional. Some clients will do (1), and that's OK. Nico -- From nobody Tue Feb 17 13:40:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506801A0102 for ; Tue, 17 Feb 2015 13:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vqHI9NWct1wn for ; Tue, 17 Feb 2015 13:40:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 18BE01A8A6B for ; Tue, 17 Feb 2015 13:40:05 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1HLe3sX011522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 17 Feb 2015 16:40:04 -0500 Received: from vpn-50-159.rdu2.redhat.com (vpn-50-159.rdu2.redhat.com [10.10.50.159]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1HLe1ns000606 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Feb 2015 16:40:02 -0500 Message-ID: <1424209200.2645.54.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Tue, 17 Feb 2015 16:40:00 -0500 In-Reply-To: <20150217195815.GJ5246@localhost> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:40:53 -0000 On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote: > On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum wrote: > > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum > > > wrote: > > > > I see 1 and 3 as the only good options. Having to register > > > > group parameters instead of using OIDs is a deal-breaker in my > > > > book. > > > > > > I also prefer not to have to add registration of groups. I'm > > > not sure that I want to have any support for negotiable group > > > parameters though, if that's what you meant. I'd rather have > > > well-known curves (groups) suitable for discrete codepoint > > > assignments regardless of whether we have/need a registry. > > > > That was not what I meant. I meant parameters of the exchange. > > Current parameters are: > > * PAKE method (currently: SPAKE and JPAKE; needs registration) > > * Group (currently: only standardized elliptic curve groups) > > * Hash (currently: MD5, SHA1, SHA2-*) > > [I covered that elsewhere.] Assuming these are all orthogonal (they > should be), then pseudo-enctypes work, but need a registry. OIDs > are much better (though larger) because we can then outsource the > registry to CFRG and friends. In the current code, the actual key is generated by a hash of: 1. the shared EC point: K 2. the client principal 3. the server principal 4. all padata sent or received Currently, we do not truncate hashes to fit key size. So the hash output must exactly match the expected size of the key. This is the reason MD5 is enabled (to support 128bit keys). This is not a long term plan. However, we should not allow, for instance, SHA1 to be used to generate a 256bit key. Given the above, hashes are supported per etype. I currently do something similar for the groups. An elliptic curve group can only be used for an etype if its field size is >=1.75x the key size. For example, P-224 can be used for generating 128bit keys, but not for 256bit keys. Given the above, groups are supported per etype. > > Currently, I advertise these as: > > > > PAKEInfo ::= SEQUENCE { > > ptypes SEQUENCE (SIZE(1..MAX)) OF Int32, > > supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport, > > ... > > } > > > > PAKESupport ::= SEQUENCE { > > etype Int32, > > groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > > hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > > ... > > } > > Why is etype not a sequence? Because this contains the lists of supported groups and hashes for that specific etype. > > The drawback to this approach is that groups or hashes supported > > by multiple enctypes get listed multiple times. However, this also > > captures that some groups/hashes are only usable for some enctypes. > > If all of these are orthogonal (they should be) then we should just > send sequences (sets, really, but ASN.1 SEQUENCEs) of enctypes, > PAKEs, groups (curves; we're not likely to bother with non-EC DH, > right?), and hash functions (and/or KDF??). We don't need to send enctypes. This is already sent in etypes. Having them all be orthogonal is how I originally designed it. But I changed it given the above considerations. Small hashes/ECs should not be used to generate larger keys. > > Generally this relates to key size and protects large keys from > > being generated by small curves. > > I don't see why that should be a problem. It should be possible to > generate a key for AES-256 from a 128-bit shared secret. That's one > reason for PRFs/KDFs: so we can resolve such impedance mismatches. What we can do and what we should do are different things. We can make large keys from small seeds. But I think allowing this makes for unclear security situations. I would prefer limiting the parameters for an etype to only those which do not degrade the security expectations of that etype. > > > On the whole I prefer (3). I agree that it's an optimization > > > that could come later though. But it's also an optimization > > > that clients could implement immediately (with the fallback > > > penalty); it's only the AS where more work is needed. > > > > Having implemented it, the AS side is easy. The client is harder. > > That is at least the case on the MIT codebase. I suspect it is > > true of all implementations. > > Interesting. All the better. Let's go with (3), with the > optimization being optional. Some clients will do (1), and that's > OK. I think you mean 1 with the optimization (3) being optional. I only wish to add that it should be optional for clients but required for servers. Nathaniel From nobody Tue Feb 17 13:42:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615571A90E5 for ; Tue, 17 Feb 2015 13:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1DpsKw52PN2O for ; Tue, 17 Feb 2015 13:42:21 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 118EE1A90DA for ; Tue, 17 Feb 2015 13:41:58 -0800 (PST) X-AuditID: 12074422-f79d16d0000024cf-28-54e3b5a6ec8f 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 5E.05.09423.6A5B3E45; Tue, 17 Feb 2015 16:41:58 -0500 (EST) 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 t1HLfv13018963 for ; Tue, 17 Feb 2015 16:41:58 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1HLftL4014147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Feb 2015 16:41:57 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1HLftJq029537; Tue, 17 Feb 2015 16:41:55 -0500 (EST) Date: Tue, 17 Feb 2015 16:41:55 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrbts6+MQg+dPpCyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF8Xl7IXbFCsuDPjGEsD4xGpLkZODgkBE4lDeyYyQdhiEhfu rWcDsYUEFjNJPG+z7mLkArKPM0rc3jifBcK5wSRx++MxNgingVHi5YxDjCAtLALaEid3NLOA 2GwCKhIz32wEGyUiICyxe+s7ZpAGYYGZjBKdZ5rB9nEKOEn0PWsEK+IVcJC4evIpO8RuR4lp l7aB2aICOhKr909hgagRlDg58wmYzSygJbF8+jaWCYwCs5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRrqpebWaKXmlK6iREUgOwuSjsYfx5UOsQowMGoxMM7YdKjECHWxLLiytxD jJIcTEqivDPmPA4R4kvKT6nMSCzOiC8qzUktPsQowcGsJMIblAKU401JrKxKLcqHSUlzsCiJ 8276wRciJJCeWJKanZpakFoEk5Xh4FCS4GXbAtQoWJSanlqRlplTgpBm4uAEGc4DNFwfpIa3 uCAxtzgzHSJ/ilFRSpyXByQhAJLIKM2D64UliFeM4kCvCPOmgFTxAJMLXPcroMFMQIPn/3kE MrgkESEl1cCY/cDh1ITXCf/Ukjiuv7q+v2tRlU9Xu04TD9sSXpOf6fKxba6h+s/PaYjnJB2o VrrIs05igUxp8p6La9q4Y/zKVr1xZD6tWcww3cisyJ2VPdXQhtsq/+TCqHuR2XLVkYoWm3/y Gh7Y29nYZGf45pLuu9s/ZhTG5goUPTmiyu/xqE1WziRQVomlOCPRUIu5qDgRAO/7+GTrAgAA Archived-At: Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:42:24 -0000 On Tue, 20 Jan 2015, Benjamin Kaduk wrote: > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 I reviewed this one, and it seems fine. A few minor (nonsubstantive) issues below. The new text says: In Section 7, pepper string 2 is corrected to comply with the string actually used by implementations. However, the actual body text where the change to this string is made just refers to it as "pepper2", so it might be better to be consistent and say "the pepper2 string is corrected". The introductory text in section 7 and the description of the attack read almost as if they were originally written for a different context and just dropped in place here; the terminology used does not match well with the rest of the document. For example, what are "channels"? What does it mean for a channel to have "a given name"? The text here could probably be drastically improved; perhaps we should take the time to do so since we are already modifying the document. I think that the attack could be expressed more cleanly, too -- "it is desirable that neither the KDC nor the client unilaterally determine the ticket session key" doesn't really say why. What this extension is doing is providing a binding between the party which generated the session key and the DH exchange used to generate the reply key. Supposing for the sake of argument that the KDC picks the ticket session key as usual, absent the use of PA-PKINIT-KX, the client and KDC would perform a DH key exchange to determine a shared key, and that key would be used as the reply key. The KDC generates a ticket with session key as usual, and encrypts the reply using the result of the DH agreement. If there is a MITM, the attacker can just decrypt the session key + ticket using the DH key from the attacker<-->KDC DH exchange, and reencrypt it using the key from the attacker<-->client DH exchange, keeping a copy of the session key and ticket. By requiring the session key to be a function of the reply key in a way that can be verified by the client, this extension binds the ticket to the DH exchange and prevents the MITM attack. Some nits in the original RFC 6112 text: In the introduction, [...] Note that the membership of a realm can imply a member of the community represented by the realm. seems ungrammatical. At the bottom of page 4, "For example, an anonymous principal that is identifiable only within a particular group of users can be implemented using authorization data and such authorization data, if included in the anonymous ticket, would disclose the client's membership of that group." is a bit awkward. I would probably rephrase it as "For example, an anonymous principal that is identifiable only as being one of a particular group of users can be implemented using authorization data. Such authorization data, if included in the anonymous ticket, would disclose that the client is a member of the group in question." In section 4.1: The Kerberos client can use the client's long-term keys, the client's X.509 certificates [RFC4556], or any other pre-authentication data, to authenticate to the KDC and requests an anonymous ticket in an AS exchange where the client's identity is known to the KDC. I think that the final 's' in "requests" is ungrammatical and should be removed. At the top of page 6, "According to [RFC4120]" could just as easily be "As specified by [RFC4120]", since this is just repeating standard Kerberos behavior. Two paragraphs later, we could s/AD-INITIAL-VERIFIED-CAS/AD_INITIAL_VERIFIED_CAS/ (twice), since the ad-type assigned number uses the underscores and the ASN.1 type uses hyphens. (This also appears in section 4.2 on page 9.) The final paragraph of section 4.1 starts with "The client can use the client keys"; the phrase "client keys" does not appear anywhere else in this document, or RFC 4120, or RFC 4556. Perhaps the intent was "the client's key" instead. In the last sentence of page 7, I think that "Anonymity PKINIT" should be "Anonymous PKINIT". In section 4.2, there's a missing space in "the anonymous KDC optionSHOULD be set in the request." -Ben From nobody Tue Feb 17 18:43:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25661A702B for ; Tue, 17 Feb 2015 18:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 606ASsOeNlg9 for ; Tue, 17 Feb 2015 18:43:52 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id B56841A8961 for ; Tue, 17 Feb 2015 18:43:52 -0800 (PST) X-AuditID: 12074422-f79d16d0000024cf-37-54e3fc672513 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 D9.33.09423.76CF3E45; Tue, 17 Feb 2015 21:43:51 -0500 (EST) 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 t1I2hoi8001236; Tue, 17 Feb 2015 21:43:51 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1I2hmQO019001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2015 21:43:50 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1I2hmd5007374; Tue, 17 Feb 2015 21:43:48 -0500 (EST) Date: Tue, 17 Feb 2015 21:43:48 -0500 (EST) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: <54E2BFE4.4000003@oracle.com> Message-ID: References: <54CE9F5B.9070808@mit.edu> <54E2BFE4.4000003@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrpv+53GIQcdlPYujm1exWPS9PsTu wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGUsPbWeseABZ8Xj9QeZGhjPs3cxcnJICJhI 9D27zwphi0lcuLeerYuRi0NIYDGTxMpvG5ghnI2MEk2TPzODVAkJHGKSWP8yDMJuYJR4sswM xGYR0JY4/uYRC4jNJqAiMfPNRjYQW0RAS+JGQwcTiM0soC7x7cwbRpChwgLHGCXWLXvJCJLg BCqav3U3WAOvgIPEt3X7oTavZ5R4u3ENWLeogI7E6v1TWCCKBCVOznzCAjFVS2L59G0sExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyM4WF2UdjD+PKh0 iFGAg1GJh3fCpEchQqyJZcWVuYcYJTmYlER5k74/DhHiS8pPqcxILM6ILyrNSS0+xCjBwawk wqt0AijHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBa/kbqFGwKDU9 tSItM6cEIc3EwQkynAdouBxIDW9xQWJucWY6RP4Uo6KUOK8ZSEIAJJFRmgfXC0smrxjFgV4R 5jUGqeIBJiK47ldAg5mABs//8whkcEkiQkqqgTFHOcytZoraLNNPOf0u9vtf3Hx1eH81j/75 d7aNSpUeGrrrJJeHSjiaS227n+N8oXBrY7L25sCwp+/ke47v+Fj+Y2lEMufaXfuti/9dvWbG /DTP6p6wvprymtypDbVpjvNnhyjtjN95+eUN5xWGkp2Xr+Y9Xpj7RPZS3fGcaHljmU3PFRy6 OZRYijMSDbWYi4oTAWENIc8BAwAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-rfc4402bis-00 (was: Re: WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 02:43:54 -0000 On Mon, 16 Feb 2015, Shawn M Emery wrote: > > Thanks for your review, comments in-line... > > On 02/13/15 11:16 AM, Benjamin Kaduk wrote: > > > The original RFC 4402 security considerations include: > > > > [...] if an > > application can be tricked into providing very large input octet > > strings and requesting very long output octet strings, then that may > > constitute a denial of service attack on the application; therefore, > > applications SHOULD place appropriate limits on the size of any input > > octet strings received from their peers without integrity protection. > > > > It is not clear to me that integrity protection is sufficient to alleviate > > the denial of service attack, since verifying the message integrity may > > itself consume a substantial amount of resources. > > I interpret this statement differently: > > If integrity protection is not enforced then an attacker can construct an > arbitrarily long string. Woudln't the attacker be able to do that without needing a very large input string, though? I guess the claims it that each individual pseudo-random() call is more expensive on a long input, so your interpretation is still plausible. -Ben From nobody Tue Feb 17 19:40:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2211A86EF for ; Tue, 17 Feb 2015 19:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 tnBaIBKK7zo6 for ; Tue, 17 Feb 2015 19:40:58 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1391A86E3 for ; Tue, 17 Feb 2015 19:40:58 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 20F19318059 for ; Tue, 17 Feb 2015 19:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=uy2+zSDdxHyNX8zJZq2E 4vWWfXQ=; b=RTsT4L+/G6uCqyhZckTiro53Ovuv2W3n1hn2wTq9kERmUiZeOGrN BDprALjTpw+qp6O0XyTFGxkKAF+XpZXtHsSDriTvqzSTTDyY+fPBm8XYvlj1A1dN BuRzxs5Wd5HHBg9zwibWOJ5gCXnQJBDZzhQe/SlGq8qIbxHYEchwqHI= Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 0D82031805D for ; Tue, 17 Feb 2015 19:40:58 -0800 (PST) Received: by iecrp18 with SMTP id rp18so30519856iec.9 for ; Tue, 17 Feb 2015 19:40:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.27.143 with SMTP id b137mr13976974iob.76.1424230857559; Tue, 17 Feb 2015 19:40:57 -0800 (PST) Received: by 10.64.130.66 with HTTP; Tue, 17 Feb 2015 19:40:57 -0800 (PST) In-Reply-To: References: <54CE9F5B.9070808@mit.edu> <54E2BFE4.4000003@oracle.com> Date: Tue, 17 Feb 2015 21:40:57 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-rfc4402bis-00 (was: Re: WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:40:59 -0000 On Tue, Feb 17, 2015 at 8:43 PM, Benjamin Kaduk wrote: > On Mon, 16 Feb 2015, Shawn M Emery wrote: >> Thanks for your review, comments in-line... >> On 02/13/15 11:16 AM, Benjamin Kaduk wrote: >> >> > The original RFC 4402 security considerations include: >> > >> > [...] if an >> > application can be tricked into providing very large input octet >> > strings and requesting very long output octet strings, then that may >> > constitute a denial of service attack on the application; therefore, >> > applications SHOULD place appropriate limits on the size of any input >> > octet strings received from their peers without integrity protection. >> > >> > It is not clear to me that integrity protection is sufficient to alleviate >> > the denial of service attack, since verifying the message integrity may >> > itself consume a substantial amount of resources. >> >> I interpret this statement differently: >> >> If integrity protection is not enforced then an attacker can construct an >> arbitrarily long string. > > > Woudln't the attacker be able to do that without needing a very large > input string, though? I guess the claims it that each individual > pseudo-random() call is more expensive on a long input, so your > interpretation is still plausible. I think the original was about use of the PRF to bind something like, say, a TLS handshake. Now suppose you send such messages that are very large prior to completing authentication. Anyways, it's not a realistic problem. I think that was stretching to cover what in retrospect strikes me as a non-issue. Nico -- From nobody Tue Feb 17 19:45:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F001A893F for ; Tue, 17 Feb 2015 19:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hhdyH2Jzydqg for ; Tue, 17 Feb 2015 19:45:19 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id E2C131A897F for ; Tue, 17 Feb 2015 19:45:09 -0800 (PST) X-AuditID: 12074422-f79d16d0000024cf-57-54e40ac5b84f 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 EC.D5.09423.5CA04E45; Tue, 17 Feb 2015 22:45:09 -0500 (EST) 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 t1I3j8vM025506; Tue, 17 Feb 2015 22:45:09 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1I3j5J0006481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2015 22:45:08 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1I3j50K015008; Tue, 17 Feb 2015 22:45:05 -0500 (EST) Date: Tue, 17 Feb 2015 22:45:05 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150216041027.GB5246@localhost> Message-ID: References: <20150216041027.GB5246@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrXuU60mIQd9eEYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY+/Icc8EayYpFcy+zNDD+Fe5i5OSQEDCR OPCmkwXCFpO4cG89G4gtJLCYSWL+RKA4F5C9kVHi37ab7BCJQ0wSU9rMIBINjBLb5j8B62YR 0Jb41z0NrIhNQEVi5puNYJNEBDQlrs9bCmYzCwhLrD83gxmkWVhgJqNE55lmJpAEp4CexPNJ HYwgNq+Ag8TSj5OBbA6gDckSCx4mgoRFBXQkVu+fwgJRIihxcibEXmYBLYnl07exTGAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTSTYygQGV3UdrB+POg0iFG AQ5GJR7eDqYnIUKsiWXFlbmHGCU5mJREeZO+Pw4R4kvKT6nMSCzOiC8qzUktPsQowcGsJMKr dAIox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwRvDCbRHsCg1PbUi LTOnBCHNxMEJMpwHaLghSA1vcUFibnFmOkT+FKOilDivH0hCACSRUZoH1wtLJK8YxYFeEebl BKniASYhuO5XQIOZgAbP//MIZHBJIkJKqoExeKdyZ619mtMBy8tX43sDHpZ/8n4vuni2VDPX oiU/KirLqkUf8R+V6t3VtOASl8FTUSfvvfUvbj/crPhGa5032+vpScZRJ1O3Wp/Z5ZwUoeP4 +WiC6S7G23+ZPiazPFTXZF1gdLqVR2Lr/sj5b8rqFLbMsipqi5HZc128Kuicwjb+p3+tdaSU WIozEg21mIuKEwHuvfle/wIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:45:22 -0000 On Sun, 15 Feb 2015, Nico Williams wrote: > > Please forgive me for being so late with these reviews. > > On Tue, Jan 20, 2015 at 06:02:24PM -0500, Benjamin Kaduk wrote: > > > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 > > I've not reviewed the entirety of this document, just the docs from > RFC5653 to rfc5653bis-02. > > Comments: > > My one comment on the changes is that having GSSException() > constructors that take major and minor status code numbers seems... > like a bad idea, particularly as to minor status codes. HOWEVER, > since some implementations may use an all-Java GSSException class even > with a JNI bindings for the rest of the API (or for specific mechanism > providers), it seems like a good idea for that purpose. I don't think > this is worth mentioning in the I-D; this is really just a comment for > the mailing list archive. Yeah, it's a bit late to try to not have minor codes in the constructor argument list. > > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 > > Ditto here, I'm only reviewing the changes, not the entire I-D. > Although I have one comment as to the original RFC: > > - Should we take this opportunity to define an AD to carry the PKINIT > client cert and its validation cert chain (and trust anchor)? That seems more like something I would want to put in a 4556bis than a 6112bis (though of course there is no rule preventing it from being done). I'm inclined to not try to add such an AD in at this time. > Regarding the change in section 4.2, the only reason for not reducing > the MUST further to MAY is probably interoperability with TGSes that > implemented the "MUST return a KRB-ERROR..." text that is being deleted. > This seems to merit a mention, something like: > > If the ticket in the PA-TGS-REQ of the TGS request is an anonymous > one, the client SHOULD set the anonymous KDC option in the request > for interoperability with TGSes that insist on it. The TGS SHOULD > ignore the presence/absence of the anonymous KDC option in the > request when the the ticket in the request is an anonymous ticket. I think we should say something about "for interoperability with ..." ("insist on it" is probably too colloquial). I had pondered saying something about the TGS behavior when I reviewed this change as well, but did not say anything about it in my review. I don't see any harm in spelling it out, though. > (Do we need to be more careful about defining "anonymous ticket"? You mean here in 4.2? I don't think so; section 3 has an extensive definition of what it means to be an anonymous ticket. > Clearly this refers to tickets whose cname is anonymous, but in the > user-to-user case the sname of the second ticket could be anonymous, > and when we add post-dating, one could even have a TGS-REQ where the > ticket has an anonymous sname. Such a request is bound to fail, and > makes no sense anyways! This is just a twisted case just to > demonstrate that it's the cname of a ticket that determines whether its > an anonymous one or not. Just a curiosity.) Oh, but maybe we should be more careful about "in the request", hmm. -Ben From nobody Wed Feb 18 04:58:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A25C1A1A9A for ; Wed, 18 Feb 2015 04:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 dDvdZuMrnbPc for ; Wed, 18 Feb 2015 04:58:31 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 934EE1A1ACC for ; Wed, 18 Feb 2015 04:58:27 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id i50so644716qgf.2 for ; Wed, 18 Feb 2015 04:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; s=swgoo; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qZHGLYKv3Qd4bSALEINcFelyyLSeIqoiShDEAuS/P+w=; b=ydE2EB7HA3zwlQzqPnEGTvdRLu2ohiZ6ARWMBo9Ma/BjI2Bx48Md2XihVVjlgmh+ag eVieU8qIWrwDK9jWkm5FbSi4t1Q+1CLPzBV88gTgIHcTszQgz0/RW/mGowX59hgTNqGc YwrXMGK8D93l/2iqc2T9x0QaU+3fhZH/c4+tA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qZHGLYKv3Qd4bSALEINcFelyyLSeIqoiShDEAuS/P+w=; b=HPksi602WIKMdMbQMC58ke7WPbomFn4L2tzsde0Ies9HzQxSA0fHZB4xZyRNWHFUDi frpFiOn2v4d06uSDuz1bx4nERKzeK4B9j72y/HCxY5cUv1Cs5LFvnXLgsdY2yqgPvGLO uIs2PdEhhlgqDQmzkSitZ2YW6gcL9dZvW/7H6T8tx1UL8J1ClCYaxPeNZUx7Ob/JPgkP DgfOQ9O1aAHCR6U5ld59HyYJJgFESDLhr6DECw60lqNR8kbuixU6DdXCwrbglMhUZWaT l6xJHltRnPmC0Ik9qAvXKEhlDSkJ7hym7fxBkkcwQ3MPZnbCcjAb/vOb/x8lneg6y8gl 2YSg== X-Gm-Message-State: ALoCoQly3XH/h+9S7aVEk7IkshpD3JeR9JQRAs0hx8YKp+ZHryjfAaqROYOETCmdGlOUzINOZFiM X-Received: by 10.229.216.130 with SMTP id hi2mr657282qcb.4.1424264306770; Wed, 18 Feb 2015 04:58:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.22.51 with HTTP; Wed, 18 Feb 2015 04:57:46 -0800 (PST) X-Originating-IP: [75.117.16.85] In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> From: Sam Whited Date: Wed, 18 Feb 2015 07:57:46 -0500 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 12:58:33 -0000 On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland wrote: > Worth asking in the XSF, there's likely to be implementation experience f= rom > the Android client devs there. I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't remember actual numbers off the top of my head, I can definitely tell you that there is a noticable delay with a 4096 iteration count (probably a little over half a second) on my HTC m7 (which is fairly beefy as far as phones go). HOWEVER=E2=80=94 > However, clients need only do the iterations once, if the salt is stable,= at > least in principle. =E2=80=94since we then store the session information in an LRU Cache in memory, it's only slow when you first login. I've thought about moving the session info to the database as well to make it even more persistant, but decided it wasn't enough of a problem to bother polluting the database. Best, Sam --=20 Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com From nobody Wed Feb 18 06:03:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EBE1A890F for ; Wed, 18 Feb 2015 06:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5VgjSBpDb5ux for ; Wed, 18 Feb 2015 06:03:38 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 DB2631A87E6 for ; Wed, 18 Feb 2015 06:03:38 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IE3b4n014826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 09:03:38 -0500 Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IE3bHb019541; Wed, 18 Feb 2015 09:03:37 -0500 Message-ID: <1424268216.6980.1.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nathaniel McCallum Date: Wed, 18 Feb 2015 09:03:36 -0500 In-Reply-To: <1424209200.2645.54.camel@redhat.com> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> <1424209200.2645.54.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:03:41 -0000 On Tue, 2015-02-17 at 16:40 -0500, Nathaniel McCallum wrote: > On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote: > > On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum wrote: > > > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > > > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum > > > > wrote: > > > > > I see 1 and 3 as the only good options. Having to register > > > > > group parameters instead of using OIDs is a deal-breaker in my > > > > > book. > > > > > > > > I also prefer not to have to add registration of groups. I'm > > > > not sure that I want to have any support for negotiable group > > > > parameters though, if that's what you meant. I'd rather have > > > > well-known curves (groups) suitable for discrete codepoint > > > > assignments regardless of whether we have/need a registry. > > > > > > That was not what I meant. I meant parameters of the exchange. > > > Current parameters are: > > > * PAKE method (currently: SPAKE and JPAKE; needs registration) > > > * Group (currently: only standardized elliptic curve groups) > > > * Hash (currently: MD5, SHA1, SHA2-*) > > > > [I covered that elsewhere.] Assuming these are all orthogonal (they > > should be), then pseudo-enctypes work, but need a registry. OIDs > > are much better (though larger) because we can then outsource the > > registry to CFRG and friends. > > In the current code, the actual key is generated by a hash of: > 1. the shared EC point: K > 2. the client principal I wonder ^^^ if this is problematic when canonicalization is requested ? Simo. > 3. the server principal > 4. all padata sent or received > > Currently, we do not truncate hashes to fit key size. So the hash > output must exactly match the expected size of the key. This is the > reason MD5 is enabled (to support 128bit keys). This is not a long > term plan. However, we should not allow, for instance, SHA1 to be used > to generate a 256bit key. > > Given the above, hashes are supported per etype. > > I currently do something similar for the groups. An elliptic curve > group can only be used for an etype if its field size is >=1.75x the > key size. For example, P-224 can be used for generating 128bit keys, > but not for 256bit keys. > > Given the above, groups are supported per etype. > > > > Currently, I advertise these as: > > > > > > PAKEInfo ::= SEQUENCE { > > > ptypes SEQUENCE (SIZE(1..MAX)) OF Int32, > > > supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport, > > > ... > > > } > > > > > > PAKESupport ::= SEQUENCE { > > > etype Int32, > > > groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > > > hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > > > ... > > > } > > > > Why is etype not a sequence? > > Because this contains the lists of supported groups and hashes for > that specific etype. > > > > The drawback to this approach is that groups or hashes supported > > > by multiple enctypes get listed multiple times. However, this also > > > captures that some groups/hashes are only usable for some enctypes. > > > > If all of these are orthogonal (they should be) then we should just > > send sequences (sets, really, but ASN.1 SEQUENCEs) of enctypes, > > PAKEs, groups (curves; we're not likely to bother with non-EC DH, > > right?), and hash functions (and/or KDF??). > > We don't need to send enctypes. This is already sent in etypes. > > Having them all be orthogonal is how I originally designed it. But I > changed it given the above considerations. Small hashes/ECs should not > be used to generate larger keys. > > > > Generally this relates to key size and protects large keys from > > > being generated by small curves. > > > > I don't see why that should be a problem. It should be possible to > > generate a key for AES-256 from a 128-bit shared secret. That's one > > reason for PRFs/KDFs: so we can resolve such impedance mismatches. > > What we can do and what we should do are different things. We can make > large keys from small seeds. But I think allowing this makes for > unclear security situations. I would prefer limiting the parameters > for an etype to only those which do not degrade the security > expectations of that etype. > > > > > On the whole I prefer (3). I agree that it's an optimization > > > > that could come later though. But it's also an optimization > > > > that clients could implement immediately (with the fallback > > > > penalty); it's only the AS where more work is needed. > > > > > > Having implemented it, the AS side is easy. The client is harder. > > > That is at least the case on the MIT codebase. I suspect it is > > > true of all implementations. > > > > Interesting. All the better. Let's go with (3), with the > > optimization being optional. Some clients will do (1), and that's > > OK. > > I think you mean 1 with the optimization (3) being optional. I only > wish to add that it should be optional for clients but required for > servers. > > Nathaniel > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Feb 18 06:22:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7C1A87E7 for ; Wed, 18 Feb 2015 06:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fpkdHrbhdEY9 for ; Wed, 18 Feb 2015 06:22:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 BD4111A87A1 for ; Wed, 18 Feb 2015 06:22:44 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEMgpK019279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 09:22:43 -0500 Received: from vpn-49-134.rdu2.redhat.com (vpn-49-134.rdu2.redhat.com [10.10.49.134]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEMePZ030208 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Feb 2015 09:22:41 -0500 Message-ID: <1424269360.2547.6.camel@redhat.com> From: Nathaniel McCallum To: Simo Sorce Date: Wed, 18 Feb 2015 09:22:40 -0500 In-Reply-To: <1424268216.6980.1.camel@willson.usersys.redhat.com> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> <1424209200.2645.54.camel@redhat.com> <1424268216.6980.1.camel@willson.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:22:47 -0000 On Wed, 2015-02-18 at 09:03 -0500, Simo Sorce wrote: > On Tue, 2015-02-17 at 16:40 -0500, Nathaniel McCallum wrote: > > On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote: > > > On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum > > > wrote: > > > > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > > > > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum > > > > > wrote: > > > > > > I see 1 and 3 as the only good options. Having to register > > > > > > group parameters instead of using OIDs is a deal-breaker > > > > > > in my book. > > > > > > > > > > I also prefer not to have to add registration of groups. > > > > > I'm not sure that I want to have any support for negotiable > > > > > group parameters though, if that's what you meant. I'd > > > > > rather have well-known curves (groups) suitable for discrete > > > > > codepoint > > > > > assignments regardless of whether we have/need a registry. > > > > > > > > That was not what I meant. I meant parameters of the exchange. > > > > Current parameters are: > > > > * PAKE method (currently: SPAKE and JPAKE; needs registration) > > > > * Group (currently: only standardized elliptic curve groups) > > > > * Hash (currently: MD5, SHA1, SHA2-*) > > > > > > [I covered that elsewhere.] Assuming these are all orthogonal > > > (they should be), then pseudo-enctypes work, but need a > > > registry. OIDs are much better (though larger) because we can > > > then outsource the registry to CFRG and friends. > > > > In the current code, the actual key is generated by a hash of: 1. > > the shared EC point: K > > 2. the client principal > I wonder ^^^ if this is problematic when canonicalization is > requested ? > > Simo. I'm not sure. I hash whatever is in krb5_kdc_req.client. > > 3. the server principal > > 4. all padata sent or received I forgot to mention: 5. The long term key used in the PAKE > > Currently, we do not truncate hashes to fit key size. So the hash > > output must exactly match the expected size of the key. This is > > the reason MD5 is enabled (to support 128bit keys). This is not a > > long term plan. However, we should not allow, for instance, SHA1 > > to be used to generate a 256bit key. > > > > Given the above, hashes are supported per etype. > > > > I currently do something similar for the groups. An elliptic curve > > group can only be used for an etype if its field size is >=1.75x > > the key size. For example, P-224 can be used for generating 128bit > > keys, but not for 256bit keys. > > > > Given the above, groups are supported per etype. > > > > > > Currently, I advertise these as: > > > > > > > > PAKEInfo ::= SEQUENCE { > > > > ptypes SEQUENCE (SIZE(1..MAX)) OF Int32, > > > > supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport, > > > > ... > > > > } > > > > > > > > PAKESupport ::= SEQUENCE { > > > > etype Int32, > > > > groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > > > > hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER, > > > > ... > > > > } > > > > > > Why is etype not a sequence? > > > > Because this contains the lists of supported groups and hashes for > > that specific etype. > > > > > > The drawback to this approach is that groups or hashes > > > > supported by multiple enctypes get listed multiple times. > > > > However, this also captures that some groups/hashes are only > > > > usable for some enctypes. > > > > > > If all of these are orthogonal (they should be) then we should > > > just send sequences (sets, really, but ASN.1 SEQUENCEs) of > > > enctypes, PAKEs, groups (curves; we're not likely to bother with > > > non-EC DH, right?), and hash functions (and/or KDF??). > > > > We don't need to send enctypes. This is already sent in etypes. > > > > Having them all be orthogonal is how I originally designed it. But > > I changed it given the above considerations. Small hashes/ECs > > should not be used to generate larger keys. > > > > > > Generally this relates to key size and protects large keys > > > > from being generated by small curves. > > > > > > I don't see why that should be a problem. It should be possible > > > to generate a key for AES-256 from a 128-bit shared secret. > > > That's one reason for PRFs/KDFs: so we can resolve such > > > impedance mismatches. > > > > What we can do and what we should do are different things. We can > > make large keys from small seeds. But I think allowing this makes > > for unclear security situations. I would prefer limiting the > > parameters for an etype to only those which do not degrade the > > security expectations of that etype. > > > > > > > On the whole I prefer (3). I agree that it's an > > > > > optimization that could come later though. But it's also an > > > > > optimization > > > > > that clients could implement immediately (with the fallback > > > > > penalty); it's only the AS where more work is needed. > > > > > > > > Having implemented it, the AS side is easy. The client is > > > > harder. That is at least the case on the MIT codebase. I > > > > suspect it is true of all implementations. > > > > > > Interesting. All the better. Let's go with (3), with the > > > optimization being optional. Some clients will do (1), and > > > that's OK. > > > > I think you mean 1 with the optimization (3) being optional. I > > only wish to add that it should be optional for clients but > > required for servers. > > > > Nathaniel > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > From nobody Wed Feb 18 06:35:37 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB841A87DE for ; Wed, 18 Feb 2015 06:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gsxsPY-LeH0A for ; Wed, 18 Feb 2015 06:35:34 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 8E73D1A8833 for ; Wed, 18 Feb 2015 06:35:34 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEZXne029535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 09:35:33 -0500 Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEZWRB011269; Wed, 18 Feb 2015 09:35:33 -0500 Message-ID: <1424270132.6980.14.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nathaniel McCallum Date: Wed, 18 Feb 2015 09:35:32 -0500 In-Reply-To: <1424269360.2547.6.camel@redhat.com> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> <1424209200.2645.54.camel@redhat.com> <1424268216.6980.1.camel@willson.usersys.redhat.com> <1424269360.2547.6.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:35:36 -0000 On Wed, 2015-02-18 at 09:22 -0500, Nathaniel McCallum wrote: > On Wed, 2015-02-18 at 09:03 -0500, Simo Sorce wrote: > > On Tue, 2015-02-17 at 16:40 -0500, Nathaniel McCallum wrote: > > > On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote: > > > > On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum > > > > wrote: > > > > > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > > > > > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum > > > > > > wrote: > > > > > > > I see 1 and 3 as the only good options. Having to register > > > > > > > group parameters instead of using OIDs is a deal-breaker > > > > > > > in my book. > > > > > > > > > > > > I also prefer not to have to add registration of groups. > > > > > > I'm not sure that I want to have any support for negotiable > > > > > > group parameters though, if that's what you meant. I'd > > > > > > rather have well-known curves (groups) suitable for discrete > > > > > > codepoint > > > > > > assignments regardless of whether we have/need a registry. > > > > > > > > > > That was not what I meant. I meant parameters of the exchange. > > > > > Current parameters are: > > > > > * PAKE method (currently: SPAKE and JPAKE; needs registration) > > > > > * Group (currently: only standardized elliptic curve groups) > > > > > * Hash (currently: MD5, SHA1, SHA2-*) > > > > > > > > [I covered that elsewhere.] Assuming these are all orthogonal > > > > (they should be), then pseudo-enctypes work, but need a > > > > registry. OIDs are much better (though larger) because we can > > > > then outsource the registry to CFRG and friends. > > > > > > In the current code, the actual key is generated by a hash of: 1. > > > the shared EC point: K > > > 2. the client principal > > I wonder ^^^ if this is problematic when canonicalization is > > requested ? > > > > Simo. > > I'm not sure. I hash whatever is in krb5_kdc_req.client. Ok, as long as client and server are using the same name it is fine, but it should probably be spelled out clearly that this is not the canonical principal name but whatever name the client used. > > > 3. the server principal > > > 4. all padata sent or received > > I forgot to mention: > 5. The long term key used in the PAKE Thanks, I thought something was amiss here :) Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Feb 18 06:37:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE21A87F0 for ; Wed, 18 Feb 2015 06:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0n_63-cnPv8i for ; Wed, 18 Feb 2015 06:37:42 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 5B6531A87DE for ; Wed, 18 Feb 2015 06:37:42 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEbfDT026210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 09:37:41 -0500 Received: from vpn-49-134.rdu2.redhat.com (vpn-49-134.rdu2.redhat.com [10.10.49.134]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEbdWG008538 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Feb 2015 09:37:40 -0500 Message-ID: <1424270259.2547.12.camel@redhat.com> From: Nathaniel McCallum To: Simo Sorce Date: Wed, 18 Feb 2015 09:37:39 -0500 In-Reply-To: <1424270132.6980.14.camel@willson.usersys.redhat.com> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> <1424209200.2645.54.camel@redhat.com> <1424268216.6980.1.camel@willson.usersys.redhat.com> <1424269360.2547.6.camel@redhat.com> <1424270132.6980.14.camel@willson.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:37:44 -0000 On Wed, 2015-02-18 at 09:35 -0500, Simo Sorce wrote: > On Wed, 2015-02-18 at 09:22 -0500, Nathaniel McCallum wrote: > > On Wed, 2015-02-18 at 09:03 -0500, Simo Sorce wrote: > > > On Tue, 2015-02-17 at 16:40 -0500, Nathaniel McCallum wrote: > > > > On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote: > > > > > On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum > > > > > wrote: > > > > > > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote: > > > > > > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel > > > > > > > McCallum > > > > > > > wrote: > > > > > > > > I see 1 and 3 as the only good options. Having to > > > > > > > > register > > > > > > > > group parameters instead of using OIDs is a deal- > > > > > > > > breaker > > > > > > > > in my book. > > > > > > > > > > > > > > I also prefer not to have to add registration of groups. > > > > > > > I'm not sure that I want to have any support for > > > > > > > negotiable > > > > > > > group parameters though, if that's what you meant. I'd > > > > > > > rather have well-known curves (groups) suitable for > > > > > > > discrete > > > > > > > codepoint > > > > > > > assignments regardless of whether we have/need a > > > > > > > registry. > > > > > > > > > > > > That was not what I meant. I meant parameters of the > > > > > > exchange. Current parameters are: > > > > > > * PAKE method (currently: SPAKE and JPAKE; needs > > > > > > registration) > > > > > > * Group (currently: only standardized elliptic curve > > > > > > groups) > > > > > > * Hash (currently: MD5, SHA1, SHA2-*) > > > > > > > > > > [I covered that elsewhere.] Assuming these are all > > > > > orthogonal (they should be), then pseudo-enctypes work, but > > > > > need a > > > > > registry. OIDs are much better (though larger) because we > > > > > can then outsource the registry to CFRG and friends. > > > > > > > > In the current code, the actual key is generated by a hash of: > > > > 1. the shared EC point: K > > > > 2. the client principal > > > I wonder ^^^ if this is problematic when canonicalization is > > > requested ? > > > > > > Simo. > > > > I'm not sure. I hash whatever is in krb5_kdc_req.client. > > Ok, as long as client and server are using the same name it is fine, > but it should probably be spelled out clearly that this is not the > canonical principal name but whatever name the client used. > > > > > 3. the server principal > > > > 4. all padata sent or received > > > > I forgot to mention: > > 5. The long term key used in the PAKE > > Thanks, I thought something was amiss here :) Two private things go into the final key hash: 1. the shared EC point derived from the key exchange: K 2. the long term key Successfully attacking #1 breaks either the PAKE method or the DDH assumption. Nathaniel From nobody Wed Feb 18 07:57:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF731A89B0 for ; Wed, 18 Feb 2015 07:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LRpHW6pNGNDG for ; Wed, 18 Feb 2015 07:56:56 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 853751A89AF for ; Wed, 18 Feb 2015 07:56:56 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IFuuHC030980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 Feb 2015 10:56:56 -0500 Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IFutgG031026 for ; Wed, 18 Feb 2015 10:56:55 -0500 Message-ID: <1424275015.6980.23.camel@willson.usersys.redhat.com> From: Simo Sorce To: kitten@ietf.org Date: Wed, 18 Feb 2015 10:56:55 -0500 Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: [kitten] Authentication indicator - Do we need client indicator ? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 15:56:58 -0000 Reading the draft I am wondering if we also need a "Client Indicator" Auth Data definition (in this draft or a separate draft). In AD-CAMMAC we mention that if the KDC want to make sure to bind the CAMMAC to a specific client principal, then this need to be done with data embedded into an AD within CAMMAC, but in AD-CAMMAC we specify no AD type to do that. I had not thought that we'd care about this binding in Auth Indicator work, but I see S4U2Proxy is mentioned there, so perhaps we actually do ? Would it be bad to define a new AD-CLIENT-INDICATOR data type as part of this RFC ? The AD would be defined as: AD-CLIENT-INDICATOR ::= SEQUENCE { principal [0] PrincipalName realm [1] Realm } The client indicator would be optional, but if it is included in a CAMMAC the KDC MUST verify that the client in the ticket including the CAMMAC matches the indicator. The AD Auth indicator security considerations would mention that if support for things like S4U2Proxy is desired and no other AD element in the CAMMAC ties the CAMMAC to a specific principal, then AD_CLIENT_INDICATOR SHOULD be used, and the KDC SHOULD deny a S4U2 operation (or perhaps simply omit the CAMMAC from the resulting ticket) if AD-CLIENT-INDICATOR is missing. Comments ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Feb 18 08:14:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A9C1A89C5 for ; Wed, 18 Feb 2015 08:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9YTugZ8wZ1Vn for ; Wed, 18 Feb 2015 08:14:14 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B331A89F5 for ; Wed, 18 Feb 2015 08:14:09 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-4e-54e4ba4f2d63 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 74.DB.08135.05AB4E45; Wed, 18 Feb 2015 11:14:08 -0500 (EST) 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 t1IGE79j003222; Wed, 18 Feb 2015 11:14:07 -0500 Received: from [18.101.8.186] (vpn-18-101-8-186.mit.edu [18.101.8.186]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1IGE5bK002542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Feb 2015 11:14:06 -0500 Message-ID: <54E4BA4D.3030405@mit.edu> Date: Wed, 18 Feb 2015 11:14:05 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Simo Sorce , kitten@ietf.org References: <1424275015.6980.23.camel@willson.usersys.redhat.com> In-Reply-To: <1424275015.6980.23.camel@willson.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrhuw60mIwYNHLBZHN69isfgxdxGr A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJVx+oR2wXXmiv0HTjM2MH5n6mLk5JAQMJF4 27ONBcIWk7hwbz1bFyMXh5DAYiaJ5zu2M0M4Gxkllm54wwrhHGGSWHzxNCNIC6+AmsSb68fY uxg5OFgEVCW+btEECbMJKEus378VbKqoQJjE9807mCHKBSVOznwCFhcRMJSYv+sRK4gtLBAg 0dvTCTZGSMBR4tt2A5Awp4CTxLb2w2wgNrOAnsSO679YIWx5ie1v5zBPYBSYhWTqLCRls5CU LWBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrpJebWaKXmlK6iREUpJySvDsY3x1UOsQowMGo xMPbwfQkRIg1say4MvcQoyQHk5Io77wdQCG+pPyUyozE4oz4otKc1OJDjBIczEoivLkrgXK8 KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8hjuBGgWLUtNTK9Iyc0oQ 0kwcnCDDeYCG+4DU8BYXJOYWZ6ZD5E8x6nIsaN8/k0mIJS8/L1VKHGKQAEhRRmke3BxYcnnF KA70ljBvAEgVDzAxwU16BbSECWjJ/D+PQJaUJCKkpBoYL8un/hVn+ih/ZcbdBs/C3GxDmRsp H09NkPp/t68nzLlS9l6wt/uTi1mO3bxeW5zcPWs3B7xhfvv2Flf1myOLCuSN5005fWTRvNVn N95uSrizuzzmSpFbet9naxv75M5vzztuMGz/Iv1u5kvplaZFU1ssd2xsVHDN/GN1bdvpw3ci DY9sib3wQ4mlOCPRUIu5qDgRAAPuRdUJAwAA Archived-At: Subject: Re: [kitten] Authentication indicator - Do we need client indicator ? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:14:15 -0000 On 02/18/2015 10:56 AM, Simo Sorce wrote: > In AD-CAMMAC we mention that if the KDC want to make sure to bind the > CAMMAC to a specific client principal, then this need to be done with > data embedded into an AD within CAMMAC, but in AD-CAMMAC we specify no > AD type to do that. CAMMACs are already bound to a client principal name. You are probably thinking of the final paragraph of the security considerations, which refers to the service principal name. From nobody Wed Feb 18 08:22:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9488A1A89B3 for ; Wed, 18 Feb 2015 08:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ARdVD1hY-Ywf for ; Wed, 18 Feb 2015 08:22:01 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 5928A1A89A9 for ; Wed, 18 Feb 2015 08:22:01 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IGLx7b010924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 11:22:00 -0500 Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IGLwOR020774; Wed, 18 Feb 2015 11:21:58 -0500 Message-ID: <1424276518.6980.28.camel@willson.usersys.redhat.com> From: Simo Sorce To: Greg Hudson Date: Wed, 18 Feb 2015 11:21:58 -0500 In-Reply-To: <54E4BA4D.3030405@mit.edu> References: <1424275015.6980.23.camel@willson.usersys.redhat.com> <54E4BA4D.3030405@mit.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Authentication indicator - Do we need client indicator ? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:22:07 -0000 On Wed, 2015-02-18 at 11:14 -0500, Greg Hudson wrote: > On 02/18/2015 10:56 AM, Simo Sorce wrote: > > In AD-CAMMAC we mention that if the KDC want to make sure to bind the > > CAMMAC to a specific client principal, then this need to be done with > > data embedded into an AD within CAMMAC, but in AD-CAMMAC we specify no > > AD type to do that. > > CAMMACs are already bound to a client principal name. You are probably > thinking of the final paragraph of the security considerations, which > refers to the service principal name. Doh! Ok, and Auth Indicator doesn't care about Service Principal Names. So ... nevermind :) Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Feb 18 08:28:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF961A1EE9 for ; Wed, 18 Feb 2015 08:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 lSjImNjLWyvE for ; Wed, 18 Feb 2015 08:28:03 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 26E571A889C for ; Wed, 18 Feb 2015 08:28:03 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id B69EB438082; Wed, 18 Feb 2015 08:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Gu/F+mS0/+tmpq JlF5sVodvOCPY=; b=sKTzEfBBzkJYQkswmMM9F4o3gk7m4GyO//FPc3cWuuxMRj tl/0i/d0QfYSFT5x0jzPu+hD6LpVhfa4TgdaEux6mlg2XLddAOYLQslyVdXov8fw k/ETKc1BmsibZTQqJC5NsprtvHM9QwD0Lg7Qod/geJ0ag42GiKcMFpv/aNrsc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id CA204438080; Wed, 18 Feb 2015 08:28:01 -0800 (PST) Date: Wed, 18 Feb 2015 10:28:00 -0600 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150218162755.GQ5246@localhost> References: <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> <1424209200.2645.54.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424209200.2645.54.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:28:04 -0000 On Tue, Feb 17, 2015 at 04:40:00PM -0500, Nathaniel McCallum wrote: > In the current code, the actual key is generated by a hash of: > 1. the shared EC point: K > 2. the client principal > 3. the server principal > 4. all padata sent or received > > Currently, we do not truncate hashes to fit key size. So the hash > output must exactly match the expected size of the key. This is the > reason MD5 is enabled (to support 128bit keys). This is not a long > term plan. However, we should not allow, for instance, SHA1 to be used > to generate a 256bit key. Requiring that hash function outputs match enctype key sizes is terrible. Use a KDF, it's what it's there for; Kerberos has one. > Given the above, hashes are supported per etype. Don't do it that way :) > > Why is etype not a sequence? > > Because this contains the lists of supported groups and hashes for > that specific etype. See above and preceding reply. > We don't need to send enctypes. This is already sent in etypes. True. > Having them all be orthogonal is how I originally designed it. But I > changed it given the above considerations. Small hashes/ECs should not > be used to generate larger keys. That's not right. Smaller amounts of entropy can be used to generate larger keys. We do it all the time. It's what KDFs are for. Granted, one should not use *too* small an amount of entropy, but this is about setting a proper security floor. The client (and the AS) should set a security floor, say, 128-bit, 192-bit, or 256-bit. It should probably also set a ceiling (since we have no ciphers stronger than 256-bit, there's no point using groups at much higher security levels). Above the security floor, anything goes. Use a KDF to overcome impedance mismatches. > I think you mean 1 with the optimization (3) being optional. I only > wish to add that it should be optional for clients but required for > servers. Sure. Nico -- From nobody Wed Feb 18 10:34:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A325C1A001B for ; Wed, 18 Feb 2015 10:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 c1DHftby_ye0 for ; Wed, 18 Feb 2015 10:34:22 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E561A0007 for ; Wed, 18 Feb 2015 10:34:21 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-58-54e4db2cbca1 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 7B.46.30099.C2BD4E45; Wed, 18 Feb 2015 13:34:20 -0500 (EST) 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 t1IIYJl3010285; Wed, 18 Feb 2015 13:34:20 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1IIYHdA023689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2015 13:34:18 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1IIYH0Y007545; Wed, 18 Feb 2015 13:34:17 -0500 (EST) Date: Wed, 18 Feb 2015 13:34:16 -0500 (EST) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1424189675.2645.23.camel@redhat.com> Message-ID: References: <1424189675.2645.23.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqratz+0mIwb3dyhZHN69isZj7dRar A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJXxeMdftoI3nBUTb5c3MH5j72Lk5JAQMJE4 cng6G4QtJnHh3nogm4tDSGAxk0Trqo+MIAkhgY2MErcmJkLYh5gk9h9zgShqYJR4MXc12CQW AW2JJWf3M4PYbAIqEjPfbASbKiKgJ7Fs3wSgQRwczAJGEhd+ZYCEhQVsJSbf/g5WzgkUXnzs BFg5r4CDxMJDX1kgdoVLXHs0HaxGVEBHYvX+KSwQNYISJ2c+AbOZBbQklk/fxjKBUXAWktQs JKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgoNUkn8H47eDSocYBTgY lXh4O5iehAixJpYVV+YeYpTkYFIS5T1+EyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHfHPqAc b0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr8ctoEbBotT01Iq0zJwS hDQTByfIcB6g4akgNbzFBYm5xZnpEPlTjIpS4rwhIAkBkERGaR5cLyyJvGIUB3pFmLcNpIoH mIDgul8BDWYCGjz/zyOQwSWJCCmpBsYAj5mqwrOqq7XSP+ydLRiopL0n7lPj15QTGxevSLxu vcstT+loT/Xl3Ib+Nwf0+JWFp7arlugJ7XKX9E45eflj2Noi628J0/neC2Sy/qte4RSjZn1K NuTKlPSObn4Oy7BoBQmltkdb0p7KPdOdy+k2L+LFRrHtiv+9LhmZ2V+rzv3S4q5Yo8RSnJFo qMVcVJwIALXR82T9AgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 18:34:26 -0000 On Tue, 17 Feb 2015, Nathaniel McCallum wrote: > So a KDC can actually implement both 1 and 3 simultaneously. If the > KDC does not receive the padata in the first step (option 3), it > generates the empty hint (option 1). Otherwise, 1 and 3 are identical. > Only one thing differs: PREAUTH_REQUIRED or > MORE_PREAUTH_DATA_REQUIRED. Can we just always use the latter error? It is safe to use MORE_PREAUTH_DATA_REQUIRED since we can document that support for that error is a requirement of the new preauth mechanism. Determining whether it is acceptable to ask for MORE_PREAUTH in response to the initial AS-REQ (including the hints which we are calling optimistic preauth here), as opposed to just PREAUTH_REQUIRED, will probably require a close reading of the relevant RFCs. > After thinking about this (and implementing it), I think the best way > forward is 1 with 3 as an optional optimization. The KDC should always > support both 1 and 3; adding support for (optional) 3 should be > trivial. Clients should choose whether or not to support 3 based on > complexity of implementation; 3 can always be added later as an > optimization. That does seem like the best way forward, as the rest of the thread is concluding. -Ben From nobody Wed Feb 18 10:55:36 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698511A00E6 for ; Wed, 18 Feb 2015 10:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 a71O9pA8Gmnn for ; Wed, 18 Feb 2015 10:55:27 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846181A00FB for ; Wed, 18 Feb 2015 10:55:27 -0800 (PST) X-AuditID: 12074424-f79356d000004839-e4-54e4e01e5dc8 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E2.97.18489.E10E4E45; Wed, 18 Feb 2015 13:55:26 -0500 (EST) 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 t1IItP76027005; Wed, 18 Feb 2015 13:55:25 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1IItNKd031798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2015 13:55:24 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1IItM67010257; Wed, 18 Feb 2015 13:55:22 -0500 (EST) Date: Wed, 18 Feb 2015 13:55:22 -0500 (EST) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <54DD194D.2010201@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nriv34EmIwZVlQhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv7tJ5gLmnQqLhz4x9LAeFmpi5GTQ0LAROJK701mCFtM4sK9 9WxdjFwcQgKLmSS+LXjDCOFsZJSYOPsMO4RziEni1tKrTCAtQgINjBKP9iaA2CwC2hK3b+wA i7MJqEjMfLORDcQWEZCUOPbkPNAKDg5mASOJC78yQMLCAi4SBx68YASxOQX0JPon7gVr5RVw kHjW944J6gpGiYMHW8GKRAV0JFbvn8ICUSQocXLmEzCbWUBLYvn0bSwTGAVnIUnNQpJawMi0 ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIzgsXVR2MDYfUjrEKMDBqMTD28H0 JESINbGsuDL3EKMkB5OSKO+2e0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrw79gHleFMSK6tS i/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeN1BhgoWpaanVqRl5pQgpJk4OEGG 8wANTwGp4S0uSMwtzkyHyJ9iVJQS51UESQiAJDJK8+B6YWnjFaM40CvCvC0gVTzAlAPX/Qpo MBPQ4Pl/HoEMLklESEk1MM7PWvBjzvQHmXObfR76ahuoL5ndpZTekaIV29ItHfOw00gvtybG xfDN+hLOC3UJogtMFL0WqYtwbOQRna53VPSc2P8Ov8+dWQobr+hqn6qSkNf+ltL0ItXLyd2s +IDe5tz46RfSWk+qNz1lq/npv0Mvbp5Lt7qCZNsO74XrPuw3P6tXqBuixFKckWioxVxUnAgA Bwu2rvYCAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 18:55:32 -0000 On Thu, 12 Feb 2015, Tom Yu wrote: > Greg Hudson writes: > > > On 02/12/2015 01:47 PM, Benjamin Kaduk wrote: > >> Do you want to come up with a concrete proposal for new text? > > > > Sure. In section 8 (Security Considerations), replace "two exceptions" > > with "three exceptions," and add a third item to the list: > > > > --- > > 3. If the ticket server principal is a cross-realm TGS from a different > > realm, the CAMMAC's kdc-verifier cannot be validated because the > > checksum was made using the other realm's local TGS key. If the > > CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely > > assumed to have originated from the other realm. The KDC SHOULD NOT > > blindly copy CAMMAC elements originating from another realm, but MAY > > choose to filter, transform, and propagate elements according to policy > > rules, and MAY place a kdc-verifier in the new CAMMAC containing the > > resulting authorization data elements. > > --- > > > > I use MUST NOT instead of SHOULD NOT because a KDC might be in a > > subsidiary relationship to a higher-security realm. By "cross-realm TGS > > from a different realm," I mean an incoming cross-realm krbtgt principal > > like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell > > that out. > > This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy" > in your suggested text. Which did you intend? > > I would like to try to reason about this from a data origin > authentication standpoint. This might help us come up with more clear > and generally applicable wording. On the other hand, if we want to > minimize textual changes, reasoning about this might help us avoid > missing edge cases when we make the more minimal changes. > > The kdc-verifier provides data origin authentication that the CAMMAC > contents originated from the KDC itself (or another KDC serving the same > local realm). If the KDC successfully validates the kdc-verifier, it > can copy the CAMMAC contents knowing that either it or another KDC in > the realm originated the contents. There is also the local TGT special > case. In the other cases, where it can only validate the svc-verifier, > it must apply some policy about the provenance of the contents of the > CAMMAC to decide whether to copy the contents verbatim, filter, or > transform them. This includes both the non-S4U2Proxy service tickets > and the cross-realm TGTs. > > Exception (1) in the document is for the case where the > ticket-encrypting key is a key that only other KDCs in the local realm > know, and therefore provides the same properties of data origin > authentication that the kdc-verifier would. Exception (2) is different, > because the KDC has no assurance that the CAMMAC contents originated > from it or another KDC serving the same local realm. In this case, the > KDC makes a policy decision that the only consumers of the possibly > forged CAMMAC contents that it copies into a new CAMMAC are consumers > that would not suffer adverse effects from such a forgery. > > In the cross-realm case, the local realm KDC can only validate the > svc-verifier (because the only remote realm KDC can validate the > kdc-verifier). The local realm KDC makes a policy decision about how to > filter, transform, etc. the original CAMMAC contents to a new CAMMAC. > > I guess this is a roundabout way of suggesting text that includes: > > The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new > CAMMAC when it cannot validate the original CAMMAC as authentically > originating from itself or another KDC in its local realm. In such a The SHOULD NOT here makes me slightly uncomfortable. (I understand Greg's reasons for suggesting it, though.) Can we say something about MUST NOT ... as originating from itself or another KDC in its local realm or [some other trusted KDC; wording TBD]? This could potentially even include the cross-realm case. > situation, the KDC MAY choose to filter, transform, or propagate I think that what "such a situation" is potentially unclear and should be specified more concretely. > elements from the original CAMMAC to a new CAMMAC according to policy > rules, and MAY place a kdc-verifier in the new CAMMAC containing the > resulting authorization data elements. > > The two individually sufficient conditions for a KDC validating a > CAMMAC as authentically originating from itself or another KDC in its That's a rather complicated sentence; I expect it would confuse some readers. > local realm are: > > 1. The KDC successfully validates the kdc-verifier of the CAMMAC; or > > 2. The CAMMAC lacks a kdc-verifier, but the encryption key for its > surrounding ticket is one known exclusively by the local realm > KDCs (e.g., when the ticket is a local TGT), and all KDCs > serving the realm are configured to filter out CAMMAC > authorization data submitted by clients. > > Then we would somehow modify existing explanatory text about the > specific use cases, e.g.: > > 1. omission of kdc-verifier to make TGTs, etc., smaller -- safe to make > verbatim copies if the local realm KDCs are configured properly > > 2. omission of kdc-verifier when the only consumers of the CAMMAC are > the original service principal of the ticket (no S4U2Proxy > privileges) -- apply policy rules Would these involve changes outside section 8? -Ben > 3. incoming cross-realm TGTs -- apply policy rules > From nobody Wed Feb 18 11:18:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234B61A0016 for ; Wed, 18 Feb 2015 11:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 w5PynmwiMM8u for ; Wed, 18 Feb 2015 11:18:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 8D2FC1A00E7 for ; Wed, 18 Feb 2015 11:18:38 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IJIb7O001160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 14:18:37 -0500 Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IJIbpE003132; Wed, 18 Feb 2015 14:18:37 -0500 Message-ID: <1424287116.6980.35.camel@willson.usersys.redhat.com> From: Simo Sorce To: Benjamin Kaduk Date: Wed, 18 Feb 2015 14:18:36 -0500 In-Reply-To: References: <54DD194D.2010201@mit.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 19:18:47 -0000 On Wed, 2015-02-18 at 13:55 -0500, Benjamin Kaduk wrote: > On Thu, 12 Feb 2015, Tom Yu wrote: > > > Greg Hudson writes: > > > > > On 02/12/2015 01:47 PM, Benjamin Kaduk wrote: > > >> Do you want to come up with a concrete proposal for new text? > > > > > > Sure. In section 8 (Security Considerations), replace "two exceptions" > > > with "three exceptions," and add a third item to the list: > > > > > > --- > > > 3. If the ticket server principal is a cross-realm TGS from a different > > > realm, the CAMMAC's kdc-verifier cannot be validated because the > > > checksum was made using the other realm's local TGS key. If the > > > CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely > > > assumed to have originated from the other realm. The KDC SHOULD NOT > > > blindly copy CAMMAC elements originating from another realm, but MAY > > > choose to filter, transform, and propagate elements according to policy > > > rules, and MAY place a kdc-verifier in the new CAMMAC containing the > > > resulting authorization data elements. > > > --- > > > > > > I use MUST NOT instead of SHOULD NOT because a KDC might be in a > > > subsidiary relationship to a higher-security realm. By "cross-realm TGS > > > from a different realm," I mean an incoming cross-realm krbtgt principal > > > like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell > > > that out. > > > > This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy" > > in your suggested text. Which did you intend? > > > > I would like to try to reason about this from a data origin > > authentication standpoint. This might help us come up with more clear > > and generally applicable wording. On the other hand, if we want to > > minimize textual changes, reasoning about this might help us avoid > > missing edge cases when we make the more minimal changes. > > > > The kdc-verifier provides data origin authentication that the CAMMAC > > contents originated from the KDC itself (or another KDC serving the same > > local realm). If the KDC successfully validates the kdc-verifier, it > > can copy the CAMMAC contents knowing that either it or another KDC in > > the realm originated the contents. There is also the local TGT special > > case. In the other cases, where it can only validate the svc-verifier, > > it must apply some policy about the provenance of the contents of the > > CAMMAC to decide whether to copy the contents verbatim, filter, or > > transform them. This includes both the non-S4U2Proxy service tickets > > and the cross-realm TGTs. > > > > Exception (1) in the document is for the case where the > > ticket-encrypting key is a key that only other KDCs in the local realm > > know, and therefore provides the same properties of data origin > > authentication that the kdc-verifier would. Exception (2) is different, > > because the KDC has no assurance that the CAMMAC contents originated > > from it or another KDC serving the same local realm. In this case, the > > KDC makes a policy decision that the only consumers of the possibly > > forged CAMMAC contents that it copies into a new CAMMAC are consumers > > that would not suffer adverse effects from such a forgery. > > > > In the cross-realm case, the local realm KDC can only validate the > > svc-verifier (because the only remote realm KDC can validate the > > kdc-verifier). The local realm KDC makes a policy decision about how to > > filter, transform, etc. the original CAMMAC contents to a new CAMMAC. > > > > I guess this is a roundabout way of suggesting text that includes: > > > > The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new > > CAMMAC when it cannot validate the original CAMMAC as authentically > > originating from itself or another KDC in its local realm. In such a > > The SHOULD NOT here makes me slightly uncomfortable. (I understand Greg's > reasons for suggesting it, though.) Can we say something about MUST NOT > ... as originating from itself or another KDC in its local realm or [some > other trusted KDC; wording TBD]? This could potentially even include the > cross-realm case. Would it make more sense to say something like: The KDC MUST NOT make verbatim copies of CAMMAC contents into a new CAMMAC unless the original CAMMAC is authenticated by an originator that is fully trusted by the KDC. The KDC MAY choose to filter, transform, or propagate elements from the original CAMMAC according to local policy. This is less verbose and should be easier to read. It sill make clear (IMO) that CAMMAC can be trusted only if the KDC trusts fully one of the originators, which can be the local Realm's key or a Trusted Realm key, up to local policy. > > situation, the KDC MAY choose to filter, transform, or propagate > > I think that what "such a situation" is potentially unclear and should be > specified more concretely. See my proposal above to make this part also less unclear. There is no need for "such situation", the KDC may *always* choose top do as it wishes with the CAMMAC. HTH, Simo. > > elements from the original CAMMAC to a new CAMMAC according to policy > > rules, and MAY place a kdc-verifier in the new CAMMAC containing the > > resulting authorization data elements. > > > > The two individually sufficient conditions for a KDC validating a > > CAMMAC as authentically originating from itself or another KDC in its > > That's a rather complicated sentence; I expect it would confuse some > readers. > > > local realm are: > > > > 1. The KDC successfully validates the kdc-verifier of the CAMMAC; or > > > > 2. The CAMMAC lacks a kdc-verifier, but the encryption key for its > > surrounding ticket is one known exclusively by the local realm > > KDCs (e.g., when the ticket is a local TGT), and all KDCs > > serving the realm are configured to filter out CAMMAC > > authorization data submitted by clients. > > > > Then we would somehow modify existing explanatory text about the > > specific use cases, e.g.: > > > > 1. omission of kdc-verifier to make TGTs, etc., smaller -- safe to make > > verbatim copies if the local realm KDCs are configured properly > > > > 2. omission of kdc-verifier when the only consumers of the CAMMAC are > > the original service principal of the ticket (no S4U2Proxy > > privileges) -- apply policy rules > > Would these involve changes outside section 8? > > > -Ben > > > > 3. incoming cross-realm TGTs -- apply policy rules > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Feb 18 12:16:36 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080511A0A85 for ; Wed, 18 Feb 2015 12:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uO8tGgR-43pG for ; Wed, 18 Feb 2015 12:16:34 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047851A02F1 for ; Wed, 18 Feb 2015 12:16:33 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-2f-54e4f320d1ca 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 61.88.21729.023F4E45; Wed, 18 Feb 2015 15:16:32 -0500 (EST) 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 t1IKGVBx006581; Wed, 18 Feb 2015 15:16:32 -0500 Received: from [18.101.8.186] (vpn-18-101-8-186.mit.edu [18.101.8.186]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1IKGTMx030957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Feb 2015 15:16:31 -0500 Message-ID: <54E4F31D.5080103@mit.edu> Date: Wed, 18 Feb 2015 15:16:29 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nathaniel McCallum References: <1424189675.2645.23.camel@redhat.com> In-Reply-To: <1424189675.2645.23.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrqvw+UmIQWOHpsXRzatYLOZ+ncXq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGX8fLCUpWCfaMW8jSsZGxgXCnYxcnJICJhI POndzwhhi0lcuLeerYuRi0NIYDGTxOPWK4wQzkZGiVdHbrBAOEeYJNruPWEDaeEVUJPYdKiB HcRmEVCV6D/8nhXEZhNQlli/fysLiC0qECbxffMOZoh6QYmTM5+AxUUE9CSW7ZsAtppZQFji wva9YL3CArYSk29/B6sXEgiXuPZoOpjNKWAksfjYCTaIenWJP/MuMUPY8hLNW2czT2AUnIVk xSwkZbOQlC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRHMIuqjsYJxxS OsQowMGoxMPbwfQkRIg1say4MvcQoyQHk5Iob/pjoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3h37gHK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8GR+BGgWLUtNT K9Iyc0oQ0kwcnCDDeYCGLwOp4S0uSMwtzkyHyJ9iVJQS5+X9BJQQAElklObB9cJSzCtGcaBX hHlngLTzANMTXPcroMFMQIPn/3kEMrgkESEl1cAY4r0wwOjVP0vnM1kLdQ5wmyppzZ+7+/57 DoWm1osHBP+v5AvT+65+u9646ECpdfvkw94Z8Y8v5EX3pib+1GzQjIiM0QwKs/xwYBZfaPX7 K0tT9r8zO+diov569QMlzfm9oqvD1/8zM1x/cXH6lbc+7DydHE5Ljs9fm1HlNnuHJafu6dk2 h5iUWIozEg21mIuKEwEGUzybDAMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:16:36 -0000 I wrote (in summary): >> I think there are basically three options: >> 1. Add a third round trip >> 2. Use pseudo-enctypes >> 3. Use client preauth hints On 02/17/2015 11:14 AM, Nathaniel McCallum wrote: > 1 and 3 are also compatible workflows. In 3, the first AS-REQ is > exactly the same padata as the second AS-REQ in 1. That is to say, 3 > is an optimization of 1 where the first round-trip of 1, which > includes no meaningful data, is simply not used. Put another way, 3 is > just 1 with optimistic preauth. That's an interesting way of looking at things. It means we wouldn't have to amend RFC 6113, although we might be bending it a bit. Here are some considerations, which all seem manageable: * Traditionally, optimistic preauth is only done with some prior knowledge of what the KDC wants (see RFC 6113 section 2.3 paragraph 1). To get down to two round trips in the common case, an AS client needs to do optimistic PA-PAKE by default. * Of course PA-PAKE would need to be specified such that the first client message requires no knowledge from the KDC. This is pretty simple; the first client message can be defined to contain only sub-negotiation parameters. * Most KDC implementations will ignore the client's PA-PAKE padata if they don't implement it, and respond with PREAUTH_REQUIRED with METHOD-DATA. Some older KDCs (like MIT krb5 pre-1.7) will instead respond with PREAUTH_FAILED. Clients already need to deal with this behavior if they implement RFC 6112 encrypted padata negotiation or any similar extension, so this is not really a concern. * An optimistic PA-PAKE message should be cheap to compute (it's just parameters), but is still wasted bytes if the exchange winds up settling on a different mechanism or not using preauth at all. The more compactly we can represent client parameters, the less bandwidth we will waste and the fewer problems we will have with AS-REQs exceeding UDP limitations. * Can a client optimistically preauthenticate with multiple mechanisms? RFC 6113 doesn't really say either way. Without going into detail on the arguments pro and con: - If we assume no, then a client which does optimistic PA-PAKE by default can't do the same thing with any other mechanism. This could be a reasonable choice; the client implementation could always choose to drop back to three round trips for PA-PAKE if it wants to do optimistic PA-FUTURE-AWESOME by default in the future. - If we assume yes, then a client which does optimistic PA-PAKE is still privileging that mechanism by choosing to spend bandwith on it before it is negotiated. But it wouldn't necessarily have to exclude other mechanisms from doing the same thing. From nobody Wed Feb 18 12:43:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210071A1A5B for ; Wed, 18 Feb 2015 12:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 8n3Rl0O5Z9jg for ; Wed, 18 Feb 2015 12:43:45 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E71A1A28 for ; Wed, 18 Feb 2015 12:43:45 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 38B80674070; Wed, 18 Feb 2015 12:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=jfzV2cQ+MWwjl8 xqAsQlYVEs+dk=; b=Mo2C3jFB2Y838rOU0h2mnBKHyRKXERHixGckkha7yljBQH PHI9gpI/ahApEIGwoo0lOOsV6O+GAzWewYZUqNKyyodrZKjnBWxn5qNlaKmVk3hP nouMLhHSAMQanJs5o89N843DSaN8uy9HuIrp1cCUHjIfg2jseeq2rRfAupjLw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id CADFD674059; Wed, 18 Feb 2015 12:43:44 -0800 (PST) Date: Wed, 18 Feb 2015 14:43:44 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20150218204339.GR5246@localhost> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E4F31D.5080103@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:43:47 -0000 On Wed, Feb 18, 2015 at 03:16:29PM -0500, Greg Hudson wrote: > On 02/17/2015 11:14 AM, Nathaniel McCallum wrote: > > 1 and 3 are also compatible workflows. In 3, the first AS-REQ is > > exactly the same padata as the second AS-REQ in 1. That is to say, 3 > > is an optimization of 1 where the first round-trip of 1, which > > includes no meaningful data, is simply not used. Put another way, 3 is > > just 1 with optimistic preauth. > > That's an interesting way of looking at things. It means we wouldn't > have to amend RFC 6113, although we might be bending it a bit. Here are > some considerations, which all seem manageable: > > * Traditionally, optimistic preauth is only done with some prior > knowledge of what the KDC wants (see RFC 6113 section 2.3 paragraph 1). > To get down to two round trips in the common case, an AS client needs > to do optimistic PA-PAKE by default. When the client has only one pre-auth it's willing to do then it can be optimistic. That doesn't seem terribly likely in many cases, but for environments where 2fa is used for protecting some resources and not others, then it could be clear at AS-REQ time that the client only wants to do 2fa. Clients can also tell -sometimes- when they have credentials for PKINIT. And they can learn and cache -or have configured- whether a realm's KDCs support FAST for protecting PA-ENC-TIMESTAMP, and so on. It may not be such a stretch that a client will have just one pre-auth method that it's willing to use in some cases. > * Of course PA-PAKE would need to be specified such that the first > client message requires no knowledge from the KDC. This is pretty > simple; the first client message can be defined to contain only > sub-negotiation parameters. Yea, we're already there as to this proposal. > * Most KDC implementations will ignore the client's PA-PAKE padata if > they don't implement it, and respond with PREAUTH_REQUIRED with > METHOD-DATA. Some older KDCs (like MIT krb5 pre-1.7) will instead > respond with PREAUTH_FAILED. Clients already need to deal with this > behavior if they implement RFC 6112 encrypted padata negotiation or any > similar extension, so this is not really a concern. Good point. > * An optimistic PA-PAKE message should be cheap to compute (it's just > parameters), but is still wasted bytes if the exchange winds up settling > on a different mechanism or not using preauth at all. The more > compactly we can represent client parameters, the less bandwidth we will > waste and the fewer problems we will have with AS-REQs exceeding UDP > limitations. We can greatly "compress" it by using bit sets (which could be compressed if there are many contiguous zero bits in the bit string). The trade-off is requiring a registry. For PAKEs and groups, an OID would do just fine, or we could use an existing (or upcoming) registry. A middle of the road proposal would be to use a bit set for registered PAKEs and groups and an optional set (sequence) of OIDs for all others. But all this to save a bit of space? Before we go there we should determine that this really is a problem we need to address. > * Can a client optimistically preauthenticate with multiple mechanisms? > RFC 6113 doesn't really say either way. Without going into detail on > the arguments pro and con: A separate update to RFC6113 about this would be nice. > - If we assume no, then a client which does optimistic PA-PAKE by > default can't do the same thing with any other mechanism. This could be > a reasonable choice; the client implementation could always choose to > drop back to three round trips for PA-PAKE if it wants to do optimistic > PA-FUTURE-AWESOME by default in the future. Well... See above. Also, a client could be somewhat abusive and send N single-preauth AS-REQs concurrently, hoping one of them will succeed. > - If we assume yes, then a client which does optimistic PA-PAKE is > still privileging that mechanism by choosing to spend bandwith on it > before it is negotiated. But it wouldn't necessarily have to exclude > other mechanisms from doing the same thing. Yes, but hopefully the client knows from context that it will need this PA method. From nobody Wed Feb 18 13:45:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06BE1A1AFB for ; Wed, 18 Feb 2015 13:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JjNxSRmnbvrH for ; Wed, 18 Feb 2015 13:45:14 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435D81A1AE2 for ; Wed, 18 Feb 2015 13:45:14 -0800 (PST) X-AuditID: 1209190d-f792d6d000001fc7-6e-54e507e848a9 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 6C.E7.08135.9E705E45; Wed, 18 Feb 2015 16:45:13 -0500 (EST) 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 t1ILjCh3017764; Wed, 18 Feb 2015 16:45:12 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1ILjAU8019492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2015 16:45:11 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1ILj9HL002706; Wed, 18 Feb 2015 16:45:09 -0500 (EST) Date: Wed, 18 Feb 2015 16:45:09 -0500 (EST) From: Benjamin Kaduk To: Thomas Maslen In-Reply-To: Message-ID: References: , User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrPuS/WmIwawWLoujm1exWLxubGJy YPJYsuQnk0ffMZcApigum5TUnMyy1CJ9uwSujCX/H7AUXBCu2HX1JVsDY49AFyMnh4SAiURL yyM2CFtM4sK99UA2F4eQwGImiVf7t0A5GxklHj34yg7hHGKS6GjdAJVpYJR4MeMXWD+LgLbE hf23WUBsNgEViZlvNoLFRQSMJT4tXQ5mMwuoS3w784axi5GDQ1jARuLkh3CQMKdAoMTaEx8Z QWxeAQeJZXffM0LMP8Uo8fjzQ2aQhKiAjsTq/VNYIIoEJU7OfMICMVNLYvn0bSwTGAVnIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIzhUJXl3ML47qHSIUYCD UYmHt4PpSYgQa2JZcWXuIUZJDiYlUd40tqchQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4d+wD KudNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuBdATJUsCg1PbUiLTOn BCHNxMEJMpwHaPhpkBre4oLE3OLMdIj8KUZFKXHeRpCEAEgiozQPrheWSl4xigO9IszLDUws QjzANATX/QpoMBPQ4Pl/HoEMLklESEk1MHqdlUuZtOnRhMyLcfKlimePyZxNPM1jcfb4SrX6 pBnb3/QXd20/4bulKO3ktBdK+8rUVCP+Z2hc6Z48d175+rmdkvcMshdobG3x33W1MPLMujcB Qb/OS046LBrTcHntZ85Uox/MCdU1Gyf8Zud8qtV5eanRIo0GDpNbSw4rGtVHyT9XYI7QZlZi Kc5INNRiLipOBABP5FlwAAMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-rfc5653bis-02 review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 21:45:17 -0000 On Sat, 14 Feb 2015, Thomas Maslen wrote: > On Thu, 12 Feb 2015, Benjamin Kaduk wrote: > > [...] > > While there is a strong sequencing requirement for context-level tokens > > (the negotiation loop proceeds in lockstep), and so a stream-based method > > would definitely be workaboe there, the per-message operations do not have > > that ordering requirement. I think it would be an unreasonable burden on > > an application to expect it to supply input streams to the per-message > > GSS operations which are guaranteed to only supply a single token. Even > > though it is possible to do, it requires a lot of effort to do correctly. > > Quite possibly I'm missing something obvious or just haven't thought this through, but: > > Even in really complex scenarios, e.g. running with requestSequenceDet(false) + concurrent / unordered delivery of application messages from the peer (e.g. using UDP or a separate TCP connection for each) + multiple threads operating concurrently to receive these application messages and present their per-message tokens to the GSSContext instance, I believe that it's as easy (or as difficult) to use the stream-based methods as it is to use the byte-array methods. > > Possibly relevant: note that the spec (2853, 5653, 5653bis) doesn't promise anything about concurrency w.r.t. the methods of a GSSContext instance (nor about anything else in the API, for that matter) -- in particular, the Java keyword "synchronized" doesn't appear anywhere. [Yes, it might be a good thing if this were more explicit in the spec, whereas at present it's very very implicit; by contrast, GSSContext's Javadoc in the JDK > > http://docs.oracle.com/javase/1.5.0/docs/api/org/ietf/jgss/GSSContext.html > > comes right out and says "Also note that none of the methods in this interface are synchronized. Therefore, it is not advisable to share a GSSContext among several threads unless some application level synchronization is in place"]. > > The byte-array methods may intuitively seem to be kinda sorta "more > atomic" than the stream-based methods, but they aren't; if you're using > multiple threads to feed per-message tokens to a GSSContext instance > then you're responsible for serializing the calls, regardless of whether > you're using the byte-array methods or the stream-based methods. I suspect you are right, and I am just having a hard time getting out of my array-based mindset instilled from the C bindings. Sorry about that, Ben From nobody Thu Feb 19 21:44:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF591A01D5; Thu, 19 Feb 2015 21:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 FEfOT_5lGigG; Thu, 19 Feb 2015 21:44:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6697D1A6FF6; Thu, 19 Feb 2015 21:44:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220054410.12428.36788.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 21:44:10 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gss-loop-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 05:44:19 -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 Working Group of the IETF. Title : Structure of the GSS Negotiation Loop Author : Benjamin Kaduk Filename : draft-ietf-kitten-gss-loop-05.txt Pages : 21 Date : 2015-02-19 Abstract: This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 19 21:46:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AD41A6FE6 for ; Thu, 19 Feb 2015 21:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oLVKMEBi7vMs for ; Thu, 19 Feb 2015 21:46:22 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B301A6FBB for ; Thu, 19 Feb 2015 21:46:21 -0800 (PST) X-AuditID: 1209190c-f79696d000005933-5e-54e6ca2c03a4 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 17.75.22835.C2AC6E45; Fri, 20 Feb 2015 00:46:20 -0500 (EST) 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 t1K5kJ10010714 for ; Fri, 20 Feb 2015 00:46:20 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1K5kFuI005538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Feb 2015 00:46:16 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1K5kFBd003189; Fri, 20 Feb 2015 00:46:15 -0500 (EST) Date: Fri, 20 Feb 2015 00:46:14 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20150220054410.12428.36788.idtracker@ietfa.amsl.com> Message-ID: References: <20150220054410.12428.36788.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixG6noqtz6lmIwYlpyhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvE7PYwFTVwVb7oaWBsYn7B3MXJySAiYSOy6dpAVwhaTuHBv PVsXIxeHkMBiJonXv2azQzjHGSUWPr/IDOHcYJJonjmHEcJpYJToWtEM1s8ioC3xq+UcmM0m oCIx881GNhBbREBYYvfWd8wgtrCAs8Sbp4/B4pwCThKLOzoYQWxeAQeJzcd3MYHYQgKOEpO3 rgW7T1RAR2L1/iksEDWCEidnPgGzmQW0JJZP38YygVFgFpLULCSpBYxMqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3QN9XIzS/RSU0o3MYICkFOSZwfjm4NKhxgFOBiVeHgrpj8LEWJNLCuuzD3E KMnBpCTKa7sIKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEt2cSUI43JbGyKrUoHyYlzcGiJM67 6QdfiJBAemJJanZqakFqEUxWhoNDSYJ3xwmgRsGi1PTUirTMnBKENBMHJ8hwHqDhZ0BqeIsL EnOLM9Mh8qcYFaXEeTeAJARAEhmleXC9sATxilEc6BVh3gcgVTzA5ALX/QpoMBPQ4Pl/HoEM LklESEk1MOre0F99w2yhjOPFgDKuRMG6GS1hfDYOIutFWU4KXv31Lb3k2tF8RdUd8b4ejhfZ o5NSH/KYJmomfOIxbNs2XYCnl1M2Y0qs4Kze8F9MHn4rlY5eC5y1nmu/5Qcj/uiLORNuWTxv vc+jLGfQ+2xzy/ykxCmpEbUPH+7fwPPadUl7O3/8/HP5SizFGYmGWsxFxYkAr4ZejusCAAA= Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gss-loop-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 05:46:24 -0000 On Fri, 20 Feb 2015, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Structure of the GSS Negotiation Loop > Author : Benjamin Kaduk > Filename : draft-ietf-kitten-gss-loop-05.txt > Pages : 21 > Date : 2015-02-19 > > Abstract: > This document specifies the generic structure of the negotiation loop > to establish a GSS security context between initiator and acceptor. > The control flow of the loop is indicated for both parties, including > error conditions, and indications are given for where application- > specific behavior must be specified. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-05 This version makes some minor tweaks suggested by the secdir reviewer. -Ben From nobody Fri Feb 20 13:04:55 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714221A87B2 for ; Fri, 20 Feb 2015 13:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AhBARnguFPeV for ; Fri, 20 Feb 2015 13:04:52 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBA21A0161 for ; Fri, 20 Feb 2015 13:04:51 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-50-54e7a1726a69 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 80.1A.30099.271A7E45; Fri, 20 Feb 2015 16:04:50 -0500 (EST) 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 t1KL4neC028622; Fri, 20 Feb 2015 16:04:50 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1KL4kcd005685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Feb 2015 16:04:48 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1KL4iVA014773; Fri, 20 Feb 2015 16:04:44 -0500 (EST) Date: Fri, 20 Feb 2015 16:04:44 -0500 (EST) From: Benjamin Kaduk To: Simo Sorce In-Reply-To: <1424287116.6980.35.camel@willson.usersys.redhat.com> Message-ID: References: <54DD194D.2010201@mit.edu> <1424287116.6980.35.camel@willson.usersys.redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrVu08HmIQWOTnsXRzatYLH7MXcTq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGW8uJZT8FmgYkHDB+YGxjc8XYycHBICJhKb dx1hg7DFJC7cWw9kc3EICSxmkmh4/QAsISSwkVHi/GpPiMQhJone/hssEE4Do8S5z3uYQapY BLQltnZdYQWx2QRUJGa+2QjWLSKgILGg/w4LiM0soCXxaPFSJhBbWMBF4sCDF4wgNqeAk8Ts G71gNbwCDhIdt5ugFkxmktjTfwNsgaiAjsTq/VOgigQlTs58Ajd0+fRtLBMYBWchSc1CklrA yLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMjOFQl+XcwfjuodIhRgINRiYe3 YvqzECHWxLLiytxDjJIcTEqivJ29z0OE+JLyUyozEosz4otKc1KLDzFKcDArifDaZwDleFMS K6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeE/PB2oULEpNT61Iy8wpQUgz cXCCDOcBGq64AGR4cUFibnFmOkT+FKOilDgvC0hCACSRUZoH1wtLJa8YxYFeEea1BqniAaYh uO5XQIOZgAYf+PoMZHBJIkJKqoGxMqL41l2rMlmPl4Yh9i2Xnhy+tjNtd3jyxC+3DI1mnbx7 ZYpaPmtE2+EOoasO7r9PqG9LEItuE1KPq/zmuJi3YUrY2hTrw8qnFlYd3t7xe9as/Xk1s8Wf 2OV6Ra16UNLd6REaV2mxOyp6UcVyk9tK7gXM5xn8o7wF3s9rrvJXjb2+7RWfXZcSS3FGoqEW c1FxIgAvoXbTAAMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:04:54 -0000 On Wed, 18 Feb 2015, Simo Sorce wrote: > On Wed, 2015-02-18 at 13:55 -0500, Benjamin Kaduk wrote: > > On Thu, 12 Feb 2015, Tom Yu wrote: > > > > > Greg Hudson writes: > > > > > > > > > I guess this is a roundabout way of suggesting text that includes: > > > > > > The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new > > > CAMMAC when it cannot validate the original CAMMAC as authentically > > > originating from itself or another KDC in its local realm. In such a > > > > The SHOULD NOT here makes me slightly uncomfortable. (I understand Greg's > > reasons for suggesting it, though.) Can we say something about MUST NOT > > ... as originating from itself or another KDC in its local realm or [some > > other trusted KDC; wording TBD]? This could potentially even include the > > cross-realm case. > > Would it make more sense to say something like: > > The KDC MUST NOT make verbatim copies of CAMMAC contents into a > new CAMMAC unless the original CAMMAC is authenticated by an > originator that is fully trusted by the KDC. > The KDC MAY choose to filter, transform, or propagate elements > from the original CAMMAC according to local policy. It might. Is this the first time we are using the word "trusted" in a Kerberos RFC, though? And being concrete does have something going for it (we just have to get it right). > This is less verbose and should be easier to read. It sill make clear > (IMO) that CAMMAC can be trusted only if the KDC trusts fully one of the > originators, which can be the local Realm's key or a Trusted Realm key, > up to local policy. > > > > situation, the KDC MAY choose to filter, transform, or propagate > > > > I think that what "such a situation" is potentially unclear and should be > > specified more concretely. > > See my proposal above to make this part also less unclear. There is no > need for "such situation", the KDC may *always* choose top do as it > wishes with the CAMMAC. And that is true; the KDC can always choose to do whatever it wants, in some sense. -Ben From nobody Fri Feb 20 13:53:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39761A019B for ; Fri, 20 Feb 2015 13:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NmvTBivpiyx1 for ; Fri, 20 Feb 2015 13:53:29 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4371A0203 for ; Fri, 20 Feb 2015 13:53:13 -0800 (PST) X-AuditID: 12074424-f79356d000004839-e9-54e7acc82eb8 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id C7.4B.18489.8CCA7E45; Fri, 20 Feb 2015 16:53:12 -0500 (EST) 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 t1KLrBGp002739; Fri, 20 Feb 2015 16:53:12 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1KLr9TE022980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Feb 2015 16:53:11 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1KLr98S022037; Fri, 20 Feb 2015 16:53:09 -0500 (EST) Date: Fri, 20 Feb 2015 16:53:09 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrXtizfMQg4MzlCy+tj1gszi6eRWL A5PHkiU/mTxWTj3NHsAUxWWTkpqTWZZapG+XwJXRe3A6S8Ep/opJ7ZdZGhi/8XQxcnJICJhI dN+8xgxhi0lcuLeeDcQWEljMJDHpa2QXIxeQvZFRYvn1U0wQziEmiZMtN1ggnAZGicOnr4C1 swhoS9xf18UKYrMJqEjMfLMRbJSIgLDE7q3vwGqYBUQk/qy6zQrSLCwwk1Gi80wzE0iCU8BJ ou9ZI1gDr4CDxOd1Nxgh7nCUmHZpGzuILSqgI7F6/xQWiBpBiZMzn7BADNWSWD59G8sERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECApWdheVHYzNh5QO MQpwMCrx8FZMfxYixJpYVlyZe4hRkoNJSZT398rnIUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eOctAMrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwnlsN1ChYlJqe WpGWmVOCkGbi4AQZzgM0/C5IDW9xQWJucWY6RP4Uo6KUOG8TSEIAJJFRmgfXC0smrxjFgV4R 5g0AqeIBJiK47ldAg5mABh/4+gxkcEkiQkqqgVGJK99w2Q2DyNbZ9388veFgt/Bw1lT5pNvb eRKVV/6dotVR4ps9+2Fu2Qvh8z2fFgaK+9q5WjHxn5kff1Os97DgV4YbvBWXmuLra4PKA32+ b27dcHPO/mM/duy+dfuf5iqBnE+X5l9Iu3U4aV4si8yJbbvrfznvUhP5deQr1xou7bOJKkfn Oc5UYinOSDTUYi4qTgQAAiZdTgEDAAA= Archived-At: Cc: hartmans@MIT.EDU Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:53:31 -0000 On Tue, 20 Jan 2015, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) for the following > three documents: "A Pseudo-Random Function (PRF) for the Kerberos V > Generic Security Service Application Program Interface (GSS-API) > Mechanism" , "Generic Security Service > API Version 2: Java Bindings Update" , > and "Anonymity Support for Kerberos" . > Because there are three documents under review, and the whole body of the > documents are up for re-review (not just the updates), the WGLC is > extended to four weeks, so the WGLC will end on Tuesday February 17th, > 2015. The drafts are available at: > > http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00 > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 (an -02 witih editorial fixes was issued during the WGLC) > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 Now that the WGLC period is over, I've gone through the on-list discussion to determine the outcome of the WGLC. Shawn has made some editorial fixes to rfc4402bis already; there are a few more, but then I think we can put out an -01 and progress it forward. There seems to be general agreement on the GSSException additions in rfc5653bis, but further discussion is needed on the preexisting issue raised about the stream-based methods. It seems likely that the resulting document update will be substantial enough to require another WGLC. rfc6112bis received the fewest comments, which were mostly editorial but a couple minor substantive issues were raised. A new version should be issued incorporating the suggested changes. The minor substantive issues may be minor enough that another WGLC is not needed, but it is not entirely clear since the new text is not finalized yet. Sam, you submitted the -00 -- will you be able to submit the update as well? Thanks, Ben From nobody Mon Feb 23 10:18:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C41A1EB7 for ; Mon, 23 Feb 2015 10:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YrVIPCgoFXLr for ; Mon, 23 Feb 2015 10:18:06 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFBE1A1E0F for ; Mon, 23 Feb 2015 10:18:06 -0800 (PST) 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 t1NII2tJ009526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Feb 2015 18:18:03 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t1NII2C0006449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Feb 2015 18:18:02 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1NII1Qs018976; Mon, 23 Feb 2015 18:18:02 GMT Received: from [10.159.86.55] (/10.159.86.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Feb 2015 10:18:01 -0800 Message-ID: <54EB6F1C.6070804@oracle.com> Date: Mon, 23 Feb 2015 11:19:08 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20150125 Thunderbird/17.0.11 MIME-Version: 1.0 To: Nico Williams References: <54CE9F5B.9070808@mit.edu> <54E2BFE4.4000003@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-ietf-kitten-rfc4402bis-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:18:08 -0000 On 02/17/15 08:40 PM, Nico Williams wrote: > On Tue, Feb 17, 2015 at 8:43 PM, Benjamin Kaduk wrote: >> On Mon, 16 Feb 2015, Shawn M Emery wrote: >>> Thanks for your review, comments in-line... >>> On 02/13/15 11:16 AM, Benjamin Kaduk wrote: >>> >>>> The original RFC 4402 security considerations include: >>>> >>>> [...] if an >>>> application can be tricked into providing very large input octet >>>> strings and requesting very long output octet strings, then that may >>>> constitute a denial of service attack on the application; therefore, >>>> applications SHOULD place appropriate limits on the size of any input >>>> octet strings received from their peers without integrity protection. >>>> >>>> It is not clear to me that integrity protection is sufficient to alleviate >>>> the denial of service attack, since verifying the message integrity may >>>> itself consume a substantial amount of resources. >>> I interpret this statement differently: >>> >>> If integrity protection is not enforced then an attacker can construct an >>> arbitrarily long string. >> >> Woudln't the attacker be able to do that without needing a very large >> input string, though? I guess the claims it that each individual >> pseudo-random() call is more expensive on a long input, so your >> interpretation is still plausible. > I think the original was about use of the PRF to bind something like, > say, a TLS handshake. Now suppose you send such messages that are > very large prior to completing authentication. > > Anyways, it's not a realistic problem. I think that was stretching to > cover what in retrospect strikes me as a non-issue. If this is the case then I think this problem is really outside the scope of the specification and in general applications would be susceptible to such DoS attacks. I believe the consensus in the WG is that this sentence be elided from the bis draft. I will make the necessary update if so. BTW, I should probably move myself as an editor of the draft. Shawn. -- From nobody Mon Feb 23 12:13:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1161A6F03 for ; Mon, 23 Feb 2015 12:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 P8DMZKdvA84h for ; Mon, 23 Feb 2015 12:13:48 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 942A21A3BA6 for ; Mon, 23 Feb 2015 12:13:48 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1NKDj2f012060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Feb 2015 15:13:45 -0500 Received: from vpn-59-5.rdu2.redhat.com (vpn-59-5.rdu2.redhat.com [10.10.59.5]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1NKDioY029026 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Feb 2015 15:13:45 -0500 Message-ID: <1424722422.2604.77.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Mon, 23 Feb 2015 15:13:42 -0500 In-Reply-To: <20150218204339.GR5246@localhost> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 20:13:51 -0000 On Wed, 2015-02-18 at 14:43 -0600, Nico Williams wrote: > On Wed, Feb 18, 2015 at 03:16:29PM -0500, Greg Hudson wrote: > > On 02/17/2015 11:14 AM, Nathaniel McCallum wrote: > > > 1 and 3 are also compatible workflows. In 3, the first AS-REQ is > > > exactly the same padata as the second AS-REQ in 1. That is to > > > say, 3 is an optimization of 1 where the first round-trip of 1, > > > which includes no meaningful data, is simply not used. Put > > > another way, 3 is just 1 with optimistic preauth. > > > > That's an interesting way of looking at things. It means we > > wouldn't have to amend RFC 6113, although we might be bending it a > > bit. Here are some considerations, which all seem manageable: > > > > * Traditionally, optimistic preauth is only done with some prior > > knowledge of what the KDC wants (see RFC 6113 section 2.3 > > paragraph 1). > > To get down to two round trips in the common case, an AS client > > needs > > to do optimistic PA-PAKE by default. > > When the client has only one pre-auth it's willing to do then it can > be optimistic. That doesn't seem terribly likely in many cases, but > for environments where 2fa is used for protecting some resources and > not others, then it could be clear at AS-REQ time that the client > only wants to do 2fa. > > Clients can also tell -sometimes- when they have credentials for > PKINIT. And they can learn and cache -or have configured- whether a > realm's KDCs support FAST for protecting PA-ENC-TIMESTAMP, and so > on. It may not be such a stretch that a client will have just one > pre-auth method that it's willing to use in some cases. > > > * Of course PA-PAKE would need to be specified such that the first > > client message requires no knowledge from the KDC. This is pretty > > simple; the first client message can be defined to contain only > > sub-negotiation parameters. > > Yea, we're already there as to this proposal. > > > * Most KDC implementations will ignore the client's PA-PAKE padata > > if > > they don't implement it, and respond with PREAUTH_REQUIRED with > > METHOD-DATA. Some older KDCs (like MIT krb5 pre-1.7) will instead > > respond with PREAUTH_FAILED. Clients already need to deal with > > this behavior if they implement RFC 6112 encrypted padata > > negotiation or any similar extension, so this is not really a > > concern. > > Good point. > > > * An optimistic PA-PAKE message should be cheap to compute (it's > > just > > parameters), but is still wasted bytes if the exchange winds up > > settling on a different mechanism or not using preauth at all. > > The more compactly we can represent client parameters, the less > > bandwidth we will waste and the fewer problems we will have with > > AS-REQs exceeding UDP limitations. > > We can greatly "compress" it by using bit sets (which could be > compressed if there are many contiguous zero bits in the bit string). > > The trade-off is requiring a registry. For PAKEs and groups, an OID > would do just fine, or we could use an existing (or upcoming) > registry. > > A middle of the road proposal would be to use a bit set for > registered PAKEs and groups and an optional set (sequence) of OIDs > for all others. > > But all this to save a bit of space? Before we go there we should > determine that this really is a problem we need to address. On the call last week there was a general consensus to move forward with SPAKE2 and not make PAKEs negotiable. SPAKE2 has all the properties we care about. It: * has a formal security proof that is well regarded * takes only a single roundtrip * supports elliptic curves * has wide deployment (via Chromium/Chrome) We also had a general consensus that there is no need to negotiate hashes. There are three hash uses: 1. Transcript for message integrity 2. Key derivation 3. Key validation For #1, we can just use the checksum method implicit in the enctype. For #2, we can just use a KDF. For #3, Greg had an idea, but I've since forgotten it and can't find it in my email. Greg, perhaps you can remind me? Enctype negotiation is implicit from the existing exchange. This leaves only groups and second factors. We also discussed making group negotiation have a note in the RFC about being careful regarding the number of groups exposed. I suspect sensible defaults will be: * P-256 * P-384 * P-521 * Curve25519 OpenSSL does not support Curve25519 (yet) so it won't be offered in my implementation. One reason I don't think it will be a problem is that no other data is sent in the group negotiation packet from the client to the server. The response from the server will contain just one group OID along with the public key and the 2FA negotiation parameters. I suggest an empirical approach here. I'll be developing the RFC in parallel with the application itself. If we see this becoming a problem, we can address it at that time. I am open even to bit set negotiation if space becomes a serious concern. I would simply like to avoid a registry if it is not needed. > > * Can a client optimistically preauthenticate with multiple > > mechanisms? > > RFC 6113 doesn't really say either way. Without going into > > detail on > > the arguments pro and con: > > A separate update to RFC6113 about this would be nice. > > > - If we assume no, then a client which does optimistic PA-PAKE by > > default can't do the same thing with any other mechanism. This > > could be a reasonable choice; the client implementation could > > always choose to drop back to three round trips for PA-PAKE if it > > wants to do optimistic PA-FUTURE-AWESOME by default in the future. > > Well... See above. Also, a client could be somewhat abusive and > send N single-preauth AS-REQs concurrently, hoping one of them will > succeed. > > > - If we assume yes, then a client which does optimistic PA-PAKE > > is > > still privileging that mechanism by choosing to spend bandwith on > > it before it is negotiated. But it wouldn't necessarily have to > > exclude other mechanisms from doing the same thing. > > Yes, but hopefully the client knows from context that it will need > this PA method. From nobody Mon Feb 23 13:12:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C179D1A6F03 for ; Mon, 23 Feb 2015 13:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Q6YNuoSyKg65 for ; Mon, 23 Feb 2015 13:12:12 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B8C921A6F01 for ; Mon, 23 Feb 2015 13:12:12 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 888102004F4DE for ; Mon, 23 Feb 2015 13:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZJfcZwqr3EvXHDdE5HpP kBH/gsI=; b=r7jMhrbFkQMPiu5iGo2MZgEXFGpmxNGSEM7BB64yjMXCb8WsLTYA XW9OCKjYP9YmTraveNMm52Se2LcjuFj+/CZZTiJxR3HBislK/Uc+SHqxndT+sPMs PYcC6BW7fvjweHmLCgyspYCvvrhtHntm9oyAyBl6+qS4ZYmD7iSNOM0= Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 7BD872004F4DC for ; Mon, 23 Feb 2015 13:12:12 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so21787724igb.2 for ; Mon, 23 Feb 2015 13:12:12 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.168 with SMTP id x8mr7735729igl.28.1424725932042; Mon, 23 Feb 2015 13:12:12 -0800 (PST) Received: by 10.64.130.66 with HTTP; Mon, 23 Feb 2015 13:12:11 -0800 (PST) In-Reply-To: <1424722422.2604.77.camel@redhat.com> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> Date: Mon, 23 Feb 2015 15:12:11 -0600 Message-ID: From: Nico Williams To: Nathaniel McCallum Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:12:13 -0000 On Mon, Feb 23, 2015 at 2:13 PM, Nathaniel McCallum wrote: > On the call last week there was a general consensus to move forward > with SPAKE2 and not make PAKEs negotiable. SPAKE2 has all the > properties we care about. It: Sure, a PAKE per-pre-auth. If we want new PAKEs, we clone this pre-auth, change the PAKE, give it a new number. > We also had a general consensus that there is no need to negotiate > hashes. There are three hash uses: > 1. Transcript for message integrity > 2. Key derivation > 3. Key validation > > For #1, we can just use the checksum method implicit in the enctype. > > For #2, we can just use a KDF. > > For #3, Greg had an idea, but I've since forgotten it and can't find > it in my email. Greg, perhaps you can remind me? Just use the enctype's authenticated encryption, natch. > Enctype negotiation is implicit from the existing exchange. This > leaves only groups and second factors. Making second factors negotiable is going to make the UI very fun :/ But it probably has to get done anyways. > We also discussed making group negotiation have a note in the RFC > about being careful regarding the number of groups exposed. I suspect > sensible defaults will be: > * P-256 > * P-384 > * P-521 > * Curve25519 Sure. > OpenSSL does not support Curve25519 (yet) so it won't be offered in my > implementation. OpenSSL needs to add Curve25519 support ASAP (particularly now that there is consensus in CFRG for Curve25519 as an RTI at the 128-bit security level), but is a subject for a different list. > One reason I don't think it will be a problem is that no other data is What won't be a problem? > sent in the group negotiation packet from the client to the server. > The response from the server will contain just one group OID along > with the public key and the 2FA negotiation parameters. > > I suggest an empirical approach here. I'll be developing the RFC in > parallel with the application itself. If we see this becoming a > problem, we can address it at that time. I am open even to bit set > negotiation if space becomes a serious concern. I would simply like to > avoid a registry if it is not needed. Eh, if I understood correctly you're saying that the client shouldn't send a list/set of groups. Either the client does send a set/list of groups or the server must return a PAKE message for each group. The latter is not going to work well for every PAKE. Having the server choose one without any idea of what the client supports just won't do. Just have the client send a set (SEQUENCE) of OIDs. If you really hate the wire bloat, then send both, an enum bit string and a sequence of OIDs, with the latter absent when only registered groups are proposed and the former absent when no registered groups are proposed. Nico -- From nobody Mon Feb 23 13:22:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE201A6F27 for ; Mon, 23 Feb 2015 13:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 in2n1nxL8a2h for ; Mon, 23 Feb 2015 13:22:24 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 D9A071A6F1E for ; Mon, 23 Feb 2015 13:22:24 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLMN9I017964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Feb 2015 16:22:23 -0500 Received: from vpn-59-5.rdu2.redhat.com (vpn-59-5.rdu2.redhat.com [10.10.59.5]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLMMUh023625 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Feb 2015 16:22:23 -0500 Message-ID: <1424726541.2604.82.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Mon, 23 Feb 2015 16:22:21 -0500 In-Reply-To: References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:22:26 -0000 On Mon, 2015-02-23 at 15:12 -0600, Nico Williams wrote: > On Mon, Feb 23, 2015 at 2:13 PM, Nathaniel McCallum < > npmccallum@redhat.com> wrote: > > On the call last week there was a general consensus to move > > forward with SPAKE2 and not make PAKEs negotiable. SPAKE2 has all > > the > > properties we care about. It: > > Sure, a PAKE per-pre-auth. If we want new PAKEs, we clone this pre- > auth, change the PAKE, give it a new number. > > > We also had a general consensus that there is no need to negotiate > > hashes. There are three hash uses: > > 1. Transcript for message integrity > > 2. Key derivation > > 3. Key validation > > > > For #1, we can just use the checksum method implicit in the > > enctype. > > > > For #2, we can just use a KDF. > > > > For #3, Greg had an idea, but I've since forgotten it and can't > > find it in my email. Greg, perhaps you can remind me? > > Just use the enctype's authenticated encryption, natch. > > > Enctype negotiation is implicit from the existing exchange. This > > leaves only groups and second factors. > > Making second factors negotiable is going to make the UI very fun :/ > But it probably has to get done anyways. > > > We also discussed making group negotiation have a note in the RFC > > about being careful regarding the number of groups exposed. I > > suspect sensible defaults will be: > > * P-256 > > * P-384 > > * P-521 > > * Curve25519 > > Sure. > > > OpenSSL does not support Curve25519 (yet) so it won't be offered > > in my implementation. > > OpenSSL needs to add Curve25519 support ASAP (particularly now that > there is consensus in CFRG for Curve25519 as an RTI at the 128-bit > security level), but is a subject for a different list. > > > One reason I don't think it will be a problem is that no other > > data is > > What won't be a problem? OID bloat. > > sent in the group negotiation packet from the client to the > > server. The response from the server will contain just one group > > OID along with the public key and the 2FA negotiation parameters. > > > > I suggest an empirical approach here. I'll be developing the RFC > > in parallel with the application itself. If we see this becoming a > > problem, we can address it at that time. I am open even to bit set > > negotiation if space becomes a serious concern. I would simply > > like to avoid a registry if it is not needed. > > Eh, if I understood correctly you're saying that the client > shouldn't send a list/set of groups. > > Either the client does send a set/list of groups or the server must > return a PAKE message for each group. The latter is not going to > work well for every PAKE. Having the server choose one without any > idea of what the client supports just won't do. > > Just have the client send a set (SEQUENCE) of OIDs. If you really > hate the wire bloat, then send both, an enum bit string and a > sequence of OIDs, with the latter absent when only registered groups > are proposed and the former absent when no registered groups are > proposed. No. I'm saying that the first message from the client to the server contains ONLY a SEQUENCE OF OBJECT IDENTIFIER. The reply contains the server's choice from that list, the public key from that chosen group, and 2FA parameters. I'm saying the OID bloat isn't really a problem. Nathaniel From nobody Mon Feb 23 13:24:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421131A6F01 for ; Mon, 23 Feb 2015 13:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LdE7l0_6xgIj for ; Mon, 23 Feb 2015 13:24:38 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id F2D771A6F0E for ; Mon, 23 Feb 2015 13:24:37 -0800 (PST) X-AuditID: 12074422-f79d16d0000024cf-97-54eb9a953e41 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 D4.1B.09423.59A9BE45; Mon, 23 Feb 2015 16:24:37 -0500 (EST) 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 t1NLOark022166; Mon, 23 Feb 2015 16:24:36 -0500 Received: from [18.101.8.182] (vpn-18-101-8-182.mit.edu [18.101.8.182]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1NLOXUf022273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Feb 2015 16:24:35 -0500 Message-ID: <54EB9A91.6040007@mit.edu> Date: Mon, 23 Feb 2015 16:24:33 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nathaniel McCallum , Nico Williams References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> In-Reply-To: <1424722422.2604.77.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT150663WIwf07QhZHN69isTh17Qib xdyvs1gdmD1enjrH6LFkyU8mj/f7rrIFMEdx2aSk5mSWpRbp2yVwZZx+OJW5YL5AxYOl85gb GD/wdDFyckgImEicWbaBCcIWk7hwbz1bFyMXh5DAYiaJxZv+MkE4GxklVux5yg7hHGGSmNm4 hhGkhVdATWLbs30sIDaLgKrEmcMnwGw2AWWJ9fu3gtmiAmES3zfvYIaoF5Q4OfMJWFxEIE7i wdV7bCA2s4CwxIXte1lBbGEBW4nJt78zQyzbwyhx9f1LsPs4BYwkth44AdWgLvFn3iVmCFte onnrbOYJjIKzkOyYhaRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3 MYID20VpB+PPg0qHGAU4GJV4eA2KXoUIsSaWFVfmHmKU5GBSEuU9Pvl1iBBfUn5KZUZicUZ8 UWlOavEhRgkOZiURXrF6oBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgTvuxlAjYJFqempFWmZOSUIaSYOTpDhPEDDP4PU8BYXJOYWZ6ZD5E8xKkqJ8x4FSQiAJDJK 8+B6YYnnFaM40CvCvB4zgap4gEkLrvsV0GAmoMF7Hr8CGVySiJCSamC0SYyuOiz0uMrxiiVn W59Tka+ItqPAqZ8dkv93BYgtSpp47lhea6Xt7m/i9gn7/kx54PLw+ZLmqTyX+x51Kl/ynhDb Kjvht3eK0TazLpk+l/U5W+/+rJU9vbhZyDZX+p1TspvUjk/5j1eGeizb9Jdlo8TuwxMU5h+e ot81x319/jqdCVOZLSYrsRRnJBpqMRcVJwIAVbkHNBcDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:24:40 -0000 On 02/23/2015 03:13 PM, Nathaniel McCallum wrote: > On the call last week there was a general consensus Just to be clear on process, the call Nathaniel refers to here was not an IETF conference call as described in https://www.ietf.org/iesg/statement/interim-meetings.html and did not establish a working group consensus. > We also had a general consensus that there is no need to negotiate > hashes. There are three hash uses: > 1. Transcript for message integrity > 2. Key derivation > 3. Key validation > > For #1, we can just use the checksum method implicit in the enctype. The idea here (as I remember it) is to make an RFC 3961 keyed checksum, at each step of the exchange, over the padata message and the previous checksum, using the original client long-term key as the checksum key. The final checksum is included in the derivation of the reply key. > For #2, we can just use a KDF. Specifically (as I remember it), we can do PRF+ (from either RFC 6112 or RFC 4402bis), using the original client long-term key and a text input containing the final transcript checksum, the point negotiated by the PAKE algorithm, and the client and server principals. The PRF+ output can then be fed to the RFC 3961 random-to-key operation to produce the reply key. > For #3, Greg had an idea, but I've since forgotten it and can't find > it in my email. Greg, perhaps you can remind me? I believe #3 refers to the client's proof of reply key possession at the end of the PAKE exchange. My idea was just to encrypt an empty string if we don't have a second factor value to send. (Alternatively we could encrypt a timestamp; that should not really be necessary, as the KDC cookie should be protected with a timestamp.) > We also discussed making group negotiation have a note in the RFC > about being careful regarding the number of groups exposed. I suspect > sensible defaults will be: > * P-256 > * P-384 > * P-521 > * Curve25519 I would prefer an even more limited offering, but this decision can wait until later. From nobody Mon Feb 23 13:37:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D11A6F2F for ; Mon, 23 Feb 2015 13:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 t6PHYjD5S6ss for ; Mon, 23 Feb 2015 13:37:54 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6D1A3B9C for ; Mon, 23 Feb 2015 13:37:54 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id B85AF2004EE09 for ; Mon, 23 Feb 2015 13:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Kqn1BINK8kAeE2PyTVJN DqH/yMM=; b=GR6gyaZni5+zsRIzZ50WlpgEpk9ZCyZ2Ic/NYyBVKj/tkHu0iFxy pcrDSog6+MAio1NB4QUsrMmSh6JFx1uHg6oOfBY5YMXnzgNwSyqGan/uytoN3eMn NYPowTSE60xg/tc3ARtwWZhlocw9nGWVNJ5LPtBTX8Mt2TXdj9Z9oJ0= Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id AA7462005D82D for ; Mon, 23 Feb 2015 13:37:54 -0800 (PST) Received: by iecrl12 with SMTP id rl12so27126327iec.2 for ; Mon, 23 Feb 2015 13:37:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.198 with SMTP id y6mr16020897igl.16.1424727474418; Mon, 23 Feb 2015 13:37:54 -0800 (PST) Received: by 10.64.130.66 with HTTP; Mon, 23 Feb 2015 13:37:54 -0800 (PST) In-Reply-To: <1424726541.2604.82.camel@redhat.com> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> <1424726541.2604.82.camel@redhat.com> Date: Mon, 23 Feb 2015 15:37:54 -0600 Message-ID: From: Nico Williams To: Nathaniel McCallum Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:37:55 -0000 On Mon, Feb 23, 2015 at 3:22 PM, Nathaniel McCallum wrote: > On Mon, 2015-02-23 at 15:12 -0600, Nico Williams wrote: >> On Mon, Feb 23, 2015 at 2:13 PM, Nathaniel McCallum < >> npmccallum@redhat.com> wrote: > No. I'm saying that the first message from the client to the server > contains ONLY a SEQUENCE OF OBJECT IDENTIFIER. The reply contains the > server's choice from that list, the public key from that chosen group, > and 2FA parameters. > > I'm saying the OID bloat isn't really a problem. I agree. BTW, if this were a GSS mech we might have a single mech OID for the entire {enctype, PAKE, group} negotiation (but not second factor), and for an IANA registry where one each of three arms of the OID correspond to enctype, PAKE, group. Here that would mean that the client advertises multiple PAs, and would get us into the business of having a registry. What you propose is fine. Nico -- From nobody Mon Feb 23 13:40:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B481A6F10 for ; Mon, 23 Feb 2015 13:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 l1m000JVSpL3 for ; Mon, 23 Feb 2015 13:40:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 A6EB71A3B9C for ; Mon, 23 Feb 2015 13:40:27 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLeQPP010872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Feb 2015 16:40:27 -0500 Received: from vpn-59-5.rdu2.redhat.com (vpn-59-5.rdu2.redhat.com [10.10.59.5]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLePiG004084 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Feb 2015 16:40:26 -0500 Message-ID: <1424727625.2604.84.camel@redhat.com> From: Nathaniel McCallum To: Greg Hudson Date: Mon, 23 Feb 2015 16:40:25 -0500 In-Reply-To: <54EB9A91.6040007@mit.edu> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> <54EB9A91.6040007@mit.edu> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:40:30 -0000 On Mon, 2015-02-23 at 16:24 -0500, Greg Hudson wrote: > On 02/23/2015 03:13 PM, Nathaniel McCallum wrote: > > On the call last week there was a general consensus > > Just to be clear on process, the call Nathaniel refers to here was > not an IETF conference call as described in > https://www.ietf.org/iesg/statement/interim-meetings.html > and did not establish a working group consensus. > > > We also had a general consensus that there is no need to negotiate > > hashes. There are three hash uses: > > 1. Transcript for message integrity > > 2. Key derivation > > 3. Key validation > > > > For #1, we can just use the checksum method implicit in the > > enctype. > > The idea here (as I remember it) is to make an RFC 3961 keyed > checksum, at each step of the exchange, over the padata message and > the previous checksum, using the original client long-term key as > the checksum key. The final checksum is included in the derivation > of the reply key. > > > For #2, we can just use a KDF. > > Specifically (as I remember it), we can do PRF+ (from either RFC > 6112 or RFC 4402bis), using the original client long-term key and a > text input containing the final transcript checksum, the point > negotiated by the PAKE algorithm, and the client and server > principals. The PRF+ output can then be fed to the RFC 3961 random- > to-key operation to produce the reply key. > > > For #3, Greg had an idea, but I've since forgotten it and can't > > find it in my email. Greg, perhaps you can remind me? > > I believe #3 refers to the client's proof of reply key possession at > the end of the PAKE exchange. My idea was just to encrypt an empty > string if we don't have a second factor value to send. > (Alternatively we could encrypt a timestamp; that should not really > be necessary, as the KDC cookie should be protected with a > timestamp.) > > > We also discussed making group negotiation have a note in the RFC > > about being careful regarding the number of groups exposed. I > > suspect sensible defaults will be: > > * P-256 > > * P-384 > > * P-521 > > * Curve25519 > > I would prefer an even more limited offering, but this decision can > wait until later. Thanks for all the clarifications! I agree with all of them. From nobody Mon Feb 23 13:41:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3591A3B9C for ; Mon, 23 Feb 2015 13:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 guI5_ZO-T1pm for ; Mon, 23 Feb 2015 13:41:23 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 264551A6F10 for ; Mon, 23 Feb 2015 13:41:23 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 0965C43807C for ; Mon, 23 Feb 2015 13:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lo+cQDChpxeXnEp6/Cj8 QQjtVlE=; b=bZVYmPRXWp/UcFKmS01wPC+rwJQX5jTYwsdUE6ysWOjRzACqaWuN v0CjoXC+0YGwmWDRWkse3Z3/JF0ggPjWBZCIR7/n1JsP03MysitbP/rOJNtTJ34l vFhxQK/ern8Lor/aT6bW1W/xmu1JmM9gIamgHJgusiB6BbDieqEAF0g= Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id F098D438079 for ; Mon, 23 Feb 2015 13:41:22 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so21849566igb.3 for ; Mon, 23 Feb 2015 13:41:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.213.7 with SMTP id gu7mr14083144icb.47.1424727682589; Mon, 23 Feb 2015 13:41:22 -0800 (PST) Received: by 10.64.130.66 with HTTP; Mon, 23 Feb 2015 13:41:22 -0800 (PST) In-Reply-To: <54EB9A91.6040007@mit.edu> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> <54EB9A91.6040007@mit.edu> Date: Mon, 23 Feb 2015 15:41:22 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:41:24 -0000 On Mon, Feb 23, 2015 at 3:24 PM, Greg Hudson wrote: > On 02/23/2015 03:13 PM, Nathaniel McCallum wrote: >> We also discussed making group negotiation have a note in the RFC >> about being careful regarding the number of groups exposed. I suspect >> sensible defaults will be: >> * P-256 >> * P-384 >> * P-521 >> * Curve25519 > > I would prefer an even more limited offering, but this decision can wait > until later. I think two for the 128-bit level and one or two (preferably one) each for the 192- and 256-bit levels. Nico -- From nobody Mon Feb 23 13:59:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1E1A0018 for ; Mon, 23 Feb 2015 13:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wm81ufSUUwyY for ; Mon, 23 Feb 2015 13:59:48 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 822D71A0004 for ; Mon, 23 Feb 2015 13:59:48 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLxlFM017965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Feb 2015 16:59:47 -0500 Received: from vpn-59-5.rdu2.redhat.com (vpn-59-5.rdu2.redhat.com [10.10.59.5]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLxkJE029336 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Feb 2015 16:59:47 -0500 Message-ID: <1424728786.2604.88.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Mon, 23 Feb 2015 16:59:46 -0500 In-Reply-To: References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> <54EB9A91.6040007@mit.edu> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:59:49 -0000 On Mon, 2015-02-23 at 15:41 -0600, Nico Williams wrote: > On Mon, Feb 23, 2015 at 3:24 PM, Greg Hudson wrote: > > On 02/23/2015 03:13 PM, Nathaniel McCallum wrote: > > > We also discussed making group negotiation have a note in the > > > RFC about being careful regarding the number of groups exposed. I > > > suspect sensible defaults will be: > > > * P-256 > > > * P-384 > > > * P-521 > > > * Curve25519 > > > > I would prefer an even more limited offering, but this decision > > can wait until later. > > > I think two for the 128-bit level and one or two (preferably one) > each for the 192- and 256-bit levels. I think this is an implementation detail that will change over time. :) From nobody Mon Feb 23 14:23:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCA91A01F2 for ; Mon, 23 Feb 2015 14:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 vtmZhIaJZcyZ for ; Mon, 23 Feb 2015 14:23:21 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 730061A0018 for ; Mon, 23 Feb 2015 14:23:21 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 4EF4D350078 for ; Mon, 23 Feb 2015 14:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8HfIwwmE+mmyr/f9EUFm hWU4iVY=; b=p5pIj+met6L0r7mGZtX2vw3lsIr7FbnJjCrdn/9Y6fXZpZ97ufRG KPVnxruOSpN00IfB2j8KSvt5a8AoGPRND4K1vUJ6JYEK/gnDIwPlXHIpIvgQ4sUS AWeUAEiUluSpOxxt33d5/iYcRBQ6FXpqH9u6XURY9YeCd/diRz/YnBs= Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 15D2035005B for ; Mon, 23 Feb 2015 14:23:21 -0800 (PST) Received: by iecrd18 with SMTP id rd18so27332690iec.8 for ; Mon, 23 Feb 2015 14:23:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.27.143 with SMTP id b137mr16787518iob.76.1424730200528; Mon, 23 Feb 2015 14:23:20 -0800 (PST) Received: by 10.64.130.66 with HTTP; Mon, 23 Feb 2015 14:23:20 -0800 (PST) In-Reply-To: <1424728786.2604.88.camel@redhat.com> References: <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> <54EB9A91.6040007@mit.edu> <1424728786.2604.88.camel@redhat.com> Date: Mon, 23 Feb 2015 16:23:20 -0600 Message-ID: From: Nico Williams To: Nathaniel McCallum Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Kerberos preauth negotiation techniques X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:23:22 -0000 On Mon, Feb 23, 2015 at 3:59 PM, Nathaniel McCallum wrote: > On Mon, 2015-02-23 at 15:41 -0600, Nico Williams wrote: >> On Mon, Feb 23, 2015 at 3:24 PM, Greg Hudson wrote: >> > On 02/23/2015 03:13 PM, Nathaniel McCallum wrote: >> > > We also discussed making group negotiation have a note in the >> > > RFC about being careful regarding the number of groups exposed. I >> > > suspect sensible defaults will be: >> > > * P-256 >> > > * P-384 >> > > * P-521 >> > > * Curve25519 >> > >> > I would prefer an even more limited offering, but this decision >> > can wait until later. >> >> I think two for the 128-bit level and one or two (preferably one) >> each for the 192- and 256-bit levels. > > I think this is an implementation detail that will change over time. :) This is what we do here: we specify what must be implemented to get interop. We can argue about whether some group that you can't implement _now_ should be required to implement. We can argue about other groups that others can't implement _now_. We can't really have no required-to-implement groups. Well, we could, but not as an Standards-Track RFC. Nico -- From nobody Tue Feb 24 03:56:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AD41A19F7 for ; Tue, 24 Feb 2015 03:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QZruStrxOSSC for ; Tue, 24 Feb 2015 03:56:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341461A03A9 for ; Tue, 24 Feb 2015 03:56:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E424DBED4; Tue, 24 Feb 2015 11:56:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaTd-eN3L0DB; Tue, 24 Feb 2015 11:56:48 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.27.159]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71258BED8; Tue, 24 Feb 2015 11:56:47 +0000 (GMT) Message-ID: <54EC66FF.50603@cs.tcd.ie> Date: Tue, 24 Feb 2015 11:56:47 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tony Hansen References: <54DC00D0.2050900@cs.tcd.ie> In-Reply-To: <54DC00D0.2050900@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 11:56:52 -0000 (list reduced to kitten) On 12/02/15 01:24, Stephen Farrell wrote: > > Hiya, > > I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's > needed for some work in http-auth but doesn't quite fit with any > current WG. I plan to start an IETF LC for that shortly, but please > do let me know if there are any issues. > > This was previously discussed on the kitten WG list, so (with > the WG chairs' permission) I'd ask that you send any comments > there if you've any before I start the IETF LC. (Reply-to is > set to the kitten WG list.) So I've seen positive responses, and some tweaks suggested which are all to the good, so I'm happy to sponsor this work. But in addition, there were two substantive issues that ought be resolved before IETF LC: 1. a new channel binding or requiring tls-session-hash (and I guess some explanatory text about why that is good/needed) 2. justify and possibly mandate an iteration count with which folks are happy Tony - could you propose text for #1 and #2 or start threads to resolve them. Feel free to shoot out any revisions you think make sense whilst doing that. And once we're done with those, and have a draft that reflects the consensus then I'll start IETF LC. Cheers, S. > > Thanks, > S. > > [1] https://tools.ietf.org/html/draft-hansen-scram-sha256 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Tue Feb 24 05:56:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741371A1A82; Tue, 24 Feb 2015 05:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dVO8OZdGVRfH; Tue, 24 Feb 2015 05:56:23 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C05D1A1AE6; Tue, 24 Feb 2015 05:56:23 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 5038ce45.0.4798030.00-2331.13494641.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Feb 2015 13:56:23 +0000 (UTC) X-MXL-Hash: 54ec830719bcac5e-253cd24390c5f32065b2bfebe308a4f61dbb9c7c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODuKB3008578; Tue, 24 Feb 2015 08:56:20 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODuGF1008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Feb 2015 08:56:18 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 24 Feb 2015 13:56:04 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODu3ZD005610; Tue, 24 Feb 2015 08:56:04 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1ODtuZ6005177; Tue, 24 Feb 2015 08:55:56 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224135555gw1000ceefe>; Tue, 24 Feb 2015 13:55:56 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54EC82EB.3040705@att.com> Date: Tue, 24 Feb 2015 08:55:55 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <54E1D009.2050408@isode.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG] X-AnalysisOut: [9nkA:10 a=KWikpAkKAAAA:8 a=aQeYOMMR6rlqqqAHQZoA:9 a=QEXdDO] X-AnalysisOut: [2ut3YA:10 a=zdbJd93gu_dgrkFV:21 a=MGKYglSutNO77KFl:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: kitten@ietf.org, "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 13:56:29 -0000 On 2/18/15 7:57 AM, Sam Whited wrote: > On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland wrote: >> Worth asking in the XSF, there's likely to be implementation experience from >> the Android client devs there. > I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't > remember actual numbers off the top of my head, I can definitely tell > you that there is a noticable delay with a 4096 iteration count > (probably a little over half a second) on my HTC m7 (which is fairly > beefy as far as phones go). HOWEVER— > >> However, clients need only do the iterations once, if the salt is stable, at >> least in principle. > —since we then store the session information in an LRU Cache in > memory, it's only slow when you first login. I've thought about moving > the session info to the database as well to make it even more > persistant, but decided it wasn't enough of a problem to bother > polluting the database. We have implementations of both SCRAM-SHA-1 and SCRAM-SHA-256 on multiple phone platforms, both Android and iOS. Yes, it can be rather slow. But, as Sam says above, caching does mitigate the issue for subsequent uses. This is why I pushed back when it was suggested before in KITTEN to raise the number higher than 4096. Tony Hansen From nobody Tue Feb 24 06:43:13 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C517E1A1BB3; Tue, 24 Feb 2015 06:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 j_Z5ExxKcrDE; Tue, 24 Feb 2015 06:43:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC21A1BD9; Tue, 24 Feb 2015 06:43:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224144307.8890.35911.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 06:43:07 -0800 Archived-At: Cc: kitten mailing list , kitten chair , RFC Editor Subject: [kitten] Document Action: 'Structure of the GSS Negotiation Loop' to Informational RFC (draft-ietf-kitten-gss-loop-05.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:43:10 -0000 The IESG has approved the following document: - 'Structure of the GSS Negotiation Loop' (draft-ietf-kitten-gss-loop-05.txt) as Informational RFC This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ Technical Summary This document provides guidance for implementing the GSS negotiation loop. It describes expectations of application protocols that use GSSAPI, such as error reporting and separation of application data from security negotiation data; the expected inputs and outputs for GSS_Accept_sec_context() and GSS_Init_sec_context(), including how various status codes should be handled; and what applications are expected to do once the loop completes. This document also describes what applications should do with unexpected state conditions. Working Group Summary This document went through two separate Working Group Last Calls with extensive discussion from a number of participants. One concern discussed is if this document should normatively update RFC 2743 or if it should "merely" provide application developers guidnace for how to work with GSSAPI as it exists today. The consensus ultimately was for this document to provide guidance for the current state of the art. Another major concern was the behavior when a context token is received after the security context is established. The consensus was for implementers to always call GSS_Process_context_token(), then call GSS_Inquire_context() to determine the usability of the security context, and call GSS_Delete_sec_context() to clean up. This document acknowledges that the current state of GSSAPI implementations renders the security context unusable when such context tokens are processed. In the course of discussing and updating this document, erratum 4151 was filed against RFC 2743 regarding the output of GSS_Process_context_token(). The erratum has not yet been formally discussed or verified in the Working Group. Document Quality This is informational and seems good to the AD. I-D nits asked about the code fragment but the authors/chairs discussed that and prefer to note add begin/end as the code is one fragment in it's own sub-section with a comment to the same effect. Personnel Matthew Miller (kitten WG co-chair) is the document shepherd and Stephen Farrell is the responsible Area Director. From nobody Tue Feb 24 06:53:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7061A1A51 for ; Tue, 24 Feb 2015 06:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ELwWx4zIfhbY for ; Tue, 24 Feb 2015 06:53:46 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760431A0203 for ; Tue, 24 Feb 2015 06:53:46 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 9709ce45.0.4838826.00-2309.13576520.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 24 Feb 2015 14:53:46 +0000 (UTC) X-MXL-Hash: 54ec907a46954f82-f0c776970498897dd83bd16d5582b412c957d609 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OEri1Q005371 for ; Tue, 24 Feb 2015 09:53:44 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OEreOT005315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 09:53:40 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 14:53:26 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OErQ6p026163 for ; Tue, 24 Feb 2015 09:53:26 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OErKM2025812 for ; Tue, 24 Feb 2015 09:53:20 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224145319gw1000ceeie>; Tue, 24 Feb 2015 14:53:19 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54EC905F.7060404@att.com> Date: Tue, 24 Feb 2015 09:53:19 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> In-Reply-To: <54EC66FF.50603@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=KNft+i5o c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG] X-AnalysisOut: [9nkA:10 a=TFv4FGCHG9rH0VdxLmwA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:53:48 -0000 On 2/24/15 6:56 AM, Stephen Farrell wrote: > (list reduced to kitten) > > On 12/02/15 01:24, Stephen Farrell wrote: >> Hiya, >> >> I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's >> needed for some work in http-auth but doesn't quite fit with any >> current WG. I plan to start an IETF LC for that shortly, but please >> do let me know if there are any issues. >> >> This was previously discussed on the kitten WG list, so (with >> the WG chairs' permission) I'd ask that you send any comments >> there if you've any before I start the IETF LC. (Reply-to is >> set to the kitten WG list.) > So I've seen positive responses, and some tweaks suggested which > are all to the good, so I'm happy to sponsor this work. > > But in addition, there were two substantive issues that ought be > resolved before IETF LC: > > 1. a new channel binding or requiring tls-session-hash (and I guess > some explanatory text about why that is good/needed) > > 2. justify and possibly mandate an iteration count with which folks > are happy > > Tony - could you propose text for #1 and #2 or start threads to > resolve them. Feel free to shoot out any revisions you think make > sense whilst doing that. And once we're done with those, and have > a draft that reflects the consensus then I'll start IETF LC. Thanks Stephen. I'll start separate threads for these. Tony From nobody Tue Feb 24 08:34:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C071A1A8F for ; Tue, 24 Feb 2015 08:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 r2LdQrtL19R8 for ; Tue, 24 Feb 2015 08:34:05 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9881A1A9D for ; Tue, 24 Feb 2015 08:33:54 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 1f7ace45.0.4904219.00-2387.13800259.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Feb 2015 16:33:54 +0000 (UTC) X-MXL-Hash: 54eca7f27a74d008-34d69c864845c6f151f1d5a7be56b896ca172f98 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXqH7028760 for ; Tue, 24 Feb 2015 11:33:53 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXlmF028714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 11:33:51 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 16:33:35 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXZCX018436 for ; Tue, 24 Feb 2015 11:33:35 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXViH018220 for ; Tue, 24 Feb 2015 11:33:31 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224163330gw1000ceeke>; Tue, 24 Feb 2015 16:33:31 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54ECA7DA.40203@att.com> Date: Tue, 24 Feb 2015 11:33:30 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> In-Reply-To: <54EC66FF.50603@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------000401040301070403080902" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=4Qr2YTnE] X-AnalysisOut: [bfVFj56_p2gA:9 a=QEXdDO2ut3YA:10 a=PXvjJup8crUr2pDL:21 a=D] X-AnalysisOut: [uVDpGu2oBqJH4kU:21 a=E4mqhp5XrJEm3fLxLvcA:9 a=_W_S_7VecoQA] X-AnalysisOut: [:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [kitten] draft-hansen-scram-sha256 and the hash iteration count X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:34:07 -0000 This is a multi-part message in MIME format. --------------000401040301070403080902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/24/15 6:56 AM, Stephen Farrell wrote: > But in addition, there were two substantive issues that ought be > resolved before IETF LC: ... > > 2. justify and possibly mandate an iteration count with which folks > are happy The issue here is this text in draft-hansen-scram-sha256: > For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers > SHOULD announce a hash iteration-count of at least 4096. Simon Josefsson's comment in saag was: > A suggested (not even mandated) pbkdf iteration count of at least 4096 > is unchanged since RFC 5802 -- I'd really like to see that be > significantly higher. Back in 2000 an iteration count of 1000 was > recommended as the minimum. Surely computational power has increased > more than a factor of four since then. (Note: I think that recommendation of 1000 was for MD5, but let's assume SHA-1 in the following discourse.) Alexey Melnikov responded: > I've heard complains from developers that 4096 with SHA-1 is too high > for current Android phones. It would be good to get more information > on performance before changing the number. to which Simon responded: > You will always hear complaints from developers that security features > adds computational and other resource costs. When that happens, I > prefer asking myself whether the threat model motivates the cost or not. There is a balancing act with the minimum hash iteration count: usability versus security. When this was last discussed in kitten last August, I brought the topic up myself, but I also noted that: > I do know that we found 4096 iterations to be significant on a > handheld device, and I would *prefer* not raising it any higher. (We > would not be willing to change our existing implementation of > scram-sha-256 to a higher number unless there was a >>really good > reason<<.) (This was specifically about 4096 iterations for SHA-256. SHA-1 runs better.) A subsequent comment by Russ Allbery said: > The rule of thumb that I was told by the CS crypto faculty at Stanford was > to use a number of iterations such that string-to-key would take 0.1 > seconds on a computer with typical current performance. That may or may > not be practical, given... > >> I do know that we found 4096 iterations to be significant on a handheld >> device, and I would*prefer* not raising it any higher. (We would not be >> willing to change our existing implementation of scram-sha-256 to a higher >> number unless there was a >>really good reason<<.) > ...you're already seeing performance issues with 4,096, and my testing > showed that meeting that rule of thumb would require at least 14,500 > iterations of SHA-2 with PBKDF2. So in 2000, the recommendation for SHA-1 was 1000. In 2010, the recommendation for SHA-1 was 4096 [RFC5082]. What is the definition for "typical current performance"? Should it be oriented toward mobile or oriented toward desktops or oriented toward super computers? Does SHA-256 being slower than SHA-1 affect the answer any? So, what to do for SCRAM-SHA-256? One way to derive a recommended number might be to use a log scale between 2000's and 2010's numbers, extend it out to 2015, then reduce the number by some percentage to account for SHA-1 vs SHA-256 performance. If my math is correct, and using a performance reduction of 30%, this gives 4260, which is only a few percent away from my original recommendation of 4096 for SHA-2. Or we could jump all the way up to 14500, as suggested by Russ. Another possibility is to suggest two values: one for mobile use and one for non-mobile use. Let the stones and arrows fly! Tony Hansen --------------000401040301070403080902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 2/24/15 6:56 AM, Stephen Farrell wrote:
But in addition, there were two substantive issues that ought be
resolved before IETF LC: ...

2. justify and possibly mandate an iteration count with which folks
   are happy

The issue here is this text in draft-hansen-scram-sha256:

   For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers
   SHOULD announce a hash iteration-count of at least 4096.

Simon Josefsson's comment in saag was:

A suggested (not even mandated) pbkdf iteration count of at least 4096
is unchanged since RFC 5802 -- I'd really like to see that be
significantly higher.  Back in 2000 an iteration count of 1000 was
recommended as the minimum.  Surely computational power has increased
more than a factor of four since then.

(Note: I think that recommendation of 1000 was for MD5, but let's assume SHA-1 in the following discourse.)

Alexey Melnikov responded:

I've heard complains from developers that 4096 with SHA-1 is too high for current Android phones. It would be good to get more information on performance before changing the number.

to which Simon responded:

You will always hear complaints from developers that security features
adds computational and other resource costs.  When that happens, I
prefer asking myself whether the threat model motivates the cost or not.

There is a balancing act with the minimum hash iteration count: usability versus security.

When this was last discussed in kitten last August, I brought the topic up myself, but I also noted that:

I do know that we found 4096 iterations to be significant on a handheld device, and I would *prefer* not raising it any higher. (We would not be willing to change our existing implementation of scram-sha-256 to a higher number unless there was a >>really good reason<<.)

(This was specifically about 4096 iterations for SHA-256. SHA-1 runs better.)

A subsequent comment by Russ Allbery said:

The rule of thumb that I was told by the CS crypto faculty at Stanford was
to use a number of iterations such that string-to-key would take 0.1
seconds on a computer with typical current performance.  That may or may
not be practical, given...


I do know that we found 4096 iterations to be significant on a handheld
device, and I would *prefer* not raising it any higher. (We would not be
willing to change our existing implementation of scram-sha-256 to a higher
number unless there was a >>really good reason<<.)

...you're already seeing performance issues with 4,096, and my testing
showed that meeting that rule of thumb would require at least 14,500
iterations of SHA-2 with PBKDF2.


So in 2000, the recommendation for SHA-1 was 1000. In 2010, the recommendation for SHA-1 was 4096 [RFC5082].

What is the definition for "typical current performance"? Should it be oriented toward mobile or oriented toward desktops or oriented toward super computers?

Does SHA-256 being slower than SHA-1 affect the answer any?

So, what to do for SCRAM-SHA-256?

One way to derive a recommended number might be to use a log scale between 2000's and 2010's numbers, extend it out to 2015, then reduce the number by some percentage to account for SHA-1 vs SHA-256 performance. If my math is correct, and using a performance reduction of 30%, this gives 4260, which is only a few percent away from my original recommendation of 4096 for SHA-2.

Or we could jump all the way up to 14500, as suggested by Russ.


Another possibility is to suggest two values: one for mobile use and one for non-mobile use.



Let the stones and arrows fly!

    Tony Hansen
--------------000401040301070403080902-- From nobody Tue Feb 24 08:50:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CEE1A8784 for ; Tue, 24 Feb 2015 08:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jhiNZTh2S_EH for ; Tue, 24 Feb 2015 08:50:49 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4D61A1B5E for ; Tue, 24 Feb 2015 08:50:48 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 8ebace45.0.4907786.00-2237.13798659.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 24 Feb 2015 16:50:49 +0000 (UTC) X-MXL-Hash: 54ecabe9378d970f-1bd42983167e28b280d182a22dea355548900b2b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGomBN012152 for ; Tue, 24 Feb 2015 11:50:48 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGohMr012095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 11:50:43 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 16:50:39 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGodNa013668 for ; Tue, 24 Feb 2015 11:50:39 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGoYi8012942 for ; Tue, 24 Feb 2015 11:50:34 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224165033gw1000ceele>; Tue, 24 Feb 2015 16:50:34 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54ECABD8.3090902@att.com> Date: Tue, 24 Feb 2015 11:50:32 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> In-Reply-To: <54EC66FF.50603@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EtBlW1gA c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG] X-AnalysisOut: [9nkA:10 a=48vgC7mUAAAA:8 a=jQSuHIxzjw1VzZep4TIA:9 a=QEXdDO] X-AnalysisOut: [2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:50:50 -0000 On 2/24/15 6:56 AM, Stephen Farrell wrote: > But in addition, there were two substantive issues that ought be > resolved before IETF LC: > > 1. a new channel binding or requiring tls-session-hash (and I guess > some explanatory text about why that is good/needed) To recap: Simon Josefsson made this comment: > Since SCRAM was published, we have learned that the tls-unique channel > binding is insecure -- it would be nice if we could combine the SHA256 > update with another default channel binding type to resolve that > problem. In my view, the problem with SCRAM today isn't primarily its > use of SHA1 but it's broken channel binding. Martin Thompson responded: > We have a solution for that: > https://tools.ietf.org/html/draft-ietf-tls-session-hash I've read through tls-session-hash and am unsure how to proceed here. One of my goals when proposing SCRAM-SHA-256 was to not change the protocol at all, other than updating the hash algorithm. I'm not sure how to incorporate a recommendation for session hashing here. I'm thinking this would be best handled by adding something to the Security Considerations section. Does that seem right? Would anyone be willing to suggest text changes for these comments? Tony Hansen From nobody Tue Feb 24 08:55:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DCE1A1B71 for ; Tue, 24 Feb 2015 08:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 40iHGb9U4APt for ; Tue, 24 Feb 2015 08:55:55 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 4B48A1A0393 for ; Tue, 24 Feb 2015 08:55:55 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so44630778obc.1 for ; Tue, 24 Feb 2015 08:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/0MZ1I1buZfnYJq1on9Z3ke4Avp1HdR4GU9URZMF6rg=; b=c/RMDjMPnD7HVcuPiy6nDisH+2AYjcqO8/CkKrPKvnczpnVATXDT1EgktZ6SqEHn3s +nHhivq/I6ChVAnJhywdVjo/znf2MeNQXPvHU6Mmub6yEeEMyobs4fk3dT7vy+9HQKk2 VaJa18nkNq80XPUwTkM8TJ37a9fg7uzZXP8UM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/0MZ1I1buZfnYJq1on9Z3ke4Avp1HdR4GU9URZMF6rg=; b=e4bMftJ5OoDQs0BYTJS72u2DB8eGL5YOQGrUNG1XgNg4BkHNFq90FWyWU3M1+MuTGD kFLtNql/AGAhi99re7iQq9DBFHOrkoL64fHYjGYZS/WWAXBC2OCFvRZCJ/Vc9PSFtrWA du9MoqCaYraiDVk/K0mF3HD0LaYLLWveNKvX2MViWXO2VqReczEWCOBaMTcZrNlNLQmK npY4tNYHxhqBtOsFr4l20mTQkdCjIEtIQiw/Uda8CpYEfIpyPpfMvP3qL1/Z7vcoXyBj 4mXpm/vEihLTIjgRh72KyyeUxeyLo2bv7y4DuFfVS31FAbrpFDTvHjpYTZVmWcAxBQKd XinA== X-Gm-Message-State: ALoCoQkaTZei95M0kH+e0rZD9YhXSjSJrbvcd130OMXmp3cygIck+f9EGx0IPDxr0QKh8Gm7gdNw MIME-Version: 1.0 X-Received: by 10.182.209.72 with SMTP id mk8mr11521034obc.54.1424796954592; Tue, 24 Feb 2015 08:55:54 -0800 (PST) Received: by 10.60.62.172 with HTTP; Tue, 24 Feb 2015 08:55:54 -0800 (PST) In-Reply-To: <54ECA7DA.40203@att.com> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECA7DA.40203@att.com> Date: Tue, 24 Feb 2015 16:55:54 +0000 Message-ID: From: Dave Cridland To: Tony Hansen Content-Type: multipart/alternative; boundary=e89a8ff252565b1dee050fd86481 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:55:56 -0000 --e89a8ff252565b1dee050fd86481 Content-Type: text/plain; charset=UTF-8 On 24 February 2015 at 16:33, Tony Hansen wrote many things... As a thought, is it not worthwhile to distill all this into a paragraph or two within the Security Considerations, such as: The strength of this mechanism is dependent in part on the iteration count, as denoted by "i" in [RFC 5802]. As a rule of thumb, the iteration count should be such that a modern machine will take 0.1 seconds to perform the complete algorithm; however this is unlikely to be practical on mobile devices and other relatively low-performance systems. At the time this was written, the rule of thumb gives around 15,000 iterations required; however an iteration count of 4096 takes around 0.5 seconds on current mobile handsets. This computational cost can be avoided by caching the ClientKey (assuming the Salt and iteration count is stable). Therefore the recommendation of this specification is that the iteration count SHOULD be at least 4096, but careful consideration ought to be given to using a significantly higher value, particularly where mobile use is less important. --e89a8ff252565b1dee050fd86481 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 24 February 2015 at 16:33, Tony Hansen <tony@att.com> wrote ma= ny things...

As a thought, is it not worthwhile to distill all this into a paragr= aph or two within the Security Considerations, such as:

The strength of this mech= anism is dependent in part on the iteration count, as denoted by "i&qu= ot; in [RFC 5802]. As a rule of thumb, the iteration count should be such t= hat a modern machine will take 0.1 seconds to perform the complete algorith= m; however this is unlikely to be practical on mobile devices and other rel= atively low-performance systems. At the time this was written, the rule of = thumb gives around 15,000 iterations required; however an iteration count o= f 4096 takes around 0.5 seconds on current mobile handsets. This computatio= nal cost can be avoided by caching the ClientKey (assuming the Salt and ite= ration count is stable).

Therefore the recommendation of this specification is th= at the iteration count SHOULD be at least 4096, but careful consideration o= ught to be given to using a significantly higher value, particularly where = mobile use is less important.
--e89a8ff252565b1dee050fd86481-- From nobody Tue Feb 24 09:00:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5C1A1B7A for ; Tue, 24 Feb 2015 09:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KTqOYkhi_g0a for ; Tue, 24 Feb 2015 08:59:59 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3531A1B30 for ; Tue, 24 Feb 2015 08:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424797198; d=isode.com; s=selector; i=@isode.com; bh=DjqTVxTRYY7E+O2oXiHuD9UyQ5A5dc6iWwoIQLohlvU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eXbw0DZg9+CfFK0z7kNZ04coNe7NyNhmyk8IOjI0MesNIuulEmzJYjXFNDjUI8YcIrfUnp 4CbXJ+XxifGEtdPeEiiFl04TaTssonf4Xi6mZTZy36Ut+tvPy+WaHJ/+z2TcayJrAUiED+ B3vAXqrFy9HgsrKLQ4w+WxAO4cEMLwg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Feb 2015 16:59:58 +0000 Message-ID: <54ECAE08.2090106@isode.com> Date: Tue, 24 Feb 2015 16:59:52 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Dave Cridland , Tony Hansen References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECA7DA.40203@att.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020002050903010906020406" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:00:01 -0000 This is a multi-part message in MIME format. --------------020002050903010906020406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 24/02/2015 16:55, Dave Cridland wrote: > > On 24 February 2015 at 16:33, Tony Hansen > wrote many things... > > As a thought, is it not worthwhile to distill all this into a > paragraph or two within the Security Considerations, such as: > > The strength of this mechanism is dependent in part on the iteration > count, as denoted by "i" in [RFC 5802]. As a rule of thumb, the > iteration count should be such that a modern machine will take 0.1 > seconds to perform the complete algorithm; however this is unlikely to > be practical on mobile devices and other relatively low-performance > systems. At the time this was written, the rule of thumb gives around > 15,000 iterations required; however an iteration count of 4096 takes > around 0.5 seconds on current mobile handsets. This computational cost > can be avoided by caching the ClientKey (assuming the Salt and > iteration count is stable). > > Therefore the recommendation of this specification is that the > iteration count SHOULD be at least 4096, but careful consideration > ought to be given to using a significantly higher value, particularly > where mobile use is less important. > +1. --------------020002050903010906020406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 24/02/2015 16:55, Dave Cridland wrote:

On 24 February 2015 at 16:33, Tony Hansen <tony@att.com> wrote many things...

As a thought, is it not worthwhile to distill all this into a paragraph or two within the Security Considerations, such as:

The strength of this mechanism is dependent in part on the iteration count, as denoted by "i" in [RFC 5802]. As a rule of thumb, the iteration count should be such that a modern machine will take 0.1 seconds to perform the complete algorithm; however this is unlikely to be practical on mobile devices and other relatively low-performance systems. At the time this was written, the rule of thumb gives around 15,000 iterations required; however an iteration count of 4096 takes around 0.5 seconds on current mobile handsets. This computational cost can be avoided by caching the ClientKey (assuming the Salt and iteration count is stable).

Therefore the recommendation of this specification is that the iteration count SHOULD be at least 4096, but careful consideration ought to be given to using a significantly higher value, particularly where mobile use is less important.

+1.

--------------020002050903010906020406-- From nobody Tue Feb 24 09:31:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBC81A875D for ; Tue, 24 Feb 2015 09:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MjkascHjbJ_V for ; Tue, 24 Feb 2015 09:31:19 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D63D1A1BC3 for ; Tue, 24 Feb 2015 09:31:19 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 465bce45.0.4955492.00-1980.13911134.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 24 Feb 2015 17:31:19 +0000 (UTC) X-MXL-Hash: 54ecb5675ccc2cd0-aba41c3951ee07ab9e8e221ffa515096e49dcfaf Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OHVG7N027874 for ; Tue, 24 Feb 2015 12:31:16 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OHVAV2027776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 12:31:11 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 17:30:58 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OHUwUW010374 for ; Tue, 24 Feb 2015 12:30:58 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OHUqnN010016 for ; Tue, 24 Feb 2015 12:30:52 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224173051gw1000ceeme>; Tue, 24 Feb 2015 17:30:51 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54ECB54A.3040002@att.com> Date: Tue, 24 Feb 2015 12:30:50 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECA7DA.40203@att.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010807090105030404050302" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=KNft+i5o c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=zdOV5PIi] X-AnalysisOut: [SKSzHpzq2iYA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=H7dR8y] X-AnalysisOut: [VHmTnR0TsgIuUA:9 a=_W_S_7VecoQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:31:21 -0000 This is a multi-part message in MIME format. --------------010807090105030404050302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/24/15 11:55 AM, Dave Cridland wrote: > > On 24 February 2015 at 16:33, Tony Hansen > wrote many things... > > As a thought, is it not worthwhile to distill all this into a > paragraph or two within the Security Considerations, such as: > > The strength of this mechanism is dependent in part on the iteration > count, as denoted by "i" in [RFC 5802]. As a rule of thumb, the > iteration count should be such that a modern machine will take 0.1 > seconds to perform the complete algorithm; however this is unlikely to > be practical on mobile devices and other relatively low-performance > systems. At the time this was written, the rule of thumb gives around > 15,000 iterations required; however an iteration count of 4096 takes > around 0.5 seconds on current mobile handsets. This computational cost > can be avoided by caching the ClientKey (assuming the Salt and > iteration count is stable). > > Therefore the recommendation of this specification is that the > iteration count SHOULD be at least 4096, but careful consideration > ought to be given to using a significantly higher value, particularly > where mobile use is less important. Thank you Dave. I think this is an excellent path forward. Tony Hansen --------------010807090105030404050302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 2/24/15 11:55 AM, Dave Cridland wrote:

On 24 February 2015 at 16:33, Tony Hansen <tony@att.com> wrote many things...

As a thought, is it not worthwhile to distill all this into a paragraph or two within the Security Considerations, such as:

The strength of this mechanism is dependent in part on the iteration count, as denoted by "i" in [RFC 5802]. As a rule of thumb, the iteration count should be such that a modern machine will take 0.1 seconds to perform the complete algorithm; however this is unlikely to be practical on mobile devices and other relatively low-performance systems. At the time this was written, the rule of thumb gives around 15,000 iterations required; however an iteration count of 4096 takes around 0.5 seconds on current mobile handsets. This computational cost can be avoided by caching the ClientKey (assuming the Salt and iteration count is stable).

Therefore the recommendation of this specification is that the iteration count SHOULD be at least 4096, but careful consideration ought to be given to using a significantly higher value, particularly where mobile use is less important.

Thank you Dave. I think this is an excellent path forward.

    Tony Hansen
--------------010807090105030404050302-- From nobody Wed Feb 25 07:06:40 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193871A875E for ; Wed, 25 Feb 2015 07:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 1QpUFOjMvqI8 for ; Wed, 25 Feb 2015 07:06:36 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 3BF0B1A8758 for ; Wed, 25 Feb 2015 07:06:36 -0800 (PST) Received: from latte.josefsson.org (c-04f7e555.014-1001-73746f1.cust.bredbandsbolaget.se [85.229.247.4]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1PF6MLv019546 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 25 Feb 2015 16:06:23 +0100 From: Simon Josefsson To: Tony Hansen References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECA7DA.40203@att.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150225:kitten@ietf.org::LbP+tK9kP0BpOIZ7:6a70 X-Hashcash: 1:22:150225:tony@att.com::Om4/BCH+6WepAkt6:861C Date: Wed, 25 Feb 2015 16:06:21 +0100 In-Reply-To: <54ECA7DA.40203@att.com> (Tony Hansen's message of "Tue, 24 Feb 2015 11:33:30 -0500") Message-ID: <874mqaghea.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 15:06:38 -0000 --=-=-= Content-Type: text/plain Tony Hansen writes: > So, what to do for SCRAM-SHA-256? > > One way to derive a recommended number might be to use a log scale > between 2000's and 2010's numbers, extend it out to 2015, then reduce > the number by some percentage to account for SHA-1 vs SHA-256 > performance. If my math is correct, and using a performance reduction > of 30%, this gives 4260, which is only a few percent away from my > original recommendation of 4096 for SHA-2. > > Or we could jump all the way up to 14500, as suggested by Russ. > > > Another possibility is to suggest two values: one for mobile use and > one for non-mobile use. I think there are at least two different considerations: 1) Language used. As you quoted, the text now says that servers "SHOULD announce at least 4096". Using SHOULD already gives room for using other values if there is good justification. To split things into mobile and non-mobile use-cases (which sounds like a bad idea for several reasons to me) would require changing the language, as the server normally doesn't know what type the client is. Another idea is to give two values but phrase it in a different way: one MUST minimum value for protocol conformance (say 4096) and one RECOMMENDED value for good protection in various deployments (say 14500). 2) How to decide the value. I don't agree with the focus on performance -- the reason for using PBKDF2 is to improve security, so the normal approach to decide security parameters (compare key sizes) is that the security needs dictate the requirements. On one extreme, using 10 iteration count would be weak (although I can't cite attacks, maybe because nobody uses 10 iterations...). IMHO, the metric should be: how many iterations raises the cost for an attacker so that it is no longer a cost-effective way to crack the system? Of course, different systems will have different attack cost models, but we should give a ball-park number applicable for common Internet applications. I'm with Alexey that current estimates are probably mostly guesses. I don't know of a established way to derive a better value. However it feels weird for us to not raise the value when we are revising the specification: surely all attacks are more cost-effective as time passes by, so the value should at least be incremented somewhat. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU7eTtAAoJEIYLf7sy+BGdi0wIAKgrIXMJ1HXa7MW0Knb/kP63 e92HjRe8P690FSL6KRMxtYvH+Gwe2tkvvvsx7Jl4yxbp4X+G83iOnS6HIsR2I69G NklWNsLB4tyveJMtdm86iKcKSa2EknG2Q8h0U4pRZmCju1Q8rQykJk4ujs/X0UhW uCWVO0hVvvnfsj9jEMDduClYwq38BFoiWKMrD1MiV2K2IQAC4Olh86WIZ63Fakdi yzlQ3H0OK45NaQa+LxAxkMZT/XgGfkr9g9/BIbndD7lIsc8g7kw1YxQ0TEGErWvc 11IIPAJ6rXjQu7Lh4ToOHBaVvDnL4Xq20RBVoqmOyHgpGi1QG5yaryV+u06p0Lg= =rqqs -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 25 07:25:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C9B1A0A6A for ; Wed, 25 Feb 2015 07:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 SCpARo4dCjzj for ; Wed, 25 Feb 2015 07:25:31 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 70AB51A03A1 for ; Wed, 25 Feb 2015 07:25:31 -0800 (PST) Received: from latte.josefsson.org (c-04f7e555.014-1001-73746f1.cust.bredbandsbolaget.se [85.229.247.4]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t1PFPEXv021455 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 25 Feb 2015 16:25:15 +0100 From: Simon Josefsson To: Tony Hansen References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150225:tony@att.com::n0aPQdeKkD9+05yD:62Me X-Hashcash: 1:22:150225:kitten@ietf.org::Six+Zhbqx153rSru:MQem Date: Wed, 25 Feb 2015 16:25:08 +0100 In-Reply-To: <54ECABD8.3090902@att.com> (Tony Hansen's message of "Tue, 24 Feb 2015 11:50:32 -0500") Message-ID: <87zj82f1yj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 15:25:33 -0000 --=-=-= Content-Type: text/plain Tony Hansen writes: > On 2/24/15 6:56 AM, Stephen Farrell wrote: >> But in addition, there were two substantive issues that ought be >> resolved before IETF LC: >> >> 1. a new channel binding or requiring tls-session-hash (and I guess >> some explanatory text about why that is good/needed) > > To recap: > > Simon Josefsson made this comment: > >> Since SCRAM was published, we have learned that the tls-unique channel >> binding is insecure -- it would be nice if we could combine the SHA256 >> update with another default channel binding type to resolve that >> problem. In my view, the problem with SCRAM today isn't primarily its >> use of SHA1 but it's broken channel binding. > > Martin Thompson responded: > >> We have a solution for that: >> https://tools.ietf.org/html/draft-ietf-tls-session-hash > > I've read through tls-session-hash and am unsure how to proceed here. > > One of my goals when proposing SCRAM-SHA-256 was to not change the > protocol at all, other than updating the hash algorithm. > > I'm not sure how to incorporate a recommendation for session hashing > here. I'm thinking this would be best handled by adding something to > the Security Considerations section. Does that seem right? > > Would anyone be willing to suggest text changes for these comments? I believe the problem is that RFC 5802 is insecure as currently specified, and we are bringing this up as a problem with your draft, which is unfair to you since the problem was not introduced by you. If people like the tls-session-hash approach (I'm not in that category, but there may be consensus around it), the proper fix is to update RFC 5802 and reference tls-session-hash as a normative reference. This will take care of the problem, as you could copy that text into your document. If you are looking for a text change here, it would be: To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel that MUST have [TLS-SESSION-HASH] negotiated. Personally, I would prefer to change to another mandatory channel binding that is secure for all TLS versions. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJU7elUAAoJEIYLf7sy+BGd/iMH/2bGnU4q6Yh1y7AJfSN+ERu2 EdU0lMRKgoetMMwPmL4iNghPQyJ8slNtBvv8g4ctgx24rpXLiCBeapVrQEZ2yqoC pZVM5Dl93FmenZslsQfyeuO8Fu13J8sXsXPWGVp6t64b6lXNtoklcWQmLJf7wGbL 4y8Iu6vpSfjU5UcafeB0a16iKgDgoyAny+IG6CZfuCMfkb+RXCQZCt9z8SOAADKv dTsvn+SE5u93jd4/je95o7m6Qpb0s+c0Yt63BArVBBejS3Esn3PpNsg98Cbcjxcs h7Q2wC16Z0FeUWSa2B97fIO6s2FEJzb95ECWzoITynoq1PfPHUqDGgLoAdp/ZGY= =Q3+b -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 25 08:40:20 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EFD1A03A1 for ; Wed, 25 Feb 2015 08:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pGA7dzO6MOWm for ; Wed, 25 Feb 2015 08:40:17 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4E51A0366 for ; Wed, 25 Feb 2015 08:40:16 -0800 (PST) X-AuditID: 12074425-f79846d0000054e1-d1-54edfaeff758 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 F6.F2.21729.FEAFDE45; Wed, 25 Feb 2015 11:40:15 -0500 (EST) 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 t1PGeEm6029206 for ; Wed, 25 Feb 2015 11:40:15 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1PGeDIq014686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Feb 2015 11:40:14 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1PGeCah013739; Wed, 25 Feb 2015 11:40:12 -0500 (EST) Date: Wed, 25 Feb 2015 11:40:12 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> <20141217230505.GD9443@localhost> <20141220001633.GD12662@localhost> <1421269970.18482.184.camel@minbar.fac.cs.cmu.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrfv+19sQg47Z6hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsMF11kLGqUqNvxpZmtgXCvSxcjJISFgInFo/XxWCFtM4sK9 9WwgtpDAYiaJ9T9Kuxi5gOzjjBITP55gg3BuMEncuPyNHcJpYJSYcnUJcxcjBweLgLbE5yd+ IN1sAioSM99sBJskIiAssXvrO2YQW1hAU2Ln11tg2zgFnCR+bm5lAbF5BRwkvnT+h1rwnEVi 8+3dYEWiAjoSq/dPgSoSlDg58wmYzSygJbF8+jaWCYwCs5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRroZebWaKXmlK6iREUfuwuqjsYJxxSOsQowMGoxMN7QOZNiBBrYllxZe4h RkkOJiVR3oqfb0OE+JLyUyozEosz4otKc1KLDzFKcDArifC2vQLK8aYkVlalFuXDpKQ5WJTE eTf94AsREkhPLEnNTk0tSC2CycpwcChJ8F4EGSpYlJqeWpGWmVOCkGbi4AQZzgM0/ApIDW9x QWJucWY6RP4Uo6KUOO9ckIQASCKjNA+uF5YeXjGKA70izPsUpIoHmFrgul8BDWYCGrzn8SuQ wSWJCCkpYJoInj6Ja+eG7gnH/4u3lNxy1PPoWSEX7bCMs6Gt3GjKhFOOPvc03hRXvPohkf3B ivGpjpSx6rdFXU8t0i/I3ZA89WSH+AH/u7GvXqakWWW3BGcbLJ3Pr3S+89REw0C3rSy7XyjZ zahjzqy4unev0JPFlo7Pbv59Kx1k49OWUfomXcE/pDJypxJLcUaioRZzUXEiAB1o6knqAgAA Archived-At: Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:40:19 -0000 On Tue, 20 Jan 2015, Benjamin Kaduk wrote: > On Tue, 20 Jan 2015, Benjamin Kaduk wrote: > > > In practice, an unexpected security context token that imediately > > follows full security context establishment is very likely a > > context token conveying error information rather than a security > > context deletion token, especially since the latter are obsoleted. > > Given what Jeff pointed out about new statements in errata being taken as > indicating important (new) changes, I wonder if this paragraph should also > be removed. I believe it to be a true statement, but perhaps including it > in the erratum at all will give it more weight than is appropriate. It is > also the first mention of deletion tokens in section 2.2.4 (another > mention does occur later on), so it comes in somewhat abruptly without > introduction. > > > Applications using transports that may deliver messages out of > > order may continue to attempt to process per-message tokens between > > calling GSS_Process_context_token() and GSS_Delete_sec_context(), > > though there is no guarantee that processing per-message tokens will > > then succeed. > > This also may be too much information for the erratum. (Again, I believe > it is basically a correct statement, but that including it in the erratum > may cause it to be given too much weight.) > > What do other people think? This doesn't seem to have received any replies, so let me rephrase in the form of a new proposed erratum text: ====================================================== Section 2.2.4 says: o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Process_context_token() operation could not be performed for reasons unspecified at the GSS-API level. It should say: o GSS_S_FAILURE indicates that the context is recognized, but either the GSS_Process_context_token() operation could not be performed for reasons unspecified at the GSS-API level, or the peer had an error consuming the last context token sent to it. The latter occurs when the local side became fully established and produced one last token which was sent to the peer, but the peer encountered an error while processing that last context token. In either case the minor status code provides additional information. In the case of successful processing of error tokens, the minor status code provides information from the input token. The display string outputs of GSS_Display_status() as applied to such minor status codes should indicate that the error originated on the remote peer, along with the nature of the error. Note that there is no way to distinguish failures of GSS_Process_context_token() from error token information other than to read the human-readable status display strings. ====================================================== Removing the last paragraph ("Applications using transports ...") removes the only text implying that callers of GSS_Process_context_token() are still required to eventually call GSS_Delete_sec_context(). Do we think that text to that effect is needed in this erratum (as opposed to a separate one)? -Ben From nobody Wed Feb 25 09:15:20 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451131A87D4 for ; Wed, 25 Feb 2015 09:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 3z2Gg-oH4PWT for ; Wed, 25 Feb 2015 09:15:18 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 30F2A1A8839 for ; Wed, 25 Feb 2015 09:15:15 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id DDA51E222 for ; Wed, 25 Feb 2015 09:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=owwP2toQe/5SGpAAEsUk jvAxDNQ=; b=jUmujQpozyY7CCQDoDkdJk2pbQOm/CgiT21X0zASI2aUhHKma6wc RpYg/cR/1XzFR0SmVsTy0J5WzejK8+cY/JkWqWrCmMIaQsMRpW2nP1BOvs/R1fgD a4kF1es6gmLlVB9kSQRfMlJQCQi3EEo81ZvzEZKAi68MKdMHb8NRtpg= Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 750B8163B for ; Wed, 25 Feb 2015 09:15:14 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id hl2so37275968igb.3 for ; Wed, 25 Feb 2015 09:15:12 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.171.170 with SMTP id av10mr28524475igc.28.1424884512470; Wed, 25 Feb 2015 09:15:12 -0800 (PST) Received: by 10.64.130.66 with HTTP; Wed, 25 Feb 2015 09:15:12 -0800 (PST) In-Reply-To: References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> <20141217230505.GD9443@localhost> <20141220001633.GD12662@localhost> <1421269970.18482.184.camel@minbar.fac.cs.cmu.edu> Date: Wed, 25 Feb 2015 11:15:12 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:15:19 -0000 I believe this text is correct. As to Ben's question, I don't think text to the effect of when the application should get around to calling GSS_Delete_sec_context() is needed. Application developers will end up figuring that out for themselves. Nico -- From nobody Wed Feb 25 13:37:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D470E1A6EFC for ; Wed, 25 Feb 2015 13:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HjblkarqUU8g for ; Wed, 25 Feb 2015 13:37:04 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290C71A88E4 for ; Wed, 25 Feb 2015 13:37:02 -0800 (PST) X-AuditID: 1209190e-f79bb6d0000030e8-43-54ee407dd11c 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 16.0E.12520.D704EE45; Wed, 25 Feb 2015 16:37:01 -0500 (EST) 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 t1PLatWb006345; Wed, 25 Feb 2015 16:36:55 -0500 Received: from [18.101.8.121] (vpn-18-101-8-121.mit.edu [18.101.8.121]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1PLaksU031018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2015 16:36:54 -0500 Message-ID: <54EE406E.2070505@mit.edu> Date: Wed, 25 Feb 2015 16:36:46 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> <20141217230505.GD9443@localhost> <20141220001633.GD12662@localhost> <1421269970.18482.184.camel@minbar.fac.cs.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nolvr8C7EYOVFHoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro+P+TMaCs5wVN583sDcwzmfvYuTkkBAwkWjft40NwhaTuHBv PZgtJLCYSWLHh7AuRi4geyOjxM6N36ASR5gk5h8T7mLk4OAVUJN41ScKEmYRUJXYOH82K4jN JqAssX7/VhYQW1QgTOL75h3MIDavgKDEyZlPwOIiAsYSd3/eALOFBTQldn69xQqxawarxPP5 78CO4xRwlOj5tJEJxGYW0JPYcf0XK4QtL7H97RzmCYwCs5DMnYWkbBaSsgWMzKsYZVNyq3Rz EzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzGCQpJTkm8H49eDSocYBTgYlXh4D8i8CRFiTSwr rsw9xCjJwaQkyvvM9l2IEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeZSugHG9KYmVValE+TEqa g0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBG+ePVCjYFFqempFWmZOCUKaiYMTZDgP0PBO kBre4oLE3OLMdIj8KUZFKXHeOJCEAEgiozQPrheWMl4xigO9IswrDVLFA0w3cN2vgAYzAQ3e 8/gVyOCSRISUVANjpcMRLUPR29bvbthc46+f8Wd37Ckf18RC1chTCt9WaOav3xVY8vnoSR75 BV85NDmu2DDeKa5LNNFfaPro56EZxVF1Z/8kLjseOH/e9ukX9BldXeWib5wqecu00oRpQ129 depLNosgnd0tPzfWfJA8aStxzvyIqaJNf8HGbd7fpe7u2SAUzBWqxFKckWioxVxUnAgAcMDT 3/QCAAA= Archived-At: Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 21:37:06 -0000 On 02/25/2015 11:40 AM, Benjamin Kaduk wrote: > It should say: > > o GSS_S_FAILURE indicates that the context is recognized, but > either the GSS_Process_context_token() operation could not be > performed for reasons unspecified at the GSS-API level, or the peer > had an error consuming the last context token sent to it. The latter > occurs when the local side became fully established and produced one > last token which was sent to the peer, but the peer encountered an > error while processing that last context token. In either case the > minor status code provides additional information. > > In the case of successful processing of error tokens, the minor > status code provides information from the input token. The display > string outputs of GSS_Display_status() as applied to such minor > status codes should indicate that the error originated on the remote > peer, along with the nature of the error. Note that there is no > way to distinguish failures of GSS_Process_context_token() from > error token information other than to read the human-readable status > display strings. This seems okay to me. From nobody Thu Feb 26 12:40:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043EF1A039B for ; Thu, 26 Feb 2015 12:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fzDHMbJl4E1c for ; Thu, 26 Feb 2015 12:40:11 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425161A1DE1 for ; Thu, 26 Feb 2015 12:40:11 -0800 (PST) X-AuditID: 12074423-f79066d0000058b8-fd-54ef84aa8bc9 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 58.FD.22712.AA48FE45; Thu, 26 Feb 2015 15:40:10 -0500 (EST) 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 t1QKe4kC023081; Thu, 26 Feb 2015 15:40:04 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1QKe12u017443; Thu, 26 Feb 2015 15:40:03 -0500 From: Tom Yu To: Benjamin Kaduk References: <54DD194D.2010201@mit.edu> <1424287116.6980.35.camel@willson.usersys.redhat.com> Date: Thu, 26 Feb 2015 15:40:01 -0500 In-Reply-To: (Benjamin Kaduk's message of "Fri, 20 Feb 2015 16:04:44 -0500") Message-ID: Lines: 51 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrLuq5X2Iwde13BZHN69isfgxdxGr A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJVx8nZhwT3Biss3rjM1ML7n7WLk5JAQMJHY 0fWAGcIWk7hwbz1bFyMXh5DAYiaJt5OOsEA4GxklXny5xQ7hvGGUmHKiD6yFTUBa4vjlXUwg toiAksTisy1sIDazgLHEmiffwWxhAReJAw9eMEI0n2WS2DJlCyNIgkVAVWLju2msIAlOgWZG iXVrt7KAJHgFdCU67i0H28AjwAm0bQ0bRFxQ4uTMJywQG7Qkbvx7yTSBUWAWktQsJKkFjEyr GGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxgoKS3UV5B+Ofg0qHGAU4GJV4eHfk vgsRYk0sK67MPcQoycGkJMp7tul9iBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXoZSoBxvSmJl VWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgRvTjNQo2BRanpqRVpmTglCmomD E2Q4D9DwGyA1vMUFibnFmekQ+VOMilLivKtAEgIgiYzSPLheWNJ4xSgO9IowryVIFQ8w4cB1 vwIazAQ0+MDddyCDSxIRUlINjElGefOcupo1xBaHd7zY8zDmV+2hUNZ0zptR1XbLJ3xxXhQj cfXi1t3OpiqW77otBPjjJLhUJFIU9uqleQnzTEj1+7FJ6kyKVamYWV3jphvBJlfvqRYtc2QT bfof8uH1+/SuBL61jX/Y5jR6+jZKH7V6Or8jb158z9eeZokDxt1qd/xPr/yuxFKckWioxVxU nAgAYOdTU/UCAAA= Archived-At: Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 20:40:13 -0000 Benjamin Kaduk writes: > On Wed, 18 Feb 2015, Simo Sorce wrote: > >> On Wed, 2015-02-18 at 13:55 -0500, Benjamin Kaduk wrote: >> >> Would it make more sense to say something like: >> >> The KDC MUST NOT make verbatim copies of CAMMAC contents into a >> new CAMMAC unless the original CAMMAC is authenticated by an >> originator that is fully trusted by the KDC. >> The KDC MAY choose to filter, transform, or propagate elements >> from the original CAMMAC according to local policy. > > It might. Is this the first time we are using the word "trusted" in a > Kerberos RFC, though? And being concrete does have something going for > it (we just have to get it right). I prefer to avoid using the word "trusted" here. The KDC makes a policy decision about which CAMMACs have contents that are safe to copy verbatim into a new CAMMAC. We can recommend that the KDC limit verbatim CAMMAC copying to cases where only the local realm KDCs know the key that authenticates the CAMMAC. We could define a term "authenticated as originating from a local realm KDC" to mean: 1. kdc-verifier is present and validates; 2. svc-verifier is present, validates, and uses a key known only to local realm KDCs; or 3. no verifiers are present, the ticket-encrypting key is known only to local realm KDCs, and all local realm KDCs properly filter out client-submitted CAMMACs (I think I didn't include case 2 in my earlier message, and think it's somewhat unlikely to get used in practice, but I think mentioning it makes the definition more complete.) We can say that the KDC SHOULD only make verbatim copies of CAMMAC contents to a new CAMMAC when it has authenticated the CAMMAC as originating from a local realm KDC. We might also say that when the KDC has not authenticated a CAMMAC as originating from a local realm KDC, it SHOULD NOT apply a kdc-verifier to a new CAMMAC whose contents are a verbatim copy from that first CAMMAC. (The cross-realm case is somewhat of an exception, though there generally should be some filtering.) I guess "verbatim copying" is really shorthand for "verbatim copying without a complete policy check on the copied stuff". From nobody Thu Feb 26 12:48:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0B1A8793 for ; Thu, 26 Feb 2015 12:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ye1__qtnzRho for ; Thu, 26 Feb 2015 12:48:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 AA4121A879B for ; Thu, 26 Feb 2015 12:47:58 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1QKlvAc025927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 26 Feb 2015 15:47:58 -0500 Received: from [10.3.113.41] (ovpn-113-41.phx2.redhat.com [10.3.113.41]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1QKlvPH016357; Thu, 26 Feb 2015 15:47:57 -0500 Message-ID: <1424983676.640.21.camel@willson.usersys.redhat.com> From: Simo Sorce To: Tom Yu Date: Thu, 26 Feb 2015 15:47:56 -0500 In-Reply-To: References: <54DD194D.2010201@mit.edu> <1424287116.6980.35.camel@willson.usersys.redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 20:48:04 -0000 On Thu, 2015-02-26 at 15:40 -0500, Tom Yu wrote: > Benjamin Kaduk writes: > > > On Wed, 18 Feb 2015, Simo Sorce wrote: > > > >> On Wed, 2015-02-18 at 13:55 -0500, Benjamin Kaduk wrote: > >> > >> Would it make more sense to say something like: > >> > >> The KDC MUST NOT make verbatim copies of CAMMAC contents into a > >> new CAMMAC unless the original CAMMAC is authenticated by an > >> originator that is fully trusted by the KDC. > >> The KDC MAY choose to filter, transform, or propagate elements > >> from the original CAMMAC according to local policy. > > > > It might. Is this the first time we are using the word "trusted" in a > > Kerberos RFC, though? And being concrete does have something going for > > it (we just have to get it right). > > I prefer to avoid using the word "trusted" here. Can we use "authorized" or something similar ? > The KDC makes a policy decision about which CAMMACs have contents that > are safe to copy verbatim into a new CAMMAC. We can recommend that the > KDC limit verbatim CAMMAC copying to cases where only the local realm > KDCs know the key that authenticates the CAMMAC. > > We could define a term "authenticated as originating from a local realm > KDC" to mean: > > 1. kdc-verifier is present and validates; > > 2. svc-verifier is present, validates, and uses a key known only to > local realm KDCs; or > > 3. no verifiers are present, the ticket-encrypting key is known only to > local realm KDCs, and all local realm KDCs properly filter out > client-submitted CAMMACs This definition fails to include cross-realm tgts, because in (2) you say the key must be known only by the local realm KDCS and it is not the case fro cross-realm. > (I think I didn't include case 2 in my earlier message, and think it's > somewhat unlikely to get used in practice, but I think mentioning it > makes the definition more complete.) (2) is fundamental for the cross-realm case where the only thing you can verify in the local KDC is the svc-verifier, given the kdc-verifier uses a key you do not known (the other's realm tgt key). We need to state that it is ok consider the CAMMAC if local policy says you "trust" another REALM (you will probably not fully trust it, and perform some filtering, but that is local policy and is captured in the part that mentions filtering). > We can say that the KDC SHOULD only make verbatim copies of CAMMAC > contents to a new CAMMAC when it has authenticated the CAMMAC as > originating from a local realm KDC. We might also say that when the KDC > has not authenticated a CAMMAC as originating from a local realm KDC, it > SHOULD NOT apply a kdc-verifier to a new CAMMAC whose contents are a > verbatim copy from that first CAMMAC. (The cross-realm case is somewhat > of an exception, though there generally should be some filtering.) > > I guess "verbatim copying" is really shorthand for "verbatim copying > without a complete policy check on the copied stuff". I think we should say the KDC should apply policy but not dictate whether there should necessarily be any filtering. In a cross-realm case you may "fully-trust" the originating realm and decide to verbating copy the CAMMAC, in other cases you may have a different level of trust and apply filtering. The KDC should follow whatever policy the amdin applies, with reasonable defaults in implementations (but that is an implementation detail, we just need to tell implementors what to pay attention to). Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Feb 26 13:40:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FAD1A07BE for ; Thu, 26 Feb 2015 13:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2lt6vthT6xqy for ; Thu, 26 Feb 2015 13:40:30 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FBE1A1B25 for ; Thu, 26 Feb 2015 13:40:29 -0800 (PST) X-AuditID: 1209190f-f79546d000007593-a2-54ef92ccc170 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 27.33.30099.CC29FE45; Thu, 26 Feb 2015 16:40:28 -0500 (EST) 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 t1QLeMW1005446; Thu, 26 Feb 2015 16:40:23 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1QLeL7K018630; Thu, 26 Feb 2015 16:40:22 -0500 From: Tom Yu To: Simo Sorce References: <54DD194D.2010201@mit.edu> <1424287116.6980.35.camel@willson.usersys.redhat.com> <1424983676.640.21.camel@willson.usersys.redhat.com> Date: Thu, 26 Feb 2015 16:40:20 -0500 In-Reply-To: <1424983676.640.21.camel@willson.usersys.redhat.com> (Simo Sorce's message of "Thu, 26 Feb 2015 15:47:56 -0500") Message-ID: Lines: 85 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6nrntm0vsQgztXLSyObl7FYvFj7iJW ByaPJUt+Mnm833eVLYApissmJTUnsyy1SN8ugSvj6NfjrAUdchVn5h5haWB8I97FyMkhIWAi certAjYIW0ziwr31QDYXh5DAYiaJ/Xf6mCCcjYwSk3rbGEGqhATeMErcWVoJYrMJSEscv7yL CcQWEVCQWNB/h6WLkYODWcBU4t8PK5CwsICLxIEHLxgh5qxglviy9TcrSIJFQFViRv9/ZhCb U6Be4umUOSwgNq+ArsSrnRfAZvIIcEoc+P+dCSIuKHFy5hOwGmYBLYkb/14yTWAUmIUkNQtJ agEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYyggOSU5N/B+O2g0iFGAQ5G JR7eHbnvQoRYE8uKK3MPMUpyMCmJ8j6d8D5EiC8pP6UyI7E4I76oNCe1+BCjBAezkghvcDdQ jjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgrdmIlCjYFFqempFWmZO CUKaiYMTZDgP0PD/IIt5iwsSc4sz0yHypxgVpcR5K0CaBUASGaV5cL2whPGKURzoFWHeSyBV PMBkA9f9CmgwE9DgA3ffgQwuSURISTUwul7si/1p8Yjl27VkUyu99fanZy3cvmDpjsbCOf3N mYmHJx+6dnz5xz5TuV9691W3OC12l45MXvPAu/Xp7fnGEgweoiE37DYFGCRXFZQtmzr5A9dS 0/IVC0vfTxW9fFhxr8/7ipYABtN+TqGavRvzp1X6ckt2mYu9/n+s4sDRxJfTOl6k8Be9VWIp zkg01GIuKk4EACrDHFrzAgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 21:40:32 -0000 Simo Sorce writes: > On Thu, 2015-02-26 at 15:40 -0500, Tom Yu wrote: >> Benjamin Kaduk writes: >> >> I prefer to avoid using the word "trusted" here. > > Can we use "authorized" or something similar ? We could, or we could describe the concepts in terms of KDC policies. >> The KDC makes a policy decision about which CAMMACs have contents that >> are safe to copy verbatim into a new CAMMAC. We can recommend that the >> KDC limit verbatim CAMMAC copying to cases where only the local realm >> KDCs know the key that authenticates the CAMMAC. >> >> We could define a term "authenticated as originating from a local realm >> KDC" to mean: >> >> 1. kdc-verifier is present and validates; >> >> 2. svc-verifier is present, validates, and uses a key known only to >> local realm KDCs; or >> >> 3. no verifiers are present, the ticket-encrypting key is known only to >> local realm KDCs, and all local realm KDCs properly filter out >> client-submitted CAMMACs > > This definition fails to include cross-realm tgts, because in (2) you > say the key must be known only by the local realm KDCS and it is not the > case fro cross-realm. I think it's not necessary to include cross-realm in (2). Almost by definition, a cross-realm TGT doesn't originate from the local realm. (I guess a local realm KDC could forge one, because it has the key, but I think there's not much point in analyzing that use case.) >> (I think I didn't include case 2 in my earlier message, and think it's >> somewhat unlikely to get used in practice, but I think mentioning it >> makes the definition more complete.) > > (2) is fundamental for the cross-realm case where the only thing you can > verify in the local KDC is the svc-verifier, given the kdc-verifier uses > a key you do not known (the other's realm tgt key). The cross-realm key is also known to the KDCs of the remote realm, so I think it doesn't call into this set of definitions. We can consider the cross-realm case when we describe policies for CAMMACs not authenticated by local realm KDC-only principals. > We need to state that it is ok consider the CAMMAC if local policy says > you "trust" another REALM (you will probably not fully trust it, and > perform some filtering, but that is local policy and is captured in the > part that mentions filtering). [...] > I think we should say the KDC should apply policy but not dictate > whether there should necessarily be any filtering. > In a cross-realm case you may "fully-trust" the originating realm and > decide to verbating copy the CAMMAC, in other cases you may have a > different level of trust and apply filtering. The KDC should follow > whatever policy the amdin applies, with reasonable defaults in > implementations (but that is an implementation detail, we just need to > tell implementors what to pay attention to). > > Simo. You make a good point that there might be cases where a policy allows the KDC to make verbatim copies of CAMMAC contents in cross-realm TGTs from specific "trusted" remote realms. We could provide examples of local policies that would allow verbatim copying of CAMMAC not originating from a local realm KDC. Some would be: 1. svc-verifier is for a cross-realm TGS principal, and policy allows the KDC to copy that realm's CAMMAC contents verbatim. 2. kdc-verifier is absent, svc-verifier is present and valid, but is for a non-KDC service. Typically only allow verbatim copying if the only possible consumer is the same service principal as the original ticket, but don't apply a kdc-verifier. This is the use case where there's a policy that prohibits the service from using S4U2Proxy, and the KDC omits kdc-verifier to save space in the ticket.