From nobody Mon Dec 1 13:20:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A73C1A912F for ; Mon, 1 Dec 2014 13:20:15 -0800 (PST) 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 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 ljhSlw2oQ3wr for ; Mon, 1 Dec 2014 13:20:13 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221611A912D for ; Mon, 1 Dec 2014 13:20:12 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-72-547cdb8b7803 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 dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 98.DA.03762.B8BDC745; Mon, 1 Dec 2014 16:20:11 -0500 (EST) 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 sB1LKBgB008092; Mon, 1 Dec 2014 16:20:11 -0500 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 sB1LK8oK003841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 16:20:10 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB1LK8x1014875; Mon, 1 Dec 2014 16:20:08 -0500 (EST) Date: Mon, 1 Dec 2014 16:20:08 -0500 (EST) 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+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrNt9uybEYOIXc4tDF44zWhzdvIrF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MpYuK+LqeAxc8W97c0sDYw9zF2MnBwSAiYS 5/dPZ4WwxSQu3FvP1sXIxSEksJhJomHpKhYIZwOjxNUNd6EyB5kkfn26zgbSIiRQL9Fw5TuY zSKgJbF/xncWEJtNQEVi5puNYHERAWGJ3Vvfga1jFlCQ2Ny/l72LkYNDWMBCYsIuK5Awr4Cj xPQFi9lBbFEBHYnV+6ewQMQFJU7OfMIC0aolsXz6NpYJjPyzkKRmIUktYGRaxSibklulm5uY mVOcmqxbnJyYl5dapGuol5tZopeaUrqJERx4kjw7GN8cVDrEKMDBqMTDe+J8TYgQa2JZcWXu IUZJDiYlUV7XK0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryPQcp5UxIrq1KL8mFS0hwsSuK8 m37whQgJpCeWpGanphakFsFkZTg4lCR4+W4BNQoWpaanVqRl5pQgpJk4OEGG8wANdwKp4S0u SMwtzkyHyJ9i1OVoaXrbyyTEkpeflyolznv1JlCRAEhRRmke3BxYwnjFKA70ljCvP8goHmCy gZv0CmgJE9AShuZKkCUliQgpqQbGFR+Ovrnz2V9kQ+uvT04Fb/b87w/KuN5SbT17u7x+1kID +SWF7pN4V/HtNNmrkJg8t3mWg8IsleVm59Y8Tl4tpPDM38HZRnnN6VusMzm1LQ8s/j3P7zmD KkuG593N7/fd0FabWrzs8Iq5rgIRd5/K9qxfaPtm897V+3i8i859vtq8a0H3Gz6L+0osxRmJ hlrMRcWJAPI/tHrzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Pd2qx-XmE_UfCnspBtPC8TPYvHc Cc: kitten-chairs@tools.ietf.org Subject: [kitten] Call for Adoption: draft-short-pkinit-freshness X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 21:20:15 -0000 The chairs are considering adopting draft-short-pkinit-freshness [0] as a kitten draft. We would like to solicit comments on whether to adopt this draft. Since it updates RFC 4556, it seems clear that it needs to be standards-track, but feel free to comment on that as well, if you wish. Please submit comments by December 19th, 2014, either to the chairs or to the list. -Ben, for the kitten co-chairs [0] https://tools.ietf.org/html/draft-short-pkinit-freshness-00 From nobody Mon Dec 1 13:26:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB21A8A52 for ; Mon, 1 Dec 2014 13:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EnrG6y6tQVz for ; Mon, 1 Dec 2014 13:26:36 -0800 (PST) Received: from nm33-vm5.bullet.mail.bf1.yahoo.com (nm33-vm5.bullet.mail.bf1.yahoo.com [72.30.239.205]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A061AC3A5 for ; Mon, 1 Dec 2014 13:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417469158; bh=UsKtTRH+wHDLMpyOz3GLRU8B856OEDxvB0ouuGD+d7A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=L4aq0vrFzk99NNn368/e8eXhj4TnZNDGUGKCmI81v+z83jHUHPS+I6ee/7KXII4K0QDXPD/J9sb3C5AxkFdxHYNjLBWysNapeKnKgBdLlrCbRNk2wjjbOYDYcsuxz5RFwCgHfz230tcRZAQG9cbueXgUVhiKOC9gk62W2CdptLSPBTIYKgGRR0OawRlwC37qXMa6jvrxev4/3ueeFxIhCclhq4fxuAz5WvQEdvF6utwNiZHGRsEpt0uaC1eI0hKQXQZ8PsFVh4plFHp7EMjY3zZx5vcEA+KkZlx0TJT26G6ZcA9YyLmKxxkoGQPErxtJ5ynixAIN4WrJhI74wbwpGQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=mDnkx82IEtH3j4/wLpI2IC7I3MLcajiqU+T39wL/AVHLX38KtNByZs6bKHxRdcjX7/rAx0NHu7aphYQ2D2S02geyUKY9C+BPTY1GR3VAkW57AMj4YcpkWqDjyqtwoXp8FjAM3+VUT7WEHNmKqybi/jSInJOMrpTPMcd/a49qhq56xjuaY7gi5bPuTRU8MyEBg6xsWwTRGWD5AqyCxIX4HTlaFgLoviLaZUZkE1cZ6lRkG7sOPsdqtAfpnPdJavNnsAPj/u8fz97791t782kwcBgkVJGFZGwC1LOQOftQtVVB0yIT5vB3iqksG74v6cputw1VSn+XENrxi4tNDiHc1g==; Received: from [98.139.212.150] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 21:25:58 -0000 Received: from [98.139.212.218] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 21:25:58 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 21:25:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 746864.87726.bm@omp1027.mail.bf1.yahoo.com X-YMail-OSG: KXzgFGsVM1nneE4ci3vEkQwM2EK_mR6LqDBVB.BZRa2JxMA0qFh0mxAsrvQv4zM DHKVuq90SjbSN.ovmSaiCKbMsFi5vxkDHL1uh0ybA0y1ud5B8nr2NYOjYHXsy8n72HgwY8soSZpP C2QKhR.qDJoe_FOeq3jqUqN.79pEFfbpzVdD_Hxc0e_mqzn5hCzg0IUyGT7ii2TGN9mZGi4zrQnj KWbFhlR8b38lATYxMAOvBu7HGaygsCmkhMqE8nNIT95BzOVA3vkLiWVvulr3ot5va70H2tBkywCl UYbUrrguYDMr.PWJt7sRQbuzAMB6Ijw4TcP2IMx9tmQ53btibpyPAtOVYOcUw4cJ5_AYLwwCU3fI a2pL6usmT4KcxGlyRGWNb6q0vZqBRlVvPKSxEWTKXJUVLkJKakUEknQbP7LH0Vet49rymGPpOZ48 Ioxxr2wtwU97X_.9MnUC9aQt1K2FVFzMohOSDVg4lhWm_2XRw_VwoCd7LjiAPI_hPzFdfMkyQBxE gEsY- Received: by 66.196.81.117; Mon, 01 Dec 2014 21:25:58 +0000 Date: Mon, 1 Dec 2014 21:25:57 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk , "kitten@ietf.org" Message-ID: <2120998297.3430123.1417469157859.JavaMail.yahoo@jws10616.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3430122_792731123.1417469157856" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/gZ_cXetSmtitUqCC1mNfoFTba6k Cc: "kitten-chairs@tools.ietf.org" Subject: Re: [kitten] Call for Adoption: draft-short-pkinit-freshness X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 21:26:40 -0000 ------=_Part_3430122_792731123.1417469157856 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Looks like a worthwhile incremental update. ------=_Part_3430122_792731123.1417469157856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Looks like a worthwhile incremental update.
------=_Part_3430122_792731123.1417469157856-- From nobody Mon Dec 1 14:17:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719071A913B for ; Mon, 1 Dec 2014 14:17:27 -0800 (PST) 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 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 1Bf4XYpGqcV4 for ; Mon, 1 Dec 2014 14:17:24 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34821A1A96 for ; Mon, 1 Dec 2014 14:17:23 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-bf-547ce8f2a54a 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A0.66.03354.2F8EC745; Mon, 1 Dec 2014 17:17:22 -0500 (EST) 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 sB1MHKMt002440; Mon, 1 Dec 2014 17:17:20 -0500 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 sB1MHI5l026360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Dec 2014 17:17:20 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB1MHIre022089; Mon, 1 Dec 2014 17:17:18 -0500 (EST) Date: Mon, 1 Dec 2014 17:17:18 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <20141125194322.31870.82600.idtracker@ietfa.amsl.com> Message-ID: References: <20141125194322.31870.82600.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrvvpRU2IwdM9KhZHN69isfjWdZ3Z gcljyZKfTB6zZh1mCmCK4rJJSc3JLEst0rdL4Mr4/mc5U8F23orzj2awNTBO5upi5OSQEDCR uPyjjx3CFpO4cG89WxcjF4eQwGImidUruxghnA2MEisnXIFyDjJJrFm6mrmLkQPIqZc4fdUU pJtFQEviy8Q5zCA2m4CKxMw3G9lASkQE1CWav3uDhJkFhCXWn5sBViIs4CpxcOEtsMWcAk4S zZO62EBsXgFHiWlvu5hAbCEgu/XcR7B6UQEdidX7p7BA1AhKnJz5hAVippbE8unbWCYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGUJhySvLvYPx2UOkQ owAHoxIP74nzNSFCrIllxZW5hxglOZiURHlDngGF+JLyUyozEosz4otKc1KLDzFKcDArifA+ BinnTUmsrEotyodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgXf0cqFGwKDU9tSIt M6cEIc3EwQkynAdo+GeQxbzFBYm5xZnpEPlTjIpS4hDNAiCJjNI8uF5YGnnFKA70ijDvB5Aq HmAKgut+BTSYCWgwQ3MlyOCSRISUVANjfvGs09Gljc8eLF637W3r+R1z+CdrbTe5yGTlbXjw Hif3I9vNpzJDGzYyHfj7SoVN8HvBpSNT1aV8ynYy98xa7Lh25o2jlV3fLmStlJ+Seqtzyb4Z lwLCPlzK7XhZNOfbUT4Lj3oR36QEh13BPR91ZpV233gaqrM1ZcsMw3zJG5PPHdi80ZWlWoml OCPRUIu5qDgRAGJTBpv+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rf2iKqGTaf4kaFXMEldLw2jp6a8 Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 22:17:27 -0000 On Tue, 25 Nov 2014, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : A set of SASL Mechanisms for OAuth > Authors : William Mills > Tim Showalter > Hannes Tschofenig > Filename : draft-ietf-kitten-sasl-oauth-18.txt > Pages : 22 > Date : 2014-11-25 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-18 I looked at the diff and the full document, and don't have any substantive concerns with my individual hat. Some nits that will need fixing at some point in the process: * SASL (and all acronyms, but that's what I noticed) should be expanded at its first use, not the second use. * The Gen-ART reviewer may well ask why Figure 1 shows the authorization request being made directly to the resource owner, when the preferred workflow is for the authorization request to go through the authorization server as an intermediary. * Near the end of page 6, in the text describing the case where authorization fails, s/finalizing a SASL negotiation,/finalizing a SASL negotiation;/ (replace comma with semicolon to avoid comma splice) * In section 3.1.1, is there an extra word in "For OAuth Access Token Types that use request keyed message digest"? Thanks for the updates. -Ben From nobody Mon Dec 1 15:56:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE17A1A883D for ; Mon, 1 Dec 2014 15:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN8glNBwba7w for ; Mon, 1 Dec 2014 15:56:04 -0800 (PST) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC861A1BE1 for ; Mon, 1 Dec 2014 15:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417478163; bh=cxvYiTKQ3I00RF0NqRIPDv/iAThr/ww66lAD/+/N+C8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=gxvOWou8ZDWqqWZPd19uutNNBGrSyUTHQD98GJLHcvaVFB4byDGGq3n/5o4EgmJIvNrDgiW2ii3Ja+aS+WDGasbaTCMNLV5Smq6+Cv+YE9EPlIei1FVEReJsB+lZRwSeQ87IgqExXhFouG1winwNYvTbcNRrdaxkUgvK7RRkAXWYeKzcC0jrc4HIvit1n8G+4UW3xMB0ywToJ1IvvyFJqVrLerk0Qm7e+EKftEBMLnTempSRja856tvE9MbtCm5Co4r1pI1TPm3K6V5Mvo95+/NXe6Sg2bRCCORTCPlkWgwBotfXDIRivwLwd3cidoytLCPZlXqP33coFJiWdvoMcQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=NLoO/nRSFq/H2X0RIATuywDHtzcpgixAiSWBr7eC+lLlhObCEk19LcZ03y9kjI96SL6Abxeagvx66aNoA94f3Q0FB79ScLfxs39qQ+gkhMLzIstoCZ7rodBHuQ+6wTUxIb/PQvaVTt71h5kDB0JUNceXo8cxTereyWQ4yhSp8N8GRYa3tT0ybtiKHfTL6+b/yz1o1cRABArXU23mhbOziHa0EMSIzVnlJak7rPvZxwEmihLlPsfXbDf4fouy1W8mw3OSlausUjQITNYnTv9w4eFKaUIzdn7C3tcJjhtpjbPHM2ATSMMyBZofG6BHOm3u3dTzrHr/tLNrv/1O+LZGtw==; Received: from [98.139.212.152] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 23:56:03 -0000 Received: from [98.139.212.216] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 23:56:03 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 01 Dec 2014 23:56:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 30857.78132.bm@omp1025.mail.bf1.yahoo.com X-YMail-OSG: 590XOyEVM1nEGoeYRSYCTDSqKqDjvJwVgMn7JMsEqOQkA68017.SsH.W8x11fZC dpzAkfMaHIyZ728UskgoykTrc7vdWEholYWksHB_LVrATUcKsQkgohJt8Dic0KwPfLMGGENjyyhh YJVLFzq_VFF5u.2434v721bKJ19k6_tgsjpjEbycCPRGS6EH_luRiyAglz3OU1wKJ7ar18M72i60 ZhE1fxLMbDqGv7_NO1FpDGP4GEhi8kw5Q70ykVzay0KMQ8DxPCqxrtSYHn.UXMx2yHuAkjYUuzai e9.XaChN.vMlURTU_W_h55tIgtZl8FJcm.2P2BldN19BwCfmMQdpuq769G_auTL_4ave5GtOVzgD atR49x5.7Q87zRjrydfD85COGB1by25dMMWJhKz5MD9Diq__xJKUIJEjQqMkckWxx0aaKnanSIm3 LQXssxBCevwZHK7ICWg9ZlB9YfTpfsjdBC.4WHfrUCHk1T9B3hdTh7xvuV2OT6OeF7GU8WdI1mGE- Received: by 66.196.81.112; Mon, 01 Dec 2014 23:56:02 +0000 Date: Mon, 1 Dec 2014 23:56:02 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <1685579356.3501004.1417478162335.JavaMail.yahoo@jws106102.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3501003_1952808825.1417478162333" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/odUrVLuuJud5j5r9BMVRior37No Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 23:56:05 -0000 ------=_Part_3501003_1952808825.1417478162333 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So expand the acronym in the title? =C2=A0I was spelling it out in the firs= t use in the text. Instead of using semicolon why not just make a new sentence? =C2=A0s/finali= zing a SASL negotiation, the additional/finalizing a SASL negotiation. The = additional/ In 3.1.1 the wording is wrong. =C2=A0I think "For OAuth Access Token Types = that include a=C2=A0keyed message digest of the request the default values = MUST be used =C2=A0..." is better. =C2=A0Does that work for you?=C2=A0 ------=_Part_3501003_1952808825.1417478162333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So expand the a= cronym in the title?  I was spelling it out in the first use in the te= xt.

Instead of usin= g semicolon why not just make a new sentence?  s/finalizing a SASL neg= otiation, the additional/finalizing a SASL negotiation. The additional/

In 3.1.1 the wording is wrong.  I think "For OA= uth Access Token Types that include a = ;keyed message digest of the request the default values MUST be used  = ..." is better.  Does that work for you?
 
=
------=_Part_3501003_1952808825.1417478162333-- From nobody Tue Dec 2 10:15:49 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF61A6FC0 for ; Tue, 2 Dec 2014 10:15:47 -0800 (PST) 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 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 l4YtnwJwpxnN for ; Tue, 2 Dec 2014 10:15:45 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A5B1A1BBD for ; Tue, 2 Dec 2014 10:12:53 -0800 (PST) X-AuditID: 1209190d-f793c6d000001ec0-59-547e0124402f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D5.DE.07872.4210E745; Tue, 2 Dec 2014 13:12:52 -0500 (EST) 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 sB2ICpUc027106; Tue, 2 Dec 2014 13:12:52 -0500 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 sB2ICouo003611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Dec 2014 13:12:51 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB2ICnoP002050; Tue, 2 Dec 2014 13:12:49 -0500 (EST) Date: Tue, 2 Dec 2014 13:12:49 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1685579356.3501004.1417478162335.JavaMail.yahoo@jws106102.mail.bf1.yahoo.com> Message-ID: References: <1685579356.3501004.1417478162335.JavaMail.yahoo@jws106102.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-747350241-1417543969=:23489" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hTV1lVhrAsx2N6iYXF08yoWi29d15kd mDyWLPnJ5DFr1mGmAKYoLpuU1JzMstQifbsErozv90+zFczkqri1ewlLA+MP9i5GTg4JAROJ K+cWsEDYYhIX7q1n62Lk4hASmM0kMWvDPUYIZwOjxMqFr6EyB5kknh9dDdYuJFAvMfPfb7B2 FgEtiX87drOB2GwCKhIz32wEsjk4RATUJZq/e4OEmYHMb2feMILYwgKuEgcX3gIbwykQLXHn 821mEJtXwFHiyKrDzBC7JjBKzL62F2y+qICOxOr9U1ggigQlTs58wgIxNECid/YmlgmMgrOQ pGYhSc2C2n3g00VGCFtb4v7NNrYFjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJT SjcxgkNbkncH47uDSocYBTgYlXh4T5yvCRFiTSwrrsw9xCjJwaQkynvzf22IEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHeX8ZAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCd4vIEMFi1LTUyvSMnNKENJMHJwgw3mAhv8EqeEtLkjMLc5Mh8ifYlSUEue9BJIQAElk lObB9cJSzytGcaBXhHlPgVTxANMWXPcroMFMQIPPNoANLklESEk1MJ56aeD0KqOdTedf8Tsr Ges7k1aemnmm1vDvlt02D8svPLa1maV6NnICW+CaP4cnL3Xpii/nNG1/Nnv9v/BGK+Xjb+MT 977kXVq7mqMx/HVvRk3RJJuFhk7PXyQ8eCs5wdTooNBbbrZMttY9CjoPbdYun3pv8sETZ1bX nHBt3PZKYV3Coq3zTeSUWIozEg21mIuKEwHEzDCRGAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/x4fAkbfqfO4qf96khm2iBIsk_rk Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:15:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-747350241-1417543969=:23489 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 1 Dec 2014, Bill Mills wrote: > So expand the acronym in the title? =C2=A0I was spelling it out in the fi= rst use in > the text. No, not in the title. I think the text had changed so the expansion was no longer the first use in the text. [...] This document integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications using the integration into SASL. Hence, this document takes ^^^^ advantage of the OAuth protocol and its deployment base to provide a way to use the Simple Authentication and Security Layer (SASL) > Instead of using semicolon why not just make a new sentence? =C2=A0s/fina= lizing a SASL That works, too :) > In 3.1.1 the wording is wrong. =C2=A0I think "For OAuth Access Token Type= s that > include a=C2=A0keyed message digest of the request the default values MUS= T be used > =C2=A0..." is better. =C2=A0Does that work for you? That works, thanks. -Ben ---559023410-747350241-1417543969=:23489-- From nobody Tue Dec 2 10:31:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7221A1BFB for ; Tue, 2 Dec 2014 10:31:50 -0800 (PST) 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_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaACtSq-I2tD for ; Tue, 2 Dec 2014 10:31:49 -0800 (PST) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B231A1B4A for ; Tue, 2 Dec 2014 10:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417545108; bh=YlXx1u2xdBmkkjuI0mKbC8S8GpJgPIX+mHIXvT6/pcs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SYWzehiGZ7N4/VAOwQfa2VwYJWDEcvqOgx9UUIWdwu4mDj/oz4eCx7cTWbhGxhlJ9Luj9Kzart+jsrQ+FjeLk+OfeGy723xb/KHUfySM4w1T22cq86JR/stDbY+8aD00x1hwsknTb59RqLlnWlforzs0yCW+4rJG+g4nAL7GgSdY1ANLpTPeQ+sBgucgYoP9tTeb24unFIGjs+sfnlI+wxBrxDPllZgk3NNy9lcyQ0llRvLAy3nEF45JR3bBanZ5Hlqcl0NYqhW0WAFThYnVz8a2mXkTUj9IrqwvXuQfHwj6AZu3lSCwOE8m7+/NoWvlg+gUlYZftQDhy0Qjib5bGw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=U9dtBu9is03w70fMpBvIp6+epEQ/WlPJjl9ABHU2KTwm31RkGUOXf0Q6wiRFs2joLq2SAp8AmU4m04ZoXuLOPaG/1pdmolo7RglBptmX2aYJkubf6E9y0s3vJTiSyarG/D7waxMUabNIAn8KuA4lfuYHKzv0ksyji6/CLx+vq/jzxjmNCK78epz6+v5x/cfdzJ0veWiMtOzvVBcEEnNFNWKirQYP5yqPENy+TuYLArNkBtcqKcSBuU2RhElABLVW+DlB+8zT94pKCPRJVUbEuiswPZLiYtE24mC5elpC4QTrgDeewKGtiQZZyd0X7WVcopsjjztHx2rzZEfRxfsMYw==; Received: from [98.139.212.149] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 18:31:48 -0000 Received: from [98.139.212.209] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 18:31:48 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 02 Dec 2014 18:31:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353852.56089.bm@omp1018.mail.bf1.yahoo.com X-YMail-OSG: Tl8mUvkVM1nWbG8x_Wu1Zgl7bVa27aRhYWzu15fqb6HicTGT7iSu0mezJ7qLHVe 9zyjLtXCeeAA7KX51i7sTWzLXOtKyI66Z62Z7ODJ7LOHVtCKT4llrLqv0fK8c3DWjjXxnTyHsnUw Nt81eXOvDnbx3YoGHpLcEEE4Tuq1mhQCnQQw_bfTutmiHISjZDHCmuPJ9kIROAQZ39qYK_vSwpO5 G6EqPWmD4e3.PvCI.CZLCaIs2ZQ4JcvI1y9FJK4rp2xOLF4_3BtO1fs_r9dcVsgp.jHiFKW1XwMx nvGVp9UGOuHTC4ZcYF7zuO.vIIhIMTmRVv80DbueijnTHq0W8aekUL_GdgNAiAeGO.tou1tgpGMR Rjgrz8Jh98W8ra9P5U5aVF9BL4B65TqO2kqhLlAiErQahlnwLSwCQItfBdSBg6YZ6_4EDS8d6zz6 Z6609xl.LUhFgD3YpSrFdNrLucrdcgMIhNmyCF5z4dBYApMCI1BnzWS2H9MKDPg8a472ydc8lOZY- Received: by 76.13.27.35; Tue, 02 Dec 2014 18:31:47 +0000 Date: Tue, 2 Dec 2014 18:31:47 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <807742753.3955309.1417545107505.JavaMail.yahoo@jws10612.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3955308_310436737.1417545107502" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rGaFsSmZ06Emyc2oKVWJraXUi4I Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:31:50 -0000 ------=_Part_3955308_310436737.1417545107502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My bad, I expand SASL both in the abstract and in the 3rd usage, =C2=A0 Lea= ve the first expansion in the Abstract or do that as the first usage in the= Introduction?=20 On Tuesday, December 2, 2014 10:12 AM, Benjamin Kaduk = wrote: =20 On Mon, 1 Dec 2014, Bill Mills wrote: > So expand the acronym in the title? =C2=A0I was spelling it out in the fi= rst use in > the text. No, not in the title.=C2=A0 I think the text had changed so the expansion w= as no longer the first use in the text. =C2=A0 [...] This document =C2=A0 integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications =C2=A0 using the integration into SASL.=C2=A0 Hence, this document takes =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^ =C2=A0 advantage of the OAuth protocol and its deployment base to provide a =C2=A0 way to use the Simple Authentication and Security Layer (SASL) > Instead of using semicolon why not just make a new sentence? =C2=A0s/fina= lizing a SASL That works, too :) > In 3.1.1 the wording is wrong. =C2=A0I think "For OAuth Access Token Type= s that > include a=C2=A0keyed message digest of the request the default values MUS= T be used > =C2=A0..." is better. =C2=A0Does that work for you? That works, thanks. -Ben ------=_Part_3955308_310436737.1417545107502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My bad, I expand= SASL both in the abstract and in the 3rd usage,   Leave the first exp= ansion in the Abstract or do that as the first usage in the Introduction?


=
On Tuesday, December 2, 2014 10:12 AM, Benjamin Kadu= k <kaduk@MIT.EDU> wrote:


On Mon, 1 Dec 2014, Bill Mills wrote:
> So expand the acronym in the title?  I was spelli= ng it out in the first use in
> the text.

No, not in the title.  I think the text had c= hanged so the expansion was
no longer the first use in th= e text.

  [...] This document  integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-b= ased applications
  using the integration into SASL= .  Hence, this document takes
      &= nbsp;                    =   ^^^^
  advantage of the OAuth protocol and = its deployment base to provide a
  way to use the S= imple Authentication and Security Layer (SASL)

> Instead of using semicolon why not just make a new sentence?=  s/finalizing a SASL

That works,= too :)

> In 3.1.1 the wording is wrong.  I think "For OAu= th Access Token Types that
> include a keyed mess= age digest of the request the default values MUST be used
>  ..." is better.  Does that work for you?


That works, thanks.

-Ben

------=_Part_3955308_310436737.1417545107502-- From nobody Tue Dec 2 12:49:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CE71A6F0D for ; Tue, 2 Dec 2014 12:48:59 -0800 (PST) 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 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 gkzClj9hsnnW for ; Tue, 2 Dec 2014 12:48:57 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2C51A1F73 for ; Tue, 2 Dec 2014 12:48:57 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-ee-547e25b87602 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B1.FA.03354.8B52E745; Tue, 2 Dec 2014 15:48:56 -0500 (EST) 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 sB2Kmtq5023363; Tue, 2 Dec 2014 15:48:56 -0500 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 sB2KmsTj032356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Dec 2014 15:48:55 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB2Kmr4H022572; Tue, 2 Dec 2014 15:48:53 -0500 (EST) Date: Tue, 2 Dec 2014 15:48:53 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <807742753.3955309.1417545107505.JavaMail.yahoo@jws10612.mail.bf1.yahoo.com> Message-ID: References: <807742753.3955309.1417545107505.JavaMail.yahoo@jws10612.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1251299985-1417553333=:23489" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1t2hWhdisKBTzeLo5lUsFt+6rjM7 MHksWfKTyWPWrMNMAUxRXDYpqTmZZalF+nYJXBnzJ29kK+hkrzj1q5+1gfEWaxcjJ4eEgInE grbzTBC2mMSFe+vZuhi5OIQEFjNJPD73jQXC2cAo8er2PlYI5yCTRPfTC8wgLUIC9RJndu1k B7FZBLQkTvcfBbPZBFQkZr7ZCDSKg0NEQF2i+bs3SJgZyPx25g0jiC0s4CpxcOEtdpASToFI iX1/HUHCvAKOErN23mSGWNXHKPHgyWyw60QFdCRW75/CAlEkKHFy5hMWkF5mgUCJK3NtJjAK zkKSmYWQmQW1+MCni4wQtrbE/ZttbAsYWVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbo paaUbmIEB7Uk/w7GbweVDjEKcDAq8fCeOF8TIsSaWFZcmXuIUZKDSUmUd55yXYgQX1J+SmVG YnFGfFFpTmrxIUYJDmYlEd4ofqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKY rAwHh5IE70EVoEbBotT01Iq0zJwShDQTByfIcB6g4U9AFvMWFyTmFmemQ+RPMepytDS97WUS YsnLz0uVEud9CDJIAKQoozQPbg4sGb1iFAd6S5g3EaSKB5jI4Ca9AlrCBLTkbEMtyJKSRISU VANjpUy9noKGuJyQ3p+yvhURRdO98pta4xaVeFSea+ETdEkMF926YkOd1AXpz5Wt3tpdm2Z3 8lj9XjnJ9crtm7O07lqV32U0XmaduXnxWxGN5iXB2umBO9xYGkRK3SRTlZ+uLrU5EOTWaSGx NJaBlbHh+cKSq6/767tfvNw5vVIhs5jTIPnEDyWW4oxEQy3mouJEADAJQCEhAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kbDafWmbt8sxpCvooBlvtHlBXr8 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:48:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1251299985-1417553333=:23489 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 2 Dec 2014, Bill Mills wrote: > My bad, I expand SASL both in the abstract and in the 3rd usage, =C2=A0 L= eave > the first expansion in the Abstract or do that as the first usage in the > Introduction? I think it's best to consider the abstract as a separate creature entirely, and try to not use acronyms at all in it. Acronyms can be used in the main text, and should be expanded at the first use in the main text. It looks like the RFC style guide doesn't say anything about acronyms, so maybe I am not speaking from any authority here. -Ben ---559023410-1251299985-1417553333=:23489-- From nobody Tue Dec 2 18:57:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD91A0032 for ; Tue, 2 Dec 2014 18:57:16 -0800 (PST) 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 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 tOYpkRqsRf_1 for ; Tue, 2 Dec 2014 18:57:15 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24EC1A0025 for ; Tue, 2 Dec 2014 18:57:14 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-23-547e7c099da3 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.CB.03326.90C7E745; Tue, 2 Dec 2014 21:57:13 -0500 (EST) 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 sB32vCa1021377; Tue, 2 Dec 2014 21:57:13 -0500 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 sB32vAIU032200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Dec 2014 21:57:12 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB32vAAL009690; Tue, 2 Dec 2014 21:57:10 -0500 (EST) Date: Tue, 2 Dec 2014 21:57:10 -0500 (EST) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: <546F5E3C.1010207@cisco.com> Message-ID: References: <546F5E3C.1010207@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-212323300-1417575430=:23489" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nostZUxdiMOOmqsWhC8cZLY5uXsXi wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGVMPvSRqeC7UMXG+4ENjN/5uxg5OSQETCQ6 u5uZIGwxiQv31rN1MXJxCAksZpL49aCRHSQhJLCBUaLvFQdE4iCTxLkVDWwQiXqJtv0Q3SwC WhKb/m0Bs9kEVCRmvtkIViMioC6x99BUli5GDg5mAUeJLYuUQExhAWuJeTtDQSo4BTQlXn7c A7aKF6jiwMK/TBDTNSQeLd4KZosK6Eis3j+FBaJGUOLkzCdQEwMkTq6vmMAoOAtJZhZCBiTM DHTCgU8XGSFsbYn7N9vYFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11svNLNFLTSndxAgK Z05Jvh2MXw8qHWIU4GBU4uG1iKsLEWJNLCuuzD3EKMnBpCTK21QMFOJLyk+pzEgszogvKs1J LT7EKMHBrCTCm50ElONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuCt rwJqFCxKTU+tSMvMKUFIM3FwggznARq+H6SGt7ggMbc4Mx0if4pRUUqctwwkIQCSyCjNg+uF pZtXjOJArwjzbgep4gGmKrjuV0CDmYAGn22oBRlckoiQkmpgdLHa8+ffbouEA/030+edNvTn 8gvhsrbRevasLzY382TCPamWd4d3ZiyfdsFrauHM0r9M63y5KjxFQrnz9trOkWmSYjeW4Cl2 c1Vi/mnjmvVqr4pFwPz8dYUOQpeO/YyQ6lrLcq931cs9hlH7Cn6vblhwVVvtYuH3mW+7ao1Z t9bKKxra7JukxFKckWioxVxUnAgAKxLpJhIDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mRhB39mkQR8hMXLPpD2d8QaE5JA Cc: "kitten-chairs@tools.ietf.org" Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 02:57:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-212323300-1417575430=:23489 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Please note that there are only a few days remaining in this WGLC. It would be very good to hear from more WG participants. -Ben On Fri, 21 Nov 2014, =E2=8C=98 Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > This message begins the second Working Group Last Call (WGLC) of > "Structure of the GSS Negotiation Loop" < > draft-ietf-kitten-gss-loop-01 >. WGLC will end in two weeks, on > December 5. The draft is available at: > > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-01 > > Because the changes between -00 and -01 are substantial, the Chairs > decided to issue a second last call. > > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the co-chairs < kitten-chairs > at tools.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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUb148AAoJEDWi+S0W7cO1MCAH/RoRKAhl1rdDuAbpI7OWoomY > chsxeJ5xY/Cymjpws5uZQmq1pSgsz0hv2kw9Gv6Y/4hJKi1fH3xAHAZMrIBNdG10 > WiUqOC7+kzphgjveo/jpMusFtrcHSKc3r5Dj413xOOpqfNUfSo2XUBBT4fea7iZF > vALaGdH/9u78rwFAo3cSIojUgj/rJoU7uI1/oat+tek/v04wOIxpmY5QNphXbsBW > YAIdunilGkVTjEqZqhawgEZF8nLQHmHTKsyN5NqJk0jpPC3ljc5gXwAzMaJCne1V > 9g/Ng5RFYWMNM7EgSel3prenY3QYw5uTydi42YksOFIHtTq3qpTVYS71sCHh62Q=3D > =3D/6Sj > -----END PGP SIGNATURE----- > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > ---559023410-212323300-1417575430=:23489-- From nobody Wed Dec 3 04:26:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7011A1A93 for ; Wed, 3 Dec 2014 04:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o5xHzVgsdKs for ; Wed, 3 Dec 2014 04:26:07 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 88FD91A1AC6 for ; Wed, 3 Dec 2014 04:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1417609564; d=isode.com; s=selector; i=@isode.com; bh=bkVsk2yEZ8ZOnnva7dtAv9mSF7bopiU6NdTn43jEfOA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lgWdxltc+WbPmi2iKPuK8McPP3cq+oqS/aETIZ/IMo8PTQmwDN2jKiAs2cQVlnR02NSdFg kI9+FXxWOysfYlqz9tSzJPBI8rLnvDyjwo7ncWERE7Xj3U3o0obBMAr5/fFiJ4SpQfP7CZ ulQNbi0mf/khtzYBXxDch/5e/UrOwVw=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 3 Dec 2014 12:26:04 +0000 Message-ID: <547F00C5.8020604@isode.com> Date: Wed, 03 Dec 2014 12:23:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Benjamin Kaduk , Bill Mills References: <807742753.3955309.1417545107505.JavaMail.yahoo@jws10612.mail.bf1.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/_-LaIWPe-_T6rejyvBLUAUf74p4 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:26:10 -0000 On 02/12/2014 20:48, Benjamin Kaduk wrote: > On Tue, 2 Dec 2014, Bill Mills wrote: > >> My bad, I expand SASL both in the abstract and in the 3rd usage, Leave >> the first expansion in the Abstract or do that as the first usage in the >> Introduction? > I think it's best to consider the abstract as a separate creature > entirely, and try to not use acronyms at all in it. This is true. Although Acronyms, if used, need to be expanded in the Abstract. > Acronyms can be used in the main text, and should be expanded at the first > use in the main text. > > It looks like the RFC style guide doesn't say anything about acronyms, so > maybe I am not speaking from any authority here. From nobody Thu Dec 4 11:46:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7911A026C for ; Thu, 4 Dec 2014 11:46:02 -0800 (PST) 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 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 bG9EeRJmzq8R for ; Thu, 4 Dec 2014 11:45:54 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4B02D1A1A2C for ; Thu, 4 Dec 2014 11:45:54 -0800 (PST) X-AuditID: 12074422-f79476d000000d9e-9b-5480b9f1e510 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 72.72.03486.1F9B0845; Thu, 4 Dec 2014 14:45:53 -0500 (EST) 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 sB4JjlQf031242; Thu, 4 Dec 2014 14:45:47 -0500 Received: from [18.101.8.196] (vpn-18-101-8-196.mit.edu [18.101.8.196]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB4Jjje9013240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Dec 2014 14:45:47 -0500 Message-ID: <5480B9E9.7050205@mit.edu> Date: Thu, 04 Dec 2014 14:45:45 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benjamin Kaduk , "kitten@ietf.org" References: <546F5E3C.1010207@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrPtxZ0OIwbpOUYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9+Ob8wF09kqvrx7wt7A+Ieli5GTQ0LAROLOuv2sELaYxIV7 69m6GLk4hAQWM0ns3P+OHcLZwCgxeclzJgjnMJNE671DYC28AmoSt+7dZgSxWQRUJfa2fGUC sdkElCXW798KtIKDQ1QgTGLqUh6IckGJkzOfgG0WEXCXWLL+NTNIibCAtcS8naEgYSGBOIm7 rdfBpnMKOEls+PiSHcRmFtCT2HH9FyuELS/RvHU28wRGgVlIps5CUjYLSdkCRuZVjLIpuVW6 uYmZOcWpybrFyYl5ealFuqZ6uZkleqkppZsYQSHJ7qK0g/HnQaVDjAIcjEo8vAW760OEWBPL iitzDzFKcjApifIeW9cQIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE9wRIjjclsbIqtSgfJiXN waIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvfKDqBGwaLU9NSKtMycEoQ0EwcnyHAeoOFW O0GGFxck5hZnpkPkTzHqcrQ0ve1lEmLJy89LlRLnPQEySACkKKM0D24OLJW8YhQHekuYNxyk igeYhuAmvQJawgS05GxDLciSkkSElFQDo1jijxj3E/O2blmXy8MntvaY4Mm7NSJ9S87ZZV36 Fxo7+9ENGf+b3xJYL5/PnjJ75YW8W98U92hM2Pfw884l9pqZqxt2MXiF3+TjSr236NGvPu+7 J96I3bWc4Je0Sf5+7d9dNQferd7kfU3czurVa2F78VUbn66Pyulpjr70/Yb5k+0htxh4S04p sRRnJBpqMRcVJwIAcE8r/wADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JX5YtllFrOIB5Svw7-FpKSPff40 Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 19:46:03 -0000 I found one minor substantive concern: * In the example code, check_authz should operate on a gss_name_t, not a pointer to a gss_name_t. I also found some editorial nits: * intiator -> initiator (twice, in sections 3.3 and 4.3) * GSS_Accpet_sec_context -> GSS_Accept_sec_context (section 4.1) * token, for new... -> token for new... (section 4.3) * while(!acceptor_established) -> while (!acceptor_established) (also in the comment at the end of that loop) * In section 6, "An application using the GSS-API requests that certain features (...), but" is either missing a clause or contains an extra "that". * In section 6, "In many cases it is convenient for GSS acceptors to accept security context..." should either use an article or pluralize "context". From nobody Fri Dec 5 09:44:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7641AD4B8 for ; Fri, 5 Dec 2014 09:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ntuu_T95_-Th for ; Fri, 5 Dec 2014 09:44:21 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFE41AD4B5 for ; Fri, 5 Dec 2014 09:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=852; q=dns/txt; s=iport; t=1417801460; x=1419011060; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=EWHYN0C+zjoN4nhCkCUhBUaUf4M0PJ6Zt3Tm+PhBOiM=; b=KniUMa8fG8+gOFn8bKWq2gMTgFy4dFBrlB7afWH00VWKehleeUy9q/D5 HyELiHqQMkXtG0WsdoQk09KO2iSNLDlmQOZov6yB0jxRjCWwJIaTq/w5C dGXrtKRz5NRretb5/BzBCq8ucUznj+ZFVkFVU0Y2qfq4Dy4DlQtxf6T0D 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAPntgVStJV2U/2dsb2JhbABZgwZSWASDAcNEhhsCgR4WAQEBAQF9hAMBAQQjVRELGgIFFgsCAgkDAgECAUUGAQwIAQGIN8ARlmMBAQEBAQEBAQEBAQEBAQEBAQEBFQSBKI50OoJvgUcBBIowiRSGG4EihU2IboNiggAcgXNPgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,523,1413244800"; d="scan'208";a="103065190" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 05 Dec 2014 17:44:19 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB5HiJ57027159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 17:44:19 GMT Received: from [10.129.24.46] (10.129.24.46) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 5 Dec 2014 11:44:19 -0600 Message-ID: <5481EEF2.3010305@cisco.com> Date: Fri, 5 Dec 2014 10:44:18 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "kitten@ietf.org" , "kitten-chairs@tools.ietf.org" References: <546F5E3C.1010207@cisco.com> In-Reply-To: <546F5E3C.1010207@cisco.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.46] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CYcmeltDZxfQHB31SkhE6WsPRjo Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 17:44:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 A reminder that today is the last day of the Working Group Last Call on draft-ietf-kitten-gss-loop-01. So far we have heard from Nico, Greg, and the author. If you have any comments, now is your last chance! Thanks, - - Your Kitten Chairs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUge7yAAoJEDWi+S0W7cO1+w8H/io9XU5vE4aFqpGuyO7lblSK LzK0TYEcE6WLF7N9yuzcNSJbUE1ryA5o67fy2PYqtrHYGi3Eu5OaPz2SvdKhnKlt HiH195wYh/TzI4XJsyVT9Q2aUAqF+k+lOD7DYSTVQZVzGb5lSs32twCu/UAHX09d hjet+WHDuHeAyL30N3NSNGaVDMjeXw+Gvwv5ETUcOOx5du/W3FmMtvFtpCqAB948 Jq1tiGAXjWrDRzHcWAwCxDhIBFW9vx3bsBTdOCw/fXuzi+vyIOLX5NHNWWwSL2Jv HwGo/AxQucSNK6ugCEYOuTBU9iat9egGpU+M9BjUCqWFO8Gb08JO8czOFQtAkdk= =Wm2m -----END PGP SIGNATURE----- From nobody Fri Dec 5 12:03:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E681ACDA6; Fri, 5 Dec 2014 12:03:24 -0800 (PST) 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 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 86mVl201X8Mo; Fri, 5 Dec 2014 12:03:22 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62811A008F; Fri, 5 Dec 2014 12:03:21 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-0c-54820f88156d 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 dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 01.4B.03326.88F02845; Fri, 5 Dec 2014 15:03:20 -0500 (EST) 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 sB5K3JLT025528; Fri, 5 Dec 2014 15:03:20 -0500 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 sB5K3HMr026808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Dec 2014 15:03:18 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB5K3GEf000571; Fri, 5 Dec 2014 15:03:16 -0500 (EST) Date: Fri, 5 Dec 2014 15:03:16 -0500 (EST) From: Benjamin Kaduk To: "Adamson, Andy" In-Reply-To: Message-ID: References: <20141119180500.1172.39180.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixCmqrdvB3xRiMGefnsXRzatYLGa/f8Rq MX2RlQOzx5IlP5k8Znz6whbAFMVlk5Kak1mWWqRvl8CVcWPBLtaCDRoVW/YnNzAeVOhi5OSQ EDCReNO5kRnCFpO4cG89WxcjF4eQwGImiZ//5rFAOBsYJaYe/M8I4Rxkkni55yALSIuQQL3E kom3GEFsFgEtiaefdoLZbAIqEjPfbAQaxcEhImAgsXGpKkiYWUBZ4sCnFUwgtrCAq8S5I/vY QGxOgUCJRZt6wFp5BRwljq1cC7XrLaPEt7kdYEWiAjoSq/dPYYEoEpQ4OfMJC8RQLYnl07ex TGAUnIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzggJXk3cH4 7qDSIUYBDkYlHt4VEo0hQqyJZcWVuYcYJTmYlER5jT8BhfiS8lMqMxKLM+KLSnNSiw8xSnAw K4nwJs8GyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfDO4GsKERIs Sk1PrUjLzClBSDNxcIIM5wEavhGkhre4IDG3ODMdIn+KUVFKnPccSEIAJJFRmgfXC0sorxjF gV4R5m0GqeIBJiO47ldAg5mABt8tBrm6uCQRISXVwJhYfE6HReVit6Dyr5AJ2+zYdjpOdS68 sqbkdUWVy6zZIiWbuAoFzhWa/pvgW8z12fmR0q3DLv9sZ7HMUNdM0Kn88znwBfOEulgdx2cx ep+t78fZtS/d77UwYMKH1UlyWsarbKZN83b5yLP4QXmzyJU5TyNnveVt7M/Jn81u+6Nsj9Xk i0d3nVNiKc5INNRiLipOBACgZLGMAwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/gFUkisRzMXQdAwFhtiMSrnICRtg Cc: kitten@ietf.org, nfsv4@ietf.org Subject: Re: [kitten] [nfsv4] I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 20:03:24 -0000 Adding nfsv4 to receive the extra feedback, and kitten since I don't think the proposed solution for multi-principal assertion in the new draft was posted there yet. On Tue, 2 Dec 2014, Andy Adamson wrote: > Any comments on the multi-principal assertion changes? I think I > handled it correctly - replacing the nonce/MIC of nonce with MIC of > RPC header including credential using the inner context for both args > and reply. I'll briefly summarize the proposal for the kitten folks (and to verify that I'm reading it correctly). I will play very fast-and-loose with the XDR and field names, for concision. To recall, the RPCSEC_GSS traffic involves the generic RPC header followed by the RPC body. The header is: struct { [stuff, includes sequence number which is unique per transmission] credential verifier } Where the verifier is basically a GSS MIC over the header up to and including the credential. This verifier is always a GSS MIC regardless of the protection of the RPC body (none, integrity, or privacy). For integrity-protected RPCs (which are mostly what we care about here, since with confidentiality protection an attacker can't grab the inner verifier), the RPC body is: struct { sequence number XDR-encoded call/args/etc. verifier } where the verifier is a GSS MIC over the sequence number and the XDR blob. For RPCSEC_GSS_CREATE, party of the "XDR-encoded call/args/etc" is supposed to be the GSS inner context handle and verifier, which identify the user part of the multi-principal authentication. The version in the -08 was just a context handle, nonce, and mic over the nonce, which could be read by an attacker and replayed in an attacker-controlled parent connection. The new proposal is to have this role played by: struct { credential id verifier } where the verifier is now a GSS MIC over the current RPC header, up to and including the credential (i.e., the same content as the RPC header's verifier). Since this structure is included in the RPC call body, it will be included in the MIC over the body as part of the RPC integrity protection (this is not really relevant for preventing an attacker from replaying the inner authenticator). I think that the current proposal (-09) has acceptable security properties, since the inner verifier is tied to the outer context handle. Potentially an attacker could replay or MITM a call, but would not be able to use the resulting child context handle, since it is tied to the actual outer context's GSS security context. That said, I don't think there is any reason to exclude the RPC header verifier field from the GSS MIC with the inner handle, since the RPC header can be fully constructed by that point, and it might end up providing slightly tighter binding of the inner handle to the outer RPC. It also might be worth thinking about including the inner context handle id in the MIC, but it is probably not necessary. [kitten folks can probably stop reading here] > We need to goto WGLC, so I'm putting out one more draft. I have some > miscellaneous fixes - including your flattening of rigs_assertion. Another miscellaneous fix: Section 2 reads rather strangely, with the first bullet point just assuming that there is an existing RPCSEC_GSSv3 context handle and saying nothing about how it is created. That text could probably be reworked to be more clear and accurate, thought I don't have any concrete suggestions offhand. Section 2.3 also reads a bit oddly, with the first paragraph describing a situation that would have occurred if the MITM problem was not addressed, and the second paragraph describing the fix. Having the first paragraph read as if the MITM vulnerability is still present in the protocol specified by this document is rather strange. Section 2.5 says that RPCSEC_GSS_BIND_CHANNEL MUST NOT be used on a v3 handle, but section 2.7 still lists rpc_gss_svc_channel_prot as an acceptable security service for protecting the _CREATE and _LIST control messages -- rpc_gss_svc_channel_prot cannot be used on a non-child v3 handle unless RPCSEC_GSS_BIND_CHANNEL has been performed. Perhaps a full review of the document should be made to ensure that all of the coverage of the v2 channel binding procedure is self-consistent. I guess rpc_gss_svc_channel_prot could make sense for _LIST, but I don't think it works for _CREATE, so perhaps that should be noted in the bullet item in section 2.7. There is probably something to be said about the ordering of entries in rcr_assertions (with respect to rca_assertions' order). If I'm reading correctly (I skimmed that part a bit) the server returns in rcr_assertions exactly the subset of rca_assertions which was accepted by the server's processing. The client may want to verify which of its assertions were accepted, and requiring the server to return things in the same order would facilitate implementation efficiency in the client. Grammar nits: In the penultimate paragraph of section 2.7.1.1, s/the server send/the server sends/ -Ben From nobody Fri Dec 5 14:12:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09C61A1EF9; Fri, 5 Dec 2014 14:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2NCN51la7bE; Fri, 5 Dec 2014 14:12:30 -0800 (PST) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B871A0067; Fri, 5 Dec 2014 14:12:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,525,1413270000"; d="txt'?scan'208";a="173440311" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx11-out.netapp.com with ESMTP; 05 Dec 2014 14:12:30 -0800 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 5 Dec 2014 14:12:29 -0800 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::1c50:4d70:9302:1313%21]) with mapi id 15.00.0995.031; Fri, 5 Dec 2014 14:12:29 -0800 From: "Adamson, Andy" To: Benjamin Kaduk Thread-Topic: [nfsv4] I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-09.txt and new draft-ietf-nfsv4-rpcsec-gssv3-10.txt Thread-Index: AQHQENiOnL00TZjl7kSjk6uUCxq9sQ== Date: Fri, 5 Dec 2014 22:12:28 +0000 Message-ID: References: <20141119180500.1172.39180.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.122.56.79] Content-Type: multipart/mixed; boundary="_003_AC5C7128DB5A4CDEBD745B51B5A7E4CFnetappcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/0_wtE1lFp4VMWv1-yKdE7TfVFuk Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-09.txt and new draft-ietf-nfsv4-rpcsec-gssv3-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 22:12:39 -0000 --_003_AC5C7128DB5A4CDEBD745B51B5A7E4CFnetappcom_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 DQo+IE9uIERlYyA1LCAyMDE0LCBhdCAzOjAzIFBNLCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtATUlU LkVEVT4gd3JvdGU6DQo+IA0KPiBBZGRpbmcgbmZzdjQgdG8gcmVjZWl2ZSB0aGUgZXh0cmEgZmVl ZGJhY2ssIGFuZCBraXR0ZW4gc2luY2UgSSBkb24ndCB0aGluaw0KPiB0aGUgcHJvcG9zZWQgc29s dXRpb24gZm9yIG11bHRpLXByaW5jaXBhbCBhc3NlcnRpb24gaW4gdGhlIG5ldyBkcmFmdCB3YXMN Cj4gcG9zdGVkIHRoZXJlIHlldC4NCg0KSGVsbG8gQmVuDQoNClRoZSBoaWdoIGxldmVsIHByb3Bv c2VkIHNvbHV0aW9uIGZvciBtdWx0aS1wcmluY2lwYWwgYXNzZXJ0aW9uIGFzIHdlbGwgYXMgdGhl IGRyYWZ0LTA5IHdhcyBwb3N0ZWQgb24gdGhlIG5mc3Y0IGxpc3QuIFRoYW5rcyBmb3IgcG9zdGlu ZyB0byBraXR0ZW4uDQoNCkkgYmVsaWV2ZSB0aGUgYXR0YWNoZWQgZHJhZnQtMTAgYWRkcmVzc2Vz IHlvdXIgcmV2aWV3IGNvbW1lbnRzLg0KDQpJIGFsc28gYWRkZWQgYSBub3RlIGFib3V0IE5GU3Y0 LjEgU1NWIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uIHNlY3Rpb24uDQoNCkNvbW1lbnRz IGluLWxpbmUuDQoNCj4gDQo+IE9uIFR1ZSwgMiBEZWMgMjAxNCwgQW5keSBBZGFtc29uIHdyb3Rl Og0KPiANCj4+IEFueSBjb21tZW50cyBvbiB0aGUgbXVsdGktcHJpbmNpcGFsIGFzc2VydGlvbiBj aGFuZ2VzPyBJIHRoaW5rIEkNCj4+IGhhbmRsZWQgaXQgY29ycmVjdGx5IC0gcmVwbGFjaW5nIHRo ZSBub25jZS9NSUMgb2Ygbm9uY2Ugd2l0aCBNSUMgb2YNCj4+IFJQQyBoZWFkZXIgaW5jbHVkaW5n IGNyZWRlbnRpYWwgdXNpbmcgdGhlIGlubmVyIGNvbnRleHQgZm9yIGJvdGggYXJncw0KPj4gYW5k IHJlcGx5Lg0KPiANCj4gSSdsbCBicmllZmx5IHN1bW1hcml6ZSB0aGUgcHJvcG9zYWwgZm9yIHRo ZSBraXR0ZW4gZm9sa3MgKGFuZCB0byB2ZXJpZnkNCj4gdGhhdCBJJ20gcmVhZGluZyBpdCBjb3Jy ZWN0bHkpLiAgSSB3aWxsIHBsYXkgdmVyeSBmYXN0LWFuZC1sb29zZSB3aXRoIHRoZQ0KPiBYRFIg YW5kIGZpZWxkIG5hbWVzLCBmb3IgY29uY2lzaW9uLg0KPiANCj4gVG8gcmVjYWxsLCB0aGUgUlBD U0VDX0dTUyB0cmFmZmljIGludm9sdmVzIHRoZSBnZW5lcmljIFJQQyBoZWFkZXIgZm9sbG93ZWQN Cj4gYnkgdGhlIFJQQyBib2R5Lg0KPiANCj4gVGhlIGhlYWRlciBpczoNCj4gc3RydWN0IHsNCj4g ICBbc3R1ZmYsIGluY2x1ZGVzIHNlcXVlbmNlIG51bWJlciB3aGljaCBpcyB1bmlxdWUgcGVyIHRy YW5zbWlzc2lvbl0NCj4gICBjcmVkZW50aWFsDQo+ICAgdmVyaWZpZXINCj4gfQ0KPiANCj4gV2hl cmUgdGhlIHZlcmlmaWVyIGlzIGJhc2ljYWxseSBhIEdTUyBNSUMgb3ZlciB0aGUgaGVhZGVyIHVw IHRvIGFuZA0KPiBpbmNsdWRpbmcgdGhlIGNyZWRlbnRpYWwuICBUaGlzIHZlcmlmaWVyIGlzIGFs d2F5cyBhIEdTUyBNSUMgcmVnYXJkbGVzcyBvZg0KPiB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgUlBD IGJvZHkgKG5vbmUsIGludGVncml0eSwgb3IgcHJpdmFjeSkuDQo+IA0KPiBGb3IgaW50ZWdyaXR5 LXByb3RlY3RlZCBSUENzICh3aGljaCBhcmUgbW9zdGx5IHdoYXQgd2UgY2FyZSBhYm91dCBoZXJl LA0KPiBzaW5jZSB3aXRoIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIGFuIGF0dGFja2VyIGNh bid0IGdyYWIgdGhlIGlubmVyDQo+IHZlcmlmaWVyKSwgdGhlIFJQQyBib2R5IGlzOg0KPiBzdHJ1 Y3Qgew0KPiAgICBzZXF1ZW5jZSBudW1iZXINCj4gICAgWERSLWVuY29kZWQgY2FsbC9hcmdzL2V0 Yy4NCj4gICAgdmVyaWZpZXINCj4gfQ0KPiB3aGVyZSB0aGUgdmVyaWZpZXIgaXMgYSBHU1MgTUlD IG92ZXIgdGhlIHNlcXVlbmNlIG51bWJlciBhbmQgdGhlIFhEUiBibG9iLg0KPiANCj4gRm9yIFJQ Q1NFQ19HU1NfQ1JFQVRFLCBwYXJ0eSBvZiB0aGUgIlhEUi1lbmNvZGVkIGNhbGwvYXJncy9ldGMi IGlzDQo+IHN1cHBvc2VkIHRvIGJlIHRoZSBHU1MgaW5uZXIgY29udGV4dCBoYW5kbGUgYW5kIHZl cmlmaWVyLCB3aGljaCBpZGVudGlmeQ0KPiB0aGUgdXNlciBwYXJ0IG9mIHRoZSBtdWx0aS1wcmlu Y2lwYWwgYXV0aGVudGljYXRpb24uICBUaGUgdmVyc2lvbiBpbiB0aGUNCj4gLTA4IHdhcyBqdXN0 IGEgY29udGV4dCBoYW5kbGUsIG5vbmNlLCBhbmQgbWljIG92ZXIgdGhlIG5vbmNlLCB3aGljaCBj b3VsZA0KPiBiZSByZWFkIGJ5IGFuIGF0dGFja2VyIGFuZCByZXBsYXllZCBpbiBhbiBhdHRhY2tl ci1jb250cm9sbGVkIHBhcmVudA0KPiBjb25uZWN0aW9uLiAgVGhlIG5ldyBwcm9wb3NhbCBpcyB0 byBoYXZlIHRoaXMgcm9sZSBwbGF5ZWQgYnk6DQo+IHN0cnVjdCB7DQo+ICAgIGNyZWRlbnRpYWwg aWQNCj4gICAgdmVyaWZpZXINCj4gfQ0KPiB3aGVyZSB0aGUgdmVyaWZpZXIgaXMgbm93IGEgR1NT IE1JQyBvdmVyIHRoZSBjdXJyZW50IFJQQyBoZWFkZXIsIHVwIHRvIGFuZA0KPiBpbmNsdWRpbmcg dGhlIGNyZWRlbnRpYWwgKGkuZS4sIHRoZSBzYW1lIGNvbnRlbnQgYXMgdGhlIFJQQyBoZWFkZXIn cw0KPiB2ZXJpZmllcikuDQo+IA0KPiBTaW5jZSB0aGlzIHN0cnVjdHVyZSBpcyBpbmNsdWRlZCBp biB0aGUgUlBDIGNhbGwgYm9keSwgaXQgd2lsbCBiZSBpbmNsdWRlZA0KPiBpbiB0aGUgTUlDIG92 ZXIgdGhlIGJvZHkgYXMgcGFydCBvZiB0aGUgUlBDIGludGVncml0eSBwcm90ZWN0aW9uICh0aGlz IGlzDQo+IG5vdCByZWFsbHkgcmVsZXZhbnQgZm9yIHByZXZlbnRpbmcgYW4gYXR0YWNrZXIgZnJv bSByZXBsYXlpbmcgdGhlIGlubmVyDQo+IGF1dGhlbnRpY2F0b3IpLg0KPiANCj4gSSB0aGluayB0 aGF0IHRoZSBjdXJyZW50IHByb3Bvc2FsICgtMDkpIGhhcyBhY2NlcHRhYmxlIHNlY3VyaXR5DQo+ IHByb3BlcnRpZXMsIHNpbmNlIHRoZSBpbm5lciB2ZXJpZmllciBpcyB0aWVkIHRvIHRoZSBvdXRl ciBjb250ZXh0IGhhbmRsZS4NCj4gUG90ZW50aWFsbHkgYW4gYXR0YWNrZXIgY291bGQgcmVwbGF5 IG9yIE1JVE0gYSBjYWxsLCBidXQgd291bGQgbm90IGJlIGFibGUNCj4gdG8gdXNlIHRoZSByZXN1 bHRpbmcgY2hpbGQgY29udGV4dCBoYW5kbGUsIHNpbmNlIGl0IGlzIHRpZWQgdG8gdGhlIGFjdHVh bA0KPiBvdXRlciBjb250ZXh0J3MgR1NTIHNlY3VyaXR5IGNvbnRleHQuDQo+IA0KPiBUaGF0IHNh aWQsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IHJlYXNvbiB0byBleGNsdWRlIHRoZSBSUEMg aGVhZGVyDQo+IHZlcmlmaWVyIGZpZWxkIGZyb20gdGhlIEdTUyBNSUMgd2l0aCB0aGUgaW5uZXIg aGFuZGxlLCBzaW5jZSB0aGUgUlBDDQo+IGhlYWRlciBjYW4gYmUgZnVsbHkgY29uc3RydWN0ZWQg YnkgdGhhdCBwb2ludCwgYW5kIGl0IG1pZ2h0IGVuZCB1cA0KPiBwcm92aWRpbmcgc2xpZ2h0bHkg dGlnaHRlciBiaW5kaW5nIG9mIHRoZSBpbm5lciBoYW5kbGUgdG8gdGhlIG91dGVyIFJQQy4NCj4g DQo+IEl0IGFsc28gbWlnaHQgYmUgd29ydGggdGhpbmtpbmcgYWJvdXQgaW5jbHVkaW5nIHRoZSBp bm5lciBjb250ZXh0IGhhbmRsZQ0KPiBpZCBpbiB0aGUgTUlDLCBidXQgaXQgaXMgcHJvYmFibHkg bm90IG5lY2Vzc2FyeS4NCj4gDQo+IA0KPiBba2l0dGVuIGZvbGtzIGNhbiBwcm9iYWJseSBzdG9w IHJlYWRpbmcgaGVyZV0NCj4gDQo+IA0KPj4gV2UgbmVlZCB0byBnb3RvIFdHTEMsIHNvIEknbSBw dXR0aW5nIG91dCBvbmUgbW9yZSBkcmFmdC4gSSBoYXZlIHNvbWUNCj4+IG1pc2NlbGxhbmVvdXMg Zml4ZXMgLSBpbmNsdWRpbmcgeW91ciBmbGF0dGVuaW5nIG9mIHJpZ3NfYXNzZXJ0aW9uLg0KPiAN Cj4gQW5vdGhlciBtaXNjZWxsYW5lb3VzIGZpeDoNCj4gDQo+IFNlY3Rpb24gMiByZWFkcyByYXRo ZXIgc3RyYW5nZWx5LCB3aXRoIHRoZSBmaXJzdCBidWxsZXQgcG9pbnQganVzdA0KPiBhc3N1bWlu ZyB0aGF0IHRoZXJlIGlzIGFuIGV4aXN0aW5nIFJQQ1NFQ19HU1N2MyBjb250ZXh0IGhhbmRsZSBh bmQgc2F5aW5nDQo+IG5vdGhpbmcgYWJvdXQgaG93IGl0IGlzIGNyZWF0ZWQuDQoNCkkgZGlkbuKA mXQgc2VlIHRoZSBuZWVkIHRvIG1lbnRpb24gdGhhdCwgYXMgUlBDU0VDX0dTU3YzIGlzIGEgc3Vw ZXIgc2V0IG9mIFJQQ1NFQ19HU1N2MiB3aGljaCBpcyBhIHN1cGVyIHNldCBvZiBSUENTRUNfR1NT djEgd2hpY2ggZnVsbHkgZGVzY3JpYmVzIGhvdyB0byBjcmVhdGUgYW4gUlBDU0VDX0dTUyBoYW5k bGUgbm8gbWF0dGVyIHdoYXQgdmVyc2lvbiBpdCBpcy4NCg0KDQo+ICBUaGF0IHRleHQgY291bGQg cHJvYmFibHkgYmUgcmV3b3JrZWQgdG8NCj4gYmUgbW9yZSBjbGVhciBhbmQgYWNjdXJhdGUsIHRo b3VnaHQgSSBkb24ndCBoYXZlIGFueSBjb25jcmV0ZSBzdWdnZXN0aW9ucw0KPiBvZmZoYW5kLg0K DQogSSBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGUgUlBDU0VDX0dTU3YxIHNlY3Rpb24gb24gY29u dGV4dCBjcmVhdGlvbi4NCg0KPiANCj4gU2VjdGlvbiAyLjMgYWxzbyByZWFkcyBhIGJpdCBvZGRs eSwgd2l0aCB0aGUgZmlyc3QgcGFyYWdyYXBoIGRlc2NyaWJpbmcgYQ0KPiBzaXR1YXRpb24gdGhh dCB3b3VsZCBoYXZlIG9jY3VycmVkIGlmIHRoZSBNSVRNIHByb2JsZW0gd2FzIG5vdCBhZGRyZXNz ZWQsDQo+IGFuZCB0aGUgc2Vjb25kIHBhcmFncmFwaCBkZXNjcmliaW5nIHRoZSBmaXguICBIYXZp bmcgdGhlIGZpcnN0IHBhcmFncmFwaA0KPiByZWFkIGFzIGlmIHRoZSBNSVRNIHZ1bG5lcmFiaWxp dHkgaXMgc3RpbGwgcHJlc2VudCBpbiB0aGUgcHJvdG9jb2wNCj4gc3BlY2lmaWVkIGJ5IHRoaXMg ZG9jdW1lbnQgaXMgcmF0aGVyIHN0cmFuZ2UuDQoNCkkgYWRkZWQgYSBzZW50ZW5jZSB0byB0aGUg Zmlyc3QgcGFyYWdyYXBoIG5vdGluZyB0aGF0IHRoaXMgaXMgdGhlIG1vdGl2YXRpb24gZm9yIHRo ZSBuZXcgcmVwbHkgdmVyaWZpZXIgYW5kIHJld29yZGVkIHRoZSBwYXJhZ3JhcGguDQoNCj4gDQo+ IA0KPiBTZWN0aW9uIDIuNSBzYXlzIHRoYXQgUlBDU0VDX0dTU19CSU5EX0NIQU5ORUwgTVVTVCBO T1QgYmUgdXNlZCBvbiBhIHYzDQo+IGhhbmRsZSwgYnV0IHNlY3Rpb24gMi43IHN0aWxsIGxpc3Rz IHJwY19nc3Nfc3ZjX2NoYW5uZWxfcHJvdCBhcyBhbg0KPiBhY2NlcHRhYmxlIHNlY3VyaXR5IHNl cnZpY2UgZm9yIHByb3RlY3RpbmcgdGhlIF9DUkVBVEUgYW5kIF9MSVNUIGNvbnRyb2wNCj4gbWVz c2FnZXMgLS0gcnBjX2dzc19zdmNfY2hhbm5lbF9wcm90IGNhbm5vdCBiZSB1c2VkIG9uIGEgbm9u LWNoaWxkIHYzDQo+IGhhbmRsZSB1bmxlc3MgUlBDU0VDX0dTU19CSU5EX0NIQU5ORUwgaGFzIGJl ZW4gcGVyZm9ybWVkLiAgDQoNCkxpc3RpbmcgcnBjX2dzc19zdmNfY2hhbm5lbF9wcm90IGFzIGEg c2VjdXJpdHkgc2VydmljZSBmb3IgX0NSRUFURSBpcyB3cm9uZy4gIFNvcnJ5IEkgZGlkIG5vdCBh ZGRyZXNzIHRoaXMgLSBhcyBJIGxvb2sgb3ZlciBwYXN0IGVtYWlsLCB5b3UgbWVudGlvbmVkIGl0 IGxhc3QgcmV2aWV3Lg0KDQpJIHJlbW92ZWQgcnBjX2dzc19zdmNfY2hhbm5lbF9wcm90IGZyb20g dGhlIGxpc3QsIGFuZCBhZGRlZCBhIHNlcGFyYXRlIHBhcmFncmFwaCBhbGxvd2luZyBpdOKAmXMg dXNlIGluIFJQQ1NFQ19HU1NfTElTVC4NCg0KSnVzdCBhIG5vdGU6IGluIFJQQ1NFQ19HU1N2MyBj aGFubmVsIGJpbmRpbmdzIGNhbiBvbmx5IGV4aXN0IG9uIGNoaWxkIHYzIGhhbmRsZXMgcmV0dXJu ZWQgb24gYSBzdWNlc3NmdWwgUlBDU0VDX0dTU19DUkVBVEUgd2l0aCBhIGNoYW5uZWwgYmluZGlu ZyBwYXlsb2FkLiBBIG5vbi1jaGlsZCB2MyBoYW5kbGUgY2FuIG5vdCBoYXZlIGNoYW5uZWwgYmlu ZGluZ3MuIFJQQ1NFQ19HU1NfQklORF9DSEFOTkVMIGlzIG5vdCBhbGxvd2VkIGluIFJQQ1NFQ19H U1N2MywgaXQgaXMgcmVwbGFjZWQgYnkgUlBDU0VDX0dTU19DUkVBVEUgY2hhbm5lbCBiaW5kaW5n IGFzc2VydGlvbi4NCg0KPiANCj4gUGVyaGFwcyBhIGZ1bGwNCj4gcmV2aWV3IG9mIHRoZSBkb2N1 bWVudCBzaG91bGQgYmUgbWFkZSB0byBlbnN1cmUgdGhhdCBhbGwgb2YgdGhlIGNvdmVyYWdlDQo+ IG9mIHRoZSB2MiBjaGFubmVsIGJpbmRpbmcgcHJvY2VkdXJlIGlzIHNlbGYtY29uc2lzdGVudC4g IA0KDQpJ4oCZbGwgZ28gb3ZlciBpdCBvbmNlIGFnYWluLg0KDQo+IEkgZ3Vlc3MNCj4gcnBjX2dz c19zdmNfY2hhbm5lbF9wcm90IGNvdWxkIG1ha2Ugc2Vuc2UgZm9yIF9MSVNULCBidXQgSSBkb24n dCB0aGluayBpdA0KPiB3b3JrcyBmb3IgX0NSRUFURSwgc28gcGVyaGFwcyB0aGF0IHNob3VsZCBi ZSBub3RlZCBpbiB0aGUgYnVsbGV0IGl0ZW0gaW4NCj4gc2VjdGlvbiAyLjcuDQo+IA0KPiBUaGVy ZSBpcyBwcm9iYWJseSBzb21ldGhpbmcgdG8gYmUgc2FpZCBhYm91dCB0aGUgb3JkZXJpbmcgb2Yg ZW50cmllcyBpbg0KPiByY3JfYXNzZXJ0aW9ucyAod2l0aCByZXNwZWN0IHRvIHJjYV9hc3NlcnRp b25zJyBvcmRlcikuICBJZiBJJ20gcmVhZGluZw0KPiBjb3JyZWN0bHkgKEkgc2tpbW1lZCB0aGF0 IHBhcnQgYSBiaXQpIHRoZSBzZXJ2ZXIgcmV0dXJucyBpbiByY3JfYXNzZXJ0aW9ucw0KPiBleGFj dGx5IHRoZSBzdWJzZXQgb2YgcmNhX2Fzc2VydGlvbnMgd2hpY2ggd2FzIGFjY2VwdGVkIGJ5IHRo ZSBzZXJ2ZXIncw0KPiBwcm9jZXNzaW5nLiAgVGhlIGNsaWVudCBtYXkgd2FudCB0byB2ZXJpZnkg d2hpY2ggb2YgaXRzIGFzc2VydGlvbnMgd2VyZQ0KPiBhY2NlcHRlZCwgYW5kIHJlcXVpcmluZyB0 aGUgc2VydmVyIHRvIHJldHVybiB0aGluZ3MgaW4gdGhlIHNhbWUgb3JkZXINCj4gd291bGQgZmFj aWxpdGF0ZSBpbXBsZW1lbnRhdGlvbiBlZmZpY2llbmN5IGluIHRoZSBjbGllbnQuDQoNClRoYXQg bWFrZXMgc2Vuc2UuIEkgYWRkZWQgc29tZSB0ZXh0IHRvIHNlY3Rpb24gMi43LjEuDQoNCj4gDQo+ IEdyYW1tYXIgbml0czoNCj4gDQo+IEluIHRoZSBwZW51bHRpbWF0ZSBwYXJhZ3JhcGggb2Ygc2Vj dGlvbiAyLjcuMS4xLCBzL3RoZSBzZXJ2ZXIgc2VuZC90aGUNCj4gc2VydmVyIHNlbmRzLw0KPiAN Cg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJ4oCZdmUgYXR0YWNoZWQgYW4gdXBkYXRlZCBkcmFm dC0xMA0KDQrigJQ+QW5keQ0KDQo= --_003_AC5C7128DB5A4CDEBD745B51B5A7E4CFnetappcom_ Content-Type: text/plain; name="draft-ietf-nfsv4-rpcsec-gssv3-10.txt" Content-Description: draft-ietf-nfsv4-rpcsec-gssv3-10.txt Content-Disposition: attachment; filename="draft-ietf-nfsv4-rpcsec-gssv3-10.txt"; size=43697; creation-date="Fri, 05 Dec 2014 22:12:28 GMT"; modification-date="Fri, 05 Dec 2014 22:12:28 GMT" Content-ID: Content-Transfer-Encoding: base64 DQoNCg0KDQpORlN2NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFcuIEFkYW1zb24NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldEFwcA0KSW50ZW5kZWQgc3RhdHVz OiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uIFdpbGxpYW1z DQpFeHBpcmVzOiBKdW5lIDYsIDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBDcnlwdG9uZWN0b3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBEZWNlbWJlciAwMywgMjAxNA0KDQoNCiAgICAgICAgICAgICBSZW1v dGUgUHJvY2VkdXJlIENhbGwgKFJQQykgU2VjdXJpdHkgVmVyc2lvbiAzDQogICAgICAgICAgICAg ICAgICAgIGRyYWZ0LWlldGYtbmZzdjQtcnBjc2VjLWdzc3YzLTEwDQoNCkFic3RyYWN0DQoNCiAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHZlcnNpb24gMyBvZiB0aGUgUmVtb3RlIFByb2NlZHVy ZSBDYWxsIChSUEMpDQogICBzZWN1cml0eSBwcm90b2NvbCAoUlBDU0VDX0dTUykuICBUaGlzIHBy b3RvY29sIHByb3ZpZGVzIGZvciBtdWx0aS0NCiAgIHByaW5jaXBhbCBhdXRoZW50aWNhdGlvbiBv ZiBjbGllbnQgaG9zdHMgYW5kIHVzZXIgcHJpbmNpcGFscyB0bw0KICAgc2VydmVyIChjb25zdHJ1 Y3RlZCBieSBnZW5lcmljIGNvbXBvc2l0aW9uKSwgc2VjdXJpdHkgbGFiZWwNCiAgIGFzc2VydGlv bnMgZm9yIG11bHRpLWxldmVsIGFuZCB0eXBlIGVuZm9yY2VtZW50LCBzdHJ1Y3R1cmVkIHByaXZp bGVnZQ0KICAgYXNzZXJ0aW9ucywgYW5kIGNoYW5uZWwgYmluZGluZ3MuDQoNClJlcXVpcmVtZW50 cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQg YXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbMV0uDQoNClN0 YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQg aW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0 aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0 IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBh cyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoN CiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGlt dW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSnVuZSA2LCAyMDE1Lg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxNCBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCg0KDQoNCg0KQWRhbXNvbiAmIFdpbGxpYW1zICAgICAgICBFeHBpcmVzIEp1 bmUgNiwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgICAgTkZTdjQgICAgICAgICAgICAgICAgICAgIERlY2VtYmVyIDIwMTQN Cg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBU cnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQog ICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhl IGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3 IHRoZXNlIGRvY3VtZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmln aHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQogICB0byB0aGlzIGRvY3VtZW50LiAg Q29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KICAgaW5j bHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC5lIG9mDQogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdp dGhvdXQgd2FycmFudHkgYXMNCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZS4NCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiBhbmQgTW90 aXZhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyDQogICAyLiAgVGhl IFJQQ1NFQ19HU1N2MyBQcm90b2NvbCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDQNCiAgICAgMi4xLiAgQ29tcGF0aWJpbGl0eSB3aXRoIFJQQ1NFQ19HU1N2MiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICAyLjIuICBWZXJzaW9uIE5lZ290aWF0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1DQogICAgIDIuMy4gIE5ldyBS RVBMWSBWZXJpZmllciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUN CiAgICAgMi40LiAgTmV3IFZlcnNpb24gTnVtYmVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNg0KICAgICAyLjUuICBSUENTRUNfR1NTX0JJTkRfQ0hBTk5FTCBPcGVy YXRpb24gRGVwcmVjYXRlZCAgLiAuIC4gLiAuIC4gICA4DQogICAgIDIuNi4gIE5ldyBhdXRoX3N0 YXQgVmFsdWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAgICAg Mi43LiAgTmV3IENvbnRyb2wgUHJvY2VkdXJlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOA0KICAgICAgIDIuNy4xLiAgTmV3IENvbnRyb2wgUHJvY2VkdXJlIC0gUlBDU0VD X0dTU19DUkVBVEUgLiAuIC4gLiAuIC4gICA5DQogICAgICAgMi43LjIuICBOZXcgQ29udHJvbCBQ cm9jZWR1cmUgLSBSUENTRUNfR1NTX0xJU1QgLiAuIC4gLiAuIC4gLiAgMTYNCiAgICAgMi44LiAg RXh0ZW5zaWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNw0KICAgMy4gIE9wZXJhdGlvbmFsIFJlY29tbWVuZGF0aW9uIGZvciBEZXBsb3ltZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE4DQogICA0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgIDUuICBJQU5BIENvbnNp ZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQ0K ICAgNi4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE5DQogICAgIDYuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTkNCiAgICAgNi4yLiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQ0KICAgQXBw ZW5kaXggQS4gIEFja25vd2xlZGdtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDIwDQogICBBcHBlbmRpeCBCLiAgUkZDIEVkaXRvciBOb3RlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjANCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMA0KDQoxLiAgSW50cm9k dWN0aW9uIGFuZCBNb3RpdmF0aW9uDQoNCiAgIFRoZSBvcmlnaW5hbCBSUENTRUNfR1NTIHByb3Rv Y29sIFsyXSBwcm92aWRlZCBmb3IgYXV0aGVudGljYXRpb24gb2YNCiAgIFJQQyBjbGllbnRzIGFu ZCBzZXJ2ZXJzIHRvIGVhY2ggb3RoZXIgdXNpbmcgdGhlIEdlbmVyaWMgU2VjdXJpdHkNCiAgIFNl cnZpY2VzIEFwcGxpY2F0aW9uIFByb2dyYW1taW5nIEludGVyZmFjZSAoR1NTLUFQSSkgWzNdLiAg VGhlIHNlY29uZA0KICAgdmVyc2lvbiBvZiBSUENTRUNfR1NTIFs4XSAgYWRkZWQgc3VwcG9ydCBm b3IgY2hhbm5lbCBiaW5kaW5ncyBbNl0uDQoNCiAgIFdlIGZpbmQgdGhhdCBHU1MtQVBJIG1lY2hh bmlzbXMgYXJlIGluc3VmZmljaWVudCBmb3IgY29tbXVuaWNhdGluZw0KICAgY2VydGFpbiBhc3Bl Y3RzIG9mIGF1dGhvcml0eSB0byBhIHNlcnZlci4gIFRoZSBHU1MtQVBJIGFuZCBpdHMNCiAgIG1l Y2hhbmlzbXMgY2VydGFpbmx5IGNvdWxkIGJlIGV4dGVuZGVkIHRvIGFkZHJlc3MgdGhpcyBzaG9y dGNvbWluZywNCiAgIGJ1dCBpdCBzZWVtcyBiZSBmYXIgc2ltcGxlciB0byBhZGRyZXNzIGl0IGF0 IHRoZSBhcHBsaWNhdGlvbiBsYXllciwNCiAgIG5hbWVseSwgaW4gdGhpcyBjYXNlLCBSUENTRUNf R1NTLg0KDQoNCg0KDQoNCkFkYW1zb24gJiBXaWxsaWFtcyAgICAgICAgRXhwaXJlcyBKdW5lIDYs IDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgIE5GU3Y0ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0K ICAgQSBtYWpvciBtb3RpdmF0aW9uIGZvciBSUENTRUNfR1NTdjMgaXMgdG8gYWRkIHN1cHBvcnQg Zm9yIGxhYmVsZWQNCiAgIHNlY3VyaXR5IGFuZCBzZXJ2ZXItc2lkZSBjb3B5IGZvciBORlN2NC4N Cg0KICAgTGFiZWxlZCBORlMgKHNlZSBTZWN0aW9uIDggb2YgWzRdKSB1c2VzIHRoZSBzdWJqZWN0 IGxhYmVsIHByb3ZpZGVkIGJ5DQogICB0aGUgY2xpZW50IHZpYSB0aGUgUlBDU0VDX0dTU3YzIGxh eWVyIHRvIGVuZm9yY2UgTUFDIGFjY2VzcyB0bw0KICAgb2JqZWN0cyBvd25lZCBieSB0aGUgc2Vy dmVyIHRvIGVuYWJsZSBzZXJ2ZXIgZ3Vlc3QgbW9kZS4NCiAgIFJQQ1NFQ19HU1N2MyBsYWJlbCBh c3NlcnRpb25zIHByb3ZpZGUgdGhlIG1lYW5zIHRvIGFjaGlldmUgZnVsbCBtb2RlDQogICBsYWJl bGVkIE5GUy4NCg0KICAgQSB0cmFkaXRpb25hbCBpbnRlci1zZXJ2ZXIgZmlsZSBjb3B5IGVudGFp bHMgdGhlIHVzZXIgZ2FpbmluZyBhY2Nlc3MNCiAgIHRvIGEgZmlsZSBvbiB0aGUgc291cmNlLCBy ZWFkaW5nIGl0LCBhbmQgd3JpdGluZyBpdCB0byBhIGZpbGUgb24gdGhlDQogICBkZXN0aW5hdGlv bi4gIEluIHNlY3VyZSBORlN2NCBpbnRlci1zZXJ2ZXIgc2VydmVyLXNpZGUgY29weSAoc2VlDQog ICBTZWN0aW9uIDMuNC4xIG9mIFs0XSksIHRoZSB1c2VyIGZpcnN0IHNlY3VyZXMgYWNjZXNzIHRv IGJvdGggc291cmNlDQogICBhbmQgZGVzdGluYXRpb24gZmlsZXMsIGFuZCB0aGVuIHVzZXMgTkZT djQuMiBkZWZpbmVkIFJQQ1NFQ19HU1N2Mw0KICAgc3RydWN0dXJlZCBwcml2aWxlZ2VzIHRvIGF1 dGhvcml6ZSB0aGUgZGVzdGluYXRpb24gdG8gY29weSB0aGUgZmlsZQ0KICAgZnJvbSB0aGUgc291 cmNlIG9uIGJlaGFsZiBvZiB0aGUgdXNlci4NCg0KICAgTXVsdGktcHJpbmNpcGFsIGFzc2VydGlv bnMgY2FuIGJlIHVzZWQgdG8gYWRkcmVzcyBzaGFyZWQgY2FjaGUNCiAgIHBvaXNvbmluZyBhdHRh Y2tzIG9uIHRoZSBjbGllbnQgY2FjaGUgYnkgYSB1c2VyLiAgQXMgZGVzY3JpYmVkIGluDQogICBT ZWN0aW9uIDcgb2YgWzE0XSwgbXVsdGktdXNlciBtYWNoaW5lcyB3aXRoIGEgc2luZ2xlIGNhY2hl IG1hbmFnZXINCiAgIGNhbiBmZXRjaCBhbmQgY2FjaGUgZGF0YSBvbiBhIHVzZXJzJyBiZWhhbGYs IGFuZCByZS1kaXNwbGF5IGl0IGZvcg0KICAgYW5vdGhlciB1c2VyIGZyb20gdGhlIGNhY2hlIHdp dGhvdXQgcmUtZmV0Y2hpbmcgdGhlIGRhdGEgZnJvbSB0aGUNCiAgIHNlcnZlci4gIFRoZSBpbml0 aWFsIGRhdGEgYWNxdWlzaXRpb24gaXMgYXV0aGVudGljYXRlZCBieSB0aGUgZmlyc3QNCiAgIHVz ZXIncyBjcmVkZW50aWFscywgYW5kIGlmIG9ubHkgdGhhdCB1c2VyJ3MgY3JlZGVudGlhbHMgYXJl IHVzZWQsIGl0DQogICBtYXkgYmUgcG9zc2libGUgZm9yIGEgbWFsaWNpb3VzIHVzZXIgb3IgdXNl cnMgdG8gInBvaXNvbiIgdGhlIGNhY2hlDQogICBmb3Igb3RoZXIgdXNlcnMgYnkgaW50cm9kdWNp bmcgYm9ndXMgZGF0YSBpbnRvIHRoZSBjYWNoZS4NCg0KICAgQW5vdGhlciB1c2Ugb2YgdGhlIG11 bHRpLXByaW5jaXBhbCBhc3NlcnRpb24gaXMgdGhlIHNlY3VyZSBjb252ZXlhbmNlDQogICBvZiBw cml2aWxlZ2UgaW5mb3JtYXRpb24gZm9yIHByb2Nlc3NlcyBydW5uaW5nIHdpdGggbW9yZSAob3Ig ZXZlbg0KICAgd2l0aCBsZXNzKSBwcml2aWxlZ2UgdGhhbiB0aGUgdXNlciBub3JtYWxseSB3b3Vs ZCBiZSBhY2NvcmRlZC4NCg0KICAgV2UgdGhlcmVmb3JlIGRlc2NyaWJlIFJQQ1NFQ19HU1MgdmVy c2lvbiAzIChSUENTRUNfR1NTdjMpLg0KICAgUlBDU0VDX0dTU3YzIGlzIHRoZSBzYW1lIGFzIFJQ Q1NFQ19HU1N2MiBbOF0sIGV4Y2VwdCB0aGF0IHRoZQ0KICAgZm9sbG93aW5nIGFzc2VydGlvbnMg b2YgYXV0aG9yaXR5IGhhdmUgYmVlbiBhZGRlZC4NCg0KICAgbyAgU2VjdXJpdHkgbGFiZWxzIGZv ciBtdWx0aS1sZXZlbCwgdHlwZSBlbmZvcmNlbWVudCwgYW5kIG90aGVyDQogICAgICBsYWJlbGVk IHNlY3VyaXR5IG1vZGVscy4gIFNlZSBbMTBdLCBbMTFdLCBbMTJdLCBbNF0gYW5kIFs5XS4NCg0K ICAgbyAgQXBwbGljYXRpb24tc3BlY2lmaWMgc3RydWN0dXJlZCBwcml2aWxlZ2VzLiAgRm9yIGFu IGV4YW1wbGUgc2VlDQogICAgICBzZXJ2ZXItc2lkZSBjb3B5IFs0XS4NCg0KICAgbyAgTXVsdGkt cHJpbmNpcGFsIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQgaG9zdCBhbmQgdXNlciB0byB0 aGUNCiAgICAgIHNlcnZlciBkb25lIGJ5IGJpbmRpbmcgdHdvIFJQQ1NFQ19HU1MgaGFuZGxlcy4N Cg0KICAgbyAgU2ltcGxpZmllZCBjaGFubmVsIGJpbmRpbmcuDQoNCg0KDQoNCg0KDQpBZGFtc29u ICYgV2lsbGlhbXMgICAgICAgIEV4cGlyZXMgSnVuZSA2LCAyMDE1ICAgICAgICAgICAgICAgICAg W1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBORlN2NCAgICAg ICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIEFzc2VydGlvbnMgb2YgbGFiZWxz IGFuZCBwcml2aWxlZ2VzIGFyZSBldmFsdWF0ZWQgYnkgdGhlIHNlcnZlciwNCiAgIHdoaWNoIG1h eSB0aGVuIG1hcCB0aGUgYXNzZXJ0ZWQgdmFsdWVzIHRvIG90aGVyIHZhbHVlcywgYWxsIGFjY29y ZGluZw0KICAgdG8gc2VydmVyLXNpZGUgcG9saWN5Lg0KDQogICBXZSBhZGQgYW4gb3B0aW9uIGZv ciBlbnVtZXJhdGluZyBzZXJ2ZXIgc3VwcG9ydGVkIGxhYmVsIGZvcm1hdA0KICAgc3BlY2lmaWVy cyAoTEZTKS4gIFRoZSBMRlMgYW5kIExhYmVsIEZvcm1hdCBSZWdpc3RyeSBhcmUgZGVzY3JpYmVk IGluDQogICBkZXRhaWwgaW4gWzEzXS4NCg0KICAgVGhpcyBkb2N1bWVudCBjb250YWlucyB0aGUg RXh0ZXJuYWwgRGF0YSBSZXByZXNlbnRhdGlvbiAoWERSKSAoWzddKQ0KICAgZGVmaW5pdGlvbnMg Zm9yIHRoZSBSUENTRUNfR1NTdjMgcHJvdG9jb2wuICBUaGUgWERSIGRlc2NyaXB0aW9uIGlzDQog ICBwcm92aWRlZCBpbiB0aGlzIGRvY3VtZW50IGluIGEgd2F5IHRoYXQgbWFrZXMgaXQgc2ltcGxl IGZvciB0aGUNCiAgIHJlYWRlciB0byBleHRyYWN0IGludG8gcmVhZHkgdG8gY29tcGlsZSBmb3Jt LiAgVGhlIHJlYWRlciBjYW4gZmVlZA0KICAgdGhpcyBkb2N1bWVudCBpbiB0aGUgZm9sbG93aW5n IHNoZWxsIHNjcmlwdCB0byBwcm9kdWNlIHRoZSBtYWNoaW5lDQogICByZWFkYWJsZSBYRFIgZGVz Y3JpcHRpb24gb2YgUlBDU0VDX0dTU3YzOg0KDQogICA8Q09ERSBCRUdJTlM+DQoNCiAgICMhL2Jp bi9zaA0KICAgZ3JlcCAiXiAgKi8vLyIgfCBzZWQgJ3M/XiAgKi8vLyA/PycgfCBzZWQgJ3M/XiAg Ki8vLyQ/PycNCg0KICAgPENPREUgRU5EUz4NCg0KICAgSS5lLiBpZiB0aGUgYWJvdmUgc2NyaXB0 IGlzIHN0b3JlZCBpbiBhIGZpbGUgY2FsbGVkICJleHRyYWN0LnNoIiwgYW5kDQogICB0aGlzIGRv Y3VtZW50IGlzIGluIGEgZmlsZSBjYWxsZWQgInNwZWMudHh0IiwgdGhlbiB0aGUgcmVhZGVyIGNh biBkbzoNCg0KICAgPENPREUgQkVHSU5TPg0KDQogICAgc2ggZXh0cmFjdC5zaCA8IHNwZWMudHh0 ID4gcnBjc2VjX2dzc192My54DQoNCiAgIDxDT0RFIEVORFM+DQoNCiAgIFRoZSBlZmZlY3Qgb2Yg dGhlIHNjcmlwdCBpcyB0byByZW1vdmUgbGVhZGluZyB3aGl0ZSBzcGFjZSBmcm9tIGVhY2gNCiAg IGxpbmUsIHBsdXMgYSBzZW50aW5lbCBzZXF1ZW5jZSBvZiAiLy8vIi4NCg0KMi4gIFRoZSBSUENT RUNfR1NTdjMgUHJvdG9jb2wNCg0KICAgUlBDU0VDX0dTU3YzIGlzIHRoZSBzYW1lIGFzIFJQQ1NF Q19HU1N2MiBbOF0sIGV4Y2VwdCB0aGF0IHN1cHBvcnQgZm9yDQogICBhc3NlcnRpb25zIGhhcyBi ZWVuIGFkZGVkLiAgVGhlIGVudGlyZSBSUENTRUNfR1NTdjMgcHJvdG9jb2wgaXMgbm90DQogICBw cmVzZW50ZWQuICBJbnN0ZWFkIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIFJQQ1NFQ19HU1N2MyBh bmQNCiAgIFJQQ1NFQ19HU1N2MiBhcmUgc2hvd24uDQoNCiAgIFJQQ1NFQ19HU1N2MyBpcyBwYXR0 ZXJuZWQgYXMgZm9sbG93czoNCg0KICAgbyAgQSBjbGllbnQgdXNlcyBhbiBleGlzdGluZyBSUENT RUNfR1NTdjMgY29udGV4dCBoYW5kbGUgZXN0YWJsaXNoZWQNCiAgICAgIGluIHRoZSB1c3VhbCBt YW5uZXIgKFNlZSBTZWN0aW9uIDUuMiBbMl0pIHRvIHByb3RlY3QgUlBDU0VDX0dTU3YzDQogICAg ICBleGNoYW5nZXMsIHRoaXMgd2lsbCBiZSB0ZXJtZWQgdGhlICJwYXJlbnQiIGhhbmRsZS4NCg0K DQoNCg0KDQpBZGFtc29uICYgV2lsbGlhbXMgICAgICAgIEV4cGlyZXMgSnVuZSA2LCAyMDE1ICAg ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICBORlN2NCAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIG8gIFRo ZSBzZXJ2ZXIgaXNzdWVzIGEgImNoaWxkIiBSUENTRUNfR1NTdjMgaGFuZGxlIGluIHRoZQ0KICAg ICAgUlBDU0VDX0dTU19DUkVBVEUgcmVzcG9uc2Ugd2hpY2ggdXNlcyB0aGUgdW5kZXJseWluZyBH U1MtQVBJDQogICAgICBzZWN1cml0eSBjb250ZXh0IG9mIHRoZSBwYXJlbnQgaGFuZGxlIGluIGFs bCBzdWJzZXF1ZW50IGV4Y2hhbmdlcw0KICAgICAgdGhhdCB1c2VzIHRoZSBjaGlsZCBoYW5kbGUu DQoNCiAgIG8gIEFuIFJQQ1NFQ19HU1N2MyBjaGlsZCBoYW5kbGUgTVVTVCBOT1QgYmUgdXNlZCBh cyB0aGUgcGFyZW50IGhhbmRsZQ0KICAgICAgaW4gYW4gUlBDU0VDX0dTUzNfQ1JFQVRFIGNvbnRy b2wgbWVzc2FnZS4NCg0KMi4xLiAgQ29tcGF0aWJpbGl0eSB3aXRoIFJQQ1NFQ19HU1N2Mg0KDQog ICBUaGUgZnVuY3Rpb25hbGl0eSBvZiBSUENTRUNfR1NTdjIgWzhdIGlzIGZ1bGx5IHN1cHBvcnRl ZCBieQ0KICAgUlBDU0VDX0dTU3YzIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgUlBDU0VDX0dT U19CSU5EX0NIQU5ORUwNCiAgIG9wZXJhdGlvbiB3aGljaCBpcyBkZXByZWNhdGVkIChzZWUgU2Vj dGlvbiAyLjUpLg0KDQoyLjIuICBWZXJzaW9uIE5lZ290aWF0aW9uDQoNCiAgIEFuIGluaXRpYXRv ciB0aGF0IHN1cHBvcnRzIHZlcnNpb24gMyBvZiBSUENTRUNfR1NTIHNpbXBseSBpc3N1ZXMgYW4N CiAgIFJQQ1NFQ19HU1MgcmVxdWVzdCB3aXRoIHRoZSByZ2NfdmVyc2lvbiBmaWVsZCBzZXQgdG8N CiAgIFJQQ1NFQ19HU1NfVkVSU18zLiAgSWYgdGhlIHRhcmdldCBkb2VzIG5vdCByZWNvZ25pemUN CiAgIFJQQ1NFQ19HU1NfVkVSU18zLCB0aGUgdGFyZ2V0IHdpbGwgcmV0dXJuIGFuIFJQQyBlcnJv ciBwZXINCiAgIFNlY3Rpb24gNS4xIG9mIFsyXS4NCg0KICAgVGhlIGluaXRpYXRvciBNVVNUIE5P VCBhdHRlbXB0IHRvIHVzZSBhbiBSUENTRUNfR1NTIGhhbmRsZSByZXR1cm5lZA0KICAgYnkgdmVy c2lvbiAzIG9mIGEgdGFyZ2V0IHdpdGggdmVyc2lvbiAxIG9yIHZlcnNpb24gMiBvZiB0aGUgc2Ft ZQ0KICAgdGFyZ2V0LiAgVGhlIGluaXRpYXRvciBNVVNUIE5PVCBhdHRlbXB0IHRvIHVzZSBhbiBS UENTRUNfR1NTIGhhbmRsZQ0KICAgcmV0dXJuZWQgYnkgdmVyc2lvbiAxIG9yIHZlcnNpb24gMiBv ZiBhIHRhcmdldCB3aXRoIHZlcnNpb24gMyBvZiB0aGUNCiAgIHNhbWUgdGFyZ2V0Lg0KDQoyLjMu ICBOZXcgUkVQTFkgVmVyaWZpZXINCg0KICAgQSBuZXcgcmVwbHkgdmVyaWZpZXIgaXMgbmVlZGVk IGZvciBSUENTRUNfR1NTdjMgZHVlIHRvIHRoZSBmb2xsb3dpbmc6DQogICBUaGUgUlBDU0VDX0dT U3YzIGNoaWxkIGhhbmRsZSB1c2VzIHRoZSBzYW1lIEdTUyBjb250ZXh0IGFzIHRoZSBwYXJlbnQN CiAgIGhhbmRsZSwgc28gYSBjaGlsZCBhbmQgcGFyZW50IFJQQ1NFQ19HU1N2MyBoYW5kbGUgY291 bGQgaGF2ZSB0aGUgc2FtZQ0KICAgUlBDU0VDX0dTUyBzZXF1ZW5jZSBudW1iZXJzLiAgU2luY2Ug dGhlIHJlcGx5IHZlcmlmaWVyIG9mIHByZXZpb3VzDQogICB2ZXJzaW9ucyBvZiBSUENTRUNfR1NT IGNvbXB1dGVzIGEgTUlDIG9uIGp1c3QgdGhlIHNlcXVlbmNlIG51bWJlciwNCiAgIHRoaXMgcHJv dmlkZXMgb3Bwb3J0dW5pdGllcyBmb3IgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrcy4NCg0KICAg VGhpcyBpcyBlYXNpbHkgYWRkcmVzc2VkOiBSUENTRUNfR1NTIHZlcnNpb24gMyBjaGFuZ2VzIHRo ZSB2ZXJpZmllcg0KICAgb2YgdGhlIHJlcGx5IHRvIGNvbXB1dGUgdGhlIHZlcmlmaWVyIHVzaW5n IHRoZSBleGFjdCBzYW1lIGlucHV0IGFzDQogICB0aGF0IGlzIHVzZWQgZm9yIHZlcmlmaWVyIG9m IHRoZSByZXF1ZXN0LCBleGNlcHQgZm9yIHRoZSBtdHlwZSBjaGFuZ2UNCiAgIGZyb20gQ0FMTCB0 byBSRVBMWS4gIFRoZSBuZXcgcmVwbHkgdmVyaWZpZXIgY29tcHV0ZXMgYSBNSUMgb3ZlciB0aGUN CiAgIGZvbGxvd2luZyBSUEMgcmVwbHkgaGVhZGVyIGRhdGE6DQoNCg0KDQoNCg0KDQoNCg0KDQpB ZGFtc29uICYgV2lsbGlhbXMgICAgICAgIEV4cGlyZXMgSnVuZSA2LCAyMDE1ICAgICAgICAgICAg ICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBORlN2 NCAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgICAgdW5zaWduZWQgaW50 IHhpZDsNCiAgICAgbXNnX3R5cGUgbXR5cGU7ICAgIC8qIHNldCB0byBSRVBMWSAqLw0KICAgICB1 bnNpZ25lZCBpbnQgcnBjdmVyczsNCiAgICAgdW5zaWduZWQgaW50IHByb2c7DQogICAgIHVuc2ln bmVkIGludCB2ZXJzOw0KICAgICB1bnNpZ25lZCBpbnQgcHJvYzsNCiAgICAgb3BhcXVlX2F1dGgg IGNyZWQ7IC8qIGNhcHR1cmVzIHRoZSBSUENTRUNfR1NTIGhhbmRsZSAqLw0KDQoyLjQuICBOZXcg VmVyc2lvbiBOdW1iZXINCg0KICAgPENPREUgQkVHSU5TPg0KDQogICAgICAvLy8gIC8qDQogICAg ICAvLy8gICAqIENvcHlyaWdodCAoYykgMjAxMyBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucw0K ICAgICAgLy8vICAgKiBpZGVudGlmaWVkIGFzIHRoZSBkb2N1bWVudCBhdXRob3JzLiBBbGwgcmln aHRzDQogICAgICAvLy8gICAqIHJlc2VydmVkLg0KICAgICAgLy8vICAgKg0KICAgICAgLy8vICAg KiBUaGUgZG9jdW1lbnQgYXV0aG9ycyBhcmUgaWRlbnRpZmllZCBpbiBbUkZDMjIwM10sDQogICAg ICAvLy8gICAqIFtSRkM1NDAzXSwgYW5kIFtSRkN4eHh4XS4NCiAgICAgIC8vLyAgICoNCiAgICAg IC8vLyAgICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jt cywNCiAgICAgIC8vLyAgICogd2l0aCBvciB3aXRob3V0IG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZA0KICAgICAgLy8vICAgKiBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9u cyBhcmUgbWV0Og0KICAgICAgLy8vICAgKg0KICAgICAgLy8vICAgKiBvIFJlZGlzdHJpYnV0aW9u cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUNCiAgICAgIC8vLyAgICogICBj b3B5cmlnaHQgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlDQogICAgICAv Ly8gICAqICAgZm9sbG93aW5nIGRpc2NsYWltZXIuDQogICAgICAvLy8gICAqDQogICAgICAvLy8g ICAqIG8gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZQ0K ICAgICAgLy8vICAgKiAgIGFib3ZlIGNvcHlyaWdodCBub3RpY2UsIHRoaXMgbGlzdCBvZg0KICAg ICAgLy8vICAgKiAgIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbg0K ICAgICAgLy8vICAgKiAgIHRoZSBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMN CiAgICAgIC8vLyAgICogICBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uDQogICAgICAv Ly8gICAqDQogICAgICAvLy8gICAqIG8gTmVpdGhlciB0aGUgbmFtZSBvZiBJbnRlcm5ldCBTb2Np ZXR5LCBJRVRGIG9yIElFVEYNCiAgICAgIC8vLyAgICogICBUcnVzdCwgbm9yIHRoZSBuYW1lcyBv ZiBzcGVjaWZpYyBjb250cmlidXRvcnMsIG1heSBiZQ0KICAgICAgLy8vICAgKiAgIHVzZWQgdG8g ZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzDQogICAgICAvLy8g ICAqICAgc29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24u DQogICAgICAvLy8gICAqDQogICAgICAvLy8gICAqICAgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURF RCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUlMNCiAgICAgIC8vLyAgICogICBBTkQgQ09OVFJJQlVU T1JTICJBUyBJUyIgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQNCiAgICAgIC8vLyAgICogICBX QVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFDQogICAgICAvLy8g ICAqICAgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUw0K ICAgICAgLy8vICAgKiAgIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4g SU4gTk8NCiAgICAgIC8vLyAgICogICBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSIE9S IENPTlRSSUJVVE9SUyBCRQ0KICAgICAgLy8vICAgKiAgIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwg SU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsDQogICAgICAvLy8gICAqICAgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUDQogICAgICAvLy8gICAq ICAgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1INCg0K DQoNCkFkYW1zb24gJiBXaWxsaWFtcyAgICAgICAgRXhwaXJlcyBKdW5lIDYsIDIwMTUgICAgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAg IE5GU3Y0ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgICAgLy8vICAg KiAgIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MN CiAgICAgIC8vLyAgICogICBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkg VEhFT1JZIE9GDQogICAgICAvLy8gICAqICAgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNU LCBTVFJJQ1QgTElBQklMSVRZLA0KICAgICAgLy8vICAgKiAgIE9SIFRPUlQgKElOQ0xVRElORyBO RUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORw0KICAgICAgLy8vICAgKiAgIElOIEFOWSBX QVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRg0KICAgICAgLy8vICAg KiAgIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLg0KICAgICAgLy8v ICAgKi8NCiAgICAgIC8vLw0KICAgICAgLy8vICAvKg0KICAgICAgLy8vICAgKiBUaGlzIGNvZGUg d2FzIGRlcml2ZWQgZnJvbSBbUkZDMjIwM10uIFBsZWFzZQ0KICAgICAgLy8vICAgKiByZXByb2R1 Y2UgdGhpcyBub3RlIGlmIHBvc3NpYmxlLg0KICAgICAgLy8vICAgKi8NCiAgICAgIC8vLw0KICAg ICAgLy8vICBlbnVtIHJwY19nc3Nfc2VydmljZV90IHsNCiAgICAgIC8vLyAgICAgICAgICAvKiBO b3RlOiB0aGUgZW51bWVyYXRlZCB2YWx1ZSBmb3IgMCBpcyByZXNlcnZlZC4gKi8NCiAgICAgIC8v LyAgICAgICAgICBycGNfZ3NzX3N2Y19ub25lICAgICAgICAgPSAxLA0KICAgICAgLy8vICAgICAg ICAgIHJwY19nc3Nfc3ZjX2ludGVncml0eSAgICA9IDIsDQogICAgICAvLy8gICAgICAgICAgcnBj X2dzc19zdmNfcHJpdmFjeSAgICAgID0gMywNCiAgICAgIC8vLyAgICAgICAgICBycGNfZ3NzX3N2 Y19jaGFubmVsX3Byb3QgPSA0DQogICAgICAvLy8gIH07DQogICAgICAvLy8NCiAgICAgIC8vLyAg ZW51bSBycGNfZ3NzX3Byb2NfdCB7DQogICAgICAvLy8gICAgICAgICAgIFJQQ1NFQ19HU1NfREFU QSAgICAgICAgICA9IDAsDQogICAgICAvLy8gICAgICAgICAgIFJQQ1NFQ19HU1NfSU5JVCAgICAg ICAgICA9IDEsDQogICAgICAvLy8gICAgICAgICAgIFJQQ1NFQ19HU1NfQ09OVElOVUVfSU5JVCA9 IDIsDQogICAgICAvLy8gICAgICAgICAgIFJQQ1NFQ19HU1NfREVTVFJPWSAgICAgICA9IDMsDQog ICAgICAvLy8gICAgICAgICAgIFJQQ1NFQ19HU1NfQklORF9DSEFOTkVMICA9IDQsIC8qIG5vdCB1 c2VkICovDQogICAgICAvLy8gICAgICAgICAgIFJQQ1NFQ19HU1NfQ1JFQVRFICAgICAgICA9IDUs IC8qIG5ldyAqLw0KICAgICAgLy8vICAgICAgICAgICBSUENTRUNfR1NTX0xJU1QgICAgICAgICAg PSA2ICAvKiBuZXcgKi8NCiAgICAgIC8vLyAgfTsNCiAgICAgIC8vLw0KICAgICAgLy8vICBzdHJ1 Y3QgcnBjX2dzc19jcmVkX3ZlcnNfMV90IHsNCiAgICAgIC8vLyAgICAgICAgICBycGNfZ3NzX3By b2NfdCAgICBnc3NfcHJvYzsgLyogY29udHJvbCBwcm9jZWR1cmUgKi8NCiAgICAgIC8vLyAgICAg ICAgICB1bnNpZ25lZCBpbnQgICAgICBzZXFfbnVtOyAgLyogc2VxdWVuY2UgbnVtYmVyICovDQog ICAgICAvLy8gICAgICAgICAgcnBjX2dzc19zZXJ2aWNlX3Qgc2VydmljZTsgIC8qIHNlcnZpY2Ug dXNlZCAqLw0KICAgICAgLy8vICAgICAgICAgIG9wYXF1ZSAgICAgICAgICAgIGhhbmRsZTw+OyAv KiBjb250ZXh0IGhhbmRsZSAqLw0KICAgICAgLy8vICB9Ow0KICAgICAgLy8vDQogICAgICAvLy8g IGNvbnN0IFJQQ1NFQ19HU1NfVkVSU18xID0gMTsNCiAgICAgIC8vLyAgY29uc3QgUlBDU0VDX0dT U19WRVJTXzIgPSAyOw0KICAgICAgLy8vICBjb25zdCBSUENTRUNfR1NTX1ZFUlNfMyA9IDM7IC8q IG5ldyAqLw0KICAgICAgLy8vDQogICAgICAvLy8gIHVuaW9uIHJwY19nc3NfY3JlZF90IHN3aXRj aCAodW5zaWduZWQgaW50IHJnY192ZXJzaW9uKSB7DQogICAgICAvLy8gIGNhc2UgUlBDU0VDX0dT U19WRVJTXzE6DQogICAgICAvLy8gIGNhc2UgUlBDU0VDX0dTU19WRVJTXzI6DQogICAgICAvLy8g IGNhc2UgUlBDU0VDX0dTU19WRVJTXzM6IC8qIG5ldyAqLw0KICAgICAgLy8vICAgICAgICAgIHJw Y19nc3NfY3JlZF92ZXJzXzFfdCByZ2NfY3JlZF92MTsNCiAgICAgIC8vLyAgfTsNCg0KDQoNCkFk YW1zb24gJiBXaWxsaWFtcyAgICAgICAgRXhwaXJlcyBKdW5lIDYsIDIwMTUgICAgICAgICAgICAg ICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE5GU3Y0 ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgICAgLy8vDQoNCiAgIDxD T0RFIEVORFM+DQoNCiAgIEFzIHNlZW4gYWJvdmUsIHRoZSBSUENTRUNfR1NTdjMgY3JlZGVudGlh bCBoYXMgdGhlIHNhbWUgZm9ybWF0IGFzIHRoZQ0KICAgUlBDU0VDX0dTU3YxIFsyXSBhbmQgUlBD U0VDX0dTU3YyIFs4XSBjcmVkZW50aWFsLiAgU2V0dGluZyB0aGUNCiAgIHJnY192ZXJzaW9uIGZp ZWxkIHRvIDMgaW5kaWNhdGVzIHRoYXQgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0DQogICBzdXBw b3J0IHRoZSBuZXcgUlBDU0VDX0dTU3YzIGNvbnRyb2wgcHJvY2VkdXJlcy4NCg0KMi41LiAgUlBD U0VDX0dTU19CSU5EX0NIQU5ORUwgT3BlcmF0aW9uIERlcHJlY2F0ZWQNCg0KICAgUlBDU0VDX0dT U3YzIHByb3ZpZGVzIGEgY2hhbm5lbCBiaW5kaW5nIGFzc2VydGlvbiB0aGF0IHJlcGxhY2VzIHRo ZQ0KICAgUlBDU0VDX0dTU3YyIFJQQ1NFQ19HU1NfQklORF9DSEFOTkVMIG9wZXJhdGlvbi4NCiAg IFJQQ1NFQ19HU1NfQklORF9DSEFOTkVMIE1VU1QgTk9UIGJlIHVzZWQgb24gUlBDU0VDX0dTUyB2 ZXJzaW9uIDMNCiAgIGhhbmRsZXMuDQoNCjIuNi4gIE5ldyBhdXRoX3N0YXQgVmFsdWVzDQoNCiAg IFJQQ1NFQ19HU1N2MyByZXF1aXJlcyB0aGUgYWRkaXRpb24gb2Ygc2V2ZXJhbCB2YWx1ZXMgdG8g dGhlIGF1dGhfc3RhdA0KICAgZW51bWVyYXRlZCB0eXBlIGRlZmluaXRpb24uICBUaGUgdXNlIG9m IGVhY2ggb2YgdGhlc2UgbmV3IGF1dGhfc3RhdA0KICAgdmFsdWVzIGlzIGV4cGxhaW5lZCB0aHJv dWdob3V0IHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgICAgICAgZW51bSBhdXRoX3N0YXQgew0K ICAgICAgICAgICAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAgICAgICAgICAgIC8qDQogICAg ICAgICAgICAgICAgICAgICAgICogUlBDU0VDX0dTU3YzIGVycm9ycw0KICAgICAgICAgICAgICAg ICAgICAgICAqLw0KICAgICAgICAgICAgICAgICAgICAgIFJQQ1NFQ19HU1NfSU5ORVJfQ1JFRFBS T0JMRU0gPSAxNSwNCiAgICAgICAgICAgICAgICAgICAgICBSUENTRUNfR1NTX0xBQkVMX1BST0JM RU0gPSAxNiwNCiAgICAgICAgICAgICAgICAgICAgICBSUENTRUNfR1NTX1BSSVZJTEVHRV9QUk9C TEVNID0gMTcsDQogICAgICAgICAgICAgICAgICAgICAgUlBDU0VDX0dTU19VTktOT1dOX01FU1NB R0UgPSAxOA0KICAgICAgICAgICAgICB9Ow0KDQoyLjcuICBOZXcgQ29udHJvbCBQcm9jZWR1cmVz DQoNCiAgIFRoZXJlIGFyZSB0d28gbmV3IFJQQ1NFQ19HU1N2MyBjb250cm9sIHByb2NlZHVyZXM6 IFJQQ1NFQ19HU1NfQ1JFQVRFLA0KICAgUlBDU0VDX0dTU19MSVNULg0KDQogICBUaGUgUlBDU0VD X0dTU19DUkVBVEUgcHJvY2VkdXJlIGJpbmRzIGFueSBjb21iaW5hdGlvbiBvZiBhc3NlcnRpb25z Og0KICAgbXVsdGktcHJpbmNpcGFsIGF1dGhlbnRpY2F0aW9uLCBsYWJlbHMsIHN0cnVjdHVyZWQg cHJpdmlsZWdlcywgb3INCiAgIGNoYW5uZWwgYmluZGluZ3MgdG8gYSBuZXcgUlBDU0VDX0dTU3Yz IGNvbnRleHQgcmV0dXJuZWQgaW4gdGhlDQogICByZ3NzM19jcmVhdGVfcmVzIHJjcl9oYW5kbGUg ZmllbGQuDQoNCiAgIFRoZSBSUENTRUNfR1NTX0xJU1QgcHJvY2VkdXJlIHF1ZXJpZXMgdGhlIHRh cmdldCBmb3Igc3VwcG9ydGVkDQogICBhc3NlcnRpb25zLg0KDQogICBSUENTRUNfR1NTIHZlcnNp b24gMyBjb250cm9sIG1lc3NhZ2VzIGFyZSBzaW1pbGFyIHRvIHRoZSBSUENTRUNfR1NTDQogICB2 ZXJzaW9uIDEgYW5kIHZlcnNpb24gMiBSUENTRUNfR1NTX0RFU1RST1kgY29udHJvbCBtZXNzYWdl IChzZWUNCg0KDQoNCkFkYW1zb24gJiBXaWxsaWFtcyAgICAgICAgRXhwaXJlcyBKdW5lIDYsIDIw MTUgICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgIE5GU3Y0ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAg c2VjdGlvbiA1LjQgWzJdKSBpbiB0aGF0IHRoZSBzZXF1ZW5jZSBudW1iZXIgaW4gdGhlIHJlcXVl c3QgbXVzdCBiZQ0KICAgdmFsaWQsIGFuZCB0aGUgaGVhZGVyIGNoZWNrc3VtIGluIHRoZSB2ZXJp ZmllciBtdXN0IGJlIHZhbGlkLiAgQXMgaW4NCiAgIFJQQ1NFQ19HU1MgdmVyc2lvbiAxIGFuZCB2 ZXJzaW9uIDIsIHRoZSBSUENTRUNfR1NTdiB2ZXJzaW9uIDMgY29udHJvbA0KICAgbWVzc2FnZXMg bWF5IGNvbnRhaW4gY2FsbCBkYXRhIGZvbGxvd2luZyB0aGUgdmVyaWZpZXIgaW4gdGhlIGJvZHkg b2YNCiAgIHRoZSBOVUxMUFJPQyBwcm9jZWR1cmUuICBJbiBvdGhlciB3b3JkcywgdGhleSBsb29r IGEgbG90IGxpa2UgYW4NCiAgIFJQQ1NFQ19HU1MgZGF0YSBtZXNzYWdlIHdpdGggdGhlIGhlYWRl ciBwcm9jZWR1cmUgc2V0IHRvIE5VTExQUk9DLg0KDQogICBUaGUgY2xpZW50IE1VU1QgdXNlIG9u ZSBvZiB0aGUgZm9sbG93aW5nIHNlY3VyaXR5IHNlcnZpY2VzIHRvIHByb3RlY3QNCiAgIHRoZSBS UENTRUNfR1NTX0NSRUFURSBvciBSUENTRUNfR1NTX0xJU1QgY29udHJvbCBtZXNzYWdlOg0KDQog ICBvICBycGNfZ3NzX3N2Y19pbnRlZ3JpdHkNCg0KICAgbyAgcnBjX2dzc19zdmNfcHJpdmFjeQ0K DQogICBTcGVjaWZpY2FsbHkgdGhlIGNsaWVudCBNVVNUIE5PVCB1c2UgcnBjX2dzc19zdmNfbm9u ZS4NCg0KICAgUlBDU0VDX0dTU19MSVNUIGNhbiBhbHNvIHVzZSBycGNfZ3NzX3N2Y19jaGFubmVs X3Byb3QgKHNlZQ0KICAgUlBDU0VDX0dTU3YyIFs4XSkgaWYgdGhlIHJlcXVlc3QgaXMgc2VudCB1 c2luZyBhbiBSUENTRUNfR1NTdjMgY2hpbGQNCiAgIGhhbmRsZSB3aXRoIGNoYW5uZWwgYmluZGlu Z3MgZW5hYmxlZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjcuMS4yLg0KDQoyLjcuMS4gIE5l dyBDb250cm9sIFByb2NlZHVyZSAtIFJQQ1NFQ19HU1NfQ1JFQVRFDQoNCiAgIDxDT0RFIEJFR0lO Uz4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KQWRhbXNvbiAmIFdpbGxpYW1zICAgICAgICBFeHBpcmVzIEp1bmUgNiwgMjAxNSAgICAgICAg ICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg TkZTdjQgICAgICAgICAgICAgICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQogICAgICAvLy8gIHN0 cnVjdCByZ3NzM19jcmVhdGVfYXJncyB7DQogICAgICAvLy8gICAgICAgICAgcmdzczNfZ3NzX21w X2F1dGggICAgKnJjYV9tcF9hdXRoOw0KICAgICAgLy8vICAgICAgICAgIHJnc3MzX2NoYW5fYmlu ZGluZyAgICpyY2FfY2hhbl9iaW5kX21pYzsNCiAgICAgIC8vLyAgICAgICAgICByZ3NzM19hc3Nl cnRpb25fdSAgICAgcmNhX2Fzc2VydGlvbnM8PjsNCiAgICAgIC8vLyAgfTsNCiAgICAgIC8vLw0K ICAgICAgLy8vICBzdHJ1Y3QgcmdzczNfY3JlYXRlX3JlcyB7DQogICAgICAvLy8gICAgICAgICAg b3BhcXVlICAgICAgICAgICAgICAgcmNyX2hhbmRsZTw+Ow0KICAgICAgLy8vICAgICAgICAgIHJn c3MzX2dzc19tcF9hdXRoICAgICpyY3JfbXBfYXV0aDsNCiAgICAgIC8vLyAgICAgICAgICByZ3Nz M19jaGFuX2JpbmRpbmcgICAqcmNyX2NoYW5fYmluZF9taWM7DQogICAgICAvLy8gICAgICAgICAg cmdzczNfYXNzZXJ0aW9uX3UgICAgIHJjcl9hc3NlcnRpb25zPD47DQogICAgICAvLy8gIH07DQog ICAgICAvLy8NCiAgICAgIC8vLyAgZW51bSByZ3NzM19hc3NlcnRpb25fdHlwZSB7DQogICAgICAv Ly8gICAgICAgICAgTEFCRUwgPSAwLA0KICAgICAgLy8vICAgICAgICAgIFBSSVZTID0gMQ0KICAg ICAgLy8vICB9Ow0KICAgICAgLy8vDQogICAgICAvLy8gIHVuaW9uIHJnc3MzX2Fzc2VydGlvbl91 DQogICAgICAvLy8gICAgICAgIHN3aXRjaCAocmdzczNfYXNzZXJ0aW9uX3R5cGUgYXR5cGUpIHsN CiAgICAgIC8vLyAgY2FzZSBMQUJFTDoNCiAgICAgIC8vLyAgICAgICAgICByZ3NzM19sYWJlbCAg cmF1X2xhYmVsOw0KICAgICAgLy8vICBjYXNlIFBSSVZTOg0KICAgICAgLy8vICAgICAgICAgIHJn c3MzX3ByaXZzICByYXVfcHJpdnM7DQogICAgICAvLy8gIH07DQogICAgICAvLy8NCg0KICAgPENP REUgRU5EUz4NCg0KICAgVGhlIGNhbGwgZGF0YSBmb3IgYW4gUlBDU0VDX0dTU19DUkVBVEUgcmVx dWVzdCBjb25zaXN0cyBvZiBhbg0KICAgcmdzczNfY3JlYXRlX2FyZ3Mgd2hpY2ggYmluZHMgb25l IG9yIG1vcmUgaXRlbXMgb2Ygc2V2ZXJhbCBraW5kcyB0bw0KICAgdGhlIHJldHVybmVkIHJjcl9o YW5kbGUgUlBDU0VDX0dTU3YzIGNvbnRleHQgaGFuZGxlIGNhbGxlZCB0aGUNCiAgICJjaGlsZCIg aGFuZGxlOg0KDQogICBvICBNdWx0aS1wcmluY2lwYWwgYXV0aGVudGljYXRpb246IGFub3RoZXIg UlBDU0VDX0dTUyBjb250ZXh0IGhhbmRsZQ0KDQogICBvICBBIGNoYW5uZWwgYmluZGluZw0KDQog ICBvICBBdXRob3JpemF0aW9uIGFzc2VydGlvbnM6IGxhYmVscyBhbmQgb3IgcHJpdmlsZWdlcw0K DQogICBUaGUgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGNvbnNpc3RzIG9mIGVpdGhlciBhbiBlcnJv ciBvciBhbg0KICAgcmdzczNfY3JlYXRlX3JlcyBzdHJ1Y3R1cmUuICBBcyBub3RlZCBpbiBTZWN0 aW9uIDIuNy4xLjMgYW5kDQogICBTZWN0aW9uIDIuNy4xLjQgc3VjY2Vzc2Z1bCByZ3NzM19hc3Nl cnRpb25zIGFyZSBlbnVtZXJhdGVkIGluDQogICByY3JfYXNzZXJ0aW9ucywgYW5kIGFyZSBSRVFV SVJFRCBiZSBlbnVtZXJhdGVkIGluIHRoZSBzYW1lIG9yZGVyIGFzDQogICB0aGV5IGFwcGVhcmVk IGluIHRoZSByY2FfYXNzZXJ0aW9ucyBhcmd1bWVudC4NCg0KICAgVXBvbiBzdWNjZXNzZnVsIFJQ Q1NFQ19HU1NfQ1JFQVRFLCBib3RoIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXINCiAgIFNIT1VM RCBhc3NvY2lhdGUgdGhlIHJlc3VsdGFudCBjaGlsZCByY3JfaGFuZGxlIGNvbnRleHQgaGFuZGxl IHdpdGgNCg0KDQoNCkFkYW1zb24gJiBXaWxsaWFtcyAgICAgICAgRXhwaXJlcyBKdW5lIDYsIDIw MTUgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgIE5GU3Y0ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAg dGhlIHBhcmVudCBjb250ZXh0IGhhbmRsZSBpbiB0aGVpciBHU1MgY29udGV4dCBjYWNoZXMgc28g YXMgdG8gYmUNCiAgIGFibGUgdG8gcmVmZXJlbmNlIHRoZSBwYXJlbnQgY29udGV4dCBnaXZlbiB0 aGUgY2hpbGQgY29udGV4dCBoYW5kbGUuDQoNCiAgIFJQQ1NFQ19HU1N2MyBjaGlsZCBoYW5kbGVz IE1VU1QgYmUgZGVzdHJveWVkIHVwb24gdGhlIGRlc3RydWN0aW9uIG9mDQogICB0aGUgYXNzb2Np YXRlZCBwYXJlbnQgaGFuZGxlLg0KDQogICBTZXJ2ZXIgaW1wbGVtZW50YXRpb24gYW5kIHBvbGlj eSBNQVkgcmVzdWx0IGluIGxhYmVscywgcHJpdmlsZWdlcywNCiAgIGFuZCBpZGVudGl0aWVzIGJl aW5nIG1hcHBlZCB0byBjb25jZXB0cyBhbmQgdmFsdWVzIHRoYXQgYXJlIGxvY2FsIHRvDQogICB0 aGUgc2VydmVyLiAgU2VydmVyIHBvbGljaWVzIHNob3VsZCB0YWtlIGludG8gYWNjb3VudCB0aGUg aWRlbnRpdHkgb2YNCiAgIHRoZSBjbGllbnQgYW5kL29yIHVzZXIgYXMgYXV0aGVudGljYXRlZCB2 aWEgdGhlIEdTUy1BUEkuDQoNCjIuNy4xLjEuICBNdWx0aS1wcmluY2lwYWwgQXV0aGVudGljYXRp b24NCg0KICAgPENPREUgQkVHSU5TPg0KDQogICAgICAvLy8NCiAgICAgIC8vLyAgc3RydWN0IHJn c3MzX2dzc19tcF9hdXRoIHsNCiAgICAgIC8vLyAgICAgICAgICBvcGFxdWUgICAgICAgICAgcmdt cF9oYW5kbGU8PjsgLyogaW5uZXIgaGFuZGxlICovDQogICAgICAvLy8gICAgICAgICAgb3BhcXVl ICAgICAgICAgIHJnbXBfcnBjaGVhZGVyX21pYzw+Ow0KICAgICAgLy8vICB9Ow0KICAgICAgLy8v DQoNCiAgIDxDT0RFIEVORFM+DQoNCiAgIFJQQ1NFQ19HU1N2MyBjbGllbnRzIE1BWSBhc3NlcnQg YSBtdWx0aS1wcmluY2lwYWwgYXV0aGVudGljYXRpb24gb2YNCiAgIHRoZSBSUEMgY2xpZW50IGhv c3QgcHJpbmNpcGFsIGFuZCBhIHVzZXIgcHJpbmNpcGFsLiAgVGhpcyBmZWF0dXJlIGlzDQogICBu ZWVkZWQsIGZvciBleGFtcGxlLCB3aGVuIGFuIFJQQyBjbGllbnQgaG9zdCB3aXNoZXMgdG8gdXNl IGF1dGhvcml0eQ0KICAgYXNzZXJ0aW9ucyB0aGF0IHRoZSBzZXJ2ZXIgbWF5IG9ubHkgZ3JhbnQg aWYgYSB1c2VyIGFuZCBhbiBSUEMgY2xpZW50DQogICBob3N0IGFyZSBhdXRoZW50aWNhdGVkIHRv Z2V0aGVyIHRvIHRoZSBzZXJ2ZXIuICBUaHVzIGEgc2VydmVyIG1heQ0KICAgcmVmdXNlIHRvIGdy YW50IHJlcXVlc3RlZCBhdXRob3JpdHkgdG8gYSB1c2VyIGFjdGluZyBhbG9uZSAoZS5nLiwgdmlh DQogICBhbiB1bnByaXZpbGVnZWQgdXNlci1zcGFjZSBwcm9ncmFtKSwgb3IgdG8gYW4gUlBDIGNs aWVudCBob3N0IGFjdGluZw0KICAgYWxvbmUgKGUuZy4gd2hlbiBhbiBSUEMgY2xpZW50IGhvc3Qg aXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIHVzZXIpDQogICBidXQgbWF5IGdyYW50IHJlcXVlc3Rl ZCBhdXRob3JpdHkgdG8gYW4gUlBDIGNsaWVudCBob3N0IGFjdGluZyBvbg0KICAgYmVoYWxmIG9m IGEgdXNlciBpZiB0aGUgc2VydmVyIGlkZW50aWZpZXMgdGhlIHVzZXIgYW5kIHRydXN0cyB0aGUg UlBDDQogICBjbGllbnQgaG9zdC4NCg0KICAgSXQgaXMgYXNzdW1lZCB0aGF0IGFuIHVucHJpdmls ZWdlZCB1c2VyLXNwYWNlIHByb2dyYW0gd291bGQgbm90IGhhdmUNCiAgIGFjY2VzcyB0byBSUEMg Y2xpZW50IGhvc3QgY3JlZGVudGlhbHMgbmVlZGVkIHRvIGVzdGFibGlzaCBhIEdTUy1BUEkNCiAg IHNlY3VyaXR5IGNvbnRleHQgYXV0aGVudGljYXRpbmcgdGhlIFJQQyBjbGllbnQgaG9zdCB0byB0 aGUgc2VydmVyLA0KICAgdGhlcmVmb3JlIGFuIHVucHJpdmlsZWdlZCB1c2VyLXNwYWNlIHByb2dy YW0gY291bGQgbm90IGNyZWF0ZSBhbg0KICAgUlBDU0VDX0dTU3YzIFJQQ1NFQ19HU1NfQ1JFQVRF IG1lc3NhZ2UgdGhhdCBzdWNjZXNzZnVsbHkgYmluZHMgYW4gUlBDDQogICBjbGllbnQgaG9zdCBh bmQgYSB1c2VyIHNlY3VyaXR5IGNvbnRleHQuDQoNCiAgIEluIGFkZGl0aW9uIHRvIHRoZSBwYXJl bnQgaGFuZGxlIChTZWN0aW9uIDIpLCB0aGUgbXVsdGktcHJpbmNpcGFsDQogICBhdXRoZW50aWNh dGlvbiBjYWxsIGRhdGEgaGFzIGFuIFJQQ1NFQ19HU1MgdmVyc2lvbiAzIGhhbmRsZQ0KICAgcmVm ZXJlbmNlZCB2aWEgdGhlIHJnbXBfaGFuZGxlIGZpZWxkIHRlcm1lZCB0aGUgImlubmVyIiBoYW5k bGUuDQogICBDbGllbnRzIHVzaW5nIFJQQ1NFQ19HU1N2MyBtdWx0aS1wcmluY2lwYWwgYXV0aGVu dGljYXRpb24gTVVTVCB1c2UgYW4NCiAgIFJQQ1NFQ19HU1N2MyBjb250ZXh0IGhhbmRsZSB0aGF0 IGNvcnJlc3BvbmRzIHRvIGEgR1NTLUFQSSBzZWN1cml0eQ0KDQoNCg0KQWRhbXNvbiAmIFdpbGxp YW1zICAgICAgICBFeHBpcmVzIEp1bmUgNiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTkZTdjQgICAgICAgICAgICAg ICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQogICBjb250ZXh0IHRoYXQgYXV0aGVudGljYXRlcyB0 aGUgUlBDIGNsaWVudCBob3N0IGZvciB0aGUgcGFyZW50IGhhbmRsZS4NCiAgIFRoZSBpbm5lciBj b250ZXh0IGhhbmRsZSBpdCBTSE9VTEQgdXNlIGEgY29udGV4dCBoYW5kbGUgdG8NCiAgIGF1dGhl bnRpY2F0ZSBhIHVzZXIuICBUaGUgcmV2ZXJzZSAocGFyZW50IGhhbmRsZSBhdXRoZW50aWNhdGVz IHVzZXIsDQogICBpbm5lciBhdXRoZW50aWNhdGVzIGFuIFJQQyBjbGllbnQgaG9zdCkgTVVTVCBO T1QgYmUgdXNlZC4gIE90aGVyDQogICBtdWx0aS1wcmluY2lwYWwgcGFyZW50IGFuZCBpbm5lciBj b250ZXh0IGhhbmRsZSB1c2VzIG1pZ2h0IGV2ZW50dWFsbHkNCiAgIG1ha2Ugc2Vuc2UsIGJ1dCB3 b3VsZCBuZWVkIHRvIGJlIGludHJvZHVjZWQgaW4gYSBuZXcgcmV2aXNpb24gb2YgdGhlDQogICBS UENTRUNfR1NTIHByb3RvY29sLg0KDQogICBUaGUgY2hpbGQgY29udGV4dCBoYW5kbGUgcmV0dXJu ZWQgYnkgYSBzdWNjZXNzZnVsIG11bHRpLXByaW5jaXBhbA0KICAgYXNzZXJ0aW9uIGJpbmRzIHRo ZSBpbm5lciBSUENTRUNfR1NTdjMgY29udGV4dCBoYW5kbGUgdG8gdGhlIHBhcmVudA0KICAgUlBD U0VDX0dTUyBjb250ZXh0IGFuZCBNVVNUIGJlIHRyZWF0ZWQgYnkgc2VydmVycyBhcyBhdXRoZW50 aWNhdGluZw0KICAgdGhlIEdTUy1BUEkgaW5pdGlhdG9yIHByaW5jaXBhbCBhdXRoZW50aWNhdGVk IGJ5IHRoZSBpbm5lciBjb250ZXh0DQogICBoYW5kbGUncyBHU1MtQVBJIHNlY3VyaXR5IGNvbnRl eHQuICBUaGlzIHByaW5jaXBhbCBtYXkgYmUgbWFwcGVkIHRvIGENCiAgIHNlcnZlci1zaWRlIG5v dGlvbiBvZiB1c2VyIG9yIHByaW5jaXBhbC4NCg0KICAgTXVsdGktcHJpbmNpcGFsIGJpbmRpbmcg aXMgZG9uZSBieSBpbmNsdWRpbmcgYW4gYXNzZXJ0aW9uIG9mIHR5cGUNCiAgIHJnc3MzX2dzc19t cF9hdXRoIGluIHRoZSBSUENTRUNfR1NTX0NSRUFURSByZ3NzM19jcmVhdGVfYXJncyBjYWxsDQog ICBkYXRhLiAgVGhlIGlubmVyIGNvbnRleHQgaGFuZGxlIGlzIHBsYWNlZCBpbiB0aGUgcmdtcF9o YW5kbGUgZmllbGQuDQogICBBIE1JQyBvZiB0aGUgUlBDIGNhbGwgaGVhZGVyIHVwIHRvIGFuZCBp bmNsdWRpbmcgdGhlIGNyZWRlbnRpYWwgaXMNCiAgIGNvbXB1dGVkIHVzaW5nIHRoZSBHU1MtQVBJ IHNlY3VyaXR5IGNvbnRleHQgYXNzb2NpYXRlZCB3aXRoIHRoZSBpbm5lcg0KICAgY29udGV4dCBo YW5kbGUgaXMgcGxhY2VkIGluIHJnbXBfcnBjaGVhZGVyX21pYyBmaWVsZC4NCg0KICAgVGhlIHRh cmdldCB2ZXJpZmllcyB0aGUgbXVsdGktcHJpbmNpcGFsIGF1dGhlbnRpY2F0aW9uIGJ5IGZpcnN0 DQogICBjb25maXJtaW5nIHRoYXQgdGhlIHBhcmVudCBjb250ZXh0IHVzZWQgaXMgYW4gUlBDIGNs aWVudCBob3N0DQogICBjb250ZXh0LCBhbmQgdGhlbiB2ZXJpZmllcyB0aGUgcmdtcF9ycGNoZWFk ZXJfbWljIHVzaW5nIHRoZSBHU1MtQVBJDQogICBzZWN1cml0eSBjb250ZXh0IGFzc29jaWF0ZWQg d2l0aCB0aGUgcmdtcF9oYW5kbGUgZmllbGQuDQoNCiAgIE9uIGEgc3VjY2Vzc2Z1bCB2ZXJpZmlj YXRpb24sIHRoZSByZ3NzM19nc3NfbXBfYXV0aCBmaWVsZCBpbiB0aGUNCiAgIHJnc3MzX2NyZWF0 ZV9yZXMgcmVwbHkgTVVTVCBiZSBmaWxsZWQgaW4gd2l0aCB0aGUgaW5uZXIgUlBDU0VDX0dTU3Yz DQogICBjb250ZXh0IGhhbmRsZSBhcyB0aGUgcmdtcF9oYW5kbGUsIGFuZCBhIE1JQyBjb21wdXRl ZCBvdmVyIHRoZSBSUEMNCiAgIHJlcGx5IGhlYWRlciAoc2VlIHNlY3Rpb24gU2VjdGlvbiAyLjMp IHVzaW5nIHRoZSBHU1MtQVBJIHNlY3VyaXR5DQogICBjb250ZXh0IGFzc29jaWF0ZWQgd2l0aCB0 aGUgaW5uZXIgaGFuZGxlLg0KDQogICBPbiBmYWlsdXJlLCB0aGUgcmdzczNfZ3NzX21wX2F1dGgg ZmllbGQgaXMgbm90IHNlbnQNCiAgIChyZ3NzM19nc3NfbXBfYXV0aCBpcyBhbiBvcHRpb25hbCBm aWVsZCkuICBBIE1TR19ERU5JRUQgcmVwbHkgdG8gdGhlDQogICBSUENTRUNfR1NTX0NSRUFURSBj YWxsIGlzIGZvcm11bGF0ZWQgYXMgdXN1YWwuDQoNCiAgIEFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDUuMy4zLjMgb2YgWzJdIHRoZSBzZXJ2ZXIgbWFpbnRhaW5zIGEgbGlzdCBvZg0KICAgY29udGV4 dHMgZm9yIHRoZSBjbGllbnRzIHRoYXQgYXJlIGN1cnJlbnRseSBpbiBzZXNzaW9uIHdpdGggaXQu ICBXaGVuDQogICBhIGNsaWVudCByZXF1ZXN0IGNvbWVzIGluLCB0aGVyZSBtYXkgbm90IGJlIGEg Y29udGV4dCBjb3JyZXNwb25kaW5nDQogICB0byBpdHMgaGFuZGxlLiAgV2hlbiB0aGlzIG9jY3Vy cyBvbiBhbiBSUENTRUNfR1NTM19DUkVBVEUgcmVxdWVzdA0KICAgcHJvY2Vzc2luZyBvZiB0aGUg cGFyZW50IGhhbmRsZSwgdGhlIHNlcnZlciByZWplY3RzIHRoZSByZXF1ZXN0IHdpdGgNCiAgIGEg cmVwbHkgc3RhdHVzIG9mIE1TR19ERU5JRUQgd2l0aCB0aGUgcmVqZWN0X3N0YXQgb2YgQVVUSF9F UlJPUiBhbmQNCiAgIHdpdGggYW4gYXV0aF9zdGF0IHZhbHVlIG9mIFJQQ1NFQ19HU1NfQ1JFRFBS T0JMRU0uDQoNCiAgIEEgbmV3IHZhbHVlLCBSUENTRUNfR1NTX0lOTkVSX0NSRURQUk9CTEVNLCBo YXMgYmVlbiBhZGRlZCB0byB0aGUNCiAgIGF1dGhfc3RhdCB0eXBlLiAgV2l0aCBhIG11bHRpLXBy aWNpcGFsIGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdGhlDQogICBzZXJ2ZXIgbXVzdCBhbHNvIGhh dmUgYSBjb250ZXh0IGNvcnJlc3BvbmRpbmcgdG8gdGhlIGlubmVyIGNvbnRleHQNCg0KDQoNCkFk YW1zb24gJiBXaWxsaWFtcyAgICAgICAgRXhwaXJlcyBKdW5lIDYsIDIwMTUgICAgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE5GU3Y0 ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgaGFuZGxlLiAgV2hlbiB0 aGUgc2VydmVyIGRvZXMgbm90IGhhdmUgYSBjb250ZXh0IGhhbmRsZSBjb3JyZXNwb25kaW5nDQog ICB0byB0aGUgaW5uZXIgY29udGV4dCBoYW5kbGUgb2YgYSBtdWx0aS1wcmljaXBhbCBhdXRob3Jp emF0aW9uDQogICByZXF1ZXN0LCB0aGUgc2VydmVyIHNlbmRzIGEgcmVwbHkgc3RhdHVzIG9mIE1T R19ERU5JRUQgd2l0aCB0aGUNCiAgIHJlamVjdF9zdGF0IG9mIEFVVEhfRVJST1IgYW5kIHdpdGgg YW4gYXV0aF9zdGF0IHZhbHVlIG9mDQogICBSUENTRUNfR1NTX0lOTkVSX0NSRURQUk9CTEVNLg0K DQogICBXaGVuIHByb2Nlc3NpbmcgdGhlIG11bHRpLXByaW5jaXBhbCBhdXRoZW50aWNhdGlvbiBy ZXF1ZXN0LCBpZiB0aGUNCiAgIEdTU19WZXJpZnlNSUMoKSBjYWxsIG9uIHRoZSByZ21wX3JwY2hl YWRlcl9taWMgZmFpbHMgdG8gcmV0dXJuDQogICBHU1NfU19DT01QTEVURSwgdGhlIHNlcnZlciBz ZW5kcyBhIHJlcGx5IHN0YXR1cyBvZiBNU0dfREVOSUVEIHdpdGgNCiAgIHRoZSByZWplY3Rfc3Rh dCBvZiBBVVRIX0VSUk9SIGFuZCB3aXRoIGFuIGF1dGhfc3RhdCB2YWx1ZSBvZg0KICAgUlBDU0VD X0dTU19JTk5FUl9DUkVEUFJPQkxFTS4NCg0KMi43LjEuMi4gIENoYW5uZWwgQmluZGluZw0KDQog ICA8Q09ERSBCRUdJTlM+DQoNCiAgICAgIC8vLw0KICAgICAgLy8vICB0eXBlZGVmIG9wYXF1ZSBy Z3NzM19jaGFuX2JpbmRpbmc8PjsNCiAgICAgIC8vLw0KDQogICA8Q09ERSBFTkRTPg0KDQogICBS UENTRUNfR1NTdjMgcHJvdmlkZXMgYSBkaWZmZXJlbnQgd2F5IHRvIGRvIGNoYW5uZWwgYmluZGlu ZyB0aGFuDQogICBSUENTRUNfR1NTdjIgWzhdLiAgU3BlY2lmaWNhbGx5Og0KDQogICBhLiAgUlBD U0VDX0dTU3YzIGJ1aWxkcyBvbiBSUENTRUNfR1NTdjEgYnkgcmV1c2luZyBleGlzdGluZywNCiAg ICAgICBlc3RhYmxpc2hlZCBjb250ZXh0IGhhbmRsZXMgcmF0aGVyIHRoYW4gcHJvdmlkaW5nIGEg ZGlmZmVyZW50IFJQQw0KICAgICAgIHNlY3VyaXR5IGZsYXZvciBmb3IgZXN0YWJsaXNoaW5nIGNv bnRleHQgaGFuZGxlcywNCg0KICAgYi4gIGNoYW5uZWwgYmluZGluZ3MgZGF0YSBhcmUgbm90IGhh c2hlZCBiZWNhdXNlIHRoZSBjb21tdW5pdHkgbm93DQogICAgICAgYWdyZWVzIHRoYXQgaXQgaXMg dGhlIHNlY3VyZSBjaGFubmVsJ3MgcmVzcG9uc2liaWxpdHkgdG8gcHJvZHVjZQ0KICAgICAgIGNo YW5uZWwgYmluZGluZ3MgZGF0YSBvZiBtYW5hZ2VhYmxlIHNpemUuDQoNCiAgIChhKSBpcyB1c2Vm dWwgaW4ga2VlcGluZyBSUENTRUNfR1NTdjMgc2ltcGxlIGluIGdlbmVyYWwsIG5vdCBqdXN0IGZv cg0KICAgY2hhbm5lbCBiaW5kaW5nLiAgKGIpIGlzIHVzZWZ1bCBpbiBrZWVwaW5nIFJQQ1NFQ19H U1N2MyBzaW1wbGUNCiAgIHNwZWNpZmljYWxseSBmb3IgY2hhbm5lbCBiaW5kaW5nLg0KDQogICBD aGFubmVsIGJpbmRpbmcgaXMgYWNjb21wbGlzaGVkIGFzIGZvbGxvd3MuICBUaGUgY2xpZW50IHBy ZWZpeGVzIHRoZQ0KICAgY2hhbm5lbCBiaW5kaW5ncyBkYXRhIG9jdGV0IHN0cmluZyB3aXRoIHRo ZSBjaGFubmVsIHR5cGUgYXMgZGVzY3JpYmVkDQogICBpbiBbNl0sIHRoZW4gdGhlIGNsaWVudCBj YWxscyBHU1NfR2V0TUlDKCkgdG8gZ2V0IGEgTUlDIG9mIHJlc3VsdGluZw0KICAgb2N0ZXQgc3Ry aW5nLCB1c2luZyB0aGUgcGFyZW50IFJQQ1NFQ19HU1N2MyBjb250ZXh0IGhhbmRsZSdzIEdTUy1B UEkNCiAgIHNlY3VyaXR5IGNvbnRleHQuICBUaGUgTUlDIGlzIHRoZW4gcGxhY2VkIGluIHRoZSBy Y2FfY2hhbl9iaW5kX21pYw0KICAgZmllbGQgb2YgUlBDU0VDX0dTU19DUkVBVEUgYXJndW1lbnRz IChyZ3NzM19jcmVhdGVfYXJncykuDQoNCiAgIElmIHRoZSByY2FfY2hhbl9iaW5kX21pYyBmaWVs ZCBvZiB0aGUgYXJndW1lbnRzIG9mIGENCiAgIFJQQ1NFQ19HU1NfQ1JFQVRFIGNvbnRyb2wgbWVz c2FnZSBpcyBzZXQsIHRoZW4gdGhlIHNlcnZlciBNVVNUIHZlcmlmeQ0KICAgdGhlIGNsaWVudCdz IGNoYW5uZWwgYmluZGluZyBNSUMgaWYgdGhlIHNlcnZlciBzdXBwb3J0cyB0aGlzIGZlYXR1cmUu DQogICBJZiBjaGFubmVsIGJpbmRpbmcgdmVyaWZpY2F0aW9uIHN1Y2NlZWRzIHRoZW4gdGhlIHNl cnZlciBNVVNUDQoNCg0KDQpBZGFtc29uICYgV2lsbGlhbXMgICAgICAgIEV4cGlyZXMgSnVuZSA2 LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICBORlN2NCAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoN CiAgIGdlbmVyYXRlIGEgbmV3IE1JQyBvZiB0aGUgc2FtZSBjaGFubmVsIGJpbmRpbmdzIGFuZCBw bGFjZSBpdCBpbiB0aGUNCiAgIHJjcl9jaGFuX2JpbmRfbWljIGZpZWxkIG9mIHRoZSBSUENTRUNf R1NTX0NSRUFURSByZ3NzM19jcmVhdGVfcmVzDQogICByZXN1bHRzLiAgSWYgY2hhbm5lbCBiaW5k aW5nIHZlcmlmaWNhdGlvbiBmYWlscyBvciB0aGUgc2VydmVyIGRvZXNuJ3QNCiAgIHN1cHBvcnQg Y2hhbm5lbCBiaW5kaW5nIHRoZW4gdGhlIHNlcnZlciBNVVNUIGluZGljYXRlIHRoaXMgaW4gaXRz DQogICByZXBseSBieSBub3QgaW5jbHVkaW5nIGEgcmdzczNfY2hhbl9iaW5kaW5nIHZhbHVlIGlu IHJnc3MzX2NyZWF0ZV9yZXMNCiAgIChyZ3NzM19jaGFuX2JpbmRpbmcgaXMgYW4gb3B0aW9uYWwg ZmllbGQpLg0KDQogICBUaGUgY2xpZW50IE1VU1QgdmVyaWZ5IHRoZSByZXN1bHQncyByY3JfY2hh bl9iaW5kX21pYyB2YWx1ZSBieQ0KICAgY2FsbGluZyBHU1NfVmVyaWZ5TUlDKCkgd2l0aCB0aGUg Z2l2ZW4gTUlDIGFuZCB0aGUgY2hhbm5lbCBiaW5kaW5ncw0KICAgZGF0YSAoaW5jbHVkaW5nIHRo ZSBjaGFubmVsIHR5cGUgcHJlZml4KS4gIElmIGNsaWVudC1zaWRlIGNoYW5uZWwNCiAgIGJpbmRp bmcgdmVyaWZpY2F0aW9uIGZhaWxzIHRoZW4gdGhlIGNsaWVudCBNVVNUIGNhbGwNCiAgIFJQQ1NF Q19HU1NfREVTVFJPWS4gIElmIHRoZSBjbGllbnQgcmVxdWVzdGVkIGNoYW5uZWwgYmluZGluZyBi dXQgdGhlDQogICBzZXJ2ZXIgZGlkIG5vdCBpbmNsdWRlIGFuIHJjcl9jaGFuX2JpbmRpbmdfbWlj IGZpZWxkIGluIHRoZSByZXN1bHRzLA0KICAgdGhlbiB0aGUgY2xpZW50IE1BWSBjb250aW51ZSB0 byB1c2UgdGhlIHJlc3VsdGluZyBjb250ZXh0IGhhbmRsZSBhcw0KICAgdGhvdWdoIGNoYW5uZWwg YmluZGluZyBoYWQgbmV2ZXIgYmVlbiByZXF1ZXN0ZWQuICBJZiB0aGUgY2xpZW50DQogICBjb25z aWRlcnMgY2hhbm5lbCBiaW5kaW5nIGNyaXRpY2FsLCBpdCBNVVNUIGNhbGwgUlBDU0VDX0dTU19E RVNUUk9ZLg0KDQogICBBcyBwZXItUlBDU0VDX0dTU3YyIFs4XToNCg0KICAgICAgIk9uY2UgYSBz dWNjZXNzZnVsIFtjaGFubmVsIGJpbmRpbmddIHByb2NlZHVyZSBoYXMgYmVlbiBwZXJmb3JtZWQN CiAgICAgIG9uIGFuIFtSUENTRUNfR1NTdjNdIGNvbnRleHQgaGFuZGxlLCB0aGUgaW5pdGlhdG9y J3MNCiAgICAgIGltcGxlbWVudGF0aW9uIG1heSBtYXAgYXBwbGljYXRpb24gcmVxdWVzdHMgZm9y IHJwY19nc3Nfc3ZjX25vbmUNCiAgICAgIGFuZCBycGNfZ3NzX3N2Y19pbnRlZ3JpdHkgdG8gcnBj X2dzc19zdmNfY2hhbm5lbF9wcm90IGNyZWRlbnRpYWxzLg0KICAgICAgQW5kIGlmIHRoZSBzZWN1 cmUgY2hhbm5lbCBoYXMgcHJpdmFjeSBlbmFibGVkLCByZXF1ZXN0cyBmb3INCiAgICAgIHJwY19n c3Nfc3ZjX3ByaXZhY3kgY2FuIGFsc28gYmUgbWFwcGVkIHRvDQogICAgICBycGNfZ3NzX3N2Y19j aGFubmVsX3Byb3QuIg0KDQogICBBbnkgUlBDU0VDX0dTU3YzIGNoaWxkIGNvbnRleHQgaGFuZGxl IHRoYXQgaGFzIGJlZW4gYm91bmQgdG8gYSBzZWN1cmUNCiAgIGNoYW5uZWwgaW4gdGhpcyB3YXkg U0hPVUxEIGJlIHVzZWQgb25seSB3aXRoIHRoZQ0KICAgcnBjX2dzc19zdmNfY2hhbm5lbF9wcm90 LCBhbmQgU0hPVUxEIE5PVCBiZSB1c2VkIHdpdGgNCiAgIHJwY19nc3Nfc3ZjX25vbmUgbm9yIHJw Y19nc3Nfc3ZjX2ludGVncml0eSAtLSBpZiB0aGUgc2VjdXJlIGNoYW5uZWwNCiAgIGRvZXMgbm90 IHByb3ZpZGUgcHJpdmFjeSBwcm90ZWN0aW9uIHRoZW4gdGhlIGNsaWVudCBNQVkgdXNlDQogICBy cGNfZ3NzX3N2Y19wcml2YWN5IHdoZXJlIHByaXZhY3kgcHJvdGVjdGlvbiBpcyBuZWVkZWQgb3Ig ZGVzaXJlZC4NCg0KMi43LjEuMy4gIExhYmVsIEFzc2VydGlvbnMNCg0KICAgPENPREUgQkVHSU5T Pg0KDQogICAgICAvLy8gIHN0cnVjdCByZ3NzM19sYWJlbCB7DQogICAgICAvLy8gICAgICAgICAg cmdzczNfbGZzICAgICAgIHJsX2xmczsNCiAgICAgIC8vLyAgICAgICAgICBvcGFxdWUgICAgICAg ICAgcmxfbGFiZWw8PjsNCiAgICAgIC8vLyAgfTsNCiAgICAgIC8vLw0KICAgICAgLy8vICBzdHJ1 Y3QgcmdzczNfbGZzIHsNCiAgICAgIC8vLyAgICAgICAgICB1bnNpZ25lZCBpbnQgcmxmX2xmc19p ZDsNCiAgICAgIC8vLyAgICAgICAgICB1bnNpZ25lZCBpbnQgcmxmX3BpX2lkOw0KICAgICAgLy8v ICB9Ow0KICAgICAgLy8vDQoNCg0KDQpBZGFtc29uICYgV2lsbGlhbXMgICAgICAgIEV4cGlyZXMg SnVuZSA2LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBORlN2NCAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAx NA0KDQoNCiAgIDxDT0RFIEVORFM+DQoNCiAgIFRoZSBjbGllbnQgZGlzY292ZXJzIHdoaWNoIGxh YmVscyB0aGUgc2VydmVyIHN1cHBvcnRzIHZpYSB0aGUNCiAgIFJQQ1NFQ19HU1NfTElTVCBjb250 cm9sIG1lc3NhZ2UuICBBc3NlcnRpbmcgYSBzZXJ2ZXIgc3VwcG9ydGVkIGxhYmVsDQogICB2aWEg UlBDU0VDX0dTU19DUkVBVEUgZW5hYmxlcyBzZXJ2ZXIgZ3Vlc3QgbW9kZSBsYWJlbHMuICBGdWxs IG1vZGUgaXMNCiAgIGVuYWJsZWQgd2hlbiBhbiBSUENTRUNfR1NTX0NSRUFURSBsYWJlbCBhc3Nl cnRpb24gaXMgY29tYmluZWQgd2l0aA0KICAgYXNzZXJ0aW5nIHRoZSBzYW1lIGxhYmVsIHdpdGgg dGhlIE5GU3Y0LjIgc2VjX2xhYmVsIGF0dHJpYnV0ZS4NCg0KICAgTGFiZWwgZW5jb2RpbmcgaXMg c3BlY2lmaWVkIHRvIG1pcnJvciB0aGUgTkZTdjQuMiBzZWNfbGFiZWwgYXR0cmlidXRlDQogICBk ZXNjcmliZWQgaW4gU2VjdGlvbiAxMi4yLjIgb2YgWzRdLiAgVGhlIGxhYmVsIGZvcm1hdCBzcGVj aWZpZXIgKExGUykNCiAgIGlzIGFuIGlkZW50aWZpZXIgdXNlZCBieSB0aGUgY2xpZW50IHRvIGVz dGFibGlzaCB0aGUgc3ludGFjdGljIGZvcm1hdA0KICAgb2YgdGhlIHNlY3VyaXR5IGxhYmVsIGFu ZCB0aGUgc2VtYW50aWMgbWVhbmluZyBvZiBpdHMgY29tcG9uZW50cy4NCiAgIFRoZSBwb2xpY3kg aWRlbnRpZmllciAoUEkpIGlzIGFuIG9wdGlvbmFsIHBhcnQgb2YgdGhlIGRlZmluaXRpb24gb2YN CiAgIGFuIExGUyB3aGljaCBhbGxvd3MgZm9yIGNsaWVudHMgYW5kIHNlcnZlciB0byBpZGVudGlm eSBzcGVjaWZpYw0KICAgc2VjdXJpdHkgcG9saWNpZXMuICBUaGUgb3BhcXVlIGxhYmVsIGZpZWxk IG9mIHJnc3MzX2xhYmVsIGlzDQogICBkZXBlbmRlbnQgb24gdGhlIE1BQyBtb2RlbCB0byBpbnRl cnByZXQgYW5kIGVuZm9yY2UuDQoNCiAgIElmIGEgbGFiZWwgaXRzZWxmIHJlcXVpcmVzIHByaXZh Y3kgcHJvdGVjdGlvbiAoaS5lLiwgdGhhdCB0aGUgdXNlcg0KICAgY2FuIGFzc2VydCB0aGF0IGxh YmVsIGlzIGEgc2VjcmV0KSB0aGVuIHRoZSBjbGllbnQgTVVTVCB1c2UgdGhlDQogICBycGNfZ3Nz X3N2Y19wcml2YWN5IHByb3RlY3Rpb24gc2VydmljZSBmb3IgdGhlIFJQQ1NFQ19HU1NfQ1JFQVRF DQogICByZXF1ZXN0Lg0KDQogICBSUENTRUNfR1NTdjMgY2xpZW50cyBNQVkgYXNzZXJ0IGEgc2Vy dmVyIHNlY3VyaXR5IGxhYmVsIGluIHNvbWUgTFNGDQogICBieSBiaW5kaW5nIGEgbGFiZWwgYXNz ZXJ0aW9uIHRvIHRoZSBSUENTRUNfR1NTdjMgY29udGV4dCBoYW5kbGUuDQogICBUaGlzIGlzIGRv bmUgYnkgaW5jbHVkaW5nIGFuIGFzc2VydGlvbiBvZiB0eXBlIHJnc3MzX2xhYmVsIGluIHRoZQ0K ICAgUlBDU0VDX0dTU19DUkVBVEUgcmdzczNfY3JlYXRlX2FyZ3MgcmNhX2Fzc2VydGlvbnMgY2Fs bCBkYXRhLg0KDQogICBTZXJ2ZXJzIHRoYXQgc3VwcG9ydCBsYWJlbGluZyBpbiB0aGUgcmVxdWVz dGVkIExGUyBNQVkgbWFwIHRoZQ0KICAgcmVxdWVzdGVkIGxhYmVsIHRvIGRpZmZlcmVudCBsYWJl bCBhcyBhIHJlc3VsdCBvZiBzZXJ2ZXItc2lkZSBwb2xpY3kNCiAgIGV2YWx1YXRpb24uDQoNCiAg IFRoZSBsYWJlbHMgdGhhdCBhcmUgYWNjZXB0ZWQgYnkgdGhlIHRhcmdldCBhbmQgYm91bmQgdG8g dGhlDQogICBSUENTRUNfR1NTdjMgY29udGV4dCBNVVNUIGJlIGVudW1lcmF0ZWQgaW4gdGhlIHJj cl9hc3NlcnRpb25zIGZpZWxkDQogICBvZiB0aGUgcmdzczNfY3JlYXRlX3JlcyBSUENTRUNfR1NT X0NSRUFURSByZXBseS4NCg0KICAgU2VydmVycyB0aGF0IGRvIG5vdCBzdXBwb3J0IGxhYmVsaW5n IG9yIHRoYXQgZG8gbm90IHN1cHBvcnQgdGhlDQogICByZXF1ZXN0ZWQgTEZTIHJlamVjdCB0aGUg bGFiZWwgYXNzZXJ0aW9uIHdpdGggYSByZXBseSBzdGF0dXMgb2YNCiAgIE1TR19ERU5JRUQsIGEg cmVqZWN0X3N0YXR1cyBvZiBBVVRIX0VSUk9SLCBhbmQgYW4gYXV0aF9zdGF0IG9mDQogICBSUENT RUNfR1NTX0xBQkVMX1BST0JMRU0uDQoNCjIuNy4xLjQuICBTdHJ1Y3R1cmVkIFByaXZpbGVnZSBB c3NlcnRpb25zDQoNCiAgIDxDT0RFIEJFR0lOUz4NCg0KDQoNCg0KDQoNCg0KDQpBZGFtc29uICYg V2lsbGlhbXMgICAgICAgIEV4cGlyZXMgSnVuZSA2LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFn ZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBORlN2NCAgICAgICAg ICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgICAgIC8vLw0KICAgICAgLy8vICBzdHJ1 Y3QgcmdzczNfcHJpdnMgew0KICAgICAgLy8vICAgICAgICAgIHN0cmluZyAgICAgICAgICBycF9u YW1lPD47IC8qIGh1bWFuIHJlYWRhYmxlICovDQogICAgICAvLy8gICAgICAgICAgb3BhcXVlICAg ICAgICAgIHJwX3ByaXZpbGVnZTw+Ow0KICAgICAgLy8vICB9Ow0KDQogICA8Q09ERSBFTkRTPg0K DQogICBBIHN0cnVjdHVyZWQgcHJpdmlsZWdlIGlzIGFuIFJQQyBhcHBsaWNhdGlvbiBkZWZpbmVk IHByaXZpbGVnZS4NCiAgIFJQQ1NFQ19HU1N2MyBjbGllbnRzIE1BWSBhc3NlcnQgYSBzdHJ1Y3R1 cmVkIHByaXZpbGVnZSBieSBiaW5kaW5nIHRoZQ0KICAgcHJpdmlsZWdlIHRvIHRoZSBSUENTRUNf R1NTdjMgY29udGV4dCBoYW5kbGUuICBUaGlzIGlzIGRvbmUgYnkNCiAgIGluY2x1ZGluZyBhbiBh c3NlcnRpb24gb2YgdHlwZSByZ3NzM19wcml2cyBpbiB0aGUgUlBDU0VDX0dTU19DUkVBVEUNCiAg IHJnc3MzX2NyZWF0ZV9hcmdzIHJjYV9hc3NlcnRpb25zIGNhbGwgZGF0YS4gIEVuY29kaW5nLCBz ZXJ2ZXINCiAgIHZlcmlmaWNhdGlvbiBhbmQgYW55IHBvbGljaWVzIGZvciBzdHJ1Y3R1cmVkIHBy aXZpbGVnZXMgYXJlIGRlc2NyaWJlZA0KICAgYnkgdGhlIFJQQyBhcHBsaWNhdGlvbiBkZWZpbml0 aW9uLg0KDQogICBBIHN1Y2Nlc3NmdWwgc3RydWN0dXJlZCBwcml2aWxlZ2UgYXNzZXJ0aW9uIE1V U1QgYmUgZW51bWVyYXRlZCBpbiB0aGUNCiAgIHJjcl9hc3NlcnRpb25zIGZpZWxkIG9mIHRoZSBy Z3NzM19jcmVhdGVfcmVzIFJQQ1NFQ19HU1NfQ1JFQVRFIHJlcGx5Lg0KDQogICBJZiBhIHNlcnZl ciByZWNlaXZlcyBhIHN0cnVjdHVyZWQgcHJpdmlsZWdlIGFzc2VydGlvbiB0aGF0IGl0IGRvZXMN CiAgIG5vdCByZWNvZ25pemUgdGhlIGFzc2VydGlvbiBpcyByZWplY3RlZCB3aXRoIGEgcmVwbHkg c3RhdHVzIG9mDQogICBNU0dfREVOSUVELCBhIHJlamVjdF9zdGF0dXMgb2YgQVVUSF9FUlJPUiwg YW5kIGFuIGF1dGhfc3RhdCBvZg0KICAgUlBDU0VDX0dTU19VTktOT1dOX01FU1NBR0UuDQoNCiAg IElmIGEgc2VydmVyIHJlY2VpdmVzIGEgc3RydWN0dXJlZCBwcml2aWxlZ2UgYXNzZXJ0aW9uIHRo YXQgaXQgZmFpbHMNCiAgIHRvIHZlcmlmeSBhY2NvcmRpbmcgdG8gdGhlIHJlcXVpcmVtZW50cyBv ZiB0aGUgUlBDIGFwcGxpY2F0aW9uDQogICBkZWZpbmVkIGJlaGF2aW9yLCB0aGUgYXNzZXJ0aW9u IGlzIHJlamVjdGVkIHdpdGggYSByZXBseSBzdGF0dXMgb2YNCiAgIE1TR19ERU5JRUQsIGEgcmVq ZWN0X3N0YXR1cyBvZiBBVVRIX0VSUk9SLCBhbmQgYW4gYXV0aF9zdGF0IG9mDQogICBSUENTRUNf R1NTX1BSSVZJTEVHRV9QUk9CTEVNLg0KDQogICBTZWN0aW9uIDMuNC4xLjIuICAiSW50ZXItU2Vy dmVyIENvcHkgd2l0aCBSUENTRUNfR1NTdjMiIG9mIFs0XSBzaG93cw0KICAgYW4gZXhhbXBsZSBv ZiBzdHJ1Y3R1cmVkIHByaXZpbGVnZSBkZWZpbml0aW9uIGFuZCB1c2UuDQoNCjIuNy4yLiAgTmV3 IENvbnRyb2wgUHJvY2VkdXJlIC0gUlBDU0VDX0dTU19MSVNUDQoNCiAgIDxDT0RFIEJFR0lOUz4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFkYW1zb24gJiBXaWxsaWFtcyAgICAgICAg RXhwaXJlcyBKdW5lIDYsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE5GU3Y0ICAgICAgICAgICAgICAgICAgICBEZWNl bWJlciAyMDE0DQoNCg0KICAgICAgLy8vICBlbnVtIHJnc3MzX2xpc3RfaXRlbSB7DQogICAgICAv Ly8gICAgICAgICAgTEFCRUwgPSAwLA0KICAgICAgLy8vICAgICAgICAgIFBSSVZTID0gMQ0KICAg ICAgLy8vICB9Ow0KICAgICAgLy8vDQogICAgICAvLy8gIHN0cnVjdCByZ3NzM19saXN0X2FyZ3Mg ew0KICAgICAgLy8vICAgICAgICAgIHJnc3MzX2xpc3RfaXRlbSAgICAgIHJsYV9saXN0X3doYXQ8 PjsNCiAgICAgIC8vLyAgfTsNCiAgICAgIC8vLw0KICAgICAgLy8vICB1bmlvbiByZ3NzM19saXN0 X2l0ZW1fdQ0KICAgICAgLy8vICAgICAgICBzd2l0Y2ggKHJnc3MzX2xpc3RfaXRlbSBpdHlwZSkg ew0KICAgICAgLy8vICBjYXNlIExBQkVMOg0KICAgICAgLy8vICAgICAgICAgIHJnc3MzX2xhYmVs ICAgICAgICAgIHJsaV9sYWJlbHM8PjsNCiAgICAgIC8vLyAgY2FzZSBQUklWUzoNCiAgICAgIC8v LyAgICAgICAgICByZ3NzM19wcml2cyAgICAgICAgICBybGlfcHJpdnM8PjsNCiAgICAgIC8vLyAg fTsNCiAgICAgIC8vLw0KICAgICAgLy8vICB0eXBlZGVmIHJnc3MzX2xpc3RfaXRlbV91IHJnc3Mz X2xpc3RfcmVzPD47DQogICAgICAvLy8NCg0KICAgPENPREUgRU5EUz4NCg0KICAgVGhlIGNhbGwg ZGF0YSBmb3IgYW4gUlBDU0VDX0dTU19MSVNUIHJlcXVlc3QgY29uc2lzdHMgb2YgYSBsaXN0IG9m DQogICBpbnRlZ2VycyAocmxhX2xpc3Rfd2hhdCkgaW5kaWNhdGluZyB3aGF0IGFzc2VydGlvbnMg dG8gYmUgbGlzdGVkLCBhbmQNCiAgIHRoZSByZXBseSBjb25zaXN0cyBvZiBhbiBlcnJvciBvciB0 aGUgcmVxdWVzdGVkIGxpc3QuDQoNCiAgIFRoZSByZXN1bHQgb2YgcmVxdWVzdGluZyBhIGxpc3Qg b2YgcmdzczNfbGlzdF9pdGVtIExBQkVMIGlzIGEgbGlzdCBvZg0KICAgTEZTcyBzdXBwb3J0ZWQg YnkgdGhlIHNlcnZlci4gIFRoZSBjbGllbnQgY2FuIHRoZW4gdXNlIHRoZSBMRlMgbGlzdA0KICAg dG8gYXNzZXJ0IGxhYmVscyB2aWEgdGhlIFJQQ1NFQ19HU1NfQ1JFQVRFIGxhYmVsIGFzc2VydGlv bnMuICBTZWUNCiAgIFNlY3Rpb24gMi43LjEuMy4NCg0KMi44LiAgRXh0ZW5zaWJpbGl0eQ0KDQog ICBBc3NlcnRpb24gdHlwZXMgbWF5IGJlIGFkZGVkIGluIHRoZSBmdXR1cmUgYnkgYWRkaW5nIGFy bXMgdG8gdGhlDQogICAncmdzczNfYXNzZXJ0aW9uX3UnIHVuaW9uLiAgT3RoZXIgYXNzZXJ0aW9u IHR5cGVzIGFyZSBkZXNjcmliZWQNCiAgIGVsc2V3aGVyZSBhbmQgaW5jbHVkZToNCg0KICAgbyAg Q2xpZW50LXNpZGUgYXNzZXJ0aW9ucyBvZiBpZGVudGl0eToNCg0KICAgICAgKiAgUHJpbWFyeSBj bGllbnQvdXNlciBpZGVudGl0eQ0KDQogICAgICAqICBTdXBwbGVtZW50YXJ5IGdyb3VwIG1lbWJl cnNoaXBzIG9mIHRoZSBjbGllbnQvdXNlciwgaW5jbHVkaW5nDQogICAgICAgICBzdXBwb3J0IGZv ciBzcGVjaWZ5aW5nIGRlbHRhcyB0byB0aGUgbWVtYmVyc2hpcCBsaXN0IGFzIHNlZW4gb24NCiAg ICAgICAgIHRoZSBzZXJ2ZXIuDQoNCg0KDQoNCg0KDQoNCkFkYW1zb24gJiBXaWxsaWFtcyAgICAg ICAgRXhwaXJlcyBKdW5lIDYsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIE5GU3Y0ICAgICAgICAgICAgICAgICAgICBE ZWNlbWJlciAyMDE0DQoNCg0KMy4gIE9wZXJhdGlvbmFsIFJlY29tbWVuZGF0aW9uIGZvciBEZXBs b3ltZW50DQoNCiAgIFJQQ1NFQ19HU1N2MyBpcyBhIHN1cGVyc2V0IG9mIFJQQ1NFQ19HU1N2MiBb OF0gd2hpY2ggaW4gdHVybiBpcyBhDQogICBzdXBlcnNldCBvZiBSUENTRUNfR1NTdjEgWzJdLCBh bmQgc28gY2FuIGJlIHVzZWQgaW4gYWxsIHNpdHVhdGlvbnMNCiAgIHdoZXJlIFJQQ1NFQ19HU1N2 MSBvciBSUENTRUNfR1NTdjIgaXMgdXNlZC4gIFJQQ1NFQ19HU1N2MyBzaG91bGQgYmUNCiAgIHVz ZWQgd2hlbiB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgaXMgbmVlZGVkLg0KDQo0LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBlbnRpcmUgZG9jdW1lbnQgZGVhbHMgd2l0aCBzZWN1 cml0eSBpc3N1ZXMuDQoNCiAgIFRoZSBSUENTRUNfR1NTdjMgcHJvdG9jb2wgYWxsb3dzIGZvciBj bGllbnQtc2lkZSBhc3NlcnRpb25zIG9mIGRhdGENCiAgIHRoYXQgaXMgcmVsZXZhbnQgdG8gc2Vy dmVyLXNpZGUgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMuICBUaGVzZQ0KICAgYXNzZXJ0aW9ucyBt dXN0IGJlIGV2YWx1YXRlZCBieSB0aGUgc2VydmVyIGluIHRoZSBjb250ZXh0IG9mIHdoZXRoZXIN CiAgIHRoZSBjbGllbnQgYW5kL29yIHVzZXIgYXJlIGF1dGhlbnRpY2F0ZWQsIHdoZXRoZXIgbXVs dGktcHJpbmNpcGFsDQogICBhdXRoZW50aWNhdGlvbiB3YXMgdXNlZCwgd2hldGhlciB0aGUgY2xp ZW50IGlzIHRydXN0ZWQsIHdoYXQgcmFuZ2VzDQogICBvZiBhc3NlcnRpb25zIGFyZSBhbGxvd2Vk IGZvciB0aGUgY2xpZW50IGFuZCB0aGUgdXNlciAoc2VwYXJhdGVseSBvcg0KICAgdG9nZXRoZXIp LCBhbmQgYW55IHJlbGV2YW50IHNlcnZlci1zaWRlIHBvbGljeS4NCg0KICAgVGhlIHNlY3VyaXR5 IHNlbWFudGljcyBvZiBhc3NlcnRpb25zIGNhcnJpZWQgYnkgUlBDU0VDX0dTU3YzIGFyZQ0KICAg YXBwbGljYXRpb24gcHJvdG9jb2wtc3BlY2lmaWMuDQoNCiAgIE5vdGUgdGhhdCBSUFNFQ19HU1N2 MyBpcyBub3QgYSBjb21wbGV0ZSBzb2x1dGlvbiBmb3IgbGFiZWxpbmc6IGl0DQogICBjb252ZXlz IHRoZSBsYWJlbHMgb2YgYWN0b3JzLCBidXQgbm90IHRoZSBsYWJlbHMgb2Ygb2JqZWN0cy4gIFJQ Qw0KICAgYXBwbGljYXRpb24gcHJvdG9jb2xzIG1heSByZXF1aXJlIGV4dGVuZGluZyBpbiBvcmRl ciB0byBjYXJyeSBvYmplY3QNCiAgIGxhYmVsIGluZm9ybWF0aW9uLg0KDQogICBUaGVyZSBtYXkg YmUgaW50ZXJhY3Rpb25zIHdpdGggTkZTdjQncyBjYWxsYmFjayBzZWN1cml0eSBzY2hlbWUgYW5k DQogICBORlN2NC4xJ3MgWzVdIEdTUy1BUEkgIlNTViIgbWVjaGFuaXNtcy4gIFNwZWNpZmljYWxs eSwgdGhlIE5GU3Y0DQogICBjYWxsYmFjayBzY2hlbWUgcmVxdWlyZXMgdGhhdCB0aGUgc2VydmVy IGluaXRpYXRlIEdTUy1BUEkgc2VjdXJpdHkNCiAgIGNvbnRleHRzLCB3aGljaCBkb2VzIG5vdCB3 b3JrIHdlbGwgaW4gcHJhY3RpY2UsIGFuZCBpbiB0aGUgY29udGV4dCBvZg0KICAgY2xpZW50LSBz aWRlIHByb2Nlc3NlcyBydW5uaW5nIGFzIHRoZSBzYW1lIHVzZXIgYnV0IHdpdGggZGlmZmVyZW50 DQogICBwcml2aWxlZ2VzIGFuZCBzZWN1cml0eSBsYWJlbHMgdGhlIE5GU3Y0IGNhbGxiYWNrIHNl Y3VyaXR5IHNjaGVtZQ0KICAgc2VlbXMgcGFydGljdWxhcmx5IHVubGlrZWx5IHRvIHdvcmsgd2Vs bC4gIE5GU3Y0LjEgaGFzIHRoZSBzZXJ2ZXIgdXNlDQogICBhbiBleGlzdGluZywgY2xpZW50LWlu aXRpYXRlZCBSUENTRUNfR1NTIGNvbnRleHQgaGFuZGxlIHRvIHByb3RlY3QNCiAgIHNlcnZlci1p bml0aWF0ZWQgY2FsbGJhY2sgUlBDcy4gIFRoZSBORlN2NC4xIGNhbGxiYWNrIHNlY3VyaXR5IHNj aGVtZQ0KICAgbGFja3MgYWxsIHRoZSBwcm9ibGVtcyBvZiB0aGUgTkZTdjQgc2NoZW1lLCBob3dl dmVyLCBpdCBpcyBpbXBvcnRhbnQNCiAgIHRoYXQgdGhlIHNlcnZlciBwaWNrIGFuIGFwcHJvcHJp YXRlIFJQQ1NFQ19HU1MgY29udGV4dCBoYW5kbGUgdG8NCiAgIHByb3RlY3QgYW55IGNhbGxiYWNr cy4gIFNwZWNpZmljYWxseSwgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHNlcnZlcg0KICAgdXNl IFJQQ1NFQ19HU1MgY29udGV4dCBoYW5kbGVzIHdoaWNoIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50 IHRvDQogICBwcm90ZWN0IGFueSBjYWxsYmFja3MgcmVsYXRpbmcgdG8gc2VydmVyIHN0YXRlIGlu aXRpYXRlZCBieSBSUENzDQogICBwcm90ZWN0ZWQgYnkgUlBDU0VDX0dTU3YzIGNvbnRleHRzLg0K DQogICBBcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEwLjEwIFs1XSB0aGUgY2xpZW50IGlzIHBl cm1pdHRlZCB0bw0KICAgYXNzb2NpYXRlIG11bHRpcGxlIFJQQ1NFQ19HU1MgaGFuZGxlcyB3aXRo IGEgc2luZ2xlIFNTViBHU1MgY29udGV4dC4NCiAgIFJQQ1NFQ19HU1N2MyBoYW5kbGVzIHdpbGwg d29yayB3ZWxsIHdpdGggU1NWIGluIHRoYXQgdGhlIG1hbi1pbi10aGUtDQogICBtaWRkbGUgYXR0 YWNrcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEwLjEwIFs1XSBhcmUgc29sdmVkIGJ5IHRoZSBu ZXcNCiAgIHJlcGx5IHZlcmlmaWVyIChTZWN0aW9uIDIuMykuICBVc2luZyBhbiBSUENTRUNfR1NT djMgaGFuZGxlIGJhY2tlZCBieQ0KDQoNCg0KQWRhbXNvbiAmIFdpbGxpYW1zICAgICAgICBFeHBp cmVzIEp1bmUgNiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgTkZTdjQgICAgICAgICAgICAgICAgICAgIERlY2VtYmVy IDIwMTQNCg0KDQogICBhIEdTUy1TU1YgbWVjaGFuaXNtIGNvbnRleHQgYXMgYSBwYXJlbnQgaGFu ZGxlIGluIGFuDQogICBSUENTRUNfR1NTX0NSRUFURSBjYWxsIHdoaWxlIHBlcm1pdHRlZCBpcyBj b21wbGljYXRlZCBieSB0aGUgbGlmZXRpbWUNCiAgIHJ1bGVzIG9mIFNTViBjb250ZXh0cyBhbmQg dGhlaXIgYXNzb2NpYXRlZCBSUENTRUNfR1NTIGhhbmRsZXMuDQoNCjUuICBJQU5BIENvbnNpZGVy YXRpb25zDQoNCiAgIFRoZXJlIGFyZSBubyBJQU5BIGNvbnNpZGVyYXRpb25zIGluIHRoaXMgZG9j dW1lbnQuDQoNCjYuICBSZWZlcmVuY2VzDQoNCjYuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoN CiAgIFsxXSAgICAgICAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv IEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAyMTE5LCBN YXJjaCAxOTk3Lg0KDQogICBbMl0gICAgICAgIEVpc2xlciwgTS4sIENoaXUsIEEuLCBhbmQgTC4g TGluZywgIlJQQ1NFQ19HU1MgUHJvdG9jb2wNCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiIs IFJGQyAyMjAzLCBTZXB0ZW1iZXIgMTk5Ny4NCg0KICAgWzNdICAgICAgICBMaW5uLCBKLiwgIkdl bmVyaWMgU2VjdXJpdHkgU2VydmljZSBBcHBsaWNhdGlvbiBQcm9ncmFtDQogICAgICAgICAgICAg IEludGVyZmFjZSBWZXJzaW9uIDIsIFVwZGF0ZSAxIiwgUkZDIDI3NDMsIEphbnVhcnkgMjAwMC4N Cg0KICAgWzRdICAgICAgICBIYXluZXMsIFQuLCAiTkZTIFZlcnNpb24gNCBNaW5vciBWZXJzaW9u IDIiLCBkcmFmdC1pZXRmLQ0KICAgICAgICAgICAgICBuZnN2NC1taW5vcnZlcnNpb24yLTI5IChX b3JrIEluIFByb2dyZXNzKSwgRGVjZW1iZXIgMjAxNC4NCg0KICAgWzVdICAgICAgICBTaGVwbGVy LCBTLiwgRWlzbGVyLCBNLiwgYW5kIEQuIE5vdmVjaywgIk5ldHdvcmsgRmlsZQ0KICAgICAgICAg ICAgICBTeXN0ZW0gKE5GUykgVmVyc2lvbiA0IE1pbm9yIFZlcnNpb24gMSBQcm90b2NvbCIsIFJG Qw0KICAgICAgICAgICAgICA1NjYxLCBKYW51YXJ5IDIwMTAuDQoNCiAgIFs2XSAgICAgICAgV2ls bGlhbXMsIE4uLCAiT24gdGhlIFVzZSBvZiBDaGFubmVsIEJpbmRpbmdzIHRvIFNlY3VyZQ0KICAg ICAgICAgICAgICBDaGFubmVscyIsIFJGQyA1MDU2LCBOb3ZlbWJlciAyMDA3Lg0KDQogICBbN10g ICAgICAgIEVpc2xlciwgTS4sICJYRFI6IEV4dGVybmFsIERhdGEgUmVwcmVzZW50YXRpb24gU3Rh bmRhcmQiLA0KICAgICAgICAgICAgICBSRkMgNDUwNiwgTWF5IDIwMDYuDQoNCiAgIFs4XSAgICAg ICAgRWlzbGVyLCBNLiwgIlJQQ1NFQ19HU1MgVmVyc2lvbiAyIiwgUkZDIDU0MDMsIEZlYnJ1YXJ5 DQogICAgICAgICAgICAgIDIwMDkuDQoNCiAgIFs5XSAgICAgICAgSGF5bmVzLCBULiwgIlJlcXVp cmVtZW50cyBmb3IgTGFiZWxlZCBORlMiLCBSRkMgNzIwNCwNCiAgICAgICAgICAgICAgQXByaWwg MjAxNC4NCg0KNi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbMTBdICAgICAgICJT ZWN0aW9uIDQ2LjYuIE11bHRpLUxldmVsIFNlY3VyaXR5IChNTFMpIG9mIERlcGxveW1lbnQNCiAg ICAgICAgICAgICAgR3VpZGU6IERlcGxveW1lbnQsIGNvbmZpZ3VyYXRpb24gYW5kIGFkbWluaXN0 cmF0aW9uIG9mIFJlZA0KICAgICAgICAgICAgICBIYXQgRW50ZXJwcmlzZSBMaW51eCA1LCBFZGl0 aW9uIDYiLCAyMDExLg0KDQoNCg0KDQoNCg0KQWRhbXNvbiAmIFdpbGxpYW1zICAgICAgICBFeHBp cmVzIEp1bmUgNiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgTkZTdjQgICAgICAgICAgICAgICAgICAgIERlY2VtYmVy IDIwMTQNCg0KDQogICBbMTFdICAgICAgIFNtYWxsZXksIFMuLCAiVGhlIERpc3RyaWJ1dGVkIFRy dXN0ZWQgT3BlcmF0aW5nIFN5c3RlbQ0KICAgICAgICAgICAgICAoRFRPUykgSG9tZSBQYWdlIiwg MjAwMCwNCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cuY3MudXRhaC5lZHUvZmx1eC9mbHVrZS9o dG1sL2R0b3MvSFRNTC8NCiAgICAgICAgICAgICAgZHRvcy5odG1sPi4NCg0KICAgWzEyXSAgICAg ICBDYXJ0ZXIsIEouLCAiSW1wbGVtZW50aW5nIFNFTGludXggU3VwcG9ydCBmb3IgTkZTIiwgMjAw NSwNCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cubnNhLmdvdi9yZXNlYXJjaC9fZmlsZXMvc2Vs aW51eC9wYXBlcnMvDQogICAgICAgICAgICAgIG5mc3YzLnBkZj4uDQoNCiAgIFsxM10gICAgICAg UXVpZ2xleSwgRC4gYW5kIEouIEx1LCAiUmVnaXN0cnkgU3BlY2lmaWNhdGlvbiBmb3IgTUFDDQog ICAgICAgICAgICAgIFNlY3VyaXR5IExhYmVsIEZvcm1hdHMiLCBkcmFmdC1xdWlnbGV5LWxhYmVs LWZvcm1hdC0NCiAgICAgICAgICAgICAgcmVnaXN0cnkgKHdvcmsgaW4gcHJvZ3Jlc3MpLCAyMDEx Lg0KDQogICBbMTRdICAgICAgIFdpbGtpbnNvbiwgUy4gYW5kIEIuIEthZHVrLCAiSW50ZWdyYXRp bmcgcnhnayB3aXRoIEFGUyIsDQogICAgICAgICAgICAgIGRyYWZ0LXdpbGtpbnNvbi1hZnMzLXJ4 Z2stYWZzICh3b3JrIGluIHByb2dyZXNzKSwgQXByaWwNCiAgICAgICAgICAgICAgMjAxNC4NCg0K QXBwZW5kaXggQS4gIEFja25vd2xlZGdtZW50cw0KDQogICBBbmR5IEFkYW1zb24gd291bGQgbGlr ZSB0byB0aGFuayBOZXRBcHAsIEluYy4gZm9yIGl0cyBmdW5kaW5nIG9mIGhpcw0KICAgdGltZSBv biB0aGlzIHByb2plY3QuDQoNCiAgIFdlIHRoYW5rIExhcnMgRWdnZXJ0LCBNaWtlIEVpc2xlciwg QmVuIEthZHVrLCBhbmQgQnJ1Y2UgRmllbGRzIGZvcg0KICAgdGhlaXIgbW9zdCBoZWxwZnVsIHJl dmlld3MuDQoNCkFwcGVuZGl4IEIuICBSRkMgRWRpdG9yIE5vdGVzDQoNCiAgIFtSRkMgRWRpdG9y OiBwbGVhc2UgcmVtb3ZlIHRoaXMgc2VjdGlvbiBwcmlvciB0byBwdWJsaXNoaW5nIHRoaXMNCiAg IGRvY3VtZW50IGFzIGFuIFJGQ10NCg0KICAgW1JGQyBFZGl0b3I6IHByaW9yIHRvIHB1Ymxpc2hp bmcgdGhpcyBkb2N1bWVudCBhcyBhbiBSRkMsIHBsZWFzZQ0KICAgcmVwbGFjZSBhbGwgb2NjdXJy ZW5jZXMgb2YgUkZDVEJEMTAgd2l0aCBSRkN4eHh4IHdoZXJlIHh4eHggaXMgdGhlDQogICBSRkMg bnVtYmVyIG9mIHRoaXMgZG9jdW1lbnRdDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBXaWxs aWFtIEEuIChBbmR5KSBBZGFtc29uDQogICBOZXRBcHANCiAgIDM2MjkgV2FnbmVyIFJpZGdlIEN0 DQogICBBbm4gQXJib3IsIE1JICA0ODEwMw0KICAgVVNBDQoNCiAgIFBob25lOiArMSA3MzQgNjY1 IDEyMDQNCiAgIEVtYWlsOiBhbmRyb3NAbmV0YXBwLmNvbQ0KDQoNCg0KDQoNCg0KDQpBZGFtc29u ICYgV2lsbGlhbXMgICAgICAgIEV4cGlyZXMgSnVuZSA2LCAyMDE1ICAgICAgICAgICAgICAgICBb UGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBORlN2NCAgICAg ICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIE5pY28gV2lsbGlhbXMNCiAgIGNy eXB0b25lY3Rvci5jb20NCiAgIDEzMTE1IFRhbWF5byBEcg0KICAgQXVzdGluLCBUWCAgNzg3MjkN CiAgIFVTQQ0KDQogICBFbWFpbDogbmljb0BjcnlwdG9uZWN0b3IuY29tDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KQWRhbXNvbiAmIFdpbGxpYW1zICAgICAgICBFeHBpcmVzIEp1bmUg NiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdDQo= --_003_AC5C7128DB5A4CDEBD745B51B5A7E4CFnetappcom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=16; creation-date="Fri, 05 Dec 2014 22:12:28 GMT"; modification-date="Fri, 05 Dec 2014 22:12:28 GMT" Content-ID: <2F742C269868754BB7B690AE74C8168C@hq.netapp.com> Content-Transfer-Encoding: base64 DQo+IA0KPiAtQmVuDQoNCg== --_003_AC5C7128DB5A4CDEBD745B51B5A7E4CFnetappcom_-- From nobody Fri Dec 5 15:14:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EFE1A6FFA for ; Fri, 5 Dec 2014 15:14:03 -0800 (PST) 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 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 ZP1i9vSLKlRm for ; Fri, 5 Dec 2014 15:14:01 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECD71A212D for ; Fri, 5 Dec 2014 15:14:01 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-4e-54823c3848cf 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 dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 94.8A.03326.83C32845; Fri, 5 Dec 2014 18:14:00 -0500 (EST) 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 sB5NDxLO006924; Fri, 5 Dec 2014 18:14:00 -0500 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 sB5NDwIv029425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Dec 2014 18:13:59 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB5NDvYw025595; Fri, 5 Dec 2014 18:13:57 -0500 (EST) Date: Fri, 5 Dec 2014 18:13:57 -0500 (EST) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <5480B9E9.7050205@mit.edu> Message-ID: References: <546F5E3C.1010207@cisco.com> <5480B9E9.7050205@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+NgFnrEIsWRmVeSWpSXmKPExsUixG6nomth0xRisPanksXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8e77P6aCt+wVUxcfZW9gnMbWxcjJISFgIvH1XxcrhC0mceHe eqA4F4eQwGImiVlzdjJCOBsYJZ7eXcgO4Rxkklj54ANYi5BAvcTx67PARrEIaEn86uoGs9kE VCRmvtkIZosIKEr8XvmWEcRmFlCX+HbmDZDNwSEsYC0xb2coSJgTKDz1xClmEJtXwFHizISD bBDjKyWmn3sB1ioqoCOxev8UFogaQYmTM5+wQIzUklg+fRvLBEbBWUhSs5CkFjAyrWKUTcmt 0s1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgKSk5J3h2M7w4qHWIU4GBU4uFdIdEYIsSa WFZcmXuIUZKDSUmU941xU4gQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7k2UDlvCmJlVWpRfkw KWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvBzWQEMFi1LTUyvSMnNKENJMHJwgw3mA hkuB1PAWFyTmFmemQ+RPMSpKifNeswJKCIAkMkrz4HphSeMVozjQK8K8K0CqeIAJB677FdBg JqDBd4tBri4uSURISTUwnv505PE2O0OuOOGKZZ4TXlyKdrmw/cf9uocuES3iNwoOCq+23OOp KPrZ8+Km/zOiFbXcnR4+ypI98Mp1y7tFKumZ+649qN5gsGnDjTWnxZXU49fUKkga3pxye8nh jTJdf6PUpn77szBifiqT31cv3Szpn62m94L/Xqto29XF/ck6s/5eybkPHUosxRmJhlrMRcWJ ANA8Tcr1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/BcWwFajZsre6Tsq0wrTHzAH1HG4 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 23:14:03 -0000 Hi Greg, Thanks for the review. I agree with all the changes/comments, and will address them in the next version. -Ben On Thu, 4 Dec 2014, Greg Hudson wrote: > I found one minor substantive concern: > > * In the example code, check_authz should operate on a gss_name_t, not > a pointer to a gss_name_t. > > I also found some editorial nits: > > * intiator -> initiator (twice, in sections 3.3 and 4.3) > > * GSS_Accpet_sec_context -> GSS_Accept_sec_context (section 4.1) > > * token, for new... -> token for new... (section 4.3) > > * while(!acceptor_established) -> while (!acceptor_established) > (also in the comment at the end of that loop) > > * In section 6, "An application using the GSS-API requests that > certain features (...), but" is either missing a clause or contains an > extra "that". > > * In section 6, "In many cases it is convenient for GSS acceptors to > accept security context..." should either use an article or pluralize > "context". > > From nobody Mon Dec 8 15:39:32 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4991A012D; Mon, 8 Dec 2014 15:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubtyFvoDJFVF; Mon, 8 Dec 2014 15:39:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C2B1A006E; Mon, 8 Dec 2014 15:39:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208233925.734.59432.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 15:39:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rwJJTwHclqKEHwVpaR74HV229y4 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gss-loop-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:39:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Structure of the GSS Negotiation Loop Author : Benjamin Kaduk Filename : draft-ietf-kitten-gss-loop-02.txt Pages : 20 Date : 2014-12-08 Abstract: This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 8 15:49:14 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C854E1A0016 for ; Mon, 8 Dec 2014 15:49:12 -0800 (PST) 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 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 rSZKQ7xJcnTx for ; Mon, 8 Dec 2014 15:49:11 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E2B1A020A for ; Mon, 8 Dec 2014 15:49:11 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-6c-548638f57553 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.92.03354.6F836845; Mon, 8 Dec 2014 18:49:10 -0500 (EST) 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 sB8Nn9hl018738 for ; Mon, 8 Dec 2014 18:49:09 -0500 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 sB8Nn758024197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Dec 2014 18:49:09 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB8Nn7nE003195; Mon, 8 Dec 2014 18:49:07 -0500 (EST) Date: Mon, 8 Dec 2014 18:49:06 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20141208233925.734.59432.idtracker@ietfa.amsl.com> Message-ID: References: <20141208233925.734.59432.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrPvNoi3EYP8WZoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro3nuHcaCj1wVrVveMTUw7uToYuTkkBAwkZi9/A8jhC0mceHe ejYQW0hgMZPE1EkZXYxcQPYxRoln7TCJ60wSLS/jIex6id7e1SwgNouAlsS+Cx+YQGw2ARWJ mW82gtWLCAhL7N76jhnEFhZwluie9QmshlPAQaLhyT+wxbwCjhKrV/9mhphpL/Gu7RJYr6iA jsTq/VNYIGoEJU7OfAJmMwPtWj59G8sERoFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7M y0st0jXRy80s0UtNKd3ECA49Sf4djN8OKh1iFOBgVOLhXfCgJUSINbGsuDL3EKMkB5OSKG+H TluIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe5TtbQ4R4UxIrq1KL8mFS0hwsSuK8m37whQgJ pCeWpGanphakFsFkZTg4lCR455oDDRUsSk1PrUjLzClBSDNxcIIM5wEaXglSw1tckJhbnJkO kT/FqCglzjsVJCEAksgozYPrhaWGV4ziQK8I87IDE4UQDzCtwHW/AhrMBDT4RSLI1cUliQgp qQbGxCdGMk5LcvxiQ4IO/m+cM2lHsNKy384vp7k43nt6Vk0kMceQc0PqQYEfAoXfL5R+nlu5 /YXc5LygH876l88K5C9Tevn8hJzPLZ/Lz3+c9PcsYV18JKpfJP7Ki7pmvcs9ivNF9xf9n/ZF /LXsm5v+Cj9n8lX9C+bZeUKuhO3LtVdK5/X/uy/wVGIpzkg01GIuKk4EAM1QGjnoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RGAtHNTDCLiolqpHSdNdOre67RE Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gss-loop-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:49:12 -0000 On Mon, 8 Dec 2014, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Structure of the GSS Negotiation Loop > Author : Benjamin Kaduk > Filename : draft-ietf-kitten-gss-loop-02.txt > Pages : 20 > Date : 2014-12-08 > > Abstract: > This document specifies the generic structure of the negotiation loop > to establish a GSS security context between initiator and acceptor. > The control flow of the loop is indicated for both parties, including > error conditions, and indications are given for where application- > specific behavior must be specified. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-02 I believe that this addresses all of the comments from Nico and Greg during the WGLC. The scope of the changes seem pretty minor, so I don't think there's a need for another WGLC. -Ben From nobody Tue Dec 9 13:37:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E721A8A76 for ; Tue, 9 Dec 2014 13:36:59 -0800 (PST) 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 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 i0QXOcGTvFdL for ; Tue, 9 Dec 2014 13:36:56 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB3E1A8A78 for ; Tue, 9 Dec 2014 13:36:46 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-25-54876b6dfea2 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DC.50.03365.D6B67845; Tue, 9 Dec 2014 16:36:45 -0500 (EST) 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 sB9LaiW5009330; Tue, 9 Dec 2014 16:36:44 -0500 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 sB9LagSb004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2014 16:36:43 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB9LafwC023763; Tue, 9 Dec 2014 16:36:41 -0500 (EST) Date: Tue, 9 Dec 2014 16:36:41 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141124185114.GM3200@localhost> Message-ID: References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> 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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJub3R5i0LGL2+Lo5lUsFqeuHWFz YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKuPn3DVrBYuuL26vPsDYyzRLsYOTkkBEwk pl15wQZhi0lcuLceyObiEBJYzCSx7MgXRghnA6PEyt/v2CGcg0wS247dZgZpERKolzhx9gIL iM0ioCWxZe0xRhCbTUBFYuabjWBjRQQ0Ja7PWwpmMwsIS6w/NwOsVxgovvPrLdYuRg4OTgE9 iTl9mSBhXgFHif7We1BXXGeUOPfyPitIQlRAR2L1/iksEEWCEidnPmGBmKklsXz6NpYJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERSq7C4qOxibDykd YhTgYFTi4dWwbAsRYk0sK67MPcQoycGkJMr7PLk9RIgvKT+lMiOxOCO+qDQntfgQowQHs5II 71oWoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvyiygRsGi1PTU irTMnBKENBMHJ8hwHqDhK0BqeIsLEnOLM9Mh8qcYFaXEebtBEgIgiYzSPLheWCp5xSgO9Iow 771MoCoeYBqC634FNJgJaPCLxFaQwSWJCCmpBkZb87mujl9kDL5OyT3PeLt6y99Dkv7GJi83 vte9fKrdTVzI32rW4qW8nk6fv/E1i037fEPq5v01h/NvX9Y9NSmP6dyL2b5e4mzBrxb0f5nU +Sj4v/+myE3VZY/P7tTbqu9XdybDiX3jRy3D9TW739Rsy9+45M1219erDk/8FDb1ldjFJ8bT 2n5vVGIpzkg01GIuKk4EACMzbSIAAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/SYxmNAltFhyHn2qeamR_U7i88NA Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 21:36:59 -0000 Some potential tweaks. On Mon, 24 Nov 2014, Nico Williams wrote: > New proposal: > > Section 2.2.4 says: > > o GSS_S_FAILURE indicates that the context is recognized, but that > the GSS_Process_context_token() operation could not be performed > for reasons unspecified at the GSS-API level. > > It should say: > > o GSS_S_FAILURE indicates that the context is recognized, but > either the GSS_Process_context_token() operation could not be > performed for reasons unspecified at the GSS-API level, or the peer > had an error consuming the last context token sent to it (when the I might make the parenthentical be a new sentence, and reword it slightly to: In order for errors from the peer to be conveyed as input context tokens to GSS_Process_context_token() (as opposed to one of the context-establishment calls GSS_Init_sec_context() or GSS_Accept_sec_context()), the local side must already have been fully established but the remote peer's side not established. > local side must have been fully established but the peer hadn't yet > been). In either case the minor status code provides additional > information. > > In the case of successful processing of error tokens, the minor > status code provides information from the input token. The display > string outputs of GSS_Display_status() as applied to such minor > status codes should indicate this, but note that there is no way to "this" is vague. How about "that the error originated on the remote peer, along with the nature of the error"? At this point, the sentence is getting a bit long, so breaking before "but note" and just starting a new sentence with "Note" may be in order. > distinguish failures of GSS_Process_context_token() from error > token information other than to read the human-readable status > display strings. Since status display strings are not machine- > readable, there is no way to programmatically make this > distinction. Again about "this". Perhaps "programmatically distinguish between an error internal to GSS_Process_context_token() and a supplied error token"? > In practice, an unexpected security context token that imediately > follows full security context establishment is very likely a > context token conveying error information rather than a security > context deletion token, especially since the latter are obsoleted. > > Though future GSS-API extensions may add new uses of asynchronous > security context tokens and ways to process them, applications > using the GSS-API version 2, update 1, should generally call > GSS_Delete_sec_context() after calling GSS_Process_context_token(), > when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. > > Applications using transports that may deliver messages out of > order may continue to attempt to process per-message tokens between > calling GSS_Process_context_token() and GSS_Delete_sec_context(), > though there's no guarantee that processing per-message tokens will I have a marginal preference for avoiding contractions in formal documents (i.e., "there is"). > then succeed. > > I hope this addresses all concerns, both Martin's and those arising from > the loop I-D. > > Feel free to propose alternative text. How do you feel about the tidbits above? -Ben From nobody Tue Dec 9 13:55:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C321A01C6 for ; Tue, 9 Dec 2014 13:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW7qokiBbJ0k for ; Tue, 9 Dec 2014 13:55:25 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CAAAB1A002B for ; Tue, 9 Dec 2014 13:55:25 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 68B6843807F; Tue, 9 Dec 2014 13:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Vqg4AfKIrdc/dh +YdOi6D1KDXB4=; b=eqVZHO+CR9F96YGbEnmj+fv8/V+7lgqQg+5ERRzRwBv5GK cy5HdJW6Gmv/Bp7YBh/kEEEn45X2z75BbjuaTN1hI5L2z10ZHzxL802ktdx6VT9g n2j70zVrnvoFuyrsIxnnfkMs/RZob4jYFzmtjjKZWrzwfIbKynR3tYxZuOXlw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 2067B43806C; Tue, 9 Dec 2014 13:55:25 -0800 (PST) Date: Tue, 9 Dec 2014 15:55:24 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141209215519.GI12979@localhost> References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@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: http://mailarchive.ietf.org/arch/msg/kitten/mG0iN9-MIQAhkXya6eo7H_tOEI4 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 21:55:27 -0000 On Tue, Dec 09, 2014 at 04:36:41PM -0500, Benjamin Kaduk wrote: > On Mon, 24 Nov 2014, Nico Williams wrote: > > It should say: > > > > o GSS_S_FAILURE indicates that the context is recognized, but > > either the GSS_Process_context_token() operation could not be > > performed for reasons unspecified at the GSS-API level, or the peer > > had an error consuming the last context token sent to it (when the > > I might make the parenthentical be a new sentence, Maybe. > [...], and reword it slightly > to: This is just the re-write of the parenthetical? > In order for errors from the peer to be conveyed as input context tokens > to GSS_Process_context_token() (as opposed to one of the > context-establishment calls GSS_Init_sec_context() or > GSS_Accept_sec_context()), the local side must already have been fully > established but the remote peer's side not established. How about: [...], or the peer had an error consuming the last context token sent to it. [insert here] The latter occurs when the local side became fully established upon producing one last context token that then triggered an error on the remote peer. In either case the minor status code... > > local side must have been fully established but the peer hadn't yet > > been). In either case the minor status code provides additional > > information. > > > > In the case of successful processing of error tokens, the minor > > status code provides information from the input token. The display > > string outputs of GSS_Display_status() as applied to such minor > > status codes should indicate this, but note that there is no way to > > "this" is vague. How about "that the error originated on the remote peer, > along with the nature of the error"? Agreed. > At this point, the sentence is getting a bit long, so breaking before "but > note" and just starting a new sentence with "Note" may be in order. Agreed. > > distinguish failures of GSS_Process_context_token() from error > > token information other than to read the human-readable status > > display strings. Since status display strings are not machine- > > readable, there is no way to programmatically make this > > distinction. > > Again about "this". Well, the following word ('distinction') relates to the previous sentence's 'distinguish', so I think it's safe. We could just... remove that last sentence and be done: it adds nothing[*]. [*] So why did I write it in the first place? Nico -- From nobody Tue Dec 9 14:15:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6891A0119 for ; Tue, 9 Dec 2014 14:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i265KRTyR0iY for ; Tue, 9 Dec 2014 14:14:59 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5BE1A0166 for ; Tue, 9 Dec 2014 14:14:58 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-68-54877461feaa 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 dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id DA.E4.03326.16477845; Tue, 9 Dec 2014 17:14:57 -0500 (EST) 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 sB9MEuVt014631; Tue, 9 Dec 2014 17:14:57 -0500 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 sB9MEsgX022106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2014 17:14:56 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB9MEsdd000070; Tue, 9 Dec 2014 17:14:54 -0500 (EST) Date: Tue, 9 Dec 2014 17:14:53 -0500 (EST) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <5C562C9B-4421-4CB1-9F5D-E354AE2C0104@openfortress.nl> Message-ID: References: <5C562C9B-4421-4CB1-9F5D-E354AE2C0104@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1474860353-1418163036=:23489" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixCmqrJtY0h5icLxD1+Lo5lUsFk9f3WNz YPJYsuQnk8eGf01sAUxRXDYpqTmZZalF+nYJXBn3DxUUXBeq6H5xl6mBcRJ/FyMnh4SAicSs uXvZIGwxiQv31gPZXBxCAouZJDo7NzBBOBsYJRb8nMcK4RxkkvjT94IRpEVIoF7i1P+nYO0s AloSj98+ZQex2QRUJGa+2QgWFxHQkPj8ayqYzSwgLLH+3AxmEFtYwEHi7IJVYDangLPE6oWX WUFsXgFHiRsPfjBBzHeSaGl6CrZLVEBHYvX+KSwQNYISJ2c+YYGYGSixZH8LE4TtKPFv3y2m CYxCs5CUzUJSNgtJGYStI3FzxmI2CFtb4v7NNjaYmiW/97IuYGRbxSibklulm5uYmVOcmqxb nJyYl5dapGusl5tZopeaUrqJERwhknw7GL8eVDrEKMDBqMTDq2HZFiLEmlhWXJl7iFGSg0lJ lPd5cnuIEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHetSxAOd6UxMqq1KJ8mJQ0B4uSOO+mH3wh QgLpiSWp2ampBalFMFkZDg4lCV6dYqBGwaLU9NSKtMycEoQ0EwcnyHAeoOExIDW8xQWJucWZ 6RD5U4yKUuK8biAJAZBERmkeXC8sgb1iFAd6RZi3CaSKB5j84LpfAQ1mAhr8IrEVZHBJIkJK qoGx0j8sbfmO0m8q8fWMN2+yCieuNUhLWVi/JS1yysRmGabF/67b1nBbNe/PtEm+3pno/lR0 b7Gh+oaS3Zqun4P+S6y8UiFR1dYc6ch704PTjmdb17TbJllnbnGaa3cvaFzb6z3pgiOTfNX0 sOl/s9V0+5P2ac9RvVJ+3V3WUeeQn0KI/c1qfyWW4oxEQy3mouJEAE/Yp4s7AwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/BJBNU3RCCOr9BO6EkK-jVaE7UQE Cc: kitten@ietf.org Subject: Re: [kitten] Draft Action: draft-vanrein-dnstxt-krb1-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 22:15:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1474860353-1418163036=:23489 Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Mon, 17 Nov 2014, Rick van Rein wrote: > Hello, > > Thanks all for your feedback on the DNS TXT proposal for Kerberos realm n= ames. I=A2ve used it for > http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-01 > > CHANGES FROM 00 TO 01: > * Introduced KREALM RRtype to replace overloading of the TXT RRtype > * Switched from an ASCII grammar to an ASN.1 grammar for KREALM RDATA > * Switched from case-independent ASCII values to full UTF8String values > * Proposed base64 representation in master files for KREALM RDATA > > I switched to an ASN.1 format that is easier to process by Kerberos, as w= ell as to give structure. > Entry in master zone files would be as base64, which is clearly non-optim= al, but parsing text isn=A2t either. > I don=A2t know what=A2s best here, I suppose it=A2s a matter of taste. > > As before, feedback is welcome :) and I will also forward it to DNS lists= this time. I did a fairly quick read and did not spend a whole lot of time trying to process everything. My "big-picture" takeaways: The utility of the concept of a "Home Record" (and related) is not clear to me. It seems the document could be shorter if it didn't bother with a distinction, and I'm not sure what would be lost if it did. This is not to say "you should remove them", but if you want to keep them, please help the reader understand why they are there :) The general structure seems like a reasonable chunk to bite off at once, handling a bit more than just realm names, and providing a reasonable mechanism for future extension. It does read more like a DNS document than a Kerberos one, so I wonder if that should be the primary forum for discussion, with consultations to kitten as needed. I don't really see anything to mitigate the previous criticisms regarding the use of the zone apex as a fallback (regarding the potential lack of a relationship between the zone cut and Kerberos administrative boundaries). -Ben ---559023410-1474860353-1418163036=:23489-- From nobody Tue Dec 9 16:03:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B851A6EF2 for ; Tue, 9 Dec 2014 16:03:00 -0800 (PST) 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 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 tEe18ylNuuVN for ; Tue, 9 Dec 2014 16:02:58 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887B11A6EF1 for ; Tue, 9 Dec 2014 16:02:58 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-10-54878db1bcad 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 16.2A.03365.1BD87845; Tue, 9 Dec 2014 19:02:57 -0500 (EST) 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 sBA02uCh025349; Tue, 9 Dec 2014 19:02:57 -0500 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 sBA02sUU023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2014 19:02:56 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBA02src017056; Tue, 9 Dec 2014 19:02:54 -0500 (EST) Date: Tue, 9 Dec 2014 19:02:54 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141209215519.GI12979@localhost> Message-ID: References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> 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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrLuxtz3E4OABEYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4/iauYIV0xY9eywbG18JdjJwcEgImEl3n v7FD2GISF+6tZ+ti5OIQEljMJHFjwjFmCGcDo8T1q2uhnINMEosO/QFrERKol9jw6AYziM0i oCXx9dFURhCbTUBFYuabjWwgtoiApsT1eUvBbGYBYYn152aA1QsDxXd+vcUKYnMK6Etce3ke zOYVcJT41byWFWLZJiaJvZ86mEASogI6Eqv3T2GBKBKUODnzCQvEUC2J5dO3sUxgFJyFJDUL SWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoEBld1HZwdh8SOkQowAH oxIPr4ZlW4gQa2JZcWXuIUZJDiYlUd4rNe0hQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR417IA 5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHhX9AA1ChalpqdWpGXm lCCkmTg4QYbzAA13BqnhLS5IzC3OTIfIn2JUlBLnNQJJCIAkMkrz4HphieQVozjQK8K81iBV PMAkBNf9CmgwE9DgF4mtIINLEhFSUg2MFeo/LNaKtqoF/Vlwq3wbj96EOe9D11Y1cRkfu/0u w6jaujDoxTQnqalq/ILOj0uTGwSC5fRTFzFtd1y45t9lLVXeAm+7nescFd5fNXPZdfgH2/m+ Q07MD95eVynZ8LtFY0bZs2DG388i3r0vZPcSnjlDbMa+Ou3Wm4pfVOK6Zjyx5Bc6uLhBiaU4 I9FQi7moOBEAFjxu0v8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wIn550aKzUv2Mn3ko9hcU4JuQLs Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:03:00 -0000 On Tue, 9 Dec 2014, Nico Williams wrote: > On Tue, Dec 09, 2014 at 04:36:41PM -0500, Benjamin Kaduk wrote: > > On Mon, 24 Nov 2014, Nico Williams wrote: > > > It should say: > > > > > > o GSS_S_FAILURE indicates that the context is recognized, but > > > either the GSS_Process_context_token() operation could not be > > > performed for reasons unspecified at the GSS-API level, or the peer > > > had an error consuming the last context token sent to it (when the > > > > I might make the parenthentical be a new sentence, > > Maybe. > > > [...], and reword it slightly > > to: > > This is just the re-write of the parenthetical? Correct. (It's a bit long for such a re-write.) > > In order for errors from the peer to be conveyed as input context tokens > > to GSS_Process_context_token() (as opposed to one of the > > context-establishment calls GSS_Init_sec_context() or > > GSS_Accept_sec_context()), the local side must already have been fully > > established but the remote peer's side not established. > > How about: > [...], or the peer > had an error consuming the last context token sent to it. [insert here] > > The latter > occurs when the local side became fully established upon producing > one last context token that then triggered an error on the remote > peer. In either case the minor status code... That's better than mine, but probably still has some room for tweaking. Just throwing something out there: The latter occurs when the local side became fully established and produced one last context token which was sent to the peer, but the peer encountered an error while processing that last context token. > > > local side must have been fully established but the peer hadn't yet > > > been). In either case the minor status code provides additional > > > information. > > > > > > In the case of successful processing of error tokens, the minor > > > status code provides information from the input token. The display > > > string outputs of GSS_Display_status() as applied to such minor > > > status codes should indicate this, but note that there is no way to > > > > "this" is vague. How about "that the error originated on the remote peer, > > along with the nature of the error"? > > Agreed. > > > At this point, the sentence is getting a bit long, so breaking before "but > > note" and just starting a new sentence with "Note" may be in order. > > Agreed. > > > > distinguish failures of GSS_Process_context_token() from error > > > token information other than to read the human-readable status > > > display strings. Since status display strings are not machine- > > > readable, there is no way to programmatically make this > > > distinction. > > > > Again about "this". > > Well, the following word ('distinction') relates to the previous > sentence's 'distinguish', so I think it's safe. We could just... remove > that last sentence and be done: it adds nothing[*]. I think I would be okay with that. > [*] So why did I write it in the first place? I don't know :) Once we nail down the text about why the peer would be producing an error token, I can turn this into a new erratum candidate text. -Ben From nobody Tue Dec 9 16:24:53 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0F1A0318 for ; Tue, 9 Dec 2014 16:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3owW3xesQMA for ; Tue, 9 Dec 2014 16:24:47 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDE21A0250 for ; Tue, 9 Dec 2014 16:24:47 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 995F1584064; Tue, 9 Dec 2014 16:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=H0lagi0OksmFt8 RldS/02nQ/gUQ=; b=MNvJCnreBUyoNAZxuNISxaVfrw0zsfZ74OoYxK5Dm3jbec O+mU16zKZQ/lMhhSovvm8OkvBxZGnx6wKJMSAxncXUpvNxAfdanblO5iudULYGRD ntQzCH9hT2d07qASonsg4YCnzOwucrFT2lDH+RUhsu90RXK+hwut590zDh4S4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 4E0FC584057; Tue, 9 Dec 2014 16:24:46 -0800 (PST) Date: Tue, 9 Dec 2014 18:24:45 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141210002441.GP12979@localhost> References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@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: http://mailarchive.ietf.org/arch/msg/kitten/wNP8hJwqYE-6BY0ApePvBLYHVdQ Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:24:47 -0000 On Tue, Dec 09, 2014 at 07:02:54PM -0500, Benjamin Kaduk wrote: > On Tue, 9 Dec 2014, Nico Williams wrote: > > The latter occurs when the local side became fully established and > produced one last context token which was sent to the peer, but the peer > encountered an error while processing that last context token. Sold. From nobody Wed Dec 10 10:58:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82D51A8A9B for ; Wed, 10 Dec 2014 10:58:01 -0800 (PST) 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 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 kzUn0p4ftnTp for ; Wed, 10 Dec 2014 10:57:55 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263581A8A87 for ; Wed, 10 Dec 2014 10:57:55 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-f1-548897b1c388 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 84.43.03365.2B798845; Wed, 10 Dec 2014 13:57:54 -0500 (EST) 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 sBAIvrHU006976; Wed, 10 Dec 2014 13:57:53 -0500 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 sBAIvpeF010768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Dec 2014 13:57:52 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBAIvpLh020336; Wed, 10 Dec 2014 13:57:51 -0500 (EST) Date: Wed, 10 Dec 2014 13:57:50 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141210002441.GP12979@localhost> Message-ID: References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> 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+NgFnrDIsWRmVeSWpSXmKPExsUixG6nortpekeIwd1mZoujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4cHQzc8FskYonC/6wNDDe4u9i5OCQEDCR uNDr1sXICWSKSVy4t56ti5GLQ0hgMZPE8vP/WSGcjYwSv3bvYYJwDjFJzP1zGCrTwCjx7eh1 ZpBRLALaEreOuIOMYhNQkZj5ZiMbiC0ioClxfd5SMJtZQFhi/bkZzCC2MFB859dbrCCtnAL6 Eotu1oOEeQUcJb7/Pwy1q5tZYuutw2D1ogI6Eqv3T2GBKBKUODnzCQvETC2J5dO3sUxgFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2M4EB1UdnB2HxI6RCj AAejEg9vwOX2ECHWxLLiytxDjJIcTEqivLundoQI8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE9 Mxkox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwWs6DahRsCg1PbUi LTOnBCHNxMEJMpwHaHg6SA1vcUFibnFmOkT+FKOilDjvX5CLBEASGaV5cL2wRPKKURzoFWHe DJB2HmASgut+BTSYCWjwi8RWkMEliQgpqQZGNddMpn1d15j25qcWSkhXHXOUPOXR1vtBP7f+ 5F6PpY13K5uWromdZ8nzsVT85Vkn61jHPzFzJCOsF+6S7J5zfeckdx9LsW9v+tQm/p1+xj/m 7fmAZ11fxacV62Y5HWIQL/PeGtuU+FUgi/HdPxYLp1mvzG94i5VYnt0euu29WtQbblX95AdK LMUZiYZazEXFiQDlL6O+/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OZ_0cWG5Yw6ZgJSGWezJToxJU4w Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 18:58:01 -0000 On Tue, 9 Dec 2014, Nico Williams wrote: > Sold. Okay, so now we're looking at: ====================================================== Section 2.2.4 says: o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Process_context_token() operation could not be performed for reasons unspecified at the GSS-API level. It should say: o GSS_S_FAILURE indicates that the context is recognized, but either the GSS_Process_context_token() operation could not be performed for reasons unspecified at the GSS-API level, or the peer had an error consuming the last context token sent to it. The latter occurs when the local side became fully established and produced one last token which was sent to the peer, but the peer encountered an error while processing that last context token. In either case the minor status code provides additional information. In the case of successful processing of error tokens, the minor status code provides information from the input token. The display string outputs of GSS_Display_status() as applied to such minor status codes should indicate that the error originated on the remote peer, along with the nature of the error. Note that there is no way to distinguish failures of GSS_Process_context_token() from error token information other than to read the human-readable status display strings. In practice, an unexpected security context token that imediately follows full security context establishment is very likely a context token conveying error information rather than a security context deletion token, especially since the latter are obsoleted. Though future GSS-API extensions may add new uses of asynchronous security context tokens and ways to process them, applications using the GSS-API version 2, update 1, should generally call GSS_Delete_sec_context() after calling GSS_Process_context_token(), when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. Applications using transports that may deliver messages out of order may continue to attempt to process per-message tokens between calling GSS_Process_context_token() and GSS_Delete_sec_context(), though there is no guarantee that processing per-message tokens will then succeed. ====================================================== It would be good to hear comments from people other than Nico and I. (Martin? Greg?) -Ben From nobody Sat Dec 13 19:54:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE01A1EE9 for ; Sat, 13 Dec 2014 19:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBQt-ONCWjRB for ; Sat, 13 Dec 2014 19:53:58 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4DB1A1A68 for ; Sat, 13 Dec 2014 19:53:58 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-e1-548d09d41e5e 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id EC.12.03354.5D90D845; Sat, 13 Dec 2014 22:53:57 -0500 (EST) 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 sBE3ruFi032462; Sat, 13 Dec 2014 22:53:56 -0500 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 sBE3rsFT022164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Dec 2014 22:53:55 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBE3rrpX012268; Sat, 13 Dec 2014 22:53:53 -0500 (EST) Date: Sat, 13 Dec 2014 22:53:53 -0500 (EST) 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+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrHuVszfEYM0JZotDF44zWhzdvIrF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mo4+VOw4AR7xcur/cwNjBPYuhg5OSQETCSW Hz7JDmGLSVy4tx4ozsUhJLCYSWLmwX4WCGcjo8Tmr7vBqoQEDjFJHHzODJFoYJTof9HBCJJg EdCWuLDtKBOIzSagIjHzzUawFSICwhK7t75jBrGZBRQkNvfvBRrEwSEs4Cpx8Zg5SJhTwEni UtcDsHJeAUeJDU2roXY5Skz6vwVspKiAjsTq/VNYIGoEJU7OfMICMVJLYvn0bSwTGAVnIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQTIzhMJfl3MH47qHSIUYCD UYmH16K3O0SINbGsuDL3EKMkB5OSKG/Fo54QIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8fd+B crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErwFHL0hQoJFqempFWmZ OSUIaSYOTpDhPEDDd4DU8BYXJOYWZ6ZD5E8x6nIsaN8/k0mIJS8/L1VKnHcFSJEASFFGaR7c HFh6ecUoDvSWMO89kCoeYGqCm/QKaAkT0JLLjCAfFJckIqSkGhgteKbnnFkT1ZPd9zf5+Yrp vQV+DhZSh8U+zV6m+2QSz/+5NtKrWL38N68wUpyyxPtn+C3p5KZLpUd0pvzjey7kXXNKJ37j sTVvnpcufPBocfbFw4un2Zj6rN9TsO/egdLurRJ3jFK2+/y/w31n46q9SRnsx56u3ZvxpvXB icTAZ4G7H/g8eblqnRJLcUaioRZzUXEiAAN/+4MKAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/XQGNTintYcnvdj0mK01nirT_4ZI Cc: kitten-chairs@tools.ietf.org Subject: Re: [kitten] Call for Adoption: draft-short-pkinit-freshness X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 03:54:05 -0000 Just a reminder: the period for comments is more than halfway over. Thanks to Bill for replying, and I believe that we also heard from Greg and Nico in support of adoption in previous threads on the draft. Greg and Nico, if that's wrong, please correct me. -Ben On Mon, 1 Dec 2014, Benjamin Kaduk wrote: > The chairs are considering adopting draft-short-pkinit-freshness [0] as a > kitten draft. We would like to solicit comments on whether to adopt this > draft. Since it updates RFC 4556, it seems clear that it needs to be > standards-track, but feel free to comment on that as well, if you wish. > > Please submit comments by December 19th, 2014, either to the chairs or to > the list. > > -Ben, for the kitten co-chairs > > [0] https://tools.ietf.org/html/draft-short-pkinit-freshness-00 > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Sun Dec 14 13:50:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8EA1A01F6 for ; Sun, 14 Dec 2014 13:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_Z8BN0QejZT for ; Sun, 14 Dec 2014 13:50:34 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812091A0196 for ; Sun, 14 Dec 2014 13:50:34 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBELoXe4006523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 14 Dec 2014 16:50:33 -0500 Received: from willson.usersys.redhat.com ([10.3.113.5]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBELoUrZ015898 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Sun, 14 Dec 2014 16:50:31 -0500 Date: Sun, 14 Dec 2014 16:50:30 -0500 From: Simo Sorce To: Benjamin Kaduk Message-ID: <20141214165030.55a4d0ed@willson.usersys.redhat.com> In-Reply-To: References: Organization: Red Hat, Inc MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/q7bCl7TG4qufWYG4Xj6DlKHhT7I Cc: kitten@ietf.org, kitten-chairs@tools.ietf.org Subject: Re: [kitten] Call for Adoption: draft-short-pkinit-freshness X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 21:50:37 -0000 On Sat, 13 Dec 2014 22:53:53 -0500 (EST) Benjamin Kaduk wrote: > Just a reminder: the period for comments is more than halfway over. > > Thanks to Bill for replying, and I believe that we also heard from > Greg and Nico in support of adoption in previous threads on the > draft. Greg and Nico, if that's wrong, please correct me. I also agree we should adopt this draft. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Dec 15 00:18:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5961A1A47 for ; Mon, 15 Dec 2014 00:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPOLOE72oPgI for ; Mon, 15 Dec 2014 00:18:52 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204F61A1A28 for ; Mon, 15 Dec 2014 00:18:52 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so8715157lbi.18 for ; Mon, 15 Dec 2014 00:18:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CICm3cii8m+FXdTgnpAfo3P30M36ED5KE32dyTBg9y0=; b=On8ZD+bcC2E4ykb0RJr4jMV7WVi6daBoMKZzDgNqeNhFXBZqCTly5L2WapjCk6v3iU 0XusAMlIEYWVaHS8OSflTlwR5QIPstnY2v/5zmOSOAm1DbKCoguJmYRpO2vWrUdZYC4U Im7ZwrqjoHk9UE6OQGaIsa05xhjIvBqDdgC33dOIahcPqz1KkQKm7znrCcLhmME6BMvc nzojlRAnpU6bTO7dBPuzK4JVZuXonTmeP9RqFrQ7Vj5NJoz6ju1zjwX4ONWjIYmL1lVr ZYxvWFsxm2iK+xNEnzo59BJdpcsVxTHsfXEZXpw7VO71kt5NjRrVA6kT6nYFJelA0c9Z YNJA== X-Gm-Message-State: ALoCoQlvlbg4NkptKQzPrN47cECUxf+k1z2ljcrbWEABG5D68TGUMB1piEdYu//zDzFq4p8ddBaM X-Received: by 10.112.85.11 with SMTP id d11mr29013770lbz.100.1418631530657; Mon, 15 Dec 2014 00:18:50 -0800 (PST) Received: from [192.168.50.183] (scandic804.host.songnetworks.se. [212.214.188.34]) by mx.google.com with ESMTPSA id h7sm2492901lbl.41.2014.12.15.00.18.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 00:18:49 -0800 (PST) Message-ID: <548E9968.9060607@mnt.se> Date: Mon, 15 Dec 2014 09:18:48 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: kitten@ietf.org References: <20141214165030.55a4d0ed@willson.usersys.redhat.com> In-Reply-To: <20141214165030.55a4d0ed@willson.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/95YG66TgIrEJajUuLKgBXTNQ_OI Subject: Re: [kitten] Call for Adoption: draft-short-pkinit-freshness X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 08:18:54 -0000 On 12/14/2014 10:50 PM, Simo Sorce wrote: > On Sat, 13 Dec 2014 22:53:53 -0500 (EST) > Benjamin Kaduk wrote: > >> Just a reminder: the period for comments is more than halfway over. >> >> Thanks to Bill for replying, and I believe that we also heard from >> Greg and Nico in support of adoption in previous threads on the >> draft. Greg and Nico, if that's wrong, please correct me. > > I also agree we should adopt this draft. > > Simo. > FWIW so do I. From nobody Mon Dec 15 09:14:39 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DB91A86EA for ; Mon, 15 Dec 2014 09:14:37 -0800 (PST) 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 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 cvw4iHY5do30 for ; Mon, 15 Dec 2014 09:14:35 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7727D1A86FC for ; Mon, 15 Dec 2014 09:14:35 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-8e-548f16fa6bb7 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id CE.79.03365.AF61F845; Mon, 15 Dec 2014 12:14:34 -0500 (EST) 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 sBFHEXGP030016; Mon, 15 Dec 2014 12:14:33 -0500 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 sBFHEVCj026643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Dec 2014 12:14:33 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBFHEULl004221; Mon, 15 Dec 2014 12:14:30 -0500 (EST) Date: Mon, 15 Dec 2014 12:14:30 -0500 (EST) 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+NgFrrKIsWRmVeSWpSXmKPExsUixG6novtLrD/E4O1uEYtDF44zWhzdvIrF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mr4+/U2a8FvzoquC9OYGhgnc3QxcnBICJhI TJ5T28XICWSKSVy4t56ti5GLQ0hgMZPE4oPnmCCcjYwSmx/+gnIOMUk0XWpnhHAaGCXeTZnA CtLPIqAtsfnEWTCbTUBFYuabjWwgtoiAsMTure+YQWxmAQWJzf172UFsYQEDiWXtf8DqeQUc JQ5N+MECYosK6Eis3j+FBSIuKHFy5hMWiF4tieXTt7FMYOSfhSQ1C0lqASPTKkbZlNwq3dzE zJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjODQc1HZwdh8SOkQowAHoxIPbwRjX4gQa2JZcWXu IUZJDiYlUV5m/v4QIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8s94BlfOmJFZWpRblw6SkOViU xHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfC+FwUaKliUmp5akZaZU4KQZuLgBBnOAzT8LkgN b3FBYm5xZjpE/hSjopQ47xaQhABIIqM0D64XlhpeMYoDvSLMywdMFEI8wLQC1/0KaDAT0ODL jD0gg0sSEVJSDYxCdlc2Lt8Ymz2V8de8/P1Tnbr0mytaVVTn1uqtSTHKk38/uW5i6sVlebJ7 z0Xu0inVrJ20NnHReVURh/6P2R2K2uyJuikynh9XTOwtcZyn6vj10IZdP3Y8PqIZtfbL33P6 10oe/4qa2rwt5jNfv11p7jr+q/aLdJZtcw5uvKBuYee34QR/w0QlluKMREMt5qLiRAD9qbPB 6AIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/0Pg8T0cXkqjq09YSZbUCODTFsc4 Cc: kitten-chairs@tools.ietf.org Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:14:37 -0000 This message begins the fourth Working Group Last Call (WGLC) of "A set of SASL Mechanisms for OAuth" . Due to the overlap of the last call period with holidays, the duration of the WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. The draft is available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 Because the changes between -15 and -18 involve behavior changes, including changes regarding discovery and dynamic registration, the Chairs decided to issue an additional last call. Please review the document and send comments to the Working Group mailing list < kitten at itef.org > or the co-chairs < kitten-chairs at tools.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 Mon Dec 15 09:20:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48E51A8706 for ; Mon, 15 Dec 2014 09:20:40 -0800 (PST) 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 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 O7vVObKs3EnU for ; Mon, 15 Dec 2014 09:20:39 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9B01A8704 for ; Mon, 15 Dec 2014 09:20:39 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-f2-548f18660eb4 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 9C.F9.03365.6681F845; Mon, 15 Dec 2014 12:20:38 -0500 (EST) 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 sBFHKWPg031387; Mon, 15 Dec 2014 12:20:32 -0500 Received: from [18.101.8.106] (vpn-18-101-8-106.mit.edu [18.101.8.106]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBFHKU6T028709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Dec 2014 12:20:31 -0500 Message-ID: <548F185E.70701@mit.edu> Date: Mon, 15 Dec 2014 12:20:30 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benjamin Kaduk , Nico Williams References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1k2T6A8x6DwqZnF08yoWi1PXjrA5 MHm8PHWO0WPJkp9MAUxRXDYpqTmZZalF+nYJXBk/9j5mLjjDVnHk9QGWBsbVrF2MnBwSAiYS 1ycsYoKwxSQu3FvP1sXIxSEksJhJ4sXzHlYIZyOjxNkZ15ggnCNMEncPPGIHaeEVUJHYfeMj G4jNIqAqcfvYHbCxbALKEuv3b2XpYuTgEBUIk5i6lAeiXFDi5MwnYGERAU+JD9ONQMLMAsIS F7bvBesUFtCU2Pn1FtTe/cwSGzb9ZARJcAo4SfQ8+sII0aAnseP6L1YIW15i+9s5zBMYBWch WTELSdksJGULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBAUwu4vKDsbm Q0qHGAU4GJV4eCMY+0KEWBPLiitzDzFKcjApifIy8/eHCPEl5adUZiQWZ8QXleakFh9ilOBg VhLhnfUOqJw3JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYK3RRxoqGBR anpqRVpmTglCmomDE2Q4D9DwfSA1vMUFibnFmekQ+VOMuhwL2vfPZBJiycvPS5US550DUiQA UpRRmgc3B5Z4XjGKA70lzHsWpIoHmLTgJr0CWsIEtOQyYw/IkpJEhJRUA+OsVd38c3zadrcI THDruNpxeZXVzynTb6pv+sHW9oyH02N/4IvyOIebRxQ7L0ysvvMss8X/jE6rm6+zumxY5cyV M6NtWpmW3t+6qDbt5EMrps5DWg1sveyvQqY1PV2+2zbrjraR9Mway3NCt/8t6o8vCpFS/Rm3 1yp95q9JPU+nbphutuCQt40SS3FGoqEWc1FxIgD3arjKFwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Fnd2pxGlWTtrqi_QvUh3eMl8ooI Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:20:41 -0000 On 12/10/2014 01:57 PM, Benjamin Kaduk wrote: > Though future GSS-API extensions may add new uses of asynchronous > security context tokens and ways to process them, applications > using the GSS-API version 2, update 1, should generally call > GSS_Delete_sec_context() after calling GSS_Process_context_token(), > when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. I don't like the wording of this part. Encouraging applications to assume that context tokens destroy the context essentially closes the door to specifying context tokens which don't. (To be clear: saying that applications must eventually call GSS_Delete_sec_context() is fine; saying that they should do so immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is not fine.) Otherwise the new text looks good. From nobody Mon Dec 15 09:50:43 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979661A86EB for ; Mon, 15 Dec 2014 09:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLH3C0elcOaI for ; Mon, 15 Dec 2014 09:50:39 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B5A271A86E9 for ; Mon, 15 Dec 2014 09:50:39 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 7F36654073; Mon, 15 Dec 2014 09:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BS1+SSShIEGY9r Kbaru73msJElg=; b=iGllqY4HvhKemKvIFQ1Q7jrO2fiYnltkQ3brd7WCjXSH9g k8ISPmYPIGAvmOmH1eFdHTZnWDaO+akjT5x/rrR4N5VPTm9ndOgpTA0cVwKM0W5v N8CVTo7r0MBO5wW/U3bjIny7HGJWmL2twqtYRIpUA52snGMxfRYBanfxcdYY0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id DF3805406F; Mon, 15 Dec 2014 09:50:38 -0800 (PST) Date: Mon, 15 Dec 2014 11:50:38 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141215175033.GF3241@localhost> References: <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F185E.70701@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Ixw8wp9upfXlC-VeIELTg6Jy8cw Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:50:40 -0000 On Mon, Dec 15, 2014 at 12:20:30PM -0500, Greg Hudson wrote: > On 12/10/2014 01:57 PM, Benjamin Kaduk wrote: > > Though future GSS-API extensions may add new uses of asynchronous > > security context tokens and ways to process them, applications > > using the GSS-API version 2, update 1, should generally call > > GSS_Delete_sec_context() after calling GSS_Process_context_token(), > > when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. > > I don't like the wording of this part. Encouraging applications to > assume that context tokens destroy the context essentially closes the > door to specifying context tokens which don't. > > (To be clear: saying that applications must eventually call > GSS_Delete_sec_context() is fine; saying that they should do so > immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is > not fine.) GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before calling GSS_Delete_sec_context(), however, as it is today processing an async context token does mean that the other peer cannot continue. Therefore the caller of GSS_Process_context_token(), while they can continue to process per-msg tokens from the peer, has to get around to calling GSS_Delete_sec_context(). Sure, exiting, crashing, hanging around doing nothing -- these are also options, but not really desirable ones. In v2u1, the peer has indicated that it can't continue, so calling GSS_Wrap() and GSS_GetMIC() does the app no good[**]. Thus the word "generally". It's a bit of a weasel word that captures all of the above possibilities. Thus also the very specific reference to a GSS-API version (v2u1): it's quite true that a GSS-APIv2u1 application could not properly handle a v3 extension that uses async context tokens. What could a v2u1 application possibly do to properly handle such an extension? How could it interpret the major/minor status codes (other than GSS_S_DEFECTIVE_TOKEN) from GSS_Process_context_token() to determine whether the app should continue? If it can't, then how could it decide whether to keep going instead of getting around to calling GSS_Delete_sec_context()? I don't see how a GSS-APIv2u1 application could make that determination. A GSS-APIv2u1 app just has to end up calling GSS_Delete_sec_context() when GSS_Process_context_token() returns either GSS_S_COMPLETE or GSS_S_FAILURE -- and "soon" after, too. [*] Hmmm, should we consider GSS_Pseudo_random() to be part of a v2u2? [**] A vwu1 peer could have done GSS_Export_sec_context(), then imported it twice and then called GSS_Delete_sec_context() on one of them, producing a context deletion token, and sent it, while then continuing to use the second imported version. This would be rather tortured behavior! No app does this. Nico -- From nobody Mon Dec 15 10:10:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBDB1A8718 for ; Mon, 15 Dec 2014 10:09:59 -0800 (PST) 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 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 aazkYgTYSRLZ for ; Mon, 15 Dec 2014 10:09:52 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88051A8712 for ; Mon, 15 Dec 2014 10:09:50 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-b7-548f23edd025 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 15.77.03354.DE32F845; Mon, 15 Dec 2014 13:09:49 -0500 (EST) 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 sBFI9hj4005248; Mon, 15 Dec 2014 13:09:44 -0500 Received: from [18.101.8.106] (vpn-18-101-8-106.mit.edu [18.101.8.106]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBFI9fON014447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Dec 2014 13:09:42 -0500 Message-ID: <548F23E5.1020401@mit.edu> Date: Mon, 15 Dec 2014 13:09:41 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams References: <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <20141215175033.GF3241@localhost> In-Reply-To: <20141215175033.GF3241@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrftWuT/E4PMCdYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4sUmnYK5Qxd1PF9kaGP/wdTFyckgImEi0 v3nPCmGLSVy4t56ti5GLQ0hgMZPE7iWfmSGcjYwSjW+fMUI4R5gkDmz5CZTh4OAVUJOYdccP pJtFQFVi2673TCA2m4CyxPr9W1lASkQFwiSmLuUBCfMKCEqcnPmEBcQWEdCUuD5vKRuIzSxg LHGpZz3YEcJA8Z1fb7FCrLrBLNH4+RoTyBxOAT2JlhNlEPV6Ejuu/2KFsOUlmrfOZp7AKDgL yYpZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyh42V1UdzBO OKR0iFGAg1GJhzeCsS9EiDWxrLgy9xCjJAeTkiivgkJ/iBBfUn5KZUZicUZ8UWlOavEhRgkO ZiURXncZoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvIyWgRsGi 1PTUirTMnBKENBMHJ8hwHqDhJ0FqeIsLEnOLM9Mh8qcYFaXEedeDJARAEhmleXC9sOTyilEc 6BVh3nMgVTzAxATX/QpoMBPQ4MuMPSCDSxIRUlINjJFPT32qSYp6J2MbMcuK/8v2dz8DZtf+ tWz1UuELOs+240t9yrOg6zkadqbpch8mPxE8d/aa8QzF27OjN67uKzhhvU32oM//64qfe+X0 U/Z27FovqjJBe9G8y8bvxR7KXN7xe/K6dRcqXj6u7nq9IUftjG8MvxcT14dfYrXOajyivCsm iyzhtFBiKc5INNRiLipOBADaHirdCQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lQrTgr7BB5p8704Yl9hOjJuKu48 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 18:10:00 -0000 On 12/15/2014 12:50 PM, Nico Williams wrote: >> (To be clear: saying that applications must eventually call >> GSS_Delete_sec_context() is fine; saying that they should do so >> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is >> not fine.) [...] > Therefore the caller of GSS_Process_context_token(), while they can > continue to process per-msg tokens from the peer, has to get around to > calling GSS_Delete_sec_context(). I think I acknowledged above that it must do so eventually (that is, it must not assume that calling GSS_Process_context token discharged its responsibility to release the context, despite the lack of a GSS_Delete_sec_context call by the client in the RFC 2743 section 1 narrative). > In v2u1, the peer has indicated that it can't continue, so > calling GSS_Wrap() and GSS_GetMIC() does the app no good[**]. I don't think that is really specified in RFC 2743. Section 2.2.4 says "one use..." and then "another use..." but doesn't say that's a comprehensive list of context token types. If the authors had intended for these two uses to be a comprehensive list, I would have expected more specific language than "impact on context-level state information" in the preceding sentence. > Thus also the very specific reference to a GSS-API version (v2u1): it's > quite true that a GSS-APIv2u1 application could not properly handle a v3 > extension that uses async context tokens. What could a v2u1 application > possibly do to properly handle such an extension? How could it interpret > the major/minor status codes (other than GSS_S_DEFECTIVE_TOKEN) from > GSS_Process_context_token() to determine whether the app should > continue? If it can't, then how could it decide whether to keep going > instead of getting around to calling GSS_Delete_sec_context()? It can try to keep going, and terminate the context when it runs into an error or a transport-level or application-level closure. I think this is the right behavior to encourage given the text in RFC 2743. > A GSS-APIv2u1 app just has to end up calling GSS_Delete_sec_context() > when GSS_Process_context_token() returns either GSS_S_COMPLETE or > GSS_S_FAILURE -- and "soon" after, too. I don't see a compelling reason to encourage doing so "soon" after a GSS_S_COMPLETE. From nobody Mon Dec 15 10:25:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC88B1A8725 for ; Mon, 15 Dec 2014 10:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TB836uMmBnb for ; Mon, 15 Dec 2014 10:25:08 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BD9141A8722 for ; Mon, 15 Dec 2014 10:25:08 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6A76B2F4075; Mon, 15 Dec 2014 10:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5YJ2eUOghFp6ZL /9zbeAaxfNqmc=; b=cQh0hMaLvm9NOQBavoRP29BLei6scYXjqZliVh1q2BZvel ReUavDKqoV+40FKci7GHa5oYFLaWGup6+g07A02txtEHAxsJ3HHxBU08Z4U8qXnf q85qTQridNfHyechY/Eo44AG5GEdzo7LovCgkK9coNG29doNK0t/ppH/1Ncl0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 164032F406D; Mon, 15 Dec 2014 10:25:08 -0800 (PST) Date: Mon, 15 Dec 2014 12:25:07 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141215182502.GI3241@localhost> References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <20141215175033.GF3241@localhost> <548F23E5.1020401@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F23E5.1020401@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2qfHS9zYgm30aC8hr7XP2YU2-bM Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 18:25:10 -0000 On Mon, Dec 15, 2014 at 01:09:41PM -0500, Greg Hudson wrote: > On 12/15/2014 12:50 PM, Nico Williams wrote: > >> (To be clear: saying that applications must eventually call > >> GSS_Delete_sec_context() is fine; saying that they should do so > >> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is > >> not fine.) > [...] > > Therefore the caller of GSS_Process_context_token(), while they can > > continue to process per-msg tokens from the peer, has to get around to > > calling GSS_Delete_sec_context(). > > I think I acknowledged above that it must do so eventually (that is, it > must not assume that calling GSS_Process_context token discharged its > responsibility to release the context, despite the lack of a > GSS_Delete_sec_context call by the client in the RFC 2743 section 1 > narrative). All apps must do so eventually, async context tokens or not. "Eventually" could mean "at the end of time". But here it has a more specific meaning: the "connection" state must be "cleanup", whatever that means to the app. > > In v2u1, the peer has indicated that it can't continue, so > > calling GSS_Wrap() and GSS_GetMIC() does the app no good[**]. > > I don't think that is really specified in RFC 2743. Section 2.2.4 says > "one use..." and then "another use..." but doesn't say that's a > comprehensive list of context token types. If the authors had intended > for these two uses to be a comprehensive list, I would have expected > more specific language than "impact on context-level state information" > in the preceding sentence. By elimination we know that no other outcomes are possible in the v2u1 API. > > Thus also the very specific reference to a GSS-API version (v2u1): it's > > quite true that a GSS-APIv2u1 application could not properly handle a v3 > > extension that uses async context tokens. What could a v2u1 application > > possibly do to properly handle such an extension? How could it interpret > > the major/minor status codes (other than GSS_S_DEFECTIVE_TOKEN) from > > GSS_Process_context_token() to determine whether the app should > > continue? If it can't, then how could it decide whether to keep going > > instead of getting around to calling GSS_Delete_sec_context()? > > It can try to keep going, and terminate the context when it runs into an > error or a transport-level or application-level closure. I think this > is the right behavior to encourage given the text in RFC 2743. But why bother with async context tokens then? I do see an argument for continuing: that an error token might have no integrity protection and the app can't tell, therefore the app should continue just in case. (Indeed, KRB-ERRORs today don't have integrity protection. The krb5 mech could just always return GSS_S_DEFECTIVE_TOKEN when processing unprotected KRB-ERRORs, with the peer-side error captured in the minor status. This could either be required behavior for the mechanism, or locally configurable.) But then, neither would a TCP FIN/RST... unless IPsec or some TCPINC protocol are in use, in which case the possible lack of integrity protection for a GSS error token is irrelevant. There's also no integrity protection for a non-responsive peer. I.e., active attackers can DoS a security context. That's not news though... > > A GSS-APIv2u1 app just has to end up calling GSS_Delete_sec_context() > > when GSS_Process_context_token() returns either GSS_S_COMPLETE or > > GSS_S_FAILURE -- and "soon" after, too. > > I don't see a compelling reason to encourage doing so "soon" after a > GSS_S_COMPLETE. I don't see a compelling reason not to. Again, this is tied to a very specific GSS-API version: v2u1 and all versions until there is an enhancement to the API that uses async context tokens. I don't think there ever will be such an extension. The use case I can think of, re-keying, doesn't really require async context tokens, and has fallen out of favor in the TLS community. There's a whole off-list discussion that would have to get brought on-list to pursue this angle, which I'd like to do eventually. Nico -- From nobody Mon Dec 15 10:38:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82F51A8739 for ; Mon, 15 Dec 2014 10:37:59 -0800 (PST) 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 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 ZTG3id6E59BB for ; Mon, 15 Dec 2014 10:37:58 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40671A872E for ; Mon, 15 Dec 2014 10:37:57 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-09-548f2a844bf2 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 84.90.03365.48A2F845; Mon, 15 Dec 2014 13:37:56 -0500 (EST) 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 sBFIboaX013633; Mon, 15 Dec 2014 13:37:50 -0500 Received: from [18.101.8.106] (vpn-18-101-8-106.mit.edu [18.101.8.106]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBFIbmMI024545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Dec 2014 13:37:49 -0500 Message-ID: <548F2A7B.2040400@mit.edu> Date: Mon, 15 Dec 2014 13:37:47 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <20141215175033.GF3241@localhost> <548F23E5.1020401@mit.edu> <20141215182502.GI3241@localhost> In-Reply-To: <20141215182502.GI3241@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrNui1R9isP+nlMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGX03PrJXLCdu+Ln12ssDYwzObsYOTkkBEwk thw5yQphi0lcuLeeDcQWEljMJLH2IUsXIxeQvZFR4sXlJ8wQzhEmiebmZ2AdvAJqEgvW72Hq YuTgYBFQlbhx1wwkzCagLLF+/1YWkLCoQJjE1KU8ENWCEidnPmEBsUUENCWuz1sKtotZwFji Us96sInCQPGdX2+xQqw6zCzxbu9dRpA5nAJ6Evceu0LU60nsuP6LFcKWl2jeOpt5AqPgLCQr ZiEpm4WkbAEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYyg4GV3UdnB2HxI 6RCjAAejEg9vBGNfiBBrYllxZe4hRkkOJiVRXgWF/hAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK IrzSykA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXitNoEbBotT0 1Iq0zJwShDQTByfIcB6g4VIgNbzFBYm5xZnpEPlTjIpS4rwCIAkBkERGaR5cLyy5vGIUB3pF mHc5SBUPMDHBdb8CGswENPgyYw/I4JJEhJRUA6NUnu7RhXYbdPYLzkq6Hnar2CjHNvLPrfoF 8sVGxz4Lnb9ue2dTYPi+vqyp1qGeGdu+VDvwSM+dsNX5J/eP9818Erc28+18svGG/NHl64Ju ny6ZOmm91erpbamvnd9U2PKH+CeaTnzRtZot9MtBIUtBH8X+R+/Fp1l3yyVvqrh+U2St5fx5 wk1KLMUZiYZazEXFiQAP1Ue9CQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/r33Qmf2YoVme7TdkIF2oBL_mLmA Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 18:38:00 -0000 On 12/15/2014 01:25 PM, Nico Williams wrote: >> I don't think that is really specified in RFC 2743. Section 2.2.4 says >> "one use..." and then "another use..." but doesn't say that's a >> comprehensive list of context token types. If the authors had intended >> for these two uses to be a comprehensive list, I would have expected >> more specific language than "impact on context-level state information" >> in the preceding sentence. > > By elimination we know that no other outcomes are possible in the v2u1 > API. I don't follow this argument, and I think this point is pretty fundamental. >> It can try to keep going, and terminate the context when it runs into an >> error or a transport-level or application-level closure. I think this >> is the right behavior to encourage given the text in RFC 2743. > > But why bother with async context tokens then? To communicate better error information to callers? To support re-keying or other mechanism-specified context tokens which might improve security? > I do see an argument for continuing: that an error token might have no > integrity protection and the app can't tell, therefore the app should > continue just in case. This is not my reasoning; my reasoning is simply that the application has no strong reason to believe that the context has been terminated, and that encouraging applications to make this assumption unnecessarily closes the door to other uses. From nobody Mon Dec 15 11:48:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5516D1A883A for ; Mon, 15 Dec 2014 11:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btUmR_rWSF9d for ; Mon, 15 Dec 2014 11:48:24 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CE5F21A8839 for ; Mon, 15 Dec 2014 11:48:09 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 916F52C806B; Mon, 15 Dec 2014 11:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bmz5D720JIvZEM UWDeQdVVpNe4I=; b=yN/HCmHwuvsBaKPqtJZXAslFk+jh+fqPotzlNWAPolgqvH 1mHDbd9YqurTzUWTzZRKg8xfDtKA11i80qFWJ1q0B9C9c7XsGIfOKpvYboIe21Ex X9HukPl48r31QepxCE46BV5a2tWqy8TLQA9cupFw687vSBwSzPQd4pPQMTxbQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 2A95F2C8058; Mon, 15 Dec 2014 11:48:09 -0800 (PST) Date: Mon, 15 Dec 2014 13:48:08 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141215194803.GJ3241@localhost> References: <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <20141215175033.GF3241@localhost> <548F23E5.1020401@mit.edu> <20141215182502.GI3241@localhost> <548F2A7B.2040400@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F2A7B.2040400@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/WDHt7ses4P33pNSJJ__iw1bOM9U Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 19:48:25 -0000 On Mon, Dec 15, 2014 at 01:37:47PM -0500, Greg Hudson wrote: > On 12/15/2014 01:25 PM, Nico Williams wrote: > > I do see an argument for continuing: that an error token might have no > > integrity protection and the app can't tell, therefore the app should > > continue just in case. > > This is not my reasoning; my reasoning is simply that the application > has no strong reason to believe that the context has been terminated, > and that encouraging applications to make this assumption unnecessarily > closes the door to other uses. If the token is a deletion token, then yes, it has such a strong reason. If it's an error token then... it depends on whether the peer ever was PROT_READY: if not, then there's no way to continue, else... it could continue without authentication and other services, but why would an application do this? Actually, that's not farfetched. If the two peers successfully exchanged ephemeral DH keys but did not authenticate them then the app could tunnel a new authentication attempt protected by the unauthenticated one, thus obtaining protection from off-path attackers. That would be the argument that wins me over (and it's why I'm eliding my responses to your other points; those might be moot), if anyone cares to make it (I might! I'll have to think about it). Nico -- From nobody Mon Dec 15 13:52:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D642F1A006F for ; Mon, 15 Dec 2014 13:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaf2dMUhiyQ7 for ; Mon, 15 Dec 2014 13:52:39 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D001A0084 for ; Mon, 15 Dec 2014 13:52:34 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 38CF63A2FC; Mon, 15 Dec 2014 22:52:32 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 05FC444E5D; Mon, 15 Dec 2014 22:52:32 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EF6F31B085; Mon, 15 Dec 2014 22:52:31 +0100 (CET) In-Reply-To: <20141215175033.GF3241@localhost> To: Nico Williams Date: Mon, 15 Dec 2014 22:52:31 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141215215231.EF6F31B085@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Z59nD4aBNlnimvv0N2sZm-pDEmY Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:52:46 -0000 Nico Williams wrote: > On Mon, Dec 15, 2014 at 12:20:30PM -0500, Greg Hudson wrote: >> On 12/10/2014 01:57 PM, Benjamin Kaduk wrote: >>> Though future GSS-API extensions may add new uses of asynchronous >>> security context tokens and ways to process them, applications >>> using the GSS-API version 2, update 1, should generally call >>> GSS_Delete_sec_context() after calling GSS_Process_context_token(), >>> when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. >> >> I don't like the wording of this part. Encouraging applications to >> assume that context tokens destroy the context essentially closes the >> door to specifying context tokens which don't. GSS_Process_context_token() will typically mark a security context as "no longer usable" (but leave the context handle itself intact). It is a "local matter" (read: implementation defined) whether a gssapi mechanism destroys cryptographic keying material associated with the security context handle already within GSS_Process_context_token() or only upon cleanup when GSS_Delete_sec_context() is called. >> >> (To be clear: saying that applications must eventually call >> GSS_Delete_sec_context() is fine; saying that they should do so >> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is >> not fine.) > > GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and > GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before > calling GSS_Delete_sec_context(), however, You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ? Nope. That GSS_Unwrap() or GSS_VerifyMIC() still works is at least somewhat unlikely for "regular" context deletion tokens, but guaranteed for context error tokens that report a context establishment failure. A gssapi mechanism that would have GSS_Wrap() or GSS_GetMIC() work after processing a context deletion token would be somewhat silly, because the mechanism knows _reliably_ that there exists noone that could process the results. -Martin From nobody Mon Dec 15 13:59:45 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A311A013B for ; Mon, 15 Dec 2014 13:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSXS7V3eYzwz for ; Mon, 15 Dec 2014 13:59:40 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D631A0137 for ; Mon, 15 Dec 2014 13:59:40 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 4F9E93A2FC; Mon, 15 Dec 2014 22:59:39 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 470E544E8B; Mon, 15 Dec 2014 22:59:39 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3D0AD1B085; Mon, 15 Dec 2014 22:59:39 +0100 (CET) In-Reply-To: <20141215215231.EF6F31B085@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Mon, 15 Dec 2014 22:59:39 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141215215939.3D0AD1B085@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/jEBz0YfyOev6tGlVdfIQaaH0W_8 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:59:42 -0000 Sorry, fixing a typo and clarifying. The "early message protection" facilities will only ever succeed for early message protection (gss_wrap(), gss_getmic()), but will _never_ succeed for early message un-protection (gss_unwrap(), gss_verifymic()). -Martin I wrote: > > Nico Williams wrote: >> On Mon, Dec 15, 2014 at 12:20:30PM -0500, Greg Hudson wrote: >>> On 12/10/2014 01:57 PM, Benjamin Kaduk wrote: >>>> Though future GSS-API extensions may add new uses of asynchronous >>>> security context tokens and ways to process them, applications >>>> using the GSS-API version 2, update 1, should generally call >>>> GSS_Delete_sec_context() after calling GSS_Process_context_token(), >>>> when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. >>> >>> I don't like the wording of this part. Encouraging applications to >>> assume that context tokens destroy the context essentially closes the >>> door to specifying context tokens which don't. > > GSS_Process_context_token() will typically mark a security context > as "no longer usable" (but leave the context handle itself intact). > It is a "local matter" (read: implementation defined) whether > a gssapi mechanism destroys cryptographic keying material associated > with the security context handle already within GSS_Process_context_token() > or only upon cleanup when GSS_Delete_sec_context() is called. > > > >>> >>> (To be clear: saying that applications must eventually call >>> GSS_Delete_sec_context() is fine; saying that they should do so >>> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is >>> not fine.) >> >> GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and >> GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before >> calling GSS_Delete_sec_context(), however, > > You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() > GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ? > > Nope. > > That GSS_Unwrap() or GSS_VerifyMIC() still works is at least somewhat > unlikely for "regular" context deletion tokens, but guaranteed ++ to fail for > context error tokens that report a context establishment failure. > > A gssapi mechanism that would have GSS_Wrap() or GSS_GetMIC() work after > processing a context deletion token would be somewhat silly, because > the mechanism knows _reliably_ that there exists noone that could > process the results. From nobody Mon Dec 15 15:07:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3BC1A6F9C for ; Mon, 15 Dec 2014 15:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99d2yqAM3NVS for ; Mon, 15 Dec 2014 15:07:25 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB831A6F90 for ; Mon, 15 Dec 2014 15:07:25 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id E9FD631805D; Mon, 15 Dec 2014 15:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5+QsnP0Ony2zYb SymawWHxasgMM=; b=FgICR71S14Yr+BqoZhp/4uIxa7DhbJSAMS1J70yw2Go9Co gkEIEeNu4a22LbbigeYXHk367V0kvwEk54adGc14S8XXJkrN851UuQHUckZbMSJQ 9AGxRIpHSGUpBpADb1ZLMsCRdO37u/17HSYYWwKqjolZ9qknEbw401zEwUHMs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 8937331805C; Mon, 15 Dec 2014 15:07:24 -0800 (PST) Date: Mon, 15 Dec 2014 17:07:24 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141215230719.GM3241@localhost> References: <20141215175033.GF3241@localhost> <20141215215231.EF6F31B085@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141215215231.EF6F31B085@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/QRYimqbNCJhynCMzIQ007okiR7s Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:07:26 -0000 On Mon, Dec 15, 2014 at 10:52:31PM +0100, Martin Rex wrote: > Nico Williams wrote: > >> (To be clear: saying that applications must eventually call > >> GSS_Delete_sec_context() is fine; saying that they should do so > >> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is > >> not fine.) > > > > GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and > > GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before > > calling GSS_Delete_sec_context(), however, > > You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() > GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ? No, after calling GSS_Process_context_token(). From nobody Mon Dec 15 15:13:50 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606561A6F93 for ; Mon, 15 Dec 2014 15:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCLSVlUixAC7 for ; Mon, 15 Dec 2014 15:13:46 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED1E1A6F8B for ; Mon, 15 Dec 2014 15:13:46 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2D98A778071; Mon, 15 Dec 2014 15:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TYGtwsKJsu5fou /F9HQpE0/I/wA=; b=cU8x+lonlBKIkClgH7FPuxNfTVVOIVREEDmshH5nmUcleq pV+TonzlbLDtvedG7xhKCZGyJZps1w7IORB3F+9KDgaHL76UIZxq+uBvESgdtDHl 3hpJeSDhZkVztWMN6uxTYxt24NeIj9K6eseHqVbtWFk/NhqQ39EEBzPkZefPM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id D98ED778070; Mon, 15 Dec 2014 15:13:45 -0800 (PST) Date: Mon, 15 Dec 2014 17:13:45 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141215231340.GN3241@localhost> References: <20141215215231.EF6F31B085@ld9781.wdf.sap.corp> <20141215215939.3D0AD1B085@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141215215939.3D0AD1B085@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Xfvs-YaBtdgCilmod_d6vyjENK0 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:13:47 -0000 On Mon, Dec 15, 2014 at 10:59:39PM +0100, Martin Rex wrote: > The "early message protection" facilities will only ever succeed > for early message protection (gss_wrap(), gss_getmic()), but will _never_ > succeed for early message un-protection (gss_unwrap(), gss_verifymic()). RFC2743, page 26, contradicts you on this: For context establishment calls, this state Boolean is valid and interpretable when the associated major_status is either GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both initiators and acceptors) can assume that per-message protection (via -> GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is available and ready for use if either: prot_ready_state == TRUE, or major_status == GSS_S_COMPLETE, though mutual authentication (if requested) cannot be guaranteed until GSS_S_COMPLETE is returned. And this makes plenty of sense too. Consider a mechanism that does a key exchange using ephemeral-ephemeral DH in one round trip but nonetheless requires several more round trips to complete authentication. The early prot_ready protection could be available several context tokens prior to full establishment, and this could be quite useful. For example, ABFAB can require multiple round trips to authenticate, but it could be modified to support (and maybe already does) early prot_ready using DH. Nico -- From nobody Tue Dec 16 02:02:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955361A1A80 for ; Tue, 16 Dec 2014 02:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0wxBeeDrc6R for ; Tue, 16 Dec 2014 02:02:19 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8031A1A4C for ; Tue, 16 Dec 2014 02:02:19 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 864DA3A0FF; Tue, 16 Dec 2014 11:02:17 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 537B345252; Tue, 16 Dec 2014 11:02:17 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4AB701B084; Tue, 16 Dec 2014 11:02:17 +0100 (CET) In-Reply-To: <20141215230719.GM3241@localhost> To: Nico Williams Date: Tue, 16 Dec 2014 11:02:17 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141216100217.4AB701B084@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NAOJtWhZEIWPf2KFVYcEUkpGgKA Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 10:02:22 -0000 Nico Williams wrote: > On Mon, Dec 15, 2014 at 10:52:31PM +0100, Martin Rex wrote: > > Nico Williams wrote: > > >> (To be clear: saying that applications must eventually call > > >> GSS_Delete_sec_context() is fine; saying that they should do so > > >> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is > > >> not fine.) > > > > > > GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and > > > GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before > > > calling GSS_Delete_sec_context(), however, > > > > You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() > > GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ? > > No, after calling GSS_Process_context_token(). It seems I was tired last night. I meant to say: You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() GSS_GetMIC() _after_ calling GSS_Process_sec_context() ? -Martin From nobody Tue Dec 16 02:08:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B7A1A1A80 for ; Tue, 16 Dec 2014 02:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huDAm8bzecb8 for ; Tue, 16 Dec 2014 02:08:13 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB141A1A79 for ; Tue, 16 Dec 2014 02:08:12 -0800 (PST) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id UA871p00410HQrX01A88yT; Tue, 16 Dec 2014 11:08:09 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Rick van Rein In-Reply-To: Date: Tue, 16 Dec 2014 11:08:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8338B5E2-26C7-45E4-BC0D-423ECBC258A7@openfortress.nl> References: <5C562C9B-4421-4CB1-9F5D-E354AE2C0104@openfortress.nl> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/D3U74fsuIhpguhN8uC3HbSnJgpQ Cc: kitten@ietf.org Subject: Re: [kitten] Draft Action: draft-vanrein-dnstxt-krb1-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 10:08:15 -0000 Hi Benjamin, > I did a fairly quick read and did not spend a whole lot of time trying = to > process everything. Thanks, and sorry for the late reply. It=E2=80=99s that time of year = that everything must be finished. > The utility of the concept of a "Home Record" (and related) is not = clear > to me. It seems the document could be shorter if it didn't bother = with a > distinction, and I'm not sure what would be lost if it did. This is = not > to say "you should remove them", but if you want to keep them, please = help > the reader understand why they are there :) OK. Since I=E2=80=99m following the suggestion to define general = tag=3Dvalue setups, and subsequently proposed an IANA register for tags, I felt a need to separate these two classes of records. The idea is a security matter; and should perhaps be explained better. A record for EXAMPLE.COM situated at example.com has more right to speak about the realm than a record for EXAMPLE.COM situated under example.org. The first is a =E2=80=9Chome=E2=80=9D record, the = second would be a mere reference. In the second case, when an application needs info from a "home tag=E2=80=9D, it would first resolve example.org to point = to the EXAMPLE.COM realm, then lookup the home record under example.com and from there harvest the additional tag value. The general idea being that a =E2=80=9Chome record=E2=80=9D is = DNSSEC-signed to be authoritative for the realm, which is not true for a mere reference. Does that help? I am not actually using this distinction in the document, so it is = purely for the sake of the general registry and possible future expansion that it enables. I do not believe that it is valid to remove the home record distinction without also removing the registry of tags. Whether putting up a registry is useful for future expansion, or merely added administrative minutia is open for dicussion as far as I=E2=80=99m = concerned. There is definately something to gain from sticking to a fixed set of = tags: simpler syntax, simpler parsing and simpler processing. > The general structure seems like a reasonable chunk to bite off at = once, > handling a bit more than just realm names, and providing a reasonable > mechanism for future extension. Glad you like that. Have I convinced you that future tags might be specific for references, and/or specific for home records? > It does read more like a DNS document than a Kerberos one, so I wonder = if > that should be the primary forum for discussion, with consultations to > kitten as needed. Agreed. I still have to post it on DNS OPS. We=E2=80=99ll see what = turns out to be the most logical place for acceptance. At some point there may be a question to Kitten of the order =E2=80=9Cis this of any use?" > I don't really see anything to mitigate the previous criticisms = regarding > the use of the zone apex as a fallback (regarding the potential lack = of a > relationship between the zone cut and Kerberos administrative = boundaries). Please recall that this criticism ended in =E2=80=9CI should perhaps = read the document=E2=80=9D. But there=E2=80=99s no ideal solution AFAIK =E2=80=94 there are only = suboptimal alternatives. Either you actively search upwards, and risk hitting on your parent = (both overloading and trusting it) or you choose to interpret the Start Of = Authority record as a DNS-published boundary to never cross. In light of DNSSEC practice which assigns more operational authority to zones, especially concerning security, I have chosen the last one. Total avoidance of the search upward would be possible as a null = solution; in that case, you=E2=80=99d end up adding a KREALM record to each and = every A and AAAA record in DNS. That has its own problems of scale, though, especially in a DNSSEC-signed world. The null solution is O(N), = searching up the DNS chain is O(log N), what I am proposing is O(1). Cheers, -Rick= From nobody Tue Dec 16 07:47:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE27C1A1B93 for ; Tue, 16 Dec 2014 07:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePR05YEuzb5r for ; Tue, 16 Dec 2014 07:47:21 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E87941A1B44 for ; Tue, 16 Dec 2014 07:47:20 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 9D3E61006E; Tue, 16 Dec 2014 07:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=cNUEjws+dYwUUd ffiELczh0xQtk=; b=s/EkIhNvfRCJquEVErlAgp3LXc9H2Pq2TXDUwiKgBSj9vp aDVBh+dnZTZE3I3hVDYQevgSjtfr78EFoJ8JOc071JxFLlO1irmTXJ6XSjdcF5xM M2/x6j8IArKEUuahV35+0qpizhbAkQZ7RBk4RpGIrRFf7qpjra9nXn+bY14Bk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 4117210059; Tue, 16 Dec 2014 07:47:20 -0800 (PST) Date: Tue, 16 Dec 2014 09:47:18 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141216154712.GS3241@localhost> References: <20141215230719.GM3241@localhost> <20141216100217.4AB701B084@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141216100217.4AB701B084@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EI8g4G1rJFegYTyT5mCaxk7WsS0 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:47:22 -0000 On Tue, Dec 16, 2014 at 11:02:17AM +0100, Martin Rex wrote: > Nico Williams wrote: > > On Mon, Dec 15, 2014 at 10:52:31PM +0100, Martin Rex wrote: > > > Nico Williams wrote: > > > >> (To be clear: saying that applications must eventually call > > > >> GSS_Delete_sec_context() is fine; saying that they should do so > > > >> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is > > > >> not fine.) > > > > > > > > GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and > > > > GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before > > > > calling GSS_Delete_sec_context(), however, > > > > > > You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() > > > GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ? > > > > No, after calling GSS_Process_context_token(). > > It seems I was tired last night. > > I meant to say: > > You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap() > GSS_GetMIC() _after_ calling GSS_Process_sec_context() ? Yes. Because of out of order delivery of tokens in, say, a UDP-based app it's certainly possible for GSS_Unwrap() and GSS_VerifyMIC() to be needed after calling GSS_Process_sec_context(). GSS_Pseudo_random(), of course, should also continue functioning after processing an error token. (For the same reason that GSS_Unwrap() and GSS_VerifyMIC() should.} The logic by which I conclude that GSS_Wrap() and GSS_GetMIC() can also be called after calling GSS_Process_sec_context() is this: error tokens do not prove that peer delete their security context, and if they had been PROT_READY, they could still continue (though I grant that it would be rather weird to do so). GSS_Process_sec_context() should just do what its name says, and it should disable no security context functionality. So, I'm coming around to Greg's position, though for different reasons than his. Nico -- From nobody Tue Dec 16 08:02:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5A1A1BC0 for ; Tue, 16 Dec 2014 08:02:19 -0800 (PST) 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 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 7t89q6fDQol2 for ; Tue, 16 Dec 2014 08:02:06 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503461A1BB4 for ; Tue, 16 Dec 2014 08:02:06 -0800 (PST) X-AuditID: 12074423-f79b86d000000cf5-0c-5490577dd516 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.A6.03317.D7750945; Tue, 16 Dec 2014 11:02:05 -0500 (EST) 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 sBGG24iM018232; Tue, 16 Dec 2014 11:02:04 -0500 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 sBGG21Wh011528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2014 11:02:04 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBGG2163029177; Tue, 16 Dec 2014 11:02:01 -0500 (EST) Date: Tue, 16 Dec 2014 11:02:00 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> 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+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrlsbPiHEYHo7n8XRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGUsn/mRtWCpaMXuc71sDYy3BLoYOTgkBEwk nnwx7mLkBDLFJC7cW8/WxcjFISSwmEni1OM/LBDORkaJzistrCBVQgKHmCQu/zKEsBsYJf48 4AKxWQS0JaZNuMEIYrMJqEjMfLORDcQWEdCUuD5vKZjNLCAssf7cDGYQWxgovvPrLbCZnAJO Ej2PvoD18go4Sizu62GBmH+QWaLxtSCILSqgI7F6/xQWiBpBiZMzn7BAzNSSWD59G8sERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECA5TF+UdjH8OKh1i FOBgVOLhDSjsDxFiTSwrrsw9xCjJwaQkymvhPyFEiC8pP6UyI7E4I76oNCe1+BCjBAezkghv kDJQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJglcvDKhRsCg1PbUi LTOnBCHNxMEJMpwHaHgaSA1vcUFibnFmOkT+FKOilDhvNkhCACSRUZoH1wtLI68YxYFeEebt B6niAaYguO5XQIOZgAZP/twPMrgkESEl1cDIWdScwd9sfzxr7Z2QCd+nTz7VeVbX/reS4qqj N/aHX9tv/nfu8ujOrLk9M46siOv79Vg1Yc6GmJTGfjnP+wI/80JPxq0NO9nOue/7hocrPlZt CLad2qbP0+/8iDOqeiX7+szYyUsu73jtf+fIvVfK/zbIvd/BVc966pmUYUHY/wXH1oZP6Hn0 SYmlOCPRUIu5qDgRAKtAyVz+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/beEKtjdmWD1IfuZMsYZqbTHlFE4 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:02:19 -0000 On Wed, 10 Dec 2014, Benjamin Kaduk wrote: > On Tue, 9 Dec 2014, Nico Williams wrote: > > > Sold. > > Okay, so now we're looking at: > > ====================================================== > > Section 2.2.4 says: > > o GSS_S_FAILURE indicates that the context is recognized, but that > the GSS_Process_context_token() operation could not be performed > for reasons unspecified at the GSS-API level. > > It should say: > > o GSS_S_FAILURE indicates that the context is recognized, but > either the GSS_Process_context_token() operation could not be > performed for reasons unspecified at the GSS-API level, or the peer > had an error consuming the last context token sent to it. The latter > occurs when the local side became fully established and produced one > last token which was sent to the peer, but the peer encountered an > error while processing that last context token. In either case the > minor status code provides additional information. Thinking about things a bit more with a clearer head, I would like to replace "last context token" with "last context establishment token" in this paragraph, since error and deletion tokens are still context-level tokens, and the one which we thought was last isn't actually last if there's an error token in reply to it, so calling it the "last context(-level) token" is strange. [...] > Though future GSS-API extensions may add new uses of asynchronous > security context tokens and ways to process them, applications > using the GSS-API version 2, update 1, should generally call > GSS_Delete_sec_context() after calling GSS_Process_context_token(), > when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. [peeking ahead in the thread, since I'm replying to an early message] I think the disagreement between Greg and Nico can be distilled to: how likely are we to require that future extensions using async context tokens are implemented in a backwards-compatible way? Taking the rekey example as a strawman (even though we know that there are other ways to do it not involving async context tokens), this would just mean that a GSSv2u3 app would try to do the rekey, and if it was talking to a GSSv2u1 app, the rekey would fail, and the old key would transparently continue to be used. So, it is certainly possible to be backwards compatible, at least in some cases. Greg's argument that there should also be application-level error handling which could discover that the context is unusable and tear things down rings true to me, so I agree with Greg that we should not close the door prematurely. -Ben From nobody Tue Dec 16 08:44:39 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37921A1BA3 for ; Tue, 16 Dec 2014 08:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrV3Qcbw6dS5 for ; Tue, 16 Dec 2014 08:44:35 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A4CB61A1BE3 for ; Tue, 16 Dec 2014 08:44:33 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 81E9F163D; Tue, 16 Dec 2014 08:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Cdo9XhYCXOQcCa h40x2hXlsQ+ZE=; b=yFwnsV1hN9mqL3Blg8BBeYok4Zk7wBAxNMiB59Fh3+fpfM /NaW0ecVNf0A5j8TIrXCK4loSWb69nx2jtBElxUSDz3l4TJB/y8lxw55P9NA1Ydm Q6fEH7gYjjJr5hqKiwgr/ShoUrbN2DUIHsZd4VyJH0mEQbeGFACPBXnulx8RE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id A3ADF163B; Tue, 16 Dec 2014 08:44:32 -0800 (PST) Date: Tue, 16 Dec 2014 10:44:31 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141216164426.GU3241@localhost> References: <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@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: http://mailarchive.ietf.org/arch/msg/kitten/w0NlwctV6HKUxyM5lQUdwbj4ZoM Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:44:37 -0000 On Tue, Dec 16, 2014 at 11:02:00AM -0500, Benjamin Kaduk wrote: > On Wed, 10 Dec 2014, Benjamin Kaduk wrote: > > On Tue, 9 Dec 2014, Nico Williams wrote: > > ====================================================== > > > > Section 2.2.4 says: > > > > o GSS_S_FAILURE indicates that the context is recognized, but that > > the GSS_Process_context_token() operation could not be performed > > for reasons unspecified at the GSS-API level. > > > > It should say: > > > > o GSS_S_FAILURE indicates that the context is recognized, but > > either the GSS_Process_context_token() operation could not be > > performed for reasons unspecified at the GSS-API level, or the peer > > had an error consuming the last context token sent to it. The latter > > occurs when the local side became fully established and produced one > > last token which was sent to the peer, but the peer encountered an > > error while processing that last context token. In either case the > > minor status code provides additional information. > > Thinking about things a bit more with a clearer head, I would like to > replace "last context token" with "last context establishment token" in > this paragraph, since error and deletion tokens are still context-level > tokens, and the one which we thought was last isn't actually last if > there's an error token in reply to it, so calling it the "last > context(-level) token" is strange. The problem is "last" then. The addition of "establishment" doesn't cure the problem. IMO it's a non-problem. > [...] > > > Though future GSS-API extensions may add new uses of asynchronous > > security context tokens and ways to process them, applications > > using the GSS-API version 2, update 1, should generally call > > GSS_Delete_sec_context() after calling GSS_Process_context_token(), > > when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. > > [peeking ahead in the thread, since I'm replying to an early message] > > I think the disagreement between Greg and Nico can be distilled to: how > likely are we to require that future extensions using async context tokens > are implemented in a backwards-compatible way? Sort of. But the key is that we shouldn't REQUIRE that the next step be getting into a state that leads inexorably to calling GSS_Delete_sec_context(). We don't, as this RFC doesn't use RFC2119. Greg things that "...should generally call GSS_Delete_sec_context()..." is too strong. It's a bit of an angels on a headpin argument... if we assume that all properly function applications will inexorably end up calling GSS_Delete_sec_context() anyways (they should, if they succeed as establishing a security context). I believe the "generally" weasel word is good enough. I don't think the entire paragraph should be excised. I'd like to see alternative text from Greg. > Taking the rekey example as a strawman (even though we know that there are > other ways to do it not involving async context tokens), this would just > mean that a GSSv2u3 app would try to do the rekey, and if it was talking > to a GSSv2u1 app, the rekey would fail, and the old key would > transparently continue to be used. Or the v2u1 app would end up calling GSS_Delete_sec_context(). It's not at all clear to me that we want a v2u1 app to continue in the case of a re-key attempt that fails because it (the app) doesn't know that that's what the context token was about (or how to respond to it). Of course, the thought occurs that a re-key context token would elicit a GSS_S_DEFECTIVE_TOKEN major status code from GSS_Process_context_token(), so maybe there's no real problem here (since the "should generally" text above does not apply in that case). > So, it is certainly possible to be backwards compatible, at least in some > cases. Greg's argument that there should also be application-level error > handling which could discover that the context is unusable and tear things > down rings true to me, so I agree with Greg that we should not close the > door prematurely. I believe the above text does not do this. See above comment about GSS_S_DEFECTIVE_TOKEN. Nico -- From nobody Tue Dec 16 08:50:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3850E1A6F2A for ; Tue, 16 Dec 2014 08:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm-pCiqmDypX for ; Tue, 16 Dec 2014 08:50:24 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE951A6EE7 for ; Tue, 16 Dec 2014 08:50:24 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id E15A520058D80; Tue, 16 Dec 2014 08:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=YzoMp6Lg+cwC8M AL+1WohtXhzBA=; b=MfgCmxydLjIULdnORBeTW976yYEEJSa2NY3XPM4TxVO7OJ Aty+W8fXO5cGvDWJtSQ+uT1PE5GnLxoTFxemHOPvvjXamzfPdcwSi0o4cXe1FVkN jHDTaF+VoQhqlC9J/4CO8tEvNjbBQibm0vukced5kxPGxxvKqDoWHnYenQzUI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 8DE0F2005D82E; Tue, 16 Dec 2014 08:50:23 -0800 (PST) Date: Tue, 16 Dec 2014 10:50:23 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141216165018.GW3241@localhost> References: <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <20141216164426.GU3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141216164426.GU3241@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wHZ6Eue-QvdowmO98B63K94RiDA Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:50:26 -0000 On Tue, Dec 16, 2014 at 10:44:26AM -0600, Nico Williams wrote: > Of course, the thought occurs that a re-key context token would elicit a > GSS_S_DEFECTIVE_TOKEN major status code from GSS_Process_context_token(), > so maybe there's no real problem here (since the "should generally" text > above does not apply in that case). The further thought occurs that a v2u1 app might be using a v2u1+N GSS-API implementation (there's no version negotiation between the two). For the case of re-keys (if we ever implement re-key with extra async context tokens) we must then... what? introduce a new major status code for GSS_Process_context_token()? I think that would do. Nico -- From nobody Tue Dec 16 11:07:15 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48D91ACDF0 for ; Tue, 16 Dec 2014 11:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdCSxNXZxm7L for ; Tue, 16 Dec 2014 11:07:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C0B1ACD2D for ; Tue, 16 Dec 2014 11:07:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A1262BE88; Tue, 16 Dec 2014 19:07:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCoaSK5vTKEK; Tue, 16 Dec 2014 19:07:02 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.57.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 72E9BBE87; Tue, 16 Dec 2014 19:07:02 +0000 (GMT) Message-ID: <549082D6.9060000@cs.tcd.ie> Date: Tue, 16 Dec 2014 19:07:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <20141216164426.GU3241@localhost> <20141216165018.GW3241@localhost> In-Reply-To: <20141216165018.GW3241@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oYXUNi1rmn3PUGMAB7adJFg-_aA Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:07:14 -0000 Meta question: if it requires so much discussion is this really suited as an erratum? Just wondering:-) S. On 16/12/14 16:50, Nico Williams wrote: > On Tue, Dec 16, 2014 at 10:44:26AM -0600, Nico Williams wrote: >> Of course, the thought occurs that a re-key context token would elicit a >> GSS_S_DEFECTIVE_TOKEN major status code from GSS_Process_context_token(), >> so maybe there's no real problem here (since the "should generally" text >> above does not apply in that case). > > The further thought occurs that a v2u1 app might be using a v2u1+N > GSS-API implementation (there's no version negotiation between the two). > > For the case of re-keys (if we ever implement re-key with extra async > context tokens) we must then... what? introduce a new major status code > for GSS_Process_context_token()? I think that would do. > > Nico > From nobody Tue Dec 16 11:53:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF331A873C for ; Tue, 16 Dec 2014 11:53:33 -0800 (PST) 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 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 KxH_UY8P4zO6 for ; Tue, 16 Dec 2014 11:53:31 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE5F1A873E for ; Tue, 16 Dec 2014 11:53:31 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-4b-54908dba75cd 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 98.D5.03354.ABD80945; Tue, 16 Dec 2014 14:53:30 -0500 (EST) 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 sBGJrTYk018377; Tue, 16 Dec 2014 14:53:29 -0500 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 sBGJrQ9b026143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2014 14:53:28 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBGJrQKD028232; Tue, 16 Dec 2014 14:53:26 -0500 (EST) Date: Tue, 16 Dec 2014 14:53:26 -0500 (EST) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <549082D6.9060000@cs.tcd.ie> Message-ID: References: <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <20141216164426.GU3241@localhost> <20141216165018.GW3241@localhost> <549082D6.9060000@cs.tcd.ie> 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+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrrurd0KIwc/T3BZHN69isTh17Qib xfS919gdmD1enjrH6LG2+yqbx5IlP5kCmKO4bFJSczLLUov07RK4Mp4dySn4xlvx4IF9A+NU 7i5GTg4JAROJI4sPs0HYYhIX7q0Hsrk4hAQWM0m8eNTPBOFsZJSY3n+PEcI5xCTR/vgQlNPA KNHz/QsrSD+LgLbEmh/PwWaxCahIzHyzEcwWEdCX2Lv5HDuIzSxgJdH4uxUsLiygKbHz6y2g Xg4OTiD7SHsxSJhXwFFiyokfrBDz21gkDux5zgySEBXQkVi9fwoLRJGgxMmZT1ggZmpJLJ++ jWUCo+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBAevi+oO xgmHlA4xCnAwKvHwBhT2hwixJpYVV+YeYpTkYFIS5V3QMyFEiC8pP6UyI7E4I76oNCe1+BCj BAezkggvcyNQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvczyFDB otT01Iq0zJwShDQTByfIcB6g4ZNAaniLCxJzizPTIfKnGBWlxHk1gOlBSAAkkVGaB9cLSy6v GMWBXhHmrQVp5wEmJrjuV0CDmYAGT/7cDzK4JBEhJdXAWLaQ2UtUI2+9go7nejEHA51GzSVu Ndky7UnrtkXk2QQ/vxt4TPOigNHVT3Oc5Bcc/f/jvsWhLwWzlfJ+387+Fn/3opVR0U79U2+C C9/OsgnwdA3dx6K7xe/tPkVvG+GFxnWrM6XZT0QkWnqsF5nMkitg/iUi9c80xwfKb7mXOsow /rz1tZlLiaU4I9FQi7moOBEAKsWCPAkDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/aTL1HrLFq70orr7jZ29tRl8LKcg Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:53:33 -0000 On Tue, 16 Dec 2014, Stephen Farrell wrote: > > Meta question: if it requires so much discussion is this > really suited as an erratum? Just wondering:-) Well, I think the crux of it is that the thing which is inspiring so many words is not really suited as an erratum, but that's only a small part of the actual proposed text. The main goal is to fix the broken behavior of GSS_Process_context_token(), which as written in RFC 2743 does not allow a caller to obtain information from a processed error token. (If that's the case, there's no reason to specify error tokens, so it's clearly a bug.) However, the proposed text also adds this paragraph: Though future GSS-API extensions may add new uses of asynchronous security context tokens and ways to process them, applications using the GSS-API version 2, update 1, should generally call GSS_Delete_sec_context() after calling GSS_Process_context_token(), when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. which is adding new text which attempts to clarify how applications consume the GSS-API. It is this paragraph which is controversial, and it is perhaps not appropriate for an erratum. We may be better off both consensus-wise and process-wise if we eliminate this paragraph and leave the current description of how to call GSS_Process_conetxt_token() as it is in RFC 2743. (Nico will probably say that "generally" is wiggle room so this is not actually normative, but even with that, it's not clear that this paragraph adds enough to merit inclusion in an erratum.) Skipping that paragraph would allow us to move forward and fix the clear brokenness in the spec, without being bogged down trying to resolve a different apparent ambiguity. -Ben From nobody Tue Dec 16 12:03:50 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565EC1A8744 for ; Tue, 16 Dec 2014 12:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKsfahlP3Y-s for ; Tue, 16 Dec 2014 12:03:42 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E2B1ACD8A for ; Tue, 16 Dec 2014 12:03:38 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-32-54909019af7f 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FD.C6.03354.91090945; Tue, 16 Dec 2014 15:03:37 -0500 (EST) 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 sBGK3aU6019766; Tue, 16 Dec 2014 15:03:37 -0500 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 sBGK3YHv029509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2014 15:03:36 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBGK3YcB029477; Tue, 16 Dec 2014 15:03:34 -0500 (EST) Date: Tue, 16 Dec 2014 15:03:34 -0500 (EST) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <8338B5E2-26C7-45E4-BC0D-423ECBC258A7@openfortress.nl> Message-ID: References: <5C562C9B-4421-4CB1-9F5D-E354AE2C0104@openfortress.nl> <8338B5E2-26C7-45E4-BC0D-423ECBC258A7@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-658937764-1418760214=:23489" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT15WcMCHEYEKzsMXRzatYLJ6+usfm wOSxZMlPJo8N/5rYApiiuGxSUnMyy1KL9O0SuDLWfVzAVPBPomL2uunsDYyvhbsYOTkkBEwk zvyYwgJhi0lcuLeeDcQWEljMJDFpfkAXIxeQvZFRYu+ct+wQziEmiZPH5jFDVDUwSkyeFg1i swhoS1w6/hGsm01ARWLmm41gtoiAhsTnX1PBbGYBYYn152aA9QoLOEicXbAKzOYUcJY4/hek noODV8BR4sG1Uohd6xklvnY8ZQWpERXQkVi9H+JSXgFBiZMzn7BAzAyQWHZ1AfMERsFZSFKz kKQgbHWJxgdn2SBsbYn7N9vYFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSnd xAgObBfVHYwTDikdYhTgYFTi4Q0o7A8RYk0sK67MPcQoycGkJMq7oGdCiBBfUn5KZUZicUZ8 UWlOavEhRgkOZiURXuZGoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgTv3D6gRsGi1PTUirTMnBKENBMHJ8hwHqDhP3tBhhcXJOYWZ6ZD5E8xKkqJ8wb0AyUEQBIZ pXlwvbDE84pRHOgVYV4rkCoeYNKC634FNJgJaPDkz/0gg0sSEVJSDYxMXy+HO9wwNTvRyPOS j/Xqw+mcwRVPKyPE25Kc5sdEtRj9unR/14ZFLLIzuQ27636uX/XpsPkbDvvYF/scr8S9VNXq Mbh2Tr14w3XvSUEd5yY0ijn0ztUULnsvfzd7z5VfPV0fZWKvL29btlOgf/YTaxXpg91q1o9z crn65xpmH4w8e+np3TIlluKMREMt5qLiRACny+fYFwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/bvMFuhOfoTzeCvlC_MAJ8tnDh0g Cc: kitten@ietf.org Subject: Re: [kitten] Draft Action: draft-vanrein-dnstxt-krb1-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:03:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-658937764-1418760214=:23489 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Dec 2014, Rick van Rein wrote: > Hi Benjamin, > > > I did a fairly quick read and did not spend a whole lot of time trying = to > > process everything. > > Thanks, and sorry for the late reply. It=E2=80=99s that time of year tha= t everything must be finished. Understood. > > The utility of the concept of a "Home Record" (and related) is not clea= r > > to me. It seems the document could be shorter if it didn't bother with= a > > distinction, and I'm not sure what would be lost if it did. This is no= t > > to say "you should remove them", but if you want to keep them, please h= elp > > the reader understand why they are there :) > > OK. Since I=E2=80=99m following the suggestion to define general tag=3Dv= alue setups, > and subsequently proposed an IANA register for tags, I felt a need to > separate these two classes of records. > > The idea is a security matter; and should perhaps be explained better. > > A record for EXAMPLE.COM situated at example.com has more right > to speak about the realm than a record for EXAMPLE.COM situated > under example.org. The first is a =E2=80=9Chome=E2=80=9D record, the sec= ond would be > a mere reference. In the second case, when an application needs info > from a "home tag=E2=80=9D, it would first resolve example.org to point to= the > EXAMPLE.COM realm, then lookup the home record under example.com > and from there harvest the additional tag value. > > The general idea being that a =E2=80=9Chome record=E2=80=9D is DNSSEC-sig= ned to be > authoritative for the realm, which is not true for a mere reference. > > Does that help? That does help, yes. > I am not actually using this distinction in the document, so it is purely= for > the sake of the general registry and possible future expansion that it > enables. I do not believe that it is valid to remove the home record > distinction without also removing the registry of tags. > > Whether putting up a registry is useful for future expansion, or merely > added administrative minutia is open for dicussion as far as I=E2=80=99m = concerned. > There is definately something to gain from sticking to a fixed set of tag= s: > simpler syntax, simpler parsing and simpler processing. > > > The general structure seems like a reasonable chunk to bite off at once= , > > handling a bit more than just realm names, and providing a reasonable > > mechanism for future extension. > > Glad you like that. Have I convinced you that future tags might be > specific for references, and/or specific for home records? I don't think you have quite convinced me, but neither do I remain unconvinced. I would need to think about it for longer than I can right now (and it's unclear that the issue is important enough for me to spend that time in the near future). -Ben ---559023410-658937764-1418760214=:23489-- From nobody Tue Dec 16 13:55:51 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3F11A8736 for ; Tue, 16 Dec 2014 13:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwV-HWtOvYAZ for ; Tue, 16 Dec 2014 13:55:47 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A2E1A007A for ; Tue, 16 Dec 2014 13:55:47 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id DACE13A48F; Tue, 16 Dec 2014 22:55:44 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id A97834189E; Tue, 16 Dec 2014 22:55:44 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9E7EB1B087; Tue, 16 Dec 2014 22:55:44 +0100 (CET) In-Reply-To: <20141215231340.GN3241@localhost> To: Nico Williams Date: Tue, 16 Dec 2014 22:55:44 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20141216215544.9E7EB1B087@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Ru7mFbU0ToBwZ-HqftAB-AT3Dr8 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:55:50 -0000 Nico Williams wrote: > On Mon, Dec 15, 2014 at 10:59:39PM +0100, Martin Rex wrote: > > The "early message protection" facilities will only ever succeed > > for early message protection (gss_wrap(), gss_getmic()), but will _never_ > > succeed for early message un-protection (gss_unwrap(), gss_verifymic()). > > RFC2743, page 26, contradicts you on this: No, this does not really contract me. :) > > For context establishment calls, this state Boolean is valid and > interpretable when the associated major_status is either > GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both > initiators and acceptors) can assume that per-message protection (via > -> GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is > available and ready for use if either: prot_ready_state == TRUE, or > major_status == GSS_S_COMPLETE, though mutual authentication (if > requested) cannot be guaranteed until GSS_S_COMPLETE is returned. The original purpose, semantics and security guarantees of GSS-API per-message protection services are *NOT* changed by PROT_READY. The original purpose and semantics (quoting rfc2743): Per-message GSS_Wrap() and GSS_Unwrap() calls provide the data origin authentication and data integrity services which GSS_GetMIC() and GSS_VerifyMIC() offer, and also support selection of confidentiality services as a caller option. or another quote from rfc2743: The GSS-API per-message integrity and data origin authentication services provide assurance to a receiving caller that protection was applied to a message by the caller's peer on the security context, corresponding to the entity named at context initiation. The GSS-API per-message confidentiality service provides assurance to a sending caller that the message's content is protected from access by entities other than the context's named peer. PROT_READY was never conceived to preempt any actually requested authentication or to neuter message protection services from data origin authentication--in case that this characteristic will be provided should security context establishment succeed with GSS_S_COMPLETE. rfc2743 acknowledges that prot_ready may cause message (un)protection to precede _confirmation_ of mutual authentication (back to the initiator), but not preempt mutual authentication (allowing the acceptor to get at the contents of confidentiality protected messages without actually succeeding authentication when mutual authentication is requested. What is a little less clear: what does this mean for the "simple" form of authentication, the unidirectional authentication from initiator to target, for gssapi mechanisms other than, say, Kerberos. > > And this makes plenty of sense too. I have my doubts. In the original design, TLS also does not allow application data to be sent prior to the verification of the server's Finished handshake message. There are hacks such as FALSE START, but AFAIK they at least still try to ensure not to leak application data to the server unless the server can successfully complete the TLS handshake (i.e. pass the authentication). Only confirmation of the Server passing the handshake gets delayed. > > Consider a mechanism that does a key exchange using ephemeral-ephemeral > DH in one round trip but nonetheless requires several more round trips > to complete authentication. The early prot_ready protection could be > available several context tokens prior to full establishment, > and this could be quite useful. And it will provide *MORE* than enough rope to apps to hang themselves... -Martin From nobody Tue Dec 16 15:10:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7701A011F for ; Tue, 16 Dec 2014 15:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG7iBt_l8lHU for ; Tue, 16 Dec 2014 15:10:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0E41A0173 for ; Tue, 16 Dec 2014 15:10:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9CD6EBE87; Tue, 16 Dec 2014 23:10:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfCUlUevReuy; Tue, 16 Dec 2014 23:10:08 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.41.57.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41CB1BE83; Tue, 16 Dec 2014 23:10:08 +0000 (GMT) Message-ID: <5490BBC8.3010000@cs.tcd.ie> Date: Tue, 16 Dec 2014 23:10:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <20141216164426.GU3241@localhost> <20141216165018.GW3241@localhost> <549082D6.9060000@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EHOKo3bu_X1lbt6yhqFadtBmcVE Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 23:10:45 -0000 On 16/12/14 19:53, Benjamin Kaduk wrote: > Skipping that paragraph would allow us to move forward and fix the clear > brokenness in the spec, without being bogged down trying to resolve a > different apparent ambiguity. Could be a plan - don't forget that it's entirely possible to file a 2nd or 3rd or N-th erratum after the first is finalised. Cheers, S. From nobody Wed Dec 17 14:27:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1A1A7008 for ; Wed, 17 Dec 2014 14:27:06 -0800 (PST) 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 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 4B247ZK0339c for ; Wed, 17 Dec 2014 14:27:05 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89A31A6FDB for ; Wed, 17 Dec 2014 14:27:04 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-4e-5492033790e7 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 dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.A6.03762.73302945; Wed, 17 Dec 2014 17:27:03 -0500 (EST) 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 sBHMQvwH002673; Wed, 17 Dec 2014 17:26:58 -0500 Received: from [18.101.8.137] (vpn-18-101-8-137.mit.edu [18.101.8.137]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBHMQtOF025332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2014 17:26:57 -0500 Message-ID: <5492032F.9050607@mit.edu> Date: Wed, 17 Dec 2014 17:26:55 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benjamin Kaduk , Nico Williams References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> In-Reply-To: <548F185E.70701@mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrWvOPCnE4PcVA4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY/+I1e8Fsnoo/336yNjB+5exi5OCQEDCR OLPfqYuRE8gUk7hwbz1bFyMXh5DAYiaJi+enM0E4GxklFv9oZIdwjjBJLDp9mRGkhVdATaJl 2kMmEJtFQFVizf2ZLCA2m4CyxPr9W1lANogKhElMXcoDUS4ocXLmE7CwiICnxIfpRiBhZgFh iQvb97KC2MICmhI7v95ihVh1g1li25FOZpAEJ9D4w7+esUM06EnsuP6LFcKWl2jeOpt5AqPg LCQrZiEpm4WkbAEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdQ73czBK91JTSTYzg8JXk2cH4 5qDSIUYBDkYlHt4X1yeECLEmlhVX5h5ilORgUhLl3fV+YogQX1J+SmVGYnFGfFFpTmrxIUYJ DmYlEV7zX0A53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJ3mymSSFC gkWp6akVaZk5JQhpJg5OkOE8QMO3g9TwFhck5hZnpkPkTzEqSonzrgBJCIAkMkrz4Hph6eUV ozjQK8K8EiBVPMDUBNf9CmgwE9DgyZ/7QQaXJCKkpBoY/Raq9mUXfzyy+tGlx/pf5b+qnby+ tenQ8f/zcqa/W993+1/Cw59icgXzUj5N2G29ae787U3Lji6buXLOWm4W1/k+Spdnva7IzKwT yY+s+KI49bXHttOCeZ9PnYrvP/lOUEvBLKW1wjC8d/Fnnbf+0w9+PNXJLflX25BZbbPcbaVF X7/m3lxi7KjEUpyRaKjFXFScCAA/g+ADCgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/6GVdL606klzDEHXbKPEtfgTUfHc Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:27:07 -0000 On 12/15/2014 12:20 PM, Greg Hudson wrote: > On 12/10/2014 01:57 PM, Benjamin Kaduk wrote: >> Though future GSS-API extensions may add new uses of asynchronous >> security context tokens and ways to process them, applications >> using the GSS-API version 2, update 1, should generally call >> GSS_Delete_sec_context() after calling GSS_Process_context_token(), >> when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. > > I don't like the wording of this part. Encouraging applications to > assume that context tokens destroy the context essentially closes the > door to specifying context tokens which don't. Let me rephrase this objection: I think the scope of this erratum should be limited to making it possible for conforming gss_process_context_token implementations to convey peer error token information to callers. As Ben said yesterday, the inability to do so is a clear defect in the spec, which makes it appropriate fodder for an erratum. The proposed text goes beyond that scope by giving guidance on how to respond to GSS_S_COMPLETE. That guidance assumes that async context token types are limited to the ones mentioned in section 2.2.4: (deletion tokens and error tokens resulting from the final synchronous token). Because this assumption does not match my reading of the existing text, I don't think providing such additional guidance about GSS_S_COMPLETE is appropriate for an erratum. I also don't think clarifying this point is important enough to justify a document revision. From nobody Wed Dec 17 15:05:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53C51A002F for ; Wed, 17 Dec 2014 15:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bbok8HMJrus for ; Wed, 17 Dec 2014 15:05:13 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2601A0019 for ; Wed, 17 Dec 2014 15:05:12 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id E8EE520047D12; Wed, 17 Dec 2014 15:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=vFryukp1v50LpI Mcg5Fv0KFLACI=; b=lnpQwObkSvBEBJ5EtTLoQh3JOgreOg6OAt4BMxwO7pE6u8 kImv04lSHOvMEZyrfxd2GqG50PXNhr73VUhPE8yGS8JgQxGIJFoBsRcJzPnjCSKS vEtH6CJ38VWmc0HHZM6zDQd3bxS+GTEOjWd7LloOMsN+VApPuoLUTl0EKYNDA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 9708920046913; Wed, 17 Dec 2014 15:05:11 -0800 (PST) Date: Wed, 17 Dec 2014 17:05:11 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141217230505.GD9443@localhost> References: <20141110162504.GA3412@localhost> <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5492032F.9050607@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wHCKO2kN3yx8qOeW_GW0XB9mAd4 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:05:24 -0000 On Wed, Dec 17, 2014 at 05:26:55PM -0500, Greg Hudson wrote: > On 12/15/2014 12:20 PM, Greg Hudson wrote: > > On 12/10/2014 01:57 PM, Benjamin Kaduk wrote: > >> Though future GSS-API extensions may add new uses of asynchronous > >> security context tokens and ways to process them, applications > >> using the GSS-API version 2, update 1, should generally call > >> GSS_Delete_sec_context() after calling GSS_Process_context_token(), > >> when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. > > > > I don't like the wording of this part. Encouraging applications to > > assume that context tokens destroy the context essentially closes the > > door to specifying context tokens which don't. > > Let me rephrase this objection: > > I think the scope of this erratum should be limited to making it > possible for conforming gss_process_context_token implementations to > convey peer error token information to callers. As Ben said yesterday, > the inability to do so is a clear defect in the spec, which makes it > appropriate fodder for an erratum. This rationale for excluding the above is less objectionable to me than the original. I would rather say what the application should do in the GSS_S_COMPLETE/FAILURE cases, and I thought (and still thing) that "should generally" or some such weasel verbiage ought to be an acceptably non-normative way to do this. But if this is the only way to make progress on this erratum, I'll accept it. > The proposed text goes beyond that scope by giving guidance on how to > respond to GSS_S_COMPLETE. That guidance assumes that async context > token types are limited to the ones mentioned in section 2.2.4: > (deletion tokens and error tokens resulting from the final synchronous > token). Because this assumption does not match my reading of the > existing text, I don't think providing such additional guidance about > GSS_S_COMPLETE is appropriate for an erratum. I also don't think > clarifying this point is important enough to justify a document revision. I think that the [mostly implied, in the base GSS RFCs and our work since then] that the extensibility model for the GSS-API (the API _and_ the protocol pattern it sets out) is such that the door to the sorts of extensions you had in mind is closed without negotiation of their use. That means that the possible unexpected context tokens can only be error and context deletion tokens unless the application (and mechanism) negotiate the availability of new unexpected context token types (e.g., via a req_flag/ret_flag). If there's no consensus as to the GSS extensibility model then I think it's fair to say that there's no consensus to include the above text in the erratum, but if there is consensus as to the GSS extensibility model then I don't see much reason to reject the above text -- just a question of expediency. I do think it's better to give guidance here -even the opposite of that which I'd give- than none. Finally, if there's no consensus as to the GSS extensibility model then we're going to have more problems in the future. I don't know what we can do about that without more (and more active) participants to help define a consensus about a GSS extensibility model in a future RFC. Nico -- From nobody Thu Dec 18 14:09:34 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1511A8AAB for ; Thu, 18 Dec 2014 14:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcPg_rRHCfHY for ; Thu, 18 Dec 2014 14:09:30 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6431A8AE7 for ; Thu, 18 Dec 2014 14:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1418940570; x=1420150170; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/lloEgsVpqe4KQ643hyQ3O+i0VF7tawWbUG/y9sZGbI=; b=iLqgfPdsWOlpbe7J6nG4+SFn1WjQqmzKDm0cM/ac2xqujK9XDN6vrZhp WW+1afixzJcc2eawSrOhgr9HCexuvanSEZN87r8xYHmWCnDKvz1GoqyaY HWaUbcIi8pb1GUZczX8wCFgJa38v6YS9PlGX0/TW1JilfotL6GnOqVVI/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAAxQk1StJV2R/2dsb2JhbABbgwZSWASDAsMVhXoCgSYWAQEBAQF9hA0BAQQjVRELGgIFFgsCAgkDAgECAUUGDQgBAYgouRiWKwEBAQEBAQEDAQEBAQEBAQEWBIEhjh46gmiBQQEEiUOCcIUVhTKBDYRxiAyDOCKCAByBcE+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,603,1413244800"; d="scan'208";a="106687301" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 18 Dec 2014 22:09:29 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBIM9T1N008074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Dec 2014 22:09:29 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Dec 2014 16:09:29 -0600 Message-ID: <54935098.5040501@cisco.com> Date: Thu, 18 Dec 2014 15:09:28 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <546F5E3C.1010207@cisco.com> In-Reply-To: <546F5E3C.1010207@cisco.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.63] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/t7DkyQWfCfWu96Eh-4UiHB62cPA Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 22:09:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, The Working Group Last Call of draft-ietf-kitten-gss-loop-01 completed on Friday, 12 December. The Chairs and Editor believe all comments have been addressed in the latest version < draft-ietf-kitten-gss-loop-02 > . The Chairs will be requesting IESG publication soon. Thanks to all for the feedback. - - Your kitten chairs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUk1CYAAoJEDWi+S0W7cO1qwUIAIVbpsD6sxVRmzVLHC5mZsva D1X/RjCMTmXHAvDnyDuPU6Nt6OIeldQsGbyqBdkzbCFlHKqPCWniBSfrB0GHr99g WTEzF/JFnkreHfnvLLQQWQ/1j8tVNfMaepQkxJVTcfKapq13cWe3h9SciRB7pqdU 0vUr9afFsN5r8Y8L0wwC3ELvV2E3w76qA7V8z9rLgFnQwtjmW69b3rAnEm8IJsF2 qE3rxaZ1dHnU3cMDprUlUn+tJr0OE5Kv6zdmS/D/Xt3Rv7IwxJesBsCE4Xf1u9A0 SyJZd5mcmQYFUuQgt8GqaNeDCb5w1mc46Dm8m01+2YVtXMEdzQxc5VDMzFCpgII= =IkwO -----END PGP SIGNATURE----- From nobody Fri Dec 19 16:16:44 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718A41A8A3B for ; Fri, 19 Dec 2014 16:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ-3IwYnhqaD for ; Fri, 19 Dec 2014 16:16:40 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE2D1ACE7D for ; Fri, 19 Dec 2014 16:16:40 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 269A821DE6A; Fri, 19 Dec 2014 16:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2tNdCShLbu6zn5 3oXQ0nN903/LQ=; b=jhOIkz+jnF/sMkvNcOltblJH4WPa/N5SHifys1mhIqhFs8 TXynbJacgHiEaSpQxVru5h7i7og6c6HCGcqbZeFedc/zvHfayM1xCNm90k5eRfXK dSRogB2Tc9X4plq5d3fIexmLmGBrKkAIpFZfzLFMibtjXnGdP+3uEqoRQGW4g= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id B598321DE65; Fri, 19 Dec 2014 16:16:39 -0800 (PST) Date: Fri, 19 Dec 2014 18:16:38 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141220001633.GD12662@localhost> References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> <20141217230505.GD9443@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141217230505.GD9443@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/bkbrYhCicq37uXVZ-wck8cPyu20 Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 00:16:42 -0000 On further thought, since context deletion tokens are obsoleted, and have been for a long time, we might as well say nothing about GSS_S_COMPLETE implying that the peer is done using its side of the security context. The GSS_S_FAILURE case, however, still kinda leads to the caller being done. OLD PROPOSED TEXT | Though future GSS-API extensions may add new uses of asynchronous | security context tokens and ways to process them, applications | using the GSS-API version 2, update 1, should generally call | GSS_Delete_sec_context() after calling GSS_Process_context_token(), | when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. NEW: | Applications should generally call GSS_Delete_sec_context() when | GSS_Process_context_token() returns GSS_S_FAILURE. Nico -- From nobody Wed Dec 24 12:57:16 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955881A1AD8 for ; Wed, 24 Dec 2014 12:57:14 -0800 (PST) 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 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 1agA_7kA_wQi for ; Wed, 24 Dec 2014 12:57:12 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F9E1A1A96 for ; Wed, 24 Dec 2014 12:57:11 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-4d-549b28a6e2d0 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 dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A6.7F.03354.6A82B945; Wed, 24 Dec 2014 15:57:10 -0500 (EST) 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 sBOKvAbw014956; Wed, 24 Dec 2014 15:57:10 -0500 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 sBOKv7Ka028080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Dec 2014 15:57:09 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBOKv7jY029107; Wed, 24 Dec 2014 15:57:07 -0500 (EST) Date: Wed, 24 Dec 2014 15:57:07 -0500 (EST) 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+NgFmpkleLIzCtJLcpLzFFi42IRYrdT112mMTvE4EmHucWhC8cZLY5uXsVi 8a+bz4HZY8mSn0werTv+snt8ufyZLYA5issmJTUnsyy1SN8ugStj0tefrAX72SqWTrvF2MC4 nLWLkZNDQsBEYter7VC2mMSFe+vZuhi5OIQEFjNJ/D0+HcrZyCix9MdPdgjnEJPE+/O3oJwG RomTv6czdzFycLAIaEvcfcwOMopNQEVi5puNbCC2iICwxO6t75hBbGYBD4m5c5awgJQLC7hK XDxmDhLmFHCSuNT1AKycV8BRYtLs02C2EIj9fwsTiC0qoCOxev8UFogaQYmTM5+wQIzUklg+ fRvLBEbBWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgKXU5J /h2M3w4qHWIU4GBU4uE9ED8rRIg1say4MvcQoyQHk5Io7zf22SFCfEn5KZUZicUZ8UWlOanF hxglOJiVRHjfqwDleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeIvU gRoFi1LTUyvSMnNKENJMHJwgw3mAhveD1PAWFyTmFmemQ+RPMepyLGjfP5NJiCUvPy9VSpy3 EKRIAKQoozQPbg4s5bxiFAd6S5i3AqSKB5iu4Ca9AlrCBLRE6tZ0kCUliQgpqQZGO9WLmb5O stPjp2w4silln2AZS4n/tjs+2/rvVTn2Mxa2/18pJ9ltlmGWzxvALvXHRNj1kc/lN1mq0g45 lpvb9zbkH8k6EDHpolbY4XVf99hseuO0he2EsRzDj+vSp5JyHq1pXTttA+f3e6o7+5vUl9Tn fuB/8jBvz/4G6RX/8/I9f2kUCe5SYinOSDTUYi4qTgQA/hLYWBQDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/t0Nl3PN6qkH1qNepyGbc3xtRqPU Cc: kitten-chairs@tools.ietf.org, Michiko Short Subject: Re: [kitten] Call for Adoption: draft-short-pkinit-freshness X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 20:57:14 -0000 Thanks to all who responded. Michiko, please submit the next revision as draft-ietf-kitten-pkinit-freshness-00. Thanks, Ben On Mon, 1 Dec 2014, Benjamin Kaduk wrote: > The chairs are considering adopting draft-short-pkinit-freshness [0] as a > kitten draft. We would like to solicit comments on whether to adopt this > draft. Since it updates RFC 4556, it seems clear that it needs to be > standards-track, but feel free to comment on that as well, if you wish. > > Please submit comments by December 19th, 2014, either to the chairs or to > the list. > > -Ben, for the kitten co-chairs > > [0] https://tools.ietf.org/html/draft-short-pkinit-freshness-00 > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Mon Dec 29 09:12:52 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDAA1A89FE; Mon, 29 Dec 2014 09:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZYP1UCdPCPC; Mon, 29 Dec 2014 09:12:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 053CC1A87BB; Mon, 29 Dec 2014 09:12:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229171240.971.24324.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 09:12:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RnzDRe0hf2I7VHw9ghV7lJGoLvY Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-12.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:12:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Authors : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-12.txt Pages : 38 Date : 2014-12-29 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-saml-ec-12 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 Dec 29 09:27:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBB41A887E for ; Mon, 29 Dec 2014 09:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ty2lrrYNkTA for ; Mon, 29 Dec 2014 09:27:00 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290271A888B for ; Mon, 29 Dec 2014 09:27:00 -0800 (PST) Received: from BL2FFO11FD026.protection.gbl (10.173.160.34) by BL2FFO11HUB033.protection.gbl (10.173.161.113) with Microsoft SMTP Server (TLS) id 15.1.49.13; Mon, 29 Dec 2014 17:26:52 +0000 Received: from cio-krc-pf05.osuad.osu.edu (164.107.81.212) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Mon, 29 Dec 2014 17:26:52 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-krc-pf05.osuad.osu.edu (Postfix) with ESMTPS id 138146003D for ; Mon, 29 Dec 2014 12:26:52 -0500 (EST) Received: from CIO-TNC-HT08.osuad.osu.edu (2002:a46b:51b1::a46b:51b1) by CIO-TNC-HT05.osuad.osu.edu (2002:a46b:51a8::a46b:51a8) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 29 Dec 2014 12:26:51 -0500 Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT08.osuad.osu.edu ([fe80::8431:784b:bd14:3d8%18]) with mapi id 14.03.0174.001; Mon, 29 Dec 2014 12:26:51 -0500 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-12.txt Thread-Index: AQHQI4qwAwQZaeL2pUuLaUQBlv7iU5ym0i6A Date: Mon, 29 Dec 2014 17:26:51 +0000 Message-ID: <8C695AC1-CC85-46AC-8D0A-9494514D03B7@osu.edu> References: <20141229171240.971.24324.idtracker@ietfa.amsl.com> In-Reply-To: <20141229171240.971.24324.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.59.103] Content-Type: text/plain; charset="utf-8" Content-ID: <02ECEA1F8080F843AD95CBDDBF956BF0@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.212 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.212; helo=cio-krc-pf05.osuad.osu.edu; Authentication-Results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=cantor.2@osu.edu; X-Forefront-Antispam-Report: CIP:164.107.81.212; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377424004)(24454002)(377454003)(479174004)(199003)(106116001)(230783001)(4396001)(19580395003)(6806004)(19580405001)(50466002)(16796002)(86362001)(2950100001)(76176999)(54356999)(47776003)(33656002)(46102003)(450100001)(120916001)(83716003)(66066001)(106466001)(20776003)(21056001)(87936001)(90282001)(88552001)(64706001)(89122001)(75432002)(107046002)(92566001)(99396003)(102836002)(23676002)(2656002)(107886001)(82746002)(31966008)(77156002)(109096001)(110136001)(2351001)(2501002)(93346002)(36756003)(50986999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB033; H:cio-krc-pf05.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; PTR:cio-krc-pf05.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB033; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BL2FFO11HUB033; X-Forefront-PRVS: 0440AC9990 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB033; X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Dec 2014 17:26:52.3364 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.212] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB033 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ioIgdW9dFSWSZZP-5AZm8s8MfrY Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-12.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:27:04 -0000 QXBvbG9naWVzIGZvciB0aGUgOSBtb250aCBkZWxheSwgYnV0IEkndmUgZmluYWxseSBwcm9kdWNl ZCBhIG5ldyBkcmFmdCBpbiANCnJlc3BvbnNlIHRvIGNvbW1lbnRzIGZyb20gU2FtIGFuZCBvdGhl cnMgYmFjayBpbiBNYXJjaCAodGhyZWFkIG5hbWUgDQpjb21tZW50cyBvbiBkcmFmdC1pZXRmLWtp dHRlbi1zYXNsLXNhbWwtZWMsIHN0YXJ0ZWQgYnkgU2FtKS4NCg0KTW9zdCBpbXBvcnRhbnRseSwg dGhpcyBjb3JyZWN0cyBhIG5vcm1hdGl2ZSBlcnJvciBieSBjaGFuZ2luZyB0aGUgDQpkZXBlbmRl bmN5IG9uIHRoZSA0MTYxIGVuY3R5cGUgbmFtZXMgaW50byBudW1iZXJzLg0KDQpJIGF0dGVtcHRl ZCB0byBhZGRyZXNzIGFsbCBvZiB0aGUgY29tbWVudHMgaW4gb25lIGZvcm0gb3IgYW5vdGhlciwg YnV0IA0KaXQncyBiZWVuIGxvbmcgZW5vdWdoIHRoYXQgdGhpcyBuZWVkcyBhIGZyZXNoIHJldmll dyBhbnl3YXkuDQoNCi0tIFNjb3R0DQoNCk9uIDEyLzI5LzE0LCA1OjEyIFBNLCAiaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiANCjxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+ DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIA0KPmRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBDb21tb24gQXV0aGVudGljYXRpb24gVGVjaG5vbG9neSBOZXh0IA0KPkdlbmVyYXRp b24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAg ICA6IFNBTUwgRW5oYW5jZWQgQ2xpZW50IFNBU0wgYW5kIEdTUy1BUEkgTWVjaGFuaXNtcw0KPiAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogU2NvdHQgQ2FudG9yDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICBTaW1vbiBKb3NlZnNzb24NCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1r aXR0ZW4tc2FzbC1zYW1sLWVjLTEyLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAzOA0KPglEYXRl ICAgICAgICAgICAgOiAyMDE0LTEyLTI5DQo= From nobody Tue Dec 30 12:38:37 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1707B1A6EF2 for ; Tue, 30 Dec 2014 12:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_nhhhwKkbMd for ; Tue, 30 Dec 2014 12:38:34 -0800 (PST) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F9E1A1BB0 for ; Tue, 30 Dec 2014 12:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419971913; bh=f37pAZCRFq3vk5WQao/+wp7Rk2iEaC2QJyf/GkTKwqo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kn4m9ebjqnNbJpJkehC5u7TYshaa6k7Z0YD2FM+vgiVdZ1LwrZRZOYOzLmqJI5I/YJSOtUkgbNiffi2TnPxH2vpi5nu0RkhO9UKRFFICrNwP86TvCZ6H4aVOud3kxXkvlSLQqoYU1l0gpZbWtuGDOo2uNffJmUpGaV+3FX8dI5nDbQfpAUbOfdtOfHoAEqkmrELFzhghGvO9NtvkLJ3CnffiSxCyvCRplYESZP9o9uaJA4zli9b7yNylP/TXhkYCtrUsIeIKMB8HKbhzuzf5beIo5zbMpt/YtZuDakz7IPsPwYbPX/AYF3FRUJixtIsDw471BgWjH01F4UTLsxYwWg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=rWECN/nTVu4t9TC4y38de7Kl7jZh1u1UPpFGaRn+G1tVqhaiM2eEt9NtPNlsEN/Razdz+4ffjjl1G/nbd2Q7dJazLYCFkmn1hftGHw5MszBXGwwSDkVsQxz6HIc6WX6UQCr0FeaPhSX/IaeL6giuf3x/O6gQJG+8xkgWwN/5uscx/zcvShTFQ+SpM/n9ITd69BS1DHZwpU3hgh0jKv2/iDmyEpH4RRQaTBuI3xyygupP69bkWdFHuBpaSV9rI3NP9iNWyAPPezQW2AjSiE5WT5hsAN/A6HbSSbd2sZK7DCm5SklMgf9Htq+PTZ97dRXjNzp3okhgzsReQhRKKR+fzQ==; Received: from [98.139.212.151] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 30 Dec 2014 20:38:33 -0000 Received: from [98.139.212.243] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 30 Dec 2014 20:38:33 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 30 Dec 2014 20:38:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 459182.42835.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: lbdZxskVM1nrVw9raUtopDTzepdenO7wJrJE4s3Rpe8QvIQNC5JedFrBgjLnD2R GCii.uJHYZdOLvdM.2pgQZWQqtXUvwGbDqkS_ZDJCqdoH44QGzRypAdpwW63.u9FKMAYFG87fGVn G47kAVB5yBptKLvU5VTR6qZ72LXXex7PtoPCgcFcie9T6bArxOlhflmy8T8kg7Ydg77donErYVuU 2uZQ217nSOkEh2gtSjblER.TK_d885asjXKBJgFEYUfobcEFPVuVPoDMGDC7flhqS95BFvys9Hze Gs4UO2kmA1i7VRtfq6t1C_yXomCrt1wrHT7nwez9sDItJu5dzcglgDVhtAnKFRdEpe8qsrd5cPL3 5V36W5AjLcfsD6q9AjxIn4yRvrRFZQWGYoybb4M.JYBomOIlKxhaJzJDrlNCGWZvCNv4r4sVD7hC VPHeu60ioqar5vwJL5blijvge_h1SpCSS65SvgsrHFGfHkebc1q_VAxc.vFXh5Z2KBniGXSBh75U SO7ekfSYg.BRPuXnQts4AiLfm8Jt1jT3ZR6RsASZlXrTbYcR1RUEHLqtMUh4EEHmiIaP62YQuUos WbguUwed3ZXzqHjkGEkr8 Received: by 66.196.80.119; Tue, 30 Dec 2014 20:38:33 +0000 Date: Tue, 30 Dec 2014 20:38:32 +0000 (UTC) From: Bill Mills To: Kitten WG Message-ID: <749113922.2852173.1419971912627.JavaMail.yahoo@jws106105.mail.bf1.yahoo.com> In-Reply-To: <1032414067.649954.1419971840703.JavaMail.yahoo@jws10650.mail.bf1.yahoo.com> References: <36433644-59A7-4E02-A841-AEC3D0087BD6@ve7jtb.com> <1032414067.649954.1419971840703.JavaMail.yahoo@jws10650.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2852172_2010701344.1419971912621" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/R2D_trvu_T13TFCQvNCLr-4ARsQ Subject: [kitten] Fw: [OAUTH-WG] Fwd: WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 20:38:36 -0000 ------=_Part_2852172_2010701344.1419971912621 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, December 30, 2014 12:37 PM, Bill Mills wrote: =20 Thank you both for the feedback.=20 On Tuesday, December 30, 2014 5:28 AM, John Bradley wrote: =20 I have been tracking it.=C2=A0 It is ready.=20 Sent from my iPhone > On Dec 15, 2014, at 2:33 PM, Benjamin Kaduk wrote: >=20 > Hi all, >=20 > There may be some interested parties over here; please feel free to chime > in on this WGLC over on the kitten list. >=20 > -Ben >=20 > ---------- Forwarded message ---------- > Date: Mon, 15 Dec 2014 12:14:30 -0500 > From: Benjamin Kaduk > To: kitten@ietf.org > Cc: kitten-chairs@tools.ietf.org > Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 >=20 > This message begins the fourth Working Group Last Call (WGLC) of "A set o= f > SASL Mechanisms for OAuth" .=C2=A0 D= ue to > the overlap of the last call period with holidays, the duration of the > WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. > The draft is available at: >=20 > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 >=20 > Because the changes between -15 and -18 involve behavior changes, > including changes regarding discovery and dynamic registration, the Chair= s > decided to issue an additional last call. >=20 > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the co-chairs < kitten-chairs > at tools.ietf.org > before the end of the WGLC.=C2=A0 Any and all comment= s > on the document are sought in order to access the strength of > consensus.=C2=A0 Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again.=C2=A0 This is > particularly important if you found issues with the previous version. >=20 > 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. >=20 >=20 > - Your Kitten Chairs >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------=_Part_2852172_2010701344.1419971912621 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
On Tuesday, December 30, 2014 = 12:37 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

Thank you both for the feedback.
=


On Tuesday, December 30, 2014 = 5:28 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
<= /font>


I have been= tracking it.  It is ready.

Sent= from my iPhone

> On Dec 15, 2014, = at 2:33 PM, Benjamin Kaduk <k= aduk@MIT.EDU> wrote:
>
> = Hi all,
>
> There may be some in= terested parties over here; please feel free to chime
>= ; in on this WGLC over on the kitten list.
>
> -Ben
>
> --------= -- Forwarded message ----------
> Date: Mon, 15 Dec 20= 14 12:14:30 -0500
> From: Benjamin Kaduk <kaduk@MIT.EDU>
>= ; To: kitten@ietf.org
> Cc: kitten-chairs@tools.ietf.org
> = Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18
>
> This message begins the fourth Working Group = Last Call (WGLC) of "A set of
> SASL Mechanisms for OA= uth" <draft-ietf-kitten-sasl-oauth-18.txt>.  Due to
> the overlap of the last call period with holidays, the duration = of the
> WGLC is extended to four weeks, so the WGLC w= ill end on 12 January 2015.
> The draft is available a= t:
>
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oa= uth-18
>
> Because the chang= es between -15 and -18 involve behavior changes,
> inc= luding changes regarding discovery and dynamic registration, the Chairs
> decided to issue an additional last call.
>
> Please review the document and send comme= nts to the Working Group
> mailing list < kitten at= itef.org > or the co-chairs < kitten-chairs
> a= t tools.ietf.org > before the end of the WGLC.  Any and all comment= s
> on the document are sought in order to access the = strength of
> consensus.  Even if you have read a= nd commented on this or earlier
> versions of the draf= t, please feel free to comment again.  This is
> = particularly important if you found issues with the previous version.
>
> As a reminder, comments can be an= ything from "this looks fine" to
> "this is a horrible= idea"; they can include suggestions for minor
> edito= rial corrections to significant editorial changes.
> <= br clear=3D"none">>
> - Your Kitten Chairs
>
> ___________________________________= ____________
> Kitten mailing list
&= gt; Kitten@ietf.org
> https://www.ietf.org/mail= man/listinfo/kitten
>
> ____= ___________________________________________
> OAuth ma= iling list
> OAuth@ietf.org
> = https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




------=_Part_2852172_2010701344.1419971912621-- From nobody Wed Dec 31 11:27:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A291A1A15 for ; Wed, 31 Dec 2014 11:27:25 -0800 (PST) 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 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 Y2QAHMrjI5nc for ; Wed, 31 Dec 2014 11:27:23 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7555E1A1A11 for ; Wed, 31 Dec 2014 11:27:23 -0800 (PST) X-AuditID: 12074422-f79476d000000d9e-92-54a44e1a0de6 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B2.E4.03486.A1E44A45; Wed, 31 Dec 2014 14:27:22 -0500 (EST) 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 sBVJRLOw004790; Wed, 31 Dec 2014 14:27:22 -0500 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 sBVJRJxt002286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Dec 2014 14:27:21 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBVJRJSV022186; Wed, 31 Dec 2014 14:27:19 -0500 (EST) Date: Wed, 31 Dec 2014 14:27:19 -0500 (EST) 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+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrSvltyTEYPllQ4tDF44zWhzdvIrF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MqYP2seY8Efnor/X9ayNzAe4Opi5OSQEDCR uLW0kRXCFpO4cG89WxcjF4eQwGImifcfOpghnI2MEo33D0FlDjFJTF6ziQnCaWCUmPbvPBNI P4uAtkTnjc8sIDabgIrEzDcb2UBsEQFhid1b3zGD2MwCChKb+/eyg9jCArYS+7/sAevlFHCS uPLoM5jNK+Aosfz+O7AaISD76LUmsF5RAR2J1funsEDUCEqcnPmEBWKmlsTy6dtYJjAKzkKS moUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQsLK7KO1g/HlQ6RCj AAejEg9vg83iECHWxLLiytxDjJIcTEqivH22S0KE+JLyUyozEosz4otKc1KLDzFKcDArifD2 yQHleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeE18gRoFi1LTUyvS MnNKENJMHJwgw3mAhu/wARleXJCYW5yZDpE/xagoJc7LAdIsAJLIKM2D64Ulk1eM4kCvCPOu AGnnASYiuO5XQIOZgAbnb1oMMrgkESEl1cAYNP+L+a2X+8LO+3vsZPyY3fc6vfzC65DVx4qz ZC7LdNyuW3NbOp9vQvHiOceTWCfNtvnQYX/0/AvBL+fWmTxcY9YXt+ah6cUWpnb2R1a1zG8X P5xbcmbL36ftjC6/WuuzG2ZMCjy44NDa2pMGEhdMI3ZtqdP6lLuuv3MSi5d72fzf3pnTHZas VmIpzkg01GIuKk4EAHvZwN0BAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qENjR3j6NU6hjHW6BVBuE4EXZBk Cc: kitten-chairs@tools.ietf.org Subject: Re: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 19:27:25 -0000 We've gotten some "looks good"s on the oauth list, for those only on kitten@. Just under two weeks remain in the last call period. -Ben On Mon, 15 Dec 2014, Benjamin Kaduk wrote: > This message begins the fourth Working Group Last Call (WGLC) of "A set of > SASL Mechanisms for OAuth" . Due to > the overlap of the last call period with holidays, the duration of the > WGLC is extended to four weeks, so the WGLC will end on 12 January 2015. > The draft is available at: > > https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 > > Because the changes between -15 and -18 involve behavior changes, > including changes regarding discovery and dynamic registration, the Chairs > decided to issue an additional last call. > > Please review the document and send comments to the Working Group > mailing list < kitten at itef.org > or the co-chairs < kitten-chairs > at tools.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 > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Dec 31 11:27:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F01A1A29; Wed, 31 Dec 2014 11:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgrJKjns6jTD; Wed, 31 Dec 2014 11:27:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7401A1A25; Wed, 31 Dec 2014 11:27:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231192738.17828.48638.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 11:27:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2zL4ExvHob1JoNcO6wR4kkFuLhA Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gss-loop-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 19:27:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Structure of the GSS Negotiation Loop Author : Benjamin Kaduk Filename : draft-ietf-kitten-gss-loop-03.txt Pages : 20 Date : 2014-12-31 Abstract: This document specifies the generic structure of the negotiation loop to establish a GSS security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application- specific behavior must be specified. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-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 Dec 31 11:29:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1431E1A1A1F for ; Wed, 31 Dec 2014 11:29:04 -0800 (PST) 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 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 yIWl8gPEKOL7 for ; Wed, 31 Dec 2014 11:29:02 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B001A1A11 for ; Wed, 31 Dec 2014 11:29:02 -0800 (PST) X-AuditID: 1209190d-f79006d000000cfe-51-54a44e7dd60c 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 dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.4E.03326.D7E44A45; Wed, 31 Dec 2014 14:29:01 -0500 (EST) 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 sBVJT0Xg004923 for ; Wed, 31 Dec 2014 14:29:01 -0500 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 sBVJSwMY002681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 Dec 2014 14:29:00 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBVJSwEF022393; Wed, 31 Dec 2014 14:28:58 -0500 (EST) Date: Wed, 31 Dec 2014 14:28:58 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20141231192738.17828.48638.idtracker@ietfa.amsl.com> Message-ID: References: <20141231192738.17828.48638.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrVvrtyTEYNUEQYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/uuJpaC/bwVF5dPY2lgvM3VxcjJISFgInG78wEThC0mceHe erYuRi4OIYHFTBIzDv5igXCOM0rsenCfGcK5wSTx/cI9KKeBUeLi/+1sIP0sAtoSd7YsYwWx 2QRUJGa+2QgWFxEQlti99R0ziC0s4CzROfk9WA2ngJPE8it7wXbzCjhKTPl3lR3EFgKy5+2/ CVYjKqAjsXr/FBaIGkGJkzOfgNnMAloSy6dvY5nAKDALSWoWktQCRqZVjLIpuVW6uYmZOcWp ybrFyYl5ealFukZ6uZkleqkppZsYwQEoybuD8d1BpUOMAhyMSjy8N+wWhwixJpYVV+YeYpTk YFIS5e2zXRIixJeUn1KZkVicEV9UmpNafIhRgoNZSYS3Tw4ox5uSWFmVWpQPk5LmYFES5930 gy9ESCA9sSQ1OzW1ILUIJivDwaEkwbvDF6hRsCg1PbUiLTOnBCHNxMEJMpwHaPgSkBre4oLE 3OLMdIj8KUZFKXHefpCEAEgiozQPrheWIF4xigO9Isy7AKSKB5hc4LpfAQ1mAhqcv2kxyOCS RISUVAOjWVH6fcO/az984JiwbOGeiAvilVPnOAT+/HPl7yKN7coha+6ctdLwfHmzZqn1E5/F yRY3mx88P/r51ZNP+64zff+2/WqCU36DmdEhe2az9TUOnvd+i6w9ZqTr+S3g/ulXJssn2nYJ KBjp/A9wXZsW4t97/nhsns7ZbWu+sO/hsmWpy5Wua4rMV2Ipzkg01GIuKk4EAHvdqsjrAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zJRhz8WPgQxN68Q3c2zHhX8PWwE Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gss-loop-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 19:29:04 -0000 This version addresses some formatting nits and minor internal inconsistencies found during shepherd review. -Ben On Wed, 31 Dec 2014, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Structure of the GSS Negotiation Loop > Author : Benjamin Kaduk > Filename : draft-ietf-kitten-gss-loop-03.txt > Pages : 20 > Date : 2014-12-31 > > Abstract: > This document specifies the generic structure of the negotiation loop > to establish a GSS security context between initiator and acceptor. > The control flow of the loop is indicated for both parties, including > error conditions, and indications are given for where application- > specific behavior must be specified. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-loop/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-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/ > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Dec 31 14:34:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77ECF1A1A52 for ; Wed, 31 Dec 2014 14:34:17 -0800 (PST) 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 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 bb8nsWGojAF6 for ; Wed, 31 Dec 2014 14:34:16 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id D56C01A1A4D for ; Wed, 31 Dec 2014 14:34:15 -0800 (PST) X-AuditID: 12074422-f79476d000000d9e-93-54a479e7501a 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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.2D.03486.7E974A45; Wed, 31 Dec 2014 17:34:15 -0500 (EST) 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 sBVMYEL8002273; Wed, 31 Dec 2014 17:34:14 -0500 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 sBVMYCIZ015379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Dec 2014 17:34:13 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBVMYB6A015648; Wed, 31 Dec 2014 17:34:11 -0500 (EST) Date: Wed, 31 Dec 2014 17:34:11 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141220001633.GD12662@localhost> Message-ID: References: <20141124185114.GM3200@localhost> <20141209215519.GI12979@localhost> <20141210002441.GP12979@localhost> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu> <20141217230505.GD9443@localhost> <20141220001633.GD12662@localhost> 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+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrvu8ckmIwa87vBZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXR+eM1S8FH7opDi+MbGA9ydjFyckgImEgc 7tnGBmGLSVy4tx7I5uIQEljMJNH28BcLSEJIYCOjRMf2aIjEISaJn03v2CGcBkaJ1/37mbsY OThYBLQlriwUAWlgE1CRmPlmI9hUEQFNievzlrKBlDALGElc+JUBEhYGCu/8eosVxOYU0Jf4 M/8pmM0r4Chx/vAdqCOOMUusONTPDJIQFdCRWL1/CgtEkaDEyZlPwGxmAS2J5dO3sUxgFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4DB1UdrB+POg0iFG AQ5GJR7eBpvFIUKsiWXFlbmHGCU5mJREeTWSl4QI8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHt kwPK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8K6oAGoULEpNT61I y8wpQUgzcXCCDOcBGi5cCTK8uCAxtzgzHSJ/ilFRSpz3KUizAEgiozQPrheWRl4xigO9Iszb ClLFA0xBcN2vgAYzAQ3O37QYZHBJIkJKqoHRd8FN3Xt3z/YwNs8JOm/VUXpB59nEFxv9imX3 fL6rzqjNqaBvzjyT+61uw37F2foh76NmhpZs5sxkWPjwlJDswtsuZ47ev/9S9McmK8MXLdfe LcnmCNG48WhF+w2NZtWAysX3Z1XVTWhczTjd7lzCkei6bP7tZ5/Zbfe+Y1morvd4ncKV8zPK lFiKMxINtZiLihMBc8xCbP4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qQicNbX3yVQTQb_AFhdaRBx-IDg Cc: kitten@ietf.org Subject: Re: [kitten] RFC2743 errata 4251 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 22:34:17 -0000 On Fri, 19 Dec 2014, Nico Williams wrote: > > On further thought, since context deletion tokens are obsoleted, and > have been for a long time, we might as well say nothing about > GSS_S_COMPLETE implying that the peer is done using its side of the > security context. The GSS_S_FAILURE case, however, still kinda leads to > the caller being done. > > OLD PROPOSED TEXT > | Though future GSS-API extensions may add new uses of asynchronous > | security context tokens and ways to process them, applications > | using the GSS-API version 2, update 1, should generally call > | GSS_Delete_sec_context() after calling GSS_Process_context_token(), > | when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE. > > NEW: > | Applications should generally call GSS_Delete_sec_context() when > | GSS_Process_context_token() returns GSS_S_FAILURE. I suppose I could live with this, but I still don't see how it's actually adding enough to merit inclusion in an erratum. That is, the application is going to be calling GSS_Delete_sec_context() eventually anyway, so we're just saying that failures of Process_context_token() should (generally) fail the whole context (immediately). Would application authors (generally) do anything else upon presented with a GSS_S_FAILURE from Process_context_token()? It seems like it is just calling out a specific case of what people should already be doing, which is not tied to the key component of the erratum. -Ben