From nobody Tue Jul 1 11:33:33 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A091B285C for ; Tue, 1 Jul 2014 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVpKMeoikUEo for ; Tue, 1 Jul 2014 11:33:28 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD851A02D9 for ; Tue, 1 Jul 2014 11:33:28 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-f5-53b2fef768e2 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 51.3A.32177.7FEF2B35; Tue, 1 Jul 2014 14:33:27 -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 s61IXQxr019898 for ; Tue, 1 Jul 2014 14:33:27 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s61IXPl5006633 for ; Tue, 1 Jul 2014 14:33:26 -0400 From: Tom Yu To: References: <20140630194645.30577.48140.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 14:33:25 -0400 In-Reply-To: <20140630194645.30577.48140.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 30 Jun 2014 12:46:45 -0700") Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixG6nrvv936Zgg4NvRCyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOdNm5gLtjNVLLw/i6WB8S1jFyMnh4SAicTJB5PYIWwxiQv3 1rN1MXJxCAnMZpL4++0UM4RzjFHix4qdTBBOI5PE6Z+tQC0cHGwC0hJHF5eBdIsIiErM3vKK BcQWFrCQeHDhHpgtJOAo8XDLJFYQm0VAVWLOlAtgQzkFJjBKLJm0DOwMXgFdiWXLvoMV8Qhw Sizt28oEEReUODnzCdggZgEtiRv/XjJNYOSfhSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTE vLzUIl1jvdzMEr3UlNJNjKAw45Tk28H49aDSIUYBDkYlHl6G25uChVgTy4orcw8xSnIwKYny uvwECvEl5adUZiQWZ8QXleakFh9ilOBgVhLhbTgPlONNSaysSi3Kh0lJc7AoifO+tbYKFhJI TyxJzU5NLUgtgsnKcHAoSfA++gvUKFiUmp5akZaZU4KQZuLgBBnOAzT8M0gNb3FBYm5xZjpE /hSjopQ47xqQhABIIqM0D64XlgZeMYoDvSLMKw1MCkI8wBQC1/0KaDAT0OCvqzaADC5JREhJ NTD2NTo3dd+TD+RedePeI2v7qBfdSSmRLgYqeR21vidmPZR/u/rbnbmXk0z33lovdzt2q0Hg 7evi15en/lI8w6e9TiK6+WL1Q3/BOg9+7ke2LjVH/n06t82z/vVrqTrreeGm3J67Xv6weqy6 Wn/G21rpyZOLdVx5n1fyprFs1TM3fSS52q5i4i0lluKMREMt5qLiRABTOoNy3gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7wo8RLhD41L0oc60uw_Hc_mVrKw Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:33:30 -0000 Changes in this version: * Make minor editorial changes * Assign numbers - ad-type number 96 - key usage number 64 * Delete "Open Issues" section I think this is ready for WGLC. I believe the number assignments are free of conflicts, but please let me know if you think otherwise. Thanks. From nobody Wed Jul 2 08:43:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655311B2975; Wed, 2 Jul 2014 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aRJ_sEVAkfX; Wed, 2 Jul 2014 08:43:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1473A1B294F; Wed, 2 Jul 2014 08:43:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702154337.23812.83936.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 08:43:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8XUL-YUOdqGXsVcXpcNIoz8njm8 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:43:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-03.txt Pages : 15 Date : 2014-07-02 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 10:43:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA191B2981 for ; Thu, 3 Jul 2014 10:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmKlHRiUliJO for ; Thu, 3 Jul 2014 10:43:08 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D051A023E for ; Thu, 3 Jul 2014 10:43:08 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-ef-53b5962b1333 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BF.C9.12039.B2695B35; Thu, 3 Jul 2014 13:43:07 -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 s63Hh6ag018112; Thu, 3 Jul 2014 13:43:07 -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 s63Hh4bn006224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jul 2014 13:43:06 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s63Hh4Wo020089; Thu, 3 Jul 2014 13:43:04 -0400 (EDT) Date: Thu, 3 Jul 2014 13:43:04 -0400 (EDT) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: <53B192F2.2060707@oracle.com> Message-ID: References: <53B192F2.2060707@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrqs9bWuwwadfyhZHN69iseh7fYjd gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mq49uswa8El5orv8x+wNjA2MXcxcnJICJhI PHi2gwnCFpO4cG89WxcjF4eQwGwmiRdTlzFDOBsYJU5PO8IC4RxkkmiafJkNpEVIoF7i9swf YDaLgJbE1Z9nwGw2ARWJmW82gtkiQPEbDR1gK5gF1CW+nXnDCGILC+hIfL10hL2LkYODE6jm 9UtLkDCvgKPEjmXPWSDGa0oceXsIrFwUqHz1/iksEDWCEidnPmGBGGkp8W/tL9YJjIKzkKRm IUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGukl5tZopeaUrqJERSonJK8OxjfHVQ6xCjA wajEw7ugZGuwEGtiWXFl7iFGSQ4mJVFe3klAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8Tu1A Od6UxMqq1KJ8mJQ0B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwMB4eSBK/JVKBGwaLU9NSKtMyc EoQ0EwcnyHAeoOGhIDW8xQWJucWZ6RD5U4yKUuK8r6cAJQRAEhmleXC9sETyilEc6BVhXjOQ dh5gEoLrfgU0mAloMBsT2OCSRISUVAOjjomnccfqdyu6Y+O+tBvpVxqeWTJbqnnzKfeps42e PJz7YdqSostV6Z7Gp+4EuZq9X8C00GaHGtfnUM+EO3HVkq+K14VNeqGipPyAY5Ysz44fkVMW yneaupwKq52xncfxnIWku9nemgRGWbY7JdVrzye4sl9bwB95/uGp52FaHsuazs1fVzJbiaU4 I9FQi7moOBEAbSUVs/8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CMtdjImFJYRndP2fiGlqYAF1mss Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 90 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:43:10 -0000 On Mon, 30 Jun 2014, Shawn M Emery wrote: > > Please provide any additions or updates to the draft agenda posted here: > > http://www.ietf.org/proceedings/90/agenda/agenda-90-kitten It looks like the active documents draft-ietf-kitten-gss-loop and draft-ietf-kitten-sasl-oauth, and the recently-expired draft-ietf-kitten-channel-bound-flag are not on the agenda. Is that just because we don't think there's anything to talk about for them? -Ben From nobody Thu Jul 3 22:05:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538481B2BE1 for ; Thu, 3 Jul 2014 22:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4qf7vfELRcw for ; Thu, 3 Jul 2014 22:04:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4411B2BDB for ; Thu, 3 Jul 2014 22:04:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6454sI3026901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jul 2014 05:04:54 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6454rKr002706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2014 05:04:53 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6454qli022268; Fri, 4 Jul 2014 05:04:52 GMT Received: from [10.159.78.127] (/10.159.78.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Jul 2014 22:04:52 -0700 Message-ID: <53B63606.8090107@oracle.com> Date: Thu, 03 Jul 2014 23:05:10 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: Benjamin Kaduk References: <53B192F2.2060707@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fQB-lbj3rOo0w5-vY1Z6MrfMiWE Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 90 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 05:04:57 -0000 On 07/ 3/14 11:43 AM, Benjamin Kaduk wrote: > On Mon, 30 Jun 2014, Shawn M Emery wrote: > >> >> Please provide any additions or updates to the draft agenda posted here: >> >> http://www.ietf.org/proceedings/90/agenda/agenda-90-kitten > > It looks like the active documents draft-ietf-kitten-gss-loop I've placed this on the agenda. Do you have status that I can incorporate into the slides? > and draft-ietf-kitten-sasl-oauth This is already on the agenda under OAuth Mech, but it had referenced the wrong draft. Corrected now. > and the recently-expired draft-ietf-kitten-channel-bound-flag are not > on the agenda. There hasn't been any activity on this draft since the last session. From what I remember there are some outstanding changes that are needed before progressing. > Is that just because we don't think there's anything to talk about for > them? Thanks for catching the typo and the exclusion of gss-loop. The agenda has been updated and uploaded to its usual location: http://www.ietf.org/proceedings/90/agenda/agenda-90-kitten Shawn. -- From nobody Sat Jul 5 12:24:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E61B27CC for ; Sat, 5 Jul 2014 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh8ePhzffXdO for ; Sat, 5 Jul 2014 12:24:03 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C481B27CB for ; Sat, 5 Jul 2014 12:24:02 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-f0-53b850d02691 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 21.54.30080.0D058B35; Sat, 5 Jul 2014 15:24:01 -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 s65JO0Kb000498; Sat, 5 Jul 2014 15:24:00 -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 s65JNwl9021306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Jul 2014 15:23:59 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s65JNvW8002505; Sat, 5 Jul 2014 15:23:57 -0400 (EDT) Date: Sat, 5 Jul 2014 15:23:57 -0400 (EDT) From: Benjamin Kaduk To: Shawn M Emery In-Reply-To: <53B63606.8090107@oracle.com> Message-ID: References: <53B192F2.2060707@oracle.com> <53B63606.8090107@oracle.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+NgFnrNIsWRmVeSWpSXmKPExsUixG6nonsxYEewwaWZjBZHN69iseh7fYjd gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4MrYd/QGc8F6zorOM4kNjBvYuxg5OSQETCQW PupkhbDFJC7cW88GYgsJzGaS6D1T08XIBWRvYJRonLeYHcI5yCQx895kZoiqeokDdz8zgdgs AloSE5a8B5vKJqAiMfPNRrBJIkDxGw0dYDXMAuoS3868YQSxhQV0JL5eOgJWzwlU8/rTLbCZ vAKOEsv69kBdUSvx5Gk3WK8oUP3q/VNYIGoEJU7OfMICMdNS4tyf62wTGAVnIUnNQpJawMi0 ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdMLzezRC81pXQTIzhMXZR3MP45qHSIUYCDUYmHt/LE tmAh1sSy4srcQ4ySHExKorzbLHcEC/El5adUZiQWZ8QXleakFh9ilOBgVhLhtTQDyvGmJFZW pRblw6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHjv+AM1ChalpqdWpGXmlCCkmTg4 QYbzAA2fDVLDW1yQmFucmQ6RP8WoKCXOuxYkIQCSyCjNg+uFpZFXjOJArwjzPgap4gGmILju V0CDmYAGszFtBRlckoiQkmpgzDRkn6/1r1RC5GzBjanTjl0smJd2y0EyV4zxz4JNXdO3fJv+ 7viJDot1GvMbn9xx+LiOda6GzN3zW49xn05imlw6waz29qrvZ69N2nD4/eqi0qTIndOXrPl1 O8X8tuHMuZEvd6398IpP+8INi3JPqdfMb9zmSckxtr71jtoofiFgc07xN7tN2+uVWIozEg21 mIuKEwF3Iwk2/gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Sv9yt9E9jWNcLoQMNUnTXpvGFf4 Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 90 - Draft Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:24:04 -0000 On Fri, 4 Jul 2014, Shawn M Emery wrote: > On 07/ 3/14 11:43 AM, Benjamin Kaduk wrote: >> On Mon, 30 Jun 2014, Shawn M Emery wrote: >> >>> >>> Please provide any additions or updates to the draft agenda posted here: >>> >>> http://www.ietf.org/proceedings/90/agenda/agenda-90-kitten >> >> It looks like the active documents draft-ietf-kitten-gss-loop > > I've placed this on the agenda. Do you have status that I can incorporate > into the slides? I think I'm happy with the current text; the main changes in the current version are updates to the sample code. I don't know that anyone other than me has looked at the new code particularly closely, though. I guess such review could occur just as easily during a WGLC as prior to one. I don't think we have any known outstanding issues that would block a WGLC. >> and the recently-expired draft-ietf-kitten-channel-bound-flag are not on >> the agenda. > > There hasn't been any activity on this draft since the last session. From > what I remember there are some outstanding changes that are needed before > progressing. I guess Nico just hasn't had any time to spend on it, then. Thanks, Ben From nobody Sat Jul 5 18:37:39 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F161A0107 for ; Sat, 5 Jul 2014 18:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU5o32aReues for ; Sat, 5 Jul 2014 18:37:35 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BFD1A00D8 for ; Sat, 5 Jul 2014 18:37:34 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-5d-53b8a85d7674 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 73.33.32177.D58A8B35; Sat, 5 Jul 2014 21:37:33 -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 s661bW1Q022340; Sat, 5 Jul 2014 21:37:33 -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 s661bUkX012555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Jul 2014 21:37:32 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s661bURW019029; Sat, 5 Jul 2014 21:37:30 -0400 (EDT) Date: Sat, 5 Jul 2014 21:37:30 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <20140630194645.30577.48140.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+NgFnrEIsWRmVeSWpSXmKPExsUixG6nohu7YkewQVevocXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseH8VqaCV8wVDW8usTQwfmbqYuTkkBAwkbiz7jCULSZx4d56 ti5GLg4hgdlMEht3TmSFcDYwSqz7fAMqc5BJYsXmu+wgLUIC9RLz7/SDtbMIaEkcmXOGBcRm E1CRmPlmIxuILSIgKXHsyXlmEJtZQFhi/bkZYLawgKPEmblzwHo5BfQkfmx7wghi8wLFl+// AlTDATQ/WeLmkSyQsKiAjsTq/VNYIEoEJU7OfMICMdJS4tyf62wTGAVnIUnNQpJawMi0ilE2 JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81pXQTIygoOSX5djB+Pah0iFGAg1GJhzehdEew EGtiWXFl7iFGSQ4mJVHeHfOAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4fy4DyvGmJFZWpRbl w6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHh9lwM1ChalpqdWpGXmlCCkmTg4QYbz AA3fBja8uCAxtzgzHSJ/ilFRSpz3FUhCACSRUZoH1wtLGq8YxYFeEea9CFLFA0w4cN2vgAYz AQ1mY9oKMrgkESEl1cDYdTX+1fzZJ5/XM/EW7NI9IuJbeMvzjFzNryqd3jOndf1fOjHdCdua Od3V7lBr+bfQwmbtwuAPjtov2PPYWv5+epB2YOGht9emSORosxnln3ubmDIv8k6j4J5jQi9W vlm2OnrXArNVFefTnryVZV94ehPrs8jSL1dSmKvqEsM5Dy0tTaj+XvxXiaU4I9FQi7moOBEA 1k+lUfUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/XzoTpGwEsBl5B87GiD_esXe5yD4 Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 01:37:36 -0000 On Tue, 1 Jul 2014, Tom Yu wrote: > Changes in this version: > > * Make minor editorial changes > > * Assign numbers > - ad-type number 96 > - key usage number 64 > > * Delete "Open Issues" section > > I think this is ready for WGLC. I believe the number assignments are > free of conflicts, but please let me know if you think otherwise. I did not attempt to review the number assignments for conflicts, but I am happy with the document after these changes. -Ben From nobody Sat Jul 5 18:40:45 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2541A1A0107 for ; Sat, 5 Jul 2014 18:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb8C6wRMRvWT for ; Sat, 5 Jul 2014 18:40:42 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFBA1A0109 for ; Sat, 5 Jul 2014 18:40:42 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-09-53b8a9194095 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 4B.1E.24022.919A8B35; Sat, 5 Jul 2014 21:40: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 s661eevg005535 for ; Sat, 5 Jul 2014 21:40:41 -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 s661edZP013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 5 Jul 2014 21:40:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s661eciE019452; Sat, 5 Jul 2014 21:40:38 -0400 (EDT) Date: Sat, 5 Jul 2014 21:40:38 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20140702154337.23812.83936.idtracker@ietfa.amsl.com> Message-ID: References: <20140702154337.23812.83936.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+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrCu5ckewwanN/BZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq3+zawFC7grVh45z9rAuIuji5GTQ0LARGLCkZVsELaYxIV7 64FsLg4hgdlMEhN2z2OGcI4xSuz+/44dwrnOJHGr7TlYi5BAvUTLpVfsIDaLgJZE0+mXrCA2 m4CKxMw3G8FqRASEJXZvfccMYgsL+Em0rToOZnMKOEl8fHsYrJ5XwFHi2stpLBAzHSVOH9sF NlNUQEdi9f4pLBA1ghInZz4Bs5kFLCXO/bnONoFRYBaS1CwkqQWMTKsYZVNyq3RzEzNzilOT dYuTE/PyUot0DfVyM0v0UlNKNzGCw0+SZwfjm4NKhxgFOBiVeHgTSncEC7EmlhVX5h5ilORg UhLl3TEPKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE9+cyoBxvSmJlVWpRPkxKmoNFSZz3rbVV sJBAemJJanZqakFqEUxWhoNDSYL3wHKgRsGi1PTUirTMnBKENBMHJ8hwHqDhK0BqeIsLEnOL M9Mh8qcYFaXEeV+BbBUASWSU5sH1wtLDK0ZxoFeEeXeBtPMAUwtc9yugwUxAg9mYtoIMLklE SEk1MK6XmzBbV/jtkjlPllavqy1ac2z7IjYdsbsRJ2qWP50pm9actWox5z09l4MfaiZ8Uqt7 q+WgEMBzRfWxc/ShpRPbT/9bIF66w/x4zFTBI3fZDndJbre9pKPkvL+uVqj1gtw87Q+5LwPr Yx9Fbfm9c84bexML/aaZL+Y6n7i+1/qC59xYdeO9yfVKLMUZiYZazEXFiQCm1XSO6gIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/c69lfQedwn7I8G7srMizQMntfZw Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 01:40:44 -0000 On Wed, 2 Jul 2014, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > Authors : Michael J. Jenkins > Michael A. Peck > Kelley W. Burgin > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-03.txt > Pages : 15 > Date : 2014-07-02 > > 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-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-03 The text changes look good to me; thanks. I would still like to have pseudo-random test vectors (though I do not think I will insist on it). I may try to find time to generate some. -Ben From nobody Mon Jul 7 07:04:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549071A011C for ; Mon, 7 Jul 2014 07:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGpvTLUOc4Br for ; Mon, 7 Jul 2014 07:03:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 935A51A0120 for ; Mon, 7 Jul 2014 07:03:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F3E241F0267; Mon, 7 Jul 2014 10:03:58 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D0A661F00EA; Mon, 7 Jul 2014 10:03:58 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.226]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 10:03:58 -0400 From: "Peck, Michael A" To: Benjamin Kaduk , "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt Thread-Index: AQHPlgxyGHeCy5BqJE6NR5iOV7LZfJuSjYgAgAIfAYA= Date: Mon, 7 Jul 2014 14:03:57 +0000 Message-ID: References: <20140702154337.23812.83936.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.31.33.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <99349540A195794B94B4E5B8613989A4@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1xSg-G_xKsomYC5iaiGjbV62Yzk Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 14:04:02 -0000 Ben, Thanks for reviewing the changes. I put together test vectors this morning for deriving Kp from the base-key and for the pseudo-random function invocations. I can add the following text to Appendix A (Test Vectors) once Internet-Draft submission reopens. If you'd like to verify these I certainly wouldn't mind. Sample results for key derivation: ---------------------------------- enctype aes128-cts-hmac-sha256-128: 128-bit base-key: 37 05 D9 60 80 C1 77 28 A0 E8 00 EA B6 E0 D2 3C Kc value for key usage 2 (constant =3D 0x0000000299): B3 1A 01 8A 48 F5 47 76 F4 03 E9 A3 96 32 5D C3 Ke value for key usage 2 (constant =3D 0x00000002AA): 9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E Ki value for key usage 2 (constant =3D 0x0000000255): 9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C Kp value (constant =3D 0x707266): 9C 66 77 98 08 4F 16 82 1E 77 15 DD 5A A6 EB 71 enctype aes256-cts-hmac-sha384-192: 256-bit base-key: 6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98 00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52 Kc value for key usage 2 (constant =3D 0x0000000299): EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4 BA 41 F2 8F AF 69 E7 3D Ke value for key usage 2 (constant =3D 0x00000002AA): 56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 A5 EB 1C 82 51 60 C3 83 12 98 0C 44 2E 5C 7E 49 Ki value for key usage 2 (constant =3D 0x0000000255): 69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 22 C4 D0 0F FC 23 ED 1F Kp value (constant =3D 0x707266): 5D 63 0D B7 EF DE 37 DE 9C 92 03 C5 2B D9 6C 77 31 BE 1C 5B DD 50 DC 75 44 D9 60 AF F3 CC 23 04 Sample pseudo-random function (PRF) invocations: ----------------------------------------- PRF input octet-string: "test" (0x74657374) enctype aes128-cts-hmac-sha256-128: Kp value: 9C 66 77 98 08 4F 16 82 1E 77 15 DD 5A A6 EB 71 PRF output: 3A CA 18 6C C1 26 56 76 5C FE B1 D2 2D 1C B1 36 enctype aes256-cts-hmac-sha384-192: Kp value: 5D 63 0D B7 EF DE 37 DE 9C 92 03 C5 2B D9 6C 77 31 BE 1C 5B DD 50 DC 75 44 D9 60 AF F3 CC 23 04 PRF output: 01 72 03 F2 90 CD 16 6C D6 B2 BB 4F 18 7D 16 23 6B 9A 4E D7 66 19 D8 11 6C 64 06 A3 37 E7 F9 08 On 7/5/14, 9:40 PM, "Benjamin Kaduk" wrote: >On Wed, 2 Jul 2014, internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Common Authentication Technology Next >>Generation Working Group of the IETF. >> >> Title : AES Encryption with HMAC-SHA2 for Kerberos 5 >> Authors : Michael J. Jenkins >> Michael A. Peck >> Kelley W. Burgin >> Filename : draft-ietf-kitten-aes-cts-hmac-sha2-03.txt >> Pages : 15 >> Date : 2014-07-02 >> >> 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-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-aes-cts-hmac-sha2-0= 3 > >The text changes look good to me; thanks. > >I would still like to have pseudo-random test vectors (though I do not >think I will insist on it). I may try to find time to generate some. > >-Ben > >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Jul 7 22:36:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76C71B2A44 for ; Mon, 7 Jul 2014 22:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mk9EUGg2s4G for ; Mon, 7 Jul 2014 22:36:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939201B2A3F for ; Mon, 7 Jul 2014 22:36:10 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s685a9pg008635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Jul 2014 05:36:10 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s685a9gF005830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Jul 2014 05:36:09 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s685a7nb023840 for ; Tue, 8 Jul 2014 05:36:07 GMT Received: from [10.159.97.89] (/10.159.97.89) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Jul 2014 22:36:07 -0700 Message-ID: <53BB8362.3010605@oracle.com> Date: Mon, 07 Jul 2014 23:36:34 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <53799133.70201@oracle.com> In-Reply-To: <53799133.70201@oracle.com> X-Forwarded-Message-Id: <53799133.70201@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OglBoOMRyBjTGwhPJDY7o9AG1aE Subject: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:36:11 -0000 This message officially starts the kitten Working Group Last Call for the following document: Kerberos Authorization Data Container Authenticated by Multiple MACs http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-08 The Working Group Last Call for this document starts today, on Monday, 7th of July and will end on Monday, 21st of July. Please send any comments to the kitten mailing list or directly to the chairs. Even if you reviewed this document and found no issues then please provide this feed-back. Thank you, Shawn Emery kitten co-chair -- From nobody Tue Jul 8 00:59:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4470B1A0B09 for ; Tue, 8 Jul 2014 00:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBVoMqc8gIu4 for ; Tue, 8 Jul 2014 00:59:39 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id AACF51A0B07 for ; Tue, 8 Jul 2014 00:59:39 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 08 Jul 2014 00:59:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,624,1400050800"; d="scan'208";a="566587645" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by fmsmga002.fm.intel.com with ESMTP; 08 Jul 2014 00:59:05 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 00:59:05 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 00:59:05 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.122]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 15:58:58 +0800 From: "Zheng, Kai" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Thread-Index: AQHPmm6RUB80BlquYEiOnctz7pGb45uVyPnA Date: Tue, 8 Jul 2014 07:58:58 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FB2BB@SHSMSX103.ccr.corp.intel.com> References: <53799133.70201@oracle.com> <53BB8362.3010605@oracle.com> In-Reply-To: <53BB8362.3010605@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/H2Hno9zqry1skDaPl5xbUF_2uF0 Subject: Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 07:59:41 -0000 Could I post a minor comment? I'm just a beginning learner so apologize if = I'm doing bad here and please kindly point me elsewhere, thanks.=20 Regarding the following: =3D=3D=3D However, protocol extensions such as Constrained Delegation (S4U2Proxy [MS-SFU]) require that a service present to the KDC a service ticket that the service received from a client, as evidence that the client authenticated to the service. In the S4U2Proxy extension, the KDC uses the evidence ticket as the basis for issuing a derivative ticket that the service can then use to impersonate the client. =3D=3D=3D Looks like the issue this draft targets to address mainly comes from MS-S4U= 2Proxy. As said in the MS-S4U doc, the S4U extension is intended to be used when the user authenticates to the service in some way other than b= y using Kerberos. And in the S4U2Proxy flow, service 1 requests a service ticket to service 2 on behalf of the named user using a forwardab= le service ticket (or evidence ticket mentioned here). This forwardable=20 service ticket might have been obtained by a KRB_AP_REQ and come from the u= ser client (the case mentioned here), or by an S4U2self request (ignored=20 here). IMHO, it might be better to rephrase the following sentence to make = it more accurate. =3D=3D=3D ... require that a service present to the KDC a service ticket that the ser= vice received from a client =3D=3D=3D Regards, Kai -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Shawn M Emery Sent: Tuesday, July 08, 2014 1:37 PM To: kitten@ietf.org Subject: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 This message officially starts the kitten Working Group Last Call for the f= ollowing document: =20 Kerberos Authorization Data Container Authenticated by Multiple MACs http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-08 The Working Group Last Call for this document starts today, on Monday, 7th = of July and will end on Monday, 21st of July. Please send any comments to the kitten mailing list or directly to the chai= rs. Even if you reviewed this document and found no issues then please pro= vide this feed-back. Thank you, Shawn Emery kitten co-chair -- _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nobody Tue Jul 8 05:10:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A221A03B0 for ; Tue, 8 Jul 2014 05:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhgh5eYcBdao for ; Tue, 8 Jul 2014 05:10:36 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7A11B2AC9 for ; Tue, 8 Jul 2014 05:10:36 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 08 Jul 2014 05:10:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="566691484" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by fmsmga002.fm.intel.com with ESMTP; 08 Jul 2014 05:10:09 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 05:10:08 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 05:10:09 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.122]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 20:10:00 +0800 From: "Zheng, Kai" To: Simo Sorce Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAACyy6gADKjG2g///1jYD/3rPSIA== Date: Tue, 8 Jul 2014 12:10:00 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> <1403009009.22737.129.camel@willson.usersys.redhat.com> In-Reply-To: <1403009009.22737.129.camel@willson.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dSXJO7-JZK93-lfsJ_EimUNTuuA Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:10:39 -0000 SGkgU2ltbywNCg0KSSBhcG9sb2dpemUgZm9yIHRoZSB2ZXJ5IGxhdGUgcmVzcG9uc2UuIA0KDQo+ PiBJIHRoaW5rIEFEIGRhdGEgY2FuIGJlIGFkZGVkIHdpdGggczR1MnNlbGYvczR1MnByb3h5IGFz IHdlbGwsIHdoYXQgb3RoZXIgbW9kaWZpY2F0aW9ucyBkbyB5b3UgaGF2ZSBpbiBtaW5kID8NClll cyBJIGFncmVlLiBBZGRpbmcgQUQgZGF0YSBsaWtlIEFEX1RPS0VOIHdvbid0IGJlIGFuIGlzc3Vl IGlmIHdlIGNvdWxkIGVuaGFuY2UgUzRVIHRvIHN1cHBvcnQgdG9rZW4gYWRkaW5nIHNvbWV0aGlu ZyBsaWtlIFBBX1M0VV9UT0tFTiANCmluIGxpZXUgd2l0aCBQQV9GT1JfVVNFUiBhbmQgUEFfUzRV X1g1MDlfVVNFUi4gOikNCkkgbWlnaHQgYmUganVzdCByZXBlYXRpbmcgd2hhdCBJIGhhdmUgc2Fp ZCBhbHJlYWR5LCB3aHkgSSB3b3VsZCBwcmVmZXIgdG8gZG8gaXQgaW4gcHJlLWF1dGhlbnRpY2F0 aW9uIGZyYW1ld29yazoNCjEuIFRva2VuIGNhbiBiZSB1c2VkIGluIEFTLVJFUS9BUy1SRVAgZXhj aGFuZ2UgdmlhIHRva2VuLXByZWF1dGggbWVjaGFuaXNtIHRvIGFjcXVpcmUgYSBUR1QsIG1ha2lu ZyBraW5pdCB0b29sIHN1cHBvcnQgdGhhdCBpcyBlYXN5Lg0KUzRVIHdvcmtzIGluIFRHUy1SRVEv VEdTLVJFUCBleGNoYW5nZSB0byBhY3F1aXJlIHNlcnZpY2UgdGlja2V0LCB3aGljaCBpbnZvbHZl cyBjb3JyZXNwb25kaW5nIEdTU0FQSSBzdXBwb3J0IGZvciBhcHBsaWNhdGlvbnMgdG8gbWFrZSB1 c2Ugb2YgaXQuIA0KMi4gSW4gdG9rZW4tcHJlYXV0aCBhcHByb2FjaCwgd2UgY2FuIGFsc28gYWNo aWV2ZSB0aGUgZWZmZWN0IG9mIFM0VSBpbiBzb21lIGRlZ3JlZS4gV2ViIHNlcnZlciBhY2NlcHRp bmcgdG9rZW4gc3VibWl0dGVkIGJ5IGJyb3dzZXIgcGFnZSBmb3JtLA0KZG9pbmcgS2VyYmVyb3Mg bG9naW4gc3R1ZmYgdmlhIHRva2VuLXByZWF1dGgsIHRoZW4gcGVyZm9ybWluZyBHU1NBUEkvU0FT TCBuZWdvdGlhdGlvbiB3aXRoIGJhY2tlbmQgc2VydmljZSwgd29ya3MgZ3JlYXQuDQoNCj4+IERv IHlvdSBoYXZlIGEgc3RhbmRhcmRpemVkIEFEIGVsZW1lbnQgaW4gbWluZCwgb3IgYXJlIHlvdSBn b2luZyB0byBkZWZpbmUgYSBuZXcgb25lID8NCkhvdyBhYm91dCBoYXZpbmcgYSBuZXcgb25lIGxp a2UgQUQtVE9LRU4gdGhhdCBjb250YWlucyB0aGUgdG9rZW4gZGVyaXZhdGlvbi4gSXQgY2FuIGVu Y2Fwc3VsYXRlZCBpbnRvIEFELUtEQy1JU1NVRUQsIHdpdGggY2hlY2tzdW0uIFRoZSB0aGlua2lu Zw0Kd291bGQgYmUsIEtEQyB2YWxpZGF0ZXMgaW5jb21pbmcgdG9rZW4gYW5kIGRldGVybWluZXMg dG8gaXNzdWUgdGlja2V0LCBieSBlc2NhcGluZyBhbnkgZW5jcnlwdGlvbi9zaWduYXR1cmUgbGF5 ZXJzIG9mIHRoZSB0b2tlbiwgZ2V0cyB0aGUgdG9rZW4gZGVyaXZhdGlvbiwNCmFuZCBwdXQgaXQg aW50byB0aGUgaXNzdWVkIHRpY2tldC4gQXMgc3VjaCBpdCdzIG5hdHVyYWwgdG8gd3JhcCB0aGUg bmV3IEFEIGRhdGEgaW50byBBRC1LREMtSVNTVUVELg0KDQpUaGFua3MgZm9yIHRoaW5raW5nIGFi b3V0IHRoaXMuIA0KDQpSZWdhcmRzLA0KS2FpDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFNpbW8gU29yY2UgW21haWx0bzpzaW1vQHJlZGhhdC5jb21dIA0KU2VudDogVHVl c2RheSwgSnVuZSAxNywgMjAxNCA4OjQzIFBNDQpUbzogWmhlbmcsIEthaQ0KQ2M6IGtpdHRlbkBp ZXRmLm9yZzsga3JiZGV2QG1pdC5lZHUNClN1YmplY3Q6IFJlOiBba2l0dGVuXSBUb2tlbiBQcmVh dXRoIGZvciBLZXJiZXJvcw0KDQpPbiBUdWUsIDIwMTQtMDYtMTcgYXQgMDU6MzUgKzAwMDAsIFpo ZW5nLCBLYWkgd3JvdGU6DQo+ID4+IFlvdSBuZWVkIHRvIG1vZGlmeSBzb21ldGhpbmcgYW55d2F5 LCBjb25zdHJhaW5lZCBkZWxlZ2F0aW9uIHNvdW5kDQo+IGxpa2UgYSBiZXR0ZXIgd2F5IHRoYW4g dHJ5aW5nIHRvIGRldmlzZSBhIHdob2xlIG5ldyBwcmUtYXV0aCBwbHVnaW4uDQo+IEFzIGZhciBh cyBJIGtub3cgczR1MnNlbGYgJiBzNHUycHJveHkgcGx1cyBjb250cmFpbmVkIGRlbGVnYXRpb24g YXJlIA0KPiBmcm9tIE1TIGFuZCBJJ20gbm90IHN1cmUgd2UgY291bGQgbW9kaWZ5IGl0IGFzIHdl IG5lZWQuIEEgbmV3IA0KPiB0b2tlbi1wcmVhdXRoIGJhc2VkIG9uIGV4aXN0aW5nIEtlcmJlcm9z IGFuZCBmcmFtZXdvcmsgaXMgbW9yZSANCj4gcHJlZmVycmVkIGZvciB1cyBzaW5jZSB0aGUgcGx1 Z2luIGlzIGVhc3kgdG8gZGVwbG95LCBhbHNvIHdlIGJlbGlldmUgDQo+IHRoZSBtZWNoYW5pc20g dXNpbmcgSldUIHRva2VuIHdpbGwgb3BlbiB0aGUgZG9vciB0byBpbnRlZ3JhdGUgS2VyYmVyb3Mg DQo+IHdpdGggT0F1dGguDQoNCkkgdGhpbmsgQUQgZGF0YSBjYW4gYmUgYWRkZWQgd2l0aCBzNHUy c2VsZi9zNHUycHJveHkgYXMgd2VsbCwgd2hhdCBvdGhlciBtb2RpZmljYXRpb25zIGRvIHlvdSBo YXZlIGluIG1pbmQgPw0KDQo+ID4+SG93ZXZlciB5b3Ugc2hvdWxkIG9ubHkgdHJhbnNtaXQgdGhl IGF1dGhvcml6YXRpb24gZGF0YSwgbm90IHRoZQ0KPiB3aG9sZSB0b2tlbiwgb3RoZXJ3aXNlIHlv dSBkZXN0cm95IGV2ZXJ5IHNpbmdsZSBzZWN1cml0eSBwcm9wZXJ0eSBvZiANCj4gS2VyYmVyb3Mu DQo+ID4+SSBjYW4ndCBzZWUgYW55IGtyYiBhZG1pbiBhcyBhY2NlcHRpbmcgc29tZXRoaW5nIGxp a2UgdGhhdC4NCj4gWWVzIEkgYWdyZWUuIEFzIGRpc2N1c3NlZCB3aXRoIEdyZWcgYW5kIGFsc28g c2FpZCBoZXJlIGluIG15IHByZXZpb3VzIA0KPiBlbWFpbCwgd2Ugd2lsbCBub3QgcGFzcyB0aGUg dG9rZW4gaXRzZWxmIHRvIHNlcnZpY2UsIGluc3RlYWQgdG9rZW4gDQo+IGF0dHJpYnV0ZXMgb3Ig dGhlIGRlcml2YXRpb24gdGhhdCBjYW4ndCBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIA0K PiBLREMuDQoNCkRvIHlvdSBoYXZlIGEgc3RhbmRhcmRpemVkIEFEIGVsZW1lbnQgaW4gbWluZCwg b3IgYXJlIHlvdSBnb2luZyB0byBkZWZpbmUgYSBuZXcgb25lID8NCg0KU2ltby4NCg0KLS0NClNp bW8gU29yY2UgKiBSZWQgSGF0LCBJbmMgKiBOZXcgWW9yaw0KDQo= From nobody Tue Jul 8 09:33:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422271B2BB1 for ; Tue, 8 Jul 2014 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmln899X3jVv for ; Tue, 8 Jul 2014 09:33:32 -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 8FE6F1B2BB5 for ; Tue, 8 Jul 2014 09:33:27 -0700 (PDT) X-AuditID: 12074422-f79be6d000007518-c9-53bc1d560314 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 5F.A9.29976.65D1CB35; Tue, 8 Jul 2014 12:33:27 -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 s68GXP1a008198; Tue, 8 Jul 2014 12:33:26 -0400 Received: from [18.101.8.71] (vpn-18-101-8-71.mit.edu [18.101.8.71]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s68GXNxa012533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:33:25 -0400 Message-ID: <53BC1D53.6040106@mit.edu> Date: Tue, 08 Jul 2014 12:33:23 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Zheng, Kai" References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> <1403009009.22737.129.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT1w2X3RNs8PcRk8X61tMsFkc3r2Jx YPJYsuQnk8fiPS+ZApiiuGxSUnMyy1KL9O0SuDIuX9nDUvCFtWLtiV8sDYxvWLoYOTkkBEwk Ll5fxQxhi0lcuLeerYuRi0NIYDaTxI/ra5khnA2MEo97TrNCOAeYJDb/vM8E0sIroCZx+sQD dhCbRUBV4vDGZ2wgNpuAssTBs9/AVogKhEl8PLqODaJeUOLkzCdgcRGg3vXnd7GC2MwCXhKz zj0Es4UFDCS6792EOuMis8Tq3/cYuxg5ODgFQiQONftAnCopsW3RMXaIXh2Jd30PmCFseYnt b+cwT2AUmoVk3SwkZbOQlC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mil5pSuokR HNouSjsYfx5UOsQowMGoxMN7gnNPsBBrYllxZe4hRkkOJiVR3glMQCG+pPyUyozE4oz4otKc 1OJDjBIczEoivMsFgXK8KYmVValF+TApaQ4WJXHet9ZWwUIC6YklqdmpqQWpRTBZGQ4OJQne I9JAjYJFqempFWmZOSUIaSYOTpDhPEDDD4LU8BYXJOYWZ6ZD5E8xKkqJ896VAkoIgCQySvPg emGp5xWjONArwryXQdp5gGkLrvsV0GAmoMGf3+8AGVySiJCSamA0KHoXsvsAK0+j9LVP+X43 ra7Nd4xccC62Ik7625ZtbxtYu5583fr/zotZQVPNXom+k9gxd+Yuk/+zZwRPS8h0ntO/Upn/ WaJYwIKdj669X86xZEr5h+shgZ+v2f+MVpnleCA59zDfRUu2sHVxX6ryLvJwV/qpu5wPDVgj yD2zcOPNh/KLol3ClViKMxINtZiLihMBKrMzgRgDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lewHuvPhVo0v2sc9OA7HFwkKdns Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:33:35 -0000 On 07/08/2014 08:10 AM, Zheng, Kai wrote: > How about having a new one like AD-TOKEN that contains the token derivation. To me, this sounds like creating a container-of-anything within an existing container-of-anything. That is, if you see something within an AD-TOKEN subcontainer, you don't know anything about what it is, only something about where it came from and how it is encoded. An advantage of the subcontainer approach is that the KDC can be fairly dumb. But the server application has to be correspondingly smart; if a semantically equivalent piece of authorization data could exist in one of several subcontainers, each with its own encoding, then it must understand all of the different subcontainers and search within each. From nobody Tue Jul 8 18:50:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAFC1A0240 for ; Tue, 8 Jul 2014 18:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKQacyZKMO5f for ; Tue, 8 Jul 2014 18:49:57 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 597A71A023E for ; Tue, 8 Jul 2014 18:49:57 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 08 Jul 2014 18:49:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,630,1400050800"; d="scan'208";a="570287772" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga002.jf.intel.com with ESMTP; 08 Jul 2014 18:49:56 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 18:49:56 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 18:49:56 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by shsmsx102.ccr.corp.intel.com ([169.254.2.21]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:49:55 +0800 From: "Zheng, Kai" To: Greg Hudson Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAACyy6gADKjG2g///1jYD/3rPSIIBCjV+A//7iu7A= Date: Wed, 9 Jul 2014 01:49:55 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FB9DE@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> <1403009009.22737.129.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> <53BC1D53.6040106@mit.edu> In-Reply-To: <53BC1D53.6040106@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fzRtPK0sNvCNE1_FwBeVLfU7UzI Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 01:49:59 -0000 Hi Creg, > this sounds like creating a container-of-anything within an existing cont= ainer-of-anything. That is, if you see something within an AD-TOKEN subcon= tainer, you don't know anything about what it is, only something about wher= e it came from and how it is encoded. Hmmm, not exactly as what I mean. It's container-of-exactly-token within th= e existing container-of-anything (AD-KDC-ISSUED). Looking at AD-TOKEN subco= ntainer, applications are meant to get a token from it, as AD-TOKEN could b= e defined as: AD-TOKEN ::=3D SEQUENCE { token [0] OCTET STRING, } The token is defined as JWT token, and can be converted as OCTET STRING acc= ording to how JWT tokens are serialized into binary bytes. Looks like AD-CAMMAC is a better alternative to AD-KDC-ISSUED, so as you su= ggested we can use it instead, though it's a little bit complex regarding i= mplementation. Regards, Kai -----Original Message----- From: Greg Hudson [mailto:ghudson@MIT.EDU]=20 Sent: Wednesday, July 09, 2014 12:33 AM To: Zheng, Kai Cc: kitten@ietf.org; krbdev@mit.edu Subject: Re: [kitten] Token Preauth for Kerberos On 07/08/2014 08:10 AM, Zheng, Kai wrote: > How about having a new one like AD-TOKEN that contains the token derivati= on. To me, this sounds like creating a container-of-anything within an existing= container-of-anything. That is, if you see something within an AD-TOKEN s= ubcontainer, you don't know anything about what it is, only something about= where it came from and how it is encoded. An advantage of the subcontainer approach is that the KDC can be fairly dum= b. But the server application has to be correspondingly smart; if a semant= ically equivalent piece of authorization data could exist in one of several= subcontainers, each with its own encoding, then it must understand all of = the different subcontainers and search within each. From nobody Wed Jul 9 07:18:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7B1A064C for ; Wed, 9 Jul 2014 07:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwNsAXLUVeB7 for ; Wed, 9 Jul 2014 07:17:57 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327E41A063C for ; Wed, 9 Jul 2014 07:17:57 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-e0-53bd4f14876e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A5.38.30080.41F4DB35; Wed, 9 Jul 2014 10:17:56 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s69EHtk1003315; Wed, 9 Jul 2014 10:17:55 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s69EHq6a004427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jul 2014 10:17:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s69EHqvm023075; Wed, 9 Jul 2014 10:17:52 -0400 (EDT) Date: Wed, 9 Jul 2014 10:17:52 -0400 (EDT) From: Benjamin Kaduk To: "Zheng, Kai" In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118FB9DE@SHSMSX103.ccr.corp.intel.com> Message-ID: References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> <1403009009.22737.129.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> <53BC1D53.6040106@mit.edu> <8D5F7E3237B3ED47B84CF187BB17B666118FB9DE@SHSMSX103.ccr.corp.intel.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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrSvivzfYYPUhfov1radZLI5uXsXi wOSxZMlPJo/Fe14yBTBFcdmkpOZklqUW6dslcGXc/NDOXrCKveLb7K9MDYyfWbsYOTkkBEwk fm+dwghhi0lcuLeeDcQWEpjNJLFtbVIXIxeQvYFRYs+982wQzkEmiekT7zF3MXIAOfUSL78q gTSwCGhJXJx4BmwQm4CKxMw3G8EGiQioSaw/vwtsGbOAl8Tl18tYQGxhAQOJ7ns3wWo4BUIk Tn/YyAxi8wo4Shz4OY0dYtcOFokV1zaDFYkK6Eis3j+FBaJIUOLkzCcsEEMtJc79uc42gVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYICld1FeQfjn4NK hxgFOBiVeHhPcO4JFmJNLCuuzD3EKMnBpCTKW+O5N1iILyk/pTIjsTgjvqg0J7X4EKMEB7OS CK+rM1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgmK8PBoSTBy+YH1ChYlJqe WpGWmVOCkGbi4AQZzgM0nBukhre4IDG3ODMdIn+KUVFKnPeCL1BCACSRUZoH1wtLJK8YxYFe EeaVBWnnASYhuO5XQIOZgAZbW+wBGVySiJCSamD0mvE4Ke/zwgmMa7/I1p+UmmW1fMaK4q/S vVdubLn8UPY0V5SL0RPLPVl5XvmP+ye6Gm6yFT177VrL/ykHLO/sa+JLyfDQd0j4bS9envds xv29seaXxfoiakrlCjM1Xh7b+try/e2umPdsmktk6itiM/PE/zR/Y+e5F/XKNFhQK3STYPPk 4AYlluKMREMt5qLiRABiHBj1/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/sGbaQ9FB3yVvq1WEXcLZ4Tlac0Q Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:17:59 -0000 On Tue, 8 Jul 2014, Zheng, Kai wrote: > Hi Creg, > >> this sounds like creating a container-of-anything within an existing container-of-anything. That is, if you see something within an AD-TOKEN subcontainer, you don't know anything about what it is, only something about where it came from and how it is encoded. > > Hmmm, not exactly as what I mean. It's container-of-exactly-token within > the existing container-of-anything (AD-KDC-ISSUED). Looking at AD-TOKEN > subcontainer, applications are meant to get a token from it, as AD-TOKEN > could be defined as: AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data type, but rather that the JWT token therein could contain any sort of information about the user making the request, restrictions placed on the token, and so on. (Almost) any sort of information could be in the AD-TOKEN, even if only a single data type is permitted. -Ben From nobody Wed Jul 9 14:01:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90981B27A9 for ; Wed, 9 Jul 2014 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EHtwTV2aPPG for ; Wed, 9 Jul 2014 14:01:37 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF51B27A0 for ; Wed, 9 Jul 2014 14:01:37 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Jul 2014 14:01:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,633,1400050800"; d="scan'208";a="570796095" Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54]) by orsmga002.jf.intel.com with ESMTP; 09 Jul 2014 14:01:32 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.19.9.29) by FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 14:01:31 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx120.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 14:01:32 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by shsmsx102.ccr.corp.intel.com ([169.254.2.21]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 05:01:30 +0800 From: "Zheng, Kai" To: Benjamin Kaduk Thread-Topic: [kitten] Token Preauth for Kerberos Thread-Index: Ac95oBHY/v5P0th/QSGCBpa/sVINTQMo1vwAABRlhDAACyy6gADKjG2g///1jYD/3rPSIIBCjV+A//7iu7CAAom9AP//DGOg Date: Wed, 9 Jul 2014 21:01:30 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B666118FBFFA@SHSMSX103.ccr.corp.intel.com> References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <1402609038.22737.57.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118ED023@SHSMSX103.ccr.corp.intel.com> <1402663277.22737.60.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118F09D8@SHSMSX103.ccr.corp.intel.com> <1403009009.22737.129.camel@willson.usersys.redhat.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB475@SHSMSX103.ccr.corp.intel.com> <53BC1D53.6040106@mit.edu> <8D5F7E3237B3ED47B84CF187BB17B666118FB9DE@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2EgmHDjHo59NO_vOIJZq4Zt6RN8 Cc: "kitten@ietf.org" , "krbdev@mit.edu" Subject: Re: [kitten] Token Preauth for Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 21:01:39 -0000 Hi Ben, > AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data = type, but rather that the JWT token therein could contain any sort of infor= mation about the user making the request ... Yes I agree. Thanks for clarifying. I'm thinking of AD-TOKEN as AD-WIN2K-PA= C. The difference is AD-TOKEN contained token is from 3rd party token autho= rity and can contain anything like you=20 mentioned, and the layout of AD-WIN2K-PAC is well defined by MS-PAC. Also I= MO, having a subcontainer like AD-TOKEN for token-preauth mechanism could a= llow some flexibility for=20 future extensions.=20 What would you suggest regarding this or any other aspects for the proposed= mechanism? Thanks. Regards, Kai -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]=20 Sent: Wednesday, July 09, 2014 10:18 PM To: Zheng, Kai Cc: kitten@ietf.org; krbdev@mit.edu Subject: Re: [kitten] Token Preauth for Kerberos On Tue, 8 Jul 2014, Zheng, Kai wrote: > Hi Creg, > >> this sounds like creating a container-of-anything within an existing con= tainer-of-anything. That is, if you see something within an AD-TOKEN subco= ntainer, you don't know anything about what it is, only something about whe= re it came from and how it is encoded. > > Hmmm, not exactly as what I mean. It's container-of-exactly-token=20 > within the existing container-of-anything (AD-KDC-ISSUED). Looking at=20 > AD-TOKEN subcontainer, applications are meant to get a token from it,=20 > as AD-TOKEN could be defined as: AD-TOKEN is a "container of anything" not in the sense of the ASN.1 data ty= pe, but rather that the JWT token therein could contain any sort of informa= tion about the user making the request, restrictions placed on the token, a= nd so on. (Almost) any sort of information could be in the AD-TOKEN, even = if only a single data type is permitted. -Ben From nobody Mon Jul 14 09:43:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD39E1A0ADB for ; Mon, 14 Jul 2014 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNK42a_nJqak for ; Mon, 14 Jul 2014 09:43:49 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54B81A0AAC for ; Mon, 14 Jul 2014 09:43:48 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-ae-53c408c37d20 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 08.C3.30080.3C804C35; Mon, 14 Jul 2014 12:43:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6EGhlsk003717 for ; Mon, 14 Jul 2014 12:43: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 s6EGhjgK011673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Jul 2014 12:43:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6EGhjJT019691; Mon, 14 Jul 2014 12:43:45 -0400 (EDT) Date: Mon, 14 Jul 2014 12:43:45 -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: MULTIPART/MIXED; boundary="-559023410-2062347274-1405356203=:21571" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrHuY40iwwelmQ4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/Prf7aC3+wVu2dvZG9gfMzWxcjBISFgIjH9s0UXIyeQKSZx 4d56oDAXh5DAbCaJRdtmQjnHGSWmd7WwQzg3mCTu/DvGAuE0MErsbXrABNLPIqAtsfzTAxYQ m01ARWLmm41sILaIgLDE7q3vmEFsYQFPiUvndrOC2LwCjhLNT2+B2aICOhKr909hgYgLSpyc +QTMZhYIlFi86i/YqcxA9d8/eU1g5J+FpGoWkqpZCFUQpo3EhHuVEBXaEvdvtrFB2I4S/Sva mRcwsq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQICmB2F+UdjH8OKh1iFOBg VOLhlXh3OFiINbGsuDL3EKMkB5OSKK/QL6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd6jH4By vCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJXjn2I8FCgkWp6akVaZk5 JQhpJg5OkOE8QMN/sAHV8BYXJOYWZ6ZD5E8xKkqJ87aCJARAEhmleXC9sATzilEc6BVh3r8g VTzA5ATX/QpoMBPQ4PIakKuLSxIRUlINjBM+sB/52RPdsEDp9Nm5/eLt/o/ed0QcWltc/v7/ xVJVnff6cfsmeilttDIMer0zJa+E2W+DgZzCYY1F+be+h5Qfa+75VVrnfaYkTbju/8vKeaIv V74L3h2oe5nh2rVZ3BcXqVQwM9St2F0q4B4ybcbPi3OcBJLjP+TOVrnTybl8h4rAd4G/J5RY ijMSDbWYi4oTAdGRjloLAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/C2N74IPDUu8ay7C8mkfOHhb6y10 Subject: [kitten] Expiration impending: (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:43:53 -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-2062347274-1405356203=:21571 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: I am assuming that I can submit a no-change "update" on the 21st when=20 submissions reopen, and there will not be any significant consequence. -Ben ---------- Forwarded message ---------- Date: Mon, 14 Jul 2014 07:42:05 -0400 From: IETF Secretariat To: Benjamin Kaduk Subject: Expiration impending: The following draft will expire soon: Name: draft-kaduk-kitten-gss-loop Title: Structure of the GSS Negotiation Loop State: I-D Exists Expires: 2014-07-18 (in 3=A0days, 19=A0hours) ---559023410-2062347274-1405356203=:21571-- From nobody Mon Jul 14 10:09:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0F51A01C0 for ; Mon, 14 Jul 2014 10:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1itA7-hNN7t for ; Mon, 14 Jul 2014 10:09:34 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293111A0AD9 for ; Mon, 14 Jul 2014 10:09:32 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-14-53c40ecbb69d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D0.E1.01660.BCE04C35; Mon, 14 Jul 2014 13:09:31 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6EH9UNo008139 for ; Mon, 14 Jul 2014 13:09:31 -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 s6EH9QwP020392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Jul 2014 13:09:30 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6EH9Qn7022881; Mon, 14 Jul 2014 13:09:26 -0400 (EDT) Date: Mon, 14 Jul 2014 13:09:26 -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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUixCmqrXua70iwwcxTnBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvoVn1kK3rNUzP0v2MD4mbmLkZNDQsBEouPMWTYIW0ziwr31 QDYXh5DAbCaJzq6DzBDOcUaJLc1H2CGcG0wSPyasA2sREmhglPj+OqSLkYODRUBbYt1TNZAw m4CKxMw3G8FKRASEJXZvfQe2TVggQqJ351ywOKeAk8SbLydZQGxeAUeJs9/WsoCMEQKyDz6v AgmLCuhIrN4/BapEUOLkzCdgNrOApcS5P9fZJjAKzEKSmoUktYCRaRWjbEpulW5uYmZOcWqy bnFyYl5eapGuuV5uZoleakrpJkZQ4LG7qOxgbD6kdIhRgINRiYdX4t3hYCHWxLLiytxDjJIc TEqivOu4jwQL8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE9+gGonDclsbIqtSgfJiXNwaIkzvvW 2ipYSCA9sSQ1OzW1ILUIJivDwaEkwbuFF2ioYFFqempFWmZOCUKaiYMTZDgP0PATIDW8xQWJ ucWZ6RD5U4yKUuK8zSAJAZBERmkeXC8sMbxiFAd6RZj3LEgVDzCpwHW/AhrMBDS4vAbk6uKS RISUVAOjheXauisnHre5indW+4X0nIsq/rTBMb/jnl9i7wSBWRN2nopaG9MUYfr5eFLxvc8c Zz7Ou/MivodHhq/MLX3yBINNPm7H+/atu7Qm6+czy6RHfw1vJfIuqS1ykPulMW8C/wHBitum tTv53/028OEJv75Xp635t4/6h/Uq6UbMkRJdhZbLt1xTYinOSDTUYi4qTgQAU+Jy5OcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7umEdO7FQM6KigzsyADStcc6PfU Subject: Re: [kitten] Expiration impending: (fwd) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 17:09:35 -0000 On Mon, 14 Jul 2014, Benjamin Kaduk wrote: > I am assuming that I can submit a no-change "update" on the 21st when > submissions reopen, and there will not be any significant consequence. Whoops, I guess I was not reading closely enough -- this expiration notice is for the non-WG version of the document, but the WG version (http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-00) is still live and not at risk of expiry until November. I'm not sure why I expected the expiration-impending notifications to check for a new version of the document by a different name. Sorry for the noise. -Ben From nobody Mon Jul 21 02:04:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D100B1B2B63 for ; Mon, 21 Jul 2014 02:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiPZ9ZAq0hI6 for ; Mon, 21 Jul 2014 02:04:02 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C362C1B2A46 for ; Mon, 21 Jul 2014 02:04:01 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id s6L93tUm093348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 11:03:57 +0200 (CEST) (envelope-from rick@openfortress.nl) From: Rick van Rein Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2014 11:03:55 +0200 To: tlyu@mit.edu, kitten@ietf.org Message-Id: <93975EF5-D151-417E-8043-6B54D36FD9DC@openfortress.nl> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/yqV5stI91cl9P4ABaWlsAj-3IK4 Subject: [kitten] draft-ietf-kitten-kerberos-iana-registries -- KerberosFlags limited to 0..31? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 09:04:04 -0000 Hello Tom Yu / Kitten, I was surprised to learn that = draft-ietf-kitten-kerberos-iana-registries-03 defines > 6.1. AP-REQ options >=20 > Registry name: AP-REQ options > Assignment policy: Standards action > Valid values: ASN.1 bit numbers 0 through 31 >=20 > 6.2. KDC-REQ options >=20 > Registry name: KDC-REQ options > Assignment policy: Standards action > Valid values: ASN.1 bit numbers 0 through 31 >=20 > 6.3. Ticket flags >=20 > Registry name: Ticket flags > Assignment policy: Standards action > Valid values: ASN.1 bit numbers 0 through 31 These are all instances of the KerberosFlags type. I=92m not sure that a maximum of 32 bits is required, or desirable, for = that type. RFC 4120 specifies in section 5.2.8 =93KerberosFlags=94 that > KerberosFlags ::=3D BIT STRING (SIZE (32..MAX)) > -- minimum number of bits shall be sent, > -- but no fewer than 32 and > Most existing implementations of Kerberos unconditionally send 32 > bits on the wire when encoding bit strings used as boolean vectors. > This behavior violates the ASN.1 syntax used for flag values in RFC > 1510, but it occurs on such a widely installed base that the = protocol > description is being modified to accommodate it. >=20 > Consequently, this document removes the "NamedBit" notations for > individual bits, relegating them to comments. The size constraint = on > the KerberosFlags type requires that at least 32 bits be encoded at > all times, though a lenient implementation MAY choose to accept = fewer > than 32 bits and to treat the missing bits as set to zero. >=20 > Currently, no uses of KerberosFlags specify more than 32 bits' = worth > of flags, although future revisions of this document may do so. = When > more than 32 bits are to be transmitted in a KerberosFlags value, > future revisions to this document will likely specify that the > smallest number of bits needed to encode the highest-numbered one- > valued bit should be sent. This is somewhat similar to the DER > encoding of a bit string that is declared with the "NamedBit" > notation. I see nothing here that constrains the number of bits, and I cannot = think of any real problems as a result of encoding more bits; not even = when a lot of zero bits are included at the high end; for instance, to = send 64 bits to be able to include 35 bits worth of flags. (And if = problems arose with existing implementations, then these would = constitute an error in the ASN.1 encoding used, and these = implementations would need a bug fix.) I would therefore like to argue that it is not necessary to constrain = the "Ticket flags=94 registry to 32 bits, and that it may be helpful in = the future to prepare for longer BITSTRINGs. I hope this is a useful addition. Cheers, -Rick= From nobody Mon Jul 21 07:43:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081AA1A00DB for ; Mon, 21 Jul 2014 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfAKVE0z7tzL for ; Mon, 21 Jul 2014 07:43:28 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43C11A000F for ; Mon, 21 Jul 2014 07:43:27 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-7d-53cd270ed8e8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FB.DF.32177.E072DC35; Mon, 21 Jul 2014 10:43:26 -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 s6LEhP8a024152; Mon, 21 Jul 2014 10:43:25 -0400 Received: from [18.101.8.166] (vpn-18-101-8-166.mit.edu [18.101.8.166]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6LEhMW9025608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Jul 2014 10:43:24 -0400 Message-ID: <53CD270A.4030102@mit.edu> Date: Mon, 21 Jul 2014 10:43:22 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rick van Rein , tlyu@mit.edu, kitten@ietf.org References: <93975EF5-D151-417E-8043-6B54D36FD9DC@openfortress.nl> In-Reply-To: <93975EF5-D151-417E-8043-6B54D36FD9DC@openfortress.nl> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hRV1uVTPxts8PukksXRzatYLJ6+usfm wOSxZMlPJo8N/5rYApiiuGxSUnMyy1KL9O0SuDLW9f5nLOhgrzg1czZTA+Mt1i5GTg4JAROJ w1c6oGwxiQv31rN1MXJxCAnMZpKYtvkqlLORUeLp4X3sEM4RJol9/b+YQFp4BdQktk24xA5i swioSqzetJ0NxGYTUJY4ePYbC4gtKhAm8XjOOUaIekGJkzOfgMVFBNwlVl2cBLZaWCBV4uyW 32BxIQEniRkde8Hmcwo4Szw79wnqPEmJbYuOge1iFtCT2HH9FyuELS+x/e0c5gmMgrOQrJiF pGwWkrIFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxgkNYkm8H49eDSocY BTgYlXh4LeTPBguxJpYVV+YeYpTkYFIS5b0gBxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwqup ApTjTUmsrEotyodJSXOwKInzvrW2ChYSSE8sSc1OTS1ILYLJynBwKEnwvlMFahQsSk1PrUjL zClBSDNxcIIM5wEazqsGMry4IDG3ODMdIn+KUZdj0f6X3UxCLHn5ealS4rwPQC4QACnKKM2D mwNLPa8YxYHeEuZ9D7KOB5i24Ca9AlrCBLSkKPM0yJKSRISUVAOjfKiQs4p08aTPXkdPfxMU rVzcf/+Rxn6bm5ufli3dKKn58KTk3f0fZGImaU7gNXPcytii61XWpH9rld97dm0Jw+fsvA45 MzRvBH+14M887jlnt5Q2++HNU6V8nOICBeccycz1dfEutCx/71A5P/99LO/rSbX/ujbU57Z/ 3WMhqR7y4cKBaG0lluKMREMt5qLiRACD5in7GAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/eBxRVjKtRlksn6Z8kwGTv9cHTyI Subject: Re: [kitten] draft-ietf-kitten-kerberos-iana-registries -- KerberosFlags limited to 0..31? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:43:31 -0000 On 07/21/2014 05:03 AM, Rick van Rein wrote: > I was surprised to learn that draft-ietf-kitten-kerberos-iana-registries-03 defines >> 6.1. AP-REQ options >> Valid values: ASN.1 bit numbers 0 through 31 [...] I believe this is in deference to implementations which store flag values in fixed 32-bit flags. For example, in MIT krb5: * krb5_flags is a 32-bit integer type. * A krb5_flags field representing ticket flags is included in krb5_creds. * krb5_creds is used in several core public APIs such as krb5_get_credentials. Although RFC 4120 has a well-specified means of encoding larger flag values over the wire, there would still be a significant implementation cost to using larger bit values over the wire. If the IETF decides that this implementation cost is warranted, the standards action which assigns the flag value could amend the registry to accomodate it. From nobody Mon Jul 21 10:24:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656D81A015F; Mon, 21 Jul 2014 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4McmB4eOMM_z; Mon, 21 Jul 2014 10:24:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AA01A02F2; Mon, 21 Jul 2014 10:24:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721172422.10746.81978.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 10:24:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fwfNi9FkXaBqIRxkpEmvHTtLiws Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:24:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-04.txt Pages : 16 Date : 2014-07-21 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-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/ From nobody Tue Jul 22 22:30:15 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6381A0414; Tue, 22 Jul 2014 22:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBh3plHIAWxf; Tue, 22 Jul 2014 22:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 619261A007A; Tue, 22 Jul 2014 22:30:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723053006.25844.40762.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 22:30:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZPIlTorn88wPB9SkpRWQvOaLmoY Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-15.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 05:30:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-15.txt Pages : 21 Date : 2014-07-22 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 22:33:45 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554FE1B2800 for ; Tue, 22 Jul 2014 22:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11kLgzLLECUa for ; Tue, 22 Jul 2014 22:33:43 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C6A1A02FA for ; Tue, 22 Jul 2014 22:33:43 -0700 (PDT) Received: from [66.196.81.172] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jul 2014 05:33:42 -0000 Received: from [98.139.212.229] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jul 2014 05:33:42 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 23 Jul 2014 05:33:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 507214.75480.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 90227 invoked by uid 60001); 23 Jul 2014 05:33:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406093622; bh=eFeW/sqrnVrKZoNmq/JZOj/aXaJXREuj+GvXGHc02B4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AIFX1/XB/Ydk43tGHUWWLsVWeTHUOoZ3WSpIbm1ZvTX7uQ/j+BoRO9nX2qx/EAI0BUd/5B05B3YfipweJ9VvxuCwg7vW/YR07W3HRaXac+TZoEyX0Pd2TvLGvzU2cSQskzaj+0O8Lj15IpsXLRthb0RtvMHfxc3K1vUpEB0Lr5k= X-YMail-OSG: 6Z_4pUkVM1n.I6nmz6JTetx0D_1vWZ96CyEpyMxl9rjW8yp HdEj3MJZGut4hQETrt2wsJ.CE9Ua4j5O2rhYeyOtftL3MxF8S1x1gjkstZkw CY5iwSMNMfuGMd.UdrbNwu._JWXafKe3fWnsrlzc82VUFxIKvOJ5cBERK.WP 9fbRXGrjFHCfAN_8qgZlH8jsvX_H40rhOWAdGPUeDFH17qIsh936tMwB9SD5 pkCGFMFwFs9YeOfchlDv9OpeM6dBomKfflud09J9TtVi0_BbA_Lf9h38lJiX .v2WVwYgKtVoPvnUB_l81Z25H9sYBMeRJADKVdg6myhkg4bqXHSyMUOR4XgA tyiaUYYzfrVNjr5MFttAeuon.KqTMTgvUGLqv0At0bCgUugFNm1yBV6Mp1fm RxTAbxH8f5pZjrSOB39erIqcY5giGYWWALUVJGpLy.fo6SHc6OkHdeLhDKQs oAyuNbDZMJ3zRf2664pG.z3TyN_tgFCLAoH2DBzPOJQ0jgY5UU85sB2RgxSI p48IZB1V_7cFlUn_JXf8_ihP5zd53vinVCfI56qxlen1jeESNh_.p Received: from [99.31.212.42] by web142806.mail.bf1.yahoo.com via HTTP; Tue, 22 Jul 2014 22:33:42 PDT X-Rocket-MIMEInfo: 002.001, U29ycnkgdGhpcyB0b29rIHNvIGxvbmcsIGl0J3MgdGhlIGVkaXRzIHdlIHRhbGtlZCBhYm91dCBpbiBMb25kb24gZmluYWxseSBicm91Z2h0IGZvcndhcmQgaW50byBhIGRyYWZ0LgoKSSdsbCB0cnkgdG8gYmUgaW4gb24gdGhlIHNlc3Npb24gdG9tb3Jyb3cgcmVtb3RlbHkgaWYgYW55b25lIHdhbnRzIHRvIGJyaW5nIHRoaXMgdXAsIGJ1dCBpdCBpc24ndCBvbiB0aGUgYWdlbmRhLCB3aGljaCBpcyBwcmV0dHkgZnVsbC4gwqAKClJlZ2FyZHMsCgotYmlsbAoKCk9uIFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTABMAEBAQE- X-Mailer: YahooMailWebService/0.8.196.685 References: <20140723052445.23752.69830.idtracker@ietfa.amsl.com> Message-ID: <1406093622.41540.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Tue, 22 Jul 2014 22:33:42 -0700 From: Bill Mills To: "kitten@ietf.org" In-Reply-To: <20140723052445.23752.69830.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-822746691-1406093622=:41540" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mNYYVBFb-IcKqNMRiIpW2i2oTC0 Subject: [kitten] Fw: Confirm submission of I-D draft-ietf-kitten-sasl-oauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 05:33:44 -0000 --515012262-822746691-1406093622=:41540 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sorry this took so long, it's the edits we talked about in London finally b= rought forward into a draft.=0A=0AI'll try to be in on the session tomorrow= remotely if anyone wants to bring this up, but it isn't on the agenda, whi= ch is pretty full. =A0=0A=0ARegards,=0A=0A-bill=0A=0A=0AOn Tuesday, July 22= , 2014 10:24 PM, IETF I-D Submission Tool wrote:=0A= =0A=0A=0A=0AHi,=0A=0AThe IETF datatracker draft submission service has rec= eived your draft=0Adraft-ietf-kitten-sasl-oauth-15, and requires a=0Aconfir= mation step in order to be able to complete the posting of=0Athe draft.=0A= =0APlease follow this link to the page where you can confirm the posting:= =0A=0Ahttp://datatracker.ietf.org/submit/status/61929/confirm/55a4d7e8d762e= 3f7663bb4819d09e66c/=0A=0A=0ABest regards,=0A=0A=A0=A0=A0 The IETF Secretar= iat=0A=A0=A0=A0 through the draft submission service --515012262-822746691-1406093622=:41540 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry this took so long, it's the edits we talked about = in London finally brought forward into a draft.

I'll try to be in o= n the session tomorrow remotely if anyone wants to bring this up, but it is= n't on the agenda, which is pretty full.  

Regards,

-bill


On Tuesday, July 22, 2014 10:24 PM, IETF I-D Submission Tool <idsubmission= @ietf.org> wrote:



Hi,

The IETF datatracker draft submission service has rece= ived your draft
draft-ietf-kitten-sasl-oauth-15, and requires a
confi= rmation step in order to be able to complete the posting of
the draft.
Please follow this link to the page where you can confirm the posting= :

http://datatracker.ie= tf.org/submit/status/61929/confirm/55a4d7e8d762e3f7663bb4819d09e66c/

Best regards,

    The IETF Secretariat
&n= bsp;   through the draft submission service




--515012262-822746691-1406093622=:41540-- From nobody Wed Jul 23 03:46:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191061A017E for ; Wed, 23 Jul 2014 03:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.594 X-Spam-Level: * X-Spam-Status: No, score=1.594 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m74Ky4QPYp_W for ; Wed, 23 Jul 2014 03:46:09 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BAB1A00A3 for ; Wed, 23 Jul 2014 03:46:08 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id s6NAk4BH030917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jul 2014 12:46:05 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <53CD270A.4030102@mit.edu> Date: Wed, 23 Jul 2014 12:46:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B295561-1AB0-481B-BCB0-6D8C1F106944@openfortress.nl> References: <93975EF5-D151-417E-8043-6B54D36FD9DC@openfortress.nl> <53CD270A.4030102@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/g7-D78IX0o1bwAv4YTTI7o59GFc Cc: kitten@ietf.org Subject: Re: [kitten] draft-ietf-kitten-kerberos-iana-registries -- KerberosFlags limited to 0..31? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 10:46:11 -0000 Hi, > I believe this is in deference to implementations which store flag > values in fixed 32-bit flags. I=92m fairly new to this list, so I may have missed that discussion. > If the IETF decides that this implementation cost is warranted, the > standards action which assigns the flag value could amend the registry > to accomodate it. So you are saying that the Kitten list has agreed to do it this way? IMHO, standards should not be dictated by software; it ought to be the other way around, thus celebrating the soft in software. It will take = long before we run over the 32 bits, and by then software could be adapted. Meanwhile, we=92re not introducing a =9364 kB ought to be enough for = everyone=94. But, if all this has been discussed in the past and the group has = decided in favour of the current proposal than I feel it is warranted to ignore = this opinion. -Rick= From nobody Wed Jul 23 06:39:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFCA1B27C0 for ; Wed, 23 Jul 2014 06:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyfq5szNplBH for ; Wed, 23 Jul 2014 06:39:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF21B27DC for ; Wed, 23 Jul 2014 06:39:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 129E7BDDC for ; Wed, 23 Jul 2014 14:39:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr73jgep0vkR for ; Wed, 23 Jul 2014 14:39:20 +0100 (IST) Received: from [31.133.172.66] (dhcp-ac42.meeting.ietf.org [31.133.172.66]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C14F8BDFE for ; Wed, 23 Jul 2014 14:39:19 +0100 (IST) Message-ID: <53CFBB06.4020108@cs.tcd.ie> Date: Wed, 23 Jul 2014 14:39:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8M80wlkBFtVH67m-2wy_CPWo9c8 Subject: [kitten] chair changes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:39:22 -0000 Hi all, After many years of service Sam is stepping down as co-chair. Josh unfortunately also has to step down due to $dayjob. I hope you'll join me in thanking them for all their work in the WG as chairs, and welcome them back as WG participants. I'm also delighted to say that Matt Miller and Benjamin Kaduk have agreed to join Shawn in chairing, so we're losing a couple of highly capable chairs, but gaining another pair. Thanks to all four and to Shawn for continuing, Cheers, Stephen. From nobody Wed Jul 23 07:32:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C501ABB25 for ; Wed, 23 Jul 2014 07:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8RsN5dYs1IK for ; Wed, 23 Jul 2014 07:32:24 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D56D1A005E for ; Wed, 23 Jul 2014 07:32:24 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-a8-53cfc7776f85 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id AC.15.25032.777CFC35; Wed, 23 Jul 2014 10:32:23 -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 s6NEWMkY020159 for ; Wed, 23 Jul 2014 10:32:22 -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 s6NEWK8I003386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 23 Jul 2014 10:32:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6NEWKJ7025896; Wed, 23 Jul 2014 10:32:20 -0400 (EDT) Date: Wed, 23 Jul 2014 10:32:20 -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+NgFjrFIsWRmVeSWpSXmKPExsUixG6nolt+/HywwfNuPoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9fcL4wF/XwV31oeMzcw7uDuYuTkkBAwkfjW/oEJwhaTuHBv PRuILSQwm0ni13n2LkYuIPs4o8Szb/PYIJwbTBLXfv+GyjQwSvz+/gAow8HBIqAtMfusJ0g3 m4CKxMw3G8EmiQgIS+ze+o4ZxBYWcJFYPXcfmM0r4Cjx/fVcsBpRAR2J1funsEDEBSVOznwC ZjMLWEr8W/uLdQIj3ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaU bmIEBROnJP8Oxm8HlQ4xCnAwKvHwduw9HyzEmlhWXJl7iFGSg0lJlJfxKFCILyk/pTIjsTgj vqg0J7X4EKMEB7OSCO/eQ0A53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwH h5IEr/sxoEbBotT01Iq0zJwShDQTByfIcB6g4a0gNbzFBYm5xZnpEPlTjLocKx6cbWMSYsnL z0uVEucNBSkSACnKKM2DmwNLAq8YxYHeEuYNA6niASYQuEmvgJYwAS15lQC2pCQRISXVwOj2 rmdlbPLkB8YRswL//p8QP3/etY6NQZnh8RmbjizYdcf34jkhM47QVjUNjquc6wS/x7Q1TBEw Zk/73epndnXJYde1ibV/uGaHyh3KDvt4b9uWdqcFJaUWv12jrixJrqtcNNdIw/T7mjf/9Mtl 986fx3v7S79u/S09N6bAXbnaFmlMpiHuTUosxRmJhlrMRcWJACV+8TbdAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CCD9g7M0-x0LrOthfnTiMx2HK54 Subject: [kitten] takeaways from the Toronto session (i.e., please volunteer) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:32:26 -0000 Hi all, Looking through my notes from Shawn's presentation, we need volunteers to pick up the following documents to issue a new revision addressing comments that have already been made: (1) draft-ietf-krb-wg-pkinit-alg-agility (2) draft-ietf-kitten-iakerb which is not actually a large list of documents needing new coauthors/editors. I think I can pick up IAKERB as I mentioned in the jabber room, so that just leaves pkinit-alg-agility. We also haven't heard much from Nico recently about draft-ietf-kitten-channel-bound-flag. Nico, do you think having a coauthor would help that move along faster? We also haven't had much movement on draft-ietf-kitten-sasl-saml-ec; if I remember correctly, Scott has been pretty busy and hasn't had time to work on it, but Shawn is going to talk with Scott and get a sense of how to move forward (so we are not necessarily looking for coauthors at this time). We also needed volunteers for a couple of other tasks (other than reviewing documents, for which we always welcome more help): (1) Coming up with initial entries for the gssapi-extensions-iana registry (and trying out the process/form for adding a new entry to the registry, if I understand correctly?) It sounded like Alexey wanted to try getting that done in-person in Toronto; please let us know if that proves to be inadequate. (2) Verifying the test vectors in the draft for the new AES enctypes. I said that I would try to do (2). And, of course, there are always more documents to review. Called out in particular were: draft-ietf-kitten-sasl-oauth-15 that just came out this morning draft-josefsson-kitten-gs2bis [several people volunteered to review draft-ietf-krb-wg-cammac during the meeting] Shawn, did I miss anything? -Ben From nobody Wed Jul 23 08:23:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF8C1A0B10 for ; Wed, 23 Jul 2014 08:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dQUDbkQ17Vx for ; Wed, 23 Jul 2014 08:23:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B911A0117 for ; Wed, 23 Jul 2014 08:23:44 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6NFNhJO023867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jul 2014 15:23:44 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s6NFNhgB005538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Jul 2014 15:23:43 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s6NFNfPp005476 for ; Wed, 23 Jul 2014 15:23:42 GMT Received: from dhcp-a2d7.meeting.ietf.org (/10.159.72.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Jul 2014 08:23:41 -0700 Message-ID: <53CFD37B.3000400@oracle.com> Date: Wed, 23 Jul 2014 09:23:39 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IDa-OigIrcPp4yTXmQlMxh0CDEA Subject: Re: [kitten] takeaways from the Toronto session (i.e., please volunteer) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 15:23:46 -0000 On 7/23/14 8:32 AM, Benjamin Kaduk wrote: > Hi all, > > Looking through my notes from Shawn's presentation, we need volunteers > to pick up the following documents to issue a new revision addressing > comments that have already been made: > (1) draft-ietf-krb-wg-pkinit-alg-agility > (2) draft-ietf-kitten-iakerb > which is not actually a large list of documents needing new > coauthors/editors. I think I can pick up IAKERB as I mentioned in the > jabber room, so that just leaves pkinit-alg-agility. > > We also haven't heard much from Nico recently about > draft-ietf-kitten-channel-bound-flag. Nico, do you think having a > coauthor would help that move along faster? > > We also haven't had much movement on draft-ietf-kitten-sasl-saml-ec; > if I remember correctly, Scott has been pretty busy and hasn't had > time to work on it, but Shawn is going to talk with Scott and get a > sense of how to move forward (so we are not necessarily looking for > coauthors at this time). > > We also needed volunteers for a couple of other tasks (other than > reviewing documents, for which we always welcome more help): > (1) Coming up with initial entries for the gssapi-extensions-iana > registry (and trying out the process/form for adding a new entry to > the registry, if I understand correctly?) It sounded like Alexey > wanted to try getting that done in-person in Toronto; please let us > know if that proves to be inadequate. We will meet during lunch tomorrow to start work on the registry subset. > (2) Verifying the test vectors in the draft for the new AES enctypes. > I said that I would try to do (2). > > And, of course, there are always more documents to review. Called out > in particular were: > draft-ietf-kitten-sasl-oauth-15 that just came out this morning Matt has volunteered to inspect this update, but would like more reviewers. > draft-josefsson-kitten-gs2bis > [several people volunteered to review draft-ietf-krb-wg-cammac during > the meeting] > > Shawn, did I miss anything? I had left out draft-ietf-kitten-kerberos-iana-registries. Tom had requested help in populating the registry. He had mentioned that there may be some entries for review in the near future. Are there any volunteers to help Tom define the Kerberos registry? Shawn. -- From nobody Wed Jul 23 08:27:49 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5A1B2919 for ; Wed, 23 Jul 2014 08:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdHp1LPN5Z0D for ; Wed, 23 Jul 2014 08:27:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151801B28B9 for ; Wed, 23 Jul 2014 08:27:45 -0700 (PDT) Received: from BN1AFFO11FD020.protection.gbl (10.58.52.32) by BN1AFFO11HUB067.protection.gbl (10.58.52.218) with Microsoft SMTP Server (TLS) id 15.0.980.11; Wed, 23 Jul 2014 15:27:43 +0000 Received: from cio-krc-pf05.osuad.osu.edu (164.107.81.212) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 15:27:43 +0000 Received: from CIO-KRC-HT03.osuad.osu.edu (cio-krc-ht03.osuad.osu.edu [164.107.81.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-krc-pf05.osuad.osu.edu (Postfix) with ESMTPS id D1F1D60059; Wed, 23 Jul 2014 11:27:42 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::b12f:aa15:1901:8bcc%10]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 11:27:41 -0400 From: "Cantor, Scott" To: Shawn M Emery , "kitten@ietf.org" Thread-Topic: [kitten] takeaways from the Toronto session (i.e., please volunteer) Thread-Index: AQHPpoL2Xi7OsA6jjEyYRj3LdelyQpuuCjCA//++EoA= Date: Wed, 23 Jul 2014 15:27:42 +0000 Message-ID: References: <53CFD37B.3000400@oracle.com> In-Reply-To: <53CFD37B.3000400@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.31.0.111] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.212; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(199002)(189002)(51704005)(24454002)(377454003)(479174003)(88552001)(47776003)(20776003)(95666004)(80022001)(23726002)(106116001)(74502001)(46406003)(76176999)(93346002)(50986999)(85306003)(107046002)(19580405001)(97756001)(50466002)(74662001)(89122001)(106466001)(31966008)(66066001)(99396002)(109096001)(2656002)(64706001)(77982001)(92726001)(44976005)(83322001)(86362001)(79102001)(83072002)(85852003)(75432001)(46102001)(81342001)(87936001)(36756003)(21056001)(77096002)(92566001)(54356999)(4396001)(107886001)(81542001)(19580395003)(6806004)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB067; H:cio-krc-pf05.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-krc-pf05.osuad.osu.edu; A:1; MX:1; LANG:en; X-OriginatorOrg: osu.edu X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 028166BF91 Received-SPF: Pass (: domain of osu.edu designates 164.107.81.212 as permitted sender) receiver=; client-ip=164.107.81.212; helo=cio-krc-pf05.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=cantor.2@osu.edu; Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1Z1ncne3YTKAnMIumXpQBoWe1zs Subject: Re: [kitten] takeaways from the Toronto session (i.e., please volunteer) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 15:27:47 -0000 On 7/23/14, 11:23 AM, "Shawn M Emery" wrote: >> >> We also haven't had much movement on draft-ietf-kitten-sasl-saml-ec; >> if I remember correctly, Scott has been pretty busy and hasn't had >> time to work on it, but Shawn is going to talk with Scott and get a >> sense of how to move forward (so we are not necessarily looking for >> coauthors at this time). Yes, I have a number of edits to do based on feedback from Sam and others but it's been languishing in my queue for the last few months. I recently finished implementing support for it in our upcoming IdP release, so this is not dead, just resting. -- Scott From nobody Wed Jul 23 10:33:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51FF1B2A1E for ; Wed, 23 Jul 2014 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqERFVR0m6EE for ; Wed, 23 Jul 2014 10:33:27 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047041B2BB8 for ; Wed, 23 Jul 2014 10:32:44 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-51-53cff1bb90cf Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 55.27.12039.BB1FFC35; Wed, 23 Jul 2014 13:32:43 -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 s6NHWgXl030763 for ; Wed, 23 Jul 2014 13:32:43 -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 s6NHWgp3006282 for ; Wed, 23 Jul 2014 13:32:42 -0400 From: Greg Hudson To: kitten@ietf.org Date: Wed, 23 Jul 2014 13:28:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6nrrv74/lgg42n9SyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBefTrEWvBGu+PFsMlsD4yn+LkZODgkBE4mHe5YzQdhiEhfu rWfrYuTiEBKYzSSxcOVWFpCEkMBxRonG36UQiQ4miaalM5hBEmwCyhIHz34DKxIREJbYvfUd WFxYQF5i78RnYDaLgKrEqnf/wGp4BQwlmk6dZoKwBSVOznwCFmcW0JK48e8l0wRGnllIUrOQ pBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQICg5OSd4djO8OKh1iFOBg VOLh7dh7PliINbGsuDL3EKMkB5OSKO/v90AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxr7wHl eFMSK6tSi/JhUtIcLErivG+trYKFBNITS1KzU1MLUotgsjIcHEoSvMIfgBoFi1LTUyvSMnNK ENJMHJwgw3mAhoPV8BYXJOYWZ6ZD5E8xKkqJ87qBXCQAksgozYPrhUXvK0ZxoFeEeV+AVPEA Ix+u+xXQYCagwa8SwAaXJCKkpBoYF397FuCiUtqwQjPFiytVP1SI6/RyD3GfpUu/9jw6qGHy /U0gl2DSDot1B66vb392XDhjzdt55+RS1FOfVbd97pXtuFKhtVa5Y+064bsHe3u7DXK7uS0O qL7fw/vGfNmyfaXzuAxONhin2ba4KU9/PEf+jc5+rykXv8ZXKBZmf4wqYHWYufi0EktxRqKh FnNRcSIAbcgfpLkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/eKvvhr43393Pm_01oSdjGVQ7Ulg Subject: [kitten] CAMMAC review comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:33:30 -0000 Shawn asked for more review of the CAMMAC draft. Here are my comments. All but one is a minor wording issue, and none of them are intended to be blocking. * "The svc-verifier element of the CAMMAC is equivalent to the ad-checksum element of AD-KDC-ISSUED" is true in the sense that svc-verifier has the same functional and security properties as ad-checksum, but is false in the sense of being precisely equivalent. svc-verifier uses the ticket encryption key, while ad-checksum uses the session key(*). * "The KDC thus avoids recomputing all of the authorization data" seems vague. I suggest adding "... for the issued ticket." * "A Verifier-MAC where the key is that of the local Ticket-Granting Service (TGS)" is phrased as if the local TGS only has one key. "... where the key is a long-term key of the local..." would be more correct. * "... and it is very difficult to have two such authorization data types coexist" would be more correctly phrased as "and it is very difficult for two such authorization data types to coexist." It also might be worth mentioning the non-standard authdata type we're thinking of (SignedPath) instead of just asserting that one exists. * Right now kdc-verifier is mandatory and svc-verifier is optional. I can foresee situations where kdc-verifier isn't needed: - If the KDC knows that all KDCs in its realm implement AD-CAMMAC, and therefore will filter out CAMMACs from authdata requested by clients, then it doesn't need any verifier at all for local TGTs. - If the KDC knows that the target service does not or cannot use S4U2Proxy, then it doesn't need to include a kdc-verifier. The svc-verifier is sufficient for ticket modification requests (such as renewals) which target the same server. If we do decide to make kdc-verifier optional, we probably need to add text saying that the KDC MUST NOT re-sign CAMMAC authdata unless it has a kdc-verifier, except in one of the above cases: a CAMMAC in a local TGT with configured assumptions about the other KDCs in the realm, or a CAMMAC with a valid svc-verifier in a ticket modification request. It would certainly be simpler, and therefore safer, to require a kdc-verifier in all cases. But ticket sizes are sometimes an issue, and unneeded checksums can contribute noticeably. (*) RFC 4120 is contradictory on what key ad-checksum should use, but all implementations use the session key as far as I know. From nobody Thu Jul 24 09:47:43 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2F61A04A2 for ; Thu, 24 Jul 2014 09:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEf0EstBkY6N for ; Thu, 24 Jul 2014 09:47:38 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 48DBA1A04C2 for ; Thu, 24 Jul 2014 09:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1406220455; d=isode.com; s=selector; i=@isode.com; bh=UzZNKr7jKq3CgwuB+AozGRabe9sQ9XbNhSl7gM4PlxU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Ce3KNPk3pIBa83S7zkQoV0p/5qtbVsA+6yxAr98PwxtKtt7nD0OiCzhH1Xv46pGeqQMkJK 3NA24hY9ZmCXrIqeWP2Ih67Cdmhe+1lDPkS7zhqbIBoaThRw1IVJloEYV1EdjdcpyMWUwM tgO9jOD1TR6dsqTCHLVNoEznUGpKQPo=; Received: from [31.133.167.13] (dhcp-a70d.meeting.ietf.org [31.133.167.13]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 24 Jul 2014 17:47:35 +0100 Message-ID: <53D138AC.60702@isode.com> Date: Thu, 24 Jul 2014 17:47:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/29T19EkleaWzhlKFWpv9Yu53pDk Subject: [kitten] Some test registrations according to draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:47:40 -0000 Shawn and I tried to register several items in the registry. Does this look reasonable (I am less sure about the last one, so please double check)? Bindings: C Registration type: Instance Object Type: Function Symbol Name: gss_init_sec_context Binding of: GSS_Init_sec_context Constant Value/Range: N/A Description: Create a security context by initiator Registration Rules: N/A Reference: RFC 2744 Expert Reviewer: Kitten WG Expert Review Notes: Status: Registered Obsoleting Reference: N/A Bindings: C Registration type: Instance Object Type: Function Symbol Name: gss_accept_sec_context Binding of: GSS_Accept_sec_context Constant Value/Range: N/A Description: Accept a security context from initiator Registration Rules: N/A Reference: RFC 2744 Expert Reviewer: Kitten WG Expert Review Notes: Status: Registered Obsoleting Reference: N/A Bindings: C Registration type: Instance Object Type: Context-Flag Symbol Name: GSS_C_DELEG_FLAG Binding of: deleg_state or deleg_req_flag Constant Value/Range: 1 Description: On output (if set): Delegated credentials are available via the delegated_cred_handle parameter of GSS_Accept_sec_context/GSS_Init_sec_context. On input (if set): requests delegation of access rights. Registration Rules: N/A Reference: RFC 2744 Expert Reviewer: Kitten WG Expert Review Notes: Status: Registered Obsoleting Reference: N/A From nobody Thu Jul 24 15:57:58 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F2D1A04F1 for ; Thu, 24 Jul 2014 15:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcXB8dg64lah for ; Thu, 24 Jul 2014 15:57:55 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E6E1A041D for ; Thu, 24 Jul 2014 15:57:55 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id s6OMvsBu024726 for ; Thu, 24 Jul 2014 15:57:55 -0700 Received: from vpn-135-70-98-163.vpn.swst.att.com ([135.70.98.163]) by maillennium.att.com (mailgw1) with ESMTP id <20140724225753gw100j0cmee>; Thu, 24 Jul 2014 22:57:53 +0000 X-Originating-IP: [135.70.98.163] Message-ID: <53D18F6F.1060204@att.com> Date: Thu, 24 Jul 2014 18:57:51 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: kitten@ietf.org References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> In-Reply-To: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050309010005030101000208" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nVX3F6c7urilFSOkWZ5UDEVH2EY Subject: [kitten] Fwd: I-D Action: draft-hansen-scram-sha256-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:57:57 -0000 This is a multi-part message in MIME format. --------------050309010005030101000208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I just posted this update to the document I circulated back in April, registering SCRAM-SHA-256 as a SASL mechanism. I added Minimum iteration-count and OID to the registration form for SCRAM-* registrations. I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. This should probably be discussed further. One question I have for this: would it be worth change SCRAM registrations to Expert Review in place of IETF review? There was discussion in the HTTPAUTH working group this morning, asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 being discussed in Alexey's draft. An open question is whether this could/should become a working group draft. I am happy with it being handled either that way or keeping it an individual AD-sponsored draft. (I've already spoken with Steven and Kathleen about that possibility.) Tony Hansen -------- Original Message -------- Subject: I-D Action: draft-hansen-scram-sha256-01.txt Date: Thu, 24 Jul 2014 15:49:56 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms Author : Tony Hansen Filename : draft-hansen-scram-sha256-01.txt Pages : 5 Date : 2014-07-24 Abstract: This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- SHA-256-PLUS. It also updates RFC 5802 in minor ways. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-hansen-scram-sha256-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------050309010005030101000208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I just posted this update to the document I circulated back in April, registering SCRAM-SHA-256 as a SASL mechanism.

I added Minimum iteration-count and OID to the registration form for SCRAM-* registrations.

I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. This should probably be discussed further.

One question I have for this: would it be worth change SCRAM registrations to Expert Review in place of IETF review?

There was discussion in the HTTPAUTH working group this morning, asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 being discussed in Alexey's draft.

An open question is whether this could/should become a working group draft. I am happy with it being handled either that way or keeping it an individual AD-sponsored draft. (I've already spoken with Steven and Kathleen about that possibility.)

    Tony Hansen

-------- Original Message --------
Subject: I-D Action: draft-hansen-scram-sha256-01.txt
Date: Thu, 24 Jul 2014 15:49:56 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms
        Author          : Tony Hansen
	Filename        : draft-hansen-scram-sha256-01.txt
	Pages           : 5
	Date            : 2014-07-24

Abstract:
   This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
   SHA-256-PLUS.  It also updates RFC 5802 in minor ways.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hansen-scram-sha256-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------050309010005030101000208-- From nobody Mon Jul 28 09:23:32 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE51A0342 for ; Mon, 28 Jul 2014 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPGKVRo6J5O4 for ; Mon, 28 Jul 2014 09:23:07 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35261A033B for ; Mon, 28 Jul 2014 09:23:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C55DC20162 for ; Mon, 28 Jul 2014 12:20: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 eMQ3pWHV03HL for ; Mon, 28 Jul 2014 12:20:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 28 Jul 2014 12:20:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BB118800C0; Mon, 28 Jul 2014 12:23:01 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Mon, 28 Jul 2014 12:23:01 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/D_mTgtqETKkxmnV_73nImDE_sV0 Subject: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 16:23:15 -0000 Section 4: I expect advice on whether this should be contained in ad-if-relevant and on how an implementation that does understand this element should process contained elements that it does not understand. I believe this comment needs to be addressed prior to publication. Section 5/6: This document registers a new authorization data container but does not provide a way to use that container. Any authorization data designed to fit within that container would require action from this working group either to publish a document describing that authorization data or a document establishing an IANA registry for authorization data. I think that publishing a new authorization data container without a way to legitimately use it dis not in the IETF's interest. Either it won't get used until we publish some document, in which case we're better off holding off until that document is published and gaining implementation experience with both. Alternatively, it will get used by someone squatting on a number, which is bad. My recommendation is that we move the authorization data registry from Kerberos IANA to section 6 here and remove section 5. I feel reasonably strongly that publishing this document without either an IETF consumer or an IANA registry is bad. Section 7: We only bind to the encrypted ticket part. A KDC knows from the MAC verification that it issued a ticket with the given encrypted part, but has no confidence from that information what service key it encrypted that ticket in nor the service name in the outer ticket. How is a KDC supposed to make sure this authorization container was issued to the service that claims to have received it. At one level, you could argue that's a general issue with s4u and similar. At another level, we're introducing those mechanisms into the IETF here, so I think we need to discuss that issue here. we could either solve it in this document by including the principal name to which the ticket is issued in something covered by the KDC MAC. The obvious solution there would be to define an authorization data element for an interested KDC to include. Alternatively we could include an octet-string for KDC internal usage that is covered by the MAC. If we establish an IANA registry for authorization data types with expert review or more liberal of a registration policy, then we could document the issue without providing an explicit solution. From nobody Tue Jul 29 10:37:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF901B299B for ; Tue, 29 Jul 2014 10:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipMxlmy4tx1A for ; Tue, 29 Jul 2014 10:37:43 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B101B295D for ; Tue, 29 Jul 2014 10:37:41 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-95-53d7dbe46c08 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 60.19.32177.4EBD7D35; Tue, 29 Jul 2014 13:37:40 -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 s6THbdjA008688; Tue, 29 Jul 2014 13:37:40 -0400 Received: from [18.101.8.185] (vpn-18-101-8-185.mit.edu [18.101.8.185]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6THbcOl017394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 13:37:38 -0400 Message-ID: <53D7DBE2.3010105@mit.edu> Date: Tue, 29 Jul 2014 13:37:38 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sam Hartman , kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrvvk9vVggxeb5C2+tj1gszi6eRWL A5PHkiU/mTxWTj3NHsAUxWWTkpqTWZZapG+XwJXRseUHa8En7oqJ99vZGxhPcHYxcnJICJhI HOhsYYawxSQu3FvP1sXIxSEkMJtJ4sHGncwQzkZGict/fjJCOEeYJFau2skG0sIroCbROWsB I4jNIqAq8f5pL5jNJqAscfDsNxYQW1QgTOLxnHOMEPWCEidnPgGLiwhYSHzYeAlstbCAjcSb 3fNZQWwhoDn7Hj0Hm88JNP/99DZWiPMkJbYtOsYOYjML6Ei863vADGHLS2x/O4d5AqPgLCQr ZiEpm4WkbAEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYygEOaU5NvB+PWg 0iFGAQ5GJR7eDXOvBQuxJpYVV+YeYpTkYFIS5d189XqwEF9SfkplRmJxRnxRaU5q8SFGCQ5m JRHeFpAcb0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mCl/EWUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8Gs3QYYXFyTmFmemQ+RPMSpKifPOAUkIgCQySvPgemEp5hWjONAr wry3QKp4gOkJrvsV0GAmoMGsLmCDSxIRUlINjDOXBgTO5NvE+mt/VOsmOdNvJr+P3lptU2B5 8rt2FN9OPr2Nc4snTbPq3ZMs+cj596rJDtKuAWdXu8nu28Z2OSb0ePzuzi9nmsKL1m5+vqfq vyXXpsxVN2c9Oe5e8Piteon/QW8h1RtrZeQaLzcs+P+grOiVZouesN6vtaVRTrMeiBhYH2I3 71ZiKc5INNRiLipOBABBiAdADAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/A1rHrTrpzMIEDU669cdvP_2zx2o Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 17:37:50 -0000 On 07/28/2014 12:23 PM, Sam Hartman wrote: > I expect advice on whether this should be contained in ad-if-relevant > and on how an implementation that does understand this element should > process contained elements that it does not understand. My preference is to: * Advise that CAMMACs be put inside AD-IF-RELEVANT. * Specify that authdata contained within a CAMMAC should be considered non-critical. (That is, you don't have to wrap everything inside a CAMMAC in AD-IF-RELEVANT.) RFC 4120 already does this for AD-KDC-ISSUED (section 5.2.6.2, last paragraph), presumably under the assumption that it is used for positive rather than negative authdata. > This document registers a new authorization data container but does not > provide a way to use that container. I'm not sure I agree with your reasoning, but improving the authdata registry would be a good thing, so I don't mind if we do what you suggest here. > We only bind to the encrypted ticket part. A KDC knows from the MAC > verification that it issued a ticket with the given encrypted part, but > has no confidence from that information what service key it encrypted > that ticket in nor the service name in the outer ticket. To read the CAMMAC, the KDC had to decrypt the ticket it came from using a key for the purported service principal. Is the concern here about principal entries with multiple names? I'm not sure there are any interesting attacks here, since all of the names refer to the same principal. From nobody Tue Jul 29 18:51:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3F1B2A25 for ; Tue, 29 Jul 2014 18:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW7Gp_bLQN7V for ; Tue, 29 Jul 2014 18:51:02 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA591B2A27 for ; Tue, 29 Jul 2014 18:51:01 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-88-53d84f843e35 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id DD.82.30080.48F48D35; Tue, 29 Jul 2014 21:51:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s6U1ox3c006505; Tue, 29 Jul 2014 21:51:00 -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 s6U1ovl1002936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2014 21:50:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6U1ovUG014713; Tue, 29 Jul 2014 21:50:57 -0400 (EDT) Date: Tue, 29 Jul 2014 21:50:57 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <53D7DBE2.3010105@mit.edu> Message-ID: References: <53D7DBE2.3010105@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+NgFnrDIsWRmVeSWpSXmKPExsUixG6notvifyPYYO1CXYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGW0XT3AXLCYu+LY1AnMDYwzOLsYOTkkBEwk th96zQZhi0lcuLceyObiEBKYzSSxYs8qVghnI6PE7/sPmSCcQ0wSX59uhXIaGCVWtWwE62cR 0Jb4OvcjmM0moCIx8w1EXERAUeL3yreMIDazgIVEx9GJLCC2sICNxJvd81lBbE4BdYlzC/uA ajg4eAUcJV53BYGYQgIOEq2LjUEqRAV0JFbvnwLWySsgKHFy5hMWiImWEv/W/mKdwCg4C0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGMGB6qK8g/HPQaVDjAIc jEo8vDP+Xw8WYk0sK67MPcQoycGkJMo7Q/9GsBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3q9y QDnelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpisDAeHkgSvgR9Qo2BRanpqRVpm TglCmomDE2Q4D9BwL5Aa3uKCxNzizHSI/ClGRSlxXltfoIQASCKjNA+uF5ZIXjGKA70izNsG 0s4DTEJw3a+ABjMBDX5+6zrI4JJEhJRUA2Pd5hsR29Y6639TnBCze5a1dfjLOxtrZnx5Yyha sa5l4XX1lUW+Nq6fRUSqjq/+Y/3o+YkbApL1pbf+lHL+2HuSTzs8VPZe5meN7kWHgngPBzaq cb0wfuv+4/F7/r/bjAR/sx+vmPdOvu5GeJPKxV47kWlles6Pqi+ePNb4XE8t4/oBs5WhIpxK LMUZiYZazEXFiQA2tN8t/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oqm5BLL4yKkeisltTRTAQJ1AYFE Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 01:51:03 -0000 On Tue, 29 Jul 2014, Greg Hudson wrote: > On 07/28/2014 12:23 PM, Sam Hartman wrote: >> I expect advice on whether this should be contained in ad-if-relevant >> and on how an implementation that does understand this element should >> process contained elements that it does not understand. > > My preference is to: > > * Advise that CAMMACs be put inside AD-IF-RELEVANT. > > * Specify that authdata contained within a CAMMAC should be considered > non-critical. (That is, you don't have to wrap everything inside a > CAMMAC in AD-IF-RELEVANT.) RFC 4120 already does this for AD-KDC-ISSUED > (section 5.2.6.2, last paragraph), presumably under the assumption that > it is used for positive rather than negative authdata. It looks like we discussed the AD-IF-RELEVANT situation back in November, but the discussion fizzled out without reaching a real conclusion. Jeff's point in http://www.ietf.org/mail-archive/web/kitten/current/msg04425.html that we're designing a generic container because the previous generic container wasn't good enough, so we should probably make sure this one is generic enough seems pretty compelling on first re-read. On the other hand, Greg's reply to that message is also pretty compelling, namely, that de facto we cannot create any critical authdata and expect them to be actually treated as critical. It would probably be good for people to review that thread. -Ben From nobody Wed Jul 30 04:46:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF281B278F for ; Wed, 30 Jul 2014 04:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJGoplaWCGbM for ; Wed, 30 Jul 2014 04:46:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1C91B279E for ; Wed, 30 Jul 2014 04:46:16 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6UBkGTh006025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Jul 2014 07:46:16 -0400 Received: from [10.3.113.33] (ovpn-113-33.phx2.redhat.com [10.3.113.33]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6UBkBT4022466; Wed, 30 Jul 2014 07:46:12 -0400 Message-ID: <1406720770.3242.7.camel@willson.usersys.redhat.com> From: Simo Sorce To: Benjamin Kaduk Date: Wed, 30 Jul 2014 07:46:10 -0400 In-Reply-To: References: <53D7DBE2.3010105@mit.edu> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UDY3pGu6dQSkbBChrm9FmERxEBc Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 11:46:21 -0000 On Tue, 2014-07-29 at 21:50 -0400, Benjamin Kaduk wrote: > On Tue, 29 Jul 2014, Greg Hudson wrote: > > > On 07/28/2014 12:23 PM, Sam Hartman wrote: > >> I expect advice on whether this should be contained in ad-if-relevant > >> and on how an implementation that does understand this element should > >> process contained elements that it does not understand. > > > > My preference is to: > > > > * Advise that CAMMACs be put inside AD-IF-RELEVANT. > > > > * Specify that authdata contained within a CAMMAC should be considered > > non-critical. (That is, you don't have to wrap everything inside a > > CAMMAC in AD-IF-RELEVANT.) RFC 4120 already does this for AD-KDC-ISSUED > > (section 5.2.6.2, last paragraph), presumably under the assumption that > > it is used for positive rather than negative authdata. > > It looks like we discussed the AD-IF-RELEVANT situation back in November, > but the discussion fizzled out without reaching a real conclusion. > Jeff's point in > http://www.ietf.org/mail-archive/web/kitten/current/msg04425.html that > we're designing a generic container because the previous generic container > wasn't good enough, so we should probably make sure this one is generic > enough seems pretty compelling on first re-read. On the other hand, > Greg's reply to that message is also pretty compelling, namely, that de > facto we cannot create any critical authdata and expect them to be > actually treated as critical. It would probably be good for people to > review that thread. I thought we concluded that CAMMAC does not need to be wrapped in AD-IF-RELEVANT because it has the same properties by definition and therefore is always non critical as well, but I would not mind specifying it has to be wrapped in AD-IF-RELEVANT for best compatibility. Perhaps I convinced myself we addressed the issue and then failed to make it really explicit in the text, thanks Sam for being thorough, we certainly need to add language similar to the AD-KDC-ISSUED text to make it clear. Also I do not think we need to create any specific registry with the CAMMAC specification, the intention is that the CAMMAC can contain the same AD data you would put in AD-IF-RELEVANT, just that the data is "certified" by the KDC. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Jul 30 08:02:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF621A0180 for ; Wed, 30 Jul 2014 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7DhNrkK9Q5Y for ; Wed, 30 Jul 2014 08:02:14 -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 5ACB21A01AC for ; Wed, 30 Jul 2014 08:02:14 -0700 (PDT) X-AuditID: 12074422-f79be6d000007518-cf-53d908f55700 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id BC.17.29976.5F809D35; Wed, 30 Jul 2014 11:02:13 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6UF2C8x008228; Wed, 30 Jul 2014 11:02:13 -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 s6UF2AjM018442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2014 11:02:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6UF29x4023605; Wed, 30 Jul 2014 11:02:09 -0400 (EDT) Date: Wed, 30 Jul 2014 11:02:09 -0400 (EDT) From: Benjamin Kaduk To: Simo Sorce In-Reply-To: <1406720770.3242.7.camel@willson.usersys.redhat.com> Message-ID: References: <53D7DBE2.3010105@mit.edu> <1406720770.3242.7.camel@willson.usersys.redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrPuV42awQXO/isXRzatYLH7MXcTq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGXc71nHXDCfpaL56GT2Bsa1zF2MnBwSAiYS e/b/ZISwxSQu3FvP1sXIxSEkMJtJ4sC7+0wQzkZGiesbZrFCOIeYJL5uuc4O0iIk0MAosf6c JojNIqAtse/wJxYQm01ARWLmm41sILaIgILEgv47YHFmAWGg8hlgq4UFbCTe7J7PCmJzCjhK fJ54EszmBbJnLT0ItXkNo8SDjQvBlokK6Eis3j+FBaJIUOLkzCdQQy0lzv25zjaBUXAWktQs JKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxgoKV3UVpB+PPg0qHGAU4 GJV4eGf8vx4sxJpYVlyZe4hRkoNJSZT3390bwUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJex 3wwW4k1JrKxKLcqHSUlzsCiJ8761tgoWEkhPLEnNTk0tSC2CycpwcChJ8P4GaRQsSk1PrUjL zClBSDNxcIIM5wEazsoBMry4IDG3ODMdIn+KUZdj0f6X3UxCLHn5ealS4rzf2YCKBECKMkrz 4ObAkswrRnGgt4R5r4Gs4wEmKLhJr4CWMAEteX7rOsiSkkSElFQDo8n5JWmzF11wWiyXXK7y hkn5brqJtfYduaCuqT3/z6QvCZxXH6GQ05d83nBNQbudav8xyTSL6IefMv+ccDC1Csm/8FRN ctGMO59X/n0rp9sj8taRc+nBdbNbNvtMWf/ul0ubw/5u0UyGVZO5551bNNWfLenylL/9u16X 5P9ed926u6y4JenPdSWW4oxEQy3mouJEADLWh70NAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fWIKI_uNO8iRK8Uzv2chv-GQLUs Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:02:25 -0000 On Wed, 30 Jul 2014, Simo Sorce wrote: > I thought we concluded that CAMMAC does not need to be wrapped in > AD-IF-RELEVANT because it has the same properties by definition and > therefore is always non critical as well, but I would not mind > specifying it has to be wrapped in AD-IF-RELEVANT for best > compatibility. I had some memories of coming to this conclusion as well, but don't see anything in the list archive or meeting minutes. Maybe it was from discussion on one of the krb5 development conference calls. -Ben From nobody Wed Jul 30 08:20:16 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F111A0108; Wed, 30 Jul 2014 07:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0306-3H9F1i; Wed, 30 Jul 2014 07:47:47 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE21B1A00A7; Wed, 30 Jul 2014 07:47:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,764,1400050800"; d="scan'208";a="137317649" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 30 Jul 2014 07:47:46 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 30 Jul 2014 07:47:46 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 30 Jul 2014 07:47:45 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Wed, 30 Jul 2014 07:47:45 -0700 From: "Adamson, Andy" To: NFSv4 Thread-Topic: draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeQ== Date: Wed, 30 Jul 2014 14:47:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41BFC27B497E0B4DAAF23D5BB21D3962@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/z_r6LGbtHAPBb5_RWoR2g_niCJQ X-Mailman-Approved-At: Wed, 30 Jul 2014 08:20:03 -0700 Cc: "kitten@ietf.org" Subject: [kitten] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:47:48 -0000 Hello I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he= agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten WG as= well as to the NFSv4 WG to solicit reviews. Please review the draft which= adds two new RPCSEC GSS operations and is a normative reference to draft-i= etf-nfsv4-minorversion2. As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit = your reviews by Aug 31, 2014. https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 Thanks =97>Andy Adamson= From nobody Wed Jul 30 13:09:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D411F1A0290; Wed, 30 Jul 2014 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5DcgRcae7F1; Wed, 30 Jul 2014 09:30:08 -0700 (PDT) Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A771A02FA; Wed, 30 Jul 2014 09:30:08 -0700 (PDT) Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1XCWlS-0001ui-Bc; Wed, 30 Jul 2014 12:30:06 -0400 Date: Wed, 30 Jul 2014 12:30:06 -0400 To: "Adamson, Andy" Message-ID: <20140730163006.GG26316@fieldses.org> 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) From: "J. Bruce Fields" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/maZ4zRKjSrwzs4Ry_4_1KCT1BWY X-Mailman-Approved-At: Wed, 30 Jul 2014 13:08:55 -0700 Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:30:12 -0000 On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote: > Hello > > I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten WG as well as to the NFSv4 WG to solicit reviews. Please review the draft which adds two new RPCSEC GSS operations and is a normative reference to draft-ietf-nfsv4-minorversion2. > > As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit your reviews by Aug 31, 2014. > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 I'm confused by multi-principal authentication: The RPCSEC_GSS_CREATE request should demonstrate that the caller knows both parent and child's credentials. That's easy for the parent since an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request sent as the parent. For the child the caller has to calculate the mic of a nonce using the child context, but as far as I can tell the choice of nonce is entirely up to the caller. Couldn't it then just choose as the nonce some data that it had previously seen a mic for? If so, would it work to remove the nonce and instead calculate, say, a mic of the rpc header (as we do when calculating the verifier?). Apologies if the question's already answered somewhere. I'm not sure about the reply either: On a successful reply, the rgss3_gss_mp_auth field in the rgss3_create_res reply uses the parent RPCSEC_GSSv3 context as the rgmp_handle, the same rgmp_nounce as was sent in the call data with the rgmp_nounce_mic created using the GSS-API security context associate with the parent handle. Verification of the rbg_nounce_mic by the initiator demonstrates that the target agrees to the multi-principal authentication. "The target" here is ambiguous. The reply is already authenticated as the parent, the problem again is authenticating as the child, so I think it should be calculating a mic using the child context (maybe over the header data again, as in section 2.3?). (Also, note the draft uses at least "nonce", "nounc", and "nounce", a spellcheck would help here.) --b. From nobody Wed Jul 30 14:14:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1DF1A063F for ; Wed, 30 Jul 2014 14:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec8XifWZrj4D for ; Wed, 30 Jul 2014 14:14:27 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF6C1A061D for ; Wed, 30 Jul 2014 14:14:21 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-43-53d9602c568a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.76.12039.C2069D35; Wed, 30 Jul 2014 17:14:20 -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 s6ULEJ8n024541; Wed, 30 Jul 2014 17:14:20 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6ULEIoE025649; Wed, 30 Jul 2014 17:14:19 -0400 From: Tom Yu To: Greg Hudson References: Date: Wed, 30 Jul 2014 17:14:18 -0400 In-Reply-To: (Greg Hudson's message of "Wed, 23 Jul 2014 13:28:36 -0400") Message-ID: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUixCmqrKuTcDPYoOW/rsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMe/uJpaCx1wVPcu2sTQwbuToYuTkkBAwkZi44j0jhC0mceHe erYuRi4OIYHZTBIz915igXA2MkrMmHmVDaRKSOANo8SO6WldjBwcbALSEkcXl4GERQQUJZ6t mssCYjMLiEqcW3eEFaREWEBH4tvWUohOQ4kljzczg9gsAqoSy97eZgEp4RQolJh0XQrE5BXQ leiclQ5SwSPAKfFmQw/YZbwCghInZz6BGq4lcePfS6YJjAKzkKRmIUktYGRaxSibklulm5uY mVOcmqxbnJyYl5dapGukl5tZopeaUrqJERx0krw7GN8dVDrEKMDBqMTD+8PkZrAQa2JZcWXu IUZJDiYlUV7TYKAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4uT6Acb0piZVVqUT5MSpqDRUmc 9621VbCQQHpiSWp2ampBahFMVoaDQ0mCd1ccUKNgUWp6akVaZk4JQpqJgxNkOA/Q8OMgNbzF BYm5xZnpEPlTjIpS4ryyIAkBkERGaR5cLywpvGIUB3pFmPckSBUPMKHAdb8CGswENPj5resg g0sSEVJSDYzOt9ZwnXx4PFpT8MWpGVzuMpyuqa/FLyj3W2+wa95noNWwszzF40OiXHTFs6XK ghqFsVUdZ9JPMU3OF/rC+zHlSs3+2SZXTlS0Ny1s6s1rVxI4AEyc9V2XPDm3RDTH7X+xWrzH dE3HKoOmnxrOKUUMk432LtSaILwzZ3L050mJxYwVPyoXKbEUZyQaajEXFScCAAICp3zlAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/srliyAFfvQv58yaLAq7vIVRh2ow Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC review comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:14:28 -0000 Greg Hudson writes: > * Right now kdc-verifier is mandatory and svc-verifier is optional. I > can foresee situations where kdc-verifier isn't needed: > > - If the KDC knows that all KDCs in its realm implement AD-CAMMAC, and > therefore will filter out CAMMACs from authdata requested by > clients, then it doesn't need any verifier at all for local TGTs. > > - If the KDC knows that the target service does not or cannot use > S4U2Proxy, then it doesn't need to include a kdc-verifier. The > svc-verifier is sufficient for ticket modification requests (such as > renewals) which target the same server. > > If we do decide to make kdc-verifier optional, we probably need to add > text saying that the KDC MUST NOT re-sign CAMMAC authdata unless it > has a kdc-verifier, except in one of the above cases: a CAMMAC in a > local TGT with configured assumptions about the other KDCs in the > realm, or a CAMMAC with a valid svc-verifier in a ticket modification > request. > > It would certainly be simpler, and therefore safer, to require a > kdc-verifier in all cases. But ticket sizes are sometimes an issue, > and unneeded checksums can contribute noticeably. Thanks, Greg. I think making kdc-verifier optional is a useful and reasonable change to consider. Does anyone else agree? From nobody Wed Jul 30 15:45:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDAF1A01A8 for ; Wed, 30 Jul 2014 15:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vds18xJpBFJn for ; Wed, 30 Jul 2014 15:45:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604F01A0064 for ; Wed, 30 Jul 2014 15:45:34 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6UMjXrM015612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Jul 2014 18:45:33 -0400 Received: from [10.3.113.33] (ovpn-113-33.phx2.redhat.com [10.3.113.33]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6UMjT5w012336; Wed, 30 Jul 2014 18:45:30 -0400 Message-ID: <1406760327.30289.23.camel@willson.usersys.redhat.com> From: Simo Sorce To: Tom Yu Date: Wed, 30 Jul 2014 18:45:27 -0400 In-Reply-To: References: Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3JR1FT7n4S3bQ_vu8FVhA-l1wbU Cc: kitten@ietf.org Subject: Re: [kitten] CAMMAC review comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 22:45:36 -0000 On Wed, 2014-07-30 at 17:14 -0400, Tom Yu wrote: > Greg Hudson writes: > > > * Right now kdc-verifier is mandatory and svc-verifier is optional. I > > can foresee situations where kdc-verifier isn't needed: > > > > - If the KDC knows that all KDCs in its realm implement AD-CAMMAC, and > > therefore will filter out CAMMACs from authdata requested by > > clients, then it doesn't need any verifier at all for local TGTs. So here we are relying on the fact the AD data is encrypted with the krbtgt key and therefore implicitly validated, right ? > > - If the KDC knows that the target service does not or cannot use > > S4U2Proxy, then it doesn't need to include a kdc-verifier. The > > svc-verifier is sufficient for ticket modification requests (such as > > renewals) which target the same server. > > > > If we do decide to make kdc-verifier optional, we probably need to add > > text saying that the KDC MUST NOT re-sign CAMMAC authdata unless it > > has a kdc-verifier, except in one of the above cases: a CAMMAC in a > > local TGT with configured assumptions about the other KDCs in the > > realm, or a CAMMAC with a valid svc-verifier in a ticket modification > > request. > > > > It would certainly be simpler, and therefore safer, to require a > > kdc-verifier in all cases. But ticket sizes are sometimes an issue, > > and unneeded checksums can contribute noticeably. > > Thanks, Greg. I think making kdc-verifier optional is a useful and > reasonable change to consider. Does anyone else agree? I think the kdc-verifier could be made optional, though I am not sure why anyone would go through the trouble of disabling it using complex heuristics to save a few bytes unless the CAMMAC payload is very small. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Jul 31 13:13:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A771A00C2 for ; Thu, 31 Jul 2014 13:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0ZK1FsPYzF9 for ; Thu, 31 Jul 2014 13:12:49 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D511A0137 for ; Thu, 31 Jul 2014 13:12:44 -0700 (PDT) Received: from [192.168.1.115] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s6VKCZI1008428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 16:12:42 -0400 (EDT) Message-ID: <1406837555.8950.10.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Benjamin Kaduk Date: Thu, 31 Jul 2014 16:12:35 -0400 In-Reply-To: References: <53D7DBE2.3010105@mit.edu> <1406720770.3242.7.camel@willson.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/K5FZY14JOyXgt1lRMu4f_s-reew Cc: kitten@ietf.org, Simo Sorce , jhutz@cmu.edu Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 20:12:52 -0000 On Wed, 2014-07-30 at 11:02 -0400, Benjamin Kaduk wrote: > On Wed, 30 Jul 2014, Simo Sorce wrote: > > > I thought we concluded that CAMMAC does not need to be wrapped in > > AD-IF-RELEVANT because it has the same properties by definition and > > therefore is always non critical as well, but I would not mind > > specifying it has to be wrapped in AD-IF-RELEVANT for best > > compatibility. > > I had some memories of coming to this conclusion as well, but don't see > anything in the list archive or meeting minutes. Maybe it was from > discussion on one of the krb5 development conference calls. Well, I'm glad my opinion today is more or less consistent with my opinion of almost a year ago... I think we only have two reasonable choices: 1) Accept that implementations don't treat unrecognized auth-data as critical and will never be fixed sufficiently well to be depended upon, and give up on ever being able to have critical AD. 2) Attempt to build a protocol suite which, if implemented correctly, allows a KDC or client to place critical constraints on the use of a ticket. If we choose (1), then we should say so. New containers such as AD-CAMMAC should (always) be wrapped in AD-IF-RELEVANT, for compatibility, and the data they wrap should be considered non-critical, not as a result of the definition of the new container but because we've given up on AD ever being critical. If we choose (2), then being able to have authorization data which is both critical and authenticated seems fairly important, and having AD-CAMMAC imply non-criticality of the wrapped elements would prevent that. So, it shouldn't do that. However, it seems reasonable for AD-IF-RELEVANT(AD-CAMMAC(...)) to indicate that both the AD-CAMMAC and everything it wraps are non-critical(*). Regardless of which option we choose, the authorization data contained within AD-IF-RELEVANT(AD-CAMMAC(...)) is non-critical. In fact, regardless of which option we choose, AD-CAMMAC does not affect the criticality (or lack thereof) of the things it wraps. So really, this just boils down to whether we are ready to make a statement that Kerberos doesn't really have critical authorization data after all. -- Jeff (*) Note that this is _not_ the same as AD-IF-RELEVANT implying non-criticality for everything contained within it down to every depth. In particular, it is possible to imagine a container which can safely ignored in its entirety, but for which ignoring individual contained elements produces the wrong effect. From nobody Thu Jul 31 15:38:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA591A0135; Thu, 31 Jul 2014 15:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ESTABLISH2=2.492, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xibvK8C8TYQT; Thu, 31 Jul 2014 15:38:17 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3031A0115; Thu, 31 Jul 2014 15:38:16 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-f6-53dac557b52b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.5A.25032.755CAD35; Thu, 31 Jul 2014 18:38:15 -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 s6VMcDuB025862; Thu, 31 Jul 2014 18:38:15 -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 s6VMcAi6007760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2014 18:38:12 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6VMc9bn001337; Thu, 31 Jul 2014 18:38:09 -0400 (EDT) Date: Thu, 31 Jul 2014 18:38:09 -0400 (EDT) From: Benjamin Kaduk To: "Adamson, Andy" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrRt+9FawwZQjyhZHN69isZj9/hGr xfRFVg7MHkuW/GTymPHpC1sAUxSXTUpqTmZZapG+XQJXxvs7F9gL9sVW/Fit0cC42LuLkZND QsBEYs3NJ4wQtpjEhXvr2boYuTiEBGYzScxo3g/lbGSUWHB1GQuEc4hJYn/XFqhMA6PEug0T wPpZBLQlJj4/yw5iswmoSMx8sxGoiINDRMBAYuNSVZAws4C9xMJPr1hBbGEBN4nmV7+YQWxO ATuJN9f3AS1g5+AVcJRY5wfSKCRgK3FmvwFIgaiAjsTq/VNYQGxeAUGJkzOfsEAMtJT4t/YX 6wRGwVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdHLzSzRS00p3cQIDlVJ/h2M 3w4qHWIU4GBU4uF1CL0VLMSaWFZcmXuIUZKDSUmUN/EwUIgvKT+lMiOxOCO+qDQntfgQowQH s5IIb8FWoBxvSmJlVWpRPkxKmoNFSZz3rbVVsJBAemJJanZqakFqEUxWhoNDSYK3DmSoYFFq empFWmZOCUKaiYMTZDgP0PArIDW8xQWJucWZ6RD5U4yKUuK8Hw4BJQRAEhmleXC9sFTyilEc 6BVhiHYeYBqC634FNJgJaPDzW9dBBpckIqSkGhhz1jrdCBd4wZ2j1F3VzFdtHPiy7aPKa/uk BYekgnT+8Bz53BMf/z3lxuSM6ODaRd8uCQgtu7y0rXinvM+rkj1qLfv/sS6e3zX9oPafbyer u+y/+lRI1vtInY0qU4ruqEk5XbpO8rz/ymeCR7iPZj1aOkVb3+D9vBfsbon22tHvFvHPMg+s rlRiKc5INNRiLipOBABhh7LOAAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CUwuP9s0dK3_YuiPflJOIgSHpnc Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:38:20 -0000 Hmm, this seems to have gotten rather long. The most important part is near the top, just after the refresher on the RPCSEC_GSS protocol. On Wed, 30 Jul 2014, Adamson, Andy wrote: > Hello > > I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and > he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten > WG as well as to the NFSv4 WG to solicit reviews. Please review the > draft which adds two new RPCSEC GSS operations and is a normative > reference to draft-ietf-nfsv4-minorversion2. > > As we are working to finish draft-ietf-nfsv4-minorversion2 , please > submit your reviews by Aug 31, 2014. > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 I'll start off with some big-picture items, and leave my more detailed comments/nitpicks to the end. First off, RPCSEC_GSSv3 is a diff on top of RPCSEC_GSSv2, itself a diff on top of RPCSEC_GSSv1. As a refresher [well, I had to go look it up. Maybe it's a refresher for other people], RPCSEC works by running the GSS negotiation loop over RPC messages, with special RPCSEC control messages being passed on top of the "NULL" RPC until the context is estalblished. Once the context is established, "real" data RPCs can be sent. Three levels of protection are provided for the RPC bodies, none, integrity, and privacy. The choice of level for this attempt at this RPC, as well as a sequence number unique to this transmission, are encoded into the "credential", a part of the RPC request header; there is a GSS MIC over the header, so the header (and protection level and sequence number) are always protected. The request payload's encoding depends on the level; for none, it is unchanged. For integrity, a MIC is taken over the concatenation of the sequence number and the request body, and the transmitted payload is the concatenation of that sequence number and request body, and the MIC. For privacy, the same seqnum+body encoding is done, but GSS_Wrap is used instead of GSS_GetMIC, and the output of Wrap used as the payload. The server keeps a window of sequence numbers and rejects replays and old ones; if packet loss occurs and a client must retransmit, the retransmit uses a new sequence number. --- Multi-principal authentication This draft proposes a multi-principal authentication scheme, restricted to just the case of a privileged client process on a machine combining the (privileged) host's credentials with the (unprivileged) user's credentials so as to take action on behalf of the user. This is a similar combination to that we are using for RXGK_AFSCombineTokens (see draft-wilkinson-afs3-rxgk-afs), restricted to just a combination of host and user credentials, specifying which one is which. I think this is the only well-understood scenario for compount authentication at the moment, and makes sense. The key material from the host's GSS context are used unchanged for securing RPCs issued with the combined identity, but the opaque RPCSEC_GSS context handle is changed to indicate that it represents a "child" context which has the combined identity (and possibly other attributes as well, not relevant for multi-principal authentication). The creation of the child context involves sending an authenticated RPC using the parent/host-credential context, containing body data including a random nonce and the MIC of that nonce using the "inner" context (i.e., the user's credentials). The reply contains the same nonce, but the MIC in the reply is performed using the parent/host-credentials context. The RPC to create the child context is not permitted over a plaintext channel, and requires either integrity protection, confidentiality+integrity protection, or channel binding to a secure channel. However, I don't think this is strong enough; I think this scheme requires the "privacy" level of protection. Otherwise, an attacker could replay the nonce+MIC and obtain an RPCSEC_GSS context that will authenticate as the user from the "inner" context, without actually proving that it possesses the user's credentials. In RXGK_AFSCombineTokens, we are not using (opaque) GSS credentials and can explicitly combine the key material for a strong proof of possession. GSS credentials are opaque, and the GSS-API does not really provide any primitives that seem applicable here. So, I would recommend requiring privacy protection for this call. --- The union construct in 2.6.1 with the default case being an opaque is quite similar to the extensible union construct defined in draft-keiser-afs3-xdr-union; the only difference is that the encoding of the currently listed 'LABEL' and 'PRIVS' cases do not include a length field. It might be nice to have afs3 and nfsv4 agree on a consistent type for the extensible union primitive, though I understand that this is unlikely to happen on the timescale you desire for the rpcsec-gssv3 draft. --- It feels a little strange to be talking about adding a way to specify privileges/restrictions via "assertions" onto a GSS-based security scheme, since GSS is philosophically more of a "request and check" scheme for features. This is not a realy problem, of course, it just takes some getting used to. Actually, I guess it is still kind of "request and check", since the server only replies with the assertions it has accepted. Maybe this is indicative that the name could be more descriptive. --- This draft makes no mention of the use of the 'critical' bit for structured privilege assertions, but does imply that the critical bit will apply to any future branches that are added to the rgss3_assertion_u. This strikes me as odd; at the very least it could say that the critical bit is ignored. (That's my reading of what the behavior is supposed to be, from section 2.6.1.3.) --- It seems like it would not adversely affect the document to move the definition of rgss3_chan_binding up to between rgss3_gss_mp_auth and the branches of rgss3_assertion, to match the layout of the rgss3_create_args structure. Kind of minor, but helps the reader find things. --- I think it's valid to assume that a successful call to GSS_GetMIC will never return a zero-length output, so the encoding of rgss3_create_{args,res} could be reduced in size by just using an opaque for their respective _chan_bind_mic fields, instead of including the extra pointer in the type. I don't know if there's enough need for space to make this worth doing, though. There is some potential value in being able to easily differentiate "not present" from zero-length. --- Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample code on page 7? It is not otherwise mentioned in the draft, and the abstract claims that RPCSEC_GSSv3 provides channel binding capabilities. Furthermore, it is permitted to use rpc_gss_svc_channel_prot to protect the RPCSEC_GSS_{CREATE,LIST} messages, which requires the prior use of RPCSEC_GSS_BIND_CHANNEL. I see that an alternate scheme of channel binding is specified by this document, but it does not actively forbid the use of the RPCSEC_GSSv2 model, as written. --- And now, the minutiae: The fourth paragraph of section 1 (Introduction) refers to section 8 of draft-ietf-nfsv4-minorversion2-27 for Labeled NFS, but the IETF tools will only give me the -26, where Labeled NFS is section 9. Not a big deal, but I figured I'd mention it. The phrasing in section 2.3 that "RPCSEC_GSS version 3 MUST change the verifier" seems odd. This is the specification of RPCSEC_GSSv3, just say what format is specified. Note it as a change from the previous format if you must, but to say that "this document MUST do this thing that this document does" serves no purpose other than to confuse the reader. In section 2.6, fourth paragraph, there's a missing space in "version2". In 2.6.1.1, the following text is a little confusing: Thus a server may refuse to grant requested authority to a user acting alone (e.g., via an unprivileged user-space program), or to a client acting alone (e.g. when a client is acting on behalf of a user) but may grant requested authority to a client acting on behalf of a user if the server identifies the user and trusts the client. It makes more sense when one reads "client" to mean "in-kernel NFS client", but would probably be more clear if the "client is acting on behalf of a user" is reworded, possibly to "on behalf of a single user, using only that user's credentials). It looks like the "client" vs. "kernel service" distinction is fuzzy throughout the rest of the section, too. I would prefer if the word "client" throughout the document referred only to "the RPC client", without any implications about whether the RPC client is a trusted (in-kernel) service or a program run by the user or anything else. This document defines RPCSEC_GSSv3, not NFS; "client" should mean "RPC client", not "NFS client". Still on multi-principal authentication, the text says "Other multi-principal parent and inner context handle uses might eventually make sense." It seems like any such uses would require standards action to specify them; you might as well also say that they would be introduced in a new revision of the RPCSEC_GSS protocol (e.g., v4). In: An inner RPCSEC_GSSv3 context handle that is bound to a parent RPCSEC_GSS context through multi-principal authentication MUST be treated by servers as authenticating the GSS-API initiator principal authenticated by the inner context handle's GSS-API security context. In the first line, should that be "inner" or "child"? I think "child", since the child context handle is what is used to authenticate RPCs, and the inner context handle is implicit. The identity is from the inner handle, of course. This form of multi-principal authentication is using a nonce+MIC to verify the validity of the assertion of the inner context. You should give some guidance on the length of the nonce, especially if the nonce can be sent in plaintext. (For similar things in afs3-rxgk, we use 20 octets. Apparently this is UUID-length, and I'm told there is some precedent for this choice.) Please put a comma before "with" in "the same rgmp_nounce as was sent in the call data with the rgmp_nounce_mic created using the GSS-API security context associate with the parent handle." The fourth text paragraph of section 2.6.1.2 refers to section 12.2.2 of draft-ietf-nfsv4-minorversion2-27; again, only -26 is currently available, and I cannot infer what section 12.2.2 is supposed to be from the context. In the sixth paragraph of that same section, "can assert that label is a secret" should have either "that" or "the" (your preference) inserted prior to "label". The last sentence of the penultimate paragraph of section 2.6.1.3 should be reworded for clarity, maybe something like "If the server receives a structured privilege assertion that fails to verify according to the requirements of the RPC application defined behavior, the assertion is rejected [...]" It's probably worth noting in 2.6.1.4 that the GSS_GetMIC for the channel binding is done using the outer/parent RPCSEC_GSSv3 context, instead of just "the RPCSEC_GSSv3 context handle's GSS-API security context". The channel binding may be performed in parallel with muti-principal authentication, so there may be multiple contexts in play. The clause "if the client really wanted channel binding" is rather informal; you might want to adjust it to say something about "considered to be critical" or similar. In the security considerations, "evaludated" has a typo (spurious 'd'). -Ben From nobody Thu Jul 31 16:01:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6391A0273 for ; Thu, 31 Jul 2014 16:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luSRLGdiEHWv for ; Thu, 31 Jul 2014 16:00:51 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 10E2D1A0252 for ; Thu, 31 Jul 2014 16:00:51 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id D63102007F00A for ; Thu, 31 Jul 2014 16:00:50 -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=yegESGtwj5hXHjI2CFfO zY+Po58=; b=Atzb9HrA3g6pp9h48x7Mpjd95fYFV7fDfqfB/YNBPYVwcP3Lw0iL 2rlposGDrVzZGYB29SIAlQEK0KVWHEaA9/JORJuZY/zRByIOlbasnu9UleyHuDL4 dhMQ4nP9myVh5SF8o3HCB0M50vnmpIY4mGDuNww4x2+ip9yc74LGWv8= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 8CB022007F005 for ; Thu, 31 Jul 2014 16:00:50 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so3384171wgg.4 for ; Thu, 31 Jul 2014 16:00:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.221.65 with SMTP id qc1mr1283595wic.28.1406847648254; Thu, 31 Jul 2014 16:00:48 -0700 (PDT) Received: by 10.217.98.6 with HTTP; Thu, 31 Jul 2014 16:00:48 -0700 (PDT) In-Reply-To: <1406837555.8950.10.camel@destiny.pc.cs.cmu.edu> References: <53D7DBE2.3010105@mit.edu> <1406720770.3242.7.camel@willson.usersys.redhat.com> <1406837555.8950.10.camel@destiny.pc.cs.cmu.edu> Date: Thu, 31 Jul 2014 18:00:48 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tvQdc86Ws0tVBSaSSpspBPkh5mY Cc: "kitten@ietf.org" , Simo Sorce Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:00:52 -0000 We might never get around to doing anything with critical AD. That doesn't mean we should close the door on it. Nico -- From nobody Thu Jul 31 16:10:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D31A02CF; Thu, 31 Jul 2014 16:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEmDrr7y4NcM; Thu, 31 Jul 2014 16:10:24 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A371A01FF; Thu, 31 Jul 2014 16:10:24 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-c7-53daccdf63ce Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id F6.A0.24022.FDCCAD35; Thu, 31 Jul 2014 19:10:23 -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 s6VNAL2u027595; Thu, 31 Jul 2014 19:10:21 -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 s6VNAJVB016002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2014 19:10:20 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6VNAILP005518; Thu, 31 Jul 2014 19:10:18 -0400 (EDT) Date: Thu, 31 Jul 2014 19:10:18 -0400 (EDT) From: Benjamin Kaduk To: "J. Bruce Fields" In-Reply-To: <20140730163006.GG26316@fieldses.org> Message-ID: References: <20140730163006.GG26316@fieldses.org> 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+NgFvrNIsWRmVeSWpSXmKPExsUixG6nonv/zK1ggzMXRS1eTImyOLp5FYvF 7PePWC2mL7JyYPHYMLWJzWPJkp9MHjM+fWELYI7isklJzcksSy3St0vgytg6+TlLwVKpiqfn pzA2MP4V6WLk5JAQMJFY9PcMI4QtJnHh3nq2LkYuDiGB2UwS8yb0MkI4GxklGrZOhMocYpL4 cbUDymlglGg+dwGsn0VAW6LtcxMziM0moCIx881GNhBbREBHYsPnd0wgNrNAmUT3tHZWEFtY wE2i+dUvsHpOASOJt01TwGxeAUeJq/M+gM0UEkiWmHCuDaxXFGjO6v1TWCBqBCVOznzCAjHT UuLcn+tsExgFZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyMo jDkleXYwvjmodIhRgINRiYd3RvitYCHWxLLiytxDjJIcTEqivImHgUJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeAu2AuV4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK8 O08DNQoWpaanVqRl5pQgpJk4OEGG8wAN5zoDMry4IDG3ODMdIn+KUVFKnLcQpFkAJJFRmgfX C0szrxjFgV4R5uUEaecBpii47ldAg5mABj+/dR1kcEkiQkqqgVE+jsn+WP41/961Jz6t35oZ kZLAeFJ7xYnw7ZqODX1MUvGKMbInvzhq5ufKJ8g9kmX2ZYvRSw7bPO/qif9f9fyCu77bMb2q +uMjkRJT3th3jXOt1E9TkTVT1Ff4nOL4s8kr+GoVh/+q6+se/+IsXPn2yUpVx5T38tu1XzIs vB8hsOXNhw0btiqxFGckGmoxFxUnAgDBUj0qDgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1ndbKFCSZ1dNabD4TpZt_HNhZX0 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:10:28 -0000 On Wed, 30 Jul 2014, J. Bruce Fields wrote: > On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote: >> Hello >> >> I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten WG as well as to the NFSv4 WG to solicit reviews. Please review the draft which adds two new RPCSEC GSS operations and is a normative reference to draft-ietf-nfsv4-minorversion2. >> >> As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit your reviews by Aug 31, 2014. >> >> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 > > I'm confused by multi-principal authentication: Ah, good, it's not just me. Sorry I didn't catch this before sending my giant pile of comments. > The RPCSEC_GSS_CREATE request should demonstrate that the caller knows > both parent and child's credentials. That's easy for the parent since > an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request > sent as the parent. > > For the child the caller has to calculate the mic of a nonce using the > child context, but as far as I can tell the choice of nonce is entirely > up to the caller. > > Couldn't it then just choose as the nonce some data that it had > previously seen a mic for? If so, would it work to remove the nonce and > instead calculate, say, a mic of the rpc header (as we do when > calculating the verifier?). Certainly it would help to include (something with) the sequence number, as a proof of "liveness". We may have to brainstorm a bit. > I'm not sure about the reply either: > > On a successful reply, the rgss3_gss_mp_auth field in the > rgss3_create_res reply uses the parent RPCSEC_GSSv3 context as > the rgmp_handle, the same rgmp_nounce as was sent in the call > data with the rgmp_nounce_mic created using the GSS-API security > context associate with the parent handle. Verification of the > rbg_nounce_mic by the initiator demonstrates that the target > agrees to the multi-principal authentication. > > "The target" here is ambiguous. The reply is already authenticated as > the parent, the problem again is authenticating as the child, so I think > it should be calculating a mic using the child context (maybe over the > header data again, as in section 2.3?). In some sense at least, the server "owns" all the resources on it. It could choose to hand out a user's data to the whole world if it felt like it, but we have to trust that it will not. In particular, the server could decline to validate the nonce-MIC at all, and grant access to anyone who claimed to be the user; we must trust that it does the verification properly. (A proper verification confirms that the server does have a valid context handle for the inner context.) In that sense, this reply is just serving as a confirmation that the server accepts the multi-authentication claim, and a simple boolean would have the same effect, so long as it is authenticated. Labels and MAC make this more interesting than the oversimplified picture I just painted, of course, and I agree that this exchange has room for improvement. > (Also, note the draft uses at least "nonce", "nounc", and "nounce", a > spellcheck would help here.) Thank you for saying it :) -Ben From nobody Thu Jul 31 22:54:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE51A040A; Thu, 31 Jul 2014 22:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVkjXmeWgMxW; Thu, 31 Jul 2014 22:54:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C36B21A0409; Thu, 31 Jul 2014 22:54:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 92F156B0078; Thu, 31 Jul 2014 22:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xkxoxGdb1wTlZ7 AlHrLzy1lovs0=; b=uOnUSxI41dUa3NryuFxvPnYIpAX8BEzxJBvlLPx4aGsHIG +5BayrjTcRI/zxwFIyyNcZ9oBv3UQBAVuC5OYopves7PspyohEGQfulhsN519kZj dCtf3osM8Bqikda/GjbbdsEzi/2gyagv+e9bWNHM9eLWgi7mQ6UWu3veuPYek= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 23CA06B0070; Thu, 31 Jul 2014 22:54:04 -0700 (PDT) Date: Fri, 1 Aug 2014 00:54:03 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140801055401.GA7409@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/44XdwfhhnvdbIuMLmwXfGFPW-tA Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 05:54:06 -0000 On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: > Hmm, this seems to have gotten rather long. The most important part > is near the top, just after the refresher on the RPCSEC_GSS > protocol. I may reply in bite sizes :) > [...] > Three levels of protection are provided for the RPC bodies, none, > integrity, and privacy. The choice of level for this attempt at > this RPC, as well as a sequence number unique to this transmission, > are encoded into the "credential", a part of the RPC request header; > there is a GSS MIC over the header, so the header (and protection > level and sequence number) are always protected. The request > payload's encoding depends on the level; for none, it is unchanged. > [...] Though "none" always MICs the header. > Multi-principal authentication > > This draft proposes a multi-principal authentication scheme, > restricted to just the case of a privileged client process on a No, not only the case of a privileged client process. RPCSEC_GSSv3 wants to solve TWO problems: - cache poisoning attacks on the client by the user - secure conveyance of privilege information for processes running with more or even LESS privilege than the user normally would be accorded Therefore we envision that RPCSEC_GSSv3 will *always* be used to establish security contexts on any ONC RPC client where the client can avail itself of a credential distinct from the user's. > machine combining the (privileged) host's credentials with the > (unprivileged) user's credentials so as to take action on behalf of > the user. This is a similar combination to that we are using for > RXGK_AFSCombineTokens (see draft-wilkinson-afs3-rxgk-afs), Yes, it is similar to rxgk. > restricted to just a combination of host and user credentials, > specifying which one is which. I think this is the only > well-understood scenario for compount authentication at the moment, > and makes sense. What is the antecedent of "this" here? Did you mean that conveying local privilege information is not understood? > The key material from the host's GSS context are used unchanged for > securing RPCs issued with the combined identity, but the opaque > RPCSEC_GSS context handle is changed to indicate that it represents > a "child" context which has the combined identity (and possibly A new context results. > other attributes as well, not relevant for multi-principal > authentication). The creation of the child context involves sending Yes. > an authenticated RPC using the parent/host-credential context, > containing body data including a random nonce and the MIC of that > nonce using the "inner" context (i.e., the user's credentials). The > reply contains the same nonce, but the MIC in the reply is performed > using the parent/host-credentials context. The RPC to create the > child context is not permitted over a plaintext channel, and > requires either integrity protection, confidentiality+integrity > protection, or channel binding to a secure channel. Eh? No, confidentiality is neither needed nor called for for context establishment. > However, I don't think this is strong enough; I think this scheme > requires the "privacy" level of protection. Otherwise, an attacker > could replay the nonce+MIC and obtain an RPCSEC_GSS context that > will authenticate as the user from the "inner" context, without > actually proving that it possesses the user's credentials. In The client's credentials are required to make progress. That stops replay attacks. We need only bind things sufficiently to the new RPCSEC_GSS security context handle and the client credentials. Sure, if you're not using integrity protection for the payloads then an attacker can hijack RPCs, but that was always true of RPCSEC_GSSv1. > RXGK_AFSCombineTokens, we are not using (opaque) GSS credentials and > can explicitly combine the key material for a strong proof of > possession. GSS credentials are opaque, and the GSS-API does not > really provide any primitives that seem applicable here. So, I would > recommend requiring privacy protection for this call. I'll have to take a look (Andy produced the latest update and it's been a while since I've looked at RPCSEC_GSSv3), but IIRC it suffices to provide integrity protection. More tomorrow. Nico -- From nobody Thu Jul 31 23:22:49 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED11A02E6; Thu, 31 Jul 2014 16:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCjQ6tm2S49C; Thu, 31 Jul 2014 16:31:27 -0700 (PDT) Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B381A02EB; Thu, 31 Jul 2014 16:31:20 -0700 (PDT) Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1XCzoa-0006HH-Om; Thu, 31 Jul 2014 19:31:16 -0400 Date: Thu, 31 Jul 2014 19:31:16 -0400 From: "J. Bruce Fields" To: Benjamin Kaduk Message-ID: <20140731233116.GA24040@fieldses.org> References: <20140730163006.GG26316@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/--PqMXlVqRz7BNtqjQV-X2y4iEk X-Mailman-Approved-At: Thu, 31 Jul 2014 23:22:46 -0700 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:31:31 -0000 On Thu, Jul 31, 2014 at 07:10:18PM -0400, Benjamin Kaduk wrote: > On Wed, 30 Jul 2014, J. Bruce Fields wrote: > > >On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote: > >>Hello > >> > >>I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten WG as well as to the NFSv4 WG to solicit reviews. Please review the draft which adds two new RPCSEC GSS operations and is a normative reference to draft-ietf-nfsv4-minorversion2. > >> > >>As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit your reviews by Aug 31, 2014. > >> > >>https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 > > > >I'm confused by multi-principal authentication: > > Ah, good, it's not just me. > Sorry I didn't catch this before sending my giant pile of comments. > > >The RPCSEC_GSS_CREATE request should demonstrate that the caller knows > >both parent and child's credentials. That's easy for the parent since > >an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request > >sent as the parent. > > > >For the child the caller has to calculate the mic of a nonce using the > >child context, but as far as I can tell the choice of nonce is entirely > >up to the caller. > > > >Couldn't it then just choose as the nonce some data that it had > >previously seen a mic for? If so, would it work to remove the nonce and > >instead calculate, say, a mic of the rpc header (as we do when > >calculating the verifier?). > > Certainly it would help to include (something with) the sequence > number, as a proof of "liveness". We may have to brainstorm a bit. Maybe I'm forgetting some part of the motivation here: http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-26#section-4.10.1.1 There might be something in the complete COPY protocol that makes this work. Though I don't see it yet. At a minimum we could use some more explanation in this draft. --b.