From kitten-bounces@lists.ietf.org Thu Nov 4 16:59:52 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 16:59:52 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 13AA513174 for ; Thu, 4 Nov 2004 16:59:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpNW-00038b-1e; Thu, 04 Nov 2004 16:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpEo-0000E9-OX for kitten@megatron.ietf.org; Thu, 04 Nov 2004 16:33:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08324 for ; Thu, 4 Nov 2004 16:33:44 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpUP-0007gi-2C for kitten@ietf.org; Thu, 04 Nov 2004 16:49:53 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA01454; Thu, 4 Nov 2004 22:33:07 +0100 (MEZ) From: Martin Rex Message-Id: <200411042133.WAA12775@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 4 Nov 2004 22:33:09 +0100 (MET) In-Reply-To: <20041025204252.GE21427@binky.central.sun.com> from "Nicolas Williams" at Oct 25, 4 03:42:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, hartmans@mit.edu Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 2543 Lines: 53 Nicolas Williams wrote: > > On Mon, Oct 25, 2004 at 04:36:25PM -0400, Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > > > Nicolas> Also, for default name, think of the MIT krb5 ccache. It > > Nicolas> can store tickets for more than one client principal, but > > Nicolas> the ccache file format specifies a default principal name > > Nicolas> so that even if one does store tickets for multiple > > Nicolas> different client principals it is always clear which to > > Nicolas> use when not explicitly requesting one or another name. > > > > Remember the thread on krbdev where we proposed to drop that and use > > the best match principal for the service in question. > > That does not change the fact that one could (and one implementor has) > treated Kerberos credentials in that way. This helps me view the > Kerberos V mechanism as not so different from x.509 certificate-based > mechanisms w.r.t. to credentials having multiple names associated with > them. As I mentioned in my last Email, a gss-api credential may be composed of several credentials for seperate mechanisms. However for a single mechanism, a GSS-API credential may refer only to one single identity (principal,name). It is OK if a gssapi mechanism allows an application to select a particular credential out of a set, depending on either an explicit name supplied by the application or a locally configured default when the application calls gss_acquire_cred(). However when the gss_acquire_cred() returns, the mechanism does not yet know to which target the application is going to authenticate, however the decision to which identity the returned credentials handle refers must have been made and is irreversible. A spec weasel might try to loophole the case where gss_init_sec_context() is called with GSS_S_NO_CREDENTIAL, but an application may prefer to use seperate calls for the distinct purposes (so that a credential-related error will be caught and reported before a network connection has been established -- usually gss_init_sec_context() will be called after a network connection has been established, and if it fails, the app will have to close the network connection and leave the server in the dark why it rattled the door... And if you really care about servers, then you shouldn't write clients that behave like that. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 17:49:51 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 17:49:50 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 6A05313174 for ; Thu, 4 Nov 2004 17:49:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqCb-0004jL-FZ; Thu, 04 Nov 2004 17:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpv1-0003Vh-2t for kitten@megatron.ietf.org; Thu, 04 Nov 2004 17:17:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13361 for ; Thu, 4 Nov 2004 17:17:20 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqAb-0000ea-P0 for kitten@ietf.org; Thu, 04 Nov 2004 17:33:31 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA4MHKs3025901 for ; Thu, 4 Nov 2004 14:17:20 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA4MHJjW027105 for ; Thu, 4 Nov 2004 15:17:19 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA4MGov1028597; Thu, 4 Nov 2004 16:16:50 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA4MGoPh028596; Thu, 4 Nov 2004 16:16:50 -0600 (CST) Date: Thu, 4 Nov 2004 16:16:50 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20041104221650.GF29391@binky.central.sun.com> References: <20041025204252.GE21427@binky.central.sun.com> <200411042133.WAA12775@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411042133.WAA12775@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org, hartmans@mit.edu Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 919 Lines: 24 On Thu, Nov 04, 2004 at 10:33:09PM +0100, Martin Rex wrote: > As I mentioned in my last Email, a gss-api credential may be composed > of several credentials for seperate mechanisms. However for a single > mechanism, a GSS-API credential may refer only to one single identity > (principal,name). A given *CREDENTIAL HANDLE*, yes. But looking a t a very specific kind of credential, a PKI cert, it's clear that it may respond to several names. My point is that it'd be nice if the app could deal with that and pick one name, rather than leave the selection to a spec or to local configuration. One way to do this would be through an abstraction of the "credential store" -- think of a function to acquire all the credentials that are in the "curren credential store." Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 18:06:15 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 18:06:15 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 9015A13174 for ; Thu, 4 Nov 2004 18:06:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqdI-0005Wd-Oo; Thu, 04 Nov 2004 18:03:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqUF-0001VX-I6 for kitten@megatron.ietf.org; Thu, 04 Nov 2004 17:53:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18550 for ; Thu, 4 Nov 2004 17:53:45 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqjr-0001te-Da for kitten@ietf.org; Thu, 04 Nov 2004 18:09:55 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA4Mrjs3013011 for ; Thu, 4 Nov 2004 14:53:45 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA4MrjjW010488 for ; Thu, 4 Nov 2004 15:53:45 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA4MrGTF028633; Thu, 4 Nov 2004 16:53:16 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA4MrGhK028632; Thu, 4 Nov 2004 16:53:16 -0600 (CST) Date: Thu, 4 Nov 2004 16:53:16 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20041104225315.GI29391@binky.central.sun.com> References: <20041025204252.GE21427@binky.central.sun.com> <200411042133.WAA12775@uw1048.wdf.sap.corp> <20041104221650.GF29391@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041104221650.GF29391@binky.central.sun.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org, hartmans@mit.edu Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 1348 Lines: 31 On Thu, Nov 04, 2004 at 04:16:50PM -0600, Nicolas Williams wrote: > On Thu, Nov 04, 2004 at 10:33:09PM +0100, Martin Rex wrote: > > As I mentioned in my last Email, a gss-api credential may be composed > > of several credentials for seperate mechanisms. However for a single > > mechanism, a GSS-API credential may refer only to one single identity > > (principal,name). > > A given *CREDENTIAL HANDLE*, yes. But looking a t a very specific kind > of credential, a PKI cert, it's clear that it may respond to several > names. My point is that it'd be nice if the app could deal with that > and pick one name, rather than leave the selection to a spec or to local > configuration. > > One way to do this would be through an abstraction of the "credential > store" -- think of a function to acquire all the credentials that are in > the "curren credential store." Sam points out that then one could not distinguish between a pair of credential handles that correspond to different names of the same credential, which for a GSS equivalent of the 'klist' command would be a pretty annoying problem. An alternative to this interface that we've discussed has a different problem. We may need both. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 16:42:55 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 16:42:55 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 47C4513174 for ; Thu, 4 Nov 2004 16:42:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpHW-0000zW-Cr; Thu, 04 Nov 2004 16:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPp2w-0004HZ-AG for kitten@megatron.ietf.org; Thu, 04 Nov 2004 16:21:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06491 for ; Thu, 4 Nov 2004 16:21:28 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpIW-0007Cw-L1 for kitten@ietf.org; Thu, 04 Nov 2004 16:37:38 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA20901; Thu, 4 Nov 2004 22:20:50 +0100 (MEZ) From: Martin Rex Message-Id: <200411042120.WAA12352@uw1048.wdf.sap.corp> To: hartmans@mit.edu (Sam Hartman) Date: Thu, 4 Nov 2004 22:20:52 +0100 (MET) In-Reply-To: from "Sam Hartman" at Oct 25, 4 04:36:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 950 Lines: 24 Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> Also, for default name, think of the MIT krb5 ccache. It > Nicolas> can store tickets for more than one client principal, but > Nicolas> the ccache file format specifies a default principal name > Nicolas> so that even if one does store tickets for multiple > Nicolas> different client principals it is always clear which to > Nicolas> use when not explicitly requesting one or another name. > > Remember the thread on krbdev where we proposed to drop that and use > the best match principal for the service in question. Actually that would break the GSS-API abstraction. A GSS-API credential may have mechanis-specific names, it may NOT have target-specific names. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 17:16:44 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 17:16:43 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id ECD0F13174 for ; Thu, 4 Nov 2004 17:16:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpmR-00017z-1G; Thu, 04 Nov 2004 17:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpf7-0006n5-Rk for kitten@megatron.ietf.org; Thu, 04 Nov 2004 17:00:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11168 for ; Thu, 4 Nov 2004 17:00:55 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpuj-0008VC-73 for kitten@ietf.org; Thu, 04 Nov 2004 17:17:05 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 3C8311D8025; Thu, 4 Nov 2004 17:00:59 -0500 (EST) To: martin.rex@sap.com References: <200411042120.WAA12352@uw1048.wdf.sap.corp> From: Sam Hartman Date: Thu, 04 Nov 2004 17:00:59 -0500 In-Reply-To: <200411042120.WAA12352@uw1048.wdf.sap.corp> (Martin Rex's message of "Thu, 4 Nov 2004 22:20:52 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: O Content-Length: 1569 Lines: 40 >>>>> "Martin" == Martin Rex writes: Martin> Sam Hartman wrote: >> >>>>> "Nicolas" == Nicolas Williams >> writes: >> Nicolas> Also, for default name, think of the MIT krb5 ccache. It Nicolas> can store tickets for more than one client principal, but Nicolas> the ccache file format specifies a default principal name Nicolas> so that even if one does store tickets for multiple Nicolas> different client principals it is always clear which to Nicolas> use when not explicitly requesting one or another name. >> Remember the thread on krbdev where we proposed to drop that >> and use the best match principal for the service in question. Martin> Actually that would break the GSS-API abstraction. A Martin> GSS-API credential may have mechanis-specific names, it Martin> may NOT have target-specific names. Yes. It's clear that the intent of the spec is consistent with what you are saying. It seems like GSSAPI V2 has the requirement that if I export the name I get from my default credentials, that needs to be the same as the name I get by exporting the name from my context established with those credentials. Thanks for pointing this out. I had previously convinced myself that if I went through enough contortions in how I defined what name types were used that I could get the behavior I want. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 17:30:48 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 17:30:48 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 319DB13174 for ; Thu, 4 Nov 2004 17:30:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpuX-0003MF-D6; Thu, 04 Nov 2004 17:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpmm-0001Ho-Rz for kitten@megatron.ietf.org; Thu, 04 Nov 2004 17:08:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12375 for ; Thu, 4 Nov 2004 17:08:50 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPq2N-0000Qm-FO for kitten@ietf.org; Thu, 04 Nov 2004 17:25:00 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA4M8o7q007178 for ; Thu, 4 Nov 2004 14:08:50 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA4M8njW022974 for ; Thu, 4 Nov 2004 15:08:49 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA4M8Kjw028589; Thu, 4 Nov 2004 16:08:20 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA4M8KDq028588; Thu, 4 Nov 2004 16:08:20 -0600 (CST) Date: Thu, 4 Nov 2004 16:08:19 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041104220819.GE29391@binky.central.sun.com> References: <200411042120.WAA12352@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 559 Lines: 17 On Thu, Nov 04, 2004 at 05:00:59PM -0500, Sam Hartman wrote: > Thanks for pointing this out. I had previously convinced myself that > if I went through enough contortions in how I defined what name types > were used that I could get the behavior I want. I think of GSS name types as much like Kerberos V name types: hints, except that in the GSS case they can determine the "query" syntax for that name type. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 16:25:01 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 16:25:01 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id BA3C013174 for ; Thu, 4 Nov 2004 16:25:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPotu-00006Y-HG; Thu, 04 Nov 2004 16:12:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPopG-0005qN-DK for kitten@megatron.ietf.org; Thu, 04 Nov 2004 16:07:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05063 for ; Thu, 4 Nov 2004 16:07:20 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPp4r-0006to-J7 for kitten@ietf.org; Thu, 04 Nov 2004 16:23:30 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA08660; Thu, 4 Nov 2004 22:06:45 +0100 (MEZ) From: Martin Rex Message-Id: <200411042106.WAA11906@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 4 Nov 2004 22:06:46 +0100 (MET) In-Reply-To: <20041025190036.GX21427@binky.central.sun.com> from "Nicolas Williams" at Oct 25, 4 02:00:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, hartmans@mit.edu Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 1844 Lines: 50 Nicolas Williams wrote: > > On Mon, Oct 25, 2004 at 02:53:16PM -0400, Sam Hartman wrote: > > To be useful you need to standardize which name you pick as the > > canonical name from a cert. > > For a given query form. Which part is insufficient, you need to specify much more ... consider the following existing variants: 1. /C=US/OU=org2/OU=org1/O=Foo, Inc./CN=John Doe 2. C=US, OU=org2, OU=org1, O="Foo, Inc.", CN=John Doe 3. cn=John Doe, o="Foo, Inc.", ou=org1, ou=org2, c=US 4. CN=John Doe, O="Foo, Inc.", OU=org1, OU=org2, C=US 5. CN=John Doe, O="Foo, Inc.", OU=org2, OU=org1, C=US Whether 4. and 5. should be considered equivalent is the most interesting question. There are very few (if any) products that will apply a sorting order to RDNs (and those that do, what might be the result when those compare 4. and 5.?). Just look at SPKM (rfc2025). The spec is hardly sufficient to come up with useful wire-interoperable implementations, but the lack of a standardized name format makes is quite useless as a standard because it will not fly in a heterogeneous distributed environment. I know several independent implementations of rfc-2025, and neither two are fully interoperable on names. But actually there appear to be more proprietary variants that are loosely based on rfc-2025 than there are true rfc-2025 implementations. Still, no two products that I've encountered are fully interoperable on names. There's limited interoperability on the printable INput, and zero interoperability on the binary canonical form. In this respect, the rfc1964 gssapi mechanism is magnitudes better, as it defines the canonical encoding and a mandatory printable representation. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 16:00:24 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 16:00:23 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id A90B213174 for ; Thu, 4 Nov 2004 16:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPoXG-0005Gp-6l; Thu, 04 Nov 2004 15:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPoUn-0003xz-Fk for kitten@megatron.ietf.org; Thu, 04 Nov 2004 15:46:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03157 for ; Thu, 4 Nov 2004 15:46:11 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPokE-0006RY-Dj for kitten@ietf.org; Thu, 04 Nov 2004 16:02:20 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA25391; Thu, 4 Nov 2004 21:45:24 +0100 (MEZ) From: Martin Rex Message-Id: <200411042045.VAA11289@uw1048.wdf.sap.corp> To: hartmans@mit.edu (Sam Hartman) Date: Thu, 4 Nov 2004 21:45:25 +0100 (MET) In-Reply-To: from "Sam Hartman" at Oct 25, 4 02:53:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 2203 Lines: 57 (I'm a little behind on my Email...) Sam Hartman wrote: > > To be useful you need to standardize which name you pick as the > canonical name from a cert. I believe it is possible to come up with a single standard about name mapping for X.509 certs. X.509 is magnitudes to "flexible" and Companies are magnitudes to "creative" when setting up PKIs and their own CAs, including a lot of fancy information in the DNs that just make life harder for software and admins which are being faced with those names through APIs for secure authentication... The best thing would be to have it configurable for the software which components are used to make up a distinct name at the authentication API -- however that creates the problem of how one creates a homogeneous installation with the same configuration... (Having a single standard which can be preconfigured/hardcoded makes software maintenance&distribution so much easier). > > Also, the compatibility issue is not just about whether you have > something to return. The issue also includes the question of whether > a gssapi v2 application that uses gss_export_name as intended by the > v2 spec will get the desired behavior. > > If you pick some arbitrary mapping then you may have an implementable > protocol but you will not have a protocol that meets users' needs. You underestimate the "creativity" of customers. A while ago I had a customer asking why our software didn't include their particular altSubjectName extension in the ACLs for authentication with SSL client certs in our software. He indicated that his CA might issue distinct certs that would only differ in the contents of their special altSubjectName extension and not in the contents of the DN itself. Well, I had to explain him that I'm sorry, but we wouldn't support that, and I suggested that they better fix their CA, because there are certificate profiles (like rfc2459) which clearly state that a CA issuing certs with non-empty subjectDNs must issue unique subjectDNs for certs identifying distict end entities. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 13:55:44 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 13:55:42 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 598FB1324F for ; Mon, 25 Oct 2004 13:55:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM93N-0003CF-IW; Mon, 25 Oct 2004 13:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8xy-0002O8-9J for kitten@megatron.ietf.org; Mon, 25 Oct 2004 13:49:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17835 for ; Mon, 25 Oct 2004 13:49:08 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM9BT-000405-6d for kitten@ietf.org; Mon, 25 Oct 2004 14:03:07 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 2A2A0E004F; Mon, 25 Oct 2004 13:49:18 -0400 (EDT) To: kitten@ietf.org From: Sam Hartman Date: Mon, 25 Oct 2004 13:49:18 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 2522 Lines: 77 Section 3.2 (d) (I) is garbled. Based on 3.2 (b) I don't understand how you ever get to rule 3.2 (d) (I) (3). I believe the bug is in 3.2 (b) because I believe you should be able to get to this rule. In section 3.2 you claim: On receipt of a negotiation token on the target side, a GSS-API implementation that does not support negotiation would indicate the GSS_S_BAD_MECH status as if a particular basic security mechanism had been requested but was not supported. That's actually not true; a mechanism could just as easily return GSS_S_BAD_TOKEN in this state. Actually there is a possibility involving non-standards-track mechanisms that look a lot like the SPNEGO mechanism where you could get other responses as well, but that will not happen in practie. There seem to be several significant semantic changes I'd like to call to the attention of the IETF. I believe we need explicit consensus for these changes: 1) The use of optimistic negotiation is promoted to a SHOULD. This simplifies the description of the protocol because you can generally assume that the client does support including the optimistic token. 2) The mechanism requires that all target mechs support integrity protection. This is a significant change and is non-backward-compatible. 3) prot_ready is forbidden. I believe this is required for things to work out correctly. 4) There is complexity to support omitting the MIC when appropriate. I'm not sure this is correct; I need to actually go through the same reasoning that Larry and the other Microsoft folks did. 5) The API in SPNEGO for determining what set of credentials you support is dropped and replaced with a reference to Nico's draft. I'd like to suggest the following improvements to the draft: 1) Write an explanation of what's going on with the safe to omit MIC stuff that is sufficient for the rest of us to convince ourselves it is secure. 2) Write an explanation of what Windows 2000 did that is sufficient for us to confirm the claim in Appendix A that this should interoperate 3) Describe what the MIC is an encoding of; I think this is still unclear. 4) Describe when (if ever) you can take advantage of the extensibility markers you've added. I think this is a great start on a new SPNEGO spec. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 15:24:46 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 15:24:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id BB4691324F for ; Mon, 25 Oct 2004 15:24:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMARi-0006DW-7T; Mon, 25 Oct 2004 15:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAQn-0005ij-Qq for kitten@megatron.ietf.org; Mon, 25 Oct 2004 15:23:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26100 for ; Mon, 25 Oct 2004 15:22:59 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAe8-0005ZD-Vt for kitten@ietf.org; Mon, 25 Oct 2004 15:36:59 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA19387; Mon, 25 Oct 2004 21:22:13 +0200 (MESZ) From: Martin Rex Message-Id: <200410251922.VAA09962@uw1048.wdf.sap.corp> To: hartmans@mit.edu (Sam Hartman) Date: Mon, 25 Oct 2004 21:22:13 +0200 (MET DST) In-Reply-To: from "Sam Hartman" at Oct 25, 4 01:49:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 4413 Lines: 108 Sam Hartman wrote: > > In section 3.2 you claim: > > On receipt of a negotiation token on the target side, a GSS-API > implementation that does not support negotiation would indicate > the GSS_S_BAD_MECH status as if a particular basic security > mechanism had been requested but was not supported. > > That's actually not true; a mechanism could just as easily return > GSS_S_BAD_TOKEN in this state. Actually there is a possibility > involving non-standards-track mechanisms that look a lot like the > SPNEGO mechanism where you could get other responses as well, but that > will not happen in practice. I'm sorry to disagree with you, Sam, but the quote paragraph seems to be perfectly correct. The initial context token MUST use the generic framing with the mechanism OID for the precise reason that a gssapi mechanism will be able to recognize whether it supports communication with the peer or not. If not, then GSS_S_BAD_MECH is the required major status response. Btw. GSS_S_BAD_TOKEN does not exist, did you mean GSS_S_DEFECTIVE_TOKEN? If mechanism does not recognize the SPNEGO mechanism OID, then it can not know what the rest of the token means, so GSS_S_DEFECTIVE_TOKEN would be a mere guess and probably the wrong guess in 99.8%. So it is not only prohibited to return GSS_S_DEFECTIVE_TOKEN, it is also a pretty bad idea. > > There seem to be several significant semantic changes I'd like > to call to the attention of the IETF. I believe we need explicit > consensus for these changes: > > 1) The use of optimistic negotiation is promoted to a SHOULD. This > simplifies the description of the protocol because you can > generally assume that the client does support including the > optimistic token. The reasoning is maybe that Microsoft has architected some protocols with SPNEGO that need it badly (it must fail without optimistic negotiation because the embedding protocol doesn't support an additional round trip...). When Denis Pinkas originally proposes SNEGO (without P for "protected") they had a free sample implementation. They didn't need the "P" for their purposes back then, and I think they also didn't need the optimistic negotiation either. I have strong reservations against a SHOULD instead of a MAY, because in the next round someone could try to turn this into a MUST, and I definitely don't ever want to see a MUST there! One of the easiest approaches to test whether an embedding protocol that uses SPNEGO isn't entirely broken is to switch off the optimistic token (adding another roundtrip to the security context establishment) and checking whether everything still works just as smooth as it is required to by the existing spec (which, as I mentioned, isn't true for some uses architected by Microsoft). SPGENO is only useful when it is allowed to negotiate, i.e. when it is allowed to add round-trips to the security context exchange to accomodate the negotiation. If the embedding protocol doesn't have provisions to accomodate that, then it is pointless to call SPNEGO, it just adds complexity with zero value. Essentially what I wanted to say: The benefit of the optimistic token should be obvious to implementors of SPNEGO. The absence does not give applications the permission to fail. Technically, the MAY is perfectly sufficient. > > 2) The mechanism requires that all target mechs support integrity > protection. This is a significant change and is > non-backward-compatible. Wasn't that already sufficiently addressed in the security considerations of the existing spec? I do NOT see a need to require integrity protection either. > > 3) prot_ready is forbidden. I believe this is required for things to > work out correctly. prot_ready was never easy, not even for the regular GSS-API. The problem with prot_ready is the message sequencing interference of SPNEGO's use of the get_mic() primitive with the applications use of message protection facilities. Except for the situation where the optimistic negotiation is used, security context establishment consists of at most 2 token exchanges and actually succeeds -- in all other situations the would be interference. ... and I need to read the document before commenting on the rest. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 19:35:07 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 19:35:06 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id DB4971324F for ; Mon, 25 Oct 2004 19:35:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBZs-0004tS-K4; Mon, 25 Oct 2004 16:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBNh-0004a2-HT for kitten@megatron.ietf.org; Mon, 25 Oct 2004 16:23:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04006 for ; Mon, 25 Oct 2004 16:23:50 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBbC-0007ke-E4 for kitten@ietf.org; Mon, 25 Oct 2004 16:37:51 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 55CB1E0053; Mon, 25 Oct 2004 16:24:01 -0400 (EDT) To: martin.rex@sap.com References: <200410251922.VAA09962@uw1048.wdf.sap.corp> From: Sam Hartman Date: Mon, 25 Oct 2004 16:24:00 -0400 In-Reply-To: <200410251922.VAA09962@uw1048.wdf.sap.corp> (Martin Rex's message of "Mon, 25 Oct 2004 21:22:13 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 3221 Lines: 81 >>>>> "Martin" == Martin Rex writes: Martin> Sam Hartman wrote: >> In section 3.2 you claim: >> >> On receipt of a negotiation token on the target side, a GSS-API >> implementation that does not support negotiation would indicate >> the GSS_S_BAD_MECH status as if a particular basic security >> mechanism had been requested but was not supported. >> >> That's actually not true; a mechanism could just as easily >> return GSS_S_BAD_TOKEN in this state. Actually there is a >> possibility involving non-standards-track mechanisms that look >> a lot like the SPNEGO mechanism where you could get other >> responses as well, but that will not happen in practice. Martin> I'm sorry to disagree with you, Sam, but the quote Martin> paragraph seems to be perfectly correct. Martin> The initial context token MUST use the generic framing Martin> with the mechanism OID for the precise reason that a Martin> gssapi mechanism will be able to recognize whether it Martin> supports communication with the peer or not. Section 3.1 of RFC 2743 requires a specific context token framing for IETF standards-track mechanisms. However no such requirement is made for non-standards-track mechanisms. We're aware of non-standards track mechanisms that do not use the framing described in this section. If the default mechanism happens not to be a standards-track mechanism, it seems unreasonable to require that mechanism to understand the IETF framing. Moreover in particularly pathalogical cases, the non-standards-track mechanism may have a context token that conflicts in semantics with the IETF framing. I believe this will never happen in practice. However Martin> If not, then Martin> GSS_S_BAD_MECH is the required major status response. Can you cite part of RFC 2743 that supports this claim? The closest I can find is section 2.2.2. That section says that o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the input_token failed, preventing further processing from being performed based on that token. o GSS_S_BAD_MECH indicates receipt of a context establishment token specifying a mechanism unsupported by the local system or with the caller's active credentials. I think both of these return status seem appropriate in the case where the token does not correspond to the mechanism ID passed into gss_accept_sec_context. Our implementation returns GSS_S_DEFECTIVE_TOKEN because the consistency check of confirming the OID in the token header matches the expected value fails. I suspect other implementations return GSS_S_BAD_MECH. I'd agree with a proposal to require that standards-track mechanisms (or other mechanisms that use the IETF framing described in section 3.2) return GSS_S_BAD_MECH in this case. However absent text in the standard to the contrary, such a proposal would be a change/clarification of current behavior. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 4 16:42:37 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 04 Nov 2004 16:42:37 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 02FDC13174 for ; Thu, 4 Nov 2004 16:42:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpEW-00007e-60; Thu, 04 Nov 2004 16:33:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPozl-0002so-Mq for kitten@megatron.ietf.org; Thu, 04 Nov 2004 16:18:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06219 for ; Thu, 4 Nov 2004 16:18:11 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpFM-00079g-0U for kitten@ietf.org; Thu, 04 Nov 2004 16:34:21 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA15912; Thu, 4 Nov 2004 22:17:37 +0100 (MEZ) From: Martin Rex Message-Id: <200411042117.WAA12238@uw1048.wdf.sap.corp> To: hartmans@mit.edu (Sam Hartman) Date: Thu, 4 Nov 2004 22:17:38 +0100 (MET) In-Reply-To: from "Sam Hartman" at Oct 25, 4 04:24:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 1281 Lines: 35 Ooops -- blush. You're correct, Sam. Sam Hartman wrote: > > Martin> The initial context token MUST use the generic framing > Martin> with the mechanism OID for the precise reason that a > Martin> gssapi mechanism will be able to recognize whether it > Martin> supports communication with the peer or not. > > Section 3.1 of RFC 2743 requires a specific context token framing for > IETF standards-track mechanisms. However no such requirement is made > for non-standards-track mechanisms. We're aware of non-standards > track mechanisms that do not use the framing described in this > section. And if I'm not mistaken, then there is actually a large installed base of an SPNEGO implementation that may send security context tokens from a non-IETF "mechanism" which does not use the generic token framing. That "mechanism" is also known as Microsoft "NT Lan Manager" (NTLM). So you're correct, implementations of SPNEGO that receive an initial security context token from a non-IETF (gssapi) mechanism that lacks the generic framing will likely return GSS_S_DEFECTIVE_TOKEN rather than GSS_S_BAD_MECHANISM. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 19:53:43 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 19:53:42 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 338811324F for ; Mon, 25 Oct 2004 19:53:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO6-0007FF-Ba; Mon, 25 Oct 2004 19:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBw2-00021Y-Ok for kitten@megatron.ietf.org; Mon, 25 Oct 2004 16:59:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08711 for ; Mon, 25 Oct 2004 16:59:19 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMC9X-0000mS-Rf for kitten@ietf.org; Mon, 25 Oct 2004 17:13:21 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id C8B54168027; Mon, 25 Oct 2004 16:59:26 -0400 (EDT) To: martin.rex@sap.com References: <200410251922.VAA09962@uw1048.wdf.sap.corp> From: Sam Hartman Date: Mon, 25 Oct 2004 16:59:26 -0400 In-Reply-To: <200410251922.VAA09962@uw1048.wdf.sap.corp> (Martin Rex's message of "Mon, 25 Oct 2004 21:22:13 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 903 Lines: 26 >>>>> "Martin" == Martin Rex writes: >> 3) prot_ready is forbidden. I believe this is required for >> things to work out correctly. Martin> prot_ready was never easy, not even for the regular Martin> GSS-API. Martin> The problem with prot_ready is the message sequencing Martin> interference of SPNEGO's use of the get_mic() primitive Martin> with the applications use of message protection Martin> facilities. Martin> Except for the situation where the optimistic negotiation Martin> is used, security context establishment consists of at Martin> most 2 token exchanges and actually succeeds -- in all Martin> other situations the would be interference. I think we're in agreement here. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 19:53:39 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 19:53:38 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 3413B1381E for ; Mon, 25 Oct 2004 19:53:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO4-0007Dx-Ed; Mon, 25 Oct 2004 19:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBuK-0007fy-BA for kitten@megatron.ietf.org; Mon, 25 Oct 2004 16:57:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08606 for ; Mon, 25 Oct 2004 16:57:31 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMC7n-0000jy-7E for kitten@ietf.org; Mon, 25 Oct 2004 17:11:33 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 13:57:00 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 13:57:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 13:56:44 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1110); Mon, 25 Oct 2004 13:56:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2004 13:56:58 -0700 Message-ID: Thread-Topic: Comments on Larry's SPNEGO draft Thread-Index: AcS6yFx2LAjLFagdTNqp7pLdI4k5dwACr/DQ From: "Liqiang(Larry) Zhu" To: , "Sam Hartman" X-OriginalArrivalTime: 25 Oct 2004 20:56:59.0209 (UTC) FILETIME=[2B658390:01C4BAD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 5597 Lines: 142 Martin Rex wrote, > Except for the situation where the optimistic negotiation is used,=20 > security context establishment consists of at most 2 >=20 > token exchanges and actually succeeds -- in all other situations the=20 > would be interference. This is incorrect when you use user2user. GSSAPI-CFX has updated RFC 1964 to allow Kerberos mechanisms with 3+ tokens. About whether we should demote the "SHOULD" on the optimistic token, I will need to talk with Wyllys and Nico, to see if we should settle on the protocol such that the "basic form" of the protocol is actually what we use. Right now, we are deploying an "optional" form of the 2478 SPENGO, and if what is also what Sun does, it means this draft has done the right thing. Do you agree?=20 -- larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Monday, October 25, 2004 12:22 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft Sam Hartman wrote: >=20 > In section 3.2 you claim: >=20 > On receipt of a negotiation token on the target side, a GSS-API > implementation that does not support negotiation would indicate > the GSS_S_BAD_MECH status as if a particular basic security > mechanism had been requested but was not supported. >=20 > That's actually not true; a mechanism could just as easily return=20 > GSS_S_BAD_TOKEN in this state. Actually there is a possibility=20 > involving non-standards-track mechanisms that look a lot like the=20 > SPNEGO mechanism where you could get other responses as well, but that > will not happen in practice. I'm sorry to disagree with you, Sam, but the quote paragraph seems to be perfectly correct. The initial context token MUST use the generic framing with the mechanism OID for the precise reason that a gssapi mechanism will be able to recognize whether it supports communication with the peer or not. If not, then GSS_S_BAD_MECH is the required major status response. Btw. GSS_S_BAD_TOKEN does not exist, did you mean GSS_S_DEFECTIVE_TOKEN? If mechanism does not recognize the SPNEGO mechanism OID, then it can not know what the rest of the token means, so GSS_S_DEFECTIVE_TOKEN would be a mere guess and probably the wrong guess in 99.8%. So it is not only prohibited to return GSS_S_DEFECTIVE_TOKEN, it is also a pretty bad idea. >=20 > There seem to be several significant semantic changes I'd like to call > to the attention of the IETF. I believe we need explicit consensus=20 > for these changes: >=20 > 1) The use of optimistic negotiation is promoted to a SHOULD. This > simplifies the description of the protocol because you can > generally assume that the client does support including the > optimistic token. The reasoning is maybe that Microsoft has architected some protocols with SPNEGO that need it badly (it must fail without optimistic negotiation because the embedding protocol doesn't support an additional round trip...). When Denis Pinkas originally proposes SNEGO (without P for "protected") they had a free sample implementation. They didn't need the "P" for their purposes back then, and I think they also didn't need the optimistic negotiation either. I have strong reservations against a SHOULD instead of a MAY, because in the next round someone could try to turn this into a MUST, and I definitely don't ever want to see a MUST there! One of the easiest approaches to test whether an embedding protocol that uses SPNEGO isn't entirely broken is to switch off the optimistic token (adding another roundtrip to the security context establishment) and checking whether everything still works just as smooth as it is required to by the existing spec (which, as I mentioned, isn't true for some uses architected by Microsoft). SPGENO is only useful when it is allowed to negotiate, i.e. when it is allowed to add round-trips to the security context exchange to accomodate the negotiation. If the embedding protocol doesn't have provisions to accomodate that, then it is pointless to call SPNEGO, it just adds complexity with zero value. Essentially what I wanted to say: The benefit of the optimistic token should be obvious to implementors of SPNEGO. The absence does not give applications the permission to fail. Technically, the MAY is perfectly sufficient. >=20 > 2) The mechanism requires that all target mechs support integrity > protection. This is a significant change and is > non-backward-compatible. Wasn't that already sufficiently addressed in the security considerations of the existing spec? I do NOT see a need to require integrity protection either. >=20 > 3) prot_ready is forbidden. I believe this is required for things to > work out correctly. prot_ready was never easy, not even for the regular GSS-API. The problem with prot_ready is the message sequencing interference of SPNEGO's use of the get_mic() primitive with the applications use of message protection facilities. Except for the situation where the optimistic negotiation is used, security context establishment consists of at most 2 token exchanges and actually succeeds -- in all other situations the would be interference. ... and I need to read the document before commenting on the rest. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Oct 29 14:03:21 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 29 Oct 2004 14:03:20 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 961011383E for ; Fri, 29 Oct 2004 14:03:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNb4G-00084h-Sl; Fri, 29 Oct 2004 14:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNayV-0003Mb-JC for kitten@megatron.ietf.org; Fri, 29 Oct 2004 13:55:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19536 for ; Fri, 29 Oct 2004 13:55:42 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbCo-0004dF-Eu for kitten@ietf.org; Fri, 29 Oct 2004 14:10:31 -0400 Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9THtes3012825 for ; Fri, 29 Oct 2004 10:55:40 -0700 (PDT) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9THtdqq637416 for ; Fri, 29 Oct 2004 10:55:39 -0700 (PDT) Message-ID: <4182830B.9000609@sun.com> Date: Fri, 29 Oct 2004 13:51:07 -0400 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040907 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: Subject: SPNEGO draft comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 4352 Lines: 115 My thoughts on the new SPNEGO draft... Many of my comments are editorial, just trying to make it easier to read. The original SPNEGO RFC was very difficult to read and follow in many places and we should strive to make this draft easier to read and thus to implement. Where are the SOMIC rules? Is that a separate document or something? -Wyllys Ingersoll 3.1 paragraph 3 - Seems contradictory when read the first time, could it be rewritten to be a little. clearer ? My suggestion... The first negotiation token sent by the acceptor contains the result of the negotiation (accept_completed, accept_incomplete or reject) and, in case of accept, the agreed security mechanism. If the first proposed mechanism from the initiator was selected and the initiator included an initial mechanism token, the response MUST include the response mechanism token. Otherwise, the target will not emit a response mechanism token in the first reply. 3.2 (d)(I) Would it add security if the GSS_GetMIC covered other fields from the NegTokenInit such as the reqFlags? 3.2 (d)(I)(2) garbled and unnecessarily verbose... Rewrite suggestion... 2) If the initiator's preferred mechanism is accepted and policy exists on the target such that a different mechanism couuld have been selected given a different list of mechanisms, GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and a MIC MUST be generated by the target. This MIC is to be verified by the initiator and the result will be sent back to the acceptor. This is referred in this document as the Safe to Omit MIC (SOMIC) rule number 2. The resulting negotiation token MUST include the security token if one is returned by the selected mechanism. 3.2 (d) (III) s/mechanism is sent/mechanism was sent/ s/token need to be transferred/token needs to be transferred/ s/establish the context,/establish the context./ 3.2 (e) - is this paragraph necessary? All of the scenarios from 3.2 (d) already explain that the target app must return the negotiation token to the intiator. 3.2 (f) (III) When you say "deposit the security token" - what does this mean, where is it being deposited? The rest of this section is a little unclear as well. suggestion... When the negotiation token carries a reject result with a response security token, the initiator MUST deposit the security token. GSS_Init_sec_context() MUST indicate a failure status as reported by the underlying mechanism, and the mech_type output parameter from GSS_Init_sec_context must indicate the mechanism that was rejected. 3.2 (f) (IV) s/complete context establishment,/complete context establishment./ 3.2 (f) (V) s/mechanism token/mechanism tokens/ s/establishment, the/establishment. The/ 3.2 (h) Perhaps clarify that the "mech_type" output param is for the GSS_Init_sec_context call. Its easy to become disoriented with all of the various talk of "mech types" being passed around. 4.2.2 paragraph 6 under "negResult" is a little confusing. suggestion... For those targets that support piggybacking the initial mechToken, an optimistic negotiation response is possible. This response includes a responseToken which MAY continue the authentication exchange (e.g. when mutual authentication has been requested or when unilateral authentication requires several round trips). Otherwise the responseToken is used to carry the tokens specific to the mechanism selected. 4.2.2 paragraph 7 - The MIC should include the reqFlags as well as the MechTypes. Appendix A paragraph 1 s/should be ale/should be able/ Under what circumstance would an app NOT do optimistic negotiation? I'm sure there are examples, but maybe it would be good to document a situation where optimistic negotiation could not be used. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Oct 29 19:38:18 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 29 Oct 2004 19:38:17 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 6218A1383E for ; Fri, 29 Oct 2004 19:38:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgCF-0007Qq-BQ; Fri, 29 Oct 2004 19:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNg4k-0001KG-99 for kitten@megatron.ietf.org; Fri, 29 Oct 2004 19:22:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25389 for ; Fri, 29 Oct 2004 19:22:27 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNgJ4-0005O2-7f for kitten@ietf.org; Fri, 29 Oct 2004 19:37:21 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 16:21:55 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 16:21:54 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 16:21:58 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1110); Fri, 29 Oct 2004 16:21:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2004 16:21:53 -0700 Message-ID: Thread-Topic: SPNEGO draft comments thread-index: AcS94cE9cDGCNna8SUaHm7qvcu5F3AAKX3iw From: "Liqiang(Larry) Zhu" To: "Wyllys Ingersoll" , , "Sam Hartman" X-OriginalArrivalTime: 29 Oct 2004 23:21:27.0113 (UTC) FILETIME=[0385B390:01C4BE0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: SPNEGO draft comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 5308 Lines: 166 Wyllys, Sam, and Martin provided excellent comments; some of the points raised are somewhat controversial.=20 Since this is the first version, I suggest that I would compile a list of issues so far and try to arrange hall-way meetings at Washington DC with Wyllys, Sam, and Martin and go over the list in person. Martin, are you going to meet us at the DC? Any other folks who are interested in the discussion are welcome to join, in that case, please drop me an email. I would expect the next version that is based on these comments should be out shortly after IETF61. Thanks, -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Wyllys Ingersoll Sent: Friday, October 29, 2004 10:51 AM To: kitten@ietf.org Subject: SPNEGO draft comments My thoughts on the new SPNEGO draft... Many of my comments are editorial, just trying to make it easier to read. The original SPNEGO RFC was very difficult to read and follow in many places and we should strive to make this draft easier to read and thus to implement. Where are the SOMIC rules? Is that a separate document or something? -Wyllys Ingersoll 3.1 paragraph 3 - Seems contradictory when read the first time, could it be rewritten to be a little. clearer ? My suggestion... The first negotiation token sent by the acceptor contains the result of the negotiation (accept_completed, accept_incomplete or reject) and, in case of accept, the agreed security mechanism. If the first proposed mechanism from the initiator was selected and the initiator included an initial mechanism token, the response MUST include the response mechanism token. Otherwise, the target will not emit a response mechanism token in the first reply. 3.2 (d)(I) Would it add security if the GSS_GetMIC covered other fields from the NegTokenInit such as the reqFlags? 3.2 (d)(I)(2) garbled and unnecessarily verbose... Rewrite suggestion... 2) If the initiator's preferred mechanism is accepted and policy exists on the target such that a different mechanism couuld have been selected given a different list of mechanisms, GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and a MIC MUST be generated by the target. This MIC is to be verified by the initiator and the result will be sent back to the acceptor. This is referred in this document as the Safe to Omit MIC (SOMIC) rule number 2. The resulting negotiation token MUST include the security token if one is returned by the selected mechanism. 3.2 (d) (III) s/mechanism is sent/mechanism was sent/ s/token need to be transferred/token needs to be transferred/ s/establish the context,/establish the context./ 3.2 (e) - is this paragraph necessary? All of the scenarios from 3.2 (d) already explain that the target app must return the negotiation token to the intiator. 3.2 (f) (III) When you say "deposit the security token" - what does this mean, where is it being deposited? The rest of this section is a little unclear as well. suggestion... When the negotiation token carries a reject result with a response security token, the initiator MUST deposit the security token. GSS_Init_sec_context() MUST indicate a failure status as reported by the underlying mechanism, and the mech_type output parameter from GSS_Init_sec_context must indicate the mechanism that was rejected. 3.2 (f) (IV) s/complete context establishment,/complete context establishment./ 3.2 (f) (V) s/mechanism token/mechanism tokens/ s/establishment, the/establishment. The/ 3.2 (h) Perhaps clarify that the "mech_type" output param is for the GSS_Init_sec_context call. Its easy to become disoriented with all of the various talk of "mech types" being passed around. 4.2.2 paragraph 6 under "negResult" is a little confusing. suggestion... For those targets that support piggybacking the initial mechToken, an optimistic negotiation response is possible. This response includes a responseToken which MAY continue the authentication exchange (e.g. when mutual authentication has been requested or when unilateral authentication requires several round trips). Otherwise the responseToken is used to carry the tokens specific to the mechanism selected. 4.2.2 paragraph 7 - The MIC should include the reqFlags as well as the MechTypes. Appendix A paragraph 1 s/should be ale/should be able/ Under what circumstance would an app NOT do optimistic negotiation? I'm sure there are examples, but maybe it would be good to document a situation where optimistic negotiation could not be used. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Oct 29 20:02:46 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 29 Oct 2004 20:02:45 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 60C9F1383E for ; Fri, 29 Oct 2004 20:02:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgb7-0008Uy-Ly; Fri, 29 Oct 2004 19:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgNM-0007Nw-5O for kitten@megatron.ietf.org; Fri, 29 Oct 2004 19:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26499 for ; Fri, 29 Oct 2004 19:41:41 -0400 (EDT) Received: from brazilnut.cc.columbia.edu ([128.59.206.18] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNgbj-0005ix-T7 for kitten@ietf.org; Fri, 29 Oct 2004 19:56:36 -0400 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i9TNfgPY000248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 29 Oct 2004 19:41:43 -0400 (EDT) Message-ID: <4182D550.6000700@columbia.edu> Date: Fri, 29 Oct 2004 19:42:08 -0400 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Subject: Re: SPNEGO draft comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384385780==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 11329 Lines: 273 This is a cryptographically signed message in MIME format. --===============0384385780== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207060007040803060301" This is a cryptographically signed message in MIME format. --------------ms030207060007040803060301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I would like to see the list of issues be published to the mailing list and the positions explained at the Kitten meeting during the SPNEGO time slot. Hallway discussions can take place afterwards. Thanks. Jeffrey Altman Liqiang(Larry) Zhu wrote: > Wyllys, Sam, and Martin provided excellent comments; some of the points > raised are somewhat controversial. > > Since this is the first version, I suggest that I would compile a list > of issues so far and try to arrange hall-way meetings at Washington DC > with Wyllys, Sam, and Martin and go over the list in person. Martin, > are you going to meet us at the DC? > > Any other folks who are interested in the discussion are welcome to > join, in that case, please drop me an email. > > I would expect the next version that is based on these comments should > be out shortly after IETF61. > > Thanks, > > > -- Larry > > -----Original Message----- > From: kitten-bounces@lists.ietf.org > [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Wyllys Ingersoll > Sent: Friday, October 29, 2004 10:51 AM > To: kitten@ietf.org > Subject: SPNEGO draft comments > > > My thoughts on the new SPNEGO draft... > > Many of my comments are editorial, just trying to make it easier to > read. > The original SPNEGO RFC was very difficult to read and follow in many > places and we should strive to make this draft easier to read and thus > to implement. > > Where are the SOMIC rules? Is that a separate document or something? > > -Wyllys Ingersoll > > > 3.1 paragraph 3 - > Seems contradictory when read the first time, could it be rewritten > to be a little. > clearer ? > My suggestion... > > The first negotiation token sent by the acceptor contains the > result > of the negotiation (accept_completed, accept_incomplete or > reject) > and, in case of accept, the agreed security mechanism. If > the first > proposed mechanism from the initiator was selected and the > initiator > included an initial mechanism token, the response MUST > include the > response mechanism token. Otherwise, the target will not > emit a > response mechanism token in the first reply. > > > 3.2 (d)(I) > Would it add security if the GSS_GetMIC covered other fields from > the > NegTokenInit such as the reqFlags? > > 3.2 (d)(I)(2) garbled and unnecessarily verbose... > Rewrite suggestion... > 2) If the initiator's preferred mechanism is accepted and > policy exists on the target such that a different > mechanism couuld have been selected given a different list > of > mechanisms, GSS_Accept_sec_context() MUST indicate > GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and > a MIC MUST be generated by the target. This MIC is to be > verified by the initiator and the result will be sent back > to the acceptor. This is referred in this document as the > Safe to Omit MIC (SOMIC) rule number 2. The resulting > negotiation token MUST include the security token if one is > returned by the selected mechanism. > > 3.2 (d) (III) > s/mechanism is sent/mechanism was sent/ > s/token need to be transferred/token needs to be transferred/ > s/establish the context,/establish the context./ > > 3.2 (e) - is this paragraph necessary? All of the scenarios from 3.2 > (d) > already explain that the target app must return the negotiation > token to the > intiator. > > 3.2 (f) (III) > When you say "deposit the security token" - what does this mean, > where is > it being deposited? The rest of this section is a little unclear > as well. > suggestion... > > When the negotiation token carries a reject result with a > response security token, the initiator MUST deposit the > security token. GSS_Init_sec_context() MUST indicate a > failure status as reported by the underlying mechanism, and > the > mech_type output parameter from GSS_Init_sec_context must > indicate the mechanism that was rejected. > > 3.2 (f) (IV) > s/complete context establishment,/complete context > establishment./ > > 3.2 (f) (V) > s/mechanism token/mechanism tokens/ > s/establishment, the/establishment. The/ > > 3.2 (h) Perhaps clarify that the "mech_type" output param is for the > GSS_Init_sec_context call. Its easy to become disoriented with all > of the > various talk of "mech types" being passed around. > > 4.2.2 paragraph 6 under "negResult" is a little confusing. > suggestion... > > For those targets that support piggybacking the initial > mechToken, an optimistic negotiation response is possible. > This > response includes a responseToken which MAY continue the > authentication exchange (e.g. when mutual authentication has > been requested or when unilateral authentication requires > several round trips). Otherwise the responseToken is used to > carry the tokens specific to the mechanism selected. > > 4.2.2 paragraph 7 - The MIC should include the reqFlags as well as the > MechTypes. > > Appendix A paragraph 1 > s/should be ale/should be able/ > > > > > > > > > > > > > > > Under what circumstance would an app NOT do optimistic negotiation? I'm > sure there are examples, but maybe it would be good to document a > situation where optimistic negotiation could not be used. > > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms030207060007040803060301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMDI5MjM0MjA4WjAjBgkqhkiG9w0BCQQxFgQUz+y5CIB4dZJApljR21SC+X6kTdgw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAFGYQPSyBl+UZndEmb4xHE/dnMn1QkfeUzgo2MdY6 ItA7AscMUM9oIlm/trQ1evp9FrIkz+E89M7AN/kCx99E7D/MDMgrCSw3hHX66FgE0VissNzF 6k/gd3E8AkgaD7iquS73CQGnvepbz8u36rHRszfIn2/6Zc/JGPCf8M5FFRwBNVtMOUnj99cZ fbxB8tD1fp7CDH5lvbDq5VsZbSqQKkw8GMCED7iLqs9WJgBOP2jmRGjGXAw055Mf4kSMbt3F xpmuci4OIy540jyi6A1nsrSdZ+pmqCNEyJOU3tzoVCkX0nGLvx+JlEgOH5jePVsHZ8+Q2SVs fQW/3dvgpCtLdgAAAAAAAA== --------------ms030207060007040803060301-- --===============0384385780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0384385780==-- From kitten-bounces@lists.ietf.org Fri Oct 29 22:46:47 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 29 Oct 2004 22:46:46 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 6B67E1383E for ; Fri, 29 Oct 2004 22:46:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNjE6-0000Ec-Gr; Fri, 29 Oct 2004 22:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNj3A-0004Xr-L9 for kitten@megatron.ietf.org; Fri, 29 Oct 2004 22:33:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05629 for ; Fri, 29 Oct 2004 22:33:01 -0400 (EDT) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNjHX-0008Oh-Ei for kitten@ietf.org; Fri, 29 Oct 2004 22:47:56 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id i9U2WHB9062634; Sat, 30 Oct 2004 12:32:17 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id i9U2WHGt062633; Sat, 30 Oct 2004 12:32:17 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200410300232.i9U2WHGt062633@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lzhu@windows.microsoft.com Date: Sat, 30 Oct 2004 12:32:16 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: kitten@ietf.org, hartmans@mit.edu Subject: RE: SPNEGO draft comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 5936 Lines: 185 Is the draft going to specify GSS_C_EXPECTING_MECH_LIST_MIC_FLAG? -- Luke >From: "Liqiang\(Larry\) Zhu" >Subject: RE: SPNEGO draft comments >To: "Wyllys Ingersoll" , , "Sam Hartman" > >Date: Fri, 29 Oct 2004 16:21:53 -0700 > >Wyllys, Sam, and Martin provided excellent comments; some of the points >raised are somewhat controversial. > >Since this is the first version, I suggest that I would compile a list >of issues so far and try to arrange hall-way meetings at Washington DC >with Wyllys, Sam, and Martin and go over the list in person. Martin, >are you going to meet us at the DC? > >Any other folks who are interested in the discussion are welcome to >join, in that case, please drop me an email. > >I would expect the next version that is based on these comments should >be out shortly after IETF61. > >Thanks, > > >-- Larry > >-----Original Message----- >From: kitten-bounces@lists.ietf.org >[mailto:kitten-bounces@lists.ietf.org] On Behalf Of Wyllys Ingersoll >Sent: Friday, October 29, 2004 10:51 AM >To: kitten@ietf.org >Subject: SPNEGO draft comments > > >My thoughts on the new SPNEGO draft... > >Many of my comments are editorial, just trying to make it easier to >read. >The original SPNEGO RFC was very difficult to read and follow in many >places and we should strive to make this draft easier to read and thus >to implement. > >Where are the SOMIC rules? Is that a separate document or something? > >-Wyllys Ingersoll > > >3.1 paragraph 3 - > Seems contradictory when read the first time, could it be rewritten >to be a little. > clearer ? > My suggestion... > > The first negotiation token sent by the acceptor contains the >result > of the negotiation (accept_completed, accept_incomplete or >reject) > and, in case of accept, the agreed security mechanism. If >the first > proposed mechanism from the initiator was selected and the >initiator > included an initial mechanism token, the response MUST >include the > response mechanism token. Otherwise, the target will not >emit a > response mechanism token in the first reply. > > >3.2 (d)(I) > Would it add security if the GSS_GetMIC covered other fields from >the > NegTokenInit such as the reqFlags? > >3.2 (d)(I)(2) garbled and unnecessarily verbose... > Rewrite suggestion... > 2) If the initiator's preferred mechanism is accepted and > policy exists on the target such that a different > mechanism couuld have been selected given a different list >of > mechanisms, GSS_Accept_sec_context() MUST indicate > GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and > a MIC MUST be generated by the target. This MIC is to be > verified by the initiator and the result will be sent back > to the acceptor. This is referred in this document as the > Safe to Omit MIC (SOMIC) rule number 2. The resulting > negotiation token MUST include the security token if one is > returned by the selected mechanism. > >3.2 (d) (III) > s/mechanism is sent/mechanism was sent/ > s/token need to be transferred/token needs to be transferred/ > s/establish the context,/establish the context./ > >3.2 (e) - is this paragraph necessary? All of the scenarios from 3.2 >(d) > already explain that the target app must return the negotiation >token to the > intiator. > >3.2 (f) (III) > When you say "deposit the security token" - what does this mean, >where is > it being deposited? The rest of this section is a little unclear >as well. > suggestion... > > When the negotiation token carries a reject result with a > response security token, the initiator MUST deposit the > security token. GSS_Init_sec_context() MUST indicate a > failure status as reported by the underlying mechanism, and >the > mech_type output parameter from GSS_Init_sec_context must > indicate the mechanism that was rejected. > >3.2 (f) (IV) > s/complete context establishment,/complete context >establishment./ > >3.2 (f) (V) > s/mechanism token/mechanism tokens/ > s/establishment, the/establishment. The/ > >3.2 (h) Perhaps clarify that the "mech_type" output param is for the > GSS_Init_sec_context call. Its easy to become disoriented with all >of the > various talk of "mech types" being passed around. > >4.2.2 paragraph 6 under "negResult" is a little confusing. > suggestion... > > For those targets that support piggybacking the initial > mechToken, an optimistic negotiation response is possible. >This > response includes a responseToken which MAY continue the > authentication exchange (e.g. when mutual authentication has > been requested or when unilateral authentication requires > several round trips). Otherwise the responseToken is used to > carry the tokens specific to the mechanism selected. > >4.2.2 paragraph 7 - The MIC should include the reqFlags as well as the >MechTypes. > >Appendix A paragraph 1 > s/should be ale/should be able/ > > > > > > > > > > > > > > >Under what circumstance would an app NOT do optimistic negotiation? I'm >sure there are examples, but maybe it would be good to document a >situation where optimistic negotiation could not be used. > > >_______________________________________________ >Kitten mailing list >Kitten@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/kitten > >_______________________________________________ >Kitten mailing list >Kitten@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/kitten > -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Nov 5 04:11:56 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 05 Nov 2004 04:11:56 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 4EF101315D for ; Fri, 5 Nov 2004 04:11:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ079-0003dE-Qf; Fri, 05 Nov 2004 04:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ064-0003S5-Fn for kitten@megatron.ietf.org; Fri, 05 Nov 2004 04:09:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18735 for ; Fri, 5 Nov 2004 04:09:26 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0Ll-0005Wd-Qy for kitten@ietf.org; Fri, 05 Nov 2004 04:25:42 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 01:08:56 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 01:08:39 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 01:09:04 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 01:08:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 01:08:51 -0800 Message-ID: Thread-Topic: Comments on Larry's SPNEGO draft thread-index: AcTCtz0fQfly7V4NRn25nDdZOmDX1gAXzsKg From: "Liqiang(Larry) Zhu" To: , "Sam Hartman" X-OriginalArrivalTime: 05 Nov 2004 09:08:52.0857 (UTC) FILETIME=[1219EE90:01C4C317] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 2172 Lines: 61 Martin Rex wrote: > So you're correct, implementations of SPNEGO that receive an initial=20 > security context token from a non-IETF >(gssapi) mechanism that lacks=20 > the generic framing will likely return GSS_S_DEFECTIVE_TOKEN rather=20 > than >=20 > GSS_S_BAD_MECHANISM. The decision clearly should not be made by SPNEGO but by the underlying mechanisms. Please stay on the track, and the current draft only dicusses mechanisms that are fully compliant with 2743/2744. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Thursday, November 04, 2004 1:18 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft Ooops -- blush. You're correct, Sam. Sam Hartman wrote: >=20 > Martin> The initial context token MUST use the generic framing > Martin> with the mechanism OID for the precise reason that a > Martin> gssapi mechanism will be able to recognize whether it > Martin> supports communication with the peer or not. =20 >=20 > Section 3.1 of RFC 2743 requires a specific context token framing for=20 > IETF standards-track mechanisms. However no such requirement is made=20 > for non-standards-track mechanisms. We're aware of non-standards=20 > track mechanisms that do not use the framing described in this=20 > section. And if I'm not mistaken, then there is actually a large installed base of an SPNEGO implementation that may send security context tokens from a non-IETF "mechanism" which does not use the generic token framing. That "mechanism" is also known as Microsoft "NT Lan Manager" (NTLM). So you're correct, implementations of SPNEGO that receive an initial security context token from a non-IETF (gssapi) mechanism that lacks the generic framing will likely return GSS_S_DEFECTIVE_TOKEN rather than GSS_S_BAD_MECHANISM. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Nov 5 12:51:52 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 05 Nov 2004 12:51:52 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id AD51013226 for ; Fri, 5 Nov 2004 12:51:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ8CR-0005Vz-Kd; Fri, 05 Nov 2004 12:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7v5-0001Tb-DF for kitten@megatron.ietf.org; Fri, 05 Nov 2004 12:30:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00869 for ; Fri, 5 Nov 2004 12:30:37 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ8As-00087s-50 for kitten@ietf.org; Fri, 05 Nov 2004 12:46:58 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 09:30:08 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 09:30:07 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 09:29:55 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 09:30:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 09:30:05 -0800 Message-ID: Thread-Topic: Comments on Larry's SPNEGO draft thread-index: AcTDPYJHK6Q8mJ05Q3iqN6AheY/RHgAHtxew From: "Liqiang(Larry) Zhu" To: X-OriginalArrivalTime: 05 Nov 2004 17:30:06.0939 (UTC) FILETIME=[17A6AAB0:01C4C35D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, hartmans@mit.edu Subject: RE: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 2044 Lines: 60 Martin Rex wrote: > SPNEGO should *NEVER* rely on trial and error.=20 I agree, but is this relevant to the current draft? It is certainly not what our current implementations do either. I would be happy to explain to you what are the additional mechanisms we have in order to be backward compatible with NT4, but please take that kind of discussions off the list. -- larry -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Friday, November 05, 2004 5:44 AM To: Liqiang(Larry) Zhu Cc: martin.rex@sap.com; hartmans@mit.edu; kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft Liqiang\ wrote: >=20 > Martin Rex wrote: > > So you're correct, implementations of SPNEGO that receive an initial > > security context token from a non-IETF >(gssapi) mechanism that=20 > > lacks the generic framing will likely return GSS_S_DEFECTIVE_TOKEN=20 > > rather than > GSS_S_BAD_MECHANISM. >=20 > The decision clearly should not be made by SPNEGO but by the=20 > underlying mechanisms. I disagree. SPNEGO should *NEVER* rely on trial and error. When gss_accept_sec_context is called for the first time, SPNEGO does not know to which underlying gssapi mechanims it should pass the received initial context token, because the input security context handle is still undefined. So SPNEGO MUST try to decode the token to get the hands on the mechanism OID in order to decide which mechanism to pass the data to. And only if an SPNEGO knows about a non-IETF gssapi mechanism which it serves then it could blindly pass on a token that lacks the generic framing. >=20 > Please stay on the track, and the current draft only dicusses=20 > mechanisms that are fully compliant with 2743/2744. Which is no longer practical, since some vendor created a large installed base of SPNEGO that will pass on security context token which lacks the generic context token framing... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 19:53:21 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 19:53:19 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id B8D6C1324F for ; Mon, 25 Oct 2004 19:53:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO2-0007B2-Mp; Mon, 25 Oct 2004 19:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBoH-0007jx-9c for kitten@megatron.ietf.org; Mon, 25 Oct 2004 16:51:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08109 for ; Mon, 25 Oct 2004 16:51:17 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMC1m-0000aa-DB for kitten@ietf.org; Mon, 25 Oct 2004 17:05:18 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9PKpINH018022 for ; Mon, 25 Oct 2004 14:51:19 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i9PKpIjW018785 for ; Mon, 25 Oct 2004 14:51:18 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9PKovd8019720 for ; Mon, 25 Oct 2004 15:50:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9PKovDv019719 for kitten@ietf.org; Mon, 25 Oct 2004 15:50:57 -0500 (CDT) Date: Mon, 25 Oct 2004 15:50:57 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20041025205057.GF19142@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Subject: Comments on draft-hartman-gss-naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: O Content-Length: 4885 Lines: 133 - Section 1 (intro) See my comments today about mechs that lack a single canonical name. Namely, I don't agree that this is a real problem. I do believe that there are problems to be solved in this space, namely: - Some mechanisms, e.g., Kerberos V, do not map well onto the GSS-API's name canonicalization model, as you describe in section 2. - How to get away from name-based access control? The referential integrity problem of how to keep name-based ACLs up to date as names are changed, deleted, re-used, is real and must be addressed. The simplest way is to use internal identifiers, such as POSIX UIDs and GIDs and Windows SIDs, instead of names, in ACLs. The good news is that your name attribute proposal is part of the solution, in my view. I think this problem should be front and center, as well as: - How to access Kerberos V ticket/authenticator authorization-data and x.509 certificate extensions (and SPKM authorization-data)? Similarly, IMO your name attribute proposal is part of the solution. The name selection problem for mechs whose credentials may respond to multiple names is, IMO, partly a mechanism-specific problem (in that the mechs' context tokens had better assert one or another such name; if SPKM doesn't, well, that'd be bad news...), and partly an implementation-specific problem (in that the implementation should somehow select a name for use as the name of the credential that corresponds to GSS_C_NO_CREDENTIAL; the mechs' specifications can help here too). - Section 2 (Kerberos Naming) I agree, the Kerberos mechanism does not allow for reliable canonicalization of query names without access to credentials suitable for the purpose. This is a serious problem for applications that utilize name-based authorization. This calls for a GSS_Canonicalize_name() extension that takes a credential handle as an input, though that is no panacea, as the rest of your text makes clear. Ultimately only MNs output by GSS_Inquire_sec_context() may useful for name-based authorization, and only as long as one is aware of the resulting referential integrity problem with using names, rather than UIDs/GIDs/SIDs/... for authorization. The other items in this section, in the 3rd and 4th paragraphs are generic though. - Section 3 (x.509 Names) See above. - Section 4.1, 1st paragraph Not only acceptors, but initiators also. - Section 4.1, 2nd paragraph Not only mechanism-specific, but platform-specific also. I.e., "internal" IDs like POSIX UIDs/GIDs and Windows SIDs are specific to platforms, not mechanisms. - Section 4.3 IMO, most of the name attributes that folks will be interested in have generic representations or can be treated generically or, failing that, in platform-specific ways. Mechanisms's context tokens should not assert name attributes that cannot be validated nor should peers accept such assertions without validating them. Because the assertions may be tied to the credentials, rather than the contexts (this is the distinction between authorization-data in Kerberos Tickets and Authenticators) name attributes need not always be asserted explicitly. Thus, w.r.t. your name attribute source tagging proposal I see two such sources: the credential, and the peer; for the latter there's really only two sub-variants: unvalidated, and validated -- how is probably not important to GSS applications. Finally, composite names (names w/ attributes) need an exported form for transfer between processes. This is different from, and should not be confounded with the exported name form in the GSS-APIv2. - Section 4.3 It would be nice to have a GSS_Inquire_name() API which is a superset of GSS_Display_name() and which includes information such as: - whether the name is an MN and, if so, the mech's OID - the source of the name (an established context, an exported name re-imported, a canonicalized query name, just a query name) - where applicable, the name type OID used to import the name - Section 5 Note that if a credential is acquired for a composite name then the credential may also "carry" the given name's attributes. The semantics here need to be specified: must the credential carry all such name attributes, where applicable? or may it carry some or even none? Is an extended GSS_Acquire/Add_cred() API necessary? - Section 6 I see this as applicable primarily to machine UID/GID and similar names for which concrete mechs may not have MNs. Thanks, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Oct 25 20:43:09 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 25 Oct 2004 20:43:07 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 988411324F for ; Mon, 25 Oct 2004 20:43:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFPU-0003gw-C0; Mon, 25 Oct 2004 20:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFLY-0002m6-4L for kitten@megatron.ietf.org; Mon, 25 Oct 2004 20:37:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25166 for ; Mon, 25 Oct 2004 20:37:53 -0400 (EDT) Received: from stratton-four-twenty-nine.mit.edu ([18.187.6.174] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFZ5-0005pz-Be for kitten@ietf.org; Mon, 25 Oct 2004 20:51:56 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 643BE178024; Mon, 25 Oct 2004 20:38:05 -0400 (EDT) To: Nicolas Williams References: <20041025205057.GF19142@binky.central.sun.com> From: Sam Hartman Date: Mon, 25 Oct 2004 20:38:05 -0400 In-Reply-To: <20041025205057.GF19142@binky.central.sun.com> (Nicolas Williams's message of "Mon, 25 Oct 2004 15:50:57 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org Subject: Re: Comments on draft-hartman-gss-naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1635 Lines: 40 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> - Section 1 (intro) See my comments today about mechs Nicolas> that lack a single canonical name. Namely, I don't agree Nicolas> that this is a real problem. I think your comments are only sufficient to convince me that we can solve the problem, not that it doesn't exist. In all the cases you discussed today, we're significantly changing semantics from what GSSAPI v2 expects. I agree that we will in almost all cases end up with solutions where gss_export_name does something. I suspect in many cases that will not be a good enough something that a GSSAPI V2 application will work well; they wll often limp along. You seem to be more willing to accept platform or implementation-specific solutions to the canonical name problem than I am. Actually I'm not sure that I'm unwilling to accept these solutions, but I'm sure we need to explore the problem space more thoroughly before doing so. In summary, I'm working towards a broad description of what we are considering with naming. I want to have a single document that captures the goals we are trying to meet and the solutions we propose to meet those goals. If you end up believing that one of the goals ends up being a non-goal, that's probably OK. When we get to the end and ask ourselves whether we've met our goals, you can argue that the weight of things you believe to be non-goals in the evaluation should be very low. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Oct 26 11:22:58 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 26 Oct 2004 11:22:58 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 08E6013226 for ; Tue, 26 Oct 2004 11:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMT87-00008D-SW; Tue, 26 Oct 2004 11:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMT4o-0007m0-8K for kitten@megatron.ietf.org; Tue, 26 Oct 2004 11:17:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13126 for ; Tue, 26 Oct 2004 11:17:31 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTIT-000571-5P for kitten@ietf.org; Tue, 26 Oct 2004 11:31:42 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i9QFHTs3025829 for ; Tue, 26 Oct 2004 08:17:30 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i9QFHTjW027672 for ; Tue, 26 Oct 2004 09:17:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9QFH7NF020264; Tue, 26 Oct 2004 10:17:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9QFH6M9020263; Tue, 26 Oct 2004 10:17:06 -0500 (CDT) Date: Tue, 26 Oct 2004 10:17:06 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20041026151706.GI21427@binky.central.sun.com> References: <20041025205057.GF19142@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: kitten@ietf.org Subject: Re: Comments on draft-hartman-gss-naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 3048 Lines: 68 On Mon, Oct 25, 2004 at 08:38:05PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> - Section 1 (intro) See my comments today about mechs > Nicolas> that lack a single canonical name. Namely, I don't agree > Nicolas> that this is a real problem. > > I think your comments are only sufficient to convince me that we can > solve the problem, not that it doesn't exist. > > In all the cases you discussed today, we're significantly changing > semantics from what GSSAPI v2 expects. One semantic problem in the GSS-APIv2 that is related to this is the fact that the Kerberos V mechanism requires credentials in order to canonicalize names, and another is that a mechanism might not be able to produce useful MNs except for established security contexts. Ok, you convince me that there is a problem, but then I still see it as separate from, though perhaps related to, the name-based authorization problem; I think both should be given top billing in the abstract and introduction :) > I agree that we will in almost all cases end up with solutions where > gss_export_name does something. I suspect in many cases that will not > be a good enough something that a GSSAPI V2 application will work > well; they wll often limp along. Indeed. The reason I insist on exported name tokens for names like machine UID which may not be MNs is so that existing ACL facilicities can be adapted with minimal ACL format change, but the apps will definitely require v3 features to take advantage of this (since v2 provides no way to discover the machine UID names associated with a given MN). > You seem to be more willing to accept platform or > implementation-specific solutions to the canonical name problem than I > am. Actually I'm not sure that I'm unwilling to accept these > solutions, but I'm sure we need to explore the problem space more > thoroughly before doing so. Yes, but those solutions are just for the single canonical name problem, not for the > In summary, I'm working towards a broad description of what we are > considering with naming. I want to have a single document that > captures the goals we are trying to meet and the solutions we propose > to meet those goals. If you end up believing that one of the goals > ends up being a non-goal, that's probably OK. When we get to the end > and ask ourselves whether we've met our goals, you can argue that the > weight of things you believe to be non-goals in the evaluation should > be very low. I'd like to start seeing some concrete interface proposals. I think some aspects of the GSS naming problems and some aspects of the solutions we're working towards have received enough thought that it would be helpful to see what interfaces might result; if nothing else it would help me. I can volunteer to produce some interface designs if you wish. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Oct 26 12:14:01 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 26 Oct 2004 12:13:59 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 25AAF13226 for ; Tue, 26 Oct 2004 12:13:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTvF-0003by-3U; Tue, 26 Oct 2004 12:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTt0-0002PE-3O for kitten@megatron.ietf.org; Tue, 26 Oct 2004 12:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18912 for ; Tue, 26 Oct 2004 12:09:23 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMU6g-0006WR-2S for kitten@ietf.org; Tue, 26 Oct 2004 12:23:35 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id AEEFEE0053; Tue, 26 Oct 2004 12:09:36 -0400 (EDT) To: Nicolas Williams References: <20041025205057.GF19142@binky.central.sun.com> <20041026151706.GI21427@binky.central.sun.com> From: Sam Hartman Date: Tue, 26 Oct 2004 12:09:36 -0400 In-Reply-To: <20041026151706.GI21427@binky.central.sun.com> (Nicolas Williams's message of "Tue, 26 Oct 2004 10:17:06 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org Subject: Re: Comments on draft-hartman-gss-naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 1503 Lines: 35 >>>>> "Nicolas" == Nicolas Williams writes: >> In summary, I'm working towards a broad description of what we >> are considering with naming. I want to have a single document >> that captures the goals we are trying to meet and the solutions >> we propose to meet those goals. If you end up believing that >> one of the goals ends up being a non-goal, that's probably OK. >> When we get to the end and ask ourselves whether we've met our >> goals, you can argue that the weight of things you believe to >> be non-goals in the evaluation should be very low. Nicolas> I'd like to start seeing some concrete interface Nicolas> proposals. I think some aspects of the GSS naming Nicolas> problems and some aspects of the solutions we're working Nicolas> towards have received enough thought that it would be Nicolas> helpful to see what interfaces might result; if nothing Nicolas> else it would help me. I completely agree that we're at a point where we could do this work and that it would be quite beneficial. I also think what I'm trying to do is reasonably beneficial. My goal is to have a document we can last call shortly after DC and publish as informational that describes what we're doing and limits scope of possible solutions. Does this seem worth doing? --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Oct 26 12:33:54 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 26 Oct 2004 12:33:54 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 535AC13226 for ; Tue, 26 Oct 2004 12:33:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMU9z-00085S-Fd; Tue, 26 Oct 2004 12:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMU6X-0007On-Pj for kitten@megatron.ietf.org; Tue, 26 Oct 2004 12:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20137 for ; Tue, 26 Oct 2004 12:23:23 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUKE-0006nC-Dr for kitten@ietf.org; Tue, 26 Oct 2004 12:37:35 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9QGNONH009365 for ; Tue, 26 Oct 2004 10:23:24 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i9QGNLJf002550 for ; Tue, 26 Oct 2004 10:23:21 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id i9QGMx8t020317; Tue, 26 Oct 2004 11:22:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id i9QGMxaA020316; Tue, 26 Oct 2004 11:22:59 -0500 (CDT) Date: Tue, 26 Oct 2004 11:22:58 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20041026162258.GM21427@binky.central.sun.com> References: <20041025205057.GF19142@binky.central.sun.com> <20041026151706.GI21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org Subject: Re: Comments on draft-hartman-gss-naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 713 Lines: 20 On Tue, Oct 26, 2004 at 12:09:36PM -0400, Sam Hartman wrote: > I completely agree that we're at a point where we could do this work > and that it would be quite beneficial. > > I also think what I'm trying to do is reasonably beneficial. My goal > is to have a document we can last call shortly after DC and publish as > informational that describes what we're doing and limits scope of > possible solutions. Does this seem worth doing? Oh yes, much like my guide to the v3 work, this sort of document can be quite useful apart from actual, concrete proposals. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Oct 27 16:41:09 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 27 Oct 2004 16:41:09 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 46C24131D0 for ; Wed, 27 Oct 2004 16:41:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuZZ-00057y-NW; Wed, 27 Oct 2004 16:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMuJv-0000a8-P7 for kitten@megatron.ietf.org; Wed, 27 Oct 2004 16:22:59 -0400 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.206.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10050 for ; Wed, 27 Oct 2004 16:22:56 -0400 (EDT) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i9RKMtm7025187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 27 Oct 2004 16:22:56 -0400 (EDT) Message-ID: <418003C1.9010102@columbia.edu> Date: Wed, 27 Oct 2004 16:23:29 -0400 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Cc: Subject: Mailing List problems X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810040034==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 6825 Lines: 134 This is a cryptographically signed message in MIME format. --===============0810040034== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030800090509010200080500" This is a cryptographically signed message in MIME format. --------------ms030800090509010200080500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just want to make the membership of this list aware that I am aware of the following mailing list difficulties. Apparently for some unknown number of days or weeks it has not been possible to register for the list either via the web page https://www1.ietf.org/mailman/listinfo/kitten or via the mail address kitten-request@ietf.org Apparently, the requests are received by mailman but the responses from mailman to the requestor are not be sent out. This has the negative effect that it is not possible to confirm the request and after a while mailman drops the request. The second problem is the mail archive which is supposed to be accesible via http://www1.ietf.org/mail-archive/web/kitten/current/index.html does not list any of the e-mail since the list creation. I have reported both problems to Fortec and I have been waiting for several days without receiving a response. There is not much I can do about the archive but I have switched mailman to require my approval for new subscriptions instead of confirmation. I will check each day to approve new subscription requests until this problem is resolved. Unfortunately, once I approve you I doubt you will receive the welcome message. If you know of anyone who has been trying to join the list, please ask them to try again. Hopefully all of this will be resolved shortly. Jeffrey Altman --------------ms030800090509010200080500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMDI3MjAyMzI5WjAjBgkqhkiG9w0BCQQxFgQU9Bmm5pWf67kmHzhNVITz1hVGyasw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAcOdrkcZFqIQWZQ0IugcJRilcsSRuDz+mZ5+pO4nT g8FCgpH2YLYjgeYbnKyg+JGUZzrwmcjNCelO5rnvAIJCpenGR7mbNuO52zUruTd/ibjAPbS8 56mvmzh0jNuvKYYLIXf5VL+JdNHc/Gog41/yhoP9SoV6/Ug96RfrxRhxLUu10IFFULJGsP+z T6yvAoH20tzPcZRlR7lBXYOalbTf1oh0o/PsGSsEHN2bAEJlqTfeGNGExL1ntv/HeQBp4Dyh Q6K0P6PGt5AsWCRKmE6sn2eBoQ1m2ZHf2+yAlBjeZ9kcmOwOTv+6d4PBwh/8OL4biY/UzFxw SpbymOcggzi2RQAAAAAAAA== --------------ms030800090509010200080500-- --===============0810040034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0810040034==-- From kitten-bounces@lists.ietf.org Wed Oct 27 17:49:54 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 27 Oct 2004 17:49:53 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 8EE25131D0 for ; Wed, 27 Oct 2004 17:49:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvf6-0008Tg-8T; Wed, 27 Oct 2004 17:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvX9-0007Vu-Fp for kitten@megatron.ietf.org; Wed, 27 Oct 2004 17:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18290 for ; Wed, 27 Oct 2004 17:40:40 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvl5-0008SP-4z for kitten@ietf.org; Wed, 27 Oct 2004 17:55:08 -0400 Received: by cz.mit.edu (Postfix, from userid 8042) id 84F5C178025; Wed, 27 Oct 2004 17:40:53 -0400 (EDT) To: Jeffrey Altman References: <418003C1.9010102@columbia.edu> From: Sam Hartman Date: Wed, 27 Oct 2004 17:40:53 -0400 In-Reply-To: <418003C1.9010102@columbia.edu> (Jeffrey Altman's message of "Wed, 27 Oct 2004 16:23:29 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: kitten@ietf.org Subject: Re: Mailing List problems X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 353 Lines: 13 If people want access to an archive of the list, I believe i imap://imap.suchdamage.org/ietf.kitten is complete. I believe that archive should allow anonymous login using the fine anonymous sasl mechanism. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Oct 28 19:00:13 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Thu, 28 Oct 2004 19:00:12 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 93DDB13259 for ; Thu, 28 Oct 2004 19:00:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGS9-0001F2-5Z; Thu, 28 Oct 2004 16:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDsM-0004Nn-K6 for kitten@megatron.ietf.org; Thu, 28 Oct 2004 13:15:50 -0400 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.206.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23012 for ; Thu, 28 Oct 2004 13:15:47 -0400 (EDT) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i9SHFjP4003489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Oct 2004 13:15:45 -0400 (EDT) Message-ID: <41812968.7040907@columbia.edu> Date: Thu, 28 Oct 2004 13:16:24 -0400 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Content-Transfer-Encoding: 7bit Cc: Subject: Kitten is now a Working Group X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 347 Lines: 12 I have received notification from Russ that Kitten has been formally chartered by the IESG as a working group during today's telechat. Our first working group meeting will be held at IETF 61. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Nov 1 04:09:35 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 01 Nov 2004 04:09:34 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 63C38131D0 for ; Mon, 1 Nov 2004 04:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COY56-0008P2-Kr; Mon, 01 Nov 2004 04:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COY2l-00082B-Sb for kitten@megatron.ietf.org; Mon, 01 Nov 2004 04:00:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06508 for ; Mon, 1 Nov 2004 04:00:03 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COYHc-0001uD-Uy for kitten@ietf.org; Mon, 01 Nov 2004 04:15:26 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 00:59:37 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 00:59:32 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 00:59:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1110); Mon, 1 Nov 2004 00:59:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2004 00:59:34 -0800 Message-ID: Thread-Topic: Comments: draft-williams-gssapi-prf-00.txt thread-index: AcS/8RiYtV85YFSmSEqHwJInK8+4LA== From: "Liqiang(Larry) Zhu" To: X-OriginalArrivalTime: 01 Nov 2004 08:59:30.0264 (UTC) FILETIME=[191E0D80:01C4BFF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: Nicolas Williams Subject: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 868 Lines: 24 1) please describe why is undesirable to export the raw session key/subkey directly: aka why not a gss_export_key() extension. 2) add an GSS_Session_key_info() extension to desribe the native key size information and algorithms. The callers may want to know the true attack resistance strength of the output when using this PRF extension. A DES key of 8 bytes may only have 56 bits strength thus the algorithms may matter. 3) add the desired PRF output length to GSS_Pseudo_random(), so that the callers do not have to do further composition to get the desired output length. We do not give application protocols a chance to create a security weakness. A good example of bad key derivations is provided in RFC 3766. -- larry _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Nov 1 13:21:48 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 01 Nov 2004 13:21:46 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 5288D13252 for ; Mon, 1 Nov 2004 13:21:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgTc-0003OL-5o; Mon, 01 Nov 2004 13:00:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COg4Q-0000Hl-IK for kitten@megatron.ietf.org; Mon, 01 Nov 2004 12:34:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07321 for ; Mon, 1 Nov 2004 12:34:14 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgJK-0005EA-MB for kitten@ietf.org; Mon, 01 Nov 2004 12:49:43 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA1HYEs3010391 for ; Mon, 1 Nov 2004 09:34:14 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA1HYDjW008235 for ; Mon, 1 Nov 2004 10:34:13 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA1HXk9R023135; Mon, 1 Nov 2004 11:33:46 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA1HXkuj023134; Mon, 1 Nov 2004 11:33:46 -0600 (CST) Date: Mon, 1 Nov 2004 11:33:46 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20041101173346.GN21427@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 2029 Lines: 53 On Mon, Nov 01, 2004 at 12:59:34AM -0800, Liqiang(Larry) Zhu wrote: > 1) please describe why is undesirable to export the raw session > key/subkey directly: aka why not a gss_export_key() extension. You mean, in the I-D? Explain why GSS_Pseudo_random() instead of GSS_Get_key()? Ok, it's easy enough. > 2) add an GSS_Session_key_info() extension to desribe the native key > size information and algorithms. The callers may want to know the true > attack resistance strength of the output when using this PRF extension. > A DES key of 8 bytes may only have 56 bits strength thus the algorithms > may matter. This dos not belong in this I-D. The GSS-API provides a [lame] facility for this: the Quality of Protection values. Unfortunately the GSS-API's QoP notion is badly broken for a number of reasons. I do not, however, count inability to compare QoPs as such a reason, mostly because it's really, really hard to quantify the strength of a given cryptosystem. Is an AES-128 in CBC mode with HMAC-SHA-1 stronger than AES-128 in GCM mode? Who knows? At such key lenghts performance may be a better way to decide which cipher/mode to use. The GSS-API provides no way to influence the QoP that will be negotiated in a context token exchange, *that*, IMO, is a bigger deal. This is all fodder for a separate I-D. Let the GSS_Pseudo_random() remain simple, so we can last-call it soon. > 3) add the desired PRF output length to GSS_Pseudo_random(), so that the > callers do not have to do further composition to get the desired output > length. We do not give application protocols a chance to create a > security weakness. A good example of bad key derivations is provided in > RFC 3766. This needs to be decided here. I suggest that arguments pro and con be posted and then we can have a consensus call on the matter unless we all come to be obviously in agreement. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 16:58:09 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 16:58:09 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 69B4113824 for ; Tue, 2 Nov 2004 16:58:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6bB-00025i-Kl; Tue, 02 Nov 2004 16:53:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6BS-0000f7-SY for kitten@megatron.ietf.org; Tue, 02 Nov 2004 16:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14640 for ; Tue, 2 Nov 2004 16:27:16 -0500 (EST) Received: from stratton-four-seventy-four.mit.edu ([18.187.6.219] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6Qa-0006QL-8e for kitten@ietf.org; Tue, 02 Nov 2004 16:42:59 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id C026C16011E; Tue, 2 Nov 2004 16:27:12 -0500 (EST) To: Nicolas Williams References: <20041101173346.GN21427@binky.central.sun.com> From: Sam Hartman Date: Tue, 02 Nov 2004 16:27:12 -0500 In-Reply-To: <20041101173346.GN21427@binky.central.sun.com> (Nicolas Williams's message of "Mon, 1 Nov 2004 11:33:46 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 903 Lines: 25 >>>>> "Nicolas" == Nicolas Williams writes: >> 3) add the desired PRF output length to GSS_Pseudo_random(), so >> that the callers do not have to do further composition to get >> the desired output length. We do not give application protocols >> a chance to create a security weakness. A good example of bad >> key derivations is provided in RFC 3766. Nicolas> This needs to be decided here. I suggest that arguments Nicolas> pro and con be posted and then we can have a consensus Nicolas> call on the matter unless we all come to be obviously in Nicolas> agreement. pro: Makes it easier to design secure applications. Unless there are strong con arguments I support this for the stated reason. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 17:21:31 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 17:21:31 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id EE6C613824 for ; Tue, 2 Nov 2004 17:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6ce-0003DK-TX; Tue, 02 Nov 2004 16:55:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6KS-0007R9-O4 for kitten@megatron.ietf.org; Tue, 02 Nov 2004 16:36:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17596 for ; Tue, 2 Nov 2004 16:36:34 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6Zd-0006v1-Ib for kitten@ietf.org; Tue, 02 Nov 2004 16:52:18 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA2LaUui024472 for ; Tue, 2 Nov 2004 14:36:33 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA2LaQJf013551 for ; Tue, 2 Nov 2004 14:36:27 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA2LZtJD027584; Tue, 2 Nov 2004 15:35:55 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA2LZr1Z027583; Tue, 2 Nov 2004 15:35:53 -0600 (CST) Date: Tue, 2 Nov 2004 15:35:53 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041102213553.GC21427@binky.central.sun.com> References: <20041101173346.GN21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 1139 Lines: 32 On Tue, Nov 02, 2004 at 04:27:12PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > >> 3) add the desired PRF output length to GSS_Pseudo_random(), so > >> that the callers do not have to do further composition to get > >> the desired output length. We do not give application protocols > >> a chance to create a security weakness. A good example of bad > >> key derivations is provided in RFC 3766. > > Nicolas> This needs to be decided here. I suggest that arguments > Nicolas> pro and con be posted and then we can have a consensus > Nicolas> call on the matter unless we all come to be obviously in > Nicolas> agreement. > > pro: Makes it easier to design secure applications. > Unless there are strong con arguments I support this for the stated > reason. And what should specify the mechanism's PRF? An update to the mech, or an update to the mech _and_ kcrypto? What should the PRF be? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 17:21:48 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 17:21:47 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 3110B13824 for ; Tue, 2 Nov 2004 17:21:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6cm-0003KS-Cy; Tue, 02 Nov 2004 16:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6Mt-0001Ge-4L for kitten@megatron.ietf.org; Tue, 02 Nov 2004 16:39:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17807 for ; Tue, 2 Nov 2004 16:39:05 -0500 (EST) Received: from stratton-four-seventy-four.mit.edu ([18.187.6.219] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6c3-0006zm-W1 for kitten@ietf.org; Tue, 02 Nov 2004 16:54:49 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id F328B198002; Tue, 2 Nov 2004 16:39:05 -0500 (EST) To: Nicolas Williams References: <20041101173346.GN21427@binky.central.sun.com> <20041102213553.GC21427@binky.central.sun.com> From: Sam Hartman Date: Tue, 02 Nov 2004 16:39:05 -0500 In-Reply-To: <20041102213553.GC21427@binky.central.sun.com> (Nicolas Williams's message of "Tue, 2 Nov 2004 15:35:53 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 369 Lines: 13 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> What should the PRF be? Some sort of counter mode should be reasonable. That will form a valid PRF provided that you hold the length constant. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 17:21:54 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 17:21:54 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 91B9C13824 for ; Tue, 2 Nov 2004 17:21:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6cp-0003Ns-Ge; Tue, 02 Nov 2004 16:55:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6P3-0001dg-08 for kitten@megatron.ietf.org; Tue, 02 Nov 2004 16:41:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18054 for ; Tue, 2 Nov 2004 16:41:18 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6eD-00073E-L7 for kitten@ietf.org; Tue, 02 Nov 2004 16:57:03 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA2LfIs3014465 for ; Tue, 2 Nov 2004 13:41:18 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA2LfHJf016200 for ; Tue, 2 Nov 2004 14:41:17 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA2Len7P027591; Tue, 2 Nov 2004 15:40:49 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA2Lendv027590; Tue, 2 Nov 2004 15:40:49 -0600 (CST) Date: Tue, 2 Nov 2004 15:40:48 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041102214048.GD21427@binky.central.sun.com> References: <20041101173346.GN21427@binky.central.sun.com> <20041102213553.GC21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 549 Lines: 19 On Tue, Nov 02, 2004 at 04:39:05PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> What should the PRF be? > > Some sort of counter mode should be reasonable. That will form a > valid PRF provided that you hold the length constant. Why not do that at the GSS layer, with a GSS_Pseudo_random_plus() that uses GSS_Pseudo_random()? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 17:22:42 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 17:22:41 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 7B21C13824 for ; Tue, 2 Nov 2004 17:22:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6dl-0004Yj-Ac; Tue, 02 Nov 2004 16:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6Zr-0000hv-MQ for kitten@megatron.ietf.org; Tue, 02 Nov 2004 16:52:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19890 for ; Tue, 2 Nov 2004 16:52:29 -0500 (EST) Received: from stratton-four-seventy-four.mit.edu ([18.187.6.219] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6p2-0007aX-7w for kitten@ietf.org; Tue, 02 Nov 2004 17:08:13 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id EDEB116011E; Tue, 2 Nov 2004 16:52:27 -0500 (EST) To: Nicolas Williams References: <20041101173346.GN21427@binky.central.sun.com> <20041102213553.GC21427@binky.central.sun.com> <20041102214048.GD21427@binky.central.sun.com> From: Sam Hartman Date: Tue, 02 Nov 2004 16:52:27 -0500 In-Reply-To: <20041102214048.GD21427@binky.central.sun.com> (Nicolas Williams's message of "Tue, 2 Nov 2004 15:40:48 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 745 Lines: 22 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Nov 02, 2004 at 04:39:05PM -0500, Sam Hartman Nicolas> wrote: >> >>>>> "Nicolas" == Nicolas Williams >> writes: >> Nicolas> What should the PRF be? >> Some sort of counter mode should be reasonable. That will >> form a valid PRF provided that you hold the length constant. Nicolas> Why not do that at the GSS layer, with a Nicolas> GSS_Pseudo_random_plus() that uses GSS_Pseudo_random()? Why do you need both functions exposed at the GSS layer? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 17:42:11 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 17:42:11 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 5F10513824 for ; Tue, 2 Nov 2004 17:42:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP73J-00089y-Fd; Tue, 02 Nov 2004 17:22:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6dz-0004gR-SG for kitten@megatron.ietf.org; Tue, 02 Nov 2004 16:56:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20825 for ; Tue, 2 Nov 2004 16:56:45 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6tB-0007s6-MO for kitten@ietf.org; Tue, 02 Nov 2004 17:12:30 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA2LukNH000677 for ; Tue, 2 Nov 2004 14:56:46 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA2LukJf021247 for ; Tue, 2 Nov 2004 14:56:46 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA2LuIpk027612; Tue, 2 Nov 2004 15:56:18 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA2LuID3027611; Tue, 2 Nov 2004 15:56:18 -0600 (CST) Date: Tue, 2 Nov 2004 15:56:18 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041102215617.GF21427@binky.central.sun.com> References: <20041101173346.GN21427@binky.central.sun.com> <20041102213553.GC21427@binky.central.sun.com> <20041102214048.GD21427@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: O Content-Length: 927 Lines: 28 On Tue, Nov 02, 2004 at 04:52:27PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Tue, Nov 02, 2004 at 04:39:05PM -0500, Sam Hartman > Nicolas> wrote: > >> >>>>> "Nicolas" == Nicolas Williams > >> writes: > >> > Nicolas> What should the PRF be? > >> Some sort of counter mode should be reasonable. That will > >> form a valid PRF provided that you hold the length constant. > > Nicolas> Why not do that at the GSS layer, with a > Nicolas> GSS_Pseudo_random_plus() that uses GSS_Pseudo_random()? > > Why do you need both functions exposed at the GSS layer? Only to simplify specification of the generic PRF+ in terms of mechanisms' PRFs. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 18:18:15 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 18:18:14 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 96AA813824 for ; Tue, 2 Nov 2004 18:18:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7lK-0000od-PV; Tue, 02 Nov 2004 18:08:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7ZJ-00076p-5N for kitten@megatron.ietf.org; Tue, 02 Nov 2004 17:56:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26160 for ; Tue, 2 Nov 2004 17:55:58 -0500 (EST) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CP7oU-0000ut-PB for kitten@ietf.org; Tue, 02 Nov 2004 18:11:43 -0500 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19170; 2 Nov 2004 17:55 EST Date: Tue, 02 Nov 2004 17:55:55 -0500 From: Jeffrey Hutzelman To: Sam Hartman , Nicolas Williams Message-ID: <2654580000.1099436155@minbar.fac.cs.cmu.edu> In-Reply-To: References: <20041101173346.GN21427@binky.central.sun.com> <20041102213553.GC21427@binky.central.sun.com> <20041102214048.GD21427@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 1054 Lines: 30 On Tuesday, November 02, 2004 16:52:27 -0500 Sam Hartman wrote: >>>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Tue, Nov 02, 2004 at 04:39:05PM -0500, Sam Hartman > Nicolas> wrote: > >> >>>>> "Nicolas" == Nicolas Williams > >> writes: > >> > Nicolas> What should the PRF be? > >> Some sort of counter mode should be reasonable. That will > >> form a valid PRF provided that you hold the length constant. > > Nicolas> Why not do that at the GSS layer, with a > Nicolas> GSS_Pseudo_random_plus() that uses GSS_Pseudo_random()? > > Why do you need both functions exposed at the GSS layer? I think Nico is suggesting that GSS_Pseudo_random() be provided by the mechanism, while GSS_Pseudo_random_plus() is implemented in a mechanism-independent manner in terms of GSS_Pseudo_random(). _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 2 18:38:22 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 02 Nov 2004 18:38:22 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 0B32613824 for ; Tue, 2 Nov 2004 18:38:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7ys-0003O6-Jz; Tue, 02 Nov 2004 18:22:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7mY-0001cU-Rv for kitten@megatron.ietf.org; Tue, 02 Nov 2004 18:09:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28102 for ; Tue, 2 Nov 2004 18:09:40 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP81k-0001MG-Bz for kitten@ietf.org; Tue, 02 Nov 2004 18:25:25 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA2N9eui016690 for ; Tue, 2 Nov 2004 16:09:40 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA2N9dJh016166 for ; Tue, 2 Nov 2004 16:09:40 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA2N9BHY027940; Tue, 2 Nov 2004 17:09:11 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA2N9AiF027939; Tue, 2 Nov 2004 17:09:10 -0600 (CST) Date: Tue, 2 Nov 2004 17:09:10 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20041102230910.GJ21427@binky.central.sun.com> References: <20041101173346.GN21427@binky.central.sun.com> <20041102213553.GC21427@binky.central.sun.com> <20041102214048.GD21427@binky.central.sun.com> <2654580000.1099436155@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2654580000.1099436155@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org, "Liqiang(Larry) Zhu" , Sam Hartman Subject: Re: Comments: draft-williams-gssapi-prf-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 870 Lines: 24 On Tue, Nov 02, 2004 at 05:55:55PM -0500, Jeffrey Hutzelman wrote: > I think Nico is suggesting that GSS_Pseudo_random() be provided by the > mechanism, while GSS_Pseudo_random_plus() is implemented in a > mechanism-independent manner in terms of GSS_Pseudo_random(). Yes, mostly to avoid any battles over the correct way to deliver a PRF+ for the Kerberos V mech: as an update to the mech, or as an update to the mech and kcrypto. Anyways, Sam convinces me that we can just update the mech and be done and have the GSS-API just provide an interface to the mechs' PRF+ functions. Larry seems to be proposing exactly as much, so I think we can consider the matter settled, unless someone else has a different opinion. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From mailman-bounces@lists.ietf.org Mon Nov 1 05:15:37 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 01 Nov 2004 05:15:36 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id B0E631382E for ; Mon, 1 Nov 2004 05:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ1n-00060z-N4 for ietf.kitten@mailboxes.suchdamage.org; Mon, 01 Nov 2004 05:03:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@lists.ietf.org To: ietf.kitten@mailboxes.suchdamage.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:01:26 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@lists.ietf.org Errors-To: mailman-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 2355 Lines: 56 This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for ietf.kitten@mailboxes.suchdamage.org: List Password // URL ---- -------- kitten@lists.ietf.org fooglagre https://www1.ietf.org/mailman/options/kitten/ietf.kitten%40mailboxes.suchdamage.org From kitten-bounces@lists.ietf.org Mon Nov 1 18:03:21 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 01 Nov 2004 18:03:20 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id F1C4413252 for ; Mon, 1 Nov 2004 18:03:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkjf-0005pZ-DR; Mon, 01 Nov 2004 17:33:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkZC-0006hV-AD for kitten@megatron.ietf.org; Mon, 01 Nov 2004 17:22:22 -0500 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.206.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12910 for ; Mon, 1 Nov 2004 17:22:20 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iA1MMKcm016994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Nov 2004 17:22:21 -0500 (EST) Message-ID: <4186B73C.4020506@columbia.edu> Date: Mon, 01 Nov 2004 17:22:52 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Cc: Subject: IETF-61 Agenda X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1860633773==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 6495 Lines: 135 This is a cryptographically signed message in MIME format. --===============1860633773== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020808070706000404010208" This is a cryptographically signed message in MIME format. --------------ms020808070706000404010208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kitten (GSS-API Next Generation) BOF (kitten) Monday, November 8 at 1530-1730 =============================== CHAIR: Jeffrey Altman AGENDA: - Introduction and Welcome - Charter review - Guide to the GSS-APIv3 (draft-williams-gssapi-v3-guide-to-00.txt) - Namespace Considerations and Registries for GSS-API Extensions (draft-williams-gssapi-extensions-iana-00.txt) - GSS-API Domain-Based Service Names and Name Type (draft-williams-gssapi-domain-based-names-00.txt) - GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (draft-williams-krb5-gssapi-domain-based-names-00.txt) - A PRF API extension for the GSS-API (draft-williams-gssapi-prf-00.txt) - A PRF for the Kerberos V GSS-API Mechanism (draft-williams-krb5-gssapi-prf-00.txt) - Generic Security Service API Version 2 : Java & C# Bindings (draft-morris-java-gssapi-update-for-csharp-00.txt) - The Simple and Protected GSS-API Negotiation Mechanism (draft-zhu-spnego-2478bis-00.txt) --------------ms020808070706000404010208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTAxMjIyMjUyWjAjBgkqhkiG9w0BCQQxFgQUHE0Uin8iIJNsGqwMoPn2oBYhpBsw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA20L5Q7gQBUzCieFwqQPkhl+mbFGGISCnRwUngeUl msGh1NW6iMY9XfhOh+bGx5gY4NO/97WK7e9Ab5sZBs6Oh4Z7pu3FC1IB1zkO3lbTMM2adoa1 yLaEDiB+G7GIy+wSZZMtIr6d5jKb6b3UaDLdXSJVJyr32Lqtn2ipd8hM03rdbqbx1xvsd4Hx Vtr22wEWoJsFJr6rmVzJ+8pifuWs589pN0Gpe4s9CDD3CvbxUgg9MR5SFyW/mfaX/yfr1eDK g62Ck+fdtnOJS17/8h1CYjEyr9i/Gpm069OkqCE0ksc/iW+d1j2Npkwru+KsOw6y6Ws/MVmB BypuTGI8J9KJiAAAAAAAAA== --------------ms020808070706000404010208-- --===============1860633773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1860633773==-- From kitten-bounces@lists.ietf.org Mon Nov 1 23:11:10 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 01 Nov 2004 23:11:10 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 1D95C13252 for ; Mon, 1 Nov 2004 23:11:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COpwV-0006SB-8T; Mon, 01 Nov 2004 23:06:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COphN-0002ef-NK for kitten@megatron.ietf.org; Mon, 01 Nov 2004 22:51:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21413 for ; Mon, 1 Nov 2004 22:51:08 -0500 (EST) Received: from cz-hotass.mit.edu ([18.101.1.53] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COpwP-0005ws-1b for kitten@ietf.org; Mon, 01 Nov 2004 23:06:42 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 1CCEF16011F; Mon, 1 Nov 2004 22:51:08 -0500 (EST) To: Jeffrey Altman References: <4186B73C.4020506@columbia.edu> From: Sam Hartman Date: Mon, 01 Nov 2004 19:17:43 -0500 In-Reply-To: <4186B73C.4020506@columbia.edu> (Jeffrey Altman's message of "Mon, 01 Nov 2004 17:22:52 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.7 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: kitten@ietf.org Subject: Re: IETF-61 Agenda X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.63 X-Spam-Level: Status: RO Content-Length: 334 Lines: 11 If we have some extra time, it is likely that Nico and I will have made progress on draft-hartman-gss-naming and could report our progress back to the working group to start judging consensus. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Nov 1 23:19:51 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 01 Nov 2004 23:19:51 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 8FADB13252 for ; Mon, 1 Nov 2004 23:19:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COq0X-0000tH-A8; Mon, 01 Nov 2004 23:10:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COptd-0005mi-0z for kitten@megatron.ietf.org; Mon, 01 Nov 2004 23:03:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22053 for ; Mon, 1 Nov 2004 23:03:41 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.206.19] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COq8Y-0006AA-N2 for kitten@ietf.org; Mon, 01 Nov 2004 23:19:16 -0500 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iA243eCx014567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Nov 2004 23:03:40 -0500 (EST) Message-ID: <4187074D.4050005@columbia.edu> Date: Mon, 01 Nov 2004 23:04:29 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <4186B73C.4020506@columbia.edu> In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: Re: IETF-61 Agenda X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2021937952==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 5780 Lines: 108 This is a cryptographically signed message in MIME format. --===============2021937952== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050504040106010000070202" This is a cryptographically signed message in MIME format. --------------ms050504040106010000070202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Hartman wrote: > If we have some extra time, it is likely that Nico and I will have > made progress on draft-hartman-gss-naming and could report our > progress back to the working group to start judging consensus. I would be happy to amend the agenda. We were given a two hour slot when 90 minutes were requested. Jeffrey Altman --------------ms050504040106010000070202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTAyMDQwNDI5WjAjBgkqhkiG9w0BCQQxFgQUyVu3c+g7IzlxQdtlgd4VOYKRMt8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAFcjYHTpFEaE0j9pRTU5BaoyKCYsEWHuqbjChaxcR eZnSweq71lGqsD8mXhXgqSb5apge2dCyn1xqiR54baHLAY7IYeG/moIHl5i9Tb4/WLgQo7c/ dgzDsXtthUqS1RkWFJGuNn/xAMHFxtY1VaWqx3OzR/QaASW14arM4BwGTuegoaGNSAJ6ilZQ 34stHK+gljFt8deneRmjlpAKytCdR8nTwQVuhC9LX6gm4ufoRIu7+2Fzdu0JkYK/T7yr2tm1 mm/xa1HPwMFa0T8r34Mi91py0N+YXTOrpCDC0zHI1L4U3pBSMthbauUdMQBQ9XCpB0LfnQLP G9ePiRC6Q3GGXQAAAAAAAA== --------------ms050504040106010000070202-- --===============2021937952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============2021937952==-- From kitten-bounces@lists.ietf.org Wed Nov 3 16:42:11 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 03 Nov 2004 16:42:09 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id AB95C13226 for ; Wed, 3 Nov 2004 16:42:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSfH-0001wu-5U; Wed, 03 Nov 2004 16:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPScC-0001Ky-AD; Wed, 03 Nov 2004 16:24:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20479; Wed, 3 Nov 2004 16:24:22 -0500 (EST) Message-Id: <200411032124.QAA20479@ietf.org> From: The IESG To: IETF-Announce@ietf.org Date: Wed, 03 Nov 2004 16:24:22 -0500 Cc: kitten@ietf.org Subject: WG Action: Kitten (GSS-API Next Generation) (kitten) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: RO Content-Length: 7043 Lines: 186 A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Kitten (GSS-API Next Generation) (kitten) ========================================= Current Status: Active Working Group Chair(s): Jeffrey Altman Security Area Director(s): Russell Housley Steven Bellovin Security Area Advisor: Russell Housley Mailing Lists: General Discussion: kitten@lists.ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/kitten Archive: http://www1.ietf.org/mail-archive/web/kitten/current/index.html Description of Working Group: The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the core GSSAPI specification and language bindings that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: o Use of channel bindings o Thread safety restrictions o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 including support for the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Define a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend the GSS-API to support authorization by portable GSS applications while also supporting mechanisms that do not have a single canonical name for each authentication identity. o Specify a Domain-based GSS service principal name consisting of: service name, host name, and domain name for use by application services hosted across multiple servers. o Extensions to support stackable GSSAPI mechanisms. o Define a Psuedo-Random Function for GSSAPI This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec. o Update the GSSAPI Java Language Bindings to match actual implementation This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# DELIVERABLES Either: o Clarifications to GSSAPIv2 (May 2005 to IESG)Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 [editor: TBD] o Generic Security Service API Version 2, Update 1 : C-bindings [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI [editors: Mike Eisler/Nicolas Williams] (based on draft-ietf-nfsv4-ccm, which has been discussed previously in the NFSv4 WG) o On the Use of Channel Bindings to Secure Channels [editor: Nicolas Williams] (based on draft-ietf-nfsv4-channel-bindings, which has been discussed previously in the NFSv4 WG) o GSSAPIv3 [editor: to be determined] o Stackable Generic Security Service Pseudo-mechanisms [editor: Nicolas Williams] draft-williams-gssapi-stackable-pseudo-mechs o GSS-APIv2 Extension for Storing Delegated Credentials [editor: Nicolas Williams] draft-williams-gssapi-store-deleg-creds o GSSAPI Mechanisms without a Unique Canonical Name [editor: Sam Hartman] draft-hartman-gss-naming o SPNEGO (RFC 2478) Revisions [editor: Wyllys Ingersoll / Larry Zhu] draft-zhu-spnego-2478bis o Guide to the GSS-APIv3 [editor: Nicolas Williams] draft-williams-gssapi-v3-guide-to o Namespace Considerations and Registries for GSS-API Extensions [editor: Nicolas Williams] draft-williams-gssapi-extensions-iana o GSS-API Domain-Based Service Names and Name Type [editor: Nicolas Williams] draft-williams-gssapi-domain-based-names o GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-domain-based-names o A PRF API extension for the GSS-API [editor: Nicolas Williams] draft-williams-gssapi-prf o A PRF for the Kerberos V GSS-API Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-prf o Generic Security Service API Version 2 : Java & C# Bindings [editors: Larry Zhu / Corby Morris] draft-morris-java-gssapi-update-for-csharp Goals and Milestones: Nov 04 First Meeting Mar 05 First drafts of either 'Clarifications to GSSAPIv2' as Informational ORsubmit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Jul 05 Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Jul 05 Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI' to the IESG as Proposed Standard Jul 05 Submit 'On the Use of Channel Bindings to Secure Channels' to the IESG as Proposed Standard Jul 05 Submit 'The Simple and Protected GSS-API Negotiation Mechanism (Revised)' to the IESG as Proposed Standard Nov 05 Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service Application Program Interface Version 3' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service API Version 3 : C-bindings' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service API Version 3 : Java and C# bindings' to the IESG as Proposed Standard Nov 06 Charter Review _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Nov 5 12:28:01 2004 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 05 Nov 2004 12:28:00 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 055BC13226 for ; Fri, 5 Nov 2004 12:28:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7ri-0000YU-FH; Fri, 05 Nov 2004 12:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7SE-0002Vd-Qe for kitten@megatron.ietf.org; Fri, 05 Nov 2004 12:00:50 -0500 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.206.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28751 for ; Fri, 5 Nov 2004 12:00:47 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iA5H0mqa002324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Nov 2004 12:00:49 -0500 (EST) Message-ID: <418BB1F5.9060409@columbia.edu> Date: Fri, 05 Nov 2004 12:01:41 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.20 Cc: Subject: Presentations for Monday's Session X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380432648==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on solipsist-nation.suchdamage.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Status: O Content-Length: 5940 Lines: 115 This is a cryptographically signed message in MIME format. --===============1380432648== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050707080909010307020002" This is a cryptographically signed message in MIME format. --------------ms050707080909010307020002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To all presenters at Monday's session: In order to provide for a smooth meeting on Monday as well as to enable the Jabber participants to fully take part in the session I will require that all presentations be delivered to me no later then Sunday night. This will provide me ample time to place the presentations on the web and configure them on a single presentation laptop. The presentations will be uploaded to the web and displayed at the meeting in PDF format. Thank you. Jeffrey Altman --------------ms050707080909010307020002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTA1MTcwMTQxWjAjBgkqhkiG9w0BCQQxFgQU9R4I+/jUJlcSPn+zyfnTHFveXCEw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAEbAWu5N3K/qKiGl8twg21hh6S60kCaJY6AFcRyNj fHYIIIykcak31YnCnM1hErGH9Xr6JFk1UMusLITncA1w49S3Kci1SF/tcHS7tTcefWWQbeWw FcmzgeSroRk4dy7kh84+dTzwgAvwkZ5asCkXC+2i9JfiESpSByqCpOK3dHo9xbhIV0tX8XDg HxHjDnrWxzUmyicGiAppZmZ8kSlBhqfTpd3HJSUXlYlG+Bcvsm+jLR2cDMhR8nLkr2A3p6sM p7ctE/c7lgH/v4A0lUYwAV+e4rV7I4FXOSrpphn0URlBKfMQr2oMkOYQYB6LrZP5N7UDkXXG WXsnNW2z7NAUjgAAAAAAAA== --------------ms050707080909010307020002-- --===============1380432648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1380432648==-- From kitten-bounces@ietf.org Fri Nov 5 18:30:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00913; Fri, 5 Nov 2004 18:30:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDXf-0007Zy-Gq; Fri, 05 Nov 2004 18:30:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDWg-0003l9-8n; Fri, 05 Nov 2004 18:29:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDNV-0002IL-In for kitten@megatron.ietf.org; Fri, 05 Nov 2004 18:20:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00443 for ; Fri, 5 Nov 2004 18:20:18 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDNL-0007Nn-Uc for kitten@ietf.org; Fri, 05 Nov 2004 18:20:22 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA12474; Sat, 6 Nov 2004 00:19:36 +0100 (MEZ) From: Martin Rex Message-Id: <200411052319.AAA27599@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Sat, 6 Nov 2004 00:19:35 +0100 (MET) In-Reply-To: <20041105221038.GF102351@binky.central.sun.com> from "Nicolas Williams" at Nov 5, 4 04:10:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, hartmans@mit.edu Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > > The purpose of MNs is for authentication (ACL checks). Even > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Nit: authorization. Nope, I really meant authentication. The check whether we do recognize the canonical name that we get as the result of one (out of many) methods to authenticate a user. In our application for example this is the transformation of a name as known to the gssapi mechanism into the legacy namespace of our application. Authorization, including wether we allow this user to logon at all is done later in the game. I don't even want to talk about the fine-grained authorization profiles that come into play once the user passes our logon checks. > > For those who don't remember, we've argued as to the, shall we say, > quality of gss_canonicalize_name()'s output. > > The crux of the matter is this: all these names are really based on > human-readable names (for example, the exported name token for the > Kerberos V mechanism is really an encoding of a Kerberos V principal and > realm name), but these can change and may require online infrastructure > to validate. The crux of the matter is that Kerberos 5 authentication is by definition based on printable Kerberos principal names. Period. I know that when Microsoft uses Kerberos for authentication, it entirely ignores the Kerberos principal names that are involved when they find a PAC inside the ticket. However this only works in a homogeneous Microsoft Windows environment. As soon as you include non-Microsoft-W2K machines in your infrastructure (or use a non-Microsoft KDC), you can not use the canonical representation of a name which microsoft uses in their proprietary ACLs, these fancy SIDs. The only name that is guaranteed to be universally available across a heterogeneous Kerberos 5 infrastructure is the Kerberos principal name, because that is the lowest common denominator that every implementation must understand and provide. And frankly, if you look at the transformation calls that Microsoft provides between SIDs and Kerberos principal names (in both directions) an which names you need where (do SIDs work as target names with Microsoft's Kerberos SSP?) > > I don't have any intention to break GSS_Canonicalize_name(), but to > provide for alternatives to name-based authorization, specifically > authorization by "internal" IDs (e.g., POSIX UIDs, GIDs, Windows SIDs). The problem with UUIDs, GUIDs or Windows SIDs is, that although there may be less motivation to change or reuse them over time than printable names, but - they're still inherently non-portable across heterogenous environments - they're not used natively for maintenance by (human) admins and therefore translation/lookup APIs are necessary for the transformations - the use of UUIDs, GUIDs or Windows SIDs vs. printable names is often quite inconsistent in those areas where they're used - the translation/conversion APIs between the printable and the binary canonical forms are often insufficient, plain broken or even missing/non-functional in existing implementations. - the translation/conversion usually requires access to a central name service / directory and therefore credentials, and that is a serious problem for some environments and some uses. Funny that you mention POSIX uid_t. They used to be 16-bit on Unix, providing a *MUCH* smaller space than Kerberos principal names, and they're only valid locally which makes them less useful. > > Yes, we intend to provide at least runtime feature detection facilities, > as well as compile-time facilities for language bindings where that > makes sense. Runtime feature detection facilities can be used to build > compile-time profiles, BTW (think of GNU autoconf); as Sam points out, > this not ideal for cross-compilation, but in a pinch it will do. > > (And note that link-time feature detection is also possible; think of > weak symbolic references, shared object filters). I consider unix system loader / runtimer linker behaviour with the global symbol space, function overloading and other nuisances among the worst of evil inventions in IT. As soon as code from different sources that has never seen each other before meets on a customers machine and causes problems, you will realize that. Just recently I had to deal with an AIX problem coming from the crazy "-brtl -bnortllib" linker switches, and when you dig into the underlying issues, you'll realize that the responsible engineer were plain nuts. > > I want to keep this implementation specific, though most implementations > allow for/default to finding a credential in the "credential store" > corresponding to the calling thread's/process' current user context > (note: I consider a PAG to be part of such a user context). On such > platforms the application must switch to the user context of the user > for which it wants to acquire credentials; many applications don't have > the privilege to do so. A lot of code is not prepared for "impersonation" kind of techiques or even breaks. Usually this model makes abstraction much much harder, because you need access to the lower level handle to switch around at the application layer, which means you have to tunnel the access through all layers. Even Microsoft's Software breaks in various ways because it cannot correctly cope with this architecture. I.e. when doing an NTLM SSPI-authentication and impersonation. After an authentication through the network with a failed logon to a domain account and a fallback to the local guest account, QueryContextAttributes(Names) will ALWAYS return an account name that looks nice, but doesn't even exist (i.e. PC_NBNAME\DOM_USER instead of PC_NBNAME\GUEST) and LookupAccountSID() will do the exact same error when it's call while still impersonating. So you have to Impersonate, QueryToken,Revert,LookupAccountSID to reliably get the real name... I reported this bug to Microsoft in 1997, but I think it never got fixed in NT4 and I never felt like checking whether W2K still has it. The problem here is that with sufficiently modularized code and sufficient abstraction, you don't know which API calls will actually perform operations where OS-level access control is involved so to play on the safe side you'll probably have to switch between original and impersonated identity like crazy and localize the impersonation code path as closely as possible to exactly those operations that should be performed under the impersonating user. But as I said--with sufficiently modularized code you'll get into troubles sooner or later, so that inside a high-level abstracted function that is supposed to be performed under impersonation, you'll suddenly have a need to do a translation/lookup which ultimately does a remote request through the network, and *Booom* you have a problem. Now you do not only have to tunnel the handle for switching access tokens not only backup to the application layer, but also downward into abstract modularized service functions which may eventually have a need for it. That's a *lot* of work for being inherently non-portable. And believe me, there are a lot of things that simply can not be mapped to Posix style access control. That model is ok for a simple fileserver (or a web-server that is effectively used in a fileserver manner), but not for a lot of real world scenarious with magnitudes higher complexity. If it were easy, then you could write down a mapping of e.g. an X.509 cert basic constraints and (extended) key usage extensions into a Posix style ACL... ;-) -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 5 18:41:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01535; Fri, 5 Nov 2004 18:41:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDhl-0007nX-6m; Fri, 05 Nov 2004 18:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDWm-0003oS-6i; Fri, 05 Nov 2004 18:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDRY-0002oC-Mz for kitten@megatron.ietf.org; Fri, 05 Nov 2004 18:24:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00643 for ; Fri, 5 Nov 2004 18:24:29 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDRZ-0007TO-2B for kitten@ietf.org; Fri, 05 Nov 2004 18:24:33 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 15:24:00 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 15:24:00 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 15:24:00 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 15:23:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 15:23:58 -0800 Message-ID: Thread-Topic: Comments on Larry's SPNEGO draft thread-index: AcTDgmoXRTNJDQmKRR+wnJiPgUOXOwACvqDQ From: "Liqiang\(Larry\) Zhu" To: "Ken Raeburn" X-OriginalArrivalTime: 05 Nov 2004 23:23:59.0867 (UTC) FILETIME=[87765CB0:01C4C38E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Ken Raeburn wrote: > And, frankly, I think having the latitude to=20 > implement things so as to test for broken=20 > assumptions makes a lot of sense, > particularly=20 > in what's supposed to be a generic framework.=20 But this is not specific to SPNEGO and it dose not belong to here. furthermore, the word SHOULD does allow you test applications properly. > So even if generating the token for the preferred mech is an expensive > operation or involves prompting the user for input, and is known only=20 > to be supported by a couple of servers out of the dozens that the client=20 > will use, you think the token should be generated before negotiating=20 > whether the mech will be used? Using the optimistic token allows you to select the next available mech. It is a broken design if your gss_init_sec_context involves a prompt (and that is not part of 2743/2744), even worse without letting the users know what the credentials will be used for. This is a security weakness on your side, and we do not have this in SSPI. -- Larry -----Original Message----- From: Ken Raeburn [mailto:raeburn@MIT.EDU]=20 Sent: Friday, November 05, 2004 1:55 PM To: Liqiang(Larry) Zhu Cc: kitten@ietf.org; Martin Rex Subject: Re: Comments on Larry's SPNEGO draft On Nov 5, 2004, at 16:12, Liqiang((Larry)) Zhu wrote: > Martin Rex wrote: >> It is *NOT* the applications decision to do optimistic negotiation, > that is entirely at the discretion of the SPNEGO >> implementation and it can not even be requested by the application at > the API level. > >> However a SHOULD or a MUST would give a poor excuse to applications=20 >> or > upper level protocol designers to rely on the >> optimistic negotiation to succeed -- which is not what SPNEGO was=20 >> made > for. > > If I understand you correctly, you argued to increase the # of round=20 > trips to test if existing applications are written correctly to handle > arbitrarily large # of round trips, or to break future applications=20 > that are not written correctly. I regret to see this kind of arguments > even exist He's not arguing for a SHOULD NOT. (At least, not in the quoted paragraphs, I haven't seen the full original message yet.) He's arguing to be allowed to use the extra round, at his discretion as the SPNEGO implementor. And, frankly, I think having the latitude to implement things so as to test for broken assumptions makes a lot of sense, particularly in what's supposed to be a generic framework. You may not want to do it for production use when performance matters, but being able to exercise the multiple round trip case with (for example) Kerberos will catch bugs earlier than waiting for a mechanism that can only work that way, and then discovering that you can't use it at all because of one buggy implementation. >> What convincing problem do you have with MAY? > > The following argument should justify a SHOULD (or even a MUST). > > "The optimistic token SHOULD always be provided. This is because if=20 > you do not use the optimistic token, and gss_init_sec_context fails=20 > with a continue-able/non-fatal error after the two sides already agree > upon a common mech, we can not renegotiate the next best available mechanism. > That is not acceptable." So even if generating the token for the preferred mech is an expensive operation or involves prompting the user for input, and is known only to be supported by a couple of servers out of the dozens that the client will use, you think the token should be generated before negotiating whether the mech will be used? Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 5 18:48:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02065; Fri, 5 Nov 2004 18:48:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDp0-0007we-Eh; Fri, 05 Nov 2004 18:48:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDjC-00065O-4U; Fri, 05 Nov 2004 18:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDap-0004Rl-CP for kitten@megatron.ietf.org; Fri, 05 Nov 2004 18:34:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01059 for ; Fri, 5 Nov 2004 18:34:04 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDap-0007cu-S6 for kitten@ietf.org; Fri, 05 Nov 2004 18:34:08 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA5NY57q024676 for ; Fri, 5 Nov 2004 15:34:05 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA5NY3Jf007210 for ; Fri, 5 Nov 2004 16:34:04 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA5NXXMp470039; Fri, 5 Nov 2004 17:33:33 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA5NXXfK470038; Fri, 5 Nov 2004 17:33:33 -0600 (CST) Date: Fri, 5 Nov 2004 17:33:33 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20041105233333.GK102351@binky.central.sun.com> References: <20041105221038.GF102351@binky.central.sun.com> <200411052319.AAA27599@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411052319.AAA27599@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: kitten@ietf.org, hartmans@mit.edu Subject: Re: Single canonical names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 On Sat, Nov 06, 2004 at 12:19:35AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > > The purpose of MNs is for authentication (ACL checks). Even > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Nit: authorization. > > Nope, I really meant authentication. The check whether we do recognize > the canonical name that we get as the result of one (out of many) > methods to authenticate a user. In our application for example > this is the transformation of a name as known to the gssapi mechanism > into the legacy namespace of our application. > > Authorization, including wether we allow this user to logon at all > is done later in the game. I don't even want to talk about the > fine-grained authorization profiles that come into play once > the user passes our logon checks. Ah, ok, this is very specific to your app. > > > > For those who don't remember, we've argued as to the, shall we say, > > quality of gss_canonicalize_name()'s output. > > > > The crux of the matter is this: all these names are really based on > > human-readable names (for example, the exported name token for the > > Kerberos V mechanism is really an encoding of a Kerberos V principal and > > realm name), but these can change and may require online infrastructure > > to validate. > > The crux of the matter is that Kerberos 5 authentication is by definition > based on printable Kerberos principal names. Period. Yup. > I know that when Microsoft uses Kerberos for authentication, it entirely > ignores the Kerberos principal names that are involved when they > find a PAC inside the ticket. However this only works in a homogeneous > Microsoft Windows environment. As soon as you include non-Microsoft-W2K > machines in your infrastructure (or use a non-Microsoft KDC), you > can not use the canonical representation of a name which microsoft > uses in their proprietary ACLs, these fancy SIDs. > > The only name that is guaranteed to be universally available across > a heterogeneous Kerberos 5 infrastructure is the Kerberos principal > name, because that is the lowest common denominator that every > implementation must understand and provide. We propose portable GSS-APIv3 interfaces to facilitate use of internal identifiers. > > > > I don't have any intention to break GSS_Canonicalize_name(), but to > > provide for alternatives to name-based authorization, specifically > > authorization by "internal" IDs (e.g., POSIX UIDs, GIDs, Windows SIDs). > > The problem with UUIDs, GUIDs or Windows SIDs is, that although > there may be less motivation to change or reuse them over time > than printable names, but > > - they're still inherently non-portable across heterogenous environments This is less of an issue than you think (but I'm not prepared, today, for lack of time, to back this up with a full treatment). > - they're not used natively for maintenance by (human) admins > and therefore translation/lookup APIs are necessary for the transformations That's ok, we all use them, at least on such platforms as Unix, Windows. > - the use of UUIDs, GUIDs or Windows SIDs vs. printable names is > often quite inconsistent in those areas where they're used I'm not sure what you mean here. > - the translation/conversion APIs between the printable and the > binary canonical forms are often insufficient, plain broken or even > missing/non-functional in existing implementations. See above. > - the translation/conversion usually requires access to a central > name service / directory and therefore credentials, and that > is a serious problem for some environments and some uses. Sort of. Just as tickets can carry authorization data, so could certs (the necessary hooks are already there). > Funny that you mention POSIX uid_t. They used to be 16-bit on Unix, > providing a *MUCH* smaller space than Kerberos principal names, > and they're only valid locally which makes them less useful. But they're not 16-bit wide anymore. Certainly not on Solaris. > > (And note that link-time feature detection is also possible; think of > > weak symbolic references, shared object filters). > > I consider unix system loader / runtimer linker behaviour with > the global symbol space, function overloading and other nuisances > among the worst of evil inventions in IT. I'll pass on this comment. > As soon as code from different sources that has never seen each > other before meets on a customers machine and causes problems, > you will realize that. Users should not use LD_LIBRARY_PATH, if that's what you mean. Yes, abuse of LD_LIBRARY_PATH leads to Bad Things. > > I want to keep this implementation specific, though most implementations > > allow for/default to finding a credential in the "credential store" > > corresponding to the calling thread's/process' current user context > > (note: I consider a PAG to be part of such a user context). On such > > platforms the application must switch to the user context of the user > > for which it wants to acquire credentials; many applications don't have > > the privilege to do so. > > A lot of code is not prepared for "impersonation" kind of techiques > or even breaks. Usually this model makes abstraction much much harder, > because you need access to the lower level handle to switch around > at the application layer, which means you have to tunnel the access > through all layers. > > Even Microsoft's Software breaks in various ways because it cannot > correctly cope with this architecture. > > I.e. when doing an NTLM SSPI-authentication and impersonation. > After an authentication through the network with a failed logon > to a domain account and a fallback to the local guest account, > QueryContextAttributes(Names) will ALWAYS return an account name > that looks nice, but doesn't even exist (i.e. PC_NBNAME\DOM_USER > instead of PC_NBNAME\GUEST) and LookupAccountSID() will do > the exact same error when it's call while still impersonating. > So you have to Impersonate, QueryToken,Revert,LookupAccountSID > to reliably get the real name... > I reported this bug to Microsoft in 1997, but I think it never > got fixed in NT4 and I never felt like checking whether W2K > still has it. > > The problem here is that with sufficiently modularized code and > sufficient abstraction, you don't know which API calls will > actually perform operations where OS-level access control is > involved so to play on the safe side you'll probably have > to switch between original and impersonated identity like > crazy and localize the impersonation code path as closely > as possible to exactly those operations that should be > performed under the impersonating user. > > But as I said--with sufficiently modularized code you'll > get into troubles sooner or later, so that inside a > high-level abstracted function that is supposed to be > performed under impersonation, you'll suddenly have a > need to do a translation/lookup which ultimately > does a remote request through the network, and *Booom* > you have a problem. Now you do not only have to tunnel > the handle for switching access tokens not only > backup to the application layer, but also downward > into abstract modularized service functions which may > eventually have a need for it. > > > That's a *lot* of work for being inherently non-portable. Again, I lack the time to provide a full answer to this. Suffice it to say that I disagree and will come back to this later (probably much later). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 5 19:00:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03145; Fri, 5 Nov 2004 19:00:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDzz-0008CO-BM; Fri, 05 Nov 2004 19:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDr9-0008Hx-RR; Fri, 05 Nov 2004 18:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDpy-0007zH-LG for kitten@megatron.ietf.org; Fri, 05 Nov 2004 18:49:46 -0500 Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.206.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02242 for ; Fri, 5 Nov 2004 18:49:43 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iA5NninZ013006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Nov 2004 18:49:45 -0500 (EST) Message-ID: <418C11C6.7010307@columbia.edu> Date: Fri, 05 Nov 2004 18:50:30 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.21 Subject: Kitten Archives and Mailing List problems X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094364218==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a cryptographically signed message in MIME format. --===============1094364218== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010705090102040002020608" This is a cryptographically signed message in MIME format. --------------ms010705090102040002020608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The Kitten Archives and the Mailing List problems of the last few weeks should now be fixed. Sorry for the inconvenience. Jeffrey Altman --------------ms010705090102040002020608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTA1MjM1MDMwWjAjBgkqhkiG9w0BCQQxFgQU+dUO98Fix+9ccVbD+V11ePofwiYw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAnbCK/hXseXwlWtFymEMTiQWe1en1uFeLssj2dp1a 96T4jxPYPRifLAll1f0c2Y2cd36mdpijAAYHnljP8VaNuDHEAjrEVnlePop0qaTZhuq375C0 LGjkPtplham+RcBF/GpB43LJzCRqfYJGy+/Lo1EVSCWHLAFLlZoNeMkYJD5OGwGparFnvEwb fQ9CxBEQbJ7udFVaOaJNJ8AJh2TJSfgrIdk8LVc/kWkCMyBch18nFm2FgECNeMyjZCzsH5x+ KOvo16XWT3pUxrHyKiltPXnUHMlQeujaKTDlZ1crEnvsdiOND/hbdoHzHDKYobvgWTLJTzU6 9HS/8C5jSjoEXAAAAAAAAA== --------------ms010705090102040002020608-- --===============1094364218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1094364218==-- From kitten-bounces@ietf.org Fri Nov 5 19:52:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06758; Fri, 5 Nov 2004 19:52:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEp1-0000vV-B9; Fri, 05 Nov 2004 19:52:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEYT-0002SU-Bu; Fri, 05 Nov 2004 19:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQETm-0000ts-Qe for kitten@megatron.ietf.org; Fri, 05 Nov 2004 19:30:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05209 for ; Fri, 5 Nov 2004 19:30:51 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQETn-0000Or-S0 for kitten@ietf.org; Fri, 05 Nov 2004 19:30:56 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 16:30:22 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 16:30:22 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 16:30:17 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 16:30:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 16:30:21 -0800 Message-ID: Thread-Topic: Comments on Larry's SPNEGO draft thread-index: AcTDkRsqGuIiuilHRYmgHBmNhfxZRwABjsTg From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 06 Nov 2004 00:30:21.0822 (UTC) FILETIME=[CCE479E0:01C4C397] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, raeburn@MIT.EDU Subject: RE: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Martin, the current draft only discusses mechanisms that are fully compliant with RFC2744/2743. I CAN NOT discuss the implementation details of NTLMSSP because 1) it is not relevant here, 2) one needs a protocol license to get the information you are asking for. -- Larry -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Friday, November 05, 2004 3:42 PM To: Liqiang(Larry) Zhu Cc: raeburn@MIT.EDU; kitten@ietf.org; martin.rex@sap.com Subject: Re: Comments on Larry's SPNEGO draft Liqiang\ wrote: >=20 > > And, frankly, I think having the latitude to implement things so as=20 > > to test for broken assumptions makes a lot of sense, particularly in > > what's supposed to be a generic framework. >=20 > But this is not specific to SPNEGO and it dose not belong to here. > furthermore, the word SHOULD does allow you test applications properly. It's nice to have and it doesn't hurt. >=20 > > So even if generating the token for the preferred mech is an=20 > > expensive operation or involves prompting the user for input, and is > > known only to be supported by a couple of servers out of the dozens=20 > > that the client will use, you think the token should be generated=20 > > before negotiating whether the mech will be used? >=20 > Using the optimistic token allows you to select the next available mech. > It is a broken design if your gss_init_sec_context involves a prompt=20 > (and that is not part of 2743/2744), even worse without letting the=20 > users know what the credentials will be used for. This is a security=20 > weakness on your side, and we do not have this in SSPI. Pardon me -- which SSPI are we discussing. According to my MSDN documentation, Microsoft's SSPI has the following context attribute flag that can be requested from InitializeSecurityContext(): PROMPT_FOR_CREDS If the client is an interactive user, the security package must, if possible, prompt the user for the appropriate credentials.=20 And My VS98\VC98\INLCUDE\SSPI.H file dated 24-Apr-1998 contains the following definition: #define ISC_REQ_PROMPT_FOR_CREDS 0x00000040 I never tried this, so I don't know whether Microsoft's SSPs are conforming with Microsoft's SSPI spec, however I don't see how that popup could possibly inform the user about the purpose of the password prompt. With NTLM, one doesn't have to supply a target name, and with Kerberos User2User (which Microsoft's Kerberos SSP offers) it should not _technically_ be necessary to provide a target name, although I haven't tested what happens if I do not supply the peers name. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 5 19:54:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07187; Fri, 5 Nov 2004 19:54:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEqj-00013h-St; Fri, 05 Nov 2004 19:54:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEZF-0002Yt-36; Fri, 05 Nov 2004 19:36:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEWx-00023n-4N for kitten@megatron.ietf.org; Fri, 05 Nov 2004 19:34:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05408 for ; Fri, 5 Nov 2004 19:34:07 -0500 (EST) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEWx-0000Sc-EJ for kitten@ietf.org; Fri, 05 Nov 2004 19:34:12 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id iA60Y8T4013938; Fri, 5 Nov 2004 19:34:09 -0500 (EST) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id iA60Y71U018368 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 5 Nov 2004 19:34:07 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <909C8866-2F8B-11D9-8DA2-000A95909EE2@mit.edu> From: Ken Raeburn Date: Fri, 5 Nov 2004 19:34:05 -0500 To: "Liqiang\(Larry\) Zhu" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On Nov 5, 2004, at 18:23, Liqiang((Larry)) Zhu wrote: >> So even if generating the token for the preferred mech is an expensive >> operation or involves prompting the user for input, and is known only >> to be supported by a couple of servers out of the dozens that the > client >> will use, you think the token should be generated before negotiating >> whether the mech will be used? > > Using the optimistic token allows you to select the next available > mech. > It is a broken design if your gss_init_sec_context involves a prompt > (and that is not part of 2743/2744), even worse without letting the > users know what the credentials will be used for. This is a security > weakness on your side, and we do not have this in SSPI. Well, forget the prompting then. Expensive operations (big calculations, excessive directory queries, etc), then. If it's the preferred method for use with the servers that support it, and known to be supported only by a few servers of the many the user is likely to contact, the work should still be done for every server anyways? Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 5 20:16:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09264; Fri, 5 Nov 2004 20:16:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQFBi-0001mI-R6; Fri, 05 Nov 2004 20:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQF5M-00033h-Ug; Fri, 05 Nov 2004 20:09:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEvv-0000Ia-Nw for kitten@megatron.ietf.org; Fri, 05 Nov 2004 19:59:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08129 for ; Fri, 5 Nov 2004 19:59:56 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEvx-0001Lv-7G for kitten@ietf.org; Fri, 05 Nov 2004 20:00:01 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 16:59:29 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 16:59:27 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 16:59:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 16:59:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2004 16:59:26 -0800 Message-ID: Thread-Topic: Comments on Larry's SPNEGO draft thread-index: AcTDmF8bg7rY2LLZQdyv9t4NyCrGYwAAnpVg From: "Liqiang\(Larry\) Zhu" To: "Ken Raeburn" X-OriginalArrivalTime: 06 Nov 2004 00:59:26.0990 (UTC) FILETIME=[DD17FAE0:01C4C39B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Ken Raeburn wrote: > If it's the preferred method for use with the servers that support it, > and known to be supported only by a few servers of=20 > the many the user is likely to contact, the work should still be=20 > done for every server anyways? You want to avoid/delay these expensive operations till we know for sure what is the common mech. This should be allowed. In that case, I would reluctantly agree to demote the "SHOULD" to "MAY", but as a compromise I would add that the receiver MUST process the optimistic token if one is included. Do you agree? -- larry -----Original Message----- From: Ken Raeburn [mailto:raeburn@MIT.EDU]=20 Sent: Friday, November 05, 2004 4:34 PM To: Liqiang(Larry) Zhu Cc: Subject: Re: Comments on Larry's SPNEGO draft On Nov 5, 2004, at 18:23, Liqiang((Larry)) Zhu wrote: >> So even if generating the token for the preferred mech is an=20 >> expensive operation or involves prompting the user for input, and is=20 >> known only to be supported by a couple of servers out of the dozens=20 >> that the > client >> will use, you think the token should be generated before negotiating=20 >> whether the mech will be used? > > Using the optimistic token allows you to select the next available=20 > mech. > It is a broken design if your gss_init_sec_context involves a prompt=20 > (and that is not part of 2743/2744), even worse without letting the=20 > users know what the credentials will be used for. This is a security=20 > weakness on your side, and we do not have this in SSPI. Well, forget the prompting then. Expensive operations (big calculations, excessive directory queries, etc), then. If it's the preferred method for use with the servers that support it, and known to be supported only by a few servers of the many the user is likely to contact, the work should still be done for every server anyways? Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 5 21:14:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13195; Fri, 5 Nov 2004 21:14:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQG68-0002zx-F0; Fri, 05 Nov 2004 21:14:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQFsL-00084k-4y; Fri, 05 Nov 2004 21:00:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQFH4-0005hG-Ls for kitten@megatron.ietf.org; Fri, 05 Nov 2004 20:21:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09508 for ; Fri, 5 Nov 2004 20:21:49 -0500 (EST) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQFH6-0001rB-GA for kitten@ietf.org; Fri, 05 Nov 2004 20:21:52 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id iA61Lnef026280; Fri, 5 Nov 2004 20:21:49 -0500 (EST) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id iA61Lm1U021532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 5 Nov 2004 20:21:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <909C8866-2F8B-11D9-8DA2-000A95909EE2@mit.edu> References: <909C8866-2F8B-11D9-8DA2-000A95909EE2@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39F94049-2F92-11D9-8DA2-000A95909EE2@mit.edu> From: Ken Raeburn Date: Fri, 5 Nov 2004 20:21:46 -0500 To: Liqiang((Larry)) Zhu , "" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 05 Nov 2004 21:00:18 -0500 Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit *sigh* I thought I recalled RFC 2119 better than I did. "SHOULD" carries less weight than I thought it did, and the same weight as "RECOMMENDED", which I was going to suggest as sounding weaker than (I thought) "SHOULD" sounded, while still encouraging developers to go in that direction. So, I guess I'm okay with "SHOULD" (or "RECOMMENDED") after all. Sorry... Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 8 01:19:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12773; Mon, 8 Nov 2004 01:19:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR2sn-0007mu-SM; Mon, 08 Nov 2004 01:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR2gD-0002Kx-RJ; Mon, 08 Nov 2004 01:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR2f0-00020y-HN for kitten@megatron.ietf.org; Mon, 08 Nov 2004 01:05:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11056 for ; Mon, 8 Nov 2004 01:05:49 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR2fU-0007Pu-Ez for kitten@ietf.org; Mon, 08 Nov 2004 01:06:20 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Nov 2004 22:05:21 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Sun, 7 Nov 2004 22:05:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Sun, 7 Nov 2004 22:05:18 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Sun, 7 Nov 2004 22:05:17 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2004 22:05:15 -0800 Message-ID: Thread-Topic: SPNEGO issues to be addressed in the next version Thread-Index: AcTFWOfFfk2iwH4EScypjchBwZg0Kg== From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 08 Nov 2004 06:05:17.0449 (UTC) FILETIME=[EBA54F90:01C4C558] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Subject: SPNEGO issues to be addressed in the next version X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable As I promised, the next version should be out shortly after IETF61. 1) Sam: section 3.2 (b) and (d) seemed to be self inconsistent, this is corrected/clarified now. 2) Sam and Martin: consideration of non-standard track mechanisms: if the target does not support negotiation, should we return BAD_MECH or DEFFECTIVE_TOKEN?=20 3) Martin and Sam: the support of negotiation without integrity. Perhaps this should be added back. 4) Sam, Ken, and Martin: SHOULD or MAY? on the use of optimistic token. Wyllys requested an example where the optimistic token is not used. The latest draft is updated with new details. 5) Sam and Martin: the support of partially established context, no disagreement, but Martin suggested pre-emptive clarifications. 6) Sam and Wyllys: on the rules for when it is safe to omit MIC. This was designed to interop with Windows2000/WindowsXP/Windows2003 SPNEGO when there is no interference. This is perhaps the most controversial part of this draft. Sam and Wyllys were looking into these. We should discuss these in details in the next few days. I am putting down a separate section to discuss these now. 7) Sam, further clarifications on how the MIC token is computed. 8) Sam, what is the possible use of extensibility marker 9) Wyllys: fair amount of editorial issues, these are fixed now. 10) Wyllys: should the MIC token be used to protect reqFlags as well? 11) Luke, should we use out-of-band mechanisms for SPNEGO to negotiate whether the implementations are updated to support mechListMIC? Aka the GSS_C_EXPECTING_MECH_LIST_MIC_FLAG GssChecksum flag. -- Larry _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 8 15:05:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22677; Mon, 8 Nov 2004 15:05:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFli-0003vU-OA; Mon, 08 Nov 2004 15:05:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFVM-0006CB-55; Mon, 08 Nov 2004 14:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRF7n-0000Zg-0L for kitten@megatron.ietf.org; Mon, 08 Nov 2004 14:24:23 -0500 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.206.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17405 for ; Mon, 8 Nov 2004 14:24:21 -0500 (EST) Received: from [130.129.134.169] ([130.129.134.169]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iA8JOLZW021743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Nov 2004 14:24:22 -0500 (EST) Message-ID: <418FC816.80609@columbia.edu> Date: Mon, 08 Nov 2004 14:25:10 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.19 Subject: IETF 61 Kitten WG Presentations X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0439137805==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a cryptographically signed message in MIME format. --===============0439137805== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090001060808060006080707" This is a cryptographically signed message in MIME format. --------------ms090001060808060006080707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The presentations for today's IETF61 Kitten meeting can be found online in PowerPoint and PDF formats at: http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.ppt http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.pdf The meeting will take place at 15:30 EST. Online participation is encouraged via Jabber: Jabber Server: ietf.xmpp.org Room Name: kitten Jeffrey Altman --------------ms090001060808060006080707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTA4MTkyNTEwWjAjBgkqhkiG9w0BCQQxFgQU8rj4rU/FAqsrHgyERuAYcFYTVi4w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAeX1RdlpWOY8xDvYEMhoIcMZHb63m8pj62zdiwrLl 5aAhSyMG2ZDl8JnKXSajqQxsqDwcH5P8qI+fcNOxxJquGPNN0V7qrqUiHZttaKSPvSY63P6e EqnVZ8CC7azESncYrLJCcPfEmrvjczRqKdVPGqAYRvp2fwC0BQMNzS9bGGqJHfXhid4NnV9M FJ/U0NrLe601+o5aSxaOu/YWPfETGKWywrQ0UYuHeg+h2M9NLgNQSeJVvak4JJ6S5vX8rK6J aysvMU6BcBfuB6P4W6gj3AnxuMEau5jYHhKZ6KaStu0mDj111QkL1euCJKdy5aTFTNEBASj9 4Abqf9TNjxUiSQAAAAAAAA== --------------ms090001060808060006080707-- --===============0439137805== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0439137805==-- From kitten-bounces@ietf.org Mon Nov 8 15:07:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23339; Mon, 8 Nov 2004 15:07:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFoZ-00042z-2B; Mon, 08 Nov 2004 15:08:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFWa-0006Sn-MX; Mon, 08 Nov 2004 14:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFGV-0001da-V8 for kitten@megatron.ietf.org; Mon, 08 Nov 2004 14:33:24 -0500 Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18373 for ; Mon, 8 Nov 2004 14:33:21 -0500 (EST) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CRFGQ-0000f1-00 for ; Mon, 08 Nov 2004 20:33:18 +0100 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Nov 2004 20:33:18 +0100 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Nov 2004 20:33:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: kitten@ietf.org From: Simon Josefsson Date: Mon, 08 Nov 2004 20:33:12 +0100 Lines: 7 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:3P20vSH1YB2O6KmzIEjklkofiM0= Subject: Add PRF_READY flag (similar to PROT_READY) for PRF? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Would it make sense to add a new GSS_Init_sec_context flag PRF_READY to make it possible to use the PRF function earlier? The flag would be similar to PROT_READY. Alternatively, overload the PROT_READY flag to mean that the PRF function is ready too? Just an idea, Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 8 15:08:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23390; Mon, 8 Nov 2004 15:08:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFol-00043o-QE; Mon, 08 Nov 2004 15:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFWg-0006Um-HL; Mon, 08 Nov 2004 14:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFHq-0001sm-Rl for kitten@megatron.ietf.org; Mon, 08 Nov 2004 14:34:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18480 for ; Mon, 8 Nov 2004 14:34:45 -0500 (EST) Received: from [130.129.135.209] (helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFIR-0002xA-8M for kitten@ietf.org; Mon, 08 Nov 2004 14:35:24 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id D1D6CE0037; Mon, 8 Nov 2004 14:34:47 -0500 (EST) To: Ken Raeburn References: <5C391168-2F75-11D9-8DA2-000A95909EE2@mit.edu> From: Sam Hartman Date: Mon, 08 Nov 2004 14:34:47 -0500 In-Reply-To: <5C391168-2F75-11D9-8DA2-000A95909EE2@mit.edu> (Ken Raeburn's message of "Fri, 5 Nov 2004 16:55:08 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >>>>> "Ken" == Ken Raeburn writes: >>> What convincing problem do you have with MAY? >> The following argument should justify a SHOULD (or even a >> MUST). >> >> "The optimistic token SHOULD always be provided. This is >> because if you do not use the optimistic token, and >> gss_init_sec_context fails with a continue-able/non-fatal error >> after the two sides already agree upon a common mech, we can >> not renegotiate the next best available mechanism. That is not >> acceptable." Ken> So even if generating the token for the preferred mech is an Ken> expensive operation or involves prompting the user for input, Ken> and is known only to be supported by a couple of servers out Ken> of the dozens that the client will use, you think the token Ken> should be generated before negotiating whether the mech will Ken> be used? Yes absolutely. You need to generate a initial token for any mechanism you offer to guarantee that you can actually do so. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 8 15:51:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00123; Mon, 8 Nov 2004 15:51:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGUI-0005GB-Uv; Mon, 08 Nov 2004 15:51:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGEU-0008D5-2N; Mon, 08 Nov 2004 15:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRG2F-0000ya-Im for kitten@megatron.ietf.org; Mon, 08 Nov 2004 15:22:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25754 for ; Mon, 8 Nov 2004 15:22:41 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRG2g-0004R7-QM for kitten@ietf.org; Mon, 08 Nov 2004 15:23:21 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA19482; Mon, 8 Nov 2004 21:21:55 +0100 (MEZ) From: Martin Rex Message-Id: <200411082021.VAA05935@uw1048.wdf.sap.corp> To: hartmans@mit.edu (Sam Hartman) Date: Mon, 8 Nov 2004 21:21:55 +0100 (MET) In-Reply-To: from "Sam Hartman" at Nov 8, 4 02:34:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > Ken> So even if generating the token for the preferred mech is an > Ken> expensive operation or involves prompting the user for input, > Ken> and is known only to be supported by a couple of servers out > Ken> of the dozens that the client will use, you think the token > Ken> should be generated before negotiating whether the mech will > Ken> be used? > > Yes absolutely. You need to generate a initial token for any > mechanism you offer to guarantee that you can actually do so. I do not agree. Although it might be a good in many environments if SPNEGO would check each mechanism for credentials availability (i.e. gss_acquire_cred) before listing it in the mechanism list, I don't think that it is (or should be) a general requirement. I don't think that doing the initial gss_init_sec_context() for every mechanism in advance is a good idea. There are too many "mechanisms" in widespread use that require entry of either a longterm secret or a passphrase which protects the longterm secret, and I think none of those should query the user for a secret unless there is a high probability it is actually required for succeeding. The majority of authentication systems currently in use is still password-based, unfortunately. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 8 15:59:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01135; Mon, 8 Nov 2004 15:59:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGcv-0005SJ-1Z; Mon, 08 Nov 2004 16:00:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGSt-0006oq-HX; Mon, 08 Nov 2004 15:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRGBY-0005bW-JH for kitten@megatron.ietf.org; Mon, 08 Nov 2004 15:32:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26741 for ; Mon, 8 Nov 2004 15:32:18 -0500 (EST) Received: from [130.129.135.209] (helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGC9-0004hZ-CY for kitten@ietf.org; Mon, 08 Nov 2004 15:32:58 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id EB2C3E0037; Mon, 8 Nov 2004 15:32:18 -0500 (EST) To: martin.rex@sap.com References: <200411082021.VAA05935@uw1048.wdf.sap.corp> From: Sam Hartman Date: Mon, 08 Nov 2004 15:32:18 -0500 In-Reply-To: <200411082021.VAA05935@uw1048.wdf.sap.corp> (Martin Rex's message of "Mon, 8 Nov 2004 21:21:55 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org Subject: Re: Comments on Larry's SPNEGO draft X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >>>>> "Martin" == Martin Rex writes: Martin> I don't think that doing the initial Martin> gss_init_sec_context() for every mechanism in advance is a Martin> good idea. Then we need to do something more complex. For Kerberos you really need to do the init_sec_ctx because until you do that you don't know if the target has credentials. BTW, are you going to be on jabber for this meeting? (kitten@xmpp.ietf.org) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 9 11:22:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15659; Tue, 9 Nov 2004 11:22:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYmJ-0007yj-Bz; Tue, 09 Nov 2004 11:23:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYTB-0001BK-Sg; Tue, 09 Nov 2004 11:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYRG-0000Md-Sp for kitten@megatron.ietf.org; Tue, 09 Nov 2004 11:01:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13039 for ; Tue, 9 Nov 2004 11:01:44 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYS1-0007JU-SX for kitten@ietf.org; Tue, 09 Nov 2004 11:02:35 -0500 Received: from jurassic.eng.sun.com ([129.146.81.144]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA9G1hui002954 for ; Tue, 9 Nov 2004 09:01:43 -0700 (MST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA9G1hVk961218 for ; Tue, 9 Nov 2004 08:01:43 -0800 (PST) Message-ID: <4190E9E4.9010504@sun.com> Date: Tue, 09 Nov 2004 11:01:40 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: SPNEGO and MechListMIC field X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit If I recall correctly (and from looking at my own code), in order to interoperate with Microsoft's SPNEGO implementation, the MIC must never be sent by an initiator nor should it be expected or processed by an acceptor. If this is the case, then I don't think we risk breaking backwards compatibility by including the reqFlags in the MIC calculation for the new spec. It would obviously be incompatible with the current spec, but the risk of breaking deployed implementations is very small. So, someone remind me again, why not put reqFlags in the MIC ? -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 9 12:34:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23228; Tue, 9 Nov 2004 12:34:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZuH-0001dd-JQ; Tue, 09 Nov 2004 12:35:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZko-0005C9-RP; Tue, 09 Nov 2004 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZap-0002FK-8B for kitten@megatron.ietf.org; Tue, 09 Nov 2004 12:15:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21438 for ; Tue, 9 Nov 2004 12:15:40 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZbS-00015e-06 for kitten@ietf.org; Tue, 09 Nov 2004 12:16:32 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id SAA17382; Tue, 9 Nov 2004 18:14:56 +0100 (MEZ) From: Martin Rex Message-Id: <200411091714.SAA13645@uw1048.wdf.sap.corp> To: wyllys.ingersoll@sun.com (Wyllys Ingersoll) Date: Tue, 9 Nov 2004 18:14:57 +0100 (MET) In-Reply-To: <4190E9E4.9010504@sun.com> from "Wyllys Ingersoll" at Nov 9, 4 11:01:40 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 1.2 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO and MechListMIC field X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 8bit Wyllys Ingersoll wrote: > > If I recall correctly (and from looking at my own code), in order to > interoperate with Microsoft's SPNEGO implementation, the MIC must > never be sent by an initiator nor should it be expected or processed > by an acceptor. I have no experience with Microsoft's SPNEGO implementation, so I'm curious: The situation that an initiator would be required to send a mechListMIC would only happen for an odd number of context establishment tokens, accompanying the final context establishment token from initiator to target. For rfc-1964 this would affect target-only authentication (i.e. when "mutual" authentication is not requested), and for Microsoft's Kerberos SSP it would also affect the proprietary user2user authentication (which is quite difficult to avoid when the KDC is a W2K3 AD in W2K3 native mode). The absence of the mechListMIC token is equivalent to *NO* protection of the negotiation. As the purpose of the protection is primarily to prevent a downgrade attack on a mechanism List that includes weak mechanisms, there shouldn't be a problem when the strongest available choice is Kerberos and the negotiation result is Kerberos, even when the mechListMic is absent. There will be a problem when stronger mechanisms (or stronger variants of Kerberos) are added. In the original SPNEGO spec, the mechListMIC was a MUST. How much of the must can we retain in the successor spec, i.e. how tightly can we identify the interop scenarios with broken SPNEGO implementations so that we can actually retain the "P" of SPNEGO. Keep in mind that the many of PKI-based gssapi mechanisms have an odd number of security context tokens in the handshake! I would prefer when we could keep the MUST send mechListMIC, but document the precise interop scenarios for a particular broken implementation, so any SPNEGO that negotiate and starts a handshake with a non-rfc1964 (and non-microsoft-user2user?) mechanism MUST send the mechListMIC as the original spec required. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 9 14:24:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03245; Tue, 9 Nov 2004 14:24:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbck-0004EZ-1n; Tue, 09 Nov 2004 14:25:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbXc-0001XE-8E; Tue, 09 Nov 2004 14:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbTZ-0000cn-NM for kitten@megatron.ietf.org; Tue, 09 Nov 2004 14:16:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02626 for ; Tue, 9 Nov 2004 14:16:20 -0500 (EST) Received: from [130.129.135.209] (helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbUM-00043c-LI for kitten@ietf.org; Tue, 09 Nov 2004 14:17:12 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id B0EF8E003B; Tue, 9 Nov 2004 14:16:26 -0500 (EST) To: martin.rex@sap.com References: <200411091714.SAA13645@uw1048.wdf.sap.corp> From: Sam Hartman Date: Tue, 09 Nov 2004 14:16:26 -0500 In-Reply-To: <200411091714.SAA13645@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Nov 2004 18:14:57 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kitten@ietf.org Subject: Re: SPNEGO and MechListMIC field X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 FYI, we had a discussion with Larry over lunch and he convinced us that his negotiation rules are reasonable and always provide protection for a new implementation. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 9 17:46:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23290; Tue, 9 Nov 2004 17:46:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRelR-0000j6-4l; Tue, 09 Nov 2004 17:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRea2-0003Mu-Dy; Tue, 09 Nov 2004 17:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReOf-0000J7-G0 for kitten@megatron.ietf.org; Tue, 09 Nov 2004 17:23:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20828 for ; Tue, 9 Nov 2004 17:23:26 -0500 (EST) Received: from [130.129.133.236] (helo=nutcracker.it.su.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRePU-00007M-Mj for kitten@ietf.org; Tue, 09 Nov 2004 17:24:21 -0500 Received: by nutcracker.it.su.se (Postfix, from userid 913) id 37AA434C1AC; Tue, 9 Nov 2004 23:22:25 +0100 (CET) To: kitten@ietf.org From: Love User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) Date: Tue, 09 Nov 2004 23:22:17 +0100 Message-ID: MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896983806==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --===============0896983806== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= I think that sasl needs to be modified to use domain based names. rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE with service and hostname as service@hostname. and since nico uses ldap, that uses sasl, as an example. I think think needs to make into consideration if the example is ever is going to work. Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (NetBSD) iQIVAwUAQZFDIBZyDLTSep3UAQJaNQ//Zs3DQP7cilriG3Fic/k1I9eXTddpULIu x9CZe/tyC/ky8S27qiSeWnbd92kjnSMWKpKXhEo6ZpQx0l2ZFbTsjCNlxvICNQVG pp4Y4N8s8lZ2Mxl0TQZcus7Ij1kiv9iKPY45Gt8Ul5DDUq//NjFFgkncUzTn+f+3 zxqtqdH535vZbFl65wPTKbRM8F3EHqk6IpRBNzhg4VvdlUeWKZO++XraWg+N/Fhd shWq/lWrYWTuCQPXZT01a2XR0zwmw4LY342+RR6lc8cuXjwTf17nW+ioRuTgFOhE m7DgAMznQWnpgy7+IoEtoZYf+zqccJu23pfCrIAT4N0NgbH7A2OzFAhgoG7xrlhd 4tGfwL5TS5x4yfd5Ii24plIYlmBKw2iDooxi/Mjg1whilcTqHcYcB6D26/wPp/rN nvLBj3a9IsWltpscv7Ci1YmOYob/6v1hixp6SflztQUZysc4R/4xNwQshi81N9M4 SmkCORyiq1sq69NrMY/rTZQMXXlrmixqluqZL4XwT+OzDRrz+SB3NRpCfwzS3LAV bLaX+TpGsggodlHI44lf9yyxDVmnEImkJ4iiHgrXRpmY+7uUgz0Bur+0NhQ+98oq 3sjdxgNkSoatDTbZaUUV+fwGvOS2HOz24T6qyja/6Y2R8NCgkCKecQdOknzrMXg3 meGfsOgKshI= =TX9b -----END PGP SIGNATURE----- --=-=-=-- --===============0896983806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0896983806==-- From kitten-bounces@ietf.org Tue Nov 9 18:34:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28312; Tue, 9 Nov 2004 18:34:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRfVr-0001k9-GQ; Tue, 09 Nov 2004 18:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfTG-0002JY-UB; Tue, 09 Nov 2004 18:32:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfRZ-0001o8-Jc for kitten@megatron.ietf.org; Tue, 09 Nov 2004 18:30:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27787 for ; Tue, 9 Nov 2004 18:30:30 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRfSP-0001g9-2O for kitten@ietf.org; Tue, 09 Nov 2004 18:31:25 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA9NUVNH019653 for ; Tue, 9 Nov 2004 16:30:31 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA9NUTJf028263 for ; Tue, 9 Nov 2004 16:30:29 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA9NTuE9472200; Tue, 9 Nov 2004 17:29:56 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA9NTsEd472199; Tue, 9 Nov 2004 17:29:54 -0600 (CST) Date: Tue, 9 Nov 2004 17:29:54 -0600 From: Nicolas Williams To: Love Message-ID: <20041109232954.GI102351@binky.central.sun.com> Mail-Followup-To: Love , kitten@ietf.org, ietf-sasl@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Re: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Tue, Nov 09, 2004 at 11:22:17PM +0100, Love wrote: > > I think that sasl needs to be modified to use domain based names. > > rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE with service > and hostname as service@hostname. Yes. At this rate rfc2222bis might as well be modified accordingly and have a reference to the domain based naming i-d added to be. > and since nico uses ldap, that uses sasl, as an example. I think think > needs to make into consideration if the example is ever is going to work. Yes. Thanks for pointing this out. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 9 18:40:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29023; Tue, 9 Nov 2004 18:40:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRfc8-0001wq-Jl; Tue, 09 Nov 2004 18:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfYP-0003dt-Pa; Tue, 09 Nov 2004 18:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRfUH-0002bE-Qu for kitten@megatron.ietf.org; Tue, 09 Nov 2004 18:33:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28205 for ; Tue, 9 Nov 2004 18:33:18 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRfV3-0001j5-GL for kitten@ietf.org; Tue, 09 Nov 2004 18:34:14 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA9NXFs3000278 for ; Tue, 9 Nov 2004 15:33:15 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA9NXEJh029276 for ; Tue, 9 Nov 2004 16:33:14 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA9NWfXL472221; Tue, 9 Nov 2004 17:32:41 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iA9NWe0w472206; Tue, 9 Nov 2004 17:32:40 -0600 (CST) Date: Tue, 9 Nov 2004 17:32:40 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20041109233240.GJ102351@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@ietf.org Subject: Re: Add PRF_READY flag (similar to PROT_READY) for PRF? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Mon, Nov 08, 2004 at 08:33:12PM +0100, Simon Josefsson wrote: > Would it make sense to add a new GSS_Init_sec_context flag PRF_READY > to make it possible to use the PRF function earlier? The flag would > be similar to PROT_READY. Alternatively, overload the PROT_READY flag > to mean that the PRF function is ready too? I thought about this and decided against it on the KISS principle. Of course, the EAP folks may disagree. I suppose I should as them... I will. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 10 01:19:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28957; Wed, 10 Nov 2004 01:19:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRlqE-0001Ir-TV; Wed, 10 Nov 2004 01:20:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRloW-0008QO-Bs; Wed, 10 Nov 2004 01:18:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRllX-00087k-NC for kitten@megatron.ietf.org; Wed, 10 Nov 2004 01:15:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28681 for ; Wed, 10 Nov 2004 01:15:34 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRlmQ-0001Dr-Jg for kitten@ietf.org; Wed, 10 Nov 2004 01:16:31 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2004 22:15:41 -0800 X-BrightmailFiltered: true Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAA6Eucj009375; Tue, 9 Nov 2004 22:14:56 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.240.221]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Nov 2004 22:16:45 -0800 From: "Joseph Salowey" To: "'Nicolas Williams'" , "'Simon Josefsson'" Date: Tue, 9 Nov 2004 22:14:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041109233240.GJ102351@binky.central.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcTGtdd+PUst25u6Ty+0Yo9M8Lt82AANn2Fw Message-ID: X-OriginalArrivalTime: 10 Nov 2004 06:16:45.0862 (UTC) FILETIME=[DACC4C60:01C4C6EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: RE: Add PRF_READY flag (similar to PROT_READY) for PRF? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit I'm jumping in the middle of the conversation, but I don't see what EAP would require to know this early. Joe kitten-bounces@lists.ietf.org wrote: > On Mon, Nov 08, 2004 at 08:33:12PM +0100, Simon Josefsson wrote: >> Would it make sense to add a new GSS_Init_sec_context flag PRF_READY >> to make it possible to use the PRF function earlier? The flag would >> be similar to PROT_READY. Alternatively, overload the PROT_READY >> flag to mean that the PRF function is ready too? > > I thought about this and decided against it on the KISS > principle. Of course, the EAP folks may disagree. I suppose > I should as them... I will. > > Nico _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 10 10:16:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17675; Wed, 10 Nov 2004 10:16:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuDx-0004d9-Ck; Wed, 10 Nov 2004 10:17:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtw7-0007J1-Pf; Wed, 10 Nov 2004 09:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtmi-0005FW-1C for kitten@megatron.ietf.org; Wed, 10 Nov 2004 09:49:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13846 for ; Wed, 10 Nov 2004 09:49:18 -0500 (EST) Received: from [130.129.135.209] (helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtnf-0003mu-CL for kitten@ietf.org; Wed, 10 Nov 2004 09:50:20 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 3783DE003B; Wed, 10 Nov 2004 09:49:26 -0500 (EST) To: Love References: <20041109232954.GI102351@binky.central.sun.com> From: Sam Hartman Date: Wed, 10 Nov 2004 09:49:26 -0500 In-Reply-To: <20041109232954.GI102351@binky.central.sun.com> (Nicolas Williams's message of "Tue, 9 Nov 2004 17:29:54 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Re: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Nov 09, 2004 at 11:22:17PM +0100, Love wrote: >> I think that sasl needs to be modified to use domain based >> names. >> >> rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE >> with service and hostname as service@hostname. Nicolas> Yes. At this rate rfc2222bis might as well be modified Nicolas> accordingly and have a reference to the domain based Nicolas> naming i-d added to be. Are there any 2222 implications or is it just a gssapi implication? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 10 16:22:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05423; Wed, 10 Nov 2004 16:22:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzvm-0007mM-SN; Wed, 10 Nov 2004 16:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzmf-0001UY-BJ; Wed, 10 Nov 2004 16:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRylT-00038j-2t for kitten@megatron.ietf.org; Wed, 10 Nov 2004 15:08:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21147 for ; Wed, 10 Nov 2004 15:08:21 -0500 (EST) Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRymU-0003p1-7C for kitten@ietf.org; Wed, 10 Nov 2004 15:09:26 -0500 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAAK8EZv074763; Wed, 10 Nov 2004 20:08:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041110150627.03368e50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 10 Nov 2004 15:08:39 -0500 To: Sam Hartman From: "Kurt D. Zeilenga" In-Reply-To: References: <20041109232954.GI102351@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Wed, 10 Nov 2004 16:13:40 -0500 Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Re: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 At 09:49 AM 11/10/2004, Sam Hartman wrote: >>>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Tue, Nov 09, 2004 at 11:22:17PM +0100, Love wrote: > >> I think that sasl needs to be modified to use domain based > >> names. > >> > >> rfc2222 specifies it want to use GSS_C_NT_HOSTBASED_SERVICE > >> with service and hostname as service@hostname. To be clear, its the "GSSAPI" mechanism specification in RFC 2222 which wants this... not the SASL framework specification that wants this. > Nicolas> Yes. At this rate rfc2222bis might as well be modified > Nicolas> accordingly and have a reference to the domain based > Nicolas> naming i-d added to be. > >Are there any 2222 implications or is it just a gssapi implication? This might have "GSSAPI"-bis implications (sasl-gssapi), but it shouldn't have any SASL framework (sasl-2222bis) implications. Kurt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Nov 11 02:10:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03623; Thu, 11 Nov 2004 02:10:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS97F-0002Zl-KT; Thu, 11 Nov 2004 02:11:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS94F-0002Nz-67; Thu, 11 Nov 2004 02:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS90E-0000Ds-6T for kitten@megatron.ietf.org; Thu, 11 Nov 2004 02:04:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27360 for ; Thu, 11 Nov 2004 02:04:16 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS91I-0002Rs-CB for kitten@ietf.org; Thu, 11 Nov 2004 02:05:26 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAB7497q006726 for ; Wed, 10 Nov 2004 23:04:09 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAB748Jf000858 for ; Thu, 11 Nov 2004 00:04:08 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAB73aUo473066; Thu, 11 Nov 2004 01:03:36 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAB73YPC473065; Thu, 11 Nov 2004 01:03:34 -0600 (CST) Date: Thu, 11 Nov 2004 01:03:33 -0600 From: Nicolas Williams To: "Kurt D. Zeilenga" Message-ID: <20041111070333.GT102351@binky.central.sun.com> Mail-Followup-To: "Kurt D. Zeilenga" , Sam Hartman , Love , kitten@ietf.org, ietf-sasl@imc.org References: <20041109232954.GI102351@binky.central.sun.com> <6.1.2.0.0.20041110150627.03368e50@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.0.20041110150627.03368e50@127.0.0.1> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman Subject: Re: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Love's point is that RFC2222 specifically talks about what server names are like, and that is like hostbased-services. Introducing new name types for SASL mechs may require changing this. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Nov 11 10:56:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25156; Thu, 11 Nov 2004 10:56:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHK8-0005Pe-Dy; Thu, 11 Nov 2004 10:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHFL-00041r-P8; Thu, 11 Nov 2004 10:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSH5P-0002It-Dh for kitten@megatron.ietf.org; Thu, 11 Nov 2004 10:42:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23992 for ; Thu, 11 Nov 2004 10:42:09 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSH6Z-00057o-QT for kitten@ietf.org; Thu, 11 Nov 2004 10:43:25 -0500 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iABFg87q018905 for ; Thu, 11 Nov 2004 07:42:08 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABFg7hs913418 for ; Thu, 11 Nov 2004 07:42:07 -0800 (PST) Message-ID: <4193884F.90605@sun.com> Date: Thu, 11 Nov 2004 10:42:07 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040906 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit I've attempted to condense and summarize the rules for when an acceptor and initiator need to process the MIC tokens (section 3.2). I'm not certain I've captured every nuance, but the goal is to simplify the text and clarify the rules. -Wyllys ACCEPTOR RULES 1. The initiators preferred mech is accepted by the target and acceptor could not have selected anything else no matter what the initiators sent. Initiator included initial token and no further input is needed from initiator. - MUST NOT send MIC back to initiator - return GSS_S_COMPLETE [ in short: if the target supports only 1 mechanism, and that is what the initiator requested, then no need for a MIC as long as no additional initiator tokens are needed ] 2. Initiators preferred mech is accepted, but the acceptor *could* have selected a different mech if a different list had been presented. - send MIC and "accept incomplete" status if initial token was included and no further tokens are needed from initiator. - do NOT send MIC if initial token was not included or additional initiator tokens are needed. 3. Initiators non-preferred mech is accepted. - acceptor returns GSS_S_CONTINUE_NEEDED with negotiation token and "accept_incomplete" status and the selected mechanism OID. - no MIC in response and no response mechanism token. INITIATOR RULES 4. Initiator gets "accept complete" from target, the selected mech is the original preferred mech. - initiator SHALL NOT reject if no MIC is present. * this rule is to maintain backwards compatibility ? - if MIC present, verify and return GSS_S_BAD_MIC if incorrect. 5. Initiator gets "accept complete" from target, but the selected mech is not the preferred mech and no MIC or incorrect MIC is present. - return GSS_S_BAD_MIC status 6. Initiator gets "accept_incomplete" and no further tokens from target are required to complete the context establishment. - if target returned a MIC, initiator must verify it and return GSS_S_BAD_MIC if it fails. If MIC verifies correctly, return GSS_S_COMPLETE. - if target did not include a MIC, initiator must indicate GSS_S_BAD_MIC status. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Nov 11 10:57:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25467; Thu, 11 Nov 2004 10:57:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHLs-0005S9-3a; Thu, 11 Nov 2004 10:59:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHFQ-00044V-L8; Thu, 11 Nov 2004 10:52:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHB2-00034g-8U for kitten@megatron.ietf.org; Thu, 11 Nov 2004 10:48:00 -0500 Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.206.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24523 for ; Thu, 11 Nov 2004 10:47:58 -0500 (EST) Received: from [130.129.134.169] ([130.129.134.169]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iABFlqYj007239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Nov 2004 10:47:56 -0500 (EST) Message-ID: <419389D7.6080304@columbia.edu> Date: Thu, 11 Nov 2004 10:48:39 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: housley@vigilsec.com, Sam Hartman , "Steven M. Bellovin" , kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.21 Subject: IETF61 Kitten WG Summary X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0002894855==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 This is a cryptographically signed message in MIME format. --===============0002894855== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000301040103010603030908" This is a cryptographically signed message in MIME format. --------------ms000301040103010603030908 Content-Type: multipart/mixed; boundary="------------060203060701050004060406" This is a multi-part message in MIME format. --------------060203060701050004060406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------060203060701050004060406 Content-Type: text/plain; name="ietf61-kitten-summary.txt" Content-Disposition: inline; filename="ietf61-kitten-summary.txt" Content-Transfer-Encoding: 7bit IETF 61: Kitten Working Group Summary Monday, November 8, 2004 Jeffrey Altman [chair] Presentations: http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.pdf The chair announced the creation of the working group by the IESG; reviewed the charter and the groups initial milestones. Since the BOF at IETF 60 there has been significant progress on: + describing the GSS Naming problem + solving the interoperability problems between protected SPNEGO and implementations which have been widely deployed + defining the requirements and interfaces for PRFs + C# bindings + Roadmap document Nico gave a presentation on PRF Nico gave a presentation on Domain Names Chair presented Corby Morris' presentation on C# Bindings Larry Zhu gave a presentation on SPNEGO Sam Hartman gave a presentation on GSS Naming Chair lead discussion on whether or not implementation of Kerberos 5 mechanism support for PRF and Domain Names should take place in kitten or krb-wg. DECISIONS (to be validated on the list): + Maintaining interoperability with existing deployed SPNEGO implementations is more important then the ability to add new features such as protect reqFlags + No consensus was reached on whether the use of an optimistic token in SPNEGO will be SHOULD or MAY. + There are strong feelings against the relaxing the MUST NOT applied to the negotiation of mechanisms which do not support integrity protection + The GSS Naming document will describe the problem space and not just solutions + The Kerberos 5 mechanism documents will working group documents of Kitten. We will work closely with the Kerberos WG to ensure proper review and we we last call in both. This decision was made by flipping a coin. ACTION ITEMS: + Larry Zhu will follow up on the outstanding issues with SPNEGO and report to the list by Fri Nov 19 + The chair will send a list of working group documents to the secretariat + Nico Williams will publish new I-Ds for PRF and Domain Names including results of recent on-list discussions + The Chair will contact Sun Java Security team to obtain a draft describing the incompatibilities between RFC and org.ietf.jgss + Sam Hartman will revise GSS Naming document and then hand it off to a new editor MILESTONES: Nov 04 First Meeting Dec 04 Prepare SPNEGO for Last Call Mar 05 Submit SPNEGO to the IESG as Proposed Standard Mar 05 First drafts of either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Jul 05 Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Jul 05 Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI' to the IESG as Proposed Standard Jul 05 Submit 'The Simple and Protected GSS-API Negotiation Mechanism (Revised)' to the IESG as Proposed Standard Nov 05 Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service Application Program Interface Version 3' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service API Version 3 : C-bindings' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service API Version 3 : Java and C# bindings' to the IESG as Proposed Standard Nov 06 Charter Review --------------060203060701050004060406-- --------------ms000301040103010603030908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTExMTU0ODM5WjAjBgkqhkiG9w0BCQQxFgQUuvHwInXXVE1fv03eL/fGY1nOJC8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAeipLadLqS9povFf87zRc4O3ZK8UNEaT7xlENIII5 cUnTMvXSBfwTRx6Fg9U0EpiO+MQO/p3Y4fUHuICvhXzLWE0xq6x4r/upAH0IPVfM6aE6kTUS 5WxZYB8zslq/wWklDzvnBhpNIcbd2P2r+u3t6AaQJdSr3qvua1lrHOUS244wvNgu3kMfWicT clzmDdK5P3JRIRqwQbEcKjXp1H0Znsd6yx18zZBqYpGo/0UovU13sbKP8WrL6nYOi82bWz2m D/Ee4CZBnYQPwolpIwHeOEDjGqzpriwfm6XTzsU2UCFbjp7wr3JTolc8wEHs546R4+kZUwDR mrLngcRKJkLbxQAAAAAAAA== --------------ms000301040103010603030908-- --===============0002894855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0002894855==-- From kitten-bounces@ietf.org Thu Nov 11 11:21:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27530; Thu, 11 Nov 2004 11:21:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHii-000601-8R; Thu, 11 Nov 2004 11:22:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHgM-0001UN-KJ; Thu, 11 Nov 2004 11:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSHY7-00087X-SN for kitten@megatron.ietf.org; Thu, 11 Nov 2004 11:11:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26679 for ; Thu, 11 Nov 2004 11:11:49 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.206.20] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSHZI-0005m9-NI for kitten@ietf.org; Thu, 11 Nov 2004 11:13:05 -0500 Received: from [130.129.134.169] ([130.129.134.169]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iABGBmVa024255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Nov 2004 11:11:49 -0500 (EST) Message-ID: <41938F76.9060903@columbia.edu> Date: Thu, 11 Nov 2004 11:12:38 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <4193884F.90605@sun.com> In-Reply-To: <4193884F.90605@sun.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1846258141==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a cryptographically signed message in MIME format. --===============1846258141== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030708030406060301080505" This is a cryptographically signed message in MIME format. --------------ms030708030406060301080505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am aware that Larry has spent a great deal of time over the last couple of days working on the SPNEGO draft and the SOMIC rules in particular. I suggest we hold off discussions until Larry is able to post an updated draft next week. Jeffrey Altman Wyllys Ingersoll wrote: > > I've attempted to condense and summarize the rules for when > an acceptor and initiator need to process the MIC tokens (section 3.2). > > I'm not certain I've captured every nuance, but the goal is to simplify > the text and clarify the rules. > > -Wyllys --------------ms030708030406060301080505 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTExMTYxMjM4WjAjBgkqhkiG9w0BCQQxFgQUJ8EiokUHjOHLn2+t/cN+7pul9uIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA3C7byXu9wgczU+HxXr0TF4wyxTvdDO4SkngccoHe FruDWFYS/kmmFGRhsa0MZLn8uY7F0/46yEAxOIfSWJ0OA6UCdnrBtxKau+7HYA/jLRVOblbh OqYVhtrxHx/lDwI+lv/55GT33JX7biFSDqE0kep8rlG8bq961LnRJvDeK85S7PE4ZXypeK+r JrCgtPIP0U0YrzZXksnAiqcT566LMii480P7W0RI9xlzeqVzs1rqPXQ+rVID2GmmBrMq254v GG0qsjNuin/tFsWO1fnPuYkWuBk2vDwETPvErX09+r3K++PKzLuKq6/64HRiAzvZVfTfyXix OvwCavVSvYFmwgAAAAAAAA== --------------ms030708030406060301080505-- --===============1846258141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1846258141==-- From kitten-bounces@ietf.org Thu Nov 11 15:47:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25513; Thu, 11 Nov 2004 15:47:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLs6-0004Pc-Ae; Thu, 11 Nov 2004 15:48:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLhp-0008FT-9o; Thu, 11 Nov 2004 15:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLeS-0005RA-PK for kitten@megatron.ietf.org; Thu, 11 Nov 2004 15:34:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23256 for ; Thu, 11 Nov 2004 15:34:39 -0500 (EST) Received: from [130.129.135.209] (helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLff-0003tb-Uz for kitten@ietf.org; Thu, 11 Nov 2004 15:35:57 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 7AA1AE003B; Thu, 11 Nov 2004 15:34:49 -0500 (EST) To: Jeffrey Altman References: <4193884F.90605@sun.com> <41938F76.9060903@columbia.edu> From: Sam Hartman Date: Thu, 11 Nov 2004 15:34:49 -0500 In-Reply-To: <41938F76.9060903@columbia.edu> (Jeffrey Altman's message of "Thu, 11 Nov 2004 11:12:38 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> I am aware that Larry has spent a great deal of time over Jeffrey> the last couple of days working on the SPNEGO draft and Jeffrey> the SOMIC rules in particular. I suggest we hold off Jeffrey> discussions until Larry is able to post an updated draft Jeffrey> next week. I actually think Larry should also post a summary of the discussions as well as the draft. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 16:59:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05109; Fri, 12 Nov 2004 16:59:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjSl-0002CO-RK; Fri, 12 Nov 2004 17:00:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjKe-00086w-2r; Fri, 12 Nov 2004 16:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjCw-0004ct-R3 for kitten@megatron.ietf.org; Fri, 12 Nov 2004 16:43:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03847 for ; Fri, 12 Nov 2004 16:43:47 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjCi-0000nW-18 for kitten@ietf.org; Fri, 12 Nov 2004 16:43:47 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA14437; Fri, 12 Nov 2004 22:41:24 +0100 (MEZ) From: Martin Rex Message-Id: <200411122141.WAA19519@uw1048.wdf.sap.corp> To: wyllys.ingersoll@sun.com (Wyllys Ingersoll) Date: Fri, 12 Nov 2004 22:41:24 +0100 (MET) In-Reply-To: <4193884F.90605@sun.com> from "Wyllys Ingersoll" at Nov 11, 4 10:42:07 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Wyllys Ingersoll wrote: > > I've attempted to condense and summarize the rules for when > an acceptor and initiator need to process the MIC tokens (section 3.2). > > I'm not certain I've captured every nuance, but the goal is to simplify > the text and clarify the rules. I'm sorry, but I find your description quite difficult to understand. As I said, I would really prefer if the spec itself unconditionally required to create and send the MIC as in the original spec. In addition, I'd like to see a precise list of all scenarios for which one has to omit the mechListMic in order to interoperate with a particular broken implementation and an explanation for each case why this particular omission does not open a vulnerability. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 17:03:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05863; Fri, 12 Nov 2004 17:03:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjXa-0002X9-Lq; Fri, 12 Nov 2004 17:05:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjUG-0003qE-Sf; Fri, 12 Nov 2004 17:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjSg-0003DB-B5 for kitten@megatron.ietf.org; Fri, 12 Nov 2004 17:00:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05442 for ; Fri, 12 Nov 2004 17:00:00 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjHM-0001SI-El for kitten@ietf.org; Fri, 12 Nov 2004 16:48:27 -0500 Received: from jurassic.eng.sun.com ([129.146.84.45]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iACLkqui013660; Fri, 12 Nov 2004 14:46:53 -0700 (MST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iACLkp12219052; Fri, 12 Nov 2004 13:46:52 -0800 (PST) Message-ID: <41952E2A.7050903@sun.com> Date: Fri, 12 Nov 2004 16:42:02 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040907 X-Accept-Language: en-us, en MIME-Version: 1.0 To: martin.rex@sap.com References: <200411122141.WAA19519@uw1048.wdf.sap.corp> In-Reply-To: <200411122141.WAA19519@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Martin Rex wrote: > Wyllys Ingersoll wrote: > >>I've attempted to condense and summarize the rules for when >>an acceptor and initiator need to process the MIC tokens (section 3.2). >> >>I'm not certain I've captured every nuance, but the goal is to simplify >>the text and clarify the rules. > > > I'm sorry, but I find your description quite difficult to understand. Sorry about that. I think there were several off-list conversations about this stuff at IETF this past week. Once everyone returns and has time to digest it all, I believe a proper summary will appear on this list and in an updated draft. For now, I won't bother trying to explain my previous summary since some of what I wrote was already out of date when I wrote it. -Wyllys > > As I said, I would really prefer if the spec itself unconditionally > required to create and send the MIC as in the original spec. > > In addition, I'd like to see a precise list of all scenarios for > which one has to omit the mechListMic in order to interoperate with > a particular broken implementation and an explanation for each case > why this particular omission does not open a vulnerability. > > -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 17:12:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06255; Fri, 12 Nov 2004 17:12:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjgP-0002vA-PK; Fri, 12 Nov 2004 17:14:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjaj-0005lS-Cj; Fri, 12 Nov 2004 17:08:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjYo-0005CG-VN for kitten@megatron.ietf.org; Fri, 12 Nov 2004 17:06:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05965 for ; Fri, 12 Nov 2004 17:06:24 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.206.20] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjaE-0002ev-57 for kitten@ietf.org; Fri, 12 Nov 2004 17:07:57 -0500 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iACM6MLe020758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Nov 2004 17:06:22 -0500 (EST) Message-ID: <41953426.60403@columbia.edu> Date: Fri, 12 Nov 2004 17:07:34 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <200411122141.WAA19519@uw1048.wdf.sap.corp> In-Reply-To: <200411122141.WAA19519@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Martin Rex wrote: > Wyllys Ingersoll wrote: > >>I've attempted to condense and summarize the rules for when >>an acceptor and initiator need to process the MIC tokens (section 3.2). >> >>I'm not certain I've captured every nuance, but the goal is to simplify >>the text and clarify the rules. > > > I'm sorry, but I find your description quite difficult to understand. > > As I said, I would really prefer if the spec itself unconditionally > required to create and send the MIC as in the original spec. > > In addition, I'd like to see a precise list of all scenarios for > which one has to omit the mechListMic in order to interoperate with > a particular broken implementation and an explanation for each case > why this particular omission does not open a vulnerability. > > -Martin Martin: The IETF meeting just finished and everyone is traveling. Please give Larry a few days to return to Microsoft and send an update to the list with a summary of the in-person discussions. I think it will clear things up quite a bit. As for requiring a MIC in all cases, this is a problem if we want to ensure interoperability with the existing deployed implementations. In the meeting there was strong consensus that interoperability is a desired goal. I believe that it is possible for us to maintain a limited set of situations in which it is safe for the MIC to be omitted. I will give Larry time to explain early next week in a revised draft. Thanks. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 17:13:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06317; Fri, 12 Nov 2004 17:13:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjhA-00031g-O7; Fri, 12 Nov 2004 17:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjaj-0005lc-PA; Fri, 12 Nov 2004 17:08:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjZt-0005L4-Ux for kitten@megatron.ietf.org; Fri, 12 Nov 2004 17:07:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06023 for ; Fri, 12 Nov 2004 17:07:31 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjbJ-0002ia-1K for kitten@ietf.org; Fri, 12 Nov 2004 17:09:04 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 12 Nov 2004 14:06:58 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 12 Nov 2004 14:06:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 12 Nov 2004 14:06:58 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 12 Nov 2004 14:06:57 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Nov 2004 14:06:56 -0800 Message-ID: Thread-Topic: SPNEGO SOMIC rules Thread-Index: AcTJAtKgyGcYeGD7Smem5PB+i7grdQAAHZ3A From: "Liqiang\(Larry\) Zhu" To: , "Wyllys Ingersoll" X-OriginalArrivalTime: 12 Nov 2004 22:06:57.0505 (UTC) FILETIME=[ED362510:01C4C903] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable I am working on this right now. -- larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Friday, November 12, 2004 1:41 PM To: Wyllys Ingersoll Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules Wyllys Ingersoll wrote: >=20 > I've attempted to condense and summarize the rules for when an=20 > acceptor and initiator need to process the MIC tokens (section 3.2). >=20 > I'm not certain I've captured every nuance, but the goal is to=20 > simplify the text and clarify the rules. I'm sorry, but I find your description quite difficult to understand. As I said, I would really prefer if the spec itself unconditionally required to create and send the MIC as in the original spec. In addition, I'd like to see a precise list of all scenarios for which one has to omit the mechListMic in order to interoperate with a particular broken implementation and an explanation for each case why this particular omission does not open a vulnerability. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 17:31:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07444; Fri, 12 Nov 2004 17:31:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjyZ-0003rm-Ny; Fri, 12 Nov 2004 17:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjsb-00062f-BG; Fri, 12 Nov 2004 17:26:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSjkW-0000Ee-2P for kitten@megatron.ietf.org; Fri, 12 Nov 2004 17:18:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06520 for ; Fri, 12 Nov 2004 17:18:29 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSjlv-0003Ao-8r for kitten@ietf.org; Fri, 12 Nov 2004 17:20:02 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA17703; Fri, 12 Nov 2004 23:17:55 +0100 (MEZ) From: Martin Rex Message-Id: <200411122217.XAA20104@uw1048.wdf.sap.corp> To: wyllys.ingersoll@sun.com (Wyllys Ingersoll) Date: Fri, 12 Nov 2004 23:17:55 +0100 (MET) In-Reply-To: <41952E2A.7050903@sun.com> from "Wyllys Ingersoll" at Nov 12, 4 04:42:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit > > Sorry about that. I think there were several off-list conversations about > this stuff at IETF this past week. Once everyone returns and has time to > digest it all, I believe a proper summary will appear on this list and in > an updated draft. > > For now, I won't bother trying to explain my previous summary since > some of what I wrote was already out of date when I wrote it. OK. The purpose of the protection in SPNEGO was to assure *BOTH* sides that the negotiation wasn't doctored by an active attacker. The mechListMic is supposed to provide this assurance for both at least as long as the receiver of the mechListMIC will reliably abort when either the mechListMIC is missing or when it doesn't match. You will break the general scheme as soon as you allow one side to continue without having either sent a mechListMIC or received and verified a mechListMIC. Therefore, if it is to be permitted -- an explanation is necessary why or how there still is **MUTUAL** assurance that the negotiation was not doctored. Keep in mind that the initiator never knows which or how many mechanisms the acceptor has available. An active attacker would be able to modify the initial token sent by the initiator (remove mechanisms, reorder mechanisms, remove optimistic token), and remove a mechListMic from later negotiation tokens. Personally, I have the feeling that allowing the omission of the mechListMic token breaks the protection scheme... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 18:26:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11816; Fri, 12 Nov 2004 18:26:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSkqE-0006Kr-A9; Fri, 12 Nov 2004 18:28:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSkku-0002LG-AI; Fri, 12 Nov 2004 18:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSkkR-000270-2e for kitten@megatron.ietf.org; Fri, 12 Nov 2004 18:22:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11609 for ; Fri, 12 Nov 2004 18:22:27 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.206.20] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSklt-0006BJ-S8 for kitten@ietf.org; Fri, 12 Nov 2004 18:24:02 -0500 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iACNMRaj010481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Nov 2004 18:22:27 -0500 (EST) Message-ID: <419545E9.2080509@columbia.edu> Date: Fri, 12 Nov 2004 18:23:21 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <200411122217.XAA20104@uw1048.wdf.sap.corp> In-Reply-To: <200411122217.XAA20104@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Martin Rex wrote: > The purpose of the protection in SPNEGO was to assure *BOTH* sides > that the negotiation wasn't doctored by an active attacker. The > mechListMic is supposed to provide this assurance for both at least > as long as the receiver of the mechListMIC will reliably abort > when either the mechListMIC is missing or when it doesn't match. Martin: Please be assured that the working group, myself and the area directors are very aware of the requirement to ensure that only cases in which we can prove that both the client and server will choose the desired mechanism without outside influence can be sent without a MIC. There are a sufficient set of cases in which this is true that we can provide interoperability with the existing deployed implementations in the common cases. I expect you will be happy with the outcome. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 12 22:07:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24278; Fri, 12 Nov 2004 22:07:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSoHa-0007jb-Oa; Fri, 12 Nov 2004 22:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSoEr-0005fh-GK; Fri, 12 Nov 2004 22:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSoDH-0005DU-Bm for kitten@megatron.ietf.org; Fri, 12 Nov 2004 22:04:32 -0500 Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.206.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24086 for ; Fri, 12 Nov 2004 22:04:28 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iAD34TST023863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Nov 2004 22:04:30 -0500 (EST) Message-ID: <419579F2.1040608@columbia.edu> Date: Fri, 12 Nov 2004 22:05:22 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.21 Subject: Draft Minutes for Kitten (IETF61) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362776132==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 This is a cryptographically signed message in MIME format. --===============1362776132== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050802000100080200080900" This is a cryptographically signed message in MIME format. --------------ms050802000100080200080900 Content-Type: multipart/mixed; boundary="------------050301080208020501040003" This is a multi-part message in MIME format. --------------050301080208020501040003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The attached are very draft minutes from the meeting. I would appreciate it if presenters would review my comments on their sections. (Sam, I know the gss naming needs lots of polish I just ran out of time and wanted to get this out asap.) As a note to the working group, I will be on vacation from Nov 13 to Nov 22. Please be aware that I will not be responding to e-mail during that time period but will respond to all requests upon my return. Jeffrey Altman --------------050301080208020501040003 Content-Type: text/plain; name="ietf61-kitten-minutes.txt" Content-Disposition: inline; filename="ietf61-kitten-minutes.txt" Content-Transfer-Encoding: 8bit IETF 61: Kitten Working Group Summary Monday, November 8, 2004 Jeffrey Altman [chair] Presentations: http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.pdf The chair announced the creation of the working group by the IESG; reviewed the charter and the group's initial milestones. (please see the presentation slides for details). Since the BOF at IETF 60 there has been significant progress on: + describing the GSS Naming problem + solving the interoperability problems between protected SPNEGO and implementations which have been widely deployed + defining the requirements and interfaces for PRFs + C# bindings + producing a roadmap document Nico Williams gave a presentation on Pseudo-random function API: Many applications would like to obtain an encryption key from the GSSAPI context. Breaking the abstraction layer to obtain the negotiated key is dangerous. To solve the problem we are proposing the use of a new PRF seeded with internal keying material. Calls to GSS_Pseudo_Random() will be deterministic. When initialized with the same context and input it will produce the same output. Nico Williams gave a presentation on a Kerberos v5 GSS Mech PRF: We will construct the Krb5 PRF based on the Kerberos v5 crypto framework PRF. For new mechanisms we will always use the acceptor's subkey. For 1964 mechs the initiator subkey can be used. Key usage to be determined. Nico Williams gave a presentation on Domain based Service Names for GSS and the Krb5 Mechanism: Domain based Service names are meant mitigate against attacks caused by the use of insecure DNS SRV to obtain the host/service pair for a given domain. The generic name syntax is: @@ an OID for GSS_C_NT_DOMAINBASED_SERVICE needs to be allocated. Since the I-Ds were published the Krb5 name form was changed to //@ An open question is "how do we determine the realm of the domain?" We do not want the realm to be that of the host. + Must fold edits in for: – Domain name not optional in 'query' name form – Switch order of krb5 princ name components - Add Security considerations Both I-Ds will soon be ready for WG Last Call Chair presented Corby Morris' presentation on C# Bindings C# bindings will be very similar to the Java bindings except for some minor differences in the method declarations due to language requirements. draft-morris-java-gssapi-update-for-csharp Note: Java Security team will soon submit an update to RFC 2853 which will correct differences between the rfc and the implemented org.ietf.jgss package. Larry Zhu gave a presentation on SPNEGO: The goals for this work is to update 2478 to restore the 'P' in SPNEGO while maintaining backwards compatibility with the existing Windows SPNEGO implementation. Initial draft published: draft-zhu-spnego-2478bis-00 The basis of the backwards compatibility is provided by a set of rules called: Safe-To-Omit-MIC rules. Significant issues: + Safe-to-omit MIC rules: what are they? and when can they be used? + should we protect reqFlags? + SHOULD or MAY use optimistic token? + How is the MIC token computed? + Do we need out -of-band negotiation with down-level clients and servers? There was heavy discussion on the need for negotiation and the case for maintaining compatibility with existing implementations even though they do not implement the existing RFC. Conclusions were that negotiation is important and there is a need to provide protected negotiation while maintaining interoperability if it can be done securely. The discussion on the use of the optimistic token did not produce an opinion on the use of SHOULD vs MAY. There were strong feelings against supporting the use of mechanisms which do not provide integrity protection. No conclusion was reached on how the MIC token is to be computed. Is it over the OCTET-STREAM, with or without the OID. Sam Hartman gave a presentation on GSS Naming: The immediate goal of this document has been to describe problems that we're trying to solve to prevent scope creep. We want to support authentication of internal identities (uuids) and allow applications to work with parts of composite names. Applications should be able to query available credentials and presented names based on components and thereby find the most appropriate credential for a target. (Martin Rex points out that you can't do authentication of internal identities portably today) We think it can be portable, and Nico and I think at least we can do a lot better than we can do today. There are several levels of GSSAPI v2 compatibility we need to look at. + New mechanisms used by old applications (should they be visible? Or only do GSSAPI v2 features?) + File formats for ACLs containing names Possible Solutions include name attributes, GSSAPI credential extensions, client given ability to assert a name, a facility for enumerating the credentials that we have, choose different credential depending on the party that they're talking to. name attributes: names are composed of attributes attributes are OID label plus ?????? client aserted names: allow clients to assert part of a name to be exported. tell implementation what part of the name that it gets. this would provide better compatibility with older applications credential extensions: add labelled extensions to credentials similar in functionality to name attirubutes, but requires more changes to contexts. credential enumeration: Basically a "GSSAPI klist" facility to find credentials that are available. Consensus was reached that we will have a document describing the solution space. Chair lead discussion on whether or not implementation of Kerberos 5 mechanism support for PRF and Domain Names should take place in kitten or krb-wg. DECISIONS (to be validated on the list): + Maintaining interoperability with existing deployed SPNEGO implementations is more important then the ability to add new features such as protect reqFlags + No consensus was reached on whether the use of an optimistic token in SPNEGO will be SHOULD or MAY. + There are strong feelings against the relaxing the MUST NOT applied to the negotiation of mechanisms which do not support integrity protection + The GSS Naming document will describe the problem space and not just solutions + The Kerberos 5 mechanism documents will working group documents of Kitten. We will work closely with the Kerberos WG to ensure proper review and we we last call in both. This decision was made by flipping a coin. ACTION ITEMS: + Larry Zhu will follow up on the outstanding issues with SPNEGO and report to the list by Fri Nov 19 + The chair will send a list of working group documents to the secretariat + Nico Williams will publish new I-Ds for PRF and Domain Names including results of recent on-list discussions + The Chair will contact Sun Java Security team to obtain a draft describing the incompatibilities between RFC and org.ietf.jgss + Sam Hartman will revise GSS Naming document and then hand it off to a new editor MILESTONES: Nov 04 First Meeting Dec 04 Prepare SPNEGO for Last Call Mar 05 Submit SPNEGO to the IESG as Proposed Standard Mar 05 First drafts of either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Jul 05 Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Jul 05 Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI' to the IESG as Proposed Standard Jul 05 Submit 'The Simple and Protected GSS-API Negotiation Mechanism (Revised)' to the IESG as Proposed Standard Nov 05 Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service Application Program Interface Version 3' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service API Version 3 : C-bindings' to the IESG as Proposed Standard Jul 06 Submit 'Generic Security Service API Version 3 : Java and C# bindings' to the IESG as Proposed Standard Nov 06 Charter Review --------------050301080208020501040003-- --------------ms050802000100080200080900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDQxMTEzMDMwNTIyWjAjBgkqhkiG9w0BCQQxFgQUtlvROvH7tHCrj93E3RvWAEdtPSUw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEATmWK0+XZMOfZdnb9ztWlyA2ZEhDIAUxiNlAIKHMu q8VTzkxW0oYNAq4Dh3TIO9h7TNa1ZJC5D6DZTCWCl63PIsD6rCDuDXh7wvGUAXcSctSBOKIl 7Nt/Nk6MPCNS6G2zo0rCtBjFS21nXr3kL9AtIyEqnFiknlCxspxlWQaYFr/6eM3qKOgjzNH2 uitIlVanQ+lVxCDHGSvNpn31GZJKX4m4QlNEst9JVE5tT/6oIDWD//JgB6Qg+10L88Y9sbAQ i/i0msx6ul2v9WsPH6zTsSRYPPE3jGPC+l9rCekLhF0y8KU9RV15vOm35/In1Hh36NIETi64 jtF+c43u+QXOqAAAAAAAAA== --------------ms050802000100080200080900-- --===============1362776132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1362776132==-- From kitten-bounces@ietf.org Sat Nov 13 18:37:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11562; Sat, 13 Nov 2004 18:37:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7UZ-0000tk-JZ; Sat, 13 Nov 2004 18:39:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT76N-0005Kh-3J; Sat, 13 Nov 2004 18:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT6wn-0000v7-Vc for kitten@megatron.ietf.org; Sat, 13 Nov 2004 18:04:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08504 for ; Sat, 13 Nov 2004 18:04:43 -0500 (EST) Received: from stratton-four-o-six.mit.edu ([18.187.6.151] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT6yQ-0007pB-Im for kitten@ietf.org; Sat, 13 Nov 2004 18:06:29 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 941D1E0037; Sat, 13 Nov 2004 18:04:56 -0500 (EST) To: martin.rex@sap.com References: <200411122217.XAA20104@uw1048.wdf.sap.corp> From: Sam Hartman Date: Sat, 13 Nov 2004 18:04:56 -0500 In-Reply-To: <200411122217.XAA20104@uw1048.wdf.sap.corp> (Martin Rex's message of "Fri, 12 Nov 2004 23:17:55 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca >>>>> "Martin" == Martin Rex writes: >> Sorry about that. I think there were several off-list >> conversations about this stuff at IETF this past week. Once >> everyone returns and has time to digest it all, I believe a >> proper summary will appear on this list and in an updated >> draft. >> >> For now, I won't bother trying to explain my previous summary >> since some of what I wrote was already out of date when I wrote >> it. Martin> OK. Martin> The purpose of the protection in SPNEGO was to assure Martin> *BOTH* sides that the negotiation wasn't doctored by an Martin> active attacker. The mechListMic is supposed to provide Martin> this assurance for both at least as long as the receiver Martin> of the mechListMIC will reliably abort when either the Martin> mechListMIC is missing or when it doesn't match. Thanks for hitting so quickly on the crux of the issue. I'd like your help in understanding exactly which guarantee SPNEGO makes. I'd like to draw your attention to section 3.2.2 of RFC 2478. This section describes the processing of the mechListMIC field. Let's consider a mechanism with an even number of tokens. If I'm reading that section correctly, then the acceptor will return the mechListMIC to the initiator at the same time it returns complete to the application. In particular, it seems like an attacker could change the initiator's mechanism list and the acceptor would still return complete to its application. The initiator could never be made to return complete to its application. Still, this attack would be valuable against a protocol that used GSS authentication but did not later use gss_wrap or gss_getmic. Is my understand correct? If so, it sounds like the guarantee that RFC 2748 makes is that at least one party must fail the authentication if the negotiation is attacked, but the other party may complete the negotiation. Thanks, --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Sat Nov 13 18:44:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11803; Sat, 13 Nov 2004 18:44:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7bM-000190-Du; Sat, 13 Nov 2004 18:46:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7Sr-0001XS-4l; Sat, 13 Nov 2004 18:37:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT75M-0004pF-N0 for kitten@megatron.ietf.org; Sat, 13 Nov 2004 18:13:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09573 for ; Sat, 13 Nov 2004 18:13:34 -0500 (EST) Received: from stratton-four-o-six.mit.edu ([18.187.6.151] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT772-0008Cp-Ec for kitten@ietf.org; Sat, 13 Nov 2004 18:15:20 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id B41E6E0037; Sat, 13 Nov 2004 18:13:45 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Sat, 13 Nov 2004 18:13:45 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Security Considerations for SPNEGO X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Eventually I'm going to have to take the SPNEGO document to the IESG and convince them that what we propose is secure. I'll also have to convince them that the complexity Larry is introducing is necessary. I will need the cooperation of the working group in several areas in order to do that. I think that providing answers to the questions I'm asking will also help all of us be sure that we are approaching the problem reasonably. Larry is introducing rules describing when it is safe to omit the MIC. Before the first rule is presented, the document needs to explain why we are introducing this complexity. I believe that the answer is roughly that we are able to maintain interoperability with older broken implementations of the SPEC while maintaining the security guarantees if we introduce this complexity. Presumably we believe this interoperability is necessary to get the new version deployed. We should have an answer to the question of why we don't provide a simple solution in the case where the implementation is known to be new. We could choose to offer such a solution. We could also decide that an optional simple mode would be more error-prone than always requiring the complexity. Next, in the security considerations section, the document must explain what security guarantees SPNEGO will make. The document must argue that Larry's rules will meet these guarantees. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Sat Nov 13 18:54:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12384; Sat, 13 Nov 2004 18:54:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7kG-0001VT-Dx; Sat, 13 Nov 2004 18:55:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7TK-0001qd-KK; Sat, 13 Nov 2004 18:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT7Gc-00009n-EJ for kitten@megatron.ietf.org; Sat, 13 Nov 2004 18:25:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10903 for ; Sat, 13 Nov 2004 18:25:12 -0500 (EST) Received: from stratton-four-o-six.mit.edu ([18.187.6.151] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT7IH-0000O9-AQ for kitten@ietf.org; Sat, 13 Nov 2004 18:26:58 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id CAB26E0037; Sat, 13 Nov 2004 18:25:22 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Sat, 13 Nov 2004 18:25:22 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: Concerns about forbidding mechanisms without integrity X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 I understand the desire to require integrity. I'm also concerned if SASL and GSSAPI diverge in the space of mechanisms they can support. In effect this decision would be requiring useful GSS mechanisms to support integrity. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 10:58:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12397; Tue, 16 Nov 2004 10:58:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5kn-0000Ms-Hy; Tue, 16 Nov 2004 11:00:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5dk-0007cv-61; Tue, 16 Nov 2004 10:53:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5a7-0006YX-G5 for kitten@megatron.ietf.org; Tue, 16 Nov 2004 10:49:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11591 for ; Tue, 16 Nov 2004 10:49:19 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5cI-00008N-Jm for kitten@ietf.org; Tue, 16 Nov 2004 10:51:40 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA17858; Tue, 16 Nov 2004 16:48:30 +0100 (MEZ) From: Martin Rex Message-Id: <200411161548.QAA12789@uw1048.wdf.sap.corp> To: jaltman@columbia.edu (Jeffrey Altman) Date: Tue, 16 Nov 2004 16:48:30 +0100 (MET) In-Reply-To: <419545E9.2080509@columbia.edu> from "Jeffrey Altman" at Nov 12, 4 06:23:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Jeffrey Altman wrote: > Martin Rex wrote: > > The purpose of the protection in SPNEGO was to assure *BOTH* sides > > that the negotiation wasn't doctored by an active attacker. The > > mechListMic is supposed to provide this assurance for both at least > > as long as the receiver of the mechListMIC will reliably abort > > when either the mechListMIC is missing or when it doesn't match. > > Please be assured that the working group, myself and the area > directors are very aware of the requirement to ensure that only > cases in which we can prove that both the client and server will > choose the desired mechanism without outside influence can be > sent without a MIC. There are a sufficient set of cases in which > this is true that we can provide interoperability with the existing > deployed implementations in the common cases. > > I expect you will be happy with the outcome. I'm not so sure whether there really are situation where the mechListMic can be omitted without loosing the protection. As Wyllys indicated, an acceptor might want to use a different mechanism even if it supports the optimistic token provide by the initiator, so the mechListMIC is even required for the case where the acceptor uses the optimistic token in order to ensure that the acceptor really got to see the undoctored mechanism list of the client. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 11:01:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12954; Tue, 16 Nov 2004 11:01:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5oQ-0000TY-KU; Tue, 16 Nov 2004 11:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5kX-0000ML-9k; Tue, 16 Nov 2004 11:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5ei-0007qP-FZ for kitten@megatron.ietf.org; Tue, 16 Nov 2004 10:54:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12039 for ; Tue, 16 Nov 2004 10:54:06 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5gv-0000Gi-Sc for kitten@ietf.org; Tue, 16 Nov 2004 10:56:27 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA14569; Tue, 16 Nov 2004 16:53:25 +0100 (MEZ) From: Martin Rex Message-Id: <200411161553.QAA12848@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Tue, 16 Nov 2004 16:53:25 +0100 (MET) In-Reply-To: from "Sam Hartman" at Nov 13, 4 06:04:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > Thanks for hitting so quickly on the crux of the issue. > I'd like your help in understanding exactly which guarantee SPNEGO makes. > > I'd like to draw your attention to section 3.2.2 of RFC 2478. This > section describes the processing of the mechListMIC field. Let's > consider a mechanism with an even number of tokens. > > If I'm reading that section correctly, then the acceptor will return > the mechListMIC to the initiator at the same time it returns complete > to the application. In particular, it seems like an attacker could > change the initiator's mechanism list and the acceptor would still > return complete to its application. The initiator could never be made > to return complete to its application. > > Still, this attack would be valuable against a protocol that used GSS > authentication but did not later use gss_wrap or gss_getmic. > > > Is my understand correct? If so, it sounds like the guarantee that > RFC 2748 makes is that at least one party must fail the authentication > if the negotiation is attacked, but the other party may complete the > negotiation. Yes, this is correct. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 11:59:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18950; Tue, 16 Nov 2004 11:59:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6ho-0001wJ-9V; Tue, 16 Nov 2004 12:01:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6dW-0000GL-F7; Tue, 16 Nov 2004 11:56:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6bM-0008MB-OG for kitten@megatron.ietf.org; Tue, 16 Nov 2004 11:54:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18655 for ; Tue, 16 Nov 2004 11:54:42 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6dZ-0001qM-V9 for kitten@ietf.org; Tue, 16 Nov 2004 11:57:04 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAGGscoY028591 for ; Tue, 16 Nov 2004 08:54:38 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAGGsbJh000795 for ; Tue, 16 Nov 2004 09:54:37 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAGGs01E481321; Tue, 16 Nov 2004 10:54:00 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAGGrxYV481320; Tue, 16 Nov 2004 10:53:59 -0600 (CST) Date: Tue, 16 Nov 2004 10:53:59 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20041116165359.GB473487@binky.central.sun.com> Mail-Followup-To: Martin Rex , Jeffrey Altman , kitten@ietf.org References: <419545E9.2080509@columbia.edu> <200411161548.QAA12789@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411161548.QAA12789@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Tue, Nov 16, 2004 at 04:48:30PM +0100, Martin Rex wrote: > I'm not so sure whether there really are situation where the > mechListMic can be omitted without loosing the protection. The meta-rule is this: If the acceptor selects the initiator's preferred mechanism (i.e., the first one on the mechList) and there is no mechanism which, had it been present in mechList, the acceptor wouldn't have preferred over the initiator's preferred mech, then no mechListMIC exchange is needed. The reason this works is that though an MITM may change the mechList seen by the acceptor, as long as what it did had no material impact on the negotiation then the attack is irrelevant. And if the attack would have a material impact on the negotiation, then one, the other or both peers will insist on a mechListMIC exchange (unless both are legacy implementations). This rule translates easily into actual rules to be implemented by initiators and acceptors. The interesting twist is how to perform the mechListMIC exchange in a way that is, er, friendly to legacy implementations. I'll let Larry provide the remaining details, and maybe an alternate view of the above. > As Wyllys indicated, an acceptor might want to use a different mechanism > even if it supports the optimistic token provide by the initiator, > so the mechListMIC is even required for the case where the acceptor > uses the optimistic token in order to ensure that the acceptor > really got to see the undoctored mechanism list of the client. The meta-rule applies, and works, regardless of whether the initiator sends an optimistic context token or not. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 12:29:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22084; Tue, 16 Nov 2004 12:29:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7B9-0002j2-Us; Tue, 16 Nov 2004 12:31:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU750-0006gu-Me; Tue, 16 Nov 2004 12:25:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6oT-000222-L9 for kitten@megatron.ietf.org; Tue, 16 Nov 2004 12:08:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19943 for ; Tue, 16 Nov 2004 12:08:15 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6qh-0002AG-6p for kitten@ietf.org; Tue, 16 Nov 2004 12:10:37 -0500 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAGH8Br7006850; Tue, 16 Nov 2004 09:08:11 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAGH8A7t175245; Tue, 16 Nov 2004 09:08:10 -0800 (PST) Message-ID: <419A32D2.4040007@sun.com> Date: Tue, 16 Nov 2004 12:03:14 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041028 X-Accept-Language: en-us, en MIME-Version: 1.0 To: martin.rex@sap.com References: <200411161548.QAA12789@uw1048.wdf.sap.corp> In-Reply-To: <200411161548.QAA12789@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Martin Rex wrote: > I'm not so sure whether there really are situation where the > mechListMic can be omitted without loosing the protection. > > As Wyllys indicated, an acceptor might want to use a different mechanism > even if it supports the optimistic token provide by the initiator, > so the mechListMIC is even required for the case where the acceptor > uses the optimistic token in order to ensure that the acceptor > really got to see the undoctored mechanism list of the client. > > -Martin > I do think it is safe to omit the MIC in certain situations. For example, the initiator sends only 1 mechanism in the list. If the acceptor returns a token for a different mech, the client would just reject this immediately and the that session would fail. Even if a MITM had altered the list and the acceptor chose the altered mech list, the initiator would notice the change and kill the session, so the attack effectively would have failed. Forcing the use of the MIC in all cases will certainly break backwards compat, so we are trying hard to define this such that backwards compat is maintained in addition to clarifying the spec and making it more secure for future implementors. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 14:39:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03835; Tue, 16 Nov 2004 14:39:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9D9-0005yw-RY; Tue, 16 Nov 2004 14:41:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU92q-0004hg-1a; Tue, 16 Nov 2004 14:31:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8xG-0003f9-7Q for kitten@megatron.ietf.org; Tue, 16 Nov 2004 14:25:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02128 for ; Tue, 16 Nov 2004 14:25:29 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8zS-0005X3-WA for kitten@ietf.org; Tue, 16 Nov 2004 14:27:50 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA09131; Tue, 16 Nov 2004 20:24:53 +0100 (MEZ) From: Martin Rex Message-Id: <200411161924.UAA14943@uw1048.wdf.sap.corp> To: wyllys.ingersoll@sun.com (Wyllys Ingersoll) Date: Tue, 16 Nov 2004 20:24:53 +0100 (MET) In-Reply-To: <419A32D2.4040007@sun.com> from "Wyllys Ingersoll" at Nov 16, 4 12:03:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 8bit Wyllys Ingersoll wrote: > > I do think it is safe to omit the MIC in certain situations. > For example, the initiator sends only 1 mechanism in the list. > If the acceptor returns a token for a different mech, the client would > just reject this immediately and the that session would fail. Even if a > MITM had altered the list and the acceptor chose the altered mech list, > the initiator would notice the change and kill the session, so the > attack effectively would have failed. That's an assessment that an observer with meta-knowledge can do! However where is the programmatic assurance for the acceptor in this case that the client only supports a single mechanism (and not more, but the others got removed from the list by an attacker). Your example looks like a situation where the "protection" of the negotiation is lost. > > Forcing the use of the MIC in all cases will certainly break backwards > compat, so we are trying hard to define this such that backwards > compat is maintained in addition to clarifying the spec and making > it more secure for future implementors. Forcing the MIC will *NOT* break backwards compatibility, but removing the requirement will undoubtedly break backwards compatibility! Forcing the MIC unconditionally as in the original spec may break interoperability with an installed based of a particular broken implementation. You have to keep in mind that not all implementors of an IETF spec are going to participate in IETF discussions or activities! In fact, in the GSS-API area, the majority of vendors that have done interoperability certification with our app based on the GSS-API v2 spec are *NOT* active in the IETF. So just because *we* here only know about one particular broken implementation doesn't mean that there are correct implementations out there that we're going to break by making a non-backwards compatible change of the spec. And that change is *NOT* to fix the spec (in fact, from the engineering point of view this change is a bad idea), but to get around fixing that one broken implementation. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 15:33:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10004; Tue, 16 Nov 2004 15:33:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUA3B-0007JZ-55; Tue, 16 Nov 2004 15:35:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9xi-00057v-4h; Tue, 16 Nov 2004 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9tG-0002qT-QF for kitten@megatron.ietf.org; Tue, 16 Nov 2004 15:25:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09060 for ; Tue, 16 Nov 2004 15:25:25 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9vW-00075W-Lf for kitten@ietf.org; Tue, 16 Nov 2004 15:27:47 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id BB3E4E003B; Tue, 16 Nov 2004 15:25:43 -0500 (EST) To: martin.rex@sap.com References: <200411161924.UAA14943@uw1048.wdf.sap.corp> From: Sam Hartman Date: Tue, 16 Nov 2004 15:25:43 -0500 In-Reply-To: <200411161924.UAA14943@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 16 Nov 2004 20:24:53 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d >>>>> "Martin" == Martin Rex writes: Martin> Wyllys Ingersoll wrote: >> I do think it is safe to omit the MIC in certain situations. >> For example, the initiator sends only 1 mechanism in the list. >> If the acceptor returns a token for a different mech, the >> client would just reject this immediately and the that session >> would fail. Even if a MITM had altered the list and the >> acceptor chose the altered mech list, the initiator would >> notice the change and kill the session, so the attack >> effectively would have failed. Martin> That's an assessment that an observer with meta-knowledge Martin> can do! Martin> However where is the programmatic assurance for the Martin> acceptor in this case that the client only supports a Martin> single mechanism (and not more, but the others got removed Martin> from the list by an attacker). The server knows (because the new protocol will mandate this behavior) that a client will demand a MIC if the client sees the server trying to negotiate anything other than the most preferred mechanism of the client. That's part of the meta-rule Nico proposes. Again, how the client demands a MIC is something Larry's draft will explain. It should be clear thought that the situation where the client offers only one mechanism is secure provided that the client can demand a MIC and correctly coded clients do demand a MIC in the appropriate situations. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 15:55:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12430; Tue, 16 Nov 2004 15:55:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAOQ-0007lT-Kh; Tue, 16 Nov 2004 15:57:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAKz-0007TS-PE; Tue, 16 Nov 2004 15:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAIl-0006Mq-IC for kitten@megatron.ietf.org; Tue, 16 Nov 2004 15:51:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11894 for ; Tue, 16 Nov 2004 15:51:46 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAL1-0007eM-HY for kitten@ietf.org; Tue, 16 Nov 2004 15:54:08 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA11229; Tue, 16 Nov 2004 21:51:11 +0100 (MEZ) From: Martin Rex Message-Id: <200411162051.VAA15623@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Tue, 16 Nov 2004 21:51:12 +0100 (MET) In-Reply-To: from "Sam Hartman" at Nov 16, 4 03:25:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > The server knows (because the new protocol will mandate this behavior) > that a client will demand a MIC if the client sees the server trying > to negotiate anything other than the most preferred mechanism of the > client. That's part of the meta-rule Nico proposes. > > Again, how the client demands a MIC is something Larry's draft will > explain. OK, I'll wait and see. > > It should be clear thought that the situation where the client offers > only one mechanism is secure provided that the client can demand a MIC > and correctly coded clients do demand a MIC in the appropriate > situations. I think that a client that has only a single mechanism an uses SPNEGO is broken, it should be using the underlying gss-api mechanism directly, and will become interoperable with peers that do not support SPNEGO. Actually, the client's SPNEGO implementation could make that optimization instead of going for the SPNEGO exchange with optimistic token. That way it will not only omit/save the mechListMIC, but all the SPNEGO overhead and complexity. When I asked Larry whether their IIS would correctly handle a Kerberos token instead of a Kerberos-optimistic-token-within-SPNEGO when doing the HTTP-authentication, he claimed this should work. Suggesting such a change for *initiators* would *not* impair backwards compatibility with correct implementations of SPNEGO (which may exist). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 16:11:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14182; Tue, 16 Nov 2004 16:11:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAdr-0008FB-8e; Tue, 16 Nov 2004 16:13:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAZ5-0005JF-HE; Tue, 16 Nov 2004 16:08:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUATH-0002vp-Ah for kitten@megatron.ietf.org; Tue, 16 Nov 2004 16:02:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13160 for ; Tue, 16 Nov 2004 16:02:37 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAVX-000833-FM for kitten@ietf.org; Tue, 16 Nov 2004 16:05:00 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 5A3C7E003D; Tue, 16 Nov 2004 16:02:56 -0500 (EST) To: martin.rex@sap.com References: <200411162051.VAA15623@uw1048.wdf.sap.corp> From: Sam Hartman Date: Tue, 16 Nov 2004 16:02:56 -0500 In-Reply-To: <200411162051.VAA15623@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 16 Nov 2004 21:51:12 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >>>>> "Martin" == Martin Rex writes: Martin> I think that a client that has only a single mechanism an Martin> uses SPNEGO is broken, it should be using the underlying Martin> gss-api mechanism directly, and will become interoperable Martin> with peers that do not support SPNEGO. Martin> Actually, the client's SPNEGO implementation could make Martin> that optimization instead of going for the SPNEGO exchange Martin> with optimistic token. That way it will not only Martin> omit/save the mechListMIC, but all the SPNEGO overhead and Martin> complexity. we need to mandate that a server receieving a normal mechanism token but expecting an SPNEGO token should respond appropriately if we're going to allow this optimization. I don't mind mandating that, but I don't think we do today. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 17:37:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03365; Tue, 16 Nov 2004 17:37:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBzP-0005UY-LW; Tue, 16 Nov 2004 17:39:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBjC-0002qH-Hv; Tue, 16 Nov 2004 17:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAm6-0002tf-34 for kitten@megatron.ietf.org; Tue, 16 Nov 2004 16:22:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15534 for ; Tue, 16 Nov 2004 16:22:04 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAoM-0008RZ-0f for kitten@ietf.org; Tue, 16 Nov 2004 16:24:27 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA02432; Tue, 16 Nov 2004 22:21:29 +0100 (MEZ) From: Martin Rex Message-Id: <200411162121.WAA15836@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Tue, 16 Nov 2004 22:21:29 +0100 (MET) In-Reply-To: from "Sam Hartman" at Nov 16, 4 04:02:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > we need to mandate that a server receieving a normal mechanism token > but expecting an SPNEGO token should respond appropriately if we're > going to allow this optimization. I don't mind mandating that, but I > don't think we do today. It has always been a(n implicit) requirement that SPNEGO makes a well-behaved multi-mechanism with the underlying real gss-api mechanisms, i.e. that the OID in the generic framing of the initial security context token is passed to and processed by the respective gssapi mechanism on the server side. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 17:37:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03418; Tue, 16 Nov 2004 17:37:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBzW-0005VP-FZ; Tue, 16 Nov 2004 17:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBjf-0003Hl-IC; Tue, 16 Nov 2004 17:23:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAuW-0005cM-TU for kitten@megatron.ietf.org; Tue, 16 Nov 2004 16:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17108 for ; Tue, 16 Nov 2004 16:30:47 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAwn-0000Q5-6E for kitten@ietf.org; Tue, 16 Nov 2004 16:33:10 -0500 Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAGLUk7q027309; Tue, 16 Nov 2004 13:30:46 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAGLUjOR434976; Tue, 16 Nov 2004 13:30:46 -0800 (PST) Message-ID: <419A705D.7090705@sun.com> Date: Tue, 16 Nov 2004 16:25:49 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041028 X-Accept-Language: en-us, en MIME-Version: 1.0 To: martin.rex@sap.com References: <200411162051.VAA15623@uw1048.wdf.sap.corp> In-Reply-To: <200411162051.VAA15623@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Martin Rex wrote: > > I think that a client that has only a single mechanism an uses SPNEGO > is broken, it should be using the underlying gss-api mechanism directly, > and will become interoperable with peers that do not support SPNEGO. > Technically it's not broken, though it is clearly not a very useful or efficient use of the protocol. > Actually, the client's SPNEGO implementation could make that optimization > instead of going for the SPNEGO exchange with optimistic token. That way > it will not only omit/save the mechListMIC, but all the SPNEGO overhead > and complexity. > > When I asked Larry whether their IIS would correctly handle a > Kerberos token instead of a Kerberos-optimistic-token-within-SPNEGO > when doing the HTTP-authentication, he claimed this should work. I believe IIS does indeed handle this correctly. If you send IIS a GSSAPI/Kerberos initial token without SPNEGO, it will accept it and respond with GSSAPI/Kerberos tokens accordingly. I have tested this myself in the past. This is how Mozilla is able to implement Microsoft's HTTP "Negotiate" authentication without requiring SPNEGO on the clients, it just sends GSSAPI/KRB5 tokens instead. > > Suggesting such a change for *initiators* would *not* impair backwards > compatibility with correct implementations of SPNEGO (which may exist). Right. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 17:37:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03441; Tue, 16 Nov 2004 17:37:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBzZ-0005VY-2T; Tue, 16 Nov 2004 17:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBjm-0003RG-Rs; Tue, 16 Nov 2004 17:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAx6-0006BY-OS for kitten@megatron.ietf.org; Tue, 16 Nov 2004 16:33:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17628 for ; Tue, 16 Nov 2004 16:33:27 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAzN-0000Yb-4p for kitten@ietf.org; Tue, 16 Nov 2004 16:35:50 -0500 Received: from jurassic.eng.sun.com ([129.146.84.45]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAGLXPr7013043; Tue, 16 Nov 2004 13:33:25 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAGLXOsD436982; Tue, 16 Nov 2004 13:33:25 -0800 (PST) Message-ID: <419A70FD.5010002@sun.com> Date: Tue, 16 Nov 2004 16:28:29 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041028 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <200411162051.VAA15623@uw1048.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Sam Hartman wrote: >>>>>>"Martin" == Martin Rex writes: > > > > Martin> I think that a client that has only a single mechanism an > Martin> uses SPNEGO is broken, it should be using the underlying > Martin> gss-api mechanism directly, and will become interoperable > Martin> with peers that do not support SPNEGO. > > Martin> Actually, the client's SPNEGO implementation could make > Martin> that optimization instead of going for the SPNEGO exchange > Martin> with optimistic token. That way it will not only > Martin> omit/save the mechListMIC, but all the SPNEGO overhead and > Martin> complexity. > > we need to mandate that a server receieving a normal mechanism token > but expecting an SPNEGO token should respond appropriately if we're > going to allow this optimization. I don't mind mandating that, but I > don't think we do today. Perhaps there should be some sort of statement in the new SPNEGO draft that clearly states that initiators who only send 1 mech in the mechlist should not use SPNEGO at all and just use their preferred mechanism. Likewise, servers that accept SPNEGO should also be able to accept initial tokens for any of their supported mechanisms without SPNEGO wrapping. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 17:46:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04692; Tue, 16 Nov 2004 17:46:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC7t-0005pE-Tp; Tue, 16 Nov 2004 17:48:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBvB-0002QP-0H; Tue, 16 Nov 2004 17:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBQR-0002Dq-QS for kitten@megatron.ietf.org; Tue, 16 Nov 2004 17:03:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25026 for ; Tue, 16 Nov 2004 17:03:45 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBSi-0002uK-0W for kitten@ietf.org; Tue, 16 Nov 2004 17:06:09 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA01808; Tue, 16 Nov 2004 23:03:12 +0100 (MEZ) From: Martin Rex Message-Id: <200411162203.XAA16465@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Tue, 16 Nov 2004 23:03:12 +0100 (MET) In-Reply-To: from "Sam Hartman" at Nov 16, 4 04:28:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > Martin> It has always been a(n implicit) requirement that SPNEGO > Martin> makes a well-behaved multi-mechanism with the underlying > Martin> real gss-api mechanisms, i.e. that the OID in the generic > Martin> framing of the initial security context token is passed to > Martin> and processed by the respective gssapi mechanism on the > Martin> server side. > > This requirement has not been clear to the rest of the IETF. The most > notable example of this is the dnsext working group's interpretation > of the spec, but none of us who were at the meeting were able to come > up with text to convince them they were wrong. This requirement is implicit from the GSS-API architecture that allowed for multi-mechanisms even before SPNEGO was invented. The server/acceptor MUST always look at the mechanism OID of the initial context token and dispatch the token accordingly Before SPNEGO, a client with multiple mechanism was required to choose a particular mechanism and try that (and possibly fail). SPNEGO was added to allow to negotiate among the set of available mechanisms, not having to go through failures at the application level when trying to find a matching mechanism. However SPNEGO was never designed to preclude direct selection of a particular mechanism and was never allowed to force itself onto the application. The prerequisite for SPNEGO to get used at all is mentioned in rfc2478: 4.1. Initial steps (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2). (I) invokes GSS_Init_sec_context() with : Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism. In case that the input mech_type is *NOT* SPNEGO (or NULL and teh local default mechanism is not SPNEGO), then the initial security context token will not be an SPNEGO token. It is as simple as that. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 16 18:43:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11221; Tue, 16 Nov 2004 18:43:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUD1I-0007S5-JR; Tue, 16 Nov 2004 18:45:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCxv-0004zM-69; Tue, 16 Nov 2004 18:42:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCvw-0004Zt-FD for kitten@megatron.ietf.org; Tue, 16 Nov 2004 18:40:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11020 for ; Tue, 16 Nov 2004 18:40:21 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUCyD-0007M2-Ja for kitten@ietf.org; Tue, 16 Nov 2004 18:42:46 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAGNdWUe006124; Wed, 17 Nov 2004 10:39:32 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAGNdUWB006123; Wed, 17 Nov 2004 10:39:30 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411162339.iAGNdUWB006123@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: martin.rex@sap.com Date: Wed, 17 Nov 2004 10:39:30 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >This requirement is implicit from the GSS-API architecture that >allowed for multi-mechanisms even before SPNEGO was invented. >The server/acceptor MUST always look at the mechanism OID of the >initial context token and dispatch the token accordingly Agreed, but there is an argument that protocols that do their own security mechanism negotiation such as SASL and RPC may wish to restrict the list of GSS mechanisms they are willing to accept. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 08:06:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25647; Wed, 17 Nov 2004 08:06:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPY7-0000P8-Mc; Wed, 17 Nov 2004 08:08:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPL1-0002D3-SF; Wed, 17 Nov 2004 07:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPKC-0001wv-Aw for kitten@megatron.ietf.org; Wed, 17 Nov 2004 07:54:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24308 for ; Wed, 17 Nov 2004 07:54:15 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPMS-0008Mo-0o for kitten@ietf.org; Wed, 17 Nov 2004 07:56:46 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id NAA25396; Wed, 17 Nov 2004 13:53:06 +0100 (MEZ) From: Martin Rex Message-Id: <200411171253.NAA21588@uw1048.wdf.sap.corp> To: lukeh@padl.com Date: Wed, 17 Nov 2004 13:53:05 +0100 (MET) In-Reply-To: <200411162339.iAGNdUWB006123@au.padl.com> from "Luke Howard" at Nov 17, 4 10:39:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit Luke Howard wrote: > > >This requirement is implicit from the GSS-API architecture that > >allowed for multi-mechanisms even before SPNEGO was invented. > >The server/acceptor MUST always look at the mechanism OID of the > >initial context token and dispatch the token accordingly > > Agreed, but there is an argument that protocols that do their own > security mechanism negotiation such as SASL and RPC may wish to > restrict the list of GSS mechanisms they are willing to accept. SPNEGO is not a real mechanism, but a pseudo- or wrapping mechanism that only provide negotiation and leaves the actual work to one of the underlying real gssapi mechanisms. Therefore I would expect any mechanism like you mention (SASL,RPC) that does negotiation on its own to reject SPNEGO, if any, because SPNEGO is not a mechanism itself and hides the actual mechanism token inside a non-trivial SPNEGO-token, and not necessarily in the first one. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 11:46:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17810; Wed, 17 Nov 2004 11:46:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSzb-0005nc-U0; Wed, 17 Nov 2004 11:49:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSoe-0002u1-OX; Wed, 17 Nov 2004 11:37:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUPbI-0005cE-Ef for kitten@megatron.ietf.org; Wed, 17 Nov 2004 08:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26779 for ; Wed, 17 Nov 2004 08:11:55 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUPdh-0000dm-6w for kitten@ietf.org; Wed, 17 Nov 2004 08:14:26 -0500 Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 17 Nov 2004 13:11:09 +0000 Message-ID: <419B4DEC.6000603@isode.com> Date: Wed, 17 Nov 2004 13:11:08 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <20041109232954.GI102351@binky.central.sun.com> <6.1.2.0.0.20041110150627.03368e50@127.0.0.1> <20041111070333.GT102351@binky.central.sun.com> In-Reply-To: <20041111070333.GT102351@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 Nov 2004 11:37:55 -0500 Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Re: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >Love's point is that RFC2222 specifically talks about what server names >are like, and that is like hostbased-services. Introducing new name >types for SASL mechs may require changing this. > > 2222bis only refers to service names. I can't find anywhere in the text reference to hostnames. I think only the GSSAPI draft is affected. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 12:23:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21485; Wed, 17 Nov 2004 12:23:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUTYx-0006qs-ML; Wed, 17 Nov 2004 12:25:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUTCM-0000fL-2m; Wed, 17 Nov 2004 12:02:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUT1X-0006bi-Qo for kitten@megatron.ietf.org; Wed, 17 Nov 2004 11:51:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18336 for ; Wed, 17 Nov 2004 11:51:12 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUT3w-0005wd-M7 for kitten@ietf.org; Wed, 17 Nov 2004 11:53:46 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAHGpB7q022519 for ; Wed, 17 Nov 2004 08:51:11 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAHGpAjW012915 for ; Wed, 17 Nov 2004 09:51:10 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAHGoX0O484781; Wed, 17 Nov 2004 10:50:33 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAHGoV8g484780; Wed, 17 Nov 2004 10:50:31 -0600 (CST) Date: Wed, 17 Nov 2004 10:50:31 -0600 From: Nicolas Williams To: Alexey Melnikov Message-ID: <20041117165031.GS473487@binky.central.sun.com> Mail-Followup-To: Alexey Melnikov , Love , kitten@ietf.org, ietf-sasl@imc.org References: <20041109232954.GI102351@binky.central.sun.com> <6.1.2.0.0.20041110150627.03368e50@127.0.0.1> <20041111070333.GT102351@binky.central.sun.com> <419B4DEC.6000603@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <419B4DEC.6000603@isode.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Re: Comments: gssapi-domain-based-name X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Wed, Nov 17, 2004 at 01:11:08PM +0000, Alexey Melnikov wrote: > Nicolas Williams wrote: > > >Love's point is that RFC2222 specifically talks about what server names > >are like, and that is like hostbased-services. Introducing new name > >types for SASL mechs may require changing this. > > > > > 2222bis only refers to service names. I can't find anywhere in the text > reference to hostnames. > > I think only the GSSAPI draft is affected. Good. I'll come up with some text. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 13:23:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27103; Wed, 17 Nov 2004 13:23:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUV3-0008Kw-BX; Wed, 17 Nov 2004 13:25:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUURV-0002oa-EQ; Wed, 17 Nov 2004 13:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUO9-00020K-7E for kitten@megatron.ietf.org; Wed, 17 Nov 2004 13:18:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26618 for ; Wed, 17 Nov 2004 13:18:37 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUQb-0008DP-8Q for kitten@ietf.org; Wed, 17 Nov 2004 13:21:14 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA29380; Wed, 17 Nov 2004 19:18:01 +0100 (MEZ) From: Martin Rex Message-Id: <200411171818.TAA24440@uw1048.wdf.sap.corp> To: wyllys.ingersoll@sun.com (Wyllys Ingersoll) Date: Wed, 17 Nov 2004 19:18:00 +0100 (MET) In-Reply-To: <419A70FD.5010002@sun.com> from "Wyllys Ingersoll" at Nov 16, 4 04:28:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 8bit When it was designed, SPNEGO was *NOT* supposed to be an additional protocol layer, but instead a special-purpose pseudo- mechanism of a gssapi multi-mechanism implementation. As an additional protocol level, it would require a flag day, while as a multi-mechanism there is a migration path (i.e. you start adding SPNEGO to the servers and later on clients at your convenience, still maintaining interoperability with non-SPNEGO clients because of the multi-mechanism capabilities of GSS-API where the server/acceptor recognizes the actual gssapi mechanism by looking at the mechanism OID in the initial security context token. Maybe we should explicitly describe this in the successor document as the absence of this appears to have caused some people to make flawed assumptions. It seems that I also forgot about one special feature of SPNEGO which the SESAME guys were actually using: "mechanism variants". Although it's a non-portable (implementation specific) extension, I have no objections. Therefore, I would appreciate something like a "MAY" or at most a "SHOULD" for entirely omitting SPNEGO framing when there's only a single mechanism availble for the initiator, but never a MUST. Quoting from rfc2478: 2. NEGOTIATION MODEL 2.1. Negotiation description The model for security mechanism negotiation reuses a subset of the concepts specified in [2]. Each OID represents one GSS-API mechanism or one variant of it. Did anyone wonder what the "variant of it" was supposed to mean? When the guys from Bull designed SNEGO (the protection "P" was added to their proposal when it was disussed in the cat-ietf wg), then they did not only use it to negotiate among seperate mechanisms, but also for variants of a single mechanism (their mechanism seemed to lack the capability to negotiate crypto algorithms). So they proposed to append further elements to the gssapi mechanism ASN.1 OID to indicate crypto algorithms (QOPs) or other mechanism specific options (in a non-portable fashion). The original description was dropped from rfc2478, but I assume it was used like that by SESAME. (When the SNEGO proposal was originally brought up (~1997), there was a sample implementation available for download from Bull.) The original text about mechanism variants was this: As most existing GSS-API security mechanisms can support different options (such as differing cryptographic algorithms due to policy or legislative constraints), the Simple and Protected GSS-API Negotiation Mechanism allows to negotiate security mechanisms including their options (i.e. variants). Mechanism options can be considered as providing a type of "quality of protection" for security contexts. To facilitate mechanism negotiation, the OID which currently defines a security mechanism is "extended" to be able to specify options within a security mechanism rather than simply the basic mechanism. When the OID specifies the mechanism only and no explicit option, then this means that the default option is used. The default option and the specific options for a given mechanism are as defined in the IETF GSS-API specification(s) for the mechanism. This allows to negotiate basic security mechanisms, different options within a given security mechanism or different options from several basic security mechanisms. That approach was dropped from the spec by the cat-ietf wg because would have -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 16:25:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18363; Wed, 17 Nov 2004 16:25:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXLK-0005SQ-BY; Wed, 17 Nov 2004 16:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWjd-00037l-Gy; Wed, 17 Nov 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUgO-0005aG-RC for kitten@megatron.ietf.org; Wed, 17 Nov 2004 13:37:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28221 for ; Wed, 17 Nov 2004 13:37:31 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUio-0000BS-OR for kitten@ietf.org; Wed, 17 Nov 2004 13:40:05 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 81CFAE003B; Wed, 17 Nov 2004 13:37:48 -0500 (EST) To: kitten@ietf.org References: <200411171818.TAA24440@uw1048.wdf.sap.corp> From: Sam Hartman Date: Wed, 17 Nov 2004 13:37:48 -0500 In-Reply-To: <200411171818.TAA24440@uw1048.wdf.sap.corp> (Martin Rex's message of "Wed, 17 Nov 2004 19:18:00 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Wed, 17 Nov 2004 15:49:00 -0500 Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I wonder if SPNEGO needs to pick up a copy of the standard multi-layer-negotiation considered harmful argument? I wonder if we're getting to a point where we need a single version of that document to reference. (I bring up this comment because Martin's discussion of GSSAPI variants reminds me that doing stuff like that at the SPNEGO layer is the only safe way to do it in a case where you have the SPNEGO layer at all. Probably not so true for crypto algorithms, but true for anything that can influence the choice of mechanism.) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 17:06:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24129; Wed, 17 Nov 2004 17:06:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXyq-00075l-2m; Wed, 17 Nov 2004 17:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXi6-0005Zd-U5; Wed, 17 Nov 2004 16:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUXLL-0002FE-Sp for kitten@megatron.ietf.org; Wed, 17 Nov 2004 16:27:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19124 for ; Wed, 17 Nov 2004 16:27:57 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUXNo-0005dD-Qd for kitten@ietf.org; Wed, 17 Nov 2004 16:30:34 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAHLRu6O021931 for ; Wed, 17 Nov 2004 13:27:56 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAHLRujW020102 for ; Wed, 17 Nov 2004 14:27:56 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAHLRJP9488281; Wed, 17 Nov 2004 15:27:19 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAHLRIlQ488280; Wed, 17 Nov 2004 15:27:18 -0600 (CST) Date: Wed, 17 Nov 2004 15:27:18 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041117212718.GB473487@binky.central.sun.com> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: <200411171818.TAA24440@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote: > I wonder if SPNEGO needs to pick up a copy of the standard > multi-layer-negotiation considered harmful argument? I wonder if > we're getting to a point where we need a single version of that > document to reference. Yes, yes. > > (I bring up this comment because Martin's discussion of GSSAPI > variants reminds me that doing stuff like that at the SPNEGO layer is > the only safe way to do it in a case where you have the SPNEGO layer > at all. Probably not so true for crypto algorithms, but true for > anything that can influence the choice of mechanism.) "only" is a bit strong, but I digress :) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 22:18:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20139; Wed, 17 Nov 2004 22:18:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcrI-0005U5-OI; Wed, 17 Nov 2004 22:21:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUcDS-0006CH-7l; Wed, 17 Nov 2004 21:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUc90-0004uf-FE for kitten@megatron.ietf.org; Wed, 17 Nov 2004 21:35:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18801 for ; Wed, 17 Nov 2004 21:35:32 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcBX-0004rH-7F for kitten@ietf.org; Wed, 17 Nov 2004 21:38:11 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 18:34:51 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 18:35:02 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:35:00 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 18:35:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2004 18:34:52 -0800 Message-ID: Thread-Topic: SPNEGO SOMIC rules Thread-Index: AcTMHocI1XzmcCa3R4WQ5DhOAZl14gA+Gdfw From: "Liqiang\(Larry\) Zhu" To: , "Sam Hartman" X-OriginalArrivalTime: 18 Nov 2004 02:35:01.0729 (UTC) FILETIME=[3438B510:01C4CD17] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > OK, I'll wait and see. The next version of this draft is still in review by the authors. It should be available to publish soon, but I just sent Martin a copy of the initial version. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Tuesday, November 16, 2004 12:51 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules Sam Hartman wrote: >=20 > The server knows (because the new protocol will mandate this behavior) > that a client will demand a MIC if the client sees the server trying=20 > to negotiate anything other than the most preferred mechanism of the=20 > client. That's part of the meta-rule Nico proposes. >=20 > Again, how the client demands a MIC is something Larry's draft will=20 > explain. OK, I'll wait and see. >=20 > It should be clear thought that the situation where the client offers=20 > only one mechanism is secure provided that the client can demand a MIC > and correctly coded clients do demand a MIC in the appropriate=20 > situations. I think that a client that has only a single mechanism an uses SPNEGO is broken, it should be using the underlying gss-api mechanism directly, and will become interoperable with peers that do not support SPNEGO. Actually, the client's SPNEGO implementation could make that optimization instead of going for the SPNEGO exchange with optimistic token. That way it will not only omit/save the mechListMIC, but all the SPNEGO overhead and complexity. When I asked Larry whether their IIS would correctly handle a Kerberos token instead of a Kerberos-optimistic-token-within-SPNEGO when doing the HTTP-authentication, he claimed this should work. Suggesting such a change for *initiators* would *not* impair backwards compatibility with correct implementations of SPNEGO (which may exist). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 22:39:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22321; Wed, 17 Nov 2004 22:39:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUdBf-00061O-2h; Wed, 17 Nov 2004 22:42:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUd4w-0001fX-Fm; Wed, 17 Nov 2004 22:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUctp-0007hU-3c for kitten@megatron.ietf.org; Wed, 17 Nov 2004 22:23:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20497 for ; Wed, 17 Nov 2004 22:23:54 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcwM-0005aJ-J1 for kitten@ietf.org; Wed, 17 Nov 2004 22:26:34 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:45:39 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 18:45:37 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:45:38 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 18:45:36 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2004 18:45:26 -0800 Message-ID: Thread-Topic: SPNEGO SOMIC rules Thread-Index: AcTMLMgSqEYVnmp6TsW5jByYJGxmLgA67IBA From: "Liqiang\(Larry\) Zhu" To: "Wyllys Ingersoll" , "Sam Hartman" X-OriginalArrivalTime: 18 Nov 2004 02:45:36.0096 (UTC) FILETIME=[AE556E00:01C4CD18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Wyllys Ingersoll wrote: > Perhaps there should be some sort of statement in the new SPNEGO draft that clearly states that initiators who only send 1=20 > mech in the mechlist should not use SPNEGO at all and just use their preferred mechanism. Likewise, servers that accept > > SPNEGO should also be able to accept initial tokens for any of their supported mechanisms without SPNEGO wrapping. No, this might solve the case with a SUN client and MS server, but not the case with a MS client and a SUN server. Our clients do have more than one to offer. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Wyllys Ingersoll Sent: Tuesday, November 16, 2004 1:28 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules Sam Hartman wrote: >>>>>>"Martin" =3D=3D Martin Rex writes: >=20 >=20 >=20 > Martin> I think that a client that has only a single mechanism an > Martin> uses SPNEGO is broken, it should be using the underlying > Martin> gss-api mechanism directly, and will become interoperable > Martin> with peers that do not support SPNEGO. >=20 > Martin> Actually, the client's SPNEGO implementation could make > Martin> that optimization instead of going for the SPNEGO exchange > Martin> with optimistic token. That way it will not only > Martin> omit/save the mechListMIC, but all the SPNEGO overhead and > Martin> complexity. >=20 > we need to mandate that a server receieving a normal mechanism token=20 > but expecting an SPNEGO token should respond appropriately if we're=20 > going to allow this optimization. I don't mind mandating that, but I=20 > don't think we do today. Perhaps there should be some sort of statement in the new SPNEGO draft that clearly states that initiators who only send 1 mech in the mechlist should not use SPNEGO at all and just use their preferred mechanism. Likewise, servers that accept SPNEGO should also be able to accept initial tokens for any of their supported mechanisms without SPNEGO wrapping. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 17 22:40:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22354; Wed, 17 Nov 2004 22:40:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUdCp-000629-H0; Wed, 17 Nov 2004 22:43:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUd4w-0001fq-TV; Wed, 17 Nov 2004 22:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUctq-0007nS-RJ for kitten@megatron.ietf.org; Wed, 17 Nov 2004 22:23:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20500 for ; Wed, 17 Nov 2004 22:23:56 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUcwN-0005aJ-AS for kitten@ietf.org; Wed, 17 Nov 2004 22:26:36 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:43:17 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:43:15 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 18:43:13 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 17 Nov 2004 18:43:14 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2004 18:43:04 -0800 Message-ID: Thread-Topic: SPNEGO SOMIC rules Thread-Index: AcTMHocI1XzmcCa3R4WQ5DhOAZl14gA+UVuA From: "Liqiang\(Larry\) Zhu" To: , "Sam Hartman" X-OriginalArrivalTime: 18 Nov 2004 02:43:14.0801 (UTC) FILETIME=[5A1D8610:01C4CD18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable =20 > I think that a client that has only a single mechanism an uses SPNEGO is broken, it should be using the underlying gss- > api mechanism directly, and will become interoperable with peers that do not support SPNEGO. You are correct, SPNEGO is useful when the client supports more than one mechanism. Our clients have two mechanism to offer, we want to 1) interoperate with other implementations, 2) allow negotiation.=20 -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Tuesday, November 16, 2004 12:51 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules Sam Hartman wrote: >=20 > The server knows (because the new protocol will mandate this behavior) > that a client will demand a MIC if the client sees the server trying=20 > to negotiate anything other than the most preferred mechanism of the=20 > client. That's part of the meta-rule Nico proposes. >=20 > Again, how the client demands a MIC is something Larry's draft will=20 > explain. OK, I'll wait and see. >=20 > It should be clear thought that the situation where the client offers=20 > only one mechanism is secure provided that the client can demand a MIC > and correctly coded clients do demand a MIC in the appropriate=20 > situations. I think that a client that has only a single mechanism an uses SPNEGO is broken, it should be using the underlying gss-api mechanism directly, and will become interoperable with peers that do not support SPNEGO. Actually, the client's SPNEGO implementation could make that optimization instead of going for the SPNEGO exchange with optimistic token. That way it will not only omit/save the mechListMIC, but all the SPNEGO overhead and complexity. When I asked Larry whether their IIS would correctly handle a Kerberos token instead of a Kerberos-optimistic-token-within-SPNEGO when doing the HTTP-authentication, he claimed this should work. Suggesting such a change for *initiators* would *not* impair backwards compatibility with correct implementations of SPNEGO (which may exist). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Nov 18 07:40:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20114; Thu, 18 Nov 2004 07:40:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUlcp-0008VN-PS; Thu, 18 Nov 2004 07:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUlZF-0005t0-Bh; Thu, 18 Nov 2004 07:39:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUlVQ-00051k-0M for kitten@megatron.ietf.org; Thu, 18 Nov 2004 07:35:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19618 for ; Thu, 18 Nov 2004 07:35:18 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUlY2-0008OH-2b for kitten@ietf.org; Thu, 18 Nov 2004 07:38:02 -0500 Received: from jurassic.eng.sun.com ([129.146.89.50]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAICZHVu020785; Thu, 18 Nov 2004 05:35:18 -0700 (MST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAICZGXh727579; Thu, 18 Nov 2004 04:35:17 -0800 (PST) Message-ID: <419C95DC.8020505@sun.com> Date: Thu, 18 Nov 2004 07:30:20 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041028 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Liqiang(Larry) Zhu wrote: > Wyllys Ingersoll wrote: > >>Perhaps there should be some sort of statement in the new SPNEGO draft > > that clearly states that initiators who only send 1 > >>mech in the mechlist should not use SPNEGO at all and just use their > > preferred mechanism. Likewise, servers that accept > > SPNEGO should > also be able to accept initial tokens for any of their supported > mechanisms without SPNEGO wrapping. > > No, this might solve the case with a SUN client and MS server, but not > the case with a MS client and a SUN server. Our clients do have more > than one to offer. In the case of the Solaris GSS server, it would accept GSS-SPNEGO or GSS-KRB5, either one would work. The point I was making is that GSS servers should not restrict themselves to accept *only* SPNEGO, so that if a client only supports a single mechanism, the server would still be able to process it. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 19 18:00:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04689; Fri, 19 Nov 2004 18:00:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVHmq-0004t2-J0; Fri, 19 Nov 2004 18:03:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVHez-0007AH-VX; Fri, 19 Nov 2004 17:55:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVHby-00064w-Fd for kitten@megatron.ietf.org; Fri, 19 Nov 2004 17:52:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03954 for ; Fri, 19 Nov 2004 17:52:12 -0500 (EST) Received: from stratton-four-twenty-seven.mit.edu ([18.187.6.172] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVHes-0004iK-KL for kitten@ietf.org; Fri, 19 Nov 2004 17:55:15 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id A3A6AE003B; Fri, 19 Nov 2004 17:52:14 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Message-Id: <20041119225214.A3A6AE003B@cz.mit.edu> Date: Fri, 19 Nov 2004 17:52:14 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: Critical extensions to SPNEGO X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c I'm assuming we do not need a mechanism for critical extensions in SPNEGO. It is doable if we standardize it now, but it would be a hack and would not be in the spirit of the GSSAPI. Typically in GSSAPI applications, the client must verify that the context is acceptable after negotiation. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 19 18:51:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09166; Fri, 19 Nov 2004 18:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVIa4-0005o1-N4; Fri, 19 Nov 2004 18:54:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVIW3-0004Cz-UP; Fri, 19 Nov 2004 18:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVIVB-0003Zy-8b for kitten@megatron.ietf.org; Fri, 19 Nov 2004 18:49:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09064 for ; Fri, 19 Nov 2004 18:49:14 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVIY5-0005m6-AJ for kitten@ietf.org; Fri, 19 Nov 2004 18:52:18 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAJNnEVu011368 for ; Fri, 19 Nov 2004 16:49:14 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAJNnEjW029317 for ; Fri, 19 Nov 2004 16:49:14 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAJNmZ1K494195; Fri, 19 Nov 2004 17:48:35 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAJNmZAQ494194; Fri, 19 Nov 2004 17:48:35 -0600 (CST) Date: Fri, 19 Nov 2004 17:48:35 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041119234834.GW473487@binky.central.sun.com> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: <20041119225214.A3A6AE003B@cz.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041119225214.A3A6AE003B@cz.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@ietf.org Subject: Re: Critical extensions to SPNEGO X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Fri, Nov 19, 2004 at 05:52:14PM -0500, Sam Hartman wrote: > I'm assuming we do not need a mechanism for critical extensions in > SPNEGO. It is doable if we standardize it now, but it would be a hack > and would not be in the spirit of the GSSAPI. Typically in GSSAPI > applications, the client must verify that the context is acceptable > after negotiation. If we ever add new fields to the SEQUENCEs in SPNEGO tokens we'll have to add new MIC fields to sign those as well. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 03:31:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01112; Mon, 22 Nov 2004 03:31:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9er-0007tj-Qh; Mon, 22 Nov 2004 03:34:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9Q1-0002Q7-RN; Mon, 22 Nov 2004 03:19:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9PH-0002ES-L9 for kitten@megatron.ietf.org; Mon, 22 Nov 2004 03:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00243 for ; Mon, 22 Nov 2004 03:18:42 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9Sh-0007eE-5K for kitten@ietf.org; Mon, 22 Nov 2004 03:22:15 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 00:18:11 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 00:18:10 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 00:18:39 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 00:18:11 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2004 00:18:05 -0800 Message-ID: Thread-Topic: SPNEGO-bis: a summary of discussions at the DC and changes since -00 Thread-Index: AcTQa82Fi0y0BV/oRNCdiJ3eidZSmg== From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 22 Nov 2004 08:18:11.0104 (UTC) FILETIME=[CE190200:01C4D06B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Subject: SPNEGO-bis: a summary of discussions at the DC and changes since -00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable The updated version was submitted, and it was based on discussions we had at IETF61.=20 The following is a summary of major changes since -00. This is also the summary of the discussions among Sam, Wyllys, Nico, Jeff, me and others at the Washington DC. 1) The support of security mechanisms that do not support integrity services is back. 2) The request_mic state is added as an optimization for avoiding an extra message. 3) The MIC request now contains a MIC itself. 4) The security invariants are summarized in the security considerations, and the security of SPNEGO is discussed. 5) Legacy windows SPNEGO implementations are described. 6) Discussions on extensibility were added. 7) The Safe-to-omit MIC rules are consolidated into a separate/new section. 8) Out-of-band negotiation as mentioned by Luke did not make into this version (was not considered needed). 9) The computation of mechlistMIC is further clarified. 10) Discussions on the use of the optimistic token were added: pros and cons. 11) The use of reqFlags remains unchanged. Note that implementers can promote the "OPTIONAL" MIC token exchange to be "REQUIRED", if so desirable.=20 The complexity as the result of maintaining backward compatibility is kept to minimal. Thanks, -- Larry _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 07:22:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23817; Mon, 22 Nov 2004 07:22:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWDGH-0000FO-MN; Mon, 22 Nov 2004 07:25:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWDCG-0007nB-Na; Mon, 22 Nov 2004 07:21:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWDBG-0007eR-Cl for kitten@megatron.ietf.org; Mon, 22 Nov 2004 07:20:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23771 for ; Mon, 22 Nov 2004 07:20:29 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWDEg-000079-Sy for kitten@ietf.org; Mon, 22 Nov 2004 07:24:04 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAMCJbxF027411; Mon, 22 Nov 2004 23:19:37 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAMCJZiT027402; Mon, 22 Nov 2004 23:19:35 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411221219.iAMCJZiT027402@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lzhu@windows.microsoft.com Date: Mon, 22 Nov 2004 23:19:35 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since -00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >9) The computation of mechlistMIC is further clarified. What was the rationale for not including the tag and length of the encoded MechTypeList as input to GSS_GetMIC()? I ask only as Heimdal presently does include the tag and length when computing the mechlistMIC. I would be interested to know if you surveyed other implementations. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 11:35:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14916; Mon, 22 Nov 2004 11:35:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWHDT-0005Ea-5q; Mon, 22 Nov 2004 11:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWH2o-0004OA-Dg; Mon, 22 Nov 2004 11:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGst-0002ca-Vi for kitten@megatron.ietf.org; Mon, 22 Nov 2004 11:17:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12927 for ; Mon, 22 Nov 2004 11:17:45 -0500 (EST) Received: from jalapeno.cc.columbia.edu ([128.59.206.19] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGwN-0004Cl-NK for kitten@ietf.org; Mon, 22 Nov 2004 11:21:24 -0500 Received: from [18.18.6.109] (WEST-NINETYTWO-THREE-SIXTY-FOUR.MIT.EDU [18.18.6.109]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iAMGHhmn013113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Nov 2004 11:17:44 -0500 (EST) Message-ID: <41A1F5BE.6020301@columbia.edu> Date: Mon, 22 Nov 2004 09:20:46 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.19 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since -00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Liqiang(Larry) Zhu wrote: > The updated version was submitted, and it was based on discussions we > had at IETF61. > > > The following is a summary of major changes since -00. This is also the > summary of the discussions among Sam, Wyllys, Nico, Jeff, me and others > at the Washington DC. > > 1) The support of security mechanisms that do not support integrity > services is back. Although this decision has not been validated on the list yet, according to the minutes of the IETF 61 meeting there was a strong preference to maintain the MUST NOT restriction on the use of security mechanisms without integrity protection. I will also point out that no consensus has yet been reached on whether the use of an optimistic token in SPNEGO will be SHOULD or MAY in the document. I will be issuing a CALL FOR CONSENSUS on these issues and other decisions from IETF 61 later today. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 12:55:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26911; Mon, 22 Nov 2004 12:55:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIT2-0005V3-A1; Mon, 22 Nov 2004 12:59:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIE4-0001b4-UV; Mon, 22 Nov 2004 12:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWICf-0001N7-Au for kitten@megatron.ietf.org; Mon, 22 Nov 2004 12:42:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25853 for ; Mon, 22 Nov 2004 12:42:14 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIG9-000434-Sd for kitten@ietf.org; Mon, 22 Nov 2004 12:45:54 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 09:41:36 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 09:41:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 09:41:45 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 09:41:44 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2004 09:42:05 -0800 Message-ID: Thread-Topic: SPNEGO-bis: a summary of discussions at the DC and changes since -00 Thread-Index: AcTQruFOmNHZIb3rT++GOl/vjMlKeQAC3cmA From: "Liqiang\(Larry\) Zhu" To: "Jeffrey Altman" X-OriginalArrivalTime: 22 Nov 2004 17:41:44.0311 (UTC) FILETIME=[8856F070:01C4D0BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO-bis: a summary of discussions at the DC and changes since -00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable > Larry Zhu wrote: > 1) The support of security mechanisms that do not support integrity=20 > services is back. This was actually left unspecified in the draft submitted. -- Larry -----Original Message----- From: Jeffrey Altman [mailto:jaltman@columbia.edu]=20 Sent: Monday, November 22, 2004 6:21 AM To: Liqiang(Larry) Zhu Cc: kitten@ietf.org Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since -00 Liqiang(Larry) Zhu wrote: > The updated version was submitted, and it was based on discussions we=20 > had at IETF61. >=20 >=20 > The following is a summary of major changes since -00. This is also=20 > the summary of the discussions among Sam, Wyllys, Nico, Jeff, me and=20 > others at the Washington DC. >=20 > 1) The support of security mechanisms that do not support integrity=20 > services is back. Although this decision has not been validated on the list yet, according to the minutes of the IETF 61 meeting there was a strong preference to maintain the MUST NOT restriction on the use of security mechanisms without integrity protection. I will also point out that no consensus has yet been reached on whether the use of an optimistic token in SPNEGO will be SHOULD or MAY in the document. I will be issuing a CALL FOR CONSENSUS on these issues and other decisions from IETF 61 later today. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 17:15:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28063; Mon, 22 Nov 2004 17:15:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMX0-00060y-0r; Mon, 22 Nov 2004 17:19:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMEm-0002nm-CM; Mon, 22 Nov 2004 17:00:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWM5F-0007MG-NP for kitten@megatron.ietf.org; Mon, 22 Nov 2004 16:50:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24633 for ; Mon, 22 Nov 2004 16:50:51 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWM8c-0002Te-By for kitten@ietf.org; Mon, 22 Nov 2004 16:54:32 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA15567; Mon, 22 Nov 2004 22:49:57 +0100 (MEZ) From: Martin Rex Message-Id: <200411222149.WAA25245@uw1048.wdf.sap.corp> To: jaltman@columbia.edu (Jeffrey Altman) Date: Mon, 22 Nov 2004 22:49:57 +0100 (MET) In-Reply-To: <41A1F5BE.6020301@columbia.edu> from "Jeffrey Altman" at Nov 22, 4 09:20:46 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Jeffrey Altman wrote: > > Although this decision has not been validated on the list yet, according > to the minutes of the IETF 61 meeting there was a strong preference to > maintain the MUST NOT restriction on the use of security mechanisms > without integrity protection. ... MUST NOT ... without ... I'm not sure I understand. Keep in mind that base GSS-API does not have a MUST support integrity protection, so a requirement in SPNEGO would exclude those mechanisms entirely from negotiation. Personally, I think the warning in the security considerations that the absense of integrity protection on any single mechanism of the clients mechanism list makes the handshake vulnerable to a downgrade attack should be sufficient. > > I will also point out that no consensus has yet been reached on whether > the use of an optimistic token in SPNEGO will be SHOULD or MAY in the > document. My clear preference is to stick with MAY, as in the original SPNEGO spec. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 17:23:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28477; Mon, 22 Nov 2004 17:23:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMe9-0007Ae-68; Mon, 22 Nov 2004 17:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMWl-0006lu-KJ; Mon, 22 Nov 2004 17:19:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMHf-0003zV-Hy for kitten@megatron.ietf.org; Mon, 22 Nov 2004 17:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27079 for ; Mon, 22 Nov 2004 17:03:41 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMLB-0004QQ-OG for kitten@ietf.org; Mon, 22 Nov 2004 17:07:23 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id CE402E003B; Mon, 22 Nov 2004 17:03:46 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Mon, 22 Nov 2004 17:03:46 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: housley@vigilsec.com Subject: Conflict of interest: SPNEGO? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 There has been a bit of confusion surrounding the authors/editors for SPNEGO. Larry asked me if I wanted to be listed as an author; I didn't see the message and he took my silence as confirmation. As it turns out I don't think I should be listed as an author although I probably should be acknowledged in the acknowledgements section. I think this was just a misunderstanding. However I want to make sure that the working group does not believe a conflict of interest exists for me being the AD handling that document. Below, I'll list what I believe my contributions to that document are. If you believe that I should recuse myself and ask Russ to Shepard the document please let Jeff Altman or I know. First, I have sent several messages about the draft. I described changes I saw between Larry's first version and RFC 2748 as well as pointing out issues that needed more review. I participated in discussions of the issues I brought up. At the IETF meeting, I participated in several meetings with Larry, Nico and Jeff Altman. Other people were in some of these meetings. The goal was to determine whether Larry's somic rules were secure. We discussed various modifications to reduce round trips or improve security. I also helped work through an understanding of what threats we were trying to protect against and what security guarantee the SPNEGO protocol makes. I've proposed text to be included in the security considerations section and proposed text on extensibility of the protocol. I've also reviewed several versions of the draft and discussed whether various proposed changes impacted security. I described some things I believed the security considerations section needed to cover on the mailing list. I also brought up interoperability/compatibility concerns with the proposal to drop support for mechanisms without integrity. I've also responded to several mailing list exchanges that happened since the meeting. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 17:51:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01803; Mon, 22 Nov 2004 17:51:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWN5c-0002lM-4X; Mon, 22 Nov 2004 17:55:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMdl-0000n8-0Y; Mon, 22 Nov 2004 17:26:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMbW-0000I5-I0 for kitten@megatron.ietf.org; Mon, 22 Nov 2004 17:24:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28540 for ; Mon, 22 Nov 2004 17:24:12 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMf3-0007Ba-Bn for kitten@ietf.org; Mon, 22 Nov 2004 17:27:53 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 06DCFE003B; Mon, 22 Nov 2004 17:24:15 -0500 (EST) To: martin.rex@sap.com References: <200411222149.WAA25245@uw1048.wdf.sap.corp> From: Sam Hartman Date: Mon, 22 Nov 2004 17:24:15 -0500 In-Reply-To: <200411222149.WAA25245@uw1048.wdf.sap.corp> (Martin Rex's message of "Mon, 22 Nov 2004 22:49:57 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 >>>>> "Martin" == Martin Rex writes: Martin> Personally, I think the warning in the security Martin> considerations that the absense of integrity protection on Martin> any single mechanism of the clients mechanism list makes Martin> the handshake vulnerable to a downgrade attack should be Martin> sufficient. Speaking as an individual, I agree. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 19:34:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11544; Mon, 22 Nov 2004 19:34:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOhT-0008FQ-27; Mon, 22 Nov 2004 19:38:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOTk-00005d-1c; Mon, 22 Nov 2004 19:24:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOLQ-0007Qy-LY for kitten@megatron.ietf.org; Mon, 22 Nov 2004 19:15:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09670 for ; Mon, 22 Nov 2004 19:15:41 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOOx-0005Ts-KG for kitten@ietf.org; Mon, 22 Nov 2004 19:19:25 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 16:15:11 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 16:14:52 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 16:15:11 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 16:15:10 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2004 16:15:03 -0800 Message-ID: Thread-Topic: SPNEGO-bis: a summary of discussions at the DC and changes since Thread-Index: AcTQ3UL6JzhlE8jAQY+qwYUX1Cdz5gAE5OKw From: "Liqiang\(Larry\) Zhu" To: , "Jeffrey Altman" X-OriginalArrivalTime: 23 Nov 2004 00:15:10.0412 (UTC) FILETIME=[7EAC18C0:01C4D0F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO-bis: a summary of discussions at the DC and changes since X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > My clear preference is to stick with MAY, as in the original SPNEGO spec. Most of people who have spoken either on the list or at the DC preferred a "SHOULD". You did not provide convincing arguments for a "MAY". If your sole purpose to use a "MAY" is to test applications and break bad ones, a "SHOULD" here is sufficient. The consensus seemed clearly to be a "SHOULD", not a "MAY" in this case. -- Larry -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Monday, November 22, 2004 1:50 PM To: Jeffrey Altman Cc: Liqiang(Larry) Zhu; kitten@ietf.org Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since Jeffrey Altman wrote: >=20 > Although this decision has not been validated on the list yet,=20 > according to the minutes of the IETF 61 meeting there was a strong=20 > preference to maintain the MUST NOT restriction on the use of security > mechanisms without integrity protection. ... MUST NOT ... without ... I'm not sure I understand. Keep in mind that base GSS-API does not have a MUST support integrity protection, so a requirement in SPNEGO would exclude those mechanisms entirely from negotiation. Personally, I think the warning in the security considerations that the absense of integrity protection on any single mechanism of the clients mechanism list makes the handshake vulnerable to a downgrade attack should be sufficient. >=20 > I will also point out that no consensus has yet been reached on=20 > whether the use of an optimistic token in SPNEGO will be SHOULD or MAY > in the document. My clear preference is to stick with MAY, as in the original SPNEGO spec. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Nov 22 21:49:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22611; Mon, 22 Nov 2004 21:49:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWQo4-0000Vk-2y; Mon, 22 Nov 2004 21:53:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWQhH-0003y9-FL; Mon, 22 Nov 2004 21:46:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWQdU-0002nq-2j for kitten@megatron.ietf.org; Mon, 22 Nov 2004 21:42:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22105 for ; Mon, 22 Nov 2004 21:42:30 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWQh3-0008Dr-Jn for kitten@ietf.org; Mon, 22 Nov 2004 21:46:14 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 18:42:04 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 18:41:59 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 18:42:04 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 22 Nov 2004 18:41:59 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2004 18:41:48 -0800 Message-ID: Thread-Topic: SPNEGO-bis: a summary of discussions at the DC and changes since -00 Thread-Index: AcTQja7ZrSuzmeFFSLyWEpqmNSF8LQAd/WuA From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 23 Nov 2004 02:41:59.0239 (UTC) FILETIME=[01246D70:01C4D106] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO-bis: a summary of discussions at the DC and changes since -00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable I talked with Luke off-list about this, we might not have issues at all here but we definitely need some clarifications with all the inner and outer tags and lengths, and how to describe them unambiguously. Thanks, -- Larry -----Original Message----- From: Luke Howard [mailto:lukeh@padl.com]=20 Sent: Monday, November 22, 2004 4:20 AM To: Liqiang(Larry) Zhu Cc: kitten@ietf.org; lha@stacken.kth.se Subject: Re: SPNEGO-bis: a summary of discussions at the DC and changes since -00 >9) The computation of mechlistMIC is further clarified. What was the rationale for not including the tag and length of the encoded MechTypeList as input to GSS_GetMIC()? I ask only as Heimdal presently does include the tag and length when computing the mechlistMIC. I would be interested to know if you surveyed other implementations. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 00:07:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14764; Tue, 23 Nov 2004 00:07:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWSxT-0001y8-5K; Tue, 23 Nov 2004 00:11:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWSjf-0005cP-Cx; Mon, 22 Nov 2004 23:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWSiM-0005On-QF for kitten@megatron.ietf.org; Mon, 22 Nov 2004 23:55:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13972 for ; Mon, 22 Nov 2004 23:55:39 -0500 (EST) Received: from cathode-dark-space.mit.edu ([18.18.1.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWSlw-0000Iy-O5 for kitten@ietf.org; Mon, 22 Nov 2004 23:59:25 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id iAN4teLx001958; Mon, 22 Nov 2004 23:55:40 -0500 (EST) To: lukeh@padl.com References: <200411221219.iAMCJZiT027402@au.padl.com> From: Tom Yu Date: Mon, 22 Nov 2004 23:55:40 -0500 In-Reply-To: <200411221219.iAMCJZiT027402@au.padl.com> (Luke Howard's message of "Mon, 22 Nov 2004 23:19:35 +1100") Message-ID: Lines: 133 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 >>>>> "lukeh" == Luke Howard writes: >> 9) The computation of mechlistMIC is further clarified. lukeh> What was the rationale for not including the tag and length lukeh> of the encoded MechTypeList as input to GSS_GetMIC()? lukeh> I ask only as Heimdal presently does include the tag and length lukeh> when computing the mechlistMIC. I would be interested to know lukeh> if you surveyed other implementations. In response to the above, and to some private email from Larry, I will attempt to clarify the nature of the confusion. Fundamentally, the confusion results from imprecision in the terminology used by the document for referring to details of ASN.1 encodings. I apologize for the length of this reply, as I include some necessary tutorial information about ASN.1 encoding rules and about certain ASN.1 concepts. The draft-zhu-spnego-2478bis-01 document has: 4.1 Mechanism Types [...] MechType ::= OBJECT IDENTIFIER [...] MechTypeList ::= SEQUENCE OF MechType [...] 4.2.1 negTokenInit NegTokenInit ::= SEQUENCE { mechTypes [0] MechTypeList, reqFlags [1] ContextFlags OPTIONAL, mechToken [2] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL, ... } [...] 5. Processing of mechListMIC [...] a) The mechlistMIC token (or simply the MIC token) is computed through invoking GSS_GetMIC(): the input context_handle is the established mechanism context, the input qop_req is 0, and the input message is the mechTypes field in the initial negotiation message (only the "value" portion, omitting the tag and length, of the ASN.1 encoding for that field is included). It is not very useful to speak of the encoding of a _field_ of an ASN.1 structure in isolation from the encoding of the complete structure. It is only really meaningful to speak of the encoding of an ASN.1 _type_. This is a _very_ _important_ concept. When the document says "input message is the mechTypes field in the initial negotiation message", there is an ambiguity about which ASN.1 _type_ is meant. "mechTypes" is _not_ the name of an ASN.1 type. (Recall that case is lexically significant in ASN.1.) "mechTypes" is the name identifying a component of a SEQUENCE type. The _type_ of the component named "mechTypes" is "[0] MechTypeList". What might be meant instead is that the MIC must be computed over the encoding of the type "MechTypeList" rather than over the encoding of the type "[0] MechTypeList". Additionally, X.690 describes BER encodings as consisting of "identifier octets", "length octets", and "contents octets". The word "value" is not used to refer to the "contents octets", since the ASN.1 specifications typically use the word "value" to refer to the _abstract_ value of a type, which is an _input_ to the encoding process. The initial fragment of a NegTokenInit would look like: (with each level of contents indented, and where "nn" are some length encodings, possibly longer than one octet each) 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) nn -- length -- contents of SEQUENCE are: A0 -- identifier octet for constructed [0] nn -- length -- contents of the constructed [0] are: 30 -- identifier octet for constructed SEQUENCE nn -- length -- contents of the SEQUENCE are: 06 -- identifier octet for primitive OBJECT IDENTIFIER 09 -- length 2A 86 48 86 F7 12 01 02 02 -- { 1 2 840 113554 1 2 2 } -- ... other OBJECT IDENTIFIER values ... Which of the following does the document mean for the MIC to be computed over? (a) The DER encoding of the type "[0] MechTypeList", i.e.: A0 nn 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... (b) The DER encoding of the type "MechTypeList", i.e.: 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... This is probably what is actually intended, as it makes very little sense to encode the additional tag for MIC purposes. (c) Only the _contents_ of type "MechTypeList", i.e.: 06 09 2A 86 48 86 F7 12 01 02 02 ... noting that the encoding is no longer self-delimiting without the id+length octets for the surrounding SEQUENCE encoding (which in my opinion is a _bad_ idea) (d) Something else entirely? For some reason, I get the strange feeling that we've had this discussion before. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 00:11:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15025; Tue, 23 Nov 2004 00:11:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWT1G-0002hX-IQ; Tue, 23 Nov 2004 00:15:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWSuZ-0007Sn-7A; Tue, 23 Nov 2004 00:08:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWSqS-0006md-D6 for kitten@megatron.ietf.org; Tue, 23 Nov 2004 00:04:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14488 for ; Tue, 23 Nov 2004 00:04:01 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWSu1-0001Yd-3z for kitten@ietf.org; Tue, 23 Nov 2004 00:07:46 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAN53FqW063659; Tue, 23 Nov 2004 16:03:15 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAN53FPS063658; Tue, 23 Nov 2004 16:03:15 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411230503.iAN53FPS063658@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: tlyu@mit.edu References: <200411221219.iAMCJZiT027402@au.padl.com> Date: Tue, 23 Nov 2004 16:03:15 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >(b) The DER encoding of the type "MechTypeList", i.e.: > > 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... > > This is probably what is actually intended, as it makes very > little sense to encode the additional tag for MIC purposes. >From talking to Larry it does appear that (b) is intended. The language in the draft suggested to me (c), though, so it could probably do with some clarification. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 01:22:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20135; Tue, 23 Nov 2004 01:22:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWU7g-0003Ce-PR; Tue, 23 Nov 2004 01:25:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWU2N-0004i0-FC; Tue, 23 Nov 2004 01:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWTyD-0003rg-6t for kitten@megatron.ietf.org; Tue, 23 Nov 2004 01:16:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19497 for ; Tue, 23 Nov 2004 01:16:07 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWU1o-0002Pn-1K for kitten@ietf.org; Tue, 23 Nov 2004 01:19:52 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Nov 2004 22:15:38 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 22:15:35 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 22:15:35 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 22 Nov 2004 22:15:35 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Nov 2004 22:15:32 -0800 Message-ID: Thread-Topic: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) Thread-Index: AcTRGL7++D2L2M3uQ4mzUKCQFzoK/wACbi+g From: "Liqiang\(Larry\) Zhu" To: "Tom Yu" , X-OriginalArrivalTime: 23 Nov 2004 06:15:35.0591 (UTC) FILETIME=[D8488B70:01C4D123] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Tom, thanks, choice (b) is clearly what we intended. Thanks, Larry=20 -----Original Message----- From: Tom Yu [mailto:tlyu@mit.edu]=20 Sent: Monday, November 22, 2004 8:56 PM To: lukeh@padl.com Cc: Liqiang(Larry) Zhu; kitten@ietf.org Subject: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) >>>>> "lukeh" =3D=3D Luke Howard writes: >> 9) The computation of mechlistMIC is further clarified. lukeh> What was the rationale for not including the tag and length of=20 lukeh> the encoded MechTypeList as input to GSS_GetMIC()? lukeh> I ask only as Heimdal presently does include the tag and length=20 lukeh> when computing the mechlistMIC. I would be interested to know if=20 lukeh> you surveyed other implementations. In response to the above, and to some private email from Larry, I will attempt to clarify the nature of the confusion. Fundamentally, the confusion results from imprecision in the terminology used by the document for referring to details of ASN.1 encodings. I apologize for the length of this reply, as I include some necessary tutorial information about ASN.1 encoding rules and about certain ASN.1 concepts. The draft-zhu-spnego-2478bis-01 document has: 4.1 Mechanism Types [...] MechType ::=3D OBJECT IDENTIFIER [...] MechTypeList ::=3D SEQUENCE OF MechType [...] 4.2.1 negTokenInit NegTokenInit ::=3D SEQUENCE { mechTypes [0] MechTypeList, reqFlags [1] ContextFlags OPTIONAL, mechToken [2] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL, ... } [...] 5. Processing of mechListMIC [...] a) The mechlistMIC token (or simply the MIC token) is computed through invoking GSS_GetMIC(): the input context_handle is the established mechanism context, the input qop_req is 0, and the input message is the mechTypes field in the initial negotiation message (only the "value" portion, omitting the tag and length, of the ASN.1 encoding for that field is included). It is not very useful to speak of the encoding of a _field_ of an ASN.1 structure in isolation from the encoding of the complete structure. It is only really meaningful to speak of the encoding of an ASN.1 _type_. This is a _very_ _important_ concept. When the document says "input message is the mechTypes field in the initial negotiation message", there is an ambiguity about which ASN.1 _type_ is meant. "mechTypes" is _not_ the name of an ASN.1 type. (Recall that case is lexically significant in ASN.1.) "mechTypes" is the name identifying a component of a SEQUENCE type. The _type_ of the component named "mechTypes" is "[0] MechTypeList". What might be meant instead is that the MIC must be computed over the encoding of the type "MechTypeList" rather than over the encoding of the type "[0] MechTypeList". Additionally, X.690 describes BER encodings as consisting of "identifier octets", "length octets", and "contents octets". The word "value" is not used to refer to the "contents octets", since the ASN.1 specifications typically use the word "value" to refer to the _abstract_ value of a type, which is an _input_ to the encoding process. The initial fragment of a NegTokenInit would look like: (with each level of contents indented, and where "nn" are some length encodings, possibly longer than one octet each) 30 -- identifier octet for constructed SEQUENCE (NegTokenInit) nn -- length -- contents of SEQUENCE are: A0 -- identifier octet for constructed [0] nn -- length -- contents of the constructed [0] are: 30 -- identifier octet for constructed SEQUENCE nn -- length -- contents of the SEQUENCE are: 06 -- identifier octet for primitive OBJECT IDENTIFIER 09 -- length 2A 86 48 86 F7 12 01 02 02 -- { 1 2 840 113554 1 2 2 } -- ... other OBJECT IDENTIFIER values ... Which of the following does the document mean for the MIC to be computed over? (a) The DER encoding of the type "[0] MechTypeList", i.e.: A0 nn 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... (b) The DER encoding of the type "MechTypeList", i.e.: 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... This is probably what is actually intended, as it makes very little sense to encode the additional tag for MIC purposes. (c) Only the _contents_ of type "MechTypeList", i.e.: 06 09 2A 86 48 86 F7 12 01 02 02 ... noting that the encoding is no longer self-delimiting without the id+length octets for the surrounding SEQUENCE encoding (which in my opinion is a _bad_ idea) (d) Something else entirely? For some reason, I get the strange feeling that we've had this discussion before. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 08:07:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07275; Tue, 23 Nov 2004 08:07:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWaRz-0005bh-A9; Tue, 23 Nov 2004 08:11:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWaK3-0002Dk-Rv; Tue, 23 Nov 2004 08:03:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWaFh-000146-0o for kitten@megatron.ietf.org; Tue, 23 Nov 2004 07:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06166 for ; Tue, 23 Nov 2004 07:58:35 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWaJK-0004Gt-SN for kitten@ietf.org; Tue, 23 Nov 2004 08:02:24 -0500 Received: from jurassic.eng.sun.com ([129.146.87.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iANCwVVu015981; Tue, 23 Nov 2004 05:58:31 -0700 (MST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iANCwU6i574800; Tue, 23 Nov 2004 04:58:30 -0800 (PST) Message-ID: <41A333F5.4040502@sun.com> Date: Tue, 23 Nov 2004 07:58:29 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041028 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Liqiang(Larry) Zhu wrote: > Tom, thanks, choice (b) is clearly what we intended. > (a) The DER encoding of the type "[0] MechTypeList", i.e.: A0 nn 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... (b) The DER encoding of the type "MechTypeList", i.e.: 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... From looking at my code, it appears that I interpreted the original document to mean A), but if the consensus is that B is correct, I can make the adjustment without much pain since MICs are not used at all in situations where we are interoperating with MS anyway. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 10:23:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20888; Tue, 23 Nov 2004 10:23:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWca1-0007La-B3; Tue, 23 Nov 2004 10:27:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcQF-0007TF-Jq; Tue, 23 Nov 2004 10:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcFR-0002fs-P3 for kitten@megatron.ietf.org; Tue, 23 Nov 2004 10:06:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18366 for ; Tue, 23 Nov 2004 10:06:26 -0500 (EST) Received: from imr5.us.db.com ([160.83.65.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcJ7-0004eX-0g for kitten@ietf.org; Tue, 23 Nov 2004 10:10:17 -0500 Received: from sdbo1005.db.com by imr5.us.db.com id iANF6OOr015854; Tue, 23 Nov 2004 10:06:26 -0500 (EST) To: "Wyllys Ingersoll X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Frank Balluffi" Date: Tue, 23 Nov 2004 10:06:23 -0500 X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(5013aHF19 | July 26, 2004) at 11/23/2004 10:06:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Score: 2.6 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 I do not fully understand what Larry means by "my code", but would just add that I have always received (a) from IE. The actual octets I have seen are: A0 24 30 22 mechTypes 06 09 2A 86 48 82 F7 12 01 02 02 1.2.840.48018.1.2.2 (Kerberos V5 Legacy) 06 09 2A 86 48 86 F7 12 01 02 02 1.2.840.113554.1.2.2 (Kerberos V5 GSS-API mechanism) 06 0A 2B 06 01 04 01 82 37 02 02 0A 1.3.6.1.4.1.311.2.2.10 (Microsoft SPNEGO sub-mechanism) Frank Wyllys Ingersoll sun.com> cc: kitten@ietf.org Sent by: Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) kitten-bounces@lis ts.ietf.org 11/23/2004 07:58 AM Liqiang(Larry) Zhu wrote: > Tom, thanks, choice (b) is clearly what we intended. > (a) The DER encoding of the type "[0] MechTypeList", i.e.: A0 nn 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... (b) The DER encoding of the type "MechTypeList", i.e.: 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... From looking at my code, it appears that I interpreted the original document to mean A), but if the consensus is that B is correct, I can make the adjustment without much pain since MICs are not used at all in situations where we are interoperating with MS anyway. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 11:08:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25336; Tue, 23 Nov 2004 11:08:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdGh-0004yZ-Lx; Tue, 23 Nov 2004 11:11:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcyx-0008IT-3x; Tue, 23 Nov 2004 10:53:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcrk-00064T-C6 for kitten@megatron.ietf.org; Tue, 23 Nov 2004 10:46:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23261 for ; Tue, 23 Nov 2004 10:46:01 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWcvN-0001jF-TV for kitten@ietf.org; Tue, 23 Nov 2004 10:49:53 -0500 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iANFjv6O010388; Tue, 23 Nov 2004 07:45:57 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iANFjujx680530; Tue, 23 Nov 2004 07:45:57 -0800 (PST) Message-ID: <41A35B34.3090500@sun.com> Date: Tue, 23 Nov 2004 10:45:56 -0500 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041028 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Balluffi References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Frank Balluffi wrote: > I do not fully understand what Larry means by "my code", but would just add that I have always received (a) from IE. The actual octets I have seen are: It was me (Wyllys Ingersoll), not Larry, who wrote about "my code". I was referring to a SPNEGO mechanism that I wrote which will be included in Solaris 10. I wrote one that interoperates with MS but that has a configurable option to be RFC 2478 compliant (and not interop with Microsoft). In the latter case, the MIC was computed across the DER encoding of "[0] MechTypeList" which is choice "a" from Tom Yu's earlier post on the topic. Whatever you received from IE or IIS in the past during SPNEGO negotiation should have been ignored because it was completely wrong and wasn't even a MIC at all, it was a copy of one of the other fields. -Wyllys > > A0 24 30 22 mechTypes > 06 09 2A 86 48 82 F7 12 01 02 02 1.2.840.48018.1.2.2 (Kerberos V5 Legacy) > 06 09 2A 86 48 86 F7 12 01 02 02 1.2.840.113554.1.2.2 (Kerberos V5 GSS-API mechanism) > 06 0A 2B 06 01 04 01 82 37 02 02 0A 1.3.6.1.4.1.311.2.2.10 (Microsoft SPNEGO sub-mechanism) > > Frank > > > > > Wyllys Ingersoll > > sun.com> cc: kitten@ietf.org > Sent by: Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...) > kitten-bounces@lis > ts.ietf.org > > > 11/23/2004 07:58 > AM > > > > > > > Liqiang(Larry) Zhu wrote: > >>Tom, thanks, choice (b) is clearly what we intended. >> > > > (a) The DER encoding of the type "[0] MechTypeList", i.e.: > > A0 nn 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... > > (b) The DER encoding of the type "MechTypeList", i.e.: > > 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ... > > From looking at my code, it appears that I interpreted > the original document to mean A), but if the consensus is > that B is correct, I can make the adjustment without much > pain since MICs are not used at all in situations where we > are interoperating with MS anyway. > > -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 13:33:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06512; Tue, 23 Nov 2004 13:33:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfXF-0007MD-LX; Tue, 23 Nov 2004 13:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfQv-00071h-FL; Tue, 23 Nov 2004 13:30:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfMI-0005yV-5y for kitten@megatron.ietf.org; Tue, 23 Nov 2004 13:25:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06070 for ; Tue, 23 Nov 2004 13:25:42 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfPq-0006Cw-7s for kitten@ietf.org; Tue, 23 Nov 2004 13:29:36 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA08071; Tue, 23 Nov 2004 19:25:02 +0100 (MEZ) From: Martin Rex Message-Id: <200411231825.TAA03698@uw1048.wdf.sap.corp> Orig-To: frank.balluffi@db.com (Frank Balluffi) To: wyllys.ingersoll@sun.com@db.com, kitten@ietf.org, lzhu@windows.microsoft.com Date: Tue, 23 Nov 2004 19:23:10 +0100 (MET) In-Reply-To: from "Frank Balluffi" at Nov 23, 4 10:06:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, lzhu@windows.microsoft.com, @db.com Subject: Re: What is SPNEGO mechlistMIC computed over? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit I was a little confused by your description (of OIDs and descriptions of those OIDs) therefore I rechecked quickly. Here's what I get inside an initial context token when requesting the "Negotiate" SSP on W2K3 IA64: a0 24 30 22 06 09 2a 86 48 82 f7 12 01 02 02 unknown OID (MS Kerberos bug?) 06 09 2a 86 48 86 f7 12 01 02 02 Kerberos rfc-1964 gssapi 06 0a 2b 06 01 04 01 82 37 02 02 0a Microsoft non-IETF NTLM SSP mechanism It would be incorrect to include a "negotiation" mechanism OID, like the one of SPNEGO itself in that list. However what I'm missing in this list is actually the OID that is used for Microsoft's proprietary user2user extension: 06 0a 2a 86 48 86 f7 12 01 02 02 03 The context tokens which you undocumentedly get when passing the "ISC_REQ_USE_SESSION_KEY" context attribute to InitializeSecurityContext (or which if forced upon you if someone was crazy enough to upgrade his Active Directory to Windows 2003 and switch it to Windows 2003 native mode). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 15:57:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27720; Tue, 23 Nov 2004 15:57:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWhnJ-0003BA-0J; Tue, 23 Nov 2004 16:01:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhBg-0000Ye-Q7; Tue, 23 Nov 2004 15:22:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgwz-0007nm-QS; Tue, 23 Nov 2004 15:07:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17213; Tue, 23 Nov 2004 15:07:43 -0500 (EST) Message-Id: <200411232007.PAA17213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 23 Nov 2004 15:07:43 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-2478bis-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : The Simple and Protected GSS-API Negotiation Mechanism Author(s) : L. Zhu, et al. Filename : draft-ietf-kitten-2478bis-00.txt Pages : 22 Date : 2004-11-23 This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-2478bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-2478bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-2478bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-23142953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-2478bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-2478bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-23142953.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Tue Nov 23 17:34:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14329; Tue, 23 Nov 2004 17:34:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWjId-0001cT-Gq; Tue, 23 Nov 2004 17:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWj8g-0004Ig-FU; Tue, 23 Nov 2004 17:27:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWj27-0002dK-3G for kitten@megatron.ietf.org; Tue, 23 Nov 2004 17:21:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13126 for ; Tue, 23 Nov 2004 17:21:05 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWj5n-0008QX-Ql for kitten@ietf.org; Tue, 23 Nov 2004 17:25:00 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iANMKGHG005405 for ; Wed, 24 Nov 2004 09:20:16 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iANMKGKO005404; Wed, 24 Nov 2004 09:20:16 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411232220.iANMKGKO005404@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: kitten@ietf.org Date: Wed, 24 Nov 2004 09:20:16 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >Folks, I have great news to report: Luke Howard implemented SPNEGO-bis >in Heimdal, and we have the protocol verified independently. Of course, the proof will be in the pudding (when we do some interop testing). >Also "negResult" field need to remain OPTIONAL based on Luke's >experiments. This behaviour may only be necessary for Windows interop. If is optional then the behaviour should be specified. In our implementation the acceptor treats the absence of negResult as equivalent to the initiator sending accept_incomplete. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 19:32:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24942; Tue, 23 Nov 2004 19:32:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWl8i-0000Vj-3g; Tue, 23 Nov 2004 19:36:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWl3x-0000Ty-E9; Tue, 23 Nov 2004 19:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWl22-00082U-6I for kitten@megatron.ietf.org; Tue, 23 Nov 2004 19:29:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24755 for ; Tue, 23 Nov 2004 19:29:10 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWl5m-00006F-4m for kitten@ietf.org; Tue, 23 Nov 2004 19:33:07 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 16:28:30 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 16:28:41 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 23 Nov 2004 16:28:40 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 23 Nov 2004 16:28:40 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2004 16:28:39 -0800 Message-ID: Thread-Topic: Issues in SPNEGO-bis draft 00 Thread-Index: AcTRrKSnzcq//LySRemENEd9gGMjLwADieNw From: "Liqiang\(Larry\) Zhu" To: , X-OriginalArrivalTime: 24 Nov 2004 00:28:40.0301 (UTC) FILETIME=[8BD119D0:01C4D1BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Subject: RE: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable The original email did not get through, so here I sent again. =3D=3D=3D=3D=3D=3D=3D Luke found that it was underspecified what to do if the mechanism has a single mechanism token, to address that, I added the following text: =20 Section 5, c) In the case that the optimistic mechanism token is the only mechanism token for the initiator's preferred mechanism, the mechlistMIC token is OPTIONAL. (IV) In the case that the optimistic mechanism token is also the last mechanism token (when the initiator's preferred mechanism is accepted by the target), and the target sends a request_mic state, the target MUST include a mechlistMIC token in that first reply. GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED. The initiator MUST then verify this mechlistMIC token, and generate a mechlistMIC token to send back to the target, who SHALL in turn verify the returned mechlistMIC token and complete the negotiation. Also "negResult" field need to remain OPTIONAL based on Luke's experiments. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Luke Howard wrote: > In our implementation the acceptor treats the absence of negResult as equivalent to the initiator sending=20 > accept_incomplete. This is reasonable. The case of interest was in handling the third leg of DCE-kerberos, but fortunately the algorithm for that case in the current draft does not rely on the presence of this field. Thus we do not need further change for this. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Luke Howard Sent: Tuesday, November 23, 2004 2:20 PM To: kitten@ietf.org Subject: Re: Issues in SPNEGO-bis draft 00 >Folks, I have great news to report: Luke Howard implemented SPNEGO-bis=20 >in Heimdal, and we have the protocol verified independently. Of course, the proof will be in the pudding (when we do some interop testing). >Also "negResult" field need to remain OPTIONAL based on Luke's=20 >experiments. This behaviour may only be necessary for Windows interop. If is optional then the behaviour should be specified. In our implementation the acceptor treats the absence of negResult as equivalent to the initiator sending accept_incomplete. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 23 20:14:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28025; Tue, 23 Nov 2004 20:14:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWlnZ-0005tQ-C0; Tue, 23 Nov 2004 20:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWlih-0002c6-6a; Tue, 23 Nov 2004 20:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWlhc-0002Cm-Lh for kitten@megatron.ietf.org; Tue, 23 Nov 2004 20:12:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27777 for ; Tue, 23 Nov 2004 20:12:10 -0500 (EST) Received: from stratton-four-o-seven.mit.edu ([18.187.6.152] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWllL-0005Vv-HE for kitten@ietf.org; Tue, 23 Nov 2004 20:16:06 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 41F6CE003B; Tue, 23 Nov 2004 20:12:14 -0500 (EST) To: "Liqiang(Larry) Zhu" References: From: Sam Hartman Date: Tue, 23 Nov 2004 20:12:14 -0500 In-Reply-To: (Liqiang Zhu's message of "Tue, 23 Nov 2004 16:28:39 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: kitten@ietf.org Subject: Re: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea I agree with Larry's proposed change. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 00:21:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15058; Wed, 24 Nov 2004 00:21:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWpeS-00047V-K9; Wed, 24 Nov 2004 00:25:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWpZ0-0006uj-6j; Wed, 24 Nov 2004 00:19:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWpY7-0006RO-5a for kitten@megatron.ietf.org; Wed, 24 Nov 2004 00:18:39 -0500 Received: from brazilnut.cc.columbia.edu (IDENT:cu41754@brazilnut.cc.columbia.edu [128.59.206.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14975 for ; Wed, 24 Nov 2004 00:18:34 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iAO5IbNq009197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Nov 2004 00:18:37 -0500 (EST) Message-ID: <41A419F7.10502@columbia.edu> Date: Wed, 24 Nov 2004 00:19:51 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.18 Content-Transfer-Encoding: 7bit Subject: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Folks, I am back from vacation. There are some open issues which I need to have a resolution to based upon the discussion at IETF61 and the e-mail communication on this list over the last ten days. (1) At IETF61 there was a consensus call in the meeting room asking whether it was more important to maintain backward compatibility then to add new features to the protocol. There was unanimous consensus in the room that backward compatibility was more important. (2) At IETF61 there was a consensus call in the meeting room asking whether or not the use of mechanisms which do not support integrity protection should be prohibited in 2478bis. There was a very strong feeling in the room that these mechanisms should be prohibited. Is this the consensus of the participants of this mailing list? My concerns about adding this prohibition are that it may break backward compatibility for some implementations of 2478 which we are not aware of. As such I believe doing so would be in conflict with (1). (3) At IETF61 there was a consensus call in the meeting room asking whether the use of optimistic tokens will be specified in 2478bis as a "SHOULD" or a "MAY". There was no consensus in the room. Is there consensus on the mailing list? (4) Martin raised the possibility that implementations of SPNEGO outside of the current list participants might be broken by the new SOMIC rules or other changes. In the absence of additional data it is very hard to make a determination as to how great a risk this is. What I am wondering is what we can do to try and track down some of these additional implementations? Martin, do you have any ideas? (5) There was discussion on the list on the subject of whether or not there should be explicit text added to the draft recommending that implementations replace a SPNEGO token with a mech specific token when only one mech is available in the initiator. It seems to me that doing so would improve the security of the protocol as well as improve the performance. I did not see the discussion reach a conclusion one way or the other. Does anyone have some proposed text for this or should it be dropped? (6) There was a discussion on the history of the term "mechanism variants". I would prefer to either see undefined terms be removed from documents or be defined. Martin, could you propose some text to be added to the document which can be used to define the meaning of this term? (7) There was discussion on the list of the "multi-layer negotiation is considered harmful argument" and whether or not text should be added to this document on the subject. Does anyone have some proposed text for this or should it be dropped? I realize that the holidays are fast approaching. It is my hope to be able to get this document to the IESG before the end of the year. To meet that goal I must ask that folks who have been putting off reviewing the document until it becomes stable do so now. The process I would like to follow in this group is that proposed changes to published documents be sent to the mailing list and only be incorporated into the documents by the editor after consensus on the proposed text has been reached on the list. I believe this process will allow us to move documents ahead at a faster pace with more consistent review. Thanks. Jeffrey Altman P.S. - Happy Thanksgiving to all. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 01:02:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18098; Wed, 24 Nov 2004 01:02:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqII-0000z7-JB; Wed, 24 Nov 2004 01:06:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqDy-0008QO-Pw; Wed, 24 Nov 2004 01:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWq7S-0006xP-68 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 00:55:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17154 for ; Wed, 24 Nov 2004 00:55:05 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqBA-0008Hl-EU for kitten@ietf.org; Wed, 24 Nov 2004 00:59:05 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAO5t2Vu016698 for ; Tue, 23 Nov 2004 22:55:02 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAO5t2jW015687 for ; Tue, 23 Nov 2004 22:55:02 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAO5sLSC556556; Tue, 23 Nov 2004 23:54:21 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAO5sJAw556555; Tue, 23 Nov 2004 23:54:19 -0600 (CST) Date: Tue, 23 Nov 2004 23:54:19 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20041124055419.GR556007@binky.central.sun.com> Mail-Followup-To: "Liqiang(Larry) Zhu" , lukeh@padl.com, kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: kitten@ietf.org Subject: Re: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 On Tue, Nov 23, 2004 at 04:28:39PM -0800, Liqiang(Larry) Zhu wrote: > The original email did not get through, so here I sent again. > > ======= > Luke found that it was underspecified what to do if the mechanism has a > single mechanism token, to address that, I added the following text: > > > Section 5, c) > > > In the case that the optimistic > mechanism token is the only mechanism token for the initiator's > preferred mechanism, the mechlistMIC token is OPTIONAL. This seems redundant and confused me earlier. See below. > (IV) In the case that the optimistic mechanism token is also the > last mechanism token (when the initiator's preferred mechanism > is accepted by the target), and the target sends a request_mic > state, the target MUST include a mechlistMIC token in that > first reply. GSS_Accept_sec_context() indicates > GSS_S_CONTINUE_NEEDED. The initiator MUST then verify this > mechlistMIC token, and generate a mechlistMIC token to send > back to the target, who SHALL in turn verify the returned > mechlistMIC token and complete the negotiation. I agree. But it might be better to state that this case is like the other odd-mech-token exchanges, only responseToken is missing from the second and third SPNEGO tokens, if those are required. > Also "negResult" field need to remain OPTIONAL based on Luke's > experiments. Would it be safe to make it DEFAULT to the accept-incomplete value? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 02:00:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21784; Wed, 24 Nov 2004 02:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrCI-0008HL-Vi; Wed, 24 Nov 2004 02:04:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWr0e-0004gi-TY; Wed, 24 Nov 2004 01:52:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqrg-0002cp-ST for kitten@megatron.ietf.org; Wed, 24 Nov 2004 01:42:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20832 for ; Wed, 24 Nov 2004 01:42:55 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqvU-0005xL-1y for kitten@ietf.org; Wed, 24 Nov 2004 01:46:53 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAO6gAV9022188; Wed, 24 Nov 2004 17:42:10 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAO6gA3d022187; Wed, 24 Nov 2004 17:42:10 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411240642.iAO6gA3d022187@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: Nicolas.Williams@sun.com References: <20041124055419.GR556007@binky.central.sun.com> Date: Wed, 24 Nov 2004 17:42:09 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: Re: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >I agree. But it might be better to state that this case is like the >other odd-mech-token exchanges, only responseToken is missing from the >second and third SPNEGO tokens, if those are required. And the server's mechListMIC is sent in the second SPNEGO token rather than the fourth. eg. C: negTokenInit { mechTypes = {foo}; mechToken = {only mech token}} S: negTokenResp { negResult = request_mic; supportedMech = foo; mechListMIC = {MIC}} C: negTokenResp { negResult = accept_completed; mechListMIC = {MIC}} -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 02:01:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22375; Wed, 24 Nov 2004 02:01:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrD2-0008IJ-Mq; Wed, 24 Nov 2004 02:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWr24-00058N-O0; Wed, 24 Nov 2004 01:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqsa-0002qc-HS for kitten@megatron.ietf.org; Wed, 24 Nov 2004 01:43:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20898 for ; Wed, 24 Nov 2004 01:43:50 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqwO-0005yk-Gc for kitten@ietf.org; Wed, 24 Nov 2004 01:47:49 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 22:43:20 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 23 Nov 2004 22:43:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 22:43:19 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 23 Nov 2004 22:43:18 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2004 22:43:18 -0800 Message-ID: Thread-Topic: Issues in SPNEGO-bis draft 00 Thread-Index: AcTR6i2lnTZjKxHFRj23eJydb2XRbgAAXNuQ From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" X-OriginalArrivalTime: 24 Nov 2004 06:43:18.0780 (UTC) FILETIME=[E208CBC0:01C4D1F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > > In the case that the optimistic > > mechanism token is the only mechanism token for the initiator's > > preferred mechanism, the mechlistMIC token is OPTIONAL. > This seems redundant and confused me earlier. See below. This is clear if we see the whole text together: c) In the case that the chosen mechanism uses an odd number of mechanism tokens (namely the initiator sends the last mechanism token), the initiator does the following when emitting the negotiation message containing the last mechanism token: if the negResult state was request_mic in the first reply from the target, a mechlistMIC token MUST be included, otherwise the mechlistMIC token is OPTIONAL. In the case that the optimistic mechanism token is the only mechanism token for the initiator's preferred mechanism, the mechlistMIC token is OPTIONAL. GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED. Initiators who wish to be compatible with legacy Windows SPNEGO implementations as described in Appendix B shall not generate a mechlistMIC token when the MIC token exchange is not required. The acceptor then processes the last mechanism token, and does one of the following: As you can see that the first sentence below is sufficient for describing the "rules":=20 if the negResult state was request_mic in the first reply from the target, a mechlistMIC token MUST be included, otherwise the mechlistMIC token is OPTIONAL. The second sentence as you pointed out is indeed redundent, but was added as clarifications only, it is not "normative". > I agree. But it might be better to state that this case is like the other odd-mech-token exchanges, only >=20 > responseToken is missing from the second and third SPNEGO tokens, if those are required. This case is different only in that the last mechanism token is not accompanied with a mechlistMIC when the MIC token exchange is *required*. Yes, you might be able to deduce this from the rest of rules, but this stanza would make it easier for implementers to interpret the rules. > > Also "negResult" field need to remain OPTIONAL based on Luke's=20 > > experiments. > Would it be safe to make it DEFAULT to the accept-incomplete value? The rules do not rely on the value of this field (except that of the first reply, where this field is required), this is because this field is not protected.=20 I made small adjustments below to make this a bit clearer. 4.2.2 negTokenResp NegTokenResp ::=3D SEQUENCE { negResult [0] ENUMERATED { accept_completed (0), accept_incomplete (1), reject (2), request_mic (3) } OPTIONAL, -- REQUIRED in the first reply from the target supportedMech [1] MechType OPTIONAL, -- present only in the first reply from the target responseToken [2] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL, ... } This is the syntax for all subsequent negotiation messages. negResult This field, if present, contains the state of the negotiation. This can be: accept_completed No further negotiation message from the peer is expected, and the security context is established for the sender. accept_incomplete At least one more negotiation message from the peer is needed to establish the security context. reject The sender terminates the negotiation. request_mic The sender indicates that the exchange of MIC tokens, as described in Section 5, will be REQUIRED if per-message integrity services are available on the mechanism context to be established. This value SHALL only be present in the first reply from the target. Zhu, et al. Expires May 24, 2005 [Page 11] =0C This field is REQUIRED in the first reply from the target, and it is OPTIONAL thereafter. -- larry -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Tuesday, November 23, 2004 9:54 PM To: Liqiang(Larry) Zhu Cc: lukeh@padl.com; kitten@ietf.org Subject: Re: Issues in SPNEGO-bis draft 00 On Tue, Nov 23, 2004 at 04:28:39PM -0800, Liqiang(Larry) Zhu wrote: > The original email did not get through, so here I sent again. >=20 > =3D=3D=3D=3D=3D=3D=3D > Luke found that it was underspecified what to do if the mechanism has=20 > a single mechanism token, to address that, I added the following text: >=20 > =20 > Section 5, c) >=20 >=20 > In the case that the optimistic > mechanism token is the only mechanism token for the initiator's > preferred mechanism, the mechlistMIC token is OPTIONAL. This seems redundant and confused me earlier. See below. > (IV) In the case that the optimistic mechanism token is also the > last mechanism token (when the initiator's preferred mechanism > is accepted by the target), and the target sends a request_mic > state, the target MUST include a mechlistMIC token in that > first reply. GSS_Accept_sec_context() indicates > GSS_S_CONTINUE_NEEDED. The initiator MUST then verify this > mechlistMIC token, and generate a mechlistMIC token to send > back to the target, who SHALL in turn verify the returned > mechlistMIC token and complete the negotiation. I agree. But it might be better to state that this case is like the other odd-mech-token exchanges, only responseToken is missing from the second and third SPNEGO tokens, if those are required. > Also "negResult" field need to remain OPTIONAL based on Luke's=20 > experiments. Would it be safe to make it DEFAULT to the accept-incomplete value? Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 02:09:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29136; Wed, 24 Nov 2004 02:09:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrLa-00010v-Lv; Wed, 24 Nov 2004 02:13:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrGc-0002qe-Ab; Wed, 24 Nov 2004 02:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWr8o-00070i-JV for kitten@megatron.ietf.org; Wed, 24 Nov 2004 02:00:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22020 for ; Wed, 24 Nov 2004 02:00:37 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrCd-0008H7-1C for kitten@ietf.org; Wed, 24 Nov 2004 02:04:35 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 23:00:06 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 23 Nov 2004 23:00:05 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 23 Nov 2004 23:00:04 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 23 Nov 2004 23:00:05 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2004 23:00:05 -0800 Message-ID: Thread-Topic: Open Issues on draft-ietf-kitten-2478bis Thread-Index: AcTR5XSPVNXTI+R7TiqCFMJuHt4XAwAB+W2w From: "Liqiang\(Larry\) Zhu" To: "Jeffrey Altman" , X-OriginalArrivalTime: 24 Nov 2004 07:00:05.0625 (UTC) FILETIME=[3A292690:01C4D1F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Subject: RE: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable =20 Jeff wrote: > Is there consensus on the mailing list? Humm... This sounds a call for the duty of the chair.=20 Folks, if you spoke before, I urge you to speak again. Ken, Sam, Nico, Wyllys, and me preferred "SHOULD", please speak if this is accurate.=20 Love, Luke, please comment, thanks. > Does anyone have some > proposed text for this or should it be dropped? negative. Nico and Sam, you were on the last thread on this subject. > There was a discussion on the history of the term "mechanism > variants". =20 Section 6 actually described what is a "mechanism variant". I agree we can add a forward reference here. 5) and &) seem to be related, if not the same. > proposed changes to published documents be sent to the mailing list=20 I just want to raise an observation that changes in isolation are rather hard to comprehend in general.=20 But in this case this makes sense as we are fairly close to last calling the document. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Jeffrey Altman Sent: Tuesday, November 23, 2004 9:20 PM To: kitten@ietf.org Subject: Open Issues on draft-ietf-kitten-2478bis Folks, I am back from vacation. There are some open issues which I need to have a resolution to based upon the discussion at IETF61 and the e-mail communication on this list over the last ten days. (1) At IETF61 there was a consensus call in the meeting room asking whether it was more important to maintain backward compatibility then to add new features to the protocol. There was unanimous consensus in the room that backward compatibility was more important. (2) At IETF61 there was a consensus call in the meeting room asking whether or not the use of mechanisms which do not support integrity protection should be prohibited in 2478bis. There was a very strong feeling in the room that these mechanisms should be prohibited. Is this the consensus of the participants of this mailing list? My concerns about adding this prohibition are that it may break backward compatibility for some implementations of 2478 which we are not aware of. As such I believe doing so would be in conflict with (1). (3) At IETF61 there was a consensus call in the meeting room asking whether the use of optimistic tokens will be specified in 2478bis as a "SHOULD" or a "MAY". There was no consensus in the room. Is there consensus on the mailing list? (4) Martin raised the possibility that implementations of SPNEGO outside of the current list participants might be broken by the new SOMIC rules or other changes. In the absence of additional data it is very hard to make a determination as to how great a risk this is. What I am wondering is what we can do to try and track down some of these additional implementations? Martin, do you have any ideas? (5) There was discussion on the list on the subject of whether or not there should be explicit text added to the draft recommending that implementations replace a SPNEGO token with a mech specific token when only one mech is available in the initiator. It seems to me that doing so would improve the security of the protocol as well as improve the performance. I did not see the discussion reach a conclusion one way or the other. Does anyone have some proposed text for this or should it be dropped? (6) There was a discussion on the history of the term "mechanism variants". I would prefer to either see undefined terms be removed from documents or be defined. Martin, could you propose some text to be added to the document which can be used to define the meaning of this term? (7) There was discussion on the list of the "multi-layer negotiation is considered harmful argument" and whether or not text should be added to this document on the subject. Does anyone have some proposed text for this or should it be dropped? I realize that the holidays are fast approaching. It is my hope to be able to get this document to the IESG before the end of the year. To meet that goal I must ask that folks who have been putting off reviewing the document until it becomes stable do so now. The process I would like to follow in this group is that proposed changes to published documents be sent to the mailing list and only be incorporated into the documents by the editor after consensus on the proposed text has been reached on the list. I believe this process will allow us to move documents ahead at a faster pace with more consistent review. Thanks. Jeffrey Altman P.S. - Happy Thanksgiving to all. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 02:12:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01347; Wed, 24 Nov 2004 02:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrNz-0001Nd-2G; Wed, 24 Nov 2004 02:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrJ8-00041Z-CJ; Wed, 24 Nov 2004 02:11:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrHo-0003Lw-0k for kitten@megatron.ietf.org; Wed, 24 Nov 2004 02:09:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29176 for ; Wed, 24 Nov 2004 02:09:54 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrLa-000101-Tc for kitten@ietf.org; Wed, 24 Nov 2004 02:13:53 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAO794dI023089; Wed, 24 Nov 2004 18:09:04 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAO794KG023088; Wed, 24 Nov 2004 18:09:04 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411240709.iAO794KG023088@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: jaltman@columbia.edu Date: Wed, 24 Nov 2004 18:09:04 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >(3) At IETF61 there was a consensus call in the meeting room asking > whether the use of optimistic tokens will be specified in 2478bis > as a "SHOULD" or a "MAY". There was no consensus in the room. > Is there consensus on the mailing list? We would prefer SHOULD. Indeed, Heimdal right now requires the optimistic token (and this is unlikely to be fixed until it gets mechglue). >P.S. - Happy Thanksgiving to all. You too. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 11:39:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08849; Wed, 24 Nov 2004 11:39:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX0Ev-0004qM-KN; Wed, 24 Nov 2004 11:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX07I-0004jB-4Q; Wed, 24 Nov 2004 11:35:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX01X-0003ID-EH for kitten@megatron.ietf.org; Wed, 24 Nov 2004 11:29:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08081 for ; Wed, 24 Nov 2004 11:29:40 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX05Q-0003uQ-2E for kitten@ietf.org; Wed, 24 Nov 2004 11:33:45 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAOGTepv011196 for ; Wed, 24 Nov 2004 08:29:40 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAOGTdJh025653 for ; Wed, 24 Nov 2004 09:29:40 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAOGSv0h556782; Wed, 24 Nov 2004 10:28:57 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAOGSutV556781; Wed, 24 Nov 2004 10:28:56 -0600 (CST) Date: Wed, 24 Nov 2004 10:28:56 -0600 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20041124162855.GV556007@binky.central.sun.com> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <41A419F7.10502@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A419F7.10502@columbia.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: (4) Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Wed, Nov 24, 2004 at 12:19:51AM -0500, Jeffrey Altman wrote: > (4) Martin raised the possibility that implementations of SPNEGO outside > of the current list participants might be broken by the new SOMIC > rules or other changes. In the absence of additional data it is > very hard to make a determination as to how great a risk this is. > What I am wondering is what we can do to try and track down some > of these additional implementations? Martin, do you have any > ideas? This is very important. I suspect that currently any implementations that are faithful, modulo spec ambiguities, to rfc2478 wouldn't interop with MS's implementation -- or Sun's when in MS interop mode (which is the default). Further, I suspect that such implementations aren't being used with Windows peers as otherwise Larry surely would be aware of such implementations. Just because we have disjoint sets of implementations doesn't mean we shouldn't consider interop between them, but I fear that the worst case scenario will bring us back to flag days and out-of-band configuration mechanisms. It would be good to hear from Martin about how the implementations he's aware of handle the "mechListMIC request" in Larry's proposal. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 12:51:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15762; Wed, 24 Nov 2004 12:51:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1N2-0001P9-AL; Wed, 24 Nov 2004 12:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX19z-0006kW-9P; Wed, 24 Nov 2004 12:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX16j-0005UM-1S for kitten@megatron.ietf.org; Wed, 24 Nov 2004 12:39:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14744 for ; Wed, 24 Nov 2004 12:39:06 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1Ad-0000yf-EP for kitten@ietf.org; Wed, 24 Nov 2004 12:43:11 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 09:38:30 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 09:38:36 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 09:38:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 09:38:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 09:38:35 -0800 Message-ID: Thread-Topic: SPNEGO SOMIC rules thread-index: AcTM8eMLipUkEccwThurQiYQ5q7UIwFWSvzA From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" , "Sam Hartman" X-OriginalArrivalTime: 24 Nov 2004 17:38:35.0897 (UTC) FILETIME=[6CDCBE90:01C4D24C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote: > I wonder if SPNEGO needs to pick up a copy of the standard=20 > multi-layer-negotiation considered harmful argument? I wonder if=20 > we're getting to a point where we need a single version of that=20 > document to reference. nothing from here so far, but here are my thoughts: If the SPNEGO target accepts a single mechanism token without the SPNEGO framing, it will prevent the acceptor from demanding the mechlistMIC. Using a two-token mechanism A in the following example, the initiator supports mechanism A, and the acceptor supports mechanism A and mechanism B, but prefers B if offered. The initiator sends negTokenInit with an optimistic token of A, the attacker strips out the optimistic token and sends it to the acceptor; the acceptor processes this optimistic token and sends a response token of A and returns complete; the attacker then puts the response token of A into negTokenResp with an accept_complete state. An attack was successfully just launched. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Nicolas Williams Sent: Wednesday, November 17, 2004 1:27 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote: > I wonder if SPNEGO needs to pick up a copy of the standard=20 > multi-layer-negotiation considered harmful argument? I wonder if=20 > we're getting to a point where we need a single version of that=20 > document to reference. Yes, yes. >=20 > (I bring up this comment because Martin's discussion of GSSAPI=20 > variants reminds me that doing stuff like that at the SPNEGO layer is=20 > the only safe way to do it in a case where you have the SPNEGO layer=20 > at all. Probably not so true for crypto algorithms, but true for=20 > anything that can influence the choice of mechanism.) "only" is a bit strong, but I digress :) Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 13:17:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17529; Wed, 24 Nov 2004 13:17:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1lR-0002IS-7N; Wed, 24 Nov 2004 13:21:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1XE-0004Qp-9T; Wed, 24 Nov 2004 13:06:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX1QK-0002a7-29 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 12:59:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16280 for ; Wed, 24 Nov 2004 12:59:20 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX1UD-0001io-K6 for kitten@ietf.org; Wed, 24 Nov 2004 13:03:27 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 09:58:51 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 09:58:01 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 09:58:46 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 09:58:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 09:58:44 -0800 Message-ID: Thread-Topic: SPNEGO SOMIC rules thread-index: AcTM8eMLipUkEccwThurQiYQ5q7UIwFWSvzAAAD0k9A= From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" , X-OriginalArrivalTime: 24 Nov 2004 17:58:45.0835 (UTC) FILETIME=[3E0AA1B0:01C4D24F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable =20 Note that although the attack via the single-mech-token below is valid, it is harmful only when the initiator supports both A and B but prefers A. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Liqiang(Larry) Zhu Sent: Wednesday, November 24, 2004 9:39 AM To: Nicolas Williams; Sam Hartman Cc: kitten@ietf.org Subject: RE: SPNEGO SOMIC rules On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote: > I wonder if SPNEGO needs to pick up a copy of the standard=20 > multi-layer-negotiation considered harmful argument? I wonder if=20 > we're getting to a point where we need a single version of that=20 > document to reference. nothing from here so far, but here are my thoughts: If the SPNEGO target accepts a single mechanism token without the SPNEGO framing, it will prevent the acceptor from demanding the mechlistMIC. Using a two-token mechanism A in the following example, the initiator supports mechanism A, and the acceptor supports mechanism A and mechanism B, but prefers B if offered. The initiator sends negTokenInit with an optimistic token of A, the attacker strips out the optimistic token and sends it to the acceptor; the acceptor processes this optimistic token and sends a response token of A and returns complete; the attacker then puts the response token of A into negTokenResp with an accept_complete state. An attack was successfully just launched. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Nicolas Williams Sent: Wednesday, November 17, 2004 1:27 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: SPNEGO SOMIC rules On Wed, Nov 17, 2004 at 01:37:48PM -0500, Sam Hartman wrote: > I wonder if SPNEGO needs to pick up a copy of the standard=20 > multi-layer-negotiation considered harmful argument? I wonder if=20 > we're getting to a point where we need a single version of that=20 > document to reference. Yes, yes. >=20 > (I bring up this comment because Martin's discussion of GSSAPI=20 > variants reminds me that doing stuff like that at the SPNEGO layer is=20 > the only safe way to do it in a case where you have the SPNEGO layer=20 > at all. Probably not so true for crypto algorithms, but true for=20 > anything that can influence the choice of mechanism.) "only" is a bit strong, but I digress :) Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 14:49:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23164; Wed, 24 Nov 2004 14:49:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3CT-0004SC-7E; Wed, 24 Nov 2004 14:53:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX33x-0001ER-S5; Wed, 24 Nov 2004 14:44:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX2ys-000063-04 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 14:39:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22653 for ; Wed, 24 Nov 2004 14:39:08 -0500 (EST) Received: from luminous.mit.edu ([18.101.1.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX32m-0004Fe-E6 for kitten@ietf.org; Wed, 24 Nov 2004 14:43:13 -0500 Received: by luminous.mit.edu (Postfix, from userid 1000) id 6AD0876BBB; Wed, 24 Nov 2004 14:38:05 -0500 (EST) To: Jeffrey Altman References: <41A419F7.10502@columbia.edu> From: Sam Hartman Date: Wed, 24 Nov 2004 14:38:05 -0500 In-Reply-To: <41A419F7.10502@columbia.edu> (Jeffrey Altman's message of "Wed, 24 Nov 2004 00:19:51 -0500") Message-ID: <871xej3un6.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> (3) At IETF61 there was a consensus call in the meeting Jeffrey> room asking whether the use of optimistic tokens will be Jeffrey> specified in 2478bis as a "SHOULD" or a "MAY". There was Jeffrey> no consensus in the room. Is there consensus on the Jeffrey> mailing list? Interesting. Who in the meeting spoke in favor of may not should. I favor should. Martin has given a good explanation for why we need should not must. Ken also gave some arguments for should. So far I have seen no justification that successfully explained why should isn't good enough. Jeffrey> (4) Martin raised the possibility that implementations of Jeffrey> SPNEGO outside of the current list participants might be Jeffrey> broken by the new SOMIC rules or other changes. In the Jeffrey> absence of additional data it is very hard to make a Jeffrey> determination as to how great a risk this is. What I am Jeffrey> wondering is what we can do to try and track down some of Jeffrey> these additional implementations? Martin, do you have Jeffrey> any ideas? Given the confusion about encoding of the MIC in 2478, I don't think it all that likely we have interoperable implementations of that spec at all. Jeffrey> (5) There was discussion on the list on the subject of Jeffrey> whether or not there should be explicit text added to the Jeffrey> draft recommending that implementations replace a SPNEGO Jeffrey> token with a mech specific token when only one mech is Jeffrey> available in the initiator. It seems to me that doing so Jeffrey> would improve the security of the protocol as well as Jeffrey> improve the performance. I did not see the discussion Jeffrey> reach a conclusion one way or the other. Does anyone Jeffrey> have some proposed text for this or should it be dropped? I think it should be dropped. I don't see how it improves security. Jeffrey> (6) There was a discussion on the history of the term Jeffrey> "mechanism variants". I would prefer to either see Jeffrey> undefined terms be removed from documents or be defined. Jeffrey> Martin, could you propose some text to be added to the Jeffrey> document which can be used to define the meaning of this Jeffrey> term? This sounds like a big rathole to me. I'd rather manage to avoid this discussion somehow. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 14:54:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23635; Wed, 24 Nov 2004 14:54:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3HM-0004a9-Dp; Wed, 24 Nov 2004 14:58:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX392-0002md-Mo; Wed, 24 Nov 2004 14:49:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX33z-0001Eq-8i for kitten@megatron.ietf.org; Wed, 24 Nov 2004 14:44:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22883 for ; Wed, 24 Nov 2004 14:44:25 -0500 (EST) Received: from pecan.cc.columbia.edu ([128.59.206.21] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX37u-0004LN-Q2 for kitten@ietf.org; Wed, 24 Nov 2004 14:48:31 -0500 Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id iAOJiPAQ001618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Nov 2004 14:44:25 -0500 (EST) Message-ID: <41A4E4F2.5030307@columbia.edu> Date: Wed, 24 Nov 2004 14:45:54 -0500 From: Jeffrey Altman Organization: Mass User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <41A419F7.10502@columbia.edu> <871xej3un6.fsf@luminous.mit.edu> In-Reply-To: <871xej3un6.fsf@luminous.mit.edu> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.21 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Sam Hartman wrote: >>>>>>"Jeffrey" == Jeffrey Altman writes: > > > Jeffrey> (3) At IETF61 there was a consensus call in the meeting > Jeffrey> room asking whether the use of optimistic tokens will be > Jeffrey> specified in 2478bis as a "SHOULD" or a "MAY". There was > Jeffrey> no consensus in the room. Is there consensus on the > Jeffrey> mailing list? > > Interesting. Who in the meeting spoke in favor of may not should. > > I favor should. Martin has given a good explanation for why we need > should not must. Ken also gave some arguments for should. So far I > have seen no justification that successfully explained why should > isn't good enough. In the meeting when I asked the question no one offered an opinion one way or another. Therefore, I feel obliged to ask the question on the list. I agree that the consensus appears to be "SHOULD". If there are objections I want to hear them. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 15:04:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24462; Wed, 24 Nov 2004 15:04:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3RU-0004qM-52; Wed, 24 Nov 2004 15:08:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3HP-0005IF-OG; Wed, 24 Nov 2004 14:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3FN-0004ia-Ll for kitten@megatron.ietf.org; Wed, 24 Nov 2004 14:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23812 for ; Wed, 24 Nov 2004 14:56:11 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3JI-0004dc-A8 for kitten@ietf.org; Wed, 24 Nov 2004 15:00:17 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAOJuA6O024063 for ; Wed, 24 Nov 2004 11:56:11 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAOJu9Jh025093 for ; Wed, 24 Nov 2004 12:56:10 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAOJtSVB557306; Wed, 24 Nov 2004 13:55:28 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAOJtNOu557305; Wed, 24 Nov 2004 13:55:23 -0600 (CST) Date: Wed, 24 Nov 2004 13:55:22 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20041124195522.GH556007@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Jeffrey Altman , kitten@ietf.org References: <41A419F7.10502@columbia.edu> <871xej3un6.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871xej3un6.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 I agree with all of Sam's comments, but I think we may have to do a bit more work to see that (4) is not an issue -- though even if it is, I don't see what we can do about it other than require configurable support for one way or the other. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 16:45:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06981; Wed, 24 Nov 2004 16:45:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX51B-0007Vy-SZ; Wed, 24 Nov 2004 16:49:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4w6-0004U1-Ni; Wed, 24 Nov 2004 16:44:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4qJ-0002yk-Dx for kitten@megatron.ietf.org; Wed, 24 Nov 2004 16:38:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06513 for ; Wed, 24 Nov 2004 16:38:24 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4uF-0007N5-Rt for kitten@ietf.org; Wed, 24 Nov 2004 16:42:32 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 13:37:42 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 13:37:54 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 13:37:56 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 13:37:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 13:37:53 -0800 Message-ID: Thread-Topic: Issues in SPNEGO-bis draft 00 thread-index: AcTSbJhfm7Os1vhvT3y4sFD5p3ZZpwAAFQug From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 24 Nov 2004 21:37:54.0220 (UTC) FILETIME=[DB16F6C0:01C4D26D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > The following description extends a single-token security context establishment into a 3-token security context=20 > establishment. Have you noticed that the protocol can end up with two negotiation messages/tokens in the following two ways? 1) The initiator includes a mechlistMIC token in the first message. 2) The acceptor omits the mic_token exchange because it is safe to do so. You can avoid the third token if you do one of the above, but this protocol allows having at most 3 tokens in the worst scenario (not in the above two cases). By the way, the vanilla 2478 allows 4 tokens for the above single mechanism token case (2 tokens for negotiation, then one for the mechanism token, another for the mechlistMIC), right? -- Larry -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Wednesday, November 24, 2004 1:29 PM To: Liqiang(Larry) Zhu Cc: lukeh@padl.com; kitten@ietf.org Subject: Re: Issues in SPNEGO-bis draft 00 I'm sorry for replying before having read Larry newest draft: The following sounds incompatibly strange to me: rfc2478 did extend a security context establishment by at most one token if the optimistic token was used and was accepted by the acceptor. The following description extends a single-token security context establishment into a 3-token security context establishment, which is a significant change from rfc2478 and incurs an additional round-trip, something that rfc2478 tried to avoid. -Martin Liqiang\ wrote: >=20 > In the case that the optimistic > mechanism token is the only mechanism token for the initiator's > preferred mechanism, the mechlistMIC token is OPTIONAL. >=20 > (IV) In the case that the optimistic mechanism token is also the > last mechanism token (when the initiator's preferred mechanism > is accepted by the target), and the target sends a request_mic > state, the target MUST include a mechlistMIC token in that > first reply. GSS_Accept_sec_context() indicates > GSS_S_CONTINUE_NEEDED. The initiator MUST then verify this > mechlistMIC token, and generate a mechlistMIC token to send > back to the target, who SHALL in turn verify the returned > mechlistMIC token and complete the negotiation. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 17:18:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08843; Wed, 24 Nov 2004 17:18:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5Wu-00088M-Om; Wed, 24 Nov 2004 17:22:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5Rp-0002iG-9F; Wed, 24 Nov 2004 17:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5RX-0002Xa-B5 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 17:16:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08759 for ; Wed, 24 Nov 2004 17:16:51 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5VR-00085A-5N for kitten@ietf.org; Wed, 24 Nov 2004 17:20:59 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAOMG4KN061287; Thu, 25 Nov 2004 09:16:04 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAOMG4IX061286; Thu, 25 Nov 2004 09:16:04 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411242216.iAOMG4IX061286@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lzhu@windows.microsoft.com Date: Thu, 25 Nov 2004 09:16:04 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org Subject: RE: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >Have you noticed that the protocol can end up with two negotiation >messages/tokens in the following two ways? > >1) The initiator includes a mechlistMIC token in the first message. >2) The acceptor omits the mic_token exchange because it is safe to do >so. Martin argues that in 2) the server should not send back a response. I haven't looked at RFC 2478 closely, but it seems to me that even in in this case case the server should send back a NegTokenResp with the negResult (accept_completed) and supportedMech elements. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 17:37:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11037; Wed, 24 Nov 2004 17:37:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5pj-0000AR-Tn; Wed, 24 Nov 2004 17:41:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5kS-0006Gk-Pr; Wed, 24 Nov 2004 17:36:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5gN-0005eq-E9 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 17:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10717 for ; Wed, 24 Nov 2004 17:32:12 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5kK-0008V4-08 for kitten@ietf.org; Wed, 24 Nov 2004 17:36:20 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA01056; Wed, 24 Nov 2004 23:31:26 +0100 (MEZ) From: Martin Rex Message-Id: <200411242231.XAA15663@uw1048.wdf.sap.corp> To: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 24 Nov 2004 23:31:26 +0100 (MET) In-Reply-To: <41A419F7.10502@columbia.edu> from "Jeffrey Altman" at Nov 24, 4 00:19:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 8bit Jeffrey Altman wrote: > > (1) At IETF61 there was a consensus call in the meeting room asking > whether it was more important to maintain backward compatibility > then to add new features to the protocol. There was unanimous > consensus in the room that backward compatibility was more > important. Now I'm a little confused. The new document contains a few clearly backwards incompatible changes, and some of them are neither necessary nor sensible. Reading the current document and following the discussion I get the impression that we're heading to standardize Microsoft's defective installed based and create a significantly more complex and backward incompatible standard. Personally, I would appreciate if we kept the original standard, added clarifications where necessary, and as an appendix listed a few protocol-violating changes if one intends to interoperate with Microsofts broken implementation and the security implications of not requiring or not sending the mechListMIC token in those scenarios. > > (2) At IETF61 there was a consensus call in the meeting room asking > whether or not the use of mechanisms which do not support integrity > protection should be prohibited in 2478bis. There was a very > strong feeling in the room that these mechanisms should be > prohibited. Is this the consensus of the participants of > this mailing list? > > My concerns about adding this prohibition are that it may break > backward compatibility for some implementations of 2478 which > we are not aware of. As such I believe doing so would be in > conflict with (1). Not only does it break backwards compatibility, it artificially limits SPNEGO to a subset of mechanisms allowed by GSS-API v2 (rfc2743/44), and is therefore the entirely wrong place for such a limitation. If GSS-API doesn't prohibit mechanisms that lack integrity, then SPNEGO should do it either. I would agree to a SHOULD NOT include gssapi mechanisms lacking integrity protection, but I will NOT agree to MUST NOT. > > (3) At IETF61 there was a consensus call in the meeting room asking > whether the use of optimistic tokens will be specified in 2478bis > as a "SHOULD" or a "MAY". There was no consensus in the room. > Is there consensus on the mailing list? NOPE! It is NOT necessary to change the MAY, it will not improve interoperability in any way, and the MAY will not discourage anyone from implementing it (for anyone with common sense implementing SPNEGO -- and for those who don't understand the possible benefit, the MAY should make it easier to idenify implementations that we should avoid ... :) But what I really dislike is the suprising "MUST process" of the optimistic token for the acceptor -- while rfc2478 said MAY ignore. This is is entirely against IETF conventions of rev'ing standard track protocol specs, a SHOULD process is the only sensible (and the only backwards compatible) change we could do here. > > (4) Martin raised the possibility that implementations of SPNEGO outside > of the current list participants might be broken by the new SOMIC > rules or other changes. In the absence of additional data it is > very hard to make a determination as to how great a risk this is. > What I am wondering is what we can do to try and track down some > of these additional implementations? Martin, do you have any > ideas? Sorry, I don't. I don't know whether Denis Pinkas or Eric Baize (listed as authors on the original SPNEGO document) still work for Bull and one SESAME issues and can provide feedback on the evolution of their former SNEGO implementation on which the SPNEGO spec was founded. I was surprized how many independent (mostly proprietary) implementations of gssapi mechanism exist. I got to know then only because the vendors asked for interoperability certification of their product with our application. I don't know how many of them (if any) are or have ever participated in IETF activities. Here's a quick list of companies: ietf mechanism: Company (Country) Kerberos 5 MIT, CyberSafe, CA/Platinum, Microsoft, heimdal SPKM Entrust (CA), Shym (US), Baltimore (US) proprietary mechanisms: AM-DCE Bull (FR) (propr.) Sagem (FR) sdti,rsakeon,trustnet TFS-Tech (SE) former RSA/SDTI safelayer Safelayer (SP) NEC Secureware NEC (JP) itsec UBS/ITsec (CH) Adnovum GSSv2 UBS/Adnovum (CH) ISign/secui Penta Security Systems (South Korea) Sisler Siemens India (India) cpro Mecomp (RU) lissi Lissi (RU) kobil Kobil GmbH (DE) T-Secure secunet/Telekom (DE) how many do you recognize? > > (5) There was discussion on the list on the subject of whether or > not there should be explicit text added to the draft recommending > that implementations replace a SPNEGO token with a mech specific > token when only one mech is available in the initiator. It seems > to me that doing so would improve the security of the protocol > as well as improve the performance. I did not see the discussion > reach a conclusion one way or the other. Does anyone have some > proposed text for this or should it be dropped? In addition, the explicit requirement for an SPNEGO acceptor to dispatch an initial non-SPNEGO security context token correctly to the corresponding mechanism (if available) should be added, because the existing implicit requirement seems not to be obvious for everyone. > > (6) There was a discussion on the history of the term "mechanism > variants". I would prefer to either see undefined terms be removed > from documents or be defined. Martin, could you propose some text > to be added to the document which can be used to define the meaning > of this term? I can only come up with "hear-say" and the text from the originally circulated SNEGO proposal from Denis Pinkas and Eric Baize. But that really isn't a lot. Most of the variants issue was discussed in person, maybe even in break or hallway discussion that did not get captured in any minutes. -Martin PS: Lacking time, I still have only glanced through the document. It's 11:30pm here now, and I gotta go home. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 17:58:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12375; Wed, 24 Nov 2004 17:58:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX69R-0000af-SX; Wed, 24 Nov 2004 18:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX64j-00024W-DP; Wed, 24 Nov 2004 17:57:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX62x-0001oN-KJ for kitten@megatron.ietf.org; Wed, 24 Nov 2004 17:55:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12159 for ; Wed, 24 Nov 2004 17:55:32 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX66t-0000Up-Rj for kitten@ietf.org; Wed, 24 Nov 2004 17:59:41 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA01481; Wed, 24 Nov 2004 23:54:46 +0100 (MEZ) From: Martin Rex Message-Id: <200411242254.XAA15902@uw1048.wdf.sap.corp> To: lukeh@padl.com Date: Wed, 24 Nov 2004 23:54:45 +0100 (MET) In-Reply-To: <200411240709.iAO794KG023088@au.padl.com> from "Luke Howard" at Nov 24, 4 06:09:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Luke Howard wrote: > > >(3) At IETF61 there was a consensus call in the meeting room asking > > whether the use of optimistic tokens will be specified in 2478bis > > as a "SHOULD" or a "MAY". There was no consensus in the room. > > Is there consensus on the mailing list? > > We would prefer SHOULD. Indeed, Heimdal right now requires the > optimistic token (and this is unlikely to be fixed until it gets > mechglue). I'm a little surprized? Do you mean that your SPNEGO acceptor will break if it receives an initial SPNEGO token without an optimistic context token? That this token was optional was quite obvious from the rfc2478 spec, and that spec is so short that it is hard to misread or misinterpret this part. Now if implementors get that part of rfc2478 wrong, then I don't have any hope that implementors get the current rfc2478bis right, because it is a least a magnitude more complex. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:08:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13587; Wed, 24 Nov 2004 18:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6JI-0000oy-PK; Wed, 24 Nov 2004 18:12:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6EV-0007Oi-AD; Wed, 24 Nov 2004 18:07:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6BJ-0006ET-Oo for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:04:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12952 for ; Wed, 24 Nov 2004 18:04:10 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6FF-0000hl-5K for kitten@ietf.org; Wed, 24 Nov 2004 18:08:19 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAON3O1a063651; Thu, 25 Nov 2004 10:03:24 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAON3NuT063648; Thu, 25 Nov 2004 10:03:23 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411242303.iAON3NuT063648@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: martin.rex@sap.com Date: Thu, 25 Nov 2004 10:03:23 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >> We would prefer SHOULD. Indeed, Heimdal right now requires the >> optimistic token (and this is unlikely to be fixed until it gets >> mechglue). > >I'm a little surprized? Do you mean that your SPNEGO acceptor will >break if it receives an initial SPNEGO token without an optimistic >context token? Yes. I agree it's wrong, and it needs to be fixed, but it's a little difficult due to the way SPNEGO is implemented in Heimdal. Fixing it is on my todo list (see related discussion on heimdal-discuss). -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:23:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15289; Wed, 24 Nov 2004 18:23:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6Xc-000187-C4; Wed, 24 Nov 2004 18:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6Sd-00069C-Ne; Wed, 24 Nov 2004 18:22:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6Rc-0005FV-D6 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:21:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15104 for ; Wed, 24 Nov 2004 18:21:00 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6VY-00015K-1I for kitten@ietf.org; Wed, 24 Nov 2004 18:25:09 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAONL0un003664 for ; Wed, 24 Nov 2004 16:21:00 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAONKxjY020984 for ; Wed, 24 Nov 2004 16:21:00 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAONKHna557579; Wed, 24 Nov 2004 17:20:17 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAONKG63557578; Wed, 24 Nov 2004 17:20:16 -0600 (CST) Date: Wed, 24 Nov 2004 17:20:16 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20041124232016.GO556007@binky.central.sun.com> Mail-Followup-To: Martin Rex , Jeffrey Altman , kitten@ietf.org References: <41A419F7.10502@columbia.edu> <200411242231.XAA15663@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411242231.XAA15663@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba On Wed, Nov 24, 2004 at 11:31:26PM +0100, Martin Rex wrote: > Jeffrey Altman wrote: > > > > (1) At IETF61 there was a consensus call in the meeting room asking > > whether it was more important to maintain backward compatibility > > then to add new features to the protocol. There was unanimous > > consensus in the room that backward compatibility was more > > important. > > Now I'm a little confused. The new document contains a few clearly > backwards incompatible changes, and some of them are neither necessary > nor sensible. > > Reading the current document and following the discussion I get the > impression that we're heading to standardize Microsoft's defective > installed based and create a significantly more complex and backward > incompatible standard. Well, that's the thing, we have at least one implementation, MS', that is widely deployed and not faithful to rfc2478, broken in a particular way such that recovering from it will require flag days or sacrifice of some degree of interop. If there are other widely deployed implementations we need to hear about them and figure out what we can do, if anything, to recover from this. > Personally, I would appreciate if we kept the original standard, > added clarifications where necessary, and as an appendix listed > a few protocol-violating changes if one intends to interoperate > with Microsofts broken implementation and the security implications > of not requiring or not sending the mechListMIC token in those > scenarios. This is worth considering, and if we do this we ought to have a requirement for a configuration knob for selecting which behaviour to use. > > (2) At IETF61 there was a consensus call in the meeting room asking > > whether or not the use of mechanisms which do not support integrity > > protection should be prohibited in 2478bis. There was a very > > strong feeling in the room that these mechanisms should be > > prohibited. Is this the consensus of the participants of > > this mailing list? > > > > My concerns about adding this prohibition are that it may break > > backward compatibility for some implementations of 2478 which > > we are not aware of. As such I believe doing so would be in > > conflict with (1). > > Not only does it break backwards compatibility, it artificially limits > SPNEGO to a subset of mechanisms allowed by GSS-API v2 (rfc2743/44), > and is therefore the entirely wrong place for such a limitation. > > If GSS-API doesn't prohibit mechanisms that lack integrity, then > SPNEGO should do it either. I would agree to a SHOULD NOT include > gssapi mechanisms lacking integrity protection, but I will NOT agree > to MUST NOT. SHOULD NOT is fine by me. > > > > (3) At IETF61 there was a consensus call in the meeting room asking > > whether the use of optimistic tokens will be specified in 2478bis > > as a "SHOULD" or a "MAY". There was no consensus in the room. > > Is there consensus on the mailing list? > > NOPE! > > It is NOT necessary to change the MAY, it will not improve interoperability > in any way, and the MAY will not discourage anyone from implementing it > (for anyone with common sense implementing SPNEGO -- and for those who > don't understand the possible benefit, the MAY should make it easier > to idenify implementations that we should avoid ... :) I don't care if it's MAY or SHOULD, but do see Love's note about Heimdal's implementation -- evidently saying 'SHOULD' would help interop with Heimdal. > But what I really dislike is the suprising "MUST process" of the > optimistic token for the acceptor -- while rfc2478 said MAY ignore. If the acceptor selects that mechanism then it should be MUST process -- how is the initiator to know that the acceptor didn't process its optimistic token even though it accepted that mechanism? > > (4) Martin raised the possibility that implementations of SPNEGO outside > > of the current list participants might be broken by the new SOMIC > > rules or other changes. In the absence of additional data it is > > very hard to make a determination as to how great a risk this is. > > What I am wondering is what we can do to try and track down some > > of these additional implementations? Martin, do you have any > > ideas? > > Sorry, I don't. > > I don't know whether Denis Pinkas or Eric Baize (listed as authors on > the original SPNEGO document) still work for Bull and one SESAME issues > and can provide feedback on the evolution of their former SNEGO implementation > on which the SPNEGO spec was founded. > > I was surprized how many independent (mostly proprietary) implementations > of gssapi mechanism exist. I got to know then only because the vendors > asked for interoperability certification of their product with our > application. I don't know how many of them (if any) are or have > ever participated in IETF activities. Here's a quick list of companies: > > ietf mechanism: Company (Country) > > Kerberos 5 MIT, CyberSafe, CA/Platinum, Microsoft, heimdal > SPKM Entrust (CA), Shym (US), Baltimore (US) > > proprietary mechanisms: > > AM-DCE Bull (FR) > (propr.) Sagem (FR) > sdti,rsakeon,trustnet TFS-Tech (SE) former RSA/SDTI > safelayer Safelayer (SP) > NEC Secureware NEC (JP) > itsec UBS/ITsec (CH) > Adnovum GSSv2 UBS/Adnovum (CH) > ISign/secui Penta Security Systems (South Korea) > Sisler Siemens India (India) > cpro Mecomp (RU) > lissi Lissi (RU) > kobil Kobil GmbH (DE) > T-Secure secunet/Telekom (DE) > > how many do you recognize? None, and I worked for a subsidiary of one of those companies :/ That list is surprisingly -- and satisfyingly -- long. > > > > (5) There was discussion on the list on the subject of whether or > > not there should be explicit text added to the draft recommending > > that implementations replace a SPNEGO token with a mech specific > > token when only one mech is available in the initiator. It seems > > to me that doing so would improve the security of the protocol > > as well as improve the performance. I did not see the discussion > > reach a conclusion one way or the other. Does anyone have some > > proposed text for this or should it be dropped? > > In addition, > the explicit requirement for an SPNEGO acceptor to dispatch an > initial non-SPNEGO security context token correctly to the > corresponding mechanism (if available) should be added, because the > existing implicit requirement seems not to be obvious for everyone. I'm not sure I follow (5). But the acceptor should reply with a token for the mechanism named in the initiator's initial token's frame, which would be SPNEGO if the initiator used SPNEGO. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:26:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15563; Wed, 24 Nov 2004 18:26:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6aa-0001Cs-UW; Wed, 24 Nov 2004 18:30:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6Vl-0006pg-Hf; Wed, 24 Nov 2004 18:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6Tm-0006WL-J7 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:23:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15332 for ; Wed, 24 Nov 2004 18:23:15 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6XZ-00017Y-I5 for kitten@ietf.org; Wed, 24 Nov 2004 18:27:23 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA16646; Thu, 25 Nov 2004 00:22:32 +0100 (MEZ) From: Martin Rex Message-Id: <200411242322.AAA16120@uw1048.wdf.sap.corp> To: hartmans@mit.edu (Sam Hartman) Date: Thu, 25 Nov 2004 00:22:32 +0100 (MET) In-Reply-To: <871xej3un6.fsf@luminous.mit.edu> from "Sam Hartman" at Nov 24, 4 02:38:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > Jeffrey> (5) There was discussion on the list on the subject of > Jeffrey> whether or not there should be explicit text added to the > Jeffrey> draft recommending that implementations replace a SPNEGO > Jeffrey> token with a mech specific token when only one mech is > Jeffrey> available in the initiator. It seems to me that doing so > Jeffrey> would improve the security of the protocol as well as > Jeffrey> improve the performance. I did not see the discussion > Jeffrey> reach a conclusion one way or the other. Does anyone > Jeffrey> have some proposed text for this or should it be dropped? > > I think it should be dropped. I don't see how it improves security. I do not think it improves security either. That was only to improve interoperability with gssapi mechanisms that don't have an accompanying SPNEGO. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:31:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16220; Wed, 24 Nov 2004 18:31:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6fR-0001JD-St; Wed, 24 Nov 2004 18:35:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6ZZ-0007Qs-7B; Wed, 24 Nov 2004 18:29:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6Z2-0007Gd-A5 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:28:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16005 for ; Wed, 24 Nov 2004 18:28:41 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6cy-0001Fu-NJ for kitten@ietf.org; Wed, 24 Nov 2004 18:32:50 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id iAONRtQZ064742; Thu, 25 Nov 2004 10:27:55 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id iAONRt6p064741; Thu, 25 Nov 2004 10:27:55 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200411242327.iAONRt6p064741@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: Nicolas.Williams@sun.com References: <41A419F7.10502@columbia.edu> <200411242231.XAA15663@uw1048.wdf.sap.corp> <20041124232016.GO556007@binky.central.sun.com> Date: Thu, 25 Nov 2004 10:27:55 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >> It is NOT necessary to change the MAY, it will not improve interoperability >> in any way, and the MAY will not discourage anyone from implementing it >> (for anyone with common sense implementing SPNEGO -- and for those who >> don't understand the possible benefit, the MAY should make it easier >> to idenify implementations that we should avoid ... :) > >I don't care if it's MAY or SHOULD, but do see Love's note about >Heimdal's implementation -- evidently saying 'SHOULD' would help interop >with Heimdal. Taking my implementor's hat off, I don't think the specification should be relaxed just because one implementation isn't fixed, particularly if it is not widely deployed (correct me if I'm wrong but I don't know too many people using Heimdal's SPNEGO). -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:33:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16455; Wed, 24 Nov 2004 18:33:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6hM-0001MT-2v; Wed, 24 Nov 2004 18:37:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6cb-00082r-8G; Wed, 24 Nov 2004 18:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6c8-0007tL-Kx for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:31:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16308 for ; Wed, 24 Nov 2004 18:31:53 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6g3-0001K7-6V for kitten@ietf.org; Wed, 24 Nov 2004 18:36:02 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA03551; Thu, 25 Nov 2004 00:31:06 +0100 (MEZ) From: Martin Rex Message-Id: <200411242331.AAA16183@uw1048.wdf.sap.corp> To: lukeh@padl.com Date: Thu, 25 Nov 2004 00:31:02 +0100 (MET) In-Reply-To: <200411242216.iAOMG4IX061286@au.padl.com> from "Luke Howard" at Nov 25, 4 09:16:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: Re: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 8bit Luke Howard wrote: > > >Have you noticed that the protocol can end up with two negotiation > >messages/tokens in the following two ways? > > > >1) The initiator includes a mechlistMIC token in the first message. > >2) The acceptor omits the mic_token exchange because it is safe to do > >so. > > Martin argues that in 2) the server should not send back a response. > > I haven't looked at RFC 2478 closely, but it seems to me that even in > in this case case the server should send back a NegTokenResp with the > negResult (accept_completed) and supportedMech elements. What I'm actually worried about is the synchronization of when both sides think the security context establishment is complete. Because once the security context establishment is complete, the implementation must return GSS_S_COMPLETE from either gss_init_sec_context() or gss_accept_sec_context() and at that point the application is free to start using the message protection facilities. Different from GSS-API v2, a GSS-API mechanism is therefore not longer permitted to return an additional (=optional) security context token, because that would create a prohibited interference of the applications permitted use of the message protection primitives after GSS_S_COMPLETE and SPNEGOs use of gss_getmic() to integrity protect the mechListMIC. So basically the negotiation token must reflect the state information whether an additional security token MUST be sent by the peer, or whether it MUST NOT be sent. There is no option. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:44:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17407; Wed, 24 Nov 2004 18:44:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6s3-0001Yr-UB; Wed, 24 Nov 2004 18:48:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6nr-00015w-GM; Wed, 24 Nov 2004 18:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6iC-0000ZO-Vt for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:38:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16905 for ; Wed, 24 Nov 2004 18:38:09 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6m9-0001SJ-JN for kitten@ietf.org; Wed, 24 Nov 2004 18:42:18 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 15:37:38 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 15:37:37 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 15:37:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 15:37:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 15:37:35 -0800 Message-ID: Thread-Topic: Open Issues on draft-ietf-kitten-2478bis thread-index: AcTSfQEt/ke/Lu/CRPuTCulc9ZzslgAASNew From: "Liqiang\(Larry\) Zhu" To: , "Sam Hartman" X-OriginalArrivalTime: 24 Nov 2004 23:37:37.0194 (UTC) FILETIME=[9479D0A0:01C4D27E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > I do not think it improves security either. We already established that if this creates a security weakness, because it prevents the SPENGO server from demanding mechlistMIC when that is needed. -- larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Wednesday, November 24, 2004 3:23 PM To: Sam Hartman Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis Sam Hartman wrote: >=20 > Jeffrey> (5) There was discussion on the list on the subject of > Jeffrey> whether or not there should be explicit text added to the > Jeffrey> draft recommending that implementations replace a SPNEGO > Jeffrey> token with a mech specific token when only one mech is > Jeffrey> available in the initiator. It seems to me that doing so > Jeffrey> would improve the security of the protocol as well as > Jeffrey> improve the performance. I did not see the discussion > Jeffrey> reach a conclusion one way or the other. Does anyone > Jeffrey> have some proposed text for this or should it be dropped? >=20 > I think it should be dropped. I don't see how it improves security. I do not think it improves security either. That was only to improve interoperability with gssapi mechanisms that don't have an accompanying SPNEGO. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:45:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17457; Wed, 24 Nov 2004 18:45:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6t4-0001ZX-RA; Wed, 24 Nov 2004 18:49:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6nx-00018e-4f; Wed, 24 Nov 2004 18:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6jy-0000aX-E4 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:40:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17093 for ; Wed, 24 Nov 2004 18:39:59 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6nw-0001U1-27 for kitten@ietf.org; Wed, 24 Nov 2004 18:44:08 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA08356; Thu, 25 Nov 2004 00:39:28 +0100 (MEZ) From: Martin Rex Message-Id: <200411242339.AAA16236@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 25 Nov 2004 00:39:27 +0100 (MET) In-Reply-To: <20041124232016.GO556007@binky.central.sun.com> from "Nicolas Williams" at Nov 24, 4 05:20:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > > But what I really dislike is the suprising "MUST process" of the > > optimistic token for the acceptor -- while rfc2478 said MAY ignore. > > If the acceptor selects that mechanism then it should be MUST process -- > how is the initiator to know that the acceptor didn't process its > optimistic token even though it accepted that mechanism? How do you understand the following text from rfc2478, under NegTokenTarg/NegResult, page 8: this feature allows to make a difference between a mechToken sent by the initiator but not processed by the target (accept_incomplete) and a mechToken sent by the initiator and processed by the target (accept_completed). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:46:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17538; Wed, 24 Nov 2004 18:46:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6uQ-0001bo-17; Wed, 24 Nov 2004 18:50:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6nx-00018z-Cd; Wed, 24 Nov 2004 18:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6kW-0000bB-9l for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:40:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17113 for ; Wed, 24 Nov 2004 18:40:33 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6oT-0001UK-U0 for kitten@ietf.org; Wed, 24 Nov 2004 18:44:42 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 15:40:09 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 15:40:04 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 15:39:44 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 15:40:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 15:40:03 -0800 Message-ID: Thread-Topic: Issues in SPNEGO-bis draft 00 thread-index: AcTSfbsMuULPpqbmSzaDjhsuy5j0TgAAPYng From: "Liqiang\(Larry\) Zhu" To: , X-OriginalArrivalTime: 24 Nov 2004 23:40:03.0661 (UTC) FILETIME=[EBC6E7D0:01C4D27E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Haven't we explicitly masked out prot_ready_state in section 3.1? To avoid conflicts with the use of MIC tokens by SPNEGO, partially-established contexts are not used for per-message calls: the prot_ready_state [RFC2743] will be false even if the underlying mechanism would return true natively. -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Wednesday, November 24, 2004 3:31 PM To: lukeh@padl.com Cc: Liqiang(Larry) Zhu; martin.rex@sap.com; kitten@ietf.org Subject: Re: Issues in SPNEGO-bis draft 00 Luke Howard wrote: >=20 > >Have you noticed that the protocol can end up with two negotiation=20 > >messages/tokens in the following two ways? > > > >1) The initiator includes a mechlistMIC token in the first message. > >2) The acceptor omits the mic_token exchange because it is safe to do > >so. >=20 > Martin argues that in 2) the server should not send back a response. >=20 > I haven't looked at RFC 2478 closely, but it seems to me that even in=20 > in this case case the server should send back a NegTokenResp with the=20 > negResult (accept_completed) and supportedMech elements. =20 What I'm actually worried about is the synchronization of when both sides think the security context establishment is complete. Because once the security context establishment is complete, the implementation must return GSS_S_COMPLETE from either gss_init_sec_context() or gss_accept_sec_context() and at that point the application is free to start using the message protection facilities. Different from GSS-API v2, a GSS-API mechanism is therefore not longer permitted to return an additional (=3Doptional) security context token, because that would create a prohibited interference of the applications permitted use of the message protection primitives after GSS_S_COMPLETE and SPNEGOs use of gss_getmic() to integrity protect the mechListMIC. So basically the negotiation token must reflect the state information whether an additional security token MUST be sent by the peer, or whether it MUST NOT be sent. There is no option. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:53:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17917; Wed, 24 Nov 2004 18:53:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX70g-0001j5-QJ; Wed, 24 Nov 2004 18:57:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6un-0002LM-Tf; Wed, 24 Nov 2004 18:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6t1-0001zd-Ea for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:49:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17783 for ; Wed, 24 Nov 2004 18:49:20 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6wy-0001fV-41 for kitten@ietf.org; Wed, 24 Nov 2004 18:53:29 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAONnKpv020572 for ; Wed, 24 Nov 2004 15:49:21 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAONnKjY028566 for ; Wed, 24 Nov 2004 16:49:20 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAONmbJ0557616; Wed, 24 Nov 2004 17:48:37 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id iAONmbOB557615; Wed, 24 Nov 2004 17:48:37 -0600 (CST) Date: Wed, 24 Nov 2004 17:48:37 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20041124234837.GS556007@binky.central.sun.com> Mail-Followup-To: Martin Rex , jaltman@columbia.edu, kitten@ietf.org References: <20041124232016.GO556007@binky.central.sun.com> <200411242339.AAA16236@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411242339.AAA16236@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On Thu, Nov 25, 2004 at 12:39:27AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > > But what I really dislike is the suprising "MUST process" of the > > > optimistic token for the acceptor -- while rfc2478 said MAY ignore. > > > > If the acceptor selects that mechanism then it should be MUST process -- > > how is the initiator to know that the acceptor didn't process its > > optimistic token even though it accepted that mechanism? > > How do you understand the following text from rfc2478, under > NegTokenTarg/NegResult, page 8: > > this feature allows to make a > difference between a mechToken sent by the initiator but not > processed by the target (accept_incomplete) and a mechToken > sent by the initiator and processed by the target > (accept_completed). That works only for mechs with one-token exchanges and... See the rest of that paragraph: Note: For the case where (a) a single-token context setup is used and (b) the preferred mechanism does not support the integrity facility which would cause a mechListMIC to be generated and enclosed, this feature allows to make a difference between a mechToken sent by the initiator but not processed by the target (accept_incomplete) and a mechToken sent by the initiator and processed by the target (accept_completed). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 18:56:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18133; Wed, 24 Nov 2004 18:56:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX74E-0001nn-Cd; Wed, 24 Nov 2004 19:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6xB-000330-4t; Wed, 24 Nov 2004 18:53:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX6vK-0002VP-V3 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 18:51:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17856 for ; Wed, 24 Nov 2004 18:51:43 -0500 (EST) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX6zH-0001h8-NJ for kitten@ietf.org; Wed, 24 Nov 2004 18:55:53 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA13928; Thu, 25 Nov 2004 00:50:56 +0100 (MEZ) From: Martin Rex Message-Id: <200411242350.AAA16367@uw1048.wdf.sap.corp> To: martin.rex@sap.com Date: Thu, 25 Nov 2004 00:50:56 +0100 (MET) In-Reply-To: from "d019080" at Nov 25, 4 00:47:17 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, lzhu@windows.microsoft.com Subject: Re: Issues in SPNEGO-bis draft 00 X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit Martin.Rex wrote: > > > > >Have you noticed that the protocol can end up with two negotiation > > > >messages/tokens in the following two ways? > > > > > > > >1) The initiator includes a mechlistMIC token in the first message. > > > >2) The acceptor omits the mic_token exchange because it is safe to do > > Maybe I was just confused by the wording above? > > Omitting a token exchange would break the architecture. > Omitting a specific content in a token exchange (like a particular > mechListMIC) would be ok. Ooops, I meant to say that Omitting a specific content in a token exchange would be ok with the GSS-API architecture. One would still have to check whether it breaks the SPNEGO protection promise or backwards compatibility. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 20:08:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23277; Wed, 24 Nov 2004 20:08:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX8Bl-0003PJ-FN; Wed, 24 Nov 2004 20:12:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX86S-0000ZZ-Hl; Wed, 24 Nov 2004 20:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX83B-0008QF-6M for kitten@megatron.ietf.org; Wed, 24 Nov 2004 20:03:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22885 for ; Wed, 24 Nov 2004 20:03:55 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX879-0003Gp-BJ for kitten@ietf.org; Wed, 24 Nov 2004 20:08:03 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 17:03:24 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 17:03:23 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 17:03:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 17:03:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 17:03:23 -0800 Message-ID: Thread-Topic: Open Issues on draft-ietf-kitten-2478bis thread-index: AcTSeR4eVxVJBQI2T7GuvfYTMB1xCwAETSaA From: "Liqiang\(Larry\) Zhu" To: , X-OriginalArrivalTime: 25 Nov 2004 01:03:24.0195 (UTC) FILETIME=[9053D730:01C4D28A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Now if implementors get that part of rfc2478 wrong, then I don't have any hope that implementors get the current=20 > rfc2478bis right, because it is a least a magnitude more complex. I strongly disagree, vanilla 2478 is impossible to implement because it is underspecified. I have at least 3 implementers who indicated to me independently 2478bis is very easy to translate into code! -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Martin Rex Sent: Wednesday, November 24, 2004 2:55 PM To: lukeh@padl.com Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis Luke Howard wrote: >=20 > >(3) At IETF61 there was a consensus call in the meeting room asking > > whether the use of optimistic tokens will be specified in 2478bis > > as a "SHOULD" or a "MAY". There was no consensus in the room. > > Is there consensus on the mailing list? >=20 > We would prefer SHOULD. Indeed, Heimdal right now requires the=20 > optimistic token (and this is unlikely to be fixed until it gets=20 > mechglue). I'm a little surprized? Do you mean that your SPNEGO acceptor will break if it receives an initial SPNEGO token without an optimistic context token? That this token was optional was quite obvious from the rfc2478 spec, and that spec is so short that it is hard to misread or misinterpret this part. Now if implementors get that part of rfc2478 wrong, then I don't have any hope that implementors get the current rfc2478bis right, because it is a least a magnitude more complex. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Nov 24 20:09:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23337; Wed, 24 Nov 2004 20:09:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX8CG-0003Q7-Ds; Wed, 24 Nov 2004 20:13:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX86n-0000ap-P1; Wed, 24 Nov 2004 20:07:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX85a-0000M2-2v for kitten@megatron.ietf.org; Wed, 24 Nov 2004 20:06:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23117 for ; Wed, 24 Nov 2004 20:06:24 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX89W-0003L2-AK for kitten@ietf.org; Wed, 24 Nov 2004 20:10:32 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 17:05:57 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 17:05:51 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 17:05:31 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 17:05:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4D28A.E7DC45F3" Date: Wed, 24 Nov 2004 17:05:51 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Open Issues on draft-ietf-kitten-2478bis thread-index: AcTSd/ohPEapltCaTy2b72u9MOlj3QAEpo8A From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 25 Nov 2004 01:05:51.0424 (UTC) FILETIME=[E8153400:01C4D28A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: kitten@ietf.org Subject: RE: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D28A.E7DC45F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > then I have Ken on the record for MAY (from his posting to this mailing list, I don't know about IETF hallway=20 > discussions). Ken is for "SHOULD". See attached. -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Wednesday, November 24, 2004 2:50 PM To: Liqiang(Larry) Zhu Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis Liqiang\ wrote: >=20 > Jeff wrote: > > Is there consensus on the mailing list? >=20 > Humm... This sounds a call for the duty of the chair.=20 >=20 > Folks, if you spoke before, I urge you to speak again. >=20 > Ken, Sam, Nico, Wyllys, and me preferred "SHOULD", please speak if=20 > this is accurate. If the consensus context was about the MAY or SHOULD support optimistic token, then I have Ken on the record for MAY (from his posting to this mailing list, I don't know about IETF hallway discussions). Folks, this is NOT about whether we put MAY or SHOULD into an entirely new document. This is about whether there are strong reasons that justify changing a MAY into a SHOULD for an existing spec. As it is, such a change will not affect interoperability, so a change is neither necessary nor advisable. >=20 > > There was a discussion on the history of the term "mechanism > > variants". =20 >=20 > Section 6 actually described what is a "mechanism variant". I agree we > can add a forward reference here. Sorry, but I strongly disagree. Section 6 further adds to the confusion by being extremely ambiguous/vague, and the motivation for rev'ving rfc2478 was to reduce ambiguity. Either we drop the mentioning of variants entirely or we standardize them in a non-ambiguous fashion. (Which might prove rather difficult, given the original ambiguity an few, if any, actual use in implementations. Anyone from Bull or the Original SESAME project listening? SESAME was the European counterpart for DCE, partly funded as a research project of the Europeaon union and a cooperation of at least one University and three companies Bull (FR), SSE/Siemens (IR) and ICL (UK) ? -Martin ------_=_NextPart_001_01C4D28A.E7DC45F3 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1110); Fri, 5 Nov 2004 17:21:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 17:21:51 -0800 Received: from igr-hub-01.redmond.corp.microsoft.com ([157.54.1.117]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 17:21:51 -0800 Received: from IGR-IMC-03.redmond.corp.microsoft.com ([157.54.8.120]) by igr-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Fri, 5 Nov 2004 17:21:51 -0800 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by IGR-IMC-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 17:21:51 -0800 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id iA61Lnef026280; Fri, 5 Nov 2004 20:21:49 -0500 (EST) Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id iA61Lm1U021532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 5 Nov 2004 20:21:48 -0500 (EST) In-Reply-To: <909C8866-2F8B-11D9-8DA2-000A95909EE2@mit.edu> Return-Path: X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 06 Nov 2004 01:21:51.0830 (UTC) FILETIME=[FEAE4760:01C4C39E] X-Scanned-By: MIMEDefang 2.42 Content-class: urn:content-classes:message Subject: Re: Comments on Larry's SPNEGO draft Date: Fri, 5 Nov 2004 17:21:46 -0800 Message-ID: <39F94049-2F92-11D9-8DA2-000A95909EE2@mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Larry's SPNEGO draft thread-index: AcTDnwKahJDG7cxNQgad3WQIwACZtA== From: "Ken Raeburn" To: "Liqiang\(Larry\) Zhu" , Content-Transfer-Encoding: quoted-printable *sigh* I thought I recalled RFC 2119 better than I did. "SHOULD" carries less weight than I thought it did, and the same weight=20 as "RECOMMENDED", which I was going to suggest as sounding weaker than=20 (I thought) "SHOULD" sounded, while still encouraging developers to go=20 in that direction. So, I guess I'm okay with "SHOULD" (or "RECOMMENDED") after all. =20 Sorry... Ken ------_=_NextPart_001_01C4D28A.E7DC45F3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten ------_=_NextPart_001_01C4D28A.E7DC45F3-- From kitten-bounces@ietf.org Wed Nov 24 20:45:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26326; Wed, 24 Nov 2004 20:45:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX8lP-00047f-PL; Wed, 24 Nov 2004 20:49:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX8gC-0006WQ-3f; Wed, 24 Nov 2004 20:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX8f1-0006F3-R0 for kitten@megatron.ietf.org; Wed, 24 Nov 2004 20:43:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26130 for ; Wed, 24 Nov 2004 20:43:01 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX8iz-00044l-GF for kitten@ietf.org; Wed, 24 Nov 2004 20:47:10 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 17:42:30 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 17:42:29 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Wed, 24 Nov 2004 17:42:31 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 24 Nov 2004 17:42:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 17:42:29 -0800 Message-ID: Thread-Topic: Open Issues on draft-ietf-kitten-2478bis thread-index: AcTSd/ohPEapltCaTy2b72u9MOlj3QAEzgrg From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 25 Nov 2004 01:42:29.0984 (UTC) FILETIME=[0686D600:01C4D290] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Folks, this is NOT about whether we put MAY or SHOULD into an entirely new document. =20 Your claim is ridiculously false! Vanilla 2478 does not contain a "MAY" in the terminology of RFC 2119. Even if a MAY were in RFC 2478, promoting it to a "SHOULD" does not break compatibility: the *receiver* will need to handle the optimistic token even we use a "MAY" there. -- Larry P.S. I do not want to go too far on this, but would the word "bloody sports" rings a bell here? -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Wednesday, November 24, 2004 2:50 PM To: Liqiang(Larry) Zhu Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis Liqiang\ wrote: >=20 > Jeff wrote: > > Is there consensus on the mailing list? >=20 > Humm... This sounds a call for the duty of the chair.=20 >=20 > Folks, if you spoke before, I urge you to speak again. >=20 > Ken, Sam, Nico, Wyllys, and me preferred "SHOULD", please speak if=20 > this is accurate. If the consensus context was about the MAY or SHOULD support optimistic token, then I have Ken on the record for MAY (from his posting to this mailing list, I don't know about IETF hallway discussions). Folks, this is NOT about whether we put MAY or SHOULD into an entirely new document. This is about whether there are strong reasons that justify changing a MAY into a SHOULD for an existing spec. As it is, such a change will not affect interoperability, so a change is neither necessary nor advisable. >=20 > > There was a discussion on the history of the term "mechanism > > variants". =20 >=20 > Section 6 actually described what is a "mechanism variant". I agree we > can add a forward reference here. Sorry, but I strongly disagree. Section 6 further adds to the confusion by being extremely ambiguous/vague, and the motivation for rev'ving rfc2478 was to reduce ambiguity. Either we drop the mentioning of variants entirely or we standardize them in a non-ambiguous fashion. (Which might prove rather difficult, given the original ambiguity an few, if any, actual use in implementations. Anyone from Bull or the Original SESAME project listening? SESAME was the European counterpart for DCE, partly funded as a research project of the Europeaon union and a cooperation of at least one University and three companies Bull (FR), SSE/Siemens (IR) and ICL (UK) ? -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Nov 26 16:06:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23655; Fri, 26 Nov 2004 16:06:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXnNG-0006yp-QD; Fri, 26 Nov 2004 16:11:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXnGq-0003Y1-4q; Fri, 26 Nov 2004 16:04:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXnGB-0003BM-6e for kitten@megatron.ietf.org; Fri, 26 Nov 2004 16:04:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23339 for ; Fri, 26 Nov 2004 16:04:04 -0500 (EST) Received: from stratton-four-o-seven.mit.edu ([18.187.6.152] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXnDj-0006WS-GV for kitten@ietf.org; Fri, 26 Nov 2004 16:01:36 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 23A19E003B; Fri, 26 Nov 2004 15:57:11 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Fri, 26 Nov 2004 15:57:11 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: spnego: Support must proccess optimistic token X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi. I'd like to express support for the current text that requires must process an optimistic token if one is provided. I believe this makes implementations simpler to code and reduces the testing matrix. Also, it is not incompatible with any of the reasons given for SHOULD send optimistic instead of MUST send optimistic. I understand Martin's concern that this text may make some existing RFC 2748 implementations non-conformant. I think that when recycling at proposed, which is what we plan to do for SPNEGO, it is acceptable to add additional requirements that have been found to be advantageous. There would be a higher bar to meet if it were impossible to meet the requirements of both RFC 2748 and the new requirements. However RFC 2748 clearly permits the processing of optimistic tokens. I do believe that Martin has brought up points regarding incompatibilities with RFC 2748 that require careful consideration. My generals thoughts are that we are going in the right direction and are doing the best job we can. However I'm still considering Martin's messages on the subject. I do plan to write a note giving my opinion on that issue once I finish forming it in the next day or so. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Sat Nov 27 16:18:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23693; Sat, 27 Nov 2004 16:18:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYA1o-0002rT-WF; Sat, 27 Nov 2004 16:22:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY9wH-0000z4-Q7; Sat, 27 Nov 2004 16:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY9vf-0000i1-W1 for kitten@megatron.ietf.org; Sat, 27 Nov 2004 16:16:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23629 for ; Sat, 27 Nov 2004 16:16:25 -0500 (EST) Received: from stratton-four-o-seven.mit.edu ([18.187.6.152] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYA0C-0002pw-12 for kitten@ietf.org; Sat, 27 Nov 2004 16:21:11 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 82C26E003B; Sat, 27 Nov 2004 16:16:33 -0500 (EST) To: "Liqiang(Larry) Zhu" References: From: Sam Hartman Date: Sat, 27 Nov 2004 16:16:33 -0500 In-Reply-To: (Liqiang Zhu's message of "Wed, 24 Nov 2004 17:42:29 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: kitten@ietf.org Subject: Re: Open Issues on draft-ietf-kitten-2478bis X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 >>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu writes: Liqiang(Larry)> Martin Rex wrote: >> Folks, this is NOT about whether we put MAY or SHOULD into an >> entirely Liqiang(Larry)> new document. Liqiang(Larry)> Your claim is ridiculously false! Vanilla 2478 Liqiang(Larry)> does not contain a "MAY" in the terminology of RFC Liqiang(Larry)> 2119. Even if a MAY were in RFC 2478, promoting it Liqiang(Larry)> to a "SHOULD" does not break compatibility: the Liqiang(Larry)> *receiver* will need to handle the optimistic Liqiang(Larry)> token even we use a "MAY" there. Liqiang(Larry)> -- Larry I wouldn't use language as strong as Larry, but I do agree with what he says. Promoting MAYs to SHOULD based on implementation experience is one of the things that commonly happens as standards are revised. Promoting SHOULD to MUST also happens; if you do that you need to recycle at proposed because you may cause implementations of the old spec not to conform to the new spec. You definitely want to make it possible to write an implementation that will work with the new and the old spec. I think a lot of Martin's reluctance here may come from the API part of GSSAPI. Interoperability rules for an API are more tricky in some ways than for a protocol. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Nov 30 16:23:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11251; Tue, 30 Nov 2004 16:23:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFYf-0001Ky-0t; Tue, 30 Nov 2004 16:29:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEeI-00029x-Rk; Tue, 30 Nov 2004 15:30:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEKp-0007YB-9N; Tue, 30 Nov 2004 15:10:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28827; Tue, 30 Nov 2004 15:10:49 -0500 (EST) Message-Id: <200411302010.PAA28827@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 30 Nov 2004 15:10:48 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-2478bis-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : The Simple and Protected GSS-API Negotiation Mechanism Author(s) : L. Zhu, et al. Filename : draft-ietf-kitten-2478bis-01.txt Pages : 24 Date : 2004-11-30 This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-2478bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-2478bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-2478bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-30111301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-2478bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-2478bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-30111301.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Tue Nov 30 22:17:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19349; Tue, 30 Nov 2004 22:17:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZL4f-0003fm-4T; Tue, 30 Nov 2004 22:22:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKyP-0005zn-Gw; Tue, 30 Nov 2004 22:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKwO-0005P5-0d for kitten@megatron.ietf.org; Tue, 30 Nov 2004 22:14:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19040 for ; Tue, 30 Nov 2004 22:14:01 -0500 (EST) Received: from stratton-four-ninety-nine.mit.edu ([18.187.6.244] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZL1b-0003aJ-Rb for kitten@ietf.org; Tue, 30 Nov 2004 22:19:29 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id DA7A4E0063; Tue, 30 Nov 2004 22:14:15 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Tue, 30 Nov 2004 22:14:15 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: Spnego and interoperability--Running code X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Especially in working groups where I'm fairly active as an individual contributor, I'l try and explicitly lable when I'm speaking as area director. I'll also generally label when I'm speaking as an individual, but if there is doubt I'm probably speaking as an individual. This message is definitely my individual opinion. I'm hoping to try and explain why the interoperability approach we're adopting in the new SPNEGO protocol is correct. Martin brought up a good point in the SPNEGO discussion. Roughly as I understand it, he is concerned that we're catering to the Microsoft implementation rather than what RFC 2478 says. An implementation that conforms to Larry's draft will not interoperate with a strict 2748 implementation. Even if the new implementation always sends a MIC, it will still fail to interop. If it is a server, it will fail because it requests a MIC using an option that older implementations simply do not support. I believe clients will tend to fail too. This is not ideal. I'm going to try and justify why I believe this is the right course of action for the IETF. The IETf is about producing a working Internet--running code is at the core of our mission statement. We write specs for two reasons. First, without having a written document to discuss, we find it hard to judge rough consensus. Second, we have found that clear specifications are the best way to get running code. As a practical matter, the SPNEGO implementers within the IETF have valued interoperability with the Microsoft implementation. SPNEGO is at proposed standard; it is reasonable for us to modify or withdraw the specification based on implementation experience. It's unfortunate that it has been sitting at proposed standard so long, but that's where we are. martin made an argument that the base GSS-API and C bindings spec are actually more mature than their standars level indicates. I agree with that argument but do not think it applies for SPNEGO. For one thing, the spec is critically flawed in that it doesn't tell you what encoding to use. Tom indicated that there are at least three possible encodings; discussion on the list suggested that the choice of encoding is rather arbitrary. Even if there are RFC 2478 implementations out there, they may end up not interoperating with themselves because of this defect in the spec. Martin proposed that we document correct behavior and include an appendix on how to interoperate with existing incorrect implementations. In principle that seems like a fine idea. However without changing what correct behavior is somewhat, there is no way to be secure and to interoperate with existing implementations. If we are willing to adopt Larry's approach, we get security between new implementations all the time while maintaining interoperability with the implementations we have within the IETF community. In my mind this is the best of the available bad solutions. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten