From hartmans@mit.edu Thu Aug 1 05:41:08 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 A033221E8102 for ; Thu, 1 Aug 2013 05:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 D260D9mVnLta for ; Thu, 1 Aug 2013 05:41:02 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2521E80F2 for ; Thu, 1 Aug 2013 05:38:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BE1D320217; Thu, 1 Aug 2013 08:37:41 -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 GekYwNqy2i58; Thu, 1 Aug 2013 08:37:41 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (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; Thu, 1 Aug 2013 08:37:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E2B5E80D75; Thu, 1 Aug 2013 08:38:18 -0400 (EDT) From: Sam Hartman To: Kelley Burgin References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> Date: Thu, 01 Aug 2013 08:38:18 -0400 In-Reply-To: (Kelley Burgin's message of "Fri, 19 Jul 2013 11:24:36 -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, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 01 Aug 2013 12:41:09 -0000 Hi. I've read all the discussions on this thread, and with my chair hat on, a few points seem to have been made and not really considered. 1) we have not evaluated CTR mode. We looked at CCM and GCM, but have not looked at CTR with an HMAC. Just pointing out that we have not thoroughly considered the options. 2) You don't need to implement the short plaintext special case if you implement Kerberos and GSS-API. You need to implement it only if you expose a general RFC 3961 API and choose to support short plaintexts in that that API. 3) Speaking as someone involved at the time, making sure that no more than 8 bytes of expansion were included in the AES enctypes was a critical consideration to gaining consensus and to developing RFC 4121. The chairs will need to discuss how to approach consensus on this document. From hartmans@mit.edu Thu Aug 1 05:42: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 BDE2E21E8181 for ; Thu, 1 Aug 2013 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 kMzYtsfZokUM for ; Thu, 1 Aug 2013 05:41:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3421E8105 for ; Thu, 1 Aug 2013 05:40:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8A27320217; Thu, 1 Aug 2013 08:39:27 -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 OwEn672_exZQ; Thu, 1 Aug 2013 08:39:27 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (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; Thu, 1 Aug 2013 08:39:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4700580D75; Thu, 1 Aug 2013 08:40:05 -0400 (EDT) From: Sam Hartman To: Simo Sorce References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> Date: Thu, 01 Aug 2013 08:40:05 -0400 In-Reply-To: <1374600899.18186.1.camel@willson.li.ssimo.org> (Simo Sorce's message of "Tue, 23 Jul 2013 13:34:59 -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" , Zhanna Tsitkov Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 01 Aug 2013 12:42:00 -0000 *blink* why do we ever want to make enctype optional even it can be inferred? We've never done that before that I am aware of. Enctype is always explicit in Kerberos. From simo@redhat.com Thu Aug 1 05:54: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 A0FF121E80E1 for ; Thu, 1 Aug 2013 05:54:40 -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 h0MfpeaRqP01 for ; Thu, 1 Aug 2013 05:54:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 45A7821F9DA0 for ; Thu, 1 Aug 2013 05:53:09 -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 r71Cr5nf025075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 08:53:05 -0400 Received: from [10.3.113.18] ([10.3.113.18]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r71Cr4gE014006; Thu, 1 Aug 2013 08:53:04 -0400 From: Simo Sorce To: Sam Hartman In-Reply-To: References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Thu, 01 Aug 2013 08:53:03 -0400 Message-ID: <1375361584.15733.172.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" , Zhanna Tsitkov Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 01 Aug 2013 12:54:44 -0000 On Thu, 2013-08-01 at 08:40 -0400, Sam Hartman wrote: > *blink* > why do we ever want to make enctype optional even it can be inferred? > We've never done that before that I am aware of. > Enctype is always explicit in Kerberos. The reasoning was that the KDC krbtgt has only ever one enctype so we do not need to provide it. I was not totally convinced at first, but it saves a few bytes so I am ok if others agree. If you feel strongly that it would be an error I am also ok making it mandatory. Basically I do not have a problem either way. Simo. -- Simo Sorce * Red Hat, Inc * New York From ghudson@mit.edu Thu Aug 1 07: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 15AE321F9D3E for ; Thu, 1 Aug 2013 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 NqXcZNSkX7h0 for ; Thu, 1 Aug 2013 07:17: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 AA2B121F9994 for ; Thu, 1 Aug 2013 07:17:14 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-91-51fa6de8c69d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 51.C7.02357.8ED6AF15; Thu, 1 Aug 2013 10:17:12 -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 r71EHARJ020496; Thu, 1 Aug 2013 10:17:10 -0400 Received: from [18.101.8.207] (vpn-18-101-8-207.mit.edu [18.101.8.207]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r71EH6VS002472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 10:17:07 -0400 Message-ID: <51FA6DE2.2050708@mit.edu> Date: Thu, 01 Aug 2013 10:17:06 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sam Hartman References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> 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+NgFlrMKsWRmVeSWpSXmKPExsUixCmqrfsi91egQc9DQ4uvbQ/YLK6/P8du cXTzKhaLeQ0ZDiwe+1uPsXosWfKTyWPl1NPsHlub/zEGsERx2aSk5mSWpRbp2yVwZXR3fWYr 2C9c8fBQD2MD437+LkZODgkBE4ljJ08yQ9hiEhfurWfrYuTiEBLYxyjx7ukXRpCEkMAGRol5 G9khEoeZJLZ/6GMHSfAKqElsufkarJtFQFVi8alLrCA2m4CyxMGz31i6GDk4RAVCJJae5IYo F5Q4OfMJC4gtIqAusfrSJLAxzALpEgsmrAXbJSxQJPH0fyMzxK5LLBI7brwES3AC7bpyYgET xKWSEoumdbJANOtIvOt7wAxhy0tsfzuHeQKj0Cwk+2YhKZuFpGwBI/MqRtmU3Crd3MTMnOLU ZN3i5MS8vNQiXVO93MwSvdSU0k2MoPBnd1HawfjzoNIhRgEORiUe3geZvwKFWBPLiitzDzFK cjApifJezAEK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9rAGU401JrKxKLcqHSUlzsCiJ8z57 ejZQSCA9sSQ1OzW1ILUIJivDwaEkwfsQZKhgUWp6akVaZk4JQpqJgxNkOA/Q8OcgNbzFBYm5 xZnpEPlTjLock89uec8oxJKXn5cqJc77FaRIAKQoozQPbg4sbb1iFAd6S5h3J0gVDzDlwU16 BbSECWhJKgfYkpJEhJRUA2Nz+Yy+Sd/Lol7FHI8Rm6/1QvbGzo6QamnnuRF5+5uvKH9t9Uj5 pVMX31l2/Ert95jb1wWeHbHO/fDQ//3r31PtrF9w6E8rDpXg//Bw/+5TQQ921G4ynZt39vGL r0ssXr97fpOh7xZDGW/0//9b+L3v228xvlZ92vXIVZGsDrt3jZKzLqndfmOmxFKckWioxVxU nAgAQEq8XjYDAAA= Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 01 Aug 2013 14:17:54 -0000 On 08/01/2013 08:38 AM, Sam Hartman wrote: > 1) we have not evaluated CTR mode. We looked at CCM and GCM, but have > not looked at CTR with an HMAC. > Just pointing out that we have not thoroughly considered the options. If I understand how CTR+HMAC would work, the same problems exist for CTR+HMAC as for CCM: the 128-bit block size of AES is not big enough for a random nonce and a block counter, given the requirements for maximum message size and the requirements for confidence of nonce uniqueness. > 2) You don't need to implement the short plaintext special case if you > implement Kerberos and GSS-API. You need to implement it only if you > expose a general RFC 3961 API and choose to support short plaintexts in > that that API. I don't think that's an interesting fact for my MIT krb5, and I would speculate that it's not interesting fact for any Kerberos implementation. This is a 3961 enctype, and if we implement it, we would want to implement it generally. We have internal uses of 3961 which involve short plaintexts, and we know of other 3961 consumers such as OpenAFS. > 3) Speaking as someone involved at the time, making sure that no more > than 8 bytes of expansion were included in the AES enctypes was a > critical consideration to gaining consensus and to developing RFC 4121. [Sam clarified online that he meant no more than 8 bytes of variable expansion; fixed expansion beyond 8 bytes is okay. I think he may have meant 3962 rather than 4121.] I would welcome additional information on this. I am not at all comfortable with the position that, essentially, the burden of proof is on anyone who doesn't want to meet this technical requirement, the rationale for which has never been concretely described on the mailing list. When we searched the archives for discussion of the rationale for CTS in RFC 3962, all we found is suggestions from Ken that it would save some space (which was also presumably the reason for truncating the HMAC to 96 bits). Also, I would like a clarification on Sam's earlier statement (July 17) that: > We're at a point in the process where the presumption is that we will > not make a given change unless consensus is demonstrated to make the > change. Was there a WG last call on this draft? (I wasn't able to find one in the archives, but I think Sam mentioned a "second last call" at some point during the meeting.) When did it reach this point in the process if not? From ghudson@mit.edu Thu Aug 1 07:19:21 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 23A3121E8202 for ; Thu, 1 Aug 2013 07:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.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 hcnUs2uvI2z5 for ; Thu, 1 Aug 2013 07:19:14 -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 59CC221E8150 for ; Thu, 1 Aug 2013 07:18:42 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-9e-51fa6e42ca16 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 26.15.02411.24E6AF15; Thu, 1 Aug 2013 10:18:42 -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 r71EIemc029354; Thu, 1 Aug 2013 10:18:40 -0400 Received: from [18.101.8.207] (vpn-18-101-8-207.mit.edu [18.101.8.207]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r71EIb5v003039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 10:18:38 -0400 Message-ID: <51FA6E3D.6040500@mit.edu> Date: Thu, 01 Aug 2013 10:18:37 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sam Hartman References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> 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+NgFuphleLIzCtJLcpLzFFi42IRYrdT13XK+xVo8H6OvMXXtgdsFkc3r2Kx +DF3EasDs8eSJT+ZPN7vu8rmsXLqafYA5igum5TUnMyy1CJ9uwSujDt/JjIWLGKqmL//CHsD 4yvGLkYODgkBE4lN9zW6GDmBTDGJC/fWs3UxcnEICexjlOh4tZkRJCEksIFRon1fEkTiMJPE 45/rwRK8AmoSSz8tZgOxWQRUJebvu8sMYrMJKEscPPuNBWSBqECIxNKT3BDlghInZz5hAbFF BNQlVl+axA5iMwsUSpzrmMMEUi4sYCSx43c9xKo5jBJTzz8Aq+cEWnXm8E8miEMlJRZN62SB 6NWReNf3gBnClpfY/nYO8wRGoVlI1s1CUjYLSdkCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealF uuZ6uZkleqkppZsYwYHuorKDsfmQ0iFGAQ5GJR5ei5xfgUKsiWXFlbmHGCU5mJREeS+ChPiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nwPtYAyvGmJFZWpRblw6SkOViUxHmfPT0bKCSQnliSmp2a WpBaBJOV4eBQkuCdnwvUKFiUmp5akZaZU4KQZuLgBBnOAzR8LkgNb3FBYm5xZjpE/hSjopQ4 7zyQhABIIqM0D64XloheMYoDvSLMuwykigeYxOC6XwENZgIanMoBNrgkESEl1cC4M3sRW/3U z7uj7RXlF/U8WrPG8J/gZOfVssn/17V8L/p1Yp1WoDen6q2/tpdZ9jsYsO+2/V60uulW7p8F D0z3Cnm/sDspprVFfdv2afP/5t0wKWsTZPY48IbrfuDsYs865weTChTqt3vKZX/M/ZBWbmXo 2FDHmDlrTyrz94cT9+QtXs3HxcesxFKckWioxVxUnAgA8OPTFh8DAAA= Cc: "kitten@ietf.org" , Zhanna Tsitkov , Simo Sorce Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 01 Aug 2013 14:19:21 -0000 On 08/01/2013 08:40 AM, Sam Hartman wrote: > Enctype is always explicit in Kerberos. Enctype has always been explicit for ciphertexts, not for checksums. Most of the time when we include a checksum in Kerberos, we include the cksumtype and specify what key should be used somehow. From Josh.Howlett@ja.net Thu Aug 1 08:53:32 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 E5E5A21E8195 for ; Thu, 1 Aug 2013 08:53:32 -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 xmBq2r4MklXj for ; Thu, 1 Aug 2013 08:53:26 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6021E8150 for ; Thu, 1 Aug 2013 08:53:22 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D2EAC4A6B9B_1FA846EB; Thu, 1 Aug 2013 15:53:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 9AB8E4A6B72_1FA846EF; Thu, 1 Aug 2013 15:53:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 16:53:18 +0100 From: Josh Howlett To: Nico Williams , "Henry B. Hotz" Thread-Topic: [kitten] PKCROSS Thread-Index: AQHOfn9BpOrz4y8paUKhaptjNcbaZ5lgBYOAgAAFcYCAAdsjAIAHJssAgBelVAA= Date: Thu, 1 Aug 2013 15:53:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, 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: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <62EC0A6208932847A3CAEB6D8E0286C3@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS 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, 01 Aug 2013 15:53:33 -0000 > >That's nice, for you :) But you should care about it. And we should >care about: a) making sysadmins' lives easier, b) removing the need >for them to know sensitive secret keys, c) scalability (see (a)), d) >removing the need for manual key rollover and outages during key >rollover. We might agree that we don't need e) LoF/TOFU, but I think >ABFAB is proof that we need something like it, and also, for a very >large Internet I think LoF/TOFU makes some sense, and indeed we see >some of that in TLS server PKI specifications like key/CA pinning, and >in browser plugins like CertPatrol. (Speaking as an individual) Personally I would argue that trust management strategies such as LoF and pinning are indicative of a poorly functioning trust system. They make sense only insofar that the other options are even worse. We should aspire to better.=20 Nico's PKCROSS draft looks really interesting. However I don't believe that, in practice, the use of DANE will provide a solution for "a very large Internet", unless KDC trust policies can be made congruent with DNS naming. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From nico@cryptonector.com Thu Aug 1 09:10: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 4776A21E80BE for ; Thu, 1 Aug 2013 09:10:01 -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 Hw3Mhf5FkslU for ; Thu, 1 Aug 2013 09:09:52 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7333611E810A for ; Thu, 1 Aug 2013 09:09:52 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 9A28DBC034 for ; Thu, 1 Aug 2013 09:09:49 -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=7gvmCwSOv6l83vvaRBST nIK5a58=; b=lqmjMZFHIgCE20Gpvv0atqYJqlWUJjo9Q3tHZfYM4bDSfHCapeYD dvS50zQR50g8qk8CC9s4v9hOISuQpOBAqQQt0/lu7w7MJfxbFA3EhCLEPEO+ZBKi R6fKG9/BiTfD+jXxo1h23GQRzK3x43DEnDUL2VxdlnQ0Ae7KyqOrSP8= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 2D7A1BC033 for ; Thu, 1 Aug 2013 09:09:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so2020760wib.10 for ; Thu, 01 Aug 2013 09:09:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=StqvdpTEmvmi/J8Z69sO1Amg7V579sarnhuCRX59ZGw=; b=LV45A586NdA3U+h73lPVLqVMGiFJZz+120NI6ehy+HdD1hSpZSCr4X8kIoQsVkAk7j RMbU8yJeBZ0EcnJHFOfDOaB6h3uulnmtkI0cS3tv8p6bfVXHS22uGZZLIIuQDYaZj0xe 5eFIGWfeUjS80Lem4kNW3GMURSeYopC1sqT/c5qL9GQ+hzfCNE7TFCmmJu0CrCDs2jyM 5dzfYkidQnPmbF8Yu4M96kOrqtzSJhIszxM9OlZS/wYEYJreKWDQ44WSWNLrkfOh04/Q pMRVduOmh128t3bOiT5Wnl5hD+IQGh2BlfgasRCmC75mAxTyHV2RXYlghKsx1Acg34qo eB/A== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr1756304wjc.90.1375373386547; Thu, 01 Aug 2013 09:09:46 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Thu, 1 Aug 2013 09:09:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 11:09:46 -0500 Message-ID: From: Nico Williams To: Josh Howlett Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS 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, 01 Aug 2013 16:10:03 -0000 On Thu, Aug 1, 2013 at 10:53 AM, Josh Howlett wrote: > (Speaking as an individual) > > Personally I would argue that trust management strategies such as LoF and > pinning are indicative of a poorly functioning trust system. They make > sense only insofar that the other options are even worse. We should aspire > to better. LoF/TOFU is not a central feature here. It's just a side benefit that one could do it. Pseudonymous authentication is at least as useful as anonymous authentication. > Nico's PKCROSS draft looks really interesting. However I don't believe > that, in practice, the use of DANE will provide a solution for "a very > large Internet", unless KDC trust policies can be made congruent with DNS > naming. If you want to scale to Internet scale then you kinda need trust policies that are congruent with the DNS. Now, that doesn't mean that you can't have islands of higher trust. For example, CRYPTONECTOR.COM might have various partners with manually-exchanged trust anchors. Principals in our respective realms would reject trust paths involving each other than do not use those manually-exchanged trust anchors. But if I wanted to access some AFS resource in some .edu, I could without having to manually exchange any sort of key material to make that possible -- that's what scalability requires. And I could, once I've authenticated a service in some realm that later becomes valuable to me, apply pinning techniques to increase trust in spite of having used DANE to start with (this is TOFUish). To me this is no different than ABFAB's approach to federation. If it's good for ABFAB, it's good for Kerberos. Nico -- From Josh.Howlett@ja.net Thu Aug 1 09:31:44 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 6454C21E8204 for ; Thu, 1 Aug 2013 09:31:44 -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 Zjw6vskF5O3B for ; Thu, 1 Aug 2013 09:31:38 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5972821E81FD for ; Thu, 1 Aug 2013 09:31:29 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 88EE91AF4304_1FA8D5AB; Thu, 1 Aug 2013 16:31:22 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 5483D1AF42F4_1FA8D5AF; Thu, 1 Aug 2013 16:31:22 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 17:31:22 +0100 From: Josh Howlett To: Nico Williams Thread-Topic: [kitten] PKCROSS Thread-Index: AQHOfn9BpOrz4y8paUKhaptjNcbaZ5lgBYOAgAAFcYCAAdsjAIAHJssAgBelVAD//+McAIAAJ4iA Date: Thu, 1 Aug 2013 16:31:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, 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: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <720BFDB873C7A3439BE553097D4AA1C7@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS 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, 01 Aug 2013 16:31:44 -0000 (Speaking as an individual) >> >>Personally I would argue that trust management strategies such as LoF and >> pinning are indicative of a poorly functioning trust system. They make >> sense only insofar that the other options are even worse. We should >>aspire >> to better. > >LoF/TOFU is not a central feature here. It's just a side benefit that >one could do it. Understood (as a "side feature" :-) >Pseudonymous authentication is at least as useful as anonymous >authentication. > >> Nico's PKCROSS draft looks really interesting. However I don't believe >> that, in practice, the use of DANE will provide a solution for "a very >> large Internet", unless KDC trust policies can be made congruent with >>DNS >> naming. > >If you want to scale to Internet scale then you kinda need trust >policies that are congruent with the DNS. Now, that doesn't mean that >you can't have islands of higher trust. Sure. But those "higher trust" islands get manifested using a different mechanism from the mechanism used to manifest the "baseline" trust. I would prefer a more consistent architecture that didn't require this distinction. >To me this is no different than ABFAB's approach to federation. If >it's good for ABFAB, it's good for Kerberos. Well, I disagree but let's not have that discussion here :-) Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From Josh.Howlett@ja.net Thu Aug 1 09:52:01 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 9898621E81FE for ; Thu, 1 Aug 2013 09:51:57 -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 tcuTrn6oCF9V for ; Thu, 1 Aug 2013 09:51:40 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 967C921E80BF for ; Thu, 1 Aug 2013 09:51:35 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2068320C7126_1FA9215B; Thu, 1 Aug 2013 16:51:33 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id F122920C710D_1FA9213F; Thu, 1 Aug 2013 16:51:31 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 17:51:31 +0100 From: Josh Howlett To: Josh Howlett , Nico Williams Thread-Topic: [kitten] PKCROSS Thread-Index: AQHOfn9BpOrz4y8paUKhaptjNcbaZ5lgBYOAgAAFcYCAAdsjAIAHJssAgBelVAD//+McAIAAJ4iAgAAFoQA= Date: Thu, 1 Aug 2013 16:51:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, 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: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS 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, 01 Aug 2013 16:52:01 -0000 I wrote: >>To me this is no different than ABFAB's approach to federation. If >>it's good for ABFAB, it's good for Kerberos. > >Well, I disagree but let's not have that discussion here :-) Let me clarify: you are correct for extant trust management mechanisms for AAA infrastructures that are standardised today. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From nico@cryptonector.com Thu Aug 1 10:27: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 2132911E8131 for ; Thu, 1 Aug 2013 10:27:11 -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=[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 2xAYq671Q5s2 for ; Thu, 1 Aug 2013 10:27:06 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E13C511E80F9 for ; Thu, 1 Aug 2013 10:27:02 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 62829584059 for ; Thu, 1 Aug 2013 10:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=lMveWQ4AZPbtE1tXp8jANgDnaAc=; b=qjzheOZJhhC B6spZWFR02AZE9deyG/mu3OWXduk/3GNIolHE44WoUqpy2XFJoiI0dZy9sXNfZe2 aUZoHMBXMrWKjqXuOQZVZqAqDWvlHz+SFm7Ja9ZBMe2GNUAtJjD5wm1xsN9XT6Xd NIM4yiU2o0hjXTIRbkfToIN9oqdZdyX8= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 464F7584058 for ; Thu, 1 Aug 2013 10:27:00 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m46so1949997wev.36 for ; Thu, 01 Aug 2013 10:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=CiE+0BFknozjUaKecOo1+BtVCLZ33KsLJ0GeiYIR0II=; b=OzBVJC6ab7Z9d6ie9wmDTS/Hi/onwRmurDAlBjaVLLt6Eqh4dOaP/EawDRP7gOtgKL R2WL8tnxXrC0ySCtP5NAzg7Adw0DY3trFs0ieiU4pk91fH157F/nJhvUJuEgEOSAhLZP ApyR8Gwtbh9cM7r/Xue3PVTA8fiAVe2DaUlGwVu3Z6q/wJPpRFsIQo3zIJiPxKDl+rGZ IneSVKVdXOnnpLKNhJxrqjjsuDCo5kmkPeJcwcOJQbzolUFtA/SVWA7jBKf7MW53jUmm 4Hp2LNxJztIWU3pm5MOLzhFdhpgz5tWH3ZoXyj6pMrrgJ3HZPhOKiSMY3/hGQkoY4WyA 5lbg== MIME-Version: 1.0 X-Received: by 10.180.10.99 with SMTP id h3mr8031525wib.0.1375378018507; Thu, 01 Aug 2013 10:26:58 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Thu, 1 Aug 2013 10:26:58 -0700 (PDT) Date: Thu, 1 Aug 2013 12:26:58 -0500 Message-ID: From: Nico Williams To: Josh Howlett Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: [kitten] On TOFU and metaphysics (Re: PKCROSS) 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, 01 Aug 2013 17:27:11 -0000 On Thu, Aug 1, 2013 at 11:31 AM, Josh Howlett wrote: >>LoF/TOFU is not a central feature here. It's just a side benefit that >>one could do it. > > Understood (as a "side feature" :-) I don't see how any PK-based protocol fails to have this feature, whether anyone likes it or not (think: how many SSL/TLS implementations have failed to do thorough certificate validation? and even when they do, how many CAs have lied or been subverted?). There's little point in pointing out that there are many cases where LoF/TOFU is undesirable :( And TOFU is a useful side feature. I'd rather have it than not. And there are real use cases for it. But we'd get it no matter what. So I score it as a plus. Philosophically, TOFU is all we naturally have, and any TTP system is just an attempt to scale up, with trust inversely proportional to the size of the world you want to scale to, asymptotically approaching zero. >>If you want to scale to Internet scale then you kinda need trust >>policies that are congruent with the DNS. Now, that doesn't mean that >>you can't have islands of higher trust. > > Sure. But those "higher trust" islands get manifested using a different > mechanism from the mechanism used to manifest the "baseline" trust. I > would prefer a more consistent architecture that didn't require this > distinction. Nothing requires that anyone's baseline be 'scale to the whole Internet'. The protocol does not (must not) dictate trust baselines; I'd not propose otherwise. >>To me this is no different than ABFAB's approach to federation. If >>it's good for ABFAB, it's good for Kerberos. > > Well, I disagree but let's not have that discussion here :-) OK, sure, but then you say "you are correct for extant trust management mechanisms for AAA infrastructures that are standardised today", so which is it, and how could ABFAB do better? :) (that's rhetorical -- see below) If you want to scale up trust infrastructure to the whole Internet then you have to accept that some trust paths will be iffy. It's an unavoidable fact of nature. It's not even a shortcoming of PK crypto. Authentication and identification are metaphysical problems. "Papers" and cryptographic equivalents are nothing more than a trusted-third-party protocol for authentication/identification, subject to all the usual problems, on-line and off. Off-line we *all* practice TOFU every time we meet someone new. We happen to have great biometric authentication devices that are difficult to spoof, but so what? We aren't omniscient, we don't know our peers' past; any background checks are necessarily costly and imperfect, therefore the vast majority of the time we use our also-amazing memories (in conjunction with our senses) in a TOFU manner. It should not surprise us that on-line it's the same, but worse: because our natural biometric devices don't work on-line and because we have so many more peers on-line. TOFU and TTP -- that's all we have, and all we can ever hope to manage. Nico -- From jhutz@cmu.edu Thu Aug 1 11: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 467D611E8138 for ; Thu, 1 Aug 2013 11:44:29 -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 C8V7RFJVJ9pQ for ; Thu, 1 Aug 2013 11:44:23 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 4782911E80F3 for ; Thu, 1 Aug 2013 11:44:23 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r71IiGgk026795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 14:44:16 -0400 (EDT) Message-ID: <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Simo Sorce Date: Thu, 01 Aug 2013 14:44:16 -0400 In-Reply-To: <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: "kitten@ietf.org" , Sam Hartman , Zhanna Tsitkov , jhutz@cmu.edu Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 01 Aug 2013 18:44:29 -0000 On Thu, 2013-08-01 at 08:53 -0400, Simo Sorce wrote: > On Thu, 2013-08-01 at 08:40 -0400, Sam Hartman wrote: > > *blink* > > why do we ever want to make enctype optional even it can be inferred? > > We've never done that before that I am aware of. > > Enctype is always explicit in Kerberos. > > The reasoning was that the KDC krbtgt has only ever one enctype so we do > not need to provide it. I was not totally convinced at first, but it > saves a few bytes so I am ok if others agree. > If you feel strongly that it would be an error I am also ok making it > mandatory. Basically I do not have a problem either way. I think agree with Sam here. The enctype should always be explicit. There is no requirement in the spec or protocol that krbtgt or any other principal only have keys of one enctype. -- Jeff From Josh.Howlett@ja.net Thu Aug 1 14:19:24 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 8E63221E828B for ; Thu, 1 Aug 2013 14:19:24 -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 0AOnOjC6ahK5 for ; Thu, 1 Aug 2013 14:19:11 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id F1D0521E826C for ; Thu, 1 Aug 2013 14:14:41 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 060191B4E6A8_1FACC3CB; Thu, 1 Aug 2013 20:59:40 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 764E71B4E66C_1FACC3BF; Thu, 1 Aug 2013 20:59:39 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 21:59:32 +0100 From: Josh Howlett To: Nico Williams Thread-Topic: On TOFU and metaphysics (Re: PKCROSS) Thread-Index: AQHOjtxcuTFhiVcy+0q9mk0yXckvTJmA5vyA Date: Thu, 1 Aug 2013 20:59:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, 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: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <59EF076CDE4BDE42B44D108D75FB3AE1@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] On TOFU and metaphysics (Re: PKCROSS) 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, 01 Aug 2013 21:19:24 -0000 > >If you want to scale up trust infrastructure to the whole Internet >then you have to accept that some trust paths will be iffy. It's an >unavoidable fact of nature. It's not even a shortcoming of PK crypto. I agree with everything you say. There is, as you suggest, a spectrum of iffy-ness and I certainly have no interest in eradicating or normalising the natural iffy-ness that is inherent in different kinds of social relations. I'm simply arguing that, for the spectrum of iffy-ness, we should seek consistency in how we technically manage it, for as many trust paths as possible, such that we can accommodate the spectrum of paths (iffy or otherwise) within an operational framework that is usable for administrators and users. >TOFU and TTP -- that's all we have, and all we can >ever hope to manage. Amen! Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From nico@cryptonector.com Thu Aug 1 14:40: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 5F54F11E8231 for ; Thu, 1 Aug 2013 14:40:14 -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=[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 hK4UqF1e9RfY for ; Thu, 1 Aug 2013 14:40:02 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id DBFED11E81B7 for ; Thu, 1 Aug 2013 14:23:16 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 8D14740122425 for ; Thu, 1 Aug 2013 14:23:16 -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=Lq3+uXjL4aQXT/os0it1 41dwk6A=; b=AVEcjuQMpJOCiBC1A6Tb2uRM5/F3Ts8Cpc7ZFX+UemkqpGfRQXnc IL2Hxco6r0XM5dPchb438sTHmjweH6eK9Dh0eyzNUwCkhwqyW57IeixBTNuDSQJn DMlVyBfmtXrG+ics2ZSQlJI7WSx2yIaBFCtqS0WrqFxBkOAojUuHWtE= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 3CD0240122422 for ; Thu, 1 Aug 2013 14:23:16 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so55952wib.11 for ; Thu, 01 Aug 2013 14:23:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HLiTdfVpH7IRpRIaUeHtfMdCAdoXX0P95rYuJWR8Xvc=; b=UBZ3/fJqFSjiutuoVAI/pNmSTj6bLWCbxqpRBGSnGV366NZu/6SIa4X30B/tEN3DR3 plf9hwGO+b8GJpnk284Bo/zxvRQIYzKI3tjObF0Db5RHN4wqyrpHvWGeHHFxfMWYJkcU mm7M+raeIcFMhuJ9PE0sJno6cQGd+Pw/6e0L0WMkyj0uHK/yOAt+mYEKceKgdqU4qOYG g/F1hmTODEElzyFToQoduxck3wCiYaQ3utuzbM3wBI+Knqp7UXRSGd9h/7LY2mPcm49y yotgKuoyA8PlaBNc0MLwml/+kDgeOq7zfTjqLU5acyGXiZGYJheXf8qSNAPmlRFeKlPj TgZw== MIME-Version: 1.0 X-Received: by 10.180.95.133 with SMTP id dk5mr6455566wib.33.1375392194785; Thu, 01 Aug 2013 14:23:14 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Thu, 1 Aug 2013 14:23:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 16:23:14 -0500 Message-ID: From: Nico Williams To: Josh Howlett Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] On TOFU and metaphysics (Re: PKCROSS) 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, 01 Aug 2013 21:40:20 -0000 On Thu, Aug 1, 2013 at 3:59 PM, Josh Howlett wrote: >>If you want to scale up trust infrastructure to the whole Internet >>then you have to accept that some trust paths will be iffy. It's an >>unavoidable fact of nature. It's not even a shortcoming of PK crypto. > > I agree with everything you say. There is, as you suggest, a spectrum of > iffy-ness and I certainly have no interest in eradicating or normalising > the natural iffy-ness that is inherent in different kinds of social > relations. I'm simply arguing that, for the spectrum of iffy-ness, we > should seek consistency in how we technically manage it, for as many trust > paths as possible, such that we can accommodate the spectrum of paths > (iffy or otherwise) within an operational framework that is usable for > administrators and users. I don't want a separate protocol for each use case. This is how we've ended up with a mess of protocols that must all be deployed concurrently and at great cost. The whole point of GSS and SASL is to abstract away those protocols so that users can use the ones most appropriate to them. But then too, the whole point of Kerberos pluggable pre-auth (PKINIT, OTP, ...) and kx509, and other bridges, is that we need to be able to reuse existing infrastructure. Closing the door to some feature in one protocol is not a proper substitute for lack of policy/UI. Implementations need to fail safe in the absence of suitable policies/UIs, of course, and that's the correct answer here. Nico -- From nico@cryptonector.com Thu Aug 1 14:40:35 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 06DDC11E817F for ; Thu, 1 Aug 2013 14:40:35 -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 MDXlI+mdE4-k for ; Thu, 1 Aug 2013 14:40:21 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0485911E81B0 for ; Thu, 1 Aug 2013 14:24:15 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id C50512F4071 for ; Thu, 1 Aug 2013 14:24:14 -0700 (PDT) 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-a63.g.dreamhost.com (Postfix) with ESMTPSA id 707DC2F4059 for ; Thu, 1 Aug 2013 14:24:14 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so2186460wes.31 for ; Thu, 01 Aug 2013 14:24:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BbHJ90CpTaIcW2QB6vhiQP0S/G4voyHQUy4JAZWdFKk=; b=eezkOFoX54xLhAzWgcNG5/c5XJ1pscAULxBh/Vm23vvM9rpna4/zzYq66GKtkGq3tF k++rfa0EockL+YXcc3Clu2KVkA0+EXha75mhRuwg+qCCgIXvV98ZztEMR2DNf4/yup9K IeWyTJJbOhn36yA5sFrSrD0B8lHXec41MVw+fjHQsGFqcTwVX456uzyufQg96OolBlPW tcBoqjNp0X/RgIyZv2OpFeEN1IpIYQ1bhCkRUnefni20pVt6u6CesfzlOpI9trFj5oTE qvnjAm8/yR1pBbrxPQ+/HkD2ZS5eo7jM3/wxHltQ7PjF43i4zlMKUNbA8Djsv+b0Zkhe o9zQ== MIME-Version: 1.0 X-Received: by 10.180.95.133 with SMTP id dk5mr6457595wib.33.1375392253093; Thu, 01 Aug 2013 14:24:13 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Thu, 1 Aug 2013 14:24:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 16:24:13 -0500 Message-ID: From: Nico Williams To: Josh Howlett Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] On TOFU and metaphysics (Re: PKCROSS) 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, 01 Aug 2013 21:40:36 -0000 On Thu, Aug 1, 2013 at 4:23 PM, Nico Williams wrote: > The whole point of GSS and SASL is to abstract away those protocols so > that users can use the ones most appropriate to them. But then too, > the whole point of Kerberos pluggable pre-auth (PKINIT, OTP, ...) and > kx509, and other bridges, is that we need to be able to reuse existing > infrastructure. I should also add that protocols/bridges that allow for infrastructure reuse are also easier to deploy/invest in than ones that don't. From tlyu@mit.edu Thu Aug 1 18:18:40 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 03B2211E81E2 for ; Thu, 1 Aug 2013 18:18:40 -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 ktlP2KxbApAB for ; Thu, 1 Aug 2013 18:18:26 -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 C3D7F21F8C72 for ; Thu, 1 Aug 2013 17:18:42 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-d9-51fafae1aa22 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FA.C2.02471.1EAFAF15; Thu, 1 Aug 2013 20:18:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r720IbAX019884; Thu, 1 Aug 2013 20:18:38 -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 r720IYr4006386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 20:18:36 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r720IX7t021575; Thu, 1 Aug 2013 20:18:33 -0400 (EDT) To: Jeffrey Hutzelman References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> From: Tom Yu Date: Thu, 01 Aug 2013 20:18:33 -0400 In-Reply-To: <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 01 Aug 2013 14:44:16 -0400") Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1n3461egQfMPI4uvbQ/YLK6/P8du cXTzKhaLH3MXsTqweOxvPcbqsWTJTyaP9/uusnmsnHqaPYAlissmJTUnsyy1SN8ugSvj5bop rAWfOCo+Lt3H1MD4l62LkZNDQsBEYnnjXnYIW0ziwr31YHEhgX2MEudeq3cxcgHZGxglbnyY xwzhnGWSeDu1jRHC6WSUmHujnRWkRURAVeLenFksIAlmgWmMEjsWfwKay8EhLGAkseN3PUTD SiaJDesXsIDE2QSkJY4uLgPpZQHq3X2xD2wDp0ATo8TCy//B7uAVsJBY1XmBFaSeR4BTYtKC ZIiwoMTJmU9YQGxmAS2JG/9eMk1gFJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQi XWO93MwSvdSU0k2M4JCW5NvB+PWg0iFGAQ5GJR5ei5xfgUKsiWXFlbmHGCU5mJREeU99Agrx JeWnVGYkFmfEF5XmpBYfYpTgYFYS4f0zGyjHm5JYWZValA+TkuZgURLnffb0bKCQQHpiSWp2 ampBahFMVoaDQ0mCN+snUKNgUWp6akVaZk4JQpqJgxNkOA/Q8DUgNbzFBYm5xZnpEPlTjIpS 4rzHQRICIImM0jy4XljKecUoDvSKMO86kCoeYLqC634FNJgJaLDSHLDBJYkIKakGxvj36oZK /xd+XKv166D1ZRdFDsOys12muZk32AvvRHCJt119cOp5W45oU8WDvwJBTtLygWfVs0VYkoKy Yppu8Ey68GjJA6Hdp6/Ut2TevH8gvYrJ79jOUwvK7Xhi9ir+FJFbu/7pFOcXF0K35mwqOzwr lsHh36F9049tY/jJeH9i0o834lc+PFJiKc5INNRiLipOBAChYMs8FAMAAA== Cc: "kitten@ietf.org" , Sam Hartman , Zhanna Tsitkov , Simo Sorce Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 02 Aug 2013 01:18:40 -0000 Jeffrey Hutzelman writes: > On Thu, 2013-08-01 at 08:53 -0400, Simo Sorce wrote: >> On Thu, 2013-08-01 at 08:40 -0400, Sam Hartman wrote: >> > *blink* >> > why do we ever want to make enctype optional even it can be inferred? >> > We've never done that before that I am aware of. >> > Enctype is always explicit in Kerberos. >> >> The reasoning was that the KDC krbtgt has only ever one enctype so we do >> not need to provide it. I was not totally convinced at first, but it >> saves a few bytes so I am ok if others agree. >> If you feel strongly that it would be an error I am also ok making it >> mandatory. Basically I do not have a problem either way. > > I think agree with Sam here. The enctype should always be explicit. > There is no requirement in the spec or protocol that krbtgt or any other > principal only have keys of one enctype. On the other hand, AD-KDCIssued does not have an enctype, because the key for the checksum is implicitly the same as the one the KDC used to encrypt the ticket. This is a precedent for omitting the enctype when it should be obvious from context. From ghudson@mit.edu Thu Aug 1 18:27:21 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 5314511E8257 for ; Thu, 1 Aug 2013 18:27:21 -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 PqQahkuLYyOc for ; Thu, 1 Aug 2013 18:27:08 -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 DB21711E839F for ; Thu, 1 Aug 2013 17:27:46 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-e4-51fafd01356d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 39.DB.02411.20DFAF15; Thu, 1 Aug 2013 20:27:46 -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 r720Rhgw020531; Thu, 1 Aug 2013 20:27:43 -0400 Received: from [18.101.8.67] (vpn-18-101-8-67.mit.edu [18.101.8.67]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r720ReF0008357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 20:27:41 -0400 Message-ID: <51FAFCFC.3010804@mit.edu> Date: Thu, 01 Aug 2013 20:27:40 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixCmqrMv091egwZbNzBZf2x6wWVx/f47d 4ujmVSwWP+YuYnVg8djfeozVY8mSn0we7/ddZfNYOfU0ewBLFJdNSmpOZllqkb5dAlfG1O3t rAUtHBU9uy+wNTDuZeti5OSQEDCRuLf1OpQtJnHh3nogm4tDSGAfo8SVvdeYIJwNjBLXrl9n BqkSEjjAJHHssC+IzSugJnFkxTvGLkYODhYBVYmezxwgYTYBZYmDZ7+xgIRFBUIklp7khqgW lDg58wkLiC0CVH1vziwWkPHMAtMYJaYdWAxWLyxgJLHjdz3E2oVMEn+3/2UCaeAUsJdY0dnC CnGopMSiaZ1gg5gFdCTe9T1ghrDlJba/ncM8gVFoFpJ9s5CUzUJStoCReRWjbEpulW5uYmZO cWqybnFyYl5eapGuuV5uZoleakrpJkZQ+LO7qOxgbD6kdIhRgINRiYdX4tmvQCHWxLLiytxD jJIcTEqivKc+AYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8P6ZDZTjTUmsrEotyodJSXOwKInz Pnt6NlBIID2xJDU7NbUgtQgmK8PBoSTBe+A3UKNgUWp6akVaZk4JQpqJgxNkOA/QcE+QGt7i gsTc4sx0iPwpRkUpcV6vP0AJAZBERmkeXC8sPb1iFAd6RZg3CaSKB5ja4LpfAQ1mAhqsNAds cEkiQkqqgZF5fZzpsm2XrbkcrBbmbwqYPe/D5klZ8zpmpO7P5pWeaBq/5US3kfvvMuM5/enF HMH+v+Tt2Yo2TCzwmm386XnsXN5dX2PuNEdJMc9S1OZQqr2YITrzTntx8eG28BVVn5fpnvco +VmQZLbyskjfjrnSwZ1r+aZpn93/033eLuvJ358a6PtkP1ViKc5INNRiLipOBAAUGDtDKgMA AA== Cc: "kitten@ietf.org" , Sam Hartman , Zhanna Tsitkov , Simo Sorce Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 02 Aug 2013 01:27:21 -0000 On 08/01/2013 02:44 PM, Jeffrey Hutzelman wrote: > I think agree with Sam here. The enctype should always be explicit. > There is no requirement in the spec or protocol that krbtgt or any other > principal only have keys of one enctype. I don't see how that's relevant. A KDC implementation would omit the enctype in the KDC verifier because it thinks it can deduce the enctype (by always using the first key, for instance), not because it assumes there is only one enctype in the krbtgt principal. To expand on what I said before, it's disingenuous to call this a departure from current practice because "the enctype is always explicit in Kerberos." The enctype is always explicit in ciphertext because it specifies the kind of encryption operation which was used to generate the ciphertext. In this case, the enctype would be there for a different purpose (key identification), and it is not normal practice in Kerberos to include an enctype with a checksum if the key can be identified without one. From kwburgi@tycho.ncsc.mil Fri Aug 2 05:31: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 6C07E11E82B9 for ; Fri, 2 Aug 2013 05:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, 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 09Ug+kCxzdtw for ; Fri, 2 Aug 2013 05:30:58 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 68CAC11E81A5 for ; Fri, 2 Aug 2013 05:30:55 -0700 (PDT) X-TM-IMSS-Message-ID: <9e6ee0f30002fbc8@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 9e6ee0f30002fbc8 ; Fri, 2 Aug 2013 08:36:06 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r72CUoet023762; Fri, 2 Aug 2013 08:30:50 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kelley Burgin In-Reply-To: <51FA6DE2.2050708@mit.edu> Date: Fri, 2 Aug 2013 08:32:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> To: Sam Hartman X-Mailer: Apple Mail (2.1503) Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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: Fri, 02 Aug 2013 12:31:13 -0000 Sam, I understand you've set the bar high for moving to CBC+padding from CTS = mode. I believe we can provide the necessary justifications and = assurance to move to CBC+padding, but I'm still unclear what the actual = hurdles are.=20 Would you provide your concerns? In particular, I'd like to hear the = reason for limiting variable expansion to 8 bytes (your point 3 below). = Seems like the reasons I can imagine are no longer relevant. Kelley On Aug 1, 2013, at 10:17 AM, Greg Hudson wrote: > On 08/01/2013 08:38 AM, Sam Hartman wrote: >> 1) we have not evaluated CTR mode. We looked at CCM and GCM, but have >> not looked at CTR with an HMAC. >> Just pointing out that we have not thoroughly considered the options. >=20 > If I understand how CTR+HMAC would work, the same problems exist for > CTR+HMAC as for CCM: the 128-bit block size of AES is not big enough = for > a random nonce and a block counter, given the requirements for maximum > message size and the requirements for confidence of nonce uniqueness. >=20 >> 2) You don't need to implement the short plaintext special case if = you >> implement Kerberos and GSS-API. You need to implement it only if = you >> expose a general RFC 3961 API and choose to support short plaintexts = in >> that that API. >=20 > I don't think that's an interesting fact for my MIT krb5, and I would > speculate that it's not interesting fact for any Kerberos > implementation. This is a 3961 enctype, and if we implement it, we > would want to implement it generally. We have internal uses of 3961 > which involve short plaintexts, and we know of other 3961 consumers = such > as OpenAFS. >=20 >> 3) Speaking as someone involved at the time, making sure that no more >> than 8 bytes of expansion were included in the AES enctypes was a >> critical consideration to gaining consensus and to developing RFC = 4121. >=20 > [Sam clarified online that he meant no more than 8 bytes of variable > expansion; fixed expansion beyond 8 bytes is okay. I think he may = have > meant 3962 rather than 4121.] >=20 > I would welcome additional information on this. I am not at all > comfortable with the position that, essentially, the burden of proof = is > on anyone who doesn't want to meet this technical requirement, the > rationale for which has never been concretely described on the mailing > list. When we searched the archives for discussion of the rationale = for > CTS in RFC 3962, all we found is suggestions from Ken that it would = save > some space (which was also presumably the reason for truncating the = HMAC > to 96 bits). >=20 > Also, I would like a clarification on Sam's earlier statement (July = 17) > that: >=20 >> We're at a point in the process where the presumption is that we will >> not make a given change unless consensus is demonstrated to make the >> change. >=20 > Was there a WG last call on this draft? (I wasn't able to find one in > the archives, but I think Sam mentioned a "second last call" at some > point during the meeting.) When did it reach this point in the = process > if not? >=20 From lha@h5l.org Fri Aug 2 05:41:27 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 7105811E8321 for ; Fri, 2 Aug 2013 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3] 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 pbWl10TCJIDo for ; Fri, 2 Aug 2013 05:41:22 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE011E8319 for ; Fri, 2 Aug 2013 05:41:20 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 5FE9320F5; Fri, 2 Aug 2013 14:41:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([130.237.48.192]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 6l9TcLmqj6Ms; Fri, 2 Aug 2013 14:41:14 +0200 (CEST) X-KTH-Auth: lha [79.102.62.78] X-KTH-mail-from: lha@h5l.org Received: from [192.168.0.51] (c-4f663e4e-74736162.cust.telenor.se [79.102.62.78]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id C79B95F8; Fri, 2 Aug 2013 14:41:11 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC7BF25D-8164-4E75-9E43-0C475022B032" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1786\)) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> Date: Fri, 2 Aug 2013 14:41:09 +0200 Message-Id: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> To: Kelley Burgin X-Mailer: Apple Mail (2.1786) X-Mailman-Approved-At: Fri, 02 Aug 2013 13:30:55 -0700 Cc: kitten@ietf.org, Sam Hartman , Jeffery Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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: Fri, 02 Aug 2013 12:41:27 -0000 --Apple-Mail=_BC7BF25D-8164-4E75-9E43-0C475022B032 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Kelly, Legacy DCE-RPC appellations that didn=92t query unlaying DCE crypto = layer to see what the padding layer is and just sent in 8 as a = padding/extra block, since that worked with both DES and RC4. You better ask the msft folks if this still is an issue. Love 2 aug 2013 kl. 14:32 skrev Kelley Burgin : > Sam, >=20 > I understand you've set the bar high for moving to CBC+padding from = CTS mode. I believe we can provide the necessary justifications and = assurance to move to CBC+padding, but I'm still unclear what the actual = hurdles are.=20 >=20 > Would you provide your concerns? In particular, I'd like to hear the = reason for limiting variable expansion to 8 bytes (your point 3 below). = Seems like the reasons I can imagine are no longer relevant. >=20 > Kelley >=20 > On Aug 1, 2013, at 10:17 AM, Greg Hudson wrote: >=20 >> On 08/01/2013 08:38 AM, Sam Hartman wrote: >>> 1) we have not evaluated CTR mode. We looked at CCM and GCM, but = have >>> not looked at CTR with an HMAC. >>> Just pointing out that we have not thoroughly considered the = options. >>=20 >> If I understand how CTR+HMAC would work, the same problems exist for >> CTR+HMAC as for CCM: the 128-bit block size of AES is not big enough = for >> a random nonce and a block counter, given the requirements for = maximum >> message size and the requirements for confidence of nonce uniqueness. >>=20 >>> 2) You don't need to implement the short plaintext special case if = you >>> implement Kerberos and GSS-API. You need to implement it only if = you >>> expose a general RFC 3961 API and choose to support short plaintexts = in >>> that that API. >>=20 >> I don't think that's an interesting fact for my MIT krb5, and I would >> speculate that it's not interesting fact for any Kerberos >> implementation. This is a 3961 enctype, and if we implement it, we >> would want to implement it generally. We have internal uses of 3961 >> which involve short plaintexts, and we know of other 3961 consumers = such >> as OpenAFS. >>=20 >>> 3) Speaking as someone involved at the time, making sure that no = more >>> than 8 bytes of expansion were included in the AES enctypes was a >>> critical consideration to gaining consensus and to developing RFC = 4121. >>=20 >> [Sam clarified online that he meant no more than 8 bytes of variable >> expansion; fixed expansion beyond 8 bytes is okay. I think he may = have >> meant 3962 rather than 4121.] >>=20 >> I would welcome additional information on this. I am not at all >> comfortable with the position that, essentially, the burden of proof = is >> on anyone who doesn't want to meet this technical requirement, the >> rationale for which has never been concretely described on the = mailing >> list. When we searched the archives for discussion of the rationale = for >> CTS in RFC 3962, all we found is suggestions from Ken that it would = save >> some space (which was also presumably the reason for truncating the = HMAC >> to 96 bits). >>=20 >> Also, I would like a clarification on Sam's earlier statement (July = 17) >> that: >>=20 >>> We're at a point in the process where the presumption is that we = will >>> not make a given change unless consensus is demonstrated to make the >>> change. >>=20 >> Was there a WG last call on this draft? (I wasn't able to find one = in >> the archives, but I think Sam mentioned a "second last call" at some >> point during the meeting.) When did it reach this point in the = process >> if not? >>=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_BC7BF25D-8164-4E75-9E43-0C475022B032 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Kelly,

Legacy DCE-RPC = appellations that didn=92t query unlaying DCE crypto layer to see what = the padding layer is and just sent in 8 as a padding/extra block, since = that worked with both DES and RC4.

You better = ask the msft folks if this still is an = issue.

Love


2 = aug 2013 kl. 14:32 skrev Kelley Burgin <kwburgi@tycho.ncsc.mil>:
Sam,

I understand you've set the = bar high for moving to CBC+padding from CTS mode. I believe we can = provide the necessary justifications and assurance to move to = CBC+padding, but I'm still unclear what the actual hurdles are. 

Would you provide = your concerns? In particular, I'd like to hear the reason for limiting = variable expansion to 8 bytes (your point 3 below). Seems like the = reasons I can imagine are no longer relevant.

Kelley

On = Aug 1, 2013, at 10:17 AM, Greg Hudson <ghudson@MIT.EDU> = wrote:

On 08/01/2013 08:38 AM, Sam = Hartman wrote:
1) we have not evaluated CTR = mode. We looked at CCM and GCM, but have
not looked at CTR with an = HMAC.
Just pointing out that we have not thoroughly considered the = options.

If I understand how CTR+HMAC would work, = the same problems exist for
CTR+HMAC as for CCM: the 128-bit block = size of AES is not big enough for
a random nonce and a block counter, = given the requirements for maximum
message size and the requirements = for confidence of nonce uniqueness.

2) = You don't need to implement the short plaintext special case if = you
implement Kerberos and GSS-API.  You need  to implement = it only if you
expose a general RFC 3961 API and choose to support = short plaintexts in
that that API.

I don't think = that's an interesting fact for my MIT krb5, and I would
speculate = that it's not interesting fact for any Kerberos
implementation. =  This is a 3961 enctype, and if we implement it, we
would want = to implement it generally.  We have internal uses of 3961
which = involve short plaintexts, and we know of other 3961 consumers such
as = OpenAFS.

3) Speaking as someone = involved at the time, making sure that no more
than 8 bytes of = expansion were included in the AES enctypes was a
critical = consideration to gaining consensus and to developing RFC = 4121.

[Sam clarified online that he meant no more = than 8 bytes of variable
expansion; fixed expansion beyond 8 bytes is = okay.  I think he may have
meant 3962 rather than = 4121.]

I would welcome additional information on this.  I am = not at all
comfortable with the position that, essentially, the = burden of proof is
on anyone who doesn't want to meet this technical = requirement, the
rationale for which has never been concretely = described on the mailing
list.  When we searched the archives = for discussion of the rationale for
CTS in RFC 3962, all we found is = suggestions from Ken that it would save
some space (which was also = presumably the reason for truncating the HMAC
to 96 = bits).

Also, I would like a clarification on Sam's earlier = statement (July 17)
that:

We're at a = point in the process where the presumption is that we will
not make a = given change unless consensus is demonstrated to make = the
change.

Was there a WG last call on this = draft?  (I wasn't able to find one in
the archives, but I think = Sam mentioned a "second last call" at some
point during the meeting.) =  When did it reach this point in the process
if = not?


_____________________________________________= __
Kitten mailing list
Kitten@ietf.org
https://www.ietf.or= g/mailman/listinfo/kitten

= --Apple-Mail=_BC7BF25D-8164-4E75-9E43-0C475022B032-- From kaduk@mit.edu Mon Aug 5 08:47: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 4AD8421E80E5 for ; Mon, 5 Aug 2013 08:47:43 -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 779VZMqTGlHj for ; Mon, 5 Aug 2013 08:47:37 -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 2E91821E80C0 for ; Mon, 5 Aug 2013 08:47:23 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-de-51ffc907c7b9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 42.80.02411.709CFF15; Mon, 5 Aug 2013 11:47:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r75FlItw003747; Mon, 5 Aug 2013 11:47:19 -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 r75FlGGb008673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 11:47:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r75FlGg8025433; Mon, 5 Aug 2013 11:47:16 -0400 (EDT) Date: Mon, 5 Aug 2013 11:47:16 -0400 (EDT) From: Benjamin Kaduk To: Thomas L Yu In-Reply-To: <20130225234150.5714.90921.idtracker@ietfa.amsl.com> Message-ID: References: <20130225234150.5714.90921.idtracker@ietfa.amsl.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+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrMt+8n+gwcpfyhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuqOPvaCl7wVd+deYW5g/MPVxcjJISFgIvHu/W52CFtM4sK9 9WxdjFwcQgL7GCUeLXrJDuFsYJR49nMrE4RzkEni1aFvzCAtQgL1EodP7gZKcHCwCGhJbPoB NpVNQEVi5puNbCC2iICcxMX9B1lAbGYBYYn152Ywg5QLC4RKvL/OCRLmFHCUWHpjBdgRvED2 ss0PoaY7SHy8948VxBYV0JFYvX8KC0SNoMTJmU+gRlpK/Fv7i3UCo+AsJKlZSFILGJlWMcqm 5Fbp5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBIUku4vKDsbmQ0qHGAU4GJV4eBXY/wcK sSaWFVfmHmKU5GBSEuVlOwgU4kvKT6nMSCzOiC8qzUktPsQowcGsJMI7fwtQjjclsbIqtSgf JiXNwaIkzvvs6dlAIYH0xJLU7NTUgtQimKwMB4eSBO/L40CNgkWp6akVaZk5JQhpJg5OkOE8 QMPfgNTwFhck5hZnpkPkTzEqSonzngFJCIAkMkrz4HphKeMVozjQK8K8l0CqeIDpBq77FdBg JqDBJj//ggwuSURISTUw5mR/FJeP+vxANYzFpjSCV1S6Zqeo7lO/wq+8baFKnSsKiu4IpNb6 7TL50NVoqJZ8p0N4vvbKdzbCK9s4w5oNZL99y9KoXHu+fE+AaOkLVaZtBXvMT82dPjeKq2lK 0+wDRzKOKZmITbu+vYjj/xbhsz9WbW6f0r4r9/BkcWblt4kTO/wr5bSVWIozEg21mIuKEwED E+GD9AIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-kerberos-iana-registries-01.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, 05 Aug 2013 15:47:43 -0000 On Mon, 25 Feb 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Move Kerberos protocol parameter registries to IANA > Author(s) : Tom Yu > Filename : draft-ietf-kitten-kerberos-iana-registries-01.txt > Pages : 8 > Date : 2013-02-25 > > Abstract: > The Keberos 5 network authentication protocol has several numeric > protocol parameters. Most of these parameters are not currently > under IANA maintenance. This document requests that IANA take over > the maintenance of the remainder of these Kerberos parameters. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registries > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-01 I looked this document over and don't see anything objectionable. However, current values are given for the name type section only; is the intent to give current values in all sections? (Is this something that other people could help with?) Typo: in section 4, second paragraph, "Assignments for integers parameters" should have the singular "integer". In the last paragraph of 4.6, it's a bit unclear what exactly is entailed when "a pre-authentication number may be also be assigned to a related typed data number." One of the "be"s is probably superfluous, but does this mean that two names are given to the same number, or that two numbers are assigned with similar names? -Ben From kaduk@mit.edu Mon Aug 5 11:47:57 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 54DAE21F9D95 for ; Mon, 5 Aug 2013 11:47:57 -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 HjYDsB8Q+AZC for ; Mon, 5 Aug 2013 11:47:50 -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 F1E6F21F9DA1 for ; Mon, 5 Aug 2013 11:47:48 -0700 (PDT) X-AuditID: 12074423-b7f168e00000095a-39-51fff354689d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 58.79.02394.453FFF15; Mon, 5 Aug 2013 14:47:48 -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 r75Ilkqg003888 for ; Mon, 5 Aug 2013 14:47:47 -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 r75IliNT014833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Aug 2013 14:47:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r75IlhJv018792; Mon, 5 Aug 2013 14:47:44 -0400 (EDT) Date: Mon, 5 Aug 2013 14:47:43 -0400 (EDT) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: <50992138.9030200@sunet.se> Message-ID: References: <50992138.9030200@sunet.se> 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+NgFrrKIsWRmVeSWpSXmKPExsUixG6nrhvy+X+gQf83SYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/n9buaCToGKg0/fMjYwPubpYuTkkBAwkZiw/TwjhC0mceHe erYuRi4OIYF9jBLnnvUzgySEBI4xSjTOl4awrzNJXDnNC2HXS3z4/pIVxGYR0JKYu76NBcRm E1CRmPlmIxuILSKgLrH30FSwuLCAt8Th1rlg9ZwCGhJ7/x4AW8wr4CjRd/cFG8RMdYmDW4+C 2aICOhKr909hgagRlDg58wmYzSxgKfFv7S/WCYwCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqs W5ycmJeXWqRrppebWaKXmlK6iREcei7KOxj/HFQ6xCjAwajEw5tw9X+gEGtiWXFl7iFGSQ4m JVHelZ+AQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4528ByvGmJFZWpRblw6SkOViUxHmfPT0b KCSQnliSmp2aWpBaBJOV4eBQkuDdAjJUsCg1PbUiLTOnBCHNxMEJMpwHaPgLkBre4oLE3OLM dIj8KUZFKXHeWJCEAEgiozQPrheWGl4xigO9Isx7FaSKB5hW4LpfAQ1mAhps8vMvyOCSRISU VAOjxuHvllFdWyy+Pd6p6rdvQ2LMAUcuWe3TYnvaPPIrL71QOBAQ/b5WfnNW5HLrZavSZx49 fsXpRfrP0p6ZesKW/7gtjKql3CbdCJjTrBaRssDo2JlJMp8WL+ub+1D5TOXFxRpsJVeOfVzq 7HTwY2yPn+Odv9Y35l7/2DO9/R5Lz+U9z5elmJmJKbEUZyQaajEXFScCADtDJA/oAgAA Subject: Re: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07 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, 05 Aug 2013 18:47:57 -0000 On Tue, 6 Nov 2012, Leif Johansson wrote: > > Folks, > > I've reviewed version -07. I general I think the document is in good shape. > Reading through it I've found a small set of relatively minor nits. > > - Object Type: A long list of things like "Function" and "Integer" is given > but the description text basically sais these are just examples. I suggest > replacing the list with the following text > > defined by the binding language > > - Registration Rules: Suggest change to say: > > " to Policy defined by [RFC5226] or an RFC that > updates [RFC5226], for instance ..." > > Finally, I find the guidelines to Expert reviewers to be somewhat hard to > follow. The final paragraph in section 8.2.2 to me basically reads as "use > your good judgement". > > Personally I would find it difficult to draw any guidance from that text > but I > fully understand if this horse has been flogged enough. I've also reviewed version -07, and don't see anything particularly objectionable. Minor nits: In the table in section 7, in the entry for "Registration Rules", my first reading left me confused as to which sub-namespace "items that fall in this sub-namespace" referred to. Re-reading makes it clear that the sub-namespace is the one which has this Registration Rules attribute, and I don't have any ideas for how to reword the text to be clearer. The capitalization of "sub-namespace" is a bit inconsistent throughout the document. The table entry for "Reference" should add an 'a' in "Reference to a document". The "Expert Reviewer" entry is internally inconsistent about how many reviewers can be listed in a single field. Multiple instances are allowed, which would seem to indicate that one-reviewer-per-instance is the correct disambiguation. In section 8, the meaning might be more clear with a comma between "multiple registries" and "each". In the first paragraph of 8.2.2, "there is are any IETF Working Groups" has an unnecessary "is". -Ben From nico@cryptonector.com Mon Aug 5 12:54: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 0909621F9E28 for ; Mon, 5 Aug 2013 12:54:18 -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 PEqWYWmSRHRe for ; Mon, 5 Aug 2013 12:54:13 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D06FA21F9E27 for ; Mon, 5 Aug 2013 12:54:12 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 429CB1F008D for ; Mon, 5 Aug 2013 12:54:12 -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=/OyA/CweQH8mKGpfZxvr Hy8O/Kw=; b=kx7F4r8PR1KQWTy1urzXwRdYL43XfT+tTI7sBNUa/hxZ/b6VFM76 V0Ucmx5FsT9LFIcfq5cEWBaoKuaHVR+qeFjPiocyHKTltk0phgaw/f/siOspvhoB sjKuPxI9DW+ASZMQJzicTZhvwjYlRfnSkxFlRDH1b3q+vkdTLf8DICw= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id DD1F61F008A for ; Mon, 5 Aug 2013 12:54:11 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hi8so1960793wib.1 for ; Mon, 05 Aug 2013 12:54:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t0ZQ4XjVmPeGad+ZHnsIDTzRrHR5aPjOChnamjlZO/o=; b=YaD7E+/dDaT+KKvKDOlIXkcWNGNdL/b7rlk9ZURd3HzMGwD5PunDm0Umt4gjpYMvry k7I7Zs8AMmnxTX413+bXhjV0O7nAz/fu2sWTJZbklZ+VQcf+BVkNp68HOSPP7uZMPjKR ilaWcUDN7vBTWwXxhzb3mEF0QO+0/R7VnnHZyYiJ1GvUoZFaZGImMVMjX5806qgCWSF7 mevWH6RiklAosO6Y+1xA4BeJmZDu4Lr/+qmFHrqSfSrwLC0AWK2RedmEbSYBjuHAwzb8 MqJEWV94LxqNCbMuRpUEmf7yn+tNmaTYZKsh8cnxiMGexbC2ASEzqhdUdC+6mhbb4ZRQ ifhg== MIME-Version: 1.0 X-Received: by 10.180.187.175 with SMTP id ft15mr7660931wic.20.1375732450063; Mon, 05 Aug 2013 12:54:10 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Mon, 5 Aug 2013 12:54:10 -0700 (PDT) In-Reply-To: <509BD173.9000606@mnt.se> References: <50992138.9030200@sunet.se> <509BC801.8060506@isode.com> <509BD173.9000606@mnt.se> Date: Mon, 5 Aug 2013 14:54:10 -0500 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07 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, 05 Aug 2013 19:54:18 -0000 On Thu, Nov 8, 2012 at 9:36 AM, Leif Johansson wrote: >> The short answer to this is: if we know what the exact guidance is, we >> wouldn't need to use the Expert Review. So this is by design. > > I object to that answer. Hmm, well, we could certainly spend some time on providing GSS API design perls of wisdom. But then, if we proceed with the channel bound thing and async I/O... well, we'll be rototilling the whole thing. That will be great because the API will get easier to use, but it may also change some of those perls of wisdom. > Expert review should absolutely have guidance. I'm fine saying "use your > good > judgement" or not even having a guidance section and relying on implicit > good sense. "Take API design 101, and preferably 201 too". > However, the current text claims to provide guidance to reviewers but > probably > won't help anyone who doesn't already understand what to do. > > I say skip it, but if ppl are really married to it I'm fine with that > too :-) I'll provide a handful of perls now: - *always* include an OM_uint32 *minor_status argument in the C bindings of any new GSS functions - always specify all major status codes a new function may return, and if it may return as-yet-undefined errors, then say so (or maybe that should always be allowed for new functions?) - if you add any new opaque types always add a GSS_Duplicate_() function - wherever possible use the naming attributes API for extensions You already have to follow the naming conventions (GSS_S_.*, GSS_C_.*, ...), so no need to go there. I could add more. Someone else take a turn first. Nico -- From kaduk@mit.edu Tue Aug 6 13:23: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 6C0CC21F9F4F for ; Tue, 6 Aug 2013 13:23:26 -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 Viy3yrYJX2Ey for ; Tue, 6 Aug 2013 13:23:10 -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 3532721F9EF4 for ; Tue, 6 Aug 2013 13:23:09 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-88-52015b2a6fa0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E6.17.02387.A2B51025; Tue, 6 Aug 2013 16:23:06 -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 r76KN53b022095; Tue, 6 Aug 2013 16:23:06 -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 r76KN2BN001793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 16:23:04 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r76KN22m007453; Tue, 6 Aug 2013 16:23:02 -0400 (EDT) Date: Tue, 6 Aug 2013 16:23:02 -0400 (EDT) From: Benjamin Kaduk To: Jim Schaad In-Reply-To: <20130411064110.29519.86993.idtracker@ietfa.amsl.com> Message-ID: References: <20130411064110.29519.86993.idtracker@ietfa.amsl.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+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrKsVzRhksOS2icXq6d/ZLI5uXsXi wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGXsOHuQsWC+VsWxBa/ZGxhPK3YxcnJICJhI 7Jh9jwXCFpO4cG89WxcjF4eQwD5Gib6lW5hAEkICGxglrp2xgEgcZJI4fW8GO0SiXmLu3ZVg RSwCWhLrNnxiBLHZBFQkZr7ZyAZiiwioS2xdfROshllAWGL9uRnMILawgKPEuwcfweZwCjhJ TH+4D6yGFyh+4csfZoj5jhK3nrwHmyMqoCOxev8UFogaQYmTM5+wQMy0lPi39hfrBEbBWUhS s5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgOVEn+HYzfDiodYhTg YFTi4a0QYwwSYk0sK67MPcQoycGkJMobFAEU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLrIwGU 401JrKxKLcqHSUlzsCiJ8z57ejZQSCA9sSQ1OzW1ILUIJivDwaEkwdsTCdQoWJSanlqRlplT gpBm4uAEGc4DNLwCpIa3uCAxtzgzHSJ/itGYY/LZLe8ZOY6v2vqeUYglLz8vVUqcVxvkRgGQ 0ozSPLhpsGTzilEc6Dlh3m6QgTzARAU37xXQKiagVR4nGUBWlSQipKQaGFktVQydJPffXNWz 6KHdm9YNFye02MtUHeysL31osvnOCtkqLXOOfVPCAryNFULTWZ+eOKBwQ1pxjYLz1p8pBz50 vokIPt03cVf6SmP3J3L7l4fPZr3XH3vLvqLbZru2jOjxmY+mrg9W1rQP2CBc+cMrYHdtw4uN WS8kJ9mxyKSekSr69vXeISWW4oxEQy3mouJEAPXFsh8RAwAA Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-00.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, 06 Aug 2013 20:23:26 -0000 On Wed, 10 Apr 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) > Author(s) : Jim Schaad > Larry Zhu > Jeffery Altman > Filename : draft-ietf-kitten-iakerb-00.txt > Pages : 9 > Date : 2013-04-10 > > Abstract: > This document defines extensions to the Kerberos protocol and the > GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to > exchange messages with the KDC using the GSS-API acceptor as the > proxy, by encapsulating the Kerberos messages inside GSS-API tokens. > With these extensions a client can obtain Kerberos tickets for > services where the KDC is not accessible to the client, but is > accessible to the application server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-iakerb-00 I have reviewed this document. There are many small fixes which could be made, but I don't have any structural objections to the present text. The text for the GSS_EXTS_FINISHED extension will need review when it gets brought in, of course. The source XML should use to indicate that multiple documents are being updated. In the abstract, "using the GSS-API acceptor as the proxy" should read "using the GSS-API acceptor as a proxy" (s/the/a/). A similar text appears in the introduction and should get patched there, too. In section 3, "All context establishment token" should have "tokens" plural. The next paragraph starts out rather curiously ("The client starts [...] to establish the context."). In addition to being quite long, this sentence does not seem to make much sense. Perhaps the client constructs the ticket request "*as if* the ticket request is being made to the KDC."? (Note the full stop ending the sentence there.) Then the next sentence could continue "Instead of contacting the KDC directly, the client encapsulates [...]". The diagram here could benefit from an extra line indicating the causality -- the message from the proxy back to the client cannot occur until the KDC has replied to the proxy. Right at the top of page 3, the document refers to an "innerToken" described in RFC2743, but that string (case-insensitive, with or without an intervening space) does not appear in RFC2743. RFC2743 has innerContextToken and innerMsgToken, but it is RFC4121 that has innerToken. Looking up the TOK_ID for IAKERB_PROXY (or rather, how assignments of such values are performed) reveals that the IANA registry for token types is incomplete(!). http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types lists only 0100, 0200, 0300, 0404, 0504, 0601, and 0602 as assigned, but 0101, 0201, and 0102 are documented in RFC1964. Unfortunately, I still don't have an understanding of the rationale behind TOK_ID assignments; the current set seems quite sparse. The statement "The content of the IAKERB_PROXY message is defined as an IAKERB-HEADER structure immediately followed by a Kerberos message." does not really indicate that the Kerberos message can be omitted, a case described later on for enabling referrals. This section makes reference to "IAKERB client", "IAKERB proxy", "GSS-API server", and "GSS-API acceptor", which could probably be rearchitected to be more consistent. The first sentence of the last paragraph of page 4 ("When obtaining [...] Kerberos realm.") is hard to parse. I think the intent is that the client has no realm information at all, not even a default realm for the the machine from which the client is acting. If so, "When obtaining [...] name type and no realm information." seems like it would be more clear. The following sentence seems to be describing standard (non-IAKERB) behavior and should probably be indicated as such. Then, "In this case" would be "When the IAKERB client does not have any realm information available". It seems like it would be wise to explicitly say that after the client obtains a service ticket, the subsequent token is of type KRB_AP_REQ (not IAKERB_PROXY), instead of just saying "an KRB_AP_REQ message". If I remember correctly, we decided to pull the GSS_EXTS_FINISHED bits from PKU2U and include them inline in this document. I don't, however, remember whether Jim was going to do this on his own or who was going to help him. Jim? (That should probably be in a new section/subsection.) In the last paragraph of section 3, I might say "Implementations SHOULD utilize" instead of "Implementations SHOULD provide" [the AS_REQ armoring...]. In the second paragraph of page 6, I think "firewall filters can be applied to allow from which hosts the client requests can be proxied" would be better as "firewall filters can be applied to restrict from which hosts the client requests may be proxied". -Ben From kaduk@mit.edu Tue Aug 6 13:44: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 4B43211E80D1 for ; Tue, 6 Aug 2013 13:44:14 -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 Qa2BiuL4iWMH for ; Tue, 6 Aug 2013 13:43:58 -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 D7E7421F9EC3 for ; Tue, 6 Aug 2013 13:43:57 -0700 (PDT) X-AuditID: 12074423-b7f168e00000095a-d0-5201600cf739 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A1.A5.02394.C0061025; Tue, 6 Aug 2013 16:43:56 -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 r76KhuFN024730 for ; Tue, 6 Aug 2013 16:43:56 -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 r76KhrFu010356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Aug 2013 16:43:56 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r76KhrgY010097; Tue, 6 Aug 2013 16:43:53 -0400 (EDT) Date: Tue, 6 Aug 2013 16:43:53 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <20130411064110.29519.86993.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrMuTwBhksHaLhcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseDLK8aCjawVD5cuYGlg3MzSxcjJISFgInHt2mQmCFtM4sK9 9WwgtpDAPkaJzm2MXYxcQPYxRok9f7YzQTjXmSRu7X3G3sXIAeTUS9xaLAjSwCKgJfHr9Q6w ZjYBFYmZbzaC2SICwhK7t75jBrGFBcwkZj+6A2ZzCjhJbH59jR3E5hVwlJj+ax0zxOJyiSOf r7GC2KICOhKr909hgagRlDg58wmYzSxgKXHuz3W2CYwCs5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRrppebWaKXmlK6iREUeuwuyjsY/xxUOsQowMGoxMN7QYIxSIg1say4MvcQ oyQHk5Iob1EUUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIrw9IOW9KYmVValE+TEqag0VJnPfZ 07OBQgLpiSWp2ampBalFMFkZDg4lCd4bsUCNgkWp6akVaZk5JQhpJg5OkOE8QMOl4kGGFxck 5hZnpkPkTzHqckw+u+U9oxBLXn5eqpQ47zmQQQIgRRmleXBzYCnjFaM40FvCvN0gVTzAdAM3 6RXQEiagJR4nGUCWlCQipKQaGIPi3ne+CzH7NOVYhoTXezurGyffnAo1yXzy4PzLvRuW/HhQ dk0nfcHCn9KyzSWcVXkdfEeU2Zaf2bJ529lPZl8nbml92N+h0luyX1aP5cK7Y6cYVvyNqFJ8 XlMW0eFh8f06T/Wvxp7QxcfVp1cu+WdWqdx/zdDkouL0o3w5eutiZq1XmrpM3kmJpTgj0VCL uag4EQCDOnGE9AIAAA== Subject: [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: Tue, 06 Aug 2013 20:44:14 -0000 On Tue, 6 Aug 2013, Benjamin Kaduk wrote: > Looking up the TOK_ID for IAKERB_PROXY (or rather, how assignments of such > values are performed) reveals that the IANA registry for token types is > incomplete(!). > http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types > lists only 0100, 0200, 0300, 0404, 0504, 0601, and 0602 as assigned, but > 0101, 0201, and 0102 are documented in RFC1964. > Unfortunately, I still don't have an understanding of the rationale behind > TOK_ID assignments; the current set seems quite sparse. What is the mechanism to get IANA to update the registry with the additional values from RFC 1964? -Ben From tlyu@mit.edu Tue Aug 6 14:17: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 3A17521F991F for ; Tue, 6 Aug 2013 14:17:29 -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 aCEwbuA6qWM2 for ; Tue, 6 Aug 2013 14:17:24 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27621F9967 for ; Tue, 6 Aug 2013 14:17:23 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-bf-520167e211b0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BF.D8.02387.2E761025; Tue, 6 Aug 2013 17:17:22 -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 r76LHGBm028763; Tue, 6 Aug 2013 17:17: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 r76LHEGV022366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 17:17:16 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r76LHEWK008271; Tue, 6 Aug 2013 17:17:14 -0400 (EDT) To: Benjamin Kaduk References: <20130411064110.29519.86993.idtracker@ietfa.amsl.com> From: Tom Yu Date: Tue, 06 Aug 2013 17:17:14 -0400 In-Reply-To: (Benjamin Kaduk's message of "Tue, 6 Aug 2013 16:43:53 -0400 (EDT)") Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixCmqrPsonTHIYNU/PYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/PsdKaCtRwVPw79YW9g/MTWxcjJISFgInHn3xEmCFtM4sK9 9UBxLg4hgX2MEuf+NUA5G4Cc6evZIZyzTBI/zk5jhXA6GSVen9nLCNIvIqAksfhsC9hcZgFh ieVrzgLZHBzCAs4SG3dFQNRvZJQ4/2gbC0icTUBa4ujiMpByFgFVicOPj4Bt4xRoZ5To+QGy gJODV8BC4sfjFewgNo8Ap8Tkbz3MEHFBiZMzn7BA7NKSuPHvJdMERsFZSFKzkKQWMDKtYpRN ya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3ECApMdhfVHYwTDikdYhTgYFTi4a0QYwwS Yk0sK67MPcQoycGkJMp7LRkoxJeUn1KZkVicEV9UmpNafIhRgoNZSYTXRwIox5uSWFmVWpQP k5LmYFES533+9GygkEB6YklqdmpqQWoRTFaGg0NJgndzGlCjYFFqempFWmZOCUKaiYMTZDgP 0PC5IDW8xQWJucWZ6RD5U4y6HJPPbnnPKMSSl5+XKiXOWwdSJABSlFGaBzcHllBeMYoDvSXM uxGkigeYjOAmvQJawgS0xOMkA8iSkkSElFQDo3TevafZ5xZU8p+NUxV+OP3t6WVmX6xfFpjI up7vbzViD5/QO2Vlo//LybYvZBI1Az3q/3T0TA1t6O2a51TwMMjElMusgpUhZ5Wmp4Bk8Em5 6OdLpR7euTpDYXZDWn+m75nJV7Z68s5k0n70LP+uSrXInMXanEzX9sxeVrlTaPWZC9GTco+l KbEUZyQaajEXFScCADMLdXIDAwAA Cc: kitten@ietf.org 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: Tue, 06 Aug 2013 21:17:29 -0000 Benjamin Kaduk writes: > On Tue, 6 Aug 2013, Benjamin Kaduk wrote: > >> Looking up the TOK_ID for IAKERB_PROXY (or rather, how assignments >> of such values are performed) reveals that the IANA registry for >> token types is >> incomplete(!). http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types >> lists only 0100, 0200, 0300, 0404, 0504, 0601, and 0602 as assigned, >> but 0101, 0201, and 0102 are documented in RFC1964. >> Unfortunately, I still don't have an understanding of the rationale >> behind TOK_ID assignments; the current set seems quite sparse. > > What is the mechanism to get IANA to update the registry with the > additional values from RFC 1964? It seems like GSS-EAP establishes the registry: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09 and the allocation procedure for TOK_ID values is expert review. I'm also noticing that the RFC 4121 reserved values for 6000 through 60ff (see section 4.4) are not marked as reserved in the registry for some reason. From kaduk@MIT.EDU Tue Aug 6 14:25:59 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 E218F21F9D92 for ; Tue, 6 Aug 2013 14:25:59 -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, MIME_8BIT_HEADER=0.3] 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 lfc0cyTNfyTu for ; Tue, 6 Aug 2013 14:25:55 -0700 (PDT) Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) by ietfa.amsl.com (Postfix) with ESMTP id B477B21F9CF5 for ; Tue, 6 Aug 2013 14:25:54 -0700 (PDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r76LDdRI014108; Tue, 6 Aug 2013 17:13:39 -0400 (EDT) Date: Tue, 6 Aug 2013 17:13:39 -0400 (EDT) From: Benjamin Kaduk To: =?ISO-8859-15?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Message-ID: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-668870856-1375823619=:24720" Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 06 Aug 2013 21:26:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-668870856-1375823619=:24720 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 2 Aug 2013, Love H=F6rnquist =C5strand wrote: > Kelly, > > Legacy DCE-RPC appellations that didn=92t query unlaying DCE crypto layer= =20 > to see what the padding layer is and just sent in 8 as a padding/extra=20 > block, since that worked with both DES and RC4. > > You better ask the msft folks if this still is an issue. Tom's message from 10 July=20 (http://www.ietf.org/mail-archive/web/kitten/current/msg04114.html)=20 indicates that "The most recent information I have from Microsoft (from a= =20 few months ago in private mail) is that it would only be a problem for=20 legacy applications that aren't using the SSPI correctly. To me, that appears to address your concerns. -Ben ---559023410-668870856-1375823619=:24720-- From lha@h5l.org Tue Aug 6 14:45:35 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 E0EE421E80B3 for ; Tue, 6 Aug 2013 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_20=-0.74, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 2uawkBLlUA0l for ; Tue, 6 Aug 2013 14:45:30 -0700 (PDT) Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de3]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3E21F995B for ; Tue, 6 Aug 2013 14:45:29 -0700 (PDT) Received: from mailscan-2.sys.kth.se (mailscan-2.sys.kth.se [130.237.48.169]) by smtp-4.sys.kth.se (Postfix) with ESMTP id 7134D1FED; Tue, 6 Aug 2013 23:45:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([130.237.48.193]) by mailscan-2.sys.kth.se (mailscan-2.sys.kth.se [130.237.48.169]) (amavisd-new, port 10024) with LMTP id R6o9scT3W5hm; Tue, 6 Aug 2013 23:45:15 +0200 (CEST) X-KTH-Auth: lha [79.102.147.235] X-KTH-mail-from: lha@h5l.org Received: from [192.168.0.51] (c-4f6693eb-74736162.cust.telenor.se [79.102.147.235]) by smtp-4.sys.kth.se (Postfix) with ESMTPSA id CD0A6BC7; Tue, 6 Aug 2013 23:45:14 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\)) From: =?windows-1252?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Tue, 6 Aug 2013 23:45:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1793.4) Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 06 Aug 2013 21:45:36 -0000 6 aug 2013 kl. 23:13 skrev Benjamin Kaduk : > On Fri, 2 Aug 2013, Love H=F6rnquist =C5strand wrote: >=20 >> Kelly, >>=20 >> Legacy DCE-RPC appellations that didn=92t query unlaying DCE crypto = layer to see what the padding layer is and just sent in 8 as a = padding/extra block, since that worked with both DES and RC4. >>=20 >> You better ask the msft folks if this still is an issue. >=20 > Tom's message from 10 July = (http://www.ietf.org/mail-archive/web/kitten/current/msg04114.html) = indicates that "The most recent information I have from Microsoft (from = a few months ago in private mail) is that it would only be a problem for = legacy applications that aren't using the SSPI correctly. >=20 > To me, that appears to address your concerns. That doesn=92t address the the concern. msft needs to pipe up and say if = this is would be a issue for them and if they would not implement this = draft. Love From nico@cryptonector.com Tue Aug 6 14:46:08 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 41C4F21E809A for ; Tue, 6 Aug 2013 14:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 PjYMMPo5cBJS for ; Tue, 6 Aug 2013 14:46:04 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 70CAA21F995B for ; Tue, 6 Aug 2013 14:46:03 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id C87C42AC092 for ; Tue, 6 Aug 2013 14:46:02 -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:content-transfer-encoding; s= cryptonector.com; bh=vRjKIGwJE5GUasbe8uOdv4s1D50=; b=DYKwJxY0YMt tGrsopLhx+7/NMVXqKWg7UPHvob61hrH4pFp2UG0SK7vCywTpFmeAiBfCunJmYIW oRXFbrKFhzM4qZG4lk20Nv0JBliKLv/GzKe5VZcGhApBARf1jh6iv8nP0aOvhK8Z AnpMcMQ2ESXA+cEat369ZHfM03Hk9cjo= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 200652AC096 for ; Tue, 6 Aug 2013 14:46:01 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so845195wgh.33 for ; Tue, 06 Aug 2013 14:45:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C4j48UCMtBfdcVJJCDOxPUxBYoS2QTgmBUdmlPkfnFY=; b=dHXPTdXyqvs+f7VuAcxZ18/lCiLyfGlmxXAZutqx7jCEwIgWq3nVgODnwg6H9yRUv6 ljqOeEYfkr73wOq1LlH0KV2DqUpojbxYOK3eMeNVZ84v/8cLT4NkLWDv3i2PIYeWVvqK BcYKxttfhzFb25xJwo7lCSQRK6G0h717yUnC7noSkYfDoa6a59MPwM3esgvPFXNVNYmZ SBVhyuEcts4ejDGKMUbfnjpLCI7oCvR7figLzqfwTdMhs+SaxfrFJ6NBZkPLcj+efKwm 0P6V1uERyrVDf8leOkMyzLTZlDa9vH6YhJlVRTnjWkrI3gMIVE5wRO5Oi33moCAw6u4Z Y+MQ== MIME-Version: 1.0 X-Received: by 10.180.95.133 with SMTP id dk5mr169509wib.33.1375825558674; Tue, 06 Aug 2013 14:45:58 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Tue, 6 Aug 2013 14:45:58 -0700 (PDT) In-Reply-To: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> Date: Tue, 6 Aug 2013 16:45:58 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 06 Aug 2013 21:46:08 -0000 On Tue, Aug 6, 2013 at 4:13 PM, Benjamin Kaduk wrote: > On Fri, 2 Aug 2013, Love H=C3=B6rnquist =C3=85strand wrote: >> Legacy DCE-RPC appellations that didn=E2=80=99t query unlaying DCE crypt= o layer to >> see what the padding layer is and just sent in 8 as a padding/extra bloc= k, >> since that worked with both DES and RC4. >> >> You better ask the msft folks if this still is an issue. > > > Tom's message from 10 July > (http://www.ietf.org/mail-archive/web/kitten/current/msg04114.html) > indicates that "The most recent information I have from Microsoft (from a > few months ago in private mail) is that it would only be a problem for > legacy applications that aren't using the SSPI correctly. > > To me, that appears to address your concerns. Well, it's "hearsay", but we can't just wait forever. Speaking for myself, not for Love, my concern would be addressed by the chairs seeing to it that Microsoft is notified. Then we can start WGLC immediately and Microsoft will have the usual WGLC and IETF LC to comment. Nico -- From mrex@sap.com Tue Aug 6 15:36: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 7759421E80B7 for ; Tue, 6 Aug 2013 15:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 OwnBBoA472sX for ; Tue, 6 Aug 2013 15:36:11 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8E21E80AF for ; Tue, 6 Aug 2013 15:35:56 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r76MZrjU015394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 00:35:54 +0200 (MEST) In-Reply-To: To: Tom Yu Date: Wed, 7 Aug 2013 00:35:53 +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: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry 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: Tue, 06 Aug 2013 22:36:15 -0000 Tom Yu wrote: > Benjamin Kaduk writes: > > > On Tue, 6 Aug 2013, Benjamin Kaduk wrote: > > > >> Looking up the TOK_ID for IAKERB_PROXY (or rather, how assignments > >> of such values are performed) reveals that the IANA registry for > >> token types is > >> incomplete(!). http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types > >> lists only 0100, 0200, 0300, 0404, 0504, 0601, and 0602 as assigned, > >> but 0101, 0201, and 0102 are documented in RFC1964. Glancing over the archives, I see the following TOK_IDs in Kerberos-specific specifications: rfc1964 defines http://tools.ietf.org/html/rfc1964#page-2 0100 KRB_AP_REQ (page 2) 0200 KRB_AP_REP (page 2) 0300 KRB_ERROR (page 2) 0101 gss_get_mic() token (page 7) 0201 gss_wrap() token (page 10) 0102 gss_delete_sec_context() token (page 12) rfc4121 adds http://tools.ietf.org/html/rfc4121#section-4.2.6.1 0404 gss_get_mic() token without generic framing 0504 gss_wrap() token without generic framing > and the allocation procedure for TOK_ID values is expert review. I'm > also noticing that the RFC 4121 reserved values for 6000 through 60ff > (see section 4.4) are not marked as reserved in the registry for some > reason. 6000-60ff reserved to determine if generic GSS-API framing is present on per-message tokens just by looking at the first two bytes of the token http://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 0400 KERB-TGT-REQUEST 0401 KERB-TGT-REPLY http://tools.ietf.org/html/draft-ietf-krb-wg-iakerb-02 0501 IAKERB_PROXY plus something "else": http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-08#page-17 0601 Initiator->Acceptor Token 0602 Acceptor->Initiator Token -Martin From lukeh@padl.com Tue Aug 6 16:50: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 ECDB121E80BD for ; Tue, 6 Aug 2013 16:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 uJY982a8PDv4 for ; Tue, 6 Aug 2013 16:49:59 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C11DD21F844D for ; Tue, 6 Aug 2013 16:49:59 -0700 (PDT) Received: by us.padl.com with ESMTP id r76Nnjvj030683; Tue, 6 Aug 2013 19:49:48 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D76E2F3C-329B-4D91-8506-44272110954B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> Date: Wed, 7 Aug 2013 09:49:45 +1000 Message-Id: <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,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] 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: Tue, 06 Aug 2013 23:50:04 -0000 --Apple-Mail=_D76E2F3C-329B-4D91-8506-44272110954B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Also http://tools.ietf.org/html/draft-howard-gss-browserid-04 section 4: +---------+----------+-------+--------------------------+ | Section | Token ID | ASCII | Description | +---------+----------+-------+--------------------------+ | 4.1.1 | 0x632C | c, | Initiator context token | | | | | | | 4.1.2 | 0x432C | C, | Acceptor context token | | | | | | | | 0x442C | D, | Context deletion token | | | | | | | 4.2.4 | 0x6D2C | m, | Initiator metadata token | | | | | | | 4.2.4 | 0x4D2C | M, | Acceptor metadata token | +---------+----------+-------+--------------------------+ -- Luke --Apple-Mail=_D76E2F3C-329B-4D91-8506-44272110954B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Also http://t= ools.ietf.org/html/draft-howard-gss-browserid-04 section = 4:


        =  +---------+----------+-------+--------------------------+
         | Section | Token ID | ASCII | =        Description       = |
        =  +---------+----------+-------+--------------------------+
         |  4.1.1  | =  0x632C  |   c,  |  Initiator context token = |
         |         = |          |       |   =                     =    |
         | =  4.1.2  |  0x432C  |   C,  | =  Acceptor context token  |
      =    |         |         =  |       |             =             =  |
         |   =       |  0x442C  |   D,  | =  Context deletion token  |
      =    |         |         =  |       |             =             =  |
         | =  4.2.4  |  0x6D2C  |   m,  | Initiator = metadata token |
         |   =       |          |     =   |                   =        |
      =    |  4.2.4  |  0x4D2C  |   M, =  |  Acceptor metadata token |
      =   =  +---------+----------+-------+--------------------------+

-- Luke= --Apple-Mail=_D76E2F3C-329B-4D91-8506-44272110954B-- From kaduk@mit.edu Tue Aug 6 17:28:27 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 8FC9621E80BE for ; Tue, 6 Aug 2013 17:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 i9uj9IB7crad for ; Tue, 6 Aug 2013 17:28:22 -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 F3B1D11E80F2 for ; Tue, 6 Aug 2013 17:28:21 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-b1-520194a44294 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B2.65.02411.4A491025; Tue, 6 Aug 2013 20:28:20 -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 r770SIFZ020021; Tue, 6 Aug 2013 20:28:18 -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 r770SFVE008702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 20:28:16 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r770SErL009624; Tue, 6 Aug 2013 20:28:14 -0400 (EDT) Date: Tue, 6 Aug 2013 20:28:14 -0400 (EDT) From: Benjamin Kaduk To: Luke Howard In-Reply-To: <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> 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+NgFvrCIsWRmVeSWpSXmKPExsUixG6nrrtkCmOQwbfvZhZHN69isbh76T+7 Re/vHcwOzB5Llvxk8pj7YRqLx5TPWxkDmKO4bFJSczLLUov07RK4Mj6ub2EpOMpWsfpJSAPj UtYuRk4OCQETid/T2pkhbDGJC/fWs3UxcnEICexjlPhxcBczhLOBUWLquensEM5BJom1E6+C tQgJ1EusWvKEHcRmEdCSaPt7DcxmE1CRmPlmIxuILSKgIDF5/1qwemYBRYnHTf1ANgeHsICz xMZdESAmp4CNRO/OTJAKXgFHiaULJkNNz5bY+vY32ERRAR2J1funsEDUCEqcnPmEBWKipcS/ tb9YJzAKzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuuV5uZoleakrpJkZw4Lqo 7GBsPqR0iFGAg1GJh7dCjDFIiDWxrLgy9xCjJAeTkijvuUlAIb6k/JTKjMTijPii0pzU4kOM EhzMSiK8PhJAOd6UxMqq1KJ8mJQ0B4uSOO+zp2cDhQTSE0tSs1NTC1KLYLIyHBxKErztk4Ea BYtS01Mr0jJzShDSTBycIMN5gIa/AanhLS5IzC3OTIfIn2JUlBLnvQiSEABJZJTmwfXCEssr RnGgV4R5N4NU8QCTElz3K6DBTECDPU4ygAwuSURISTUwbmm4k5EmtH9z2eEDpWu/Lqxj0di7 98acKTs6DbgT/Bik6jTlD3Wy6W0qzClbl7L99SMVfZEcU/U1DAf+s4n2LV3injTbYV3OW8W6 iAi9jPVy8ucU5x1JW/Uj6L/oAaaIwqvc58o0V54WqDnO9azHY24Yz9S6PRZ2U7u/WDF3FLaE zbz9ck+uEktxRqKhFnNRcSIAL9EOaQcDAAA= Cc: kitten@ietf.org 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, 07 Aug 2013 00:28:27 -0000 Martin, Luke, thanks for looking these up, it saved a bunch of time. I see that draft-ietf-krb-wg-gssapi-cfx-02 (which became RFC4121) had 0405 for the context deletion token, but this was removed in the -03 in favor of not emitting such tokens. That's the only value in the MIT krb5 tree (that I see) that hasn't been mentioned so far. Heimdal doesn't seem to use defined constants for these, so checking is a bit harder; grepping for _gsskrb5_make_header doesn't find anything particularly exciting. 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. -Ben From simo@redhat.com Tue Aug 6 18:52:27 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 EEEFC21F9D1F for ; Tue, 6 Aug 2013 18:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 evyPEdCuDiR8 for ; Tue, 6 Aug 2013 18:52:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 32E3821F9C69 for ; Tue, 6 Aug 2013 18:52:20 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r771qFlL002380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 21:52:15 -0400 Received: from [10.3.113.18] ([10.3.113.18]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r771qD4K030726; Tue, 6 Aug 2013 21:52:13 -0400 From: Simo Sorce To: Greg Hudson In-Reply-To: <51FAFCFC.3010804@mit.edu> References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> <51FAFCFC.3010804@mit.edu> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Tue, 06 Aug 2013 21:52:12 -0400 Message-ID: <1375840332.21810.31.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: "kitten@ietf.org" , Sam Hartman , Zhanna Tsitkov , Jeffrey Hutzelman Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 07 Aug 2013 01:52:28 -0000 On Thu, 2013-08-01 at 20:27 -0400, Greg Hudson wrote: > On 08/01/2013 02:44 PM, Jeffrey Hutzelman wrote: > > I think agree with Sam here. The enctype should always be explicit. > > There is no requirement in the spec or protocol that krbtgt or any other > > principal only have keys of one enctype. > > I don't see how that's relevant. A KDC implementation would omit the > enctype in the KDC verifier because it thinks it can deduce the enctype > (by always using the first key, for instance), not because it assumes > there is only one enctype in the krbtgt principal. > > To expand on what I said before, it's disingenuous to call this a > departure from current practice because "the enctype is always explicit > in Kerberos." The enctype is always explicit in ciphertext because it > specifies the kind of encryption operation which was used to generate > the ciphertext. In this case, the enctype would be there for a > different purpose (key identification), and it is not normal practice in > Kerberos to include an enctype with a checksum if the key can be > identified without one. Although I agree that it would be perfectly safe if the enctype were optional, given the strong feeling by Sam and Jeffrey I am fine leaving it as required. Sam, Jeffrey, do you have any other objection on the structure ? Simo. -- Simo Sorce * Red Hat, Inc * New York From hartmans@painless-security.com Tue Aug 6 21:03: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 E61A321E80E6 for ; Tue, 6 Aug 2013 21:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 zL+typW40-jv for ; Tue, 6 Aug 2013 21:03:08 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EEDDD21E8054 for ; Tue, 6 Aug 2013 21:03:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 796E420229; Wed, 7 Aug 2013 00:02:13 -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 Ky3_AwXJ3OeG; Wed, 7 Aug 2013 00:02:13 -0400 (EDT) Received: from [10.0.0.12] (gain1-180.nortex.net [63.160.158.180]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: hartmans-smtp@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA; Wed, 7 Aug 2013 00:01:48 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <1375840332.21810.31.camel@willson.li.ssimo.org> References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> <51FAFCFC.3010804@mit.edu> <1375840332.21810.31.camel@willson.li.ssimo.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L1KEJJA2810XW81LASZFLF6H8LTWCW" From: Sam Hartman Date: Tue, 06 Aug 2013 23:01:19 -0500 To: Simo Sorce ,Greg Hudson Message-ID: <3ed76c71-cdfc-4b3f-8dd2-bf2eaef6c636@email.android.com> Cc: "kitten@ietf.org" , Sam Hartman , Zhanna Tsitkov , Jeffrey Hutzelman Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 07 Aug 2013 04:03:14 -0000 ------L1KEJJA2810XW81LASZFLF6H8LTWCW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I have no strong feeling. I forgot this was a checksum. Disregard my comment. Simo Sorce wrote: >On Thu, 2013-08-01 at 20:27 -0400, Greg Hudson wrote: >> On 08/01/2013 02:44 PM, Jeffrey Hutzelman wrote: >> > I think agree with Sam here. The enctype should always be >explicit. >> > There is no requirement in the spec or protocol that krbtgt or any >other >> > principal only have keys of one enctype. >> >> I don't see how that's relevant. A KDC implementation would omit the >> enctype in the KDC verifier because it thinks it can deduce the >enctype >> (by always using the first key, for instance), not because it assumes >> there is only one enctype in the krbtgt principal. >> >> To expand on what I said before, it's disingenuous to call this a >> departure from current practice because "the enctype is always >explicit >> in Kerberos." The enctype is always explicit in ciphertext because >it >> specifies the kind of encryption operation which was used to generate >> the ciphertext. In this case, the enctype would be there for a >> different purpose (key identification), and it is not normal practice >in >> Kerberos to include an enctype with a checksum if the key can be >> identified without one. > >Although I agree that it would be perfectly safe if the enctype were >optional, given the strong feeling by Sam and Jeffrey I am fine leaving >it as required. > >Sam, Jeffrey, >do you have any other objection on the structure ? > >Simo. > >-- >Simo Sorce * Red Hat, Inc * New York -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------L1KEJJA2810XW81LASZFLF6H8LTWCW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have no strong feeling. I forgot this was a checksum. Disregard my comment.

Simo Sorce <simo@redhat.com> wrote:
On Thu, 2013-08-01 at 20:27 -0400, Greg Hudson wrote:
On 08/01/2013 02:44 PM, Jeffrey Hutzelman wrote:
I think agree with Sam here.  The enctype should always be explicit.
There is no requirement in the spec or protocol that krbtgt or any other
principal only have keys of one enctype.

I don't see how that's relevant.  A KDC implementation would omit the
enctype in the KDC verifier because it thinks it can deduce the enctype
(by always using the first key, for instance), not because it assumes
there is only one enctype in the krbtgt principal.

To expand on what I said before, it's disingenuous to call this a
departure from current practice because "the encty
 pe is
always explicit
in Kerberos."  The enctype is always explicit in ciphertext because it
specifies the kind of encryption operation which was used to generate
the ciphertext.  In this case, the enctype would be there for a
different purpose (key identification), and it is not normal practice in
Kerberos to include an enctype with a checksum if the key can be
identified without one.

Although I agree that it would be perfectly safe if the enctype were
optional, given the strong feeling by Sam and Jeffrey I am fine leaving
it as required.

Sam, Jeffrey,
do you have any other objection on the structure ?

Simo.

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------L1KEJJA2810XW81LASZFLF6H8LTWCW-- From kwburgi@tycho.ncsc.mil Wed Aug 7 05:35:39 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 59C6621F9F7F for ; Wed, 7 Aug 2013 05:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 rf3WPpfW2dsW for ; Wed, 7 Aug 2013 05:35:34 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 589D421F9FF4 for ; Wed, 7 Aug 2013 05:35:33 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id b832c417000757c9 ; Wed, 7 Aug 2013 08:41:34 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r77CZPgY011260; Wed, 7 Aug 2013 08:35:26 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kelley Burgin In-Reply-To: Date: Wed, 7 Aug 2013 08:36:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02B2AB8F-820B-4E67-98D4-BFF5E0ADF029@tycho.ncsc.mil> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <003DA3AE-2366-480A-B66C-6505E7A6D2F6@tycho.ncsc.mil> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: kitten@ietf.org, =?windows-1252?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 12:35:39 -0000 Based on the history of the draft, it seems like we can assume Microsoft = will not pipe up. Given this assumption, I like Nico's plan to put the = burden on Microsoft to come forward if they have complaints instead of = putting the (destined to fail) burden on us to get them to reply. Kelley On Aug 6, 2013, at 5:45 PM, Nico Williams wrote: > On Tue, Aug 6, 2013 at 4:13 PM, Benjamin Kaduk wrote: >> On Fri, 2 Aug 2013, Love H=F6rnquist =C5strand wrote: >>> Legacy DCE-RPC appellations that didn=92t query unlaying DCE crypto = layer to >>> see what the padding layer is and just sent in 8 as a padding/extra = block, >>> since that worked with both DES and RC4. >>>=20 >>> You better ask the msft folks if this still is an issue. >>=20 >>=20 >> Tom's message from 10 July >> (http://www.ietf.org/mail-archive/web/kitten/current/msg04114.html) >> indicates that "The most recent information I have from Microsoft = (from a >> few months ago in private mail) is that it would only be a problem = for >> legacy applications that aren't using the SSPI correctly. >>=20 >> To me, that appears to address your concerns. >=20 > Well, it's "hearsay", but we can't just wait forever. Speaking for > myself, not for Love, my concern would be addressed by the chairs > seeing to it that Microsoft is notified. Then we can start WGLC > immediately and Microsoft will have the usual WGLC and IETF LC to > comment. >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From Josh.Howlett@ja.net Wed Aug 7 06:22: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 038F821F9A30 for ; Wed, 7 Aug 2013 06:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 blurISJIO5JE for ; Wed, 7 Aug 2013 06:22:36 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 133A521E8115 for ; Wed, 7 Aug 2013 06:22:35 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id ACE5720C81E6_2024A17B; Wed, 7 Aug 2013 13:22:31 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 3672B20C7B6A_2024A17F; Wed, 7 Aug 2013 13:22:31 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Wed, 7 Aug 2013 14:22:30 +0100 From: Josh Howlett To: Kelley Burgin , Nico Williams Thread-Topic: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) Thread-Index: AQHOk3EqIU8l+iWd/kGE8ChLjnE/VQ== Date: Wed, 7 Aug 2013 13:22:29 +0000 Message-ID: In-Reply-To: <02B2AB8F-820B-4E67-98D4-BFF5E0ADF029@tycho.ncsc.mil> Accept-Language: en-GB, 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: [194.82.140.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2B5EB04A3305344FB9BED5194CC157B1@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" , =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 13:22:43 -0000 Anyone object to this? Josh. -- IETF Kitten co-chair On 07/08/2013 13:36, "Kelley Burgin" wrote: >Based on the history of the draft, it seems like we can assume Microsoft >will not pipe up. Given this assumption, I like Nico's plan to put the >burden on Microsoft to come forward if they have complaints instead of >putting the (destined to fail) burden on us to get them to reply. > >Kelley > >On Aug 6, 2013, at 5:45 PM, Nico Williams wrote: > >> On Tue, Aug 6, 2013 at 4:13 PM, Benjamin Kaduk wrote: >>> On Fri, 2 Aug 2013, Love H=F6rnquist =C5strand wrote: >>>> Legacy DCE-RPC appellations that didn=B9t query unlaying DCE crypto >>>>layer to >>>> see what the padding layer is and just sent in 8 as a padding/extra >>>>block, >>>> since that worked with both DES and RC4. >>>>=20 >>>> You better ask the msft folks if this still is an issue. >>>=20 >>>=20 >>> Tom's message from 10 July >>> (http://www.ietf.org/mail-archive/web/kitten/current/msg04114.html) >>> indicates that "The most recent information I have from Microsoft >>>(from a >>> few months ago in private mail) is that it would only be a problem for >>> legacy applications that aren't using the SSPI correctly. >>>=20 >>> To me, that appears to address your concerns. >>=20 >> Well, it's "hearsay", but we can't just wait forever. Speaking for >> myself, not for Love, my concern would be addressed by the chairs >> seeing to it that Microsoft is notified. Then we can start WGLC >> immediately and Microsoft will have the usual WGLC and IETF LC to >> comment. >>=20 >> Nico >> -- >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From tlyu@mit.edu Wed Aug 7 09:39:39 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 6608221E8155 for ; Wed, 7 Aug 2013 09:39:39 -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 sBUMv04+mIMf for ; Wed, 7 Aug 2013 09:39:34 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D121E8135 for ; Wed, 7 Aug 2013 09:39:31 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-fb-52027842897c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E0.8B.02387.24872025; Wed, 7 Aug 2013 12:39:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r77GdS5Q030922; Wed, 7 Aug 2013 12:39:29 -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 r77GdOo3021105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Aug 2013 12:39:25 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r77GdO8Y011149; Wed, 7 Aug 2013 12:39:24 -0400 (EDT) To: Josh Howlett References: From: Tom Yu Date: Wed, 07 Aug 2013 12:39:23 -0400 In-Reply-To: (Josh Howlett's message of "Wed, 7 Aug 2013 13:22:29 +0000") Message-ID: Lines: 76 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixCmqrOtUwRRk8HiNmcX5Zz9ZLY5uXsVi Ma8hw2La1n3sFqeuHWFzYPV4eeoco8exz1cYPZYs+cnk8XbyWkaPrc3/GANYo7hsUlJzMstS i/TtErgyrh++zliwRaxi3sLzbA2M24S6GDk5JARMJLauu84GYYtJXLi3Hsjm4hAS2McosfPZ dihnA6PE+nW/2CGcs0wSM1d3MEI4nYwSXV8vg/WLCKhJvG79yA5iMwucZZSYd94HxBYWKJJ4 +r+RuYuRA6jBQOL/0QIQk01AWuLo4jKQChYBVYlN218zgdicAnkSK282g9m8AhYS06bfYAWx eQQ4Jd72PGeHiAtKnJz5hAVik7rEn3mXmCFsbYllC18zT2AUmoWkbBaSsllIyhYwMq9ilE3J rdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQIigl2F9UdjBMOKR1iFOBgVOLhfRDEFCTE mlhWXJl7iFGSg0lJlPd9GVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO/FYqAcb0piZVVqUT5M SpqDRUmc9/nTs4FCAumJJanZqakFqUUwWRkODiUJ3qZyoEbBotT01Iq0zJwShDQTByfIcB6g 4U4gNbzFBYm5xZnpEPlTjIpS4rzqIBcJgCQySvPgemEp6xWjONArwryZIO08wHQH1/0KaDAT 0GCPkwwgg0sSEVJSDYzVLAfWH8zt4vBVzcy/zHSLZ32/u6OUnEBGLfMBnee2xa96p80XfJzQ /dngvxdT+4VpzzJ0/YoOs0ouvKZ48/yso3U7f3z8Y3+19XMax9qvs677m5c0nd9aVFwU5r77 HxePY9Rqm9RoQ1fXQlnPpd/+ttw4b/Uh2OL1zXgT5kPBDqJ1l8Wk/iixFGckGmoxFxUnAgBK Bt3RNAMAAA== Cc: "kitten@ietf.org" , Love =?utf-8?Q?H=C3=B6rnquist_=C3=85strand?= Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 16:39:39 -0000 Josh Howlett writes: > Anyone object to this? > > Josh. > > -- > IETF Kitten co-chair I don't object, but I can try to ask some of our Microsoft contacts specifically about the DCE-RPC issue. It's possible that they interpreted some of my previous queries solely in an SSPI context. Also, do I recall correctly that Luke was going to do some research on this? I've been trying to get some answers by reading DCE C706, but it's not easy. > On 07/08/2013 13:36, "Kelley Burgin" wrote: > >>Based on the history of the draft, it seems like we can assume Microsoft >>will not pipe up. Given this assumption, I like Nico's plan to put the >>burden on Microsoft to come forward if they have complaints instead of >>putting the (destined to fail) burden on us to get them to reply. >> >>Kelley >> >>On Aug 6, 2013, at 5:45 PM, Nico Williams wrote: >> >>> On Tue, Aug 6, 2013 at 4:13 PM, Benjamin Kaduk wrote: >>>> On Fri, 2 Aug 2013, Love H=C3=B6rnquist =C3=85strand wrote: >>>>> Legacy DCE-RPC appellations that didn=C2=B9t query unlaying DCE crypto >>>>>layer to >>>>> see what the padding layer is and just sent in 8 as a padding/extra >>>>>block, >>>>> since that worked with both DES and RC4. >>>>>=20 >>>>> You better ask the msft folks if this still is an issue. >>>>=20 >>>>=20 >>>> Tom's message from 10 July >>>> (http://www.ietf.org/mail-archive/web/kitten/current/msg04114.html) >>>> indicates that "The most recent information I have from Microsoft >>>>(from a >>>> few months ago in private mail) is that it would only be a problem for >>>> legacy applications that aren't using the SSPI correctly. >>>>=20 >>>> To me, that appears to address your concerns. >>>=20 >>> Well, it's "hearsay", but we can't just wait forever. Speaking for >>> myself, not for Love, my concern would be addressed by the chairs >>> seeing to it that Microsoft is notified. Then we can start WGLC >>> immediately and Microsoft will have the usual WGLC and IETF LC to >>> comment. >>>=20 >>> Nico >>> -- >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >> >>_______________________________________________ >>Kitten mailing list >>Kitten@ietf.org >>https://www.ietf.org/mailman/listinfo/kitten > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 > not-for-profit company which is registered in England under No. 2881024=20 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Wed Aug 7 10:21:01 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 9412921F9F8F for ; Wed, 7 Aug 2013 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.444, 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 LME11fia0iQP for ; Wed, 7 Aug 2013 10:20:53 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7086F21F9D56 for ; Wed, 7 Aug 2013 10:20:36 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 82FE6594079 for ; Wed, 7 Aug 2013 10:20:34 -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=Tw0o915yZ8PPbzOBvvTY QVFHmKw=; b=aylQo/w7TSn4Z2SFOGXPaa7jZ2RgRbJCnm2wPhrUusEtpADbmIjB hUaZTxilvzkwfgwEwi2i/Kan1SYJUuYjKDOnU4S/EOfLy7kqZR6VtVBFyvh/N6Bq fQBDwCNOU1VaEijLfP2f0ljEB9uI2CBdN7brDXUX7WAV5Uv+oYGfxxk= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 0285659407D for ; Wed, 7 Aug 2013 10:20:33 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id l18so1748924wgh.23 for ; Wed, 07 Aug 2013 10:20:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dLrLKKlSBcYXxRw59CXkUXk0AchRDIxybY1Idg8HHfE=; b=AX2VHmRPRiWI7cbIlFk5LImcrvJrXmAwO9OrW4CKbNeeljHBRLkKsTcrR4BJQn1DRj RBJ8T9Hhn2KC902KQBiLtEzYQqRslJCEma8FoJMBtRPMIe0uWM4iIegwPZ8MPBBu9iMP SD/w1PNjmB3qN4FJqLKt6QgBMjg3r23xaDuNKYFVY/JG/ZAhZCGp1w/6gDkbBpy7MFe2 ak5vHWC97zZCaOtsnncxezEx4mviCO8SxaaasWY2qCidqN5HmrBq5VhshRJjDYFTLQsl nqpiJU0sRZ8r/GZyw3qmRRB4ezGk3d80azLl+yyWxBewoaE/pKgf2hILXUqYaw1jE0u1 BAfw== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr2765298wic.33.1375896031122; Wed, 07 Aug 2013 10:20:31 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Wed, 7 Aug 2013 10:20:31 -0700 (PDT) In-Reply-To: References: <02B2AB8F-820B-4E67-98D4-BFF5E0ADF029@tycho.ncsc.mil> Date: Wed, 7 Aug 2013 12:20:31 -0500 Message-ID: From: Nico Williams To: Josh Howlett Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 17:21:01 -0000 On Wed, Aug 7, 2013 at 8:22 AM, Josh Howlett wrote: > Anyone object to this? Well, following IETF process can't be objectionable :) Two weeks for WGLC and four for IETF LC should be plenty of time. The addition of personally reaching out to whoever might-not-be-but-should-be-paying-attention is not required but is certainly the right thing to do here. But that's it, if we get no comments in that period (and, really, right up till final publication, so much more than just 6 weeks), then that's it. Nico -- From kaduk@mit.edu Wed Aug 7 10:55:27 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 1281A21F9DB4 for ; Wed, 7 Aug 2013 10:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 3P2oV5+RIbJ7 for ; Wed, 7 Aug 2013 10:55:10 -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 237F211E816D for ; Wed, 7 Aug 2013 10:55:09 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-24-520289fcd197 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.95.02357.CF982025; Wed, 7 Aug 2013 13:55:08 -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 r77Ht7f1032496 for ; Wed, 7 Aug 2013 13:55:08 -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 r77Ht5kj019675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Aug 2013 13:55:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r77Ht5Za025175; Wed, 7 Aug 2013 13:55:05 -0400 (EDT) Date: Wed, 7 Aug 2013 13:55:05 -0400 (EDT) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: <51FAFCFC.3010804@mit.edu> Message-ID: References: <6EC63FD16C85D746815D7AB1380FCB8A335729C3@OC11EXPO25.exchange.mit.edu> <1374600899.18186.1.camel@willson.li.ssimo.org> <19539_1375365464_r71DvgDV020481_1375361584.15733.172.camel@willson.li.ssimo.org> <1375382656.23365.550.camel@minbar.fac.cs.cmu.edu> <51FAFCFC.3010804@mit.edu> 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+NgFnrEIsWRmVeSWpSXmKPExsUixG6novunkynIYPt7OYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro61hDWtBn2TFprln2BoYe0W6GDk5JARMJG70r2CHsMUkLtxb z9bFyMUhJLCPUWLKn9uMIAkhgWOMEvfOB0EkrjNJND/cyQ6RqJdoW9bODGKzCGhJdB5uBbPZ BFQkZr7ZyAZiiwioS+w9NJWli5GDQ1jASGLH73qQMCdQ+Nui32BjeAUcJY4cXcwOtZhJYv/B hywgCVEBHYnV+6ewQBQJSpyc+QTMZhawlPi39hfrBEaBWUhSs5CkFjAyrWKUTcmt0s1NzMwp Tk3WLU5OzMtLLdI11cvNLNFLTSndxAgOPhelHYw/DyodYhTgYFTi4X0QxBQkxJpYVlyZe4hR koNJSZT3RjtQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvxWKgHG9KYmVValE+TEqag0VJnPfZ 07OBQgLpiSWp2ampBalFMFkZDg4lCV5JYJQJCRalpqdWpGXmlCCkmTg4QYbzAA0PBqnhLS5I zC3OTIfIn2LU5fjyY/4nRiGWvPy8VClxXh2QIgGQoozSPLg5sKTxilEc6C1hXneQKh5gwoGb 9ApoCRPQEo+TDCBLShIRUlINjAw8c6qYY47E8H73/d2gryq6rvZQi2hmyuf2X9ZdbB0rIrYe TbBce6zisM2HMLdX7zsOO9nfEGnLy3n8a/GEgIMMJw8EqnFMj5k71/tGTui36swny/YYSoko 26Smhd1Lt5V8OlHAiPPo/w0/Zjou+vBt8e/kL0eWt7m8nOXxnOdRzOdZ60tnPVJiKc5INNRi LipOBACAGVa49QIAAA== Subject: Re: [kitten] CAMMAC-05: Verifier-MAC etc 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, 07 Aug 2013 17:55:27 -0000 On Thu, 1 Aug 2013, Greg Hudson wrote: > On 08/01/2013 02:44 PM, Jeffrey Hutzelman wrote: >> I think agree with Sam here. The enctype should always be explicit. >> There is no requirement in the spec or protocol that krbtgt or any other >> principal only have keys of one enctype. > > I don't see how that's relevant. A KDC implementation would omit the > enctype in the KDC verifier because it thinks it can deduce the enctype > (by always using the first key, for instance), not because it assumes > there is only one enctype in the krbtgt principal. > > To expand on what I said before, it's disingenuous to call this a > departure from current practice because "the enctype is always explicit > in Kerberos." The enctype is always explicit in ciphertext because it > specifies the kind of encryption operation which was used to generate > the ciphertext. In this case, the enctype would be there for a > different purpose (key identification), and it is not normal practice in > Kerberos to include an enctype with a checksum if the key can be > identified without one. I don't personally care very much whether the enctype is mandatory here, but I don't think any of the objections to making it optional that have appeared so far are of particular technical merit. [Ed. I guess this is partially overtaken by events while I was drafting this mail.] Anyways, I've gotten to do a more careful review of the entire document, comments below. Section 3, first sentence, s/insure/ensure/. There is no monetary compensation involved, here :) The description of the Trusted Service MAC a bit confusing, I might reword it as "The Trusted Service MAC is not required, but can be useful when the authorization data is received by a less-trusted service and a more-trusted service is available on the same host. In this case the authorization data can be verified without an additional round trip to the KDC." In section 4.1, the description of the Verifier-MAC is very abstract/high-level. I would prefer something more concrete in a document of this nature. Now that AD-CAMMAC-BINDING is left to the implementation, we could say that about the encoding as well as the contents, and not necessarily require the OCTET STRING form. Looking at the kdc-verifier, the string "TGS key" appears only once in RFC 4120, and not in a definition. Do we want this slight informality, or would "the service key of the ticket-granting service" be better? Additionally, mandatory checksum types are bound to encryption types, not keys, so it might be more pedantically correct to say the "mandatory checksum type for the TGS key's enctype". (I am not explicitly asking for that.) I noticed while going through that RFC 3961 never uses the term "mandatory checksum", it is the "required checksum". :) In the other-verifiers description, we still have a parenthetical "(which one?)", resolution of which is the point of the thread I'm hijacking. The discussion of AD-CAMMAC-BINDING in the security considerations which we talked about previously will also be helpful. That's all the new stuff from this round of review. -Ben From mrex@sap.com Wed Aug 7 11:54: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 B918221F9D4F for ; Wed, 7 Aug 2013 11:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 8N+vK5YhoWAe for ; Wed, 7 Aug 2013 11:54:02 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8521E8088 for ; Wed, 7 Aug 2013 11:54:00 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r77Irwq3016470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 20:53:58 +0200 (MEST) In-Reply-To: To: Benjamin Kaduk Date: Wed, 7 Aug 2013 20:53:58 +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: <20130807185358.263CC1A8EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry 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: Wed, 07 Aug 2013 18:54:07 -0000 Benjamin Kaduk wrote: > Martin, Luke, thanks for looking these up, it saved a bunch of time. > > I see that draft-ietf-krb-wg-gssapi-cfx-02 (which became RFC4121) had 0405 > for the context deletion token, but this was removed in the -03 in favor > of not emitting such tokens. I just found another one: http://tools.ietf.org/html/rfc2743#page-84 04 01 exported name (token) created by gss_export_name() In case that anyone is wondering what "per-message token without generic framing" means: GSS-API defines a mechanism-independent Token Format in rfc-2743, section 3.1 http://tools.ietf.org/html/rfc2743#page-81 (originally in GSS-API v1, rfc-1508, Appendix B) http://tools.ietf.org/html/rfc1508#page-48 which must be used for the _initial_context_token_, This "generic framing" is originally defined as ASN.1, but the description in rfc2743, section 3.1 also describes that framing as bits-on-the-wire, so that it can be implemented without ASN.1 tools. There is _no_ requirement in the base gssapi specification for mechanisms what framing or format to use for others but the initia context token (i.e. the 1st token from Initiator to Acceptor) or for per-message tokens. The Kerberos gssapi mechanism (rfc1964) decided to use the generic framing for _all_ context tokens, and in addition, for _all_ per message tokens as well. The update of the Kerberos gssapi mechanism (rfc4121) dropped the generic framing on the per-message tokens, making the TOKEN_ID the fist two octets to appear in rfc4121 per-message tokens. -Martin From kaduk@mit.edu Wed Aug 7 14:09: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 4E5B011E80A2 for ; Wed, 7 Aug 2013 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ydldvFE0df5S for ; Wed, 7 Aug 2013 14:09:10 -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 9F62621F9DFC for ; Wed, 7 Aug 2013 14:09:09 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-22-5202b7749c3e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.7D.02387.477B2025; Wed, 7 Aug 2013 17:09:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r77L97xf008214 for ; Wed, 7 Aug 2013 17:09:08 -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 r77L95E7008064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Aug 2013 17:09:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r77L94Oo021447; Wed, 7 Aug 2013 17:09:04 -0400 (EDT) Date: Wed, 7 Aug 2013 17:09:04 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20130708021106.14072.49434.idtracker@ietfa.amsl.com> Message-ID: References: <20130708021106.14072.49434.idtracker@ietfa.amsl.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+NgFnrIIsWRmVeSWpSXmKPExsUixG6nrluynSnI4N4lSYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr40X/eqaCmfIVv7eVNjB+k+hi5OCQEDCR6LzE2MXICWSKSVy4 t56ti5GLQ0hgH6NE//YGJgjnGKPEkcPz2SGc60wS3xfOYwFpERKol7j07AiYzSKgJXFm/VV2 EJtNQEVi5puNbCC2iICwxO6t75hBbGEBf4lTvefAajgFnCSmH/jOCmLzCjhKPL/wAmomkD19 IpgtKqAjsXr/FBaIGkGJkzOfgNnMApYS/9b+Yp3AKDALSWoWktQCRqZVjLIpuVW6uYmZOcWp ybrFyYl5ealFuiZ6uZkleqkppZsYQaHHKcm/g/HbQaVDjAIcjEo8vJ0BTEFCrIllxZW5hxgl OZiURHnltwGF+JLyUyozEosz4otKc1KLDzFKcDArifBeLAbK8aYkVlalFuXDpKQ5WJTEeZ89 PRsoJJCeWJKanZpakFoEk5Xh4FCS4H0GMlSwKDU9tSItM6cEIc3EwQkynAdo+DqQGt7igsTc 4sx0iPwpRl2OPyvnfmIUYsnLz0uVEufdtQWoSACkKKM0D24OLGW8YhQHekuY9xrIKB5guoGb 9ApoCRPQEo+TDCBLShIRUlINjGrTv4Uf2emZclqpOrtW+ZtD16bvJT0LV3FJ3nTIO7dFoyPe debO0yrPru9WWl5Zp7gmivHPybRvvt6PDhqYJ1x1ZXBtPuY2k20mr/JJ50lb2q9UnTgoHsAd 3HSTm/vn7Cu7LTgOdPeeWtJ4QfDHR66thw23LNp7eEP7Jr3dK5c+zunjXbLnHZcSS3FGoqEW c1FxIgCQWNRm9AIAAA== Subject: Re: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-00.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, 07 Aug 2013 21:09:16 -0000 On Sun, 7 Jul 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Channel Binding Signalling for the Generic Security Services Application Programming Interface > Author(s) : Nicolas Williams > Filename : draft-ietf-kitten-channel-bound-flag-00.txt > Pages : 13 > Date : 2013-07-07 > > Abstract: > Channel binding is a technique that allows applications to use a > secure channel at a lower layer without having to use authentication > at that lower layer. The concept of channel binding comes from the > Generic Security Services Application Programming Interface (GSS- > API). It turns out that the semantics commonly implemented are > different that those specified in the base GSS-API RFC (RFC2743), and > that that specification has a serious bug. This document addresses > both, the inconsistency as-implemented and the specification bug. > > This Internet-Draft proposes the addition of a "channel bound" return > flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() > functions. Two behaviors are specified: a default, safe behavior > reflecting existing implementation deployments, and a behavior that > is only safe when the application specifically tells the GSS-API that > it (the application) supports the new behavior. Additional API > elements related to this are also added, including a new security > context establishment API. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-channel-bound-flag > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-00 I have reviewed this document; the following comments are basically editorial in nature, with no substantial flaws in the technical proposal. In the abstract, "Additional API elements related to this are also added", what is "this"? channel binding? Section 1.2 seems rather informal for a standards-track submission. (The whole document's use of "we" is a bit dubious, too, but that's a harder change to make.) Would 1.3 and 1.4 (and in general, all "future work" comments) be better in an appendix? In the first sentence of 1.3, you have a comma that begins a parenthetical, but no comma to end the parenthetical. In section 2.2, please make it more explicit that in order to use the req_flags given to GSS_Set_context_flags(), the input flags to GSS_Init_sec_context() must be all zero. Introducing the new FLAGS type in a "NOTE:" is probably not appropriate for a standards-track document. In 2.2.1, it's probably worth making a note that the flags are now 64-bit fields instead of 32-bit. In 2.5, I don't think the first sentence provides sufficient description of the flag. Please give a full paragraph with such a description, and split the rest of the (current) paragraph into a separate paragraph. Section 2.5.1's use of the phrase "both flags" is a little vague; I'd like to see some text indicating why the two flags are related. In 2.6, I would say "applied to an empty security context" instead of the plural form currently given. In the first bullet point of section 3, the use of commas to group the clauses which "both" binds together scans pretty awkwardly. Can't we just use the same (a) and (b) style as in the other bullet points? Throughout section 3, I don't see much precedent for the use of "input_channel_bindings" as a variable name. RFC2743 has "chan_bindings", the MIT krb5 gssapi.h has "/* input_chan_bindings */" and Heimdal's header matches MIT's. I agree with the overall scheme, as mentioned when we were debating between alternate approaches. -Ben From kaduk@mit.edu Wed Aug 7 14:21:27 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 AAD2511E80A2 for ; Wed, 7 Aug 2013 14:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 NIJVyOjVJ6y3 for ; Wed, 7 Aug 2013 14:21:21 -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 4F05521F977A for ; Wed, 7 Aug 2013 14:21:20 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-04-5202ba5003b1 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A4.22.02411.05AB2025; Wed, 7 Aug 2013 17:21:20 -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 r77LLJHX009360; Wed, 7 Aug 2013 17:21:19 -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 r77LLH9t012571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Aug 2013 17:21:19 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r77LLHdR023043; Wed, 7 Aug 2013 17:21:17 -0400 (EDT) Date: Wed, 7 Aug 2013 17:21:17 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Message-ID: References: <20130628173017.2197.22687.idtracker@ietfa.amsl.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+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrhuwiynIYMVUMYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGV87m9kK5jDXfF03waWBsZzHF2MnBwSAiYS a+//ZoewxSQu3FvP1sXIxSEksI9R4tC5XawQzgZGieaPB5ggnINMEneeLmQCaRESqJc49mYF WDuLgJbE3OVfGUFsNgEViZlvNrKB2CIC6hLtE76C2cwCwhLrz81g7mLk4BAW8JOY+JgfJMwp 4Chx5MNbVhCbF8h+se0qG8R4B4ntk3eBjRQV0JFYvX8KC0SNoMTJmU9YIEZaSvxb+4t1AqPg LCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6+VmluilppRuYgQHqovKDsbmQ0qH GAU4GJV4eB8EMQUJsSaWFVfmHmKU5GBSEuX9sAMoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3 YjFQjjclsbIqtSgfJiXNwaIkzvvs6dlAIYH0xJLU7NTUgtQimKwMB4eSBG/jTqBGwaLU9NSK tMycEoQ0EwcnyHAeoOHOIDW8xQWJucWZ6RD5U4yKUuK8n0AuEgBJZJTmwfXCEskrRnGgV4R5 P4JU8QCTEFz3K6DBTECDPU4ygAwuSURISTUwum8V87Vf+V3nVly9xPYZxxQ0z1gop5vqmvZ/ qTSNfG8ye8HLivxNR5nOmpVc7b7A5du15WWS2YuQkIZj/o/m+q+f8+SAyaWHO6dP/qwWNM1R U0NTYv+Ts/L2a4V+Tv72uanveOynN4m3BbV6jSvPPf9X8chLM/3PgRccx9mkKhc/6PA/XOKp o8RSnJFoqMVcVJwIAIiCwb//AgAA Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 21:21:27 -0000 On Fri, 28 Jun 2013, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > Author(s) : Kelley W. Burgin > Michael A. Peck > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-01.txt > Pages : 15 > Date : 2013-06-28 > > Abstract: > This document specifies two encryption types and two corresponding > checksum types for Kerberos 5. The new types use AES in CTS mode > (CBC mode with ciphertext stealing) for confidentiality and HMAC with > a SHA-2 hash for integrity. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01 I've reached this document in my process of going through all the documents mentioned in the kitten slides from Berlin, but don't think it's worth the time to do the review until the cts vs. cbc question is resolved. Sam, I think this is blocking on your historical recollections; do you have an estimate for when you'll be able to send them to the list? Thanks, Ben From kaduk@mit.edu Wed Aug 7 14:31: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 C881911E80A2 for ; Wed, 7 Aug 2013 14:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 XSe6o76at1Rf for ; Wed, 7 Aug 2013 14:30:54 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id F21DC11E813F for ; Wed, 7 Aug 2013 14:30:53 -0700 (PDT) X-AuditID: 12074425-b7f0c8e000000953-3b-5202bc8d96aa Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C4.9C.02387.D8CB2025; Wed, 7 Aug 2013 17:30:53 -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 r77LUpIU001559; Wed, 7 Aug 2013 17:30:52 -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 r77LUne4016195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Aug 2013 17:30:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r77LUnxQ024262; Wed, 7 Aug 2013 17:30:49 -0400 (EDT) Date: Wed, 7 Aug 2013 17:30:49 -0400 (EDT) From: Benjamin Kaduk To: Thomas L Yu In-Reply-To: Message-ID: References: <20130225234150.5714.90921.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrdu7hynI4MpNZoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4//G3IKV7BWn9jxha2B8wtrFyMkhIWAiMat/MZQtJnHh3nq2 LkYuDiGBfYwS1+dch3I2MErsedDLDOEcZJK4NvUqO0iLkEC9xKt/bYxdjBwcLAJaEpcelYCE 2QRUJGa+2cgGYosIyElc3H+QBcRmFhCWWH9uBjNIubBAqMT765wgYU4BJ4nmprNMIDavgKPE tOmfWCCml0lM2buPEcQWFdCRWL1/CgtEjaDEyZlPoEZaSpz7c51tAqPgLCSpWUhSCxiZVjHK puRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgQFJLuL6g7GCYeUDjEKcDAq8fA+CGIK EmJNLCuuzD3EKMnBpCTK+2EHUIgvKT+lMiOxOCO+qDQntfgQowQHs5II78VioBxvSmJlVWpR PkxKmoNFSZz3+dOzgUIC6YklqdmpqQWpRTBZGQ4OJQneObuBGgWLUtNTK9Iyc0oQ0kwcnCDD eYCGx4PU8BYXJOYWZ6ZD5E8xKkqJ8/aDJARAEhmleXC9sITxilEc6BVh3gkgVTzAZAPX/Qpo MBPQYI+TDCCDSxIRUlINjLwx36MkWgs3NgsvvNR7XJH5k9THB2UzBPXv77WMWjr5pZJBYEvt Oc+Uns6ahzvMwicm73qVOO98f4iC+Y9tn75c+DknIabLyUPyiK7j29OzlVLO8D0r36F52vud Mc/RR7KSbXI7DAJvlxtkMrkY2VmVdy4MMw38yC/THnHsT8/0xTqz+aZPU2Ipzkg01GIuKk4E ALLvtUHzAgAA Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-kerberos-iana-registries-01.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, 07 Aug 2013 21:31:00 -0000 On Mon, 5 Aug 2013, Benjamin Kaduk wrote: > I looked this document over and don't see anything objectionable. However, > current values are given for the name type section only; is the intent to > give current values in all sections? (Is this something that other people > could help with?) > > Typo: in section 4, second paragraph, "Assignments for integers parameters" > should have the singular "integer". > > In the last paragraph of 4.6, it's a bit unclear what exactly is entailed > when "a pre-authentication number may be also be assigned to a related typed > data number." One of the "be"s is probably superfluous, but does this mean > that two names are given to the same number, or that two numbers are assigned > with similar names? Oops, I don't know how I missed that an -02 was available while reviewing this. Section numbers increment by one, but I think the comments still apply. -Ben From lukeh@padl.com Wed Aug 7 16:16:10 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 83F5011E8168 for ; Wed, 7 Aug 2013 16:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 fdyd-R28W8Uq for ; Wed, 7 Aug 2013 16:16:03 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 67EC421F90CC for ; Wed, 7 Aug 2013 16:15:49 -0700 (PDT) Received: by us.padl.com with ESMTP id r77NFUri032407; Wed, 7 Aug 2013 19:15:32 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_60A21C7C-8A88-4186-9F6C-C7CD5D8AEC45" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: Date: Thu, 8 Aug 2013 09:15:29 +1000 Message-Id: <2564ED1A-FFEE-4304-8501-29510BC103D5@padl.com> References: To: Tom Yu X-Mailer: Apple Mail (2.1508) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,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, Michiko Short , =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 23:16:10 -0000 --Apple-Mail=_60A21C7C-8A88-4186-9F6C-C7CD5D8AEC45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Also, do I recall correctly that Luke was going to do some research on > this? I've been trying to get some answers by reading DCE C706, but > it's not easy. Yeah, and you won't find it there because GSS wasn't in the original DCE = RPC spec (only raw Kerberos). Instead I think you want [MS-RPCE] = 2.2.2.11 which says the auth trailer must be 4 byte aligned, and that = it's OK to zero fill the trailer if you over-allocated. I'm a bit skeptical about the 4 byte alignment in practice. In the last = implementation I worked on, I made the following note: /* * [MS-RPCE] states that the stub data is padded to the underlying * blocksize (or four bytes, if that is greater). In practice they * use the underlying keysize when the blocksize is one. For now, * a constant 16 bytes works for all known ciphers and mechanisms * (at the expense of 8 bytes extra padding for DES), but we should * eventually fix it to use gss_context_query_attributes(). */ -- Luke= --Apple-Mail=_60A21C7C-8A88-4186-9F6C-C7CD5D8AEC45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Also, do I recall correctly that Luke = was going to do some research on
this?  I've been trying to get = some answers by reading DCE C706, but
it's not = easy.

Yeah, and you won't find it there = because GSS wasn't in the original DCE RPC spec (only raw Kerberos). = Instead I think you want [MS-RPCE] 2.2.2.11 which says the auth trailer = must be 4 byte aligned, and that it's OK to zero fill the trailer if you = over-allocated.

I'm a bit skeptical about the 4 = byte alignment in practice. In the last implementation I worked on, I = made the following note:

/*
 * = [MS-RPCE] states that the stub data is padded to = the underlying
 * blocksize (or four bytes, if that is = greater). In practice they
 * use the underlying keysize when = the blocksize is one. For now,
 * a constant 16 bytes works = for all known ciphers and mechanisms
 * (at the expense of = 8 bytes extra padding for DES), but we should
 * eventually = fix it to use = gss_context_query_attributes().
 */
-- Luke
= --Apple-Mail=_60A21C7C-8A88-4186-9F6C-C7CD5D8AEC45-- From lukeh@padl.com Wed Aug 7 16:39: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 0AE0511E8162 for ; Wed, 7 Aug 2013 16:39:23 -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] 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 dM-QBnOgT8jw for ; Wed, 7 Aug 2013 16:39:17 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C521F9C28 for ; Wed, 7 Aug 2013 16:39:16 -0700 (PDT) Received: by us.padl.com with ESMTP id r77Nd02L001079; Wed, 7 Aug 2013 19:39:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <2564ED1A-FFEE-4304-8501-29510BC103D5@padl.com> Date: Thu, 8 Aug 2013 09:38:59 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5683F570-EB39-4B79-9C5C-0DA00E5AA763@padl.com> References: <2564ED1A-FFEE-4304-8501-29510BC103D5@padl.com> To: Tom Yu 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, =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= , Michiko Short Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 07 Aug 2013 23:39:23 -0000 On 08/08/2013, at 9:15 AM, Luke Howard wrote: >> Also, do I recall correctly that Luke was going to do some research = on >> this? I've been trying to get some answers by reading DCE C706, but >> it's not easy. >=20 > Yeah, and you won't find it there because GSS wasn't in the original = DCE RPC spec (only raw Kerberos). Instead I think you want [MS-RPCE] = 2.2.2.11 which says the auth trailer must be 4 byte aligned, and that = it's OK to zero fill the trailer if you over-allocated. To be clear: the DCE RPC auth padding is at the application layer so = it's orthogonal to any Kerberos padding. (NB: for pre-RFC 4121 enctypes = such as RC4/DES, PKCS#7 padding is disabled; presumably a putative MS = implementation wouldn't do this for RFC 4121 enctypes that require = padding.) The salient point from [MS-RPCE] is that the trailer can be variable = length (because it's OK to zero fill if you over-allocated). So you can = have a variable length filler (RFC 4121 s.4.2.4) containing the = PKCS#7-ish padding. I think we're good to go! -- Luke= From lukeh@padl.com Wed Aug 7 16:46:10 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 ED20921F9A04 for ; Wed, 7 Aug 2013 16:46:04 -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.000, 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 KfxdOvZwqMci for ; Wed, 7 Aug 2013 16:45:58 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C916121F9A1D for ; Wed, 7 Aug 2013 16:45:52 -0700 (PDT) Received: by us.padl.com with ESMTP id r77NjS1n001217; Wed, 7 Aug 2013 19:45:31 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <20130807185358.263CC1A8EE@ld9781.wdf.sap.corp> Date: Thu, 8 Aug 2013 09:45:28 +1000 Content-Transfer-Encoding: 7bit Message-Id: <7B4FC5F8-17E2-4B4C-B011-8A5C98EB1526@padl.com> References: <20130807185358.263CC1A8EE@ld9781.wdf.sap.corp> To: mrex@sap.com 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] 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, 07 Aug 2013 23:46:10 -0000 > I just found another one: > > http://tools.ietf.org/html/rfc2743#page-84 > > 04 01 exported name (token) created by gss_export_name() Ah yes, then you also need RFC 6680 s.7.8: 04 02 exported composite name(token) created by gss_export_name_composite() -- Luke From nico@cryptonector.com Wed Aug 7 21:00: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 54B1A11E81A3 for ; Wed, 7 Aug 2013 21:00:13 -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 oqRUOPCY+EgA for ; Wed, 7 Aug 2013 21:00:08 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 62ECF11E81A4 for ; Wed, 7 Aug 2013 21:00:08 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id A240E27BC06F for ; Wed, 7 Aug 2013 21:00:07 -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=XZVztQHmtv+0efQ9W2Me ENZDh4Q=; b=tBo+MJtcccdiSdLgyDcnNHGTLDI8fdgSbccsikLK4mGwBoZGp9bA VEs6gTkHY7U4RWvNnPnayZpZ+DMxp+78rJt+UXsRcWH+TG7l+f6lp+7R++HHl5Wd VvBB/ReVhE+u1TVUM//ZQIXmCtbYWrU/gRhlILS2crKnVARsBmrtCdM= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 3197527BC06B for ; Wed, 7 Aug 2013 21:00:07 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr7so129581wib.10 for ; Wed, 07 Aug 2013 21:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r3d+ICEFxNKcgXz/uZAcdhQZPEZBNphqge/lscpUHBg=; b=InhlLAjv7sli5PfA163R2gzFR84elqq1cyI7xRWfi3TnyqW+sj1il5k6zD0BWbE46b V9Fw7OSh70NdBM3MDJiV2qYolmzvpdt4YpLrKrZcAYBE+bEdJCI+f2g9fR0gto1730aq P96An2v0jPfFFQArFM2m883attNvlXgM3rh+tTHdCQiGLW+eWN9S9tE5OyRKV9XyOnqm F728Isn+AfCaAXZiQpEMWxfIzhC6cnx10DPL2Uqy26ERFfueUAS8bDZh0ZUg7ul0KDW7 CFsUlKcUCKcBkg9DijX7W/xcMKZ3BVS/DPAY9HfU88664USDBvOR3QLvSJt4kjOUi7Nb bbaQ== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr3863401wic.33.1375934405464; Wed, 07 Aug 2013 21:00:05 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Wed, 7 Aug 2013 21:00:05 -0700 (PDT) In-Reply-To: References: <20130708021106.14072.49434.idtracker@ietfa.amsl.com> Date: Wed, 7 Aug 2013 23:00:05 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-00.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, 08 Aug 2013 04:00:13 -0000 On Wed, Aug 7, 2013 at 4:09 PM, Benjamin Kaduk wrote: > I have reviewed this document; the following comments are basically > editorial in nature, with no substantial flaws in the technical proposal. Thanks! > In the abstract, "Additional API elements related to this are also added", > what is "this"? channel binding? Well, the whole subject of the I-D, yes. > Section 1.2 seems rather informal for a standards-track submission. (The Suggestions welcomed. > whole document's use of "we" is a bit dubious, too, but that's a harder > change to make.) Would 1.3 and 1.4 (and in general, all "future work" > comments) be better in an appendix? If it makes it onto the Standards-Track then it really is "we"/"us". I don't want to speak in the first person just to create extra work for the RFC-Editor. Perhaps you can suggest better wording that doesn't have this problem and doesn't feel more artificial still. > In the first sentence of 1.3, you have a comma that begins a parenthetical, > but no comma to end the parenthetical. it's not a parenthetical, it's a list of adjectives ("existing", "non-standard"); "and" might be better than a comma, but I'm all "meh" about it. > In section 2.2, please make it more explicit that in order to use the > req_flags given to GSS_Set_context_flags(), the input flags to > GSS_Init_sec_context() must be all zero. Introducing the new FLAGS type in Oh, that's probably better, yeah, and GSS_Init_sec_context() should even return an error otherwise. > a "NOTE:" is probably not appropriate for a standards-track document. Sure, I should add a sub-section just to describe FLAGS. But it will be very brief :) > In 2.2.1, it's probably worth making a note that the flags are now 64-bit > fields instead of 32-bit. Er, sure. And that it's 64-bit, not "at least 64-bit". > In 2.5, I don't think the first sentence provides sufficient description of > the flag. Please give a full paragraph with such a description, and split > the rest of the (current) paragraph into a separate paragraph. OK. > Section 2.5.1's use of the phrase "both flags" is a little vague; I'd like > to see some text indicating why the two flags are related. I think it's clear enough. The two flags need not be related at all in order to share the same bit assignment -- as long as they can't be used in the same context (one is a req_flag but not a ret_flag and vice-versa). > In 2.6, I would say "applied to an empty security context" instead of the > plural form currently given. OK. > In the first bullet point of section 3, the use of commas to group the > clauses which "both" binds together scans pretty awkwardly. Can't we just > use the same (a) and (b) style as in the other bullet points? There's a missing comma before "do not match". Would that help? But, sure, I can do the (a) and (b) thing. (I must have switched in the second bullet because the text for (b) there got unwieldy.) > Throughout section 3, I don't see much precedent for the use of > "input_channel_bindings" as a variable name. RFC2743 has "chan_bindings", > the MIT krb5 gssapi.h has "/* input_chan_bindings */" and Heimdal's header > matches MIT's. The latter match RFC2744. Hmm, well, I think it's clear enough. And I prefer it this way. If it's really obnoxious I could change it, but I'll note that we're already rather inconsistent about argument naming throughout the GSS-API. > I agree with the overall scheme, as mentioned when we were debating between > alternate approaches. Excellent! I'll submit a new version. We should implement and WGLC. Nico -- From lukeh@padl.com Wed Aug 7 21:10:44 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 3E5ED21F9CE9 for ; Wed, 7 Aug 2013 21:10:44 -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.000, 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 zJEa-3u2ANXs for ; Wed, 7 Aug 2013 21:10:40 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8897F21F9CE8 for ; Wed, 7 Aug 2013 21:10:38 -0700 (PDT) Received: by us.padl.com with ESMTP id r784AI7U011855; Thu, 8 Aug 2013 00:10:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <5683F570-EB39-4B79-9C5C-0DA00E5AA763@padl.com> Date: Thu, 8 Aug 2013 14:10:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <85404126-AFBC-4A53-97B4-42C3C0569523@padl.com> References: <2564ED1A-FFEE-4304-8501-29510BC103D5@padl.com> <5683F570-EB39-4B79-9C5C-0DA00E5AA763@padl.com> To: Tom Yu 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, =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= , Michiko Short Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 08 Aug 2013 04:10:44 -0000 > To be clear: the DCE RPC auth padding is at the application layer so = it's orthogonal to any Kerberos padding. (NB: for pre-RFC 4121 enctypes = such as RC4/DES, PKCS#7 padding is disabled; presumably a putative MS = implementation wouldn't do this for RFC 4121 enctypes that require = padding.) Well, almost orthogonal. Maybe at right angles or something. :-) It's not orthogonal in the sense that: if the DCE RPC auth padding pads = the PDU to the underlying block size, then you can guarantee that the = auth trailer will be a constant size. But, as I mentioned in my earlier = message, because [MS-RPCE] permits variable length trailers by allowing = the trailer length to be over-allocated, constant size is not a = requirement. According to the spec, you could align to a 4 byte boundary and do any = additional padding in the RFC 4121 filler (which after rotation ends up = in a single token, placed in the auth trailer). Whether Microsoft's = implementation uses 4 bytes, I'm unsure although it should be possible = to instrument our SSP to determine this. Now, there are bugs in Microsoft's RFC 4121 implementation when DCE is = in effect: even though no padding is required for CTS, their = implementation rejects non-zero EC, and miscalculates the RRC. Not being = privy to their implementation, I cannot say whether this would carry = over to any future enctypes. -- Luke PS. http://code.metager.de/source/xref/dcerpc/dcerpc/ncklib/gssauthcn.c = if anyone wants to see an implementation.= From kaduk@mit.edu Wed Aug 7 21:13: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 DA0A411E81B2 for ; Wed, 7 Aug 2013 21:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 EUyv5pqZxyzQ for ; Wed, 7 Aug 2013 21:13:37 -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 C92C311E81A3 for ; Wed, 7 Aug 2013 21:13:33 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-ea-52031ae5db7e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 62.7D.02359.5EA13025; Thu, 8 Aug 2013 00:13:25 -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 r784DOaM032220 for ; Thu, 8 Aug 2013 00:13:25 -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 r784DMdU012674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Aug 2013 00:13:24 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r784DMLn016124; Thu, 8 Aug 2013 00:13:22 -0400 (EDT) Date: Thu, 8 Aug 2013 00:13:22 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: 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+NgFtrLIsWRmVeSWpSXmKPExsUixCmqrftUijnI4PBiNYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr41ynY8Er8Yofx9vZGhi/C3UxcnJICJhIfP+7jhXCFpO4cG89 WxcjF4eQwD5GiXNf+xlBEkICxxglnjX7QiSuM0n0T1nBDJGol1i28A2YzSKgJfHjw1ImEJtN QEVi5puNbCC2iICwxO6t78BqhAW8JE5c7wGr4RVwlFjbdAtss6iAjsTq/VNYIOKCEidnPgGz mQUsJf6t/cU6gZFvFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3 MYJDSZJ3B+O7g0qHGAU4GJV4eB8EMQUJsSaWFVfmHmKU5GBSEuXdJcEcJMSXlJ9SmZFYnBFf VJqTWnyIUYKDWUmE92IxUDlvSmJlVWpRPkxKmoNFSZz36dOzgUIC6YklqdmpqQWpRTBZGQ4O JQneP5JAQwWLUtNTK9Iyc0oQ0kwcnCDDeYCG8wNjT4i3uCAxtzgzHSJ/ilFRSpz3P0izAEgi ozQPrhcW668YxYFeEeadDVLFA0wTcN2vgAYzAQ32OMkAMrgkESEl1cBoKfLRl0387ffJ23oa RG9ICPy3PZVjbnGp5Sa/yZuvCnF3v08RFsmfJHR6bVo9/7uTBt7ro7nP2B5J3tT8aPk59pMO GR+M2PfXvPDY9zL92M9/6q8qHsya4bNO5EXvyevdv/yuFm7dNeuUxdZjEQuvqlreEtS3l5jM zJ8z/+iVxKPf9cI/la05oMRSnJFoqMVcVJwIAC3MrB/QAgAA Subject: Re: [kitten] ID-Action: draft-williams-kitten-generic-naming-attributes-00 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, 08 Aug 2013 04:13:44 -0000 [Sorry for the lack of in-reply-to, I lost the original] I have reviewed this document, comments below. I don't understand what the second sentence of section 2.1 is trying to say. In section 2.1.1, "obtain a name of an issuer of a mechanism name", are there supposed to be multiple issuers of a given mechanism name? Maybe "the issuer" is better. In the last paragraph, "used as prefix" needs an 'a' -- "used as a prefix". "non-display" appears in square brackets in 2.1.1 but not when used later. (2.1.3) Off the top of my head, I'm not sure how much sense it makes to have the non-display form of the service name just be a character string, but that may just be because my instincts for GSS names are formed from looking at principal names. (2.1.4) I'm not sure I'm comfortable using "host name" to describe a "domain-based service name". I am just now learning about U-labels and A-labels by reading exerpts of RFC 5890, but its page 11 definition of a "U-label" seems to indicate that it must include at least one non-ASCII character. Hopefully this is just a misunderstanding based on an incomplete reading of the spec, otherwise it would be quite odd. I'm a bit curious what the motivation is for using Unicode for display and ASCII for non-display. I'm also not sure what is meant by "stylized" for the display form ... is there a reference to put there? A-labels have a length limit of 59 ASCII characters? That seems potentially restrictive, if I am remembering correctly. (2.1.5) Similar comments apply. I guess 2.1.4 should skip the mention of domain-based service names and dever to 2.1.5. Section 2.2 appears to impose very severe constraints on the implementation without much fanfare, indicating that retrieving any name attributes MUST check for name constraints and reject the request if constraints are not satisfied. I would have expected this restriction to be mentioned sooner in the document. I see there's a "fill in more" note in the security considerations on this topic; given that it is an implementation constraint, I'm not sreu that that would be sufficient. Of course, then 2.2.1 provides a way to disable that checking. In general, my sense is that this document is too short, and contains just a part (perhaps even the core) of a complete document. It throws out a few name attributes and gives some sense of how they might be accessed, but no motivation for why they might be desirable or how they might be used. Hmm, would fleshing out the introduction be enough? I guess it would be almost all of the way there, but the subsubsections of section 2 could benefit from a slightly longer description of the meaning of the indicated name components. Having access to name attributes of this nature from the GSSAPI layer does seem useful (maybe I am coming at this from a Kerberos-centric view? Other opinions are very welcome), so I think that this document should move forward in some form. -Ben From nico@cryptonector.com Wed Aug 7 22:02:38 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 20DC911E80E7 for ; Wed, 7 Aug 2013 22:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 GuIqEqhQLDxy for ; Wed, 7 Aug 2013 22:02:33 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE2E11E80D9 for ; Wed, 7 Aug 2013 22:02:32 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id F0F9C768059 for ; Wed, 7 Aug 2013 22:02:31 -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=h/SFKGPejmtR4hvD2bRB 0FKXzvU=; b=AJAq7wqVpzKIDafcikf28w9iou25uPK6hGW4Anm78s7c/KaaNrL+ BY5v0jVF5r9NLpvCQ0P7YPAYkpl5fWUUiHdfgCOcfoSwdbCKgo17q/Q3ILYbMC5v ZC4tsENlZtpg/HXfwhg6CjT2u/a/WIeFceKVMFmCffnChkp/P5Zgr7w= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 77C81768056 for ; Wed, 7 Aug 2013 22:02:31 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u55so2228903wes.27 for ; Wed, 07 Aug 2013 22:02:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hvPRY6qwQT0N6ipvftdRbmirwd/aa/IgfPoMjwDl3dE=; b=gqXo7TLBaEJiZpxls6fCkuzVIUnxfd6TB5VmjrILOtE+VBaoe0Bs9VeK9YIGAFr5EN ELEwShz70KcaQIY+GuDRoArAGQDNfG5Wd7jMIspwwpALUgfTPJXeBtUeYFSMYuSAZbpo OjAbY5R6qNIAshHJ9DYJR9d+2fWCC50xlJd4EzFtX4NbJxyinEe0pB6eTO4e3CTcImcM /qE9mOmQEumBJX+/Ic167vtIAZ8tQ5aRm7QyhGhGGBw+yPp4wlfgzI2/+RADil3Adce8 NgGPYZD8jOLTT6upxA3WqqfO6920ZAkOE+CF/DFFfuvXz+gC3m0O72++5TrqIZBa2t38 oftg== MIME-Version: 1.0 X-Received: by 10.194.220.103 with SMTP id pv7mr280580wjc.14.1375938149650; Wed, 07 Aug 2013 22:02:29 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Wed, 7 Aug 2013 22:02:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Aug 2013 00:02:29 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] ID-Action: draft-williams-kitten-generic-naming-attributes-00 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, 08 Aug 2013 05:02:38 -0000 On Wed, Aug 7, 2013 at 11:13 PM, Benjamin Kaduk wrote: > I have reviewed this document, comments below. Thanks! > I don't understand what the second sentence of section 2.1 is trying to say. Ah, that requires having read RFC6680 first. I'll expand on this. I'll also provide a fuller introduction (see also below). > In section 2.1.1, "obtain a name of an issuer of a mechanism name", are > there supposed to be multiple issuers of a given mechanism name? Maybe "the > issuer" is better. In the last paragraph, "used as prefix" needs an 'a' -- > "used as a prefix". Thanks for noticing these mistakes. > "non-display" appears in square brackets in 2.1.1 but not when used later. That's just me not knowing how to deal with a bit of awkwardness in GSS_Get_name_attribute(): it returns a value and a display_value. I'm trying to indicate that when getting the issuer name of an MN or an MN attribute, the value returned in the 'value' output parameter should be an exported name token. > (2.1.3) Off the top of my head, I'm not sure how much sense it makes to have > the non-display form of the service name just be a character string, but > that may just be because my instincts for GSS names are formed from looking > at principal names. Well, RFC2743 is pretty clear that service names are strings... so what else could we do here? [I suppose that if we opened the I18N pandora box we could say that the display_value's are always in whatever the caller's current locale's codeset is, while the value of service name attributes would be in... well, we'd want UTF-8, but RFC2744 says Latin-1, but with no real authority (it says "may", not even "MAY", though it also doesn't use any RFC2119 language, nor does it reference it). Can we close this pandora box now? :/] > (2.1.4) I'm not sure I'm comfortable using "host name" to describe a > "domain-based service name". I am just now learning about U-labels and This is in reference to the host name component of a) host-based service names, and b) domain-based service names (which have both, domain and host name components). > A-labels by reading exerpts of RFC 5890, but its page 11 definition of a > "U-label" seems to indicate that it must include at least one non-ASCII > character. Hopefully this is just a misunderstanding based on an incomplete > reading of the spec, otherwise it would be quite odd. I'm a bit curious > what the motivation is for using Unicode for display and ASCII for > non-display. I'm also not sure what is meant by "stylized" for the display > form ... is there a reference to put there? A-labels have a length limit of > 59 ASCII characters? That seems potentially restrictive, if I am > remembering correctly. This is part of the GSS I18N pandora's box. The problem is pre-existing and I'm making it no worse, but I'm trying to make it better. Yes, I'm not saying anything about codeset for display_value, and neither does RFC6680, but I refer to U-Labels -- I suppose that U-Labels can be encoded in non-Unicode encodings, as long as there's no loss of information in the conversion. I don't want to resolve the issue of what codeset to use for either query or display strings at this time, mostly because it seems like a good way to waste time on an argument, but if the WG likes we could have this discussion. Preview: I'm all for saying that query and display strings are in the codeset of the caller's locale, primarily because anything else instantly complicates usage of the API and *also* fails to match reality. > (2.1.5) Similar comments apply. I guess 2.1.4 should skip the mention of > domain-based service names and dever to 2.1.5. No, domain-based service names have three components: service, hostname, and domainname, so section 2.1.4 applies to domain-based service names too. > Section 2.2 appears to impose very severe constraints on the implementation > without much fanfare, indicating that retrieving any name attributes MUST > check for name constraints and reject the request if constraints are not > satisfied. I would have expected this restriction to be mentioned sooner in > the document. I see there's a "fill in more" note in the security > considerations on this topic; given that it is an implementation constraint, > I'm not sreu that that would be sufficient. I pondered about this and sought advice while implementing. I decided that I wanted three modes of operation: a) naming constraint check failure -> failure; b) naming constraint check status indicated; c) no naming constraint checks. with (a) as the default. All three are provided. You call (a) severe, but I call it "fail closed" or "fail safe". Formalizing a notion of issuer requires talking about name constraints. Kerberos has no formal notion of name constraints, but in practice we have them, in a way, and it's easy enough to create some very simple rules. > Of course, then 2.2.1 provides a way to disable that checking. Right! > In general, my sense is that this document is too short, and contains just a > part (perhaps even the core) of a complete document. It throws out a few You're absolutely right that it needs a lengthier intro. > name attributes and gives some sense of how they might be accessed, but no > motivation for why they might be desirable or how they might be used. Hmm, > would fleshing out the introduction be enough? I guess it would be almost I will add such text. For the time being let me just say that there are many applications that parse Kerberos MN display or exported name forms, which results in rather unportable code. GSS_Display_name_ext() turns out to be unsatisfactory and redundant (since what it does can be done by GSS_Get_name_attribute() to get a suitably defined attribute) -- unsatisfactory because it has no notion of name constraints checking or issue. An attribute model of naming that reflects reality (i.e., all the components of Kerberos and other mechanism principal naming) needs to do better. Consider an application that allows access to, say, root/client-hostname.fqdn... (think of NFS servers). The application will want to be able to access the service name, the hostname, and also, _of course_ the realm name (for obvious reasons). Now, if that application parses krb5 MN display/exported name token forms then that application ceases to be generic. If the application uses GSS_Get_name_attribute() and the attributes defined in this I-D then the application can be totally generic *and* safe. That is, roughly, the motivation. Other attributes will follow, some as originally envisioned for the RFC6680 interfaces. > all of the way there, but the subsubsections of section 2 could benefit from > a slightly longer description of the meaning of the indicated name > components. Having access to name attributes of this nature from the GSSAPI > layer does seem useful (maybe I am coming at this from a Kerberos-centric > view? Other opinions are very welcome), so I think that this document > should move forward in some form. It's more than useful. It's essential. We didn't know we were missing these attributes because we were so used to not having them. Nico -- From lukeh@padl.com Wed Aug 7 22:09: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 503BA11E80D9 for ; Wed, 7 Aug 2013 22:09:23 -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.000, 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 gASgJdyAZI2h for ; Wed, 7 Aug 2013 22:09:18 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6711E80E7 for ; Wed, 7 Aug 2013 22:09:12 -0700 (PDT) Received: by us.padl.com with ESMTP id r7858w5o013901; Thu, 8 Aug 2013 01:09:00 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <85404126-AFBC-4A53-97B4-42C3C0569523@padl.com> Date: Thu, 8 Aug 2013 15:08:57 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <40AC18B0-6F5E-4D62-9438-A3666CC9FC08@padl.com> References: <2564ED1A-FFEE-4304-8501-29510BC103D5@padl.com> <5683F570-EB39-4B79-9C5C-0DA00E5AA763@padl.com> <85404126-AFBC-4A53-97B4-42C3C0569523@padl.com> To: Tom Yu 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, =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= , Michiko Short Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 08 Aug 2013 05:09:23 -0000 On 08/08/2013, at 2:10 PM, Luke Howard wrote: >> To be clear: the DCE RPC auth padding is at the application layer so = it's orthogonal to any Kerberos padding. (NB: for pre-RFC 4121 enctypes = such as RC4/DES, PKCS#7 padding is disabled; presumably a putative MS = implementation wouldn't do this for RFC 4121 enctypes that require = padding.) >=20 > Well, almost orthogonal. Maybe at right angles or something. :-) Um. 45 degrees. Obviously it's a long time since I've used a protractor. -- Luke= From nico@cryptonector.com Wed Aug 7 22:18:22 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 542CB11E81A4 for ; Wed, 7 Aug 2013 22:18:22 -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 yhrvrEKetkbT for ; Wed, 7 Aug 2013 22:18:17 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id BB82821F8F63 for ; Wed, 7 Aug 2013 22:18:16 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 3088967C06E for ; Wed, 7 Aug 2013 22:18:16 -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=H6hD+8KDQSUpk4i4SoSj oz6s904=; b=NmSKrPjY1WZDc3m2lFg/qR1sbqN9HzlTcMsZ5XuEGntJCIhyRxlJ jB3Wi9SnP1CINHUnruaJrMa91cZv3yBtOI+AOpWbKcGWJW30naE6MUavVZM/ATkU GEsy0r5HEY8YQVBEDCiikSzlLbhOASrBVLyepCydAN3IIKzMf0oG43U= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 D957467C069 for ; Wed, 7 Aug 2013 22:18:15 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so172828wib.17 for ; Wed, 07 Aug 2013 22:18:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lsz2cZV0/6PsUxMYx3Qak0xg45iPBB1Vl2/SmfKxo5Y=; b=EQ1ZMcLsOKBN/BHkqV2KQQxLrLqdrBd69BVHRWKzczd0x9FWuPZH6oW6KXFWm1/O2D 3bksjqCmf5BpzxcQzj3gMm2iKQo1oJysyteseJz1yWNkRXluUkrifs6GMJWAbU74hkJT 8pUOQg9PhQ9q1y8GTW8yCKOQ8WTGm913+RcHdMjEMtrX8xaAOX27aJYtTnFjmuYLJOgE 4QD6KjDGZ62BEkDKNlCrProoNzm6lfwsFHJelfAD53XbWQjKUvmRigE4gA3Q2FdBrHpE zDpjLRB+XJHs3QYAdb2Bgny5U372SdsYP0h6jqQRf/eZC7+fMmwpu1Wwks/UM5ocM30e ZLTQ== MIME-Version: 1.0 X-Received: by 10.180.36.169 with SMTP id r9mr562378wij.20.1375939094526; Wed, 07 Aug 2013 22:18:14 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Wed, 7 Aug 2013 22:18:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Aug 2013 00:18:14 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] ID-Action: draft-williams-kitten-generic-naming-attributes-00 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, 08 Aug 2013 05:18:22 -0000 On Thu, Aug 8, 2013 at 12:02 AM, Nico Williams wrote: > [I suppose that if we opened the I18N pandora box we could say that > the display_value's are always in whatever the caller's current > locale's codeset is, while the value of service name attributes would > be in... well, we'd want UTF-8, but RFC2744 says Latin-1, but with no > real authority (it says "may", not even "MAY", though it also doesn't > use any RFC2119 language, nor does it reference it). Can we close > this pandora box now? :/] I should have added that in practice service names are all US-ASCII, so we don't need to open that box on account of *this* attribute. > Consider an application that allows access to, say, > root/client-hostname.fqdn... (think of NFS servers). The application > will want to be able to access the service name, the hostname, and > also, _of course_ the realm name (for obvious reasons). Now, if that > application parses krb5 MN display/exported name token forms then that > application ceases to be generic. If the application uses > GSS_Get_name_attribute() and the attributes defined in this I-D then > the application can be totally generic *and* safe. I should add that typical NFS servers want to grant "root-equivalent" access to client principals that have a service-like component named "root" and a hostname-like component that appears in an ACL (and possibly corresponds to the client's IP address, either via forward or reverse lookup). I say "service-like" and "hostname-like" because the name type may not actually be set to a host-based service name type, and the client is clearly not a service, but the shoe fits. I've seen host-based service style client naming in widespread usage at various companies, FYI. "Parsing" them is a common thing to do. It sucks. Nico -- From kaduk@mit.edu Thu Aug 8 10:18:57 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 9A8361F0D10 for ; Thu, 8 Aug 2013 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 8miLp3PK-riB for ; Thu, 8 Aug 2013 10:18:51 -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 B1B5321F9EE2 for ; Thu, 8 Aug 2013 10:18:50 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-84-5203d2f9736e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 44.3F.02359.9F2D3025; Thu, 8 Aug 2013 13:18:49 -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 r78HImGj029656; Thu, 8 Aug 2013 13:18:48 -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 r78HIj1t030537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Aug 2013 13:18:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r78HIi56026452; Thu, 8 Aug 2013 13:18:44 -0400 (EDT) Date: Thu, 8 Aug 2013 13:18:44 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <20130708021106.14072.49434.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA01SXUhTURz33HudZ2M3zu78OC6FuPiiOcvowcIkn9qTNYOQDOrmTu7qdmf3 TnNC5aMKlg+ROrNEDPMDLAcpJIrLRActs9KCmBEKZprUk4ZE92748fb7n98X55w/pLktxgJF yUtkSXDxOgPDJRRkWLfn6eLjA83peW8C/UxeaGFKd5ay/QiFga2nZ5u6QF025DuIS6wh8rGC awZn16afqYqk1f6ckerBSnIT0EOMTuLOZ/8SYjgZz0WGdE3AADk0DvDcNz+IDc8BDrxsZWLD JIU/1kdozcKhu3hkuSFqZ1AWvr/8G2hYhzJw+/oLnYYTUSZefPw0imlkxkPhtqjXjM7jUHNY 9UKoR3Y8PZ6vHbOoEK+PNsbHusYA7v06GPUmoWw8MPGAiYlMeLZ9mYllnsLhnUVdCzD5D1D+ A1QXoPpBusNdZ3ULokshZValTJAkIltP5LhFbw5xVA8D7VH1qewo+DXJBwGCgDeyR0boYi5e qFF87iBIhRSfxPa9U48OXfc4fE5BcV6Vq11ECQIMaT6RXa1QOdYh+OqI7NmlDkOGT2FXVt7a OVQueEklIVVE3mXTIOQxa1E/kjPJpJzU3hBd3n2agnot3KiG52kaVqkS3IpYHuNDwAp3+jr/ AI6RPBKxpLCUJkKayFkt7eXsLswaSFGvZWZNmsqortNe0ppaQqklttk4rcQr7FOWejAxWtsx tbFYAive6+NXjbhoo23mSVtgKXczk1m13+tv7Tj6nX5UOtixPV1n++zkluwflCEoZoy7PWnD pXHnmmj/wwJLg9xl+tLb3Wjr9hkoD7x52zhmnpe3Xp3O+VuZmV1jo8RQy2uOK2z9FLQvyEln IoE74aKLl0qu3OIZxSnkZtGyIvwH5h4jjAsDAAA= Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-00.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, 08 Aug 2013 17:18:57 -0000 On Wed, 7 Aug 2013, Nico Williams wrote: > On Wed, Aug 7, 2013 at 4:09 PM, Benjamin Kaduk wrote: > >> Section 1.2 seems rather informal for a standards-track submission. (The > > Suggestions welcomed. I'd probably just skip the historical discussion and mailing list mention and go straight to a declarative statement: A useful aspect of the Java Bindings of the GSS-API is appropriated for the abstract API, specifically the notion of creating [...] >> whole document's use of "we" is a bit dubious, too, but that's a harder >> change to make.) Would 1.3 and 1.4 (and in general, all "future work" >> comments) be better in an appendix? > > If it makes it onto the Standards-Track then it really is "we"/"us". > I don't want to speak in the first person just to create extra work > for the RFC-Editor. Perhaps you can suggest better wording that > doesn't have this problem and doesn't feel more artificial still. It sounds like my point came across badly -- it wasn't a question of "we" versus "I", but rather the "we propose", "we are likely to", etc.. I know that RFC stands for "request for comments" and thus proposal language should be fitting, but I'm more used to seeing declarative specification like "a new X is created, which Y". >> In the first sentence of 1.3, you have a comma that begins a parenthetical, >> but no comma to end the parenthetical. > > it's not a parenthetical, it's a list of adjectives ("existing", > "non-standard"); "and" might be better than a comma, but I'm all "meh" > about it. Hmm, okay. It doesn't look as bad now, rereading it. >> In section 2.2, please make it more explicit that in order to use the >> req_flags given to GSS_Set_context_flags(), the input flags to >> GSS_Init_sec_context() must be all zero. Introducing the new FLAGS type in > > Oh, that's probably better, yeah, and GSS_Init_sec_context() should > even return an error otherwise. Well, erroring out would remove the feature (allowed by the present text) of being able to override the flags from context-creation time at Init_sec_context time. Either would be fine with me, so long as the text is clear. >> a "NOTE:" is probably not appropriate for a standards-track document. > > Sure, I should add a sub-section just to describe FLAGS. But it will > be very brief :) Yup :) >> In the first bullet point of section 3, the use of commas to group the >> clauses which "both" binds together scans pretty awkwardly. Can't we just >> use the same (a) and (b) style as in the other bullet points? > > There's a missing comma before "do not match". Would that help? But, > sure, I can do the (a) and (b) thing. (I must have switched in the > second bullet because the text for (b) there got unwieldy.) The extra comma would help some, but I think the a/b would be substantially more clear (and would make the whole list consistent). >> Throughout section 3, I don't see much precedent for the use of >> "input_channel_bindings" as a variable name. RFC2743 has "chan_bindings", >> the MIT krb5 gssapi.h has "/* input_chan_bindings */" and Heimdal's header >> matches MIT's. > > The latter match RFC2744. That would have been clever for me to look at, whoops. > Hmm, well, I think it's clear enough. And I prefer it this way. If > it's really obnoxious I could change it, but I'll note that we're > already rather inconsistent about argument naming throughout the > GSS-API. I don't really care, I was just noting the inconsistency. It calls to mind the mandatory/required checksum type split I noted in a different thread. -Ben From kaduk@mit.edu Thu Aug 8 11:24: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 AB4BB11E8163 for ; Thu, 8 Aug 2013 11:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 f0H3S+RgBqTW for ; Thu, 8 Aug 2013 11:24:37 -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 04DE321F9E37 for ; Thu, 8 Aug 2013 11:24:35 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-85-5203e2636674 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F0.7D.02387.362E3025; Thu, 8 Aug 2013 14:24:35 -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 r78IOXuH007882; Thu, 8 Aug 2013 14:24:34 -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 r78IOVI0005906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Aug 2013 14:24:32 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r78IOVpH004811; Thu, 8 Aug 2013 14:24:31 -0400 (EDT) Date: Thu, 8 Aug 2013 14:24:30 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams 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+NgFvrGIsWRmVeSWpSXmKPExsUixG6nopv8iDnI4PZ2Toujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4PrWZqWCzesWVVcUNjNvkuxg5OCQETCTO vhDqYuQEMsUkLtxbz9bFyMUhJLCPUeL2h7mMIAkhgQ2MElOO+kEkDjJJ7Ns+lQUiUS+x+8kk NhCbRUBL4vqOzWANbAIqEjPfbASLiwhoSlyftxTMZhYQllh/bgYzyGJhgVCJaY15IGFOgUCJ 6/dusoLYvAKOEjumr2CG2NXGKHH62T92kISogI7E6v1TWCCKBCVOznzCAjHTUuLcn+tsExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXRC83s0QvNaV0EyMoSDkl+Xcwfjuo dIhRgINRiYdXYTtzkBBrYllxZe4hRkkOJiVR3r6HQCG+pPyUyozE4oz4otKc1OJDjBIczEoi vC+ygHK8KYmVValF+TApaQ4WJXHeZ0/PBgoJpCeWpGanphakFsFkZTg4lCR4p4EMFSxKTU+t SMvMKUFIM3FwggznARpuA1LDW1yQmFucmQ6RP8Woy/Fn5dxPjEIsefl5qVLivJIgRQIgRRml eXBzYMnlFaM40FvCvOEgVTzAxAQ36RXQEiagJR4nGUCWlCQipKQaGJV953eaHw5c7Z5u6sFi bLW0hIlp8fofmdv8RAI+f4tNePTG47Xwjb0M85kT+6KbzrNUlU10nbHcfl3j/r1ZLm5qe+8c TC79Lut+t2L/0dvPXjQLaKz4H++17tedh4dezNT/kPk7PJznV7jt/GOSZmcbA7Vc+9bIG8jr aGuK2sebWEbOkzPpV2Ipzkg01GIuKk4EAMYL3HUJAwAA Cc: kitten@ietf.org Subject: Re: [kitten] ID-Action: draft-williams-kitten-generic-naming-attributes-00 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, 08 Aug 2013 18:24:43 -0000 On Thu, 8 Aug 2013, Nico Williams wrote: > On Wed, Aug 7, 2013 at 11:13 PM, Benjamin Kaduk wrote: > >> I don't understand what the second sentence of section 2.1 is trying to say. > > Ah, that requires having read RFC6680 first. I'll expand on this. > I'll also provide a fuller introduction (see also below). Yeah, I only realized it was essentialy to have already read RFC6880 about halfway through the document. The longer introduction should help on that front. >> "non-display" appears in square brackets in 2.1.1 but not when used later. > > That's just me not knowing how to deal with a bit of awkwardness in > GSS_Get_name_attribute(): it returns a value and a display_value. I'm > trying to indicate that when getting the issuer name of an MN or an MN > attribute, the value returned in the 'value' output parameter should > be an exported name token. My emphasis should have been on "not when used later"; I would have expected consistent usage throughout. > use any RFC2119 language, nor does it reference it). Can we close > this pandora box now? :/] What pandora's box? Lalalalalala I can't see anything... ;) >> (2.1.4) I'm not sure I'm comfortable using "host name" to describe a >> "domain-based service name". I am just now learning about U-labels and > > This is in reference to the host name component of a) host-based > service names, and b) domain-based service names (which have both, > domain and host name components). Ah, okay. Sorry for my ignorance. >> Section 2.2 appears to impose very severe constraints on the implementation >> without much fanfare, indicating that retrieving any name attributes MUST >> check for name constraints and reject the request if constraints are not >> satisfied. I would have expected this restriction to be mentioned sooner in >> the document. I see there's a "fill in more" note in the security >> considerations on this topic; given that it is an implementation constraint, >> I'm not sreu that that would be sufficient. > > I pondered about this and sought advice while implementing. I decided > that I wanted three modes of operation: > > a) naming constraint check failure -> failure; > b) naming constraint check status indicated; > c) no naming constraint checks. > > with (a) as the default. All three are provided. > > You call (a) severe, but I call it "fail closed" or "fail safe". I definitely prefer "fail safe" as written. I used the word "severe" in that this tiny text hidden away in the middle is a large ("severe") constraint on implementation behavior, and it doesn't have a big flashing sign "behavior constraint here" in front of it. > Formalizing a notion of issuer requires talking about name constraints. > > Kerberos has no formal notion of name constraints, but in practice we > have them, in a way, and it's easy enough to create some very simple > rules. I agree that there are things that we can do. I think such a document talking about what we can currently do without more discussion of formal notions might run into trouble at (e.g.) IESG review if aiming for standards-track. >> In general, my sense is that this document is too short, and contains just a >> part (perhaps even the core) of a complete document. It throws out a few > > You're absolutely right that it needs a lengthier intro. > >> name attributes and gives some sense of how they might be accessed, but no >> motivation for why they might be desirable or how they might be used. Hmm, >> would fleshing out the introduction be enough? I guess it would be almost > > I will add such text. For the time being let me just say that there Thanks. > are many applications that parse Kerberos MN display or exported name > forms, which results in rather unportable code. > GSS_Display_name_ext() turns out to be unsatisfactory and redundant > (since what it does can be done by GSS_Get_name_attribute() to get a > suitably defined attribute) -- unsatisfactory because it has no notion > of name constraints checking or issue. An attribute model of naming > that reflects reality (i.e., all the components of Kerberos and other > mechanism principal naming) needs to do better. > > Consider an application that allows access to, say, > root/client-hostname.fqdn... (think of NFS servers). The application > will want to be able to access the service name, the hostname, and > also, _of course_ the realm name (for obvious reasons). Now, if that > application parses krb5 MN display/exported name token forms then that > application ceases to be generic. If the application uses > GSS_Get_name_attribute() and the attributes defined in this I-D then > the application can be totally generic *and* safe. > > That is, roughly, the motivation. Other attributes will follow, some I know that, and you know that ... it just needs to be in the document :) -Ben > as originally envisioned for the RFC6680 interfaces. > From michikos@microsoft.com Thu Aug 8 15:02:57 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 B930121F9C06 for ; Thu, 8 Aug 2013 15:02:57 -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 NfXFkF+bRdL3 for ; Thu, 8 Aug 2013 15:02:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 341E421F9C90 for ; Thu, 8 Aug 2013 15:02:50 -0700 (PDT) Received: from BLUPR03CA029.namprd03.prod.outlook.com (10.141.30.22) by BLUPR03MB051.namprd03.prod.outlook.com (10.255.209.151) with Microsoft SMTP Server (TLS) id 15.0.731.11; Thu, 8 Aug 2013 22:02:41 +0000 Received: from BY2FFO11FD005.protection.gbl (2a01:111:f400:7c0c::25) by BLUPR03CA029.outlook.office365.com (2a01:111:e400:879::22) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Thu, 8 Aug 2013 22:02:40 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Thu, 8 Aug 2013 22:02:40 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.223]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Thu, 8 Aug 2013 22:02:09 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) Thread-Index: Ac6UguuCfwuvEtnVS+WRXhLN+l/eLw== Date: Thu, 8 Aug 2013 22:02:08 +0000 Message-ID: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454002)(164054003)(51704005)(199002)(189002)(27574002)(377454003)(13464003)(19580395003)(77096001)(69226001)(51856001)(56816003)(81342001)(80022001)(16406001)(80976001)(65816001)(44976005)(83072001)(83322001)(81542001)(74662001)(19580405001)(47736001)(50466002)(6806004)(79102001)(23756003)(49866001)(74366001)(47446002)(31966008)(63696002)(54356001)(53806001)(47976001)(47776003)(74876001)(59766001)(4396001)(76796001)(46102001)(76482001)(74502001)(74706001)(50986001)(55846006)(66066001)(76176001)(33656001)(20776003)(54316002)(76786001)(77982001)(56776001)(81686001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB051; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 093290AD39 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BY2FFO11FD005.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB051.namprd03.prod.outlook.com Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 08 Aug 2013 22:02:58 -0000 Apologies for the late response, I have not been tracking the crypto discus= sions on aes-cts-hmac-sha2, so I did not realize a response was needed. Since the issue which requires the padding is caused by applications that d= o not use the SSPI APIs correctly, this should not be driver for the new cr= ypto. Windows SSPI functions exist for an application to obtain the require= d lengths for use with the in-place encryption functions. Performance and s= ecurity should be the drivers for selection of the new AES algorithm. We do= get a lot of feedback about perf. Thanks, Michiko Short |=A0Program Manager | Windows Security & Identity -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= kitten-request@ietf.org Sent: Wednesday, July 10, 2013 3:42 PM To: kitten@ietf.org Subject: Kitten Digest, Vol 104, Issue 5 Today's Topics: 1. Re: considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) (Nico Williams) =20 ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Jul 2013 16:30:46 -0500 From: Nico Williams To: Tom Yu Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) Message-ID: Content-Type: text/plain; charset=3DUTF-8 On Tue, Jul 9, 2013 at 6:46 PM, Tom Yu wrote: > I've looked at the diff against the previous version of this document. > Most of the changes look reasonable to me, but the special case=20 > handling of short plaintexts seems too complicated from an=20 > implementation perspective. I'd prefer to go back to the more widely=20 > accepted practice of CBC mode with explicit IV and PKCS#7-ish padding. > > It seems that one of the goals of this effort is to use, as much as=20 > possible, the off-the shelf capabilities of cryptographic modules that=20 > are validated to FIPS 140-2 or other relevant standards. As far as I=20 > know, few (if any) validated cryptographic modules support CTS mode=20 > directly. > > At this point, I think it is useful to try moving away from CTS: the=20 > benefits of CTS do not outweigh the implementation complexity,=20 > particularly when dealing with the short plaintext case. Implementing=20 > CTS mode has already proven to be a challenge even for the existing=20 > AES-CTS enctypes, and I'm reluctant to magnify that difficulty with=20 > the new enctypes in this document. Returning to a scheme based on=20 > conventionally padded CBC would further the goal of using the existing=20 > capabilities of validated cryptographic modules, and poses fewer=20 > implementation risks. I'm not at all worried about implementation risks. We can test every possi= ble plaintext length between the shortest (zero-bytes) and a small multiple= of the block size (in bytes), both with test vectors and random data (maki= ng sure it round-trips). I think the only risk we should be concerned about here is the risk that we= might design-in a cryptographic weakness. I definitely don't want to be e= ven partly to blame for that :) so it's a risk that bothers me. I think we= can analyze the non-confounded CTS we came up with, and we could/should/mu= st ask for review by strong cryptographers before we go forward with it (or= otherwise we must show that the new thing must have the same properties as= the old confounded CTS, which I think we informally did, but we'd have to = redo that analysis). Another risk I care about is the risk that we lose some hardware optimizati= ons as a result of using CTS. Though with the trend towards on-die hardwar= e cipher implementations that problem becomes much less relevant. > Statements from Microsoft imply that the main problems caused by=20 > variable-length ciphertext expansion would be limited to SSPI=20 > applications that do not use the APIs correctly. SSPI functions exist=20 > such that an application can use to obtain the required lengths for=20 > use with the in-place encryption functions. This was a big deal to them once. It might still be. It'd be nice to hear= from someone at Microsoft as to whether this is still an issue. > I realize we've spent a significant amount of effort trying to make=20 > CTS work in the short-plaintext case. I'd like to thank to Nico,=20 > Kelley, and others who participated in trying to make CTS mode work in=20 > this specification. Looking at this document as an implementer, I=20 > think using CTS mode, especially with the short-plaintext special=20 > case, presents too much risk, and I'd like us to consider going back=20 > to a more normal CBC mode. I'll be fine with ditching the no-padding requirement if the implementors w= e've known to care for no-padding modes are ok with it now and no new ones = show up to tell us otherwise. Nico -- From nico103@gmail.com Thu Aug 8 10:40:17 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 872EC11E8142 for ; Thu, 8 Aug 2013 10:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xNKC5wsY6sXf for ; Thu, 8 Aug 2013 10:40:11 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id A912311E81F8 for ; Thu, 8 Aug 2013 10:39:58 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so5817536oag.15 for ; Thu, 08 Aug 2013 10:39:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Y6v8QCaSpqLTskYkiUwMfUHIGfgkqGlV1pTU61DW84Y=; b=WljU9BGOqN9tHH/uILCPUJ2JeBzuAkAsqUuZtxUeNRg71K+uCKGBnTQbsBPPOp4FWV FZEBmkGnAXBWb4ux9ETDGKpa5I+0NXUE/V79KMjPanB/TBWZyAs5VvEwqyLsTXxe+lvd OJM8YLCgbiShmC28M0VwKMOkUBiquEs0exhXrp9aRWGpuInxwgeD/EHk25dTLlIe0XwE 64qjpIhj9Bx0ChCKWR46YxlORSzoyPZIHIB76bOOHjMLi/2M+PwH9Cg/1wg6ahT0BQpS IqrbF3KzGXGoOFiiRdfZTtlxwjDIFCrTQLXBmM20nHF11CgW2rRs7ZBi/5+YZ4u45woy tOcw== X-Received: by 10.182.241.101 with SMTP id wh5mr22268obc.49.1375983598231; Thu, 08 Aug 2013 10:39:58 -0700 (PDT) Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net. [108.207.244.174]) by mx.google.com with ESMTPSA id jz7sm14580929obb.4.2013.08.08.10.39.56 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 08 Aug 2013 10:39:57 -0700 (PDT) Date: Thu, 8 Aug 2013 12:39:53 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20130808173952.GB14281@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 Subject: Re: [kitten] ID-Action: draft-williams-kitten-generic-naming-attributes-00 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, 09 Aug 2013 16:53:11 -0000 It's been pointed out to me that RFC5178 addressed the I18N issues. I can't believe I forgot that. From nico103@gmail.com Thu Aug 8 10:46: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 54B5E1F0C61 for ; Thu, 8 Aug 2013 10:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 X52rdNvlVrP8 for ; Thu, 8 Aug 2013 10:46:48 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4675321F9B6A for ; Thu, 8 Aug 2013 10:46:33 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so1048597oag.40 for ; Thu, 08 Aug 2013 10:46:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=8Bn06tp4MgzOgXZ37hVd5akmyDe5DcAr4Ebf9ZIlsJk=; b=CeC9UVsV29vbEV/NkA8Oedb4XMvdF7CqWyDD+yOC3surSIjUPfDV9AK4KoaeyPJaBO U7adBECteBDyJABC+aGkYEP/NycKA3TF9ZsaCgfXuiGRXib5ftSJdxOJwsanZta39DF8 JQdIe+3kUw8Hx9HAHDDil3Ttbmmae75N+lTetLiRUF+srgrlNQ/s0Z93IAL7LkpyGr+z CFE/7aWof03ZG9Ww+FxiqK5M5AtDb8kgvuzLRlp+27RFBJWO3RLvP3aKXoG+LJr+MY+D X8ooBkaCkIuN/68SuonnEfBpeHpaolrqZV3HPgxzl53my0ZStFYGbEEQSoNO5appVHSa 5VpA== X-Received: by 10.60.63.68 with SMTP id e4mr5242934oes.23.1375983992638; Thu, 08 Aug 2013 10:46:32 -0700 (PDT) Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net. [108.207.244.174]) by mx.google.com with ESMTPSA id j7sm14794303oew.5.2013.08.08.10.46.30 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 08 Aug 2013 10:46:31 -0700 (PDT) Date: Thu, 8 Aug 2013 12:46:27 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20130808174626.GC14281@gmail.com> References: <20130708021106.14072.49434.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-00.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: Fri, 09 Aug 2013 16:53:20 -0000 On Thu, Aug 08, 2013 at 01:18:44PM -0400, Benjamin Kaduk wrote: > On Wed, 7 Aug 2013, Nico Williams wrote: > >On Wed, Aug 7, 2013 at 4:09 PM, Benjamin Kaduk wrote: > > > >>Section 1.2 seems rather informal for a standards-track submission. (The > > > >Suggestions welcomed. > > I'd probably just skip the historical discussion and mailing list > mention and go straight to a declarative statement: > A useful aspect of the Java Bindings of the GSS-API is appropriated > for the abstract API, specifically the notion of creating [...] OK, thanks. > >>whole document's use of "we" is a bit dubious, too, but that's a harder > >>change to make.) Would 1.3 and 1.4 (and in general, all "future work" > >>comments) be better in an appendix? > > > >If it makes it onto the Standards-Track then it really is "we"/"us". > >I don't want to speak in the first person just to create extra work > >for the RFC-Editor. Perhaps you can suggest better wording that > >doesn't have this problem and doesn't feel more artificial still. > > It sounds like my point came across badly -- it wasn't a question of > "we" versus "I", but rather the "we propose", "we are likely to", > etc.. I know that RFC stands for "request for comments" and thus > proposal language should be fitting, but I'm more used to seeing > declarative specification like "a new X is created, which Y". Ah, now I get it. Sure, though as for futures, they help explain the value of the new design (or is that just my perception?), so I don't want to relegate that to an appendix. > >>In section 2.2, please make it more explicit that in order to use the > >>req_flags given to GSS_Set_context_flags(), the input flags to > >>GSS_Init_sec_context() must be all zero. Introducing the new FLAGS type in > > > >Oh, that's probably better, yeah, and GSS_Init_sec_context() should > >even return an error otherwise. > > Well, erroring out would remove the feature (allowed by the present > text) of being able to override the flags from context-creation time > at Init_sec_context time. Either would be fine with me, so long as > the text is clear. I prefer the error out method. > >Hmm, well, I think it's clear enough. And I prefer it this way. If > >it's really obnoxious I could change it, but I'll note that we're > >already rather inconsistent about argument naming throughout the > >GSS-API. > > I don't really care, I was just noting the inconsistency. > It calls to mind the mandatory/required checksum type split I noted > in a different thread. I propose we continute this tradition of inconsistent argument naming ;) From kaduk@mit.edu Fri Aug 9 11:07: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 64C0521F96B6 for ; Fri, 9 Aug 2013 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Xp7MLcMOg-7v for ; Fri, 9 Aug 2013 11:07:08 -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 B26C721F8925 for ; Fri, 9 Aug 2013 11:00:57 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-46-52052e589e0e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.49.02357.85E25025; Fri, 9 Aug 2013 14:00:56 -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 r79I0tDt022037 for ; Fri, 9 Aug 2013 14:00:56 -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 r79I0rOB011801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Aug 2013 14:00:55 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r79I0rkP006688; Fri, 9 Aug 2013 14:00:53 -0400 (EDT) Date: Fri, 9 Aug 2013 14:00:53 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: 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+NgFtrHIsWRmVeSWpSXmKPExsUixG6nrhuhxxpk8PmKqsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXfReeaCizwVB3pvszQwTuXqYuTkkBAwkTh3/wUjhC0mceHe erYuRi4OIYF9jBJbTm9nBkkICRxjlFhysBwicZ1J4vPhjywQiXqJzucHWUFsFgEtictr74A1 sAmoSMx8s5ENxBYREJbYvfUdWFxYwFZi4ZdJ7CA2r4CjRP/3b2BxUQEdidX7p7BAxAUlTs58 AmYzC1hK/Fv7i3UCI98sJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrq5WaW6KWm lG5iBAeTi9IOxp8HlQ4xCnAwKvHwTvjFEiTEmlhWXJl7iFGSg0lJlHe9LmuQEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHe11xAOd6UxMqq1KJ8mJQ0B4uSOO+zp2cDhQTSE0tSs1NTC1KLYLIy HBxKErxRIEMFi1LTUyvSMnNKENJMHJwgw3mAhi8DqeEtLkjMLc5Mh8ifYlSUEuedApIQAElk lObB9cKi/RWjONArwrwTQKp4gIkCrvsV0GAmoMHTD7OADC5JREhJNTDGs2g5zSzcP+PXzlXN 955seiQ/uXjWPH3+s3u6VgkuyUo6UqrdLr82Yu7OvKhjVgFyXovWn+vUOsa1avZP2Znfvha9 vvJBv3yCzbFLc3yCKl1VGlOnZwXOmbx3/aMg6Yu979sldfx31nitvBh375zLn1YpjWlVfwTe KJ0/uHv+bqWQwxtu7969U4mlOCPRUIu5qDgRADM7DB3RAgAA Subject: Re: [kitten] ID-Action: draft-williams-kitten-krb5-pkcross-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, 09 Aug 2013 18:07:15 -0000 [again no in-reply-to, sorry] I've looked over this document, though I did not do a full-depth review of it. The scheme is intellectually appealing, or at least amusing, and on paper it seems to help with the issues related to cross-realm trusts. I just can't shake the feeling that it won't be adopted in the real world, though, and I'm not sure why. This makes me reluctant to spend much time trying to move it forward without some indication that it would gain traction. Another reason for reluctance is that the propsal wants one of the relatively-scarce KDCOptions flag bits. It looks like USE-SESSION-KEY-AS-REALM-KEY will only do one direction of trust (at a time)? So a bidirectional trust would still require initiation from both sides (as it should). It might be worth mentioning that explicitly, even though it follows directly from the directions of trust having different principal names. In section 2.1, I don't really understand the motivation for (d). Section 3 makes me wonder if there is some discussion to be had about the KDC allowing/disallowing itself of making signatures of users' PKCROSS certificates when there does exist a symmetric key between the realms. That is, allowing new certs to be signed would preserve the privacy property, but requires more work (?) and reduces auditability. In section 4, there might be something to be said about setting TRANSITED-POLICY-CHECKED for a cached/post-LoF trust, after some threshold has passed (wall time without changed cert, or number of successful requests, or something). -Ben From kaduk@MIT.EDU Fri Aug 9 11:16:32 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 2965D11E8149 for ; Fri, 9 Aug 2013 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.454, 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 RUyM+AhfC+CZ for ; Fri, 9 Aug 2013 11:16:26 -0700 (PDT) Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) by ietfa.amsl.com (Postfix) with ESMTP id 50C4D11E8133 for ; Fri, 9 Aug 2013 11:10:57 -0700 (PDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r79I357t006971; Fri, 9 Aug 2013 14:03:05 -0400 (EDT) Date: Fri, 9 Aug 2013 14:03:04 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [kitten] ID-Action: draft-williams-kitten-krb5-pkcross-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, 09 Aug 2013 18:16:32 -0000 Forgot to note: you cite draft-hotz-kx509-06, but it is RFC 6717, now. On Fri, 9 Aug 2013, Benjamin Kaduk wrote: > [again no in-reply-to, sorry] > > I've looked over this document, though I did not do a full-depth review of > it. > > The scheme is intellectually appealing, or at least amusing, and on paper it > seems to help with the issues related to cross-realm trusts. I just can't > shake the feeling that it won't be adopted in the real world, though, and I'm > not sure why. This makes me reluctant to spend much time trying to move it > forward without some indication that it would gain traction. > > Another reason for reluctance is that the propsal wants one of the > relatively-scarce KDCOptions flag bits. > > It looks like USE-SESSION-KEY-AS-REALM-KEY will only do one direction of > trust (at a time)? So a bidirectional trust would still require initiation > from both sides (as it should). It might be worth mentioning that > explicitly, even though it follows directly from the directions of trust > having different principal names. > > In section 2.1, I don't really understand the motivation for (d). > > Section 3 makes me wonder if there is some discussion to be had about the KDC > allowing/disallowing itself of making signatures of users' PKCROSS > certificates when there does exist a symmetric key between the realms. That > is, allowing new certs to be signed would preserve the privacy property, but > requires more work (?) and reduces auditability. > > In section 4, there might be something to be said about setting > TRANSITED-POLICY-CHECKED for a cached/post-LoF trust, after some threshold > has passed (wall time without changed cert, or number of successful requests, > or something). > > -Ben > From nico@cryptonector.com Fri Aug 9 12:44: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 046C121F85D1 for ; Fri, 9 Aug 2013 12:44:26 -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=[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 9Eyt7N8rbRmv for ; Fri, 9 Aug 2013 12:44:21 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0A11E81BD for ; Fri, 9 Aug 2013 12:36:44 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id A3B39B805B for ; Fri, 9 Aug 2013 12:36:44 -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=WIlHwOrfRgI1XDVWuJvq ZxCG9rk=; b=opxZJ868MgMch2evHq/oy3dhILTEbpn4Aw8pmc8ou+G5XtjO1sf3 T2GdzdjmWkyCcxayBqCB4Yh6aazQ2/Xn9r10LXISW2us1BCatRKfYmwpZ85ywKYe mxeAKDP4Ih8W386Dv5Z5gX8sqAc8tguNb2chhmhkPyg+v5TRIYw26o4= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 4B888B8058 for ; Fri, 9 Aug 2013 12:36:44 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so71909wib.8 for ; Fri, 09 Aug 2013 12:36:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J9P9m6blKWT9FKzX9iLPUffVB4Ssv0hk9QeHUgGA4tw=; b=FzPyRT2GBH97uMQZjXnw+O+swCHWf9XjNGUgHCWF0ksZtcBzdZyhxxSuTKKPa3e27j cQuqIanm3hCp5mpAR4906kqZ1lqJ5GASkSIay1Bpk/FCTYp1N9NS8saH8FPzlxiBFE1f GcDAl7IuzsrK3GyQROAOO2CO7aGpMZuStOSp3sr5nitSw2icc+eieh1NFUuPSxK4esJ4 GPb8R5W7kJAGCh5h1kbnV+FQg4ST6r+a/pUDfz9oEQaDxqA6LinbEa8Gj2BL91ABQlgw Lwq3RL4c3S4VrGm+rYtd6YKHnzt6LdQKIJf+ROZnBm3EDGryMtIwjuww4p/uWZA44MNc EV8Q== MIME-Version: 1.0 X-Received: by 10.180.79.161 with SMTP id k1mr1092822wix.36.1376077002463; Fri, 09 Aug 2013 12:36:42 -0700 (PDT) Received: by 10.216.151.69 with HTTP; Fri, 9 Aug 2013 12:36:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Aug 2013 14:36:42 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] ID-Action: draft-williams-kitten-krb5-pkcross-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, 09 Aug 2013 19:44:26 -0000 On Fri, Aug 9, 2013 at 1:00 PM, Benjamin Kaduk wrote: > I've looked over this document, though I did not do a full-depth review of > it. Thanks. > The scheme is intellectually appealing, or at least amusing, and on paper it > seems to help with the issues related to cross-realm trusts. I just can't > shake the feeling that it won't be adopted in the real world, though, and > I'm not sure why. This makes me reluctant to spend much time trying to move > it forward without some indication that it would gain traction. Running code is the key. I don't see why this wouldn't be adopted except for lack of running code. I don't know when I'll be able to implement. However, I would say that the manual cross-realm principal keying problem is a brutal problem, and you should ask people who are still migrating from 1DES about it. Clearly solving this would be very nice. > Another reason for reluctance is that the propsal wants one of the > relatively-scarce KDCOptions flag bits. I can use something else. But remember, these are BIT STRING (SIZE 32..MAX). In theory we can add bits. And it'd better be so. (IIRC MIT's current ASN.1 decoder will accept longer bit strings but will ignore any bits beyond the first 32, which is... exactly as it should be. I'd have to check but I believe Heimdal does the same. I wouldn't know about other implementations, and, technically, shouldn't have to.) > It looks like USE-SESSION-KEY-AS-REALM-KEY will only do one direction of > trust (at a time)? So a bidirectional trust would still require initiation > from both sides (as it should). It might be worth mentioning that > explicitly, even though it follows directly from the directions of trust > having different principal names. Correct, and it does follow. I could add a section describing cross-realm trust setup procedures. > In section 2.1, I don't really understand the motivation for (d). The key is that if you have a very large PKI but don't want symmetric trust keys exchanged for all possible realms, then you might want to set a max as a DoS counter-measure, along with the others. But you're right, a throttle should suffice, so I'll just remove (d). > Section 3 makes me wonder if there is some discussion to be had about the > KDC allowing/disallowing itself of making signatures of users' PKCROSS > certificates when there does exist a symmetric key between the realms. That > is, allowing new certs to be signed would preserve the privacy property, but > requires more work (?) and reduces auditability. Good point. A realm might want such a policy and the protocol should allow its KDCs to tell clients to use symmetrically keyed x-realm. There's still the privacy protection rationale to allow this, but that's just gravy. > In section 4, there might be something to be said about setting > TRANSITED-POLICY-CHECKED for a cached/post-LoF trust, after some threshold > has passed (wall time without changed cert, or number of successful > requests, or something). Yes, once a TOFU/LoF key has been accepted and marked as valid then the KDC can validate the transit path and it can set that flag. Non-TGS services won't get the key material to validate, but they have to trust their realms' KDCs anyways w.r.t. all cross-realm keying anyways. Nico -- From hartmans@mit.edu Mon Aug 12 07:26:24 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 499CC21F9D04 for ; Mon, 12 Aug 2013 07:26:24 -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 pU7r74fwXz8p for ; Mon, 12 Aug 2013 07:26:19 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8663D21F9CC5 for ; Mon, 12 Aug 2013 07:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D8CD620238; Mon, 12 Aug 2013 10:17:53 -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 uPiFZzZl5l7V; Mon, 12 Aug 2013 10:17:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.104]) (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, 12 Aug 2013 10:17:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7E7BF87E38; Mon, 12 Aug 2013 10:18:58 -0400 (EDT) From: Sam Hartman To: Benjamin Kaduk References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 10:18:58 -0400 In-Reply-To: (Benjamin Kaduk's message of "Wed, 7 Aug 2013 17:21:17 -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, Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 12 Aug 2013 14:26:24 -0000 Hi. I have this Wednesday scheduled for IETF tasks including this writeup. From stpeter@stpeter.im Mon Aug 12 09:59:27 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 3F8F121F9EEC for ; Mon, 12 Aug 2013 09:59:27 -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 F7WbxBTDr0YD for ; Mon, 12 Aug 2013 09:59:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EA6E021F855F for ; Mon, 12 Aug 2013 09:38:53 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9579FE8343; Mon, 12 Aug 2013 10:41:41 -0600 (MDT) Message-ID: <52090F96.30700@stpeter.im> Date: Mon, 12 Aug 2013 10:38:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "kitten@ietf.org" References: <51FEEC99.1020901@stpeter.im> In-Reply-To: <51FEEC99.1020901@stpeter.im> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <51FEEC99.1020901@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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, 12 Aug 2013 16:59:27 -0000 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 > -- Peter Saint-Andre https://stpeter.im/ From hotz@jpl.nasa.gov Tue Aug 13 11:05:40 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 A485411E8118 for ; Tue, 13 Aug 2013 11:05:40 -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 9bdBU-eiloPb for ; Tue, 13 Aug 2013 11:05:34 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id B36E221F91B7 for ; Tue, 13 Aug 2013 11:05:34 -0700 (PDT) Received: from [192.168.3.117] (24-205-93-255.dhcp.psdn.ca.charter.com [24.205.93.255]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7DI5VpD006465 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 13 Aug 2013 11:05:32 -0700 From: "Henry B. Hotz" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Aug 2013 11:05:24 -0700 Message-Id: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> To: " kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-JPL-Spam-Score': 80% Subject: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 18:05:40 -0000 First, this draft comes close to just describing how to use existing = protocols rather than describing an actual protocol itself. I would = argue that is a feature, but I can imagine some reviewers might argue = that the IETF shouldn't publish mere policy documents. Second, I would welcome comments from the authors of the earlier PKCROSS = draft. Perhaps it's only historical curiosity. Third, details: Step 2 of the protocol is redundant with step 3, since only the public = key is sent to the KCA in the current kx509. When I get to doing = kx509bis, *it* will specify when/how to do the CSR, so step 2 will still = be redundant. (And yes, I intend to put the id-pkinit-san in the CSR to = support proper cryptographic binding.) Section 2.1: As an administrator, I would prefer to just configure the = cert directly, rather than a fingerprint, for any specifically trusted = relationships. As a NASA contractor I would want to limit any trusted = CAs to exclude those run by hostile foreign governments, even if they do = pass other auditing requirements. I don't believe the = TRANSIT-POLICY-CHECKED flag should ever be set unless a human has OK'ed = the trust, but maybe that's too restrictive for the draft. Section 3: This section seems a bit terse to me and might benefit from = some expansion. I mentally reversed home/destination when I first read = it. As a specific point, the recommended (normal) practice is to put = the original principal name in the kx509-issued cert, but I see that = doesn't break the property you were actually advertising. Maybe this is = just me. =20 I will say that it's a useful property if a user doesn't want the Calif = DMV to know he/she's shopping at porn-stars-r-us, but does want to use a = valid Calif ID for purchases. Section 4: This section raises issues that need discussion in the = Security Considerations. It sounds like you are changing the default = value of an authentication from something reliable to something = anonymous in trustability. I'm tempted to require something like ssh's = "never seen this guy before, are you sure" prompt, but I think that's = simplistic, and probably out-of-scope as well. Cross-realm authentication is already inherently less secure/trustable = than same-realm authentication. It's just rare enough that we don't pay = attention, and it hasn't affected our expectations. While I'm all for = making cross-realm relationships easier to set up and use, I'm afraid of = violating the principle of least surprise. I think you're on the right track with the transited-policy discussions = (modulo comment re 2.1). Do existing application services actually pay = attention to that flag? If not, then PKCROSS might be dangerous to = deploy in practice. Remember that a lot of applications thoughtlessly = strip the realm name and pretend they have a UID. We need to break that = behavior, and I doubt we can. We need to have a way to phase this into the wild that doesn't generate = horrific anecdotes. I'm nattering on because I'm not sure of the = solution. Section 6: Like the idea. Obviously needs expanding. SHOULD only be = used if all the appropriate DNS PKI stuff is deployed to support it at = the required trust level. ------------------------------------------------------ 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 hotz@jpl.nasa.gov Tue Aug 13 12:08:38 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 EB27321E8178 for ; Tue, 13 Aug 2013 12:08:37 -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 q-or08L90zuw for ; Tue, 13 Aug 2013 12:08:19 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53B21E8136 for ; Tue, 13 Aug 2013 12:08:19 -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 r7DJ8F6I006474 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 13 Aug 2013 12:08:16 -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: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> Date: Tue, 13 Aug 2013 12:08:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5264ABC8-EDE0-411E-8EED-E625F5DF1D45@jpl.nasa.gov> References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> To: " kitten@ietf.org" X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 19:08:38 -0000 On Aug 13, 2013, at 11:05 AM, "Henry B. Hotz" wrote: > SHOULD only be used if all the appropriate DNS PKI stuff PK, not PKI. ------------------------------------------------------ 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 Tue Aug 13 12:12: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 F36E021E8178 for ; Tue, 13 Aug 2013 12:12:53 -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=[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 1-ThcBrPDica for ; Tue, 13 Aug 2013 12:12:49 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id F274E21E8196 for ; Tue, 13 Aug 2013 12:12:48 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 5F9CB59807D for ; Tue, 13 Aug 2013 12:12:45 -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:content-transfer-encoding; s= cryptonector.com; bh=DY35WvS6RbBAx2Y1a3DW/0U1YIk=; b=AE8sDt9GHYU b6+pbDefrBJaLfRjSSk3FGhIl0m/Y0H6NG8DyjpvtWocOGg6CNmWQ4DFXxHamVF0 d3WW0ms33+0p9dJRjxsYEIQXL/GUgvuoLNeBMnV038xa6zjStBX3YgGwt5Y9Ghfd 6Yyqn17GimDbLAezihq7nsRo6brt2e88= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id CF27B598081 for ; Tue, 13 Aug 2013 12:12:44 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so7082617wes.9 for ; Tue, 13 Aug 2013 12:12:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MeLi726Dauu93q6vCA5RPjvRBk3qUBzRvmDCFbMMy1Q=; b=k6JmQq+64NfaUmFBW9m5XQfZ6XUG0AlF1fDGhjecwAlicbEM6LJZm4oV3G1z/1nhpd /cxfMm8hW/KFDBXsIsa1ol23t/R6sd5b0CfNuMTTQbdexesrDqemKPFQMTI215dIeB12 j2QrS6OS7ZZfSLZcvE4EN/tA9GunG4LGmCDJ0yPy1FmEoggwphE5lVnaKbK8qAQ3RBlc sLzgTJ2F5EzgD1gZ2NzuqWwXO4fpzSJAFyS2mR99SPG4SYBb7y3itneIwkPiKfVkvcs/ oG/903YPggCbslaaq7Fwi6eeCFzknJqHWcerfEBnsTHCN+BkVxl3oEPTvAu5TOpFHQsw NTBQ== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr4092748wjc.9.1376421162472; Tue, 13 Aug 2013 12:12:42 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 13 Aug 2013 12:12:42 -0700 (PDT) In-Reply-To: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> Date: Tue, 13 Aug 2013 14:12:42 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: " kitten@ietf.org" Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 19:12:54 -0000 On Tue, Aug 13, 2013 at 1:05 PM, Henry B. Hotz wrote: Thanks for your review comments! > First, this draft comes close to just describing how to use existing prot= ocols rather than describing an actual protocol itself. I would argue that= is a feature, but I can imagine some reviewers might argue that the IETF s= houldn't publish mere policy documents. I don't see why that should be a problem here.. I do think this is really specifying how combinations of a) existing protocols, b) new policies, c) some additional sub-protocols (to create symmetric key pairings, for example, or something like ABFAB's trust router). That's not only OK, it's great: we're *reusing* specifications, which is exactly as it should be (except, of course if they were broken/obsolete, which they are not). > Second, I would welcome comments from the authors of the earlier PKCROSS = draft. Perhaps it's only historical curiosity. Indeed. > Third, details: > > Step 2 of the protocol is redundant with step 3, since only the public ke= y is sent to the KCA in the current kx509. When I get to doing kx509bis, *= it* will specify when/how to do the CSR, so step 2 will still be redundant.= (And yes, I intend to put the id-pkinit-san in the CSR to support proper = cryptographic binding.) Sure, step 2 and 3 are really sub-steps of the same step. > Section 2.1: As an administrator, I would prefer to just configure the c= ert directly, rather than a fingerprint, for any specifically trusted relat= ionships. As a NASA contractor I would want to limit any trusted CAs to ex= clude those run by hostile foreign governments, even if they do pass other = auditing requirements. I don't believe the TRANSIT-POLICY-CHECKED flag sho= uld ever be set unless a human has OK'ed the trust, but maybe that's too re= strictive for the draft. Agreed. Though I don't want to specify *how* admins are to verify CA certs, whether using fingerprints, whether using a real PKI -- this is all local policy. > Section 3: This section seems a bit terse to me and might benefit from s= ome expansion. I mentally reversed home/destination when I first read it. = As a specific point, the recommended (normal) practice is to put the origi= nal principal name in the kx509-issued cert, but I see that doesn't break t= he property you were actually advertising. Maybe this is just me. Right, it doesn't break that. The privacy feature here is relative to the user's home realm, which doesn't get to find what realms the user is transiting to/through. A minor feature, in the grand scheme of things, but it's OK. Privacy relative to eavesdroppers can be had using FAST. Privacy relative to the destination realms can be had by using anonymous authentication with user certs providing pseudonymity (again, this involves local policy at the client/user-agent side and the realms traversed). > I will say that it's a useful property if a user doesn't want the Calif D= MV to know he/she's shopping at porn-stars-r-us, but does want to use a val= id Calif ID for purchases. Right. Also, I think it's a feature ABFAB has, and they have strong justifications for such features that would apply here too. > Section 4: This section raises issues that need discussion in the Securi= ty Considerations. It sounds like you are changing the default value of an= authentication from something reliable to something anonymous in trustabil= ity. I'm tempted to require something like ssh's "never seen this guy befo= re, are you sure" prompt, but I think that's simplistic, and probably out-o= f-scope as well. Yes. I just hadn't gotten to fleshing out the security considerations section. The whole I-D will discuss security considerations throughout too (and does). As for prompting, well, we have a lot of experience in the SSH world with that. We should recommend prompting, but there may be other ways to indicate trust/lack of trust and push decisions higher up the stack. For example, one might make the display form of the name such as to indicate the lack of trust path, or one might express it using naming attributes, and so on. But in order to trust for subsequent uses the user must be involved, just not necessarily with a prompt (again, maybe we ask users to recognize public key fingerprints, because maybe the user/app OK with pseudonyms and wants only continuity, not any real information about the peer). > Cross-realm authentication is already inherently less secure/trustable th= an same-realm authentication. It's just rare enough that we don't pay atte= ntion, and it hasn't affected our expectations. While I'm all for making c= ross-realm relationships easier to set up and use, I'm afraid of violating = the principle of least surprise. The principle of least surprise is not to be violated, and nothing in the proposal requires it to be violated. Existing implementations may need new APIs, and in order to operate correctly with old apps they may make principal name representations "safe" (see above) as a fail-safe such that no existing apps should accidentally get untrusted transit paths. > I think you're on the right track with the transited-policy discussions (= modulo comment re 2.1). Do existing application services actually pay atte= ntion to that flag? If not, then PKCROSS might be dangerous to deploy in p= ractice. Remember that a lot of applications thoughtlessly strip the realm= name and pretend they have a UID. We need to break that behavior, and I d= oubt we can. See above. > We need to have a way to phase this into the wild that doesn't generate h= orrific anecdotes. I'm nattering on because I'm not sure of the solution. See above. > Section 6: Like the idea. Obviously needs expanding. SHOULD only be us= ed if all the appropriate DNS PKI stuff is deployed to support it at the re= quired trust level. Well, section 6 is empty right now; did you mean section 5, the DANE stuff? Yes, it's a nice idea, but it's really just one of many ways to establish a trust transit path, and it's perfectly legitimate, and it has its own security considerations, namely: that you're trusting the DNSSEC PKI, and all the security considerations associated with that. DANE is way better than the TLS server PKI, so there's that. At the end of the day all of these all about convenience/security/cost trade-offs involved in all the different trust bootstrap choices -- we shouldn't REQUIRE any one of these to be *used*, but we should REQUIRE at least one of these to be *implemented*. This is to be discussed. Clearly *manual* validation/pre-sharing of public keys/certs should be REQUIRED to implement (and it's the easiest thing to implement). Given that we are referencing PKIX it's also trivial enough to REQUIRE that the use of locally-configured trust anchors be implemented. Beyond that I a) would NOT want to REQUIRE TOFU/LoF to be implemented, b) I would want to RECOMMEND -possibly require- that DANE be implemented. At some point we'll have an in-depth discussion about this, but I think the preceding is roughly on target. Nico -- From hotz@jpl.nasa.gov Tue Aug 13 13:03: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 A3E7221F9C7D for ; Tue, 13 Aug 2013 13:03:19 -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 eP+RWiSQijwh for ; Tue, 13 Aug 2013 13:03:12 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24C21F9C6F for ; Tue, 13 Aug 2013 13:03:12 -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 r7DK33RW024586 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 13 Aug 2013 13:03:04 -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: Date: Tue, 13 Aug 2013 13:03:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C88AAB5-88CC-4F10-99F0-C55DDE27EC09@jpl.nasa.gov> References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> To: Nico Williams X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: " kitten@ietf.org" Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 20:03:20 -0000 On Aug 13, 2013, at 12:12 PM, Nico Williams = wrote: > On Tue, Aug 13, 2013 at 1:05 PM, Henry B. Hotz = wrote: [snipping stuff we agree on] >> Section 2.1: As an administrator, I would prefer to just configure = the cert directly, rather than a fingerprint, for any specifically = trusted relationships. As a NASA contractor I would want to limit any = trusted CAs to exclude those run by hostile foreign governments, even if = they do pass other auditing requirements. I don't believe the = TRANSIT-POLICY-CHECKED flag should ever be set unless a human has OK'ed = the trust, but maybe that's too restrictive for the draft. >=20 > Agreed. Though I don't want to specify *how* admins are to verify CA > certs, whether using fingerprints, whether using a real PKI -- this is > all local policy. I'm just saying what I (as an admin) want to tell the KDC. Alternatives = are OK, and an admin will do whatever they think reasonable to get the = cert in the first place. >> Section 3: This section seems a bit terse to me and might benefit = from some expansion. I mentally reversed home/destination when I first = read it. As a specific point, the recommended (normal) practice is to = put the original principal name in the kx509-issued cert, but I see that = doesn't break the property you were actually advertising. Maybe this is = just me. >=20 > Right, it doesn't break that. The privacy feature here is relative to > the user's home realm, which doesn't get to find what realms the user > is transiting to/through. >=20 > A minor feature, in the grand scheme of things, but it's OK. >=20 > Privacy relative to eavesdroppers can be had using FAST. >=20 > Privacy relative to the destination realms can be had by using > anonymous authentication with user certs providing pseudonymity > (again, this involves local policy at the client/user-agent side and > the realms traversed). >=20 >> I will say that it's a useful property if a user doesn't want the = Calif DMV to know he/she's shopping at porn-stars-r-us, but does want to = use a valid Calif ID for purchases. >=20 > Right. Also, I think it's a feature ABFAB has, and they have strong > justifications for such features that would apply here too. Do they have something that could be referenced? >> Section 4: This section raises issues that need discussion in the = Security Considerations. It sounds like you are changing the default = value of an authentication from something reliable to something = anonymous in trustability. I'm tempted to require something like ssh's = "never seen this guy before, are you sure" prompt, but I think that's = simplistic, and probably out-of-scope as well. >=20 > Yes. I just hadn't gotten to fleshing out the security considerations > section. The whole I-D will discuss security considerations > throughout too (and does). >=20 > As for prompting, well, we have a lot of experience in the SSH world > with that. We should recommend prompting, but there may be other ways > to indicate trust/lack of trust and push decisions higher up the > stack. For example, one might make the display form of the name such > as to indicate the lack of trust path, or one might express it using > naming attributes, and so on. But in order to trust for subsequent > uses the user must be involved, just not necessarily with a prompt > (again, maybe we ask users to recognize public key fingerprints, > because maybe the user/app OK with pseudonyms and wants only > continuity, not any real information about the peer). >=20 >> Cross-realm authentication is already inherently less = secure/trustable than same-realm authentication. It's just rare enough = that we don't pay attention, and it hasn't affected our expectations. = While I'm all for making cross-realm relationships easier to set up and = use, I'm afraid of violating the principle of least surprise. >=20 > The principle of least surprise is not to be violated, and nothing in > the proposal requires it to be violated. =20 I'll agree it doesn't seem to require it to be violated. I think we = also agree that more stuff is needed to do it right. > Existing implementations may > need new APIs, and in order to operate correctly with old apps they > may make principal name representations "safe" (see above) as a > fail-safe such that no existing apps should accidentally get untrusted > transit paths. >=20 >> I think you're on the right track with the transited-policy = discussions (modulo comment re 2.1). Do existing application services = actually pay attention to that flag? If not, then PKCROSS might be = dangerous to deploy in practice. Remember that a lot of applications = thoughtlessly strip the realm name and pretend they have a UID. We need = to break that behavior, and I doubt we can. >=20 > See above. >=20 >> We need to have a way to phase this into the wild that doesn't = generate horrific anecdotes. I'm nattering on because I'm not sure of = the solution. >=20 > See above. I'm concerned that we get something that doesn't violate the principle = of least surprise when deployed with existing code bases that ignore = transited-policy. Are you proposing that your PKCROSS by default "breaks" unless the = cross-realm trust passes the transited-policy requirement? >> Section 6: Like the idea. Obviously needs expanding. SHOULD only = be used if all the appropriate DNS PKI stuff is deployed to support it = at the required trust level. >=20 > Well, section 6 is empty right now; did you mean section 5, the DANE > stuff? =20 Errr. Yeah. > Yes, it's a nice idea, but it's really just one of many ways > to establish a trust transit path, and it's perfectly legitimate, and > it has its own security considerations, namely: that you're trusting > the DNSSEC PKI, and all the security considerations associated with > that. DANE is way better than the TLS server PKI, so there's that. >=20 > At the end of the day all of these all about convenience/security/cost > trade-offs involved in all the different trust bootstrap choices -- we > shouldn't REQUIRE any one of these to be *used*, but we should REQUIRE > at least one of these to be *implemented*. This is to be discussed. >=20 > Clearly *manual* validation/pre-sharing of public keys/certs should be > REQUIRED to implement (and it's the easiest thing to implement). > Given that we are referencing PKIX it's also trivial enough to REQUIRE > that the use of locally-configured trust anchors be implemented. Yes! (The trust model for a web browser verifying it's really = www.amazon-wannabe.com are very different from PKINIT.) > Beyond that I a) would NOT want to REQUIRE TOFU/LoF to be implemented, > b) I would want to RECOMMEND -possibly require- that DANE be > implemented. At some point we'll have an in-depth discussion about > this, but I think the preceding is roughly on target. Agree. > Nico > -- ------------------------------------------------------ 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 Tue Aug 13 13:22:32 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 3F61211E81BF for ; Tue, 13 Aug 2013 13:22:32 -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=[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 bnt8F5FzbciV for ; Tue, 13 Aug 2013 13:22:25 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DCFB511E81C0 for ; Tue, 13 Aug 2013 13:22:24 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 84D3B428075 for ; Tue, 13 Aug 2013 13:22:15 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id BEC24428194 for ; Tue, 13 Aug 2013 12:13:53 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so7065604wgh.9 for ; Tue, 13 Aug 2013 12:13:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w2T3BIc74N3Wcdr3xgnQw2xcQpjy1QlmlkNDeygcUYI=; b=cULYhaIcORQKyFNb1wUoIgpLhn+tf7OJrcIRMKcetvtDL4x7JHMESmoBKdm7AXpu0+ JNi930cG/izBF65PohTQ1gbhtYPRGNVHCAaj7HpGyGTJSMiUCSfkxhsF3iIo2+qQET+W Kqeto2KQYsfrsvVCEM6A1eG1icvjhPW9ZQSxZUf46S44riS5SW1ijj97HS5NcO8LhD6a qUl+gH7gEQBAmlqgDkZQz8K1qDzS4EdIONT1LZUtnKImKfQdEVf16ls8xGX508+Rsmuc 43OkGJZRkX/OTuyAnVLCu56K5NZbdNiAaUMNv1+NwMydn5+bqLsKBPO1OBSg1kB/T48z yEQA== MIME-Version: 1.0 X-Received: by 10.180.79.161 with SMTP id k1mr595653wix.36.1376421223662; Tue, 13 Aug 2013 12:13:43 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 13 Aug 2013 12:13:43 -0700 (PDT) In-Reply-To: <5264ABC8-EDE0-411E-8EED-E625F5DF1D45@jpl.nasa.gov> References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> <5264ABC8-EDE0-411E-8EED-E625F5DF1D45@jpl.nasa.gov> Date: Tue, 13 Aug 2013 14:13:43 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: " kitten@ietf.org" Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 20:22:32 -0000 On Tue, Aug 13, 2013 at 2:08 PM, Henry B. Hotz wrote: > On Aug 13, 2013, at 11:05 AM, "Henry B. Hotz" wrote: > >> SHOULD only be used if all the appropriate DNS PKI stuff > > PK, not PKI. DNSSEC *is* a PKI -- not a PKIX one, but a PKI nonetheless :) From nico@cryptonector.com Tue Aug 13 13:27: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 2BCFE11E81C4 for ; Tue, 13 Aug 2013 13:27:54 -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=[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 qpoiKaxCXYLB for ; Tue, 13 Aug 2013 13:27:41 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD8711E81C0 for ; Tue, 13 Aug 2013 13:27:41 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 237631B406F for ; Tue, 13 Aug 2013 13:27:41 -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=laEAe1+T/jqrFuEDZmYI gZwVh/A=; b=L82aI+EZ6PaCq3iJqhANzBfNs/4KDykUBUec+H71xg75eI2aBDCr tXXAxq5WJQvV/JereyDi3Hqn+C83AYLIuFoFeE2FP6qr1KeOs5q64b675/EEz3j1 0U1kS8lTguwYNrRzNNp7JVHXW7xgnjXncO0Yx34yY25XELr2WFtCKLQ= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id C02D61B4061 for ; Tue, 13 Aug 2013 13:27:40 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z12so6979906wgg.10 for ; Tue, 13 Aug 2013 13:27:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p6ESBQefHiMe73TPtkakWmqUyQAQKHZx8HSmw9wlO4I=; b=ZGF5qkjCy/kPYS7pYcHqTg2w/DYyk08ZuokLJid048pjHx3gEz+w3WKP21Ih5L9jy3 FoDQr+YCxE+FAutx/dmXqumPmToJ3wOXm1Mn8gbqlR4FYmZioU+mTRz1pNzXPIooOpo0 mG3UCihNKPUW/kVmwTtTUHeU76WczOSc9p1+0+UbTRG7BJVFxIn94aYNfOi95lKofYD4 7XUDcm0yfbzLanOK/UHaA/4AlsbBf2sOZ2CD/LxArbm5rKuo9IMycqZ5zWTmSyxMaMZx 9qBrb2H86aOMty4szaxl8DSMwATVRD3BMJb4v+8WTlUKQ5RlYUhQw5G8cM/GilNMl9e2 VKaA== MIME-Version: 1.0 X-Received: by 10.180.187.175 with SMTP id ft15mr3893649wic.20.1376425659238; Tue, 13 Aug 2013 13:27:39 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 13 Aug 2013 13:27:39 -0700 (PDT) In-Reply-To: <9C88AAB5-88CC-4F10-99F0-C55DDE27EC09@jpl.nasa.gov> References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> <9C88AAB5-88CC-4F10-99F0-C55DDE27EC09@jpl.nasa.gov> Date: Tue, 13 Aug 2013 15:27:39 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: " kitten@ietf.org" Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 20:27:55 -0000 On Tue, Aug 13, 2013 at 3:03 PM, Henry B. Hotz wrote: > On Aug 13, 2013, at 12:12 PM, Nico Williams wrote: >> On Tue, Aug 13, 2013 at 1:05 PM, Henry B. Hotz wrote: >>> I will say that it's a useful property if a user doesn't want the Calif DMV to know he/she's shopping at porn-stars-r-us, but does want to use a valid Calif ID for purchases. >> >> Right. Also, I think it's a feature ABFAB has, and they have strong >> justifications for such features that would apply here too. > > Do they have something that could be referenced? I'd have to check; it'd be easier to ask Sam, which I'll do in a bit. >> The principle of least surprise is not to be violated, and nothing in >> the proposal requires it to be violated. > > I'll agree it doesn't seem to require it to be violated. I think we also agree that more stuff is needed to do it right. Well, we do need to say a bit about how to express things in a) the GSS-API, b) non-standard APIs (abstractly). I'll add text for this, including GSS naming attributes and so on. > I'm concerned that we get something that doesn't violate the principle of least surprise when deployed with existing code bases that ignore transited-policy. The protocol itself does no such thing and requires no such thing. Implementations could get it wrong and end up causing harm, so we'll have some implementor guidance, but as with all implementation bugs... Anyways, I'll also add text specifically addressing the view of TOFU/LoF from GSS. Ignoring TOFU/LoF for the moment, there's really only one way to end up violating the principle of least surprise: if, say, the trust anchors for the TLS server PKI were accidentally and unintentionally used for PKCROSS. If there's a trust path it's because admins put it there, intentionally or otherwise. That's how it has to be. For TOFU/LoF the key is to end up with strongly pseudonymous names (e.g., use public key fingerprints as the actual principal names). > Are you proposing that your PKCROSS by default "breaks" unless the cross-realm trust passes the transited-policy requirement? Absolutely, with the caveat that transit policy is intended to be applied (and applicable) by all Kerberos services, including TGSes and non-TGSes. Where implementations fail to check transit paths... any increase in the x-realm cloud size tends to increase those implementations' vulnerability, and there's not much that can be done about that. That's another thing: we need better policy for evaluating the value of a transit path. I've some ideas for that, but I think they belong in a different document as they are independent of *how* the transit paths' x-realm principals get keyed, as well as because such policy has always been left as a local policy matter. Nico -- From nico@cryptonector.com Tue Aug 13 16:38:22 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 1300721E804B for ; Tue, 13 Aug 2013 16:38:22 -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=[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 EjsgYZdvZjPF for ; Tue, 13 Aug 2013 16:38:17 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id BA98F11E80D1 for ; Tue, 13 Aug 2013 16:38:17 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 589D21E05C for ; Tue, 13 Aug 2013 16:38:14 -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=G33j4siGYz1x2B0BeUoR GnVcLE0=; b=J8HxDBwWK3eQ9IyU0rNxHxJpsF80fDikvqvWAe95aRPtdnrQXWoM sn/gGqa3sbSlceIPTzgxaexQRqToXaiDeqcTLoRrJVBnXiB7KHob3bBr6eYpoiZk YDUO8Zpu4LW2XSVg/go/XrSiVTqHp25YqBw8x4dsGOz22zpsIjCw9cw= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id F169C1E057 for ; Tue, 13 Aug 2013 16:38:13 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so1051707wiw.0 for ; Tue, 13 Aug 2013 16:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vx/KnvAGCQPe+pUvjTf9TMxpGF/PHf+Na1vxq8ieDgw=; b=N++4bOIJ6ufQv4ak+MUGlTwMhuQAoX20EQVbBYvJ9FHaiGaDHPACYmyo9sfy71z62A iqKIDAZC9UDmW3Xupe6+Qzt44SL12y4IjZeThWLEpWV4AAHvT5mBwNlqTcYlddSB7LlE rYRCRWpKY9T3fe0RRtCvJvMPUfaLgIcbiNxM/4W9FG5EVlTvrlHkG6zQ+Qk2H+zSRgbx 487iWsMV1X1lCWU9BFypZHsXuUDbL0yeW4yG+QZlFPgiKKB2o3KawJxuX6G+mvmU5fq8 3WN1ydY+SG9d8aabpcW7Z/HPzj5deauARwsw4JAjft11aK+DnQvIHYd78+WvsYYhKsuv abUQ== MIME-Version: 1.0 X-Received: by 10.180.79.161 with SMTP id k1mr230254wix.36.1376437092172; Tue, 13 Aug 2013 16:38:12 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 13 Aug 2013 16:38:12 -0700 (PDT) In-Reply-To: References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> <9C88AAB5-88CC-4F10-99F0-C55DDE27EC09@jpl.nasa.gov> Date: Tue, 13 Aug 2013 18:38:12 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: " kitten@ietf.org" Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 23:38:22 -0000 I've submitted a new I-D, FYI. http://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross-02 From nico@cryptonector.com Tue Aug 13 16:39:12 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 4971F21F86DD for ; Tue, 13 Aug 2013 16:39:10 -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 O2eov+kGMnmB for ; Tue, 13 Aug 2013 16:39:05 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83611E80D1 for ; Tue, 13 Aug 2013 16:39:05 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 14C52B8058 for ; Tue, 13 Aug 2013 16:39:04 -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=gXxebvORqkRR4IWeCwjB Kfi8Qyo=; b=s/Ucd3/IFHzbLFbvfot3m8AWmb59d/jjvI/5ysCLCqDxK4iSkGgi rJ4ji0u/KW0Np6a7Y+k2bpriI6TuFDbrWULh/kgpJ/EpVfYrsQOQAgX9qWEa4rGw p6mknLFE+6QhkfZIhq1mmGSZ/u1htuNnIP6HhePbtrkHP9X7rjmFvAc= 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-a26.g.dreamhost.com (Postfix) with ESMTPSA id BAA70B8057 for ; Tue, 13 Aug 2013 16:39:03 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so7156455wes.2 for ; Tue, 13 Aug 2013 16:39:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HqripHDfY7QVPR5/Jo2IZCxndtJdUGyxOpRBCwQE4og=; b=FChDaxwENDK9GcJImfqNce66YHcV76dcrtxE+wgPCU8cxD0HqskOk8ceB87aeUfXgu 0ZQhvkZR7SdeOdwzEHw+6DHim+/nXU5N/i4CGIJvTvB2486ctGOzvKPWLWVwcdH4hBQ6 5Drpruw6iTDGajK5rTcLyPkf7NwwFcfAHIsADt+SRqVOLmjBkxur2AP7/nqd+J/EDgW9 7UpCA8gaalpbnNFF9kvIpdNgcHOM/G+qZYqhEjDRU31QU1Ggea66Vtz+MrgRcZO7SxxL ciDEAkpGEybVEbBM3+jZe/Xrf48GolrgDQnzQFybGwR8enhCSqyCaLk4Niz8KuhUrECe 3Srw== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr4198041wic.33.1376437142314; Tue, 13 Aug 2013 16:39:02 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Tue, 13 Aug 2013 16:39:02 -0700 (PDT) In-Reply-To: References: <59A8B84C-8346-4243-8A2E-D7CD36B5511E@jpl.nasa.gov> <9C88AAB5-88CC-4F10-99F0-C55DDE27EC09@jpl.nasa.gov> Date: Tue, 13 Aug 2013 18:39:02 -0500 Message-ID: From: Nico Williams To: "Henry B. Hotz" Content-Type: text/plain; charset=UTF-8 Cc: " kitten@ietf.org" Subject: Re: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments 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, 13 Aug 2013 23:39:13 -0000 I forgot to add this, per-Ben's comments: +2.2. Indication of Preference for/ Required Use of Symmetrically-Keyed + Cross-Realm Principals + + A KDC MAY reject a PKINIT/PKCROSS request with a KRB-ERROR indicating + that the use of a symmetrically-keyed cross-realm relation is + required. This is done using the following error code: . The + following e-data TD type is used to hold a SEQUENCE OF Realm: . + + A KDC MAY accept a PKINIT/PKCROSS request but indicate to the client + that a symmetrically-keyed cross-realm relation is preferred. The + KDC does this by including a PA-DATA containing a SEQUENCE OF Realm, + with the following pa-type: . + + [[anchor1: Add an ASN.1 module, even though it will contain only one + untagged type consisting of a SEQUENCE OF Realm, and the IANA- + assigned values for error code, e-data TD type, and pa-type, plus the + import of the RFC4120 module (to get the Realm type).]] + This will be in the next version. From hartmans@mit.edu Wed Aug 14 09:21:52 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 64D0C21E80B6 for ; Wed, 14 Aug 2013 09:21:51 -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 SfmK1jt7hd25 for ; Wed, 14 Aug 2013 09:21:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29521E808C for ; Wed, 14 Aug 2013 09:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4575920287; Wed, 14 Aug 2013 12:20:34 -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 7efjWHFvmQph; Wed, 14 Aug 2013 12:20:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 12:20:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D22BD8051A; Wed, 14 Aug 2013 12:21:42 -0400 (EDT) From: Sam Hartman To: Michiko Short References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 14 Aug 2013 12:21:42 -0400 In-Reply-To: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> (Michiko Short's message of "Thu, 8 Aug 2013 22:02:08 +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" Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 16:21:52 -0000 >>>>> "Michiko" == Michiko Short writes: Michiko> Apologies for the late response, I have not been tracking Michiko> the crypto discussions on aes-cts-hmac-sha2, so I did not Michiko> realize a response was needed. Since the issue which Michiko> requires the padding is caused by applications that do not Michiko> use the SSPI APIs correctly, this should not be driver for Michiko> the new crypto. Windows SSPI functions exist for an Michiko> application to obtain the required lengths for use with the Michiko> in-place encryption functions. Performance and security Michiko> should be the drivers for selection of the new AES Michiko> algorithm. We do get a lot of feedback about perf. So, when were the padding length functions introduced? I seem to recall that MSDN used to say that the padding buffer would never be greater than 8. Am I misremembering? Is that no longer a concern? From hartmans@mit.edu Wed Aug 14 10:16: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 63C7111E811F for ; Wed, 14 Aug 2013 10:16: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 F4kY0WG3vGzF for ; Wed, 14 Aug 2013 10:16:39 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7203211E810B for ; Wed, 14 Aug 2013 10:16:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 37CA120287; Wed, 14 Aug 2013 13:15:27 -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 Xnx7gOy_wOcd; Wed, 14 Aug 2013 13:15:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 13:15:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2246C8051A; Wed, 14 Aug 2013 13:16:35 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Wed, 14 Aug 2013 13:16:35 -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: michikos@microsoft.com Subject: [kitten] History of AES block size issues 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, 14 Aug 2013 17:16:45 -0000 For those copied on this message, the kitten working group is considering a proposal to produce an AES enctype that provides message expansion of up to 16 octets. That's kind of a departure from how we've been approaching this, so I decided to go over the history and implications a bit. The chairs are requiring the proponents of the proposal to try and investigate why we wanted to avoid message expansion in the past and do their best to compile our rationale and an explanation of why the change is desirable. Yes, this all would have been easier if we'd done a better job of documenting the rationale. This is from my memory, and I may be getting things wrong; however I think I know the people who were involved enough that you should be able to reach out to folks and try and figure out what was happening. During the development of what became RFC 3962, I believe that John Brezak and possibly Paul Leach approached Ken Raeburn with a proposal to avoid non-constant message expansion. I don't believe a strong explanation was offered at that point why; it seemed very important to John. It seemed like an improvement, so the WG went along. Originally, Ken raeburn proposed draft-ietf-krb-wg-gss-crypto as a mechanism for GSS-API in Kerberos. Larry Zhu was very unhappy with this approach and proposed an alternative. I can't find that alternative. It was a lot closer to RFC 1964 than RFc 4121. MIT was very unhappy with that alternative because you had to specify GSS crypto algorithms separate from RFC 3961 algorithms. The big compromise that allowed us all to get to RFC 4121 was the RRC. It is my belief that two things went into that. First, a desire that the MAC and other information needed to be at the header of the token not at the end as in RFC 3961. I seem to recall a desire to do something with padding, but am not able to substantiate that now. I'd also like to discuss API implications. Most of the implementations (MIT, Heimdal and Microsoft) have a scatter-gather API for GSS operations. In Microsoft, it's the SSP. In the other implementations it is the iov interface to GSS-API. All the existing implementations will negotiate a subsession key of a modern enctype in their default configuration. That is the default configurations of all the GSS implementations will end up negotiating something that does not pad GSS tokens. So, in the default configuration, an application using the scatter-gather APIs will never test its support for padding buffers. If a non-default configuration is used and one of the DES enctypes is used for GSS-API messages, padding may be used. both the Microsoft and other APIs support padding; a correctly written application can work with padding under all the existing APIs. We believe there are some protocols that use AEAD where the length of a token is protected by AEAD. These protocols need to be able to make sure that padding does not adjust the length. Also, note that while MIT and Heimdal have a scatter-gather API, it is not their default API. The API described in RFC 2744 is more common on these implementations for applications to use. From hartmans@mit.edu Wed Aug 14 10:40:58 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 CB58C11E811F for ; Wed, 14 Aug 2013 10:40:57 -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_34=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 HCFvoEM6K9hK for ; Wed, 14 Aug 2013 10:40:50 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9A49821E808C for ; Wed, 14 Aug 2013 10:40:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9891120287; Wed, 14 Aug 2013 13:39:39 -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 gpP-IcBgoQLQ; Wed, 14 Aug 2013 13:39:38 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 13:39:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 856FE8051A; Wed, 14 Aug 2013 13:40:47 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> Date: Wed, 14 Aug 2013 13:40:47 -0400 In-Reply-To: <51FA6DE2.2050708@mit.edu> (Greg Hudson's message of "Thu, 01 Aug 2013 10:17:06 -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, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 17:40:58 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> On 08/01/2013 08:38 AM, Sam Hartman wrote: >> 1) we have not evaluated CTR mode. We looked at CCM and GCM, but >> have not looked at CTR with an HMAC. Just pointing out that we >> have not thoroughly considered the options. Greg> If I understand how CTR+HMAC would work, the same problems Greg> exist for CTR+HMAC as for CCM: the 128-bit block size of AES Greg> is not big enough for a random nonce and a block counter, Greg> given the requirements for maximum message size and the Greg> requirements for confidence of nonce uniqueness. However, CTR unlike CCM doesn't specify the breakdown. You could for example pick a random counter for each message. So, the question is whether 128-bits is big enough to get you the uniqueness probability you desire. >> 2) You don't need to implement the short plaintext special case >> if you implement Kerberos and GSS-API. You need to implement it >> only if you expose a general RFC 3961 API and choose to support >> short plaintexts in that that API. Greg> I don't think that's an interesting fact for my MIT krb5, and Greg> I would speculate that it's not interesting fact for any Greg> Kerberos implementation. This is a 3961 enctype, and if we Greg> implement it, we would want to implement it generally. We Greg> have internal uses of 3961 which involve short plaintexts, and Greg> we know of other 3961 consumers such as OpenAFS. Neither Microsoft nor Java provide access to RFC 3961. They are both widely deployed implementations of Kerberos. I agree that MIT provides access to a RFC 3961 API. To be clear I'm not making any specific proposal; I don't have an opinion on whether I favor CTR as an example. As a chair though, I have an obligation to make sure we reach an informed consensus so I'm trying to get everything out on the table. From hardjono@mit.edu Wed Aug 14 11:26: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 40C8A21F9EC9 for ; Wed, 14 Aug 2013 11:26:19 -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 0QrrYoOm1-yC for ; Wed, 14 Aug 2013 11:25: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 DCDF521F9E8B for ; Wed, 14 Aug 2013 11:25:35 -0700 (PDT) X-AuditID: 12074424-b7f228e00000096b-f1-520bcb9f06f3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DC.D7.02411.F9BCB025; Wed, 14 Aug 2013 14:25:35 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (outgoing-exchange-2.mit.edu [18.7.34.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r7EIPYAI016351 for ; Wed, 14 Aug 2013 14:25:35 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (oc11exedge3.exchange.mit.edu [18.9.3.21]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id r7EIPLgp029335 for ; Wed, 14 Aug 2013 14:25:34 -0400 Received: from OC11EXHUB7.exchange.mit.edu (18.9.3.19) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 14 Aug 2013 14:25:18 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.128]) by OC11EXHUB7.exchange.mit.edu ([18.9.3.19]) with mapi id 14.02.0309.002; Wed, 14 Aug 2013 14:25:18 -0400 From: Thomas Hardjono To: "kitten@ietf.org" Thread-Topic: New mailing-list for OIDC protocol (MITREid-Connect) Thread-Index: Ac6ZG57QfNQo27ChT4ifGjGiIJlYow== Date: Wed, 14 Aug 2013 18:25:17 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A2F22C40C@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.189.31.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsUixG6nojv/NHeQwZH5IhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqUn2QWPWCo6f69haWD8xNzFyMkhIWAiMffUaSYIW0ziwr31 bCC2kMA+RonmJyZdjFxA9jVGiWkdXUwQzmtGiblbj7FCONsYJebM+gjlrGKUuHThIgtIP5uA hsS533vZQWwRAXWJvYemgsWFBWwlZr//wwQRd5J4d/UnI4StJzHzwnJWEJtFQFVi877LYL28 AkESv+adALuVEei+76fWgPUyC4hL3HoyH+puQYlFs/cww/zwb9dDNghbQeLjvwYWiHodiQW7 P7FB2NoSyxa+ZoaYLyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYpRNya3SzU3MzClOTdYt Tk7My0st0jXXy80s0UtNKd3ECI4fF5UdjM2HlA4xCnAwKvHwRrRxBwmxJpYVV+YeYpTkYFIS 5V10CijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPdMB1CONyWxsiq1KB8mJc3BoiTO++zp2UAh gfTEktTs1NSC1CKYrAwHh5IE73KQoYJFqempFWmZOSUIaSYOTpDhPEDD14HU8BYXJOYWZ6ZD 5E8xKkqJ8z4FSQiAJDJK8+B6YentFaM40CvCvBtAqniAqRGu+xXQYCagwQ7ZXCCDSxIRUlIN jHZ37s2zD/t+I+J12faSomUKZ9Sa5zQ/lK9M74yMePp6a/yRiT6fPL2zknoLTzlz7Uyc9WPG ypLVHw6VR/5j3+HoJVu7jjlCwDpv6nnG3sn7nr8OtFinEOj5mSVuJs+pb/9yl72VD82bcchY 3OqAQmm6zr2X/Qrzzx6e4fwr6On5P381XnLsPqPEUpyRaKjFXFScCABgPk6MSgMAAA== Subject: [kitten] New mailing-list for OIDC protocol (MITREid-Connect) 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, 14 Aug 2013 18:26:28 -0000 Folks, There is a new dev mailing-list for the MITREid-Connect implementation. Th= is is the open-source implementation of the OpenID-Connect (OIDC) protocol = that uses OAuth2.0. Its continuing to developed at MIT. OIDC may be of interest to folks working in the identity/federation space. http://mailman.mit.edu/mailman/listinfo/mitreid-connect /thomas/ ____________________________________________ Thomas Hardjono MIT Consortium for Kerberos & Internet Trust e: hardjono[at]mit.edu m: +1 781 729 9559 w: kit.mit.edu ____________________________________________ From ghudson@mit.edu Wed Aug 14 12:21:38 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 1DA1221F9A2A for ; Wed, 14 Aug 2013 12:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 9YHPVF-mwsVN for ; Wed, 14 Aug 2013 12:21:26 -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 83CF121F9A4B for ; Wed, 14 Aug 2013 12:21:26 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-98-520bd8b569e9 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 2C.8B.02359.5B8DB025; Wed, 14 Aug 2013 15:21:25 -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 r7EJLNqm013847; Wed, 14 Aug 2013 15:21:23 -0400 Received: from [18.101.8.212] (vpn-18-101-8-212.mit.edu [18.101.8.212]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7EJLJaS030607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Aug 2013 15:21:21 -0400 Message-ID: <520BD8AF.40306@mit.edu> Date: Wed, 14 Aug 2013 15:21:19 -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: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> 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+NgFprBKsWRmVeSWpSXmKPExsUixCmqrbv1BneQwac95hZf2x6wWVx/f47d 4ujmVSwW8xoyHFg89rceY/VYsuQnk8fKqafZPbY2/2MMYInisklJzcksSy3St0vgyvi74C1r QatUxbmT31kbGB+IdDFyckgImEjsPLWIBcIWk7hwbz1bFyMXh5DAPkaJlqf3mSCcjYwS129M YoRwjjBJ3LzeBlTGwcEroCLx408ISDeLgKpE+/3PbCA2m4CyxMGz38CmigqESNxcdpoRxOYV EJQ4OfMJWFxEQF1i9aVJ7CA2s0C6xIIJa8FqhAWKJJ7+b2SG2NXOKjH/4GKwIk4BNYk3H1cx QZwqKbFoWicLRLOOxLu+B8wQtrzE9rdzmCcwCs1Csm8WkrJZSMoWMDKvYpRNya3SzU3MzClO TdYtTk7My0st0jXSy80s0UtNKd3ECI4ASd4djO8OKh1iFOBgVOLhjWjjDhJiTSwrrsw9xCjJ waQkymt8FSjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPdMB1CONyWxsiq1KB8mJc3BoiTO+/Tp 2UAhgfTEktTs1NSC1CKYrAwHh5IE7+XrQI2CRanpqRVpmTklCGkmDk6Q4TxAwwVugAwvLkjM Lc5Mh8ifYlSUEud9CNIsAJLIKM2D64UlqFeM4kCvCPOKgbTzAJMbXPcroMFMQIMdsrlABpck IqSkGhibP1+XfZgv+1/4noONxY6gOe9P/zBLOp9XzCZ1dLngXCnXlrcLjpze/f75v5zds9oX HWl2XHSPw+KNkTbn03lmZTPWi/YtFPza+rOsb8rPmkOh/foifA/ij3DyT5l9uVYo9+i81czl n7aLNnGZxyUndto/lH/9Z+HJGokog/Pu8h6srZVMT24osRRnJBpqMRcVJwIALPBMHysDAAA= Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 19:21:38 -0000 On 08/14/2013 01:40 PM, Sam Hartman wrote: > Greg> If I understand how CTR+HMAC would work, the same problems > Greg> exist for CTR+HMAC as for CCM: the 128-bit block size of AES > Greg> is not big enough for a random nonce and a block counter, > Greg> given the requirements for maximum message size and the > Greg> requirements for confidence of nonce uniqueness. > > However, CTR unlike CCM doesn't specify the breakdown. > You could for example pick a random counter for each message. I'm not sure how "a random counter for each message" could mean anything different from the "random nonce" I referred to above. This may mean that I was unclear, so I will expand on what I meant. Each block of message plaintext needs to be assigned a 128-bit counter value, somehow, and we want (at a minimum) a probabilistic guarantee that the same counter value will not be used for the same key. In Kerberos, the same long-term key is used for many messages in an uncoordinated fashion, so the best we can do is pick a random counter value and transmit it along with the message in the header. If we could use the full 128-bit space for this choice, then we would expect a birthday attack to succeed after an attacker observes around 2^64 messages. This is not so bad; in CBC mode we also start leaking information about plaintexts once a cipher block collision occurs. However, RFC 3961 messages can be more than one block long; in fact, RFC 3961 says that messages can have "arbitrary size." So, we have to decide what counter value to use with blocks after the first one. Some obvious options are: 1. Reserve some of the counter bits for a block counter, e.g. 96 bits for the random component and 32 bits for the counter. This decreases the expected number of messages before a birthday attack would succeed to something on the order of 2^48 messages, and also places a limit on the length of each message. 2. Apply a predictable function, such as 128-bit increment, to the current block's counter to produce the next one. Do not restrict the choice of the initial counter; instead, try to reason about the probability that the Nth block of one message has a counter collision with the Mth block of another message. 3. Pick a new random counter value for each block, and transmit it along with the ciphertext. This yields a 100% ciphertext expansion (or a bit more than that if the final plaintext block is short). Option 1 is essentially what CCM and GCM do. Option 2 could be considered novel (although you could also characterize it as just CTR with the counter XOR'd with the nonce), and I do not immediately know what probabilistic guarantees it would have. Option 3 seems strictly more likely to be incompatible with SSPI consumers than padded CBC is. As an aside, Luke has suggested in the past that we specify a CCM or GCM enctype and restrict its use to short-lived subkeys in sequential protocols (basically, as a result of RFC 4537 negotiation). However, this would not satisfy the motivating the current enctype proposal; we would still need something appropriate for use with long-term keys. Also, I'm not sure if I have good ways in MIT krb5 implementation to ensure that such an enctype is only used in a secure fashion. From simo@redhat.com Wed Aug 14 12:35: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 DD47221F9A74 for ; Wed, 14 Aug 2013 12:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 wVFBvCIgmBGO for ; Wed, 14 Aug 2013 12:35:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFE21F9B26 for ; Wed, 14 Aug 2013 12:35:22 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7EJZJDk028165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 15:35:19 -0400 Received: from [10.3.113.112] (ovpn-113-112.phx2.redhat.com [10.3.113.112]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7EJZI95025484; Wed, 14 Aug 2013 15:35:18 -0400 From: Simo Sorce To: Greg Hudson In-Reply-To: <520BD8AF.40306@mit.edu> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <520BD8AF.40306@mit.edu> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Wed, 14 Aug 2013 15:35:17 -0400 Message-ID: <1376508917.2814.22.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 19:35:27 -0000 On Wed, 2013-08-14 at 15:21 -0400, Greg Hudson wrote: > On 08/14/2013 01:40 PM, Sam Hartman wrote: > > Greg> If I understand how CTR+HMAC would work, the same problems > > Greg> exist for CTR+HMAC as for CCM: the 128-bit block size of AES > > Greg> is not big enough for a random nonce and a block counter, > > Greg> given the requirements for maximum message size and the > > Greg> requirements for confidence of nonce uniqueness. > > > > However, CTR unlike CCM doesn't specify the breakdown. > > You could for example pick a random counter for each message. > > I'm not sure how "a random counter for each message" could mean anything > different from the "random nonce" I referred to above. This may mean > that I was unclear, so I will expand on what I meant. > > Each block of message plaintext needs to be assigned a 128-bit counter > value, somehow, and we want (at a minimum) a probabilistic guarantee > that the same counter value will not be used for the same key. In > Kerberos, the same long-term key is used for many messages in an > uncoordinated fashion, so the best we can do is pick a random counter > value and transmit it along with the message in the header. If we could > use the full 128-bit space for this choice, then we would expect a > birthday attack to succeed after an attacker observes around 2^64 > messages. This is not so bad; in CBC mode we also start leaking > information about plaintexts once a cipher block collision occurs. > > However, RFC 3961 messages can be more than one block long; in fact, RFC > 3961 says that messages can have "arbitrary size." So, we have to > decide what counter value to use with blocks after the first one. Some > obvious options are: > > 1. Reserve some of the counter bits for a block counter, e.g. 96 bits > for the random component and 32 bits for the counter. This decreases > the expected number of messages before a birthday attack would succeed > to something on the order of 2^48 messages, and also places a limit on > the length of each message. > > 2. Apply a predictable function, such as 128-bit increment, to the > current block's counter to produce the next one. Do not restrict the > choice of the initial counter; instead, try to reason about the > probability that the Nth block of one message has a counter collision > with the Mth block of another message. If you simply increment and you have 1 collision, then you have a stream of collisions for all the remaining blocks of both messages after the collision, as they all have the counter increment the same way. Or did I misunderstand something in the way you propose to increment the random counter ? I am not sure whether it helps to avoid multiple collisions, but if it does then perhaps what you could do is use a PRNG that is seeded by the random counter and guarantee that different seeds produce completely different sequences, ie even if at some point there is a counter collision, the next pseudo-random counter would be different anyway as long as the initial seed was different. this may be obtained perhaps by combining the initial seed with the result of the defined pseudo random function for each block. Simo. > 3. Pick a new random counter value for each block, and transmit it along > with the ciphertext. This yields a 100% ciphertext expansion (or a bit > more than that if the final plaintext block is short). > > Option 1 is essentially what CCM and GCM do. Option 2 could be > considered novel (although you could also characterize it as just CTR > with the counter XOR'd with the nonce), and I do not immediately know > what probabilistic guarantees it would have. Option 3 seems strictly > more likely to be incompatible with SSPI consumers than padded CBC is. > > As an aside, Luke has suggested in the past that we specify a CCM or GCM > enctype and restrict its use to short-lived subkeys in sequential > protocols (basically, as a result of RFC 4537 negotiation). However, > this would not satisfy the motivating the current enctype proposal; we > would still need something appropriate for use with long-term keys. > Also, I'm not sure if I have good ways in MIT krb5 implementation to > ensure that such an enctype is only used in a secure fashion. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Simo Sorce * Red Hat, Inc * New York From nico@cryptonector.com Wed Aug 14 12:37:02 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 E1C4321F9B94 for ; Wed, 14 Aug 2013 12:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=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 pArVZiTheofH for ; Wed, 14 Aug 2013 12:36:58 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1F721F9B28 for ; Wed, 14 Aug 2013 12:36:52 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 8413D20203C for ; Wed, 14 Aug 2013 12:36:51 -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=hhfGj6kSNSGvmKe+eZoC w26VrVo=; b=noRmE4T+DinQvnvSeAZtl0o3OW+wlWpy+j0hviSpXXyVe2ZttUGN 5gUszdvp0kWhwzJlPBkWA8f8h1JaXKTioGX7lWU8Zx58iEVnWjZl4KvkkH2XmUOS Dxzj08QOFywBG7nFSbjn2wtI+uJ4XXraSba5br5Gkgr+pxhe4014+h8= 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-a31.g.dreamhost.com (Postfix) with ESMTPSA id D32E9202038 for ; Wed, 14 Aug 2013 12:36:50 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id j17so2394526wiw.13 for ; Wed, 14 Aug 2013 12:36:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VeylVKOtRdUqlQfmtG9bxBO/paTPtRY8eq2VKwYoawo=; b=MjckwbmKezrlp7rPVCBMoL3zxASKgg/3Q1juPIxFrSdR9oSbN4AtjFp+csOnGjWeb+ 0xn3GmYz7XuAAvei8WxHju2lMpm44zJkzTjs+JxK5Mtb6dct1u5HEU67USFd8tDJEzue WFWUpze4GNMuvclfAOPrqD6I09HHybWGM4HkfM5nPRx5bHNyvMSns46YDKAIhVtgITHl PwLPKobU7bSZLokeoR9A61qRr7AJiXevSCGxlcfcYlEZhBcrf6HYOTXFPocBrglhIyB/ XQsLVKgx/e/E9b9GxSA3GWJ9C75qZyc4+iLv0O4aybYzRGuc5LG3cyQnj5EJrqsdyrAp R0Uw== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr7047378wic.33.1376509008372; Wed, 14 Aug 2013 12:36:48 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Wed, 14 Aug 2013 12:36:47 -0700 (PDT) In-Reply-To: <520BD8AF.40306@mit.edu> References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <520BD8AF.40306@mit.edu> Date: Wed, 14 Aug 2013 14:36:47 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 19:37:03 -0000 On Wed, Aug 14, 2013 at 2:21 PM, Greg Hudson wrote: > On 08/14/2013 01:40 PM, Sam Hartman wrote: >> Greg> If I understand how CTR+HMAC would work, the same problems >> Greg> exist for CTR+HMAC as for CCM: the 128-bit block size of AES >> Greg> is not big enough for a random nonce and a block counter, >> Greg> given the requirements for maximum message size and the >> Greg> requirements for confidence of nonce uniqueness. >> >> However, CTR unlike CCM doesn't specify the breakdown. >> You could for example pick a random counter for each message. > > I'm not sure how "a random counter for each message" could mean anything > different from the "random nonce" I referred to above. This may mean > that I was unclear, so I will expand on what I meant. > > Each block of message plaintext needs to be assigned a 128-bit counter > value, somehow, and we want (at a minimum) a probabilistic guarantee > that the same counter value will not be used for the same key. In > Kerberos, the same long-term key is used for many messages in an > uncoordinated fashion, so the best we can do is pick a random counter > value and transmit it along with the message in the header. If we could > use the full 128-bit space for this choice, then we would expect a > birthday attack to succeed after an attacker observes around 2^64 > messages. This is not so bad; in CBC mode we also start leaking > information about plaintexts once a cipher block collision occurs. We've discussed GCM and such modes before. My opinion is that if we're to use such a mode we should: a) use a 256-bit IV, (or even 192?) using at least 128 of those bits to derive an encryption key, b) using some of the remaining 128 bits as a nonce to be held constant for all uses of the derived key, c) and using the remaining bits as a block counter That would give us enough bits with which to ensure no duplicate key+IV usage using: a) a high-resolution timestamp, b) a boot counter or timestamp, c) a random nonce. > As an aside, Luke has suggested in the past that we specify a CCM or GCM > enctype and restrict its use to short-lived subkeys in sequential > protocols (basically, as a result of RFC 4537 negotiation). However, > this would not satisfy the motivating the current enctype proposal; we > would still need something appropriate for use with long-term keys. > Also, I'm not sure if I have good ways in MIT krb5 implementation to > ensure that such an enctype is only used in a secure fashion. Agreed, that'd be a nice solution but it has those problems. Nico -- From hartmans@mit.edu Wed Aug 14 12:40: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 69D7721F9B90 for ; Wed, 14 Aug 2013 12:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 qYLiu3ZMalrj for ; Wed, 14 Aug 2013 12:40:31 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 670ED21F9B11 for ; Wed, 14 Aug 2013 12:40:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 397CD20280; Wed, 14 Aug 2013 15:39:16 -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 HfkYMYF7hiHl; Wed, 14 Aug 2013 15:39:15 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 15:39:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0B9CD8051A; Wed, 14 Aug 2013 15:40:25 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> <7772_1373495078_r6AMObRr007482_ldvwqoygijs.fsf@cathode-dark-space.mit.edu> <1373497760.23365.223.camel@minbar.fac.cs.cmu.edu> <99F1C096-A80D-42EF-8422-854EE7625073@padl.com> <51E55AFE.8020800@mit.edu> <51FA6DE2.2050708@mit.edu> <520BD8AF.40306@mit.edu> Date: Wed, 14 Aug 2013 15:40:25 -0400 In-Reply-To: <520BD8AF.40306@mit.edu> (Greg Hudson's message of "Wed, 14 Aug 2013 15:21:19 -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, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 19:40:37 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> 2. Apply a predictable function, such as 128-bit increment, to Greg> the current block's counter to produce the next one. Do not Greg> restrict the choice of the initial counter; instead, try to Greg> reason about the probability that the Nth block of one message Greg> has a counter collision with the Mth block of another message. This is what I was talking about. It's something we haven't thought about before. I don't know if it would be acceptable, nor am I personally either advocating it nor asking that we evaluate it. From hartmans@mit.edu Wed Aug 14 12:45:17 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 A2C8D21F8FF8 for ; Wed, 14 Aug 2013 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 4X0UgFz1FZ8C for ; Wed, 14 Aug 2013 12:45:11 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A867021F9D3A for ; Wed, 14 Aug 2013 12:45:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A75B620280; Wed, 14 Aug 2013 15:43:45 -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 YAcLKwkO81zp; Wed, 14 Aug 2013 15:43:45 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 15:43:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 822398051A; Wed, 14 Aug 2013 15:44:54 -0400 (EDT) From: Sam Hartman To: Derek Atkins References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 15:44:54 -0400 In-Reply-To: (Derek Atkins's message of "Thu, 11 Jul 2013 09:01:51 -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] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 19:45:17 -0000 Derek, after the Berlin meeting, you asked me some questions about CBC timing attacks and the new aes-cbc-hmac-sha2 proposal. I didn't know the answers. Any chance you could write that up here so we can discuss? From michikos@microsoft.com Wed Aug 14 16:11:52 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 5DBE111E81C6 for ; Wed, 14 Aug 2013 16:11:52 -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 tZdFQsgZM3MH for ; Wed, 14 Aug 2013 16:11:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 680F211E81C7 for ; Wed, 14 Aug 2013 16:11:45 -0700 (PDT) Received: from BLUPR03CA031.namprd03.prod.outlook.com (10.141.30.24) by BLUPR03MB601.namprd03.prod.outlook.com (10.255.124.38) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 14 Aug 2013 22:56:30 +0000 Received: from BL2FFO11FD017.protection.gbl (2a01:111:f400:7c09::23) by BLUPR03CA031.outlook.office365.com (2a01:111:e400:879::24) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Wed, 14 Aug 2013 22:56:31 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Wed, 14 Aug 2013 22:56:30 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.223]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Wed, 14 Aug 2013 22:55:29 +0000 From: Michiko Short To: Sam Hartman Thread-Topic: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt) Thread-Index: Ac6UguuCfwuvEtnVS+WRXhLN+l/eLwEh5RdIAA1hMBA= Date: Wed, 14 Aug 2013 22:55:29 +0000 Message-ID: <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.21] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(189002)(199002)(377454003)(164054003)(51856001)(6806004)(65816001)(77982001)(55846006)(74366001)(59766001)(80022001)(76786001)(76796001)(83322001)(19580405001)(44976005)(33656001)(81686001)(46102001)(50986001)(63696002)(83072001)(19580395003)(49866001)(47776003)(20776003)(47976001)(47736001)(79102001)(4396001)(81542001)(69226001)(74876001)(16406001)(53806001)(54356001)(80976001)(76482001)(77096001)(74706001)(56776001)(66066001)(50466002)(54316002)(47446002)(23756003)(31966008)(56816003)(74662001)(74502001)(81342001)(81816001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB601; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0938781D02 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BL2FFO11FD017.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB601.namprd03.prod.outlook.com Cc: "kitten@ietf.org" Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 23:11:52 -0000 None of us in the team today remember a promise that the padding buffer wou= ld be greater than 8. I would not say that padding is not a concern. There is definitely concern = about security vulnerabilities pursuing this course of action. We have see= n plenty of issues with CBC and padding. At the least, if there is a paddin= g oracle then there is a problem. So there will need to be much more scruti= ny if moving away from CTS. Remaining with CTS would be preferred as it wou= ld both avoid the app compat issue and security concerns. We would hate to = have to disable a new cipher suite due to app compat issues or limit it to = enlighted applications.=20 I am curious why we aren't just using the same AES-CTS as in the current RF= C? Also why SHA 384 instead of 512? Thanks, Michiko Short |=A0Program Manager | Windows Security & Identity -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Wednesday, August 14, 2013 9:22 AM To: Michiko Short Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft= -ietf-kitten-aes-cts-hmac-sha2-01.txt) >>>>> "Michiko" =3D=3D Michiko Short writes: Michiko> Apologies for the late response, I have not been tracking Michiko> the crypto discussions on aes-cts-hmac-sha2, so I did not Michiko> realize a response was needed. Since the issue which Michiko> requires the padding is caused by applications that do not Michiko> use the SSPI APIs correctly, this should not be driver for Michiko> the new crypto. Windows SSPI functions exist for an Michiko> application to obtain the required lengths for use with the Michiko> in-place encryption functions. Performance and security Michiko> should be the drivers for selection of the new AES Michiko> algorithm. We do get a lot of feedback about perf. So, when were the padding length functions introduced? I seem to recall that MSDN used to say that the padding buffer would never = be greater than 8. Am I misremembering? Is that no longer a concern? From michikos@microsoft.com Wed Aug 14 16:13: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 E1C0421E804D for ; Wed, 14 Aug 2013 16:13:18 -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 E5FQ14vpykT6 for ; Wed, 14 Aug 2013 16:13:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 55EBA11E81C7 for ; Wed, 14 Aug 2013 16:13:09 -0700 (PDT) Received: from BLUPR03CA035.namprd03.prod.outlook.com (10.141.30.28) by BLUPR03MB017.namprd03.prod.outlook.com (10.255.208.39) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 14 Aug 2013 22:58:01 +0000 Received: from BY2FFO11FD012.protection.gbl (2a01:111:f400:7c0c::25) by BLUPR03CA035.outlook.office365.com (2a01:111:e400:879::28) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Wed, 14 Aug 2013 22:58:01 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Wed, 14 Aug 2013 22:58:00 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.223]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Wed, 14 Aug 2013 22:56:56 +0000 From: Michiko Short To: Sam Hartman , "kitten@ietf.org" Thread-Topic: History of AES block size issues Thread-Index: AQHOmRH+HMD4ozQasUORb8tmnLRtgpmVUOuA Date: Wed, 14 Aug 2013 22:56:55 +0000 Message-ID: <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(189002)(377454003)(199002)(53806001)(16406001)(74876001)(69226001)(54356001)(4396001)(561944002)(47736001)(20776003)(49866001)(47776003)(79102001)(81542001)(81342001)(47446002)(31966008)(74662001)(81816001)(76482001)(74502001)(80976001)(77096001)(63696002)(54316002)(74706001)(56816003)(50986001)(50466002)(56776001)(46406003)(66066001)(80022001)(65816001)(55846006)(77982001)(74366001)(51856001)(59766001)(6806004)(23726002)(46102001)(47976001)(19580405001)(19580395003)(76796001)(44976005)(81686001)(83322001)(83072001)(33656001)(76786001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB017; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0938781D02 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BY2FFO11FD012.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB017.namprd03.prod.outlook.com Subject: Re: [kitten] History of AES block size issues 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, 14 Aug 2013 23:13:19 -0000 What is the scenario requiring message expansion up to 16 octets? -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Wednesday, August 14, 2013 10:17 AM To: kitten@ietf.org Cc: Michiko Short; Larry Zhu; raeburn@mit.edu Subject: History of AES block size issues For those copied on this message, the kitten working group is considering a= proposal to produce an AES enctype that provides message expansion of up t= o 16 octets. That's kind of a departure from how we've been approaching this, so I decid= ed to go over the history and implications a bit. The chairs are requiring the proponents of the proposal to try and investig= ate why we wanted to avoid message expansion in the past and do their best = to compile our rationale and an explanation of why the change is desirable. Yes, this all would have been easier if we'd done a better job of documenti= ng the rationale. This is from my memory, and I may be getting things wrong; however I think= I know the people who were involved enough that you should be able to reac= h out to folks and try and figure out what was happening. During the development of what became RFC 3962, I believe that John Brezak = and possibly Paul Leach approached Ken Raeburn with a proposal to avoid no= n-constant message expansion. I don't believe a strong explanation was offered at that point why; it seem= ed very important to John. It seemed like an improvement, so the WG went along. Originally, Ken raeburn proposed draft-ietf-krb-wg-gss-crypto as a mechanis= m for GSS-API in Kerberos. Larry Zhu was very unhappy with this approach and proposed an alternative. I can't find that alternative. It was a lot closer to RFC 1964 than RFc 4= 121. MIT was very unhappy with that alternative because you had to specify GSS c= rypto algorithms separate from RFC 3961 algorithms. The big compromise that allowed us all to get to RFC 4121 was the RRC. It is my belief that two things went into that. First, a desire that the MAC and other information needed to be at the head= er of the token not at the end as in RFC 3961. I seem to recall a desire to do something with padding, but am not able to = substantiate that now. I'd also like to discuss API implications. Most of the implementations (MIT, Heimdal and Microsoft) have a scatter-gat= her API for GSS operations. In Microsoft, it's the SSP. In the other implementations it is the iov interface to GSS-API. All the existing implementations will negotiate a subsession key of a mode= rn enctype in their default configuration. That is the default configurati= ons of all the GSS implementations will end up negotiating something that d= oes not pad GSS tokens. So, in the default configuration, an application using the scatter-gather A= PIs will never test its support for padding buffers. If a non-default configuration is used and one of the DES enctypes is used = for GSS-API messages, padding may be used. both the Microsoft and other APIs support padding; a correctly written appl= ication can work with padding under all the existing APIs. We believe there are some protocols that use AEAD where the length of a tok= en is protected by AEAD. These protocols need to be able to make sure that= padding does not adjust the length. Also, note that while MIT and Heimdal have a scatter-gather API, it is not = their default API. The API described in RFC 2744 is more common on these i= mplementations for applications to use. From hartmans@mit.edu Wed Aug 14 16:44: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 CB3EC21F8263 for ; Wed, 14 Aug 2013 16:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 5lXAF6t71bbS for ; Wed, 14 Aug 2013 16:44:19 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA4E11E817F for ; Wed, 14 Aug 2013 16:44:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 08FB820288; Wed, 14 Aug 2013 19:43:06 -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 v8rXoXjF8mQc; Wed, 14 Aug 2013 19:43:04 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 19:43:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1B1AF8051A; Wed, 14 Aug 2013 19:44:14 -0400 (EDT) From: Sam Hartman To: Michiko Short References: <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 14 Aug 2013 19:44:14 -0400 In-Reply-To: <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> (Michiko Short's message of "Wed, 14 Aug 2013 22:56:55 +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" , Sam Hartman Subject: Re: [kitten] History of AES block size issues 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, 14 Aug 2013 23:44:27 -0000 >>>>> "Michiko" == Michiko Short writes: Michiko> What is the scenario requiring message expansion up to 16 Michiko> octets? -----Original Message----- From: Sam Hartman With DES your message is padded to 8 octets.So if I sent you a 2 byte message it actually gets padded out to be 8 octets. If I send you a 9-octet message it's actually 16. If I send you a 16-octet message it's still 16 octets. Added onto that is the size of the checksum and confounder, but those are constant. With aes-cts and rc4, there's a checksum and confounder but the ciphertext is as long as the plaintext. With this aes-cbc- proposal, there's a checksum and initial IV (constant size). However the message is padded to 16-octet boundaries. If I send 1 byte of plaintext then it's going to be 16 octets. If I send a 16-octet plaintext message I think it comes out to 32 octets because of padding. Greg, am I right that if your application aligns to a block size then you'll actually end up expanding more so you can indicate no padding is needed? If so will DCE RPC be OK with that? From lukeh@padl.com Wed Aug 14 16:55: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 C1AF621E80C3 for ; Wed, 14 Aug 2013 16:55:34 -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 2LFc984WlDll for ; Wed, 14 Aug 2013 16:55:29 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A2DDD21E8082 for ; Wed, 14 Aug 2013 16:55:29 -0700 (PDT) Received: by us.padl.com with ESMTP id r7ENtIv8013371; Wed, 14 Aug 2013 19:55:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: Date: Thu, 15 Aug 2013 09:55:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <970B41DA-0AE6-4CC8-9DAB-A4049D8F0A44@padl.com> References: <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Sam Hartman 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" , Michiko Short Subject: Re: [kitten] History of AES block size issues 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, 14 Aug 2013 23:55:34 -0000 > If I send you a 9-octet message it's actually 16. > If I send you a 16-octet message it's still 16 octets. Is it not 24 octets? > Greg, am I right that if your application aligns to a block size then > you'll actually end up expanding more so you can indicate no padding = is > needed? > If so will DCE RPC be OK with that? I believe it's fine for the reasons I mentioned in my last mail: Note "trailer" here means DCE RPC auth trailer, containing the RFC 4121 = "header" (which has the EC and checksum rotated into a single token) * DCE RPC always pads at the application layer, if this it to at least = 16 bytes then we will have a constant length trailer (we need to = investigate this) * Even if DCE RPC doesn't pad at the application layer to 16 bytes, = [MS-RPCE] allows the trailer to be over-allocated, so as long as it's = big enough for the largest value of EC, variable length trailers are OK -- Luke From nico@cryptonector.com Wed Aug 14 16:57:35 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 874A221E80EB for ; Wed, 14 Aug 2013 16:57:35 -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 V96f+-gMsIIn for ; Wed, 14 Aug 2013 16:57:30 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6221E8082 for ; Wed, 14 Aug 2013 16:57:30 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 7200F7E4065 for ; Wed, 14 Aug 2013 16:57:30 -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=+pYCGIZEkVz5d3wTjvF+ 3iiSy8U=; b=JGFs1YkDQmYKyOgdBS4MbZSPu59o605TzquyeGnFExQHOqM5bKpY h7+Ir6STmdpskPOMUKPbbZSn3GQ3ar4e/ucKEGiy2675KTQ5sR5p+qW//JiEuXHb efsHBrEtg06ifMqx3Lkk434PERU/km+MNyg5dKuMM6Y0HxffidVb8eA= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 204727E405D for ; Wed, 14 Aug 2013 16:57:29 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so83540wes.40 for ; Wed, 14 Aug 2013 16:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iTbfsUornFkGKiKCVEZ5qCxy0N8CJilXbbqOnXrvpb8=; b=gD6deZK+L2PBH6pA71JTr47GvSrFqomkFe0FEJ75sgcrkPe5jN6y3IZRyeSibXTI0R tPPcudzlYo5HGu0EZbLhlfye2zVTBSGhlzQU5s8BsE4pAr5cABF0ZtLaqE3zhs2Hwg6n uvTg8OMnygZCyVKXKBclh5ZsCklH1Af0vDroleE5/IXv8fmypqcjPonmzv2KIjrVMKGr FZF/z9lUjnkKChxmVtT78AWRJJTq67tu6BG40tEbQ7FPxUst4ONENaLpIEr6VX8EcVyU VxWQcsgd54NmhDAeVO1u1nkLKsiduUs69CMb4sJZDIpg8M/pJ45zqSfxaTPyAulX2AyN gOIA== MIME-Version: 1.0 X-Received: by 10.194.75.165 with SMTP id d5mr4054236wjw.18.1376524648280; Wed, 14 Aug 2013 16:57:28 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Wed, 14 Aug 2013 16:57:28 -0700 (PDT) In-Reply-To: <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 14 Aug 2013 18:57:28 -0500 Message-ID: From: Nico Williams To: Michiko Short Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 14 Aug 2013 23:57:35 -0000 On Wed, Aug 14, 2013 at 5:55 PM, Michiko Short wrote: > I am curious why we aren't just using the same AES-CTS as in the current RFC? The initially proposed AES-CTS-HMAC-SHA-2 enctype didn't confound, though it did have a random block prefix. This is an optimization over confounding: we've mostly convinced ourselves that it merely only reduces the number of AES block operations required, not the security of the whole. But this meant that we can have ciphertexts that are shorter than one block, which CTS cannot handle. We then set about using the non-confounded nonce as a source of "ciphertext" to steal from. The result was more complex than the CTS we use today, and shares with CTS the general lack of support in existing APIs (e.g., PKCS#11). Tom Yu and others expressed concern about this and a preference for plain old CBC with nonces. Ever since we've been wondering if this would be a problem for Microsoft, specifically for DCE and SSPI applications. Nico -- From hartmans@mit.edu Wed Aug 14 17:02:52 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 B8F6211E81BB for ; Wed, 14 Aug 2013 17:02:52 -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 EKFLl+gRR2v9 for ; Wed, 14 Aug 2013 17:02:47 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E463A11E816E for ; Wed, 14 Aug 2013 17:02:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EF90520280; Wed, 14 Aug 2013 20:01:34 -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 Vxz4GIWK6y6h; Wed, 14 Aug 2013 20:01:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 14 Aug 2013 20:01:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A45F8052F; Wed, 14 Aug 2013 20:02:43 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> <970B41DA-0AE6-4CC8-9DAB-A4049D8F0A44@padl.com> Date: Wed, 14 Aug 2013 20:02:43 -0400 In-Reply-To: <970B41DA-0AE6-4CC8-9DAB-A4049D8F0A44@padl.com> (Luke Howard's message of "Thu, 15 Aug 2013 09:55:17 +1000") 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] History of AES block size issues 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, 15 Aug 2013 00:02:52 -0000 >>>>> "Luke" == Luke Howard writes: >> If I send you a 9-octet message it's actually 16. If I send you >> a 16-octet message it's still 16 octets. Luke> Is it not 24 octets? Ah, that depends if you are talking RFC 3961 or RFC 1964. Under 3961 I think 16; under 1964 I think 24. >> Greg, am I right that if your application aligns to a block size >> then you'll actually end up expanding more so you can indicate no >> padding is needed? If so will DCE RPC be OK with that? Luke> I believe it's fine for the reasons I mentioned in my last Luke> mail: Luke> Note "trailer" here means DCE RPC auth trailer, containing the Luke> RFC 4121 "header" (which has the EC and checksum rotated into Luke> a single token) Luke> * DCE RPC always pads at the application layer, if this it to Luke> at least 16 bytes then we will have a constant length trailer Luke> (we need to investigate this) Yeah, although in the obvious implementation we'll have 16 octets of pad buffer. so you might have to modify DCE RPC to deal with that if it doesn't already, but I guess that's not a problem if you control both your DCE RPC and your GSS. From tlyu@mit.edu Wed Aug 14 19:48:49 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 CB5DC11E80F6 for ; Wed, 14 Aug 2013 19:48:49 -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 yKWCH8z0q5fm for ; Wed, 14 Aug 2013 19:48:43 -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 2071E11E80E9 for ; Wed, 14 Aug 2013 19:48:43 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-0b-520c418ae6d5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id ED.BA.02359.A814C025; Wed, 14 Aug 2013 22:48:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r7F2mepL022920; Wed, 14 Aug 2013 22:48:40 -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 r7F2mbH2021752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Aug 2013 22:48:39 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7F2mbgE006379; Wed, 14 Aug 2013 22:48:37 -0400 (EDT) To: Sam Hartman References: <5674376E76F88641AD3748A64F0996971AAB7DDE@TK5EX14MBXC285.redmond.corp.microsoft.com> <970B41DA-0AE6-4CC8-9DAB-A4049D8F0A44@padl.com> From: Tom Yu Date: Wed, 14 Aug 2013 22:48:37 -0400 In-Reply-To: (Sam Hartman's message of "Wed, 14 Aug 2013 20:02:43 -0400") Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1u1y5AkyuLlGxuJr2wM2i6ObV7FY 3L30n93iXzefA4vHkiU/mTxad/xl95j7YRqLx8qpp9kDWKK4bFJSczLLUov07RK4Mn41PmEv 6OOvuPJZsoHxGHcXIyeHhICJxOMXh1ggbDGJC/fWs4HYQgL7GCXmTPfoYuQCsjcySmx/v5AJ wjnHJHGttwnK6WKUWN/Qyg7SIiKgLrH60iQwm1mgTOLM7qXMILawgJnE+WsrWCAanjFKrFo1 Ecjh4GATkJY4urgMpIZFQFVi+Zw3YPWcAskSrZ9WsILYvAIWEndOvQM7iUeAU2LundvMEHFB iZMzn7BA7NKSuPHvJdMERsFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s 0UtNKd3ECA5nSd4djO8OKh1iFOBgVOLhjWjjDhJiTSwrrsw9xCjJwaQkyqtnzxMkxJeUn1KZ kVicEV9UmpNafIhRgoNZSYQ3Rhsox5uSWFmVWpQPk5LmYFES53369GygkEB6YklqdmpqQWoR TFaGg0NJglfPAahRsCg1PbUiLTOnBCHNxMEJMpwHaLgvSA1vcUFibnFmOkT+FKMux5+Vcz8x CrHk5eelSonz2oIUCYAUZZTmwc2BpaFXjOJAbwnzyoNU8QBTGNykV0BLmICWOGRzgSwpSURI STUwutUtPlvjLPbqxBvBZ4ZNEj/4DL66HbntNifdLSIl2FDwfuUSdr2oSQtsPp3xPlestX/K 5MiiNQLz95e3P92kt15C9GdmsvnBD5cXRSV3nyzgmqy4Xr9vqbCo3PeM8koFAwMlds+Vjj1p jy+eOtC23uLclFeqjCEf/CXKEn99OmSWFxQ+Y1mrEktxRqKhFnNRcSIA37kRMh4DAAA= Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] History of AES block size issues 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, 15 Aug 2013 02:48:49 -0000 Sam Hartman writes: >>>>>> "Luke" == Luke Howard writes: > > >> If I send you a 9-octet message it's actually 16. If I send you > >> a 16-octet message it's still 16 octets. > > Luke> Is it not 24 octets? > > Ah, that depends if you are talking RFC 3961 or RFC 1964. > Under 3961 I think 16; under 1964 I think 24. > > >> Greg, am I right that if your application aligns to a block size > >> then you'll actually end up expanding more so you can indicate no > >> padding is needed? If so will DCE RPC be OK with that? > > Luke> I believe it's fine for the reasons I mentioned in my last > Luke> mail: > > Luke> Note "trailer" here means DCE RPC auth trailer, containing the > Luke> RFC 4121 "header" (which has the EC and checksum rotated into > Luke> a single token) > > Luke> * DCE RPC always pads at the application layer, if this it to > Luke> at least 16 bytes then we will have a constant length trailer > Luke> (we need to investigate this) > > Yeah, although in the obvious implementation we'll have 16 octets of pad > buffer. > > so you might have to modify DCE RPC to deal with that if it doesn't > already, but I guess that's not a problem if you control both your DCE > RPC and your GSS. My interpretation of C706 and MS-RPCE is that it won't be a problem at a MS-RPC protocol level (except for possibly transmitting overallocated padding). Applications that roll their own MS-RPC implementation rather than using a library might be in trouble, though. Applications that can query for the padding and block size, and pad at the application layer to 16 bytes, can probably get away with assuming a constant size trailer without overallocating. I don't have detailed citations for the above at this time, but I could probably write them up if people feel that it's necessary. From tlyu@mit.edu Wed Aug 14 20:26: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 88BCD11E81C4 for ; Wed, 14 Aug 2013 20:26:36 -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 Cb79Bf3T4fcl for ; Wed, 14 Aug 2013 20:26:30 -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 BD50311E80F6 for ; Wed, 14 Aug 2013 20:26:29 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-b5-520c4a64bc5c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id CB.27.02387.46A4C025; Wed, 14 Aug 2013 23:26:28 -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 r7F3QRHu028741; Wed, 14 Aug 2013 23:26:28 -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 r7F3QP8d000315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Aug 2013 23:26:26 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7F3QPYc006477; Wed, 14 Aug 2013 23:26:25 -0400 (EDT) To: Michiko Short References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> From: Tom Yu Date: Wed, 14 Aug 2013 23:26:24 -0400 In-Reply-To: (Nico Williams's message of "Wed, 14 Aug 2013 18:57:28 -0500") Message-ID: Lines: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hRV1k3x4gkyuL3IxOJr2wM2i6ObV7FY /Ovmszh17QibA4vHy1PnGD2WLPnJ5NG64y+7x8qpp9kDWKK4bFJSczLLUov07RK4Mtp/XmIu eChXsX7uPrYGxs8SXYycHBICJhKth/azQNhiEhfurWfrYuTiEBLYxyjxsukqC4SzkVHi94Gt TCBVQgLnmCTe3q2FSHQxSux5to4dJCEioCXx4cJpsFHMAjUS7f9uM4PYwgKFEh8ObWaBaJ7F JLH8t20XIwcHm4C0xNHFZSBhFgFViSdLvjKC2JwCExglDi7gBrF5BSwktnz4ABbnEeCUmPf2 NQtEXFDi5MwnUKu0JG78e8k0gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN 9HIzS/RSU0o3MYLDWZJ/B+O3g0qHGAU4GJV4eCPauIOEWBPLiitzDzFKcjApifLae/IECfEl 5adUZiQWZ8QXleakFh9ilOBgVhLhjdEGyvGmJFZWpRblw6SkOViUxHmfPT0bKCSQnliSmp2a WpBaBJOV4eBQkuCdAzJUsCg1PbUiLTOnBCHNxMEJMpwHaPhGkBre4oLE3OLMdIj8KUZdjj8r 535iFGLJy89LlRLnXQVSJABSlFGaBzcHloZeMYoDvSXM2wFSxQNMYXCTXgEtYQJa4pDNBbKk JBEhJdXAaP9cx4S5T6loURjfF/fNNx+83Lzr/ckz4aac734vvcNRpKX+uqzhzTUDZgbO4l87 7+xRm7ddfsGp5pQV71VEHncr2WT+f5oTO11rb+Pb2TwrvsrxiG3dIXd4xZmYJxOvefxSE3JW znl4lVfd97EsC9uD2XHfw7bGcd7YP02302JPWIuSQkguoxJLcUaioRZzUXEiAJe74T0eAwAA Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 15 Aug 2013 03:26:36 -0000 Michiko Short writes: > None of us in the team today remember a promise that the padding buffer would be greater than 8. Do you mean that nobody in the team recalls a promise to application developers that the padding buffer would be no greater than 8 bytes? > I would not say that padding is not a concern. There is definitely concern about security vulnerabilities pursuing this course of action. We have seen plenty of issues with CBC and padding. At the least, if there is a padding oracle then there is a problem. So there will need to be much more scrutiny if moving away from CTS. Remaining with CTS would be preferred as it would both avoid the app compat issue and security concerns. We would hate to have to disable a new cipher suite due to app compat issues or limit it to enlighted applications. My understanding is that the encrypt-then-MAC construction eliminates the known CBC padding oracle attacks. If someone has evidence to the contrary, I would like to hear about it. > I am curious why we aren't just using the same AES-CTS as in the current RFC? I think the short answer is Suite B requirements and a desire to conform with current cryptographic best practices. I believe one goal is to align with draft-mcgrew-aead-aes-cbc-hmac-sha2. Earlier proposals for the Suite B enctypes involved GCM (I think we had a consensus that GCM wouldn't really work for anything invoving long-term keys), and some variant on the padded CBC that we're considering now, but changed to CTS mode because of MS-RPC related padding concerns. It's a different CTS mode than the one we use for RFC 3962. I think part of the justification for the differences between draft-ietf-kitten-aes-cts-hmac-sha2-01 and RFC 3962 is to align more closely with cryptographic best practice. This includes using an explicit IV (rather than a confounder) and using encrypt-then-MAC. The RFC 3962 encode-then-encrypt-and-MAC approach has been proven secure, but I recall that particular security result was far from obvious to the research community before the publication of the proof. > Also why SHA 384 instead of 512? I asked Kelley about this, and he said the Suite B mandate was for 128 bits for lower security, and 192 bits for higher security. That would imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they want an unequivocal 192 bits of strength). I don't know why Suite B doesn't specify AES-192 instead of AES-256 though. Maybe these rationales should be included in future revisions. Nico Williams writes: > On Wed, Aug 14, 2013 at 5:55 PM, Michiko Short wrote: >> I am curious why we aren't just using the same AES-CTS as in the current RFC? > > The initially proposed AES-CTS-HMAC-SHA-2 enctype didn't confound, > though it did have a random block prefix. This is an optimization > over confounding: we've mostly convinced ourselves that it merely only > reduces the number of AES block operations required, not the security > of the whole. But this meant that we can have ciphertexts that are > shorter than one block, which CTS cannot handle. I get the impression that the research community has been somewhat uncomfortable with the confounder idea, mostly because it's unfamiliar. > We then set about using the non-confounded nonce as a source of > "ciphertext" to steal from. The result was more complex than the CTS > we use today, and shares with CTS the general lack of support in > existing APIs (e.g., PKCS#11). Tom Yu and others expressed concern > about this and a preference for plain old CBC with nonces. Ever since > we've been wondering if this would be a problem for Microsoft, > specifically for DCE and SSPI applications. I think part of the complications were because Kelley wanted all of the bits of the IV to be included in the MAC. From kwburgi@tycho.ncsc.mil Thu Aug 15 10:26:59 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 779BF11E81DF for ; Thu, 15 Aug 2013 10:26:59 -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 91JUrPVUvgbL for ; Thu, 15 Aug 2013 10:26:53 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7936511E817A for ; Thu, 15 Aug 2013 10:26:52 -0700 (PDT) X-TM-IMSS-Message-ID: <18bac63d0000ebf2@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 18bac63d0000ebf2 ; Thu, 15 Aug 2013 13:26:34 -0400 Received: from rd6um-58422h.infosec.tycho.ncsc.mil (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r7FHQlRI005294; Thu, 15 Aug 2013 13:26:47 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kelley Burgin In-Reply-To: Date: Thu, 15 Aug 2013 13:28:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Tom Yu X-Mailer: Apple Mail (2.1503) Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 15 Aug 2013 17:26:59 -0000 Thanks Tom for your responses, you are correct. >> I would not say that padding is not a concern. There is definitely = concern about security vulnerabilities pursuing this course of action. = We have seen plenty of issues with CBC and padding. At the least, if = there is a padding oracle then there is a problem. So there will need to = be much more scrutiny if moving away from CTS. Remaining with CTS would = be preferred as it would both avoid the app compat issue and security = concerns. We would hate to have to disable a new cipher suite due to app = compat issues or limit it to enlighted applications.=20 >=20 > My understanding is that the encrypt-then-MAC construction eliminates > the known CBC padding oracle attacks. If someone has evidence to the > contrary, I would like to hear about it. This is correct. >=20 >> I am curious why we aren't just using the same AES-CTS as in the = current RFC? >=20 > I think the short answer is Suite B requirements and a desire to > conform with current cryptographic best practices. Correct again. >=20 > I believe one goal is to align with > draft-mcgrew-aead-aes-cbc-hmac-sha2. Earlier proposals for the Suite > B enctypes involved GCM (I think we had a consensus that GCM wouldn't > really work for anything invoving long-term keys), and some variant on > the padded CBC that we're considering now, but changed to CTS mode > because of MS-RPC related padding concerns. It's a different CTS mode > than the one we use for RFC 3962. GCM will not work in a long-term key environment because of counter = rollover issues. >=20 > I think part of the justification for the differences between > draft-ietf-kitten-aes-cts-hmac-sha2-01 and RFC 3962 is to align more > closely with cryptographic best practice. This includes using an > explicit IV (rather than a confounder) and using encrypt-then-MAC. > The RFC 3962 encode-then-encrypt-and-MAC approach has been proven > secure, but I recall that particular security result was far from > obvious to the research community before the publication of the proof. >=20 >> Also why SHA 384 instead of 512? >=20 > I asked Kelley about this, and he said the Suite B mandate was for 128 > bits for lower security, and 192 bits for higher security. That would > imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they > want an unequivocal 192 bits of strength). I don't know why Suite B > doesn't specify AES-192 instead of AES-256 though. Maybe these > rationales should be included in future revisions. This encryption type is intended to support Suite B applications. From nico@cryptonector.com Thu Aug 15 10:34:49 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 C65BB21F85C3 for ; Thu, 15 Aug 2013 10:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, 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 wFsk1bioHB96 for ; Thu, 15 Aug 2013 10:34:45 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D8B3011E80AD for ; Thu, 15 Aug 2013 10:34:44 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 25F4021DE6A for ; Thu, 15 Aug 2013 10:34:44 -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=inp0AvwwUysXxruDsf0J Xx372To=; b=nYZ4Diru4LGmTM+zNmQDo1OinlFgjmehchxK5EDJNpLblEOs29Cj JegjVR+k15STqwCLuGKtZU9QWlGZH1/SPkz7nug/O3BK6JXo+svEqZntYFxYA1Sh bxsgEo0C3u1zKRV0LDG3C513IYN1UnUjPNYy3PFwSrD7iPpcFzgY7OA= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.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 8904621DE65 for ; Thu, 15 Aug 2013 10:34:43 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so691532wiw.2 for ; Thu, 15 Aug 2013 10:34:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Qkb3PGOTGt6Mj0932gHUxJEE3NRBuPr7nWpwCH9m3w=; b=oV1jK7Yar4nbVBavahV8eKl0999uQG/TE9QfuyIpcqnmx7qDIq5sdSWHqfVvE/A00e 1KxtiCaFWqDP0MFcfZUvWg/jbaFu0Z63cPCARQ3ffYewxpyJxExHR9VzfVfZs7c//p6f 7JFrKTfd0XcP/wo/ClyWxdY5nAenuhqdj2NjUz8BBwT/Pv865F1YYE7pP95wVjA5CAsh u/PNQWTAYDQUSEAgVx/ZeU5aTgaOc7/Pqn3XiQMFLKBJiaa88/bpSs4w45Fcn6TyYCZ5 WURXQhvLHVihpR5nFQ5pqczd7/M6S00hpWINYd08Z/J8uArmsIzJMLRAve8+pqZXjXzh EAwg== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr2479880wic.33.1376588080940; Thu, 15 Aug 2013 10:34:40 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Thu, 15 Aug 2013 10:34:40 -0700 (PDT) In-Reply-To: References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Thu, 15 Aug 2013 12:34:40 -0500 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 15 Aug 2013 17:34:49 -0000 On Thu, Aug 15, 2013 at 12:28 PM, Kelley Burgin wrote: > GCM will not work in a long-term key environment because of counter rollover issues. It can be made to work by using a large enough IV from which to derive a sub-key for encryption and an IV for GCM itself. This, of course, would be sub-optimal: it'd increase ciphertext size (by the additional IV bits) and it'd add key derivation and key setup costs. It'd also depend on having strong-enough sources of entropy, good enough clocks, and so on, with which to ensure non-reuse of {long-term key, IV}. With lots of care a 128-bit IV could be used safely, but makes me very uncomfortable: some implementations/deployments will fail to be careful enough. In short: I agree, GCM is out. Would that we had high-performance AEAD cipher modes without the IV-reuse-destroys-security problem. From derek@ihtfp.com Fri Aug 16 06:46: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 57ADD11E815A for ; Fri, 16 Aug 2013 06:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 qSFDa5eCHFiJ for ; Fri, 16 Aug 2013 06:46:15 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26F11E814E for ; Fri, 16 Aug 2013 06:46:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7CD022602B2; Fri, 16 Aug 2013 09:46:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26953-03; Fri, 16 Aug 2013 09:46:12 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1031D2600B4; Fri, 16 Aug 2013 09:46:12 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r7GDkBX0019835; Fri, 16 Aug 2013 09:46:11 -0400 From: Derek Atkins To: Sam Hartman References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 09:46:11 -0400 In-Reply-To: (Sam Hartman's message of "Wed, 14 Aug 2013 15:44:54 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: kitten@ietf.org Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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: Fri, 16 Aug 2013 13:46:15 -0000 Hi, Sam Hartman writes: > Derek, after the Berlin meeting, you asked me some questions about CBC > timing attacks and the new aes-cbc-hmac-sha2 proposal. > I didn't know the answers. > Any chance you could write that up here so we can discuss? The issue was a question of whether it would be subject to the same timing attacks as Lucky13 used against SSL/TLS. The issue there was that an attacker could distinguish timing differences because padding changes could cause changes in the amount of padding data checked and also the number of MAC rounds performed. For example, in TLS you can pad from 0 to 255 bytes. If you assume the ciphertext is a constant length an attacker could use this to time the difference in processing time of different pad lengths, which can lead to disclosure of data and possibly keys. The main questions are whether changes in pad length could affect the number of rounds in the MAC process, and whether you have a constant-time padding checker, regardless of the actual number of pad bytes. I.e., Lucky13 was successful because the MAC (and possibly padding checks) were not constant-time based on the ciphertext length. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From ghudson@mit.edu Fri Aug 16 07:36:10 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 0D49211E828F for ; Fri, 16 Aug 2013 07:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.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 8HfgqKK8wNRJ for ; Fri, 16 Aug 2013 07:36:01 -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 245C911E8140 for ; Fri, 16 Aug 2013 07:35:57 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-6f-520e38cbbd76 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 81.A9.02357.BC83E025; Fri, 16 Aug 2013 10:35:55 -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 r7GEZr9d018845; Fri, 16 Aug 2013 10:35:54 -0400 Received: from [18.101.8.125] (vpn-18-101-8-125.mit.edu [18.101.8.125]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7GEZj0Y028335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Aug 2013 10:35:52 -0400 Message-ID: <520E38C1.7000109@mit.edu> Date: Fri, 16 Aug 2013 10:35:45 -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: Derek Atkins References: <20130628173017.2197.22687.idtracker@ietfa.amsl.com> 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+NgFprAKsWRmVeSWpSXmKPExsUixG6nrnvagi/I4McxXouVk3awW3xte8Bm cXTzKhYHZo8lS34yeSz/+oDFY+XU0+wBzFFcNimpOZllqUX6dglcGV+fT2UveMZY8fp1J2sD 41bGLkZODgkBE4lPexYwQdhiEhfurWfrYuTiEBLYxyjxaMJldghnI6PEus/bmCGcI0wSXz48 ZgFp4RVQk7g8u58dxGYRUJW4uXoGM4jNJqAscfDsN7AaUYEQiZvLTjNC1AtKnJz5BCwuIqAk 8WXPfTCbWcBC4kv7T7AaYYEiiaf/G6GWbWSWmDljNhtIglNAX+LH1mksELdKSiya1gnVrCPx ru8BM4QtL7H97RzmCYxCs5Dsm4WkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0TfVy M0v0UlNKNzGCA95FaQfjz4NKhxgFOBiVeHgZJvIGCbEmlhVX5h5ilORgUhLl1QfGixBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3q0GQDnelMTKqtSifJiUNAeLkjjvs6dnA4UE0hNLUrNTUwtS i2CyMhwcShK8/82BGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGy4Ms5i0uSMwtzkyHyJ9iVJQS5xUE SQiAJDJK8+B6YQnpFaM40CvCvOogVTzAZAbX/QpoMBPQ4ElneEEGlyQipKQaGPtOrAgIL/in dCC5ecIdxqrXC24xCXSkFl1XzFu39xv/Nvl1e0/2Xb6UYfagss5X5LGi39f8VSePLjfdvYL9 PkfIO93q0g2OCzf+5spfzJrz7Y/Sl2VL3jdv1hdmKEmcOa3g7PmXPhOf+tnMsro6/brVzuxH D5fc7rja+Z3n9u/5WYZO1wVfNJ9UYinOSDTUYi4qTgQAkUxPlCMDAAA= Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-01.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: Fri, 16 Aug 2013 14:36:11 -0000 On 08/16/2013 09:46 AM, Derek Atkins wrote: > The issue was a question of whether it would be subject to the same > timing attacks as Lucky13 used against SSL/TLS. I believe it would not, since it uses encrypt-then-mac. From hotz@jpl.nasa.gov Fri Aug 16 17:31:40 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 65B2E11E8176 for ; Fri, 16 Aug 2013 17:31:40 -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 TSKePz8l6rdD for ; Fri, 16 Aug 2013 17:31:34 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1EB11E8158 for ; Fri, 16 Aug 2013 17:31:34 -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 r7H0VWjE020325 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 16 Aug 2013 17:31:33 -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: Date: Fri, 16 Aug 2013 17:31:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Tom Yu X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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: Sat, 17 Aug 2013 00:31:40 -0000 On Aug 14, 2013, at 8:26 PM, Tom Yu wrote: >> Also why SHA 384 instead of 512? >=20 > I asked Kelley about this, and he said the Suite B mandate was for 128 > bits for lower security, and 192 bits for higher security. That would > imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they > want an unequivocal 192 bits of strength). I don't know why Suite B > doesn't specify AES-192 instead of AES-256 though. Maybe these > rationales should be included in future revisions. There was some post on saag about AES-256 now being only 119-bits = effective strength? I confess I never backtracked the source material. = The problem didn't affect AES-128 and AES-192 much less. ------------------------------------------------------ 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 tlyu@mit.edu Fri Aug 16 21:09:12 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 CBDE011E80FD for ; Fri, 16 Aug 2013 21:09:12 -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 rGpEu2h-rjK6 for ; Fri, 16 Aug 2013 21:09:06 -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 015B111E80F3 for ; Fri, 16 Aug 2013 21:09:05 -0700 (PDT) X-AuditID: 12074422-b7ef78e000000935-92-520ef75beb3c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 6B.88.02357.B57FE025; Sat, 17 Aug 2013 00:08:59 -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 r7H48wBN024163; Sat, 17 Aug 2013 00:08:58 -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 r7H48tpb008978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Aug 2013 00:08:56 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7H48tfY013486; Sat, 17 Aug 2013 00:08:55 -0400 (EDT) To: "Henry B. Hotz" References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> From: Tom Yu Date: Sat, 17 Aug 2013 00:08:54 -0400 In-Reply-To: (Henry B. Hotz's message of "Fri, 16 Aug 2013 17:31:32 -0700") Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0Y3+zhdk0PvT1OJr2wM2i93r1zFZ HN28isXiXzefA4vHkiU/mTwmLt/H4tG64y+7x8qpp9kDWKK4bFJSczLLUov07RK4MuY0f2Yq 6GCvOP5kKWMD4xXWLkZODgkBE4m/b15A2WISF+6tZ+ti5OIQEtjHKPHl4nIWCGcjo8SDA5Og MueYJFbce8cM4XQxSix9s44dpF9EQF3ixuFbYDazQBujxPk+MFtYoFDiw6HNUKP+M0k0TfgE 1M3BwSYgLXF0cRlIDYuAqsS5yQ0sIDanQL3Ekfsv2EBsXgELiU0vdzOD2DwCnBInZ26FigsC 2U9YIHZpSdz495JpAqPgLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluil ppRuYgSHtIvSDsafB5UOMQpwMCrx8FpE8AUJsSaWFVfmHmKU5GBSEuV98x4oxJeUn1KZkVic EV9UmpNafIhRgoNZSYSX9wxQjjclsbIqtSgfJiXNwaIkzvvs6dlAIYH0xJLU7NTUgtQimKwM B4eSBO/Lr0CNgkWp6akVaZk5JQhpJg5OkOE8QMM5v4EMLy5IzC3OTIfIn2LU5fizcu4nRiGW vPy8VClx3r8ggwRAijJK8+DmwFLRK0ZxoLeEeZ+AVPEA0xjcpFdAS5iAlkw6wwuypCQRISXV wBi798DiEEGLy+e0Lws+WMLDkblZTb+16EXMrjnd7JcqJf7fidNSrS0Pm+7FKeH80P/dhtm7 G61dfn7d+6VIMFrp0ZsFnpVOQs8/q328ItkU0J7mHK1/72pPcWLq8RTD6wwBfxMeNvbWKhgc aIlgOx792iHjW+Lj6IsBK9PEN79Z+O6s+JrYdCWW4oxEQy3mouJEAI+H7/ogAwAA Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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: Sat, 17 Aug 2013 04:09:12 -0000 "Henry B. Hotz" writes: > On Aug 14, 2013, at 8:26 PM, Tom Yu wrote: > >>> Also why SHA 384 instead of 512? >> >> I asked Kelley about this, and he said the Suite B mandate was for 128 >> bits for lower security, and 192 bits for higher security. That would >> imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they >> want an unequivocal 192 bits of strength). I don't know why Suite B >> doesn't specify AES-192 instead of AES-256 though. Maybe these >> rationales should be included in future revisions. > > There was some post on saag about AES-256 now being only 119-bits effective strength? I confess I never backtracked the source material. The problem didn't affect AES-128 and AES-192 much less. I'm pretty sure those are related-key attacks, and also affect AES-192. They mostly affect the use of AES as a hash function. From hotz@jpl.nasa.gov Mon Aug 19 11:52:52 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 2E33C11E82BA for ; Mon, 19 Aug 2013 11:52:52 -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 mAq7CZUQJlKk for ; Mon, 19 Aug 2013 11:52:47 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7E60821F9AFE for ; Mon, 19 Aug 2013 11:52:47 -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 r7JIqcXC021459 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 19 Aug 2013 11:52:38 -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: Date: Mon, 19 Aug 2013 11:52:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5674376E76F88641AD3748A64F0996971AAA4F35@TK5EX14MBXC285.redmond.corp.microsoft.com> <5674376E76F88641AD3748A64F0996971AAB7DA1@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Tom Yu X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.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, 19 Aug 2013 18:52:52 -0000 I was unclear. It affected AES-192, just much less. On Aug 16, 2013, at 5:31 PM, "Henry B. Hotz" wrote: >=20 > On Aug 14, 2013, at 8:26 PM, Tom Yu wrote: >=20 >>> Also why SHA 384 instead of 512? >>=20 >> I asked Kelley about this, and he said the Suite B mandate was for = 128 >> bits for lower security, and 192 bits for higher security. That = would >> imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they >> want an unequivocal 192 bits of strength). I don't know why Suite B >> doesn't specify AES-192 instead of AES-256 though. Maybe these >> rationales should be included in future revisions. >=20 > There was some post on saag about AES-256 now being only 119-bits = effective strength? I confess I never backtracked the source material. = The problem didn't affect AES-128 and AES-192 much less. >=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 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten ------------------------------------------------------ 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 hardjono@mit.edu Tue Aug 20 10:36: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 8974611E812E for ; Tue, 20 Aug 2013 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 CmekJV5bC3fx for ; Tue, 20 Aug 2013 10:36:02 -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 97CE111E80E4 for ; Tue, 20 Aug 2013 10:36:02 -0700 (PDT) X-AuditID: 1209190e-b7f988e0000009a7-b8-5213a90171d5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.DB.02471.109A3125; Tue, 20 Aug 2013 13:36:01 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (outgoing-exchange-2.mit.edu [18.7.34.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r7KHa0SY018597; Tue, 20 Aug 2013 13:36:01 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id r7KHZxXE021458; Tue, 20 Aug 2013 13:36:00 -0400 Received: from OC11EXHUB10.exchange.mit.edu (18.9.3.24) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 20 Aug 2013 13:35:56 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.223]) by OC11EXHUB10.exchange.mit.edu ([18.9.3.24]) with mapi id 14.03.0158.001; Tue, 20 Aug 2013 13:35:59 -0400 From: Thomas Hardjono To: "kitten@ietf.org" , "krbdev@mit.edu" Thread-Topic: 2013 Kerberos Interop Event (8-9 October 2013) at MIT Thread-Index: Ac6UYimkt8mP7j+sSwO1GWM9Au/S/AJaRLXQ Date: Tue, 20 Aug 2013 17:35:59 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A2F248834@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.111.22.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsUixG6nosu4UjjI4MUha4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro7uhh7FgO2/Fu/9TmRsYF3F1MXJySAiYSFw+8JEFwhaTuHBv PVsXIxeHkMA+Ronjky+xQDgHGCVud68CqxISuMoocWGNLkRiO6PE+5cfmSGc1YwSHZubmUGq 2AQ0JM793ssOYosIeEn8ubAbzGYWUJPYfKuDFcQWFrCTuLRkHTNEjbNE27ePUPVGEotWd4DZ LAKqEq3H1jKC2LwCQRJzm3+C1TMC3fr91BomiJniEreezGeC+EFQYtHsPcww//zb9ZANwlaQ 6Lq4COoGHYkFuz+xQdjaEssWvmaGmC8ocXLmE5YJjOKzkIydhaRlFpKWWUhaFjCyrGKUTcmt 0s1NzMwpTk3WLU5OzMtLLdI11svNLNFLTSndxAiKLE5Jvh2MXw8qHWIU4GBU4uHdUCgcJMSa WFZcmXuIUZKDSUmU12MpUIgvKT+lMiOxOCO+qDQntfgQowQHs5II77YMoBxvSmJlVWpRPkxK moNFSZz32dOzgUIC6YklqdmpqQWpRTBZGQ4OJQnex8uBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG XwKp4S0uSMwtzkyHyJ9iVJQS510DkhAASWSU5sH1whLfK0ZxoFeEeReAVPEAkyZc9yugwUxA g2drCIEMLklESEk1MNYnh19dq1oUv3qbpeRx9gz3OUEKWdsCnhasvGDowJH35WLt5bzDs94f LI166u3UypKp9iRf9SfDw7+3NNQ2rgsP4FdkN5Vy0JlSye3Oeqwh9Nb2U8kr37kHXBXyyYia N5HfRXXXst/eP+Wdeo2jg0tP7k122rNTojpD1vr6tWKTmsnTs00dlFiKMxINtZiLihMBlfwf JFcDAAA= Subject: [kitten] 2013 Kerberos Interop Event (8-9 October 2013) at MIT 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, 20 Aug 2013 17:36:15 -0000 Folks, The 2013 Kerberos Interoperability & Testing ("Interop") event will be held= at the MIT Campus on 8-9 October 2013. (The Tuesday-Wednesday after the an= nual Conference). https://kit.mit.edu/events Please email Thomas Hardjono or Tom Yu if you plan to attend (hardjono[at]m= it.edu and tlyu[at]mit.edu). No registration is needed (just an email). We = have a basic template doc to capture the features you want to test. 2013 MIT Kerberos Interop Event ------------------------------- https://kit.mit.edu/events/kerberos-interoperability-testing-event Dates: 8-9 October 2013 (Tuesday-Wednesday). Time: 10AM - 5PM Venue: MIT Campus, Building W92 Backbay Rooms A & B. Corner of Vassar & Amesbury Sts. Cambridge, MA 02139. Map: http://whereis.mit.edu/?go=3DW92: Hotels: The hotels near MIT Campus can be expensive, so we have been advising people to find any hotel close to the Red Line T subway line. The MIT campus is located at the Red Line "MIT/Kendall Station". From Kendall Square there is a white MIT Tech Shuttle (free) that goes around campus and which stops at the doorsteps of Building W92. MIT's list of hotels: http://web.mit.edu/institute-events/visitor/stay.html List of stations on the Red Line T subway: http://www.mbta.com/schedules_and_maps/subway/lines/?route=3DRED Regards. /thomas/ ____________________________________________ Thomas Hardjono MIT Consortium for Kerberos & Internet Trust e: hardjono[at]mit.edu m: +1 781 729 9559 w: kit.mit.edu ____________________________________________ From hartmans@mit.edu Wed Aug 28 07:48: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 B5DEA11E811F for ; Wed, 28 Aug 2013 07:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 HMfr-o1hKTw4 for ; Wed, 28 Aug 2013 07:48:00 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 369EF21F9C87 for ; Wed, 28 Aug 2013 07:47:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 01CBA202E9; Wed, 28 Aug 2013 10:43:11 -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 o0zFHmv2qJ5y; Wed, 28 Aug 2013 10:43:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 28 Aug 2013 10:43:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B2A1F87FEE; Wed, 28 Aug 2013 10:47:53 -0400 (EDT) From: Sam Hartman To: Mayank Upadhyay References: Date: Wed, 28 Aug 2013 10:47:53 -0400 In-Reply-To: (Mayank Upadhyay's message of "Thu, 18 Jul 2013 22:34:04 -0700") 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, OpenJDK , Jeffrey Hutzelman Subject: Re: [kitten] Fwd: Kitten Digest, Vol 104, Issue 14 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, 28 Aug 2013 14:48:11 -0000 >>>>> "Mayank" == Mayank Upadhyay writes: Mayank> Hi Weijun, You point out a legitimate problem, but I want Mayank> to understand a couple of assumptions: 1. Why allow only Mayank> initSecContext() and acceptSecContext() to have this new Mayank> behavior? Imagine a mechanism built on top of TLS which is Mayank> renegotiating the session intermixed with actual payload, Mayank> and had some error it wanted to communicate to the peer Mayank> (e.g., a TLS Alert). Is there any particular reason you'd Mayank> like to avoid that scenario? 2. I didn't quite follow the Hi. RFC 2743 doesn't allow the abstract wrap or getmic apis to generate an error token. I'd object to adding that behavior to the java bindings without adding it to the abstract API. So, for the current abstract API, only initSecContext and acceptSecContext can have this issue. From matt@linuxbox.com Wed Aug 28 12:32:05 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 C3FBB11E81BB for ; Wed, 28 Aug 2013 12:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 wlsL-UgrGEUS for ; Wed, 28 Aug 2013 12:32:01 -0700 (PDT) Received: from aa.linuxbox.com (aa.linuxbox.com [69.128.83.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4B25B11E81A8 for ; Wed, 28 Aug 2013 12:32: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 r7SJVw3O012161 for ; Wed, 28 Aug 2013 15:31:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id B844A3FC8497 for ; Wed, 28 Aug 2013 15:31:58 -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 KTkkX9EWYLvb for ; Wed, 28 Aug 2013 15:31:57 -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 782F23FC848B for ; Wed, 28 Aug 2013 15:31:57 -0400 (EDT) Date: Wed, 28 Aug 2013 15:31:57 -0400 (EDT) From: "Matt W. Benjamin" To: kitten@ietf.org Message-ID: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.213] 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]); Wed, 28 Aug 2013 15:31:59 -0400 (EDT) Subject: [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: Wed, 28 Aug 2013 19:32:05 -0000 Hi, Apologies in advance if I'm sending to the wrong list. This seemed like the right place to reach the appropriate folks. I'm interested in making use of the iov interfaces now provided in the MIT and Heimdal GSSAPIs. The client code is implementing RPCSEC_GSS. >From what I can make out, the gss_wrap_iov calls provide the acceptable behavior for my intended replacement of gss_wrap, but there don't seem to be equivalent/finished/exposed iov implementations of gss_getmic. Naturally, I have basically the same input buffer requirements in producing checksums as for wrapped data. Suggestions? Matt -- 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 lukeh@padl.com Wed Aug 28 15:04: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 9F98421E8056 for ; Wed, 28 Aug 2013 15:04:03 -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 ztJvoLeHIrlk for ; Wed, 28 Aug 2013 15:03:41 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7773B21F93C4 for ; Wed, 28 Aug 2013 15:03:37 -0700 (PDT) Received: by us.padl.com with ESMTP id r7SM3HDe015583; Wed, 28 Aug 2013 18:03:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luke Howard In-Reply-To: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> Date: Thu, 29 Aug 2013 08:03:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5374C814-C119-473F-83E4-254AA067C7A2@padl.com> References: <1312896365.241.1377718317287.JavaMail.root@thunderbeast.private.linuxbox.com> To: "Matt W. Benjamin" 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: Wed, 28 Aug 2013 22:04:04 -0000 Unfortunately this interface doesn't exist. I suppose it could be hacked on (obviously the implementation would need = to be upgraded) without introducing a new API, by adding a flag to the = trailer buffer (e.g. GSS_IOV_BUFFER_FLAG_MIC_TOKEN). But maybe a new API = would be cleaner. -- Luke On 29/08/2013, at 5:31 AM, Matt W. Benjamin wrote: > Hi, >=20 > Apologies in advance if I'm sending to the wrong list. This seemed = like the right place to reach > the appropriate folks. >=20 > I'm interested in making use of the iov interfaces now provided in the = MIT and Heimdal GSSAPIs. > The client code is implementing RPCSEC_GSS. >=20 > =46rom what I can make out, the gss_wrap_iov calls provide the = acceptable behavior for my intended replacement of > gss_wrap, but there don't seem to be equivalent/finished/exposed iov = implementations of gss_getmic. Naturally, I > have basically the same input buffer requirements in producing = checksums as for wrapped data. >=20 > Suggestions? >=20 > Matt >=20 > --=20 > Matt Benjamin > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 >=20 > http://linuxbox.com >=20 > tel. 734-761-4689=20 > fax. 734-769-8938=20 > cel. 734-216-5309=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From will.fiveash@oracle.com Thu Aug 29 13:18:53 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 872EA21E804D for ; Thu, 29 Aug 2013 13:18:53 -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, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 uZCiAQoLVdpx for ; Thu, 29 Aug 2013 13:18:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DC46111E8167 for ; Thu, 29 Aug 2013 13:18:46 -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 r7TKIahr003291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Aug 2013 20:18:36 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TKIZsc007653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Aug 2013 20:18:35 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TKIYnY008854 for ; Thu, 29 Aug 2013 20:18:35 GMT Received: from oracle.com (/10.135.188.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 13:18:34 -0700 Date: Thu, 29 Aug 2013 15:18:33 -0500 From: Will Fiveash To: kitten@ietf.org Message-ID: <20130829201833.GA19539@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21+155,mq+5 (f795b1d555d7) (2012-12-30) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [kitten] FYI: working draft 02 of the PKCS#11 API v2.40 describes CKM_AES_CTS mech 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, 29 Aug 2013 20:18:53 -0000 It was brought to my attention that in working draft 02 of the PKCS#11 API spec v2.40 there is a description of a AES CBC with Cipher Text Stealing (CTS) mechanism (CKM_AES_CTS). Certainly this could be useful to those implementations of Kerberos that use PKCS#11 for its crypto backend. Note, I have not participated in the discussions related to this new version of PKCS#11 so I can not say anything else about it. -- Will Fiveash Oracle Solaris Software Engineer From ghudson@mit.edu Sat Aug 31 10:48:49 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 341FC21E80A5 for ; Sat, 31 Aug 2013 10:48:48 -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 6ajNzTSufiWa for ; Sat, 31 Aug 2013 10:48:41 -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 7126121E80CB for ; Sat, 31 Aug 2013 10:48:41 -0700 (PDT) X-AuditID: 12074423-b7f168e00000095a-2d-52222c780922 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B5.24.02394.87C22225; Sat, 31 Aug 2013 13:48:40 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r7VHmegs023777 for ; Sat, 31 Aug 2013 13:48:40 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7VHmcHp008120 for ; Sat, 31 Aug 2013 13:48:40 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sat, 31 Aug 2013 13:48:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUixCmqrFuhoxRkcPqvqcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfXadfaCTQIVuxZdZWxgnM/bxcjJISFgIrHu6RoWCFtM4sK9 9WxdjFwcQgL7GCUmfVnMCOEcZ5Q4d3w5M4TTwSTRtu8YG0gLm4CyxMGz38DaRQSEJXZvfccM YgsLWEpsufcdzGYRUJU4vOItmM0rYCjR+aCZBcIWlDg58wmYzSygJXHj30umCYw8s5CkZiFJ LWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrppebWaKXmlK6iREUHuwuyjsY/xxUOsQowMGo xMObsFQhSIg1say4MvcQoyQHk5IoL5e2UpAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7TKxWD hHhTEiurUovyYVLSHCxK4rzPnp4NFBJITyxJzU5NLUgtgsnKcHAoSfAmgAwVLEpNT61Iy8wp QUgzcXCCDOcBGp4IUsNbXJCYW5yZDpE/xajL8Wfl3E+MQix5+XmpUuK8NiBFAiBFGaV5cHNg cf2KURzoLWFePZAqHmBKgJv0CmgJE9CSaxNBPiguSURISTUwzjjGYhLnsK9W95F8Zfz0rwVs hxh6zh2KzN5x/d5uVctVL11YWg7dvvl03fJHGgy6YUXveJKT5edfNdaOqLuy/XiG/8rZoRs/ C76bf3XR8Wlal1JU8meZbQm+UFk85+rtRyVW21cvsAxe//VPwrSaaEb/FtPovXf8M1zCI07y u/4WZVTfH7KwWomlOCPRUIu5qDgRALKyRA3GAgAA Subject: [kitten] FAST option interop bug in MIT krb5 1.7-1.11 KDC 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, 31 Aug 2013 17:48:49 -0000 We have discovered a bug in the MIT krb5 KDC's handling of FastOption values in KDC requests. RFC 6113 specifies that bits 1-15 are critical, meaning that the KDC will deny the request if an unsupported bit is set. But the mask we used to detect those bits was defined as 0x00ff, which corresponds to the eight bits 24-31 in our representation of ASN.1 flag values. To complicate matters, Heimdal clients unconditionally send the hide-client-names option (bit 1, which is critical). We don't yet implement this option, and right now we are incorrectly ignoring it. If we simply fix our mask, our KDC would stop interoperating with Heimdal clients, which is arguably worse than failing to hide the client name. For our 1.12 release, we will be implementing hide-client-names and fixing our mask. (I have written and tested the code, but haven't yet pushed it to master.) We haven't yet decided what backports to make for previous releases because there is a new feature involved. Whatever we do, there are likely to be a substantial number of KDCs in the field with incorrect FAST option recognition for some time to come. Future specifications should consider that: * Option bits 1-15 will be correctly considered critical by some implementations (Heimdal and MIT 1.12+, and presumably AD) but not by all. * Option bits 16-23 will be correctly considered non-critical by all implementations. * Option bits 24-31 will be erroneously considered critical by some implementations (MIT 1.7-1.11). If there are ever any specifications containing new non-critical FAST options, they should start with bit 16 and go forward, rather than starting at bit 31 and going backwards. If there are ever any specifications containing new critical FAST options, the first one should consider requiring that clients also set bit 31, which would be chewed up as a "make MIT 1.7-1.11 fail" measure. Bit 31 could be re-used for this purpose for all new critical FAST options; we wouldn't have to use a different bit in the 24-31 range for each new option.