From nobody Wed Apr 6 06:58:56 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3D12D5D4; Wed, 6 Apr 2016 06:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406135854.24895.86806.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 06:58:54 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:58:54 -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 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-03.txt Pages : 96 Date : 2016-04-06 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 stream-based GSSContext methods are also removed in this version. 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: https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc5653bis-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 Wed Apr 6 07:23:04 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F8312D0B4; Wed, 6 Apr 2016 07:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 wUU9VMNoQaGU; Wed, 6 Apr 2016 07:23:01 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 CCE0C12D5E4; Wed, 6 Apr 2016 07:23:00 -0700 (PDT) X-AuditID: 1209190f-c8fff70000004b9e-e5-57051bc3e25b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E3.7B.19358.3CB15075; Wed, 6 Apr 2016 10:22:59 -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 u36EMw7t019635; Wed, 6 Apr 2016 10:22:59 -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 u36EMtBe031927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2016 10:22:57 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u36EMsFw003677; Wed, 6 Apr 2016 10:22:54 -0400 (EDT) Date: Wed, 6 Apr 2016 10:22:54 -0400 (EDT) From: Benjamin Kaduk To: Michiko Short In-Reply-To: Message-ID: References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> <56F0EFBD.90800@openfortress.nl> <56F13EEB.70502@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixG6nrntYmjXcYFGXksXVVR2MFkc3r2Kx +NfN58DssWTJTyaP1h1/2QOYorhsUlJzMstSi/TtErgyPm4+yFTwQ7ri1H7bBsa3Yl2MnBwS AiYSM3dPZe5i5OIQEmhjklgzezorhLOBUeLjzh9sEM5BJomONXOZQFqEBOolXn+9ygJiswho STz8vIcRxGYTUJGY+WYjG4gtAhT/cOE0C0gzs8AaRolDq2eCNQgLeEvcPNbJCmJzCsRKHJy1 HqiZg4NXwFHi+YoqiGXHmCSOftoAViMqoCOxev8UsF5eAUGJkzOfgNnMQAuWT9/GMoFRYBaS 1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0TfRyM0v0UlNKNzGCQpNTkn8H45wG70OM AhyMSjy8AlYs4UKsiWXFlbmHGCU5mJREeT0lWMOF+JLyUyozEosz4otKc1KLDzFKcDArifDO EgPK8aYkVlalFuXDpKQ5WJTEeRkZGBiEBNITS1KzU1MLUotgsjIcHEoSvKzAGBQSLEpNT61I y8wpQUgzcXCCDOcBGt4vBTK8uCAxtzgzHSJ/ilFRSpz3lSRQQgAkkVGaB9cLTh27mVRfMYoD vSLM2wTSzgNMO3Ddr4AGMwENrhdmAhlckoiQkmpgNK2UvXajPLGK2dHoiMUbh6p/FS6z9fM2 KPxz3B1Y6nklvu1Lfnbdhh3GjfEblpsdNjSta2c8tbWyLTKluqNtXfm12C45izkf5yTY25k9 8HskzJu9Zc0VLq5Zbz/Fs4Tc6/VeabtOe3a+wknNs7N4q593zmb5dHv3w5qZh504hS6I2lot THqsxFKckWioxVxUnAgAZ5D6HfgCAAA= Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-pkinit-freshness@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:23:03 -0000 Hi Michiko, Can you please submit a new revision making the MUST --> SHOULD change? Also, I would like to get an explicit confirmation from Greg that this text is not problematic (in Section 2.4): [...] If the freshness token is not valid, the KDC MUST return a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_EXPIRED [RFC6113]. The e-data field of the error contains a METHOD-DATA object [RFC4120] which specifies a valid PA_AS_FRESHNESS padata-value. I see an old comment from Greg in the archives that RFC 6113 made no specification for including METHOD-DATA in a KDC_ERR_PREAUTH_EXPIRED error packet, but a more recent message indicated general acceptance of the whole document (with no specific mention of this text). My understanding is that the concern related to the need to unambiguously specify how to construct the error packet, since RFC 6113 did not give guideance on this scenario (whereas RFC 4120 did give guidance for constructing error packets for KDC_ERR_PREAUTH_FAILED), but the thread is old enough that I would like another confirmation. Thanks, Ben On Tue, 22 Mar 2016, Michiko Short wrote: > Since the infinite loop problem exists for Kerberos clients already, I would prefer to not specify something since this is an extension to an extension. > > However, the must is valid. Not sure how we all missed that. > "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry using the new freshness token." > > I would really like to get this to last call and get the official IANA number > > -----Original Message----- > From: Greg Hudson [mailto:ghudson@mit.edu] > Sent: Tuesday, March 22, 2016 5:48 AM > To: Rick van Rein ; Paul Miller (NT) > Cc: kitten@ietf.org; draft-ietf-kitten-pkinit-freshness@ietf.org > Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt > > On 03/22/2016 03:09 AM, Rick van Rein wrote: > >> It is the responsibility of the client not to retry indefinitely. > > > > May I suggest that you state that in the text? The current draft is a procedure, and could benefit from invariant statements to clarify the cases that fall outside of the intended procedure. > > If I understand correctly, we are worried about an infinite loop of AS-REQ -> KDC_ERR_PREAUTH_EXPIRED -> AS-REQ -> ... due to the section 2.5. > > If we need to alter this text anyway, I don't like the requirement that "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it MUST retry using the new freshness token." MUSTs are to be used when behavior "is actually required for interoperation or to limit behavior which has potential for causing harm" (RFC 2119 section 6). A client which implements RFC 6113 could respond to KDC_ERR_PREAUTH_EXPIRED the same way it already does, by retrying from the beginning, without affecting interoperability or causing harm. > > I suggest the following text: > > If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that > includes a freshness token, it SHOULD retry the PKINIT-authenticated > AS-REQ using the new freshness token. The client MAY restart the > conversation instead. The client MUST limit the number of retries to > avoid looping forever in case of a misbehaving KDC. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Apr 6 07:50:11 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EF412D563 for ; Wed, 6 Apr 2016 07:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 pKwT5hIEUVek for ; Wed, 6 Apr 2016 07:50:09 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 E0DB312D56D for ; Wed, 6 Apr 2016 07:50:07 -0700 (PDT) X-AuditID: 1209190f-c8fff70000004b9e-c7-5705221e9b0b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 4D.DD.19358.E1225075; Wed, 6 Apr 2016 10:50:06 -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 u36Eo6Y4010525 for ; Wed, 6 Apr 2016 10:50:06 -0400 Received: from [18.101.8.140] (vpn-18-101-8-140.mit.edu [18.101.8.140]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u36Eo47R011249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2016 10:50:06 -0400 References: <20160406135854.24895.86806.idtracker@ietfa.amsl.com> To: kitten@ietf.org From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <5705221C.2020101@mit.edu> Date: Wed, 6 Apr 2016 10:50:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160406135854.24895.86806.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrSunxBpu8Py+icXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfDOPtaCzywVq47eZWlg/M7cxcjJISFgIjFx7UYgm4tDSKCN SeJX40NGCOcYo8ScT60sEM5NJol9/z6zgrQIC7hKPNo4mwXEFhJwlNj6aD/YKBEBYYndW9+B 2WwCyhLr929lgVghJ9HbPQnM5hVQk5h//zojiM0ioCLxZ+ImsHpRgQiJJ3NPMkLUCEqcnPkE rJ5TwEniTs9FJhCbWUBPYsf1X6wQtrxE89bZzBMYBWYhaZmFpGwWkrIFjMyrGGVTcqt0cxMz c4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgsNSkn8H45wG70OMAhyMSjy8AlYs4UKsiWXFlbmH GCU5mJREeT0lWMOF+JLyUyozEosz4otKc1KLDzFKcDArifAyKgDleFMSK6tSi/JhUtIcLEri vIwMDAxCAumJJanZqakFqUUwWRkODiUJ3ucgjYJFqempFWmZOSUIaSYOTpDhPEDDH4INLy5I zC3OTIfIn2LU5Vjw4/ZaJiGWvPy8VClx3nkgRQIgRRmleXBzwOkklaPnFaM40FvCvEtBqniA qQhu0iugJUxAS+qFmUCWlCQipKQaGB042Q6f8LB64Npp2FH+fvv9rVf/MaiKNtYs7t3Uccvi kIvF8cykO+ePPm9o3LNJ/COD/KT2rovLtx3SSPY4a32aWZ2jzaJtuSpvL3u71bXTan77rdy8 pvdUBF5dulg8eRpj29uknlX3ps6ctp2Hvb2QS/3+q+tRjQscTgR++u3DsWIfz9/jXkosxRmJ hlrMRcWJACGH0EwCAwAA Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:50:10 -0000 I have looked at the diff, and I think removing the stream methods is a reasonable path forward given the problems they present. I have two editorial nits: * In section 1, "This document and its predecessor" should be "This document and its predecessors" given the subsequent change. * In section 11, "This document has following changes" should be "This document has the following changes". Aside from those minor issues, everything looks okay. I only looked at the diffs, so if there is material about the stream methods in RFC 5653 which should be removed or edited but wasn't, I wouldn't have noticed. From nobody Wed Apr 6 08:06:15 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BD412D66E; Wed, 6 Apr 2016 08:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Lykr4utxk_p8; Wed, 6 Apr 2016 08:06:07 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 61F5512D812; Wed, 6 Apr 2016 08:02:12 -0700 (PDT) X-AuditID: 1209190f-c8fff70000004b9e-c6-570524f34b50 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E1.DF.19358.3F425075; Wed, 6 Apr 2016 11:02:11 -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 u36F2AbI015432; Wed, 6 Apr 2016 11:02:11 -0400 Received: from [18.101.8.140] (vpn-18-101-8-140.mit.edu [18.101.8.140]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u36F28U4016322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2016 11:02:09 -0400 To: Benjamin Kaduk , Michiko Short References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> <56F0EFBD.90800@openfortress.nl> <56F13EEB.70502@mit.edu> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <570524F0.5040103@mit.edu> Date: Wed, 6 Apr 2016 11:02:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrPtZhTXc4Pp5OYurqzoYLY5uXsVi 8a+bz4HZY8mSn0werTv+sgcwRXHZpKTmZJalFunbJXBl7Fw5nbngDm/FumfnGBsYe7i7GDk5 JARMJO7fnMzWxcjFISTQxiTx6v9MFpCEkMAGRokrvWoQicNMEp9mbGcESQgLeEvcPNbJ2sXI wSEi4CUx5Uc6RE0Ls0Tf1e2sIA6zQD+jxP8vp8Aa2ASUJdbv38oCsU5Oord7EpjNK6Am8f3Y MSYQm0VARWLGtmZmEFtUIELiydyTjBA1ghInZz4Bq+cUcJI4/mEpmM0soCex4/ovVghbXqJ5 62zmCYyCs5C0zEJSNgtJ2QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxjB oSzJv4NxToP3IUYBDkYlHl4BK5ZwIdbEsuLK3EOMkhxMSqK8nhKs4UJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeBkVgHK8KYmVValF+TApaQ4WJXFeRgYGBiGB9MSS1OzU1ILUIpisDAeHkgSv OjBmhQSLUtNTK9Iyc0oQ0kwcnCDDeYCG64HU8BYXJOYWZ6ZD5E8xKkqJ855WBkoIgCQySvPg esGpJpWj5xWjONArwrw6IO08wDQF1/0KaDAT0OB6YSaQwSWJCCmpBkaHo0aFfUWiZhPcdNjb drQbu7sUzdr9eIuBne4Bhr/WlcGMp1bvWsMw3UPsVlY695f1HCHZnTxrGn7f/LK+V/YFZ7Pi f7v/P05//9cgsJH72K5tAd92vbh9WFVd4kRxtwhnnbIxj6zdZNvVh/vmvQi4ypKSrvNq+RI/ rctsx7+/Y+Ky3PzvS5ESS3FGoqEWc1FxIgDB2VblEAMAAA== Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-pkinit-freshness@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:06:14 -0000 On 04/06/2016 10:22 AM, Benjamin Kaduk wrote: > Also, I would like to get an explicit confirmation from Greg that this > text is not problematic (in Section 2.4): > > [...] If the freshness token is not valid, the KDC MUST > return a KRB_ERROR [RFC4120] message with the error-code > > KDC_ERR_PREAUTH_EXPIRED [RFC6113]. The e-data field of the error > contains a METHOD-DATA object [RFC4120] which specifies a valid > PA_AS_FRESHNESS padata-value. > > I see an old comment from Greg in the archives that RFC 6113 made no > specification for including METHOD-DATA in a KDC_ERR_PREAUTH_EXPIRED error > packet, but a more recent message indicated general acceptance of the > whole document (with no specific mention of this text). My understanding > is that the concern related to the need to unambiguously specify how to > construct the error packet, since RFC 6113 did not give guideance on this > scenario (whereas RFC 4120 did give guidance for constructing error > packets for KDC_ERR_PREAUTH_FAILED), but the thread is old enough that I > would like another confirmation. My preference remains to send an unadorned KDC_ERR_PREAUTH_EXPIRED and let the client restart from the beginning, just as it would for an expired cookie. The extra round trip is a negligible cost for such an unusual event, and simplicity has value in a protocol as complicated as Kerberos. Seth Moore disagreed with me on the grounds that expired freshness tokens might not be rare; this argument seems far-fetched to me, but I think any further discussion on the point would be hand-waving. That said, I don't believe the text is problematic at this point, because it unambiguously specifies how to construct the error packet. From nobody Wed Apr 6 11:17:35 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C247012D74F; Wed, 6 Apr 2016 11:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 wud-wfMTiedM; Wed, 6 Apr 2016 11:17:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A223212D744; Wed, 6 Apr 2016 11:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EPWKNhaNq3LQu75OG78Ag6Z6l6ekRx4L62KG42WeZ6w=; b=droSrae95qAVywjluJRVLsm6gdTL3Pf2IfHoJQrv9OWbkF8qQyTCaEUYoCYbqSALpLrfoBKOMAr8HUnUM+V/n2g45SNPUuUfSfWAPctKvEFX9esZ8svNi6DFqcBF83kxdeR1zZfUS3g+BYG5Ll13Eh0mZs3LgPRGIkX1iAdKg9k= Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BY1PR03MB1418.namprd03.prod.outlook.com (10.162.127.148) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 18:17:30 +0000 Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 18:17:30 +0000 From: Michiko Short To: Benjamin Kaduk Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt Thread-Index: AQHRg8GWvlYn3zxL8kKg64f1UsNf8J9knzUAgAAQtICAAFw4gIAAXmSAgABI8fCAF2SkAIAAQUow Date: Wed, 6 Apr 2016 18:17:30 +0000 Message-ID: References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> <56F0EFBD.90800@openfortress.nl> <56F13EEB.70502@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: MIT.EDU; dkim=none (message not signed) header.d=none;MIT.EDU; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::518] x-ms-office365-filtering-correlation-id: fe288c88-66e0-4ee8-7d25-08d35e47b7b0 x-microsoft-exchange-diagnostics: 1; BY1PR03MB1418; 5:c4+mrdf3+OEe92K5Z0juMReAIfZ00dvGUzE/hgedtKtoSRy/zHM0dSKvN3RKNA7wjm/56a8hc8vTLD3lNwLYOKWEfw0Nfacd5wTIWnlxcW2uYm9ghv3eIcWn8KK31MWhDhkCp7ZH9lehd4RG/Ps6SA==; 24:7AryzzniR/cQqbFenBwpuy9lhTEla4M8j+gGWkcWx1dDV4/ZeYfsRdbOYRD2aNUS5gNH9PhaIMrDVC18lWVPGb2pYViItqIWYa1DEbm8Xhs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1418; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR03MB1418; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1418; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(52314003)(377454003)(13464003)(122556002)(586003)(86612001)(54356999)(76576001)(3660700001)(110136002)(1220700001)(76176999)(5008740100001)(102836003)(74316001)(575784001)(2950100001)(5002640100001)(2900100001)(77096005)(189998001)(93886004)(86362001)(50986999)(2171001)(164054004)(3280700002)(87936001)(10090500001)(15975445007)(6116002)(2906002)(19580405001)(33656002)(1096002)(5005710100001)(10290500002)(10400500002)(92566002)(81166005)(5004730100002)(106116001)(19580395003)(11100500001)(4326007)(230783001)(99286002)(5003600100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1418; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 18:17:30.5536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1418 Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-pkinit-freshness@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:17:35 -0000 You got it. :)=20 Can we get an IANA number as well? -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]=20 Sent: Wednesday, April 6, 2016 7:23 AM To: Michiko Short Cc: Greg Hudson ; kitten@ietf.org; draft-ietf-kitten-pkini= t-freshness@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt Hi Michiko, Can you please submit a new revision making the MUST --> SHOULD change? Also, I would like to get an explicit confirmation from Greg that this text= is not problematic (in Section 2.4): [...] If the freshness token is not valid, the KDC MUST return a KRB_ERROR [RFC4120] message with the error-code KDC_ERR_PREAUTH_EXPIRED [RFC6113]. The e-data field of the error contains a METHOD-DATA object [RFC4120] which specifies a valid PA_AS_FRESHNESS padata-value. I see an old comment from Greg in the archives that RFC 6113 made no specif= ication for including METHOD-DATA in a KDC_ERR_PREAUTH_EXPIRED error packet= , but a more recent message indicated general acceptance of the whole docum= ent (with no specific mention of this text). My understanding is that the = concern related to the need to unambiguously specify how to construct the e= rror packet, since RFC 6113 did not give guideance on this scenario (wherea= s RFC 4120 did give guidance for constructing error packets for KDC_ERR_PRE= AUTH_FAILED), but the thread is old enough that I would like another confir= mation. Thanks, Ben On Tue, 22 Mar 2016, Michiko Short wrote: > Since the infinite loop problem exists for Kerberos clients already, I wo= uld prefer to not specify something since this is an extension to an extens= ion. > > However, the must is valid. Not sure how we all missed that. > "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that in= cludes a freshness token, it SHOULD retry using the new freshness token." > > I would really like to get this to last call and get the official IANA=20 > number > > -----Original Message----- > From: Greg Hudson [mailto:ghudson@mit.edu] > Sent: Tuesday, March 22, 2016 5:48 AM > To: Rick van Rein ; Paul Miller (NT)=20 > > Cc: kitten@ietf.org; draft-ietf-kitten-pkinit-freshness@ietf.org > Subject: Re: [kitten] I-D Action:=20 > draft-ietf-kitten-pkinit-freshness-05.txt > > On 03/22/2016 03:09 AM, Rick van Rein wrote: > >> It is the responsibility of the client not to retry indefinitely. > > > > May I suggest that you state that in the text? The current draft is a = procedure, and could benefit from invariant statements to clarify the cases= that fall outside of the intended procedure. > > If I understand correctly, we are worried about an infinite loop of AS-RE= Q -> KDC_ERR_PREAUTH_EXPIRED -> AS-REQ -> ... due to the section 2.5. > > If we need to alter this text anyway, I don't like the requirement that "= If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that inclu= des a freshness token, it MUST retry using the new freshness token." MUSTs= are to be used when behavior "is actually required for interoperation or t= o limit behavior which has potential for causing harm" (RFC 2119 section 6)= . A client which implements RFC 6113 could respond to KDC_ERR_PREAUTH_EXPI= RED the same way it already does, by retrying from the beginning, without a= ffecting interoperability or causing harm. > > I suggest the following text: > > If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that > includes a freshness token, it SHOULD retry the PKINIT-authenticated > AS-REQ using the new freshness token. The client MAY restart the > conversation instead. The client MUST limit the number of retries to > avoid looping forever in case of a misbehaving KDC. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2fkitten&data=3D01%7c01%7cmichikos%40microso= ft.com%7c141d07e5fb25470ba38508d35e26f59a%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DspLywtsgLuqPMT0lESglYZVAeOh7wbHYX%2fkQO9zcJm4%3d > From nobody Fri Apr 8 12:57:00 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB8112D173; Fri, 8 Apr 2016 12:56:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160408195659.23011.71797.idtracker@ietfa.amsl.com> Date: Fri, 08 Apr 2016 12:56:59 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:56:59 -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 of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension Authors : Michiko Short Seth Moore Paul Miller Filename : draft-ietf-kitten-pkinit-freshness-06.txt Pages : 8 Date : 2016-04-08 Abstract: This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 11 10:16:13 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4308812F1CD for ; Mon, 11 Apr 2016 10:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 u5BitWQG440M for ; Mon, 11 Apr 2016 10:16:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C137A12F1CC for ; Mon, 11 Apr 2016 10:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5+/BETE/wMTapbUmOVFSNWIyCtW5Mv69dA64N5fNBzU=; b=Tz/pUb1Z/y1CHNCLQ4JNAQzXdbmjLinHizWDtizrddV3ToFwKvYFkOnqYDNnknPKS8B2tpvibURwARRldNUjtGZEK9yeARM7hcs52OM4xnRgQBH9H9YSmSzMFf90KCSDQXYbr+WBG19oQT6dYt0sYuh2oTEdvW1cAJXwWXD2vsw= Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 17:15:51 +0000 Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0453.029; Mon, 11 Apr 2016 17:15:51 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-06.txt Thread-Index: AQHRkpIId20y+kO7mESqdpvLDCnPJZ+FBkfg Date: Mon, 11 Apr 2016 17:15:51 +0000 Message-ID: References: <20160408195659.23011.71797.idtracker@ietfa.amsl.com> In-Reply-To: <20160408195659.23011.71797.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d3] x-ms-office365-filtering-correlation-id: 8db9e30e-8a58-46c7-4156-08d3622cef29 x-microsoft-exchange-diagnostics: 1; BY1PR03MB1417; 5:dBrH0W50wBNjYcV5o+5Rv8Qb88kipFM0/WvM9M/tAOvkv+RvArix8omKYsmMw1DohYXhTZGrF3xnNDd9VdNSbB1YpopF9qbkPaTzHlgTo0FNLBwoWLTaA8s1BAWAr1x5Fp33bFh/QtP5m5+IZzykOQ==; 24:jd1YFgipuVazmyZGYCZHBc6B8Wy3wiJlRPU0Bzizt8k1SiUXgQyDO2Hu8Ak7WY4gW/MvAv1gAxce5C9lX+FjIx80KAYFFoKRjWvwBoK+fa8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1417; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR03MB1417; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1417; x-forefront-prvs: 09090B6B69 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(122556002)(77096005)(2906002)(81166005)(5640700001)(107886002)(110136002)(5003600100002)(5004730100002)(50986999)(9686002)(76576001)(15975445007)(189998001)(92566002)(19580405001)(450100001)(1220700001)(3280700002)(1096002)(3660700001)(5008740100001)(2900100001)(2950100001)(74316001)(2501003)(19580395003)(1730700002)(86362001)(230783001)(86612001)(5005710100001)(10290500002)(87936001)(10400500002)(102836003)(6116002)(586003)(54356999)(8990500004)(11100500001)(76176999)(2351001)(99286002)(33656002)(106116001)(5002640100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1417; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 17:15:51.8038 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1417 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:16:11 -0000 Q2hhbmdlZCBNVVNUIHRvIFNIT1VMRCBpbiB0aGlzIHZlcnNpb24NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEFwcmlsIDgsIDIwMTYgMTI6NTcg UE0NClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBraXR0ZW5AaWV0Zi5vcmcNClN1Ympl Y3Q6IFtraXR0ZW5dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYta2l0dGVuLXBraW5pdC1mcmVzaG5l c3MtMDYudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgQ29tbW9uIEF1dGhlbnRpY2F0aW9uIFRlY2hub2xvZ3kgTmV4dCBHZW5l cmF0aW9uIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFB1YmxpYyBL ZXkgQ3J5cHRvZ3JhcGh5IGZvciBJbml0aWFsIEF1dGhlbnRpY2F0aW9uIGluIEtlcmJlcm9zIChQ S0lOSVQpIEZyZXNobmVzcyBFeHRlbnNpb24NCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWlj aGlrbyBTaG9ydA0KICAgICAgICAgICAgICAgICAgICAgICAgICBTZXRoIE1vb3JlDQogICAgICAg ICAgICAgICAgICAgICAgICAgIFBhdWwgTWlsbGVyDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1raXR0ZW4tcGtpbml0LWZyZXNobmVzcy0wNi50eHQNCglQYWdlcyAgICAgICAgICAgOiA4 DQoJRGF0ZSAgICAgICAgICAgIDogMjAxNi0wNC0wOA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGhvdyB0byBmdXJ0aGVyIGV4dGVuZCB0aGUgUHVibGljIEtleQ0KICAg Q3J5cHRvZ3JhcGh5IGZvciBJbml0aWFsIEF1dGhlbnRpY2F0aW9uIGluIEtlcmJlcm9zIChQS0lO SVQpDQogICBleHRlbnNpb24gW1JGQzQ1NTZdIHRvIGV4Y2hhbmdlIGFuIG9wYXF1ZSBkYXRhIGJs b2IgdGhhdCBhIEtEQyBjYW4NCiAgIHZhbGlkYXRlIHRvIGVuc3VyZSB0aGF0IHRoZSBjbGllbnQg aXMgY3VycmVudGx5IGluIHBvc3Nlc3Npb24gb2YgdGhlDQogICBwcml2YXRlIGtleSBkdXJpbmcg YSBQS0lOSVQgQVMgZXhjaGFuZ2UuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWtpdHRlbi1wa2luaXQtZnJlc2huZXNzLw0KDQpUaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWtpdHRlbi1wa2luaXQtZnJlc2huZXNzLTA2DQoNCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWtpdHRlbi1wa2luaXQtZnJlc2huZXNzLTA2DQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KDQoNCg== From nobody Tue Apr 12 14:46:05 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2341112E3F9 for ; Tue, 12 Apr 2016 14:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, T_TVD_FUZZY_SECURITIES=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 TwLUZ1wAN3-C for ; Tue, 12 Apr 2016 14:46:02 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B1212DA8C for ; Tue, 12 Apr 2016 14:46:02 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 9A6722AC09E; Tue, 12 Apr 2016 14:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=LzpDRzMgDgbAJRkn7d1Di/FAuYg=; b=ACKEhnWAfwQ CRfNK2vyxrP2/VgJcvknrB/OWGd/UPatK/TkR7ooR9kSqcsJql7xjYZNu4hx8OU5 L0IJizTVDfZj6Ne1KDdK4fZnYO892Dw1IlMX708yPDz6iHcSdcdytiyR1Ib0TtZQ eKi8Ih1EUyBIERUhbo5qMuG4wTuBzuCI= Received: from localhost (me65a36d0.tmodns.net [208.54.90.230]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 5233F2AC092; Tue, 12 Apr 2016 14:46:00 -0700 (PDT) Date: Tue, 12 Apr 2016 16:45:59 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20160412214556.GE19617@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Michael J. Jenkins" , "Kelley W. Burgin" Subject: [kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts-hmac-sha2? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 21:46:04 -0000 draft-ietf-kitten-aes-cts-hmac-sha2 wants randomly generated salts. That's nice, but... why did we ever have non-randomly-generated salts? "Convenience" seems like a nice explanation, but I suspect it wasn't just that: it may have been a half-baked security feature. C->AS: AS-REQ AS->C: KRB-ERROR w/ PA-ETYPE-INFO2 w/ a random salt C: string2key() w/ the AS's salt C->AS: AS-REQ w/ PA-ENC-TIMESTAMP using string2key() called with the server's choice of salt Do you see the problem? What if the AS is an active attacker? They can then use a single salt for all clients, one that they have a computed rainbow table for. The victim clients will happily use this salt. Mallory: C->Mallory: AS-REQ Mallory->C: KRB-ERROR w/ PA-ETYPE-INFO2 w/ Mallory's rainbow table salt C: string2key() w/ Mallory's choice of salt C->Mallory: AS-REQ w/ PA-ENC-TIMESTAMP using string2key() called with Mallory's choice of salt Mallory: So randomizing the salt doesn't help at all. It makes things worse even: clients now can't sanity check the salt. But if the salt *must* start with an unambiguous encoding of the client's principal name and realm, _and_ if the client checks that this is so, then the attacker can no longer have a single raibow table for all victims. And we can have a random suffix in the salt to add some additional security (especially if this suffix is changed every time the user changes their password). Now, PA-ENC-TIMESTAMP is just awful and we know it, and this is NOT a new attack: RFC3962's Security Considerations describes this attack as to the iteration count (but not the salt, but the idea follows). Though it does feel like a new attack: it seems likely that RFC3962 would have mentioned salt spoofing in addition to iteration count spoofing, if the authors had thought of salt spoofing... Back then the WG did have a chance to improve some things for "newer" enctypes, and we did, so we might have done that for salts too, if we'd thought of it. Anyways, we've got two ways of addressing this problem _today_, and we're working on a third: - (existing) PKINIT (look ma', no passwords; but not trivial to deploy) - (existing) FAST tunnel (requires a bit more configuration on the clients) - (upcoming) SPAKE So maybe we just don't care about this problem. But we could perhaps plug the above hole by requiring clients to check that the salt is prefixed with an unambiguous encoding of the client principal's name and realm name at least when using the new AES-CTS HMAC-SHA2 enctypes or _newer_. (Clients should probably _not_ require this for older enctypes, not by default, for interop reasons.) This has some consequences for principal renames, but pretty much nothing else, I think. Either principal renames cannot be supported without an administrative password reset, or the KDC must force the user to change their password after a rename _and_ the client must prompt the user to confirm the rename and the previous principal name (which further means that the client must be able to extract and decode the principal name and realm name prefix from the salt). I think this is mostly a non-issue. Do we care? Enough to fix this? Now? Ever? Now's the time for the new enctypes. If not now, never (because the SPAKE will take care of this problem). If we're inclined to fix this now, I'll implement for Heimdal. Nico -- From nobody Tue Apr 12 15:20:41 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B6112D6E8 for ; Tue, 12 Apr 2016 15:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=2.2] autolearn=no autolearn_force=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 u_1Xw-JdzKrm for ; Tue, 12 Apr 2016 15:20:39 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44BA12D7F5 for ; Tue, 12 Apr 2016 15:20:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 86549EE5D; Tue, 12 Apr 2016 18:20:35 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTW8sE+hXILk; Tue, 12 Apr 2016 18:20:34 -0400 (EDT) Received: from [192.168.1.180] (wsip-174-76-19-88.oc.oc.cox.net [174.76.19.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 1D36DEDA8; Tue, 12 Apr 2016 18:20:32 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20160412214556.GE19617@localhost> Date: Tue, 12 Apr 2016 15:20:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0429C8B0-96BE-46FB-8434-5AB65B6D82E3@oxy.edu> References: <20160412214556.GE19617@localhost> To: Nico Williams X-Mailer: Apple Mail (2.2104) Archived-At: Cc: kitten@ietf.org, "Michael J. Jenkins" , "Kelley W. Burgin" Subject: Re: [kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts-hmac-sha2? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 22:20:41 -0000 > On Apr 12, 2016, at 2:45 PM, Nico Williams = wrote: >=20 > That's nice, but... why did we ever have non-randomly-generated salts? >=20 > "Convenience" seems like a nice explanation, but I suspect it wasn't > just that: it may have been a half-baked security feature. I guess that=E2=80=99s a valid description. AFAIK time stamps were used = because because there was no way to prevent replay attacks if you used = the random nonce specified in the original Needham-Schroeder algorithm. Anyone know when JAAS will support FAST or PKINIT? Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com https://www.linkedin.com/in/hbhotz/ From nobody Tue Apr 12 16:14:00 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7462B12D5C4 for ; Tue, 12 Apr 2016 16:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 h8hRWrEZjsjr for ; Tue, 12 Apr 2016 16:13:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2FE12D15D for ; Tue, 12 Apr 2016 16:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aBgq+DqGZeM6ZvV4941ukYR3R6zqmxKnXRO/XffG4Kc=; b=CQIsYpGGiXV8h17PrPiQHay3pa/fWpaEsQm+Idf0i2vqnGqOKK5z6gaI94JE9QbE83tNcBoDuJBtLQh9PPujKDxpjNkKY4th+5JqHUcSZPNz8pzrVR5P+Ye5/oVIi27qEuWqsdaza+6lyt7EmQ6lSi9+GsORNRH+hbLG6b9xltw= Received: from BLUPR0301MB1953.namprd03.prod.outlook.com (10.164.21.23) by BLUPR0301MB1953.namprd03.prod.outlook.com (10.164.21.23) with Microsoft SMTP Server (TLS) id 15.1.453.26; Tue, 12 Apr 2016 23:13:55 +0000 Received: from BLUPR0301MB1953.namprd03.prod.outlook.com ([10.164.21.23]) by BLUPR0301MB1953.namprd03.prod.outlook.com ([10.164.21.23]) with mapi id 15.01.0453.029; Tue, 12 Apr 2016 23:13:55 +0000 From: "Paul Miller (NT)" To: Nico Williams , "kitten@ietf.org" Thread-Topic: [kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts-hmac-sha2? Thread-Index: AQHRlQS+S13dp28DIEqkb5Jwn29+Jp+G8glw Date: Tue, 12 Apr 2016 23:13:55 +0000 Message-ID: References: <20160412214556.GE19617@localhost> In-Reply-To: <20160412214556.GE19617@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cryptonector.com; dkim=none (message not signed) header.d=none;cryptonector.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::3d8] x-ms-office365-filtering-correlation-id: 22cb3f65-deb7-4cf3-9728-08d363281ee5 x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1953; 5:Omod0opjUAIHuZUL2e5V7+Er60K/hyDSMUbr+KsZnJzvl217NJ1XgSa2QfbiNkfuKhHmMLLfs7s2/ZKXbNPtaITTjxL7CWDKNWwiROb4eENeIiJaPEE++vgtlj0ZUFwzEE+vsAf8PmFY1WHAebMq9Q==; 24:j3f/1kihEsuN0mV94dNaVM+vPTtOQdV/NJgDwZMVr3/ZurIg9/+pkql5kqZMlmO0ed3G/a7q3cQAmALvVOlcEb/aq/PS8PbULF5ZwjFbYZY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0301MB1953; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BLUPR0301MB1953; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0301MB1953; x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(106116001)(81166005)(3280700002)(99286002)(3660700001)(10090500001)(2900100001)(2950100001)(33656002)(2501003)(5001770100001)(15975445007)(77096005)(5003600100002)(92566002)(76576001)(86362001)(19580405001)(5004730100002)(1096002)(1220700001)(4326007)(54356999)(50986999)(76176999)(122556002)(5002640100001)(86612001)(189998001)(6116002)(5008740100001)(230783001)(586003)(87936001)(10400500002)(5005710100001)(2906002)(11100500001)(551544002)(9686002)(74316001)(102836003)(10290500002)(8990500004)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1953; H:BLUPR0301MB1953.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2016 23:13:55.6326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1953 Archived-At: Cc: "Michael J. Jenkins" , "Kelley W. Burgin" Subject: Re: [kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts-hmac-sha2? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 23:13:59 -0000 >>> Mallory: How is this supposed to work since the client injects its own entropy into = the PA-ENC-TIMESTAMP? It should not be possible to rainbow table this resp= onse as the PA-ENC-TIMESTAMP is not predictable given the password and salt= . The client time will not be predictable if the optional Microseconds is = used in the PA-ENC-TS-ENC. Even without that, the client should be using a= random IV (or confounder) in its encryption of the timestamp. At worst the AS could have a dictionary of the string-to-key for a number o= f passwords, but a dictionary is not nearly as powerful as a rainbow table = due to its storage requirements and due to the fact that there is still a n= on-trivial amount of computation to test the key from each table entry. St= oring 32 bytes of key information for AES256 per potential password, a 1 EB= table would hold the keys for 35 trillion passwords, which only covers 45 = bits of entropy in potential passwords. -----Original Message----- From: Kitten [mailto:kitten-bounces@ietf.org] On Behalf Of Nico Williams Sent: Tuesday, April 12, 2016 2:46 PM To: kitten@ietf.org Cc: Michael J. Jenkins ; Kelley W. Burgin Subject: [kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts= -hmac-sha2? draft-ietf-kitten-aes-cts-hmac-sha2 wants randomly generated salts. That's nice, but... why did we ever have non-randomly-generated salts? "Convenience" seems like a nice explanation, but I suspect it wasn't just t= hat: it may have been a half-baked security feature. C->AS: AS-REQ AS->C: KRB-ERROR w/ PA-ETYPE-INFO2 w/ a random salt C: string2key() w/ the AS's salt C->AS: AS-REQ w/ PA-ENC-TIMESTAMP using string2key() called with the server's choice of salt Do you see the problem? What if the AS is an active attacker? They can then use a single salt for = all clients, one that they have a computed rainbow table for. The victim c= lients will happily use this salt. Mallory: C->Mallory: AS-REQ Mallory->C: KRB-ERROR w/ PA-ETYPE-INFO2 w/ Mallory's rainbow table salt C: string2key() w/ Mallory's choice of salt C->Mallory: AS-REQ w/ PA-ENC-TIMESTAMP using string2key() called with Mallory's choice of salt Mallory: So randomizing the salt doesn't help at all. It makes things worse even: clients now can't sanity check the salt. But if the salt *must* start with an unambiguous encoding of the client's p= rincipal name and realm, _and_ if the client checks that this is so, then t= he attacker can no longer have a single raibow table for all victims. And = we can have a random suffix in the salt to add some additional security (es= pecially if this suffix is changed every time the user changes their passwo= rd). Now, PA-ENC-TIMESTAMP is just awful and we know it, and this is NOT a new a= ttack: RFC3962's Security Considerations describes this attack as to the it= eration count (but not the salt, but the idea follows). Though it does feel like a new attack: it seems likely that RFC3962 would h= ave mentioned salt spoofing in addition to iteration count spoofing, if the= authors had thought of salt spoofing... Back then the WG did have a chanc= e to improve some things for "newer" enctypes, and we did, so we might have= done that for salts too, if we'd thought of it. Anyways, we've got two ways of addressing this problem _today_, and we're w= orking on a third: - (existing) PKINIT (look ma', no passwords; but not trivial to deploy) - (existing) FAST tunnel (requires a bit more configuration on the clients= ) - (upcoming) SPAKE So maybe we just don't care about this problem. But we could perhaps plug the above hole by requiring clients to check that= the salt is prefixed with an unambiguous encoding of the client principal'= s name and realm name at least when using the new AES-CTS HMAC-SHA2 enctypes or _newer_. (Clients should probably _not_ require this= for older enctypes, not by default, for interop reasons.) This has some consequences for principal renames, but pretty much nothing e= lse, I think. Either principal renames cannot be supported without an admi= nistrative password reset, or the KDC must force the user to change their p= assword after a rename _and_ the client must prompt the user to confirm the= rename and the previous principal name (which further means that the clien= t must be able to extract and decode the principal name and realm name pref= ix from the salt). I think this is mostly a non-issue. Do we care? Enough to fix this? Now? Ever? Now's the time for the new enctypes. If not now, never (because the SPAKE = will take care of this problem). If we're inclined to fix this now, I'll implement for Heimdal. Nico --=20 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nobody Tue Apr 12 22:38:10 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CAB12DD8A for ; Tue, 12 Apr 2016 22:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 ud_qjsNR-bvF for ; Tue, 12 Apr 2016 22:38:07 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D58412DD9F for ; Tue, 12 Apr 2016 22:38:07 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 5A59DE000537; Tue, 12 Apr 2016 22:39:20 -0700 (PDT) Received: from localhost (unknown [172.56.27.42]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 13A1EE000532; Tue, 12 Apr 2016 22:39:18 -0700 (PDT) Date: Wed, 13 Apr 2016 00:38:04 -0500 From: Nico Williams To: "Paul Miller (NT)" Message-ID: <20160413053802.GC22194@localhost> References: <20160412214556.GE19617@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" , "Michael J. Jenkins" , "Kelley W. Burgin" Subject: Re: [kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts-hmac-sha2? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 05:38:09 -0000 On Tue, Apr 12, 2016 at 11:13:55PM +0000, Paul Miller (NT) wrote: > >>> Mallory: Er, right, so this isn't a rainbow table. It allows the attacker to avoid having to compute s2k for each {password, salt}, but the attacker still has to try every one (well, many) of those pre-computed keys to decrypt the PA-ENC-TIMESTAMP ciphertext. So it's an optimization on the off-line dictionary attack, but the attack is still O(N), so not a huge win. I guess it's Emily Litella time for me then! Nico -- From nobody Wed Apr 13 08:25:01 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2601812D7BF for ; Wed, 13 Apr 2016 01:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9RCkdvnDECR1 for ; Wed, 13 Apr 2016 01:32:27 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86DF12D68C for ; Wed, 13 Apr 2016 01:32:26 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id hkYN1s00M10HQrX01kYQfK; Wed, 13 Apr 2016 10:32:24 +0200 Message-ID: <570E0415.5090501@openfortress.nl> Date: Wed, 13 Apr 2016 10:32:21 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tom Yu X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 13 Apr 2016 08:24:57 -0700 Cc: " Subject: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 08:32:29 -0000 Hello Tom / Kitten, Last week the Kerberos IANA registries draft popped up again. I find the general useful, but I feel strong objections against constraining "Named Bit Assignments" to the 0..31 range. I mentioned this before, but now also see a way out. My proposal is the replacement text at the end of this email. My reasons for my objection + alternative are (1) specifications should not follow implementations, and certainly not confirm bad ones; (2) limiting to 32 named bits will confirm this lowest common denominator and increase the number of flawed implementations; (3) after confirming a 32-bit limit, we have cut off any chance of growing beyond this; (4) software that is incapable of being updated is a security problem, not something that a spec should seek to confirm; (5) we currently cannot supply bits for experimental/private use, for instance for development purposes; developers end up stealing bits and the registry becomes an administration of such sins. The suggestion below puts some suggestive pressure towards proper implementation, by hinting at a future with bits beyond 32, also for experimental/private use. This is a hint in the direction that we would like to have. Also, it will help us grow an insight into which implementations are flawed, which won't happen if we stuck to 32 bits. Note that allowing more bits than anticipated is purely a parsing matter; any implementation has a limited number of flags that it can understand, and so the only requirement is to be able to parse DER structures with more bits than understood; the default behaviour for unknown flags can easily be triggered in any implementation by looking at the extra bytes and responding to anything non-zero (which is easy with DER, as the length will only be > (1+32/8) when a bit over 32 is set). After that potential trigger, only the understood (for instance, 32) bits need to be taken out for processing. (For TicketFlags and KDC-Options the unrecognised handling is even simpler, namely ignoring; I could not find unrecognised handling for AP-Options but ignoring seems to make sense there too.) This leaves implementations of RFC 1510 which may be more restrictive. Assuming this problem is real, could we resolve it with policy settings on supplied flags in client and/or KDC? Cheers, -Rick 6. Named bit assignments Names for named bit assignments must be unique within a given named bit registry, and typically do not have name prefixes that identify which registry they belong to. Assignments for named bits 0 through 31 require standards action, due to their scarcity; RFC 4120 predicts higher bit numbers, but use of these bits may involve fixing applications that falsely assume that no more than 32 named bits will ever be assigned. These bits are available under a less restrictive policy because they are not scarce. 6.1. AP-REQ options Registry name: AP-REQ options Assignment policy: Standards action Valid values: ASN.1 bit numbers 0 through 31 Assignment policy: Experimental and Private Use Valid values: ASN.1 bit numbers 32 through 35 Assignment policy: Specification Required Valid values: ASN.1 bit numbers 36 and up 6.2. KDC-REQ options Registry name: KDC-REQ options Assignment policy: Standards action Valid values: ASN.1 bit numbers 0 through 31 Assignment policy: Experimental and Private Use Valid values: ASN.1 bit numbers 32 through 35 Assignment policy: Specification Required Valid values: ASN.1 bit numbers 36 and up 6.3. Ticket flags Registry name: Ticket flags Assignment policy: Standards action Valid values: ASN.1 bit numbers 0 through 31 Assignment policy: Experimental and Private Use Valid values: ASN.1 bit numbers 32 through 35 Assignment policy: Specification Required Valid values: ASN.1 bit numbers 36 and up From nobody Thu Apr 14 08:19:05 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8E12D714 for ; Thu, 14 Apr 2016 08:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tFKRC9fNfQOi for ; Thu, 14 Apr 2016 08:19:01 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 4743912D66B for ; Thu, 14 Apr 2016 08:19:01 -0700 (PDT) X-AuditID: 1209190c-5a7ff70000003b81-fd-570fb4e3923f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F0.3D.15233.3E4BF075; Thu, 14 Apr 2016 11:18:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u3EFIx8m020618; Thu, 14 Apr 2016 11:18:59 -0400 Received: from [18.101.8.92] (vpn-18-101-8-92.mit.edu [18.101.8.92]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3EFItIt026543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Apr 2016 11:18:56 -0400 To: Rick van Rein , Tom Yu References: <570E0415.5090501@openfortress.nl> From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <570FB4DF.9070100@mit.edu> Date: Thu, 14 Apr 2016 11:18:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570E0415.5090501@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6novt4C3+4wcqllhZHN69isXj66h6b A5PHkiU/mTw2/GtiC2CK4rJJSc3JLEst0rdL4Mr4snMfY8E3qYr1tx6zNjC2iXUxcnJICJhI tPz4zdLFyMUhJNDGJDHx9XVGkISQwEZGiUuLiiHsg0wSM577dTFycAgLpEnsWOoKEhYRsJdY tGoDE0hYSEBP4uhRTpAws4C6xNHnTWwgNpuAssT6/VtZIFbJSfR2TwKzeQXUJPoP/QKrYRFQ lfi96COYLSoQIfFk7klGiBpBiZMzn4DVcwroS+xZ+YENYr6exI7rv1ghbHmJ5q2zmScwCs5C 0jILSdksJGULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBIUupyTPDsYz b7wOMQpwMCrx8D6o4Q8XYk0sK67MPcQoycGkJMrLmAEU4kvKT6nMSCzOiC8qzUktPsQowcGs JMJ7YyNQjjclsbIqtSgfJiXNwaIkzlu4/3SYkEB6YklqdmpqQWoRTFaGg0NJgnfOZqBGwaLU 9NSKtMycEoQ0EwcnyHAeoOETQGp4iwsSc4sz0yHypxgVpcR580ESAiCJjNI8uF5waknliHnF KA70ijAvGzDRCPEA0xJc9yugwUxAg8ve8YIMLklESEk1ME5L8VQLu/hzH1/hzhyNhC+F66/H GRrL8qt8XjVZqUljlhlDq9k6ka9/oiPeT0z7sHiWRsv5usRdl+JmigibnzXZ7rH3yf3L81Zd NRJsCHUOi5Trrd7ce8vt/c0l9i+8zsRNS2rmsWG9yR3Rd8Oar/ZbyM/DPjtniTwr3PylodAk MWvHzjOyAUosxRmJhlrMRcWJAHVYkoIIAwAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:19:04 -0000 On 04/13/2016 04:32 AM, Rick van Rein wrote: > (1) specifications should not follow implementations, and certainly not > confirm bad ones; > (2) limiting to 32 named bits will confirm this lowest common > denominator and increase the number of flawed implementations; > (3) after confirming a 32-bit limit, we have cut off any chance of > growing beyond this; > (4) software that is incapable of being updated is a security problem, > not something that a spec should seek to confirm; > (5) we currently cannot supply bits for experimental/private use, for > instance for development purposes; developers end up stealing bits and > the registry becomes an administration of such sins. (There is a brief earlier conversation here: http://www.ietf.org/mail-archive/web/kitten/current/msg04761.html ) (1) IETF specifications often follow implementations and take into account their limitations. The desirable outcome of IETF work is practical interoperability, not strict adherence to a waterfall model. As examples, we recently re-issued RFC 4402 as RFC 7802 because implementations screwed up the PRF count, and we are in the process of re-issuing RFC 6112 because an implementation screwed up the case of a key-derivation pepper input. (2) Heimdal and MIT krb5 both use 32-bit values for the flags fields in RFC 4120, and use those fields in public library API structures. (Shishi uses 32-bit flag values but I don't know anything about its library APIs; I don't think Microsoft has a Kerberos library API.) There isn't much danger of increasing the number of implementations with this limitation; the damage is already done. (3) Applying this rule to the registry now does not preclude changing it later. The same high implementation costs would apply regardless of how the current registry rules are set. (4) I find this argument really hyperbolic in several respects. Most importantly, there are lots of ways to extend RFC 4120 beyond adding flag values. "Flags" are just a compressed representation of boolean values; there are typically other, less efficient ways to add boolean values to the surrounding ASN.1 sequence, such as authorization-data in Ticket or padata in KDC-REQ. (5) This is a real cost, though I can't think of a historical case where an implementation has squatted on an RFC 4120 flag value. It needs to be weighed against the implementation cost of extending flag values. > The suggestion below puts some suggestive pressure towards proper > implementation, by hinting at a future with bits beyond 32, also for > experimental/private use. I don't think this suggestion has any practical benefit. Anyone who registers a flag value above 35 with a non-standards-track specification would find themselves quite disappointed in their ability to use this flag in any of the widely used krb5 implementations. > Note that allowing more bits than anticipated is purely a parsing > matter; any implementation has a limited number of flags that it can > understand, and so the only requirement is to be able to parse DER > structures with more bits than understood [...] In some cases, implementations also need to be able to re-encode flag values (particularly TicketFlags) without losing information. For instance, RFC 7751 section 4 requires KDCs to encode an EncTicketPart, which contains a TicketFlags, for the ticket surrounding a CAMMAC. From nobody Thu Apr 14 20:12:25 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1012DB89 for ; Thu, 14 Apr 2016 20:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lx5Stwnh0cyB for ; Thu, 14 Apr 2016 20:12:23 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 EC0CA12DB56 for ; Thu, 14 Apr 2016 20:12:22 -0700 (PDT) X-AuditID: 12074424-8bfff700000073db-b5-57105c15077f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 01.29.29659.51C50175; Thu, 14 Apr 2016 23:12:21 -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 u3F3CK69021095 for ; Thu, 14 Apr 2016 23:12:20 -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 u3F3CHOP004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Apr 2016 23:12:20 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3F3CHID021548; Thu, 14 Apr 2016 23:12:17 -0400 (EDT) Date: Thu, 14 Apr 2016 23:12:16 -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; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUixCmqrSsaIxBusLuBy+Lo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+HX/MmPBC66Km7NvsDcwNnF2MXJySAiYSDy+vJMVxBYSaGOS +DDJBsI+ziixrtOxi5ELyL7BJDHjeRM7hNPAKLFwzWN2kCoWAW2Jp7vb2EBsNgEViZlvNoLZ IgLCEru3vmMGsYUFzCRWPp7NAmLzCjhKLN0xH6xXVEBHYvX+KVBxQYmTM5+A2cwCWhLLp29j mcDIOwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW65nq5mSV6qSmlmxhBQcPuorKD sbvH+xCjAAejEg/vgxr+cCHWxLLiytxDjJIcTEqivJudBMKF+JLyUyozEosz4otKc1KLDzFK cDArifBKRQPleFMSK6tSi/JhUtIcLErivIwMDAxCAumJJanZqakFqUUwWRkODiUJ3iaQRsGi 1PTUirTMnBKENBMHJ8hwHqDhR8GGFxck5hZnpkPkTzEqSonzbowCSgiAJDJK8+B6wVG9m0n1 FaM40CvCvNtBqniACQGu+xXQYCagwWXveEEGlyQipKQaGEue7l42y+v5n0+yJl99/xyScom/ YseyzvmUkFn11i6Vxe5VEms2PXn/zk5o34rpUpdeFU97dZj9TU1m4NurkryH/rVZXS2rKjr7 5Fro4xUSITz/1hT3Wa2/L9cRwSYTpbPcX/KKzsIVobFeNmrz2EsPnX58MjI4e2bao+pU+bqj Uhl6U458Xa7EUpyRaKjFXFScCACgXyGFxQIAAA== Archived-At: Subject: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:12:25 -0000 This message begins the second Working Group Last Call (WGLC) of "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension". A previous WGLC was held for version 01 of this document. Review during that first WGLC raised some issues that required changes to the content of the document, so another WGLC is needed. The WGLC will last two weeks, ending on Friday, April 28th. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-06 A diff of the changes since the previous WGLC is available at: https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-06.txt&url1=draft-ietf-kitten-pkinit-freshness-01.txt Please review the document and send comments to the Working Group mailing list kitten@ietf.org or the co-chairs kitten-chairs@ietf.org before the end of the WGLC. Any and all comments on the document are sought in order to access the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. This is particularly important if you found issues with the previous version. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - Your Kitten Chairs From nobody Thu Apr 14 20:42:34 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC2312DFEA for ; Thu, 14 Apr 2016 20:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 J-OU4KfXTFEE for ; Thu, 14 Apr 2016 20:42:32 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 4ED6A12DFAC for ; Thu, 14 Apr 2016 20:42:30 -0700 (PDT) X-AuditID: 12074423-58fff7000000258f-f1-57106325128c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id FE.05.09615.52360175; Thu, 14 Apr 2016 23:42:29 -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 u3F3gSef025362 for ; Thu, 14 Apr 2016 23:42:29 -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 u3F3gMlx018140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Apr 2016 23:42:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3F3gMnS025309; Thu, 14 Apr 2016 23:42:22 -0400 (EDT) Date: Thu, 14 Apr 2016 23:42:22 -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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrauaLBBu8Ok7n8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WvOd9aCbSwVj+5PZ29gPMbcxcjJISFgIjHjfwtLFyMXh5BA G5PEtlUnmCCc44wSK2d8YwepEhK4wSRx6BgLhN3AKPFunjyIzSKgLTF/9XxGEJtNQEVi5puN bCC2iICwxO6t78A2CAs4S7TuXAs2h1PASWLf9ZdgNq+Ao8TKxh+MEDMdJR6sWws2X1RAR2L1 /iksEDWCEidnPgGzmQW0JJZP38YygZF/FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JS i3TN9HIzS/RSU0o3MYKCjN1FeQfjyz7vQ4wCHIxKPLwPYgXChVgTy4orcw8xSnIwKYnybnYC CvEl5adUZiQWZ8QXleakFh9ilOBgVhLhvRAPlONNSaysSi3Kh0lJc7AoifMyMjAwCAmkJ5ak ZqemFqQWwWRlODiUJHh9k4AaBYtS01Mr0jJzShDSTBycIMN5gIbHgNTwFhck5hZnpkPkTzHq ciz4cXstkxBLXn5eqpQ477JEoCIBkKKM0jy4OeDksJtJ9RWjONBbwrxVIKN4gIkFbtIroCVM QEvK3vGCLClJREhJNTB6vFDtTqu+W/qCzbY0c/6Ls2ryFe56Tj8jNrj9X31uZ0mC2dHknpk7 p6uunae/cfrlnwpVL/NUIyMvpz3jkzxwt+El61JWtce+jIf/iazXU7wSa65nZnyDXTTO5l/W A0tTm/zDr6SnPm+9VnFm67vAHSmTTdZs2lo3b/Jr5bjuXaJiLv9yv85RYinOSDTUYi4qTgQA cNs7/ukCAAA= Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:42:33 -0000 On Thu, 14 Apr 2016, Benjamin Kaduk wrote: > This message begins the second Working Group Last Call (WGLC) of "Public > Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > Extension". A previous WGLC was held for version 01 of this document. > Review during that first WGLC raised some issues that required changes to > the content of the document, so another WGLC is needed. The WGLC will last > two weeks, ending on Friday, April 28th. The draft is available at: Sorry for the typo; that should be Friday, April 29th. -Ben From nobody Sat Apr 16 15:29:58 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5103A12B015 for ; Sat, 16 Apr 2016 15:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 roft2y5-4w5H for ; Sat, 16 Apr 2016 15:29:54 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 B2D1912B00F for ; Sat, 16 Apr 2016 15:29:53 -0700 (PDT) X-AuditID: 1209190e-cffff70000004bd5-57-5712bce0388f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D3.72.19413.0ECB2175; Sat, 16 Apr 2016 18:29:52 -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 u3GMTpIY024475; Sat, 16 Apr 2016 18:29:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3GMTnZ8020051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Apr 2016 18:29:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3GMTmZH018379; Sat, 16 Apr 2016 18:29:48 -0400 (EDT) Date: Sat, 16 Apr 2016 18:29:48 -0400 (EDT) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <570E0415.5090501@openfortress.nl> Message-ID: References: <570E0415.5090501@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrPtgj1C4wb5rkhZHN69isXj66h6b A5PHkiU/mTw2/GtiC2CK4rJJSc3JLEst0rdL4MrY9Hwta0GneMXC/+uZGhj3CnUxcnJICJhI fL4yj6WLkYtDSKCNSaJvXTeUs5FRYs/kb1DOISaJhR8bmSCcBkaJxWefMIH0swhoS1w/8pER xGYTUJGY+WYjG4gtIqAh8fnXVDCbWUBYYv25GcxdjBwcwgJpEjuWuoKEOQX0Jfas/ABWwivg KLH4/nJ2kBIhAT2Jo0c5QcKiAjoSq/dPYYEoEZQ4OfMJC8RELYnl07exTGAUmIUkNQtJagEj 0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYzggJTk28E4qcH7EKMAB6MSD2/G NsFwIdbEsuLK3EOMkhxMSqK8nQVAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8pruEwoV4UxIr q1KL8mFS0hwsSuK8jAwMDEIC6YklqdmpqQWpRTBZGQ4OJQneBbuBGgWLUtNTK9Iyc0oQ0kwc nCDDeYCGB4HU8BYXJOYWZ6ZD5E8xKkqJ864FSQiAJDJK8+B6wQljN5PqK0ZxoFeEefeBVPEA kw1c9yugwUxAg63fCIIMLklESEk1AH2fFnF3BatH9UqWhpURPlfkrm/vndig8nchj5DGnKtz 181vU7vnXDnDw/oKq0XwobjnnfPWb3iQPMnnoVtDl3e1yMqcWR6Pg+tjtkgVPdorO/+vKN/F HUymBvfLfETY+1ZFWqw5zqSU13J+qdGq6fXvqxV/XVe0Lvv8osn+4VfRuU9rlyl0KLEUZyQa ajEXFScCAHqAZu3zAgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 22:29:56 -0000 [sorry for the extra copy, Rick; I had to enter kitten manually since reply-all tried to send the wrong place, and then I typo'd it] Hi Rick, Greg has already covered some of this, but I also wanted to say a few things. On Wed, 13 Apr 2016, Rick van Rein wrote: > Hello Tom / Kitten, > > Last week the Kerberos IANA registries draft popped up again. I find > the general useful, but I feel strong objections against constraining > "Named Bit Assignments" to the 0..31 range. I mentioned this before, > but now also see a way out. My proposal is the replacement text at the > end of this email. > > My reasons for my objection + alternative are > > (1) specifications should not follow implementations, and certainly not > confirm bad ones; A motto of the IETF says (in part), "we believe in rough consensus and running code". In practice, this means that weight is given to actual existing code, and this point is not really true -- IETF specifications frequently do follow implementations, even bad ones, since that's the route to getting things deployed. A perfect spec that is not implemented is not particularly useful... > (2) limiting to 32 named bits will confirm this lowest common > denominator and increase the number of flawed implementations; > (3) after confirming a 32-bit limit, we have cut off any chance of > growing beyond this; This is also not exactly true; a future standards-track document is permitted to change the registry specification and allow a larger number of bits to be used. And implementations still have to be prepared to decode larger bitstrings with a conformant ASN.1 decoder -- just reading bits off the wire into a uint32 would lead to software vulnerabilities. Perhaps it might confirm it in those libraries' API layer, but that does not seem to be a materially worse situation than what we have at present. > (4) software that is incapable of being updated is a security problem, > not something that a spec should seek to confirm; I'm not sure what is suggesting that software is fully *incapable* of being updated; rather that making updates in this case would be a lot of effort and require churn in the user interface. Seeking to avoid having to go through all that effort until it is fully necessary is reasonable to many people, though reasonable people could certainly disagree. > (5) we currently cannot supply bits for experimental/private use, for > instance for development purposes; developers end up stealing bits and > the registry becomes an administration of such sins. This is true, and is somewhat unfortunate. On the other hand (as Greg notes), there are usually other places in the protocol where similar information could be placed for experimental purposes. That is not a particularly compelling argument, of course, but in the balance, to me, the 32-bit limitation still makes sense for now. -Ben From nobody Sat Apr 16 17:25:13 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C43812DB39 for ; Sat, 16 Apr 2016 17:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=secure-endpoints.com 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 WPjd-d_KBnis for ; Sat, 16 Apr 2016 17:25:11 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0C612DB14 for ; Sat, 16 Apr 2016 17:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1460852688; x=1461457488; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=YCUqEmDnM7upXXRSLcb6z1 kEcBKkIQAYws560Wuzhxk=; b=BsDQ7BkOqsKYkwzEQgc8jU64mDvpP3A+yuzsB3 5vcudUPTjnm7nbdW/UiiC2/hgHPrWFeFUw/WBvc2hIj+Iv/prkMFLLu0OC3FVXPN HZeeepwxosgYBGREXzbczN57N+EU+a2RTbW18ueuWRFAWrmea/CgvQOH/8E9GUv0 isTso= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Sat, 16 Apr 2016 20:24:48 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Sat, 16 Apr 2016 20:24:47 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.1) with ESMTPSA id md50001073739.msg for ; Sat, 16 Apr 2016 20:24:46 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 68.53.147.107 X-MDArrival-Date: Sat, 16 Apr 2016 20:24:46 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=19156ebd1f=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Benjamin Kaduk , kitten@ietf.org References: From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <5712D7A8.30008@secure-endpoints.com> Date: Sat, 16 Apr 2016 19:24:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090108090001010001000702" Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 00:25:12 -0000 This is a cryptographically signed message in MIME format. --------------ms090108090001010001000702 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/25/2016 9:32 PM, Benjamin Kaduk wrote: > Thanks to everyone who reviewed the document for this WGLC. There were= no > major issues raised, so the document will be able to be sent to the IES= G > once a new version is produced that fixes the minor issues that were > raised. >=20 > -Ben Ben, Where do we stand on this document? https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ reports the state as being: In WG Last Call Revised I-D Needed - Issue raised by WGLC but the revised I-D -09 was published on 26 January 2016. Greg confirmed that same day that all of the issues he raised had been address= ed. Heimdal has full implementation ready to be shipped as soon as the IANA registry assignments are made. Thank you. Jeffrey Altman --------------ms090108090001010001000702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDE3MDAyNDA4WjAvBgkqhkiG9w0BCQQxIgQg 4+CC7GTs3xBtisxQA+rpjCAQZ8qmSJ9bN13rKV45IQcwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAHYUU3LVRE7WKdS7/zViJ9TS a3wyBEhhV/C319JCGbCAJOLwqe70a1/uxCtq0g9nh8qfi5W7/hjJfssIoScTPTbInxOcrECp 0n5WYNnFZCnM9HpHvUp3uYIcFR8YpT/TicGjQJkeWh8tCazj9Bb0qqFe3E4CFFM6L3CAUBxs qaxojUgRSo1sIFB76uzNmrinLTsVrSeA1kk253p/dVYofcZqTt8qU+qPKiyt+bqvIHlJHEGw RAdmZUdq07YKqrGS0ez+6wTo8us4AJnK4j13ThpN2DkvWyJ8y7xBsvR6F6ZN8FG/JDWbWG22 BkkFMjJLJtG5x+mqFvojlRYyZ0xf4D8AAAAAAAA= --------------ms090108090001010001000702-- From nobody Sat Apr 16 17:29:14 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1812D137 for ; Sat, 16 Apr 2016 17:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8DSisQsu-z0b for ; Sat, 16 Apr 2016 17:29:10 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 931A812D0AC for ; Sat, 16 Apr 2016 17:29:09 -0700 (PDT) X-AuditID: 1209190d-ab7ff70000004038-01-5712d8d4964c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C0.BD.16440.4D8D2175; Sat, 16 Apr 2016 20:29:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u3H0T7tB022579; Sat, 16 Apr 2016 20:29:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3H0T4di012816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Apr 2016 20:29:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3H0T4I5003464; Sat, 16 Apr 2016 20:29:04 -0400 (EDT) Date: Sat, 16 Apr 2016 20:29:04 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Altman In-Reply-To: <5712D7A8.30008@secure-endpoints.com> Message-ID: References: <5712D7A8.30008@secure-endpoints.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrnvlhlC4wdteBYs/KyexWRzdvIrF gcljyZKfTB4n+86zBjBFcdmkpOZklqUW6dslcGVc7HvIWjCRrWJ9/zvGBsYHLF2MnBwSAiYS t2cvZe1i5OIQEmhjkth3+jsThLORUeLc5F5mCOcQk8TMS0ugnAZGid1fG5lB+lkEtCX+rr7P DmKzCahIzHyzkQ3EFhEwlGj7f5MVxGYWEJZYf24GWL2wgIvEx6v/wGo4BYwkHl6dxQhi8wo4 Sjx9exNsjpDAXEaJTTf5QGxRAR2J1funsEDUCEqcnPmEBWKmlsTy6dtYJjAKzEKSmoUktYCR aRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZQUHJK8u5g/HfX6xCjAAejEg/v iz1C4UKsiWXFlbmHGCU5mJREeTsLBMOF+JLyUyozEosz4otKc1KLDzFKcDArifDOvgZUzpuS WFmVWpQPk5LmYFES5425eTRMSCA9sSQ1OzW1ILUIJivDwaEkwZtwHahRsCg1PbUiLTOnBCHN xMEJMpwHaHgDSA1vcUFibnFmOkT+FKMux4Ift9cyCbHk5eelSonz6oMUCYAUZZTmwc0BJ5Pd TKqvGMWB3hLmnQFSxQNMRHCTXgEtYQJaYv1GEGRJSSJCSqqBMXutjePFBxwL5KK0wmMiteNu pc20LJm7h6FF0SF60ZZjTi/XfY8wDbr3PDsxtVize+eR5/yPvmwvOb8nYT5X7bbsRLcL4h/y ry1Ye/7umUurrdpCfDRfqvQlntqi9WNr+q2fioaCK9Z2sWz/vFRGkXlpwMuoesvZ7dtXGB37 vitQ8eK386IbrimxFGckGmoxFxUnAgAoDCl5AQMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 00:29:12 -0000 Hi Jeffrey, On Sat, 16 Apr 2016, Jeffrey Altman wrote: > On 1/25/2016 9:32 PM, Benjamin Kaduk wrote: > > Thanks to everyone who reviewed the document for this WGLC. There were no > > major issues raised, so the document will be able to be sent to the IESG > > once a new version is produced that fixes the minor issues that were > > raised. > > > > -Ben > > Ben, > > Where do we stand on this document? > > https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ > reports the state as being: > > In WG Last Call > Revised I-D Needed - Issue raised by WGLC The "Revised I-D Needed" flag is no longer needed, sorry about that. As mentioned during the IETF 95 session last week, this document is waiting for the shepherd writeup. -Ben From nobody Sat Apr 16 17:36:32 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FB512E0BB for ; Sat, 16 Apr 2016 17:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=secure-endpoints.com 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 Z04ABmwTP3_q for ; Sat, 16 Apr 2016 17:36:30 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D79612E09D for ; Sat, 16 Apr 2016 17:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1460853367; x=1461458167; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:Cc:From:Openpgp:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=eTioXEG/1bf Y53K/+Y8Z316dnvhEJfmngrKNDZe/s28=; b=fXj02vERKH2d2nUeYTOGyn0DFB2 4QhImVf1Kav4KsVEEikJKTV4qEOOn0HJvVjGVe/TK2Lkb66esmHx2OgxGXI5cI/8 VkYjrYwGhv3V1ibRIh/a1mpIS3w2B3jq/IfFaE/nIZDU4ft4lRT6z0r9vMbA39kx XYhDC9tDMLXulQ/g= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Sat, 16 Apr 2016 20:36:07 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Sat, 16 Apr 2016 20:36:07 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.1) with ESMTPSA id md50001073746.msg for ; Sat, 16 Apr 2016 20:36:07 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 68.53.147.107 X-MDArrival-Date: Sat, 16 Apr 2016 20:36:07 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=19156ebd1f=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Benjamin Kaduk References: <5712D7A8.30008@secure-endpoints.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <5712DA54.3000805@secure-endpoints.com> Date: Sat, 16 Apr 2016 19:35:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080904020705020609000709" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 00:36:31 -0000 This is a cryptographically signed message in MIME format. --------------ms080904020705020609000709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/16/2016 7:29 PM, Benjamin Kaduk wrote: > Hi Jeffrey, >=20 > On Sat, 16 Apr 2016, Jeffrey Altman wrote: >=20 >> On 1/25/2016 9:32 PM, Benjamin Kaduk wrote: >>> Thanks to everyone who reviewed the document for this WGLC. There we= re no >>> major issues raised, so the document will be able to be sent to the I= ESG >>> once a new version is produced that fixes the minor issues that were >>> raised. >>> >>> -Ben >> >> Ben, >> >> Where do we stand on this document? >> >> https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ >> reports the state as being: >> >> In WG Last Call >> Revised I-D Needed - Issue raised by WGLC >=20 > The "Revised I-D Needed" flag is no longer needed, sorry about that. >=20 > As mentioned during the IETF 95 session last week, this document is > waiting for the shepherd writeup. >=20 > -Ben Thanks Ben. --------------ms080904020705020609000709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDE3MDAzNTMyWjAvBgkqhkiG9w0BCQQxIgQg HBR6RDI1eNeBKOFSBIl20h0/QBXXszSgpSrOLoGGraEwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAHLhkemf+OEUFb7FlPB2cKqH Y/gayV75VuM+4Uexcph7c1xJLvssloa2KBdyHfxegif9ur+6qPJqWYQzDLmhPR8oM8BSXuFW OM/ou1qTjiz8nFNe6Ox2qv+Y2pEhFcNqDREA8PvoyZi7553NVBC4YOZuzO/XwfgUPbjYekr8 NSL8A3AtdKGVZZsiIX3hbIrqoJjSL+kcmLhJCNX6uQgG5wD42capeOdPs6uU9LJHTUJtX+DO noIk41UDHmTWjsczxTJKfU+bfPgjkW/kASL0bYiicddG00m96oNyeep+gVG0kJDgtQFyPBhZ rx4t1HofJTZlRWGF8fslIoZZzjiRUo8AAAAAAAA= --------------ms080904020705020609000709-- From nobody Sun Apr 17 23:33:15 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B997612DF6A for ; Sun, 17 Apr 2016 23:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iWLQ7Ebtl7oh for ; Sun, 17 Apr 2016 23:33:10 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC7012DF87 for ; Sun, 17 Apr 2016 23:33:07 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id jiZ11s00L10HQrX01iZ2bV; Mon, 18 Apr 2016 08:33:05 +0200 Message-ID: <57147F9C.7030306@openfortress.nl> Date: Mon, 18 Apr 2016 08:33:00 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk , Greg Hudson References: <570E0415.5090501@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 06:33:14 -0000 Hello Greg and Ben, Thanks for your responses. On a scale between idealism and pragmatism, perhaps I'm leaning over too much towards idealism. I am not deeply concerned if KDC implementations choose to setup 32 bit flags; a KDC is run centrally and can be upgraded. I'm already more concerned about clients but mostly about services that make same this choice in firmware; firmware is at some point not updated anymore. I can't remember the instance, but have seen in this group how such backlog drove choices away from what would otherwise be possible. It is this backlog that concerns me. I understand that the registry can be updated, but I think a registry that states a 32 bit limit gives rise to the creation of aforementioned backlog, especially because there is no reason to state the limitation there. Given that the values are registered under a formal specification process, and so that values 32+ are not going to be released easily, I see no positive side but a potentially strongly negative side, to making a statement in the registry about an upper limit to the number of flags. The rest of my change proposal introduced uses for 32+ values, as a suggestion to implementations to care for those flags. As Greg stated, there is a little more to this than silently ignoring them, so we could discuss whether that is such a good idea. To me, that's a gray area; it is desirable to have Experimental / Private flags but requiring implementations to support such flags may be too much asked. The Specification Required suggestion is more something that arose as a side-effect possibility, it is not that important on its own. Cheers, -Rick From nobody Wed Apr 20 08:58:42 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204AB12DAA5 for ; Wed, 20 Apr 2016 08:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 m00X3_e4UtT4 for ; Wed, 20 Apr 2016 08:58:38 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 1B71312DA10 for ; Wed, 20 Apr 2016 08:58:38 -0700 (PDT) X-AuditID: 1209190e-cffff70000004bd5-6f-5717a72ca5c4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A5.75.19413.C27A7175; Wed, 20 Apr 2016 11:58:37 -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 u3KFwaP7014968; Wed, 20 Apr 2016 11:58:36 -0400 Received: from [18.101.8.204] (vpn-18-101-8-204.mit.edu [18.101.8.204]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3KFwYlw027997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Apr 2016 11:58:36 -0400 To: Benjamin Kaduk References: From: Greg Hudson X-Enigmail-Draft-Status: N1110 Message-ID: <5717A72A.6060406@mit.edu> Date: Wed, 20 Apr 2016 11:58:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrKu7XDzcYOV1Joujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr43v/NvaCgxwV354+ZGpgfMXWxcjJISFgInFi/1n2LkYuDiGB NiaJL7f2skI4GxklFrZMY4NwjjBJ/Om+AdYiLOAs0bpzLTuILSKgJLH4bAtYXEjAUeLBurUs IDabgLLE+v1bWSBWyEn0dk8Cs5kF1CWOPm8Cq+cVUJPo7W0Bm8MioCqx89opsLioQITEk7kn GSFqBCVOznwC1ssp4CSx7/pLdog5ehI7rv9ihbDlJZq3zmaewCg4C0nLLCRls5CULWBkXsUo m5JbpZubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iREcrpJ8OxgnNXgfYhTgYFTi4Q2oFQ8X Yk0sK67MPcQoycGkJMr7pgkoxJeUn1KZkVicEV9UmpNafIhRgoNZSYS3awlQjjclsbIqtSgf JiXNwaIkzsvIwMAgJJCeWJKanZpakFoEk5Xh4FCS4L26FKhRsCg1PbUiLTOnBCHNxMEJMpwH aDjrMpDhxQWJucWZ6RD5U4yKUuK8USDNAiCJjNI8uF5wOknlOPOKURzoFWFeLZB2HmAqgut+ BTSYCWgw/11RkMEliQgpqQZG95VLtK9Fu/apHOtRvWTg7bv72csfkz5v22CbZzenXsPinvKr q7uOWTbNzm31PFLHv1r/oWWuf9KZ2fkGLjqlyX0Gt35N5Kv75RnP/3p65evJjik8HNNm57i2 SVgF6j3b5VOsJmK3YsrOB8rhNns741fZFD6+Kn/t2JLupXe7dx+PMvR0fVCmxFKckWioxVxU nAgAaXScjQIDAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:58:41 -0000 On 04/14/2016 11:12 PM, Benjamin Kaduk wrote: > This message begins the second Working Group Last Call (WGLC) of "Public > Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > Extension". I re-read this draft and found only minor editorial issues: * In section 2, step 1 should say "Section 2.9.3 of [RFC4120]" as in the other references; currently it is missing "of". * Section 2.3 should make a forward reference to section 4. * In section 8 paragraph 1, "KDC provided" should be "KDC-provided". * In section 8 paragraph 2, there should be a comma between "KDCs" and "depending." I would also remove the quotes around "freshness". * In section 8 paragraph 3, the construction "allowing both X as well as Y" is not grammatical. It should either be "allowing both X and Y" or "allowing X as well as Y". Also, there should be a "the" before "existing risks". * Numeric Google search results suggest "implementor" over "implementer," but I don't know what the RFC editor's preference is. "implementer" is used twice in the draft. From nobody Wed Apr 20 15:45:21 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CB312E84E for ; Wed, 20 Apr 2016 15:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 CcVtTfe-L2_U for ; Wed, 20 Apr 2016 15:45:19 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA6C12E82B for ; Wed, 20 Apr 2016 15:45:10 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 8B4ED26C08B; Wed, 20 Apr 2016 15:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=F7pT3zKA9LbvsK1TIaMcxVa2AEw=; b=cLRz4duj0xs agQKLqqm04PuyGU5W+bVzWc+LbmAG/QVTcujEQb/ycjwoyCP1854Ebj9HH7qlRzb qtbmGvkLLiM0JF6PYQdZ67Tov4cyGaCTZK3GarfHj7DR+xQvRSruSpvA17LmSx4B /7/ixm8R4uxKfPElTGqa9RLPSxp6cM40= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 9051A26C085; Wed, 20 Apr 2016 15:45:02 -0700 (PDT) Date: Wed, 20 Apr 2016 17:44:53 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20160420224452.GK25972@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [kitten] Removing unnecessary and damaging check from RFC4120 section 3.2.3 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 22:45:21 -0000 RFC4120 (Kerberos) requires that services check that the cname/crealm fields of the decrypted Authenticator match those in the decrypted Ticket. Section 3.2.3, page 31, says that "the name and realm of the client from the ticket are compared [by the service] against the same fields in the authenticator", and that "[i]f they don't match, the KRB_AP_ERR_BADMATCH error is returned; normally this is caused by a client error or an attempted attack." (This being RFC4120, this has the force of a SHOULD at least, probably a MUST, even though such terms are not used in the quoted text.) I cannot think of a single attack that this foils. If there were such an attack, either it would be utterly uninteresting, or it would imply that the Kerberos cryptosystem and/or cryptographic protocol are broken, in which case we'd have bigger problems. In particular, the Authenticator decrypt integrity check should be sufficient to rule out all interesting attacks. I'm sure you'll agree. That leaves only the "client error" case of the given justification. But this error never happens. There is a USER error case however, not envisioned by RFC4120, where this check fails: with Active Directory as the KDC when the client acquires an INITIAL Ticket for an alias instead of their canonical principal name. In this case the AS puts the canonical name in the cname/crealm fields of the Ticket. If the client did not use the AS canonicalization feature, then the client will not put the correct cname/crealm in subsequent Authenticators, thus AP exchanges with many services will fail due to this check. The user error lies in running "kinit ". The most likely explanation for why this behavior is required by RFC4120 is that this was carried over from Kerberos IV and earlier, harkening back to the days when authentication tags were weak or missing altogether. But those days are behind us, and this check is redundant now. We should remove it. [ASIDE: Incidentally, there is a simple way to do client principal name canonicalization with no new protocols, all on the client side: - first, get a TGT for a client principal - then get a service ticket for the same principal as the service, preferably using user-to-user authentication - extract the canonical cname/crealm -and any authorization-data of interest!- from the service Ticket Of course, this only works if the AS works like Active Directory and puts the canonical cname/crealm in the issued Ticket, not the requested cname/crealm. This seems like very helpful behavior, actually, and for this reason: that the client can perform canonicalization if it wants to (though it shouldn't be necessary if the services stop performing the cname/crealm Authenticator check).] Dropping this unnecessary check will allow non-Windows clients to gracefully recover from user error at sites that have ASes that support silent aliasing as AD does. Alternatively, dropping this unnecessary check could allow the cname/crealm from the Authenticator to be used as a way to indicate that the real client wishes to impersonate another. The application, naturally, would have to decide whether any given impersonation is to be accepted. This use would conflict with the existing user-error case, so I think we can rule out this alternative use of the Authenticator cname/crealm. I propose that we update RFC4120 as follows: - drop the requirement to perform this unnecessary check; - require that the cname/crealm reported to the application be the ones from the Ticket, not the ones from the Authenticator; - recommend/require that the AS put the canonical cname/crealm in the Tickets it issues. Are there other such checks in RFC4120 that should be modified/removed? (At a quick glance I could not find any others.) In the short-term, I'm wondering if implementors shouldn't just go ahead and remove this check from their implementations. For Heimdal this would entail removing 31 lines of text (26 lines of actual code) from one file; no remaining uses of KRB_AP_ERR_BADMATCH would remain. Nico PS: I mention crealm because the crealm too can be aliased, and indeed, the Active Directory KDC supports realm aliasing. From nobody Wed Apr 20 17:16:26 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0412E6AE for ; Wed, 20 Apr 2016 17:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 j7UPVK4ELhqU for ; Wed, 20 Apr 2016 17:16:22 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCBB12E50E for ; Wed, 20 Apr 2016 17:16:22 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 4A84A2005E80E; Wed, 20 Apr 2016 17:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=uttU1SpH5cTGnFLJ61V569rxWnA =; b=sur9RuPO2Ogm9RD4Nd0uRuNgOvmSkEMHFh4JOYRUwVhc0gbvuUPUYYsDgPU UNFVddlhdDYT14XKO9Q+B+EOpazlZTcUt1/EZxhF/aBefS4Helz6ii1K/sRsdxC4 FfrGXWICSUV8jLI0EIIEnvF8tlbUJPKoE0K6pzagPbsX2wvw= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id D61F72005E808; Wed, 20 Apr 2016 17:16:10 -0700 (PDT) Date: Wed, 20 Apr 2016 19:15:51 -0500 From: Nico Williams To: kitten@ietf.org Message-ID: <20160421001550.GL25972@localhost> References: <20160420224452.GK25972@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160420224452.GK25972@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [kitten] Removing unnecessary and damaging check from RFC4120 section 3.2.3 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 00:16:24 -0000 Oy, the check should be removed and it is unnecessary, but I was wrong as to what AD puts in the Ticket: it puts the alias, not the canonical name. I should have checked that more carefully before posting. Nico -- From nobody Thu Apr 28 13:54:16 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D743412D9F1 for ; Thu, 28 Apr 2016 13:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OgF6bJeMf9kH for ; Thu, 28 Apr 2016 13:54:13 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 C6F8C12DA03 for ; Thu, 28 Apr 2016 13:53:46 -0700 (PDT) X-AuditID: 1209190c-ed7ff70000001ce8-5f-572278597c35 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 60.40.07400.95872275; Thu, 28 Apr 2016 16:53:45 -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 u3SKrjGs013622 for ; Thu, 28 Apr 2016 16:53:45 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3SKrdqa013968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Apr 2016 16:53:44 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3SKrcOu028091; Thu, 28 Apr 2016 16:53:38 -0400 (EDT) Date: Thu, 28 Apr 2016 16:53:38 -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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrRtZoRRu0N+hbXF08yoWB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBldB4+wFhwlbXi/KVNTA2Mu1i6GDk5JARMJJqW3WUCsYUE2pgk TnZ7dTFyAdnHGSX2HdjKBuHcYJL4u/gZlNPAKHFv+kGwFhYBbYmm9g1gNpuAisTMNxvZQGwR AWGJ3VvfMYPYwgLOEq0717J3MXJwcAo4Sex6UwwS5hVwlNh3ew8jxOZyiWufF7CD2KICOhKr 909hgagRlDg58wmYzSygJbF8+jaWCYz8s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeX WqRrqJebWaKXmlK6iREcZJI8OxjPvPE6xCjAwajEwzshQTFciDWxrLgy9xCjJAeTkijvwVSl cCG+pPyUyozE4oz4otKc1OJDjBIczEoivCHFQDnelMTKqtSifJiUNAeLkjhv4f7TYUIC6Ykl qdmpqQWpRTBZGQ4OJQle/nKgRsGi1PTUirTMnBKENBMHJ8hwHqDhcWUgw4sLEnOLM9Mh8qcY dTkW/Li9lkmIJS8/L1VKnHcVSJEASFFGaR7cHHBy2M2k+opRHOgtYV4RkHU8wMQCN+kV0BIm oCUCmxRBlpQkIqSkGhg5rtz4EbRq5UezN5u3PDXV3bvXa9lBNstLLcXry5kylvgdvXheq/NH 97Nf/bkCdqYB+2WqMk6ItwpsaK/T26zdNE1TV9qzjrljY0nMTa1lvZlG/r/9prA/KMqNd+hv uSqrWP/77ZZDfhta8nt3nemY1cn95+EE6de5yUffOR7tjLrwOUI59I8SS3FGoqEWc1FxIgCu DZGD6QIAAA== Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 20:54:15 -0000 Reminder: this WGLC ends soon -- please read the document and send comments! -Ben On Thu, 14 Apr 2016, Benjamin Kaduk wrote: > On Thu, 14 Apr 2016, Benjamin Kaduk wrote: > > > This message begins the second Working Group Last Call (WGLC) of "Public > > Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness > > Extension". A previous WGLC was held for version 01 of this document. > > Review during that first WGLC raised some issues that required changes to > > the content of the document, so another WGLC is needed. The WGLC will last > > two weeks, ending on Friday, April 28th. The draft is available at: > > Sorry for the typo; that should be Friday, April 29th. > > -Ben > From nobody Fri Apr 29 10:03:38 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E9E12D12B for ; Fri, 29 Apr 2016 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 dqGbl5MD-jch for ; Fri, 29 Apr 2016 10:03:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F5F12D13E for ; Fri, 29 Apr 2016 10:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1256; q=dns/txt; s=iport; t=1461949416; x=1463159016; h=from:to:subject:date:message-id:mime-version; bh=fvm/kQhtN/lBM9tXw0E/1EQqtjBoeJj7lYNmFgkTkL0=; b=Km1Ug0y9QJUR9PyDkFWdMS+SLQekupLIqyN31fMF6C1YHUU7t6AkWSLE EAk99m+TQH8YOv+0v8AjBfrPUme0L3kmzIPCr2iYNMW7Yo8NAWVyPgYuF IfVbG7wPE9aHx32+yJ1uhh3VfRbVt4lk2J2IKYx5qRl0PT3dlDKaXU57y E=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfBQCokiNX/4ENJK1dgzhTgQO5eoF2I?= =?us-ascii?q?occORMBAQEBAQEBZRwLhEiBCwGBACcEIYgcDqNSoQQBAQEBAQEEAQEBAQEBAQE?= =?us-ascii?q?BDwQEiBcIijaCKwWYEwGBLYF6gWeJCIFRARWETYhdjy8BIQFAg2uIbn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="asc'?scan'208";a="102793055" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 17:03:35 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3TH3ZYU011896 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Apr 2016 17:03:35 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 12:03:34 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 12:03:35 -0500 From: "Matt Miller (mamille2)" To: "kitten@ietf.org" Thread-Topic: Minutes for IETF95 @ BA Thread-Index: AQHRojkQ6Do2B8PvKUeqLwpvYmcCTA== Date: Fri, 29 Apr 2016 17:03:35 +0000 Message-ID: <0341379F-AC1F-4787-A3FE-C8693004C124@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.24.170] Content-Type: multipart/signed; boundary="Apple-Mail=_3CB23D78-DA92-4596-AF08-09A616295BBE"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: [kitten] Minutes for IETF95 @ BA X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 17:03:38 -0000 --Apple-Mail=_3CB23D78-DA92-4596-AF08-09A616295BBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, The draft minutes from our session in Buenos Aires are uploaded: < = https://www.ietf.org/proceedings/95/minutes/minutes-95-kitten > Please send any corrections to the chairs or the list at your earliest = convenience. Thanks, - kitten chairs --Apple-Mail=_3CB23D78-DA92-4596-AF08-09A616295BBE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXI5PlAAoJEDWi+S0W7cO1NcIH/jdh+CRpKiWmTRigL/LASCcj P3hIkAciT4Sq25cQcAFQFBygk66b5OpD1hYZxB6/X2TSgst+b1cGeZ7RihmRSv+p ulcFIeUKTUQ8+mwYkuYSp+hrRAksnFwtwnu9sNcCpNRDWEIyKENfrmENKnoCOgki ioK9q+eP3m4FZVBEpzlT3DROoRMmYu/38RsBGSg1EKIh43zc892w07F7PyCMk+KX J5FDVXsq7OAVzTvxrBOw51dbOp01JEqn0nEQVbaE0AM4V7fMWi8d89if4J72hGCW GdCGzaGewi8rJhGlGm5rEaK0orsF3kbdycfOgwXUaLXCnxZhfUK+CLXqZHwSsys= =qFSe -----END PGP SIGNATURE----- --Apple-Mail=_3CB23D78-DA92-4596-AF08-09A616295BBE-- From nobody Fri Apr 29 12:49:32 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2538E12D0DD for ; Fri, 29 Apr 2016 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nVZ_lE16bTjz for ; Fri, 29 Apr 2016 12:49:30 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 3230A12D096 for ; Fri, 29 Apr 2016 12:49:27 -0700 (PDT) X-AuditID: 1209190c-ed7ff70000001ce8-f9-5723bac6daff Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E8.D9.07400.6CAB3275; Fri, 29 Apr 2016 15:49:26 -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 u3TJnQuA023866; Fri, 29 Apr 2016 15:49:26 -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 u3TJnOhU006514; Fri, 29 Apr 2016 15:49:25 -0400 From: Tom Yu To: Benjamin Kaduk References: Date: Fri, 29 Apr 2016 15:49:24 -0400 In-Reply-To: (Benjamin Kaduk's message of "Thu, 14 Apr 2016 23:12:16 -0400") Message-ID: Lines: 6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrXtsl3K4waM3ehZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxraz65kKvjJWLLwo2cB4nLGLkZNDQsBE4nfTXuYuRi4OIYE2 JonZu9vYIZyNjBKfGq5AOW8YJY6fXccC0sImIC1x/PIuJhBbREBJYvHZFjYQm1lAVOLcuiOs ILawgLNE68617CC2kICjxIN1a8F6WQRUJc7dmcIIMpRToIVR4mh3FzNIgldAV+LA9clgDTwC HBJd7xuZIOKCEidnPmGBWKAlcePfS6YJjPyzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyY l5dapGuol5tZopeaUrqJERxmkjw7GM+88TrEKMDBqMTD++GBUrgQa2JZcWXuIUZJDiYlUd6K RcrhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4v28HyvGmJFZWpRblw6SkOViUxHkL958OExJI TyxJzU5NLUgtgsnKcHAoSfAu2AnUKFiUmp5akZaZU4KQZuLgBBnOAzT8NUgNb3FBYm5xZjpE /hSjLseCH7fXMgmx5OXnpUqJ884CKRIAKcoozYObA04PQoz7XjGKA70lzDsTpIoHmFrgJr0C WsIEtERgkyLIkpJEhJRUA6OG+YbVZx78+nyIOaH/Xvnrno3MhzPYNBQnn1gY/KvMhG9Z8BrF 2HqHh++tH/Xnh7Gaz3prp3+V3TBEYd8D01ep9rt+eV8XZ/9pEHhmYZPXR7aJM6a5GG+9Ebvz UG3c91a/4oAageaSDocLPkxcybZXv8cn6dxcrf+tYP9U4QbR3Xx5P102MSuxFGckGmoxFxUn AgBpvr266gIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 19:49:32 -0000 I've read the current and several previous revisions of this document. The current revision seems reasonable to me, and I can find no obvious substantive issues. I agree with Greg's suggested changes for the minor editorial issues. -Tom