From nobody Tue May 6 09:34: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 E56E61A017E; Tue, 6 May 2014 09:33:59 -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 eN6jm9V-eKXh; Tue, 6 May 2014 09:33:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00D1A0193; Tue, 6 May 2014 09:33:58 -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.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140506163358.32193.52513.idtracker@ietfa.amsl.com> Date: Tue, 06 May 2014 09:33:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wseCkWC5oKKJXZ22mUli_gcMTMI Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:34:00 -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-02.txt Pages : 15 Date : 2014-05-06 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 6 11:43: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 838D41A01C4 for ; Tue, 6 May 2014 11:43:13 -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 6chlpbUz2UDt for ; Tue, 6 May 2014 11:43:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 70C511A01BB for ; Tue, 6 May 2014 11:43:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6074B1F0309 for ; Tue, 6 May 2014 14:43:07 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4C3C81F02B1 for ; Tue, 6 May 2014 14:43:07 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.72]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 6 May 2014 14:43:06 -0400 From: "Peck, Michael A" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-02.txt Thread-Index: AQHPaUkLfwe21M3yK0mIaCQy2OZ7Wpsz43aA Date: Tue, 6 May 2014 18:43:06 +0000 Message-ID: References: <20140506163358.32193.52513.idtracker@ietfa.amsl.com> In-Reply-To: <20140506163358.32193.52513.idtracker@ietfa.amsl.com> 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: [128.29.194.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <30A1C402EF6C6F4FA24084C7DEF87CEB@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8ohfPhvNBx6dmVEfl8UmoLcdgLI Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-02.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, 06 May 2014 18:43:13 -0000 We updated the draft (also previously known as draft-ietf-kitten-aes-cbc-hmac-sha2) to incorporate the working group consensus to use CTS mode (instead of CBC with padding) and a confounder (instead of an explicit IV). We would appreciate your feedback. Thanks, Mike=20 On 5/6/14, 12:33 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the 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-02.txt > Pages : 15 > Date : 2014-05-06 > >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-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-aes-cts-hmac-sha2-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten From nobody Thu May 8 11:49:35 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 69F281A00DD; Thu, 8 May 2014 11:49:32 -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 CNXfnz7MnwW1; Thu, 8 May 2014 11:49:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAF61A0087; Thu, 8 May 2014 11:49:30 -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.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140508184930.30482.94798.idtracker@ietfa.amsl.com> Date: Thu, 08 May 2014 11:49:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/d_0P-HJ04q7cY9MewDFkM4MlxOM Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-07.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: Thu, 08 May 2014 18:49:32 -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 : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-07.txt Pages : 9 Date : 2014-05-08 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-07 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 Sat May 10 22:27:50 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 0A64E1A02CD; Sat, 10 May 2014 22:27:48 -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 ljsdniraG-Ue; Sat, 10 May 2014 22:27:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E39B41A02C2; Sat, 10 May 2014 22:27:46 -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.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140511052746.8581.65129.idtracker@ietfa.amsl.com> Date: Sat, 10 May 2014 22:27:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EX4xoy2onb_hXDJoLJ4Bz4c9e8c Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gss-loop-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 05:27:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Structure of the GSS Negotiation Loop Author : Benjamin Kaduk Filename : draft-ietf-kitten-gss-loop-00.txt Pages : 17 Date : 2014-05-08 Abstract: This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 18 22:05: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 3871C1A02E2 for ; Sun, 18 May 2014 22:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ay-NLt8YOZAu for ; Sun, 18 May 2014 22:05:32 -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 6FC321A02E0 for ; Sun, 18 May 2014 22:05:32 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4J55VdM003636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 May 2014 05:05:32 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4J55ULi010395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 May 2014 05:05:30 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4J55Tfk010485 for ; Mon, 19 May 2014 05:05:30 GMT Received: from [192.168.0.251] (/65.128.94.244) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 May 2014 22:05:29 -0700 Message-ID: <53799133.70201@oracle.com> Date: Sun, 18 May 2014 23:05:55 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140423 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <52AE9A65.1010700@oracle.com> In-Reply-To: <52AE9A65.1010700@oracle.com> X-Forwarded-Message-Id: <52AE9A65.1010700@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oxHXckPo9YeU4NgR-yfX8xPwBjc Subject: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 19 May 2014 05:05:34 -0000 This message officially starts the kitten Working Group Last Call for the following document: AES Encryption with HMAC-SHA2 for Kerberos 5 http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02 The Working Group Last Call for this document starts today on Sunday, May 18th and will end on Sunday, June 1st. 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. We would especially like to hear from reviewers that have provided comments that were instrumental in nudging this to CTS mode with a confounder. Thank you, Shawn Emery kitten co-chair -- From nobody Tue May 20 13:33:26 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 004C61A0782 for ; Tue, 20 May 2014 13:33:25 -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 Y-V9W1r2o42k for ; Tue, 20 May 2014 13:33:23 -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 9509A1A077D for ; Tue, 20 May 2014 13:33:21 -0700 (PDT) X-AuditID: 1209190c-f79946d000000c3b-28-537bbc100036 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 2A.1E.03131.01CBB735; Tue, 20 May 2014 16:33:20 -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 s4KKXJxQ015552 for ; Tue, 20 May 2014 16:33: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 s4KKXIB6012490 for ; Tue, 20 May 2014 16:33:19 -0400 From: Tom Yu To: kitten@ietf.org References: <20140508184930.30482.94798.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 16:33:18 -0400 In-Reply-To: <20140508184930.30482.94798.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu, 08 May 2014 11:49:30 -0700") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixG6noiuwpzrY4PINIYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro+9jJ1PBVo6KVy/uMDUwvmXrYuTkkBAwkbi35DsThC0mceHe eqA4F4eQwGwmiQ0rPrJDOMcZJQ4uOcwI4TQxSZyYvRsow8HBJiAtcXRxGUi3iICwxO6t75hB bGEBC4nNF3YygthCAo4SR/Z+YgEpZxFQlTgwrQ5kDKfABEaJPW8fs4PU8AroSvSdegrWyyPA KbHo9zw2iLigxMmZT1hAbGYBLYkb/14yTWDkn4UkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLk xLy81CJdQ73czBK91JTSTYygIOOU5NnB+Oag0iFGAQ5GJR5ej4LqYCHWxLLiytxDjJIcTEqi vPG7gEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeFOXAeV4UxIrq1KL8mFS0hwsSuK8b62tgoUE 0hNLUrNTUwtSi2CyMhwcShK8H0CGChalpqdWpGXmlCCkmTg4QYbzAA3n3Q0yvLggMbc4Mx0i f4pRUUqctx6kWQAkkVGaB9cLSwKvGMWBXhHmfQtSxQNMIHDdr4AGMwEN/ru4EmRwSSJCSqqB kefIkU49fXHpHx7rFI8mXLWJzpm18/dBBrX6Cr6NBbvqosTK6qV/r1i8fHt/YmForHvBvjON RaxLJpj/fXHFPWdprpCARNHN7XovLWSOHfHZGe5WwcNa6jHj0V/r/+Wr5P6qayivvbLiVJml uKvD+plZMSFpeYZB33ZOULnQo5S35sySk6vClViKMxINtZiLihMBEVaP5d0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Fr6ym0xWjiufXNTVy-gUFsv8sbs Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-07.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, 20 May 2014 20:33:25 -0000 I think this is ready for Working Group Last Call if we strike out the open questions. The most significant technical change is to change kdc-verifier so that it binds to the ticket. There are significant editorial changes to the motivation text, which hopefully reads more smoothly now. Thanks to Ben, Zhanna, and others who made suggestions. Changed other-verifiers so that it encodes more compactly in the common case where there are no Verifiers in other-verifiers. I recall no significant objections to this. Made kvno and enctype optional in Verifier-MAC. I think there was consensus for this after people realized that a checksum rather than ciphertext was involved. One possible open question is whether to define some verifier that is like the kdc-verifier but not bound to the ticket. This would allow for detached CAMMAC verification without needing a copy of the ticket. I'm inclined to defer this until there's a use case for it, because it can probably be put in other-verifiers, and might not even require additional specification. From nobody Thu May 22 12:34: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 5B9821A0300 for ; Thu, 22 May 2014 12:34:39 -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 eSq57z4SSjhd for ; Thu, 22 May 2014 12:34:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8FE1A02EA for ; Thu, 22 May 2014 12:34:36 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 19:34:34 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.184]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.184]) with mapi id 15.00.0944.000; Thu, 22 May 2014 19:34:34 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 Thread-Index: Ac919NzvMGoGUek4QCSJG90604ZcGg== Date: Thu, 22 May 2014 19:34:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.89] x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(13464003)(164054003)(377454003)(27574002)(86612001)(86362001)(92566001)(66066001)(79102001)(15975445006)(64706001)(20776003)(76576001)(80022001)(81542001)(81342001)(101416001)(46102001)(33646001)(76482001)(77982001)(74662001)(31966008)(74502001)(19580395003)(83322001)(19580405001)(15202345003)(85852003)(21056001)(99396002)(87936001)(83072002)(54356999)(4396001)(2656002)(50986999)(74316001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=michikos@microsoft.com; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DSWnJest6gXj7xh-bY-RSdAcLVI Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 22 May 2014 19:34:39 -0000 No issues with the current draft Thanks, Michiko Short |=A0Program Manager | Microsoft OS Security -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of kitten-request@i= etf.org Sent: Monday, May 19, 2014 12:00 PM To: kitten@ietf.org Subject: Kitten Digest, Vol 114, Issue 4 Send Kitten mailing list submissions to kitten@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/kitten or, via email, send a message with subject or body 'help' to kitten-request@ietf.org You can reach the person managing the list at kitten-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of Kitten digest..." Today's Topics: 1. WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 (Shawn M Emery) ---------------------------------------------------------------------- Message: 1 Date: Sun, 18 May 2014 23:05:55 -0600 From: Shawn M Emery To: "kitten@ietf.org" Subject: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 Message-ID: <53799133.70201@oracle.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed This message officially starts the kitten Working Group Last Call for the f= ollowing document: AES Encryption with HMAC-SHA2 for Kerberos 5 http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02 The Working Group Last Call for this document starts today on Sunday, May 1= 8th and will end on Sunday, June 1st. 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. We would especially like to hear from reviewers that = have provided comments that were instrumental in nudging this to CTS mode w= ith a confounder. Thank you, Shawn Emery kitten co-chair -- ------------------------------ Subject: Digest Footer _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------------------------------ End of Kitten Digest, Vol 114, Issue 4 ************************************** From nobody Thu May 22 14:15:53 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 3060F1A0283 for ; Thu, 22 May 2014 14:15: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 xm0MKiuvkX2f for ; Thu, 22 May 2014 14:15:50 -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 69E7C1A030B for ; Thu, 22 May 2014 14:15:50 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-f2-537e6904a350 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 31.D7.03128.4096E735; Thu, 22 May 2014 17:15:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s4MLFlJ4020471 for ; Thu, 22 May 2014 17:15:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4MLFjgq026156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 May 2014 17:15:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4MLFip5026695; Thu, 22 May 2014 17:15:44 -0400 (EDT) Date: Thu, 22 May 2014 17:15:44 -0400 (EDT) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: <53799133.70201@oracle.com> Message-ID: References: <52AE9A65.1010700@oracle.com> <53799133.70201@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+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrcuSWRdssP2dgMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWbZNeaCUzwVs++eZW1g/M3ZxcjJISFgIjHlwV5mCFtM4sK9 9WwgtpDAbCaJrs7oLkYuIPs4o8Sy1rdMEM4NJok1X8+zQDgNjBIzVn9gBWlhEdCW+PLoN1g7 m4CKxMw3G8FsEQF1ib2HprKA2MICLhIPdm9kBLE5BTQkTj49xARi8wo4Svx/tY0ZYrWrxIPf k8DqRQV0JFbvn8ICUSMocXLmEzCbWcBS4t/aX6wTGAVmIUnNQpJawMi0ilE2JbdKNzcxM6c4 NVm3ODkxLy+1SNdELzezRC81pXQTIzj8JPl3MH47qHSIUYCDUYmH14K1LliINbGsuDL3EKMk B5OSKK9BMlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK9PKFCONyWxsiq1KB8mJc3BoiTO+9ba KlhIID2xJDU7NbUgtQgmK8PBoSTBa58B1ChYlJqeWpGWmVOCkGbi4AQZzgM0PB6khre4IDG3 ODMdIn+KUVFKnPdpOlBCACSRUZoH1wtLD68YxYFeEea1AWnnAaYWuO5XQIOZgAa/WFgLMrgk ESEl1cDo/9/AIWDp4Vt6xbeDt3aqp/16t3hKBN+a/oaPvOmf0+9PSGcyW/spYOJOs5vbFdUS 5q8v22Rr+jr05YvABXPPWrHFbjn7dZKMgBvDpq6t3qdWxpTeqb8RlLXP5ugSPU82vW0lW/ax 5vporP/Xu6BwV3fxveirAZz/ZA23eJSusupTKP5oVhykxFKckWioxVxUnAgAFj3kPuoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4vyLOClkYF_K7EO6aLbB4AZju5k Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 22 May 2014 21:15:52 -0000 On Mon, 19 May 2014, Shawn M Emery wrote: > > This message officially starts the kitten Working Group Last Call for the > following document: > > AES Encryption with HMAC-SHA2 for Kerberos 5 > http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02 > > The Working Group Last Call for this document starts today on Sunday, May > 18th and will end on Sunday, June 1st. This looks pretty much okay. A few minor things: The specification of en/decryption in section 5 assigns the new cipherstate as "next-to-last 128-bit block of C"; this is slightly ambiguous when C does not end on a block boundary. I believe the intent is that the last full block will be used in this case, but one could read the current text as saying that the next-to-last full block would be used. Also, the description of D() says it is an AES encryption function, not a decryption function. There are no test vectors for the PRF. Having such vectors would also make it clear what the output length of the PRF is (luckily, we are not using the simplified profile, with its ambiguous language "truncate tmp1 to multiple of m"). (The PRF output length looks to be 256 and 384 bits for the two variants, to me.) In section 8.1, "at least 128 bits of random" feels ungrammatical. Also in that section, the third and fourth bullet points may be specific to the MIT krb5 implementation; it might be worth tweaking the wording to reflect that this is only known to affect some implementations, or something like that. I did not attempt to verify the test vectors. -Ben From nobody Thu May 22 18:23: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 0E0761A02A5 for ; Thu, 22 May 2014 18:23:29 -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 bdXS5wkJEB6b for ; Thu, 22 May 2014 18:23:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F3F9A1A02A3 for ; Thu, 22 May 2014 18:23:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2FEE11F0F00; Thu, 22 May 2014 21:23:25 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 170371F0EFF; Thu, 22 May 2014 21:23:25 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.72]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Thu, 22 May 2014 21:23:24 -0400 From: "Peck, Michael A" To: Benjamin Kaduk , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 Thread-Index: AQHPcx/5JCOL4NptgUaVEI9X1UFtfJtNYsoAgAACIIA= Date: Fri, 23 May 2014 01:23:24 +0000 Message-ID: References: <52AE9A65.1010700@oracle.com> <53799133.70201@oracle.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.16.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <59F1BE9343F53C41892065B3784F1F63@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2zW1N-lTm0utYRKVdyJ1NBDKeWs Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 23 May 2014 01:23:29 -0000 Ben, Thanks for the comments, I'll fix those. Could you help me understand or give an example of what the pseudo-random function defined in the protocol parameters is used for? I'm not quite following the RFC 3961 section 3 definition. We already separately define how a base-key is derived from a passphrase (in cases where a passphrase is used), and how the Kc, Ke, and Ki keys are derived from the base-key. What are the additional use cases for a generic PRF? Right now our pseudo-random function definition refers to KDF-HMAC-SHA2, which we define in section 3 but in the context of deriving the base-key, Kc, Ke, or Ki key (so that we get the right output length) rather than arbitrary keys, so we may need to clean up that language a bit. Then you're right that it just says "HMAC" which would mean an output of 256 or 384 bits, which probably isn't right (RFC 3961 says the "pseudo-random function should generate an octet string of some size" - but how do we know what size is needed?). Also, calling HMAC a second time rather than just passing the octet-string (and perhaps a desired output length?) into KDF-HMAC-SHA2 may be redundant. Thanks, Mike On 5/22/14, 5:15 PM, "Benjamin Kaduk" wrote: >On Mon, 19 May 2014, Shawn M Emery wrote: > >> >> This message officially starts the kitten Working Group Last Call for >>the=20 >> following document: >> >> AES Encryption with HMAC-SHA2 for Kerberos 5 >> http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02 >> >> The Working Group Last Call for this document starts today on Sunday, >>May=20 >> 18th and will end on Sunday, June 1st. > >This looks pretty much okay. > >A few minor things: > >The specification of en/decryption in section 5 assigns the new >cipherstate as "next-to-last 128-bit block of C"; this is slightly >ambiguous when C does not end on a block boundary. I believe the intent >is that the last full block will be used in this case, but one could read >the current text as saying that the next-to-last full block would be used. >Also, the description of D() says it is an AES encryption function, not a >decryption function. > >There are no test vectors for the PRF. Having such vectors would also >make it clear what the output length of the PRF is (luckily, we are not >using the simplified profile, with its ambiguous language "truncate tmp1 >to multiple of m"). (The PRF output length looks to be 256 and 384 bits >for the two variants, to me.) > >In section 8.1, "at least 128 bits of random" feels ungrammatical. Also >in that section, the third and fourth bullet points may be specific to >the=20 >MIT krb5 implementation; it might be worth tweaking the wording to >reflect=20 >that this is only known to affect some implementations, or something like >that. > >I did not attempt to verify the test vectors. > >-Ben > >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten From nobody Thu May 22 19:18:18 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 9A9731A02B7 for ; Thu, 22 May 2014 19:18:16 -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 s2Q8koXapT44 for ; Thu, 22 May 2014 19:18:15 -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 CAC341A0040 for ; Thu, 22 May 2014 19:18:14 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-b3-537eafe4c0fc 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 23.F2.03128.4EFAE735; Thu, 22 May 2014 22:18:12 -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 s4N2IAT0010644; Thu, 22 May 2014 22:18:11 -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 s4N2I6EU010469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 May 2014 22:18:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4N2I6uH004664; Thu, 22 May 2014 22:18:06 -0400 (EDT) Date: Thu, 22 May 2014 22:18:06 -0400 (EDT) From: Benjamin Kaduk To: "Peck, Michael A" In-Reply-To: Message-ID: References: <52AE9A65.1010700@oracle.com> <53799133.70201@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+NgFnrPIsWRmVeSWpSXmKPExsUixG6nrvtkfV2wQccjLoujm1exWJy+9ZzZ gcljyZKfTB5vG66yBzBFcdmkpOZklqUW6dslcGXMPneeraBVpeLLzmdsDYwPZboYOTkkBEwk bi19zQphi0lcuLeerYuRi0NIYDaTRNP6K6wQzkZGiU+TnrBDOIeYJFom3oAqa2CU+PJ+LQtI P4uAtsSzDReZQWw2ARWJmW82soHYIgLqEn2He8BqmIHsb2feMILYwgIuEg92bwSzOQV0JCad nssOYvMKOEq0HL0PcwejxNLTHWAHigIVrd4/hQWiSFDi5MwnUEMtJc79uc42gVFwFpLULCSp BYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MYLClVOSfwfjt4NKhxgFOBiV eHgtWOuChVgTy4orcw8xSnIwKYnySq4GCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh9QkFyvGm JFZWpRblw6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHi/rgNqFCxKTU+tSMvMKUFI M3FwggznARreD1LDW1yQmFucmQ6RP8WoKCXO6wmSEABJZJTmwfXC0skrRnGgV4R5X4FU8QBT EVz3K6DBTECDXyysBRlckoiQkmpgFLWfvbZujkXizD2/9l/xP2n0/PKmie11ZrIvDigmiX+6 XN36mcG29MPHkgXL49Y/m31IcnW5bEJ9rt6rVb3TV69n1WV8pzf9b6TCjAsrD8zcvEE5rey3 iJy70azzAnsKzqxWZebtyRaeL7ulWdZ8K9e5SI81HywubVdeqCeUc3VCG+crNbUrK5VYijMS DbWYi4oTAe4HDyQCAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/WgMO_Myyh4Ccfc2vU8ghMZ0NFDo Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 23 May 2014 02:18:16 -0000 On Thu, 22 May 2014, Peck, Michael A wrote: > Thanks for the comments, I'll fix those. Thanks. > Could you help me understand or give an example of what the pseudo-random > function defined in the protocol parameters is used for? I'm not quite > following the RFC 3961 section 3 definition. Sure. Probably the easiest example to refer to that comes to mind is in the implementation of gss_pseudo_random() for the krb5 mech, RFC 4402. The summary is that an RFC 3961 enctype is supposed to provide a deterministic way to turn a protocol key and some input string into pseudo-random bits, which are unpredictable to anyone who does not know the protocol key. The output from this function is a fixed length per enctype, so consumers frequently end up defining a PRF+ function to get arbitrary-length output. > We already separately define how a base-key is derived from a passphrase > (in cases where a passphrase is used), and how the Kc, Ke, and Ki keys are > derived from the base-key. What are the additional use cases for a generic > PRF? RFC 3961 sort of hints at this with the phrase "suitable for use in key generation". I don't think I know of any uses of the prf other than for key generation. This would basically always be key generation for some key to be used outside of kerberos, bootstrapping from (say) a kerberos session key and some other shared state between two parties. gss_pseudo_random() is used in draft-wilkinson-afs3-rxgk; in implementing that protocol we actually discovered a couple of interoperability issues between Heimdal and MIT kerberos, partially because the prf functionality was not very well specified originally (which in turn is possibly because the original authors did not really have a concrete use in mind). > Right now our pseudo-random function definition refers to KDF-HMAC-SHA2, > which we define in section 3 but in the context of deriving the base-key, > Kc, Ke, or Ki key (so that we get the right output length) rather than > arbitrary keys, so we may need to clean up that language a bit. Then > you're right that it just says "HMAC" which would mean an output of 256 or > 384 bits, which probably isn't right (RFC 3961 says the "pseudo-random > function should generate an octet string of some size" - but how do we > know what size is needed?). Also, calling HMAC a second time rather than > just passing the octet-string (and perhaps a desired output length?) into > KDF-HMAC-SHA2 may be redundant. That's a good point; it's not specified what the length of Kp is for the aes256-cts-hmac-sha384-192 variant. It would seem that section 3 should cover the Kp case as well as Kc, Ke, Ki, and the base key. (I just assumed that it was 192, when I was reading it.) The introduction does say "the HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm", so I think that the bare usage of "HMAC" at the end of section 5 is reasonably well specified; it's only which variant of KDF-HMAC-SHA2 should be used that is particularly unclear. We could "cheat" by changing the "prf" input to KDF-HMAC-SHA2 to instead be "prfU", since ASCII 'U' is 0x55 (and the 'ends in 0x55' case is already covered for Ki), but it's probably better to explicitly specify which form to use. I don't think there's a need to specify a fully general KDF-HMAC-SHA2, since that's just an internal tool used in defining other quantities, and it is those output quantities which are actually parameters of the RFC 3961 enctype. There is some strong convention that the pseudo_random() output be a multiple of the message block size of the underlying cipher, but from memory I do not think that RFC 3961 imposes that as a hard constraint. There is not really any other restriction or condition on what size output it should produce; consumers are already using PRF+ constructs because of existing enctypes, so we just need to pick a length. (In any case, whether HMAC is SHA-256 or SHA-384, it is still a multiple of the 128-bit block size for AES, so "multiple of the block size" is a non-issue.) I think that calling HMAC a second time is preferable to just passing the octet-string into KDF-HMAC-SHA2; it seems to be more in keeping with the other applications of KDF-HMAC-SHA2 in the specification. I will note again for clarity that the output length of pseudo_random() is a protocol constant; the idea of a "desired output length" is not relevant, since the output length must always for any key of a given enctype. Hope that helps. -Ben From nobody Thu May 22 22:31: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 DDEA01A037A; Thu, 22 May 2014 22:31:36 -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 xPI27gMBg8OQ; Thu, 22 May 2014 22:31:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B241A036E; Thu, 22 May 2014 22:31:33 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140523053133.14184.70279.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 22:31:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RoY652zY-tgfblFQE90nt8ksFis Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 05:31:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Generic Security Service API Version 2: Java Bindings Update Authors : Mayank D. Upadhyay Seema Malkani Wang Weijun Filename : draft-ietf-kitten-rfc5653bis-00.txt Pages : 99 Date : 2014-05-22 Abstract: The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 23 01:01: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 2B90B1A0117; Fri, 23 May 2014 01:01:03 -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 CHjwcKCYULga; Fri, 23 May 2014 01:01:01 -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 DFB731A00FA; Fri, 23 May 2014 01:01:01 -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 s4N80xxw014478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 May 2014 08:01:00 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 s4N80xw0013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 08:00:59 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s4N80w6a013543; Fri, 23 May 2014 08:00:58 GMT Received: from [192.168.10.106] (/111.196.137.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 May 2014 01:00:57 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: Wang Weijun In-Reply-To: <20140523053133.14184.70279.idtracker@ietfa.amsl.com> Date: Fri, 23 May 2014 16:00:47 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140523053133.14184.70279.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MUnlUxnurTpwdVwW4BhT7el6AR4 Cc: kitten@ietf.org, i-d-announce@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 08:01:03 -0000 Sorry, but seems my xml2rfc (version 2.4.3) has a bug that does not = print out the word "Parameters" if it's the hangText of an empty : Therefore you will see for every method in Section 6, there is no = "Parameters:" line before the description of its parameters. xml2rfc = 2.4.5 can print them out and I'll update it in the next draft and = hopefully this won't bring any trouble to your reading. Another difference I noticed (by looking at the diff to rfc5653) is also = in parameters text, where sometimes two words are glued together. This = is my fault when trying to rewrite from nroff to xml. It will be fixed = too in my next draft. Anyway, the real difference to RFC 5653 is described at http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-00#section-11 and I wish it does solve some problem of the original spec. Thanks Weijun On May 23, 2014, at 13:31, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Generic Security Service API Version 2: Java = Bindings Update > Authors : Mayank D. Upadhyay > Seema Malkani > Wang Weijun > Filename : draft-ietf-kitten-rfc5653bis-00.txt > Pages : 99 > Date : 2014-05-22 >=20 > Abstract: > The Generic Security Services Application Program Interface = (GSS-API) > offers application programmers uniform access to security services > atop a variety of underlying cryptographic mechanisms. This = document > updates the Java bindings for the GSS-API that are specified in > "Generic Security Service API Version 2 : Java Bindings Update" (RFC > 5653). This document obsoletes RFC 5653 by adding a new output = token > field to the GSSException class so that when the initSecContext or > acceptSecContext methods of the GSSContext class fails it has a > chance to emit an error token which can be sent to the peer for > debugging or informational purpose. >=20 > The GSS-API is described at a language-independent conceptual level > in "Generic Security Service Application Program Interface Version = 2, > Update 1" (RFC 2743). The GSS-API allows a caller application to > authenticate a principal identity, to delegate rights to a peer, and > to apply security services such as confidentiality and integrity on = a > per-message basis. Examples of security mechanisms defined for GSS- > API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and = "The > Kerberos Version 5 Generic Security Service Application Program > Interface (GSS-API) Mechanism: Version 2" (RFC 4121). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Fri May 23 01:42: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 464601A03C6 for ; Fri, 23 May 2014 01:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29UFDmLAouLD for ; Fri, 23 May 2014 01:42:37 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F6B1A0142 for ; Fri, 23 May 2014 01:42:37 -0700 (PDT) Received: from latte.josefsson.org (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s4N8gMPx008728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 10:42:24 +0200 Date: Fri, 23 May 2014 10:42:17 +0200 From: Simon Josefsson To: Shawn M Emery Message-ID: <20140523104217.05791078@latte.josefsson.org> In-Reply-To: <53799133.70201@oracle.com> References: <52AE9A65.1010700@oracle.com> <53799133.70201@oracle.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.1 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7lT-NBy8QNS4oYl5ryiuP2hutMY Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 23 May 2014 08:42:39 -0000 You wrote: > AES Encryption with HMAC-SHA2 for Kerberos 5 > http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02 I know this is a late generic comment, and I have vague memories that this was already discussed. But why are we standardizing separate encrypt and MAC when everyone else is moving towards AEAD-based modes? I don't see any discussion of this in the draft. There are AEAD modes with nicer properties wrt IV reuse, like SIV. It seems unforunate that Kerberos lingers behind when several other protocols have already specified AEAD modes. I don't see any conflict between moving this draft forward, and working on AEAD modes in parallel, so no objection from me. /Simon From nobody Fri May 23 08:08:11 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 B543C1A0019 for ; Fri, 23 May 2014 08:08:09 -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 ZSN5RGvrrGNm for ; Fri, 23 May 2014 08:08:07 -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 A24E51A01A7 for ; Fri, 23 May 2014 08:08:07 -0700 (PDT) X-AuditID: 12074424-f79546d000000c5e-96-537f645471a3 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 40.4F.03166.4546F735; Fri, 23 May 2014 11:08:04 -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 s4NF83Ni017421; Fri, 23 May 2014 11:08:03 -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 s4NF81ve022479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 May 2014 11:08:02 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4NF80IQ010504; Fri, 23 May 2014 11:08:00 -0400 (EDT) Date: Fri, 23 May 2014 11:08:00 -0400 (EDT) From: Benjamin Kaduk To: Simon Josefsson In-Reply-To: <20140523104217.05791078@latte.josefsson.org> Message-ID: References: <52AE9A65.1010700@oracle.com> <53799133.70201@oracle.com> <20140523104217.05791078@latte.josefsson.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+NgFnrDIsWRmVeSWpSXmKPExsUixG6nohuSUh9s8GWensXRzatYLO5tucTu wOSxZMlPJo+ZZy6yBzBFcdmkpOZklqUW6dslcGV0z5jCUvCcs+LRtk+sDYzf2bsYOTkkBEwk nm+BscUkLtxbz9bFyMUhJDCbSeLwk61MIAkhgY2MEn9P2EEkDjFJ3G6ZyQ7hNDBKbHn1ihmk ikVAW+Lrxx6wDjYBFYmZbzYCjeLgEBHQlJjbngESZhZQl/h25g0jiC0s4CLxYPdGMJtTwEqi Y/53FhCbV8BRYsrmqywQi4slTi1rBrtOVEBHYvX+KVA1ghInZz5hgZhpKXHuz3W2CYyCs5Ck ZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6iREcqC4qOxibDykdYhTg YFTi4X3AVBcsxJpYVlyZe4hRkoNJSZQ30bY+WIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb7Ef UI43JbGyKrUoHyYlzcGiJM771toqWEggPbEkNTs1tSC1CCYrw8GhJMErnwzUKFiUmp5akZaZ U4KQZuLgBBnOAzQ8AqSGt7ggMbc4Mx0if4pRUUqcVxAkIQCSyCjNg+uFJZJXjOJArwhDtPMA kxBc9yugwUxAg18srAUZXJKIkJJqYKyYeTr/3Z4S5o2CU5dM6f4hYW0vYrxaPvvUtTCfI6wW Lo1PE2NqZl+9lSt10H7dTauPJvc2ZnmKcDH5Xk9jzVP6dqO9KXlyReqh+ZNumXBpVex6l9sp vuP7Nx/n0NgdbPrH9XOXpJ/asnPDzY25k+5HMHoZV70Qu6Oj0C1sHO3Mu9hsh/ZNbyWW4oxE Qy3mouJEAOWm36//AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/gJ7djnshzvH2LbHK2wt3w-9T6Uc Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 23 May 2014 15:08:09 -0000 On Fri, 23 May 2014, Simon Josefsson wrote: > You wrote: > >> AES Encryption with HMAC-SHA2 for Kerberos 5 >> http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02 > > I know this is a late generic comment, and I have vague memories that > this was already discussed. But why are we standardizing separate > encrypt and MAC when everyone else is moving towards AEAD-based modes? > I don't see any discussion of this in the draft. There are AEAD modes > with nicer properties wrt IV reuse, like SIV. It seems unforunate that > Kerberos lingers behind when several other protocols have already > specified AEAD modes. AEAD had been mentioned in previous discussions, in particular in the guise of GCM. GCM is not appropriate for an RFC 3961 enctype because of the disasterous consequences of counter rollover: RFC 3961 keys are potentially used for a very long time, and there did not seem to be a reasonable way to prevent rollover or signal errors in that case. See, e.g., http://www.ietf.org/mail-archive/web/kitten/current/msg04277.html and surroundings. I don't know that non-GCM AEAD solutions had been explicitly considered for use with kerberos; I think we would be happy if you did so. -Ben From nobody Fri May 23 08:26: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 B316B1A01E7 for ; Fri, 23 May 2014 08:26:23 -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 OoIWvTw4jqOB for ; Fri, 23 May 2014 08:26:22 -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 254601A00BA for ; Fri, 23 May 2014 08:26:22 -0700 (PDT) X-AuditID: 12074422-f79376d000000c58-6f-537f689c2b4f 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 41.8C.03160.C986F735; Fri, 23 May 2014 11:26:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s4NFQJX7008628; Fri, 23 May 2014 11:26:19 -0400 Received: from [18.101.8.212] (vpn-18-101-8-212.mit.edu [18.101.8.212]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4NFQHur029141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 May 2014 11:26:18 -0400 Message-ID: <537F6899.4040108@mit.edu> Date: Fri, 23 May 2014 11:26:17 -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: Simon Josefsson References: <52AE9A65.1010700@oracle.com> <53799133.70201@oracle.com> <20140523104217.05791078@latte.josefsson.org> In-Reply-To: <20140523104217.05791078@latte.josefsson.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT152TUR9s8O6YmMXRzatYLO5tucTu wOSxZMlPJo+ZZy6yBzBFcdmkpOZklqUW6dslcGX8n3eJrWAZV8XPOxuZGhjncXQxcnJICJhI rHvdzgRhi0lcuLeerYuRi0NIYDaTxKaVH9khnI2MEhP2LoByjjBJbPy8nRWkhVdATWL57u2M IDaLgKrE3IblbCA2m4CyxMGz31hAbFGBMImPR9exQdQLSpyc+QQozsEhIqApMbc9A8RkFlCX 2LmbGaRCWMBF4sHujWAThQSKJfqf/AOzOQWsJDrmf2eBOFRSYtuiY+wgNrOAjsS7vgfMELa8 xPa3c5gnMArNQrJsFpKyWUjKFjAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI11cvNLNFLTSnd xAgOaxelHYw/DyodYhTgYFTi4X3AVBcsxJpYVlyZe4hRkoNJSZQ30bY+WIgvKT+lMiOxOCO+ qDQntfgQowQHs5IIb7EfUI43JbGyKrUoHyYlzcGiJM771toqWEggPbEkNTs1tSC1CCYrw8Gh JMHLAYxfIcGi1PTUirTMnBKENBMHJ8hwHqDh7CA1vMUFibnFmekQ+VOMilLivAXpQAkBkERG aR5cLyztvGIUB3pFmPc8SBUPMGXBdb8CGswENPjFwlqQwSWJCCmpBkblHA7+fLZt1ydeqPxS PG2/gwD7QRX587sunNl82bOvbtm6zOA3L9IPBG9/6HWp11Os9qNGqbVzv+GOW8XMm97z1J06 6cTtH1575fIRrrNH9VPafy8N2+905dJH5WxxvbWLNqtcffD8/iXFKq+Th3p6L0+8XsAc+oer 4kTntp+5rQJHnKwFVukpsRRnJBpqMRcVJwIAQ5GCXRYDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oHUPteph_zO2QeYCWxsBkrmrDG0 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02 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, 23 May 2014 15:26:23 -0000 On 05/23/2014 04:42 AM, Simon Josefsson wrote: > I know this is a late generic comment, and I have vague memories that > this was already discussed. But why are we standardizing separate > encrypt and MAC when everyone else is moving towards AEAD-based modes? We have spent a lot of time considering CCM and GCM. In the end, the uncoordinated nature of Kerberos key usage on long-term keys makes it too hard to pick nonces within the 128-bit space of an AES block with sufficient confidence that they won't be reused. Channel protocols such as TLS can assume state on either end of a connection, making it much easier to select nonces. A Kerberos enctype could be specified which is intended only to be used with short-lived keys via RFC 4537 enctype negotiation, but there would have to be a significant practical advantage to justify that extra complexity. > I don't see any discussion of this in the draft. There are AEAD modes > with nicer properties wrt IV reuse, like SIV. We have not considered SIV as no one has brought it up before (and in fact, I hadn't heard about it until now). Since a goal of this enctype is to hew as closely as possible to NIST-certified cryptography practices, I don't know that SIV would be an attractive option, but I will definitely read up on it. From nobody Fri May 23 13:30:50 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 8A7E31A0043 for ; Fri, 23 May 2014 13:30:48 -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 vhvSOjGazOXm for ; Fri, 23 May 2014 13:30:47 -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 0EC0E1A0031 for ; Fri, 23 May 2014 13:30:46 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-7a-537faff4b548 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 79.46.03128.4FFAF735; Fri, 23 May 2014 16:30:44 -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 s4NKUh8A013157 for ; Fri, 23 May 2014 16:30:44 -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 s4NKUfjj009093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 May 2014 16:30:43 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4NKUfZs021805; Fri, 23 May 2014 16:30:41 -0400 (EDT) Date: Fri, 23 May 2014 16:30:41 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20140511052746.8581.65129.idtracker@ietfa.amsl.com> Message-ID: References: <20140511052746.8581.65129.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+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrPtlfX2wwe8PfBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqGtxQUv+Cq+7Gtka2C8xN3FyMkhIWAi8X37D0YIW0ziwr31 bF2MXBxCArOZJE7MPMIE4RxnlLg34R+Uc4NJ4uaGVhaQFiGBBkaJX29EQWwWAW2Jlk1LwUax CahIzHyzkQ3EFhEQlti99R0ziC0s4Cyx8EgPE4jNKeAo0di1CCjOwcELZM/elg4x0kFi/vEt YONFBXQkVu+fAmbzCghKnJz5BMxmFrCUOPfnOtsERoFZSFKzkKQWMDKtYpRNya3SzU3MzClO TdYtTk7My0st0jXRy80s0UtNKd3ECA49Sf4djN8OKh1iFOBgVOLh/dFXHyzEmlhWXJl7iFGS g0lJlPfwWqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV7exUA53pTEyqrUonyYlDQHi5I471tr q2AhgfTEktTs1NSC1CKYrAwHh5IEb+M6oEbBotT01Iq0zJwShDQTByfIcB6g4XUgNbzFBYm5 xZnpEPlTjIpS4rzLQC4SAElklObB9cJSwytGcaBXhHmTQNp5gGkFrvsV0GAmoMEvFtaCDC5J REhJNTCKiR3efM2tnNnJN/Z/8BVt0Q2arzY822hwv9Xv8e+9z4QzJR8f+/WH4XnTvwV6Mx6+ VzTd8LnGYvb0Kq7WOxL7z75LslFKVvVkn3/2hZ3v+lfyKq4/n302lbhT1N8+41raF9baM6zN 5scWMevGqC8Qr3/IIbd19ibJeUHs8/8v/nv98sW5/cfvKbEUZyQaajEXFScCAPMvL3PoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/d3LfsBg9itiai36_-L0jv65a-TQ Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gss-loop-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 20:30:48 -0000 On Sun, 11 May 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 : Structure of the GSS Negotiation Loop > Author : Benjamin Kaduk > Filename : draft-ietf-kitten-gss-loop-00.txt > Pages : 17 > Date : 2014-05-08 > > Abstract: > This document specifies the generic structure of the negotiation loop > to establish a GSS security context between initiator and acceptor. > The control flow of the loop is indicated for both parties, including > error conditions, and indications are given for where application- > specific behavior must be specified. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-00 The only changes of note are in the C sample code. The controversial comment about "safe to call gss_release_buffer twice on the same buffer" is removed, and the behavior changed slightly. Inside the loop, the buffer is always released, which is safe. Since gss_release_buffer is required to zero the length field, that is what is checked in the outer cleanup label to avoid calling gss_release_buffer twice. I also made some style tweaks, inspired by Greg's comments, and changed the name of the "context_established" variable to reflect which side of the exchange was established. I did not take Nico's suggestion of adding in a check in the acceptor for whether the authenticated initiator name was authorized, as that would be a fair amount of extra code and probably be mission creep. -Ben From nobody Thu May 29 23:22: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 584691A06EE; Thu, 29 May 2014 23:22:40 -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 uAMaMbkBFC-A; Thu, 29 May 2014 23:22:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 697131A02B0; Thu, 29 May 2014 23:22:38 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530062238.17799.94890.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 23:22:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/izF5hp5qzVBhpYZek2c9AIcVHnY Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 06:22:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Generic Security Service API Version 2: Java Bindings Update Authors : Mayank D. Upadhyay Seema Malkani Wang Weijun Filename : draft-ietf-kitten-rfc5653bis-01.txt Pages : 102 Date : 2014-05-29 Abstract: The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc5653bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 30 14:11:53 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 C746C1A0A6E for ; Fri, 30 May 2014 14:11:49 -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 GQ73oc7wjJZn for ; Fri, 30 May 2014 14:11:42 -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 DAE231A0545 for ; Fri, 30 May 2014 14:11:40 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-c3-5388f407583b 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 64.C7.03128.704F8835; Fri, 30 May 2014 17:11:35 -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 s4ULBYgn009787; Fri, 30 May 2014 17:11:35 -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 s4ULBWin022753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 May 2014 17:11:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4ULBW1u028259; Fri, 30 May 2014 17:11:32 -0400 (EDT) Date: Fri, 30 May 2014 17:11:32 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <20140508184930.30482.94798.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrcv+pSPY4HKXnsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WDiFLaCz2wV0/ousjUwbmPtYuTkkBAwkfj8p48JwhaTuHBv PVsXIxeHkMBsJokpk1cwgySEBDYySryYVwWROMQkcalzHVSigVHizmEvEJtFQFti2dzZ7CA2 m4CKxMw3G9lAbBEBSYljT86D1TMLCEusPzcDzBYWcJSYdG0rWD2ngJ7EhJ2fwS7iBYovmNLG AjE/WWLSjs1gc0QFdCRW75/CAlEjKHFy5hMWiJmWEv/W/mKdwCg4C0lqFpLUAkamVYyyKblV urmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGMFBKcm/g/HbQaVDjAIcjEo8vA4zOoKFWBPL iitzDzFKcjApifJ6vAAK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9fgQox5uSWFmVWpQPk5Lm YFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS4OX4DNQoWJSanlqRlplTgpBm4uAEGc4DNFwb pIa3uCAxtzgzHSJ/ilFRSpxX5RNQQgAkkVGaB9cLSxqvGMWBXhHmtQdp5wEmHLjuV0CDmYAG P+lsBRlckoiQkmpgjC+fEdx1cfmpKo/Qhr+GR62ivn1O23TJ8oLTraQu3sI9jc71K3xi0tYr dEw5P+9P0hnnc0tzTv2f67HT0IP17VnRFbumRs39bNevbf3Yvu7YQqsUHq4t6iusC02lL5vf PT/f6GVHayefhbLW2hQDPsu6DBP1Ge/7IvLtRJwcd521d6k8J8ajxFKckWioxVxUnAgARNc/ nfUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/aX7UMrA00z-GwTGT9MKIQthGkCM Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 21:11:49 -0000 On Tue, 20 May 2014, Tom Yu wrote: > I think this is ready for Working Group Last Call if we strike out the > open questions. I am essentially in agreement. The key usage for the other-verifiers checksums is left as TBD, with no IANA request to assign a usage. (The key usage for the kdc-verifier and svc-verifier seem to not be specified, as well?!) > One possible open question is whether to define some verifier that is > like the kdc-verifier but not bound to the ticket. This would allow for > detached CAMMAC verification without needing a copy of the ticket. I'm > inclined to defer this until there's a use case for it, because it can > probably be put in other-verifiers, and might not even require > additional specification. I agree that it could probably be put in other-verifiers if needed, and need not be specified at this time. -Ben