From kitten-bounces@ietf.org Mon Aug 4 12:21:16 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CF23A6AE5; Mon, 4 Aug 2008 12:21:16 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC693A68A3 for ; Mon, 4 Aug 2008 12:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.667 X-Spam-Level: X-Spam-Status: No, score=-4.667 tagged_above=-999 required=5 tests=[AWL=1.379, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e47vMLlFR6u for ; Mon, 4 Aug 2008 12:21:14 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id B997C3A6AE5 for ; Mon, 4 Aug 2008 12:21:14 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m74JLhwT026992 for ; Mon, 4 Aug 2008 19:21:43 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5300001C1I4T00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for kitten@ietf.org; Mon, 04 Aug 2008 13:21:43 -0600 (MDT) Received: from [10.0.0.5] ([129.150.36.110]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5300DD9CG6EN80@mail-amer.sun.com> for kitten@ietf.org; Mon, 04 Aug 2008 13:21:43 -0600 (MDT) Date: Mon, 04 Aug 2008 13:19:50 -0600 From: "Shawn M. Emery" Subject: NegoEx Feed-back Requested To: kitten@ietf.org Message-id: <48975656.6000400@sun.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Looking feed-back from Larry's individual submission on Extended GSS-API Negotiation Mechanism, that he presented in Dublin: http://tools.ietf.org/html/draft-zhu-negoex-01 Slides presented can be found here: http://www3.ietf.org/proceedings/08jul/slides/kitten-2.pdf We were running out of time for our one hour slot during the session and the chairs wanted to continue the discussion on the list, if needed. Chairs, Alexey and Shawn. -- _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Sat Aug 9 16:27:43 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618D428C0E3; Sat, 9 Aug 2008 16:27:43 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F453A67DD for ; Sat, 9 Aug 2008 16:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymry6e4g+yjW for ; Sat, 9 Aug 2008 16:27:41 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id B9F113A67D9 for ; Sat, 9 Aug 2008 16:27:41 -0700 (PDT) Received: from proton.foo.net (pool-96-242-53-186.nwrknj.fios.verizon.net [96.242.53.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id B7C1C40C16; Sat, 9 Aug 2008 19:27:41 -0400 (EDT) Date: Sat, 9 Aug 2008 19:27:40 -0400 From: Michael B Allen To: "Shawn M. Emery" Subject: Re: NegoEx Feed-back Requested Message-Id: <20080809192740.2d907f01.miallen@ioplex.com> In-Reply-To: <48975656.6000400@sun.com> References: <48975656.6000400@sun.com> Organization: IOPLEX Software X-Mailer: Sylpheed 2.5.0rc2 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Mon, 04 Aug 2008 13:19:50 -0600 "Shawn M. Emery" wrote: > > Looking feed-back from Larry's individual submission on Extended GSS-API > Negotiation Mechanism, that he presented in Dublin: > > http://tools.ietf.org/html/draft-zhu-negoex-01 What advantage does using explicitly encoded little-endian blobs have over the much more common DER? Mike _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Aug 13 07:28:52 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4E93A69B3; Wed, 13 Aug 2008 07:28:52 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE933A68A1 for ; Wed, 13 Aug 2008 07:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBlSxgytU91Q for ; Wed, 13 Aug 2008 07:28:50 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 1FF553A6939 for ; Wed, 13 Aug 2008 07:28:50 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AD37541EF; Wed, 13 Aug 2008 10:28:16 -0400 (EDT) From: Sam Hartman To: "Shawn M. Emery" Subject: Re: NegoEx Feed-back Requested References: <48975656.6000400@sun.com> Date: Wed, 13 Aug 2008 10:28:16 -0400 In-Reply-To: <48975656.6000400@sun.com> (Shawn M. Emery's message of "Mon, 04 Aug 2008 13:19:50 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org I think that having a standards track mechanism in this space would be a good idea. My main objection based on the presentation is that I think the negotiation key and use of RFC 3961 is an unnecessary abstraction violation. I think that gss_getmic or gss_wrap would be better. I do agree that you'll have to carefully think about prot_ready implications. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 18 07:03:26 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF1D3A6AE4; Mon, 18 Aug 2008 07:03:26 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2E83A6CB5 for ; Mon, 18 Aug 2008 06:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_40=-0.185, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn2OS4sSxSC5 for ; Mon, 18 Aug 2008 06:44:55 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id DD03B3A6CB0 for ; Mon, 18 Aug 2008 06:44:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id AD9F01558A8 for ; Mon, 18 Aug 2008 15:44:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WeDApIHN7X76 for ; Mon, 18 Aug 2008 15:44:25 +0200 (CEST) Received: from [192.168.1.87] (unknown [85.134.181.23]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 363BE1557E0 for ; Mon, 18 Aug 2008 15:44:25 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Subject: draft-lha-gssapi-delegate-policy-00.txt Date: Mon, 18 Aug 2008 14:44:15 +0100 X-Mailer: Apple Mail (2.928.1) X-Mailman-Approved-At: Mon, 18 Aug 2008 07:03:24 -0700 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Hello, I would like to propose the following work to be taken up in the working group http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate- policy-00.txt Abstract Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers as well as CIFs file servers. However, delegating the ability to act as a user to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS- DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). Love _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 18 10:43:16 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92B63A68F9; Mon, 18 Aug 2008 10:43:16 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DA93A6882 for ; Mon, 18 Aug 2008 10:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJzAzwVbeODb for ; Mon, 18 Aug 2008 10:43:14 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id BFE733A67A8 for ; Mon, 18 Aug 2008 10:43:14 -0700 (PDT) Received: from proton.foo.net (pool-96-242-53-186.nwrknj.fios.verizon.net [96.242.53.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id AAF623FCF2; Mon, 18 Aug 2008 13:43:20 -0400 (EDT) Date: Mon, 18 Aug 2008 13:43:16 -0400 From: Michael B Allen To: Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: draft-lha-gssapi-delegate-policy-00.txt Message-Id: <20080818134316.28205879.miallen@ioplex.com> In-Reply-To: References: Organization: IOPLEX Software X-Mailer: Sylpheed 2.5.0rc2 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Mon, 18 Aug 2008 14:44:15 +0100 Love H=F6rnquist =C5strand wrote: > Hello, > = > I would like to propose the following work to be taken up in the > working group > = > http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-policy-00.t= xt I would much prefer that clients respect the policy first and only deviate from that behavior unless specifically instructed (e.g. GSS_C_DELEG_IGNORE_POLICY_FLAG). I realize this would be a change in behavior for existing code but I think network admins would welcome it. A violation of The Principal of Least Surprise is not a sufficient reason for perpetuating a weak default security policy. To maintain the old behavior, there could be a setting in krb5.conf like: [libdefaults] gssapi_deleg_ingore_policy =3D true; This property would also be useful for clients who's KDCs do not support OK-AS-DELEGATE. Again, of course the default value for this property should be false to indicate OK-AS-DELEGATE should be respected first unless specifically instructed otherwise. Mike -- = Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 18 13:40:24 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765F53A6D83; Mon, 18 Aug 2008 13:40:24 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B323A6D83 for ; Mon, 18 Aug 2008 13:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTI1-2vhqOmf for ; Mon, 18 Aug 2008 13:40:23 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 02BD33A6B6F for ; Mon, 18 Aug 2008 13:40:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 2E1411560C7; Mon, 18 Aug 2008 22:39:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Pz-KrJtqDl8G; Mon, 18 Aug 2008 22:39:56 +0200 (CEST) Received: from [192.168.1.87] (unknown [85.134.181.23]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 70B6415589B; Mon, 18 Aug 2008 22:39:55 +0200 (CEST) In-Reply-To: <20080818134316.28205879.miallen@ioplex.com> References: <20080818134316.28205879.miallen@ioplex.com> From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Mime-Version: 1.0 (Apple Message framework v1023) To: Michael B Allen Message-Id: Date: Mon, 18 Aug 2008 21:39:52 +0100 Subject: Re: draft-lha-gssapi-delegate-policy-00.txt X-Mailer: Apple Mail (2.1023) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org 18 aug 2008 kl. 18.43 skrev Michael B Allen: > On Mon, 18 Aug 2008 14:44:15 +0100 > Love H=F6rnquist =C5strand wrote: > >> Hello, >> >> I would like to propose the following work to be taken up in the >> working group >> >> http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-policy-00.= txt > > I would much prefer that clients respect the policy first and > only deviate from that behavior unless specifically instructed > (e.g. GSS_C_DELEG_IGNORE_POLICY_FLAG). Yes, I think that would be preferable, but this idea meets much resistance when I propose it. IMO think its a better idea to actually do something else about then fight about already existing semantics. Love _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 18 15:12:38 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BD43A6B88; Mon, 18 Aug 2008 15:12:38 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4C33A6A24 for ; Mon, 18 Aug 2008 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6iQafbu7Q1n for ; Mon, 18 Aug 2008 15:12:35 -0700 (PDT) Received: from lists.samba.org (mail.samba.org [66.70.73.150]) by core3.amsl.com (Postfix) with ESMTP id D30473A6833 for ; Mon, 18 Aug 2008 15:12:35 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 639D2163953; Mon, 18 Aug 2008 22:12:38 +0000 (GMT) Subject: Re: draft-lha-gssapi-delegate-policy-00.txt From: Andrew Bartlett To: Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= In-Reply-To: References: <20080818134316.28205879.miallen@ioplex.com> Date: Tue, 19 Aug 2008 08:12:38 +1000 Message-Id: <1219097558.3826.0.camel@naomi.s4.naomi.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515840955==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org --===============1515840955== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qFPcstIJBOb7Psvycj1f" --=-qFPcstIJBOb7Psvycj1f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 2008-08-18 at 21:39 +0100, Love H=C3=B6rnquist =C3=85strand wrote: > 18 aug 2008 kl. 18.43 skrev Michael B Allen: >=20 > > On Mon, 18 Aug 2008 14:44:15 +0100 > > Love H=C3=B6rnquist =C3=85strand wrote: > > > >> Hello, > >> > >> I would like to propose the following work to be taken up in the > >> working group > >> > >> http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-policy-0= 0.txt > > > > I would much prefer that clients respect the policy first and > > only deviate from that behavior unless specifically instructed > > (e.g. GSS_C_DELEG_IGNORE_POLICY_FLAG). >=20 > Yes, I think that would be preferable, but this idea meets much > resistance when I propose it. IMO think its a better idea to actually do > something else about then fight about already existing semantics. Except they are only existing semantics on Unix, not windows, which is the majority of krb5 clients these days. Can we try it one more time? --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-qFPcstIJBOb7Psvycj1f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIqfPNz4A8Wyi0NrsRAodEAKCFh0G/7zAUef7F0NcxSJfSgjh35ACeIDMs pkp0O77UKE5LT0lGDXYQMDQ= =GCNZ -----END PGP SIGNATURE----- --=-qFPcstIJBOb7Psvycj1f-- --===============1515840955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten --===============1515840955==-- From kitten-bounces@ietf.org Mon Aug 18 15:25:13 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954293A6983; Mon, 18 Aug 2008 15:25:13 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430A03A6765 for ; Mon, 18 Aug 2008 15:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OjMc5lb-ZhH for ; Mon, 18 Aug 2008 15:25:11 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 375F528C157 for ; Mon, 18 Aug 2008 15:25:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id B083714DC58; Tue, 19 Aug 2008 00:24:47 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4-po-sE9fnrs; Tue, 19 Aug 2008 00:24:41 +0200 (CEST) Received: from [192.168.1.87] (unknown [85.134.181.23]) by smtp-2.sys.kth.se (Postfix) with ESMTP id C84E214DC50; Tue, 19 Aug 2008 00:24:39 +0200 (CEST) In-Reply-To: <1219097558.3826.0.camel@naomi.s4.naomi.abartlet.net> References: <20080818134316.28205879.miallen@ioplex.com> <1219097558.3826.0.camel@naomi.s4.naomi.abartlet.net> From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Mime-Version: 1.0 (Apple Message framework v1023) To: Andrew Bartlett Message-Id: <071ED659-35BB-48FF-A44D-0BF1AAF2B21D@kth.se> Date: Mon, 18 Aug 2008 23:24:33 +0100 Subject: Re: draft-lha-gssapi-delegate-policy-00.txt X-Mailer: Apple Mail (2.1023) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org >> Yes, I think that would be preferable, but this idea meets much >> resistance when I propose it. IMO think its a better idea to >> actually do >> something else about then fight about already existing semantics. > > Except they are only existing semantics on Unix, not windows, which is > the majority of krb5 clients these days. Can we try it one more time? Its not the semantics for Unix, its the semantics for GSS-API. You are talking about the semantics for SSPI/Kerberos. The new flag gives the same semantics that the SSPI flag. We don't get around that changing the flag break stuff. With MIT kerberos you can't set the flag in the KDB w/o redeploying code, these are the people you need to convince this is a good idea. Love _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 18 18:37:32 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7013A68BC; Mon, 18 Aug 2008 18:37:32 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7613F3A68BC for ; Mon, 18 Aug 2008 18:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMVwKpD8Hzzi for ; Mon, 18 Aug 2008 18:37:30 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 856673A6878 for ; Mon, 18 Aug 2008 18:37:30 -0700 (PDT) Received: from proton.foo.net (pool-96-242-53-186.nwrknj.fios.verizon.net [96.242.53.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id EB7CE3FCF2; Mon, 18 Aug 2008 21:37:15 -0400 (EDT) Date: Mon, 18 Aug 2008 21:37:12 -0400 From: Michael B Allen To: Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: draft-lha-gssapi-delegate-policy-00.txt Message-Id: <20080818213712.00ba289c.miallen@ioplex.com> In-Reply-To: <071ED659-35BB-48FF-A44D-0BF1AAF2B21D@kth.se> References: <20080818134316.28205879.miallen@ioplex.com> <1219097558.3826.0.camel@naomi.s4.naomi.abartlet.net> <071ED659-35BB-48FF-A44D-0BF1AAF2B21D@kth.se> Organization: IOPLEX Software X-Mailer: Sylpheed 2.5.0rc2 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Mon, 18 Aug 2008 23:24:33 +0100 Love H=F6rnquist =C5strand wrote: > With MIT kerberos you can't set the flag in the KDB w/o redeploying > code, these are the people you need to convince this is a good idea. The OK-AS-DELEGATE flag issue with legacy KDCs is a Kerberos issue and should not be addressed by pushing the problem into GSSAPI. Mike -- = Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 07:53:25 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6783A68D3; Mon, 25 Aug 2008 07:53:25 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFE13A6CF6 for ; Mon, 25 Aug 2008 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6-KPobuRlYH for ; Mon, 25 Aug 2008 07:53:23 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id C4D213A6A64 for ; Mon, 25 Aug 2008 07:53:22 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m7PEpbGm011939; Mon, 25 Aug 2008 10:51:37 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m7PEpXgD028698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Aug 2008 10:51:33 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m7PEpXgn008174; Mon, 25 Aug 2008 10:51:33 -0400 (EDT) To: Michael B Allen Subject: Re: draft-lha-gssapi-delegate-policy-00.txt References: <20080818134316.28205879.miallen@ioplex.com> <1219097558.3826.0.camel@naomi.s4.naomi.abartlet.net> <071ED659-35BB-48FF-A44D-0BF1AAF2B21D@kth.se> <20080818213712.00ba289c.miallen@ioplex.com> From: Tom Yu Date: Mon, 25 Aug 2008 10:51:32 -0400 In-Reply-To: <20080818213712.00ba289c.miallen@ioplex.com> (Michael B. Allen's message of "Mon, 18 Aug 2008 21:37:12 -0400") Message-ID: Lines: 14 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Michael B Allen writes: > On Mon, 18 Aug 2008 23:24:33 +0100 > Love H=F6rnquist =C5strand wrote: > >> With MIT kerberos you can't set the flag in the KDB w/o redeploying >> code, these are the people you need to convince this is a good idea. > > The OK-AS-DELEGATE flag issue with legacy KDCs is a Kerberos issue and > should not be addressed by pushing the problem into GSSAPI. While OK-AS-DELEGATE may be a Kerberos-specific issue, the problem of finer-grained control over credential delegation is a general GSS-API problem. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 08:10:19 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D52F3A6884; Mon, 25 Aug 2008 08:10:19 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B383A681D for ; Mon, 25 Aug 2008 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2cxlqzC87sd for ; Mon, 25 Aug 2008 08:10:16 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 9AC4828C3E6 for ; Mon, 25 Aug 2008 08:10:16 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m7PF9NOf025783; Mon, 25 Aug 2008 11:09:37 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m7PF2DVD003189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Aug 2008 11:02:13 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m7PF2Cw2008219; Mon, 25 Aug 2008 11:02:12 -0400 (EDT) To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: draft-lha-gssapi-delegate-policy-00.txt References: From: Tom Yu Date: Mon, 25 Aug 2008 11:02:12 -0400 In-Reply-To: (Love =?iso-8859-1?Q?H=F6rnquist_=C5strand's?= message of "Mon, 18 Aug 2008 14:44:15 +0100") Message-ID: Lines: 8 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org * I see no explicit mention, but is GSS_C_DELEG_POLICY_FLAG ever to be set by accept_sec_context? * The new flag GSS_C_DELEG_POLICY_FLAG appears to request delegation regardless of whether GSS_C_DELEG_FLAG is set, and setting GSS_C_DELEG_FLAG in combination with GSS_C_DELEG_POLICY_FLAG appears to request an override of centrally administered policy. This is a somewhat non-obvious behavior. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 09:02:01 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366EE28C3F1; Mon, 25 Aug 2008 09:02:01 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEC63A6BF8 for ; Mon, 25 Aug 2008 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drHOJcUfT-CS for ; Mon, 25 Aug 2008 09:01:59 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id C13D628C7B5 for ; Mon, 25 Aug 2008 08:58:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 3E2411558A4; Mon, 25 Aug 2008 17:38:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m-m170jueA6f; Mon, 25 Aug 2008 17:38:00 +0200 (CEST) Received: from [192.168.1.87] (unknown [85.134.181.23]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 60C52155870; Mon, 25 Aug 2008 17:38:00 +0200 (CEST) In-Reply-To: References: From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Mime-Version: 1.0 (Apple Message framework v1023) To: Tom Yu Message-Id: <2D7ECF1F-7C8B-4E2F-A08E-7B7B16EFC275@kth.se> Date: Mon, 25 Aug 2008 16:37:58 +0100 Subject: Re: draft-lha-gssapi-delegate-policy-00.txt X-Mailer: Apple Mail (2.1023) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org 25 aug 2008 kl. 16.02 skrev Tom Yu: > * I see no explicit mention, but is GSS_C_DELEG_POLICY_FLAG ever to be > set by accept_sec_context? Does it matter to the server if delegation was allows by policy or not ? I think GSS_C_DELEG_POLICY_FLAG should never seen on wire, but I really dont care too much about this, either way is fine. > * The new flag GSS_C_DELEG_POLICY_FLAG appears to request delegation > regardless of whether GSS_C_DELEG_FLAG is set, and setting > GSS_C_DELEG_FLAG in combination with GSS_C_DELEG_POLICY_FLAG appears > to request an override of centrally administered policy. This is a > somewhat non-obvious behavior. It preserves the old behavior of the GSS_C_DELEG_FLAG. 0 - no delegate DELEG - always delegate DELEG_POLICY - delegate if policy allows DELEG | DELEG_POLICY - always delegate, but do tell client if it was allowed by policy. So a client that want to follow the policy of the site, can always specify DELEG_POLICY Love _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 09:10:38 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69133A681B; Mon, 25 Aug 2008 09:10:38 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732B43A6823 for ; Mon, 25 Aug 2008 09:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tN1-UfQ+E+Z for ; Mon, 25 Aug 2008 09:09:57 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 4AEE03A69DA for ; Mon, 25 Aug 2008 09:08:09 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m7PG7GS3008953; Mon, 25 Aug 2008 12:07:17 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m7PG7EGL000919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Aug 2008 12:07:16 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m7PG7ETa009339; Mon, 25 Aug 2008 12:07:14 -0400 (EDT) To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: draft-lha-gssapi-delegate-policy-00.txt References: <2D7ECF1F-7C8B-4E2F-A08E-7B7B16EFC275@kth.se> From: Tom Yu Date: Mon, 25 Aug 2008 12:07:14 -0400 In-Reply-To: <2D7ECF1F-7C8B-4E2F-A08E-7B7B16EFC275@kth.se> (Love =?iso-8859-1?Q?H=F6rnquist_=C5strand's?= message of "Mon, 25 Aug 2008 16:37:58 +0100") Message-ID: Lines: 52 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Love H=F6rnquist =C5strand writes: > 25 aug 2008 kl. 16.02 skrev Tom Yu: > >> * I see no explicit mention, but is GSS_C_DELEG_POLICY_FLAG ever to be >> set by accept_sec_context? > > Does it matter to the server if delegation was allows by policy or not ? > > I think GSS_C_DELEG_POLICY_FLAG should never seen on wire, but I > really dont care too much about this, either way is fine. I also don't care too much either way, but since flags can get output on the acceptor side, I think we should explicitly mention what happens. >> * The new flag GSS_C_DELEG_POLICY_FLAG appears to request delegation >> regardless of whether GSS_C_DELEG_FLAG is set, and setting >> GSS_C_DELEG_FLAG in combination with GSS_C_DELEG_POLICY_FLAG appears >> to request an override of centrally administered policy. This is a >> somewhat non-obvious behavior. > > > It preserves the old behavior of the GSS_C_DELEG_FLAG. > > 0 - no delegate > DELEG - always delegate RFC2743 and RFC2744 are not so clear on the "always delegate"; they indicate that the DELEG_FLAG is a request. It is possible to read the RFCs as allowing an implementation to apply policy and cause init_sec_context to decline the delegation request. In such a case, DELEG_POLICY_FLAG is not sufficient to allow the application to override policy. I suggest that we provide an additional flag to allow applications to override a centrally administered policy prohibiting delegation. > DELEG_POLICY - delegate if policy allows If this is set without DELEG_FLAG being set, then no delegation takes place if the implementation does not understand DELEG_POLICY_FLAG. This is probably desired. > DELEG | DELEG_POLICY - always delegate, but do tell client if it was > allowed by policy. > > So a client that want to follow the policy of the site, can always > specify DELEG_POLICY Unless the client assumes an implementation where setting DELEG_FLAG alone requests "delegate if permitted by policy". _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 09:37:57 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012BB3A6976; Mon, 25 Aug 2008 09:37:57 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902C13A6976 for ; Mon, 25 Aug 2008 09:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcNUgAxxmUqG for ; Mon, 25 Aug 2008 09:37:54 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 8CA823A67AE for ; Mon, 25 Aug 2008 09:37:54 -0700 (PDT) Received: from proton.foo.net (pool-96-242-53-186.nwrknj.fios.verizon.net [96.242.53.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 405A23FD05; Mon, 25 Aug 2008 12:37:17 -0400 (EDT) Date: Mon, 25 Aug 2008 12:37:14 -0400 From: Michael B Allen To: Tom Yu Subject: Re: draft-lha-gssapi-delegate-policy-00.txt Message-Id: <20080825123714.040bcfc8.miallen@ioplex.com> In-Reply-To: References: <20080818134316.28205879.miallen@ioplex.com> <1219097558.3826.0.camel@naomi.s4.naomi.abartlet.net> <071ED659-35BB-48FF-A44D-0BF1AAF2B21D@kth.se> <20080818213712.00ba289c.miallen@ioplex.com> Organization: IOPLEX Software X-Mailer: Sylpheed 2.5.0rc2 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Mon, 25 Aug 2008 10:51:32 -0400 Tom Yu wrote: > Michael B Allen writes: > = > > On Mon, 18 Aug 2008 23:24:33 +0100 > > Love H=F6rnquist =C5strand wrote: > > > >> With MIT kerberos you can't set the flag in the KDB w/o redeploying > >> code, these are the people you need to convince this is a good idea. > > > > The OK-AS-DELEGATE flag issue with legacy KDCs is a Kerberos issue and > > should not be addressed by pushing the problem into GSSAPI. > = > While OK-AS-DELEGATE may be a Kerberos-specific issue, the problem of > finer-grained control over credential delegation is a general GSS-API > problem. Tom, I did not say OK-AS-DELEGATE is an issue. I said legacy KDCs that do not understand OK-AS-DELEGATE are an issue. If there were no such KDCs, clearly GSS_C_DELEG_POLICY_FLAG would not have been proposed. If you want finer-grained control over delegation, then use a GSS_C_DELEG_IGNORE_POLICY_FLAG to accomplish what you want (but I think it would be a lot cleaner to use a "gssapi_deleg_ignore_policy" property in the client's krb5.conf to maintain old behavior). I don't think any of this has any effect on my code so this will be the last you hear from me on the topic. But I just have to say, I don't like to see insecure default security policy being proposed as an IETF standard because a handful of admins are too lazy to add a setting to their client krb5.confs. Now whenever someone posts their GSSAPI example on the kerberos mailing list, someone will have to chime in with "oh, by the way you have to set the GSS_C_DELEG_POLICY_FLAG too" and then get gaffed explaining why. Mike -- = Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 10:29:48 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C3728C25C; Mon, 25 Aug 2008 10:29:48 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FE828C259 for ; Mon, 25 Aug 2008 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA5Rh4CccaJn for ; Mon, 25 Aug 2008 10:29:45 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 01D8828C254 for ; Mon, 25 Aug 2008 10:29:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 8ECDA1551FC; Mon, 25 Aug 2008 19:28:52 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GgPDeoDebxhZ; Mon, 25 Aug 2008 19:28:45 +0200 (CEST) Received: from [192.168.1.87] (unknown [85.134.181.23]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 659BE154137; Mon, 25 Aug 2008 19:28:43 +0200 (CEST) In-Reply-To: References: <2D7ECF1F-7C8B-4E2F-A08E-7B7B16EFC275@kth.se> From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Mime-Version: 1.0 (Apple Message framework v1023) To: Tom Yu Message-Id: <13441294-8DB4-4421-9404-F84D9362D64E@kth.se> Date: Mon, 25 Aug 2008 18:28:40 +0100 Subject: Re: draft-lha-gssapi-delegate-policy-00.txt X-Mailer: Apple Mail (2.1023) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org 25 aug 2008 kl. 17.07 skrev Tom Yu: > Love H=F6rnquist =C5strand writes: > >> 25 aug 2008 kl. 16.02 skrev Tom Yu: >> >>> * I see no explicit mention, but is GSS_C_DELEG_POLICY_FLAG ever = >>> to be >>> set by accept_sec_context? >> >> Does it matter to the server if delegation was allows by policy or = >> not ? >> >> I think GSS_C_DELEG_POLICY_FLAG should never seen on wire, but I >> really dont care too much about this, either way is fine. > > I also don't care too much either way, but since flags can get output > on the acceptor side, I think we should explicitly mention what > happens. ok, will do. >>> * The new flag GSS_C_DELEG_POLICY_FLAG appears to request delegation >>> regardless of whether GSS_C_DELEG_FLAG is set, and setting >>> GSS_C_DELEG_FLAG in combination with GSS_C_DELEG_POLICY_FLAG appears >>> to request an override of centrally administered policy. This is a >>> somewhat non-obvious behavior. >> >> >> It preserves the old behavior of the GSS_C_DELEG_FLAG. >> >> 0 - no delegate >> DELEG - always delegate > > RFC2743 and RFC2744 are not so clear on the "always delegate"; they > indicate that the DELEG_FLAG is a request. It is possible to read the > RFCs as allowing an implementation to apply policy and cause > init_sec_context to decline the delegation request. In such a case, > DELEG_POLICY_FLAG is not sufficient to allow the application to > override policy. But that is not how some of people that made implementation for = kerberos have read it.' If it is how you say, then we don't need DELEG_POLICY_FLAG. And are = all done. If you change your implementation to behave like that, how far would = you make it down the Vassar street before some disgruntal sysadmin = catches you with a bat ? > I suggest that we provide an additional flag to allow applications to > override a centrally administered policy prohibiting delegation. I would say that that is DELEG_FLAG flag. I think its a bad idea to = introduce even more flags and knobs. >> DELEG_POLICY - delegate if policy allows > > If this is set without DELEG_FLAG being set, then no delegation takes > place if the implementation does not understand DELEG_POLICY_FLAG. > This is probably desired. > >> DELEG | DELEG_POLICY - always delegate, but do tell client if it was >> allowed by policy. >> >> So a client that want to follow the policy of the site, can always >> specify DELEG_POLICY > > Unless the client assumes an implementation where setting DELEG_FLAG > alone requests "delegate if permitted by policy". Right, any implementation like that except SSPI ? Love _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Aug 25 11:10:08 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9ED28CC3B; Mon, 25 Aug 2008 11:10:08 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F5D3A6B43 for ; Mon, 25 Aug 2008 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sOLVwBPDhCt for ; Mon, 25 Aug 2008 11:10:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F291E3A6B27 for ; Mon, 25 Aug 2008 11:10:02 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id m7PI85sW016107; Mon, 25 Aug 2008 20:08:06 +0200 (MEST) From: Martin Rex Message-Id: <200808251807.m7PI7x8U029967@fs4113.wdf.sap.corp> Subject: Re: draft-lha-gssapi-delegate-policy-00.txt To: tlyu@MIT.EDU (Tom Yu) Date: Mon, 25 Aug 2008 20:07:59 +0200 (MEST) In-Reply-To: from "Tom Yu" at Aug 25, 8 12:07:14 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Tom Yu wrote: > = > Love H=F6rnquist =C5strand writes: > > > > Does it matter to the server if delegation was allows by policy or not ? I also don't think this should matter to the acceptor. :) > > > > I think GSS_C_DELEG_POLICY_FLAG should never seen on wire, but I > > really dont care too much about this, either way is fine. > = > I also don't care too much either way, but since flags can get output > on the acceptor side, I think we should explicitly mention what > happens. It will be just fine to define this flag as a local flag, i.e. something that is communicated only between the local app and the local gssapi mechanism and not across the wire. There are already two other flags which are completely local: GSS_C_TRANS_FLAG and GSS_C_PROT_READY (but the spec may be lacking that these are local flags). > = > RFC2743 and RFC2744 are not so clear on the "always delegate"; they > indicate that the DELEG_FLAG is a request. It is possible to read the > RFCs as allowing an implementation to apply policy and cause > init_sec_context to decline the delegation request. In such a case, > DELEG_POLICY_FLAG is not sufficient to allow the application to > override policy. Correct, asserting the flag is a mere request. (Honestly, I haven't considered the exact details of the spec) but my recollection is this is a local issue, i.e. possible reasons why a requested delegation of credentials is not performed are - delegation of credentials is not defined for this mechanism - delegation of credentials is defined the the mechanism, but not implemented by the current mechanism implementation - delegation of credentials is prohibited by local policy - delegation of credentials is not possible due to technical reasons (i.e. the local credentials may not be valid anywhere else, or it may be impossible to transfer them, because they are bound to token hardware) > = > I suggest that we provide an additional flag to allow applications to > override a centrally administered policy prohibiting delegation. I do not take a position here. Delegation of credentials is a can of worm that I don't like to be opened where it can be avoided. I principle I see a conceptually difference in forwarding a credentials (e.g. when doing a remote login of some kind) and when doing a real delegation of a credential to some server that decides autonomously what it is going to do with the delegated credentials. For the latter, a constrained delegation might be preferable, but that is a complex topic that is likely to result in long discussions (rat hole, can of worms). > = > > DELEG_POLICY - delegate if policy allows > = > If this is set without DELEG_FLAG being set, then no delegation takes > place if the implementation does not understand DELEG_POLICY_FLAG. > This is probably desired. > = > > DELEG | DELEG_POLICY - always delegate, but do tell client if it was > > allowed by policy. > > > > So a client that want to follow the policy of the site, can always > > specify DELEG_POLICY > = > Unless the client assumes an implementation where setting DELEG_FLAG > alone requests "delegate if permitted by policy". When trying "credential forwarding" for remote login, the user may have a workaround for "policy problems", by recreating (software) credentials on the remote machine. IIRC, the primary purpose of "OK_AS_DELEGATE" was to restrict the number of targets/services which will be able to obtain delegated credentials, because it was assumed that the application might not be in the position to perform a sensible/safe decision (blindly assert the flag, sometimes due to the number of abstraction layer between "APP" and GSS-API/SSPI), and that the user would also often not be in the position to do a sensible decision (and normally should better NOT be bothered with such a decision). This might not apply to all users and all usage scenarios, but it was anticipated to apply to a non-negligable amount of users and usage scenarios, and that it might be quite easy for attackers to cause delegation to services under their control without a central policy setting. -Martin _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Aug 27 13:20:39 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039F93A6966; Wed, 27 Aug 2008 13:20:39 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C6C3A68E1 for ; Wed, 27 Aug 2008 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=1.406, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TquPy1hFyIAF for ; Wed, 27 Aug 2008 13:20:36 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5C1D73A6407 for ; Wed, 27 Aug 2008 13:20:36 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m7RKKa6S021729; Wed, 27 Aug 2008 22:20:36 +0200 (MEST) From: Martin Rex Message-Id: <200808272020.m7RKKZoZ005887@fs4113.wdf.sap.corp> Subject: Re: NegoEx Feed-back Requested To: miallen@ioplex.com (Michael B Allen) Date: Wed, 27 Aug 2008 22:20:35 +0200 (MEST) In-Reply-To: <20080809192740.2d907f01.miallen@ioplex.com> from "Michael B Allen" at Aug 9, 8 07:27:40 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@Sun.COM X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Michael B Allen wrote: > > On Mon, 04 Aug 2008 13:19:50 -0600 > "Shawn M. Emery" wrote: > > > > > Looking feed-back from Larry's individual submission on Extended GSS-API > > Negotiation Mechanism, that he presented in Dublin: > > > > http://tools.ietf.org/html/draft-zhu-negoex-01 > > What advantage does using explicitly encoded little-endian blobs have > over the much more common DER? Independent of the particular document that is referenced, the most significant advantages should be obvious: - easier to implement, less code - more efficient implementations (the variable sized length fields and variable sized integers in ASN.1 DER are a real pain in encoding) - the spec can be reviewed by a MUCH larger audience (I know very few people whom I think are capable to seriously review an ASN.1-ladden spec, actually I can not think of a name besides Tom Yu at the moment). I've been saying that since SNEGO was orignally proposed by Denis Pinkas on the CAT mailing list more than 10 years ago. ASN.1 was probably the primary reason why there so few implementations over years and the interoperability problems in the original SPNEGO spec weren't noticed and fixed. -Martin _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Aug 27 13:52:57 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343BC3A68FE; Wed, 27 Aug 2008 13:52:57 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDDD3A6A7A for ; Wed, 27 Aug 2008 13:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu+lDl8vDytB for ; Wed, 27 Aug 2008 13:52:55 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B669B3A6869 for ; Wed, 27 Aug 2008 13:52:54 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m7RKqh9h026644; Wed, 27 Aug 2008 22:52:43 +0200 (MEST) From: Martin Rex Message-Id: <200808272052.m7RKqgXo007733@fs4113.wdf.sap.corp> Subject: Re: NegoEx Feed-back Requested To: martin.rex@sap.com Date: Wed, 27 Aug 2008 22:52:42 +0200 (MEST) In-Reply-To: <200808272020.m7RKKZoZ005887@fs4113.wdf.sap.corp> from "Martin Rex" at Aug 27, 8 10:20:35 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org, Shawn.Emery@Sun.COM X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org Having briefly looked at the document, there are a couple of unecessary hurdles in the chosen notation: All integer types ought to carry the length in their names to facilitate reading. (UCHAR and ULONG64 are fine, ULONG, USHORT GUID and enums are not). Additionally, nothing is said about the alignment of the listed integer types, which is most confusing with respect to the type GUID. A "4 octet number encoded in little endian" does NOT have alignment requirements, an ULONG is very likely supposed to have it. Lack of explicit structure padding. A C-Compiler is going to add padding after members of structures and at the end of structures as necessary to accomodate the alignment requirements of the structure members and the largest structure member. A spec for on-the-wire data ought not to rely on unnamed/non-obvious padding, but instead spell out each and every octet on the wire, its value and its semantics. This is an obvious defect for simple structures like AUTH_SCHEME_VECTOR and EXTENSION_VECTOR, and in particular for the complex structures like MESSAGE_HEADER, NEGO_MESSAGE, EXCHANGE_MESSAGE and VERIFY_MESSAGE The lack of explicit alignment and padding requirements for the message formats has caused interop problems in one particular network file system protocol, so lets try to avoid it this time around... -Martin _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Aug 27 13:56:15 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E833A68E1; Wed, 27 Aug 2008 13:56:15 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BBD3A68E1 for ; Wed, 27 Aug 2008 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skZCGV4PUSki for ; Wed, 27 Aug 2008 13:56:13 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 0EE443A6407 for ; Wed, 27 Aug 2008 13:56:12 -0700 (PDT) Received: from proton.foo.net (pool-72-88-204-207.nwrknj.fios.verizon.net [72.88.204.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id C01423FD05; Wed, 27 Aug 2008 16:56:14 -0400 (EDT) Date: Wed, 27 Aug 2008 16:56:14 -0400 From: Michael B Allen To: martin.rex@sap.com Subject: Re: NegoEx Feed-back Requested Message-Id: <20080827165614.c8038a22.miallen@ioplex.com> In-Reply-To: <200808272020.m7RKKZoZ005887@fs4113.wdf.sap.corp> References: <20080809192740.2d907f01.miallen@ioplex.com> <200808272020.m7RKKZoZ005887@fs4113.wdf.sap.corp> Organization: IOPLEX Software X-Mailer: Sylpheed 2.5.0rc2 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: kitten@ietf.org, Shawn.Emery@Sun.COM, Martin Rex X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Wed, 27 Aug 2008 22:20:35 +0200 (MEST) Martin Rex wrote: > Michael B Allen wrote: > > > > On Mon, 04 Aug 2008 13:19:50 -0600 > > "Shawn M. Emery" wrote: > > > > > > > > Looking feed-back from Larry's individual submission on Extended GSS-API > > > Negotiation Mechanism, that he presented in Dublin: > > > > > > http://tools.ietf.org/html/draft-zhu-negoex-01 > > > > What advantage does using explicitly encoded little-endian blobs have > > over the much more common DER? > > Independent of the particular document that is referenced, > the most significant advantages should be obvious: > > - easier to implement, less code > > - more efficient implementations (the variable sized length fields > and variable sized integers in ASN.1 DER are a real pain in encoding) > > - the spec can be reviewed by a MUCH larger audience > (I know very few people whom I think are capable to seriously > review an ASN.1-ladden spec, actually I can not think of a name > besides Tom Yu at the moment). > > I've been saying that since SNEGO was orignally proposed by Denis Pinkas > on the CAT mailing list more than 10 years ago. ASN.1 was probably > the primary reason why there so few implementations over years and > the interoperability problems in the original SPNEGO spec weren't > noticed and fixed. Well you're assuming people are hand-wrangleing DER which is usually not true. Unfortunately sometimes it is true and I agree with you 100% about the efficiency of DER encoding. I guess I'm indifferent. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Aug 27 14:25:01 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0513A6830; Wed, 27 Aug 2008 14:25:01 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7733A6407 for ; Wed, 27 Aug 2008 14:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DmROne69tjw for ; Wed, 27 Aug 2008 14:24:59 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 1438D3A682B for ; Wed, 27 Aug 2008 14:24:59 -0700 (PDT) Received: from proton.foo.net (pool-72-88-204-207.nwrknj.fios.verizon.net [72.88.204.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id BDEF03FD05; Wed, 27 Aug 2008 17:24:49 -0400 (EDT) Date: Wed, 27 Aug 2008 17:24:49 -0400 From: Michael B Allen To: martin.rex@sap.com Subject: Re: NegoEx Feed-back Requested Message-Id: <20080827172449.582365bc.miallen@ioplex.com> In-Reply-To: <200808272052.m7RKqgXo007733@fs4113.wdf.sap.corp> References: <200808272020.m7RKKZoZ005887@fs4113.wdf.sap.corp> <200808272052.m7RKqgXo007733@fs4113.wdf.sap.corp> Organization: IOPLEX Software X-Mailer: Sylpheed 2.5.0rc2 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: kitten@ietf.org, Shawn.Emery@Sun.COM, Martin Rex X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Wed, 27 Aug 2008 22:52:42 +0200 (MEST) Martin Rex wrote: > The lack of explicit alignment and padding requirements for > the message formats has caused interop problems in one particular > network file system protocol, so lets try to avoid it this > time around... I see no mention of "alignment" or "padding" in the document. The structure definitions use "'C' conventions" and are "much like that of C". That does not mean compiler artefacts like alignment and padding are a factor. Meaning there is no alignment or padding. I think the days of casting structures into network buffers are long over. And I would hope that any standard that proposed such a thing would be stricken down with prejudice. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Aug 27 14:28:20 2008 Return-Path: X-Original-To: kitten-archive@megatron.ietf.org Delivered-To: ietfarch-kitten-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE933A6843; Wed, 27 Aug 2008 14:28:20 -0700 (PDT) X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EBB3A68B0 for ; Wed, 27 Aug 2008 14:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZHkuy6sxKHx for ; Wed, 27 Aug 2008 14:28:19 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id DFBA93A6843 for ; Wed, 27 Aug 2008 14:28:18 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m7RLSFXZ017759; Wed, 27 Aug 2008 17:28:15 -0400 (EDT) Received: from NOME-KING.MIT.EDU (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m7RLS9Dj024447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Aug 2008 17:28:14 -0400 (EDT) Message-Id: <46F6FF68-9C87-4CD0-A5C7-2E6783232DFF@mit.edu> From: Ken Raeburn To: kitten@ietf.org In-Reply-To: <200808272052.m7RKqgXo007733@fs4113.wdf.sap.corp> Subject: Re: NegoEx Feed-back Requested Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 27 Aug 2008 17:28:09 -0400 References: <200808272052.m7RKqgXo007733@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.928.1) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org On Aug 27, 2008, at 16:52, Martin Rex wrote: > Having briefly looked at the document, there are a couple > of unecessary hurdles in the chosen notation: > > All integer types ought to carry the length in their names > to facilitate reading. (UCHAR and ULONG64 are fine, > ULONG, USHORT GUID and enums are not). > Additionally, nothing is said about the alignment of the listed > integer > types, which is most confusing with respect to the type GUID. > > > A "4 octet number encoded in little endian" does NOT have > alignment requirements, an ULONG is very likely supposed to > have it. > > Lack of explicit structure padding. A C-Compiler is going to > add padding after members of structures and at the end of > structures as necessary to accomodate the alignment requirements > of the structure members and the largest structure member. My first thought on glancing at this draft was that we don't need another data layout specification language if we can avoid it. If ASN. 1 has already been shot down, why not XDR (RFC 4506)? Aside from missing a primitive GUID type, which is easy enough to work around, I think it covers all the bases, doesn't it? Ken _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten