From nobody Sat Nov 1 00:33: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 C650D1A8840 for ; Sat, 1 Nov 2014 00:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mFWakIit7eT6 for ; Sat, 1 Nov 2014 00:32:58 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD771A19F5 for ; Sat, 1 Nov 2014 00:32:58 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 40D4A20024944 for ; Sat, 1 Nov 2014 00:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JsoIknfd7/5p34Jdx/bG 9z47RNc=; b=XTP3MKLg5fCkgUylxq6lnhx23po4dxXmMATO2S9ImPWuVdbFyYd4 5epvmqqO6pSyf/PV6eD1k4WKse7uWt3fukFe9BbrT/BejS46mLQTB7lBLJO/u+UA s3HERFwbVWO6GFgTYBuMMyzaztyoqKvOyRtAHV8BBeNm2qLTzYlRjC8= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id E5A0120024943 for ; Sat, 1 Nov 2014 00:32:57 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id q5so2907177wiv.4 for ; Sat, 01 Nov 2014 00:32:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr2433868wie.28.1414827176747; Sat, 01 Nov 2014 00:32:56 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Sat, 1 Nov 2014 00:32:56 -0700 (PDT) In-Reply-To: <20141101060755.GB7913@localhost> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> Date: Sat, 1 Nov 2014 02:32:56 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: multipart/alternative; boundary=bcaec53d5f0f49e8cb0506c71fa0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/prESXoPetJ5HaKv4rkBw7yTTfZM Cc: Kitten WG Subject: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 01 Nov 2014 07:33:00 -0000 --bcaec53d5f0f49e8cb0506c71fa0 Content-Type: text/plain; charset=UTF-8 The ambiguity in GSS_Process_context_token() may be easily resolved, perhaps: it returns GSS_S_COMPLETE when a context deletion token is processed correctly, and a minor status indicating something about what happend, and if the context was terminated by the async context token, then the application will find out on the next GSS call, which should preferably be one to GSS_Inquire_context(), or from the way the error token was framed by the peer. --bcaec53d5f0f49e8cb0506c71fa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The ambiguity in GSS_Process_context_token() may be easily resolved, perhap= s: it returns GSS_S_COMPLETE when a context deletion token is processed cor= rectly, and a minor status indicating something about what happend, and if = the context was terminated by the async context token, then the application= will find out on the next GSS call, which should preferably be one to GSS_= Inquire_context(), or from the way the error token was framed by the peer. --bcaec53d5f0f49e8cb0506c71fa0-- From nobody Sat Nov 1 07:55:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56F01A88AE for ; Sat, 1 Nov 2014 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7lvzYAL_vcN7 for ; Sat, 1 Nov 2014 07:55:36 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15791A0126 for ; Sat, 1 Nov 2014 07:55:35 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-75-5454f4662406 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 12.C7.27750.664F4545; Sat, 1 Nov 2014 10:55:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sA1EtSAi011092; Sat, 1 Nov 2014 10:55:29 -0400 Received: from [18.101.8.237] (vpn-18-101-8-237.mit.edu [18.101.8.237]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sA1EtQuF028162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Nov 2014 10:55:28 -0400 Message-ID: <5454F45E.1030508@mit.edu> Date: Sat, 01 Nov 2014 10:55:26 -0400 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: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> In-Reply-To: <20141101060755.GB7913@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrpv2JSTEYPcDPYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYd/cMc8Fi2YpPhzezNzA+Fe9i5OSQEDCR 6D92hA3CFpO4cG89mC0kMJtJYskBmS5GLiB7A6PEzRUPGCGcw0wSX1cuZASp4hVQk9j5cT5z FyMHB4uAqsSmB8YgYTYBZYn1+7eygIRFBcIkpi7lgagWlDg58wkLiC0ioClxfd5SsF3MAvYS h16sALOFBawlHp7YwAyx6gGjxMz+x2AJTgE9ia5tL6Aa9CR2XP/FCmHLSzRvnc08gVFwFpId s5CUzUJStoCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuoV5uZoleakrpJkZQ+HJK8uxgfHNQ 6RCjAAejEg/vB8uQECHWxLLiytxDjJIcTEqivH2PgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eAsfAOV4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4mz4DNQoWpaan VqRl5pQgpJk4OEGG8wANlwGp4S0uSMwtzkyHyJ9iVJQS5/UBSQiAJDJK8+B6YenlFaM40CvC vHNAqniAqQmu+xXQYCagwY5dYINLEhFSUg2MRhutfW31mf46hsy7FbdR++T8qQK77igs79R6 klBxVHRq0ML71r+Lt9X83XX3hcnhGwdXNJq+PeDrF5S0izVU7ZQrz/uHMZ9SJ7bmBvNnNrPq bNgr+ET27L6UgEWJBkkztHSOz1Mq2LV1zqJPXPHt8zvNq97P23xmlpyzbgqP8Ur1I1qJHks2 KLEUZyQaajEXFScCAMthI/kKAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/xVFp98eV_R9ZIUcp_AnPp7vJMbA Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 01 Nov 2014 14:55:38 -0000 Responding point-by-point is causing miscommunication (specifically, in several places you assumed that I was arguing with you when I was agreeing), so I am going to address just one point and then re-summarize the gss_process_context_token issue. On 11/01/2014 02:07 AM, Nico Williams wrote: > If we're not out to improve the state of the world, then what are we > doing. This draft was conceived of as a document that application protocol specs can refer to so that they don't have to go on at length about how implementations should perform GSS context negotiation. As such, it is informational and does not update RFC 2743. It sounds like you oppose publication of a document with only that scope, and instead want a normative document with the ability to clarify and perhaps even change RFC 2743. I do not have a strong opinion on this question. I agree that better diagnostics would be possible if, when processing the last message in an exchange, an endpoint could generate an error token to be processed by the other endpoint after context establishment. However: 1. I believe that mechanisms are not currently doing that (though I only have high certainty with regard to the krb5 mech). 2. I believe with high certainty that applications are not currently doing that. The search results for gss_process_context_token are all provider, no consumer. 3. I believe that some--perhaps most--GSS-using protocols, do not even have a way to transport such error tokens. 4. The RFC 2743 specification of gss_process_context_token is broken for this purpose (and for any purpose), in the following ways: * It suggests that the token might result in context termination, but does not specify that this always occurs. It does not give the caller a way to know whether the context is still alive or not. It does not specify whether the caller should still release the handle with gss_delete_sec_context afterwards. * It does not admit a way to communicate error information from a token to the caller. We can reasonably amend the specification of gss_process_context_token to address these flaws, and then document that future protocols should allow it and future implementations should do it. In order to do so with the gss-loop document, we would need to expand its scope such that it is standard-track and updates RFC 2743. If we decide to do that, then there are a few options for how we fix it. Modifying the function signature in the C bindings is not reasonable, so we must assume the current signature which does not allow us to null out the caller's context handle. Therefore, that handle must remain a valid C pointer (or table index or whatever, but real-world implementations use pointers), and the caller must eventually call gss_delete_sec_context to release it. The remaining questions are: * Should the caller assume that the context is dead (except for needing to be released), or should it make no such assumption? If the former, should it assume that for all major return codes or only for some? I do not have a strong preference yet. If the latter, I think we all agree that future calls on that context handle (other than gss_delete_sec_context) should result in GSS_S_NO_CONTEXT. * Should properly validated error tokens result in GSS_S_COMPLETE with a minor code, in GSS_S_FAILURE specifically, or in perhaps any of the major codes which gss_init/accept_sec_context could return on an error token? The first option is weird for GSSAPI. The third option is the most programmatically informative to the caller, and is no less cleanly delineated than the error results for init/accept_sec_context, so that would be my preference. From nobody Sat Nov 1 14:59: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 814DA1A1AF8 for ; Sat, 1 Nov 2014 14:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxiSwLSylnuY for ; Sat, 1 Nov 2014 14:59:41 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA511A1AE4 for ; Sat, 1 Nov 2014 14:59:41 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 2B07E2C806B; Sat, 1 Nov 2014 14:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=C10Aek4YTCOruI l/j3kHAHDzXfA=; b=bqABNF0iWodrpa586kS+Rg3EYCY57V6xUL6lovgv2cupts 2IsYqJpa0U7k7ttZC+u70LzpxKMsx34Bgz9OQWREBGS/gGGrmf/2HDfg8eTkQ9rK P4xZ0loFaB8f+vKzZt7Hy5Sr5BI20YjJxEVob3MspAoh7s4hYMeXvLeCNX3+c= 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 CEF8D2C8058; Sat, 1 Nov 2014 14:59:40 -0700 (PDT) Date: Sat, 1 Nov 2014 16:59:40 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20141101215938.GC7913@localhost> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5454F45E.1030508@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mlYqRtfQIGaokWDAIeEMwvop7yY Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 01 Nov 2014 21:59:42 -0000 On Sat, Nov 01, 2014 at 10:55:26AM -0400, Greg Hudson wrote: > On 11/01/2014 02:07 AM, Nico Williams wrote: > > If we're not out to improve the state of the world, then what are we > > doing. > > This draft was conceived of as a document that application protocol > specs can refer to so that they don't have to go on at length about how > implementations should perform GSS context negotiation. As such, it is > informational and does not update RFC 2743. It sounds like you oppose I'm not proposing that we update RFC2743. I'm pointing out where this I-D diverges from RFC2743. You're not ackowledging this. Please address that point without reference to anyone's desire, real or imagined, to update RFC2743. (Perhaps you thought that my asides about the ambiguities I see in RFC2743 were me calling for updating it. They weren't.) Nico -- From nobody Sat Nov 1 15:39: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 412B71A1B89 for ; Sat, 1 Nov 2014 15:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 55vVp5NlnFOO for ; Sat, 1 Nov 2014 15:39:30 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054AD1A1B8B for ; Sat, 1 Nov 2014 15:39:29 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-0e-545561201bd3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D3.34.13180.02165545; Sat, 1 Nov 2014 18:39:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sA1MdNIC019935; Sat, 1 Nov 2014 18:39:23 -0400 Received: from [18.101.8.237] (vpn-18-101-8-237.mit.edu [18.101.8.237]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sA1MdLii018133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Nov 2014 18:39:22 -0400 Message-ID: <54556118.4070902@mit.edu> Date: Sat, 01 Nov 2014 18:39:20 -0400 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: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> <20141101215938.GC7913@localhost> In-Reply-To: <20141101215938.GC7913@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT0VVIDA0xeLvF3OLo5lUsFqeuHWFz YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKu32hiKVjHWrHhbjtzA+Mmli5GTg4JAROJ 7s79TBC2mMSFe+vZuhi5OIQEZjNJ7Ft0lBHC2cAoMXXXGhYI5zCTxOFXDYwgLbwCahLzF3wG sjk4WARUJfbuiQEJswkoS6zfv5UFJCwqECYxdSkPRLWgxMmZT8AWiwhoSlyft5QNxGYWsJc4 9GIFmC0sYC3x8MQGZohVc5kkbr8+B9bAKaAncefMB3aIBj2JHdd/sULY8hLb385hnsAoOAvJ jllIymYhKVvAyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10wvN7NELzWldBMjOIBdlHcw/jmo dIhRgINRiYfX0yYkRIg1say4MvcQoyQHk5Ior7dHaIgQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed6qeKAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr3ICUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8Dtgw4sLEnOLM9Mh8qcYdTlamt72Mgmx5OXnpUqJ864FKRIAKcoo zYObA0s8rxjFgd4S5n0KUsUDTFpwk14BLWECWuLYFQKypCQRISXVwKjYtfpHzPUyz+oGAUvD Qw9D5hzJ+fbnz8X0JV8Cqot9CtXfGLOvFZvelbZ+77aCaV9yF90V1mjP4u9MusKS2q+7/MB7 G3u99EfxnsnBlqIfblf4Luac2NDySnmPz8qzp4RWaM8JqGAq3mJrvvzH9oM+gXp+vxdauxd+ PxDuXnzu2dFyk81HVJRYijMSDbWYi4oTAYMT9KAXAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3RciLlf676HNXBp_4gCRcKRa4x8 Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 01 Nov 2014 22:39:32 -0000 On 11/01/2014 05:59 PM, Nico Williams wrote: > I'm not proposing that we update RFC2743. > > I'm pointing out where this I-D diverges from RFC2743. You're not > ackowledging this. I acknowledge that RFC 2743 does mention post-establishment error tokens in its description of gss_process_context_token. However, this part of RFC 2743 is broken (not ambiguous, broken) and everyone ignores it. According to the current spec, an application calling gss_process_context_token (1) does not receive error information from the token, and (2) does not know whether the context handle is still active and whether it is allowed to make further calls on that handle to find out. From nobody Sun Nov 2 14:06: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 6E00A1A1A43 for ; Sun, 2 Nov 2014 14:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPiM4rrdk0bM for ; Sun, 2 Nov 2014 14:06:02 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 694271A1A31 for ; Sun, 2 Nov 2014 14:06:02 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 320711B4058 for ; Sun, 2 Nov 2014 14:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fp9OEVgpu7pCU16DDyFr FqBJQRw=; b=iPcC3EvCrJAxgW6+czbjBfp6F+oBHt1yrADeeZxh/thbtTGqml3w PI+7IhoKP/yU8JxA0zc2RTwrEiUa5FN7pNM9IviDdWh3wGqgaGlJ4LCv9Nvrxi/x W69K6CRWGG3r8jZx/kbEKj+Me1R+f1cAx0VgIhbM2ZhbQ67JVp0A/8E= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id D9DEC1B4057 for ; Sun, 2 Nov 2014 14:06:01 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x13so11175425wgg.8 for ; Sun, 02 Nov 2014 14:06:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.85.229 with SMTP id k5mr41767113wjz.19.1414965960807; Sun, 02 Nov 2014 14:06:00 -0800 (PST) Received: by 10.216.32.135 with HTTP; Sun, 2 Nov 2014 14:06:00 -0800 (PST) In-Reply-To: <54556118.4070902@mit.edu> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> <20141101215938.GC7913@localhost> <54556118.4070902@mit.edu> Date: Sun, 2 Nov 2014 16:06:00 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/InsOTKT7joQ3M9KOxwCtdiQX35c Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 02 Nov 2014 22:06:04 -0000 On Sat, Nov 1, 2014 at 5:39 PM, Greg Hudson wrote: > On 11/01/2014 05:59 PM, Nico Williams wrote: >> I'm not proposing that we update RFC2743. >> >> I'm pointing out where this I-D diverges from RFC2743. You're not >> ackowledging this. > > I acknowledge that RFC 2743 does mention post-establishment error tokens > in its description of gss_process_context_token. However, this part of > RFC 2743 is broken (not ambiguous, broken) and everyone ignores it. > According to the current spec, an application calling > gss_process_context_token (1) does not receive error information from > the token, and (2) does not know whether the context handle is still > active and whether it is allowed to make further calls on that handle to > find out. [Now we're communicating.] I don't agree. First, the application can get error token information in the minor status code result from GSS_Process_context_token(). Nothing in the two RFCs prohibits returning a non-zero minor status code when returning GSS_S_COMPLETE as the major status code. Second, both existing cases of asynchronous context tokens denote that the context is no longer usable (though GSS_Process_context_token() does not itself delete the security context). I don't see the problem. Nico -- From nobody Sun Nov 2 14: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 0DD551A1A83 for ; Sun, 2 Nov 2014 14:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.656 X-Spam-Level: * X-Spam-Status: No, score=1.656 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBPGWdhSQPZp for ; Sun, 2 Nov 2014 14:13:47 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 80E031A1A81 for ; Sun, 2 Nov 2014 14:13:47 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 5783920202C for ; Sun, 2 Nov 2014 14:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3wLVslXTpIAkMTGGa8Ud CeJcIBs=; b=hAHkgjakinKMQmTnNzj+lbo747K2n9GPf6MtjZZckPabVkIPvWGA rZb7Q/idXqjIdl5/swZhaUqfhmSwTlpbbEjtaTmFTUtmETRRIkG4b03SeJWCWrkR p/lWfD4BnM8ZZ9LMZE9Af2ifzPXSVJ17Js2ShOGytJdJHn3guTuKlF4= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 01FF0202022 for ; Sun, 2 Nov 2014 14:13:46 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so9781374wgg.23 for ; Sun, 02 Nov 2014 14:13:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr11961072wid.70.1414966425730; Sun, 02 Nov 2014 14:13:45 -0800 (PST) Received: by 10.216.32.135 with HTTP; Sun, 2 Nov 2014 14:13:45 -0800 (PST) In-Reply-To: References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> <20141101215938.GC7913@localhost> <54556118.4070902@mit.edu> Date: Sun, 2 Nov 2014 16:13:45 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3WQTH4O5iiOi7UhV07KoxBsl7hk Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 02 Nov 2014 22:13:48 -0000 I.e, I think RFC2743 is not sufficiently specific as to how async error tokens are handled, but it's clear that they can occur, and there's enough text to strongly imply the missing details, and the simplest interpretation turns out to be simple enough. To ignore this would be akin to making this I-D update RFC2743. Nico -- From nobody Sun Nov 2 16:09:20 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 66AD61ACE43 for ; Sun, 2 Nov 2014 16:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 qpPLQsqPGlnw for ; Sun, 2 Nov 2014 16:09:15 -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 227A91A8A4B for ; Sun, 2 Nov 2014 16:09:14 -0800 (PST) X-AuditID: 12074424-f79346d000004923-91-5456c7a9282d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.76.18723.9A7C6545; Sun, 2 Nov 2014 19:09:13 -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 sA309DLs020815; Sun, 2 Nov 2014 19:09: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 sA309BkB005653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Nov 2014 19:09:12 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA309AFN016771; Sun, 2 Nov 2014 19:09:10 -0500 (EST) Date: Sun, 2 Nov 2014 19:09:10 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141031231321.GA7913@localhost> Message-ID: References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@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+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrrvyeFiIQecNc4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4cIel4KdzxaQLM5gaGM+YdDFyckgImEhs /DaTDcIWk7hwbz2QzcUhJDCbSWL/np1QzgZGibdbNjFCOAeZJL7N6GMHaRESqJc42X6MEcRm EdCSWLrqFJjNJqAiMfPNRrCxIgKaEtfnLQWzmQXkJZ6t6QazhQWsJR6e2MAMYnMK6EmsubuY CcTmFXCUONLQzQKxbDGjxN9708GWiQroSKzeP4UFokhQ4uTMJywQQ7Uklk/fxjKBUXAWktQs JKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL9FJTSjcxgkPVRWUHY/MhpUOMAhyM Sjy8ElvDQoRYE8uKK3MPMUpyMCmJ8i6aARTiS8pPqcxILM6ILyrNSS0+xCjBwawkwlu5FijH m5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBq3MMqFGwKDU9tSItM6cE Ic3EwQkynAdouC9IDW9xQWJucWY6RP4Uo6KUOO/vo0AJAZBERmkeXC8slbxiFAd6RZhXHqSd B5iG4LpfAQ1mAhrs2BUCMrgkESEl1cDI3flqu9Pq1boeBsYnFdh2Wi1xuMmgtf3MtmNOJV9X GMim8re+LRNaJ3ll5uHcy4e9zQX1jOYKWd6acPu+bkzzk552ifbpB7Qmv3J+XJCVmCDNW5a5 yukhx42QvakmpsqXqn/63fD7uoH/+HdetsvdmyVmyEmdlWlONRN59U1G+L606I4ZTjJKLMUZ iYZazEXFiQDPOeyVAAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/jELFfrX21O_D9VgrWa5WZ9gxywc Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 00:09:18 -0000 I'll try to trim bits that have been elucidated by later parts of the thread. On Fri, 31 Oct 2014, Nico Williams wrote: > On Fri, Oct 31, 2014 at 05:58:05PM -0400, Benjamin Kaduk wrote: > > On Mon, 27 Oct 2014, Nico Williams wrote: > > > > - We should say, in the intro, something about the expectation that the > > > application will add such things as: > > > > > > - authentication + authorization success/failure messages > > > > I'm not entirely convinced about this. We don't even necessarily know > > that there is a user to see such messages. > > The message could be a boolean (success/fail), but it's necessary in > many (but not all) applications. I've started leaning towards thinking that it's worth finding a place to list some things that are required of an application (protocol) using the GSS-API which are not otherwise mentioned in the rest of the document; things like authorization checks and the ability to convey error information. > > > - Section 2.3, what is a "synchronous TCP channel"? > > That's very non-obvious. You want an antonym for "multiplexed", I > think. I went with "dedicated". > > [...]. How > > about: > > The application protocol may also include a facility for > > indicating errors from one party to the other, which can be > > used to convey errors resulting from GSS-API calls, when > > appropriate. Note that GSS major and minor status codes > > are specified by language bindings, not the abstract API, > > so may not be directly interpretable by the other peer. [lots of diatribe trimmed] So, this text is supposed to be about what the application (protocol) does *when it didn't get an error token from the GSS implementation*. If you get a token, of course send it, but there can be situations where the local state is in error but there is no token to send. It's still useful to convey some error information in this case, and that's most of what the "when appropriate" is supposed to be saying. > "...should assume that the [peer's] state is invalid..." just strikes > me as really weird. Developers understand "timeout". How about "state is invalid (time out)"? > You can list them if you like, but please say that all request flags > must be kept the same throughout. Currently this is like "the initiator specifies as part of its fixed set of inputs to GSS_Init_sec_context() values for [the list of flags] (and any additional request flags [...])". The key part being the "fixed set of inputs", i.e., yes, they should be kept the same throughout. The email exchanges we've been having are making me wonder if that should be made more prominent. > > Applications using per-message operations > > on a partially complete security context should take into > > consideration the fact that replay protection is not avaiable > > from the GSS-API for those messages, and take the appropriate > > protective measures. > > You also need to say that they shouldn't send data requiring > confidentiality protection (since at the time the per-message token is > sent the peer may not yet be authenticated). A good point. (I might not oppose just removing all treatment of per-message operations on a partically complete context, since this document is informational only...) [discussion of error context token trimmed] Some other messages in this thread (which I won't go find and quote) seem to imply that you think applications will have trouble with GSS context exchanges involving an odd number of tokens; the whole point of this document is to provide clear guidance to application protocol designers such that they can handle the fully generic case, whether it is an odd or even number of tokens in the exchange. I furthermore think that we are agreed that new application protocols being developed should include provision for sending error tokens occuring on processing of the last regular context token (regardless of whether existing protocols do or existing mechanism implementations generate such tokens). The main disagreement centers around process_context_token, which I will cover in a reply to a later message in the thread. [GSS_ERROR()] There are three occurrences of the string "GSS_ERROR" in this document; two are in the sample code, and the third is: [sample code is written in C.] It uses the macro GSS_ERROR() to help unpack the various sorts of information which can be stored in the major status field; supplementary information does not necessarily indicate an error. Applications written in other languages will need to exercise care that checks against the major status value are written correctly. I could add a note here that GSS_ERROR() should not be used for per-message token operations (and say why that is the case in the security considerations), or I could remove its use entirely. I'm still undecided what I think is best. If I understand correctly, you prefer to remove its use entirely. In some sense, I guess this is a conflict between being formally correct as per 2743 and 2744, and operating securely with current best practices. > > > - Why not mention authorization (use a stub function) and > > > application-level status message in do_acceptor()? > > > > I believe there were previous discussions around this, and Greg convinced > > me that such checks fit more naturally outside of do_acceptor(), which > > should just be about establishing the context. This may be another case > > where guidance on the use of the GSS-API is lacking, but this document is > > not the appropriate place to rectify that. > > This is asking for a security vulnerability. We must teach proper use > of the API. > > > The closest we get is to pass &client_name to gss_accept_sec_context(), > > which we then proceed to not do anything with. > > Just add a call to a stub function. Another issue with trying to cover this is that we get into the rabbit-hole of whether to do "the right thing" and maintain a local database of exported names, or just do string processing on the display name. > > > - This: > > > > > > } else { > > > /* This situation is forbidden by RFC 2743. Bail out. */ > > > warnx("major not complete or continue but not error\n"); > > > goto cleanup; > > > } > > > > > > would be an internal error, not behavior forbidden by RFC2743, > > > because you break out of the loop in this case before ever getting > > > here. You should either assert() or ignore this. > > > > Hmm? I think this case covers at least a major status code with > > no fatal error codes set but a per-message-token informatory status code > > set, which is indeed forbidden by 2743. > > Right, which answers your question about as to GSS_ERROR(). Don't use > GSS_ERROR(). Instead treat any GSS_S_COMPLETE-with-supplementary- > status-codes-other-than-GSS_S_CONTINUE_NEEDED as errors. It's easier, > it's less code, easier to explain. I think I've realized why this makes me uncomfortable -- we only provide sample code with the C bindings, but there are other language bindings (Java is specified, and I hear there is work on python bindings in progress); these other language bindings may not use the same representation for the major status values, and the assumptions that are valid in C may not remain valid if the sample code is translated to a different language. > > > - What about mentioning the possible need to check -on the acceptor > > > side- the name of the acceptor as used by the initiator? That's a > > > gss_inquire_context() call to get the name of the acceptor, then a > > > gss_compare_name() function call (or any of the other methods of > > > comparing names given in RFC2743). > > > > "What is the possible need for that check?" > > Consider an application with keys for many principals in its keytab... Did you answer Greg's question about what it would be compared to? Oh, yes, you did (with several alternatives). I think at present I'm inclined to not give a detailed treatment of this subject, and rather mention that applications which can accept context using different names (such as by using the default credential set) may need to introspect the name of the acceptor as specified by the initiator to enforce local policy (possibly with more details in the security considerations). -Ben From nobody Sun Nov 2 17:08:09 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 CA0EC1ACE8C for ; Sun, 2 Nov 2014 17:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 8UWwIJRp-Fiv for ; Sun, 2 Nov 2014 17:08:04 -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 9F8421ACE8A for ; Sun, 2 Nov 2014 17:08:04 -0800 (PST) X-AuditID: 12074423-f799d6d00000337c-ec-5456d5731f72 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 31.C2.13180.375D6545; Sun, 2 Nov 2014 20:08: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 sA31825s026570; Sun, 2 Nov 2014 20:08:03 -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 sA3181Ia026376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Nov 2014 20:08:02 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA3180Rb024023; Sun, 2 Nov 2014 20:08:00 -0500 (EST) Date: Sun, 2 Nov 2014 20:08:00 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> <20141101215938.GC7913@localhost> <54556118.4070902@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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrVt8NSzEYNVKJYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4/O0IY8FErorW9T+YGxjXcnQxcnJICJhI TL05hxXCFpO4cG89WxcjF4eQwGwmifm9v8ASQgIbGCWevReFSBxkknj2aCITRKJe4vHk52wg NouAlsTye/cYQWw2ARWJmW82gsVFBDQlrs9bCmYzC8hLPFvTDWYLC1hLPDyxgRnE5hQIlFjR fRpsGa+Ao8TXfVuYIJb9Z5KYefs0WIOogI7E6v1TWCCKBCVOznzCAjEUaPH0bSwTGAVnIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdMLzezRC81pXQTIyhU2V2UdzD+Oah0iFGA g1GJh7dge1iIEGtiWXFl7iFGSQ4mJVHeRTOAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4K9cC 5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHibrwA1ChalpqdWpGXm lCCkmTg4QYbzAA3XAKnhLS5IzC3OTIfIn2JUlBLnlQRJCIAkMkrz4HphqeQVozjQK8K8pSBV PMA0BNf9CmgwE9Bgx64QkMEliQgpqQbGxqntatqKZwwCTbY/S1/E9KC4aH/3b9vcp//MeE3v eui0Cx87w7ermq/txs1br5OKhdo5GGZ1XWm8p6Txkdf5wOV+p4M65rLfzAvmnde5uNVrI8sn 0QnPcybplan6PTn+xy/KxvGBoPbTH353D0nc5zh8jK+juv1LGovDj0751UfCq+tWr2VRYinO SDTUYi4qTgQAV4OOkgADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UYDWeuHSc6NQZOXkWhLmgZBEtaw Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 01:08:07 -0000 On Sun, 2 Nov 2014, Nico Williams wrote: > First, the application can get error token information in the minor > status code result from GSS_Process_context_token(). Nothing in the > two RFCs prohibits returning a non-zero minor status code when > returning GSS_S_COMPLETE as the major status code. I think that Martin's gsstest program complains about it, though :) > Second, both existing cases of asynchronous context tokens denote that > the context is no longer usable (though GSS_Process_context_token() > does not itself delete the security context). > > I don't see the problem. It seems somewhat debatable whether GSS_Process_context_token() deletes the security context (viz. the last paragraph of page 5, which you noted previously); the contraints of the C bindings' API means that it should not do so, just ~render the context handle unusable. Hmm, the Java bindings don't have a process_context_token at all. I think that the behavior we should recommend to applications is to call GSS_Process_context_token(), followed immediatly by GSS_Inquire_context(), and GSS_Delete_sec_context() as appropriate (at present: always), to provide reasonable behavior and be future-proof. That said, is it even within the scope of the gss-loop document? -Ben From nobody Mon Nov 3 08:03: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 A5C231A19E2 for ; Mon, 3 Nov 2014 08:03:01 -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 3MlPKhdzc5oK for ; Mon, 3 Nov 2014 08:03:00 -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 B42951A040B for ; Mon, 3 Nov 2014 08:02:52 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 8532120047D32; Mon, 3 Nov 2014 08:02:52 -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=5WqTLJeWLivqLl c3GMIwN7Oktkc=; b=wPZJjf4f647S26E1ZR2L0CfVZBr7a/mb8g934AGihn257J HP7sUyzqKiRSFjFnnNHzWsaTR/exDiB2rc56TyGBoMbxGdkH+deXLH1DgnHD4JtK hjUD8Bw8Ad8THo9CZ0vewv5TQ91xQcAhXshMn7f/KAyCH3ObRjg7AqU80SEik= 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 2BA6D20047D12; Mon, 3 Nov 2014 08:02:52 -0800 (PST) Date: Mon, 3 Nov 2014 10:02:51 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141103160249.GD7913@localhost> References: <543EA410.5000508@cisco.com> <20141027203931.GA16952@localhost> <20141031231321.GA7913@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/x5O0fTlfDKEKYJcGXLCNC-f_PPM Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 16:03:02 -0000 On Sun, Nov 02, 2014 at 07:09:10PM -0500, Benjamin Kaduk wrote: > On Fri, 31 Oct 2014, Nico Williams wrote: > > On Fri, Oct 31, 2014 at 05:58:05PM -0400, Benjamin Kaduk wrote: > > > On Mon, 27 Oct 2014, Nico Williams wrote: > > I've started leaning towards thinking that it's worth finding a place to > list some things that are required of an application (protocol) using the > GSS-API which are not otherwise mentioned in the rest of the document; > things like authorization checks and the ability to convey error > information. :) > > > [...]. How > > > about: > > > The application protocol may also include a facility for > > > indicating errors from one party to the other, which can be > > > used to convey errors resulting from GSS-API calls, when > > > appropriate. Note that GSS major and minor status codes > > > are specified by language bindings, not the abstract API, > > > so may not be directly interpretable by the other peer. > > [lots of diatribe trimmed] > > So, this text is supposed to be about what the application (protocol) does > *when it didn't get an error token from the GSS implementation*. Oh, I guess I misunderstood that. My apologies. > If you get a token, of course send it, but there can be situations where > the local state is in error but there is no token to send. It's still > useful to convey some error information in this case, and that's most of > what the "when appropriate" is supposed to be saying. Sending a minor status code is never appropriate. Major status codes convey very little information. My advice in that case is to optionally send the display form of the two status codes, along with the major status code numeric value. > > "...should assume that the [peer's] state is invalid..." just strikes > > me as really weird. Developers understand "timeout". > > How about "state is invalid (time out)"? Fine. > > You can list them if you like, but please say that all request flags > > must be kept the same throughout. > > Currently this is like "the initiator specifies as part of its fixed set > of inputs to GSS_Init_sec_context() values for [the list of flags] (and > any additional request flags [...])". The key part being the "fixed set > of inputs", i.e., yes, they should be kept the same throughout. > > The email exchanges we've been having are making me wonder if that should > be made more prominent. I'd noticed that text. I'd a reason to ask for a change, but it may have gotten lost. My proposal: OLD: The initiator specifies as part of its fixed set of inputs to GSS_Init_sec_context() values for the following booleans: deleg_req_flag, mutual_req_flag, replay_det_req_flag, sequence_req_flag, conf_req_flag, and integ_req_flag. Upon .. NEW: The initiator specifies as part of its fixed set of inputs to GSS_Init_sec_context() values for all defined request flag booleans, among them: deleg_req_flag, mutual_req_flag, replay_det_req_flag, sequence_req_flag, conf_req_flag, and integ_req_flag. Upon ... The point is that this is an open set. > > You also need to say that they shouldn't send data requiring > > confidentiality protection (since at the time the per-message token is > > sent the peer may not yet be authenticated). > > A good point. (I might not oppose just removing all treatment of > per-message operations on a partically complete context, since this > document is informational only...) I wouldn't either! PROT_READY is a neat feature, but it is optional and difficult to use safely, therefore it seems best to not mention it here. > [discussion of error context token trimmed] > > Some other messages in this thread (which I won't go find and quote) seem > to imply that you think applications will have trouble with GSS context > exchanges involving an odd number of tokens; the whole point of this > document is to provide clear guidance to application protocol designers > such that they can handle the fully generic case, whether it is an odd or > even number of tokens in the exchange. I furthermore think that we are > agreed that new application protocols being developed should include > provision for sending error tokens occuring on processing of the last > regular context token (regardless of whether existing protocols do or > existing mechanism implementations generate such tokens). Agreed. > The main disagreement centers around process_context_token, which I will > cover in a reply to a later message in the thread. > > [GSS_ERROR()] > > There are three occurrences of the string "GSS_ERROR" in this document; > two are in the sample code, and the third is: > [sample code is written in C.] It uses the macro GSS_ERROR() to > help unpack the various sorts of information which can be stored in the > major status field; supplementary information does not necessarily > indicate an error. Applications written in other languages will > need to exercise care that checks against the major status value > are written correctly. > > I could add a note here that GSS_ERROR() should not be used for > per-message token operations (and say why that is the case in the > security considerations), or I could remove its use entirely. I'm still > undecided what I think is best. If I understand correctly, you prefer to > remove its use entirely. In some sense, I guess this is a conflict > between being formally correct as per 2743 and 2744, and operating > securely with current best practices. I believe that GSS_ERROR() was in fact intended for use with per-message token functions (gss_unwrap() and gss_verify_mic()): otherwise why ignore supplementary major status code bits that are only relevant to those functions? However, it was a bad idea. Too many application protocol implementors used GSS_ERROR() -without checking the supplementary status code bits- when they intended to implement an octet stream. Octet streams are incompatible with any supplementary status code bits from those functions. In practice many application protocols using the GSS-API want an octet stream. The GSS_ERROR() macro should have had a second parameter indicating whether an octet stream is intended. Then it wouldn't have been dangerous. The best thing we can do is tell developers never to use GSS_ERROR() when intending to consume an octet stream. FYI, I've seen this bug in: - a couple of SASL GS1 implementations - at least two FTP w/ GSS implementations - at least one non-standard GSS application > > > The closest we get is to pass &client_name to gss_accept_sec_context(), > > > which we then proceed to not do anything with. > > > > Just add a call to a stub function. > > Another issue with trying to cover this is that we get into the > rabbit-hole of whether to do "the right thing" and maintain a local > database of exported names, or just do string processing on the display > name. I think we can simply refer to the relevant sections of RFC2743 and RFC6680. > I think I've realized why this makes me uncomfortable -- we only provide > sample code with the C bindings, but there are other language bindings > [...] Good point. > > Consider an application with keys for many principals in its keytab... > > Did you answer Greg's question about what it would be compared to? Oh, > yes, you did (with several alternatives). :) At least two sshd implementations do something about this, IIRC. > I think at present I'm inclined to not give a detailed treatment of this > subject, and rather mention that applications which can accept context > using different names (such as by using the default credential set) may > need to introspect the name of the acceptor as specified by the initiator > to enforce local policy (possibly with more details in the security > considerations). I agree. A small amount of text and references to relevant sections in RFC2743 should suffice. Something like: When using the default credential handle to accept security contexts, the mechanism is free to accept contexts for any name for which the acceptor has credentials. This might be problematic. Acceptor applications can check what target name the initiator used, but the details are out of scope for this document. See RFC2743 sections 2.2.6 and 1.1.5, and RFC6680. Nico -- From nobody Mon Nov 3 08:06: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 BAD281A19F5 for ; Mon, 3 Nov 2014 08:06:14 -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 yOnErYlr_pSL for ; Mon, 3 Nov 2014 08:06:13 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C28001A19F4 for ; Mon, 3 Nov 2014 08:06:12 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 79D714012D697; Mon, 3 Nov 2014 08:06:12 -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=rUphROLTfA3k0F XbzweKfhzP1AM=; b=s5XdeF3vYAul1mBinUs0hN2264v+V+kAJuMW9+5XiVnuQd DvQiYQOaETKq/knDhCWrVM02VO8IAcpsxJLF1f/ePrByrbJJUGCcHhl2Vgu/TG7I P0P4i8pmLsSJStfsgFpA3oX1VqB+FrbWF5k1zH3+dMsH3x39pdDtkdrSEssVE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 29EFE4012D696; Mon, 3 Nov 2014 08:06:12 -0800 (PST) Date: Mon, 3 Nov 2014 10:06:11 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141103160609.GE7913@localhost> References: <20141027203931.GA16952@localhost> <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> <20141101215938.GC7913@localhost> <54556118.4070902@mit.edu> 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/XX8SqxawD0RTOGkarks8MKh_tGU Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 16:06:15 -0000 On Sun, Nov 02, 2014 at 08:08:00PM -0500, Benjamin Kaduk wrote: > On Sun, 2 Nov 2014, Nico Williams wrote: > > First, the application can get error token information in the minor > > status code result from GSS_Process_context_token(). Nothing in the > > two RFCs prohibits returning a non-zero minor status code when > > returning GSS_S_COMPLETE as the major status code. > > I think that Martin's gsstest program complains about it, though :) But is it normative? :) > > Second, both existing cases of asynchronous context tokens denote that > > the context is no longer usable (though GSS_Process_context_token() > > does not itself delete the security context). > > > > I don't see the problem. > > It seems somewhat debatable whether GSS_Process_context_token() deletes > the security context (viz. the last paragraph of page 5, which you noted > previously); the contraints of the C bindings' API means that it should > not do so, just ~render the context handle unusable. Hmm, the Java > bindings don't have a process_context_token at all. The C bindings gss_process_context_token() cannot delete the security context. For the abstract GSS_Process_context_token() it's a bit less clear, but that's OK: this is the sort of detail that is OK to leave to the various programming language bindings. > I think that the behavior we should recommend to applications is to call > GSS_Process_context_token(), followed immediatly by GSS_Inquire_context(), > and GSS_Delete_sec_context() as appropriate (at present: always), to > provide reasonable behavior and be future-proof. I agree. > That said, is it even within the scope of the gss-loop document? I think so. Nico -- From nobody Mon Nov 3 10:02: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 311CF1A1B56 for ; Mon, 3 Nov 2014 10:02:11 -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 NMqS60ZBzvXK for ; Mon, 3 Nov 2014 10:02:10 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 704191A1B3D for ; Mon, 3 Nov 2014 10:02:10 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 430ACBBA05C; Mon, 3 Nov 2014 10:02:10 -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=TbVQK8uhF3cj4m CIOmMEzq9NH6A=; b=JLp8TtGJW6xC9+DGqVzS1IGqYZPkRQPw1APU+K6bl2rUzx YirroxnJWWMCTBaSRGrGl/W7EGKuMOQMRjviymqSTSoB66d1CP6yc9+zRBJU10fm 3nfcyuqAzqaINwYqYjWieurv12YLVNywgJb5kwa0etsYTQvC/GAQpvN9KvhUE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id C9249BBA065; Mon, 3 Nov 2014 10:02:09 -0800 (PST) Date: Mon, 3 Nov 2014 12:02:09 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141103180207.GG7913@localhost> References: <20141031231321.GA7913@localhost> <545435FF.9030502@mit.edu> <20141101060755.GB7913@localhost> <5454F45E.1030508@mit.edu> <20141101215938.GC7913@localhost> <54556118.4070902@mit.edu> <20141103160609.GE7913@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103160609.GE7913@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7wNDj6JfEsd2o-dzLP0TA_iiaEM Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 18:02:11 -0000 On Mon, Nov 03, 2014 at 10:06:11AM -0600, Nico Williams wrote: > On Sun, Nov 02, 2014 at 08:08:00PM -0500, Benjamin Kaduk wrote: > > On Sun, 2 Nov 2014, Nico Williams wrote: > > > First, the application can get error token information in the minor > > > status code result from GSS_Process_context_token(). Nothing in the > > > two RFCs prohibits returning a non-zero minor status code when > > > returning GSS_S_COMPLETE as the major status code. > > > > I think that Martin's gsstest program complains about it, though :) > > But is it normative? :) BTW, RFC2744 says that minor_status is always set, and it doesn't define any numeric values for it, not even "no error", not even zero. Therefore I think gsstest is wrong to complain about it. From nobody Mon Nov 3 13:33: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 BB75F1A06FD for ; Mon, 3 Nov 2014 13:33:35 -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 ssP805KXoHoq for ; Mon, 3 Nov 2014 13:33:30 -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 25F571A049A for ; Mon, 3 Nov 2014 13:33:29 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 23BC43A6F1; Mon, 3 Nov 2014 22:33:27 +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 01C1B43607; Mon, 3 Nov 2014 22:33:26 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EBF1B1AF8D; Mon, 3 Nov 2014 22:33:26 +0100 (CET) In-Reply-To: <5454F45E.1030508@mit.edu> To: Greg Hudson Date: Mon, 3 Nov 2014 22:33:26 +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: <20141103213326.EBF1B1AF8D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VMRGnUSc7kZHj_je67JF4QmyXdY Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 21:33:35 -0000 Greg Hudson wrote: > Responding point-by-point is causing miscommunication (specifically, in > several places you assumed that I was arguing with you when I was > agreeing), so I am going to address just one point and then re-summarize > the gss_process_context_token issue. > > > I agree that better diagnostics would be possible if, when processing > the last message in an exchange, an endpoint could generate an error > token to be processed by the other endpoint after context establishment. I assume you are referring to "last [context level] message in an exchange" here? > However: > > 1. I believe that mechanisms are not currently doing that (though I only > have high certainty with regard to the krb5 mech). AFAIK, Microsoft Kerberos has been trying to do this for the last 14years, and has been trying to mislead the context acceptor about the error nature of the token by indicating the equivalent of CONTINUE_NEEDED to get the calling server app to transfer the token to the client. > > 2. I believe with high certainty that applications are not currently > doing that. The search results for gss_process_context_token are all > provider, no consumer. Few apps, if any, do that. Ours does not. My gsskrb5 wrapper even peeks inside kerbers context tokens to detect camouflaged kerberos error tokens so that the calling (server) app gets to see that there was an error. Microsoft runs its own TLS implementation under a GSS-API style interface, and you notice from Microsoft IIS never sending fatal alerts upon handshake failures before closing the network connections that apps typically ignore error tokens. > > 3. I believe that some--perhaps most--GSS-using protocols, do not even > have a way to transport such error tokens. Probably true. Even mine does not have it. (While I do have a possibility to run a new context handshake to replace an expiring or expired gss context). > > 4. The RFC 2743 specification of gss_process_context_token is broken for > this purpose (and for any purpose), in the following ways: > > * It suggests that the token might result in context termination, but > does not specify that this always occurs. It does not give the caller a > way to know whether the context is still alive or not. It does not > specify whether the caller should still release the handle with > gss_delete_sec_context afterwards. > > * It does not admit a way to communicate error information from a token > to the caller. I read rfc2743 differently. rfc2743 simply did _not_ want to limit future extensibility of the purposes of gss_process_context_token(). Currently, there exist only two calls that can produce context-level tokens that for which a necessity to call gss_process_context_token() may arise: (1) an "unexpected" context level token from one of the security context establishment iterators (init_sec_context or accept_sec_context) which the intended receipient can therefore no longer feed into his context establishment iterator call. (2) a context deletion token as a result of a call to gss_delete_sec_context(). In principle, this token needs to always be passed to gss_process_context_token() by the recipient, but there is a small grey area about the situation where one side calls this without ever completing the context establishment handshake/loop. In (1) the context never was usable for the creator of the token, so it doesn't really matter whether the status changes for the recipient of the token. In (2), the context is _no_longer_ usable for the creator of the token (because it has been deleted), so it also does not really matter whether the status changes for the recipient of the token. > > We can reasonably amend the specification of gss_process_context_token > to address these flaws, and then document that future protocols should > allow it and future implementations should do it. In order to do so > with the gss-loop document, we would need to expand its scope such that > it is standard-track and updates RFC 2743. > > If we decide to do that, then there are a few options for how we fix it. > Modifying the function signature in the C bindings is not reasonable, > so we must assume the current signature which does not allow us to null > out the caller's context handle. Therefore, that handle must remain a > valid C pointer (or table index or whatever, but real-world > implementations use pointers), and the caller must eventually call > gss_delete_sec_context to release it. The remaining questions are: > > * Should the caller assume that the context is dead (except for needing > to be released), or should it make no such assumption? If the former, > should it assume that for all major return codes or only for some? I do > not have a strong preference yet. If the latter, I think we all agree > that future calls on that context handle (other than > gss_delete_sec_context) should result in GSS_S_NO_CONTEXT. No, I would strongly discourage that. GSS_S_NO_CONTEXT refers to the validity of the context *handle*, not to the ability to use the referenced context. GSS_S_NO_CONTEXT would indicate that this handle can also not be passed to gss_delete_sec_context(), which is wrong, because it *needs* to be passed to gss_delete_sec_context() for release of the associated resources. > > * Should properly validated error tokens result in GSS_S_COMPLETE with a > minor code, in GSS_S_FAILURE specifically, or in perhaps any of the > major codes which gss_init/accept_sec_context could return on an error > token? The first option is weird for GSSAPI. The third option is the > most programmatically informative to the caller, and is no less cleanly > delineated than the error results for init/accept_sec_context, so that > would be my preference. Processing of a context deletion token should result in GSS_S_COMPLETE (provided that the mechanism has/uses any such thing). Processing of a context error token should probably result in GSS_S_FAILURE accompanied by a meaningful minor_status. There is no other suitable error code defined in rfc2743. GSS_S_DEFECTIVE_TOKEN would apply only to a defective error token, not to convey information about a previously received defective context token, and GSS_S_NO_CONTEXT refers to the context _handle_ state. -Martin From nobody Mon Nov 3 13:39: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 D961C1A19E3 for ; Mon, 3 Nov 2014 13:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DulFjwT0MTg5 for ; Mon, 3 Nov 2014 13:39:36 -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 43F9E1A06FD for ; Mon, 3 Nov 2014 13:39:36 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 68D14584064 for ; Mon, 3 Nov 2014 13:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hkeBAcyb2/Ta46dA3By5 pqEZ9zw=; b=hsw79S6BcvuVmd2c8WrKpPPnRSGJMuAwkVtN9JOMtgKv/T5vHscm NvpFxJEtvkbxlvrUUIbtosk+v0tq4V0htW42ZnixNC6WsL4zas/hb5FMfOz7oUDy DF5GkaJuIIQ5dujKl5UIg8mqrhrKoQVetyp7J6nJEs+ONhZOZJAC2gA= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 0A29B584057 for ; Mon, 3 Nov 2014 13:39:34 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so7734826wib.17 for ; Mon, 03 Nov 2014 13:39:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.240.68 with SMTP id vy4mr51838149wjc.36.1415050773678; Mon, 03 Nov 2014 13:39:33 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 3 Nov 2014 13:39:33 -0800 (PST) In-Reply-To: <20141103213326.EBF1B1AF8D@ld9781.wdf.sap.corp> References: <5454F45E.1030508@mit.edu> <20141103213326.EBF1B1AF8D@ld9781.wdf.sap.corp> Date: Mon, 3 Nov 2014 15:39:33 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Jlssf5-Ll2t0GR40JljZzOeZyLA Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 21:39:37 -0000 On Mon, Nov 3, 2014 at 3:33 PM, Martin Rex wrote: > Processing of a context deletion token should result in GSS_S_COMPLETE > (provided that the mechanism has/uses any such thing). > > Processing of a context error token should probably result in > GSS_S_FAILURE accompanied by a meaningful minor_status. There is > no other suitable error code defined in rfc2743. > > GSS_S_DEFECTIVE_TOKEN would apply only to a defective error token, > not to convey information about a previously received defective > context token, and GSS_S_NO_CONTEXT refers to the context _handle_ state. I agree with this interpretation. Nico -- From nobody Mon Nov 3 13:48: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 52FB81A1A0A for ; Mon, 3 Nov 2014 13:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WY9JeYak6xv for ; Mon, 3 Nov 2014 13:48:04 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9E97D1A1A07 for ; Mon, 3 Nov 2014 13:48:04 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 66BD82007F10D for ; Mon, 3 Nov 2014 13:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=B02VARsEBCUhY5BBmJX1 7Sf8Du0=; b=uzhmVoLQoyNbf0gap5BhsMHugRZYN1juNREQ3MGYWiU486GVundh O4GMOGkFpL/XWxWFVPBvAGKaKnYWFFrQL3QJ+c1P8i9mfW3FUwk+mnz2cpr9HAs/ NrUXvYmrBAJTWvqAqpd+Y/uPfvf2BWJdA2RR2aQk84TwnpugsLcH7CE= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 195B92007F10B for ; Mon, 3 Nov 2014 13:48:03 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so7774833wiv.0 for ; Mon, 03 Nov 2014 13:48:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.185.115 with SMTP id fb19mr5694511wjc.121.1415051282928; Mon, 03 Nov 2014 13:48:02 -0800 (PST) Received: by 10.216.32.135 with HTTP; Mon, 3 Nov 2014 13:48:02 -0800 (PST) In-Reply-To: References: <5454F45E.1030508@mit.edu> <20141103213326.EBF1B1AF8D@ld9781.wdf.sap.corp> Date: Mon, 3 Nov 2014 15:48:02 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/0qfaTp_TJ44ToT18TZZSHgy2HIo Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 03 Nov 2014 21:48:05 -0000 On Mon, Nov 3, 2014 at 3:39 PM, Nico Williams wrote: > On Mon, Nov 3, 2014 at 3:33 PM, Martin Rex wrote: >> Processing of a context deletion token should result in GSS_S_COMPLETE >> (provided that the mechanism has/uses any such thing). >> >> Processing of a context error token should probably result in >> GSS_S_FAILURE accompanied by a meaningful minor_status. There is >> no other suitable error code defined in rfc2743. >> >> GSS_S_DEFECTIVE_TOKEN would apply only to a defective error token, >> not to convey information about a previously received defective >> context token, and GSS_S_NO_CONTEXT refers to the context _handle_ state. > > I agree with this interpretation. Well, actually, this is one of two interpretations that I would agree with. The other interpretation is that GSS_S_COMPLETE is to be returned for the error token case, with the error information in the minor status. The caller can then use GSS_Inquire_context() to determine the context's current state. The problem is that RFC2743 doesn't say that GSS_S_FAILURE is the case that corresponds to an error token. But I think your interpretation is the most correct one, the one that makes most sense, and we should say that this is an error in RFC2743 (and file the erratum). Nico -- From nobody Tue Nov 4 11:18: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 CD8AD1A6FD1 for ; Tue, 4 Nov 2014 11:18:26 -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 CB92QpMxc31y for ; Tue, 4 Nov 2014 11:18:25 -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 D9AE01A6F1E for ; Tue, 4 Nov 2014 11:18:24 -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 9AA2B3A0FC; Tue, 4 Nov 2014 20:18:21 +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 64C0842948; Tue, 4 Nov 2014 20:18:21 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5A3691AF90; Tue, 4 Nov 2014 20:18:21 +0100 (CET) In-Reply-To: To: Nico Williams Date: Tue, 4 Nov 2014 20:18:21 +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: <20141104191821.5A3691AF90@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NYPouLLCTSlHXj7Fg7dLMTdRaGI Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 04 Nov 2014 19:18:27 -0000 Nico Williams wrote: > > Nico Williams wrote: >> >> Martin Rex wrote: >>> >>> Processing of a context deletion token should result in GSS_S_COMPLETE >>> (provided that the mechanism has/uses any such thing). >>> >>> Processing of a context error token should probably result in >>> GSS_S_FAILURE accompanied by a meaningful minor_status. There is >>> no other suitable error code defined in rfc2743. >>> >>> GSS_S_DEFECTIVE_TOKEN would apply only to a defective error token, >>> not to convey information about a previously received defective >>> context token, and GSS_S_NO_CONTEXT refers to the context _handle_ state. >> >> I agree with this interpretation. > > Well, actually, this is one of two interpretations that I would agree with. > > The other interpretation is that GSS_S_COMPLETE is to be returned for > the error token case, with the error information in the minor status. > The caller can then use GSS_Inquire_context() to determine the > context's current state. It's difficult to make a recommendation here. Your suggestion to return a non-zero minor_status along with GSS_S_COMPLETE would be OK with the specification (rfc2743), but application callers typically to not look at minor_status at all when major_status==GSS_S_COMPLETE, and I'm not particularly enthusiastic to see a recommendation to give meaning to minor_status!=0 when major_status==GSS_S_COMPLETE. > > The problem is that RFC2743 doesn't say that GSS_S_FAILURE is the case > that corresponds to an error token. IMHO the highest probability to get to see any error message from an (unsuspecting) app (if it calls gss_process_context_token() at all) is when using GSS_S_FAILURE. A non-zero minor_status values that accompanies GSS_S_COMPLETE has a high likelyhood to get ignored entirely. -Martin From nobody Tue Nov 4 11:25: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 0C8A71A700C for ; Tue, 4 Nov 2014 11:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPwbrnEeQKj9 for ; Tue, 4 Nov 2014 11:25:15 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 651C81A700A for ; Tue, 4 Nov 2014 11:25:15 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 8F22B59806A for ; Tue, 4 Nov 2014 11:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/AR4L3gpowqVBMS944Sb PNQKwA0=; b=WcUQtuOCWB9d29zn7qGhy63JAsvpw8WPMYGr8ckEOvOf5wdStfls Jl87InZffJYi0XR51i1xTo5/ZRG5itW//9c8TXStrRDwV+nP25WsPr3XGDm9+q1T OaOCJVmFCNB7JDDn1ytDRXZ/Y/tRTYSPkpR9eT/ivp39ETXdPz0vVtI= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 39164598060 for ; Tue, 4 Nov 2014 11:25:14 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so15784582wgg.9 for ; Tue, 04 Nov 2014 11:25:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.211.70 with SMTP id na6mr26130777wic.3.1415129113090; Tue, 04 Nov 2014 11:25:13 -0800 (PST) Received: by 10.216.32.135 with HTTP; Tue, 4 Nov 2014 11:25:12 -0800 (PST) In-Reply-To: <20141104191821.5A3691AF90@ld9781.wdf.sap.corp> References: <20141104191821.5A3691AF90@ld9781.wdf.sap.corp> Date: Tue, 4 Nov 2014 13:25:12 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/QTSpanuXHEOIzhmOUNqMpPxAinM Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 04 Nov 2014 19:25:16 -0000 On Tue, Nov 4, 2014 at 1:18 PM, Martin Rex wrote: > Nico Williams wrote: >> Well, actually, this is one of two interpretations that I would agree with. >> >> The other interpretation is that GSS_S_COMPLETE is to be returned for >> the error token case, with the error information in the minor status. >> The caller can then use GSS_Inquire_context() to determine the >> context's current state. > > It's difficult to make a recommendation here. Your suggestion to > return a non-zero minor_status along with GSS_S_COMPLETE would be OK > with the specification (rfc2743), but application callers typically > to not look at minor_status at all when major_status==GSS_S_COMPLETE, > and I'm not particularly enthusiastic to see a recommendation to give > meaning to minor_status!=0 when major_status==GSS_S_COMPLETE. Well, it'd be exceptional, but workable. I prefer your interpretation. I've filed an erratum to that effect, FYI. > IMHO the highest probability to get to see any error message from > an (unsuspecting) app (if it calls gss_process_context_token() at all) > is when using GSS_S_FAILURE. A non-zero minor_status values that > accompanies GSS_S_COMPLETE has a high likelyhood to get ignored entirely. Agreed. Nico -- From nobody Tue Nov 4 11:33: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 B73601A7007 for ; Tue, 4 Nov 2014 11:33:48 -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 JnuDycJVV2C4 for ; Tue, 4 Nov 2014 11:33:47 -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 1DA851A6FF5 for ; Tue, 4 Nov 2014 11:33: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 smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id EAAD43A0F1; Tue, 4 Nov 2014 20:33:45 +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 DF14142996; Tue, 4 Nov 2014 20:33:45 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D441A1AF90; Tue, 4 Nov 2014 20:33:45 +0100 (CET) In-Reply-To: <54556118.4070902@mit.edu> To: Greg Hudson Date: Tue, 4 Nov 2014 20:33:45 +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: <20141104193345.D441A1AF90@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qJgKBigrgM9TkhI3SQ03g3Gws9M Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 04 Nov 2014 19:33:48 -0000 Greg Hudson wrote: > On 11/01/2014 05:59 PM, Nico Williams wrote: > > I'm not proposing that we update RFC2743. > > > > I'm pointing out where this I-D diverges from RFC2743. You're not > > ackowledging this. > > I acknowledge that RFC 2743 does mention post-establishment error tokens > in its description of gss_process_context_token. However, this part of > RFC 2743 is broken (not ambiguous, broken) and everyone ignores it. > According to the current spec, an application calling > gss_process_context_token (1) does not receive error information from > the token, and (2) does not know whether the context handle is still > active and whether it is allowed to make further calls on that handle to > find out. The mere existence of a context deletion or error token does not change the status of the context handle. Feeding a context deletion or error token to gss_process_context_token() will probably impair message protection services, in case these have been previously available, so there will may be a difference in the output of gss_inquire_context() before and after the call to gss_process_context_token(). If the prior value of the "open" boolean was TRUE, then it will likely be FALSE after gss_process_context_token(). The final paragraph of the description of gss_inquire_context() in rfc2743 reads: https://tools.ietf.org/html/rfc2743#page-57 o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined. This call is used to extract information describing characteristics of a security context. Note that GSS-API implementations are expected to retain inquirable context data on a context until the context is released by a caller, even after the context has expired, although underlying cryptographic data elements may be deleted after expiration in order to limit their exposure. so I believe that gss_inquire_context() should also remain possible after calling gss_process_context_token(), i.e. should not fail. I would certainly prefer to have gss_process_context_token() rather than gss_inquire_context() to report the error from an incoming error context token. -Martin From nobody Tue Nov 4 12:44: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 9E6101ACED9 for ; Tue, 4 Nov 2014 12:44:41 -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 8jlokEP_V_Ql for ; Tue, 4 Nov 2014 12:44:40 -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 DEAD61ACEE4 for ; Tue, 4 Nov 2014 12:44:39 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id A3BCA163C; Tue, 4 Nov 2014 12:44: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=40ohp9H7f18Cfr 6O9LMWE3MtJAw=; b=fySNHhgltbqXjPrPl26Bh5PHfh476SrOkFPocw3ltPzVYF Xa6OITAWAiyMiEmBx5nxSWn9MSA7AhsihAtcqJfxotWXrVTU1caQSwB8SCOOppo1 +JFnxUgqyFK+jFYj9HgXM9EwaPEVHmmGap26fo9bTjOb6UZaYLPluc9HqsmJw= 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 41620163E; Tue, 4 Nov 2014 12:44:39 -0800 (PST) Date: Tue, 4 Nov 2014 14:44:38 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141104204436.GH7913@localhost> References: <54556118.4070902@mit.edu> <20141104193345.D441A1AF90@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141104193345.D441A1AF90@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cCCbfBNoorRev3f4v6n3Gy9hKHc Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 04 Nov 2014 20:44:41 -0000 On Tue, Nov 04, 2014 at 08:33:45PM +0100, Martin Rex wrote: > Feeding a context deletion or error token to gss_process_context_token() > will probably impair message protection services, in case these have Emphasis on 'probably'. There's no requirement as to this. My take is that currently[*] all possible tokens that can only be processed with GSS_Process_context_token() necessarily denote that the sender no longer has a security context with which to process any further tokens, either because of context establishment error or because of a call to GSS_Delete_sec_context(). [*] One could imagine future re-keying/re-establishment extensions (a la TLS renego) that would change this, but we're not there, no one is proposing such extensions, and if anyone ever does it won't be the end of the world if today's GSS applications don't support it since... they couldn't anyways. > been previously available, so there will may be a difference in > the output of gss_inquire_context() before and after the call to > gss_process_context_token(). If the prior value of the "open" boolean > was TRUE, then it will likely be FALSE after gss_process_context_token(). We all seem to agree as to this. But still ISTM that your proposal, that error tokens elicit GSS_S_FAILURE from GSS_Process_context_token(), is the right interpretation since there's no other case that could legitimately yield GSS_S_FAILURE from GSS_Process_context_token(). > The final paragraph of the description of gss_inquire_context() in > rfc2743 reads: > https://tools.ietf.org/html/rfc2743#page-57 > [...] > > so I believe that gss_inquire_context() should also remain possible after > calling gss_process_context_token(), i.e. should not fail. I would Yes. Besides, it's clear that GSS_Process_context_token() does not delete the context, and it's even more clear that this is true in the C bindings. > certainly prefer to have gss_process_context_token() rather than > gss_inquire_context() to report the error from an incoming error context > token. Agreed. Nico -- From nobody Tue Nov 4 12:47: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 80B701ACEEA for ; Tue, 4 Nov 2014 12:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RK2ah6DEZyNP for ; Tue, 4 Nov 2014 12:47:16 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B23EA1ACEE6 for ; Tue, 4 Nov 2014 12:47:16 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 7623C200B99C5 for ; Tue, 4 Nov 2014 12:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=MxlQma2KxLlmrFj7MIrfZET89Vk=; b=F1dCe7S6vTA 11cmh5Nak0KVeHH82uJ19UlqleoP/vE2C8tuCjdxr5rlwZtekZIyLx9Z3mEo+vIE cp4F7gGW9qCt8WPHMtHh+YA9ahx693Nfk0e5r2GWBMGyaEqDHcHYXvcisCk5mJ64 hx4dSTGIjpm26t4h7GcSbmBoMeB4HoT0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id 39FDB20024943 for ; Tue, 4 Nov 2014 12:47:16 -0800 (PST) Date: Tue, 4 Nov 2014 14:47:15 -0600 From: Nico Williams To: kitten@ietf.org Message-ID: <20141104204714.GI7913@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/I_tFkUGjmJRUiRItB4vGFsKCq6o Subject: [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, 04 Nov 2014 20:47:17 -0000 I wrote this yesterday but neglected to click the submit button. Just submitted: http://www.rfc-editor.org/errata_search.php?eid=4151 From nobody Tue Nov 4 15:32: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 442C51A1A25 for ; Tue, 4 Nov 2014 15:32:48 -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 vcgD3IW40eun for ; Tue, 4 Nov 2014 15:32:46 -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 CCF381A1A20 for ; Tue, 4 Nov 2014 15:32:45 -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 6A2FB3A10A; Wed, 5 Nov 2014 00:32:43 +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 3818142779; Wed, 5 Nov 2014 00:32:43 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2D8981AF91; Wed, 5 Nov 2014 00:32:43 +0100 (CET) In-Reply-To: <20141103180207.GG7913@localhost> To: Nico Williams Date: Wed, 5 Nov 2014 00:32:43 +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: <20141104233243.2D8981AF91@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/H_VMFSwpvc-jyoE1749PnmV0x5g Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 04 Nov 2014 23:32:48 -0000 Nico Williams wrote: > On Mon, Nov 03, 2014 at 10:06:11AM -0600, Nico Williams wrote: >> On Sun, Nov 02, 2014 at 08:08:00PM -0500, Benjamin Kaduk wrote: >>> On Sun, 2 Nov 2014, Nico Williams wrote: >>>> >>>> First, the application can get error token information in the minor >>>> status code result from GSS_Process_context_token(). Nothing in the >>>> two RFCs prohibits returning a non-zero minor status code when >>>> returning GSS_S_COMPLETE as the major status code. >>> >>> I think that Martin's gsstest program complains about it, though :) >> >> But is it normative? :) > > BTW, RFC2744 says that minor_status is always set, and it doesn't define > any numeric values for it, not even "no error", not even zero. > > Therefore I think gsstest is wrong to complain about it. The relevant gsstest plausibility tests look like this: if ( minor_status==BOGUS_VALUE ) { XVEB((V_ERR, "%s() FAILED to clear minor_status!\n", call_name)); rc++; minor_status = 0; } if ( major_status==0 && minor_status!=0 ) { rc++; XVEB((V_ERR, "%s() unexpected non-zero minor_status (%08lx)!\n", call_name, (Ulong) minor_status)); } So gsstest complains only about _bogus_ return values for min_stat, which is a conformance test suggested by rfc2744 section 3.9.2: https://tools.ietf.org/html/rfc2744#page-15 3.9.2. Mechanism-specific status codes GSS-API routines return a minor_status parameter, which is used to indicate specialized errors from the underlying security mechanism. This parameter may contain a single mechanism-specific error, indicated by a OM_uint32 value. The minor_status parameter will always be set by a GSS-API routine, even if it returns a calling error or one of the generic API errors indicated above as fatal, although most other output parameters may remain unset in such cases. However, output parameters that are expected to return pointers to storage allocated by a routine must always be set by the routine, even in the event of an error, although in such cases the GSS-API routine may elect to set the returned parameter value to NULL to indicate that no storage was actually allocated. Any length field associated with such pointers (as in a gss_buffer_desc structure) should also be set to zero in such cases. For unexpected non-zero minor_status values, it only returns an indication that -- whatever this value is supposed to mean -- it will go entirely unnoticed by applications (and therefore admin/users) when it accompanies a GSS_S_COMPLETE status. While it is technically true that there is no official designation in the GSS-API v2 C-Bindings (rfc2744) for a minor_status value with the meaning of "absent" / "not available", using "0" for this purpose looked like an intuitive natural fit (for C-bindings), and my app code on top of GSS-API will not even try to obtain a description for a 0 minor_status value. -Martin From nobody Tue Nov 4 18:51: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 CA52A1A87A1 for ; Tue, 4 Nov 2014 18:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 NjA6ZslZpS0w for ; Tue, 4 Nov 2014 18:51:28 -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 0AFBE1A87A7 for ; Tue, 4 Nov 2014 18:51:25 -0800 (PST) X-AuditID: 12074423-f799d6d00000337c-02-545990ac7788 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 42.2F.13180.CA099545; Tue, 4 Nov 2014 21:51:24 -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 sA52pN7f000522; Tue, 4 Nov 2014 21:51:23 -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 sA52pLJG012318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Nov 2014 21:51:23 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA52pLOn008539; Tue, 4 Nov 2014 21:51:21 -0500 (EST) Date: Tue, 4 Nov 2014 21:51:20 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141104204436.GH7913@localhost> Message-ID: References: <54556118.4070902@mit.edu> <20141104193345.D441A1AF90@ld9781.wdf.sap.corp> <20141104204436.GH7913@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+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrLtmQmSIwcOTnBZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJWx6fsGxoK7zBVXV3xjb2BsZu5i5OSQEDCR 2HRoNTuELSZx4d56ti5GLg4hgdlMEkenrmaEcDYwShw8/oAFwjnIJNG2+DwbSIuQQL3Exicv WEBsFgEtifub/jCC2GwCKhIz32wEqxER0JS4Pm8pmM0sIC/xbE03mC0sYC3x8MQGsDM4BfQk nq+4w9TFyMHBK+AocfJQDMT4ConuRRvBSkQFdCRW758CtopXQFDi5MwnLBAjtSSWT9/GMoFR cBaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCApXdRXkH45+D SocYBTgYlXh4DXIjQ4RYE8uKK3MPMUpyMCmJ8m7sBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4XVLBMrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwPuoHahQsSk1P rUjLzClBSDNxcIIM5wEavg+khre4IDG3ODMdIn+KUZejpeltL5MQS15+XqqUOG8LSJEASFFG aR7cHFiCecUoDvSWMK84MN0I8QCTE9ykV0BLmICWWPREgCwpSURISTUwLmOaXc4d232f5Wtr 58VP4U9/s2zjr2orN/Z8Pm+vu7RTqX1zcF7oVGunhcE8AnudNaxb3cIm7f33WVZOWq5yf+z3 /SqcB753svz1eBe72SXLhVVUneXvwROWFZKMb3ILX9npn0vV11xpPD9kf/LpHrsbJixyTfcd ji4oEtaoCYh+9D5SrVqJpTgj0VCLuag4EQDke2sjCwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RqbNrKoSveyzfK_AuuTGsnE93yU Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 05 Nov 2014 02:51:30 -0000 I'm working on a summary of the options and their downsides, but On Tue, 4 Nov 2014, Nico Williams wrote: > that error tokens elicit GSS_S_FAILURE from GSS_Process_context_token(), > is the right interpretation since there's no other case that could > legitimately yield GSS_S_FAILURE from GSS_Process_context_token(). Well, there are always mundane things like ENOMEM. But we are kind of stuck with no good options, so we may have to ignore those cases. -Ben From nobody Tue Nov 4 19:21:48 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 A72F01A87A8 for ; Tue, 4 Nov 2014 19:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 SXDkhG-UhhrZ for ; Tue, 4 Nov 2014 19:21:45 -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 3F1E41A1BB9 for ; Tue, 4 Nov 2014 19:21:45 -0800 (PST) X-AuditID: 12074422-f79436d000000c21-c8-545997c7554c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id AE.60.03105.8C799545; Tue, 4 Nov 2014 22:21:44 -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 sA53LWVL003172; Tue, 4 Nov 2014 22:21:32 -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 sA53LU9X020307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Nov 2014 22:21:31 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA53LTjX012271; Tue, 4 Nov 2014 22:21:29 -0500 (EST) Date: Tue, 4 Nov 2014 22:21:29 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141104204436.GH7913@localhost> Message-ID: References: <54556118.4070902@mit.edu> <20141104193345.D441A1AF90@ld9781.wdf.sap.corp> <20141104204436.GH7913@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+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrHtiemSIwe9z2hZHN69isej9vYPZ 4tS1I2wOzB4vT51j9Fiy5CeTx5TPWxkDmKO4bFJSczLLUov07RK4Mk6vf8JWcMqoYu6UXYwN jA80uxg5OSQETCQW3ZrKCGGLSVy4t54NxBYSmM0kcXRWWhcjF5C9gVHi567jTBDOQSaJj//f skNU1Ut0flnNCmKzCGhJPGzrZwGx2QRUJGa+2Qg2SURAU+L6vKVANgcHs4CVxOvlHiBhYQFr iYcnNjCD2JwCehLPV9xhArF5BRwlTm57xQIxvkKie9FGsBpRAR2J1funsEDUCEqcnPkEzGYG Wrt8+jaWCYyCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREU uuwuSjsYfx5UOsQowMGoxMNrkBsZIsSaWFZcmXuIUZKDSUmUt28yUIgvKT+lMiOxOCO+qDQn tfgQowQHs5IIr1siUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYJ3 wjSgRsGi1PTUirTMnBKENBMHJ8hwHqDhPSA1vMUFibnFmekQ+VOMilLivAtBEgIgiYzSPLhe WGp5xSgO9Iow7wqQKh5gWoLrfgU0mAlosEVPBMjgkkSElFQDo8dRFZfdFR7yNza9dc200Xqw rfONRrsRV8Aenf/XDi2KLfg3YbfDe1UH1q5dv404Xxvy5/09yGRx/nnN/An2U1pb5kla8Tv9 nhf3K+bWmdkJDew8+x4YRB49f24R+9ySsMcH3E4riahZvJDprJpwQ0nx3ZfNuZt15tw4L6xV sjPyc3mCHYevjxJLcUaioRZzUXEiABESCecIAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/d_MRlS5aXN3jJTNH38ftlvFP8tA Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 05 Nov 2014 03:21:47 -0000 I think we are approaching consensus about the right behavior for these error tokens and GSS_Process_context_token(), so I will try to summarize the options that have been considered and the arguments for and against them. (Initially I favored a different approach than proposed by Martin, but upon closer reading of 2743 I believe I am in agreement with his proposal.) Upon receiving a context-level token after its call to GSS_{Accept,Init}_sec_context() has succeeded, a peer may end up calling some or all of GSS_Process_context_token(), GSS_Inquire_context(), and/or GSS_Delete_sec_context(), in that order. Options that have been considered include: (0) Do nothing with the token; call GSS_Delete_sec_context() because the token must mean that the context is no longer usable. This is bad both because it does not verify the authenticity of the token and because it has no way to convey the actual error information to the user. (1a) Pass the token to GSS_Process_context_token(), which returns success and deletes the context data. Do not call GSS_Delete_sec_context() and assume that GSS_Process_context_token() has done that work for us. This is not supported by RFC 2743; furthermore, the C bindings in RFC 2744 do not provide a way for the context handle to be fully invalidated, so this clearly cannot be correctly implemented. (1b) Pass the token to GSS_Process_context_token(), which returns a different value depending on whether the token was an error token or a deletion token. Whether Delete_sec_context is necessary depends on the particular return. Simlar to (1a); additionally this is too complicated a contract to reasonably impose on applications. (1c) Pass the token to GSS_Process_context_token(), which returns success and marks the context as unusable. Call GSS_Inquire_context() to determine whether the context is still valid (returning success and looking at its outputs), and GSS_Delete_sec_context() when we're done. This is appealing to me because process_context_token() succeeds at what it is doing (processing the token), and it seems natural for something with the name Inquire_context() to tell me whether my handle is still valid or not. However, Inqure_context() is not really designed to produce this kind of information; it gives names, a lifetime, the mech, and some booleans corresponding roughly to the request flags, and 'open'. 'open' is described as TRUE if fully established, and FALSE if partly established (in CONTINUE_NEEDED) state. Neither one is appropriate for "deleted" (or similar). While it's true that the conf_avail and similar booleans are likely to be false after the processing of an extra token, that's a terrible way for applications to be able to tell that the context has been invalidated and should be deleted. Furthermore, GSS_S_COMPLETE "indicates that the referenced context is valid", and the only error returns are GSS_S_NO_CONTEXT (the supplied handle was not valid) and GSS_S_FAILURE (the (inquire) operation failed). (1d) Pass the token to GSS_Process_context_token(), which returns success. Error reporting is deferred until a call to GSS_Inquire_context(), which returns an error corresponding to the information in the token. (Whether or not GSS_Delete_context() is called is not relevant for the discussion.) 2743 implies that Inquire_context() really should be able to succeed in this situation, so errors from it are not an appropriate way to convey status information. (2a) Pass the token to GSS_Process_context_token(), which returns success with a minor code indicating the error. Inquire_context is optional; Delete_sec_context is required. This is probably not the right thing to do for a deletion token; we mostly should just be ignoring those, these days, I think. (2b) Pass the token to GSS_Process_context_token(), which returns success with a minor code indicating the nature of the error in the token for error tokens, and just success for deletion tokens. Nico would accept this, but it's really weird within the GSS-API to have information in the minor status when the major status is GSS_S_COMPLETE. (3a) Pass the token to GSS_Process_context_token(), which returns GSS_S_COMPLETE for deletion tokens and GSS_S_FAILURE for error tokens. Inquire_context() is still usable, and we always must call Delete_sec_context(). Martin and Nico are okay with this one. The only downside is that 2743 doesn't document GSS_S_FAILURE as meaning quite this; rather "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's not really clear what that is supposed to mean, so maybe it's okay if we feel free to interpret as something that results in a mostly usable API. (It is still possible for confusion with local errors like ENOMEM, but maybe the minor code will be enough to disambiguate.) Returning GSS_S_FAILURE is a decent way to get applications to report an error to the user which is consistent with expectations for error reporting elsewhere in the GSS-API. (3b) Pass the token to GSS_Process_context_token(), which returns GSS_S_FAILURE for both kinds of tokens. As in (3a), Inquire_context() works and Delete_sec_context() is required. As mentioned previously, we probably should just be ignoring deletion tokens. This is otherwise similar to (3a), and thus probably tolerable. (4) Pass the token to GSS_Process_context_token(), which returns some other major code than GSS_S_FAILURE which would be returned from GSS_{Init,Accept}_sec_context upon receipt of an error token. Not supported by the return codes documented in RFC 2743, which are just GSS_S_DEFECTIVE_TOKEN, which would apply to the token itself, not its contents; and GSS_S_NO_CONTEXT, which refers to the supplied handle's state. There is some potential, but the meanings of the errors would not be very clear, and would be a large change from the published spec. Just returning the same error that the other side emitted when the error token was produced is probably not okay, as that would collide with some of the existing documented return values for Process_context_token(). So, it looks like the least bad option is (3), and we are leaning towards the (3a) variant based on Martin's preference. Does that seem like a reasonable summary? -Ben From nobody Tue Nov 4 20:12:20 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 798671A8741 for ; Tue, 4 Nov 2014 20:12:18 -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 N_qWKALBa-Cf for ; Tue, 4 Nov 2014 20:12:17 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 05AF51A87AD for ; Tue, 4 Nov 2014 20:12:17 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id B62142005D008; Tue, 4 Nov 2014 20:12:16 -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=GRUU61bg0d3wXy u4NTt+uQWGvuY=; b=dEH74liRI+TS5EUqubWxHPfhbXRgoYCNLfLAIElacgdvd1 SXIQRBa0w6r4UlA47vvFYx2pDI3OyQ54VZIWS57TucmQYLp3rXhgzAUQnfWD4jZW WNc2N6YcrIddaeMN0mzAzkaBbnDSOT4TL2xxn0RDGE9jztABwMQWPMVvbSuMM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 52E252005D005; Tue, 4 Nov 2014 20:12:16 -0800 (PST) Date: Tue, 4 Nov 2014 22:12:15 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141105041213.GK7913@localhost> References: <54556118.4070902@mit.edu> <20141104193345.D441A1AF90@ld9781.wdf.sap.corp> <20141104204436.GH7913@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/fuqUQaDowsJRGYe3pQMgz7xbDUM Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 05 Nov 2014 04:12:18 -0000 On Tue, Nov 04, 2014 at 10:21:29PM -0500, Benjamin Kaduk wrote: > Upon receiving a context-level token after its call to > GSS_{Accept,Init}_sec_context() has succeeded, a peer may end up calling > some or all of GSS_Process_context_token(), GSS_Inquire_context(), and/or > GSS_Delete_sec_context(), in that order. Options that have been > considered include: I don't think it was ever the case that not calling Delete_sec_context() was OK in the case of context tokens arriving after full security context establishment. > (0) Do nothing with the token; call GSS_Delete_sec_context() because the > token must mean that the context is no longer usable. > > This is bad both because it does not verify the authenticity of the token > and because it has no way to convey the actual error information to the > user. Agreed, though it's not necessarily as bad as all that (the error token, for example, may not be integrity protected, in which case a DoS would be possible even if we bother calling GSS_Process_context_token()). (1a) was never proper. > (1b) Pass the token to GSS_Process_context_token(), which returns a > different value depending on whether the token was an error token or a > deletion token. Whether Delete_sec_context is necessary depends on the > particular return. As of today and per-RFCs 2743 and 2744, GSS_Delete_sec_context() must always eventually be called upon processing an error/deletion token _except_ when processing returns GSS_S_DEFECTIVE_TOKEN (i.e., the token may well not have been an error/deletion token). But even here, the application might well find that the peer is no longer responsive or closes the connection/whatever. With that note, (1b) is almost indistinguishable from (3a). > (1c) Pass the token to GSS_Process_context_token(), which returns success > and marks the context as unusable. Call GSS_Inquire_context() to > determine whether the context is still valid (returning success and > looking at its outputs), and GSS_Delete_sec_context() when we're done. This works for me as a second choice. It may leave more room for future extensibility, but I don't think so: if, for example, we were to add something like TLS renego I'd expect a new req_flag/ret_flag and/or function call to indicate application support for the feature. > This is appealing to me because process_context_token() succeeds at what > it is doing (processing the token), and it seems natural for something > with the name Inquire_context() to tell me whether my handle is still > valid or not. However, Inqure_context() is not really designed to produce > this kind of information; it gives names, a lifetime, the mech, and some > booleans corresponding roughly to the request flags, and 'open'. 'open' > is described as TRUE if fully established, and FALSE if partly established > (in CONTINUE_NEEDED) state. Neither one is appropriate for "deleted" (or > similar). [...] The context *must* have been open if we got to this point -- otherwise the token would have been passed to one of GSS_Init/Accept_sec_context(). The context no longer being open (if Inquire_context() says so) is indicative that the context is now to be deleted. It can't already be deleted at this point. Therefore there's nothing weird about the 'open' output being FALSE at this point. > (1d) [...] I think I might have offered (1d) at some point. If I did I retract it now. > (2a) Pass the token to GSS_Process_context_token(), which returns success > with a minor code indicating the error. Inquire_context is optional; > Delete_sec_context is required. > > This is probably not the right thing to do for a deletion token; we mostly > should just be ignoring those, these days, I think. We can't externally and securely tell if it is a deletion token. Having GSS_S_COMPLETE for both, error _and_ deletion tokens would mean we never could tell. That would be mildly dissatisfying, but I could live with it. > (2b) Pass the token to GSS_Process_context_token(), which returns success > with a minor code indicating the nature of the error in the token for > error tokens, and just success for deletion tokens. Remember, there's no defined no-error minor status. (2b) is indistinguishable from (2a) unless we also codify that the zero minor status value is no-error. (2b) is better than (2a) because it allows error and deletion tokens to be distinguished. > Nico would accept this, but it's really weird within the GSS-API to have > information in the minor status when the major status is GSS_S_COMPLETE. It's not necessarily all that weird. For one, the RFCs never say this can't happen... > (3a) Pass the token to GSS_Process_context_token(), which returns > GSS_S_COMPLETE for deletion tokens and GSS_S_FAILURE for error tokens. > Inquire_context() is still usable, and we always must call > Delete_sec_context(). > > Martin and Nico are okay with this one. The only downside is that 2743 Yes. I think it's fair to say that Martin prefers this. I do prefer this. > doesn't document GSS_S_FAILURE as meaning quite this; rather "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's not > really clear what that is supposed to mean, so maybe it's okay if we feel > free to interpret as something that results in a mostly usable API. (It > is still possible for confusion with local errors like ENOMEM, but maybe > the minor code will be enough to disambiguate.) Returning GSS_S_FAILURE > is a decent way to get applications to report an error to the user which > is consistent with expectations for error reporting elsewhere in the > GSS-API. I agree, but since either way it was curtains for the context, this slight ambiguity between exceptional local errors and every day remote errors is acceptable to me. > (3b) Pass the token to GSS_Process_context_token(), which returns > GSS_S_FAILURE for both kinds of tokens. As in (3a), Inquire_context() > works and Delete_sec_context() is required. This contradicts RFC2743 as to deletion tokens. > As mentioned previously, we probably should just be ignoring deletion > tokens. This is otherwise similar to (3a), and thus probably tolerable. I'm not so sure that obsoleting deletion tokens was a good idea... But let's leave that thought for some other day; we're having enough fun with this problem as it is. > (4) Pass the token to GSS_Process_context_token(), which returns some > other major code than GSS_S_FAILURE which would be returned from > GSS_{Init,Accept}_sec_context upon receipt of an error token. A lot of common errors have those two functions return GSS_S_FAILURE. The other errors probably don't cover all errors that the error token might be reporting. ASIDE: I see that I was wrong about the other supplementary major status codes: the two RFCs do list them for GSS_Init/Accept_sec_context(). If you could see me now, you'd see me wiping egg from my face. > So, it looks like the least bad option is (3), and we are leaning towards > the (3a) variant based on Martin's preference. I'm pulling for (3a), yes. My preferences, from most- to least-preferred: 3a, 2b, 2a. I reject the others. > Does that seem like a reasonable summary? Yes. Nico -- From nobody Wed Nov 5 14:14:58 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481301ACE68 for ; Wed, 5 Nov 2014 14:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_48=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_66=0.6, 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 fPv1vbiTyXqy for ; Wed, 5 Nov 2014 14:14:53 -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 21ABF1ACE4D for ; Wed, 5 Nov 2014 14:14:53 -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 B26493A207; Wed, 5 Nov 2014 23:14:50 +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 7722141C37; Wed, 5 Nov 2014 23:14:50 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6CA001AF95; Wed, 5 Nov 2014 23:14:50 +0100 (CET) In-Reply-To: <20141105041213.GK7913@localhost> To: Nico Williams Date: Wed, 5 Nov 2014 23:14:50 +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: <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IxOhBhDiwQRDjdaEoGOvmPZPeac Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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: Wed, 05 Nov 2014 22:14:57 -0000 Thanks Ben for the summary. I hadn't seen as many options/variants in the discussion, but I'm also not missing anything, and I also only jumped into the discussion very late. I'm following up to Nico's response for brevity. Nico wrote: > Ben wrote: >> (3a) Pass the token to GSS_Process_context_token(), which returns >> GSS_S_COMPLETE for deletion tokens and GSS_S_FAILURE for error tokens. >> Inquire_context() is still usable, and we always must call >> Delete_sec_context(). >> >> Martin and Nico are okay with this one. The only downside is that 2743 > > Yes. I think it's fair to say that Martin prefers this. I do prefer this. Confirmed. My preference is (3a). When trying to extend an existing spec that seems incomplete or ambiguous, it may help to follow the general guideline of "the principle of least surprise" and look at similar *known* situations that either already exist or can easily be constructed. Kerberos should be a suitable mechanism to describe what we have and figure out what should be. rfc1964 defines two variants of the Kerberos authentication: 1) initiator-to-target authentication with a single context token 2) initiator-to-target plus target-to-initiator authentication ("GSS_C_MUTUAL_FLAG") with two context tokens, one from initiator to acceptor and one from acceptor to initiator. A number of possible error situations that can occur during the acceptors call to gss_accept_sec_context() will equally be possible in either of these authentication variants, and could therefore result in the exact same KRB_ERROR token. The difference is, that in (1), there is no expected context level token, so if gss_accept_sec_context() returns a context level token at all, and if it is sent back to the initiator at all (in spite of that token being accompanied by a FATAL major_status from gss_accept_sec_context()), the initiator will have to pass it to gss_process_context_token(), because his initial call to gss_init_sec_context() completed with GSS_S_COMPLETE, and the initiator does not really expect another context level token. I firmly believe, that the same error cause should result in mostly the same "look and feel" for the initiator (and the user/caller on top of the initiator side) for both situations (1) and (2). In (2), the KRB_ERROR token will be processed by gss_accept_sec_context() and should cause a fatal major status along with a helpful minor_status that conveys the reason from the KRB_ERROR token. In (1), the closest matching behaviour would be that gss_process_context_token() behaves much like gss_accept_sec_context() behaves when processing that very KRB_ERROR token. The only well-defined means how a gss-api mechanism can get a mechanism-specific error shown to a user/caller is by making a gssapi call return a fatal major_status along with a helpful minor_status. The context-iterators (gss_init_sec_context/gss_accept_sec_context) are very close relatives to gss_process_context_token() with respect to processing error tokens, because error tokens that are transfered as a substitute to a regular, expected context level token will be processed by a context-iterator, whereas error tokens that are going to be "unexpected" context level tokens will have to be processed by gss_process_context_token(). Having gss_process_context_token() return an error upon processing a context deletion would look strange to me. This certainly does not fit the meaning of failure for that call and if a pair of application callers uses a context deletion token to "smoothly" close down a communication channel, why should they receiver be facing a fatal error message that is _not_ suggested anywhere in the existing specification. Nico Williams wrote: > On Tue, Nov 04, 2014 at 10:21:29PM -0500, Benjamin Kaduk wrote: >> >> Upon receiving a context-level token after its call to >> GSS_{Accept,Init}_sec_context() has succeeded, a peer may end up calling >> some or all of GSS_Process_context_token(), GSS_Inquire_context(), and/or >> GSS_Delete_sec_context(), in that order. Options that have been >> considered include: > > I don't think it was ever the case that not calling Delete_sec_context() > was OK in the case of context tokens arriving after full security > context establishment. Agreed. There are only two calls that may delete a context (handle): gss_delete_sec_context() and gss_export_sec_context(). gss_init_sec_context() and gss_accept_sec_context() can only fail to create&return a valid context handle (on the initial call) but should not delete a context handle that was created by an earlier iterator call. (from the perspective of formal correctness proofing). > > > (1b) Pass the token to GSS_Process_context_token(), which returns a > > different value depending on whether the token was an error token or a > > deletion token. Whether Delete_sec_context is necessary depends on the > > particular return. > > As of today and per-RFCs 2743 and 2744, GSS_Delete_sec_context() must > always eventually be called upon processing an error/deletion token > _except_ when processing returns GSS_S_DEFECTIVE_TOKEN (i.e., the token > may well not have been an error/deletion token). But even here, the > application might well find that the peer is no longer responsive or > closes the connection/whatever. Whether receipt of a context level token that is rejected with GSS_S_DEFECTIVE_TOKEN by the gssapi mechanism is to be seen as a fatal termination of the communication depends on the specific application an protocol. There certainly should be some _low_ threshold how often the application caller on top of gssapi should allow that to happen and be ignored, or it may open a security vulnerability (access to an "Oracle"). This is how DTLS was made practically susceptible to LuckyThirteen, whereas the same attack isn't practical for TLS, where integrity failures of the communication always fatally terminate the connection. > > With that note, (1b) is almost indistinguishable from (3a). > > > (1c) Pass the token to GSS_Process_context_token(), which returns success > > and marks the context as unusable. Call GSS_Inquire_context() to > > determine whether the context is still valid (returning success and > > looking at its outputs), and GSS_Delete_sec_context() when we're done. > > This works for me as a second choice. It may leave more room for future > extensibility, but I don't think so: if, for example, we were to add > something like TLS renego I'd expect a new req_flag/ret_flag and/or > function call to indicate application support for the feature. I'm not aware of any currently well-defined situation/behaviour where an application that (a) receives a context level token after context establishment, and (b) properly hands the token to gss_process_context_token() could expect to continue using the security context. A number of "application protocols" that embed gssapi tokens may not have a mechanism to label/tag tokens with their token type (context vs. message protection token), and instead, the nature of the token is implied (everything sent&received before the local context iterator call returns GSS_S_COMPLETE is a context level token, everything after it is a message protection token. To positively indicate the end of a data transfer, FTP Security extensions (rfc2228) uses a zero-length protected message: http://tools.ietf.org/html/rfc2228#page-15 When the end of the file is reached, the sender must encode a block of zero bytes, and send this final block to the recipient before closing the data connection. (Side note: Microsoft botched the processing of zero-length message tokens in the Microsoft Kerberos SSP in Windows 7 and keeps refusing to fix it. It is still botched in Windows 8. DecryptMessage() will fail with SEC_E_MESSAGE_ALTERED when trying to unprotect a received zero-length message and passing it to DecryptMessage() in SECBUFFER_STREAM after reading it from the network.) > > > (2a) Pass the token to GSS_Process_context_token(), which returns success > > with a minor code indicating the error. Inquire_context is optional; > > Delete_sec_context is required. > > > > This is probably not the right thing to do for a deletion token; we mostly > > should just be ignoring those, these days, I think. > > We can't externally and securely tell if it is a deletion token. Having > GSS_S_COMPLETE for both, error _and_ deletion tokens would mean we never > could tell. That would be mildly dissatisfying, but I could live with > it. While the factual result for the connection would be the same (no more data transfer), having gss_process_context_token() return GSS_S_COMPLETE would make creation, transfer and processing of an error token a silly&useless operation. And the difference in processing an error token in kerberos 1-token (unidirectional) authentication and 2-token (mutual) authentication does not look appealing/desirable to me. > > > (2b) Pass the token to GSS_Process_context_token(), which returns success > > with a minor code indicating the nature of the error in the token for > > error tokens, and just success for deletion tokens. > > Remember, there's no defined no-error minor status. (2b) is > indistinguishable from (2a) unless we also codify that the zero minor > status value is no-error. While it is true that rfc2744 fails to explicitly define a "no-error" minor status code, the spec implicitly requires that one exist (because the gssapi mechanism is explicitly required to _set_ minor_status on each return of a gssapi function. So not saying that minor_status==0 is a no-error looks like a specification defect of the omission kind where the fix is obvious and natural. > > (2b) is better than (2a) because it allows error and deletion tokens to > be distinguished. > > > Nico would accept this, but it's really weird within the GSS-API to have > > information in the minor status when the major status is GSS_S_COMPLETE. > > It's not necessarily all that weird. For one, the RFCs never say this > can't happen... As describe above, this is an implied requirement. YMMV. Expertise&experience is unevenly distributed across implementors, and often time pressure / deadlines pre-empt the necessary think-time for common sense to kick in before code gets shipped. > > > (4) Pass the token to GSS_Process_context_token(), which returns some > > other major code than GSS_S_FAILURE which would be returned from > > GSS_{Init,Accept}_sec_context upon receipt of an error token. > > A lot of common errors have those two functions return GSS_S_FAILURE. > The other errors probably don't cover all errors that the error token > might be reporting. > > ASIDE: I see that I was wrong about the other supplementary major status > codes: the two RFCs do list them for GSS_Init/Accept_sec_context(). > If you could see me now, you'd see me wiping egg from my face. I would be OK with making the behaviour of gss_process_context_token() when processing an error token match that of the context iterator call (gss_init_sec_context(),gss_accept_sec_context()) when processing this error token. -Martin From nobody Wed Nov 5 14:52:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03A01A00CD for ; Wed, 5 Nov 2014 14:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_48=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_66=0.6, 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 L820CjFD2N-s for ; Wed, 5 Nov 2014 14:51:58 -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 293AE1A00BA for ; Wed, 5 Nov 2014 14:51:58 -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 57B973A139; Wed, 5 Nov 2014 23:51:56 +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 4AF8C41D13; Wed, 5 Nov 2014 23:51:56 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 40C221AF95; Wed, 5 Nov 2014 23:51:56 +0100 (CET) In-Reply-To: <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Wed, 5 Nov 2014 23:51:56 +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: <20141105225156.40C221AF95@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DSJHS2rI2JWOneTHlNreQxJiRsI Cc: Kitten WG Subject: [kitten] correction (Re: WGLC of draft-ietf-kitten-gss-loop-00) 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: Wed, 05 Nov 2014 22:52:01 -0000 Fixing two typos ( s/gss_accept_sec_context/gss_init_sec_context/ ): I'm sorry. I firmly believe, that the same error cause should result in mostly the same "look and feel" for the initiator (and the user/caller on top of the initiator side) for both situations (1) and (2). In (2), the KRB_ERROR token will be processed by gss_init_sec_context() and should cause a fatal major status along with a helpful minor_status that conveys the reason from the KRB_ERROR token. In (1), the closest matching behaviour would be that gss_process_context_token() behaves much like gss_init_sec_context() behaves when processing that very KRB_ERROR token. -Martin Martin Rex wrote: > Thanks Ben for the summary. > > I hadn't seen as many options/variants in the discussion, > but I'm also not missing anything, and I also only jumped into the > discussion very late. > > I'm following up to Nico's response for brevity. > > Nico wrote: > > Ben wrote: > >> (3a) Pass the token to GSS_Process_context_token(), which returns > >> GSS_S_COMPLETE for deletion tokens and GSS_S_FAILURE for error tokens. > >> Inquire_context() is still usable, and we always must call > >> Delete_sec_context(). > >> > >> Martin and Nico are okay with this one. The only downside is that 2743 > > > > Yes. I think it's fair to say that Martin prefers this. I do prefer this. > > Confirmed. My preference is (3a). > > > When trying to extend an existing spec that seems incomplete or > ambiguous, it may help to follow the general guideline of > "the principle of least surprise" and look at similar *known* > situations that either already exist or can easily be constructed. > > > Kerberos should be a suitable mechanism to describe what we have > and figure out what should be. > > rfc1964 defines two variants of the Kerberos authentication: > > 1) initiator-to-target authentication with a single context token > > 2) initiator-to-target plus target-to-initiator authentication > ("GSS_C_MUTUAL_FLAG") with two context tokens, one from initiator > to acceptor and one from acceptor to initiator. > > A number of possible error situations that can occur during the > acceptors call to gss_accept_sec_context() will equally be possible > in either of these authentication variants, and could therefore result > in the exact same KRB_ERROR token. > > The difference is, that in (1), there is no expected context level token, > so if gss_accept_sec_context() returns a context level token at all, > and if it is sent back to the initiator at all (in spite of > that token being accompanied by a FATAL major_status from > gss_accept_sec_context()), the initiator will have to pass it to > gss_process_context_token(), because his initial call to > gss_init_sec_context() completed with GSS_S_COMPLETE, and the > initiator does not really expect another context level token. > > > I firmly believe, that the same error cause should result in mostly > the same "look and feel" for the initiator (and the user/caller on > top of the initiator side) for both situations (1) and (2). > > In (2), the KRB_ERROR token will be processed by gss_accept_sec_context() > and should cause a fatal major status along with a helpful minor_status > that conveys the reason from the KRB_ERROR token. > > In (1), the closest matching behaviour would be that > gss_process_context_token() behaves much like gss_accept_sec_context() > behaves when processing that very KRB_ERROR token. > > The only well-defined means how a gss-api mechanism can get a > mechanism-specific error shown to a user/caller is by making a > gssapi call return a fatal major_status along with a helpful minor_status. > > The context-iterators (gss_init_sec_context/gss_accept_sec_context) > are very close relatives to gss_process_context_token() with respect > to processing error tokens, because error tokens that are transfered > as a substitute to a regular, expected context level token will be > processed by a context-iterator, whereas error tokens that are going > to be "unexpected" context level tokens will have to be processed > by gss_process_context_token(). > > Having gss_process_context_token() return an error upon processing > a context deletion would look strange to me. This certainly does not > fit the meaning of failure for that call and if a pair of application > callers uses a context deletion token to "smoothly" close down > a communication channel, why should they receiver be facing a > fatal error message that is _not_ suggested anywhere in the existing > specification. > > > > > Nico Williams wrote: > > On Tue, Nov 04, 2014 at 10:21:29PM -0500, Benjamin Kaduk wrote: > >> > >> Upon receiving a context-level token after its call to > >> GSS_{Accept,Init}_sec_context() has succeeded, a peer may end up calling > >> some or all of GSS_Process_context_token(), GSS_Inquire_context(), and/or > >> GSS_Delete_sec_context(), in that order. Options that have been > >> considered include: > > > > I don't think it was ever the case that not calling Delete_sec_context() > > was OK in the case of context tokens arriving after full security > > context establishment. > > Agreed. There are only two calls that may delete a context (handle): > gss_delete_sec_context() and gss_export_sec_context(). > > gss_init_sec_context() and gss_accept_sec_context() can only fail to > create&return a valid context handle (on the initial call) but should > not delete a context handle that was created by an earlier iterator call. > (from the perspective of formal correctness proofing). > > > > > > > (1b) Pass the token to GSS_Process_context_token(), which returns a > > > different value depending on whether the token was an error token or a > > > deletion token. Whether Delete_sec_context is necessary depends on the > > > particular return. > > > > As of today and per-RFCs 2743 and 2744, GSS_Delete_sec_context() must > > always eventually be called upon processing an error/deletion token > > _except_ when processing returns GSS_S_DEFECTIVE_TOKEN (i.e., the token > > may well not have been an error/deletion token). But even here, the > > application might well find that the peer is no longer responsive or > > closes the connection/whatever. > > Whether receipt of a context level token that is rejected with > GSS_S_DEFECTIVE_TOKEN by the gssapi mechanism is to be seen as > a fatal termination of the communication depends on the specific > application an protocol. There certainly should be some _low_ threshold > how often the application caller on top of gssapi should allow that > to happen and be ignored, or it may open a security vulnerability > (access to an "Oracle"). This is how DTLS was made practically > susceptible to LuckyThirteen, whereas the same attack isn't practical > for TLS, where integrity failures of the communication always fatally > terminate the connection. > > > > > > With that note, (1b) is almost indistinguishable from (3a). > > > > > (1c) Pass the token to GSS_Process_context_token(), which returns success > > > and marks the context as unusable. Call GSS_Inquire_context() to > > > determine whether the context is still valid (returning success and > > > looking at its outputs), and GSS_Delete_sec_context() when we're done. > > > > This works for me as a second choice. It may leave more room for future > > extensibility, but I don't think so: if, for example, we were to add > > something like TLS renego I'd expect a new req_flag/ret_flag and/or > > function call to indicate application support for the feature. > > I'm not aware of any currently well-defined situation/behaviour where > an application that (a) receives a context level token after context > establishment, and (b) properly hands the token to gss_process_context_token() > could expect to continue using the security context. > > A number of "application protocols" that embed gssapi tokens may not > have a mechanism to label/tag tokens with their token type (context vs. > message protection token), and instead, the nature of the token is > implied (everything sent&received before the local context iterator > call returns GSS_S_COMPLETE is a context level token, everything after > it is a message protection token. > > To positively indicate the end of a data transfer, FTP Security extensions > (rfc2228) uses a zero-length protected message: > > http://tools.ietf.org/html/rfc2228#page-15 > > When the end of the file is reached, the sender must encode a block > of zero bytes, and send this final block to the recipient before > closing the data connection. > > (Side note: Microsoft botched the processing of zero-length message > tokens in the Microsoft Kerberos SSP in Windows 7 and keeps refusing > to fix it. It is still botched in Windows 8. DecryptMessage() > will fail with SEC_E_MESSAGE_ALTERED when trying to unprotect > a received zero-length message and passing it to DecryptMessage() > in SECBUFFER_STREAM after reading it from the network.) > > > > > > > > (2a) Pass the token to GSS_Process_context_token(), which returns success > > > with a minor code indicating the error. Inquire_context is optional; > > > Delete_sec_context is required. > > > > > > This is probably not the right thing to do for a deletion token; we mostly > > > should just be ignoring those, these days, I think. > > > > We can't externally and securely tell if it is a deletion token. Having > > GSS_S_COMPLETE for both, error _and_ deletion tokens would mean we never > > could tell. That would be mildly dissatisfying, but I could live with > > it. > > While the factual result for the connection would be the same (no more data > transfer), having gss_process_context_token() return GSS_S_COMPLETE would > make creation, transfer and processing of an error token a silly&useless > operation. And the difference in processing an error token in > kerberos 1-token (unidirectional) authentication and 2-token (mutual) > authentication does not look appealing/desirable to me. > > > > > > > (2b) Pass the token to GSS_Process_context_token(), which returns success > > > with a minor code indicating the nature of the error in the token for > > > error tokens, and just success for deletion tokens. > > > > Remember, there's no defined no-error minor status. (2b) is > > indistinguishable from (2a) unless we also codify that the zero minor > > status value is no-error. > > While it is true that rfc2744 fails to explicitly define a "no-error" > minor status code, the spec implicitly requires that one exist (because > the gssapi mechanism is explicitly required to _set_ minor_status on > each return of a gssapi function. So not saying that minor_status==0 > is a no-error looks like a specification defect of the omission kind > where the fix is obvious and natural. > > > > > > (2b) is better than (2a) because it allows error and deletion tokens to > > be distinguished. > > > > > Nico would accept this, but it's really weird within the GSS-API to have > > > information in the minor status when the major status is GSS_S_COMPLETE. > > > > It's not necessarily all that weird. For one, the RFCs never say this > > can't happen... > > As describe above, this is an implied requirement. YMMV. > > Expertise&experience is unevenly distributed across implementors, > and often time pressure / deadlines pre-empt the necessary think-time > for common sense to kick in before code gets shipped. > > > > > > > (4) Pass the token to GSS_Process_context_token(), which returns some > > > other major code than GSS_S_FAILURE which would be returned from > > > GSS_{Init,Accept}_sec_context upon receipt of an error token. > > > > A lot of common errors have those two functions return GSS_S_FAILURE. > > The other errors probably don't cover all errors that the error token > > might be reporting. > > > > ASIDE: I see that I was wrong about the other supplementary major status > > codes: the two RFCs do list them for GSS_Init/Accept_sec_context(). > > If you could see me now, you'd see me wiping egg from my face. > > > I would be OK with making the behaviour of gss_process_context_token() > when processing an error token match that of the context iterator call > (gss_init_sec_context(),gss_accept_sec_context()) when processing this > error token. > > > -Martin From nobody Wed Nov 5 14:54:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8EE1A0163 for ; Wed, 5 Nov 2014 14:54: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 mU9nI9onigv0 for ; Wed, 5 Nov 2014 14:54: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 DB8D61A0162 for ; Wed, 5 Nov 2014 14:54: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 A9F4843807C; Wed, 5 Nov 2014 14:54: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=gKoRJ9glTRkHkO UNhd/1KT8ZguA=; b=qZlaY0eF6tsiY91p/MZucTdm8COcqCYYsaDsFlys//uar2 WffLD35/zKzCVSnNjW0yedsL0SQ7iPGkLGUpaMcfWpnZiClFjpdrF/xiYbO9Sjyi 4SLUV8okm/s37Qsc7Z/pFHsb/cjM022M9b04CnsNCa1WKhleykX0um7TiMCw0= 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 630CB43801C; Wed, 5 Nov 2014 14:54:25 -0800 (PST) Date: Wed, 5 Nov 2014 16:54:24 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141105225422.GM7913@localhost> References: <20141105041213.GK7913@localhost> <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TEJzdxXwsR4jOEpbf5NAgcjP3fc Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 05 Nov 2014 22:54:26 -0000 On Wed, Nov 05, 2014 at 11:14:50PM +0100, Martin Rex wrote: > While it is true that rfc2744 fails to explicitly define a "no-error" > minor status code, the spec implicitly requires that one exist (because > the gssapi mechanism is explicitly required to _set_ minor_status on > each return of a gssapi function. So not saying that minor_status==0 > is a no-error looks like a specification defect of the omission kind > where the fix is obvious and natural. We could file an erratum for this too. (I don't think we have the energy for a complete update of either RFC. We could do one-off updates of them for this and that minor problem, but even that seems like a lot of energy to put into fixing minor issues that would best be dedicated to other work.) > I would be OK with making the behaviour of gss_process_context_token() > when processing an error token match that of the context iterator call > (gss_init_sec_context(),gss_accept_sec_context()) when processing this > error token. It would create an ambiguity as to GSS_S_DEFECTIVE_TOKEN: is it that the async context token is defective, or that a token we sent was seen as defective by the peer? It would also mean extending the list of major status codes that GSS_Process_context_token() can return. I have absolutely no problem doing that in this case. Nico -- From nobody Wed Nov 5 15:31: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 96F2D1A01FA for ; Wed, 5 Nov 2014 15:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Jnd-bb0ux70l for ; Wed, 5 Nov 2014 15:31: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 D38431A01F9 for ; Wed, 5 Nov 2014 15:31: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 8868821DE58; Wed, 5 Nov 2014 15:31: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=k31v3QhhN4eOXP JLHo8Wdr2FERw=; b=uQd96RmcSXfv1jirLweYJdwcqqbwMomtdmeClBHN+SOR/C KH/PbL+pNdgBWsW29DQjIr9+zb3M0biuq86U89xHxnntcNsWoWH/Yidk6uwEF8z9 FuAmDYFH2dZxV1d/yIMav6ESxduanNZrhM00vO/mqzcBbE2NN2EAPLLqNJwtk= 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 304AD21DE57; Wed, 5 Nov 2014 15:31:40 -0800 (PST) Date: Wed, 5 Nov 2014 17:31:39 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141105233138.GN7913@localhost> References: <20141105041213.GK7913@localhost> <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/z-z51GvY7jNKMbdNflIaVedVMu4 Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 05 Nov 2014 23:31:41 -0000 Incidentally, neither RFC1964 nor RFC4121 say whether the mechanism on the acceptor side should output an error token when there is an error accepting a context w/o mutual auth. I believe most implementations don't. What applications use GSS w/o mutual auth? Aside from test apps (e.g., gss-client), the only one I can think of (proprietary or otherwise) is HTTP/Negotiate [RFC4559], which doesn't say whether to request mutual auth or not (not that it matters much, security-wise, since HTTP/Negotiate doesn't actually use per-message tokens...). [Apologies for the length of this. What follows is a discussion of initiator->acceptor error tokens that can mostly be ignored. We probably shouldn't care about those; if you do, read on.] Also, in general error tokens are most useful when they convey useful information to a user. Users are usually on the initiator side. For acceptors the value in unexpected error tokens is that they indicate that the context should be deleted -- for some apps and/or mechanisms there may be no way to securely indicate this in such a situation. E.g., imagine krb5 outputting a KRB-ERROR when the acceptor's AP-REP is defective. Since the acceptor was [presumably] able to decrypt the initiator's AP-REQ's Ticket and Authenticator (and especially if we had an integrity-protected KRB-ERROR), the acceptor could take the error token as an indication that the gig is up for this context. In the case of Kerberos the initiator application could always use PROT_READY per-message tokens to secure an application-layer delete/ close message, if the application protocol has one. But if this situation was common we'd want to have the initiator output an error token. In practice we just don't care about this situation. Worst case scenario acceptor apps have to deal with timeouts, but all network applications have to anyways. I think asking for initiator->acceptor error tokens would be going bit too far for now. We should want initiator apps to know to use gss_process_context_token() though, for the reasons I gave much earlier in this thread. Nico -- From nobody Wed Nov 5 20:06:08 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 4D51D1A0469 for ; Wed, 5 Nov 2014 20:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 hKGTlTpXkkmC for ; Wed, 5 Nov 2014 20:05:34 -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 045C41A01F6 for ; Wed, 5 Nov 2014 20:04:54 -0800 (PST) X-AuditID: 12074425-f79e46d000002583-94-545af36585a8 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 17.3A.09603.563FA545; Wed, 5 Nov 2014 23:04:53 -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 sA644qHu028757; Wed, 5 Nov 2014 23:04: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 sA644nan027317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Nov 2014 23:04:51 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA644nLc020015; Wed, 5 Nov 2014 23:04:49 -0500 (EST) Date: Wed, 5 Nov 2014 23:04:49 -0500 (EST) From: Benjamin Kaduk To: Martin Rex In-Reply-To: <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> Message-ID: References: <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> 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+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrZv6OSrEYO4aHoujm1exWPT+3sFs ceraETYHZo+Xp84xeixZ8pPJY8rnrYwBzFFcNimpOZllqUX6dglcGQ8P7GYqOGdY8XSZYAPj S/UuRk4OCQETif5Zd9ggbDGJC/fWA9lcHEICs5kk/u1bxwrhbGCUmLZtApRzkEli46RzLCAt QgL1EvNWbAWyOThYBLQknjyzBQmzCahIzHyzEWyqiICsxLRrbxhBSpgF3CRWffYECQsLWEs8 PLGBGcTmFLCR6FrziwnE5hVwlPjfdpwNYrq1xISms2A1ogI6Eqv3T2GBqBGUODnzCZjNDLR1 +fRtLBMYBWchSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKHDZ XVR3ME44pHSIUYCDUYmHV+BEVIgQa2JZcWXuIUZJDiYlUV7uZ0AhvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIrwdb4ByvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvEWf gBoFi1LTUyvSMnNKENJMHJwgw3mAhteA1PAWFyTmFmemQ+RPMSpKifN2giQEQBIZpXlwvbDE 8opRHOgVYd54kCoeYFKC634FNJgJaLBFTwTI4JJEhJRUA2NlQaOt/oTQs//k7+punjw5mjFD c9JnSxlpI8err25eNZ04OXue7PR5fXOf5nJuOHjg9azDT6/8T5dPsan2ttE9d6t4m/Sag/53 5jwpNWJfJnnyRr/Y3HOmGTxhf2PUrl89eaetLeor81L/I5++a5zwmFvyOl1Y21mm+cG36PgH S1rvHuPfJZKuxFKckWioxVxUnAgATf4K8QcDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/_UfAgDeG_EPZAtLaO8t7LHRr5UM Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 06 Nov 2014 04:06:01 -0000 I'm not replying to the previous messages in the subthread after I listed a summary of options; I basically agree with all statements by both Nico and Martin, and don't see anything that clearly needs a reply. Please let me know if you want me to comment on anything in particular. On Wed, 5 Nov 2014, Martin Rex wrote: > I hadn't seen as many options/variants in the discussion, > but I'm also not missing anything, and I also only jumped into the > discussion very late. I was probably overzealous when compiling it, but it doesn't seem harmful to consider extra options. > Nico wrote: > > Ben wrote: > >> (3a) Pass the token to GSS_Process_context_token(), which returns > >> GSS_S_COMPLETE for deletion tokens and GSS_S_FAILURE for error tokens. > >> Inquire_context() is still usable, and we always must call > >> Delete_sec_context(). > >> > >> Martin and Nico are okay with this one. The only downside is that 2743 > > > > Yes. I think it's fair to say that Martin prefers this. I do prefer this. > > Confirmed. My preference is (3a). > > > When trying to extend an existing spec that seems incomplete or > ambiguous, it may help to follow the general guideline of > "the principle of least surprise" and look at similar *known* > situations that either already exist or can easily be constructed. Agreed. > The only well-defined means how a gss-api mechanism can get a > mechanism-specific error shown to a user/caller is by making a > gssapi call return a fatal major_status along with a helpful minor_status. This is also basically true. Some of the numbered proposals offered different options for conveying this sort of information, but they violate the principle of least surprise. > Having gss_process_context_token() return an error upon processing > a context deletion would look strange to me. This certainly does not > fit the meaning of failure for that call and if a pair of application > callers uses a context deletion token to "smoothly" close down > a communication channel, why should they receiver be facing a > fatal error message that is _not_ suggested anywhere in the existing > specification. Okay. > Nico Williams wrote: > > On Tue, Nov 04, 2014 at 10:21:29PM -0500, Benjamin Kaduk wrote: > >> > >> Upon receiving a context-level token after its call to > >> GSS_{Accept,Init}_sec_context() has succeeded, a peer may end up calling > >> some or all of GSS_Process_context_token(), GSS_Inquire_context(), and/or > >> GSS_Delete_sec_context(), in that order. Options that have been > >> considered include: > > > > I don't think it was ever the case that not calling Delete_sec_context() > > was OK in the case of context tokens arriving after full security > > context establishment. > > Agreed. There are only two calls that may delete a context (handle): > gss_delete_sec_context() and gss_export_sec_context(). Yes, it was always the case. Some confused statements may have been made during previous discussions on this thread, but they were wrong. > > With that note, (1b) is almost indistinguishable from (3a). > > > > > (1c) Pass the token to GSS_Process_context_token(), which returns success > > > and marks the context as unusable. Call GSS_Inquire_context() to > > > determine whether the context is still valid (returning success and > > > looking at its outputs), and GSS_Delete_sec_context() when we're done. > > > > This works for me as a second choice. It may leave more room for future > > extensibility, but I don't think so: if, for example, we were to add > > something like TLS renego I'd expect a new req_flag/ret_flag and/or > > function call to indicate application support for the feature. > > I'm not aware of any currently well-defined situation/behaviour where > an application that (a) receives a context level token after context > establishment, and (b) properly hands the token to gss_process_context_token() > could expect to continue using the security context. I agree. Nico is pointing out that we might want to create such situations in the future. > > > (4) Pass the token to GSS_Process_context_token(), which returns some > > > other major code than GSS_S_FAILURE which would be returned from > > > GSS_{Init,Accept}_sec_context upon receipt of an error token. > > > > A lot of common errors have those two functions return GSS_S_FAILURE. > > The other errors probably don't cover all errors that the error token > > might be reporting. > > > > ASIDE: I see that I was wrong about the other supplementary major status > > codes: the two RFCs do list them for GSS_Init/Accept_sec_context(). > > If you could see me now, you'd see me wiping egg from my face. > > > I would be OK with making the behaviour of gss_process_context_token() > when processing an error token match that of the context iterator call > (gss_init_sec_context(),gss_accept_sec_context()) when processing this > error token. Martin pointed out in an off-list message that many of the error codes are explicitly called out in RFC 2743 are referring to a specific input variable to the GSS call in question (e.g., "GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the input_token failed") On Wed, 5 Nov 2014, Nico Williams wrote: > On Wed, Nov 05, 2014 at 11:14:50PM +0100, Martin Rex wrote: > > > I would be OK with making the behaviour of gss_process_context_token() > > when processing an error token match that of the context iterator call > > (gss_init_sec_context(),gss_accept_sec_context()) when processing this > > error token. > > It would create an ambiguity as to GSS_S_DEFECTIVE_TOKEN: is it that the > async context token is defective, or that a token we sent was seen as > defective by the peer? > > It would also mean extending the list of major status codes that > GSS_Process_context_token() can return. I have absolutely no problem > doing that in this case. I don't think we can make that extension in gss-loop, and it seems rather silly to make a one-off document just to do that. Given the restrictions alluded to above, there would probably only be a handful of error codes other than GSS_S_FAILURE that would be permitted, so maybe it is simplest to just use that one. -Ben From nobody Wed Nov 5 20:06:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108CB1A03D0 for ; Wed, 5 Nov 2014 20:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 GZOVMcvaYLNv for ; Wed, 5 Nov 2014 20:05:51 -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 394D71A03A9 for ; Wed, 5 Nov 2014 20:05:05 -0800 (PST) X-AuditID: 1209190e-f79d46d000003643-1b-545af36f0c23 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 08.CF.13891.073FA545; Wed, 5 Nov 2014 23:05:04 -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 sA6453fK028799; Wed, 5 Nov 2014 23:05:03 -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 sA64516e027396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Nov 2014 23:05:02 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA6450vd020060; Wed, 5 Nov 2014 23:05:00 -0500 (EST) Date: Wed, 5 Nov 2014 23:05:00 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141105233138.GN7913@localhost> Message-ID: References: <20141105041213.GK7913@localhost> <20141105221450.6CA001AF95@ld9781.wdf.sap.corp> <20141105233138.GN7913@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+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrVvwOSrE4M89Voujm1exWPT+3sFs ceraETYHZo+Xp84xeixZ8pPJY8rnrYwBzFFcNimpOZllqUX6dglcGUeW7GUtmMdS0bP7AlsD 40rmLkZODgkBE4kLJ28yQthiEhfurWfrYuTiEBKYzSSx994uKGcDo8SBGSeZIJyDTBJL901k 7WLkAHLqJVY8iwPpZhHQkth/bh/YJDYBFYmZbzaygdgiApoS1+ctZQMpZxawkni93AMkLCxg LfHwxAZmkDCngJ7E+akcIGFeAUeJHb3TmWGGz+jWBAmLCuhIrN4/hQWiRFDi5MwnYDYz0NLl 07exTGAUnIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYzgsJXk 28H49aDSIUYBDkYlHl6BE1EhQqyJZcWVuYcYJTmYlER5uZ8BhfiS8lMqMxKLM+KLSnNSiw8x SnAwK4nwdrwByvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfAWfQJq FCxKTU+tSMvMKUFIM3FwggznARq+HaSGt7ggMbc4Mx0if4pRl6Ol6W0vkxBLXn5eqpQ4bydI kQBIUUZpHtwcWLp5xSgO9JYwbzxIFQ8wVcFNegW0hAloiUVPBMiSkkSElFQDY6nDLVtZo5aT zf/YW768fi54jsmOhWW9UMzspE0mqYwNF2TP3nAIcRWRmf/mVevGdWISDZX73/u++G2lKLP+ gGulEW/T71NlN17LhJ78qKV39WrGlL0rWSec3HrlRTzTtLl2udfnnFn07njv3d4FVcqfTZwu TDvw4132jqMPk2MfPL9p5PB/2zclluKMREMt5qLiRAB/Vs4HEgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Ke4hPN3AQdfgswH5TrfGWFrxxdQ Cc: Kitten WG Subject: Re: [kitten] WGLC of draft-ietf-kitten-gss-loop-00 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, 06 Nov 2014 04:06:01 -0000 On Wed, 5 Nov 2014, Nico Williams wrote: > > Incidentally, neither RFC1964 nor RFC4121 say whether the mechanism on > the acceptor side should output an error token when there is an error > accepting a context w/o mutual auth. > > I believe most implementations don't. I agree. > I think asking for initiator->acceptor error tokens would be going bit > too far for now. We should want initiator apps to know to use > gss_process_context_token() though, for the reasons I gave much earlier > in this thread. Yes. -Ben From nobody Thu Nov 6 07:07: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 937D11A6FBB for ; Thu, 6 Nov 2014 07:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SuEjkcAlUFUu for ; Thu, 6 Nov 2014 07:07:35 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03CD1A88EC for ; Thu, 6 Nov 2014 07:07:33 -0800 (PST) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id CF7U1p00C10HQrX01F7VUM; Thu, 06 Nov 2014 16:07:31 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: Date: Thu, 6 Nov 2014 16:07:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> References: <20141027071420.GB14215@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/iy4H-bfKZiLsIETNkXo2M5gg8S8 Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 15:07:38 -0000 Hello Nico, Thanks for writing draft-williams-kitten-krb5-pkcross-05 In 1 Abstract and 1, is it worth emphasising that hitherto unrelated = realms may be connected on-the-fly with PKCROSS? In 2.1, the =93source=94 and =93destination=94 are not immediately = clear; might =93client=94 and =93server=94 or =93user=94 and =93service=94= be better? Note you used =93target=94 for =93destination=94 in 2.2. In 2.1, you might want to make remarks about the validity of the kx509 = certificate and the impact that this has on the validity of the krbtgt. In 2.1, although clear, examples with realm names could be helpful. In 2.2, I have been playing with the idea of using the server key for = the KDC also for the client side. This is not likely to cause problems, = and it will simplify management of certificates in DANE; DANE and its = complex relationships with DNSSEC and cache timing makes it a beast to = operate, so simpler is better. In 2.1 and 2.2, you might want to say that DH should be used for PKINIT. = It is rather interesting here, because the switch is likely to = crossover to other operational control, and the source realm should not = be able to continue to tap traffic. (KRB5-KDH will enable this too, of = course, but then the retrieved identity has been leaked already.) In 2.2, you might want to make explicit that multiple SAN element = id-pkinit-san, and that these then serve as alternatives. This can be = used for sites that support multiple realms. The consequence of = defining it as OR is that the zero element (no id-pkinit-san available) = conforms to a FALSE outcome, which is algebraically sane (and more = importantly, it avoids programming errors). In 2.2, there is probably a lifetime for the cross-realm shared secret. = It is important to define this. There may even be a need to allow some = spare time to deal with distributed clock drift. A question to answer = is when crossover tickets expire and until when they may be renewed; are = they constrained by the ITGT? In 2.2, the result of the exchange is a-symmetric, right? Clients in = one realm can use services in another realm, but the reverse is not = possible without a similar exchange in the opposite direction. That is = the most flexible / general model. It might be good to make that = explicit. In 2.2.1, I cannot make out why the TGT is made to look different from = =93normal=94 ones. Any difference means that the client must have = PKCROSS support built in, even for this TGS mode. The reach of the = mechanism would greatly improve if =93normal=94 TGTs can be sent from = KDC to clients. Can you explain why you need to divert here? I imagine = I would do more work in the KDC than proposed here, is that perhaps not = possible? In 2.3, could it help to redirect to TCP? I don=92t know if a procedure = exists to do that from the KDC, but if so, TCP establishes a connection = and the client does not have to rely on timeouts as with UDP. It is = more likely to work. Alternatively, since the problem is =93softer=94 = than a full failure, it may not be too bad to rely on clients to handle = this cleverly. In 2.4, perhaps emphasise that this MUST be an operator choice, so a = setting on the software. Some will accept self-signed X.509 if it is = found in DANE, others will require DANE on top of X.509 and yet others = may not be willing to setup DANE/DNSSEC for its operational complexity. In 2.4, why does a client not have to validate as well as a KDC if it = uses Client-driven PKCROSS? In 2.5, stapling DANE onto X.509 may lead to differences in TTL for DNS = and kx509 certificates; what to do when DNS expires after an hour? In 2.5, care should be taken that some parties may have an interest in = cutting this path short, to make it look nicer / more reliable. Parties = that could have such an interest should not be empowered to do so. The = reason for these paths is to document reliably how far a client went to = get to a service, right? This is currently missing from the = documentation. Anchor4 =97> the reason to want this could be back-and-forth translation = paths between PKIX and KRB5. It might suffice to avoid this by = requiring only one hop, and inserting the right checks before releasing = credentials. In the end, a user wants to contact a service, and that = may require a direct path, with only one PKCROSS hop in between. In 2.5, it may be meaningless to know that =93some other=94 KDC approves = of a path, if I don=92t know that KDC=92s policy. What handles do you = imagine a relying KDC could use to come to a judgement on that? In 2.6, an alternative could be regularly refreshed keys that a KDC = keeps track of. This would reduce the risk of stored session keys. = (Avoiding this completely may not be possible, since a KDC might crash = while a relying KDC still holds a krbtgt against the crashing one.) = Such long-term keys could be requested in time to avoid the =93impatient = client=94 problem. In fact, a bit of counting could make the KDC learn = about long-term relationships. In 3.2.2, is the domain =93.=94 a suitable high-up domain to trust? Cheers, -Rick= From nobody Thu Nov 6 08:01: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 A7A2F1A1B57 for ; Thu, 6 Nov 2014 08:01:47 -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_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 hnOMwdqxfG08 for ; Thu, 6 Nov 2014 08:01:43 -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 AA7E61A87A7 for ; Thu, 6 Nov 2014 08:01:42 -0800 (PST) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id CG1f1p00Q10HQrX01G1gqV; Thu, 06 Nov 2014 17:01:40 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/mixed; boundary="Apple-Mail=_210351FB-6783-4E11-B3CC-BD07BB8C561E" From: Rick van Rein In-Reply-To: <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> Date: Thu, 6 Nov 2014 17:01:39 +0100 Message-Id: <5780023B-695F-4C98-AAC0-BA32235EFA27@openfortress.nl> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-vBjlPYiu8guylLPvl-LfTR47jc Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 16:01:47 -0000 --Apple-Mail=_210351FB-6783-4E11-B3CC-BD07BB8C561E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nico, It seemed to me that the TGS-Driven PKCROSS approach is more complex = than it needs to be. Perhaps you started out as I did, but if not it = may be interesting to consider the following as an alternative. ## AS-driven PKCROSS This section defines an alternative to Client-driven PKCROSS, and it is designed to encapsulate the logic within a KDC. It works by setting up = a PKINIT exchange, establish a shared secret for one-way trust between two KDC's, and install the resulting key as a manually installed key would = be. Such automatically installed keys expire at some point, and must then be refreshed. This can be done on demand when a client requests access to = an unknown remote realm, or the KDC can continuously refresh certificates = for realms that it knows are regularly needed. The distinction across this choice dimension is a local matter of the KDC and its operational staff, because the protocols do not change on account of it. When TGS request is made for access to a realm that is not locally known to the KDC, the following protocol is initiated: * The user's KDC connects to a service's KDC, using PKINIT. * Both KDCs use their PKINIT server key to authenticate their use of = certificates. * The KDCs mutually authenticate through DANE-with-DNSSEC and/or = through PKIX validation. * During the exchange, a Diffie-Hellman key exchange forms the shared = secret for the realm crossover. * Based on the shared secret, both inject a ticket for realm crossover = from the user's KDC to the service's KDC in their key repositories. * This crossover ticket has an expiration time, as set by the service's = KDC. It is advised to permit somewhat elongated times for this. * Based on this realm-crossover ticket, the KDC's can now proceed as = for manually configured shared keys. Tickets provided on the basis of a realm crossover ticket MUST expire = before or at the expiration of the crossover ticket. If a client KDC = considers the remaining duration too brief, it may request a fresh = crossover ticket instead. A restart of the KDC service MAY lead to loss of a crossover ticket. = When a client KDC has lost a crossover ticket, it may simply request a = fresh one; when a service KDC has lost a crossover ticket the client KDC = would notice that the key is unknown, and it would know to request a = fresh ticket and then to try again. The result of this lenient handling of loss of crossover keys is that no = sessions keys need to be stored persistently. This may help to improve = the security of the KDC service. I hope this is useful! -Rick --Apple-Mail=_210351FB-6783-4E11-B3CC-BD07BB8C561E Content-Disposition: attachment; filename=as-driven-pkcross.xml Content-Type: application/xml; name="as-driven-pkcross.xml" Content-Transfer-Encoding: 7bit
This section defines an alternative to Client-driven PKCROSS, and it is designed to encapsulate the logic within a KDC. It works by setting up a PKINIT exchange, establish a shared secret for one-way trust between two KDC's, and install the resulting key as a manually installed key would be. Such automatically installed keys expire at some point, and must then be refreshed. This can be done on demand when a client requests access to an unknown remote realm, or the KDC can continuously refresh certificates for realms that it knows are regularly needed. The distinction across this choice dimension is a local matter of the KDC and its operational staff, because the protocols do not change on account of it. When TGS request is made for access to a realm that is not locally known to the KDC, the following protocol is initiated: The user's KDC connects to a service's KDC, using PKINIT. Both KDCs use their PKINIT server key to authenticate their use of certificates. The KDCs mutually authenticate through DANE-with-DNSSEC and/or through PKIX validation. During the exchange, a Diffie-Hellman key exchange forms the shared secret for the realm crossover. Based on the shared secret, both inject a ticket for realm crossover from the user's KDC to the service's KDC in their key repositories. This crossover ticket has an expiration time, as set by the service's KDC. It is advised to permit somewhat elongated times for this. Based on this realm-crossover ticket, the KDC's can now proceed as for manually configured shared keys. Tickets provided on the basis of a realm crossover ticket MUST expire before or at the expiration of the crossover ticket. If a client KDC considers the remaining duration too brief, it may request a fresh crossover ticket instead. A restart of the KDC service MAY lead to loss of a crossover ticket. When a client KDC has lost a crossover ticket, it may simply request a fresh one; when a service KDC has lost a crossover ticket the client KDC would notice that the key is unknown, and it would know to request a fresh ticket and then to try again. The result of this lenient handling of loss of crossover keys is that no sessions keys need to be stored persistently. This may help to improve the security of the KDC service.
--Apple-Mail=_210351FB-6783-4E11-B3CC-BD07BB8C561E-- From nobody Thu Nov 6 09:53:48 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 B17A11A889F for ; Thu, 6 Nov 2014 09:53:39 -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 tGye_68Sy2yO for ; Thu, 6 Nov 2014 09:53:37 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A93751A1A71 for ; Thu, 6 Nov 2014 09:53:37 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 642C326406B; Thu, 6 Nov 2014 09:53:37 -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:content-transfer-encoding; s= cryptonector.com; bh=souUjyviA+PZFL89K8GGUvolNxk=; b=BFb75WsP1xJ H5+f1j/u2JGVj6ELjHkt1X9hqE5KdpsofQlSmI/EnPO9ipC50LnK8x0lfNgo+yQl bl3Z06qEk/TBGET9z+kZ75E5ivmcs+yYC7va8YDq4BBUjpPMIQCO8s90p7Aa3H+J RHFu+LkapLdh2ZQZKJjdx0MEg05G3CJA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id 0E39A264070; Thu, 6 Nov 2014 09:53:36 -0800 (PST) Date: Thu, 6 Nov 2014 11:53:36 -0600 From: Nico Williams To: Rick van Rein Message-ID: <20141106175334.GO7913@localhost> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/iLAOgDo9Nq1JAehpkqp8ZX2y5cs Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 17:53:39 -0000 On Thu, Nov 06, 2014 at 04:07:27PM +0100, Rick van Rein wrote: > In 1 Abstract and 1, is it worth emphasising that hitherto unrelated > realms may be connected on-the-fly with PKCROSS? I thought that was implied in the part about scalability. > In 2.1, the =E2=80=9Csource=E2=80=9D and =E2=80=9Cdestination=E2=80=9D = are not immediately clear; > might =E2=80=9Cclient=E2=80=9D and =E2=80=9Cserver=E2=80=9D or =E2=80=9C= user=E2=80=9D and =E2=80=9Cservice=E2=80=9D be better? Note > you used =E2=80=9Ctarget=E2=80=9D for =E2=80=9Cdestination=E2=80=9D in = 2.2. I think "client" and "server" would be more confusing. The source realm need not be the user's realm, nor must the destination realm be the client application's target service's realm either. Speaking of "source" and "target" or "destination" realms seems more appropriate. > In 2.1, you might want to make remarks about the validity of the kx509 > certificate and the impact that this has on the validity of the > krbtgt. Did you mean the validity time period? Sure, that's a good point. > In 2.1, although clear, examples with realm names could be helpful. OK. > In 2.2, I have been playing with the idea of using the server key for > the KDC also for the client side. This is not likely to cause > problems, and it will simplify management of certificates in DANE; > I'm lost here. What server key? > DANE and its complex relationships with DNSSEC and cache timing makes > it a beast to operate, so simpler is better. I don't follow this either. What cache timing? There's no complex relationship between DANE and DNSSEC. DNSSEC might be complex, but DANE is simple. > In 2.1 and 2.2, you might want to say that DH should be used for > PKINIT. It is rather interesting here, because the switch is likely > to crossover to other operational control, and the source realm should > not be able to continue to tap traffic. (KRB5-KDH will enable this > too, of course, but then the retrieved identity has been leaked > already.) The source realm is trusted by the client, and will be able to continue to impersonate the user, but will not be able to mount a passive attack on the user talking to the destination in the client-driven PKCROSS case regardless of whether the client uses DH in PINIT or not. The source realm will be able to mount passive attacks on the users talking to destination realms with the KDC-driven PKCROSS protocol, and this is just a consequence of the Needham-Schroeder protocol, and is true even if the source realm's KDCs use DH in PKINIT. > In 2.2, you might want to make explicit that multiple SAN element > id-pkinit-san, and that these then serve as alternatives. This can be > used for sites that support multiple realms. The consequence of > defining it as OR is that the zero element (no id-pkinit-san > available) conforms to a FALSE outcome, which is algebraically sane > (and more importantly, it avoids programming errors). Well, the KDC-REQ body's cname/crealm have to match one id-pkinit-san SAN, and that should be the one mentioned in 2.2 (I should say this about the KDC-REQ). It doesn't matter if there are multiple id-pkinit-san SANs. > In 2.2, there is probably a lifetime for the cross-realm shared > secret. It is important to define this. There may even be a need to > allow some spare time to deal with distributed clock drift. A > question to answer is when crossover tickets expire and until when > they may be renewed; are they constrained by the ITGT? It *is* the lifetime of the ITGT. It couldn't be otherwise. > In 2.2, the result of the exchange is a-symmetric, right? Clients in The trust is asymmetric, yes. (The ITGT's session key is symmetric.) > one realm can use services in another realm, but the reverse is not > possible without a similar exchange in the opposite direction. That > is the most flexible / general model. It might be good to make that > explicit. Yes. I'll make it more explicit. > In 2.2.1, I cannot make out why the TGT is made to look different from > =E2=80=9Cnormal=E2=80=9D ones. Any difference means that the client mu= st have PKCROSS > support built in, even for this TGS mode. The reach of the mechanism > would greatly improve if =E2=80=9Cnormal=E2=80=9D TGTs can be sent from= KDC to > clients. Can you explain why you need to divert here? I imagine I > would do more work in the KDC than proposed here, is that perhaps not > possible? Cross-realm tickets issued *to clients* this way can't be Ticket PDUs since there's no long-term symmetric key for the cross-realm krbtgt principal. They must have a different form. My choice was to use AP-REQ (from the issuing source realm KDC to the target realm), using the ITGT from the previous step. Clients CANNOT decrypt Tickets (except when they are also the target principal of the Ticket). Therefore clients CANNOT tell the difference. As far as clients are concerned, the KDC-driven PKCROSS case is completely transparent, with the only observable difference being in timing (and only occasionally, when the KDC doesn't already have the necessary ITGT; once a KDC has that ITGT, the clients will observe not even a difference in timing). > In 2.3, could it help to redirect to TCP? I don=E2=80=99t know if a pr= ocedure > exists to do that from the KDC, but if so, TCP establishes a > connection and the client does not have to rely on timeouts as with > UDP. It is more likely to work. Alternatively, since the problem is > =E2=80=9Csofter=E2=80=9D than a full failure, it may not be too bad to = rely on clients > to handle this cleverly. Oh, KRB_ERR_RESPONSE_TOO_BIG. Yes, that's an interesting idea. Clients still apply a timeout in the TCP case though, but they might apply a longer timeout. But anyways, if a client times out and moves on to another KDC it's not that big a deal. The real problem is that it might fail altogether if its timeout is too short and none of the KDCs it talks to already have the required ITGT. > In 2.4, perhaps emphasise that this MUST be an operator choice, so a > setting on the software. Some will accept self-signed X.509 if it is > found in DANE, others will require DANE on top of X.509 and yet others > may not be willing to setup DANE/DNSSEC for its operational > complexity. Sure. By not using RFC2119 language as to this choice I thought this was implicit. > In 2.4, why does a client not have to validate as well as a KDC if it > uses Client-driven PKCROSS? Good point. I was also assuming that the client could do the DANE lookups for the target realm, but we might want a PKINIT extension by which the KDC can staple DANE to its replies. > In 2.5, stapling DANE onto X.509 may lead to differences in TTL for > DNS and kx509 certificates; what to do when DNS expires after an hour? The two things are different. DNS RR TTLs are for caching; they aren't hard expirations. If a kx509 CA wants to issue certificates much longer than its DANE RR TTLs, so be it. I see no need to connect the two. (One might want to publish a CA policy as to max cert life in DNS too, and staple that as well.) > In 2.5, care should be taken that some parties may have an interest in > cutting this path short, to make it look nicer / more reliable. There won't be very many parties involved in the common case. Even in a network with [locally-trusted] gateway outbound/inbound realms = for routing PKCROSS to the world through... the typical path will transit not more than two Kerberos realms and the (DNSSEC) hierarchical path from the PKCROSS source realm to the root. In the more likely (long-term) common case with no gateway realms there will be no Kerberos realms in the transit path, just the domains from the source realm to the root. None of the DNSSEC hierarchical path elements (domainnames) will be "transited" in the sense of having had KDCs visited. Therefore they can't "edit" the path. In either of the two likely cases (with and w/o gateway realms) you have only realms involved that necessarily must be trusted. There's no security consideration here that isn't already in RFC4120. > Parties that could have such an interest should not be empowered to do > so. The reason for these paths is to document reliably how far a > client went to get to a service, right? This is currently missing > from the documentation. We're already making the situation much better than for RFC4120 just by shortening the real transit path (to zero realms). KDCs already can lie, and nothing we can do here can change that. The thing to do is to encourage policies whereby target realms refuse PKCROSS with the crealm not being the same as the issuing TGS's. Oh, incidentally, the KDC-driven PKCROSS case needs an Authenticator authorization-data element for conveying the transit path taken by the client reaching the PKCROSS source realm! I'd missed that completely. > Anchor4 =E2=80=94> the reason to want this could be back-and-forth tran= slation > paths between PKIX and KRB5. It might suffice to avoid this by > requiring only one hop, and inserting the right checks before > releasing credentials. In the end, a user wants to contact a service, > and that may require a direct path, with only one PKCROSS hop in > between. Right, but I was alluding to the problem is that PKIX DNs can't be reliably represented as strings, but that's what Realms are (strings). (That's kinda shocking the first time you hear about it... See RFC4514 for a more complete treatment of this.) I'm expecting the answer here to be "no, that's ETOOHARD for too little value -- none in the DANE case". But in the no-DANE case aliasing of PKIX issuer names could be problematic (though I expect that it won't be any more problematic than the WebPKI already is in itself, and that it won't be at all problematic in proper non-WebPKI PKIs that use naming constraints). > In 2.5, it may be meaningless to know that =E2=80=9Csome other=E2=80=9D= KDC approves > of a path, if I don=E2=80=99t know that KDC=E2=80=99s policy. What han= dles do you > imagine a relying KDC could use to come to a judgement on that? See RFC4120. This is about the service's realm's KDCs' policy. > In 2.6, an alternative could be regularly refreshed keys that a KDC > keeps track of. This would reduce the risk of stored session keys. Sure. Once the x-realm krbtgt principal has long-term keys, they can be changed. > (Avoiding this completely may not be possible, since a KDC might crash > while a relying KDC still holds a krbtgt against the crashing one.) The target realm has to commit and replicate the x-realm krbtgt KDB entry before the source realm starts using it. This is an existing problem. > Such long-term keys could be requested in time to avoid the =E2=80=9Cim= patient > client=E2=80=9D problem. I[...] Yes, when you know you'll need it, of course. > [...]. In fact, a bit of counting could make the KDC learn > about long-term relationships. Indeed. (But beware DoS attacks.) > In 3.2.2, is the domain =E2=80=9C.=E2=80=9D a suitable high-up domain t= o trust? Yes, though it can't be representated in a Kerberos transit path. Nico --=20 From nobody Thu Nov 6 09:57:23 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 410C41A1A71 for ; Thu, 6 Nov 2014 09:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 0rNPnyXJF9kB for ; Thu, 6 Nov 2014 09:57:20 -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 1F4E91A88C4 for ; Thu, 6 Nov 2014 09:57: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 E61B510070; Thu, 6 Nov 2014 09:57:19 -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=2SWVXkExb6yHCY i8ESHMwsRQanA=; b=RXPegvmT4b5D59x5kD+usD5SHKZeqIVhcG+LtVBbXRnfPL 3oqwk+RkG/6progu56MtOH45i1EjzGaczwXwIjU/Z1WsddrFTSxeexai5i2iF93a MIMpvR2fSMElqjAUDUNXQUv7tqGxN9UR0pEcENO+LjOyPUDX9gsm4SxGJUPMI= 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 A2EC010060; Thu, 6 Nov 2014 09:57:19 -0800 (PST) Date: Thu, 6 Nov 2014 11:57:19 -0600 From: Nico Williams To: Rick van Rein Message-ID: <20141106175717.GP7913@localhost> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> <5780023B-695F-4C98-AAC0-BA32235EFA27@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5780023B-695F-4C98-AAC0-BA32235EFA27@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tyQ8y1te7mb4laQff37eczNu38c Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 17:57:21 -0000 On Thu, Nov 06, 2014 at 05:01:39PM +0100, Rick van Rein wrote: > It seemed to me that the TGS-Driven PKCROSS approach is more complex > than it needs to be. Perhaps you started out as I did, but if not it > may be interesting to consider the following as an alternative. I thought it was simple and elegant, particularly the part about the Ticket enc-part's "ciphertext" being actually an AP-REQ. > ## AS-driven PKCROSS > > This section defines an alternative to Client-driven PKCROSS, and it > is designed to encapsulate the logic within a KDC. It works by > setting up a PKINIT exchange, establish a shared secret for one-way > trust between two KDC's, and install the resulting key as a manually > installed key would be. The problem with this is that it requires synchronization and replication (if it were only replication it might not be so bad), and that on both sides. That is pretty much a fatal problem for this approach. I had considered it. Perhaps I should have said something about why it can't work and use that as motivation for the ITGT/AP-REQ-as-Ticket concept, which avoids the sync/replication problem altogether. Nico -- From nobody Thu Nov 6 11:14: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 F28261A1A2D for ; Thu, 6 Nov 2014 11:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 lu4GDbE-5qX8 for ; Thu, 6 Nov 2014 11:14:04 -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 0A2111A1A7B for ; Thu, 6 Nov 2014 11:14:03 -0800 (PST) X-AuditID: 12074425-f79e46d000002583-cd-545bc87aa70a 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 03.12.09603.A78CB545; Thu, 6 Nov 2014 14:14:02 -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 sA6JE2iW026152; Thu, 6 Nov 2014 14:14:02 -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 sA6JE08D023425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Nov 2014 14:14:01 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA6JDxvc013912; Thu, 6 Nov 2014 14:13:59 -0500 (EST) Date: Thu, 6 Nov 2014 14:13:59 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141106175334.GO7913@localhost> Message-ID: References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> <20141106175334.GO7913@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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrVt1IjrEYOsyS4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4u/IRU8EproqvHfOZGxiXcXQxcnJICJhI vF18hwXCFpO4cG89WxcjF4eQwGwmiVvPJ0E5Gxgl9u+YwgThHGSSuH65FSjDAeTUS7Qs5gbp ZhHQkvh4cA3YJDYBFYmZbzaygdgiApoS1+ctBbOZBdQlvp15wwhiCwsESLxtvg9WzymgJ3Fo wS+wOK+Ao8TOBS9YIHa1MEn0n1zADJIQFdCRWL1/CgtEkaDEyZlPWCCGakksn76NZQKj4Cwk qVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpWujlZpbopaaUbmIEhSq7i+oOxgmHlA4x CnAwKvHwCpyIChFiTSwrrsw9xCjJwaQkyht1NDpEiC8pP6UyI7E4I76oNCe1+BCjBAezkggv 2yagHG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBO+DY0CNgkWp6akV aZk5JQhpJg5OkOE8QMOTj4MMLy5IzC3OTIfIn2JUlBLndQBJCIAkMkrz4HphqeQVozjQK8K8 GSBVPMA0BNf9CmgwE9Bgi54IkMEliQgpqQZG7cS41eJ26lfzUvJWZbSWbs7NWnDQ6kbV+SUd av9ehJ1dE3bJ767VkdLl8m4vtm184r5I6tqZ4C7Hzy8Pz0sMeHwxhq22Z+d548vTTa7vM15w cNnCan7n4+vu2hlflWzW3WXxqsEwZKK547ri4jjRQ0aGrxe46kzqOJ5nc/PK3YOymjv4Jv7k VmIpzkg01GIuKk4EABGvO84AAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/BvV3oQWro-5K0ktUw95nw0SqyKU Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 19:14:06 -0000 On Thu, 6 Nov 2014, Nico Williams wrote: > On Thu, Nov 06, 2014 at 04:07:27PM +0100, Rick van Rein wrote: > > In 1 Abstract and 1, is it worth emphasising that hitherto unrelated > > realms may be connected on-the-fly with PKCROSS? > > I thought that was implied in the part about scalability. I think it would be good to mention it explicitly, regardless. On Thu, 6 Nov 2014, Nico Williams wrote: > On Thu, Nov 06, 2014 at 05:01:39PM +0100, Rick van Rein wrote: > > > ## AS-driven PKCROSS > > > > This section defines an alternative to Client-driven PKCROSS, and it > > is designed to encapsulate the logic within a KDC. It works by > > setting up a PKINIT exchange, establish a shared secret for one-way > > trust between two KDC's, and install the resulting key as a manually > > installed key would be. > > The problem with this is that it requires synchronization and > replication (if it were only replication it might not be so bad), and > that on both sides. That is pretty much a fatal problem for this > approach. > > I had considered it. Perhaps I should have said something about why it > can't work and use that as motivation for the ITGT/AP-REQ-as-Ticket > concept, which avoids the sync/replication problem altogether. That could be useful. If it's too long, maybe put it in an appendix? -Ben From nobody Thu Nov 6 11:20:16 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9961E1A1A50 for ; Thu, 6 Nov 2014 11:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 ZzxEbMF-NO42 for ; Thu, 6 Nov 2014 11:20:06 -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 93BFB1A1A1F for ; Thu, 6 Nov 2014 11:20:06 -0800 (PST) X-AuditID: 1209190c-f795e6d000006c66-f5-545bc9e58c9a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 77.D5.27750.5E9CB545; Thu, 6 Nov 2014 14:20: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 sA6JK4Gw027291; Thu, 6 Nov 2014 14:20: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 sA6JK2Js030344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Nov 2014 14:20:03 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA6JK2OO014774; Thu, 6 Nov 2014 14:20:02 -0500 (EST) Date: Thu, 6 Nov 2014 14:20:01 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141104204714.GI7913@localhost> Message-ID: References: <20141104204714.GI7913@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+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrvv0ZHSIQeNWfoujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYs3QCS8FqlooPi/4wNTDuZu5i5OSQEDCR mPZ0JZQtJnHh3nq2LkYuDiGB2UwSBxceZIdwNjBKfOuezQLhHGSSeLXgCViLkEC9xNmrm5i6 GDk4WAS0JE68NwEJswmoSMx8s5ENxBYR0JS4Pm8pmM0sICyx/twMsFZhoPjOr7dYQVo5BfQk Xm4vBQnzCjhK/H/9hQliuq7ExH0vwFpFBXQkVu+fwgJRIyhxcuYTFoiRWhLLp29jmcAoOAtJ ahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBYcopybOD8c1BpUOM AhyMSjy8AieiQoRYE8uKK3MPMUpyMCmJ8kYdjQ4R4kvKT6nMSCzOiC8qzUktPsQowcGsJMLL tgkox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwTv9BFCjYFFqempF WmZOCUKaiYMTZDgP0PAJIDW8xQWJucWZ6RD5U4y6HC1Nb3uZhFjy8vNSpcQhigRAijJK8+Dm wNLLK0ZxoLeEeWeAVPEAUxPcpFdAS5iAllj0RIAsKUlESEk1ME6VsP5jZP21WG/PuVX8TgnC Il+Y4vfNkJL8fXXXJ+mqiUGXI9bycnQrTrqa4f0guEdhwVvv3OMaf2VfBOzs3KvrxX/Q79bC JftrXyZvW/zg0bE+y0NbdTsYq09o3P9WzixwxGD15qRPPr+3l+fnCLXX7dTRaZT9sdPCtCUl YfJ5br71u2/uOK3EUpyRaKjFXFScCAB9PR4VCgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/l7i00YyKheginBsRuiX22ZAcjm0 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: Thu, 06 Nov 2014 19:20:13 -0000 On Tue, 4 Nov 2014, Nico Williams wrote: > I wrote this yesterday but neglected to click the submit button. Just > submitted: > > http://www.rfc-editor.org/errata_search.php?eid=4151 It was probably a little premature to submit while discussion was still ongoing. We could probably wordsmith things a little better, but this looks consistent with the (3a) from my list. And of course it neglects the possibility of (rare) local errors like ENOMEM. That said, I do not think I have any strong objections to any portion of it. -Ben From nobody Thu Nov 6 12:05:21 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 AE20B1A1BA7 for ; Thu, 6 Nov 2014 12:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TIME=2.3, 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 phsGdGGa2i8n for ; Thu, 6 Nov 2014 12:05:12 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB561A1B61 for ; Thu, 6 Nov 2014 12:05:11 -0800 (PST) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id CL581p00510HQrX01L59dq; Thu, 06 Nov 2014 21:05:09 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick van Rein In-Reply-To: <20141106175334.GO7913@localhost> Date: Thu, 6 Nov 2014 21:05:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <011771B0-E738-45EA-9E86-3B73E196D70A@openfortress.nl> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> <20141106175334.GO7913@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/HDjiqufpxzGXZXetXZcZavrFaZI Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 20:05:17 -0000 Hi Nico, >> In 2.2, I have been playing with the idea of using the server key for >> the KDC also for the client side. This is not likely to cause >> problems, and it will simplify management of certificates in DANE; >>=20 > I'm lost here. What server key? During PKINIT, the KDC uses a =93server=94 certificate/key to = authenticate. This cert/key may also be used as a PKINIT client cert/key =97 possibly with a Key Usage added. This could reduce the bookkeeping in DANE, which greatly simplifies that management responsibility. >> DANE and its complex relationships with DNSSEC and cache timing makes >> it a beast to operate, so simpler is better. >=20 > I don't follow this either. What cache timing? There's no complex > relationship between DANE and DNSSEC. DNSSEC might be complex, but = DANE > is simple. =85except in practice. DANE stored in DNS (that is, if not stapled) = deals with DNS cache expirations, and the operational side of controlling proper rollover with different timinig requirements for DNS and the service is rather confusing =97 as soon as you take into account that this may span multiple managing parties. At least, that=92s been our conclusion at SURFnet. DANE is only simple if you control all the parts, and if you=92re willing to carefully handle the DNS TTL stuff, prepare your certificate rollovers in ample time, and if you don=92t = forget to (request) cleanup after DNS has rolled over. >> In 2.1 and 2.2, you might want to say that DH should be used for >> PKINIT. It is rather interesting here, because the switch is likely >> to crossover to other operational control, and the source realm = should >> not be able to continue to tap traffic. (KRB5-KDH will enable this >> too, of course, but then the retrieved identity has been leaked >> already.) >=20 > The source realm is trusted by the client, and will be able to = continue > to impersonate the user, but will not be able to mount a passive = attack > on the user talking to the destination in the client-driven PKCROSS > case regardless of whether the client uses DH in PINIT or not. I agree this is not a =93MUST=94, in light of the trust relation between = client and KDC. > The source realm will be able to mount passive attacks on the users > talking to destination realms with the KDC-driven PKCROSS protocol, = and > this is just a consequence of the Needham-Schroeder protocol, and is > true even if the source realm's KDCs use DH in PKINIT. I am talking of DH between the client and target KDC. The key setup during that exchange should not be passively observed by the client KDC. Again, I said =93should not=94 rather than =93MUST NOT=94. >> In 2.2.1, I cannot make out why the TGT is made to look different = from >> =93normal=94 ones. Thanks for explaining. The I-D wording was a little to dry for me to = get it. You need another TGS-handler then? And you might get in trouble with timing and repeats of the AP-REQ? > Oh, KRB_ERR_RESPONSE_TOO_BIG. Yes, that's an interesting idea. = Clients > still apply a timeout in the TCP case though, but they might apply a > longer timeout. O=85r=85 s=85e=85n=85d=85 o=85n=85e=85 b=85y=85t=85e=85 a=85t=85 = a=85 t=85i=85m=85e=85 > But anyways, if a client times out and moves on to another KDC it's = not > that big a deal. The real problem is that it might fail altogether if > its timeout is too short and none of the KDCs it talks to already have > the required ITGT. Yes. Although keys are usually shared, but you don=92t want to rely on that replicating *that* fast. >> In 2.4, why does a client not have to validate as well as a KDC if it >> uses Client-driven PKCROSS? >=20 > Good point. I was also assuming that the client could do the DANE > lookups for the target realm, but we might want a PKINIT extension by > which the KDC can staple DANE to its replies. Mind you, it has me worried. Clients behind crummy routers that claim to offer DNS but that cut off =93funny extensions=94 such as RRSIG makes DNSSEC unavailable to some. This might mean that a local resolver is required to have an implementation of proper authentication, unless you do include the entire DNSSEC chain as well =97 which IMHO would be possible. >> In 2.5, stapling DANE onto X.509 may lead to differences in TTL for >> DNS and kx509 certificates; what to do when DNS expires after an = hour? >=20 > The two things are different. DNS RR TTLs are for caching; they = aren't > hard expirations. If a kx509 CA wants to issue certificates much = longer > than its DANE RR TTLs, so be it. I see no need to connect the two. Yes, the TTL is meaningless when asserting a certificate for instant = use. One might have (possibly unpractical) concerns about the use of a certificate after the TTL has expired. Normally, one wants to rely on the removal of a certificate from existence when it has gone from DANE. I don=92t know if the browser world is caching DANE validations for = periods that exceed the TTL; I always imagined it is an instant check. > (One might want to publish a CA policy as to max cert life in DNS too, > and staple that as well.) After having co-authored https://dnssec.surfnet.nl/?p=3D771 I=92m not so sure DNSSEC needs more timing parameters ;-) >> In 2.5, care should be taken that some parties may have an interest = in >> cutting this path short, to make it look nicer / more reliable. >=20 > There won't be very many parties involved in the common case. Do you think there is a need for the not-so-common-case, and the brain-startling corner cases that it causes? > In either of the two likely cases (with and w/o gateway realms) you = have > only realms involved that necessarily must be trusted. There's no > security consideration here that isn't already in RFC4120. Pfew, that=92s a relief. > (That's kinda shocking the first time you hear about it... See = RFC4514 > for a more complete treatment of this.) That hurts=85 I had assumed that the mapping from DN to text is a = bijection :-( >> (Avoiding this completely may not be possible, since a KDC might = crash >> while a relying KDC still holds a krbtgt against the crashing one.) >=20 > The target realm has to commit and replicate the x-realm krbtgt KDB > entry before the source realm starts using it. This is an existing > problem. Or=85 you handle the loss by setting up a new pair, and you gain a = system that is less reliant on storing those keys persistently. >> [...]. In fact, a bit of counting could make the KDC learn >> about long-term relationships. >=20 > Indeed. (But beware DoS attacks.) Yep. Counting properly authenticated requests could help to combat DoS attacks I suppose. But this is a general problem indeed. Thanks, -Rick= From nobody Thu Nov 6 12:24:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D42F1A1B5C for ; Thu, 6 Nov 2014 12:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r66nGMB22i88 for ; Thu, 6 Nov 2014 12:24:36 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1131A1AEB for ; Thu, 6 Nov 2014 12:24:36 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 51C2A76805C for ; Thu, 6 Nov 2014 12:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BFDOd7CDAHdFKKKPmgGb 6ZqaaK4=; b=bhl3xWNe5EvbDg/g73lG3HTBpsi+wTDu/MGG4/yVZ4KZ9oJ4CDOP o6FKKhthil4ZeSKEgrZqke4i9L38zn2bnrJMSX7IdB6VO12TxMFd1U4bcm2lHacv aXJWX8uGv3OKa6uV8BrmZZZptVOuBXukKNPqfaRavMwqi5UOsl+Thow= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 2AF25768059 for ; Thu, 6 Nov 2014 12:24:36 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id k14so2117191wgh.28 for ; Thu, 06 Nov 2014 12:24:34 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.240.68 with SMTP id vy4mr9427468wjc.36.1415305474910; Thu, 06 Nov 2014 12:24:34 -0800 (PST) Received: by 10.216.32.135 with HTTP; Thu, 6 Nov 2014 12:24:34 -0800 (PST) In-Reply-To: References: <20141104204714.GI7913@localhost> Date: Thu, 6 Nov 2014 14:24:34 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GShbjVp0e1neR0xcalKqGfe1Zps 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: Thu, 06 Nov 2014 20:24:37 -0000 On Thu, Nov 6, 2014 at 1:20 PM, Benjamin Kaduk wrote: > On Tue, 4 Nov 2014, Nico Williams wrote: >> I wrote this yesterday but neglected to click the submit button. Just >> submitted: >> >> http://www.rfc-editor.org/errata_search.php?eid=4151 > > It was probably a little premature to submit while discussion was still > ongoing. We could probably wordsmith things a little better, but this > looks consistent with the (3a) from my list. Well, it can't be too premature to file the erratum: it has to be discussed regardless. > And of course it neglects the possibility of (rare) local errors like > ENOMEM. Yes, but since either way the context has to be deleted... no harm results. (Also, the peer isn't likely to send an error token saying ENOMEM, not if it has to allocate memory to make it.) > That said, I do not think I have any strong objections to any portion of > it. I think this is likely the consensus. Do we need a formal call for consensus? Do we want to use the erratum for that and wordsmith it first? Nico -- From nobody Thu Nov 6 12:47:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFFC1A007D for ; Thu, 6 Nov 2014 12:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.533 X-Spam-Level: ** X-Spam-Status: No, score=2.533 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MANGLED_TIME=2.3, 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 0j0PQPXDHFeI for ; Thu, 6 Nov 2014 12:47:36 -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 8BA021A1A56 for ; Thu, 6 Nov 2014 12:47:36 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 457E454078; Thu, 6 Nov 2014 12:47:36 -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:content-transfer-encoding; s= cryptonector.com; bh=EDVuj18bEk/wEN/jYX2fsDa+f4U=; b=HyIK3Ser9SF nWs58PNNJeDWsprlIIel0LmdGJfQ/EO1gU/nYEdec6ppiysuk6WHGU+YtcuxNTKe uu9wjCDqRgU+UNbPkIMHwRea+cSe3sIXyv2t8NWAyrg7mAaf6DkrizDEb+wPs2xG 6OsYE0f996fnVH2cgTpcmhicYU/H1yUo= 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 ED06B54075; Thu, 6 Nov 2014 12:47:35 -0800 (PST) Date: Thu, 6 Nov 2014 14:47:34 -0600 From: Nico Williams To: Rick van Rein Message-ID: <20141106204732.GR7913@localhost> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> <20141106175334.GO7913@localhost> <011771B0-E738-45EA-9E86-3B73E196D70A@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <011771B0-E738-45EA-9E86-3B73E196D70A@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GGfG9wok5FSM-s3NE9DyiSnXvyQ Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 20:47:38 -0000 On Thu, Nov 06, 2014 at 09:05:06PM +0100, Rick van Rein wrote: > Hi Nico, >=20 > >> In 2.2, I have been playing with the idea of using the server key fo= r > >> the KDC also for the client side. This is not likely to cause > >> problems, and it will simplify management of certificates in DANE; > >>=20 > > I'm lost here. What server key? >=20 > During PKINIT, the KDC uses a =E2=80=9Cserver=E2=80=9D certificate/key = to authenticate. > This cert/key may also be used as a PKINIT client cert/key =E2=80=94 po= ssibly > with a Key Usage added. This could reduce the bookkeeping in DANE, > which greatly simplifies that management responsibility. Right, I thought that wouldn't need mentioning. The KDC may have one or two certs -- that's an operational detail with little relevance here. The key is to not preclude the use a singular cert for this; I don't think the use of the id-pkcross-issuer EKU does that. ... Let's leave DNSSEC operational matters to the DNS crowd. They are aware of the problems w.r.t. child->parent zone admin communication and they are working on them. > > The source realm will be able to mount passive attacks on the users > > talking to destination realms with the KDC-driven PKCROSS protocol, a= nd > > this is just a consequence of the Needham-Schroeder protocol, and is > > true even if the source realm's KDCs use DH in PKINIT. >=20 > I am talking of DH between the client and target KDC. The key setup > during that exchange should not be passively observed by the client > KDC. Again, I said =E2=80=9Cshould not=E2=80=9D rather than =E2=80=9CM= UST NOT=E2=80=9D. Ah, good point. > >> In 2.2.1, I cannot make out why the TGT is made to look different fr= om > >> =E2=80=9Cnormal=E2=80=9D ones. >=20 > Thanks for explaining. The I-D wording was a little to dry for me to > get it. You need another TGS-handler then? And you might get in > trouble with timing and repeats of the AP-REQ? No, thre's no special "handler", and there's no replay issues either. Clock skew issues are no different than in the pure RFC4120 case. > > Oh, KRB_ERR_RESPONSE_TOO_BIG. Yes, that's an interesting idea. Clie= nts > > still apply a timeout in the TCP case though, but they might apply a > > longer timeout. >=20 > O=E2=80=A6r=E2=80=A6 s=E2=80=A6e=E2=80=A6n=E2=80=A6d=E2=80=A6 o=E2=80= =A6n=E2=80=A6e=E2=80=A6 b=E2=80=A6y=E2=80=A6t=E2=80=A6e=E2=80=A6 a=E2= =80=A6t=E2=80=A6 a=E2=80=A6 t=E2=80=A6i=E2=80=A6m=E2=80=A6e=E2=80=A6 Heh, but timeouts might apply to the whole reply, and sending one byte at a time is problematic for various implementation reasons. > > But anyways, if a client times out and moves on to another KDC it's n= ot > > that big a deal. The real problem is that it might fail altogether i= f > > its timeout is too short and none of the KDCs it talks to already hav= e > > the required ITGT. >=20 > Yes. Although keys are usually shared, but you don=E2=80=99t want to r= ely on > that replicating *that* fast. These keys won't be shared. (They could be, but that would require a replication protocol just for them, which seems unlikely.) Let's gain some deployment experience and see. We might find that there's no real problem, or we might find that changing client-side timeout handling is easier than other options. > >> In 2.4, why does a client not have to validate as well as a KDC if i= t > >> uses Client-driven PKCROSS? > >=20 > > Good point. I was also assuming that the client could do the DANE > > lookups for the target realm, but we might want a PKINIT extension by > > which the KDC can staple DANE to its replies. >=20 > Mind you, it has me worried. Clients behind crummy routers that > claim to offer DNS but that cut off =E2=80=9Cfunny extensions=E2=80=9D = such as RRSIG > makes DNSSEC unavailable to some. This might mean that a local > resolver is required to have an implementation of proper authentication= , > unless you do include the entire DNSSEC chain as well =E2=80=94 which I= MHO > would be possible. That and IAKERB. You're right of course; stapling has to be in both directions. > >> In 2.5, stapling DANE onto X.509 may lead to differences in TTL for > >> DNS and kx509 certificates; what to do when DNS expires after an hou= r? > >=20 > > The two things are different. DNS RR TTLs are for caching; they aren= 't > > hard expirations. If a kx509 CA wants to issue certificates much lon= ger > > than its DANE RR TTLs, so be it. I see no need to connect the two. >=20 > Yes, the TTL is meaningless when asserting a certificate for instant us= e. > One might have (possibly unpractical) concerns about the use of a > certificate after the TTL has expired. Normally, one wants to rely on > the removal of a certificate from existence when it has gone from DANE. One shouldn't have such concerns. The two things are simply not linked. One should re-lookup RRs not in the cache (because the entries in the cache are older than the TTL). > I don=E2=80=99t know if the browser world is caching DANE validations f= or periods > that exceed the TTL; I always imagined it is an instant check. The browsers are not yet using DANE. But anyways, with stapled DANE there's no question of caching. > > There won't be very many parties involved in the common case. >=20 > Do you think there is a need for the not-so-common-case, and the > brain-startling corner cases that it causes? I think the best thing to do may be to drop encoding of PKIX issuers into the transit path altogether, then let just the DANE path (when DANE is used) and the remainder of the normal Kerberos transit path be sufficient. In a world of highly scalable x-realm paths one might require enhancements to transit policy language to set limits on what length transit paths are accepted from certain realms, or what subset of the universe of realms is permitted / not permitted to be reached through certain realms. In practice I think a policy like listing some of the known long-term key= ed trust principals to list acceptable transit paths, then saying all other transit paths must have at most one non-hierarchical transit... should suffice. Some variant of that will suffice for most if not all uses. > > (That's kinda shocking the first time you hear about it... See RFC45= 14 > > for a more complete treatment of this.) >=20 > That hurts=E2=80=A6 I had assumed that the mapping from DN to text is a= bijection :-( When I found out about that (years ago) I was shocked. This is just one of the ways that the x.500 model of naming is a disaster. It is probably the most startling one. Why design a naming system that has no reliable, unambiguous representation for UIs other than GUIs? And even with GUIs, it seems to me that the x.500 model of naming is still too complicated in all the glory of all its detail. > >> (Avoiding this completely may not be possible, since a KDC might cra= sh > >> while a relying KDC still holds a krbtgt against the crashing one.) > >=20 > > The target realm has to commit and replicate the x-realm krbtgt KDB > > entry before the source realm starts using it. This is an existing > > problem. >=20 > Or=E2=80=A6 you handle the loss by setting up a new pair, and you gain = a system > that is less reliant on storing those keys persistently. There's no graceful way to do this other than holding back on the source side until the destination has completed replication. (Re-keying x-realm krbtgt principals is fraught with peril. For one major implementation there's no way to do it without outages, and all you can hope to do is reduce the x-realm TGT lifetime as much as tolerable before the change is made.) Nico --=20 From nobody Thu Nov 6 12:49: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 808D31A6F3F for ; Thu, 6 Nov 2014 12:49:04 -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 JLHccOSTEPNP for ; Thu, 6 Nov 2014 12:49:03 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D148B1A6F3C for ; Thu, 6 Nov 2014 12:49:03 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id AB4841DE070; Thu, 6 Nov 2014 12:49:03 -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=4/rQqaDJ+yOQCn l7r+VpkoUd92Q=; b=tN6WLcAgz/sFrVZzCadgqqAaj3KK2tcSO3N2D+ziTt4unI XOKEx6rS9cxQ31rgXSEzbalEOrn4OZq0jPGS9kpubJNjhhOQtO+smgA7NjUjWgoj iE9UH14O50b3bRvnMNkXCbR5sifoG+IYWn8pqEDWQCn5iZOFF7bL+EbBXDWH0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 53C611DE05D; Thu, 6 Nov 2014 12:49:03 -0800 (PST) Date: Thu, 6 Nov 2014 14:49:02 -0600 From: Nico Williams To: Rick van Rein Message-ID: <20141106204901.GS7913@localhost> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> <20141106175334.GO7913@localhost> <011771B0-E738-45EA-9E86-3B73E196D70A@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011771B0-E738-45EA-9E86-3B73E196D70A@openfortress.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MNN6UIbRgb9QJRXIqMgRF4QAHTI Cc: "kitten@ietf.org" Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 06 Nov 2014 20:49:04 -0000 I should add that my hope is that client timeout issues turn out to be non-issues or easily addressed so that the ITGT approach is the most sensible. Operationally the ITGT approach would be the best as it would be completely automatic. From nobody Thu Nov 6 16:14:11 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B91ACDCE for ; Thu, 6 Nov 2014 16:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1iPFy3wJLFO for ; Thu, 6 Nov 2014 16:14:00 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4664E1ACDCC for ; Thu, 6 Nov 2014 16:14:00 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id E8FA11DE05D for ; Thu, 6 Nov 2014 16:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=X8As8zSczMldEeJgEv3kdIt OfNg=; b=SlPVoxpXgIrFSiyuv+av2LEUfV3Z2uq+a5tg51aeVdml6HrQJKm6jdW 4Lfbimpq73ZCnO67M3QfmGtwebRC6oj3X3FPJa/asyQQjcV6VOv3eWWhnwHIKDfs 0+qxOB80sQpVFj3sfkh37ZVjith8PSISZzTPIPCMRvv00LkI8Jz0= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id C20F21DE058 for ; Thu, 6 Nov 2014 16:13:59 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so3082782wiv.13 for ; Thu, 06 Nov 2014 16:13:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.240.68 with SMTP id vy4mr10915005wjc.36.1415319238364; Thu, 06 Nov 2014 16:13:58 -0800 (PST) Received: by 10.216.32.135 with HTTP; Thu, 6 Nov 2014 16:13:58 -0800 (PST) In-Reply-To: <20141106204901.GS7913@localhost> References: <20141027071420.GB14215@localhost> <55049CF5-4553-4688-86BA-92B3BF45C849@openfortress.nl> <20141106175334.GO7913@localhost> <011771B0-E738-45EA-9E86-3B73E196D70A@openfortress.nl> <20141106204901.GS7913@localhost> Date: Thu, 6 Nov 2014 18:13:58 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NKyarMSrpUL7td8ag7m3Asgglyc Subject: Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business 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, 07 Nov 2014 00:14:01 -0000 Oh, it occurs that sending KRB_ERR_RESPONSE_TOO_BIG in time for the typical client timeout might actually be a way to effectively double the amount of time the KDC has to complete the KDC-driven PKCROSS work. From nobody Thu Nov 6 17:50:59 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 73C811ACE64 for ; Thu, 6 Nov 2014 17:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 08SwIq1i081t for ; Thu, 6 Nov 2014 17:50:55 -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 8B66B1ACE63 for ; Thu, 6 Nov 2014 17:50:55 -0800 (PST) X-AuditID: 1209190e-f79d46d000003643-43-545c257eb0f8 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 92.C5.13891.E752C545; Thu, 6 Nov 2014 20:50:54 -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 sA71orD4023888; Thu, 6 Nov 2014 20:50: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 sA71opQZ027326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Nov 2014 20:50:53 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA71ooIb013191; Thu, 6 Nov 2014 20:50:50 -0500 (EST) Date: Thu, 6 Nov 2014 20:50:50 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <20141104204714.GI7913@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+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrlunGhNi8PIKr8XRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGX82XKHpWANc8WJfQ0sDYyHmLoYOTkkBEwk ji04xQJhi0lcuLeerYuRi0NIYDaTxOVnO8GKhAQ2MEpsucoLkTjIJPFkxRs2iES9xM5bn8CK WAS0JLYeXAo2iU1ARWLmm41gNSICmhLX5y0Fs5kF1CW+nXnDCGILA8V3fr3FCmJzCgRKvJm0 nR3E5hVwlLj7r50RYtkKRonDD16CNYsK6Eis3j+FBaJIUOLkzCcsEEO1JJZP38YygVFwFpLU LCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RSU0o3MYJClVOSbwfj14NKhxgF OBiVeHhv8MaECLEmlhVX5h5ilORgUhLltVUECvEl5adUZiQWZ8QXleakFh9ilOBgVhLhtWEH yvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfCuVQFqFCxKTU+tSMvM KUFIM3FwggznARquDVLDW1yQmFucmQ6RP8Woy9HS9LaXSYglLz8vVUqcVxqkSACkKKM0D24O LMW8YhQHekuY9wlIFQ8wPcFNegW0hAloiUVPBMiSkkSElFQDo2TqQTmftOezzZivZfPXvnjj JqV279+TnOz/RjWr5k//xHH9gtr0wA/9dlk/7y+5/GinrmqeVo2/gGF5imbu520WvKfff3s8 aZJzqrHZ5iq1568LNp56u2U5e/4RZ3bRsxVWif/3XqkqNY06VpTUln1SMGRXhHJvpv6vS77c h+v1y64yvpi/WomlOCPRUIu5qDgRADMHz60MAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7-6cIFfJfPbchSvduUB0H2Bdc8M 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: Fri, 07 Nov 2014 01:50:57 -0000 On Thu, 6 Nov 2014, Nico Williams wrote: > On Thu, Nov 6, 2014 at 1:20 PM, Benjamin Kaduk wrote: > > > That said, I do not think I have any strong objections to any portion of > > it. > > I think this is likely the consensus. Do we need a formal call for > consensus? Do we want to use the erratum for that and wordsmith it > first? I think that's in the AD's court, so let's wait a bit. -Ben From nobody Fri Nov 7 13:13: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 6BCCA1A1B0A for ; Fri, 7 Nov 2014 13:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 GV-v-Zn2qGPt for ; Fri, 7 Nov 2014 13:13:13 -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 14F141A1AE2 for ; Fri, 7 Nov 2014 13:13:10 -0800 (PST) X-AuditID: 12074423-f799d6d00000337c-37-545d35e58e1e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AC.2A.13180.5E53D545; Fri, 7 Nov 2014 16:13:09 -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 sA7LD8xp003759; Fri, 7 Nov 2014 16:13: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 sA7LD65P021930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Nov 2014 16:13:08 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA7LD6Me026126; Fri, 7 Nov 2014 16:13:06 -0500 (EST) Date: Fri, 7 Nov 2014 16:13:06 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141027071704.GC14215@localhost> Message-ID: References: <20141027071704.GC14215@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+NgFnrDIsWRmVeSWpSXmKPExsUixG6novvUNDbEoOmxtMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGU0HF7FWHBRuuLIlqPsDYyLxboYOTkkBEwk Fq+8yQ5hi0lcuLeerYuRi0NIYDaTxMEjF1kgnA2MEr0vdzFCOAeZJJ78/MoC0iIkUC+x/+dk 1i5GDg4WAS2JGUvdQMJsAioSM99sZAOxRQQ0Ja7PWwpmMwsIS6w/N4MZxBYWsJHYcvkd2GZO AX2JlasOMYHYvAKOEvOalrFDjNeTOLmgE6xXVEBHYvX+KSwQNYISJ2c+YYGYqSWxfPo2lgmM grOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6aXm1mil5pSuokRHKguyjsY/xxU OsQowMGoxMN7gzcmRIg1say4MvcQoyQHk5Iob69ebIgQX1J+SmVGYnFGfFFpTmrxIUYJDmYl EV59E6Acb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IELw8wIoUEi1LT UyvSMnNKENJMHJwgw3mAhoPV8BYXJOYWZ6ZD5E8xKkqJ8zqDbBUASWSU5sH1whLJK0ZxoFeE ee+CVPEAkxBc9yugwUxAg/0mxoAMLklESEk1MHJYThZcs2UJ605hFqFJEx9df/pJq5Bb2TeV fanxYsPJ1axvI8OW/6qaw9n94/b9Z7uk5HsO/Nxz9MSHc54LjopvWD+pcwv/hQ8KoifLoneF 17Zl1EVkqGyLfTfFcs6FpTIeiUY2zstC33vJddx4Vfopqv7lIT2f90/WispflrSpm/TQfTLb j5lKLMUZiYZazEXFiQBbdPyi/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/YcYvWrYYvcCc5ZVT1U7FjGOZrOg Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 07 Nov 2014 21:13:15 -0000 On Mon, 27 Oct 2014, Nico Williams wrote: > ----- Forwarded message from internet-drafts@ietf.org ----- > > A new version of I-D, draft-williams-kitten-krb5-extra-rt-02.txt > has been successfully submitted by Nicolas Williams and posted to the > IETF repository. > > Name: draft-williams-kitten-krb5-extra-rt > Revision: 02 > Title: Negotiation of Extra Security Context Tokens for Kerberos V5 Generic Security Services Mechanism > Document date: 2014-10-27 > Group: Individual Submission > Pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-williams-kitten-krb5-extra-rt-02.txt > Status: https://datatracker.ietf.org/doc/draft-williams-kitten-krb5-extra-rt/ > Htmlized: http://tools.ietf.org/html/draft-williams-kitten-krb5-extra-rt-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-kitten-krb5-extra-rt-02 > > Abstract: > This Internet-Draft proposes an extension to the Kerberos V5 security > mechanism for the Generic Security Services Application Programming > Interface (GSS-API) for using extra security context tokens in order > to recover from certain errors. Other benefits include: user-to-user > authentication, authenticated errors, replay cache avoidance, and > others. > > ----- End forwarded message ----- Hmm, I guess I was slow in getting to this, and you put out an -03 already. I read the -03. My summary is: create a KRB-ERROR2 structure that the acceptor can return when the initiator has opted in by setting a flag; KRB-ERROR2 has several nice features compared to KRB-ERROR, including (1) can be encrypted, if a key is available; (2) can indicate to the acceptor to retry with a modified request; (3) can include a challenge nonce/freshness indicator; (4) can include a TGT for use with user-to-user. (It can also be sent from initiator to acceptor when the initiator fails to process a received KRB-ERROR2.) The initiator includes (3) in the follow-up AP-REQ, proving freshness and allowing the replay cache to be safely omitted. Most of the draft is just laying out the details surrounding these and how they are to be used. The core extension seems like a fine thing to have so I would be okay with adopting this as a WG document if we think we have the energy to advance it properly. I have some concerns that some of the text could be written differently and be more clear, most notably section 2. There are a few open questions tagged in the document: [[anchor1: Perhaps we should use a checksum 0x8003 [RFC4121] extension instead of authorization data in the authenticator.]] This is for incorporating the challenge-nonce back into the reply, if I understand correctly. I'm not sure how well that would work if we want to allow for stateless acceptors that use nonces similar to the pkinit freshness tokens we've been discussing. [[anchor2: Question: how should we address this? We could say "give priority to the user-to-user mechanism", but in some cases that might require changes to the acceptor side.]] This refers to the potential for conflict with draft-swift-win2k-krb-user2user, which I haven't read, so I can't say much about. [[anchor3: We could use the GSS_EXTS_FINISHED extension from draft-ietf-kitten-iakerb to implement a strong binding of all context tokens.]] I haven't thought about things hard enough to decide whether the gain in strength of binding is worth the extra work. -Ben From nobody Fri Nov 7 13:44:02 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 8B2E91A1B49 for ; Fri, 7 Nov 2014 13:43:52 -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 v1cQOtmAQ5Z9 for ; Fri, 7 Nov 2014 13:43:51 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 864BB1A1B48 for ; Fri, 7 Nov 2014 13:43:51 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 4CA8367C06E; Fri, 7 Nov 2014 13:43:51 -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=Et82j2pnDUa+AV Kom77JqF0e2JM=; b=e3EEdQUgM04v8IBeh3l3eYPEZc5lt5TWLNmCGKrq6k9G0h tnreKVoYxyM9+rBRCoSCHFAi9eJtVdfSvWUSSPt2yztglKmQh7c3d5WUKho+AjNt TjA3VtxkExKV86JfbbfYJ+OkQAdqV/nIZ9Q3P3rgF1M6dXfBDK+k89yzZBOnk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 09DA467C069; Fri, 7 Nov 2014 13:43:50 -0800 (PST) Date: Fri, 7 Nov 2014 15:43:50 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141107214348.GW7913@localhost> References: <20141027071704.GC14215@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/SR0R92RI48LAn_aRYSud002cmOc Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 07 Nov 2014 21:43:53 -0000 On Fri, Nov 07, 2014 at 04:13:06PM -0500, Benjamin Kaduk wrote: > On Mon, 27 Oct 2014, Nico Williams wrote: > My summary is: [...] That's a fine summary. (Except that I think we seem to agree that there's no need for an initiator->acceptor error context token.) > The initiator includes (3) in the follow-up AP-REQ, proving freshness and > allowing the replay cache to be safely omitted. Yes. > The core extension seems like a fine thing to have so I would be okay with > adopting this as a WG document if we think we have the energy to advance > it properly. Thanks. I hope we do. I think this is sorely needed. > There are a few open questions tagged in the document: > > [[anchor1: Perhaps we should use a checksum 0x8003 [RFC4121] > extension instead of authorization data in the authenticator.]] (FYI, this [[anchorN:...]] business is an artifact of lyx2rfc's rendering of "revision remarks" -- comments intended for rendering, effectively. I should fix this to drop the anchorN business.) > This is for incorporating the challenge-nonce back into the reply, if I > understand correctly. I'm not sure how well that would work if we want to > allow for stateless acceptors that use nonces similar to the pkinit > freshness tokens we've been discussing. It works fine: the acceptor decrypts the Ticket from the AP-REQ, then the Authenticator from the AP-REQ, recovers the challenge, and validates it. The challenge should probably have a timestamp and a counter at the very least, and should be at least integrity protected. I.e., it should be very similar to the PKINIT freshness token. > [[anchor2: Question: how should we address this? We could say "give > priority to the user-to-user mechanism", but in some cases that might > require changes to the acceptor side.]] > > This refers to the potential for conflict with > draft-swift-win2k-krb-user2user, which I haven't read, so I can't say much > about. Consider an initiator app with a mech with these extensions *and* an implementation of draft-swift-win2k-krb-user2user. Now imagine this app talks to an acceptor app that also has both mechanisms but not these extensions. Can we accidentally end up failing to setup a security context? That was my question. However, I'm now convinced that the answer is "no", therefore this section and remark can be removed. The reason the answer is "no" is that if the acceptor app has acceptor credentials for RFC4121 and draft-swift-win2k-krb-user2user then it should be able to use both, otherwise it should only have acceptor credentials for one (if that) and only offer to negotiate those mechanisms for which it has acceptor credentials. It follows then that the situation I feared cannot happen. > [[anchor3: We could use the GSS_EXTS_FINISHED extension from > draft-ietf-kitten-iakerb to implement a strong binding of all context > tokens.]] > > I haven't thought about things hard enough to decide whether the gain in > strength of binding is worth the extra work. I think it's not worth the extra work, but it's important that the acceptor either insist that the cname/crealm of the two AP-REQs be the same, or else ignore the cname/crealm from the first AP-REQ and then rely only on the second AP-REQ's cname/crealm. I feel uneasy about the latter. For PROT_READY purposes it would be convenient if the two Authenticators asserted the same sub-session keys too. I don't think there's any need to bind any more of the exchange, but then, I like the binding everything as a generic defensive design security principle. Nico -- From nobody Fri Nov 7 17:48: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 8965A1A00CD for ; Fri, 7 Nov 2014 17:48:23 -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 YYu4S4KqF__X for ; Fri, 7 Nov 2014 17:48:22 -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 D139A1A00A6 for ; Fri, 7 Nov 2014 17:48:21 -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 72A3E3A338; Sat, 8 Nov 2014 02:48:20 +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 3ADEF422AE; Sat, 8 Nov 2014 02:48:20 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3278A1AFAB; Sat, 8 Nov 2014 02:48:20 +0100 (CET) In-Reply-To: <20141104204714.GI7913@localhost> To: Nico Williams Date: Sat, 8 Nov 2014 02:48:20 +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: <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wtQSmSTvWdqXnhve_Xt-2se47ag 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: Sat, 08 Nov 2014 01:48:23 -0000 Nico Williams wrote: > I wrote this yesterday but neglected to click the submit button. Just > submitted: > > http://www.rfc-editor.org/errata_search.php?eid=4151 I hate to do this (to you), but I'm "violently" opposed to this errata. I believe you have misunderstood the meaning of the original text. Quoting from your errata: 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 peer had an error consuming the last context token sent to it (when the local side must have been fully established but the peer hadn't yet been). The minor status code provides error information from the input token. You find similar descriptions for GSS_S_FAILURE semantics all over the GSS-API specification _on_purpose_, and you _may_not_ remove that meaning here. You may at most add a hint that the minor_status(!!) that must accompany a GSS_S_FAILURE major_status returned from gss_process_context_token() may not just cover reasons that are a "local matter" (i.e. implementation issue of the current gssapi mechanism) but include reasons conveyed through an error token from the remote side. It will be impossible to define portable behaviour to programmatically react to specific such reasons, because what will be returned is not just a local issue, but a remote plus local issue combined. And Ben is right that GSS_S_FAILURE is explicitly supposed to include situations of local resource shortage (no more memory, no more filehandles, no more socket handles, whathaveyou). Btw. any minor_status that conveys an error from a remote peer that was carried in an error token ought to clearly say that this information came from the remote peer (and is not a local error) in the textual translation from gss_display_status(). -Martin From nobody Sat Nov 8 17:41:21 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 7FBFD1A00F5 for ; Sat, 8 Nov 2014 17:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 pUxIfN66I0Xc for ; Sat, 8 Nov 2014 17:41:17 -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 573FF1A00F2 for ; Sat, 8 Nov 2014 17:41:16 -0800 (PST) X-AuditID: 12074424-f79346d000004923-f8-545ec63b5441 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D9.24.18723.B36CE545; Sat, 8 Nov 2014 20:41:15 -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 sA91fFwV003602; Sat, 8 Nov 2014 20:41:15 -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 sA91fCU9007276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Nov 2014 20:41:14 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA91fCJ2029290; Sat, 8 Nov 2014 20:41:12 -0500 (EST) Date: Sat, 8 Nov 2014 20:41:12 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141107214348.GW7913@localhost> Message-ID: References: <20141027071704.GC14215@localhost> <20141107214348.GW7913@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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrWt9LC7E4PVlU4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYOnUHW0GPYMXG99uYGxh38HYxcnJICJhI 9D3exAphi0lcuLeerYuRi0NIYDaTxNVJSxghnA2MEvMeXWCHcA4ySXyb+IkdpEVIoF7id+9B MJtFQEvi2PpvYKPYBFQkZr7ZyAZiiwhoSlyftxTMZhYQllh/bgYziC0sYCOx5fI7oF4ODk4B PYnXEyRAwrwCjhI7V7dC7WpjlLg2fwrYTFEBHYnV+6ewQBQJSpyc+YQFYqaWxPLp21gmMArO QpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRlCosruo7GBsPqR0 iFGAg1GJh/dGS2yIEGtiWXFl7iFGSQ4mJVFe+71xIUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eJd3A+V4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4HxwBahQsSk1P rUjLzClBSDNxcIIM5wEaHnwUZHhxQWJucWY6RP4Uo6KUOO85kGYBkERGaR5cLyyVvGIUB3pF mDcOpJ0HmIbgul8BDWYCGuw3MQZkcEkiQkqqgTFYT7BKkDX/0u2DS1fK3vqz9qOJGs/6pcyP 41bPmr3roeX8ZSePn5s9YdbKy7xVffvTJh5M+q3jcVhtYuy/OIaDl9PEC13naCQyujpdyIy8 NUenJdSyZz1X74lrG+/xzBS88mORhv+ig8uMV3NEC2zo1jPredFnPMdRSo19Qvrcgz5FGdOt TgoqsRRnJBpqMRcVJwIAMbdKdQADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/yEXG0dQnAIPvGpGwEAxLazm2ohA Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 09 Nov 2014 01:41:19 -0000 On Fri, 7 Nov 2014, Nico Williams wrote: > On Fri, Nov 07, 2014 at 04:13:06PM -0500, Benjamin Kaduk wrote: > > On Mon, 27 Oct 2014, Nico Williams wrote: > > My summary is: [...] > > That's a fine summary. (Except that I think we seem to agree that > there's no need for an initiator->acceptor error context token.) Well, I think the acceptor application should be prepared to handle one if it gets one, but maybe the initiator doesn't always need to make/send one. > > [[anchor2: Question: how should we address this? We could say "give > > priority to the user-to-user mechanism", but in some cases that might > > require changes to the acceptor side.]] > > > > This refers to the potential for conflict with > > draft-swift-win2k-krb-user2user, which I haven't read, so I can't say much > > about. > > Consider an initiator app with a mech with these extensions *and* an > implementation of draft-swift-win2k-krb-user2user. Now imagine this app > talks to an acceptor app that also has both mechanisms but not these > extensions. Can we accidentally end up failing to setup a security > context? > > That was my question. Right, that was clear to me from reading the draft; I just don't have an answer. > > [[anchor3: We could use the GSS_EXTS_FINISHED extension from > > draft-ietf-kitten-iakerb to implement a strong binding of all context > > tokens.]] > > > > I haven't thought about things hard enough to decide whether the gain in > > strength of binding is worth the extra work. > > I think it's not worth the extra work, but it's important that the > acceptor either insist that the cname/crealm of the two AP-REQs be the > same, or else ignore the cname/crealm from the first AP-REQ and then > rely only on the second AP-REQ's cname/crealm. I feel uneasy about the > latter. For PROT_READY purposes it would be convenient if the two I also feel uneasy about the latter. -Ben > Authenticators asserted the same sub-session keys too. I don't think > there's any need to bind any more of the exchange, but then, I like the > binding everything as a generic defensive design security principle. From nobody Mon Nov 10 08:25: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 5DF9D1A00B2 for ; Mon, 10 Nov 2014 08:25:09 -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_40=-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 pYRw46-9acym for ; Mon, 10 Nov 2014 08:25:08 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 457FD1A00AF for ; Mon, 10 Nov 2014 08:25:08 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 195FE20024944; Mon, 10 Nov 2014 08: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=TXwdbA5X45NaWg FO8ECIJXv8JiE=; b=coymmp1siNIze+KX1gz4Le8JWZFKxTOjbZoBAU90U9wK9l veLdwZ5vRpTbnE428N9qpF6PVKJYnj72HYyQadxBG8ptwNgX2lXLMAvNA2mxocpg cPXUEl4pOISKi0edfxN7Z28X2VYoxIDz22x3u4hU3oJmeeil1r4yCEPiGnRyI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id C356820024943; Mon, 10 Nov 2014 08:25:07 -0800 (PST) Date: Mon, 10 Nov 2014 10:25:07 -0600 From: Nico Williams To: Martin Rex Message-ID: <20141110162504.GA3412@localhost> References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UrKtRMAvi80IQtkyP-Lrvl8tJaA 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, 10 Nov 2014 16:25:09 -0000 On Sat, Nov 08, 2014 at 02:48:20AM +0100, Martin Rex wrote: > Nico Williams wrote: > > I wrote this yesterday but neglected to click the submit button. Just > > submitted: > > > > http://www.rfc-editor.org/errata_search.php?eid=4151 > > I hate to do this (to you), but I'm "violently" opposed to this errata. Hey, at least you hated doing it! > I believe you have misunderstood the meaning of the original text. Perhaps. The goal is to explain how to process an unexpected error token. > Quoting from your errata: > > 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 peer had an error consuming the > last context token sent to it (when the local side must have been > fully established but the peer hadn't yet been). The minor status > code provides error information from the input token. > > You find similar descriptions for GSS_S_FAILURE semantics all over > the GSS-API specification _on_purpose_, and you _may_not_ remove that > meaning here. Fair enough, we'll add text rather than replace text. > You may at most add a hint that the minor_status(!!) that must > accompany a GSS_S_FAILURE major_status returned from > gss_process_context_token() may not just cover reasons that are > a "local matter" (i.e. implementation issue of the current gssapi > mechanism) but include reasons conveyed through an error token > from the remote side. It will be impossible to define portable > behaviour to programmatically react to specific such reasons, > because what will be returned is not just a local issue, but > a remote plus local issue combined. I agree. > Btw. any minor_status that conveys an error from a remote peer that > was carried in an error token ought to clearly say that this > information came from the remote peer (and is not a local error) in > the textual translation from gss_display_status(). Indeed. Nico -- From nobody Mon Nov 10 08:34:23 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 E63DB1A00E8 for ; Mon, 10 Nov 2014 08:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 T4WF26cMpQiC for ; Mon, 10 Nov 2014 08:34:15 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4315E1A00E4 for ; Mon, 10 Nov 2014 08:34:15 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B0C21360075; Mon, 10 Nov 2014 08:34:14 -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=a92+HdS9Fnb/VJ MGjeBQVLBCo40=; b=EnXBwoCj33n/h7/OwPUJj55m0EjpK2F4/NrwBUAK57gDva qpjh7wkPXwD8eAnUmK0Tn+X4udcvTwjGMTwDkE1Ls4rOpX1PuotsLIy29u+HqwtD 2ENENySI/3PM1t7RvT+TcBZWb0Ynk9+ndF1WIFs5odeCLljMpJaXvCkLAZPoA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 5FA3E36006B; Mon, 10 Nov 2014 08:34:14 -0800 (PST) Date: Mon, 10 Nov 2014 10:34:13 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141110163410.GB3412@localhost> References: <20141027071704.GC14215@localhost> <20141107214348.GW7913@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/DKOyEBjmk5wH6Qp8eeK-L7gQb9E Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 10 Nov 2014 16:34:21 -0000 On Sat, Nov 08, 2014 at 08:41:12PM -0500, Benjamin Kaduk wrote: > On Fri, 7 Nov 2014, Nico Williams wrote: > > That's a fine summary. (Except that I think we seem to agree that > > there's no need for an initiator->acceptor error context token.) > > Well, I think the acceptor application should be prepared to handle > one if it gets one, but maybe the initiator doesn't always need to > make/send one. Agreed, acceptor apps should be required to beprepared to handle them. Q: Should mechanisms specify outputting such error tokens as well? A: Optionally, yes. (my answer) Q: Should initiator apps be expected to send them? A: Optionally, yes. (my answer) > > > [[anchor2: Question: how should we address this? We could say "give > > > priority to the user-to-user mechanism", but in some cases that might > > > require changes to the acceptor side.]] > > > > > > This refers to the potential for conflict with > > > draft-swift-win2k-krb-user2user, which I haven't read, so I can't say much > > > about. > > > > [...] > > Right, that was clear to me from reading the draft; I just don't have > an answer. I'm not convinced that the problem doesn't arise. (An acceptor that supports both mechanisms but not u2u in the krb5 mech will not offer the latter if it doesn't have long-term principal keys with which to accept sec contexts, and the KDC shouldn't return KDC_ERR_MUST_USE_USER2USER if the acceptor has long-term keys. But if this should result for some reason, then we'd have a problem. In practice this doesn't happen, won't happen, and anyways, user2user is exceedingly rare.) > > > [[anchor3: We could use the GSS_EXTS_FINISHED extension from > > > draft-ietf-kitten-iakerb to implement a strong binding of all context > > > tokens.]] > > > > > > I haven't thought about things hard enough to decide whether the gain in > > > strength of binding is worth the extra work. > > > > I think it's not worth the extra work, but it's important that the > > acceptor either insist that the cname/crealm of the two AP-REQs be the > > same, or else ignore the cname/crealm from the first AP-REQ and then > > rely only on the second AP-REQ's cname/crealm. I feel uneasy about the > > latter. For PROT_READY purposes it would be convenient if the two > > I also feel uneasy about the latter. It's trivial to go with the first. I'll make it so. Nico -- From nobody Tue Nov 11 09:59: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 A75021A19EF for ; Tue, 11 Nov 2014 09:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 UBa3Vr0SFx9e for ; Tue, 11 Nov 2014 09:59:46 -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 C319C1A00F2 for ; Tue, 11 Nov 2014 09:59:44 -0800 (PST) X-AuditID: 1209190e-f79d46d000003643-85-54624e8fd83e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 04.46.13891.F8E42645; Tue, 11 Nov 2014 12:59:43 -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 sABHxbEX007564; Tue, 11 Nov 2014 12:59:37 -0500 Received: from [18.101.8.150] (vpn-18-101-8-150.mit.edu [18.101.8.150]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sABHxZi8006759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 12:59:36 -0500 Message-ID: <54624E87.8010007@mit.edu> Date: Tue, 11 Nov 2014 12:59:35 -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: <20141027071704.GC14215@localhost> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrtvvlxRisOO2vMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGWseHibsWC5XMWdTw+YGhiXSHQxcnJICJhI HNp2nhXCFpO4cG89WxcjF4eQwGwmiTlNG5kgnI2MEuuOrGWBcI4wSXw8/ZEZpIVXQE1i7Z3/ QC0cHCwCqhJf1seChNkElCXW79/KAhIWFQiTmLqUB6JaUOLkzCdgYREBT4kP041AwswCwhIX tu8Fu0FYwEZiy+V37CC2kECKxL2uxYwgNqeAk8TqjQ0sEPV6Ejuu/2KFsOUlmrfOZp7AKDgL yYZZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81pXQTIyh4OSX5djB+ Pah0iFGAg1GJh1fDPzFEiDWxrLgy9xCjJAeTkijvdq+kECG+pPyUyozE4oz4otKc1OJDjBIc zEoivJISQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQnejb5AjYJF qempFWmZOSUIaSYOTpDhPEDDS0FqeIsLEnOLM9Mh8qcYFaXEeaeCJARAEhmleXC9sOTyilEc 6BVh3k6QKh5gYoLrfgU0mAlo8LuSBJDBJYkIKakGRi7zJX5cu8OONra/P7d4tea6c4dOXjuT /X9GxtX6uyevT6ov+GYQ/azsXOfn/LVbpcqUJ+WHXmMUfHQ2eG12UMFLY0W/h4qXjqmvbNQR 7dkt9epUuNyr2QYuC1v3bTXfPc95T9yaRt9PYftk711pS7x1O4HB2mfHqh9/ilMaPLsimNi2 ies9MFViKc5INNRiLipOBADTVA6JCQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DPznBB9D6iEIJglC7oKygcleAyY Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 11 Nov 2014 17:59:48 -0000 I support adopting this document. My comments so far: * Encrypting in the null enctype/key isn't a formalized RFC 3961 concept. The RFC will need to explicitly say what goes into the EncryptedData message when encryption isn't possible. * In section 2, there are two bullet points about whether the initiator should attempt to recover, the first for receiving any KRB-ERROR2 and the second for receiving a KRB-ERROR2 with the ke-continue-needed flag set. In the first bullet point, what does "attempt to recover" imply? If the acceptor sent a KRB-ERROR2 without ke-continue-needed, it's not expecting another message, is it? * Do we really need to address the case where the acceptor can decrypt the Ticket but not the Authenticator? If not, we can get rid of KrbErrorEncPartFlags and the receiver can easily deduce the key from the EncryptedData and whether it sent an authenticator subkey. * My preference is not to specify KRB-ERROR2 messages going from the initiator to the acceptor under any circumstances. It seems like a fair amount of implementation complexity for minimal gain; at best the acceptor is going to write something about the error to a log file. * Section 2 says that an initiator MAY produce a token (softened from a MUST in earlier draft versions), but section 2.2 says it MUST produce a KRB-ERROR2 if it rejects an additional round trip. Which is it? I assume there was some concern about early abandonment of the GSSAPI exchange by one of the parties. In my experience, this isn't a serious problem. The MIT krb5 GSS acceptor was doing early abandonment for many releases due to a bug, and while it could obscure error conditions by failing to send an error packet to the client, it didn't seem to break any application protocols. * If the initiator is going to send KRB-ERROR2 messages to the acceptor, we need to specify what key it uses for encryption. (The simplest answer is to use the same key as the acceptor did.) * I don't see any reference to key usages in the draft. If the initiator sends KRB-ERROR2 messages to the acceptor using the same key as the acceptor used, it should use a different key usage to prevent reflection attacks. * How useful is service name redirection if it can only work when the acceptor was able to decrypt the ticket? (The draft bars service name redirection via unencrypted KRB-ERROR2 for fairly obvious security reasons.) * Does it make any sense to put a fast-reauth ticket in a KRB-ERROR2? Wouldn't we want it in an AP-REP instead? (That would render it out of scope for this draft.) * In the U2U flow, is there a reason not to use zero-length octet strings? * Is case 2 of the U2U flow useful? If not, it presents additional attack surface on the initiator implementation for no good reason. * I don't yet have a strong opinion on whether to add a GSS_EXTS_FINISHED binding. There might be a reason for it, but if we can't think of one then I would prefer to avoid the extra complexity. * Do we need new redir-srealm/redir-sname fields for redirection or could we just use srealm/sname? Section 5 says that srealm/sname must mirror those in the Ticket, but I don't see the point of that requirement; an attacker can't replay a KRB-ERROR2 for a different ticket because the key won't match. * Is it right to specify new ASN.1 type definitions to be added to the RFC 4120 ASN.1 module, or should we create a new module with its own OID and import declarations? * Defining KrbErrorEncPartFlags as KerberosFlags seems like a bad fit; it is conceptually an enumeration, not a bitmask. I also have several thoughts about replay cache avoidance, but will put those in a separate message. Editorial comments: * "SHALL have a the" -> "SHALL have the" * "without no fifth token" -> "without a fifth token" From nobody Tue Nov 11 10:51: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 33B501A1AAC for ; Tue, 11 Nov 2014 10:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 K5hDv7-i5dnZ for ; Tue, 11 Nov 2014 10:50:33 -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 118B81A1A7C for ; Tue, 11 Nov 2014 10:50:31 -0800 (PST) X-AuditID: 1209190d-f79c06d000006f95-ec-54625a760ea8 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 E9.03.28565.67A52645; Tue, 11 Nov 2014 13:50:31 -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 sABIoO7p012845; Tue, 11 Nov 2014 13:50:25 -0500 Received: from [18.101.8.150] (vpn-18-101-8-150.mit.edu [18.101.8.150]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sABIoMBZ024299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 13:50:24 -0500 Message-ID: <54625A6E.3000305@mit.edu> Date: Tue, 11 Nov 2014 13:50:22 -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: <20141027071704.GC14215@localhost> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrVselRRi8GUBo8XRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGXc/XyRseCFaEV731S2Bsbjgl2MnBwSAiYS XfemsUHYYhIX7q0Hsrk4hARmM0l8bJwH5WxklPgxbQEjhHOESWLCrY1MIC28AmoSd18tYQex WQRUJVavPMoKYrMJKEus37+VpYuRg0NUIExi6lIeiHJBiZMzn4CFRQQ8JT5MNwIJMwsIS1zY vhesU1jARmLL5XdgE4UEUiTudS1mBLE5BZwkVm9sYIGo15PYcf0XK4QtL9G8dTbzBEbBWUg2 zEJSNgtJ2QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxjB4SvJu4Px3UGl Q4wCHIxKPLwa/okhQqyJZcWVuYcYJTmYlER5hcOSQoT4kvJTKjMSizPii0pzUosPMUpwMCuJ 8DKA5HhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHjl/IEaBYtS01Mr 0jJzShDSTBycIMN5gIbLRIIMLy5IzC3OTIfIn2JUlBLndQFJCIAkMkrz4Hph6eUVozjQK8K8 4iBVPMDUBNf9CmgwE9Dgb+Fgg0sSEVJSDYzd3zYVqnrEz9zXOoebZfXyOVWlind05svUeQWY KkYf39ElbP1Pbeb0kwoMl7srdhZulaz6t3jW0wMplirWi3O+ysbZ5Kd6TIyrv7lnx/65n6Yf ez5vXtv8xU67d7wKZlI3vmk9l9Hzt/7mufrTF4jkNe7VPBmtMVlGm1n7Sdz9FduXCrz/nL1C iaU4I9FQi7moOBEAvJhNQQoDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/SDKzafaKV1RXQVKnKIB1lg8zfWI Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 11 Nov 2014 18:50:38 -0000 Here are further thoughts on replay cache avoidance as it affects this draft. Replay caches help in two cases: 1. They provide minimal protection when a krb5 exchange takes place over an unprotected channel and is used for authentication only, with no use of the resulting key. This protection is minimal because a replay attack assumes an active attacker, who could perhaps suppress the original exchange, beat the original exchange with the replay, or compromise the channel after authentication. It is not totally unreasonable to abandon case 1 as hopeless, but for the purpose of this message I will assume we still care about it. 2. They prevent an entire session from being replayed, causing a properly authenticated request to be processed twice within the replay window. This is not a concern when an acceptor subkey is used. (I assume that legitimate initiators don't use prot-ready messages or send wrap tokens using the initiator subkey. I think in practice RFC 4121 implementations don't set the prot-ready flag and initiators never use the initiator subkey.) A krb5 acceptor implementation generally does not know whether the application protocol will use the context key or whether there is a different case 1 acceptor using the same long-term acceptor keys. Because of this, it is intrinsically difficult for an implementation to know that it is safe not to use a replay cache for case 1. The extra round trips draft allows the acceptor to ask an initiator to encrypt a nonce, which would defeat a replay attack if everyone had to do it. However: * There is an easy downgrade attack on the extra round trip. Until client implementations are ubiquitous enough for acceptors to turn off support for basic RFC 4121, an attacker can simply suppress the extra round trip. * The first authenticator must still be added to the replay cache if it might be used for a case 1 acceptor--and if this acceptor would be a case 1 acceptor without the extra round trip, allowing basic RFC 4121 means it is still a case 1 acceptor. So this doesn't really seem to give us replay cache avoidance until basic RFC 4121 can be turned off. Specific notes: * The MUST in section 4 is not necessary for interoperability or security, and as such ought to be a SHOULD. * Section 2.2.1 states that after a recoverable error, a fifth token is not required because of the nonce in the second token. I am not sure this is true--the nonce in the second token was not necessarily encrypted; if it wasn't, an attacker could feed it to a legitimate initiator in a separate exchange. * For pedagogical purposes, section 4 should probably be explicit about what the initiator does in response to a KRB-ERROR2 with a KDC_ERR_NONE code. From nobody Tue Nov 11 10:54: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 912121A1AFD for ; Tue, 11 Nov 2014 10:54: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 1aAVslFAIfGL for ; Tue, 11 Nov 2014 10:54:35 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 949621A1AE0 for ; Tue, 11 Nov 2014 10:54:27 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 513A894075; Tue, 11 Nov 2014 10:54:27 -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=FCMcXDEQ+SDN8p wfVpPjwzOUF0M=; b=Ke7AjMDg9lkXvptKwyIdvURDS7Ftlir1qf9F11XVD6RsL9 3Cu80UbUieyKOZ6N6nxA3Skt1xRlJvYZBAP24h3FmJnbKw7UqwA3ypZLc4g1wQky srWmsEC7H0b3PLQ8JCcffEfqXb6DLxTX3s6ZKhjMTgw8Nn9vKMKZ1rjxu3q2E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id B65099406B; Tue, 11 Nov 2014 10:54:26 -0800 (PST) Date: Tue, 11 Nov 2014 12:54:25 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141111185423.GM3412@localhost> References: <20141027071704.GC14215@localhost> <54624E87.8010007@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54624E87.8010007@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/xFi5-uCIrQZ9FQUqdBoZMGSeTWw Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 11 Nov 2014 18:54:36 -0000 On Tue, Nov 11, 2014 at 12:59:35PM -0500, Greg Hudson wrote: > I support adopting this document. My comments so far: Thanks. > * Encrypting in the null enctype/key isn't a formalized RFC 3961 > concept. The RFC will need to explicitly say what goes into the > EncryptedData message when encryption isn't possible. I thought we ended up saying that the null enctype does have a purpose after all (was it about KRB-CRED? I forget). But yes. > * In section 2, there are two bullet points about whether the initiator > should attempt to recover, the first for receiving any KRB-ERROR2 and > the second for receiving a KRB-ERROR2 with the ke-continue-needed flag > set. In the first bullet point, what does "attempt to recover" imply? That's covered in section 2.1. > If the acceptor sent a KRB-ERROR2 without ke-continue-needed, it's not > expecting another message, is it? Ah, this is an editing error. Thanks for catching this. > * Do we really need to address the case where the acceptor can decrypt > the Ticket but not the Authenticator? If not, we can get rid of > KrbErrorEncPartFlags and the receiver can easily deduce the key from > the EncryptedData and whether it sent an authenticator subkey. I was wondering about this. If the acceptor can decrypt the Ticket but not the Authenticator then there was a transmission error, and the question is whether it's worth trying to recover from that. My guess now is "no". > * My preference is not to specify KRB-ERROR2 messages going from the > initiator to the acceptor under any circumstances. It seems like a fair > amount of implementation complexity for minimal gain; at best the > acceptor is going to write something about the error to a log file. What I'd like to say is that initiator _apps_ shouldn't bother sending error tokens to acceptors. Allowing the initiator _mech_ to produce them (and the acceptor _mech_ to consume them) is an exercise in completeness that would enable role reversal applications. Perhaps we shouldn't care about role reversal applications (since we have none). But since this has been needed in the past (ISMS or some such), I'd want a bit more discussion before discounting them altogether. > * Section 2 says that an initiator MAY produce a token (softened from a > MUST in earlier draft versions), but section 2.2 says it MUST produce a > KRB-ERROR2 if it rejects an additional round trip. Which is it? I > assume there was some concern about early abandonment of the GSSAPI > exchange by one of the parties. In my experience, this isn't a serious > problem. The MIT krb5 GSS acceptor was doing early abandonment for many > releases due to a bug, and while it could obscure error conditions by > failing to send an error packet to the client, it didn't seem to break > any application protocols. Yeah, it's about abandonment. There may well be no value to it because apps always have to deal with timeouts anyways. Not forcing a peer to timeout is a matter of courtesy, but if the peer minimizes state kept (as it should), it may not matter much. > * If the initiator is going to send KRB-ERROR2 messages to the acceptor, > we need to specify what key it uses for encryption. (The simplest > answer is to use the same key as the acceptor did.) Right (or more likely a dk in the same key hierarchy). > * I don't see any reference to key usages in the draft. If the > initiator sends KRB-ERROR2 messages to the acceptor using the same key > as the acceptor used, it should use a different key usage to prevent > reflection attacks. Yep, this is missing. > * How useful is service name redirection if it can only work when the > acceptor was able to decrypt the ticket? (The draft bars service name > redirection via unencrypted KRB-ERROR2 for fairly obvious security reasons.) I thought I ripped that out completely in the latest version. Did I leave stray text about it? > * Does it make any sense to put a fast-reauth ticket in a KRB-ERROR2? > Wouldn't we want it in an AP-REP instead? (That would render it out of > scope for this draft.) Two reasons: a) the server might still want rcache avoidance, b) I wanted to avoid having to extend AP-REP (though I'd be happy to extend it anyways). (b) is lame; (a) is not. > * In the U2U flow, is there a reason not to use zero-length octet > strings? Not sure. > * Is case 2 of the U2U flow useful? If not, it presents additional > attack surface on the initiator implementation for no good reason. I think it might be. Think of authz-data in the u2u TGT affecting what appears in the service ticket in the end. > * I don't yet have a strong opinion on whether to add a > GSS_EXTS_FINISHED binding. There might be a reason for it, but if we > can't think of one then I would prefer to avoid the extra complexity. It's that or authz-data. > * Do we need new redir-srealm/redir-sname fields for redirection or > could we just use srealm/sname? Section 5 says that srealm/sname must > mirror those in the Ticket, but I don't see the point of that > requirement; an attacker can't replay a KRB-ERROR2 for a different > ticket because the key won't match. Again, I thought I'd ripped that out. > * Is it right to specify new ASN.1 type definitions to be added to the > RFC 4120 ASN.1 module, or should we create a new module with its own OID > and import declarations? Either is fine with me. > * Defining KrbErrorEncPartFlags as KerberosFlags seems like a bad fit; > it is conceptually an enumeration, not a bitmask. Sure. I was following tradition :) > I also have several thoughts about replay cache avoidance, but will put > those in a separate message. OK. Thanks! Nico -- From nobody Tue Nov 11 12:57: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 7D6371AC3EF for ; Tue, 11 Nov 2014 12:57:35 -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 YP4ceBYm5Zf7 for ; Tue, 11 Nov 2014 12:57:34 -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 80C021AC3F1 for ; Tue, 11 Nov 2014 12:57:34 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 452C120058D80; Tue, 11 Nov 2014 12:57:34 -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=RnFJJV3eFfOP38 ieryO2eZXl5cI=; b=CIeD5XKckBCYlixKgijokmPEJ2Q7iFsdKkg0lZGVvU4YG1 suNe/vesP2Db7qaSUIZUyzWNM7kbNt5LIWGFRlksR7RV9HmlKzmLOCHB0YqaIEK1 zFXkB7Uy2rnr7qZSiBGtFtQI32FNfT+VaK4XfjcJpezQkbH7beHzFKdcZ7WB4= 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 E7AB02005D82E; Tue, 11 Nov 2014 12:57:33 -0800 (PST) Date: Tue, 11 Nov 2014 14:57:33 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141111205731.GO3412@localhost> References: <20141027071704.GC14215@localhost> <54625A6E.3000305@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54625A6E.3000305@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/o_XroPe5jE9Xy7mJszwdFT1KIjY Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 11 Nov 2014 20:57:35 -0000 On Tue, Nov 11, 2014 at 01:50:22PM -0500, Greg Hudson wrote: FYI, I had a separate replay cache avoidance I-D that I'm looking to abandon and replace with this one. I didn't adopt all of the content of that older I-D. > Replay caches help in two cases: > > 1. They provide minimal protection when a krb5 exchange takes place over > an unprotected channel and is used for authentication only, with no use > of the resulting key. This protection is minimal [...] This affects SSHv2 in particular because it shares a service name with things like rsh/rlogin/telnet, and those aren't always configured to protect the entirety of their sessions. It also affects every service in environments where every host-based service shares a single long-term key on the same host. It might be nice to simply make this go away by using 1.5rt for the AP exchange wherever possible. > 2. They prevent an entire session from being replayed, causing a > properly authenticated request to be processed twice within the replay > window. This is not a concern when an acceptor subkey is used. (I > assume that legitimate initiators don't use prot-ready messages or send > wrap tokens using the initiator subkey. I think in practice RFC 4121 > implementations don't set the prot-ready flag and initiators never use > the initiator subkey.) PROT_READY is nice to have, but only for data that is not too sensitive. E.g., if the first message sent will be something like "list new messages", then that's OK, but if it's going to be "list activity in bank account #..." then it may not be. > A krb5 acceptor implementation generally does not know whether the > application protocol will use the context key or whether there is a > different case 1 acceptor using the same long-term acceptor keys. That and the above point about multiple host-based services sharing a single long-term key on any given host in some environments. > Because of this, it is intrinsically difficult for an implementation to > know that it is safe not to use a replay cache for case 1. Yes. > The extra round trips draft allows the acceptor to ask an initiator to > encrypt a nonce, which would defeat a replay attack if everyone had to > do it. However: > > * There is an easy downgrade attack on the extra round trip. Until > client implementations are ubiquitous enough for acceptors to turn off > support for basic RFC 4121, an attacker can simply suppress the extra > round trip. Speaking of which, I'd meant to also have an authz-data element for indicating willingness to use extra round trips. > * The first authenticator must still be added to the replay cache if it > might be used for a case 1 acceptor--and if this acceptor would be a > case 1 acceptor without the extra round trip, allowing basic RFC 4121 > means it is still a case 1 acceptor. See above comment about authz-data. > So this doesn't really seem to give us replay cache avoidance until > basic RFC 4121 can be turned off. Or, rather, until all mechanism acceptor implementations on a host can be upgraded. > * Section 2.2.1 states that after a recoverable error, a fifth token is > not required because of the nonce in the second token. I am not sure > this is true--the nonce in the second token was not necessarily > encrypted; if it wasn't, an attacker could feed it to a legitimate > initiator in a separate exchange. The nonce should be tied to a single partially-established security context. It should not be accepted on other new contexts. > * For pedagogical purposes, section 4 should probably be explicit about > what the initiator does in response to a KRB-ERROR2 with a KDC_ERR_NONE > code. OK. Nico -- From nobody Wed Nov 12 08:01:10 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 84A921A6EE5; Wed, 12 Nov 2014 08:01:07 -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 ZTZNfvhvflZL; Wed, 12 Nov 2014 08:01:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AECE1A1BEA; Wed, 12 Nov 2014 08:01:01 -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.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141112160101.21067.76872.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 08:01:01 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EgomLDG9WZdOgfORzSTTCZzNNjQ Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-17.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, 12 Nov 2014 16:01:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-17.txt Pages : 22 Date : 2014-11-12 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-17 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 Nov 12 08:35: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 1ECF31A890F for ; Wed, 12 Nov 2014 08:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 62Ohr8eXJDnJ for ; Wed, 12 Nov 2014 08:35: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 6E19A1A894F for ; Wed, 12 Nov 2014 08:35:27 -0800 (PST) X-AuditID: 12074425-f79e46d000002583-c7-54638c4e3252 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 13.38.09603.E4C83645; Wed, 12 Nov 2014 11:35:26 -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 sACGZKK3031097; Wed, 12 Nov 2014 11:35:20 -0500 Received: from [18.101.8.234] (vpn-18-101-8-234.mit.edu [18.101.8.234]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sACGZIjt015941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Nov 2014 11:35:19 -0500 Message-ID: <54638C46.8060203@mit.edu> Date: Wed, 12 Nov 2014 11:35:18 -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: <20141027071704.GC14215@localhost> <54624E87.8010007@mit.edu> <20141111185423.GM3412@localhost> In-Reply-To: <20141111185423.GM3412@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrOvXkxxicGi3jMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGU0THzDUnBKoOL34U7mBsaFvF2MnBwSAiYS D36dZISwxSQu3FvPBmILCcxmklh21byLkQvI3sgocefhXzYI5wiTxJoTp1hBqngF1CT+fell AbFZBFQlFj9eDxZnE1CWWL9/K1Ccg0NUIExi6lIeiHJBiZMzn4CViwhoSlyftxRsGbOAscSl HohWYQEbiS2X37FD7FrIKLG69RZYglNAT+L4lV52iAY9iR3Xf7FC2PISzVtnM09gFJyFZMcs JGWzkJQtYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERTA7C6qOxgnHFI6 xCjAwajEw8uxKilEiDWxrLgy9xCjJAeTkijvpI7kECG+pPyUyozE4oz4otKc1OJDjBIczEoi vP71QDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQlev26gRsGi1PTU irTMnBKENBMHJ8hwHqDhbSA1vMUFibnFmekQ+VOMilLivLu7gBICIImM0jy4XliCecUoDvSK MG8JSDsPMDnBdb8CGswENPhbeBLI4JJEhJRUAyMv46SkTI03R12CLqq5p/JO0ciZ9V4nOIxv q1zOqjgGA/lQXU3XNtGlmW33EiK3qy25eqR+1fZFu4oqZ6ZJt1s1sjn5F3vbnPb4Ys06/8D5 4iMdZSxnao8qvS9ruet2f940FxajO1efphlv/eGezdakO01UM+/iAfEHF/yvL7qv9+brnP7Z 55RYijMSDbWYi4oTAdAzz8MLAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fLj4mHuZriQeX1hG5ksJ1yWhtls Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 12 Nov 2014 16:35:33 -0000 On 11/11/2014 01:54 PM, Nico Williams wrote: > I thought I ripped [service name redirection] out completely in the latest > version. Did I leave stray text about it? My bad. I started reviewing -01 by mistake, then attempted to update my comments for -03, and missed that service name redirection was gone in -03. >> * Does it make any sense to put a fast-reauth ticket in a KRB-ERROR2? >> Wouldn't we want it in an AP-REP instead? (That would render it out of >> scope for this draft.) > > Two reasons: a) the server might still want rcache avoidance, b) I > wanted to avoid having to extend AP-REP (though I'd be happy to extend > it anyways). (b) is lame; (a) is not. This brings up a larger point that I previously missed: in the rcache avoidance flow with an odd number of tokens, there is no AP-REP token in the exchange. So, should rcache avoidance should use a modified KRB-ERROR or a modified AP-REP? I think using a modified AP-REP is more natural, but it does mean adding a second new message type and adding the nonce to both messages. If we do use a modified KRB-ERROR in this flow, then we need to make sure that we get all of the security properties we would get from the AP-REP. The AP-REP provides: * Mutual authentication through use of the authenticator subkey (or ticket session key if none was used). An encrypted KRB-ERROR provides this, but section 4 needs to say that an unencrypted KRB-ERROR with code KDC_ERR_NONE MUST be treated as an error by the initiator. * An acceptor subkey, which prevents whole-session replays even without a replay cache (assuming the legitimate initiator uses it for all important messages). It might be okay to omit the acceptor subkey since the nonce provides the same property, but we would definitely need some rationale. * A mirror of the authenticator timestamps, to prevent AP-REP replays. This does not seem important if an authenticator subkey was used. We could require that the initiator use an authenticator subkey. We also need to consider how this all interacts with draft-vanrein-krb5-kdh. From nobody Wed Nov 12 12:06:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEFC1A8725 for ; Wed, 12 Nov 2014 12:06:22 -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 X7gLbISqHzTX for ; Wed, 12 Nov 2014 12:06:20 -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 443F41AD00B for ; Wed, 12 Nov 2014 12:05:55 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id AF9EC584064; Wed, 12 Nov 2014 12:05:55 -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=/wvfjjE5fvy3iJ BbNQBsLzebvxM=; b=AZrMHUbmaOhGGLQtGkGRmRumMatx+nv9ks8ear3JCgeUrL v6b9flB3+B2tsQu7bzNW9QvXrOEtOvfgxEMAG5yKLQr6DhFNyRrTnqHCtyAZIoPa ewu6vwz1AGwmxycPUUZKBoyUti6LJNAu3VhjrOViVKrrC6XueoSoFwX0OBclI= 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 55F66584059; Wed, 12 Nov 2014 12:05:55 -0800 (PST) Date: Wed, 12 Nov 2014 14:05:54 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141112200552.GA3124@localhost> References: <20141027071704.GC14215@localhost> <54624E87.8010007@mit.edu> <20141111185423.GM3412@localhost> <54638C46.8060203@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54638C46.8060203@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kV0wjdwXgTUNpAzUJ_SAhnAAMbY Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 12 Nov 2014 20:06:23 -0000 On Wed, Nov 12, 2014 at 11:35:18AM -0500, Greg Hudson wrote: > This brings up a larger point that I previously missed: in the rcache > avoidance flow with an odd number of tokens, there is no AP-REP token in > the exchange. I removed too much when I removed sname/srealm. The intention is to use the KRB-ERROR2 as an AP-REP in the three-token flow, which means that it needs to have an optional sub-session key field (and which must be present when the initiator's AP-REQ was fine but the acceptor wants that third token). I added this back for -04 (not yet submitted). > So, should rcache avoidance should use a modified KRB-ERROR or a > modified AP-REP? I think using a modified AP-REP is more natural, but > it does mean adding a second new message type and adding the nonce to > both messages. Right. To me KRB-ERROR2 can fill both roles. > If we do use a modified KRB-ERROR in this flow, then we need to make > sure that we get all of the security properties we would get from the > AP-REP. The AP-REP provides: Agreed. I'll be re-adding the acceptor sub-session key, I'll add the mirrored timestamp, and I'll add authz-data (not just typed-data) so that this message really can serve as both, KRB-ERROR2 and AP-REP2. (Authz-data, for example, could be useful here in the user-to-user case, for symmetry, but also so we don't have to define both, authz-data and typed-data elements for things like kDH pubkeys.) > We also need to consider how this all interacts with > draft-vanrein-krb5-kdh. A typed-hole in KRB-ERROR2, and the authz-data in AP-REQ, allow for ephemeral DH keys. We then only need to specify the relevant elements for carrying them. We'll also need to support acceptor key confirmation for the DH key in the case where the initiator's optimistic DH group/curve choice fails. The kDH flows might look like this: - 2-token flow (optimistic negotiation succeeds, no acceptor key confimation): C->S: AP-REQ with ad-kdh-groups, ad-kdh-pubkey (one or more even) (initiator is PROT_READY here) S->C: KRB-ERROR2 or extended AP-REP with ad-kdh-pubkey and key confirmation typed-data/authz-data - 3-token flow (optimistic negotiation succeeds, no acceptor key confimation, acceptor wants rcache avoidance): C->S: AP-REQ with ad-kdh-groups, ad-kdh-pubkey (one or more even) (initiator is PROT_READY here) S->C: KRB-ERROR2 or extended AP-REP with acceptor pubkey and key confirmation C->S: AP-REQ with challenge - 4-token flow (optimistic negotiation fails, acceptor key confirmation desired): C->S: AP-REQ with ad-kdh-groups, ad-kdh-pubkey (one or more even) S->C: KRB-ERROR2 or extended AP-REP with ad-kdh-pubkey C->S: AP-REQ with ad-kdh-pubkey (and with challenge if the acceptor wanted it) (initiator is PROT_READY here) S->C: AP-REP Obviously, it'd be nice if the KDC had some idea what groups/curves the acceptor supports, then we could more often avoid the 4-token flow. BTW, the TLS crowd is very keen on 0-RTT, which in GSS-speak means being prot_ready after producing the first context token^W^W handshake message. I'm not sure that prot_ready is a such terribly good idea because in many, many cases the very first app data either needs PFS/established authentication state, or else the layer right above TLS/whatever doesn't know if the app data needs that. But, there's a reason that 0-RTT is desired, and I think it'd be worth formalizing and modernizing the prot_ready concept. I also think it'd be a good idea to de-conflate (in GSS) acceptor key confirmation from authentication of the acceptor to the initiator. Nico -- From nobody Wed Nov 12 12:15:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35CC1AD042 for ; Wed, 12 Nov 2014 12:15:01 -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 TBWeHs_W3Q13 for ; Wed, 12 Nov 2014 12:15:01 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 006AA1AD272 for ; Wed, 12 Nov 2014 12:12:33 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id C1BDA2007F109; Wed, 12 Nov 2014 12:12: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=MdawJtBa1aP0ZK 0/wtUTNBJbiR4=; b=qA/jwEzTxxqB26j5KddJCpfd4OygUyISIohy4hzhdvNraT KVu7nhL8nyc4uj24GY8zrjkeuFQvqfgqYKlP4K1VbWGiB7VcoQptq5bCWpzJkuQ1 xPTBomG+8bNhUWgsTJ5Xi9xvEBJVJ73ZHR3DuroNXMP9B881rfH7pK5JR6Z+s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 77DE12007F10B; Wed, 12 Nov 2014 12:12:33 -0800 (PST) Date: Wed, 12 Nov 2014 14:12:33 -0600 From: Nico Williams To: Greg Hudson Message-ID: <20141112201231.GB3124@localhost> References: <20141027071704.GC14215@localhost> <54624E87.8010007@mit.edu> <20141111185423.GM3412@localhost> <54638C46.8060203@mit.edu> <20141112200552.GA3124@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141112200552.GA3124@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/xThw0XQzsDYPDYewfK71x2KOpO4 Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos extra round trips I-D revised 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, 12 Nov 2014 20:15:02 -0000 On Wed, Nov 12, 2014 at 02:05:54PM -0600, Nico Williams wrote: > The kDH flows might look like this: > > - 2-token flow (optimistic negotiation succeeds, no acceptor key > confimation): I should explain that in this case the acceptor does confirm the non-kDH symmetric sub-session key, but not the DH shared secret. I think that's a reasonable approach. > - 4-token flow (optimistic negotiation fails, acceptor key confirmation > desired): And here I screwed up, there's no need for a fourth token because the acceptor does confirm the non-kDH symmetric sub-session key, which is good enough. However, maybe we do need to confirm the DH shared secret? I hope not. Nico -- From nobody Wed Nov 12 19:14:21 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 EE1871A1AFF; Wed, 12 Nov 2014 19:14:17 -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 7wvQ7dVbkNBU; Wed, 12 Nov 2014 19:14:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7742F1A1B36; Wed, 12 Nov 2014 19:14:04 -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.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113031404.31360.74329.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 19:14:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/0VeW--XzNjaclRx30JMhYlKzHx8 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-cammac-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:14:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-kitten-cammac-00.txt Pages : 9 Date : 2014-11-12 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. This document updates RFC 4120. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-cammac-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 12 19:32: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 7BC2A1A1B37 for ; Wed, 12 Nov 2014 19:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 NzF3RF6ELOCm for ; Wed, 12 Nov 2014 19:32:53 -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 C01351A1AA1 for ; Wed, 12 Nov 2014 19:32:52 -0800 (PST) X-AuditID: 1209190c-f795e6d000006c66-c2-54642663d68a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 15.36.27750.36624645; Wed, 12 Nov 2014 22:32:51 -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 sAD3WpJx022220 for ; Wed, 12 Nov 2014 22:32:51 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAD3WnAu031312 for ; Wed, 12 Nov 2014 22:32:50 -0500 From: Tom Yu To: References: <20141113031404.31360.74329.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 22:32:48 -0500 In-Reply-To: <20141113031404.31360.74329.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 12 Nov 2014 19:14:04 -0800") Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixCmqrJuslhJicOKUusXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMadtNWPBRr6Km2snMjUwzuTuYuTkkBAwkXi36QYrhC0mceHe ejYQW0hgNpPEvLuxEPZxRokdt5y6GLmA7CYmiSP3jzCDJNgEpCWOX97FBGKLCIhKzN7yiqWL kYNDWMBCYu2SBIheR4klnz+zgNgsAqoSnata2UDmcApMYJRYO3k7WIJXQFdi5sKvjCA2jwCn xNw7t5kh4oISJ2c+AathFtCSuPHvJdMERv5ZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7M y0st0jXUy80s0UtNKd3ECA4xSZ4djG8OKh1iFOBgVOLhfcGSEiLEmlhWXJl7iFGSg0lJlPeI MlCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK8vSI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJ anZqakFqEUxWhoNDSYK3RwWoUbAoNT21Ii0zpwQhzcTBCTKcB2j4Z5Aa3uKCxNzizHSI/ClG RSlx3hsgCQGQREZpHlwvLAW8YhQHekWY9wJIFQ8wfcB1vwIazAQ0+Ft4EsjgkkSElFQD44r/ 4TNOt/F+iqiSjBX4435q4ss1sbm57pvP++9SSlM65NNQmcTTE8DQa5p4nef8C9P58pna65aq H0jYc6fj197nNtO3cYc9/3n67qaEqCiZY7M/bDt10y33/8He3tCg52FGGf1fdFSq1ad5n/16 Nfi81bYSxWNOfmd8pCetMFh2JOhM/oOiGUosxRmJhlrMRcWJAAJHrqrcAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GsS_ycsRnQ6-WJvOzyOho8AyV3w Subject: Re: [kitten] I-D Action: draft-ietf-kitten-cammac-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:32:54 -0000 This posting renames the draft to indicate its status in the KITTEN WG and also addresses minor ASN.1 issues raised by Greg Hudson. I believe there were no WG objections to the changes. writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. > > Title : Kerberos Authorization Data Container Authenticated by Multiple MACs > Authors : Simo Sorce > Tom Yu > Thomas Hardjono > Filename : draft-ietf-kitten-cammac-00.txt > Pages : 9 > Date : 2014-11-12 > > Abstract: > Abstract: This document specifies a Kerberos Authorization Data > container that supersedes AD-KDC-ISSUED. It allows for multiple > Message Authentication Codes (MACs) or signatures to authenticate the > contained Authorization Data elements. This document updates RFC > 4120. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-kitten-cammac-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Nov 13 17:58: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 EB16C1A017A for ; Thu, 13 Nov 2014 17:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 286YRFnbfIT7 for ; Thu, 13 Nov 2014 17:56:57 -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 524211A0146 for ; Thu, 13 Nov 2014 17:56:57 -0800 (PST) X-AuditID: 12074425-f79e46d000002583-c3-546561673886 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 81.FB.09603.76165645; Thu, 13 Nov 2014 20:56:55 -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 sAE1ut8w020632; Thu, 13 Nov 2014 20:56:55 -0500 Received: from dhcp-a66a.meeting.ietf.org (dhcp-a66a.meeting.ietf.org [31.133.166.106]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAE1uoVC008790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Nov 2014 20:56:54 -0500 From: Justin Richer Content-Type: multipart/signed; boundary="Apple-Mail=_D554F5F4-6916-44BE-A5B5-DD92B82E1FEF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Thu, 13 Nov 2014 15:56:49 -1000 Message-Id: To: kitten@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6nrpuemBpicPWVqcXRzatYLM7cWsHo wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGU0X8ou+ChacWNmF2MD40qhLkZODgkBE4lf e/8yQ9hiEhfurWfrYuTiEBKYzSSx9G0PE4SzkVFi/dUXjBDOGSaJ7pPv2UBa2ARUJaavaQGr YhaYxChxaPYGFpCEsIC8xIbJu8HmsgAVTes8wApi8wpYSRzs+wTWzAy079qr3WD1IgLCEru3 vmOGqDGQWLJrE9RN8hIfPhxnn8DINwvZjllI6maBzdKWWLbwNZRtIPG08xUrhC0vsf3tHKi4 pcTimTdYIGxbiVt9C5ggbDuJR9MWsS5g5FjFKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mi l5pSuokRHPQuqjsYJxxSOsQowMGoxMO7wjk1RIg1say4MvcQoyQHk5Ior3Y8UIgvKT+lMiOx OCO+qDQntfgQowrQrkcbVl9glGLJy89LVRLhPRQJVMebklhZlVqUD1MmzcGiJM676QdfiJBA emJJanZqakFqEUxWhoNDSYL3M8gCwaLU9NSKtMycEoQ0EwfnIUYJDh6g4TEJIMOLCxJzizPT IfKnGBWlxHnzQZoFQBIZpXlwvbBk9YpRHOgtYd4CkHYeYKKD634FNJgJaPC38CSQwSWJCCmp BsYjkrUP9u17yTTZlvnDbouFjE83qwY/fhqtXG38gunDsbnnQoyDO/OajYu3JhtdeRR+hYE/ f6fRvZ9JU5Se56Z/V1zvbJFbWbGhUZez+uLtRR9m3t11tCz4AsteZU72NH37Q267T2ns3mC6 I3t9sfJCxuhp73/rZB9cYDNPdxvzt+7PJur3d29XYinOSDTUYi4qTgQAkwX98jEDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CNw9oGY18qvBF9WrmDC5roms7JI X-Mailman-Approved-At: Thu, 13 Nov 2014 17:58:21 -0800 Cc: sakimura@gmail.com Subject: [kitten] Edit on OAuth-SASL -17 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, 14 Nov 2014 01:57:03 -0000 --Apple-Mail=_D554F5F4-6916-44BE-A5B5-DD92B82E1FEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 As brought up in the Kitten WG at IETF91, there=92s a small change that = should be made to the OAuth SASL draft in order to align it with OpenID = Connect. Specifically, section =933.2.2=94 refers to the =93issue=94 = element of OpenID Connect, which should actually be =93iss=94 (short for = issuer). The =93iss=94 is an absolute URL that uniquely identifies the = issuing server in an OpenID Connect context, and this URL is usable as = the root identifier for discovery of service information. More = importantly to this section, it can be used by clients to differentiate = which client identifier to use. We suggest the following text change: CURRENT: Since clients may interact with a number of application servers, such as email servers and XMPP servers, they need to have a way to determine whether dynamic client registration has been performed already and whether an already available refresh token can be re-used to obtain an access token for the desired resource server. This specification RECOMMENDs that a client uses the information in the 'issue' element to make this determination. NEW: Since clients may interact with a number of application servers, such as email servers and XMPP servers, they need to have a way to determine the appropriate set of tokens and credentials to use for each server, whether dynamic client registration has been performed already, and whether an already available refresh token can be = re-used to obtain an access token for the desired resource server. This specification RECOMMENDs that a client uses the information in the 'iss' element defined in OpenID Connect Core [OIDC] to make this=20 determination, where available. I would also suggest moving the JSON reference from RFC4627 to RFC7159. =97 Justin --Apple-Mail=_D554F5F4-6916-44BE-A5B5-DD92B82E1FEF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUZWFiAAoJEDPAngkbd+w9e8QIAIYRN3UuKgeNlvrc4EYr2TnZ khxplZuBn29e1Hf0jZl37iQtT8pjJVR8/SXwweOU6J07/1ZG8TBX1twKztknXQEh D/Wl3IhD0cccZDp45sr8mb4B5IEzELQsXdVUnEe5TGTvzIbQfe6/Uula6syecEHh IHJxbhro+RJQWCZvzrXWN+QWqWf07L8B2Ke4p1ep9de2dkXwDRYIKeqFlc1rN3J0 23/rAWHAXMJEiCwqvn4kh/K0ccY3nhvVxxUXR7byBEA+1eokcy5tMMVj6UqdWWJI WrEMqQf7zVvGP3v31W8pTTKG6+LieuGXRG3bAohATrIL4gW5i8v6qEik0XL3gb0= =nCho -----END PGP SIGNATURE----- --Apple-Mail=_D554F5F4-6916-44BE-A5B5-DD92B82E1FEF-- From nobody Thu Nov 13 20:25: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 74A291A1BF0 for ; Thu, 13 Nov 2014 20:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 ekXbe0Qm7Uef for ; Thu, 13 Nov 2014 20:25:21 -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 9B1431A005E for ; Thu, 13 Nov 2014 20:25:21 -0800 (PST) X-AuditID: 12074425-f79e46d000002583-34-5465843076f8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BF.91.09603.03485645; Thu, 13 Nov 2014 23:25:20 -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 sAE4PJHN031856; Thu, 13 Nov 2014 23:25:20 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAE4PI8j023351; Thu, 13 Nov 2014 23:25:19 -0500 From: Tom Yu To: Michiko Short References: Date: Thu, 13 Nov 2014 23:25:18 -0500 In-Reply-To: (Michiko Short's message of "Mon, 27 Oct 2014 20:56:16 +0000") Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrGvQkhpi8LtBxuLo5lUsFv+6+RyY PJYs+cnk0brjL3sAUxSXTUpqTmZZapG+XQJXxtqmGYwFE5kr7jWtYm9gPMPUxcjBISFgIjF/ kXYXIyeQKSZx4d56ti5GLg4hgdlMEttezGOGcDYySvx8fIoVwnnDKHFq1UdGkBY2AWmJ45d3 MYHYIgJaEh8unGYBsZkFNCQWLn7LCmILC3hLvH+6A6xeSCBUYtGbZjCbRUBV4ljbM2YQm1Ng OqPEv71BIBfxCuhKXPrADhLmEeCQ2HvnBNgYXgFBiZMzn0CN15K48e8l0wRGgVlIUrOQpBYw Mq1ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQICkZ2F9UdjBMOKR1iFOBgVOLh XeGcGiLEmlhWXJl7iFGSg0lJlDeuGijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhDesASjHm5JY WZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBy9AM1ChYlJqeWpGWmVOCkGbi 4AQZzgM0PBmkhre4IDG3ODMdIn+KUZejpeltL5MQS15+XqqUOO+8JqAiAZCijNI8uDmwJPKK URzoLWFeV5BRPMAEBDfpFdASJqAl38KTQJaUJCKkpBoYo97mb05+E1KhMeki11Z5K7Zjy6Pn vrrLdEFmMd+vNft/vz7zTo95VfCxY0+9L3CGv55Xk3B6jb0U59TON/G/11+1ZJRz/b3v/kRD /old9Sa5nD5yxtM9LX0ktPfbLOXKmNnQp6STZ6ZtqlkUsfmBROvH4/3P/zUYNE6dbT//1/WL X52mH/IoVWIpzkg01GIuKk4EAOG5xXT9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-MFKO1sGlz6hWRzCr0U3PedTG8Y Cc: "kitten@ietf.org" Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 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, 14 Nov 2014 04:25:23 -0000 I would like the authors to look at the original email thread in krb-wg and acknowledge the key contributors who discovered this. I mentioned this in the WG session today, but I was mistaken about the date. Apparently the original protocol flaw was discussed in 2011, not 2005. I think the correct archive link is: http://www.ietf.org/mail-archive/web/krb-wg/current/msg02781.html Thanks. From nobody Thu Nov 13 21:23: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 A73361A6F99 for ; Thu, 13 Nov 2014 21:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[BAYES_20=-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, RP_MATCHES_RCVD=-0.594, 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 8C4Q5gO_szvG for ; Thu, 13 Nov 2014 21:23:41 -0800 (PST) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479A91A6F67 for ; Thu, 13 Nov 2014 21:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1415942620; bh=b/0K+YMRyujZZV9/QBD5E57qCtdMoDGimOldeInxehM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=bMKwlWfJWKTU24MV8wxnDTI7at9Mdi7h5t6HGqqgi9GmML5EKcgM+dthJUHatUsd5w8+rCKtnWLizQvw3mznBNeKfAFn8HWKG4i9JjjDJpHNRS8/9SrKiAkTfv2LT0CdspUYcvJBhmk/FYTDWXIaMQEzJPVHj5ARrvAyc6v+JWvD55Crq5AvP+W8Xn8FA7tXM1TVOL0Yeh9qbm7TAFZHGeNApYQ5PWxhwa9yHoRlg+kJfvSymwDyzuLwTl7oaeqvaOap2BiiYlb91Q1YIVego6z7CTSV2EnNh/0lr9AEj95n8blcDDwcU/gk8zd9vXlkeH31ZmC6TWRJjTFDRAv4tw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=RLL3k3kNCcdkh67iRFOfAIHkihzN3W8SVO9Kyy9physfo72yMOv8FEzFrV4BwN7X9XG1TbslyTLbTqxdLQEeENYc+S5tnRlYn0kb0MFjIQUSsTroVSqHob4FINXdeEt9GFQir6N9Dc4oyuyKAT6VpDYAlxafNIcAE55J+uNKKUn6juDjn/OPd+ATJpxnjnL20iMLDhGzPT1O+TGZL3HdDv9TrQaRUdelLfqpfhNCgyCBostyz4olwm6ljLns0tmI1FKx8KgX3rZeKTRGdWXln3FvebAM0E/ddDn3EbSarwa/eH5IrKbplfHzKogdTXTY2dPEA5Ec0Xy60RlKhL7IHw==; Received: from [98.139.212.151] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 05:23:40 -0000 Received: from [98.139.215.249] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 05:23:40 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 05:23:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 425882.24759.bm@omp1062.mail.bf1.yahoo.com X-YMail-OSG: XV.v1_IVM1kWWpnLcM01Leyn4UgkEXLnYKISgvb5frHGhpKr3GjrBZC8fHo3xm4 O7bNYM1M_4SjW_2nE2.sD34OvRRlo0Ta.Vcoy2TtcRn4gmLThc1dgqeVsy8yN9iFV.u35vmJGukO Fb6ZcD.3qCtXKOqJtKuLfkcUd5B9C1yDhJxvBJJmcW6vqP7cFMnm8mDOFmKk5QZ7rdT7h_oWtpMM T7MUjQk8CxfkKYpnPaZ2ovbAJEzjL0MaPMhmAeXRVyak55VXzvuHmdjBXBA4TzGcVxA14F1C9b43 x63VUsiod17zYr8Z2NWLJJZTMhW._anM1hGB8uQpgb8WP9YoG8UJ7d1qRX0ujwA7rfo7YSyoZUE5 ZkoPzI8ia.mpOigoOpCND6Oiz7BsVdxnAsqaV0NeOJCj45dmIkQY7YtNqdf9wtBrP1ae29dCVgRC sWdgMqn4WJDoUx_BB2he28sc7zDn.pHdlrTx5SApmUe2a3AbBxVK5RywiG.OQXqTMOOqCengC Received: by 76.13.26.136; Fri, 14 Nov 2014 05:23:40 +0000 Date: Fri, 14 Nov 2014 05:23:39 +0000 (UTC) From: Bill Mills To: Justin Richer , "kitten@ietf.org" Message-ID: <603924966.511309.1415942619688.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_511308_823326150.1415942619684" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZN35xzClUWJczFD2WZDCygeu59w Cc: "sakimura@gmail.com" Subject: Re: [kitten] Edit on OAuth-SASL -17 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: Fri, 14 Nov 2014 05:23:47 -0000 ------=_Part_511308_823326150.1415942619684 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fixed it mostly. =C2=A0Discovery doesn't tell you what credential types are= needed though, which perhaps it needs to... =C2=A0but the assumption is th= at the AS will issue the right tokens for the RS. =C2=A0I left that bit out= .=20 On Thursday, November 13, 2014 5:58 PM, Justin Richer wrote: =20 As brought up in the Kitten WG at IETF91, there=E2=80=99s a small change t= hat should be made to the OAuth SASL draft in order to align it with OpenID= Connect. Specifically, section =E2=80=9C3.2.2=E2=80=9D refers to the =E2= =80=9Cissue=E2=80=9D element of OpenID Connect, which should actually be = =E2=80=9Ciss=E2=80=9D (short for issuer). The =E2=80=9Ciss=E2=80=9D is an a= bsolute URL that uniquely identifies the issuing server in an OpenID Connec= t context, and this URL is usable as the root identifier for discovery of s= ervice information. More importantly to this section, it can be used by cli= ents to differentiate which client identifier to use. We suggest the follow= ing text change: CURRENT: =C2=A0 Since clients may interact with a number of application servers, suc= h =C2=A0 as email servers and XMPP servers, they need to have a way to =C2=A0 determine whether dynamic client registration has been performed =C2=A0 already and whether an already available refresh token can be re-use= d =C2=A0 to obtain an access token for the desired resource server.=C2=A0 Thi= s =C2=A0 specification RECOMMENDs that a client uses the information in the =C2=A0 'issue' element to make this determination. NEW: =C2=A0 Since clients may interact with a number of application servers, suc= h =C2=A0 as email servers and XMPP servers, they need to have a way to =C2=A0 determine the appropriate set of tokens and credentials to use for =C2=A0 each server, whether dynamic client registration has been performed =C2=A0 already, and whether an already available refresh token can be re-us= ed =C2=A0 to obtain an access token for the desired resource server.=C2=A0 Thi= s =C2=A0 specification RECOMMENDs that a client uses the information in the =C2=A0 'iss' element defined in OpenID Connect Core [OIDC] to make this=20 =C2=A0 determination, where available. I would also suggest moving the JSON reference from RFC4627 to RFC7159. =E2=80=94 Justin _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_511308_823326150.1415942619684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fixed it mostly.  Discov= ery doesn't tell you what credential types are needed though, which perhaps= it needs to...  but the assumption is that the AS will issue the righ= t tokens for the RS.  I left that bit out.


On Thursday, November 13, 2014 5:58 PM, Justin Richer <jricher@mit.e= du> wrote:


A= s brought up in the Kitten WG at IETF91, there=E2=80=99s a small change tha= t should be made to the OAuth SASL draft in order to align it with OpenID C= onnect. Specifically, section =E2=80=9C3.2.2=E2=80=9D refers to the =E2=80= =9Cissue=E2=80=9D element of OpenID Connect, which should actually be =E2= =80=9Ciss=E2=80=9D (short for issuer). The =E2=80=9Ciss=E2=80=9D is an abso= lute URL that uniquely identifies the issuing server in an OpenID Connect c= ontext, and this URL is usable as the root identifier for discovery of serv= ice information. More importantly to this section, it can be used by client= s to differentiate which client identifier to use. We suggest the following= text change:

CURRENT:

  Since clients may interact wit= h a number of application servers, such
  as email servers and XMP= P servers, they need to have a way to
  determine whether dynamic = client registration has been performed
  already and whether an al= ready available refresh token can be re-used
  to obtain an access= token for the desired resource server.  This
  specification= RECOMMENDs that a client uses the information in the
  'issue' el= ement to make this determination.


NEW:


  Since = clients may interact with a number of application servers, such
  = as email servers and XMPP servers, they need to have a way to
  de= termine the appropriate set of tokens and credentials to use for
  = each server, whether dynamic client registration has been performed
&nb= sp; already, and whether an already available refresh token can be re-used=
  to obtain an access token for the desired resource server. = ; This
  specification RECOMMENDs that a client uses the informati= on in the
  'iss' element defined in OpenID Connect Core [OIDC] to= make this
  determination, where available.

I would also = suggest moving the JSON reference from RFC4627 to RFC7159.

=E2=80= =94 Justin
_______________________________________________
Kitten mai= ling list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten=


------=_Part_511308_823326150.1415942619684-- From nobody Fri Nov 14 07:33:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67D41A00E1 for ; Fri, 14 Nov 2014 07:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=unavailable 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 IHqnuBB7jZSX for ; Fri, 14 Nov 2014 07:33:06 -0800 (PST) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCCF1A0092 for ; Fri, 14 Nov 2014 07:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1415979185; bh=7jjU1E17Gsr7Vql1os70GmSQQ5HykKbo9/QQoCjyYJ8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=e5gP8tXnK/Wp/jMMa22SzQJoaVfCDPUogLT4wez8Rgj3yTf8O6ukOjLr8ZxJ0ean9hN4vIo/JuFadxs75Gd8Dz/nnQuziZmxigVxIQNTKuwu2JAVJq1dQAQZg0htyMoYtTjvNpwrG/nkcw/rO85D6M1dwhCSxcT1ml9C9zot7Pfr9xBTp4ht2XzRO4LtIqMdN1lP0ap8iVHP4m6vGiYWeGdZpA1AAFromMUQVlhXfVAE1ku2Fo+sEB2kf6AcEiJLRMg3o2ltG/HVdtXgocgRYzvsuGlMkxv+KcqmDnwhgriNHIRCtFW9InxdUPbc6JE+fXPtGodOBXuug78LzJFeqA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=e/jUbQZLlldIL//uRVAfzguok8vUC17MrdwrBJkXbaogr58fpTdN2sSWKAfq7zB5Sy74HqFH3zWkYq3CXCA+qh+OLYb7Wt+IT5ZQ9qA5DbxpPvkmZ2DY2VCqrOg8B6wVeEyKOTYCufBqu2q6vjiKH069vHLIQr10bbXTkn0jnQSQpB1/GkZO7DIDpvxs/5FdYqYI/n2P3Akztd/Ko2Ga4PXgVlmSN+rr86UQ1I6qV7geWwBP0ZEP8BKPaq7D8AooTc+6VxaRo7sBZoJUGNsPstipWZjf78QX7psqoyQ8599WTnC+lG36O8YxKHKifubpA9Kxn85eirVSMgYKGdeKqQ==; Received: from [66.196.81.174] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 15:33:05 -0000 Received: from [98.139.215.249] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 15:33:05 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 14 Nov 2014 15:33:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 216291.57805.bm@omp1062.mail.bf1.yahoo.com X-YMail-OSG: HDUils4VM1lrIo4CAOTXLuOY0dfwa5N3bbC7hPBV7Uvk0y0NkN1TKBEmboYEcUU BMhd1HqTYAIJ4yzHT15ON6mBF2FtLR_5VaaNVlxIJPM1vrXxfdsIZRz2iMtMGB2hmLJf3C1eFdER Zut9wLGo1qV4PvKwIoBmv8ngENefBrHTD72JZL.7npoQ8oT.WORpsrsJz.w4u9GVGDTVTmkAlQyR GZ4FF53tL1V2Iz1868_MTd9qQ8Axj94ayNJ0OGWwPp7rbiGcY4xu1UoTOVg74n7ig_A.Vmh1hV8o HwcaU_KfgxjLSQRbOPuWByD6QYAFBrbBdrrfP9ORXS.8LZhuC7MdFqfurAGW9M3Q2Xr2VGcK4_GT TMGO9Y.E5N97RJk6VTb9mnOM9qrV84k8DnhH10mdZb61LQmRt3jwsEV6HNs.NxmQF8fj4BpPGe7_ tFBtkNO16.9BKffN3hV_OSmV1aK75YZekf5EOA5qdZiB6Kg28dKfvdBWQlA6VFGSL2FmS0L23 Received: by 76.13.26.138; Fri, 14 Nov 2014 15:33:04 +0000 Date: Fri, 14 Nov 2014 15:33:04 +0000 (UTC) From: Bill Mills To: Brian Campbell Message-ID: <483734199.660612.1415979184254.JavaMail.yahoo@jws10661.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_660611_1130609993.1415979184174" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/phTqdNw4gINcXCiBVMkEiuqr9_A Cc: Kitten WG , OAuth WG Subject: Re: [kitten] [OAUTH-WG] crosspost.... SASL OAUTH X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 15:33:07 -0000 ------=_Part_660611_1130609993.1415979184174 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yep, fair enough. =C2=A0Done.=20 On Friday, November 14, 2014 6:33 AM, Brian Campbell wrote: =20 Given the state of things, maybe the MAC Token specification [I-D.ietf-oau= th-v2-http-mac] reference should be changed or omitted? On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills wrote: There's a draft it would be great to get more eyes on in the Kitten WG draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth Nearing it's 5th and hopefully final WGLC, so any more eyes and comments on= it would be welcome. Thanks, -bill _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_660611_1130609993.1415979184174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yep, fair enough.  Done.


On Friday,= November 14, 2014 6:33 AM, Brian Campbell <bcampbell@pingidentity.com&g= t; wrote:


Given the state of things, maybe= the MAC Token specification [I-D.ietf-oauth-v2-http-mac] reference should = be changed or omitted?

On T= hu, Nov 13, 2014 at 7:01 PM, Bill Mills <wmills_92105@yahoo.com>= ; wrote:
=
There's a draft it would be great to get more eyes o= n in the Kitten WG


Nearing it's 5th and hopefull= y final WGLC, so any more eyes and comments on it would be welcome.

Thanks,

-bill

_______________________________________________<= br clear=3D"none"> OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


=

------=_Part_660611_1130609993.1415979184174-- From nobody Fri Nov 14 14:59: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 2AB651AD33F for ; Fri, 14 Nov 2014 14:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N90W_392aWTK for ; Fri, 14 Nov 2014 14:59:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A91F1AD1D5 for ; Fri, 14 Nov 2014 14:59:21 -0800 (PST) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 14 Nov 2014 22:59:20 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.53]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.53]) with mapi id 15.01.0016.006; Fri, 14 Nov 2014 22:59:19 +0000 From: Michiko Short To: Tom Yu Thread-Topic: [kitten] Comments requested on draft-short-pkinit-freshness-00 Thread-Index: AQHP/8MBM/SuVKt/VU6ICfILW6DKhZxgu98w Date: Fri, 14 Nov 2014 22:59:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB212; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB212; x-forefront-prvs: 03950F25EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(13464003)(51914003)(199003)(20776003)(64706001)(99286002)(101416001)(97736003)(86612001)(21056001)(92566001)(86362001)(230783001)(40100003)(107046002)(120916001)(99396003)(62966003)(77096003)(77156002)(105586002)(122556002)(108616004)(76576001)(95666004)(33646002)(106116001)(110136001)(106356001)(19580405001)(19580395003)(54356999)(76176999)(15202345003)(50986999)(2656002)(87936001)(15975445006)(31966008)(4396001)(46102003)(74316001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB212; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/hIX8FI_hn_0oegnnJMX_mt8eyro Cc: "kitten@ietf.org" Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 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, 14 Nov 2014 22:59:23 -0000 Thanks for the link. I was going to follow up with whether you meant everyo= ne on the thread or just the original discoverer, Nikos Mavrogiannopoulos. = I don't want to leave anyone out, so the complete discussion group included= Henry B. Hotz, Nico Williams, Sam Hartman, Tom Yu, Martin Rex, and Dougl= as E. Engert. I planned to just credit everyone, but since the thread was s= tarted I'll ask. Credit everyone, right? -----Original Message----- From: Tom Yu [mailto:tlyu@mit.edu]=20 Sent: Thursday, November 13, 2014 8:25 PM To: Michiko Short Cc: kitten@ietf.org Subject: Re: [kitten] Comments requested on draft-short-pkinit-freshness-00 I would like the authors to look at the original email thread in krb-wg and= acknowledge the key contributors who discovered this. I mentioned this in= the WG session today, but I was mistaken about the date. Apparently the original protocol flaw was discussed in 2011, not 2005. I think the correct archive link is: http://www.ietf.org/mail-archive/web/krb-wg/current/msg02781.html Thanks. From nobody Mon Nov 17 14:20: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 690B21ACDAC for ; Mon, 17 Nov 2014 14:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, 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 k9KmvSrhwo8i for ; Mon, 17 Nov 2014 14:20:21 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA39F1ACDAB for ; Mon, 17 Nov 2014 14:20:20 -0800 (PST) Received: from [10.0.1.225] ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id GmLJ1p00410HQrX01mLKHV; Mon, 17 Nov 2014 23:20:19 +0100 From: Rick van Rein Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Nov 2014 23:20:18 +0100 To: kitten@ietf.org Message-Id: <5C562C9B-4421-4CB1-9F5D-E354AE2C0104@openfortress.nl> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/B3Gn7GQjjS9UcyXuuXyXNgDpdEg Subject: [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: Mon, 17 Nov 2014 22:20:24 -0000 Hello, Thanks all for your feedback on the DNS TXT proposal for Kerberos realm = names. I=E2=80=99ve 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 = well as to give structure. Entry in master zone files would be as base64, which is clearly = non-optimal, but parsing text isn=E2=80=99t either. I don=E2=80=99t know what=E2=80=99s best here, I suppose it=E2=80=99s a = matter of taste. As before, feedback is welcome :) and I will also forward it to DNS = lists this time. Cheers, -Rick From nobody Mon Nov 17 14:24:21 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 6BD571ACDC8 for ; Mon, 17 Nov 2014 14:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.507 X-Spam-Level: *** X-Spam-Status: No, score=3.507 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 AR4gnjzVKFOh for ; Mon, 17 Nov 2014 14:24:06 -0800 (PST) Received: from nm38-vm0.bullet.mail.bf1.yahoo.com (nm38-vm0.bullet.mail.bf1.yahoo.com [72.30.239.16]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492611ACDBE for ; Mon, 17 Nov 2014 14:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416263045; bh=ExCtfEZ6EQwj8BESeXJQSZxe7p46J7RCrH25rwyAMVc=; h=Date:From:Reply-To:To:Subject:From:Subject; b=LG6jGsBZGTBTiVftMBFkNzVj2FBQOrt9v439NmG3pRAvAgBXCL113zLQRBEsxGN7dH/FcoaQSNMm7rOC5ILj173qAxeHLbX+2ri3og4yLz82/5WlOWzMdOXXidSVwnsTM0ni1bJLKgiKzXKWWI7RRoduXWv9D91Ft7TPmtH/bBeA+sEDeVIbFkMHE6l9Bti0eAP+opUPa+N8zi/lWH7YEpUtz79yWjGC6VhoqwT5Lqa7FxDjasFbEDcAS8rp77kKTiKTd6SSk0S9VHvjLWV6qwQvhS1DtDh5xWU+MJZevirqsNsnVrfc0NifDeRWKjjIY7Ug3BR5s5Yf9aWyBoV4+Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=kZ5SHw2pAR+bQ0yQrDJwmaS++HsOvybLZi21OcxOATZZPVRMuz3OzC9gadj1DylALs/oM8w6DU4dHCIpF5tP8nxvrHpX6wa3n5J/cGz4MilE9R7JArCpodNqCbeOdWTaWctljBpdk5l0IDuObtr1qCNBqlb0UxrMUFCP0l8+4cMiX+RvaF5vgtRMb6iBsiM8gE8B0NmA/ieddnBSHPyHksloRvgE496RonKb6R4kySQWZJSL6uvYJuS89mIypMcszVbjTlclJnL3NwTTfuna8/bLMxOJ9qG6KLzfiaK3jCt/RP7XdMyZ8s4DHtORF1KSm/fSGRJ2nGbMh+YeqWwB1g==; Received: from [66.196.81.174] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 17 Nov 2014 22:24:05 -0000 Received: from [98.139.215.251] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Nov 2014 22:24:05 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 17 Nov 2014 22:24:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 436554.20352.bm@omp1064.mail.bf1.yahoo.com X-YMail-OSG: OO6BHxsVM1laTFbU15ox1PIb9yoP_7bXNkiw9iYChsWw6KkPwmpVNEVmfFq.1Mp HVcJnPBPrcwP9UTl7WgTqi9.Zz9LfNCjZGRHU_6OWtmBYqHfl28bj3k.Vn4XuFvBGfS2MTKsZUBl i3VNQAGLR8lm6z71vevR_dYwZIGKAMpBzW74zx595sqDT4oKBq4OAXkJq.LAvLJFX3R.nL4tMc4. iUMpZrLmIs9.tGO10K_UG4Hasr3hhZ.zwuZBx.BQw0YKJPIcJ4QmLh.Z12l9AA1FKazQxhD1eW5Z zlcdYTZYw2lyGbUsViuLXPIKPqkU63WM9poRpuY0CwqosQK7LCPD6Gg1ZysQBxRSUO2fpSUY8WlN lwRoUwwDplCOl4MONxsQ628u72EhrWcloQZavG3ONhU.SXW.8BBVyJqnS.Py19ige.5sg5DESl4C HdGbybNNLFA8gHfedPFKfu5_pylB4DQmdzIHJLED1FeCAEMkxnJDXpi4pfj0vUsMNOKySlWdlLoL cCMY- Received: by 66.196.81.118; Mon, 17 Nov 2014 22:24:05 +0000 Date: Mon, 17 Nov 2014 22:24:04 +0000 (UTC) From: Bill Mills To: Kitten WG Message-ID: <390780225.1706883.1416263044697.JavaMail.yahoo@jws106115.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1706882_708151275.1416263044695" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/g1nBkkzcvtcogSj63enttkUmCXg Subject: [kitten] now that I've volunteered.... 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, 17 Nov 2014 22:24:08 -0000 ------=_Part_1706882_708151275.1416263044695 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can someone please point me at the info for the draft I'm going to do a few= edits on? =C2=A0 Thanks, -bill ------=_Part_1706882_708151275.1416263044695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Can someone please point me at the info for the draft I'm going to do a few edits on?  

Thanks,

-bill
------=_Part_1706882_708151275.1416263044695-- From nobody Mon Nov 17 14: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 37CD51ACDCE for ; Mon, 17 Nov 2014 14:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 rv5cpFWQiShH for ; Mon, 17 Nov 2014 14:36:56 -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 D78931ACDC8 for ; Mon, 17 Nov 2014 14:36:54 -0800 (PST) X-AuditID: 12074422-f796d6d000003f66-96-546a78854264 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 59.E0.16230.5887A645; Mon, 17 Nov 2014 17:36:53 -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 sAHMar4R031947; Mon, 17 Nov 2014 17:36: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 sAHMapZf028166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Nov 2014 17:36:52 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAHMaokf010958; Mon, 17 Nov 2014 17:36:50 -0500 (EST) Date: Mon, 17 Nov 2014 17:36:50 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <390780225.1706883.1416263044697.JavaMail.yahoo@jws106115.mail.bf1.yahoo.com> Message-ID: References: <390780225.1706883.1416263044697.JavaMail.yahoo@jws106115.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-346069478-1416263810=:19231" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixG6nottakRVi8GWRocXRzatYLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDI29E5hK9jBWrHsyWSWBsYzLF2MnBwSAiYS pyYeY4SwxSQu3FvP1sXIxSEkMJtJovPqAWYIZyOjxJX3N5kgnENMEi9nnWQGaRESaGCUuHov BcRmEdCWeDL3ONgoNgEViZlvNgKN4uAQEVCXaP7uDRJmFpCXeLammw3EFhYwllj4ZgnYGE6B KIk5k3aB2bwCjhIn365hgRgfKbHs3FUwW1RAR2L1/iksEDWCEidnPmGBmBkg0bT8LfMERsFZ SFKzkKQgbHWJA58uMkLY2hL3b7axLWBkWcUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKX mlK6iREc2C5KOxh/HlQ6xCjAwajEw7sjOzNEiDWxrLgy9xCjJAeTkijvuZysECG+pPyUyozE 4oz4otKc1OJDjBIczEoivFomQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZ GQ4OJQneR2VAjYJFqempFWmZOSUIaSYOTpDhPEDDP4DU8BYXJOYWZ6ZD5E8x6nK0NL3tZRJi ycvPS5US5+UpByoSACnKKM2DmwNLSK8YxYHeEuYVAqniASYzuEmvgJYwAS2ZsyETZElJIkJK qoFxaceL75GfNz57I2uxMV1jReDWiZOmf/hpPc12s8XMJCZ+cclfW1Ifbrybo7xMyDNeN7vY 79arl0ZKrB7Xlxxv4G7eJTDdbMKCHdZvE/itObPs5SZKLNzsI/Eyaf7cpMBbPrWMQhFqS3gu H5wRF3btx8uJLtt8dAwnKATv+PB9tne9R3vjy0QOJZbijERDLeai4kQA2pjiLCMDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qlwcfnbV0dpqy18BajH6O4CuJvQ Cc: Kitten WG Subject: Re: [kitten] now that I've volunteered.... 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, 17 Nov 2014 22:36:58 -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-346069478-1416263810=:19231 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 17 Nov 2014, Bill Mills wrote: > Can someone please point me at the info for the draft I'm going to do a > few edits on? =C2=A0 I believe that would be this one: https://tools.ietf.org/html/draft-ietf-krb-wg-pkinit-alg-agility-07 As for the few edits, those should be here: http://www.ietf.org/mail-archive/web/kitten/current/msg03820.html -Ben ---559023410-346069478-1416263810=:19231-- From nobody Mon Nov 17 15:21: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 80B2E1ACE72 for ; Mon, 17 Nov 2014 15:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 2CgsHg_Ye2SA for ; Mon, 17 Nov 2014 15:20:55 -0800 (PST) Received: from nm43-vm4.bullet.mail.bf1.yahoo.com (nm43-vm4.bullet.mail.bf1.yahoo.com [216.109.114.223]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2381ACE7D for ; Mon, 17 Nov 2014 15:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416266454; bh=SDHee2Yk+spXDwVeh8Bkj0uhSZR90KDFbyEU/UikXgg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=C1QFftWsroi9+3mjHRhJ2m5QpI7rXgJysHfmKiTfzSYfPpaj8Ap0MuF/S8e9BDlHggddUlZfsgY13+5CPqYu672XIVl848QiSwUcfmF25KnRvz0Jlen+NYr3JoxG2lWXke1ugOgmTj9IHQoucKuCUY2yZCsuptDWZd/O9HD4xBPj/FQH6cP4cNF08dz4mY3aAsrbuf3r6j90dyUqnY/4SI+MhSWJfDYb3cR+vCMtxXz4w/cJmi/CNw9JqX/lqGbc+9u7Z+9KiIz8FOz6oIpwdiGVepMb4oQt8OMWkkQmBctGFruqXS8Tjcz++nCuAA9vBzzC0qJCVWetb0gyyXSMOA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=Lua4PY7d0n7Cy4WhZnbFgpjgl6L8yXlAyxPlu/o1ilranysWzACfOoHooU6mct8ohISACejM8VsohrhFo90JzVcaejxj/nCQ76mWrS6rWfMTgUh0dl0hpO1hFxwe0ZvPrJ7s1KA64cs+Y6jKcpRGRpKXLgGoZxzcDbr4ww0O9mqzMq+0liwKM1J9x91V+SLOJea9o58kvpoUl98axnUqd5c5tDgDQx83rB3AvQ05YGfZXzaVBIuoQbMKGcfVYkGeFAAjXR770EwWM2MgNVU9/FSMuXB7p1eoroO3ZMktipPsh2JooPQnGQFnZnkVqqFuyy8hyVgCKTvO1YcYkhmZgg==; Received: from [66.196.81.174] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 17 Nov 2014 23:20:54 -0000 Received: from [98.139.212.229] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Nov 2014 23:20:54 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 17 Nov 2014 23:20:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 715941.94634.bm@omp1038.mail.bf1.yahoo.com X-YMail-OSG: BW4WUp0VM1nyDmXDAceDPuJkxG2Oy94wxY7UERE3q1A47N4p91PrwoCzhp6hUn1 2dQ4oUV9pe6Qfq315CNYPJt7yloQO4WzeQ03f4bH.Rc7PkXyvEKJckZ85Y7.ECVnipYUPER2DMjv KlcTFqGQH5FcJzln3GoMsFKsT5_TLe9N893vOujB7nWCTNxFClnFAKaEPGwbKr2DcMSLNjDTf_Yo aIFFnAJYpm_M1S.vGbd0HFl9GPaHhC7gb9r3.EYX3n9vxDuRT5oZA2bcG_5apMzt9LD3en7bjLvN ThaVQQhJ5WcLQ91Nci4GNq8Cx7vhoL9LkUYJAdfeVEnrrplpMCrHmFEM1hPgjXY10jPrQB93ooDt t.Rxnt4EWeq3myKITF9WP9_R_NBDaNbVHrRzX9VTQmDCtUx3auzi9cVdLJSoIrvRobcnA_J7nkCi m2lqXmbo4ruu1KUCUgkVTRBhb_fscNV1H6N_bbDlW5Ogt2EUyIh99g78CmDzsfF__BhiRwsxXv.6 fchbpgP3.OgbQdrRNgsX6wYdieb8MAkYa5vTuZRn8geoN5s39IwCWlQ73mykioFmqn_CE7TeoxxR _h3CN6J90x3vD5M8fEf2eCpZSd74m1B2dh4fg Received: by 66.196.80.118; Mon, 17 Nov 2014 23:20:54 +0000 Date: Mon, 17 Nov 2014 23:20:52 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JQ23V0cpvZ-pjvXLOAgBD6sH2dQ Cc: Kitten WG Subject: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 17 Nov 2014 23:20:58 -0000 There are outstanding questions here, I have a copy with local edits now. The issues are: 0) conforming to the new stricter DTD parsing -- done 1) "a preference to reassign the error code" I need specifics here on what needs to happen. 2) move 2 references to informative -- done 3) Include informative reference to MD4 spec, seems optional from that message. Include it? I agree that rfc6150 seems sufficient since it's noting the retirement of MD4, and the reader can find the MD4 spec through that route. 4) "OID id-pkinit-kdc has been assigned, but not defined in the module": What needs to be done here? I need suggested text. -bill P.S. as editor I'm happy to scribe for the WG but this is outside my expertise to get this language right. On Monday, November 17, 2014 2:36 PM, Benjamin Kaduk wrote: On Mon, 17 Nov 2014, Bill Mills wrote: > Can someone please point me at the info for the draft I'm going to do a > few edits on? I believe that would be this one: https://tools.ietf.org/html/draft-ietf-krb-wg-pkinit-alg-agility-07 As for the few edits, those should be here: http://www.ietf.org/mail-archive/web/kitten/current/msg03820.html -Ben From nobody Mon Nov 17 21:33: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 E7C191AC447 for ; Mon, 17 Nov 2014 21:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 Ifg4w7lta5IN for ; Mon, 17 Nov 2014 21:33:37 -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 711CD1A00D0 for ; Mon, 17 Nov 2014 21:33:36 -0800 (PST) X-AuditID: 1209190d-f79576d00000413b-83-546ada2fa97a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E8.0F.16699.F2ADA645; Tue, 18 Nov 2014 00:33:35 -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 sAI5XT9u006597; Tue, 18 Nov 2014 00:33:29 -0500 Received: from [18.101.8.146] (vpn-18-101-8-146.mit.edu [18.101.8.146]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAI5XP1D023486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2014 00:33:28 -0500 Message-ID: <546ADA25.3000906@mit.edu> Date: Tue, 18 Nov 2014 00:33:25 -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: Bill Mills , Benjamin Kaduk References: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> In-Reply-To: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1tW/lRViMPOihMXRzatYLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDL+74gvWMlUMW+BQgPjK8YuRk4OCQETie2r nzFD2GISF+6tZ+ti5OIQEpjNJPF31lp2CGcjo8SUIyeZIZwjTBKzPzWxgrTwCqhJ3P77ggXE ZhFQldjXMIENxGYTUJZYv38rUJyDQ1QgTGLqUh6IckGJkzOfgJWLCLhLtL9dDDaGWUBeYsG3 RWC2sECixJsH3VCL+xglPvyZzA6S4BSIlGg4M40JokFPYsf1X3DN29/OYZ7AKDgLyY5ZSMpm ISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIzh8JXl3ML47qHSIUYCD UYmHN2FqVogQa2JZcWXuIUZJDiYlUd7aC0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrznuoFy vCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvOduADUKFqWmp1akZeaU IKSZODhBhvMADb8EUsNbXJCYW5yZDpE/xajL0dL0tpdJiCUvPy9VSpx3K0iRAEhRRmke3BxY 2nnFKA70ljDvYpAqHmDKgpv0CmgJE9CSORsyQZaUJCKkpBoYKzt1RJlWp66NuLckx+6NzRmJ i9aPa+537qryfMW08I1MXEX1xd0lajqPNtVKrWpMOZY58x0z63LvU3vZo9zaXVes2CdjW6vC G3eS72hU0evQ/CMCVlsaHM2SRbyku/ftUjyz/6NQk/fB2DcVa31flAr38Loa/F5eKpT+6/+Z 5D/LP6suaG9XYinOSDTUYi4qTgQADnPmhhYDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/igfYLYgk_F26QWC1rC98sJY9fqQ Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 18 Nov 2014 05:33:40 -0000 On 11/17/2014 06:20 PM, Bill Mills wrote: > 1) "a preference to reassign the error code" > > I need specifics here on what needs to happen. KRB5KDC_ERR_NO_ACCEPTABLE_KDF should have the value 100 instead of 82. (This has already been changed in MIT krb5 and the change has shipped.) From nobody Tue Nov 18 08:37:08 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 C85DC1A1AAE for ; Tue, 18 Nov 2014 08:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 pPVoptmfxwXf for ; Tue, 18 Nov 2014 08:37:03 -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 55DFC1A1AA4 for ; Tue, 18 Nov 2014 08:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416328525; bh=C+COxgrvAdf2PaITgvVgLhsDh/9LfJIEoa9M8lXm4lk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UFSZrmsyucMM2x4kOwsVxMl515UpSQ5lbGEw+dEC7/drU6HNp0C6E9Vmd+NM+D3TvzMWFdvKBhJkvg2kUE1T7/m4VacwJtxpGgguG6AButZH6D71BRpOh2gcLQoyGDoSzKTKNhh3VIW6XdRyVLK6Yil5+xCnMtYsIN0mdMyTB7ac501MBe8GkOBpQ+f6IN4uSbqT+qB4EECeCRpInUoCTErKDeZEAj0hT/cIMQZluaRhgjMurx0dWfabC8r1pg09TjMUHFcsBmf4aa6PlV55bXTcKkvjsCEIbz7JiC0sLoQG5EIu124pAnhqAOlHCscCwBF7bXoZA5S/6A7PtuPWNA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=WwK1nyyXAAfPOSgqoNXPaz5is0gpvfFudAb+A1apBksyHtKESwxw1Rg7iBreBKHjafIyWUOxL2udVpCKpBMBe0bvPH912Lgye+ga2u1AsLEIws7g82xWLghvkeH4UYRQOqjpxpu/xCMjy9le1/QifuJyYNQ9yaD+srV40fy0Zs5qlwvMgYyKMlgc2cEsUzs5H7wgdIkIV9v+z9Dx2WgWBmx2U9W9EqdgZAL60AC2c9IM0Sjsi0kdrTZoOnhV06E5i7et6z8cGggno3EYqXZu2UzhU+fFWvZciqhxlr50S5glKo0t5faVdIh02+k6/rOMYYfjVCoFDgrZ20Z37erFfQ==; Received: from [98.139.215.143] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 18 Nov 2014 16:35:25 -0000 Received: from [98.139.212.223] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 18 Nov 2014 16:35:25 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 18 Nov 2014 16:35:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 481388.20794.bm@omp1032.mail.bf1.yahoo.com X-YMail-OSG: rct5wU4VM1lhhLQx.0rXwnYwEd9to_aNY7d17l6cn9OnxQQkMzDBkL1JvVWjsWY DZjIbjYnBKQCygeKYcD7JWg84jZDhUHA6.IkZ8_MrAdrWkvc5MJCGqSPbB0HjpSZkhfQJyc0APBN hOc3wLdFW2ukENavxhzvRyhRkVSeKgVwjPmDVSjlc81DnYpIivIAAgKfjP_NMHDn1cT3rYv08A3i RxRRu53r8HUg1wLxT9ExpXAyoS1LLFayjo3QkgNXTh9NmhvGqmd.IvPJnjzjxwHN5lS5Bbl223Ar Jpwo15KEJrW9nj5erO4Xgzj5Gmwpgmoq_UsZM2lWj5u6HYGE..vwHe.fwA_MZ_vAY_QGss2FhfTu lOST8oNssBQFy56Bv1zGY2D6igJncn9K6TexomaQVqPf8LqbsWaUK1vqK1xNa2vAGQZNQquud_xB 4bZPdxDd6jL7YUG8HKF9_S.kqqGXRCi8N9xGMBcJVq3BFgo5y6vBCCCqxeNQgrwFWtk0deG9I Received: by 66.196.81.119; Tue, 18 Nov 2014 16:35:24 +0000 Date: Tue, 18 Nov 2014 16:35:24 +0000 (UTC) From: Bill Mills To: Greg Hudson , Benjamin Kaduk Message-ID: <1262939230.2059827.1416328524504.JavaMail.yahoo@jws106132.mail.bf1.yahoo.com> In-Reply-To: <546ADA25.3000906@mit.edu> References: <546ADA25.3000906@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/jQprM0fc2gUG3M8gJpAVZjGOwiY Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 18 Nov 2014 16:37:06 -0000 Fixed this. Thanks. On Monday, November 17, 2014 9:33 PM, Greg Hudson wrote: On 11/17/2014 06:20 PM, Bill Mills wrote: > 1) "a preference to reassign the error code" > > I need specifics here on what needs to happen. KRB5KDC_ERR_NO_ACCEPTABLE_KDF should have the value 100 instead of 82. (This has already been changed in MIT krb5 and the change has shipped.) From nobody Tue Nov 18 15:46: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 F2C2C1A876F; Tue, 18 Nov 2014 15:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 IbTJ3hb0v6gk; Tue, 18 Nov 2014 15:46:20 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 157391ACDC8; Tue, 18 Nov 2014 15:46:10 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id C802327BC065; Tue, 18 Nov 2014 15:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:reply-to:mime-version: content-type; s=cryptonector.com; bh=+bBtdPeYs8uQd7EBUB2zBPGC6cc =; b=W5w8dL1rZorHz/kZpIhlbGvY19W28hoQsRkOZtSs0JJKnQIvb5aq0FcTriG a3iO+KhC3KmPZoRFZSrbJ/K1OmSY/lDVBGB22LscR0ws2upi7EOdyBPlCvlcp69t As+5GZ/98gYe5etkaAx3eeNGay5IwSAH5s+tdOiOuNXVOURc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 802CA27BC064; Tue, 18 Nov 2014 15:46:09 -0800 (PST) Date: Tue, 18 Nov 2014 17:46:08 -0600 From: Nico Williams To: tls@ietf.org Message-ID: <20141118234608.GA20721@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TNQgh4u_IajNRM3KJFviAz3AbbA Cc: kitten@ietf.org Subject: [kitten] 0-RTT security considerations (was OPTLS) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 23:46:22 -0000 Following up to the OPTLS proposal I thought it'd be interesting to explore the security (API, and other) considerations of 0-RTT protocols. I'm not sure[0] how much this has been done on this list before, so pardon me if this is noisy. My experience with 0-RTT is mostly from GSS [RFC2743] and Kerberos [RFC4120], where the matter was given some explicit treatment treatment many years ago. That treatment is not complete, so this should be relevant to KITTEN WG as well. I'm cc'ing KITTEN WG, but we should continue the discussion on the TLS list; Reply-To: is set. For me the security considerations of 0-RTT have to bleed into APIs in order to be manageable, which for many TLS apps may well be a deal killer (and I suspect it generally is). I.e., I think 0-RTT is generally more trouble than it's worth. 0-RTT means: The handshake might be two or three messages, but the client can send application data immediately after sending its hello, and the server can send application data immediately after consuming the client's hello. This is not a really a new concept[1]. And this concept generalizes to longer exchanges too; the optimization can be less good than 0-RTT but still better than full latency. A client can do 0-RTT handshakes whenever it can obtain a usable session key immediately upon sending the client's first[0] handshake message. 0-RTT could be made available when: - doing session resumption - the client knows the server's pubkey a priori - using PSK Security considerations: - Replay protection (use replay cache or defer protection) Replay protection on the server side requires either a replay cache (which can more than negate the latency of one network round trip), or deferring replay protection availability to the end of the handshake. Deferring replay protection availability requires that the client's first data record(s) be held for delivery until replay protection is available (again, limiting the value of 0-RTT), or that the application be aware of the replay potential. - PFS (not available for 0-RTT data) What about PFS? Can't be done in 0-RTT, but it can become available when each party learns the others' ephemeral (EC)DH key. Again, the application may (likely will) need to know about PFS being deferred, therefore this is an API consideration as well. - Server authentication state Even in the 0-RTT case the client must check that the server's pubkey hasn't been revoked, of course, but either it won't be able to until it receives the server's Hello (where stapled OCSP should be found), or it will have to check certificate status out of band (which has privacy considerations). The problem here is that any application data sent before receiving the server's Hello will be compromised if the server's private key was compromised (even if the cert was revoked). For HTTP(S) this is a problem: the HTTP request may or may not be sensitive, but the HTTP client implementation and TLS can't know if it is -- only the application can know. This might mean that XHR, HTML, need extensions for specifying this. Again, this is an API consideration as well. DANE makes this consideration go away, mostly[2]. - Client authentication state Imagine a handshake where the client is not authenticated until the second round trip, but we have key material for 0-RTT. The server cannot authorize any application protocol commands at this stage. - Symmetric session key non-reuse depends entirely on the client and its RNG. E.g., in the resumption and PSK cases. When using cipher modes where key/IV reuse is disastrous this could be a serious problem. How to do 0-RTT in non-resumption, non-PSK handshakes: - with key transport (the server's static pubkey must be an encryption key) - with key agreement (the server's static pubkey must be an (EC)DH key) PFS can be added, and anyways, it all looks a lot like session resumption. How to learn the server's pubkey prior to making the client Hello? - use DANE - recall the server's pubkey from a previous connection and use it optimistically (as in: it hasn't changed since last time) The latter is the basis of Hugo Krawczyk's OPTLS proposal. [0] I saw the thread starting at: https://www.ietf.org/mail-archive/web/tls/current/msg13298.html but the treatment of the security considerations of 0-RTT there was not exhaustive, unless I missed it. [1] The GSS-API [RFC2743] has supported sending application data early, and has since 1997 [RFC2078]. GSS calls the "ready to send somewhat-protected data" state "prot_ready". Kerberos V [RFC4120] effectively had it even earlier, in 1993 [RFC1510], and probably before then too. [2] Provided one does not object to DANE. Nico -- From nobody Tue Nov 18 16:07: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 E38431A8AE6 for ; Tue, 18 Nov 2014 16:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 mWzjXWLNR_q4 for ; Tue, 18 Nov 2014 16:04:52 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407C11A87CC for ; Tue, 18 Nov 2014 16:04:52 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so7039759wgh.20 for ; Tue, 18 Nov 2014 16:04: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4Wkd0oYT4ErK6uNZYv94BlPxnGtMPv0iUmphIgMjMi4=; b=aspXC1NZVdnR6Nv0LAhqhWHvC5VWWRA6mTRQbO7mFBgbJ/zKRTRNosxlmAIIIQCRmb YkDyYduqcstr0rxVC8juJcA8pjFV1GU3Y1tcgRybRyMnHG2Lm9/NMQWFBi7+yJC8aNhg KmXunBAjlVK3O5VFi1E8P6SX7jk5hXzVMX7rkj21S0YgZqXFSeH/GMDZPMEOb13xpy0G MZ+5vuIB0i2gpXX2Fvxv8ux3lkYt3ce37Nm+Lke4PyB2D10t1+CH/VV+ZIYWtLgmKBpY 5TFCSLBQGUe2fVkoGBsp8wmGeOKMyzdaPXXchkpf3IeMM2AfB1DEz2vi43qOiciW5SmL rQEw== X-Gm-Message-State: ALoCoQnqAlusPb/DDvH6yISMNNo7/6H8nt+6cD2Rt6Xaw43KOW/66abUPHQ+9B/dojMLEnqi+ALO X-Received: by 10.180.150.138 with SMTP id ui10mr8121882wib.32.1416355490715; Tue, 18 Nov 2014 16:04:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 18 Nov 2014 16:04:10 -0800 (PST) In-Reply-To: <20141118234608.GA20721@localhost> References: <20141118234608.GA20721@localhost> From: Eric Rescorla Date: Tue, 18 Nov 2014 16:04:10 -0800 Message-ID: To: kitten@ietf.org Content-Type: multipart/alternative; boundary=001a11c3fb20e67d2705082af54d Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LKyYC1Uvyw70sO_OHR19lIGluAc X-Mailman-Approved-At: Tue, 18 Nov 2014 16:07:30 -0800 Cc: "tls@ietf.org" Subject: Re: [kitten] [TLS] 0-RTT security considerations (was OPTLS) 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, 19 Nov 2014 00:04:58 -0000 --001a11c3fb20e67d2705082af54d Content-Type: text/plain; charset=UTF-8 On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams wrote: > > Following up to the OPTLS proposal I thought it'd be interesting to > explore the security (API, and other) considerations of 0-RTT protocols. > I'm not sure[0] how much this has been done on this list before, so pardon > me if this is noisy. > A fair bit, including a complete solution in Snap Start and some handwavy stuff in draft-rescorla-tls13-new-flows-01, as well as the Watson Ladd mail you reference below > Security considerations: > > - Replay protection (use replay cache or defer protection) > > Replay protection on the server side requires either a replay cache > (which can more than negate the latency of one network round trip), > or deferring replay protection availability to the end of the > handshake. > > Deferring replay protection availability requires that the client's > first data record(s) be held for delivery until replay protection is > available (again, limiting the value of 0-RTT), or that the > application be aware of the replay potential. > Yes, I agree that this doesn't make sense. The server needs to provide anti-replay as part of the TLS stack using some sort of server-side state. Servers which don't want to do that should not offer 0-RTT. > - PFS (not available for 0-RTT data) > > What about PFS? Can't be done in 0-RTT, but it can become available > when each party learns the others' ephemeral (EC)DH key. > > Again, the application may (likely will) need to know about PFS being > deferred, therefore this is an API consideration as well. > Yes, we'll need APIs to let the client control whether data should be sent w/o PFS. Note that the we already have a parallel situation with resumption which currently never offers OCSP. - Server authentication state > > Even in the 0-RTT case the client must check that the server's pubkey > hasn't been revoked, of course, but either it won't be able to until > it receives the server's Hello (where stapled OCSP should be found), > or it will have to check certificate status out of band (which has > privacy considerations). > > The problem here is that any application data sent before receiving > the server's Hello will be compromised if the server's private key > was compromised (even if the cert was revoked). > > For HTTP(S) this is a problem: the HTTP request may or may not be > sensitive, but the HTTP client implementation and TLS can't know > if it is -- only the application can know. This might mean that XHR, > HTML, need extensions for specifying this. > I'm not following this. Generally, server 0-RTT keys will probably be fairly short-lived by comparison to OCSP-stapled responses, so you can just continue to use the key within the OCSP window. Remember that if the key is compromised within the OCSP window, then the attacker can attack you with 1-RTT as well as 0-RTT. Again, this is also an issue with resumption. - Client authentication state > > Imagine a handshake where the client is not authenticated until the > second round trip, but we have key material for 0-RTT. The server > cannot authorize any application protocol commands at this stage Every proposal I have ever seen for 0-RTT has the client delivering client auth in the first flight for exactly this reason. - Symmetric session key non-reuse depends entirely on the client and > its RNG. E.g., in the resumption and PSK cases. > > When using cipher modes where key/IV reuse is disastrous this could > be a serious problem. > The conventional way to address this (as in snap start) is to use an anti-replay mechanism which ensures uniqueness of the client random, thus providing key uniqueness. -Ekr --001a11c3fb20e67d2705082af54d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 18, 2014 at 3:46 PM, Nico Williams <nico@cryptonector.com&= gt; wrote:

Following up to the OPTLS proposal I thought it'd be interesting to
explore the security (API, and other) considerations of 0-RTT protocols. I'm not sure[0] how much this has been done on this list before, so par= don
me if this is noisy.

A fair bit, includ= ing a complete solution in Snap Start
and some handwavy stuff in = draft-rescorla-tls13-new-flows-01, as
well as the Watson Ladd mai= l you reference below

=C2=A0
Security considerations:

=C2=A0- Replay protection (use replay cache or defer protection)

=C2=A0 =C2=A0Replay protection on the server side requires either a replay = cache
=C2=A0 =C2=A0(which can more than negate the latency of one network round t= rip),
=C2=A0 =C2=A0or deferring replay protection availability to the end of the<= br> =C2=A0 =C2=A0handshake.

=C2=A0 =C2=A0Deferring replay protection availability requires that the cli= ent's
=C2=A0 =C2=A0first data record(s) be held for delivery until replay protect= ion is
=C2=A0 =C2=A0available (again, limiting the value of 0-RTT), or that the =C2=A0 =C2=A0application be aware of the replay potential.
=

Yes, I agree that this doesn't make sense. The serv= er needs to provide
anti-replay as part of the TLS stack using so= me sort of server-side state.
Servers which don't want to do = that should not offer 0-RTT.

=C2=A0
=C2=A0- PFS (not available for 0-RTT data)

=C2=A0 =C2=A0What about PFS?=C2=A0 Can't be done in 0-RTT, but it can b= ecome available
=C2=A0 =C2=A0when each party learns the others' ephemeral (EC)DH key.
=C2=A0 =C2=A0Again, the application may (likely will) need to know about PF= S being
=C2=A0 =C2=A0deferred, therefore this is an API consideration as well.
<= /blockquote>

Yes, we'll need APIs to let the client = control whether data should be sent
w/o PFS. Note that the we alr= eady have a parallel situation with resumption
which currently ne= ver offers OCSP.


=C2=A0- Server authentication state

=C2=A0 =C2=A0Even in the 0-RTT case the client must check that the server&#= 39;s pubkey
=C2=A0 =C2=A0hasn't been revoked, of course, but either it won't be= able to until
=C2=A0 =C2=A0it receives the server's Hello (where stapled OCSP should = be found),
=C2=A0 =C2=A0or it will have to check certificate status out of band (which= has
=C2=A0 =C2=A0privacy considerations).

=C2=A0 =C2=A0The problem here is that any application data sent before rece= iving
=C2=A0 =C2=A0the server's Hello will be compromised if the server's= private key
=C2=A0 =C2=A0was compromised (even if the cert was revoked).

=C2=A0 =C2=A0For HTTP(S) this is a problem: the HTTP request may or may not= be
=C2=A0 =C2=A0sensitive, but the HTTP client implementation and TLS can'= t know
=C2=A0 =C2=A0if it is -- only the application can know.=C2=A0 This might me= an that XHR,
=C2=A0 =C2=A0HTML, need extensions for specifying this.

I'm not following this. Generally, server 0-RTT keys w= ill probably be fairly
short-lived by comparison to OCSP-stapled = responses, so you can just
continue to use the key within the OCS= P window. Remember that if the
key is compromised within the OCSP= window, then the attacker can
attack you with 1-RTT as well as 0= -RTT. Again, this is also an issue
with resumption.

=C2=A0- Client authentication state

=C2=A0 =C2=A0Imagine a handshake where the client is not authenticated unti= l the
=C2=A0 =C2=A0second round trip, but we have key material for 0-RTT.=C2=A0 T= he server
=C2=A0 =C2=A0cannot authorize any application protocol commands at this sta= ge

Every proposal I have ever seen for 0-RT= T has the client delivering
client auth in the first flight for e= xactly this reason.



=C2=A0- Symmetric session key non-reuse depends entirely on the client and<= br> =C2=A0 =C2=A0its RNG.=C2=A0 E.g., in the resumption and PSK cases.

=C2=A0 =C2=A0When using cipher modes where key/IV reuse is disastrous this = could
=C2=A0 =C2=A0be a serious problem.

The = conventional way to address this (as in snap start) is to use an
= anti-replay mechanism which ensures uniqueness of the client random,
<= div>thus providing key uniqueness.

-Ekr
=
--001a11c3fb20e67d2705082af54d-- From nobody Tue Nov 18 16:45: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 058531A8A64; Tue, 18 Nov 2014 16:45:48 -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 Up44oVIrt7Ik; Tue, 18 Nov 2014 16:45:46 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B91051A8734; Tue, 18 Nov 2014 16:45:46 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 3D19D36006B; Tue, 18 Nov 2014 16:45: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=qqEGj5jbqoipyM alsNFxjveQaXY=; b=ZaDmNO2an2WXtfjXpBCMX3E+CbYp9Nsqee6xAT/CayeFqg +AVN06PW+Y84Ny2kBLRuhWMwW/lzWkzreCWhb5JVIO6KyXMnpaJNhW5ulnR0swPZ Q34Ezmqd0DwVfuJlRIAqLqglsbvcCKK+u/buX9IvkBrFUlZJUIcpZAoBTpjMs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id D122536005C; Tue, 18 Nov 2014 16:45:45 -0800 (PST) Date: Tue, 18 Nov 2014 18:45:45 -0600 From: Nico Williams To: Eric Rescorla Message-ID: <20141119004543.GC20758@localhost> References: <20141118234608.GA20721@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/uV19as-0ZzKRZWeJNVr_Lmf-Cv4 Cc: kitten@ietf.org, "tls@ietf.org" Subject: Re: [kitten] [TLS] 0-RTT security considerations (was OPTLS) 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, 19 Nov 2014 00:45:48 -0000 On Tue, Nov 18, 2014 at 04:04:10PM -0800, Eric Rescorla wrote: > On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams > wrote: > > - Replay protection (use replay cache or defer protection) > > [...] > > Yes, I agree that this doesn't make sense. The server needs to provide > anti-replay as part of the TLS stack using some sort of server-side state. > Servers which don't want to do that should not offer 0-RTT. But how would the client know the first time? Perhaps it shouldn't matter. The server should just hold back before delivering the data. Still, in order to do this without a replay cache the handshake has to have two more messages after the one where the client is prot_ready and the client has to confirm the early messages. So this has to be part of the protocol. > - Server authentication state > > > > Even in the 0-RTT case the client must check that the server's pubkey > > hasn't been revoked, of course, but either it won't be able to until > > it receives the server's Hello (where stapled OCSP should be found), > > or it will have to check certificate status out of band (which has > > privacy considerations). > > > > The problem here is that any application data sent before receiving > > the server's Hello will be compromised if the server's private key > > was compromised (even if the cert was revoked). > > > > For HTTP(S) this is a problem: the HTTP request may or may not be > > sensitive, but the HTTP client implementation and TLS can't know > > if it is -- only the application can know. This might mean that XHR, > > HTML, need extensions for specifying this. > > > > I'm not following this. Generally, server 0-RTT keys will probably be fairly > short-lived by comparison to OCSP-stapled responses, so you can just > continue to use the key within the OCSP window. Remember that if the > key is compromised within the OCSP window, then the attacker can > attack you with 1-RTT as well as 0-RTT. Again, this is also an issue > with resumption. Yes, this is a general problem that can only really be addressed via key freshness. > - Client authentication state > > > > Imagine a handshake where the client is not authenticated until the > > second round trip, but we have key material for 0-RTT. The server > > cannot authorize any application protocol commands at this stage > > Every proposal I have ever seen for 0-RTT has the client delivering > client auth in the first flight for exactly this reason. Even ones where the client is afforded confidentiality for its ID? I can certainly imagine protocols where that wouldn't be the case. > - Symmetric session key non-reuse depends entirely on the client and > > its RNG. E.g., in the resumption and PSK cases. > > > > When using cipher modes where key/IV reuse is disastrous this could > > be a serious problem. > > > > The conventional way to address this (as in snap start) is to use an > anti-replay mechanism which ensures uniqueness of the client random, > thus providing key uniqueness. By the time the server can check this it's too late: the client sent the bad ciphertext. Nico -- From nobody Wed Nov 19 10:58:33 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985451AD467 for ; Wed, 19 Nov 2014 10:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 nBYe5NIVD2by for ; Wed, 19 Nov 2014 10:58:22 -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 D2FA11A0235 for ; Wed, 19 Nov 2014 10:58:20 -0800 (PST) X-AuditID: 1209190c-f79dc6d000001b09-74-546ce84b2b34 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8C.94.06921.B48EC645; Wed, 19 Nov 2014 13:58:19 -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 sAJIwJiM010127; Wed, 19 Nov 2014 13:58:19 -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 sAJIwHUQ021210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Nov 2014 13:58:18 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAJIwGbQ014437; Wed, 19 Nov 2014 13:58:16 -0500 (EST) Date: Wed, 19 Nov 2014 13:58:16 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> Message-ID: References: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.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+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrev9IifEYOZ9bYujm1exWHzrus7s wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGVsPXucsaCPq2L1pXbWBsZGji5GTg4JAROJ nkVTmSBsMYkL99azdTFycQgJzGaS6Fx1iAnC2cgo8ePyUUYI5xCTxJ2JC6DKGhglJv2ezwrS zyKgLXHg7x6wWWwCKhIz32wEKuLgEBFQl2j+7g0SZhaQl3i2ppsNxBYWSJTYc6qTBcTmFIiU aDgzDayVV8BR4ufiY8wQ8/sYJT78mcwOkhAV0JFYvX8KC0SRoMTJmU9YIIZqSSyfvo1lAqPg LCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6uVmluilppRuYgQHqyTPDsY3B5UO MQpwMCrx8DLOzAkRYk0sK67MPcQoycGkJMr75BZQiC8pP6UyI7E4I76oNCe1+BCjBAezkghv 7GOgHG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBK/Dc6BGwaLU9NSK tMycEoQ0EwcnyHAeoOGJIDW8xQWJucWZ6RD5U4yKUuK8+iAJAZBERmkeXC8smbxiFAd6RZg3 A6SKB5iI4LpfAQ1mAho8Z0MmyOCSRISUVAOjuVBrqXBgZJDSE/b3JRW/jokkOAo0HexNTdWo fMql5O8e1n4/rC3p20bVQy++r/kX5rNio+HRM9V97McNKhx3rbzhHfs+UF/maIvIl0fbtB7+ YxLicFFevvBGbU2R6dUnByUWXHnEEynM1/JA/mbt71eMPwUMb7xy7dS335FyfNK5uubteruV WIozEg21mIuKEwHtw4GYAQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/p-7ippx5ZILvXfzIm4_Pl6dPJCI Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 19 Nov 2014 18:58:26 -0000 On Mon, 17 Nov 2014, Bill Mills wrote: > > 3) Include informative reference to MD4 spec, seems optional from that > message. Include it? I agree that rfc6150 seems sufficient since it's > noting the retirement of MD4, and the reader can find the MD4 spec > through that route. If it was me I would think about including it, but I'm fine leaving it out, too. > 4) "OID id-pkinit-kdc has been assigned, but not defined in the module": > What needs to be done here? I need suggested text. I think this is a typo and id-pkinit-kdf is what was meant ('f', not 'c'). The text to be added is going to be in Appendix A, in the definition of KDFAlgorithmId, extending the comment with probably something like: The object identifier of the KDF, taken from the arc iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) pkinit(3) kdf(6). We should probably also mention the component identifier 'kdf' where the OIDs are laid out in section 6, so: id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } I guess we should probably come up with component identifiers for its children as well (the next four lines). Anyone have thoughts on that? I don't know how conventional "SHA-1", "SHA-256", etc. are for such things. -Ben From nobody Wed Nov 19 11:24:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8631A1BED for ; Wed, 19 Nov 2014 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 5EO5CXmwQMn5 for ; Wed, 19 Nov 2014 11:23:58 -0800 (PST) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D685F1A1BEC for ; Wed, 19 Nov 2014 11:23:57 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so1672815wgg.14 for ; Wed, 19 Nov 2014 11:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XVVfgFSKJnF8xHNTXlDEs9Sj6idT05R6SR01RmhcMvM=; b=fv9HENfGbrTg6YNLUvxU+kJM5/t2gu3Zs2a7m7dcug6qA1bCPgsExVRLyeVC7UyYRj wrU532niqqv0IShyRv0bb1KbUOlKGhuWcq5Ut9rLHBmPqGSEfXs71MJcNeh5d0swXn1C mJ7C9PSKLnhWMa5Cl3l34Zih9in0+SPQrSVcItMRsD2ElWTYK9qnR3dDtNARuGTchFZk y4hCZV+F6ffbMRa42ZflgO5T2EDDJ5zhYuxZoWkVM1Wmvrfu+0mAOZ4wHMG1aVhhiqCX 7n33u16n8Tw7oXy0/DP7q4UUvEUhrXMXV4tGzqQj3sJl2NmAHzy1EJ/gDNl7OQDXxf8M c7eg== X-Gm-Message-State: ALoCoQkSr9AOUhXU98SMyxaDJeIkeZfM3ueHtJSWBAhsCnh52WMy58ij+WWGtP8pBmA13iUVu32B X-Received: by 10.194.176.198 with SMTP id ck6mr59385597wjc.25.1416425036590; Wed, 19 Nov 2014 11:23:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 19 Nov 2014 11:23:16 -0800 (PST) In-Reply-To: <20141119004543.GC20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> From: Eric Rescorla Date: Wed, 19 Nov 2014 11:23:16 -0800 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e013d191628396c05083b2722 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kipRmd0fWcItySEGn-n8tIu_yZw Cc: kitten , "tls@ietf.org" Subject: Re: [kitten] [TLS] 0-RTT security considerations (was OPTLS) 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, 19 Nov 2014 19:24:00 -0000 --089e013d191628396c05083b2722 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams wrote: > On Tue, Nov 18, 2014 at 04:04:10PM -0800, Eric Rescorla wrote: > > On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams > > wrote: > > > - Replay protection (use replay cache or defer protection) > > > [...] > > > > Yes, I agree that this doesn't make sense. The server needs to provide > > anti-replay as part of the TLS stack using some sort of server-side > state. > > Servers which don't want to do that should not offer 0-RTT. > > But how would the client know the first time? Perhaps it shouldn't > matter. The server should just hold back before delivering the data. > Still, in order to do this without a replay cache the handshake has to > have two more messages after the one where the client is prot_ready and > the client has to confirm the early messages. So this has to be part of > the protocol. I'm not following. The idea here is that the server indicates to the client that it is in principle prepared to do 0-RTT and provides a key that can be used for that. If the client attempts it and it doesn't work out (e.g., because the server has lost the key), you fall back to a 1-RTT handshake, so the server can just discard the data rather than holding it. > > - Client authentication state > > > > > > Imagine a handshake where the client is not authenticated until the > > > second round trip, but we have key material for 0-RTT. The server > > > cannot authorize any application protocol commands at this stage > > > > Every proposal I have ever seen for 0-RTT has the client delivering > > client auth in the first flight for exactly this reason. > > Even ones where the client is afforded confidentiality for its ID? I can certainly imagine protocols where that wouldn't be the case. If you can send encrypted data to the server, you can also encrypt the client's certificate. Yes, it's possible to design protocols where that doesn't work, but it's also possible to design ones where it does. > - Symmetric session key non-reuse depends entirely on the client and > > > its RNG. E.g., in the resumption and PSK cases. > > > > > > When using cipher modes where key/IV reuse is disastrous this could > > > be a serious problem. > > > > > > > The conventional way to address this (as in snap start) is to use an > > anti-replay mechanism which ensures uniqueness of the client random, > > thus providing key uniqueness. > > By the time the server can check this it's too late: the client sent the > bad ciphertext. Good point. I agree that the client needs a strong PRNG. -Ekr --089e013d191628396c05083b2722 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Tue, Nov 18, 2014 at= 04:04:10PM -0800, Eric Rescorla wrote:
> On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> >=C2=A0 - Replay protection (use replay cache or defer= protection)
> >=C2=A0 =C2=A0 [...]
>
> Yes, I agree that this doesn't make sense. The server needs to pro= vide
> anti-replay as part of the TLS stack using some sort of server-side st= ate.
> Servers which don't want to do that should not offer 0-RTT.

But how would the client know the first time?=C2=A0 Perhaps it shoul= dn't
matter.=C2=A0 The server should just hold back before delivering the data.<= br> Still, in order to do this without a replay cache the handshake has to
have two more messages after the one where the client is prot_ready and
the client has to confirm the early messages.=C2=A0 So this has to be part = of
the protocol.

I'm not following. The id= ea here is that the server indicates to the
client that it is in = principle prepared to do 0-RTT and provides a key
that can be use= d for that. If the client attempts it and it doesn't work
out= (e.g., because the server has lost the key), you fall back to a
= 1-RTT handshake, so the server can just discard the data rather
t= han holding it.

=C2=A0
>=C2=A0 - Client authentication state
> >
> >=C2=A0 =C2=A0 Imagine a handshake where the client is not authenti= cated until the
> >=C2=A0 =C2=A0 second round trip, but we have key material for 0-RT= T.=C2=A0 The server
> >=C2=A0 =C2=A0 cannot authorize any application protocol commands a= t this stage
>
> Every proposal I have ever seen for 0-RTT has the client delivering > client auth in the first flight for exactly this reason.

Even ones where the client is afforded confidentiality for its ID? I=
can certainly imagine protocols where that wouldn't be the case.

If you can send encrypted data to the server, you= can also
encrypt the client's certificate. Yes, it's pos= sible to design protocols
where that doesn't work, but it'= ;s also possible to design ones where
it does.


>=C2=A0 - Symmetric session key non-reuse depends entirely on the client= and
> >=C2=A0 =C2=A0 its RNG.=C2=A0 E.g., in the resumption and PSK cases= .
> >
> >=C2=A0 =C2=A0 When using cipher modes where key/IV reuse is disast= rous this could
> >=C2=A0 =C2=A0 be a serious problem.
> >
>
> The conventional way to address this (as in snap start) is to use an > anti-replay mechanism which ensures uniqueness of the client random, > thus providing key uniqueness.

By the time the server can check this it's too late: the client = sent the
bad ciphertext.

Good point. I agree that th= e client needs a strong PRNG.

-Ekr

<= /div>
--089e013d191628396c05083b2722-- From nobody Wed Nov 19 11:56: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 E7F0B1A6F2A for ; Wed, 19 Nov 2014 11:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, 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 wDqTiJ-3fbR7 for ; Wed, 19 Nov 2014 11:56:19 -0800 (PST) Received: from nm46-vm7.bullet.mail.bf1.yahoo.com (nm46-vm7.bullet.mail.bf1.yahoo.com [216.109.115.110]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E5F1A6F88 for ; Wed, 19 Nov 2014 11:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416426977; bh=FtpZDEayYO45+N5hzyWIhdO3vmlXaeepKZTlkLc8vzo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=tLW1kM25+ptLYxlsMGa0y5nkUPX3Xi0WhMt9Lsv4ExbVBPd8+rW+2N7OoRSvo3dNW7pjK4qk1C8Qo949wt1KdBr3NmB2rV3fELyJaXaLy+2sr/4Le3uKHx/j5zLaz4PsduBskoDW4B8VptD1D8HhOGQc5ffaau7eBH9swqMCQ8AkSwRY5O60q6ivIBCv2FPck5J/7MqsGNLUIW7S46Y6qXrck/x/HbWJHOTAty/sLL23zVcm42i9maHfBfqq5WcBCnA6r7xgSYM/NRdy1FfqaaOhRo03JvEl2CJJQELSicANyWn19jzRVCZgUPBX+9nJgpMsnM6tfzNdko1VPYsd6g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=VCYmHRTSLRyjG7AK+zfDxS72p0Kq6AlXt2WUYAsN4KCJyUaWu2oipB+vB6fHqHeR0+Yg1F+E8/tP6VpG26wo+XDePiA2QFNz7WG3cezn9kl3MMc5UEBlBSLkCJBs9TNMVwGsT6OKld3eUTdZwJdlvXqgQGUMzAHV5PFQtTofJnhBbrBr5b95DBFecWzbC6aRQunw2UeZBHbqK3+Zzf6X3bYcMZVMykgaYijZRQEq7s6iZWUFLlI7JM0AEzBnA7sFayFp7x3rps9YN7EDT92ix+bh9jCiLi5LO4ddIgNwpLLr/ME6lZA4U5ln6dCRPuOUBN7AmNydY8vGyuDYp5UM8w==; Received: from [66.196.81.171] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 19 Nov 2014 19:56:17 -0000 Received: from [98.139.212.243] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 19 Nov 2014 19:56:17 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 19 Nov 2014 19:56:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 45246.19909.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: Kh6wspUVM1lcGbawm7h.S7knx6UxK57d7sFieCm.T5QYC1Yj3YJorOEcEW_QJGP wjTQatamiBAjQng9uva1OS2AEa.1A3nQvk0OGBMXJdAJGRHVEHAcKF_4Re8Y0cWLFnVBHF9SQTtI GsjG5PQl4grt9MLHBAHc19H1UvO05btxQ8r3oWkLGf26y2Eafx1XldcaCBb8B2z8CHNyiLXn7J9. 5fn_HALoE0TCkp7FPCrpdaqq560zrxa4v3THC99iMCBnw.h6WMOnabanW.0nYwTlk2d5VqPZt50o clZQxTfaTr7ijeQFzi0WFZQu7N4h7KgpK9UvYd7mr5gbHZXDba1hx.Wfy4wPRLU9fOJuufyQbJXv 6bX7O6_4ORn73i5Zwz4f1DLQptgVz2lZn6vk64e1WuDeBnt_UEDNvqDXrTKCB35BpXg3ALvmq7gS OGnU4uFAxzpdWxL1sWBJzBTNlK26KyRObNUQ3J3YjPEc5BNWgIg_B_E5D4A4T5cJHIJ0.YX13EhM- Received: by 66.196.80.120; Wed, 19 Nov 2014 19:56:16 +0000 Date: Wed, 19 Nov 2014 19:56:16 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <1358838398.2748636.1416426976199.JavaMail.yahoo@jws106141.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VqOhiwXR94PjDcvXzuQZbqzeaPU Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:56:21 -0000 OK, for the first bit.... On Wednesday, November 19, 2014 10:58 AM, Benjamin Kaduk wrote: > The text to be added is going to be in Appendix A, in the definition of > KDFAlgorithmId, extending the comment with probably something like: > The object identifier of the KDF, taken from the arc iso(1) > identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) > pkinit(3) kdf(6). Is the following ccorrect? KDFAlgorithmId ::= SEQUENCE { kdf-id [0] OBJECT IDENTIFIER, -- The object identifier of the KDF, taken from the -- arc iso(1) identified-organization(3) dod(6) -- internet(1) security(5) kerberosV5(2) pkinit(3) -- kdf(6). ... } -bill From nobody Wed Nov 19 12:03:10 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 4C2001A6F14 for ; Wed, 19 Nov 2014 12:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 mPviUcovx58D for ; Wed, 19 Nov 2014 12:03:07 -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 25ACF1A6F45 for ; Wed, 19 Nov 2014 12:01:41 -0800 (PST) X-AuditID: 12074422-f79bf6d000000ffe-54-546cf7256748 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.62.04094.527FC645; Wed, 19 Nov 2014 15:01:41 -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 sAJK1ewM011168; Wed, 19 Nov 2014 15:01:40 -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 sAJK1ccR014535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Nov 2014 15:01:40 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAJK1c1k022333; Wed, 19 Nov 2014 15:01:38 -0500 (EST) Date: Wed, 19 Nov 2014 15:01:38 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1358838398.2748636.1416426976199.JavaMail.yahoo@jws106141.mail.bf1.yahoo.com> Message-ID: References: <1358838398.2748636.1416426976199.JavaMail.yahoo@jws106141.mail.bf1.yahoo.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+NgFnrLIsWRmVeSWpSXmKPExsUixG6noqv6PSfE4PY7JYujm1exWHzrus7s wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGW0Hl/AWPCLveLP8p8sDYz9bF2MnBwSAiYS n39NZIewxSQu3FsPFOfiEBKYzSSxoLeVEcLZyCjxatlUKOcQk8SyS9+hnAZGibv3zjCD9LMI aEvc/rKPFcRmE1CRmPlmI9AsDg4RAXWJ5u/eIGFmAXmJZ2u6wVYLCyRK7DnVyQJSwikQLbGm pxwkzCvgKPGw6SXUFRMYJa4umccEkhAV0JFYvX8KC0SRoMTJmU9YIGZqSSyfvo1lAqPgLCSp WUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRuYgSHqovSDsafB5UOMQpw MCrx8E54nR0ixJpYVlyZe4hRkoNJSZSX7UNOiBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3sNv gHK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8vV+BGgWLUtNTK9Iy c0oQ0kwcnCDDeYCG630DGV5ckJhbnJkOkT/FqCglzpsK0iwAksgozYPrhaWSV4ziQK8I8xqA tPMA0xBc9yugwUxAg+dsyAQZXJKIkJJqYJyj8Xt92emSlu3F/O+Lz/HGq35oy5yneGSuc7Xe Lm3laRvOuafNWx/s2NOevLm0YEn9+rOtD7hd7+SvfJww0TLL4eQ6Sev5PzYwmArq9LVudNwW YLtP5l+uZ6F9SEDdoRK73nUuT0oFd9T0fbJb02Xt8XxD1dHuiKX78/fOzF/Pd9RL+pm2qhJL cUaioRZzUXEiAKqbBIsAAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/A8Rx81fXcdCQePy77OVf9gE_yAU Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 19 Nov 2014 20:03:09 -0000 On Wed, 19 Nov 2014, Bill Mills wrote: > OK, for the first bit.... > > On Wednesday, November 19, 2014 10:58 AM, Benjamin Kaduk wrote: > > > The text to be added is going to be in Appendix A, in the definition of > > KDFAlgorithmId, extending the comment with probably something like: > > The object identifier of the KDF, taken from the arc iso(1) > > identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) > > pkinit(3) kdf(6). > > Is the following ccorrect? > > KDFAlgorithmId ::= SEQUENCE { > kdf-id [0] OBJECT IDENTIFIER, > -- The object identifier of the KDF, taken from the > -- arc iso(1) identified-organization(3) dod(6) > -- internet(1) security(5) kerberosV5(2) pkinit(3) > > -- kdf(6). > ... > } That looks like what I was asking for, yes. (Thanks!) I'm not sure I can decree whether it is correct, not really being an ASN.1 expert. I presume that if it's incorrect, someone will speak up about it. -Ben From nobody Wed Nov 19 12:19: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 D6A981A6F40 for ; Wed, 19 Nov 2014 12:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycCRGBKITV3c for ; Wed, 19 Nov 2014 12:18:57 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 598671A1A66 for ; Wed, 19 Nov 2014 12:18:57 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id E7A061E064 for ; Wed, 19 Nov 2014 12:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DK+9QzPhtyAF8+Zc/AnD q39Yg6g=; b=MQAfhD+kOLE8rNCwsI6vj6rHzIS6uxQmTASRV/eWIdmw4VbU++Un K3qmGLHdMUhpnH2s7U1xOP3INMZ0Uh158erseOERBKIFQ07+GhmH9egLRxAepJeL 5Am7G17b43cZqqlPOAyqOX/Rs8Oxguqbstr+MTAB/y61l+OnW1LAUMI= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id BC59F1E059 for ; Wed, 19 Nov 2014 12:18:56 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so3198039wiw.10 for ; Wed, 19 Nov 2014 12:18:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.223.9 with SMTP id qq9mr40134370wjc.36.1416428335676; Wed, 19 Nov 2014 12:18:55 -0800 (PST) Received: by 10.216.32.136 with HTTP; Wed, 19 Nov 2014 12:18:55 -0800 (PST) In-Reply-To: References: <1358838398.2748636.1416426976199.JavaMail.yahoo@jws106141.mail.bf1.yahoo.com> Date: Wed, 19 Nov 2014 14:18:55 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Gap3PZwH6h8llG33LYD6RsW05Us Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 19 Nov 2014 20:18:59 -0000 On Wed, Nov 19, 2014 at 2:01 PM, Benjamin Kaduk wrote: > On Wed, 19 Nov 2014, Bill Mills wrote: >> Is the following ccorrect? >> >> KDFAlgorithmId ::= SEQUENCE { >> kdf-id [0] OBJECT IDENTIFIER, >> -- The object identifier of the KDF, taken from the >> -- arc iso(1) identified-organization(3) dod(6) >> -- internet(1) security(5) kerberosV5(2) pkinit(3) >> >> -- kdf(6). >> ... >> } > > That looks like what I was asking for, yes. (Thanks!) > I'm not sure I can decree whether it is correct, not really being an ASN.1 > expert. I presume that if it's incorrect, someone will speak up about it. When in a module definition, the above compiles. FOO DEFINITIONS ::= BEGIN EXPORTS kdf-id-arc, KDFAlgorithmId; kdf-id-arc OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) pkinit(3) kdf(6) } kdf-id-test OBJECT IDENTIFIER ::= { kdf-id-arc foo(1) } KDFAlgorithmId ::= SEQUENCE { kdf-id [0] OBJECT IDENTIFIER, -- should be from kdf-id-arc ... } END From nobody Wed Nov 19 12:23:57 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 CF59B1A6F07 for ; Wed, 19 Nov 2014 12:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 lWRgBD1Xyb5Z for ; Wed, 19 Nov 2014 12:23:50 -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 61CA41A1B82 for ; Wed, 19 Nov 2014 12:23:47 -0800 (PST) X-AuditID: 12074422-f79bf6d000000ffe-99-546cfc5243bc Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id AB.B4.04094.25CFC645; Wed, 19 Nov 2014 15:23:46 -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 sAJKNeha019061; Wed, 19 Nov 2014 15:23:41 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAJKNdlC023555; Wed, 19 Nov 2014 15:23:40 -0500 From: Tom Yu To: Benjamin Kaduk References: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> Date: Wed, 19 Nov 2014 15:23:39 -0500 In-Reply-To: (Benjamin Kaduk's message of "Wed, 19 Nov 2014 13:58:16 -0500") Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrBv0JyfEoOu0ucXRzatYLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDIWvdjBWHCPu+LmsaOMDYwrOLsYOTkkBEwk OpfsYYewxSQu3FvP1sXIxSEkMJtJonnSPRYIZyOjRPfnl+wQzhtGiQP93WwgLWwC0hLHL+9i ArFFBJQkFp9tAYszC7hILL9wmxnEFhaIlziw8RPU2BOMEo/vXAJLsAioSmx6e4sVJMEp0MIo sfLJOkaQBK+ArsS+Yy/BjuIR4JTo7etmhogLSpyc+YQFYoOWxI1/L5kmMArMQpKahSS1gJFp FaNsSm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRlBYsrso7WD8eVDpEKMAB6MSD++E 19khQqyJZcWVuYcYJTmYlER5I37lhAjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T38BijHm5JY WZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBm/sbqFGwKDU9tSItM6cEIc3E wQkynAdo+ByQGt7igsTc4sx0iPwpRkUpcd7bIBcJgCQySvPgemFp4xWjONArwrxPQap4gCkH rvsV0GAmkMEbMkEGlyQipKQaGJnUjbZ1bb29vCpGOXiPJ+/ZUCGzG/PS3cR25dzw0LOQXJd3 NrqI01upz2Lq8X22e49H6xRu9ptWyzhz5rtuhxJh+4mzmm5HLda8ZDdFluX8mpOPPcR/TLJP W2jKd33Ob/7dzMnZD1uqGTTS0/+c/cox0zDgl+rCE6taGA/3+p70vr7x0Yf+iUosxRmJhlrM RcWJAAJ8pIX2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/d1FQ5egLeA2X5en04YzjYmE7l-4 Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 19 Nov 2014 20:23:53 -0000 Benjamin Kaduk writes: > On Mon, 17 Nov 2014, Bill Mills wrote: >> 4) "OID id-pkinit-kdc has been assigned, but not defined in the module": >> What needs to be done here? I need suggested text. > > I think this is a typo and id-pkinit-kdf is what was meant ('f', not 'c'). I agree that it's probably a typo and should be id-pkinit-kdf. > The text to be added is going to be in Appendix A, in the definition of > KDFAlgorithmId, extending the comment with probably something like: > The object identifier of the KDF, taken from the arc iso(1) > identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) > pkinit(3) kdf(6). Are we implying that KDF OIDs must only come from that arc in the future? Anyway, it might be easier to refer to it by a shorter identifier, e.g., "taken from the arc id-pkinit-kdf", and define id-pkinit-kdf in the module as well. We should also id-pkinit to the IMPORTS clause if we do that. > We should probably also mention the component identifier 'kdf' where the > OIDs are laid out in section 6, so: > > id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } > > I guess we should probably come up with component identifiers for its > children as well (the next four lines). Anyone have thoughts on that? I > don't know how conventional "SHA-1", "SHA-256", etc. are for such things. RFC 6955 and others seem to lean toward lowercase and unhyphenated (for the base hash algorithm name). From nobody Wed Nov 19 12:30:11 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31CA1AD507 for ; Wed, 19 Nov 2014 12:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 e43ORA7Gk_Sa for ; Wed, 19 Nov 2014 12:30:09 -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 4077A1AD4F8 for ; Wed, 19 Nov 2014 12:30:04 -0800 (PST) X-AuditID: 12074423-f79796d000006ff6-1c-546cfdcae093 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 95.23.28662.BCDFC645; Wed, 19 Nov 2014 15:30:03 -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 sAJKTvsk019974; Wed, 19 Nov 2014 15:29:57 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sAJKTtBg026051; Wed, 19 Nov 2014 15:29:56 -0500 From: Tom Yu To: Benjamin Kaduk References: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> Date: Wed, 19 Nov 2014 15:29:55 -0500 In-Reply-To: (Benjamin Kaduk's message of "Wed, 19 Nov 2014 13:58:16 -0500") Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrHv6b06IwdMTrBZHN69isfjWdZ3Z gcljyZKfTB6zZh1mCmCK4rJJSc3JLEst0rdL4Mp4fp+9oIGlYu7UVuYGxrdMXYycHBICJhKT ly5mh7DFJC7cW8/WxcjFISQwm0lix+J1rBDORkaJO/PuQmXeMEp0n1vEAtLCJiAtcfzyLrBR IgJKEovPtrCB2MwCLhLLL9xmBrGFBeIlDmz8BNV8glHi8Z1LYAkWAVWJ9T+2soMkOAVaGCVW PlnHCJLgFdCVuHKyD6yIR4BTomnJbmaIuKDEyZlPWCA2aEnc+PeSaQKjwCwkqVlIUgsYmVYx yqbkVunmJmbmFKcm6xYnJ+blpRbpmunlZpbopaaUbmIEBSW7i/IOxj8HlQ4xCnAwKvHwTnid HSLEmlhWXJl7iFGSg0lJlDfiV06IEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHew2+AcrwpiZVV qUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxr/wA1ChalpqdWpGXmlCCkmTg4 QYbzAA1vBanhLS5IzC3OTIfIn2LU5WhpetvLJMSSl5+XKiXOqwlSJABSlFGaBzcHlkxeMYoD vSXMewykigeYiOAmvQJawgS0ZM6GTJAlJYkIKakGxlbrkquRr5f9WX9w45/IFpVzMYcT6z4r zFTkqvVcNEW4pfDghZvzbz+2bzS5JBPyfP/ttQbqf8V2T5xWwj1/huoL/qhs9zSpiMwovuCk LvGVPI23GNcWmN4WkX4gsKH/vWOW4U63JIbJnA/kb8zbO0detb7+R+SCUPEtv63kWpPfHIl0 dBE+r8RSnJFoqMVcVJwIAPWJ1ZIBAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/S6mrsQ2IjUhHIwwfsobCvjQl6uA Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 19 Nov 2014 20:30:10 -0000 Also it would be good to change supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, to supportedKDFs [4] SEQUENCE (SIZE (1..MAX)) OF KDFAlgorithmId OPTIONAL, to avoid semantic ambiguity between an omitted supportedKDFs and an included but empty one. I think this will not be controversial, because I doubt anyone relies on that semantic distinction, and the document doesn't specify the difference in semantics between them. From nobody Wed Nov 19 12:33:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3348C1AD495 for ; Wed, 19 Nov 2014 12:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCQO8lsBaQXm for ; Wed, 19 Nov 2014 12:33:10 -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 EB7BF1A1B7D for ; Wed, 19 Nov 2014 12:33:09 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id A90B0163E for ; Wed, 19 Nov 2014 12:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=e9VcZuWMc26moysDynOR qnPXZhY=; b=jCTkxisahWwOIfewsXiWto6rdxC1uqMMrn72gAbf0mgF0df5FBnb h0eAox3S7NEqh5pyndEuGoAn3vF+p9Kkrg9wGEWvvCdjNWIBH96E/vz/8hYiNW7v 6yinCfK4wydIFKAWgnRRWa3tJVUuci7L5QzAFLKBskluXu8d75/IScU= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 7BEAE163C for ; Wed, 19 Nov 2014 12:33:09 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so6674479wiw.7 for ; Wed, 19 Nov 2014 12:33:08 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.19.234 with SMTP id i10mr17253534wie.28.1416429188555; Wed, 19 Nov 2014 12:33:08 -0800 (PST) Received: by 10.216.32.136 with HTTP; Wed, 19 Nov 2014 12:33:08 -0800 (PST) In-Reply-To: References: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.com> Date: Wed, 19 Nov 2014 14:33:08 -0600 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/YBe_i2fcX6k26nWC1eXgMV_DUBc Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 19 Nov 2014 20:33:12 -0000 On Wed, Nov 19, 2014 at 2:23 PM, Tom Yu wrote: > Benjamin Kaduk writes: >> On Mon, 17 Nov 2014, Bill Mills wrote: >> The text to be added is going to be in Appendix A, in the definition of >> KDFAlgorithmId, extending the comment with probably something like: >> The object identifier of the KDF, taken from the arc iso(1) >> identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) >> pkinit(3) kdf(6). > > Are we implying that KDF OIDs must only come from that arc in the > future? Anyway, it might be easier to refer to it by a shorter > identifier, e.g., "taken from the arc id-pkinit-kdf", and define > id-pkinit-kdf in the module as well. We should also id-pkinit to the > IMPORTS clause if we do that. I don't think we should require that KDF OIDs only come from that arc. Rather, we would be creating a registry with that arc from which protocol action assignments should be taken. (One nice result from using OIDs is that private use assignments are feasible with no communication with any external entity. There's no reason to preclude this. Nor is there a way in x.680 to constrain the OBJECT IDENTIFIER type to specific arcs, IIRC -- this wouldn't stop us, of course.) Nico -- From nobody Wed Nov 19 12:51: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 4DC021A1BEE; Wed, 19 Nov 2014 12:51:37 -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 v6y9wLwmA4O3; Wed, 19 Nov 2014 12:51:36 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED91A1B04; Wed, 19 Nov 2014 12:51:36 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id DD1C050808D; Wed, 19 Nov 2014 12:51:35 -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=yI0oTI0J4o8JM3 ZkFokaoQOIKy0=; b=PXdk+rNY28KfOdjf7dlXSpVCDBHKh4A/QBB6b7eEDO6wqh rXP/2C6VOfmMsf+I4zD6YtG3AsAwUq4siAw3KdmFlvhyEqzLy/fLYkAiiVdaBSdi Il7YcsNDyn6r1Zd5ZGQj/seldZe+0AsxYGHwphuYPsqOc2DXe9w22BxYY6yNI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 7919D50808C; Wed, 19 Nov 2014 12:51:35 -0800 (PST) Date: Wed, 19 Nov 2014 14:51:19 -0600 From: Nico Williams To: Eric Rescorla Message-ID: <20141119205117.GE20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@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/zXm790_s0pyF-hVra7c0dynjs-8 Cc: kitten , "tls@ietf.org" Subject: Re: [kitten] [TLS] 0-RTT security considerations (was OPTLS) 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, 19 Nov 2014 20:51:37 -0000 On Wed, Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote: > On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams > wrote: > > > Yes, I agree that this doesn't make sense. The server needs to > > > provide anti-replay as part of the TLS stack using some sort of > > > server-side state. Servers which don't want to do that should not > > > offer 0-RTT. > > > > But how would the client know the first time? [...] > > I'm not following. The idea here is that the server indicates to the > client that it is in principle prepared to do 0-RTT and [...] Certainly in the resumption case. However, in other cases, we'd have to have ensure that whatever oob method is used for establishing the server's public key also conveys this (e.g., we'd need an RR type for indicating this for DANE). It's much easier to have the server hold the early data and have it bound into the client's next handshake msg. > > > - Client authentication state > > > > > > > > Imagine a handshake where the client is not authenticated until the > > > > second round trip, but we have key material for 0-RTT. The server > > > > cannot authorize any application protocol commands at this stage > > > > > > Every proposal I have ever seen for 0-RTT has the client delivering > > > client auth in the first flight for exactly this reason. > > > > Even ones where the client is afforded confidentiality for its ID? I > > can certainly imagine protocols where that wouldn't be the case. Sure, so can I. I was describing generic 0-RTT security considerations. If a specific protocol addresses one of those completely, great. > If you can send encrypted data to the server, you can also > encrypt the client's certificate. Yes, it's possible to design protocols > where that doesn't work, but it's also possible to design ones where > it does. Yes, of course. With TLS 1.2 one can renego. Unless I missed something, there's nothing in 1.3 for protecting the client's ID. With DANE one could definitely authenticate the client in a 0-RTT way, at least if the server has either a public encryption key or a public key agreement key. SSHv2, OTOH, is an example of a protocol where key exchange completes prior to authenticating the user, so in principle one could extend it to send "early data" and run into this security consideration. But this is mostly because SSHv2 is so... shockingly under-optimized as to round trips... so perhaps I was reaching with this consideration :) > > [...] > Good point. I agree that the client needs a strong PRNG. Yes, and perhaps it's just not worth pointing out all the ways in which not having a good RNG is bad. We take the need for a good RNG as a given nowadays... (though we should consider ways to minimize dependence on strong RNGs, see, e.g., EdDSA). Nico -- From nobody Wed Nov 19 13:50:19 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 E67C91A88ED; Wed, 19 Nov 2014 13:50:09 -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 XKeO1PWu1gFP; Wed, 19 Nov 2014 13:50:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B931E1A88F2; Wed, 19 Nov 2014 13:49:59 -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: <20141119214959.10895.13847.idtracker@ietfa.amsl.com> Date: Wed, 19 Nov 2014 13:49:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OuQ57urEGb6Am11_px9Ld_fdr0Q Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gss-loop-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 21:50:10 -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-01.txt Pages : 20 Date : 2014-11-19 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gss-loop-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 19 19:07:21 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 250BA1A0010 for ; Wed, 19 Nov 2014 19:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 FvuTzMciH1mT for ; Wed, 19 Nov 2014 19:07: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 346541A000F for ; Wed, 19 Nov 2014 19:07:16 -0800 (PST) X-AuditID: 12074422-f79bf6d000000ffe-25-546d5ae3d11e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.4B.04094.3EA5D645; Wed, 19 Nov 2014 22:07:15 -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 sAK37ESu023850; Wed, 19 Nov 2014 22:07:15 -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 sAK37CpZ031406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Nov 2014 22:07:14 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAK37Cg7017444; Wed, 19 Nov 2014 22:07:12 -0500 (EST) Date: Wed, 19 Nov 2014 22:07:12 -0500 (EST) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <536100900.1715937.1416266452409.JavaMail.yahoo@jws10665.mail.bf1.yahoo.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+NgFvrFIsWRmVeSWpSXmKPExsUixG6novs4KjfE4PlqTYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYOG0uc8EetoozO5axNzBOYO1i5OSQEDCR mPV8AyOELSZx4d56ti5GLg4hgdlMEgsnPGGEcDYySqzrPsoM4Rxikvje+xAq08AoMWndWmaQ fhYBbYkLBzrYQGw2ARWJmW82gtkiApISx56cB6rh4GAWcJNY9dkTJCwskCjx5kE3O4jNKRAo se/1NLAzeAUcJT5OfsYEMX8tk8TWDVfB5osK6Eis3j+FBaJIUOLkzCdgNrOAlsTy6dtYJjAK zkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZwsLoo7WD8eVDp EKMAB6MSD2+CRW6IEGtiWXFl7iFGSQ4mJVHeflugEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe pf5AOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd4fkUCNgkWp6akV aZk5JQhpJg5OkOE8QMO7QGp4iwsSc4sz0yHypxh1OVqa3vYyCbHk5eelSonzCoMUCYAUZZTm wc2BJZlXjOJAbwnzcgBTjhAPMEHBTXoFtIQJaMmcDZkgS0oSEVJSDYyN1zxCJCWPLcvZtF9T 0ODpBKFNf1/suTrBXP+6pvf5ixKfVR7GnGsuutA6u74wKUPvcebXyKbm9oRJrrZ6Glt09ViF NuTsOP3xZO7//LCC0AXOR3yUpnPvLMyfYMRy79M8tRk1X6e5Lq/ZqiQwm5uH4VnAvfRoh4y7 1c6Hr8QdeLIv6a+e2RMlluKMREMt5qLiRADo4MGsDQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/guzzp9wVsL0vCCaemANX1Sjslbs Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... 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, 20 Nov 2014 03:07:20 -0000 On Wed, 19 Nov 2014, Nico Williams wrote: > I don't think we should require that KDF OIDs only come from that arc. > Rather, we would be creating a registry with that arc from which > protocol action assignments should be taken. Agreed, we shouldn't require that KDF OIDs only come from that arc. I'm not sure I'm parsing the second sentence correctly. Tom, do you have any interest in fleshing out Nico's example into something suitable for Bill to include in the document's appendix? Thanks, Ben > (One nice result from using OIDs is that private use assignments are > feasible with no communication with any external entity. There's no > reason to preclude this. Nor is there a way in x.680 to constrain the > OBJECT IDENTIFIER type to specific arcs, IIRC -- this wouldn't stop > us, of course.) From nobody Thu Nov 20 09:07: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 276D01A1A11 for ; Thu, 20 Nov 2014 09:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 lExtcigixUYQ for ; Thu, 20 Nov 2014 09:07:10 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC3F1A07BE for ; Thu, 20 Nov 2014 09:07:03 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so9402411wiw.1 for ; Thu, 20 Nov 2014 09:07:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NT5QxIvyH6ixv+9MrbsAYu7PoHGko9cNjIfYMj23yWo=; b=LfMaSidgKqiEpWuNaZF6FsAitb0CZOHXiKjRN3PkSZcwcvnsen2+YbS/T/gegVNxI0 gi5/BlTewm3A/0dlTQTzC5KTRPS+pYxw7ohz+5ZBleu8rmOsARIB3QD9Z8J0GdojpX/B fgZ8ts3LbJN7TJ0e0MYZJ2HKZB97LaQu0ZVdCgIuZwxa75S85CfnOB3LbAOnddSr8r74 p3S/DiCp8eVIKkdoE6CU/5pNEBBcDqXNM/MjLw4oHWh+WeihWJmGl1mrNgj0ogboFzJN nzrTyHuSZ1Ot3Fi1H2t8hDtUgz9927pB/N4Pi7XlBUHgIXtxwvosFwkGJXfL8KYtchN1 MBqw== X-Gm-Message-State: ALoCoQkiGw3UTbZhSIbUVt6UGp1k8CW410hyEPFqeGB83+ZdlMkdzX6J8ll5JuwHxsuJd+jLqHhw X-Received: by 10.180.150.138 with SMTP id ui10mr5927417wib.32.1416503221601; Thu, 20 Nov 2014 09:07:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Thu, 20 Nov 2014 09:06:21 -0800 (PST) In-Reply-To: <20141119205117.GE20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@localhost> From: Eric Rescorla Date: Thu, 20 Nov 2014 09:06:21 -0800 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c3fb2058d4c705084d5b16 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/acTvc9L7-FXi29S4h_uO6oCrGFA Cc: kitten , "tls@ietf.org" Subject: Re: [kitten] [TLS] 0-RTT security considerations (was OPTLS) 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, 20 Nov 2014 17:07:12 -0000 --001a11c3fb2058d4c705084d5b16 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams wrote: > On Wed, Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote: > > On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams > > wrote: > > > > Yes, I agree that this doesn't make sense. The server needs to > > > > provide anti-replay as part of the TLS stack using some sort of > > > > server-side state. Servers which don't want to do that should not > > > > offer 0-RTT. > > > > > > But how would the client know the first time? [...] > > > > I'm not following. The idea here is that the server indicates to the > > client that it is in principle prepared to do 0-RTT and [...] > > Certainly in the resumption case. Also in the semi-static DHE cases. > However, in other cases, we'd have to > have ensure that whatever oob method is used for establishing the > server's public key also conveys this (e.g., we'd need an RR type for > indicating this for DANE). I don't see that that's a problem. At present DANE doesn't contain enough information for the client to generate a 0-RTT handshake at all, so as a practical matter we would need to extend the record format, so that would implicitly agree to 0-RTT (or explicitly if you prefer). > It's much easier to have the server hold the > early data and have it bound into the client's next handshake msg. This is not generically possible, because the client may have used a key that the server has forgotten, which requires the client to retransmit. > If you can send encrypted data to the server, you can also > > encrypt the client's certificate. Yes, it's possible to design protocols > > where that doesn't work, but it's also possible to design ones where > > it does. > > Yes, of course. With TLS 1.2 one can renego. Unless I missed > something, there's nothing in 1.3 for protecting the client's ID. > In TLS 1.3, the client's second flight is sent encrypted. If it were sent as part of the first flight, it would also be sent encrypted. -Ekr --001a11c3fb2058d4c705084d5b16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Wed, = Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote:
> On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > > Yes, I agree that this doesn't make sense. = The server needs to
> > > provide anti-replay as part of the TLS stack using some sort= of
> > > server-side state.=C2=A0 Servers which don't want to do = that should not
> > > offer 0-RTT.
> >
> > But how would the client know the first time?=C2=A0 [...]<= br> >
> I'm not following. The idea here is that the server indicates to t= he
> client that it is in principle prepared to do 0-RTT and [...]
Certainly in the resumption case.

Also in = the semi-static DHE cases.

=C2=A0
However, in other cases, we'd have to
have ensure that whatever oob method is used for establishing the
server's public key also conveys this (e.g., we'd need an RR type f= or
indicating this for DANE).

I don't see = that that's a problem. At present DANE doesn't contain enough
=
information for the client to generate a 0-RTT handshake at all, so as=
a practical matter we would need to extend the record format, so= that
would implicitly agree to 0-RTT (or explicitly if you prefe= r).

=C2=A0
=C2= =A0 It's much easier to have the server hold the
early data and have it bound into the client's next handshake msg.

This is not generically possible, because the c= lient may have used
a key that the server has forgotten, which re= quires the client to
retransmit.


> If you can send encrypted data to the server, you can also
> encrypt the client's certificate. Yes, it's possible to design= protocols
> where that doesn't work, but it's also possible to design ones= where
> it does.

Yes, of course.=C2=A0 With TLS 1.2 one can renego.=C2=A0 Unless I mi= ssed
something, there's nothing in 1.3 for protecting the client's ID.

In TLS 1.3, the client's second flig= ht is sent encrypted. If it were sent
as part of the first flight= , it would also be sent encrypted.

-Ekr
=

--001a11c3fb2058d4c705084d5b16-- From nobody Fri Nov 21 07:46:33 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2191A011F for ; Fri, 21 Nov 2014 07:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.795 X-Spam-Level: X-Spam-Status: No, score=-14.795 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 qFeae4sluO3k for ; Fri, 21 Nov 2014 07:46:28 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDB21A1A2F for ; Fri, 21 Nov 2014 07:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1686; q=dns/txt; s=iport; t=1416584789; x=1417794389; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=yYLfWp8W66llTiVeUl1D/yCezzcn/X61JNoJ2K9+pak=; b=QQXDwScqlyL2dEJXS4ySSPzroy0UE02o8ScV15lHwytmLeqz+NRwzNex i4SZmc1uchId5kL49YQL+oaMavmD3IubvO+O9w6U7bY4MFNmNSB9wk8yl RhPMDY9YIWnLJsROHYvvhGT3zTrwjlNupmK29ovFdChRe1XqptSGoBNJG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAAReb1StJV2S/2dsb2JhbABcgw5VWQSDAshfiE0WAQEBAQF9hCwPATsKNgIFFgsCCwMCAQIBSwEMCAEBiD0NtnKWawEBAQEGAQEBAQEdgS2SWYFUBYwbixqCTYRfgTM9gxiCeTuKNoQJggIegXtNgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,432,1413244800"; d="scan'208";a="98904257" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 21 Nov 2014 15:46:06 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sALFk5UR006412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Nov 2014 15:46:05 GMT Received: from [10.129.24.46] (10.129.24.46) by xhc-rcd-x12.cisco.com (173.37.183.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 21 Nov 2014 09:46:05 -0600 Message-ID: <546F5E3C.1010207@cisco.com> Date: Fri, 21 Nov 2014 08:46:04 -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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.46] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rU6XYJEVEgwzZzpO_cmTUBJKkPo Subject: [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, 21 Nov 2014 15:46:31 -0000 -----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= =/6Sj -----END PGP SIGNATURE----- From nobody Fri Nov 21 10:52: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 2BF661A0276; Fri, 21 Nov 2014 10:52: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 8zDXwPSygzjF; Fri, 21 Nov 2014 10:52:26 -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 8CD1E1A033A; Fri, 21 Nov 2014 10:51:40 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 75EA477805F; Fri, 21 Nov 2014 10:51: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=U02JEDOOsNnBJt 3aseDR9ow6fhY=; b=AXbqMnydG47OMICMNTxrig2B11H9UCisTZZBmPACXYKYN8 ieeCF+DSMAcnPkO+Al7OqXHV1VEeF/H9sSdDKXUXpRCVk1bzqBDD6iPYnyIW8+3L LoEdlBrN88EcQ1TBPQ418AuXLLUAJQloHkxhup8gLnoASfCCal/jm4VhnN2PU= 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 2330C778057; Fri, 21 Nov 2014 10:51:39 -0800 (PST) Date: Fri, 21 Nov 2014 12:51:38 -0600 From: Nico Williams To: Eric Rescorla Message-ID: <20141121185136.GF20758@localhost> References: <20141118234608.GA20721@localhost> <20141119004543.GC20758@localhost> <20141119205117.GE20758@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/ZQxuqPB0WG1nrR-VBCsYuP8D3c8 Cc: kitten , "tls@ietf.org" Subject: Re: [kitten] [TLS] 0-RTT security considerations (was OPTLS) 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, 21 Nov 2014 18:52:27 -0000 On Thu, Nov 20, 2014 at 09:06:21AM -0800, Eric Rescorla wrote: > On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams > wrote: > > > Certainly in the resumption case. > > Also in the semi-static DHE cases. Yes, of course (it's like resumption in a way). > > However, in other cases, we'd have to > > have ensure that whatever oob method is used for establishing the > > server's public key also conveys this (e.g., we'd need an RR type for > > indicating this for DANE). > > I don't see that that's a problem. At present DANE doesn't contain enough > information for the client to generate a 0-RTT handshake at all, so as > a practical matter we would need to extend the record format, so that > would implicitly agree to 0-RTT (or explicitly if you prefer). My inclination is to think that adding a new RR type or extending TLSA for this is not worthwhile. See below. > > It's much easier to have the server hold the > > early data and have it bound into the client's next handshake msg. > > This is not generically possible, because the client may have used > a key that the server has forgotten, which requires the client to > retransmit. Yes, indeed. Applications that can retransmit, could do that. For other applications (which is to say: most) the result has to be failure, and then a reconnect. Not good. This is a good reason to want to minimize 0-RTT usage to cases where the client has good reason to think the server will be able to handle it: when a) the server said or advertised so earlier, b) not much time has passed since. 0-RTT is an optimization, but if it can lead to failures that applications must special-case, then that's problematic. For HTTPS that's probably not a problem (it's just one reconnect). Will 1.3 support 0-RTT? > > Yes, of course. With TLS 1.2 one can renego. Unless I missed > > something, there's nothing in 1.3 for protecting the client's ID. > > In TLS 1.3, the client's second flight is sent encrypted. If it were sent > as part of the first flight, it would also be sent encrypted. So... is confidentiality protection of the client's cert/ID explicitly supported in 1.3? That'd be great news. Nico -- From nobody Fri Nov 21 14:36: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 E608B1A8A9E for ; Fri, 21 Nov 2014 14:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.795 X-Spam-Level: X-Spam-Status: No, score=-14.795 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 oc8hymuvLy7L for ; Fri, 21 Nov 2014 14:36:20 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEF21A6F9C for ; Fri, 21 Nov 2014 14:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1883; q=dns/txt; s=iport; t=1416609380; x=1417818980; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=jugeYYEqQ1Gnmt/QlvSHs+mnLtbx+et4NLNvwPnqToU=; b=KkpiUh0n+ZjtBdnve9ldb/fsWSNBQN7Gz6N9UiQuAJOh0oM136PphNnl uWQzprJwDx1rSjAexx1089Dh1L1kJKviMXe3TBazOjJT/20Hxzzc2cRan L3a5ojAZWCYupkSC4ZHSvfQTVyVjybijF8HasWU976T5qhF9qfriaYm5C E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAGy9b1StJA2E/2dsb2JhbABcgw5VWQSDAskVh3MWAQEBAQF9hCwPAUU2AgUWCwILAwIBAgFLDQgBAQWIOA2nKY9OlxIBAQgBAQEBHoEtkl6BVQWMJIslhzGBNINZgn07ikWECYIEHoF7WIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,433,1413244800"; d="scan'208";a="374393113" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 21 Nov 2014 22:36:19 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sALMaJZg017424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Nov 2014 22:36:19 GMT Received: from [10.21.87.95] (10.21.87.95) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 21 Nov 2014 16:36:18 -0600 Message-ID: <546FBE62.5090707@cisco.com> Date: Fri, 21 Nov 2014 15:36: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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.21.87.95] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/iDup-s6gNbZD0btu_Gap6YQPZUk Subject: [kitten] IETF91 Draft Minutes 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, 21 Nov 2014 22:36:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello All, The current draft of minutes from the session at IETF 91 are now on datatracker at < http://www.ietf.org/proceedings/91/minutes/minutes-91-kitten >. The action items that came from the meeting are: 1) draft-ietf-krb-wg-pkinit-alg-agility * Bill Mills to edit document 2) draft-ietf-kitten-gss-loop * Chairs to issue another WGLC when edits are published 3) draft-ietf-kitten-channel-bound-flag * Chairs to find an editor 4) draft-josefsson-kitten-gs2bis * Alexey Melnikov to edit document * Sam Hartman to review 5) draft-ietf-kitten-rfc6112bis * Sam Hartman to edit this document. * Chairs to issue WGLC with other -bis drafts (4 weeks) 6) draft-ietf-kitten-rfc5653bis * Chairs to issue WGLC with other -bis drafts (4 weeks) 7) draft-ietf-kitten-rfc5653bis * Chairs to issue WGLC with other -bis drafts (4 weeks) 8) draft-ietf-kitten-rfc4402bis * Chairs to issue WGLC with other -bis drafts (4 weeks) 9) draft-ietf-kitten-sasl-oauth * Justin Richer and Nico Williams will re-read -17 and send feedback to the list * WGLC once GSS-loop finishes its WGLC Please submit any corrections to this list (kitten AT ietf.org) or to the Chairs (kitten-chairs AT tools.ietf.org) as soon as possible. - - Your kitten chairs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUb75iAAoJEDWi+S0W7cO1V5cH/j/X4KCj3MUCi71cwg+Lgt5b 79lBHrZxTY6qoM0F7HYD8Es7lrM/LunjkiIqYPNPgqltkfI1tWsfYQzDsBCe6Ict SGf+wHLVy+0ELxpddT1CswWzvHA0J+oMQZFMrQpdkDtE931vn+v206kAsasIb52X 5z21FKZa8P1KRlC4ta8EqRGlX5uvzsck4xhsyUkFHCFyWJObsu0FQcyTS0rcY28N +cu36VPAKzitrah3/lzloSOKu8khYaIDCET3fN3kAwpvG0N0XYAKIWzkkoTBi8bb 4dkF9q8miIxVsO5Q7n3FB+0yPq1YJx6RYlNDcb37L4SRNLesTEUxYI5r9ASpprU= =fa7I -----END PGP SIGNATURE----- From nobody Mon Nov 24 10:31: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 981371A1A00 for ; Mon, 24 Nov 2014 10:31:42 -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 NLZJZyNRZH_C for ; Mon, 24 Nov 2014 10:31:35 -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 A6F971A049A for ; Mon, 24 Nov 2014 10:31:35 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-45-547379869197 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 12.6C.03326.68973745; Mon, 24 Nov 2014 13:31:34 -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 sAOIVXuQ016483; Mon, 24 Nov 2014 13:31:34 -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 sAOIVVDC009235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Nov 2014 13:31:32 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAOIVUjV016026; Mon, 24 Nov 2014 13:31:30 -0500 (EST) Date: Mon, 24 Nov 2014 13:31:30 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141110162504.GA3412@localhost> Message-ID: References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@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+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrdtWWRxiMPWGmMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGU8O72TqeAJc8Xs+5NYGhj/MHUxcnBICJhI PNtr28XICWSKSVy4t54NxBYSWMwk0fY+pIuRC8jeyChx/OESRgjnEJPE0TkzoZwGRom3p9uY QSaxCGhLvPkUAtLNJqAiMfPNRrBJIgKaEtfnLQWzmQWEJdafm8EMYgsDxXd+vcUKYnMK6Ens W3KdBcTmFXCU2L32HSvEFfUS/RsmMYHYogI6Eqv3T4GqEZQ4OfMJC8RMLYnl07exTGAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYzgMJXk28H49aDSIUYB DkYlHl6GA0UhQqyJZcWVuYcYJTmYlER5DbKLQ4T4kvJTKjMSizPii0pzUosPMUpwMCuJ8Kbl A+V4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4d1cANQoWpaanVqRl 5pQgpJk4OEGG8wANPw9Sw1tckJhbnJkOkT/FqMvR0vS2l0mIJS8/L1VKnPc7SJEASFFGaR7c HFh6ecUoDvSWMC8fSBUPMDXBTXoFtIQJaEnczEKQJSWJCCmpBkanmXHt5ybv+3+AZ/nqH6Kb eq8WMhWf87wzZ2Pi0/fPjihGLjN+uEjYt1Vw5YUAlW+Cyu/rV79+c/aUn4uWjEFFINuXrTz3 t+9Lnn12UXjMA+Nsy6dz1r4/4FyrHMqezrqvxjjeiv9k8yrbF1oWy77uzPlp1RLyzWFj4iOV T/l9zlsKsrm33fFRYinOSDTUYi4qTgQAa6DRbQoDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3nHFSOdErjzedkS7ja_xxWh8WNs 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, 24 Nov 2014 18:31:42 -0000 On Mon, 10 Nov 2014, Nico Williams wrote: > On Sat, Nov 08, 2014 at 02:48:20AM +0100, Martin Rex wrote: > > > > You find similar descriptions for GSS_S_FAILURE semantics all over > > the GSS-API specification _on_purpose_, and you _may_not_ remove that > > meaning here. > > Fair enough, we'll add text rather than replace text. Nico, do you plan to come up with text for an alternate proposal? Stephen can make the changes once we have text we're happy with. -Ben From nobody Mon Nov 24 10:34: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 1283D1A701E for ; Mon, 24 Nov 2014 10:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx-MmQGUu5ZH for ; Mon, 24 Nov 2014 10:33:50 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3FC1A8783 for ; Mon, 24 Nov 2014 10:33:50 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 59D7F1DE059 for ; Mon, 24 Nov 2014 10:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hMXUH152qoJgOS9+ajVd GY7Jx1A=; b=m8aZut4CVKjF3HXbqZLT+Jp1nYmI1CCbtl685/SWm3hw7p7N2bm3 wF+bPW6TEddrFTFdiABerw0kwrG6DWryGP2VyPMFAdRc34saFgWEeHMA+JCqhAlN iF64HrfzL9I6qMD3NtexXm2IwVwuks2CdW1NNb/laHnlnNvZpVXejf8= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 2A00E1DE058 for ; Mon, 24 Nov 2014 10:33:50 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so6680914wid.3 for ; Mon, 24 Nov 2014 10:33:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.104.234 with SMTP id gh10mr23803012wib.3.1416854029065; Mon, 24 Nov 2014 10:33:49 -0800 (PST) Received: by 10.216.32.136 with HTTP; Mon, 24 Nov 2014 10:33:49 -0800 (PST) In-Reply-To: References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> Date: Mon, 24 Nov 2014 12:33:49 -0600 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/p1KwXNpOkmbC2T135vtJjLDNwIA 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, 24 Nov 2014 18:33:56 -0000 On Mon, Nov 24, 2014 at 12:31 PM, Benjamin Kaduk wrote: > On Mon, 10 Nov 2014, Nico Williams wrote: > >> On Sat, Nov 08, 2014 at 02:48:20AM +0100, Martin Rex wrote: >> > >> > You find similar descriptions for GSS_S_FAILURE semantics all over >> > the GSS-API specification _on_purpose_, and you _may_not_ remove that >> > meaning here. >> >> Fair enough, we'll add text rather than replace text. > > Nico, do you plan to come up with text for an alternate proposal? Yes, I do (I was hoping Martin might :). > Stephen can make the changes once we have text we're happy with. OK. From nobody Mon Nov 24 10:51: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 EFB361A879C for ; Mon, 24 Nov 2014 10:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ncZPQfZtAnea for ; Mon, 24 Nov 2014 10:51:33 -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 B18BC1A87AE for ; Mon, 24 Nov 2014 10:51:17 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 8E7AD163E; Mon, 24 Nov 2014 10:51:17 -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=Hi4O3a3mSRXsH+ F6pV4svecx2/Y=; b=MLi/wttgOyvNDvj8vxKPrrKzFmx8WkPKeH7IolBxL1EdbP mGQ2zDT/W2hm6lKUH1BG5ODCsebUKhvv8zzOh8OPoYGIqj0S4NEPLrnahvZubwqi hawY3SWZif+YEdPvPFiebMKaVATJIO1XFRCNZNgw1EEZYjp72IbKyGQEJLKuA= 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 46B65161E; Mon, 24 Nov 2014 10:51:17 -0800 (PST) Date: Mon, 24 Nov 2014 12:51:16 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141124185114.GM3200@localhost> References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@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/2LmHDhi_OSjlmIVlxYGlfft4Ehs 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, 24 Nov 2014 18:51:35 -0000 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 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 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. 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 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. Nico -- From nobody Mon Nov 24 13:09: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 01BCC1A912D for ; Mon, 24 Nov 2014 13:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 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, MIME_8BIT_HEADER=0.3, 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 bg95u5HSonAQ for ; Mon, 24 Nov 2014 13:09:45 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 756DF1A9127 for ; Mon, 24 Nov 2014 13:09:45 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 335042005D00B; Mon, 24 Nov 2014 13:09:45 -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:content-transfer-encoding; s= cryptonector.com; bh=N+3/H6rJ7eKUGdL0wUmHvOP3KAY=; b=H1bOi26Mbkb kkBz7EUrVod5DCfJIBIkzBTE1LKTJMsG4Ki7RWJVI8qBbUQ895I1wFIep11HTFHF nErPcYw4dKmKONtnB7Q6H5GStAPxD8ttsXUEHlh4kHH6t2YM0eCaeegXSeqs2Gh2 nVkLvw+Pmj9fdZZC1uLuWjMK28u8Dym0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id CD9842005D009; Mon, 24 Nov 2014 13:09:44 -0800 (PST) Date: Mon, 24 Nov 2014 15:09:44 -0600 From: Nico Williams To: =?utf-8?B?4oyY?= Matt Miller Message-ID: <20141124210942.GQ3200@localhost> References: <546F5E3C.1010207@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <546F5E3C.1010207@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mbmOyyySW7lCzM8MFQmIISFj7x8 Cc: "kitten@ietf.org" , "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: Mon, 24 Nov 2014 21:09:51 -0000 On Fri, Nov 21, 2014 at 08:46:04AM -0700, =E2=8C=98 Matt Miller wrote: > http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-01 >=20 > Because the changes between -00 and -01 are substantial, the Chairs > decided to issue a second last call. Comments: - Section 2, nit: this should be a list with bullets. - Section 2, think there's no need to frame initial security context tokens differently than others, except asynchronous (error, deletion) context tokens, but the first and second list items give this impression... The node producing the error token doesn't know whether the peer thinks the context is fully established, therefore the second item in the list is... not workable. And whether an application needs to frame the initial security context token differently from others is really dependent on the application protocol. E.g., the initiator might need to say "I'm starting the GSS login procedure", but for some protocols, such as 'knc' the client just starts sending context tokens from the start, with no special framing beyond the token length, so there's no generic need. Proposed fix: OLD: A way to frame and identify the initial context negotiation tokens in the loop. A way to frame and identify subsequent context-level tokens (e.g., error tokens) after a GSS_S_COMPLETE return. NEW: A way to frame and identify security context negotiation tokens in the loop. Error tokens should generally also get special framing, as the recipient may have no other way to distinguish unexpected error context tokens from per-message tokens. - Section 2, the application protocol may need to provide something like a "username" to authorize access to. (E.g., SSHv2 does.) OLD: The application (not the protocol) should provide for authorization checks in the acceptor. The GSS-API authenticates the initiator, but does not make any claim about whether the initiator is authorized for any given operation. In particular, the initiator may be from a different portion of a federated identity scheme. NEW: The GSS-API provides for authentication of mechanism-specific principals (which have names). Applications are responsible for authorization of authenticated peer principal names. - Section 4.2, last para, should be "in particular" "mutual authentication" and "replay protection" "are not available"... And even "other services". (E.g., if/when we add a GSS_C_PFS_FLAG, that may not be available at the same time as early PROT_READY.) - Section 4.3, second para, first sentence, nit: s/, but/; / - Section 4.3 and section 7, add reference to erratum 4151 (which we should revise with text like what I proposed today and do a consensus call on to get it or acceptable alternatives accepted as a valid erratum). - Section 6, Add text to the effect that "all security considerations from RFCs 2743 and 2744 apply". - Section 6, last para, the last two sentences should probably be swapped, or else in the next to last sentence s/existing software/implementations protocols intended to produce a secure octet stream/. And that's it for me. Most of the above are nits, really. With those nits fixed this I-D will be ready to be published. Thanks for seeing this through! Nico --=20 From nobody Mon Nov 24 17:35: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 5E2471A7022 for ; Mon, 24 Nov 2014 17:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ht8rJ8jyCZud for ; Mon, 24 Nov 2014 17:34:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 57D3C1A7008 for ; Mon, 24 Nov 2014 17:34:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 03D14BEB3 for ; Tue, 25 Nov 2014 01:34:36 +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 TsTLD-yf_bvr for ; Tue, 25 Nov 2014 01:34:35 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8BA2BEAA for ; Tue, 25 Nov 2014 01:34:34 +0000 (GMT) Message-ID: <5473DCAA.7010604@cs.tcd.ie> Date: Tue, 25 Nov 2014 01:34:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/g8CywpS23YIXRtrM9wyOiOTpf5g Subject: [kitten] AD review of draft-ietf-kitten-cammac 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, 25 Nov 2014 01:34:42 -0000 Hiya, Sorry for being a bit slow with this. Some nitty points below, but it's fine to consider 'em with any other LC comments and I'll now start the IETF LC. Thanks, S. - intro: I hate the term "trusted services" if you had a better one, life would be a little nicer:-) But I guess that's baked in, though you really only mean a host key I guess. - I had to read section 3 twice, though it has been ages since I delved into Kerberos detail. I think a diagram might help many readers, but am fine if you think implementers wouldn't need that. - the conditions in section 8 for when it's ok to create a new CAMMAC without verifying the old are not very clear to this reader but do look ok. Would a bit of pseudo-code help maybe? From nobody Tue Nov 25 06:13:08 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 A7EC11A1A6D; Tue, 25 Nov 2014 06:13:06 -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 9NkfVcHarKWq; Tue, 25 Nov 2014 06:13:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0551A1A48; Tue, 25 Nov 2014 06:13:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141125141300.4452.6446.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 06:13:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VxNNfgKEhr9ekXFGMmdLkpG7o7I Cc: kitten@ietf.org Subject: [kitten] Last Call: (Kerberos Authorization Data Container Authenticated by Multiple MACs) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 14:13:07 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'Kerberos Authorization Data Container Authenticated by Multiple MACs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. This document updates RFC 4120. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 25 11:22:09 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 602DE1ACE0C for ; Tue, 25 Nov 2014 11:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Xtdiig-6uVJm for ; Tue, 25 Nov 2014 11:21:03 -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 EDFB71ACDFF for ; Tue, 25 Nov 2014 11:21:00 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPJKi8g028105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 25 Nov 2014 14:20:45 -0500 Received: from willson.usersys.redhat.com ([10.3.113.5]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAPJKhHK019016 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Nov 2014 14:20:44 -0500 Date: Tue, 25 Nov 2014 14:20:41 -0500 From: Simo Sorce To: Stephen Farrell Message-ID: <20141125142041.7dbeba25@willson.usersys.redhat.com> In-Reply-To: <5473DCAA.7010604@cs.tcd.ie> References: <5473DCAA.7010604@cs.tcd.ie> 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.24 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ylTbxJBGsrlLucYELkjb9R3MuRU Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-cammac 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, 25 Nov 2014 19:21:05 -0000 On Tue, 25 Nov 2014 01:34:34 +0000 Stephen Farrell wrote: > > Hiya, > > Sorry for being a bit slow with this. Some nitty points below, but > it's fine to consider 'em with any other LC comments and I'll now > start the IETF LC. > > Thanks, > S. > > - intro: I hate the term "trusted services" if you had a better one, > life would be a little nicer:-) But I guess that's baked in, though > you really only mean a host key I guess. Not necessarily a host key, someone may just decide to use a different service principal key, perhaps one dedicated just to the task. That's why the plural and the "trusted". > - I had to read section 3 twice, though it has been ages since I > delved into Kerberos detail. I think a diagram might help many > readers, but am fine if you think implementers wouldn't need that. I am quite biased, as an author, as I've been working through the details so much they are quite familiar to me. That said I think an implementer should find the descriptions clear enough that there are no ambiguities or difficulties in determining the meaning of the text. > - the conditions in section 8 for when it's ok to create a new CAMMAC > without verifying the old are not very clear to this reader but do > look ok. Would a bit of pseudo-code help maybe? I am not sure pseudo-code is really needed, if an implementer really has doubts he can simply always attach all required signatures and always verify them, there is never a case where a party would fail because everything is in place :) Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Tue Nov 25 11:45: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 EE3B21A6EED; Tue, 25 Nov 2014 11:43:23 -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 gSBUjBbEeRQk; Tue, 25 Nov 2014 11:43:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5E81A007C; Tue, 25 Nov 2014 11:43:22 -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: <20141125194322.31870.82600.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:43:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lYd8LTAuSTjQzTkDOtlZclW0CAQ Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:43:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : 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 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 25 11:47: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 746B11A87AE for ; Tue, 25 Nov 2014 11:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.891 X-Spam-Level: * X-Spam-Status: No, score=1.891 tagged_above=-999 required=5 tests=[BAYES_60=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xVv0rXbSpCsj for ; Tue, 25 Nov 2014 11:45:35 -0800 (PST) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FDE1A8791 for ; Tue, 25 Nov 2014 11:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416944728; bh=Kbu0Ce8m+s2gsAxm83nNuik2Ntm/S6WZw45WOrjfZwg=; h=Date:From:Reply-To:To:Subject:From:Subject; b=HypLcMBY5Nbon4cOxVfebhDowsFz3n2SIPk4KUY31o6TnSZ+Rmmm1dhYeATulxahU01WiNiWtRAeAWJvDmdY2Zolk6WWhO8gspH8qXsSUViuIY/idLkRyYtFk2KQ1eKWXh5cwhhNNOAHWbo1d8VCq/PMrOKLILCk9T3anamJp9F21PhncaMtp1esXPmN4EBuH3TkkEB9z6ozP2z7ijLY15zcaCswOYzbQ0zw71vhh/ZzTH+AdsanSU1GR2BYTH5mHETIpMJz1ku22nY/bp59CBzsaehjRtteslfCWwOMnOo85tTI1/+bfHTXdDGq3x1AdikA/NwSCy6CrlFGLvAJYQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=DesmxoKzyoBnXyNpS58f6RlQVRxWGoH9E3d3uAqc7IG1rKJHC7QHaxe59tO5I/CwzfBrKrlWGVHKJF/Zz0nQEWDYHdqU6mmNK518KU02Na7/ToIsoB5J7gCbNatHqfo0y9mGARncTn4lqpm18sxHOX5vpbBdptFodxZm3M9Rw8fL/U1SCac0ss2cWqlSHDr73xlYCjgl3+qyeYFct5zT2pJ8J6t+KXB6nnMLeSGUXN/qvmqSchtal27hS75Wv7OzU8npcfWokGxF3t60utCUEdSP1dPx/BtDC/H4DUM8Lhq4KnuixBjUOzNNROtE3+QyiNES5mAkxzuhqbcsrZdeIA==; Received: from [98.139.212.152] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 25 Nov 2014 19:45:28 -0000 Received: from [98.139.212.200] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 25 Nov 2014 19:45:21 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 25 Nov 2014 19:45:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 429122.32230.bm@omp1009.mail.bf1.yahoo.com X-YMail-OSG: BuYHrWEVM1mu2gLIAZhg1fKty2xtVf6.ADo_L0rxMsLTUU0AZDGLqO63YHC7OBO zGC8BLBKIhhgY5Z3ifw.ZsSdO3Rit4ehbuYxqvgttqaF_jdoSiC0kE8k6WSx1QaylMtiSlDL8MGb 56w17bRolmVaaZmylk3vj5tJDr4gZA.929lLCciMvijPAfkMQ3etMiKrFiUiyhD2rhYQXVgQG8nq .DsNUJ7pLNbgerbpCYsSnHJPiEJ0UpQINs__nKBEHlboMY9rCHjES0w6w1YUuIds1.olsCwxrS8_ FXZpfT_GwvaLmsD9dDkKweCNJgVPkNZjEcYme6y07uFBWVZBvHcLn9PMdBbqtiAGpRGYa0YuJGZg d5641KGzIvgYI42wWTQPEoLyoHMouQYgt6xPIN_WcVfu550tEauHOTPwdGjQuGjJ9PkD6_Dc2.OP zca5hF6TAWH.ouWFF1RQdefsfnjrp_nCBWFgxm6FK9QXJyEa3pYNfubujY_N.hl_LDRoJMR5XQw-- Received: by 76.13.26.110; Tue, 25 Nov 2014 19:45:21 +0000 Date: Tue, 25 Nov 2014 19:45:20 +0000 (UTC) From: Bill Mills To: Kitten WG Message-ID: <320045518.928965.1416944720697.JavaMail.yahoo@jws10654.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_928964_597743829.1416944720695" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Yq77xV4mJ9g1l-CLCdcXcdIXlfQ Subject: [kitten] SASL/OAUTH WGLC one last time? 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, 25 Nov 2014 19:45:36 -0000 ------=_Part_928964_597743829.1416944720695 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just submitted draft -18 including the feedback from -17 both here and from= the OAUTH list.. =C2=A0If WGLC hasn't started once again is it time yet? Thanks, -bill ------=_Part_928964_597743829.1416944720695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Just submitted draft -18 including the feedback from -17 both here and from the OAUTH list..  If WGLC hasn't started once again is it time yet?

Thanks,

-bill
------=_Part_928964_597743829.1416944720695-- From nobody Tue Nov 25 18:36: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 142C71A86EB for ; Tue, 25 Nov 2014 18:36: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 OF-5GHHbm_l1 for ; Tue, 25 Nov 2014 18:36:29 -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 CC4351A0398 for ; Tue, 25 Nov 2014 18:36:27 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-26-54753caa8e43 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 9A.92.03326.AAC35745; Tue, 25 Nov 2014 21:36:26 -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 sAQ2aPYB032202; Tue, 25 Nov 2014 21:36:25 -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 sAQ2aN1D027656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Nov 2014 21:36:24 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAQ2aMXa022619; Tue, 25 Nov 2014 21:36:22 -0500 (EST) Date: Tue, 25 Nov 2014 21:36:22 -0500 (EST) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20141124210942.GQ3200@localhost> Message-ID: References: <546F5E3C.1010207@cisco.com> <20141124210942.GQ3200@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1983199521-1416877690=:19231" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixG6norvKpjTE4PIfZYtDF44zWhzdvIrF 4tS1I2wOzB4vT51j9Fiy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mj69Xs9c8M+oYsa9/6wN jF/Uuxg5OSQETCSWXl/PCGGLSVy4t56ti5GLQ0hgMZPEnTPbmCGcjYwSyyZ0sEA4h5gkJkw9 wgjhNDBKfOibBNbPIqAtsWX3PjYQm01ARWLmm41gtoiApsT1eUvBbGaBfIm/d14xdTFycAgL WEvM2xkKEuYU0JPYc+knM4jNK+Ao8e/uUXYQW0jAS+LBxJmsILaogI7E6v1TWCBqBCVOznzC AjEyUOLv/p1QtqPE7VfTWScwCs1CUjYLSdksJGUQtrrEgU8XGSFsbYn7N9vYYGpunP/BuoCR bRWjbEpulW5uYmZOcWqybnFyYl5eapGusV5uZoleakrpJkZQ3HBK8u1g/HpQ6RCjAAejEg9v hkZpiBBrYllxZe4hRkkOJiVR3lYtoBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXgkGoBxvSmJl VWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgRvnDVQo2BRanpqRVpmTglCmomD E2Q4D9DwRJAa3uKCxNzizHSI/ClGRSlxXk2QhABIIqM0D64XltZeMYoDvSLMGw1SxQNMiXDd r4AGMwENjptZCDK4JBEhJdXAODNjr+N7o/NLVOucb/333TBR5Fja8ZklkVN+mJw8KcPS9O6Q QENeO8c1toYJucnXXWp/6PoJbjjXV+f4YOZngfopD08c3Xjc/5Gl7hKmiFS7hWaZgt6Zmgd0 pSfY3C9U3DXXfPXD5HT2b02sibrqtkwvze70t9bNfGdaUXz2xrWGffYP9x1pU2Ipzkg01GIu Kk4EAARQk2VGAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1JrWklmSyklGG0yicAJQeHnTc9A Cc: "kitten@ietf.org" , "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, 26 Nov 2014 02:36:33 -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-1983199521-1416877690=:19231 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Mon, 24 Nov 2014, Nico Williams wrote: > On Fri, Nov 21, 2014 at 08:46:04AM -0700, =E2=8C=98 Matt Miller wrote: > > 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. > > Comments: Thanks for the review. > - Section 2, nit: this should be a list with bullets. Sure; I think that was my intention, but my xmlrfc was rusty. > - Section 2, think there's no need to frame initial security context > tokens differently than others, except asynchronous (error, deletion) > context tokens, but the first and second list items give this > impression... Sure, I can see how that is misleading. I think I can just combine them into a single bullet point, % A way to frame and identify all context-level tokens, whether in the % initial context negotiation loop or subsequent traffic (e.g., error or % deletion tokens). > The node producing the error token doesn't know whether the peer > thinks the context is fully established, therefore the second item in > the list is... not workable. Well, in many cases is could; certain mechanisms only use a given number of tokens. But yes, in the general case the node can't know the peer's state, especially after your extra round trips stuff is done. > And whether an application needs to frame the initial security > context token differently from others is really dependent on the > application protocol. E.g., the initiator might need to say "I'm > starting the GSS login procedure", but for some protocols, such as > 'knc' the client just starts sending context tokens from the start, > with no special framing beyond the token length, so there's no > generic need. > > Proposed fix: > > OLD: > A way to frame and identify the initial context negotiation tokens > in the loop. > > A way to frame and identify subsequent context-level tokens (e.g., > error tokens) after a GSS_S_COMPLETE return. > > NEW: > A way to frame and identify security context negotiation tokens in > the loop. > > Error tokens should generally also get special framing, as the > recipient may have no other way to distinguish unexpected error > context tokens from per-message tokens. Hmm, I like your version better than mine (above). > - Section 2, the application protocol may need to provide something > like a "username" to authorize access to. (E.g., SSHv2 does.) (as the last item) % To facilitate those authorization checks, the application protocol may % need to provide a name of a resource to be accessed, e.g., as the SSHv2 % protocol passes a username. > OLD: > The application (not the protocol) should provide for > authorization checks in the acceptor. The GSS-API authenticates > the initiator, but does not make any claim about whether the > initiator is authorized for any given operation. In particular, > the initiator may be from a different portion of a federated > identity scheme. > > NEW: > The GSS-API provides for authentication of mechanism-specific > principals (which have names). Applications are responsible for > authorization of authenticated peer principal names. I don't think I like this text as-is, since it starts off with a generic statement about the GSS-API, not an application protocol requirement. How about turning it around, as % Applications are responsible for authorization of the authenticated peer % principal names which are supplied by the GSS-API. Such names are % mechanism-specific, and may come from a different portion of a federated % identity scheme. Application protocols may need to supply additional % information to support the authorization of access to a given resource, % such as the SSHv2 "username" parameter. > - Section 4.2, last para, should be "in particular" "mutual > authentication" and "replay protection" "are not available"... And > even "other services". (E.g., if/when we add a GSS_C_PFS_FLAG, that > may not be available at the same time as early PROT_READY.) Sure, that was one of the bits I was least confident about in the new content. """In particular, mutual authentication, replay protection, and other services (if requested) are services which will be active when GSS_S_COMPLETE is returned, but which are not necessarily active before the security context is fully established.""" I went back and looked at RFC 2743 to get the "will be active" wording (section 2.2.1, buried in the middle in the paragraph starting with "Not all of the optionally-requestable features". > - Section 4.3, second para, first sentence, nit: s/, but/; / I think this is the first paragraph, third sentence? I am fine with the change. > - Section 4.3 and section 7, add reference to erratum 4151 (which we > should revise with text like what I proposed today and do a consensus > call on to get it or acceptable alternatives accepted as a valid > erratum). I guess this will go in the third paragraph of section 4.3 ("GSS_Process_context_token() may indicate an error in its major_status field [...]"). I confess I'll need to look up how to cite a specific erratum, but agree it should be there. > - Section 6, Add text to the effect that "all security considerations > from RFCs 2743 and 2744 apply". Sure. I guess we should mention the security considerations of RFC 5653 as well, thought there does not seem to be anything especially relevant there. > - Section 6, last para, the last two sentences should probably be > swapped, or else in the next to last sentence s/existing > software/implementations protocols intended to produce a secure octet > stream/. I'm happy to swap the sentences. > And that's it for me. Most of the above are nits, really. With those > nits fixed this I-D will be ready to be published. Thanks! -Ben ---559023410-1983199521-1416877690=:19231-- From nobody Tue Nov 25 19:09:23 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 DAD7B1A1EE8 for ; Tue, 25 Nov 2014 19:09: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 MUOnm1yCQkT3 for ; Tue, 25 Nov 2014 19:09:21 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1298A1A1A14 for ; Tue, 25 Nov 2014 19:09:21 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id DB68ABBA065; Tue, 25 Nov 2014 19:09: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=O97AlFz7GWfOji 5HkPuzfSv+mmI=; b=MzUur576BT74B2MRBwo+5/nInW+nvUTDGhbzG5trUIWcsj cZ1qA/Lf/3HJQSthWB2kEJKqOnGcjFT0R8nAly7S7j+X8B7Pw7MiK4YZ8Xm2y3Dj X2+dwknd/c/lrnCutc/0XJNqSoP+DcxlPSIvwI2yRuvRIkm3gS1dbJm5hUm2E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 8904EBBA05F; Tue, 25 Nov 2014 19:09:20 -0800 (PST) Date: Tue, 25 Nov 2014 21:09:20 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141126030918.GZ3200@localhost> References: <546F5E3C.1010207@cisco.com> <20141124210942.GQ3200@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/llwTDkI8PAyGxsZyap4RvkMIqVY Cc: "kitten@ietf.org" , "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, 26 Nov 2014 03:09:22 -0000 On Tue, Nov 25, 2014 at 09:36:22PM -0500, Benjamin Kaduk wrote: > On Mon, 24 Nov 2014, Nico Williams wrote: > > [...] Excellent. I like all your suggestions. > > - Section 4.3, second para, first sentence, nit: s/, but/; / > > I think this is the first paragraph, third sentence? Oops, yes. > > - Section 6, Add text to the effect that "all security considerations > > from RFCs 2743 and 2744 apply". > > Sure. I guess we should mention the security considerations of RFC 5653 > as well, thought there does not seem to be anything especially relevant > there. RFC2744's sec cons apply because 2744 is not just the C bindings, but actually fills in some gaps in 2743 (e.g., channel bindings, though badly), and its security considerations text is generic. > Thanks! Thank you! This will be a very helpful RFC to have to point people to. Nico -- From nobody Tue Nov 25 19:32:26 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF51A8750 for ; Tue, 25 Nov 2014 19:32: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 8ib3sSPLzK_Y for ; Tue, 25 Nov 2014 19:32:23 -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 6EFDD1A8034 for ; Tue, 25 Nov 2014 19:32:23 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-dc-547549c6a7ed 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 81.71.03354.6C945745; Tue, 25 Nov 2014 22:32:22 -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 sAQ3WLXS024917; Tue, 25 Nov 2014 22:32:21 -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 sAQ3WJeK010602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Nov 2014 22:32:21 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAQ3WJiW029574; Tue, 25 Nov 2014 22:32:19 -0500 (EST) Date: Tue, 25 Nov 2014 22:32:19 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <320045518.928965.1416944720697.JavaMail.yahoo@jws10654.mail.bf1.yahoo.com> Message-ID: References: <320045518.928965.1416944720697.JavaMail.yahoo@jws10654.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-461650018-1416972739=:19231" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1j3mWRpicLdH0OLo5lUsFt+6rjM7 MHksWfKTyWPWrMNMAUxRXDYpqTmZZalF+nYJXBnTevpYC7rZKv51fGJtYPzN0sXIySEhYCLR dXQRM4QtJnHh3nq2LkYuDiGBxUwSi5s2MUE4Gxkl9l3/xgrhHGKSaD/+kRWkRUiggVHi8DQ3 EJtFQFtiyox3YGPZBFQkZr7ZCDSKg0NEQF2i+bs3SJhZQF7i2ZpusLAw0OaGMz4gYU6BCIlN fV2MIDavgKPEnAW7mUBKhATCJdpWWoKERQV0JFbvn8ICUSIocXLmExaIiQESP1b1sU1gFJyF JDULSQrCVpc48OkiI4StLXH/ZhvbAkaWVYyyKblVurmJmTnFqcm6xcmJeXmpRbomermZJXqp KaWbGMFBLcm/g/HbQaVDjAIcjEo8vAmKpSFCrIllxZW5hxglOZiURHk5gTEhxJeUn1KZkVic EV9UmpNafIhRgoNZSYRXggEox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivD waEkwbvDA6hRsCg1PbUiLTOnBCHNxMEJMpwHaPgpkBre4oLE3OLMdIj8KUZdjpamt71MQix5 +XmpUuK8t0CKBECKMkrz4ObAktErRnGgt4R534JU8QATGdykV0BLmICWxM0sBFlSkoiQkmpg VHh3agbjkmV+DNd9Z9vlGP7w9J+6f/bH729O+O78W3f7q+sL/xN37+hNKrE0+Zj6nTOE2WOe YU+lipDfYftbXtc3y7EEt/2xnZfYpH7risw9+f1sJUklc3t1VtxWOv1pV4HyiWlOdSLGMWdy DgbvXhr3LDjHX3VprPzRwyHXX20st2UzqWQrUWIpzkg01GIuKk4EAFRkDy8hAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FEujGiPi-7odbRHF2VXv85iT1Nk Cc: Kitten WG Subject: Re: [kitten] SASL/OAUTH WGLC one last time? 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, 26 Nov 2014 03:32:24 -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-461650018-1416972739=:19231 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 25 Nov 2014, Bill Mills wrote: > Just submitted draft -18 including the feedback from -17 both here and > from the OAUTH list.. =C2=A0If WGLC hasn't started once again is it time = yet? Thanks for the updates. The current plan is to WGLC sasl-oauth after the gss-loop WGLC finishes, which is on 5 December. We will probably leave a little bit of a gap between the two WGLC periods, but I don't expect it to be very long. -Ben ---559023410-461650018-1416972739=:19231-- From nobody Wed Nov 26 08:17:20 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 B56AB1A026A for ; Wed, 26 Nov 2014 08:17:17 -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 AdWuH9gbWb7S for ; Wed, 26 Nov 2014 08:17:17 -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 A444F1A037A for ; Wed, 26 Nov 2014 08:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1417018634; bh=KvE9xa3M20v2XDURbFIrDlctPfklQIRYAgGbmb7bj2E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=iv2crFVFYn++PQaIOvKe7xfxXHHlzrAVi5rthBzpJS/LwHNpNJYt1s/x8R1mAP1jEdP0U3Xl5Iqc/Bcyj4qgxUgW6fifmuiEFGBK0fqy+9oXE4YeSQrRfpwvAdFILDQPhaHNL3q5sbNuSVI11+ilBikEGqyLmaxQKyc6RQiGdOAYT6g7ZuzRIRQxrLmaP2z8tWUQxdi2xMRrxiUq3q0RBvtcQoDttHzMQiVdMEiVlFV4sqYnZxIT6/rMZ9OPciQxRL573L6qQ2wD/8Dd5eMUlZV/3fd8z+Tjsit7IyodmqXgp8rIjtCbb6wBuzv/FvdUohzRRRxqrSmuH3M52gzG4Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=KchpyUHXOKQfO+vwnK4VZ5d82f8k+9nZ2AJi+1tSTgNwPpDCcHkFckTMB1JTF8HTlzaPTFyvNrpl2I5gNOBCJ9SHsIh0qQw4npP2BnpCuj0BXJHN8xKmyL/I6KbatU9/tAWZPAqV6L2mTnThD6XVZnH5sUFrMLUSpT2c/kp/nQWSxEerjvH3TRJFJ4J5ri7bTkUlSlF65yd/9MjKeDMeD0cAFhbp+4iG2iVOARG4alzDq284LBpVBQ1fX9rKCoQhsSeQBkklVHkh33cP1VVPmUVk8iapqa2aNSfoc3mSFTbEzfb5kTzUvKiVbDTUx3diglAS64jKeFfN/pdkAtpxOw==; Received: from [98.139.212.149] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 26 Nov 2014 16:17:14 -0000 Received: from [98.139.215.253] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 26 Nov 2014 16:17:14 -0000 Received: from [127.0.0.1] by omp1066.mail.bf1.yahoo.com with NNFMP; 26 Nov 2014 16:17:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 898443.86942.bm@omp1066.mail.bf1.yahoo.com X-YMail-OSG: yMfiBDoVM1kXsSnr2LHrh44ZD.PfmokpxSj2aIFXNrpSvuo81LfNJA31WPoPYsd kL.hdKLTrnsEyGIkD9oFvwj4fYLQkIAz7H5X4dpPcNWvCXSKHzfCR7.URPirviHkmA3.0klekc9L PClsBl9.E.PYexARo0XxDu.hrm18O8VDY1MaOZIaYO_asN97h8sOcPlBq5JkcH3IjwQx_Kx9h6CK 1EoiPdGQIMGJMSpcZD2IPXwIm43uQKuHffzp8xei6Jo04SLvJ5BDmoOlmTmggiWztQ0WTVwWwGRi gCVzoJK7pOeRbtmYSZo_rYxK4QDPMS_ksyXdkPtMmFnr.Rsj3wqAMe_KZJxKr7_vjtFJYtm36MyG 8BBIu1TMFBJ9ZRDU.91QCCV6tJgWhs_i28oyGklmEoNwtluXTmLN36zaT6NyaNC1kZm3SmfXZWQI f2Re1VbiSekkHzCCk9tKFMLumB1xUbt5Yd2gH22FZ4OqRKCl7vpkXbmdgI_7fiD3Fp5QdEGUL Received: by 76.13.26.137; Wed, 26 Nov 2014 16:17:14 +0000 Date: Wed, 26 Nov 2014 16:17:14 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <474026736.1383818.1417018634167.JavaMail.yahoo@jws106125.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1383817_1296341232.1417018634164" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Spy6bFGrdJrkxIQKvXWczGtiMOA Cc: Kitten WG Subject: Re: [kitten] SASL/OAUTH WGLC one last time? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:17:17 -0000 ------=_Part_1383817_1296341232.1417018634164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, I didn't realize we single threaded them. =C2=A0OK.=20 On Tuesday, November 25, 2014 7:32 PM, Benjamin Kaduk = wrote: =20 On Tue, 25 Nov 2014, Bill Mills wrote: > Just submitted draft -18 including the feedback from -17 both here and > from the OAUTH list.. =C2=A0If WGLC hasn't started once again is it time = yet? Thanks for the updates. The current plan is to WGLC sasl-oauth after the gss-loop WGLC finishes, which is on 5 December.=C2=A0 We will probably leave a little bit of a gap between the two WGLC periods, but I don't expect it to be very long. -Ben ------=_Part_1383817_1296341232.1417018634164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, I didn't realize we single threade= d them.  OK.


<= div class=3D"yahoo_quoted" style=3D"display: block;">
On Tuesday, November 25, 2= 014 7:32 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
=

On Tue, 25 Nov 2014, Bill Mills w= rote:


> Just submitted draft -18 including the feedback from -1= 7 both here and
> from the OAUTH list..  If WGLC = hasn't started once again is it time yet?


Thanks for the updates.

The = current plan is to WGLC sasl-oauth after the gss-loop WGLC finishes,
which is on 5 December.  We will probably leave a little b= it of a gap
between the two WGLC periods, but I don't exp= ect it to be very long.

-Ben

------=_Part_1383817_1296341232.1417018634164-- From nobody Wed Nov 26 08:24:35 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0F1A0204 for ; Wed, 26 Nov 2014 08:24: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 13Iw2v3IKaIz for ; Wed, 26 Nov 2014 08:24:29 -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 EA1921A0195 for ; Wed, 26 Nov 2014 08:24:28 -0800 (PST) X-AuditID: 1209190f-f79716d000000d1a-f6-5475febb0c78 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 23.AD.03354.BBEF5745; Wed, 26 Nov 2014 11:24:27 -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 sAQGORwQ023429; Wed, 26 Nov 2014 11:24:27 -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 sAQGOOAk029488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Nov 2014 11:24:26 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAQGOOIF006432; Wed, 26 Nov 2014 11:24:24 -0500 (EST) Date: Wed, 26 Nov 2014 11:24:24 -0500 (EST) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <474026736.1383818.1417018634167.JavaMail.yahoo@jws106125.mail.bf1.yahoo.com> Message-ID: References: <474026736.1383818.1417018634167.JavaMail.yahoo@jws106125.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1768385551-1417019064=:19231" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hTV1t39rzTEYM9BC4ujm1exWHzrus7s wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGW8fv2MpWAza8XBJ3+ZGhj3snQxcnBICJhI 3PzF3sXICWSKSVy4t54NxBYSWMwk0bFcq4uRC8jeyChx+slJJgjnEJPEuTfzGSGcBkaJOdPe M4G0sAhoS2zpXs0CYrMJqEjMfLORDWSDiIC6RPN3b5Aws4C8xLM13WBhYaDFDWd8QMKcAlES jScvMILYvAKOEpNP3WeGGN/PKDF39V1mkISogI7E6v1TWCCKBCVOznwC9gCzQKDEw1W8ExgF ZyHJzELIzAJbrC5x4NNFRghbW+L+zTa2BYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIz S/RSU0o3MYJDWpJ/B+O3g0qHGAU4GJV4eBMUS0OEWBPLiitzDzFKcjApifJu/gkU4kvKT6nM SCzOiC8qzUktPsQowcGsJMLL8Q4ox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUI JivDwaEkwRv3F6hRsCg1PbUiLTOnBCHNxMEJMpwHaPhvkBre4oLE3OLMdIj8KUZdjpamt71M Qix5+XmpUuK8y0GKBECKMkrz4ObAUtErRnGgt4R5FYCJSYgHmMbgJr0CWsIEtERsKtiSkkSE lFQDo93HLcXl0gen/2iOtlreaJzOuuuqhWX63K72tbtM1NK8Oj6LXjP8euXBwb+WnIxGWT09 6tujmh25Fr5kP3GTP+/S6iM2M3L7yvgunN35RaJzbdyX7eus+wWfGicq6dvU7Ej7qG/veH0V 9+74vRVtB/7MPSjMNk+kZ/GS0rLLUSUHshx0tp/bqcRSnJFoqMVcVJwIAOb7w2ggAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/V0s6_5_-Bjqpj5UsK3oag3jSiu8 Cc: Kitten WG Subject: Re: [kitten] SASL/OAUTH WGLC one last time? 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, 26 Nov 2014 16:24:33 -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-1768385551-1417019064=:19231 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 26 Nov 2014, Bill Mills wrote: > Ah, I didn't realize we single threaded them. =C2=A0OK. There's no rule that we have to single-thread them. Given that we sometimes have low energy in the WG, it seems that trying to do things in parallel risks burnout for contributors, so we've been adopting the single-threading as a goal, recently. -Ben ---559023410-1768385551-1417019064=:19231-- From nobody Wed Nov 26 12:17:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03611A1B3B for ; Wed, 26 Nov 2014 12:17:09 -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 oEBYNKxX_ur6 for ; Wed, 26 Nov 2014 12:17:08 -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 114311A19ED for ; Wed, 26 Nov 2014 12:17:07 -0800 (PST) X-AuditID: 12074423-f79b86d000000cf5-61-547635421479 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id DB.65.03317.24536745; Wed, 26 Nov 2014 15:17:06 -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 sAQKH55H017465; Wed, 26 Nov 2014 15:17:06 -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 sAQKH3aM010460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Nov 2014 15:17:05 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sAQKH3hH005524; Wed, 26 Nov 2014 15:17:03 -0500 (EST) Date: Wed, 26 Nov 2014 15:17:02 -0500 (EST) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <20141125142041.7dbeba25@willson.usersys.redhat.com> Message-ID: References: <5473DCAA.7010604@cs.tcd.ie> <20141125142041.7dbeba25@willson.usersys.redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrOtkWhZicGOticXRzatYLH7MXcRq MX3vNXYHZo+13VfZPJYs+cnk8X7fVbYA5igum5TUnMyy1CJ9uwSujFNP1jMVfOevWNM/h62B 8Q5PFyMHh4SAicT0yVFdjJxAppjEhXvr2UBsIYHFTBJbHwl0MXIB2RsZJZ7PnckO4Rxikrj7 +QobhNPAKNGy6SgTSAuLgLZE38vvrCA2m4CKxMw3G8FGiQjoS+zdfI4dZBuzgKvEpOuiIGFh AWuJSZOfMYLYnAKOEhsa/7KA2LxA9vIXfSwQV8RKPPx8nR3EFhXQkVi9fwpUjaDEyZlPwGxm AS2J5dO3sUxgFJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2M oNBld1HewfjnoNIhRgEORiUe3gip0hAh1sSy4srcQ4ySHExKorw2JmUhQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4A6WAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxK Erw3jIEaBYtS01Mr0jJzShDSTBycIMN5gIb/BKnhLS5IzC3OTIfIn2JUlBKHSAiAJDJK8+B6 YanlFaM40CvCvPdAqniAaQmu+xXQYCagwWJTS0EGlyQipKQaGEu61rlNUddc8UKqMf0T13L7 5NllS70/zX6t+CjabfWre3t+unzMTnrwzcxglcTBMzyndlyq8m9/pXWoekKYrdeO6Bz5iOlr OIKML/Z2l0VcjbANW3jr/lLZtVVn1udufqrXqb2g5HnDU5PWq2sU1a10f7rIitT8faB9Yb3V rJn/nrq+v8Y3m12JpTgj0VCLuag4EQC4b/PsCAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kfU8scZDybLuDMwQfSV3ONfexoY Cc: "kitten@ietf.org" , Simo Sorce Subject: Re: [kitten] AD review of draft-ietf-kitten-cammac 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, 26 Nov 2014 20:17:10 -0000 On Tue, 25 Nov 2014, Simo Sorce wrote: > On Tue, 25 Nov 2014 01:34:34 +0000 > Stephen Farrell wrote: > > > - I had to read section 3 twice, though it has been ages since I > > delved into Kerberos detail. I think a diagram might help many > > readers, but am fine if you think implementers wouldn't need that. > > I am quite biased, as an author, as I've been working through the > details so much they are quite familiar to me. That said I think an > implementer should find the descriptions clear enough that there are > no ambiguities or difficulties in determining the meaning of the text. To add a slightly less biased opinion (though as shepherd, I'm still quite familiar with the document), I reread section 3 just now, and don't see anything where a diagram would substantially help an implementor who is already familiar with the AD-KDC-ISSUED container. > > - the conditions in section 8 for when it's ok to create a new CAMMAC > > without verifying the old are not very clear to this reader but do > > look ok. Would a bit of pseudo-code help maybe? > > I am not sure pseudo-code is really needed, if an implementer really > has doubts he can simply always attach all required signatures and > always verify them, there is never a case where a party would fail > because everything is in place :) Well, the KDC should always verify any signatures which are present on the old CAMMAC. Simo is right that always putting in all the signatures will always be fine. The two exceptions boil down to (1) when the target service of the ticket is the KDC itself, so the kdc-verifier and svc-verifier are redundant, and (2) the CAMMAC is being used where AD-KDC-ISSUED would have been sufficient, in which case omitting the kdc-verifier brings the security properties in line with those of AD-KDC-ISSUED. I think it's easier to just state those two cases than try to represent them in pseudocode, which would probably not actually be more clear than text. -Ben