From ghudson@mit.edu Sun Sep 1 21:02:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68021E8082 for ; Sun, 1 Sep 2013 21:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyafB3D9QwOv for ; Sun, 1 Sep 2013 21:02:09 -0700 (PDT) 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 B612411E80D5 for ; Sun, 1 Sep 2013 21:02:08 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-11-52240dbfa7a1 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 67.8B.02357.FBD04225; Mon, 2 Sep 2013 00:02:07 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r82426uU027660; Mon, 2 Sep 2013 00:02:07 -0400 Received: from [18.101.8.132] (vpn-18-101-8-132.mit.edu [18.101.8.132]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8241rFf011638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Sep 2013 00:02:06 -0400 Message-ID: <52240DB0.4010803@mit.edu> Date: Mon, 02 Sep 2013 00:01:52 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Luke Howard References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> In-Reply-To: <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1t3PqxJksPmKtcXRzatYLO5e+s9u sfjrBGYHZo8lS34yeSz+8ZTFY+6HaSwBzFFcNimpOZllqUX6dglcGe83LWYtOMFZ0X5uInMD 4yX2LkZODgkBE4kpvd9ZIWwxiQv31rN1MXJxCAnsY5R4uGoZI0hCSGADo8TpeTwQicNMEsd3 fwfr5hVQkzgwaRFQBwcHi4CqxMzPWSBhNgFliYNnv7GA2KICIRI3l51mhCgXlDg58wlYXERA QWLy/rXMIDazgLXEwvbDbCC2sICmxKYDe9kh9nYxSuzcxwticwrYSPxddYQN4lBJiUXTOlkg enUk3vU9gJojL7H97RzmCYxCs5Csm4WkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0 TfVyM0v0UlNKNzGCQp3dRWkH48+DSocYBTgYlXh4K1YoBwmxJpYVV+YeYpTkYFIS5WUFRooQ X1J+SmVGYnFGfFFpTmrxIUYJDmYlEd5HzEA53pTEyqrUonyYlDQHi5I477OnZwOFBNITS1Kz U1MLUotgsjIcHEoSvDk8QI2CRanpqRVpmTklCGkmDk6Q4TxAw7+B1PAWFyTmFmemQ+RPMSpK ifOKglwkAJLIKM2D64WloleM4kCvCPPeB2nnAaYxuO5XQIOZgAZfm6gIMrgkESEl1cAYHqin xhWvauq/68zBS7f3/jgkrbNmi9BM9rBwM7XulDMdsyumtE+VqevR+302/ElWrajws/aeBW/T 2P41TPzp5JlUKKhcZ5X2+oON/dPLB3ZyWPvEbPeI3nLvguyaQM8VM845lFvHMDnunKlZV7ft mYLB45URh09wH9lc2X1l8iSpWyl7dS4osRRnJBpqMRcVJwIA8jFcPiADAAA= Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 04:02:15 -0000 On 08/28/2013 06:03 PM, Luke Howard wrote: > Unfortunately this interface doesn't exist. We've had an independent request for it and were planning to try to implement it for 1.12, though I'm not sure yet whether time will permit. Do people have opinions among these options: 1. gss_wrap_iov can produce a MIC token using new constants in the iov list. 1a. A new buffer type (GSS_IOV_BUFFER_TYPE_MIC). If the iov list contains one or more DATA buffers and a MIC buffer, we do a MIC computation and put it in the MIC buffer. We could perhaps support MICing and wrapping at the same time with this scheme, although that might not be easy to implement. 2a. A new flag (GSS_IOV_BUFFER_FLAG_MIC_TOKEN). If the iov list contains a TRAILER|MIC_TOKEN buffer, then we do a MIC computation and put it in the trailer (a header buffer is not needed or used). 2. New APIs gss_get_mic_iov, gss_get_mic_iov_length, and gss_verify_mic_iov. 2a. With a new buffer type for the MIC token as in 1a. 2b. Reusing an existing buffer type (like TRAILER). 2c. With the MIC token as a separate parameter from the iov list (so the iov list just contains DATA buffers, and any other buffer types are ignored). From lukeh@padl.com Sun Sep 1 21:09:56 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B9911E81A7 for ; Sun, 1 Sep 2013 21:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZWKjonXooMY for ; Sun, 1 Sep 2013 21:09:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1797B11E80D5 for ; Sun, 1 Sep 2013 21:09:51 -0700 (PDT) Received: by us.padl.com with ESMTP id r8249RhF024324; Mon, 2 Sep 2013 00:09:30 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <52240DB0.4010803@mit.edu> Date: Mon, 2 Sep 2013 14:09:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> <52240DB0.4010803@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 04:09:56 -0000 Hi Greg, I think these are all pretty reasonable proposals. I think I like 1a/2a. 2c I might avoid because there's an extra copy (although not a big deal = really for a MIC). Nico will probably have the most coherent arguments. -- Luke On 02/09/2013, at 2:01 PM, Greg Hudson wrote: > On 08/28/2013 06:03 PM, Luke Howard wrote: >> Unfortunately this interface doesn't exist. >=20 > We've had an independent request for it and were planning to try to > implement it for 1.12, though I'm not sure yet whether time will = permit. >=20 > Do people have opinions among these options: >=20 > 1. gss_wrap_iov can produce a MIC token using new constants in the iov = list. >=20 > 1a. A new buffer type (GSS_IOV_BUFFER_TYPE_MIC). If the > iov list contains one or more DATA buffers and a MIC buffer, we do a = MIC > computation and put it in the MIC buffer. We could perhaps support > MICing and wrapping at the same time with this scheme, although that > might not be easy to implement. >=20 > 2a. A new flag (GSS_IOV_BUFFER_FLAG_MIC_TOKEN). If the iov list > contains a TRAILER|MIC_TOKEN buffer, then we do a MIC computation and > put it in the trailer (a header buffer is not needed or used). >=20 > 2. New APIs gss_get_mic_iov, gss_get_mic_iov_length, and = gss_verify_mic_iov. >=20 > 2a. With a new buffer type for the MIC token as in 1a. >=20 > 2b. Reusing an existing buffer type (like TRAILER). >=20 > 2c. With the MIC token as a separate parameter from the iov list (so = the > iov list just contains DATA buffers, and any other buffer types are > ignored). >=20 -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From chris.newman@oracle.com Tue Sep 3 11:27:19 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A837911E8138 for ; Tue, 3 Sep 2013 11:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOQbIfJji0y7 for ; Tue, 3 Sep 2013 11:27:04 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AF8C311E812B for ; Tue, 3 Sep 2013 11:27:00 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r83IQvS3018682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Sep 2013 18:26:58 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r83IQuZx020941; Tue, 3 Sep 2013 18:26:56 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPA id <0MSK00D4ZB8OR500@gotmail.us.oracle.com>; Tue, 03 Sep 2013 11:26:55 -0700 (PDT) Date: Tue, 03 Sep 2013 11:26:47 -0700 From: Chris Newman To: Greg Hudson , Luke Howard Message-id: In-reply-to: <52240DB0.4010803@mit.edu> References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> <52240DB0.4010803@mit.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:27:19 -0000 I would recommend not adding any iovec-related APIs to a security interface. My experience with such APIs in real-world SSL usage is that they are a common source of serious and hard to diagnose bugs. These APIs tend to be rarely used interfaces so they get inadequate testing, code review and real-world use. I inherited and maintain code that made heavy use of iovecs and I'm busy removing them whenever I can. My experience is that the maintenance, complexity and associated negative security cost of these interfaces far exceeds any potential performance benefit. - Chris --On September 2, 2013 0:01:52 -0400 Greg Hudson wrote: > On 08/28/2013 06:03 PM, Luke Howard wrote: >> Unfortunately this interface doesn't exist. > > We've had an independent request for it and were planning to try to > implement it for 1.12, though I'm not sure yet whether time will permit. > > Do people have opinions among these options: > > 1. gss_wrap_iov can produce a MIC token using new constants in the iov > list. > > 1a. A new buffer type (GSS_IOV_BUFFER_TYPE_MIC). If the > iov list contains one or more DATA buffers and a MIC buffer, we do a MIC > computation and put it in the MIC buffer. We could perhaps support > MICing and wrapping at the same time with this scheme, although that > might not be easy to implement. > > 2a. A new flag (GSS_IOV_BUFFER_FLAG_MIC_TOKEN). If the iov list > contains a TRAILER|MIC_TOKEN buffer, then we do a MIC computation and > put it in the trailer (a header buffer is not needed or used). > > 2. New APIs gss_get_mic_iov, gss_get_mic_iov_length, and > gss_verify_mic_iov. > > 2a. With a new buffer type for the MIC token as in 1a. > > 2b. Reusing an existing buffer type (like TRAILER). > > 2c. With the MIC token as a separate parameter from the iov list (so the > iov list just contains DATA buffers, and any other buffer types are > ignored). > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From matt@linuxbox.com Tue Sep 3 12:19:06 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27F421F9CF5 for ; Tue, 3 Sep 2013 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRtn-Lr3YdDH for ; Tue, 3 Sep 2013 12:19:02 -0700 (PDT) Received: from aa.linuxbox.com (aa.linuxbox.com [69.128.83.226]) by ietfa.amsl.com (Postfix) with ESMTP id DC7DA21F9D23 for ; Tue, 3 Sep 2013 12:19:01 -0700 (PDT) Received: from thunderbeast.private.linuxbox.com (thunderbeast.private.linuxbox.com [10.1.1.55]) by aa.linuxbox.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id r83JJ0wP032579; Tue, 3 Sep 2013 15:19:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id 829EE3FC8498; Tue, 3 Sep 2013 15:19:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at linuxbox.com Received: from thunderbeast.private.linuxbox.com ([127.0.0.1]) by localhost (thunderbeast.private.linuxbox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtFeVgn9tNns; Tue, 3 Sep 2013 15:18:59 -0400 (EDT) Received: from thunderbeast.private.linuxbox.com (thunderbeast.private.linuxbox.com [10.1.1.55]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id 4445D3FC8497; Tue, 3 Sep 2013 15:18:59 -0400 (EDT) Date: Tue, 3 Sep 2013 15:18:59 -0400 (EDT) From: "Matt W. Benjamin" To: Luke Howard Message-ID: <1868920048.189.1378235939012.JavaMail.root@thunderbeast.private.linuxbox.com> In-Reply-To: <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.52] X-Mailer: Zimbra 6.0.5_GA_2180.CentOS5_64 (ZimbraWebClient - FF3.0 (Win)/6.0.5_GA_2180.CentOS5_64) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (aa.linuxbox.com [10.1.1.1]); Tue, 03 Sep 2013 15:19:01 -0400 (EDT) Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:19:06 -0000 Thanks Luke and Greg, 2a seems like a minor extension of the (not exported) interface in recent MITk5, which might be an argument in its favor. Matt ----- "Luke Howard" wrote: > Hi Greg, > > I think these are all pretty reasonable proposals. I think I like > 1a/2a. > > 2c I might avoid because there's an extra copy (although not a big > deal really for a MIC). > > Nico will probably have the most coherent arguments. > > -- Luke > > On 02/09/2013, at 2:01 PM, Greg Hudson wrote: > > > On 08/28/2013 06:03 PM, Luke Howard wrote: > >> Unfortunately this interface doesn't exist. > > > > We've had an independent request for it and were planning to try to > > implement it for 1.12, though I'm not sure yet whether time will > permit. > > > > Do people have opinions among these options: > > > > 1. gss_wrap_iov can produce a MIC token using new constants in the > iov list. > > > > 1a. A new buffer type (GSS_IOV_BUFFER_TYPE_MIC). If the > > iov list contains one or more DATA buffers and a MIC buffer, we do a > MIC > > computation and put it in the MIC buffer. We could perhaps support > > MICing and wrapping at the same time with this scheme, although > that > > might not be easy to implement. > > > > 2a. A new flag (GSS_IOV_BUFFER_FLAG_MIC_TOKEN). If the iov list > > contains a TRAILER|MIC_TOKEN buffer, then we do a MIC computation > and > > put it in the trailer (a header buffer is not needed or used). > > > > 2. New APIs gss_get_mic_iov, gss_get_mic_iov_length, and > gss_verify_mic_iov. > > > > 2a. With a new buffer type for the MIC token as in 1a. > > > > 2b. Reusing an existing buffer type (like TRAILER). > > > > 2c. With the MIC token as a separate parameter from the iov list (so > the > > iov list just contains DATA buffers, and any other buffer types are > > ignored). > > > > -- > Luke Howard / lukeh@padl.com > www.padl.com / www.lukehoward.com -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From nico@cryptonector.com Tue Sep 3 13:17:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34E511E813A for ; Tue, 3 Sep 2013 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP-nRfVEI2KH for ; Tue, 3 Sep 2013 13:17:08 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id E530A21E8092 for ; Tue, 3 Sep 2013 13:17:05 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 94E69438081 for ; Tue, 3 Sep 2013 13:17:05 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 3DF32438080 for ; Tue, 3 Sep 2013 13:17:05 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hj3so2513927wib.13 for ; Tue, 03 Sep 2013 13:17:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6MPSAASEty9jYYzY0MhccOIiq7Oal9AmHv843GOY3WU=; b=Le+TpkJ9ZVqfeDS/nQwx1MlXAEHvxafLpg5qWfal+2UhVkkRI5f655xQl+7KY1m+gr j0X98Z8T4YLC2VYTGQ0s9AQgZsCA5MKtZCOMGjrhoakWqM+90445+9FzuIBQuxm0kxiD s4yNDndhJH+g5EerM/04Culs2Vm+ZmYQbfgQ75qP2Q54KXdoPdALP3A9z1lzNx4RLAPe Rd/Shj4pb8zl6mqO0q58Y9B+FEaJW+j7920IkJcIAGYXksCtOESVUtkUx5xSSCHMBxIZ nc66165i7BLckX/EuppgwbJHfc/fL7XNvA6Vg3RyvedLXWPRFbhr7qjmakq2QzzO5yK+ TREA== MIME-Version: 1.0 X-Received: by 10.181.12.16 with SMTP id em16mr12459133wid.36.1378239423492; Tue, 03 Sep 2013 13:17:03 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 3 Sep 2013 13:17:03 -0700 (PDT) In-Reply-To: <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> <52240DB0.4010803@mit.edu> <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> Date: Tue, 3 Sep 2013 15:17:03 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:17:14 -0000 On Sun, Sep 1, 2013 at 11:09 PM, Luke Howard wrote: > Hi Greg, > > I think these are all pretty reasonable proposals. I think I like 1a/2a. Me too. If we were only just designing gss_wrap_iov() I'd rather have new functions for MICs instead, but as it is I think this will do, but first we should think about ABI issues: it's not uncommon to use LD_* env vars to force a GSS application to use a different libgss (I've seen it done numerous times). And some apps just do this as a matter of course (e.g., the JGSS JNI shim, PuTTY, and probably others). Thinking of ABI safety I would rather have new functions. Otherwise if we think existing gss_[un]wrap_iov() implementations will fail safe when faced with new buffer types then I'll be fine with that approach. Nico -- From nico@cryptonector.com Tue Sep 3 13:31:33 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C021F9A57 for ; Tue, 3 Sep 2013 13:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odogrr-1vLPe for ; Tue, 3 Sep 2013 13:31:28 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3321F9A37 for ; Tue, 3 Sep 2013 13:31:28 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 2D6AB5840A8 for ; Tue, 3 Sep 2013 13:31:23 -0700 (PDT) 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=u92zD+IPL6YmDPlDxOwL mcvw52U=; b=WF+n86uS+p7U3cjor6KYP8dzDLM8+wk1sNQN5kPOzwavqbvGe/hk EVRqZhNtF0rlaCW6cfWusqpfXL+QZGLbvKjakjZhNcjEQtBmUdC6TYVPz0x2CjWe jYRFTl4dYGf6w7simowAr/PAES3tLGbV+wyuhDlqCHlbCPQIABQeqPQ= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id DD774584285 for ; Tue, 3 Sep 2013 13:19:47 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p57so5202041wes.16 for ; Tue, 03 Sep 2013 13:19:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FOuIsQ709nmwYeJPxO/QsG4Iiyw3ATdshl2QZ7HpImE=; b=UuqL1lK/MMxkjOrDMFinGNIm6CwKbhBtRt3R0iZAyuisWk2HCcsY+AyxmocTIDNctw X7OFdxEdn3wzfS9jnvWCtC7Vh2pec5Zto6TGAj5cJ/l06wEO/kCoPaMwaP1BabIfJjhT VpoM8Xd/OUzClDFJVkHb+OSBvTdO+95cxw4z2q0C1PWmFvoLnW/CAZlM59VQDg+zsGzH 4hmy5v+DZmN6J66Pz33KM/kP19gGU3tFEyecOxAGAWVSR8U3S1Syhdx+UhlG7THmYXlZ YQDWfoBsbukyokucmzeIQXb5y3mtm00+d/dP9Pr7+YGGptWNspmspEmgf+Lvl/L2JhIG 4/7A== MIME-Version: 1.0 X-Received: by 10.180.36.169 with SMTP id r9mr19754978wij.20.1378239586455; Tue, 03 Sep 2013 13:19:46 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 3 Sep 2013 13:19:46 -0700 (PDT) In-Reply-To: References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> <52240DB0.4010803@mit.edu> Date: Tue, 3 Sep 2013 15:19:46 -0500 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:31:33 -0000 On Tue, Sep 3, 2013 at 1:26 PM, Chris Newman wrote: > I would recommend not adding any iovec-related APIs to a security interface. > My experience with such APIs in real-world SSL usage is that they are a > common source of serious and hard to diagnose bugs. These APIs tend to be > rarely used interfaces so they get inadequate testing, code review and > real-world use. I inherited and maintain code that made heavy use of iovecs > and I'm busy removing them whenever I can. My experience is that the > maintenance, complexity and associated negative security cost of these > interfaces far exceeds any potential performance benefit. But there really are apps that care about performance... NFS (the app in question here, via RPCSEC_GSS) is one such app. Mind you, RPCSEC_GSS if a bit of a performance disaster anyways because it requires two per-message token function calls per-RPC (when protecting the data, not just the RPC header), and should be re-done (maybe) so it at most does one GSS per-message token call per-RPC. But that wouldn't make RPCSEC_GSS not need iovec GSS calls. Nico -- From kaduk@mit.edu Wed Sep 4 08:56:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254DD11E81D3 for ; Wed, 4 Sep 2013 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2MUXWiJL6z4 for ; Wed, 4 Sep 2013 08:56:48 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 83E8B11E81CC for ; Wed, 4 Sep 2013 08:56:47 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-d5-5227583d13d6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.7C.02359.D3857225; Wed, 4 Sep 2013 11:56:45 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r84FuihV001771; Wed, 4 Sep 2013 11:56:45 -0400 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 r84FugEQ025035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Sep 2013 11:56:44 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r84FugZH002226; Wed, 4 Sep 2013 11:56:42 -0400 (EDT) Date: Wed, 4 Sep 2013 11:56:42 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrGsboR5k8GWPlMXRzatYLO5e+s/u wOSxZMlPJo+5H6axBDBFcdmkpOZklqUW6dslcGX8693GXLBBuOLmlR2MDYxL+bsYOTkkBEwk vjxfwAhhi0lcuLeerYuRi0NIYB+jxIzf/1ghnA2MEueu/mKEcA4ySSxaNJcFpEVIoF5i7v/Z YDaLgJbEk69P2UFsNgEViZlvNrKB2CICwhK7t75jBrGZBRQkLv/4CVTPwSEs4CyxcVcESJhT wEli6ox5YFfwCjhKPO48yw4xfiGjRFO/DogtKqAjsXr/FBaIGkGJkzOfsECMtJT4t/YX6wRG wVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIDlRJ3h2M7w4q HWIU4GBU4uFtMFYPEmJNLCuuzD3EKMnBpCTKuzYYKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE V84bKMebklhZlVqUD5OS5mBREud9+vRsoJBAemJJanZqakFqEUxWhoNDSYL3ShhQo2BRanpq RVpmTglCmomDE2Q4D9DwFJAa3uKCxNzizHSI/ClGRSlx3kcgCQGQREZpHlwvLJG8YhQHekWY 9zlIFQ8wCcF1vwIazAQ0OO2zKsjgkkSElFQD40rX3ORmnpT9W6qlJ+YxPLvZeT5ybtq6/7fX Xnxc7G90+oxKdTO75PI16WL6Xu0306zbPlg88gzR/i3eVTThiMvmtVdTuESLZaZI5Av1tp1z rZZIWZx2paVlp6n/NzvrGYUXlkV3B85VmVF2vnPLrTfLLZfmXBCaaal31MjYhfHUaqt3C32O KrEUZyQaajEXFScCAJqIZQz/AgAA Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:56:54 -0000 On Tue, 6 Aug 2013, Benjamin Kaduk wrote: > I'll tabulate these and send mail to iana@iana.org in a few days unless > alternate advice materializes. > https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/ indicates that the > IESG has sent it to the RFC editor, so it may be a bit late to get it to > include the additional RFC 1964 token types. It turns out that it would be easier for IANA if the abfab-gss-eap document which creates the registry was updated to include all the published values in existing RFCs. With regard to non-final drafts, the document authors will probably be on the hook for getting values allocated: > Unfortunately, we don't have an expert yet. I'll submit an item for > the next IESG telechat (on the 29th) asking an AD to find someone > they can designate. It may be possible to get someone designated on > that very telechat, but it could take longer. > > Finally, the authors of the in-process I-Ds need to send each request > to iana@iana.org themselves, if they're ready. If they suspect that > the details of those proposed registrations could change, they > should wait for IESG approval, at which point we'll make any > requested registrations anyway, as long as they're included in the > IANA Considerations section (although the values they want may not > be available). > > If they want to request specific values, I'd recommend submitting > their requests sooner than that, since we can't reserve values for > pending registrations. Whether an I-D-based request is ready for > registration or whether it should wait is up to the expert, though. We mentioned a few in-progress documents: draft-swift-win2k-krb-user2user-03 defines 0400 KERB-TGT-REQUEST 0401 KERB-TGT-REPLY draft-ietf-krb-wg-iakerb-02 defines 0501 IAKERB_PROXY draft-howard-gss-browserid-04 section 4 defines 632C Initiator context token 432C Acceptor context token 442C Context deletion token 6D2C Initiator metadata token 4D2C Acceptor metadata token Luke, I guess we can consider you informed, for the purposes of the browserid document :) I guess we turned iakerb into a kitten wg document, so Jim should be able to take that on, I hope. We might have some trouble finding an active author for U2U, though. Once an expert reviewer is found for the registry, though, I suspect it won't be too hard to come to a resolution. -Ben From hartmans@mit.edu Fri Sep 6 13:17:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23C911E812C for ; Fri, 6 Sep 2013 13:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+Qc20lWFRgq for ; Fri, 6 Sep 2013 13:17:14 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B13AD11E80F7 for ; Fri, 6 Sep 2013 13:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E308A2033E for ; Fri, 6 Sep 2013 16:16:58 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBf3BjVOLrqf for ; Fri, 6 Sep 2013 16:16:58 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Fri, 6 Sep 2013 16:16:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C359588286; Fri, 6 Sep 2013 16:17:04 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Fri, 06 Sep 2013 16:17:04 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:17:20 -0000 Folks, this message starts a consensus call on the question of whether draft-ietf-kitten-aes-cts-hmac-sha2-01 should adopt the proposal to use CBC mode rather than CTS mode. Comments in favor or against this change should be received by September 16, 2013. Even if you have commented in the past, please send in a comment again. From nico@cryptonector.com Fri Sep 6 13:24:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E6F21F9B4D for ; Fri, 6 Sep 2013 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk82h+5tShBO for ; Fri, 6 Sep 2013 13:24:05 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id EC99221F9B7E for ; Fri, 6 Sep 2013 13:23:41 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id CE7DA2C8058 for ; Fri, 6 Sep 2013 13:23:35 -0700 (PDT) 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=qEIvo6OmUrwmdKHoDtBt IrqFFYo=; b=uwk5Xx4FxaHe3vr8a0FeLIEjXyWkSTWdqn0efA9BhMp0ylNqTEax 4TOmGF2AmfmVDl1+Ts8tNHafK8GaqsJ+lWCcWIdhh1zaQ32kdUbQ5pkd5nMuJvjX 7JWJGssLy9Ab0FjBRxKMFGz96DrFw31X89UaaAI5SBTJJsKKFS9I6tA= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 7831E2C8056 for ; Fri, 6 Sep 2013 13:23:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj3so1389295wib.13 for ; Fri, 06 Sep 2013 13:23:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZWf/llV2ErCvg1gow0G5VMu1XZweedSQ/fEXUKUQsOI=; b=gQRd4DIWRHlM+1YSRr6eQ4w/J0zlyG+1dESv5jv3K85yAQJKNaa+XR0v9RokyvhHpJ UERg0C9l5aTmkpi/1n8Pcv+olNDxpR6RR/aqFecaQyurlMcI19WcoWYGeiIzQW0eF1Ab FNOoEbkH17IhBZd82oQcHiMoCOKQNp25HxwNhpjLkBeM+aX5sGSQ07b/1sfW75gbgACc XzMoC0+fTMnOwW4x0cKsyT6Evrbs1AovjmIE4Ce6awRSy/UNM7qxQhn3ZRYtdWfP6dYT 787sNT2k3m4Ig7y+N3e3pSpcQTj2EpsenAYSg1eUNDofHwX8e9Sx7jGxLXLN1OTLek0G KW3A== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr3344056wic.33.1378499013801; Fri, 06 Sep 2013 13:23:33 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Fri, 6 Sep 2013 13:23:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Sep 2013 15:23:33 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:24:15 -0000 Assuming no objections are asserted regarding DCE RPC w/ SSPI (I *think* those were cleared up), I have no objections and, indeed, I'm quite in favor of the proposal. From shawn.emery@oracle.com Fri Sep 6 13:30:13 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B570A21E80B4 for ; Fri, 6 Sep 2013 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIyYsVQufEr4 for ; Fri, 6 Sep 2013 13:30:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3659321E8054 for ; Fri, 6 Sep 2013 13:30:07 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r86KU6Ci015295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Sep 2013 20:30:06 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r86KU5Xm008713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Sep 2013 20:30:05 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r86KU54d020601 for ; Fri, 6 Sep 2013 20:30:05 GMT Received: from [192.168.0.7] (/75.171.218.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Sep 2013 13:30:04 -0700 Message-ID: <522A3B89.1010307@oracle.com> Date: Fri, 06 Sep 2013 14:31:05 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:30:13 -0000 The WG is making the following consensus calls (which were formulated from Berlin's meeting held on August 1st): 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 related text from the draft and continue the proceed to shepherd this as an RFC? a. Yes b. No c. Don't care or need more information 2. Should the WG recharter and adopt the draft-williams-kitten-generic-naming-attributes draft? a. Yes b. No c. Don't care or need more information 3. Should the WG recharter and adopt the draft-williams-kitten-krb5-pkcross draft? a. Yes b. No c. Don't care or need more information Please provide your input before September 20th. Thank you. Shawn. -- kitten co-chair From wmills@yahoo-inc.com Fri Sep 6 15:39:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE221F9CA0 for ; Fri, 6 Sep 2013 15:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.169 X-Spam-Level: X-Spam-Status: No, score=-17.169 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR5-4MWHRv+x for ; Fri, 6 Sep 2013 15:39:20 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3821F9E9D for ; Fri, 6 Sep 2013 15:39:15 -0700 (PDT) Received: from GQ1-EX10-CAHT08.y.corp.yahoo.com (gq1-ex10-caht08.corp.gq1.yahoo.com [10.73.118.87]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r86McI3p018998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Sep 2013 15:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1378507101; bh=QMmEpOXwU8kShYp4RAQEO64vQwbxVFMQmN35sIvnH6Q=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=JUscqsJ7mzbJUGAkN5FQ8kMVf0tb0WgT1eJBaeL0V9xX+ZnTVSM1TG/ct6q/+SeMv GaCSQ4rFUMg3UCthhSddKihhWkPL8/Wjq/531p7UoNEEYZtB7ooAxcTXzfGLT68xTq BhNLbc+TCtvZEZ2hut7bYJUbLwc3tDUa74RzR4B4= Received: from omp1038.mail.ne1.yahoo.com (98.138.88.238) by GQ1-EX10-CAHT08.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Sep 2013 15:38:18 -0700 Received: (qmail 30265 invoked by uid 1000); 6 Sep 2013 22:38:17 -0000 Received: (qmail 3747 invoked by uid 60001); 6 Sep 2013 22:38:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1378507097; bh=AN90EZKSCzDfPZEiiZWC49TVYnrQigcilXwTN5phAz4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ebE/qk9XVQWk6qVah9tel8N6XaT/cze/nzArLIqdyT/2Q4/GF9IWibAqL/aULClIcJFWypUzLf0HO0saMcFNQSrqWATA9uykAb1ARepI8+DOtjxJ9L42DeVr5b5icD2aD6p7EPT4gaq3AnL73tET9KYtPEdXJNBpIacaM1e3Zj8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IHp1fpAv6LJrl+rfwRI0DEMVlphEexRCCRXMeGRCO8BRhemeOz2zz5rHdTB7/t9s8guGCDFtK0HpCusLoTBT0fr7ULjRiVDyo59Do9k1/Wu1JjDjamv64CFHzWMOBO8cAjlhTNszIZ5yFqOZKbbhA7jTJYZVo2C2ZdK9HckFzDA=; X-YMail-OSG: rGLCuRQVM1nFAmQ7tVbj7xmoDl4qRESDx0ce78PHa7r5L1. .XKhjfJMO9ThGvR.2leClibBQ6v79OnRWIR_h1JOGpacOnJK1lStpKqF4Q4B Ze_HO1LR2uK2Y2VgjOXxWGT79UsIIv9oStBbh3R1Se7Y2mCLnlrCkFCA_tu7 RBbjH0oXZgecz1q8wSU0N5IA6gZQu6uKX39d.xIut3.4YNZRutpQa15TYJ66 .l2Rm1FbN3vXTMLKyqN7SxPK5yQ5zQcZryAy5TGzZJtdYRIK112RgXxRFaCt Uveo_p9lus4FvopXYD1W.rH0w Received: from [66.228.162.40] by web125604.mail.ne1.yahoo.com via HTTP; Fri, 06 Sep 2013 15:38:17 PDT X-Rocket-MIMEInfo: 002.001, MT4gWWVzCjImMz4gRG9uJ3QgaGF2ZSBhbiBvcGluaW9uLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBTaGF3biBNIEVtZXJ5IDxzaGF3bi5lbWVyeUBvcmFjbGUuY29tPgpUbzoga2l0dGVuQGlldGYub3JnIApTZW50OiBGcmlkYXksIFNlcHRlbWJlciA2LCAyMDEzIDE6MzEgUE0KU3ViamVjdDogW2tpdHRlbl0gQ29uc2Vuc3VzIEMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <522A3B89.1010307@oracle.com> Message-ID: <1378507097.91324.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Fri, 6 Sep 2013 15:38:17 -0700 From: Bill Mills To: Shawn M Emery , "kitten@ietf.org" In-Reply-To: <522A3B89.1010307@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-999804070-1378507097=:91324" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 507099003 Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 06 Sep 2013 22:39:25 -0000 ---685807438-999804070-1378507097=:91324 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1> Yes=0A2&3> Don't have an opinion.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A-------= -------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A= =0A=0A________________________________=0A From: Shawn M Emery =0ATo: kitten@ietf.org =0ASent: Friday, September 6, 2013 1:31 P= M=0ASubject: [kitten] Consensus Calls=0A =0A=0A=0AThe WG is making the foll= owing consensus calls (which were formulated =0Afrom Berlin's meeting held = on August 1st):=0A=0A1. In regards to draft-ietf-kitten-sasl-oauth; should = we remove the GS2 =0Arelated text from the draft and continue the proceed t= o shepherd this as =0Aan RFC?=0A=0Aa. Yes=0Ab. No=0Ac. Don't care or need m= ore information=0A=0A2. Should the WG recharter and adopt the =0Adraft-will= iams-kitten-generic-naming-attributes draft?=0A=0Aa. Yes=0Ab. No=0Ac. Don't= care or need more information=0A=0A3. Should the WG recharter and adopt th= e =0Adraft-williams-kitten-krb5-pkcross draft?=0A=0Aa. Yes=0Ab. No=0Ac. Don= 't care or need more information=0A=0APlease provide your input before Sept= ember 20th.=A0 Thank you.=0A=0AShawn.=0A--=0Akitten co-chair=0A____________= ___________________________________=0AKitten mailing list=0AKitten@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/kitten ---685807438-999804070-1378507097=:91324 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1> Yes=
2&3> Don't have an opinion.
&nbs= p;
-bill


--------------------------------
William = J. Mills
"Paranoid" Yahoo!


From:<= /b> Shawn M Emery <shawn.emery@oracle.com>
To: kitten@ietf.org
Sent: Friday, September 6, 2013 1:31 PM
Subject: [kitten] Consensus Calls
=


The WG is making the = following consensus calls (which were formulated
from Berlin's meeting = held on August 1st):

1. In regards to draft-ietf-kitten-sasl-oauth; = should we remove the GS2
related text from the draft and continue the p= roceed to shepherd this as
an RFC?

a. Yes
b. No
c. Don't c= are or need more information

2. Should the WG recharter and adopt th= e
draft-williams-kitten-generic-naming-attributes draft?

a. Yes<= br>b. No
c. Don't care or need more information

3. Should the WG = recharter and adopt the
draft-williams-kitten-krb5-pkcross draft?
a. Yes
b. No
c. Don't care or need more information

Please p= rovide your input before September 20th.  Thank you.

Shawn.
--
kitten co-chair
___________________________= ____________________
Kitten mailing list
Kitten@ietf.org
https://ww= w.ietf.org/mailman/listinfo/kitten


---685807438-999804070-1378507097=:91324-- From moransar@cisco.com Fri Sep 6 15:46:03 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D982D21E80BD for ; Fri, 6 Sep 2013 15:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd8soDUnba+Y for ; Fri, 6 Sep 2013 15:45:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CDE8021E80DB for ; Fri, 6 Sep 2013 15:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=471; q=dns/txt; s=iport; t=1378507556; x=1379717156; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=jUT7r+W827ZxjYj37aIzNa8uveDoi1CE0/nzdaTRUeQ=; b=LGjC7jfpDdwmrNRn84MTRF1VfF2w4hIQIM9wjC6iy0XdAMcf+XpNhLb6 zlv4Iqi3O5IfqjbxvJe9B2rbRpyiGzYlg57YzmO29ynszWyzCJV4NA8aw +kVK7axBALhJBdpeWufmV8SuFPUCnpajcQS0dcIUhCTDLeaDetmWaQiU/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAMZaKlKtJV2d/2dsb2JhbABbgweBBoJjvn2BJxZ0giYBBDpRAQgiFEIlAgQBEgiHesBpj0s4gx2BAAOpW4Mggio X-IronPort-AV: E=Sophos;i="4.90,857,1371081600"; d="scan'208";a="256677996" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 06 Sep 2013 22:45:45 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r86MjjXL017340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 22:45:45 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.27]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 17:45:45 -0500 From: "Morteza Ansari (moransar)" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] Consensus Calls Thread-Index: AQHOqz/nGTpKxba4EkGBJ5agsvuZqZm5LZyA Date: Fri, 6 Sep 2013 22:45:44 +0000 Message-ID: In-Reply-To: <522A3B89.1010307@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.84.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 22:46:03 -0000 On 9/6/13 1:31 PM, "Shawn M Emery" wrote: > >The WG is making the following consensus calls (which were formulated >from Berlin's meeting held on August 1st): > >1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 >related text from the draft and continue the proceed to shepherd this as >an RFC? > >a. Yes >b. No >c. Don't care or need more information Yes. For other questions "C". Cheers, Morteza From ghudson@mit.edu Fri Sep 6 22:01:30 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B43221F9DA9 for ; Fri, 6 Sep 2013 22:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPYNLPsSfUqz for ; Fri, 6 Sep 2013 22:01:24 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9780521F9DFC for ; Fri, 6 Sep 2013 22:01:22 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-3f-522ab321c6d5 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F7.C6.02387.123BA225; Sat, 7 Sep 2013 01:01:21 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r8751KEf032669; Sat, 7 Sep 2013 01:01:20 -0400 Received: from [18.101.8.240] (vpn-18-101-8-240.mit.edu [18.101.8.240]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8751Ieb027560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Sep 2013 01:01:19 -0400 Message-ID: <522AB31D.6050109@mit.edu> Date: Sat, 07 Sep 2013 01:01:17 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT11XcrBVk0LtN2eJr2wM2i6ObV7E4 MHksWfKTyWPl1NPsAUxRXDYpqTmZZalF+nYJXBk/1z5lK/jJWLF+8geWBsbjjF2MnBwSAiYS P18thrLFJC7cW8/WxcjFISSwj1Hi/MI+ZpCEkMAGRomXP7IhEoeZJHrfT2PpYuTg4BVQk9hz Wg+khkVAVeL6hGssIDabgLLEwbPfwGxRgRCJm8tOgy3gFRCUODnzCVhcREBdYvWlSewgNrOA sMSF7XtZQWxhgQiJLedOMELsVZWY+esGG4jNCbRq1ulz7BCHSkosmtbJAtGrI/Gu7wEzhC0v sf3tHOYJjEKzkKybhaRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3 MYLCmlOSfwfjt4NKhxgFOBiVeHgNbmsGCbEmlhVX5h5ilORgUhLlfbBSK0iILyk/pTIjsTgj vqg0J7X4EKMEB7OSCG9NLlCONyWxsiq1KB8mJc3BoiTO++zp2UAhgfTEktTs1NSC1CKYrAwH h5IE7+uNQI2CRanpqRVpmTklCGkmDk6Q4TxAw6+C1PAWFyTmFmemQ+RPMepy/Fk59xOjEEte fl6qlDjvG5AiAZCijNI8uDmwdPSKURzoLWHezyBVPMBUBjfpFdASJqAlPmc1QZaUJCKkpBoY fVVFt/zuVrohvuJ1l/5CKz19r77S+NmmmUeqzvzrql019xRfvfid/rXCr6rdRL8KG/YX6BSY OAke1dh/iKel9Nangu2nmpcuPncyIngT4yZz22tPpjGszHtf8WmpVYSMWJVCaq3Tch/h9z4i FyrnzhS0SWlVfqjFa7i7Mtv68CktRzGd1c+VWIozEg21mIuKEwHUe6cmIgMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 05:01:30 -0000 On 09/06/2013 04:17 PM, Sam Hartman wrote: > Folks, this message starts a consensus call on the question of whether > draft-ietf-kitten-aes-cts-hmac-sha2-01 should adopt the proposal to use > CBC mode rather than CTS mode. I am in favor. From simo@redhat.com Sat Sep 7 11:44:46 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B6A21F9E3F for ; Sat, 7 Sep 2013 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1D6rVUgpLcv for ; Sat, 7 Sep 2013 11:44:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1738821E80C3 for ; Sat, 7 Sep 2013 11:44:30 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r87IA77A007132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Sep 2013 14:10:07 -0400 Received: from [10.3.113.39] (ovpn-113-39.phx2.redhat.com [10.3.113.39]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r87IA6wc019501; Sat, 7 Sep 2013 14:10:06 -0400 From: Simo Sorce To: Sam Hartman In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Sat, 07 Sep 2013 14:10:05 -0400 Message-ID: <1378577405.2804.1349.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 18:44:46 -0000 On Fri, 2013-09-06 at 16:17 -0400, Sam Hartman wrote: > > Folks, this message starts a consensus call on the question of whether > draft-ietf-kitten-aes-cts-hmac-sha2-01 should adopt the proposal to use > CBC mode rather than CTS mode. > > Comments in favor or against this change should be received by September > 16, 2013. In favor. -- Simo Sorce * Red Hat, Inc * New York From kaduk@mit.edu Sat Sep 7 23:28:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D829321F9E88 for ; Sat, 7 Sep 2013 23:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01V716X+nCFi for ; Sat, 7 Sep 2013 23:27:54 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4E63721F9DAF for ; Sat, 7 Sep 2013 23:27:53 -0700 (PDT) X-AuditID: 12074423-b7f168e00000095a-c8-522c18e62fe2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A9.4E.02394.6E81C225; Sun, 8 Sep 2013 02:27:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r886RnjM015830; Sun, 8 Sep 2013 02:27:50 -0400 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 r886RlUT006035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Sep 2013 02:27:49 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r886RkIq023673; Sun, 8 Sep 2013 02:27:46 -0400 (EDT) Date: Sun, 8 Sep 2013 02:27:46 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman 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; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrPtMQifIYPppRYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGXsvSBU8Jap4sLEV0wNjHOYuhg5OSQETCSe HD3ODmGLSVy4t56ti5GLQ0hgH6PE9DmroJwNjBK7Zi+Acg4ySfw7cpYZpEVIoF7i7oYjYO0s AloS697MZQOx2QRUJGa+2QhmiwioS7RP+ApmMwsIS6w/NwOsV1ggSuLyts9gcU4BNYlZp8+B zeEVcJT4+v0qE8R8VYmZv26A1YgK6Eis3j+FBaJGUOLkzCcsEDMtJc79uc42gVFwFpLULCSp BYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYICld1FeQfjn4NKhxgFOBiV eHgrJmoHCbEmlhVX5h5ilORgUhLlfSGgEyTEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhNc1BKic NyWxsiq1KB8mJc3BoiTO++zp2UAhgfTEktTs1NSC1CKYrAwHh5IEb5g40FDBotT01Iq0zJwS hDQTByfIcB6g4Q9AaniLCxJzizPTIfKnGHU5/qyc+4lRiCUvPy9VSpz3MkiRAEhRRmke3BxY gnnFKA70ljDvfZAqHmBygpv0CmgJE9ASn7OaIEtKEhFSUg2MsaZL/iYG+bwPXJFklGjVIXtY 0NmhadbkXz4zPj1M2LMt4/V5tQkBT7rX7DyqVBvFv9dcI/fN0bus9ddOMjkdvbfvxFODU+mh P9Uehoa+fyquejyk1Sbhu8M+ucIZnJo3PUp1Ptpw/ola+vS+0+n3f2Ys7t2y4Dbna50mj9rH bXEfXE3bFr3KVmIpzkg01GIuKk4EAG8mo0YLAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 06:28:01 -0000 On Fri, 6 Sep 2013, Sam Hartman wrote: > > > Folks, this message starts a consensus call on the question of whether > draft-ietf-kitten-aes-cts-hmac-sha2-01 should adopt the proposal to use > CBC mode rather than CTS mode. > > Comments in favor or against this change should be received by September > 16, 2013. I am in favor of the CBC mode. -Ben From mamille2@cisco.com Mon Sep 9 06:48:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903ED21F9CBF for ; Mon, 9 Sep 2013 06:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsRP8fTPJ6gA for ; Mon, 9 Sep 2013 06:48:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF821F9CBD for ; Mon, 9 Sep 2013 06:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7268; q=dns/txt; s=iport; t=1378734340; x=1379943940; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UAnqX/GIRwkCpWGKRJjqY+V8hAx3l35LWZiGu1RF3wA=; b=Wt7G5+PlsneeaPj4r0uGjGNZB3QnDaXyUFgiVa36pM5uJEdYdeE/aUCx l4FQjfmOUk9sh1cJnAZMJdZ77P8B0TaoMSjhXjwheSDmhjAl9gm2l8w/0 kPzL/SbVnykH3lqSAD/lCnAz1pi1DVRkppq4PrPZ/PWVWM8Xwk/XakrSG Y=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADTQLVKtJXG9/2dsb2JhbABbgwc4UcIUgSIWdIIlAQEBAwEBAQFrEAsCAQgRBAEBCyQCJQsdCAIEARIIBoduBgzEFwSPTziDHYEAA5AjgS6YCoMggio X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="p7s'?scan'208";a="257420066" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 09 Sep 2013 13:45:32 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r89DjWSH020138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 13:45:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.124]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 08:45:32 -0500 From: "Matt Miller (mamille2)" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] Consensus Calls Thread-Index: AQHOqz/n5pdl6RrYvUKMcnpIgGnUDJm5oOGAgAQiJIA= Date: Mon, 9 Sep 2013 13:45:32 +0000 Message-ID: References: <522A3B89.1010307@oracle.com> <1378507097.91324.YahooMailNeo@web125604.mail.ne1.yahoo.com> In-Reply-To: <1378507097.91324.YahooMailNeo@web125604.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.123] Content-Type: multipart/signed; boundary="Apple-Mail=_1FA46E5A-038B-4BE7-86D5-4AE55EBAEFBC"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:48:25 -0000 --Apple-Mail=_1FA46E5A-038B-4BE7-86D5-4AE55EBAEFBC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 1) Yes 2) No opinion 3) No opinion - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > From: Shawn M Emery > To: kitten@ietf.org > Sent: Friday, September 6, 2013 1:31 PM > Subject: [kitten] Consensus Calls > > > > The WG is making the following consensus calls (which were formulated > from Berlin's meeting held on August 1st): > > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 > related text from the draft and continue the proceed to shepherd this as > an RFC? > > a. Yes > b. No > c. Don't care or need more information > > 2. Should the WG recharter and adopt the > draft-williams-kitten-generic-naming-attributes draft? > > a. Yes > b. No > c. Don't care or need more information > > 3. Should the WG recharter and adopt the > draft-williams-kitten-krb5-pkcross draft? > > a. Yes > b. No > c. Don't care or need more information > > Please provide your input before September 20th. Thank you. > > Shawn. > -- > kitten co-chair > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_1FA46E5A-038B-4BE7-86D5-4AE55EBAEFBC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MDkxMzQ1 MzJaMCMGCSqGSIb3DQEJBDEWBBRo29cImgLkr5U13E+320m4r4piaTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAGcn b6JQlq7kY0hlKdebn8lS1w+HNnOm2FyoLCIyl8yc4dXsHLDm11r3TPF9IidqeGnJZIoiWOWyJsHV Ftuhubp8MtW9N/pEnpJ9djDwIhU96Opbs8Ah3JIscaYCk17Y69v6gMwFSHcNvCxg94hh1uMcAAEY ZEaYiNUgmV9s97FLiBGM5CergILdBzE0qXaOby6rbR1W57pOzZsT5CGMr9ztCo41V1XEAMu9DVaG Szl7XuY8cR1Wsim6KY0cBGzo0N4LIktS7i31fIg6fF6fwE2GL8A5M+sC1DTFsI+tlwlozNntaU6h 2pxECNcDvRxN473w62JCudUrydkfq4Auo3cAAAAAAAA= --Apple-Mail=_1FA46E5A-038B-4BE7-86D5-4AE55EBAEFBC-- From cantor.2@osu.edu Mon Sep 9 07:05:04 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1870D21F9D71 for ; Mon, 9 Sep 2013 07:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwrL3ALHXKe0 for ; Mon, 9 Sep 2013 07:04:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id D070921E81DE for ; Mon, 9 Sep 2013 06:58:32 -0700 (PDT) Received: from mail223-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 13:58:31 +0000 Received: from mail223-ch1 (localhost [127.0.0.1]) by mail223-ch1-R.bigfish.com (Postfix) with ESMTP id 57ED54A0158; Mon, 9 Sep 2013 13:58:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.218; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf04; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: VPS7(zzda00hdc73hzz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h1b1cn1b1bi1155h) Received-SPF: pass (mail223-ch1: domain of osu.edu designates 164.107.81.218 as permitted sender) client-ip=164.107.81.218; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf04 ; cio-tnc-pf04 ; Received: from mail223-ch1 (localhost.localdomain [127.0.0.1]) by mail223-ch1 (MessageSwitch) id 1378735041883393_22321; Mon, 9 Sep 2013 13:57:21 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail223-ch1.bigfish.com (Postfix) with ESMTP id C98F6160221; Mon, 9 Sep 2013 13:57:21 +0000 (UTC) Received: from cio-tnc-pf04 (164.107.81.218) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 13:57:21 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf04 (Postfix) with ESMTP id 71CD2380055; Mon, 9 Sep 2013 09:57:21 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0123.003; Mon, 9 Sep 2013 09:56:54 -0400 From: "Cantor, Scott" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] Consensus Calls Thread-Index: AQHOqz/nONip+vcxCk2Y0t35n7h2Tpm9cmqA Date: Mon, 9 Sep 2013 13:56:54 +0000 Message-ID: In-Reply-To: <522A3B89.1010307@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:05:04 -0000 1. Don't care. 2. Yes 3. Don't care. -- Scott From stpeter@stpeter.im Mon Sep 9 09:28:37 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADDF21E8093 for ; Mon, 9 Sep 2013 09:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-Zq1ZlrhZSg for ; Mon, 9 Sep 2013 09:28:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3E45A21F9D7E for ; Mon, 9 Sep 2013 09:10:10 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26EF1414CF; Mon, 9 Sep 2013 10:14:32 -0600 (MDT) Message-ID: <522DF2DF.1040805@stpeter.im> Date: Mon, 09 Sep 2013 10:10:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Shawn M Emery References: <522A3B89.1010307@oracle.com> In-Reply-To: <522A3B89.1010307@oracle.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:28:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/6/13 2:31 PM, Shawn M Emery wrote: > The WG is making the following consensus calls (which were > formulated from Berlin's meeting held on August 1st): 1. yes 2. don't care 3. don't care Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLfLfAAoJEOoGpJErxa2pPW4P/2VQXd8H1tKTi/NYCxpPeGRz hH93jvKefiuYBEseL/MUb7Btk78w46OPH8McAIC4TW5PzJE6QO7U8U5ubyIrHhrX t3KuWnoGSPQCrop5R9du6U2IX5LoNJ+bfoLVgXjJyJBNldbKE74yNSHTvFQbqni6 jy7FlG4rZVhzArRaP64DtM8sJOQwaqMIcQWUe1Tq1gQSqYIlcUHUkMcY/Jbr3dBy pD9vUtjNky/lbsOp552Z34lEmzwhvWPVJyTNFZ2AUkAB+13728BC+SbrjkVZQQ1u 5/i5X+c24Iz8cVSJSLXsQ8H2Dgp3csM9TLeLqt7eWqQQZdQ2zmJ87EJCvUXHc9xi F6HfEIR/QAtxKwVz7awk9ionEfOAIYSbQ9axik/Q/hM0HCs7+RaH6zeMfWVFo3x3 aDBfBrP2TOoWBsjCodzqo69mEjXrB7j0vJ+0owsJlqH18h83LMTLQKL/M5PAQaEi ap6kFcrgHUlGA+RuheS1mpuBmDxiwXA+pqEC41uM/t5S+Y5j3J13UZ88EebiF5Zk DIfeVGmhX0NE21nGgTWuABMZjucGDc3BnvendxhSiztbGFy6fI2/V+yo9GpJbp8l DnzeuqOwyks+yTn4HIi813PTNmFkeJcQRZI9g4J2vRl6MW+vkxoAu5Y5bPQJ6n+G 7zsmzcXdmhhldsYqMaf6 =e7lA -----END PGP SIGNATURE----- From simo@redhat.com Mon Sep 9 12:07:26 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A516E21E81AE for ; Mon, 9 Sep 2013 12:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xkz7ayr4dF6 for ; Mon, 9 Sep 2013 12:07:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36821E80AB for ; Mon, 9 Sep 2013 12:07:21 -0700 (PDT) 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 r89J7Lnb029815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Sep 2013 15:07:21 -0400 Received: from [10.3.113.39] (ovpn-113-39.phx2.redhat.com [10.3.113.39]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r89J7Kqf017674; Mon, 9 Sep 2013 15:07:20 -0400 From: Simo Sorce To: Shawn M Emery In-Reply-To: <522A3B89.1010307@oracle.com> References: <522A3B89.1010307@oracle.com> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Mon, 09 Sep 2013 15:07:19 -0400 Message-ID: <1378753639.2804.1477.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:07:26 -0000 On Fri, 2013-09-06 at 14:31 -0600, Shawn M Emery wrote: > The WG is making the following consensus calls (which were formulated > from Berlin's meeting held on August 1st): > > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 > related text from the draft and continue the proceed to shepherd this as > an RFC? c. Need more information > 2. Should the WG recharter and adopt the > draft-williams-kitten-generic-naming-attributes draft? a. Yes > 3. Should the WG recharter and adopt the > draft-williams-kitten-krb5-pkcross draft? c. Need more information Simo. -- Simo Sorce * Red Hat, Inc * New York From nico@cryptonector.com Mon Sep 9 12:31:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4521E80AF for ; Mon, 9 Sep 2013 12:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbSuQA2QMBRJ for ; Mon, 9 Sep 2013 12:31:12 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CF75721E80A7 for ; Mon, 9 Sep 2013 12:31:11 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id EC1702C8094 for ; Mon, 9 Sep 2013 12:31:09 -0700 (PDT) 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=jczTOgLH1vujq2W0k9d6 MdqXal4=; b=RKLh6yr8Y+QPIkelDtCBFv2y2rWpE0fmt+MzEWy3WPtSiiduLg6T xnzzbPxXtahBjRk175xJZNjJjgg4lsBG+2FEZNJHFKxRQPsSim3Z9MTs5SoUoxFZ uBhHmQDasX1d8OpLA1p4Vg84DlJjTZ+JQU1g46X0y7L25qXe902Btt4= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id E320F2C80DD for ; Mon, 9 Sep 2013 12:25:42 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w61so4756347wes.31 for ; Mon, 09 Sep 2013 12:25:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0RxayOHWR5+cpcAHzGnVXhu8os1JiLx2MKcbR7BuMZM=; b=R3gxO48rXjnI2rEYLFgDPtahKrPFBuHsXwJBPbyEnJSMMiLAt+rTsI9Dzn4QWTWcFi L8B9tfntDHLBG0CE1ycm6CNKyT7GJlNCYvPjM9fp6rfLhSfG3jaVBoFXDHZOE8VUneEp Z9j3hHo9bf1qURDZJoyU6XjHGORiUAYgdqhljp7++bY2m79RL+7VnLqBAldv5bGOAR+D jfR8j/h7IABDoaFGfT8WrmjGYCpcFHU43CvHFEa/RqRPJJhmw7ZvEZLqfDeUlREA08lG 7PlUQiOkBiM8saCAZjW7WW++juhbZnKF6kR3rN+4GUST5TXzNU1t6dXjUKtXDQEUHMib BtpQ== MIME-Version: 1.0 X-Received: by 10.194.71.72 with SMTP id s8mr2639684wju.52.1378754740773; Mon, 09 Sep 2013 12:25:40 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 12:25:40 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 12:25:40 -0700 (PDT) In-Reply-To: <522A3B89.1010307@oracle.com> References: <522A3B89.1010307@oracle.com> Date: Mon, 9 Sep 2013 14:25:40 -0500 Message-ID: From: Nico Williams To: Shawn M Emery Content-Type: multipart/alternative; boundary=047d7bd91a048e70e204e5f85a2f Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:31:17 -0000 --047d7bd91a048e70e204e5f85a2f Content-Type: text/plain; charset=UTF-8 On Sep 6, 2013 3:30 PM, "Shawn M Emery" wrote: > > > The WG is making the following consensus calls (which were formulated from Berlin's meeting held on August 1st): > > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 related text from the draft and continue the proceed to shepherd this as an RFC? > > a. Yes > b. No > c. Don't care or need more information Yes, but that includes losing the -PLUS suffix. It's not OK to keep that suffix and not keep channel binding. > 2. Should the WG recharter and adopt the draft-williams-kitten-generic-naming-attributes draft? > > a. Yes > b. No > c. Don't care or need more information Yes. I'd pursue it as an individual submission if not accepted, fyi. It'd be silly to have published rfc6680 and then not specify any actual naming attribute. > 3. Should the WG recharter and adopt the draft-williams-kitten-krb5-pkcross draft? > > a. Yes > b. No > c. Don't care or need more information Yes. Kerberos needs at least a strong method for exchanging symmetric x-realm keys. The only implementation that provides that is AD, and only between realms in AD forests and between forests. Anyone who's been involved in manual keying or rekeying of x-realm trusts can attest to it's awfulness, and rekeying in particular is really difficult to perform without outages. Nico -- --047d7bd91a048e70e204e5f85a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 6, 2013 3:30 PM, "Shawn M Emery" <shawn.emery@oracle.com> wrote:
>
>
> The WG is making the following consensus calls (which were formulated = from Berlin's meeting held on August 1st):
>
> 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS= 2 related text from the draft and continue the proceed to shepherd this as = an RFC?
>
> a. Yes
> b. No
> c. Don't care or need more information

Yes, but that includes losing the -PLUS suffix.=C2=A0 It'= ;s not OK to keep that suffix and not keep channel binding.

> 2. Should the WG recharter and adopt the draft-williams= -kitten-generic-naming-attributes draft?
>
> a. Yes
> b. No
> c. Don't care or need more information

Yes.=C2=A0 I'd pursue it as an individual submission if = not accepted, fyi.=C2=A0 It'd be silly to have published rfc6680 and th= en not specify any actual naming attribute.

> 3. Should the WG recharter and adopt the draft-williams= -kitten-krb5-pkcross draft?
>
> a. Yes
> b. No
> c. Don't care or need more information

Yes.=C2=A0 Kerberos needs at least a strong method for excha= nging symmetric x-realm keys.=C2=A0 The only implementation that provides t= hat is AD, and only between realms in AD forests and between forests.=C2=A0= Anyone who's been involved in manual keying or rekeying of x-realm tru= sts can attest to it's awfulness, and rekeying in particular is really = difficult to perform without outages.

Nico
--

--047d7bd91a048e70e204e5f85a2f-- From hotz@jpl.nasa.gov Mon Sep 9 13:13:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0D11E813B for ; Mon, 9 Sep 2013 13:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvKg-G+SQwzB for ; Mon, 9 Sep 2013 13:13:15 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0522F21F9BFF for ; Mon, 9 Sep 2013 13:13:14 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r89KD531030140 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 9 Sep 2013 13:13:05 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: <522A3B89.1010307@oracle.com> Date: Mon, 9 Sep 2013 13:13:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522A3B89.1010307@oracle.com> To: Shawn M Emery X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:13:25 -0000 On Sep 6, 2013, at 1:31 PM, Shawn M Emery = wrote: > The WG is making the following consensus calls (which were formulated = from Berlin's meeting held on August 1st): 1) Don't care. 2) Haven't read it. 3) Yes ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From wmills@yahoo-inc.com Mon Sep 9 13:46:31 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859B21E80C4 for ; Mon, 9 Sep 2013 13:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL9QBHx6rK9a for ; Mon, 9 Sep 2013 13:46:26 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1921E80D0 for ; Mon, 9 Sep 2013 13:46:26 -0700 (PDT) Received: from GQ1-EX10-CAHT17.y.corp.yahoo.com (gq1-ex10-caht17.corp.gq1.yahoo.com [10.73.119.198]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r89KiktR063188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Sep 2013 13:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1378759487; bh=cIskOrv/MeKzwJv7x8HJ5AJw7Rjej9RDfUy5qUDVqxs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=HermvNGt5eWH1qlZNlcL9yC3awe1O83TQ4FkjwsjrHli5ObAZzpPsACUOJ/whIpQy BMNYr1eoAW1DBAifhSCLKlU6npBP/kYPOWmow15+zmcOPaJirWBa7Pu/xiJXWSLEEG XSKWh6cqnguLNK6uGsBCdU3VDydhufpomU9Ao8/s= Received: from omp1051.mail.ne1.yahoo.com (98.138.89.193) by GQ1-EX10-CAHT17.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Sep 2013 13:44:45 -0700 Received: (qmail 23532 invoked by uid 1000); 9 Sep 2013 20:44:44 -0000 Received: (qmail 73255 invoked by uid 60001); 9 Sep 2013 20:44:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1378759484; bh=5RslVFnfirbdWp3E0LghI8E2Q7lSgVos61EMhhdlYqw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cwy6XBNmrAH+cd7mIQSRemSK7TJm3YMlMcE+0AMmCcD0hepHUs5drQi0MpKrym4/WiTifKkFPiIV9jugdratGTJ5WecdLmV+OY7A1qPy3TxBmgOMvqXt1PV16xHjdvl2Y81pgdzPuWrgsKUG8bE5ThBXz3U7gwB06Y9plhS1JL0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qJbppqFLsy139E9CBeIJoy8UKieMmDEvFyWOoUK++H+/AHky9kaWMX6x7L4plmMU1NpsjuVX8PuRaeMHhHAp1MeakGzjDb1o0qZdrbqdKQfZbLDMMVNvo9buCZDr6AGcjSZ4tgnbkFHwt/SFYJLxDmE03S8nztcQgL0v5nIoUy8=; X-YMail-OSG: j9oh2oUVM1mrZ75FX3qJKx1RKTCUZiHDthRnuI_AFaM1itN woxab5TDzUuKVsBD3pkBPW_Nrd4mu4pscOeF1.tyNuhKBZ41P1WxKYxY7VM5 qF0cQ8R.XhuNyhtwraN36kCA0_xjR7NwT1ZE1dLbediKy8x1cMaZ4QWLp0fc 5OQiNjOJlcyMwgVEwZ6sQgcD9eyej6T4BzLf3AwfDVTZ0MMj8YIPWZIbgSig ybdn61gaW2xtNGaGIG1zefgOrHZZ5qaeFEzpdzNUrdXCySjTbzydd3dzGEG8 53KbUFjVsAk1xOoQ9pknd26_l Received: from [209.131.62.113] by web125605.mail.ne1.yahoo.com via HTTP; Mon, 09 Sep 2013 13:44:43 PDT X-Rocket-MIMEInfo: 002.001, Cgo.IFllcywgYnV0IHRoYXQgaW5jbHVkZXMgbG9zaW5nIHRoZSAtUExVUyBzdWZmaXguwqAgSXQncyBub3QgT0sgdG8ga2VlcCB0aGF0IHN1ZmZpeCBhbmQgbm90IGtlZXAgY2hhbm5lbCBiaW5kaW5nLgoKVGVhcmluZyBvdXQgQ0IgaXMgYSBzZXBhcmF0ZSBxdWVzdGlvbiBpbiBteSBvcGluaW9uLCBjYW4gd2UgaGF2ZSBhIHNlcGFyYXRlIGNvbnNlbnN1cyBjYWxsIG9uIHRoaXM_wqAgSSdtIG5vdCBvcHBvc2VkIHRvIGl0LCBJIGp1c3QgdGhpbmsgaXQncyBkaWZmZXJlbnQuwqAgR2l2ZW4gdGhlIHByYWN0aWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <522A3B89.1010307@oracle.com> Message-ID: <1378759483.73111.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Mon, 9 Sep 2013 13:44:43 -0700 From: Bill Mills To: Nico Williams , Shawn M Emery In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-1168886413-1378759483=:73111" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 759487000 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 09 Sep 2013 20:46:31 -0000 ---1124617404-1168886413-1378759483=:73111 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=0A> Yes, but that includes losing the -PLUS suffix.=A0 It's not OK to k= eep that suffix and not keep channel binding.=0A=0ATearing out CB is a sepa= rate question in my opinion, can we have a separate consensus call on this?= =A0 I'm not opposed to it, I just think it's different.=A0 Given the practi= cal challenges in getting the channel binding information from the current = context is the app stacks I doubt CB will in fact be implemented, so pullin= g CB has little impact I think.=0A=0AThere hasn't been a lot of movement on= the CB stuff, perhaps because no-one has actually implementing.=A0 We can = pull it and I'll help author/define it as a different draft if there's dema= nd for it later if that's what folks want.=0A=0A=0A-bill=0A=0A=0A=0A-------= -------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A= =0A=0A________________________________=0A From: Nico Williams =0ATo: Shawn M Emery =0ACc: kitten@ietf.= org =0ASent: Monday, September 9, 2013 12:25 PM=0ASubject: Re: [kitten] Con= sensus Calls=0A =0A=0A=0A=0AOn Sep 6, 2013 3:30 PM, "Shawn M Emery" wrote:=0A>=0A>=0A> The WG is making the following consens= us calls (which were formulated from Berlin's meeting held on August 1st):= =0A>=0A> 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove th= e GS2 related text from the draft and continue the proceed to shepherd this= as an RFC?=0A>=0A> a. Yes=0A> b. No=0A> c. Don't care or need more informa= tion=0AYes, but that includes losing the -PLUS suffix.=A0 It's not OK to ke= ep that suffix and not keep channel binding.=0A> 2. Should the WG recharter= and adopt the draft-williams-kitten-generic-naming-attributes draft?=0A>= =0A> a. Yes=0A> b. No=0A> c. Don't care or need more information=0AYes.=A0 = I'd pursue it as an individual submission if not accepted, fyi.=A0 It'd be = silly to have published rfc6680 and then not specify any actual naming attr= ibute.=0A> 3. Should the WG recharter and adopt the draft-williams-kitten-k= rb5-pkcross draft?=0A>=0A> a. Yes=0A> b. No=0A> c. Don't care or need more = information=0AYes.=A0 Kerberos needs at least a strong method for exchangin= g symmetric x-realm keys.=A0 The only implementation that provides that is = AD, and only between realms in AD forests and between forests.=A0 Anyone wh= o's been involved in manual keying or rekeying of x-realm trusts can attest= to it's awfulness, and rekeying in particular is really difficult to perfo= rm without outages.=0ANico=0A-- =0A________________________________________= _______=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/kitten ---1124617404-1168886413-1378759483=:73111 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=
> Yes, but that includes losing the -PLUS suffix.=   It's not OK to keep that suffix and not keep channel binding.
= =0A

Tearing out CB is a separate question in my opinion, can we hav= e a separate consensus call on this?  I'm not opposed to it, I just th= ink it's different.  Given the practical challenges in getting the cha= nnel binding information from the current context is the app stacks I doubt= CB will in fact be implemented, so pulling CB has little impact I think.
There hasn't been a lot of movement on the CB stuff, perhaps because = no-one has actually implementing.  We can pull it and I'll help author= /define it as a different draft if there's demand for it later if that's wh= at folks want.

-bill


------------------------= --------
William J. Mills
"Paranoid" Yahoo!

<= div>
From: Nico Williams <nico@cryptonector.com>
= To: Shawn M Emery <shaw= n.emery@oracle.com>
Cc:= kitten@ietf.org
Sent: Monday, September 9, 2013 12:25 PM
Subject: Re: [kitten] Consensus Calls
=


=0AOn Sep 6, 2013 3:30 PM, "Shawn M Emery" <shawn.emery@oracle.com> wrote:
=0A>=0A>
=0A> The WG is making the following consensus calls (which w= ere formulated from Berlin's meeting held on August 1st):
=0A>
=0A= > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS= 2 related text from the draft and continue the proceed to shepherd this as = an RFC?
=0A>
=0A> a. Yes
=0A> b. No
=0A> c. Don't c= are or need more information
=0A
Yes, but that include= s losing the -PLUS suffix.  It's not OK to keep that suffix and not ke= ep channel binding.
=0A
> 2. Should the WG recharte= r and adopt the draft-williams-kitten-generic-naming-attributes draft?
= =0A>
=0A> a. Yes
=0A> b. No
=0A> c. Don't care or need= more information
=0A
Yes.  I'd pursue it as an i= ndividual submission if not accepted, fyi.  It'd be silly to have publ= ished rfc6680 and then not specify any actual naming attribute.
=0A> 3. Should the WG recharter and adopt the draft-williams-= kitten-krb5-pkcross draft?
=0A>
=0A> a. Yes
=0A> b. No=0A> c. Don't care or need more information
=0A
Ye= s.  Kerberos needs at least a strong method for exchanging symmetric x= -realm keys.  The only implementation that provides that is AD, and on= ly between realms in AD forests and between forests.  Anyone who's bee= n involved in manual keying or rekeying of x-realm trusts can attest to it'= s awfulness, and rekeying in particular is really difficult to perform with= out outages.
=0A=0A
Nico
=0A--

____= ___________________________________________
Kitten mailing list
Kitten@iet= f.org
https://www.ietf.org/mailman/listinfo/kitten


---1124617404-1168886413-1378759483=:73111-- From stpeter@stpeter.im Mon Sep 9 16:41:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8B511E80FE for ; Mon, 9 Sep 2013 16:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPqxiQlfDzut for ; Mon, 9 Sep 2013 16:41:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 71BFF11E80F3 for ; Mon, 9 Sep 2013 16:41:33 -0700 (PDT) Received: from sjc-vpn2-571.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D3AC9415BA; Mon, 9 Sep 2013 17:45:55 -0600 (MDT) Message-ID: <522E5CAA.5010902@stpeter.im> Date: Mon, 09 Sep 2013 17:41:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "kitten@ietf.org" References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> In-Reply-To: <52090F96.30700@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 23:41:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear KITTEN WG, Your feedback would be appreciated on this I-D. This version incorporates the input that Alexey and I received from folks here, as well as discussion at the PRECIS WG session in Berlin: http://www.ietf.org/proceedings/87/minutes/minutes-87-precis One question in particular regarding preparation of usernames, especially for Nico since he suggested the original text... Version -03 said: 3. Uppercase and titlecase characters MAY be mapped to their lowercase equivalents. In version -04, based on PRECIS WG discussion, we changed that to: 3. Uppercase and titlecase characters SHOULD be mapped to their lowercase equivalents (not doing so can lead to false positives during authentication and authorization, as described in [RFC6943]). The rationale was that we really don't want to give people a gun to shoot themselves with. Some folks in the PRECIS WG session leaned even to "MUST" here, but SHOULD with an explanation of the consequences was a compromise position. In any case, the original MAY seemed way too weak to folks in the PRECIS WG. Please let us know if you have grave concerns about the text in -04. Thanks! Peter On 8/12/13 10:38 AM, Peter Saint-Andre wrote: > FYI. > > > -------- Original Message -------- Subject: Re: [precis] I-D > Action: draft-ietf-precis-saslprepbis-04.txt Date: Sun, 04 Aug 2013 > 18:06:49 -0600 From: Peter Saint-Andre To: > precis@ietf.org > > Changes to address discussion in the WG session on Friday. I did > this work in airports and on planes today, so I would not be > surprised if the text isn't perfect... > > On 8/4/13 6:04 PM, 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 >> Preparation and Comparison of Internationalized Strings Working >> Group of the IETF. >> >> Title : Preparation and Comparison of Internationalized >> Strings Representing Usernames and Passwords Author(s) : >> Peter Saint-Andre Alexey Melnikov Filename : >> draft-ietf-precis-saslprepbis-04.txt Pages : 14 Date >> : 2013-08-04 >> >> Abstract: This document describes how to handle Unicode strings >> representing usernames and passwords. This profile is intended >> to be used by protocols that exchange or otherwise make use of >> usernames and passwords. This document obsoletes RFC 4013. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-04 >> >> >> >> 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/ >> >> _______________________________________________ precis mailing >> list precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLlyqAAoJEOoGpJErxa2p6m0P/09pVQmkl2PDY/KeFm45RJzt FsnQAkhZ86ufTFRp96NgLIKn0+SSS6Zu+xVii7Hxq/vPYxFHfNYfGDoaQik8gjJ8 7Jg37HKGexu9iEFQ9R81sPTE543zv+xNrORi/599cAv8SrRcpMJTZ7Cotks9alN5 lSTylojR/czKrvg/6iHCHwPEkwDqxIM4RCXamUrrS54yhvlT2/mEFt2e83CAxDck tk9L0cIdcLhYilAJO74VxT+T7ED+G03s52CKCNk8gOi9peVLYvjW0RidKaCqLdoJ /2xd4NBAaCN3qzZls2cqTZcGZ5RTE3SjdSU0MYeQJpeiDzkQc2D7+yOOvd8jNi6l f86YdH1ANNwluB8PbT/juZtXo0x1v2A1U0bRfebNku6op9WXrvzO037AoO/yUut2 c7UjAVKkb7LlMgMh47AsSo+qhEc22KvKasi7ByIo4Wgt5JaaYmP2L/C2quNRY1Bm d+OGyWGVKHECfYPSXKpRrEoqI6oaKoCGj8rZGhyaTpXKfYQmUcFJagteriMmQhW+ zWQMqUNWN6zkh5N7kftkRBkPs/dh0sfaMvWMhw4H7upKmuzl04GZjPsGUUd28B5Y 0F99DZvak5oSgvweulJFC9y8Pi1B8N8jhMbKaS4zimgLYypKdGUEwp22+4bWxvTC jVamJg7WkcgwnoF6j7Wc =1h8a -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Sep 9 17:36:00 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CFF21E8063 for ; Mon, 9 Sep 2013 17:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NATfDMj21o1 for ; Mon, 9 Sep 2013 17:35:55 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 684A721E805D for ; Mon, 9 Sep 2013 17:35:55 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 05AD91DE059 for ; Mon, 9 Sep 2013 17:35:55 -0700 (PDT) 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=OHy1B5al7ud2aZNAAMwz x7P9Kjs=; b=Pmg3Fr/KzUr1/knTM2Nj6m2J4wZL9qJ8BsdzMn8JJe7jr1GwyPUS c7Qd3zrA4PKPzp/SYtErulh1pEcUJMLzmR7KcYbI4DUV0aGThYtuvS/xHVfJdNnU 3T/EvVKgQREf2p3FFZ5tqdKOoZp/V7dG/5OYSQYyr1w7GM7AoHHElX0= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 9C5DD1DE058 for ; Mon, 9 Sep 2013 17:35:54 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id j13so5967530wgh.17 for ; Mon, 09 Sep 2013 17:35:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q9wC7I+Iw8RN7ySZZpKKPYu/pDvBIwh51+iOBkp797k=; b=f7ufgIkJjYO0JNxsItRUrKinrwH0IzJ3Io5HSdclfc0DHWQ3nECFzrTpDJZqlJpADK Aw4bOOiINe34ZpSFAgcB+X7AO0j4dpmE2k9//fbRunMhvqTdzlCc5m60FsJH5e5B5bW7 c2cDLfjQWBdquMMT5jlA50vR1Gx8fVgAYaYzVhDE3qhXE8+3q2+/toNtho3Lw08Qlhp7 /ky3I4djNRhUjSKqXzHwtEsjHSCXDBy8AsDjoPIacI9CHRavb2TzxtkkqAUUfMVaUuS2 q8t7R7yJ9Xv1vUa9qbRefIfefLkVOrZOcyJN1S+vHAY94vLCewTBmVg93LfqHbSFBCmm l4+Q== MIME-Version: 1.0 X-Received: by 10.180.20.42 with SMTP id k10mr11186670wie.0.1378773353296; Mon, 09 Sep 2013 17:35:53 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 17:35:53 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 17:35:53 -0700 (PDT) In-Reply-To: <522E5CAA.5010902@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> Date: Mon, 9 Sep 2013 19:35:53 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=bcaec53f3959f2fa9204e5fcafc1 Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 00:36:00 -0000 --bcaec53f3959f2fa9204e5fcafc1 Content-Type: text/plain; charset=UTF-8 So.... I've to subscribe to precis and go have the same discussion there that we had here? In few days, i guess. I'm traveling today. --bcaec53f3959f2fa9204e5fcafc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So.... I've to subscribe to precis and go have the same = discussion there that we had here?=C2=A0 In few days, i guess.=C2=A0 I'= m traveling today.

--bcaec53f3959f2fa9204e5fcafc1-- From stpeter@stpeter.im Mon Sep 9 17:39:20 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A970021E8063 for ; Mon, 9 Sep 2013 17:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-CBb525P2gz for ; Mon, 9 Sep 2013 17:39:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 63DEA21E805D for ; Mon, 9 Sep 2013 17:39:14 -0700 (PDT) Received: from sjc-vpn2-571.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F154C415BC; Mon, 9 Sep 2013 18:43:35 -0600 (MDT) Message-ID: <522E6A2E.9050704@stpeter.im> Date: Mon, 09 Sep 2013 18:39:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 00:39:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/13 6:35 PM, Nico Williams wrote: > So.... I've to subscribe to precis and go have the same discussion > there that we had here? Nope, I'm bringing the discussion here to make it easy for you. But feel free to cross-post if you'd like (it's not necessary to subscribe in order to post, per IETF policy). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLmouAAoJEOoGpJErxa2pUuEP/3zux4n3US1ED2ythCVCZ3FQ V0G+E3G5d2G8WoCaoozNcUcPpyHewKWPzYAmVQc6mZCRJrn9AaiamQxDry7VVqKo iiqDaPftcG9TP62pz3kw689sAzw8HWx7LBEHNkyxy8VeMx2wyLNBa3Qg5n/2vRMJ zxYpfXsuO7FgPTbOp3EhSeGJqYfE6EkmGTcsi7jO8Y2QZIffM6to1UPF6iJfmBBN K6huQAoQOmaV7klTIWfL78QR2/N8WReg0VDDQhGxu+0Tz5m5LZCCYbGJK9iKZBQg V8wMZog6Lk8ROTtc24Z/KHWHqjxWkG4saFQdsU1o0kB1YXkD3g58Ac8LamhuRRY5 LrdITmZLUliZh616TKSVwWj7e3bQEiUZ5RFWxRq8cyXoS4kCXq6ck5iLokq1UfJa i4VcESkgXZYu9O+Rx+FGxmQEkMoXKVNxhByH3Sg0TYs+2jEBNVIU0NDbxWJ+L1XS ZJ8m69tD3tNjuVRKlTmMObylxb7MCEld7OthCOtrXzSvXczp53ZgoqJ0bcxdehdZ wZQIQ1H61EHXDm+sPHFKv5Y63/aRrWMEMMfEZ9HT6TYrH4zV+xiW0Dv8lOB+MY88 2ty6GlX+ZEFN5G7DVQcpNoxfr8ggrKWS72MRaiHQmQljMEdDcXmJtsP40ZiNNHgT KVLfhFJ0Jtr539F+JmAm =eJSQ -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Sep 10 07:06:36 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076EA21E8051; Tue, 10 Sep 2013 07:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDkXJbUajmlA; Tue, 10 Sep 2013 07:06:31 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0521F9FB3; Tue, 10 Sep 2013 07:06:26 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id D21AA264085; Tue, 10 Sep 2013 07:06:24 -0700 (PDT) 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=zLYq7gI5eip8EI+yPnoT Dkl4Z1A=; b=PdXkC8iDaTbsHE0b5+8Hs+jdSFbAQQWAlHcQ0Ymcb/2Ps6GkJ/6Q 7reqQIMxLdK0AgWQKLHmcWuhdMES4o2o5p1Qbj3/jZOR7va5SRxZF1FI67WXnDWB z0De+gCT2hGPYdKe/7jhE6GFbVsNsiCf96C2G7PwtcRvvTY0BOuCUn8= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id CBBE6264087; Tue, 10 Sep 2013 07:06:23 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so5687517wes.10 for ; Tue, 10 Sep 2013 07:06:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=igeK5CRE2xg2wkVreP47WXTipvIRetPBa6OITIxfTTI=; b=aodPs3IgXmPWsIFxIVR7OUbmJM/raK/9Hk09i+EVJb4MMjoSKYhp93bBh4Nvavx5ez 87NalKZyHWSuLoehi3CFre8L/M2fa25pzF8+U/YCrATEeVRK35wsqRKFz76Hs0f/03dt rUvTu4LsKBc0qBteLNn9gEe9ojQXQNC7UlGCb1ge6RjjF5ZzLlGBbacwcq8hhf+dcRt4 56e6k9SSHMfUjUmq75ooOd+UUuHUhm2xtfjuGSq5hfNsifX/S87OfVHIx/cmldMlKvgd Br3ufRab/GWR6bJrtV/E6SAzTJ5QtAfeFGfKIKoHB1NLCI/kuJv+gqAxcFW0XZzw0VgE FrNg== MIME-Version: 1.0 X-Received: by 10.194.48.74 with SMTP id j10mr2651242wjn.41.1378821980992; Tue, 10 Sep 2013 07:06:20 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 10 Sep 2013 07:06:20 -0700 (PDT) In-Reply-To: <522E5CAA.5010902@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> Date: Tue, 10 Sep 2013 09:06:20 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=047d7ba975c862f67104e6080227 Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:06:36 -0000 --047d7ba975c862f67104e6080227 Content-Type: text/plain; charset=UTF-8 On Monday, September 9, 2013, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear KITTEN WG, > > Your feedback would be appreciated on this I-D. This version > incorporates the input that Alexey and I received from folks here, as > well as discussion at the PRECIS WG session in Berlin: > > http://www.ietf.org/proceedings/87/minutes/minutes-87-precis > > One question in particular regarding preparation of usernames, > especially for Nico since he suggested the original text... > > Version -03 said: > > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > In version -04, based on PRECIS WG discussion, we changed that to: > > 3. Uppercase and titlecase characters SHOULD be mapped to their > lowercase equivalents (not doing so can lead to false positives > during authentication and authorization, as described in > [RFC6943]). > > The rationale was that we really don't want to give people a gun to > shoot themselves with. Some folks in the PRECIS WG session leaned even > to "MUST" here, but SHOULD with an explanation of the consequences was > a compromise position. In any case, the original MAY seemed way too > weak to folks in the PRECIS WG. Please let us know if you have grave > concerns about the text in -04. > This is the third time, I think, that I've had to voice my vehement objections to this. I thought we were done the second time. I believe SASL applications and mechanisms MUST NOT do the above, not on the client side, and that the server should be allowed to do what it wishes. The only exception is for password (and salt) processing in DIGEST/SCRAM-like mechanisms where keys are derived from passwords on the client- (and server-) sides, therefore canonical password representations are desirable, and even then, case folding would be nothing short of -- and I must be utterly frank here-- stupid, as it means dropping entropy needlessly. The argument I made before was that we need to distinguish between query, display, and storage strings. If a username must be canonicalized then this should be done where it must be used as a databased/directory lookup key or as a cryptographic salt (where roughly the same considerations as for passwords used to derive keys apply). We should delay canonicalization as much as possible so as to support the server operator's choice of canonicalization. I've mentioned before that many online games allow all sorts of username forms that we'd consider silly in an enterprise environment, but in online gaming they are quite desirable as a form of styling. Let's not put a straightjacket on users of this string preparation -- let each operator pick their poison as much as possible. The RFC6943 reference should be more specific. What specific confusion cases are we worried about? Please have this argument on the KITTEN WG list. I'm cc'ing precis@ietf.orgjust this once, and I will not subscribe to it. We've had at least two debates on SASLprep-bis at KITTEN. Nico -- --047d7ba975c862f67104e6080227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, September 9, 2013, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear KITTEN WG,

Your feedback would be appreciated on this I-D. This version
incorporates the input that Alexey and I received from folks here, as
well as discussion at the PRECIS WG session in Berlin:

http://www.ietf.org/proceedings/87/minutes/minutes-87-preci= s

One question in particular regarding preparation of usernames,
especially for Nico since he suggested the original text...

Version -03 said:

=C2=A0 =C2=A03. =C2=A0Uppercase and titlecase characters MAY be mapped to t= heir
=C2=A0 =C2=A0 =C2=A0 =C2=A0lowercase equivalents.

In version -04, based on PRECIS WG discussion, we changed that to:

=C2=A0 =C2=A03. =C2=A0Uppercase and titlecase characters SHOULD be mapped t= o their
=C2=A0 =C2=A0 =C2=A0 =C2=A0lowercase equivalents (not doing so can lead to = false positives
=C2=A0 =C2=A0 =C2=A0 =C2=A0during authentication and authorization, as desc= ribed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6943]).

The rationale was that we really don't want to give people a gun to
shoot themselves with. Some folks in the PRECIS WG session leaned even
to "MUST" here, but SHOULD with an explanation of the consequence= s was
a compromise position. In any case, the original MAY seemed way too
weak to folks in the PRECIS WG. Please let us know if you have grave
concerns about the text in -04.

This is the third time, I think, that I= 9;ve had to voice my vehement objections to this. =C2=A0I thought we were d= one the second time. =C2=A0I believe SASL applications and mechanisms MUST = NOT do the above, not on the client side, and that the server should be all= owed to do what it wishes. =C2=A0The only exception is for password (and sa= lt)=C2=A0processing in DIGEST/SCRAM-like mechanisms where keys are derived = from passwords on the client- (and server-) sides,=C2=A0therefore=C2=A0cano= nical password representations are desirable, and even then, case folding w= ould be nothing short of -- and I must be utterly frank here-- stupid, as i= t means dropping entropy needlessly.

The argument I made before was that we need to distingu= ish between query, display, and storage strings. =C2=A0If a username must b= e canonicalized then this should be done where it must be used as a databas= ed/directory lookup key or as a cryptographic salt (where roughly the same = considerations as for passwords used to derive keys apply). =C2=A0We should= delay canonicalization as much as possible so as to support the server ope= rator's choice of canonicalization. =C2=A0I've mentioned before tha= t many online games allow all sorts of username forms that we'd conside= r silly in an enterprise environment, but in online gaming they are quite d= esirable as a form of styling. =C2=A0Let's not put a straightjacket on = users of this string preparation -- let each operator pick their poison as = much as possible.

The RFC6943 reference should be more specific. =C2=A0Wh= at specific confusion cases are we worried about?
Please have this argument on the KITTEN WG list. =C2=A0I'm= cc'ing precis@ietf.org just thi= s once, and I will not subscribe to it. =C2=A0We've had at least two de= bates on=C2=A0SASLprep-bis at KITTEN.

Nico
--=C2=A0 --047d7ba975c862f67104e6080227-- From alexey.melnikov@isode.com Wed Sep 11 02:55:45 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFF911E8188 for ; Wed, 11 Sep 2013 02:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q86mZupKPxk8 for ; Wed, 11 Sep 2013 02:55:40 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5508321E80BD for ; Wed, 11 Sep 2013 02:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1378893332; d=isode.com; s=selector; i=@isode.com; bh=7bcuT+Ksh2fS8z4bo17HoVtGFr7suvt3V4LsQOFXsa8=; 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=jEM+JmCD7yJED6Tq1zp0kFfBK3l3oXr3cjXBA5tsW1SWTyu22bg0B7jaQZpO+aVH/ak8DJ R5GwY91lbHOwHt5bVAxrmEUL1q6XiCwSypJfqBdEo0GuC4dUGkqqChrUZZTGtQIYKJ24kF 9IMJ4XdCNp1zWW2cJzeK85B8CjNUrT0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Sep 2013 10:55:32 +0100 Message-ID: <52303E16.8010801@isode.com> Date: Wed, 11 Sep 2013 10:55:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Bill Mills References: <522A3B89.1010307@oracle.com> <1378759483.73111.YahooMailNeo@web125605.mail.ne1.yahoo.com> In-Reply-To: <1378759483.73111.YahooMailNeo@web125605.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090109020204030506060107" Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 09:55:45 -0000 This is a multi-part message in MIME format. --------------090109020204030506060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/09/2013 21:44, Bill Mills wrote: > > > Yes, but that includes losing the -PLUS suffix. It's not OK to keep > that suffix and not keep channel binding. > > Tearing out CB is a separate question in my opinion, can we have a > separate consensus call on this? I'm not opposed to it, I just think > it's different. Given the practical challenges in getting the channel > binding information from the current context is the app stacks I doubt > CB will in fact be implemented, so pulling CB has little impact I think. > > There hasn't been a lot of movement on the CB stuff, perhaps because > no-one has actually implementing. We can pull it and I'll help > author/define it as a different draft if there's demand for it later > if that's what folks want. I can tell you that we (Isode) implemented TLS channel binding using Cyrus SASL and openssl in both our clients and servers. So channel binding support in the OAuth mechanism are of interest to us. > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > ------------------------------------------------------------------------ > *From:* Nico Williams > *To:* Shawn M Emery > *Cc:* kitten@ietf.org > *Sent:* Monday, September 9, 2013 12:25 PM > *Subject:* Re: [kitten] Consensus Calls > > > On Sep 6, 2013 3:30 PM, "Shawn M Emery" > wrote: > > > > > > The WG is making the following consensus calls (which were > formulated from Berlin's meeting held on August 1st): > > > > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the > GS2 related text from the draft and continue the proceed to shepherd > this as an RFC? > > > > a. Yes > > b. No > > c. Don't care or need more information > Yes, but that includes losing the -PLUS suffix. It's not OK to keep > that suffix and not keep channel binding. > > 2. Should the WG recharter and adopt the > draft-williams-kitten-generic-naming-attributes draft? > > > > a. Yes > > b. No > > c. Don't care or need more information > Yes. I'd pursue it as an individual submission if not accepted, fyi. > It'd be silly to have published rfc6680 and then not specify any > actual naming attribute. > > 3. Should the WG recharter and adopt the > draft-williams-kitten-krb5-pkcross draft? > > > > a. Yes > > b. No > > c. Don't care or need more information > Yes. Kerberos needs at least a strong method for exchanging symmetric > x-realm keys. The only implementation that provides that is AD, and > only between realms in AD forests and between forests. Anyone who's > been involved in manual keying or rekeying of x-realm trusts can > attest to it's awfulness, and rekeying in particular is really > difficult to perform without outages. > Nico > -- --------------090109020204030506060107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/09/2013 21:44, Bill Mills wrote:

> Yes, but that includes losing the -PLUS suffix.  It's not OK to keep that suffix and not keep channel binding.

Tearing out CB is a separate question in my opinion, can we have a separate consensus call on this?  I'm not opposed to it, I just think it's different.  Given the practical challenges in getting the channel binding information from the current context is the app stacks I doubt CB will in fact be implemented, so pulling CB has little impact I think.

There hasn't been a lot of movement on the CB stuff, perhaps because no-one has actually implementing.  We can pull it and I'll help author/define it as a different draft if there's demand for it later if that's what folks want.

I can tell you that we (Isode) implemented TLS channel binding using Cyrus SASL and openssl in both our clients and servers. So channel binding support in the OAuth mechanism are of interest to us.

-bill


--------------------------------
William J. Mills
"Paranoid" Yahoo!


From: Nico Williams <nico@cryptonector.com>
To: Shawn M Emery <shawn.emery@oracle.com>
Cc: kitten@ietf.org
Sent: Monday, September 9, 2013 12:25 PM
Subject: Re: [kitten] Consensus Calls


On Sep 6, 2013 3:30 PM, "Shawn M Emery" <shawn.emery@oracle.com> wrote:
>
>
> The WG is making the following consensus calls (which were formulated from Berlin's meeting held on August 1st):
>
> 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 related text from the draft and continue the proceed to shepherd this as an RFC?
>
> a. Yes
> b. No
> c. Don't care or need more information
Yes, but that includes losing the -PLUS suffix.  It's not OK to keep that suffix and not keep channel binding.
> 2. Should the WG recharter and adopt the draft-williams-kitten-generic-naming-attributes draft?
>
> a. Yes
> b. No
> c. Don't care or need more information
Yes.  I'd pursue it as an individual submission if not accepted, fyi.  It'd be silly to have published rfc6680 and then not specify any actual naming attribute.
> 3. Should the WG recharter and adopt the draft-williams-kitten-krb5-pkcross draft?
>
> a. Yes
> b. No
> c. Don't care or need more information
Yes.  Kerberos needs at least a strong method for exchanging symmetric x-realm keys.  The only implementation that provides that is AD, and only between realms in AD forests and between forests.  Anyone who's been involved in manual keying or rekeying of x-realm trusts can attest to it's awfulness, and rekeying in particular is really difficult to perform without outages.
Nico
--

--------------090109020204030506060107-- From simon@josefsson.org Wed Sep 11 10:39:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275B421F9DD5; Wed, 11 Sep 2013 10:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am7Qe1vo5eEn; Wed, 11 Sep 2013 10:39:17 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 254B521F99FA; Wed, 11 Sep 2013 10:39:12 -0700 (PDT) Received: from latte.josefsson.org ([38.111.151.140]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8BHcsa0005363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Sep 2013 19:39:01 +0200 From: Simon Josefsson To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130911:precis@ietf.org::pmZoj4jn9s3KfZUb:Yzz X-Hashcash: 1:22:130911:kitten@ietf.org::V7In9ys8HsRFb3nD:35zv X-Hashcash: 1:22:130911:stpeter@stpeter.im::mFPkDl4896RoaJTC:3hSf X-Hashcash: 1:22:130911:nico@cryptonector.com::pKjQKysJ/Q5E4zeb:3T7P Date: Wed, 11 Sep 2013 10:38:48 -0700 In-Reply-To: (Nico Williams's message of "Tue, 10 Sep 2013 09:06:20 -0500") Message-ID: <87bo3zi7h3.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 17:39:18 -0000 Nico Williams writes: >> In version -04, based on PRECIS WG discussion, we changed that to: >> >> 3. Uppercase and titlecase characters SHOULD be mapped to their >> lowercase equivalents (not doing so can lead to false positives >> during authentication and authorization, as described in >> [RFC6943]). >> > > This is the third time, I think, that I've had to voice my vehement > objections to this. I thought we were done the second time. I believe > SASL applications and mechanisms MUST NOT do the above, not on the client > side, and that the server should be allowed to do what it wishes. If the text above would have any bearing on SASL implementations (which isn't clear to me), I would strongly agree with you that the text above is a Bad Idea. Generally, I believe the use-case of I18N of username & password have special requirements that have been ignored by the PRECIS WG because the username/password requirements are sometimes conflicting with other goals of PRECIS and there doesn't seem to be enough interest to cater to both communities at the same time. Perhaps that is fine (I understand PRECIS wants to publish), but then it should be made clear that PRECIS will have no immediate bearing on SASLprepNG. /Simon From stpeter@stpeter.im Wed Sep 11 11:04:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0488111E80D2; Wed, 11 Sep 2013 11:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qObl8-gakgar; Wed, 11 Sep 2013 11:04:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8221F9CB6; Wed, 11 Sep 2013 11:04:09 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3EAEC206F2; Wed, 11 Sep 2013 12:08:37 -0600 (MDT) Message-ID: <5230B096.4090303@stpeter.im> Date: Wed, 11 Sep 2013 12:04:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:04:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/13 8:06 AM, Nico Williams wrote: > On Monday, September 9, 2013, Peter Saint-Andre wrote: > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Dear KITTEN WG, > > Your feedback would be appreciated on this I-D. This version > incorporates the input that Alexey and I received from folks here, > as well as discussion at the PRECIS WG session in Berlin: > > http://www.ietf.org/proceedings/87/minutes/minutes-87-precis > > One question in particular regarding preparation of usernames, > especially for Nico since he suggested the original text... > > Version -03 said: > > 3. Uppercase and titlecase characters MAY be mapped to their > lowercase equivalents. > > In version -04, based on PRECIS WG discussion, we changed that to: > > 3. Uppercase and titlecase characters SHOULD be mapped to their > lowercase equivalents (not doing so can lead to false positives > during authentication and authorization, as described in > [RFC6943]). > > The rationale was that we really don't want to give people a gun > to shoot themselves with. Some folks in the PRECIS WG session > leaned even to "MUST" here, but SHOULD with an explanation of the > consequences was a compromise position. In any case, the original > MAY seemed way too weak to folks in the PRECIS WG. Please let us > know if you have grave concerns about the text in -04. > > > This is the third time, I think, that I've had to voice my > vehement objections to this. I thought we were done the second > time. Hi Nico, I don't think vehemence is needed. We have some different perspectives, and we're trying to find common ground. Would you perhaps have time to listen to the recording of the PRECIS WG session in Berlin? Also, would you be available for a phone conference on this topic so that we can work through it in closer to real time? Or might you be coming to the IETF meeting in Vancouver? I'm out of time for the moment but I will reply at greater length soon. (I include the rest of your message below because I have not yet seen it arrive on the PRECIS list....) > I believe SASL applications and mechanisms MUST NOT do the above, > not on the client side, and that the server should be allowed to do > what it wishes. The only exception is for password (and salt) > processing in DIGEST/SCRAM-like mechanisms where keys are derived > from passwords on the client- (and server-) sides, therefore > canonical password representations are desirable, and even then, > case folding would be nothing short of -- and I must be utterly > frank here-- stupid, as it means dropping entropy needlessly. > > The argument I made before was that we need to distinguish between > query, display, and storage strings. If a username must be > canonicalized then this should be done where it must be used as a > databased/directory lookup key or as a cryptographic salt (where > roughly the same considerations as for passwords used to derive > keys apply). We should delay canonicalization as much as possible > so as to support the server operator's choice of canonicalization. > I've mentioned before that many online games allow all sorts of > username forms that we'd consider silly in an enterprise > environment, but in online gaming they are quite desirable as a > form of styling. Let's not put a straightjacket on users of this > string preparation -- let each operator pick their poison as much > as possible. > > The RFC6943 reference should be more specific. What specific > confusion cases are we worried about? > > Please have this argument on the KITTEN WG list. I'm cc'ing > precis@ietf.org just this once, and I will > not subscribe to it. We've had at least two debates on > SASLprep-bis at KITTEN. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMLCWAAoJEOoGpJErxa2pcm0P/0ZP8jvkfVRJPmoqYn8wUIBm v+R4nJFlCDsrjpI/RowNhbovYb2pdbRfaAeR+P3Z1FDLe/vRb2itau5v3Dqp/sC1 rAEsddMZI1IAEDLQL5y2w8W8g9kIyd8qQ//oMoLjflYjO2yhM/QFlEvhSDVyanVn UdZ+m2VWZWupGfhmM+xtFyQ1VS9JjzOK6OI0z6eEs3laIZPbi9FFBUZahMeV180q P3chjmq3OYn5wAYCBlTNlp+IKQbB2F/whobn8n668oRqx1MrPpu11nwJQAVeLQiv th3pCicWw7EbLePPu9lRD88n0n+aWfDvJfffeKUE/aARcYHbsWakj8U0+1p+T8AH r8sTVRMW7YdKQiFqx2ftDfGV+GLUy6lsJa5/ah6KqWqHWxZnHVOAnuW950/y3Oyq lQEDMTwl0I+FEdqsWGwNih+XzDjF4ZmGKyENqejmUPXgvDF8c0Bf5NqBxXdtm1qB apbbPcJgWiXIWFYvwjRPfs0NTs06fmbvf+QF34ylf7UihS6D4o8w1SXiKn/FUwOl VTH6FOlaYBoK/S3ZVFlFuC9cibe/c/EW2kAVFWdgTqt6Dl/A39Bor5BplU9zy3K9 Pm0RHDH776uOMIzhYKK4x//1oE318BHwMR4+qPA65u7wWREjMzZ0ETkPxMwioMVf tFcRAQsgxXCXJTqdMwwa =RXpe -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Sep 11 11:07:41 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8CA11E8105; Wed, 11 Sep 2013 11:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1m1-tRur+kN; Wed, 11 Sep 2013 11:07:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F34B521E808E; Wed, 11 Sep 2013 11:07:35 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B141941640; Wed, 11 Sep 2013 12:12:03 -0600 (MDT) Message-ID: <5230B165.2030202@stpeter.im> Date: Wed, 11 Sep 2013 12:07:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <87bo3zi7h3.fsf@latte.josefsson.org> In-Reply-To: <87bo3zi7h3.fsf@latte.josefsson.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:07:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/11/13 11:38 AM, Simon Josefsson wrote: > Nico Williams writes: > >>> In version -04, based on PRECIS WG discussion, we changed that >>> to: >>> >>> 3. Uppercase and titlecase characters SHOULD be mapped to >>> their lowercase equivalents (not doing so can lead to false >>> positives during authentication and authorization, as described >>> in [RFC6943]). >>> >> >> This is the third time, I think, that I've had to voice my >> vehement objections to this. I thought we were done the second >> time. I believe SASL applications and mechanisms MUST NOT do the >> above, not on the client side, and that the server should be >> allowed to do what it wishes. > > If the text above would have any bearing on SASL implementations > (which isn't clear to me), I would strongly agree with you that the > text above is a Bad Idea. > > Generally, I believe the use-case of I18N of username & password > have special requirements that have been ignored by the PRECIS WG > because the username/password requirements are sometimes > conflicting with other goals of PRECIS and there doesn't seem to be > enough interest to cater to both communities at the same time. > Perhaps that is fine (I understand PRECIS wants to publish), but > then it should be made clear that PRECIS will have no immediate > bearing on SASLprepNG. Hi Simon, Actually that text comes from draft-ietf-precis-saslprepbis: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-04#section-4.2 As I noted to Nico, we need to get this right and we need to take the time to do so. Alexey and I are committed to doing that, and we'll find a way to make it happen. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMLFkAAoJEOoGpJErxa2pfv4P/Roq3J1EiaVyQVBErahCX8Lz b1HoYUgq0DfMYcTQtf69U8+MA9CFklaJiPOnaiWwZ0Wy7cXNTMMvNSBbDOFkbpiS y0pgc6Y2mel2WRwlAgAjX45SB4cfSiAEToFeG8LBST8a5hpd5Bd6zTJFaY/vOQFX e0yR99BpuPKy7DH9VGauWxFMGDOmTWo42YmBkcREwPbuuqdGttFgOqSRUxPDsQiS VNdkfWygOKunZtRa5iV6dBsloCcZLuuQBjD7iw2tjeP6cEI85mKB+QruBY4V5n/0 Bff1YkwKAaKeR2GQfz1UZMqzFy/1Ko9SmoXiW+Cvt/utY1eqqD+9VPN5lg95IU4u GrgxBT38DJmhvR0FuaFb6QKJDRVPWZG9mppj7Y8Qt/LZeZPvyvyDLKr1TBf7iMKz QLU0Osak+2YGTVXKAFCv30522IgVMcTH54GSX99Ej+CDYbJEiqK9F1FmZBl1wNko Pn9eHF31frZY4DaiLSQMyEws0p2a4CvqmBU03EPKE62J/tR7EoZSgB8cv2Dkuh1O tAvZQ4cAHR2LLl3r7nHGcuFkqQiXACh+vYC52Xogl+GxfMFfGlvooKd80TakuJt9 9OYm0ojltWihVL+bJTriIAB3ZjtxkmPMaXKNNHya7emX9tOX2MQaYS8edpwPTpL/ LTOHtJGqsBM+k2LcaZ7Z =Gat7 -----END PGP SIGNATURE----- From florob@babelmonkeys.de Wed Sep 11 11:17:26 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8933211E80D7; Wed, 11 Sep 2013 11:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk2cs050BQAk; Wed, 11 Sep 2013 11:17:26 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by ietfa.amsl.com (Postfix) with ESMTP id EBF5011E8112; Wed, 11 Sep 2013 11:17:25 -0700 (PDT) Received: from [2001:4dd0:ff00:9359:3e97:eff:fe0f:f4d] by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VJp05-0007lK-D6; Wed, 11 Sep 2013 20:18:49 +0200 Message-ID: <5230B3B3.3040805@babelmonkeys.de> Date: Wed, 11 Sep 2013 20:17:23 +0200 From: Florian Zeitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] [precis] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:17:26 -0000 Am 10.09.2013 16:06, schrieb Nico Williams: > This is the third time, I think, that I've had to voice my vehement > objections to this. I thought we were done the second time. I believe > SASL applications and mechanisms MUST NOT do the above, not on the > client side, and that the server should be allowed to do what it wishes. > The only exception is for password (and salt) processing in > DIGEST/SCRAM-like mechanisms where keys are derived from passwords on > the client- (and server-) sides, therefore canonical password > representations are desirable, and even then, case folding would be > nothing short of -- and I must be utterly frank here-- stupid, as it > means dropping entropy needlessly. > > The argument I made before was that we need to distinguish between > query, display, and storage strings. If a username must be > canonicalized then this should be done where it must be used as a > databased/directory lookup key or as a cryptographic salt (where roughly > the same considerations as for passwords used to derive keys apply). We > should delay canonicalization as much as possible so as to support the > server operator's choice of canonicalization. I've mentioned before > that many online games allow all sorts of username forms that we'd > consider silly in an enterprise environment, but in online gaming they > are quite desirable as a form of styling. Let's not put a > straightjacket on users of this string preparation -- let each operator > pick their poison as much as possible. > I'm a bit confused. My impression is that the draft already contains text very much in that spirit: « SASL mechanisms that directly re-use this profile MUST specify whether and when case mapping is to be applied to authentication identifiers. SASL mechanisms SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. In keeping with RFC4422, SASL mechanisms are not to apply this or any other profile to authorization identifiers. » While online games might not always want case folded strings, I doubt having two usernames that differ only in case is ever desirable. From nico@cryptonector.com Wed Sep 11 21:02:30 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0921F9E04; Wed, 11 Sep 2013 21:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbhUx8zp8Aib; Wed, 11 Sep 2013 21:02:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1C21F9D92; Wed, 11 Sep 2013 21:02:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 2AEA821DE65; Wed, 11 Sep 2013 21:02:25 -0700 (PDT) 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=QKK8Llcr+ibG/P5wT47J tkBl4/A=; b=sHZBNJWyyuM5bMlGuGXBQquWUgPM0fZWtmMCNqkSUDT7HZimKfPA l/gmlErsgUAyJz7ET0XN7FEP1y1zm0SxYVd49ZmbVCk82vKg62EUa/TQW7w8dxmM w+06CEuyHsJJ86nbB2x0ijBhIUHoxFCa+Zi73zW38lZ0PvzW7MKGcmo= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id A32D621DE57; Wed, 11 Sep 2013 21:02:24 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so8849701wes.14 for ; Wed, 11 Sep 2013 21:02:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y+vqcwtchrJSNhZJLSpB0c3PHKx8+7ZeSbzrhYYDJNA=; b=labGa/sdAJlkUHuKMJU0RzkKizDo+U74amSNzs0iZ9Id18+RysOWY0ahxUGzYdthcW yUX3thcj3uHaC2P5M2pp2Gu3PBUEczMF5edDMcnIf/WJUqNkGB5CPBkpzgjFwbXTzs6/ gnGuVWwNYSxUGK6yU00i88I3X7X6yfsQ2GZQKYQzUhPEUhgLosTU5LcO8lKdbAW2haOU E9zCoFLGAYUiht7zSu9kh1+EGh+85Q/rqnyroCE0hd9CS9MlBavja8E2xSABGEeUDsZc pXnIU4QaKTlBD6NXE8H4GVPClkWORh/TYAIt1mw3kgUNf655C4U+hNZel+FcedvOBvSi QDpA== MIME-Version: 1.0 X-Received: by 10.180.206.244 with SMTP id lr20mr3943327wic.45.1378958541797; Wed, 11 Sep 2013 21:02:21 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Wed, 11 Sep 2013 21:02:21 -0700 (PDT) In-Reply-To: <5230B096.4090303@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B096.4090303@stpeter.im> Date: Wed, 11 Sep 2013 23:02:21 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: [precis] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 04:02:30 -0000 On Wed, Sep 11, 2013 at 1:04 PM, Peter Saint-Andre wrote: > On 9/10/13 8:06 AM, Nico Williams wrote: >> On Monday, September 9, 2013, Peter Saint-Andre wrote: >> This is the third time, I think, that I've had to voice my >> vehement objections to this. I thought we were done the second >> time. > > Hi Nico, I don't think vehemence is needed. We have some different > perspectives, and we're trying to find common ground. I misread anyways, then overreacted. Sorry about that. I have no objection to telling people that they should (not must) treat usernames case-insensitively. They should be told to preserve case as much as possible though, if they allow mixed-case usernames at all. Also, if this is a recommendation for people *deploying* or people designing mechanisms, then the recommendation shouldn't use RFC2119 language (since it's not a recommendation as to what an implementation should do. Finally, if the only goal is to prevent confusion (thinking that two usernames are equivalent when they are not), shouldn't the prescription be to check for case-insensitive collisions at *enrollment* time? I would think so -- then the recommendation would not apply to, say, mechanism implementors (since SASL doesn't deal with enrollment) but to system integrators -- recommendations and requirements about enrollment could be stated in RFC2119 language. So, there's some subtle things here to get right. Also, if the goal is to be case-insensitive then that should be stated. As should be case-preservation. I'm not sure that specifying the nitty gritty of how case-insensitivity is obtained matters much here. > Would you perhaps have time to listen to the recording of the PRECIS > WG session in Berlin? Sure. I'll take a listen. > Also, would you be available for a phone conference on this topic so > that we can work through it in closer to real time? Or might you be > coming to the IETF meeting in Vancouver? I'm thinking I have to go to Vancouver, but as usual it probably won't be for the whole week. My primary interests now lie in KITTEN and HTTPauth WGs. Nico -- From tlyu@mit.edu Mon Sep 16 20:34:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190EE11E8310 for ; Mon, 16 Sep 2013 20:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5caCjcmbs0l9 for ; Mon, 16 Sep 2013 20:34:08 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2679211E8181 for ; Mon, 16 Sep 2013 20:34:07 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-a6-5237cdad799f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.1F.02359.DADC7325; Mon, 16 Sep 2013 23:34:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r8H3Y4It001528; Mon, 16 Sep 2013 23:34:04 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8H3Y1Wt007480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Sep 2013 23:34:03 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r8H3Y1PX000824; Mon, 16 Sep 2013 23:34:01 -0400 (EDT) To: Sam Hartman References: From: Tom Yu Date: Mon, 16 Sep 2013 23:34:01 -0400 In-Reply-To: (Sam Hartman's message of "Fri, 06 Sep 2013 16:17:04 -0400") Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrrv2rHmQwb+7ihZf2x6wWRzdvIrF gcljyZKfTB4rp55mD2CK4rJJSc3JLEst0rdL4MpYd/QEY8Ee5oqn7/6yNjA+Y+pi5OSQEDCR uHJ9A5QtJnHh3nq2LkYuDiGBfYwS/Uv2M0M4Gxklvn9fDuWcY5K4dfIIVFkXo8Tda39ZQfpF BNQlVl+axA5iMwsISyxfc5YNxBYWiJDYcu4EI4gtJKAqMfPXDaA4BwebgLTE0cVlIGEWoPDT a0fBxnAKJEu8aTsANoZXwELixJtGsDE8ApwSuydthYoLSpyc+YQFYpWWxI1/L5kmMArOQpKa hSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6RXm5miV5qSukmRlCockry7mB8d1DpEKMA B6MSD+8MKfMgIdbEsuLK3EOMkhxMSqK8p04BhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwhukC 5XhTEiurUovyYVLSHCxK4rz3zYFSAumJJanZqakFqUUwWRkODiUJ3p4zQFnBotT01Iq0zJwS hDQTByfIcB6g4WA1vMUFibnFmekQ+VOMuhx/Vs79xCjEkpeflyolzpsAUiQAUpRRmgc3B5Zi XjGKA70lzNsLUsUDTE9wk14BLWECWvJ+iRnIkpJEhJRUA6Ok9Iyp/AdXyD5c15Vc7KTxXzr9 Gve5yQ+/dqWek5lv9qV+KnPG/jzDG3tdORjqTt6sEV78Vbxpu9mCC0fNq5L2b7qwVFL6o7Bx pNaDJx6NmkUJB9dvsckK+Zm35qrW5Qs8P61SO/YKfJn/1MHvyfmckK/z+O1UWC8vea4QFhrg XZHHI2t/foYSS3FGoqEWc1FxIgDMciK7DAMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 03:34:15 -0000 Sam Hartman writes: > Folks, this message starts a consensus call on the question of whether > draft-ietf-kitten-aes-cts-hmac-sha2-01 should adopt the proposal to use > CBC mode rather than CTS mode. > > Comments in favor or against this change should be received by September > 16, 2013. > > Even if you have commented in the past, please send in a comment again. In favor, for reasons I've already said. From hartmans@mit.edu Tue Sep 17 10:04:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8608911E82EC for ; Tue, 17 Sep 2013 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEtiE3I+f+E2 for ; Tue, 17 Sep 2013 10:04:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 08F2D11E8544 for ; Tue, 17 Sep 2013 10:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5A63720186; Tue, 17 Sep 2013 13:04:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiaVYHoMSkqC; Tue, 17 Sep 2013 13:04:02 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 17 Sep 2013 13:04:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B5B9787FA2; Tue, 17 Sep 2013 13:04:33 -0400 (EDT) From: Sam Hartman To: Alexey Melnikov References: <522A3B89.1010307@oracle.com> <1378759483.73111.YahooMailNeo@web125605.mail.ne1.yahoo.com> <52303E16.8010801@isode.com> Date: Tue, 17 Sep 2013 13:04:33 -0400 In-Reply-To: <52303E16.8010801@isode.com> (Alexey Melnikov's message of "Wed, 11 Sep 2013 10:55:34 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 17:04:43 -0000 I don't think CB can stay without mutual auth. At the GSS layer, perhaps we can talk about CB without mutual auth, although I find that very confusing. However, for SASL, what people generally want from CB strongly requires mutual auth. From hartmans@mit.edu Tue Sep 17 10:08:23 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B111E830A for ; Tue, 17 Sep 2013 10:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+9r-hBXlxd4 for ; Tue, 17 Sep 2013 10:08:12 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 758FE11E82F7 for ; Tue, 17 Sep 2013 10:08:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E4753203B1; Tue, 17 Sep 2013 13:07:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlPqqhJYTF_H; Tue, 17 Sep 2013 13:07:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 17 Sep 2013 13:07:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DF85387FA2; Tue, 17 Sep 2013 13:08:04 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: Date: Tue, 17 Sep 2013 13:08:04 -0400 In-Reply-To: (Sam Hartman's message of "Fri, 06 Sep 2013 16:17:04 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 17:08:23 -0000 We appear to have a strong consensus in favor of this change to use CBC mode rather than CTS. I'd ask the authors to prepare and submit a new draft with a new name, probably draft-ietf-kitten-aes-cbc-hmac-sha2 Sorry about all the delays involved in coming to this consensus. I appreciate the effort spent by all in the discussion. From shawn.emery@oracle.com Tue Sep 17 23:49:07 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4511611E8191 for ; Tue, 17 Sep 2013 23:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FylHl8Y1QRd5 for ; Tue, 17 Sep 2013 23:49:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BA97211E818B for ; Tue, 17 Sep 2013 23:48:57 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8I6murq008652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Sep 2013 06:48:57 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 r8I6mthi024179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Sep 2013 06:48:56 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8I6mtd7015002 for ; Wed, 18 Sep 2013 06:48:55 GMT Received: from [10.159.91.78] (/10.159.91.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Sep 2013 23:48:54 -0700 Message-ID: <52394D0A.8030103@oracle.com> Date: Wed, 18 Sep 2013 00:49:46 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: multipart/alternative; boundary="------------090501060407010809050508" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [kitten] IETF 88 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 06:49:07 -0000 This is a multi-part message in MIME format. --------------090501060407010809050508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There should be lots of agenda items to put on a possible Vancouver session given recent activity on the list. Please submit these topicsto the list or co-chairs no later than 9/23. Shawn. kitten co-chair -- --------------090501060407010809050508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There should be lots of agenda items to put on a possible Vancouver session given recent activity on the list.  Please submit these topics to the list or co-chairs no later than 9/23.

Shawn.
kitten co-chair
--
 --------------090501060407010809050508-- From mpeck@mitre.org Wed Sep 18 06:12:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7011E8103 for ; Wed, 18 Sep 2013 06:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk6tZYTMdFEn for ; Wed, 18 Sep 2013 06:12:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0F11E8292 for ; Wed, 18 Sep 2013 06:12:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 993281F093B; Wed, 18 Sep 2013 09:12:33 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 805221F093F; Wed, 18 Sep 2013 09:12:33 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.110]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 09:12:33 -0400 From: "Peck, Michael A" To: 'Sam Hartman' Thread-Topic: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 Thread-Index: AQHOqz4ZPm0twRtPFkO2xckhJ+79FZnKOvJmgAFP0NA= Date: Wed, 18 Sep 2013 13:12:32 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B322E240E64@IMCMBX04.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:12:42 -0000 Thanks. We will submit a new draft shortly reflecting the working group con= sensus to use CBC mode. Mike -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= Sam Hartman Sent: Tuesday, September 17, 2013 1:08 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Call: Use CBC for draft-ietf-kitten-aes-cts= -hmac-sha2-01 We appear to have a strong consensus in favor of this change to use CBC mode rather than CTS. I'd ask the authors to prepare and submit a new draft with a new name, probably draft-ietf-kitten-aes-cbc-hmac-sha2 Sorry about all the delays involved in coming to this consensus. I appreciate the effort spent by all in the discussion. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From cantor.2@osu.edu Wed Sep 18 06:58:07 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C15C11E8241 for ; Wed, 18 Sep 2013 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLOJDO8mU1GL for ; Wed, 18 Sep 2013 06:57:52 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 155F811E811E for ; Wed, 18 Sep 2013 06:57:51 -0700 (PDT) Received: from mail33-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Sep 2013 13:57:51 +0000 Received: from mail33-tx2 (localhost [127.0.0.1]) by mail33-tx2-R.bigfish.com (Postfix) with ESMTP id 64F3C3402E6; Wed, 18 Sep 2013 13:57:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275bhz2fh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h1b1cn1b1bi1155h) Received-SPF: pass (mail33-tx2: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail33-tx2 (localhost.localdomain [127.0.0.1]) by mail33-tx2 (MessageSwitch) id 1379512669774036_27096; Wed, 18 Sep 2013 13:57:49 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.250]) by mail33-tx2.bigfish.com (Postfix) with ESMTP id ADA12100041; Wed, 18 Sep 2013 13:57:49 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Sep 2013 13:57:49 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf02 (Postfix) with ESMTP id 664532004B; Wed, 18 Sep 2013 09:57:48 -0400 (EDT) Received: from CIO-KRC-D1MBX03.osuad.osu.edu ([fe80::5ccf:246d:4573:cbba]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0123.003; Wed, 18 Sep 2013 09:57:48 -0400 From: "Cantor, Scott" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] IETF 88 - Agenda Items Thread-Index: AQHOtDsuumwce+vi5k6do/DTohzUpJnLhaYA Date: Wed, 18 Sep 2013 13:57:47 +0000 Message-ID: In-Reply-To: <52394D0A.8030103@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <24F5102D58BDFF40AF2690939C99BED4@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [kitten] IETF 88 - Agenda Items X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:58:11 -0000 On 9/18/13 2:49 AM, "Shawn M Emery" wrote: > >There should be lots of agenda items to put on a possible >Vancouversession given recent activity on the list. Please submit these >topics to the list or co-chairs no later than 9/23. I should be submitting a "final" draft of the SAML-EC mechanism this week and would like to start the WGLC process on that. Don't know if that's an agenda item per se, just noting it. -- Scott From ghudson@mit.edu Wed Sep 18 21:25:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0163211E8117 for ; Wed, 18 Sep 2013 21:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b32He65HjSXG for ; Wed, 18 Sep 2013 21:25:08 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id AAE4A11E8175 for ; Wed, 18 Sep 2013 21:25:01 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-96-523a7c9cd51b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 48.D7.02471.C9C7A325; Thu, 19 Sep 2013 00:25:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r8J4OxAj007732; Thu, 19 Sep 2013 00:24:59 -0400 Received: from [18.101.8.79] (vpn-18-101-8-79.mit.edu [18.101.8.79]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8J4OubL025729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Sep 2013 00:24:58 -0400 Message-ID: <523A7C98.8060805@mit.edu> Date: Thu, 19 Sep 2013 00:24:56 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Luke Howard References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> <52240DB0.4010803@mit.edu> <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> In-Reply-To: <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0Z1TYxVkcOCyuMXRzatYLO5e+s9u sfjrBGYHZo8lS34yeSz+8ZTFY+6HaSwBzFFcNimpOZllqUX6dglcGZ8n7WQraOequDl3NVMD 41rWLkZODgkBE4mbjzcxQthiEhfurWfrYuTiEBLYxyhxePNlKGcjo8Ss9sssEM5BJolT+yeC tfMKqEks/bGSGcRmEVCVWDZ3NpjNJqAscfDsNxYQW1QgROLmstOMEPWCEidnPgGLiwgoSEze vxasnlnAWmJh+2E2EFtYQFNi04G97BDLrjJKrLm0D2wZp4CNxPUpk4GKOMAavu0uguiVl9j+ dg7zBEbBWUhWzEKomoWkagEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYyg oOaU5NvB+PWg0iFGAQ5GJR7eDZcsg4RYE8uKK3MPMUpyMCmJ8pZUWgUJ8SXlp1RmJBZnxBeV 5qQWH2KU4GBWEuENvQhUzpuSWFmVWpQPk5LmYFES5/3+yyJISCA9sSQ1OzW1ILUIJivDwaEk wZtSDTRUsCg1PbUiLTOnBCHNxMEJMpwHaPivKqAa3uKCxNzizHSI/ClGRSlx3iKQZgGQREZp HlwvLOm8YhQHekWY1xGkigeYsOC6XwENZgIa/H6JGcjgkkSElFQD48yjud9+T1izy4VRSKz8 rjVDS7d+waLVzOtubPmY1Z0jW9jrpzf9ZZxS+/aH9kes2dZPaT7l2PJjX/qqZMmJv58VJQrO 01+Ye3VNLu+lm+xRN6fbdX1++sqeZ06NxREj5ubm42taBB7nV5yMmVF6zn91jFn7qYUnrh4I 3NR1wXNiQ3wW83NpFSWW4oxEQy3mouJEAPgfLUcVAwAA Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 04:25:15 -0000 On 09/02/2013 12:09 AM, Luke Howard wrote: > I think these are all pretty reasonable proposals. I think I like 1a/2a. I went with 2a. The new interfaces are: #define GSS_IOV_BUFFER_TYPE_MIC_TOKEN 12 OM_uint32 gss_get_mic_iov(OM_uint32 *minor_status, gss_ctx_id_t context_handle, gss_qop_t qop_req, gss_iov_buffer_desc *iov, int iov_count); OM_uint32 gss_get_mic_iov_length(OM_uint32 *minor_status, gss_ctx_id_t context_handle, gss_qop_t qop_req, gss_iov_buffer_desc *iov, iov_count); OM_uint32 gss_verify_mic_iov(OM_uint32 *minor_status, gss_ctx_id_t context_handle, gss_qop_t *qop_state, gss_iov_buffer_desc *iov, int iov_count); DATA and SIGN_ONLY buffers are signed, with the token going into the MIC_TOKEN buffer. As usual, we use the __stdcall convention on Windows. From lukeh@padl.com Wed Sep 18 21:46:46 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8977E11E80D1 for ; Wed, 18 Sep 2013 21:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8cJAeJ8zHE1 for ; Wed, 18 Sep 2013 21:46:42 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC5521F9D7E for ; Wed, 18 Sep 2013 21:46:41 -0700 (PDT) Received: by us.padl.com with ESMTP id r8J4j50J018045; Thu, 19 Sep 2013 00:46:33 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: <523A7C98.8060805@mit.edu> Date: Thu, 19 Sep 2013 14:46:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> <52240DB0.4010803@mit.edu> <07274D63-0DC2-4DB9-B304-470D4B00E417@padl.com> <523A7C98.8060805@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 04:46:46 -0000 Great. I look forward to adding support for this to Moonshot and = gss_browserid. Should be able to do that in early October. -- Luke On 19/09/2013, at 2:24 PM, Greg Hudson wrote: > On 09/02/2013 12:09 AM, Luke Howard wrote: >> I think these are all pretty reasonable proposals. I think I like = 1a/2a. >=20 > I went with 2a. The new interfaces are: >=20 > #define GSS_IOV_BUFFER_TYPE_MIC_TOKEN 12 >=20 > OM_uint32 gss_get_mic_iov(OM_uint32 *minor_status,=20 > gss_ctx_id_t context_handle,=20 > gss_qop_t qop_req,=20 > gss_iov_buffer_desc *iov,=20 > int iov_count);=20 >=20 > OM_uint32 gss_get_mic_iov_length(OM_uint32 *minor_status,=20 > gss_ctx_id_t context_handle,=20 > gss_qop_t qop_req,=20 > gss_iov_buffer_desc *iov,=20 > iov_count);=20 >=20 > OM_uint32 gss_verify_mic_iov(OM_uint32 *minor_status,=20 > gss_ctx_id_t context_handle,=20 > gss_qop_t *qop_state,=20 > gss_iov_buffer_desc *iov,=20 > int iov_count);=20 >=20 > DATA and SIGN_ONLY buffers are signed, with the token going into the = MIC_TOKEN buffer. As usual, we use the __stdcall convention on Windows. >=20 -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From mrex@sap.com Wed Sep 18 21:57:55 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3A11E818A for ; Wed, 18 Sep 2013 21:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLrqloY1BIrl for ; Wed, 18 Sep 2013 21:57:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2914E11E818C for ; Wed, 18 Sep 2013 21:57:42 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8J4vftC022123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 06:57:41 +0200 (MEST) In-Reply-To: <523A7C98.8060805@mit.edu> To: Greg Hudson Date: Thu, 19 Sep 2013 06:57:41 +0200 (CEST) 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: <20130919045741.945A01A983@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 04:57:55 -0000 Greg Hudson wrote: > > DATA and SIGN_ONLY buffers are signed, with the token going into the > MIC_TOKEN buffer. As usual, we use the __stdcall convention on Windows. __stdcall is specific to 32-bit (x86), it does not exist on 64-bit (x64). -Martin From mrex@sap.com Wed Sep 18 22:08:34 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFBD21F8201 for ; Wed, 18 Sep 2013 22:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.205 X-Spam-Level: X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqZpKoCAXtDi for ; Wed, 18 Sep 2013 22:08:29 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 46E3421F81FF for ; Wed, 18 Sep 2013 22:08:29 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8J58Rb1008719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 07:08:27 +0200 (MEST) In-Reply-To: <20130919045741.945A01A983@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 19 Sep 2013 07:08:27 +0200 (CEST) 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: <20130919050827.AE8FE1A978@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] GSS_GetMIC and iovs X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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, 19 Sep 2013 05:08:34 -0000 Martin Rex wrote: > Greg Hudson wrote: > > > > DATA and SIGN_ONLY buffers are signed, with the token going into the > > MIC_TOKEN buffer. As usual, we use the __stdcall convention on Windows. > > __stdcall is specific to 32-bit (x86), it does not exist on 64-bit (x64). Btw. Windows' own type for the purpose of attaching calling conventions to system function (typically DLL exports) is "WINAPI", defined in windef.h -Martin From tlyu@mit.edu Thu Sep 19 19:52:25 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9D621F847C for ; Thu, 19 Sep 2013 19:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q2lVm-+lUsW for ; Thu, 19 Sep 2013 19:52:18 -0700 (PDT) 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 7FCA021F85C9 for ; Thu, 19 Sep 2013 19:52:18 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-c1-523bb861cad6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id F1.38.02357.168BB325; Thu, 19 Sep 2013 22:52:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r8K2qGYi008090; Thu, 19 Sep 2013 22:52:17 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8K2qEB0008991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Sep 2013 22:52:15 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r8K2qEKR011128; Thu, 19 Sep 2013 22:52:14 -0400 (EDT) To: Shawn M Emery References: <522A3B89.1010307@oracle.com> From: Tom Yu Date: Thu, 19 Sep 2013 22:52:14 -0400 In-Reply-To: <522A3B89.1010307@oracle.com> (Shawn M. Emery's message of "Fri, 06 Sep 2013 14:31:05 -0600") Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJu4wzrI4MEyCYujm1exWPS9PsTu wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGU83/2GpeAFc8Wu65PYGhhbmbsYOTkkBEwk Dq9+ywJhi0lcuLeerYuRi0NIYB+jxIf1bawQzkZGiTW/eqGcc0wSb0+eZ4RwuhglWpq2sIL0 iwhoSdxo6GACsZkFhCWWrznLBmILC6hKtC9bDLZDSEBTYunHj0DNHBxsAtISRxeXgYRZgEq6 Pu5hB7E5BbIktj1pAxvJK2Ah8XPibrA4jwCnRM+GX1BxQYmTM5+wQKwCWvvvJdMERsFZSFKz kKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3ECApVdhelHYw/DyodYhTg YFTi4S0QtA4SYk0sK67MPcQoycGkJMp7cAtQiC8pP6UyI7E4I76oNCe1+BCjBAezkgivQhtQ jjclsbIqtSgfJiXNwaIkzvv9l0WQkEB6YklqdmpqQWoRTFaGg0NJgjdpO1CjYFFqempFWmZO CUKaiYMTZDgP0HAmkBre4oLE3OLMdIj8KUZFKXGIZgGQREZpHlwvLJW8YhQHekWYlw+kigeY huC6XwENZgIafGqBFcjgkkSElFQD44zuFVbpuuVO3D/ecHasF8s8MdXBUpl37/5T5Wwhizbx f9iezZtlsvb1Gz4xT0mj1u/HXi865P/MNkzYwrNdXv7K9OsbY0w/5v338W7dJaQidy7k1hze BcXL5zfc3jxvWfzZmb/tZyZYuzRoztLczmP7LH++UXPnnMgeq/s8bvaSy0IUtWp4lFiKMxIN tZiLihMBUlC5LQADAAA= Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 02:52:25 -0000 Shawn M Emery writes: > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the > GS2 related text from the draft and continue the proceed to shepherd > this as an RFC? a. Yes But I also agree with comments by Nico and Sam. > 2. Should the WG recharter and adopt the > draft-williams-kitten-generic-naming-attributes draft? a. Yes > 3. Should the WG recharter and adopt the > draft-williams-kitten-krb5-pkcross draft? a. Yes From kaduk@mit.edu Thu Sep 19 20:57:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3738521F8596 for ; Thu, 19 Sep 2013 20:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33SreetgaMPA for ; Thu, 19 Sep 2013 20:57:47 -0700 (PDT) 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 5E2EE21F859A for ; Thu, 19 Sep 2013 20:57:47 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-15-523bc7baa9f8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.7A.02357.AB7CB325; Thu, 19 Sep 2013 23:57:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r8K3vjRf019406; Thu, 19 Sep 2013 23:57:46 -0400 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 r8K3vhdK029578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Sep 2013 23:57:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r8K3vhbX009226; Thu, 19 Sep 2013 23:57:43 -0400 (EDT) Date: Thu, 19 Sep 2013 23:57:43 -0400 (EDT) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: <522A3B89.1010307@oracle.com> Message-ID: References: <522A3B89.1010307@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6norvruHWQwZkLlhZHN69iseh7fYjd gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4MpYeGsPW8F/1oprXT+ZGxhPsnQxcnBICJhI zHvO3sXICWSKSVy4t56ti5GLQ0hgH6PE7T2tjBDORkaJm3ePM0M4h5gkjk+8xQrSIiTQwCgx YYoHiM0ioC3xcfJ7RhCbTUBFYuabjWwgtoiAlsSNhg4mEJtZQFhi/bkZzCC2sICqRPuyxSwg NidQzfJ3i8DivAKOEvdPX2GCmK8psfTjR7CZogI6Eqv3T2GBqBGUODnzCQvETEuJf2t/sU5g FJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4EB1UdrB+POg 0iFGAQ5GJR7eAkHrICHWxLLiytxDjJIcTEqivGxHgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eGfsBcrxpiRWVqUW5cOkpDlYlMR5v/+yCBISSE8sSc1OTS1ILYLJynBwKEnwPjwG1ChYlJqe WpGWmVOCkGbi4AQZzgM0/DtIDW9xQWJucWY6RP4Uo6KUOO9vkIQASCKjNA+uF5ZIXjGKA70i zHscpIoHmITgul8BDWYCGnxqgRXI4JJEhJRUA6PP225lp4DP29ldl98+yGakJ6PRlFUmkX6E RexKzNb0iz4bSmo9bhxpeSpteWTJ18MidzMqLE42T7MxEl4WdZz5+OIv8xIDNeZ9+Nm6NW51 88M2Pvn0Bc93zrnj/q7aVvc0f57sodIbcb1/lp1VPsfEff/JtdVHclZ4iRhNNDPt9zztzFjP c0eJpTgj0VCLuag4EQBa+C3K/wIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 03:57:54 -0000 On Fri, 6 Sep 2013, Shawn M Emery wrote: > > The WG is making the following consensus calls (which were formulated from > Berlin's meeting held on August 1st): > > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 > related text from the draft and continue the proceed to shepherd this as an > RFC? > > a. Yes > b. No > c. Don't care or need more information (a) Yes. > 2. Should the WG recharter and adopt the > draft-williams-kitten-generic-naming-attributes draft? > > a. Yes > b. No > c. Don't care or need more information (a) Yes. > 3. Should the WG recharter and adopt the draft-williams-kitten-krb5-pkcross > draft? > > a. Yes > b. No > c. Don't care or need more information (a) Yes. -Ben From paumil@microsoft.com Fri Sep 20 17:28:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9D21F9F99 for ; Fri, 20 Sep 2013 17:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj+-UspT5Rx2 for ; Fri, 20 Sep 2013 17:28:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id CC36B21F9F51 for ; Fri, 20 Sep 2013 17:28:09 -0700 (PDT) Received: from BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) by BLUPR03MB280.namprd03.prod.outlook.com (10.255.213.24) with Microsoft SMTP Server (TLS) id 15.0.775.9; Sat, 21 Sep 2013 00:28:07 +0000 Received: from BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.174]) by BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.174]) with mapi id 15.00.0775.005; Sat, 21 Sep 2013 00:28:07 +0000 From: "Paul Miller (NT)" To: "kitten@ietf.org" Thread-Topic: draft-ietf-kitten-aes-cts-hmac-sha2-01 Thread-Index: Ac62VqJ6/YJPGZsjR5SXJRM51ZMV7w== Date: Sat, 21 Sep 2013 00:28:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(61684002)(199002)(189002)(47976001)(80022001)(49866001)(51856001)(81342001)(50986001)(33646001)(47446002)(77096001)(53806001)(47736001)(81542001)(46102001)(54356001)(76176001)(74502001)(69226001)(19300405004)(83072001)(81816001)(76796001)(74316001)(76482001)(83322001)(74366001)(19580395003)(65816001)(31966008)(56776001)(16236675002)(15202345003)(79102001)(15975445006)(74706001)(74876001)(80976001)(54316002)(59766001)(555904002)(76786001)(56816003)(63696002)(74662001)(81686001)(76576001)(77982001)(4396001)(69594002)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB280; H:BLUPR03MB279.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a8e701bb331e43bea50a1f59505b1b88BLUPR03MB279namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Michiko Short Subject: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 00:33:34 -0000 --_000_a8e701bb331e43bea50a1f59505b1b88BLUPR03MB279namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should first introduce myself as I am most likely unfamiliar to most of y= ou. My name is Paul Miller and I am the developer responsible for the Kerb= eros implementation in Windows. In addition to working on Kerberos, I also= am primarily responsible for the SSPI interface. Michiko Short is out of = office until November; in the interim I will be the Microsoft representativ= e to the working group. I apologize for the lateness of this communication= . Last month I met with Michiko and our cryptographer Niels Ferguson along wi= th a few other stakeholders to discuss the draft and the possibility of usi= ng the CBC cipher mode instead of CTS. Our conclusion is that the risk of = application compatibility when using a cipher suite that does not preserve = the length of the cipher text is too high. Most Windows consumers of SSPI = for user authentication call SPNEGO. This historically negotiates either K= erberos or NTLM. NTLM uses the RC4 stream cipher which preserves length, w= hile Kerberos between Windows systems would use either RC4 or AES-CTS, both= of which are length preserving. While it is true that most applications d= o not call into SSPI directly, instead going through a component like RPC t= hat will handle message encryption correctly, even the fraction of applicat= ions that call directly still represents thousands of pieces of software. = Of these, a non-trivial percentage are likely not to handle data expansion = correctly. It is true that DES has padding and that as a result callers sh= ould handle this correctly, but due to the fact that DES has never been neg= otiated by default between Windows systems (and is even disabled by default= in current versions) means that test coverage of third party applications = with DES encryption is essentially non-existent. Due to the application compatibility risk that we would face, we do not fee= l that CBC is worth the risk. CTS is proven to work for our callers. Here are some other unordered observations from that meeting: We use CTS today with AES so the complexity penalty for using it is already= paid. Using known-good code reduces the chance of introducing new securit= y holes. Using SHA-384 serves no purpose. It's the same operation as SHA-512 and th= us no cheaper to perform. Alternately, there as AES-CMAC which has the benefit of reusing the AES cod= e and can be accelerated with AES-NI, but it is only 128 bits of output. I would also offer that CTS is in fact CBC where the padding is cipher text= from the second to last block. The property of this padding where we can = then omit the cipher text that is absorbed into the last block of plain tex= t in order to preserve length is orthogonal to the properties of the cipher= mode. I do not see where using the CTS mode would then impact the ability= of cryptographic implementations to support AES or the compliance of those= implementations with security standards. Paul J. Miller --_000_a8e701bb331e43bea50a1f59505b1b88BLUPR03MB279namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I should first introduce myself as I am most likely = unfamiliar to most of you.  My name is Paul Miller and I am the develo= per responsible for the Kerberos implementation in Windows.  In additi= on to working on Kerberos, I also am primarily responsible for the SSPI interface.  Michiko Short is out of office u= ntil November; in the interim I will be the Microsoft representative to the= working group.  I apologize for the lateness of this communication.

 

Last month I met with Michiko and our cryptographer = Niels Ferguson along with a few other stakeholders to discuss the draft and= the possibility of using the CBC cipher mode instead of CTS.  Our con= clusion is that the risk of application compatibility when using a cipher suite that does not preserve the length = of the cipher text is too high.  Most Windows consumers of SSPI for us= er authentication call SPNEGO.  This historically negotiates either Ke= rberos or NTLM.  NTLM uses the RC4 stream cipher which preserves length, while Kerberos between Windows systems woul= d use either RC4 or AES-CTS, both of which are length preserving.  Whi= le it is true that most applications do not call into SSPI directly, instea= d going through a component like RPC that will handle message encryption correctly, even the fraction of applic= ations that call directly still represents thousands of pieces of software.=   Of these, a non-trivial percentage are likely not to handle data exp= ansion correctly.  It is true that DES has padding and that as a result callers should handle this correctly, but= due to the fact that DES has never been negotiated by default between Wind= ows systems (and is even disabled by default in current versions) means tha= t test coverage of third party applications with DES encryption is essentially non-existent.

 

Due to the application compatibility risk that we wo= uld face, we do not feel that CBC is worth the risk.  CTS is proven to= work for our callers.

 

Here are some other unordered observations from that= meeting:

 

We use CTS today with AES= so the complexity penalty for using it is already paid.  Using known-= good code reduces the chance of introducing new security holes.<= /p>

 

Using SHA-384 serves no p= urpose.  It’s the same operation as SHA-512 and thus no cheaper = to perform.

 

Alternately, there as AES= -CMAC which has the benefit of reusing the AES code and can be accelerated = with AES-NI, but it is only 128 bits of output.

 

I would also offer that CTS is in fact CBC where the= padding is cipher text from the second to last block.  The property o= f this padding where we can then omit the cipher text that is absorbed into= the last block of plain text in order to preserve length is orthogonal to the properties of the cipher mode.&nbs= p; I do not see where using the CTS mode would then impact the ability of c= ryptographic implementations to support AES or the compliance of those impl= ementations with security standards.

 

Paul J. Miller

 

--_000_a8e701bb331e43bea50a1f59505b1b88BLUPR03MB279namprd03pro_-- From hartmans@mit.edu Mon Sep 23 09:42:18 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31FD21F9FB1 for ; Mon, 23 Sep 2013 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF9CAwuasYMu for ; Mon, 23 Sep 2013 09:42:13 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A4F1B21F9F9E for ; Mon, 23 Sep 2013 09:42:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 7CFED20438; Mon, 23 Sep 2013 12:41:24 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux6YPzS3N5JB; Mon, 23 Sep 2013 12:41:24 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 23 Sep 2013 12:41:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 541698833F; Mon, 23 Sep 2013 12:42:10 -0400 (EDT) From: Sam Hartman To: "Paul Miller \(NT\)" References: Date: Mon, 23 Sep 2013 12:42:10 -0400 In-Reply-To: (Paul Miller's message of "Sat, 21 Sep 2013 00:28:06 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:42:19 -0000 Hi. With my chair hat on, does anyone wish to re-open the discussion of the CBC decision based on this late input? Josh and I believe that the bar for re-opening the discussion is relatively low but does require support from more than just Paul. I have not had a chance to seek Shawn's input on this process question. However, the bar for reversing our previous decision is higher than if this message had been received prior to the consensus call. At this point, the direction of the WG is CBC and we're evaluating changing directions. Which of course we can do, but it requires sufficient support from the group. Sam hartman Kitten co-chair. From kaduk@mit.edu Mon Sep 23 14:59:16 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C4A21F99F0 for ; Mon, 23 Sep 2013 14:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhRON2-pQA-b for ; Mon, 23 Sep 2013 14:59:08 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 23BCB21F9D69 for ; Mon, 23 Sep 2013 14:59:07 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-4e-5240b9a102d2 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 46.95.02471.1A9B0425; Mon, 23 Sep 2013 17:58:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r8NLwtcr032473; Mon, 23 Sep 2013 17:58:55 -0400 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 r8NLwqMn023676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Sep 2013 17:58:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r8NLwqR2008436; Mon, 23 Sep 2013 17:58:52 -0400 (EDT) Date: Mon, 23 Sep 2013 17:58:51 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrbtwp0OQwYeb3BZf2x6wWRzdvIrF 4l83n8WnZZuZHVg8liz5yeTRuuMvu8fKqafZA5ijuGxSUnMyy1KL9O0SuDIOLmxmLLjLVbGq /SZjA+Nhji5GTg4JAROJpqUfGSFsMYkL99azdTFycQgJ7GOU2N6xlgnC2cgo8eroPmYI5xCT xLpdhxghnAZGiQ8PLrCD9LMIaEtcXT0PbBabgIrEzDcb2UBsEQF1ifYJX8HmMgv0MEqcu7eO BSQhLGAjsXvRdbAGTgE1ietvzzGD2LwCjhIr+qaANQsJ5EtcWDkJLC4qoCOxev8UFogaQYmT M5+A2cwClhL/1v5incAoOAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6 qSmlmxjBoSzJt4Px60GlQ4wCHIxKPLw7vB2ChFgTy4orcw8xSnIwKYny7twBFOJLyk+pzEgs zogvKs1JLT7EKMHBrCTCezQaKMebklhZlVqUD5OS5mBREue9yWEfJCSQnliSmp2aWpBaBJOV 4eBQkuCN3w7UKFiUmp5akZaZU4KQZuLgBBnOAzS8FmQxb3FBYm5xZjpE/hSjopQ4LzswWQgJ gCQySvPgemGp5hWjONArwrwiIFU8wDQF1/0KaDAT0ODf/XYgg0sSEVJSDYwLtthsr3txYZKF 902Rz1pcMbXa532jmkv3pobNKUjfxd6hdG2n84IICW7Pi4+SDnVx6DuqrlAVk7m7zahBsOCN p5Jb8Kojejtf3Gkw0OrorbzXf0Z1Rsonp41Pey883fIk9Wqw0K0svTaPeccE9nwUmmXm8NZu svK5Z+5HrHXeHX/d/9rh+D0lluKMREMt5qLiRADorceDEAMAAA== Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 21:59:16 -0000 On Mon, 23 Sep 2013, Sam Hartman wrote: > Hi. > With my chair hat on, does anyone wish to re-open the discussion of the > CBC decision based on this late input? No comment on that particular question as of yet, but I would ask for a clarification from Paul -- when he says that "We use CTS today with AES so the complexity penalty for using it is already paid. Using known-good code reduces the chance of introducing new security holes.", does this account for the difference between the existing enctypes (17,18) and the propsed enctypes with respect to the use of a confounder versus explicit initialization vector, and the the corresponding need to special-case short inputs in the new proposal? I could not tell what Microsoft's position on the short-input behavior was from Paul's initial message. -Ben > Josh and I believe that the bar for re-opening the discussion is > relatively low but does require support from more than just Paul. > I have not had a chance to seek Shawn's input on this process question. > > > However, the bar for reversing our previous decision is higher than if > this message had been received prior to the consensus call. > At this point, the direction of the WG is CBC and we're evaluating > changing directions. > Which of course we can do, but it requires sufficient support from the > group. From nico@cryptonector.com Mon Sep 23 15:52:43 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B412721F9DA8 for ; Mon, 23 Sep 2013 15:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEalmv-UQdKr for ; Mon, 23 Sep 2013 15:52:38 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id CBD7E21F9EAD for ; Mon, 23 Sep 2013 15:52:38 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 4F28450808F; Mon, 23 Sep 2013 15:52:38 -0700 (PDT) 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=uGC3YI9RsyHzxB 3zgEyp+GbkM8A=; b=u90Fl8ODVs51yD+AM0SrKpPvdGMcUYY4iB+LJ0NwJJuNS3 PIl06m12AmYJ7Gk9Qfal9RVS7tPTXvE21F2DsdCATO1dASPg/JAeottmO0UPcKzm BWKqHQz10jtxfi9rT3y728H2tLZ3dBqtmuYotiFajElsr41sM7CYVRkQOvRF4= Received: from gmail.com (unknown [186.136.131.234]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 31A8C50808C; Mon, 23 Sep 2013 15:52:36 -0700 (PDT) Date: Mon, 23 Sep 2013 17:52:30 -0500 From: Nico Williams To: "Paul Miller (NT)" Message-ID: <20130923225228.GA15037@gmail.com> 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) Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 22:52:43 -0000 On Sat, Sep 21, 2013 at 12:28:06AM +0000, Paul Miller (NT) wrote: > Last month I met with Michiko and our cryptographer Niels Ferguson > along with a few other stakeholders to discuss the draft and the > possibility of using the CBC cipher mode instead of CTS. Our > conclusion is that the risk of application compatibility when using a > cipher suite that does not preserve the length of the cipher text is > too high. Most Windows consumers of SSPI for user authentication call > SPNEGO. This historically negotiates either Kerberos or NTLM. NTLM > uses the RC4 stream cipher which preserves length, while Kerberos > between Windows systems would use either RC4 or AES-CTS, both of which > are length preserving. While it is true that most applications do not > call into SSPI directly, instead going through a component like RPC > that will handle message encryption correctly, even the fraction of > applications that call directly still represents thousands of pieces > of software. Of these, a non-trivial percentage are likely not to > handle data expansion correctly. It is true that DES has padding and > that as a result callers should handle this correctly, but due to the > fact that DES has never been negotiated by default between Windows > systems (and is even disabled by default in current versions) means > that test coverage of third party applications with DES encryption is > essentially non-existent. Some questions: 1) Is this a problem where apps use SSPI incorrectly, or is it more general, that SSPI cannot use mechanisms with enctypes with variable padding? 2) If the answe to (1) is that it's not a general problem, is it specific to MS-RPC or is it more general? 3) What are the failure modes for potentially affected apps? Do apps... crash? or just fail to communicate when the session key enctype requires variable padding? 4) What does bad app code look like? (so we can understand the issues, so we can spot problem apps) 5) Can the system (SSPI) detect bad apps and work around this problem? (by, e.g., negotiating the older CTS enctypes) Nico -- From internet-drafts@ietf.org Mon Sep 23 17:36:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4611E80FC; Mon, 23 Sep 2013 17:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhFk5-ufg-u7; Mon, 23 Sep 2013 17:36:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9421F9FD5; Mon, 23 Sep 2013 17:36:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130924003623.32168.26100.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 17:36:23 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 00:36:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-10.txt Pages : 38 Date : 2013-09-23 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-10 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 lukeh@padl.com Mon Sep 23 21:16:33 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5021F9EBE for ; Mon, 23 Sep 2013 21:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZie3yLOQo0d for ; Mon, 23 Sep 2013 21:16:28 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 483DF21F9E88 for ; Mon, 23 Sep 2013 21:16:27 -0700 (PDT) Received: by us.padl.com with ESMTP id r8O4GHuK028152; Tue, 24 Sep 2013 00:16:22 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_3B34173F-EFB2-4103-9734-60040658DA97" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: Date: Tue, 24 Sep 2013 14:16:17 +1000 Message-Id: <83CF005B-6111-4388-9857-183EF21129B3@padl.com> References: To: Paul Miller (NT) X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.8 Cc: kitten@ietf.org, Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 04:16:33 -0000 --Apple-Mail=_3B34173F-EFB2-4103-9734-60040658DA97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul, In a putative SSPI implementation of RFC 4121 enctypes with padding, = would you put the 4121 filler in SECBUFFER_PADDING or in = SECBUFFER_TOKEN? In our scatter-gather implementation in MIT, it looks like: /* GSS: = -------GSS-HEADER--------+-DATA--+-PAD-+----------GSS-TRAILER----------*/ /* CFX: GSS-Header | Kerb-Header | Data | | EC | E(Header) | = Kerb-Trailer */ i.e. the EC goes in the trailer buffer (because I drew a [possibly = erroneous] pedantic distinction between 4121-layer filler and 3961-layer = padding). That makes for variable length trailer buffers if EC is not = fixed (obviously, this is just API semantics). SSPI has a single token buffer, so you have to use RRC. Would it look = like: /* SSP: = -----------------SSPI-TOKEN-------------------------+-DATA--+-PAD-*/ /* CFX: GSS-Header | E(Header) | Kerb-Trailer | Kerb-Header | Data = | EC */ or: /* SSP: = -----------------SSPI-TOKEN------------------------------+-DATA--+-PAD-*/ /* CFX: GSS-Header | EC | E(Header) | Kerb-Trailer | Kerb-Header | = Data | */ i.e. is your compatibility concern that applications can't deal with = padding at all, or that they can't deal with variable length tokens, or = something else? cheers, Luke= --Apple-Mail=_3B34173F-EFB2-4103-9734-60040658DA97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul,

In a = putative SSPI implementation of RFC 4121 enctypes with padding, would = you put the 4121 filler in SECBUFFER_PADDING or in = SECBUFFER_TOKEN?

In our scatter-gather = implementation in MIT, it looks like:

    /* GSS: = -------GSS-HEADER--------+-DATA--+-PAD-+----------GSS-TRAILER----------*/<= /span>
    /* CFX: = GSS-Header | Kerb-Header | Data  |     | EC | E(Header) | = Kerb-Trailer */

i.e. the EC goes in the = trailer buffer (because I drew a [possibly erroneous] pedantic = distinction between 4121-layer filler and 3961-layer padding). That = makes for variable length trailer buffers if EC is not fixed (obviously, = this is just API semantics).

SSPI has a single = token buffer, so you have to use RRC. Would it look = like:

    /* SSP: = -----------------SSPI-TOKEN-------------------------+-DATA--+-PAD-*/
    /* CFX: = GSS-Header Kerb-Header | Data  | EC =  */

or:

  =   /* SSP: = -----------------SSPI-TOKEN------------------------------+-DATA--+-PAD-*/<= /span>
| EC | E(Header) | Kerb-Trailer = |  User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 10:01:11 -0000 Florian Zeitz writes: > While online games might not always want case folded strings, I doubt > having two usernames that differ only in case is ever desirable. I have accounts in systems were that is used -- for example, in one I have a lower-case username 'jas' for the ordinary user and an uppercase variant 'JAS' as a personalized admin account. In general, I believe that any I18N solution that disallow reasonable semantics of how username and passwords are interpreted will be completely ignored. What can (and should) be discussed is what "reasonable semantics" means. But forcing uppercase and lowercase characters to be regarded as the same is to me so completely and obviously unreasonable that I believe there is a disconnect between requirements and solution. /Simon From hartmans@mit.edu Tue Sep 24 07:18:11 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238C111E8133; Tue, 24 Sep 2013 07:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOUxPfuHk3OM; Tue, 24 Sep 2013 07:18:06 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB911E8129; Tue, 24 Sep 2013 07:18:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 28C5A2043C; Tue, 24 Sep 2013 10:17:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLpvcj8X3ugU; Tue, 24 Sep 2013 10:17:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Sep 2013 10:17:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E240287FE8; Tue, 24 Sep 2013 10:17:57 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> Date: Tue, 24 Sep 2013 10:17:57 -0400 In-Reply-To: <87zjr2pmhs.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 24 Sep 2013 12:01:03 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:18:11 -0000 >>>>> "Simon" == Simon Josefsson writes: Simon> Florian Zeitz writes: >> While online games might not always want case folded strings, I >> doubt having two usernames that differ only in case is ever >> desirable. Simon> I have accounts in systems were that is used -- for example, Simon> in one I have a lower-case username 'jas' for the ordinary Simon> user and an uppercase variant 'JAS' as a personalized admin Simon> account. Simon> In general, I believe that any I18N solution that disallow Simon> reasonable semantics of how username and passwords are Simon> interpreted will be completely ignored. What can (and Simon> should) be discussed is what "reasonable semantics" means. Simon> But forcing uppercase and lowercase characters to be regarded Simon> as the same is to me so completely and obviously unreasonable Simon> that I believe there is a disconnect between requirements and Simon> solution. For myself, I've viewed a lot of systems, some of which case fold usernames and some of which do not. I think there's a lot of evidence that systems like AD that case-fold usernames are easier to use. In my mind sufficient evidence to try and move the internet in that direction. From hartmans@mit.edu Tue Sep 24 07:41:46 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CD311E8126 for ; Tue, 24 Sep 2013 07:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg9fGvgiCua8 for ; Tue, 24 Sep 2013 07:41:38 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BE80C11E80F3 for ; Tue, 24 Sep 2013 07:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0B43D2043C; Tue, 24 Sep 2013 10:40:48 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW7BlwjXsnls; Tue, 24 Sep 2013 10:40:47 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Sep 2013 10:40:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 001F487FE8; Tue, 24 Sep 2013 10:41:35 -0400 (EDT) From: Sam Hartman To: Benjamin Kaduk References: Date: Tue, 24 Sep 2013 10:41:35 -0400 In-Reply-To: (Benjamin Kaduk's message of "Mon, 23 Sep 2013 17:58:51 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:41:48 -0000 >>>>> "Benjamin" == Benjamin Kaduk writes: Benjamin> On Mon, 23 Sep 2013, Sam Hartman wrote: >> Hi. With my chair hat on, does anyone wish to re-open the >> discussion of the CBC decision based on this late input? Benjamin> No comment on that particular question as of yet, but I Benjamin> would ask for a clarification from Paul -- when he says Benjamin> that "We use CTS today with AES so the complexity penalty Benjamin> for using it is already paid. Using known-good code Benjamin> reduces the chance of introducing new security holes.", Benjamin> does this account for the difference between the existing Benjamin> enctypes (17,18) and the propsed enctypes with respect to Benjamin> the use of a confounder versus explicit initialization Benjamin> vector, and the the corresponding need to special-case Benjamin> short inputs in the new proposal? I could not tell what Benjamin> Microsoft's position on the short-input behavior was from Benjamin> Paul's initial message. well, I can't think of a way to get to a short-input case throguh SSPI. It seems like we're having the discussion, so that bar has been reached. From simon@josefsson.org Tue Sep 24 13:27:06 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3611E8165; Tue, 24 Sep 2013 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvP7ITMDBZso; Tue, 24 Sep 2013 13:27:05 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53721F90DC; Tue, 24 Sep 2013 13:27:04 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OKR1Gf013683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 22:27:02 +0200 From: Simon Josefsson To: Sam Hartman References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130924:precis@ietf.org::HTGEColy34iEnELB:2CP9 X-Hashcash: 1:22:130924:kitten@ietf.org::UxBACrsq0/BbRMxp:BGB0 X-Hashcash: 1:22:130924:hartmans-ietf@mit.edu::1f8Q4UrPaDZAEnml:6uA7 Date: Tue, 24 Sep 2013 22:27:01 +0200 In-Reply-To: (Sam Hartman's message of "Tue, 24 Sep 2013 10:17:57 -0400") Message-ID: <87txharmne.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:27:06 -0000 Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Florian Zeitz writes: > >> While online games might not always want case folded strings, I > >> doubt having two usernames that differ only in case is ever > >> desirable. > > Simon> I have accounts in systems were that is used -- for example, > Simon> in one I have a lower-case username 'jas' for the ordinary > Simon> user and an uppercase variant 'JAS' as a personalized admin > Simon> account. > > Simon> In general, I believe that any I18N solution that disallow > Simon> reasonable semantics of how username and passwords are > Simon> interpreted will be completely ignored. What can (and > Simon> should) be discussed is what "reasonable semantics" means. > Simon> But forcing uppercase and lowercase characters to be regarded > Simon> as the same is to me so completely and obviously unreasonable > Simon> that I believe there is a disconnect between requirements and > Simon> solution. > > For myself, I've viewed a lot of systems, some of which case fold > usernames and some of which do not. > > I think there's a lot of evidence that systems like AD that case-fold > usernames are easier to use. > In my mind sufficient evidence to try and move the internet in that > direction. I disagree that an I18N document is the appropriate way to move the Internet to case-insensitive usernames. If case-sensitive usernames is a significant problem, then it should be possible to publish a BCP recommending against that. Then existing protocols with case-sensitive usernames like HTTP, FTP, SMTP, SSH, etc could be revised. I don't believe any of that will happen, so we'll have to live with case sensitive usernames, and my take is that I18N documents should permit that. /Simon From hartmans@mit.edu Tue Sep 24 13:44:29 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7AA11E8167; Tue, 24 Sep 2013 13:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlKwHaFEJvpA; Tue, 24 Sep 2013 13:44:24 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0811E8165; Tue, 24 Sep 2013 13:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 78C482043F; Tue, 24 Sep 2013 16:43:15 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EowDG324SRh1; Tue, 24 Sep 2013 16:43:14 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Sep 2013 16:43:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9480687FE8; Tue, 24 Sep 2013 16:44:03 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> Date: Tue, 24 Sep 2013 16:44:03 -0400 In-Reply-To: <87txharmne.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 24 Sep 2013 22:27:01 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:44:29 -0000 >>>>> "Simon" == Simon Josefsson writes: Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't Simon> believe any of that will happen, so we'll have to live with Simon> case sensitive usernames, and my take is that I18N documents Simon> should permit that. I'm not sure any of the above hase case sensitive usernames. They permit usernames to be case sensitive. However a lot of implementations treat the username as case insensitive. I do think this is an appropriate issue for an IETF an document, but I do think considering the impact on legacy systems is important. I don't think we need to require there be no impact, simply understand an accept it. From simon@josefsson.org Tue Sep 24 14:17:54 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71EA21F9CDA; Tue, 24 Sep 2013 14:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuurd2Aol3L2; Tue, 24 Sep 2013 14:17:54 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 13AA221F9CDF; Tue, 24 Sep 2013 14:17:51 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OLHnwt022918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 23:17:50 +0200 Date: Tue, 24 Sep 2013 23:17:46 +0200 From: Simon Josefsson To: Sam Hartman Message-ID: <20130924231746.73c578b7@latte.josefsson.org> In-Reply-To: References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "kitten@ietf.org" , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 21:17:55 -0000 You wrote: > >>>>> "Simon" == Simon Josefsson writes: > > Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't > Simon> believe any of that will happen, so we'll have to live with > Simon> case sensitive usernames, and my take is that I18N > Simon> documents should permit that. > > I'm not sure any of the above hase case sensitive usernames. > They permit usernames to be case sensitive. > However a lot of implementations treat the username as case > insensitive. > > I do think this is an appropriate issue for an IETF an document, but I > do think considering the impact on legacy systems is important. > I don't think we need to require there be no impact, simply understand > an accept it. Agreed, but the devil is in the detail. For example, I would say that any I18N effort that changes how ASCII usernames ([A-Za-z0-9...]) behave have gone too far down the road that causes damage to legacy systems. For passwords, there are also security aspects, since case folding reduces entropy. Maybe in some of these details we can find were we agree and disagree. /Simon From paumil@microsoft.com Tue Sep 24 15:00:42 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC9B21F8D0B for ; Tue, 24 Sep 2013 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwr2xZuWo2LZ for ; Tue, 24 Sep 2013 15:00:28 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 183BF21F9C05 for ; Tue, 24 Sep 2013 15:00:25 -0700 (PDT) Received: from BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) by BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 22:00:18 +0000 Received: from BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.174]) by BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.174]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 22:00:18 +0000 From: "Paul Miller (NT)" To: Sam Hartman , Benjamin Kaduk Thread-Topic: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 Thread-Index: AQHOuTQqLL9iqiJfDEOixCgfmtSLk5nVbNDw Date: Tue, 24 Sep 2013 22:00:18 +0000 Message-ID: <1553bab817a2411c90c18aa4ffd2b1dc@BLUPR03MB279.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(13464003)(24454002)(51856001)(80022001)(74316001)(19580405001)(19580395003)(83322001)(76796001)(46102001)(31966008)(47446002)(74662001)(74502001)(74706001)(81342001)(54356001)(15975445006)(56816003)(53806001)(76576001)(76786001)(77096001)(83072001)(81542001)(74876001)(77982001)(59766001)(4396001)(49866001)(50986001)(47976001)(76482001)(54316002)(561944002)(56776001)(47736001)(80976001)(74366001)(33646001)(69226001)(63696002)(81686001)(81816001)(65816001)(79102001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB279; H:BLUPR03MB279.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 22:00:42 -0000 Through GSS_Wrap, the fact that we are encrypting at least the header per R= FC 4121 ensures that the message is not less than one block. The use of th= e cipher suite in the context establishment could be a problem, however. Without the confounder to avoid the short message problem, there could be a= mbiguity between what is CTS encoded to exact length and what is padded whe= n the cipher text is exactly one block length. That is to say that the pla= in texts: 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd 01 Would end up encrypting the same and could not be distinguished as the form= er would need to PKCS #7 pad and the latter would just CBC the single block= . I'm sorry I missed a lot of the context from prior discussions, but what is= the reason for using a traditional IV instead of the confounder? I don't = see a difference in security and using the confounder like cipher text allo= ws CTS for short inputs. -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= Sam Hartman Sent: Tuesday, September 24, 2013 7:42 AM To: Benjamin Kaduk Cc: kitten@ietf.org; Michiko Short; Sam Hartman Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 >>>>> "Benjamin" =3D=3D Benjamin Kaduk writes: Benjamin> On Mon, 23 Sep 2013, Sam Hartman wrote: >> Hi. With my chair hat on, does anyone wish to re-open the >> discussion of the CBC decision based on this late input? Benjamin> No comment on that particular question as of yet, but I Benjamin> would ask for a clarification from Paul -- when he says Benjamin> that "We use CTS today with AES so the complexity penalty Benjamin> for using it is already paid. Using known-good code Benjamin> reduces the chance of introducing new security holes.", Benjamin> does this account for the difference between the existing Benjamin> enctypes (17,18) and the propsed enctypes with respect to Benjamin> the use of a confounder versus explicit initialization Benjamin> vector, and the the corresponding need to special-case Benjamin> short inputs in the new proposal? I could not tell what Benjamin> Microsoft's position on the short-input behavior was from Benjamin> Paul's initial message. well, I can't think of a way to get to a short-input case throguh SSPI. It seems like we're having the discussion, so that bar has been reached. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From hotz@jpl.nasa.gov Wed Sep 25 16:06:14 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011B121F9E1A; Wed, 25 Sep 2013 16:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er0H3XqWFzZ8; Wed, 25 Sep 2013 16:06:08 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 4634621F9E01; Wed, 25 Sep 2013 16:06:05 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8PN63hI028708 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 25 Sep 2013 16:06:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Henry B. Hotz" In-Reply-To: <87txharmne.fsf@latte.josefsson.org> Date: Wed, 25 Sep 2013 16:06:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1510) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 23:06:14 -0000 On Sep 24, 2013, at 1:27 PM, Simon Josefsson = wrote: > I disagree that an I18N document is the appropriate way to move the > Internet to case-insensitive usernames. +1 The arguments re case sensitivity are legitimate concerns, and should be = dealt with in the appropriate documents. =20 ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From nico@cryptonector.com Thu Sep 26 11:42:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A283521F9F50 for ; Thu, 26 Sep 2013 11:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTWUXnrgJ-0f for ; Thu, 26 Sep 2013 11:41:47 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id AA6D021F9F88 for ; Thu, 26 Sep 2013 11:41:37 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 585FD67C073 for ; Thu, 26 Sep 2013 11:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=+1cFQbhjYXwo/0Cqq0Y486o2NcY=; b=UAJg8yF1cT5 Ts77Src+16mXxByrfi8h0TfhS1bJ8rmBbw6LVnM4kjGVWw2U63zGyhZyMxWAlKVJ siuEJWa4nXaARiqtAEQwKqoJDUwmA746wxndlxbr04Y9w9IBW1NesbEDIHB03DHP qEEDmJ3psbS5n5g2bdQedpULW0iTnL/k= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 01C2367C06B for ; Thu, 26 Sep 2013 11:41:35 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so1590143wes.16 for ; Thu, 26 Sep 2013 11:41:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=K7u1uGbcepF+zYCDPuW7kW5eiOkKL/xavnSLLwm0wdQ=; b=LQjWOj+9ktj+3soSeWE8ie190His3VOf44CjDbbaK691kr8Xm7FabO8VVZbi5iWjuB 3Eh3FpLflVW718j2v0/YkaCh9lN8/Pg9R2Av74W4Irz5M9lVmQgrI9HmuftTdEWieVyG wim1kzWa5xL7KPiZjnaYER5RMwaCHhU06i+eaAus9lU90N238bF2OoUcG4CNOc5ZmglO 5njdBbMo/ZZfxOyDlbhcUaYLWWVlg6vKu8gsRHve2W2nmlpE4URHomO2590IjBQNGJDv 8xtsuRB+5HYdLDM7h+7btuSGvM6dufG8Mb8kkKxWCRTbKfamaM45CxdmvgSHhwkWC8Kl VB6g== MIME-Version: 1.0 X-Received: by 10.194.23.196 with SMTP id o4mr2194498wjf.62.1380220894258; Thu, 26 Sep 2013 11:41:34 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Thu, 26 Sep 2013 11:41:34 -0700 (PDT) Date: Thu, 26 Sep 2013 13:41:34 -0500 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [kitten] confounding >> random IV? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:42:15 -0000 If you have an RNG that has a backdoor such that anyone who possesses the key to it can recover the next output given any one output (of some given size, perhaps), then random IVs and nonces leak RNG state if they are taken directly from the RNG. Confounding eliminates this problem, at least for RFC3961 crypto. Maybe we should keep confounding. Of course, this notion is rather contrived. No one in their right minds would run an RNG like that... Also, confounding cannot protect against other backdoored PRNG attacks, just those where the attacker gets a lot of value from observing direct PRNG outputs. So maybe confounding adds no value; it definitely subtracts performance. But we should at the very least note this in the new enctypes' security considerations. Also, we should consider carefully whether we really want to ditch confounding. Nico -- From tlyu@mit.edu Thu Sep 26 12:01:45 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978DC21E80D3 for ; Thu, 26 Sep 2013 12:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyGSl2izl3js for ; Thu, 26 Sep 2013 12:01:36 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9F72221E80CC for ; Thu, 26 Sep 2013 12:01:15 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-23-5244847ac1b3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A7.D1.02411.A7484425; Thu, 26 Sep 2013 15:01:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r8QJ1Ekr024897 for ; Thu, 26 Sep 2013 15:01:14 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8QJ1C1U020211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Sep 2013 15:01:14 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r8QJ1BWE004520; Thu, 26 Sep 2013 15:01:11 -0400 (EDT) To: kitten@ietf.org From: Tom Yu Date: Thu, 26 Sep 2013 15:01:11 -0400 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrFvV4hJk8HiNhcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVce/rG9aC97wVK77PYW9gvM7dxcjJISFgIrH4+m4WCFtM4sK9 9WxdjFwcQgL7GCV+/ZzCDJIQEjjOKHFgTTxE4gmTRM+vrYwQThejRNf8rWwgVSICwhK7t74D 6xAWiJd4PH0nexcjBwebgLTE0cVlIGEWAVWJ41sPgW3jFbCQuLn+OFgrjwCnxOlZn6HighIn Zz4Bs5kFtCRu/HvJNIGRbxaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfVyM0v0 UlNKNzGCgondRWUHY/MhpUOMAhyMSjy8GVkuQUKsiWXFlbmHGCU5mJREeTc1AIX4kvJTKjMS izPii0pzUosPMUpwMCuJ8K6PBcrxpiRWVqUW5cOkpDlYlMR5b3HYBwkJpCeWpGanphakFsFk ZTg4lCR4U5qBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGJ4HU8BYXJOYWZ6ZD5E8xKkqJ85qBJARA EhmleXC9sGh/xSgO9IowrylIFQ8wUcB1vwIazAQ02KHDCWRwSSJCSqqBUW5mUdqMGzIXGmd8 6GGXyM6/HmApOtfQ81uuYeBq3qLpvruWpuavmrCDeeeXZffza+btfjbzqvTHvU2yMx3FfT92 qF+Zx2bTxP2P36fTUsXrpsyC5Dst6+QS/z2a4ugnUKewe0P7yd0MP69np3uElLC/vqTz27b0 f3egiRBDieLJvNN1vpZSSizFGYmGWsxFxYkAdzBTbNECAAA= Subject: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:01:54 -0000 There have recently been allegations that certain RNGs might be compromised. This is significant when making cipher mode decisions for Kerberos, because encrypted confounders could mitigate against malicious RNGs. I suggest that we consider the tradeoffs of using encrypted confounders. Some of us have been thinking about whether encrypted confounders add any security beyond plaintext explicit IVs. Researchers, e.g. Boldyreva and Kumar (http://www.cs.washington.edu/research/projects/poirot3/Oakland/sp/PAPERS/oakland07-24.pdf) have proven that the encrypted confounder CBC modes in Kerberos with encode-then-E&M are no worse than explicit IVs with encrypt-then-MAC. A posting by Perry Metzger (http://www.metzdowd.com/pipermail/cryptography/2013-September/017571.html) brings up the idea of explicit plaintext IVs as being a covert channel through which a malicious RNG could leak state information. If, as alleged, leaking only 32 bytes of RNG output is sufficient to allow recovery of its internal state, leakage through IVs is a serious risk. Using an encrypted confounder can remove this covert channel, or at least significantly raise the bar for using it. A malicious implementation could still leak RNG state by first passing the confounder through a block decryption operation, but that requires access to the encryption key. Also, invocation of a decryption operation during what is supposed to be an encryption operation might be more obvious to auditors than a malicious RNG would be. I think one question we should consider is whether the increased security from using encrypted confounders is worth deviating from the historically preferred explicit IVs that we're considering in draft-ietf-kitten-aes-cts-hmac-sha2. From paumil@microsoft.com Fri Sep 27 15:56:28 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591B521F9D42 for ; Fri, 27 Sep 2013 15:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OadbOP7Ot91i for ; Fri, 27 Sep 2013 15:56:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF4A21F9DED for ; Fri, 27 Sep 2013 15:56:09 -0700 (PDT) Received: from BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) by BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 27 Sep 2013 22:56:08 +0000 Received: from BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.174]) by BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.174]) with mapi id 15.00.0775.005; Fri, 27 Sep 2013 22:56:08 +0000 From: "Paul Miller (NT)" To: "kitten@ietf.org" Thread-Topic: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2) Thread-Index: AQHOuusBYgkU2JudR0S0vPvtmQkgnpnaKpxA Date: Fri, 27 Sep 2013 22:56:07 +0000 Message-ID: <68eb2a3d201548349da7634f867a46cc@BLUPR03MB279.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(13464003)(76576001)(76796001)(15975445006)(81542001)(59766001)(51856001)(77982001)(80022001)(83322001)(19580405001)(19580395003)(76786001)(77096001)(83072001)(4396001)(49866001)(74662001)(74502001)(74876001)(74316001)(47976001)(56776001)(31966008)(47736001)(63696002)(76482001)(50986001)(81816001)(80976001)(54316002)(65816001)(53806001)(81342001)(46102001)(15202345003)(54356001)(47446002)(56816003)(74366001)(33646001)(79102001)(74706001)(69226001)(81686001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB279; H:BLUPR03MB279.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:56:28 -0000 While I agree with the analysis that the use of a confounder will limit the= exposure of the state of a faulty PRNG, I don't see this as a problem that= needs to be addressed by Kerberos. The RNG is a system service and not pa= rt of the Kerberos specification. RFC 4120 references RFC 4086 "Randomness= Requirements for Security" so the condition not to use a PRNG that leaks s= tate is already covered. Between nonces and randomly generated session key= s, there are plenty of other avenues for insufficient randomness to manifes= t. This is not to say that I disagree with using a confounder. A confounder i= s quite useful as a source of cipher text from which to steal in order to m= ake CTS work with short inputs. -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= Tom Yu Sent: Thursday, September 26, 2013 12:01 PM To: kitten@ietf.org Subject: [kitten] explicit CBC IVs vs confounders: covert channels (draft-i= etf-kitten-aes-cts-hmac-sha2) There have recently been allegations that certain RNGs might be compromised= . This is significant when making cipher mode decisions for Kerberos, beca= use encrypted confounders could mitigate against malicious RNGs. I suggest= that we consider the tradeoffs of using encrypted confounders. Some of us have been thinking about whether encrypted confounders add any s= ecurity beyond plaintext explicit IVs. Researchers, e.g. Boldyreva and Kum= ar (http://www.cs.washington.edu/research/projects/poirot3/Oakland/sp/PAPERS/o= akland07-24.pdf) have proven that the encrypted confounder CBC modes in Kerberos with encode= -then-E&M are no worse than explicit IVs with encrypt-then-MAC. A posting by Perry Metzger (http://www.metzdowd.com/pipermail/cryptography/2013-September/017571.html) brings up the idea of explicit plaintext IVs as being a covert channel thro= ugh which a malicious RNG could leak state information. If, as alleged, le= aking only 32 bytes of RNG output is sufficient to allow recovery of its in= ternal state, leakage through IVs is a serious risk. Using an encrypted confounder can remove this covert channel, or at least s= ignificantly raise the bar for using it. A malicious implementation could still leak RNG state by first passing the = confounder through a block decryption operation, but that requires access t= o the encryption key. Also, invocation of a decryption operation during wh= at is supposed to be an encryption operation might be more obvious to audit= ors than a malicious RNG would be. I think one question we should consider is whether the increased security f= rom using encrypted confounders is worth deviating from the historically pr= eferred explicit IVs that we're considering in draft-ietf-kitten-aes-cts-hm= ac-sha2. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Sat Sep 28 19:23:15 2013 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AE921E814F for ; Sat, 28 Sep 2013 19:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c83j7kZgsw9m for ; Sat, 28 Sep 2013 19:23:10 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA1211E8116 for ; Sat, 28 Sep 2013 19:23:10 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id EC64B2007AE38 for ; Sat, 28 Sep 2013 19:23:09 -0700 (PDT) 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=ApMaYpltkAHr/ljPY0oz 1fOkq04=; b=qhgdEM8SNKw4U2pWE0DNRMMwQ1xrcgKg3YThg52hNXR3Xxd5BHFg MmtVxhIFp/Nd84DObx8HWW5jZKdxyDIMKqU9M19HkHF6zqTGrGzGj4MPzM//YnWh py6A8yY0TuCKGUoOLKejRtfAiDkZ6de9qJn5pcAfzvjvdzBSIeQviu4= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 9ED3A2007AE17 for ; Sat, 28 Sep 2013 19:23:09 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so4115356wes.21 for ; Sat, 28 Sep 2013 19:23:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NVkkLdAJ+/thTeWJp6od0ui89uhQ6UJXiZVkyRHlSoE=; b=jsrJiPZSU0r1Fng1Dwie6LbTgk0VhnykaRaE8KFccIkJKzUEYA/9y9mm3dzgfp2l4r 1uqG8KM+/b+hciWxDCIVDo/NregrIv46kvWTGlmSBYodCOvpOXLEClbfyOyEbqgdIcJd M5NF7wE1bGvfD4y9n2asC40oklD8hTOCzP4T7j2EH3esV2fEOP+pATPCFHJg9ow8OG2O LzWOclVm/PGtJReIhl5Kbnn6ABbULpZhgyu2ZnFTUvKgWDNjgEEwUMktl2c8EUWdVaoW N4dWlgB/9Xgi/XrhIRSvfO8F7NRjLmgy5/888Ovi2FiwjQBbhSTn4fre4hBB6AlsOBbK juew== MIME-Version: 1.0 X-Received: by 10.180.73.109 with SMTP id k13mr8155265wiv.35.1380421387609; Sat, 28 Sep 2013 19:23:07 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Sat, 28 Sep 2013 19:23:07 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Sep 2013 21:23:07 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 02:23:15 -0000 On Thu, Sep 26, 2013 at 2:01 PM, Tom Yu wrote: > A posting by Perry Metzger > (http://www.metzdowd.com/pipermail/cryptography/2013-September/017571.html) > brings up the idea of explicit plaintext IVs as being a covert channel > through which a malicious RNG could leak state information. If, as > alleged, leaking only 32 bytes of RNG output is sufficient to allow > recovery of its internal state, leakage through IVs is a serious risk. > Using an encrypted confounder can remove this covert channel, or at > least significantly raise the bar for using it. That's an interesting idea. Combined with a counter mode that would be... counter mode. Counter reuse being so disastrous to counter modes, one could use a small counter, pad it, and encrypt into an IV for a CBC/CTS mode. Combined with small sequence number windows this would make it very difficult to leak data via the IV. Anyways, an enctype based on such a mode would not fit RFC3961. Which brings me to: RFC3961 is a bit too constraining. A single, simple extension would make it so much easier to produce new enctypes: an indication of whether a given key is a long-term key, a Ticket session key, a sub-session key, or some other type of key (e.g., non-shared). Actually, we could derive that from key usage for known key usages, and we could setup key usage number ranges as well for future uses. Anyways, just an idea. Nico --